General Java

Application architects have heard about the increased importance of security, but in many cases they really don't know how to approach this issue. In this article, I'll share my experience and define a few basic steps and checkpoints for building application architecture with security in mind.

This year, architects have started to face several domestic (SOX and HIPPA) and even international (Basel II) regulations that require a certain level of protection of the personal and financial data that's processed and owned by the companies. Though network and operating system security solutions have done a great job in their domains, there is still one weakly protected path to corporate data - it's a spectrum of commercial and homegrown applications. I won't discuss why security is important and what is required by the regulations because you can find a lot of related materials in JDJ and other on- and off-line resources. My goal is to identify and explain the most important steps to be taken toward security when building application architecture.

Step1: Requirements
Review your business and technical requirements to see if security is addressed there. If you find security requirements are absent or denied, e.g., "encryption of communication between servers is not required," collect and verify the requirements. In both cases, check requirements with the legal and compliance department - the statement "we usually do not do encryption for internal data exchange" may not be valid anymore in the light of new regulations.

During requirements gathering and analysis, identify corporate security resources and policies. In particular:

• Consider integration with identity management and access control systems (for example, Liberty Alliance Identity Management or BEA's WebLogic Enterprise Security solutions).
• Discuss user activities that should be controlled and later audited in order to meet the policies.
• Consider the use of application state/status monitoring (e.g., via JMX) to easier recognize abnormal behavior potentially caused by security violations.
• Consider the operational procedures for obtaining access permissions for application users and periodic user access recertification.

You can find some examples of security policies in the sidebar: Examples of Security Policies for Web Applications.

Step 2: Sensitive Resources
Examine business models, data sources, the data, and the user community for your future application. This should help you to recognize the points that might be the most lucrative to a potential intruder. In the process, you have to answer, at least, some questions, such as:

• How does the business model implemented by the application affect the financial reporting and status of your organization?
• Does the data include personal and/or financial information and how attractive it may be to an intruder?
• Are the data sources reliable and secured, and can/may you verify it if necessary?
• Are the application customers internal or external with regard to the served organization?
• If they are internal, do you really know who they are, e.g., does your application use information from the user provisioning and identity management system? If the users are external, are they controlled by your partner/provider or consumer organization or is it an open public audience?
• Due to the nature of the application and data, should you expect targeted intruder attacks or is it likely the application will be under less sophisticated "curiosity" attacks?

Step 3: Creation of the Architecture
Armed with the knowledge of corporate and industry policies, on the one hand, and with the picture of potential spots of security violation in your application on the other, create the architecture and the high level-design. Since we know there is no such thing as 100% security for the functioning application, the architect has to prioritize the potential risks of deliberate and accidental security violations and intrusions.

It's very important to estimate the consequences of a security violation or an impact of security breaches on the application, other applications, and your entire organization. Keep in mind that some intrusions are highly possible but may have no or very little impact. The others, on the contrary, are much less probable but cause consequences that may be terrible.

Here are two examples:

1.  Let's assume you've designed a Web application that would be deployed in a DMZ (demilitarized zone, i.e., the network zone between two firewalls). In our day, you have to expect continuous hacker attacks; if you constructed and deployed the application smartly (see Web Application Security Consortium, www.webappsec.org/), the majority of attacks would "die" in there and not penetrate into the middle and back-end layers.

2.  If you design an "internal" application that is accessible to the operation team and supporting developers, there are a lot of risks as well. For instance, you have to watch whether a database user name/password pair is stored "in clear" in the application configuration file. The probability of password misuse is low, but, as you know, in crisis situations we use all available developers, some of whom may be foreign contractors or even offshore programmers who have had little or no background check. So, a "clear" password is a "piece of cake" for really bad guys; with these passwords he or she can get access to a company's strategic data. Then, just use your imagination…

When security risks are prioritized, it's easier to concentrate on the most dangerous ones and address them sequentially, in an iterative manner, spreading the cost of security controls over multiple phases of application implementation.

Step 4: Secured Design Solutions
After you have identified and prioritized security risks, try to come up with more secure solutions, to the best of your knowledge. For this, don't ignore the operational aspects of the application - a lot of security concerns may be covered via operational activities, not by the code only. For example, the application might not need to manage login credentials for the users if there is a strong user authentication operational procedure in place. In another example, Application A maintains a password for Application B in the configuration file in the encrypted form; if both applications are deployed on the BEA WebLogic platform in a trusted domain, Application A would not need neither the password encryption nor the password itself for Application B.

In most of the cases, just following two architectural principles can provide a much higher level of security for the application. The principles are:

• Layered application architecture. The J2EE platform perfectly supports layered architecture. It contributes to the scalability, stability, and security of the entire application. If you accept an idea that each layer of the application responds to its special requirements (e.g., the Presentation layer responds to user experience requirements; the Business layer, business requirements; the Persistence layer, data management requirements), it will be much easier for you to design the application and preserve security integrity.
• Separation of responsibilities. For example, the delegation of data access from the Presentation layer to the Business layer can protect your database from easy exposure to the intruder of the Web application.