Core Security Patterns: Best Practices & Strategies for J2EE, Web Services, & Identity Management
By Christopher Steel, Ramesh Nagappan, and Ray Lai
Published by Prentice Hall
ISBN: 0131463071 Buy Now!
The Alchemy of Security Design - Methodology, Patterns, and Reality Checks
In a typical application development environment, architects and developers share similar experiences. They deploy business applications in a highly compressed time framemaking the applications work, testing the functionality at all levels, ensuring that they meet expected system performance or service levels, and wrapping the applications with an attractive client presentation and user documentation. Ensuring the security of the application at all levels has usually been considered at the last phase of the development process. If this is your company's current application development process, then you are not alone.
End-to-end security should be adopted and accomplished as part of the early application design and development process. It should not be addressed at the end of the deployment phase or even considered just before the system testing in a preproduction environment. If you wait to consider security at either of these points, your options for reactive or post-mortem security fixes are very limited. And it is important to note the fact that there is no rollback for an application security breach.
In an enterprise application development life-cycle process, different architects may have different security architecture design perspectives for the same set of security requirements. Some assume that they can secure applications with infrastructure security protection (for example, firewall policy and proxy topology). Some would prefer to secure applications using a specific-vendor security framework and infrastructure solutions that are categorized as best-practice solutions for application security. Nevertheless, what was considered secure application design may appear to be insecure if someone discovers a loophole in the application that the security architects have overlooked in the early design stage. It would be challenging to create a quality application security design that is repeatable yet reliable, so that architects could ensure all aspects of application security are considered during the early design stage in a structured manner. In addition to that, there are industry best-practices for applying security that need to be put in place before the application design process. It is always accepted as a good practice to proactively check and verify the security design for risks, tradeoffs, security policies, proactive defensive strategies, and reality checks upon completion of the application design phase. After production deployment, it is also important to adopt reactive security measures and defensive strategies to ensure service continuity and recovery in case of a security breach or malicious attack. These help in identifying and thwarting security-related threats and vulnerabilities in all facets of the application development life-cycle process, from use-cases to components, from components to prototypes, from prototypes to final implementation, from implementation to production deployment, and until retirement. With such a detailed verification process, architects and developers can reduce critical security risks within the software development life cycle and prior to production deployment. This mandates a security design methodology that provides a systematic approach and a well-defined process.
This chapter will discuss the prescription for a robust security architecture design, which is the alchemy of securing business applications end-to-end at all levels. In particular, it will cover the rationale for adopting a security methodology, the process steps of security methodology, and how to create and use security patterns within that methodology. It will also look at how and why to do a security assessment as well as adopting a security framework.
An application or service may consist of a single functional component or multiple sets of disparate components that reside locally or over a network. Security is often considered as a complex process, encompassing a chain of features and tasks related to computer system security, network security, application-level security, authentication services, data confidentiality, personal privacy issues, cryptography, and so forth. More importantly, these features must be designed and verified independently and then made to work together across the system. Applying a security feature often represents a unique function that can be a safeguard or a countermeasure, which guarantees the application or service by preventing or reducing the impact of a particular threat or vulnerability and the likelihood of its reoccurrence.
The Security Wheel
Security is represented as a set of features that fortifies the entire application or service with safeguards and countermeasures for potential risks and vulnerabilities. Each security feature is like a spoke in a wheel. This means that each functional component in the entire system must be secured or the wheel will not have structural integrity and may well break apart. In order to accomplish this, a methodical process must be put in place to ensure that security is addressed properly and integrated across all of these varying components. From the user who is accessing the application or service over the network to the routers and firewalls on the perimeter of the system and then up through the application or service and the OS on which it residesa security design must identify the risks and address the safeguards and countermeasures of the system holistically. Incorporating fundamental security principles plays a vital role during the software design and architecture, and it also helps identifying and eliminating the risks and threats in the early phases of the software development cycle. The concept of a Security Wheel provides the basis for verifying the fundamental security principles mandated for securing an application or service.
Figure 81 illustrates the Security Wheel, which represents all of the fundamental principles of security.
Figure 81 Security Wheel representing the fundamental security principles
The Security Wheel is a logical representation of the fundamental security principles required for establishing Security by Default in an application or a service. It provides guidelines that need to be taken into consideration during the entire software development life-cycle, and it can be applied across all or selected components of an application or a service.
At the core of the hub of the Security Wheel sits the service or application that you are building. In this representation, it refers more to the business logic than the application as a whole. The service resides in a secured server host with minimized and hardened OS. (OS Minimization refers to fewer software components on a server infrastructure, and Hardened OS refers to a reconfigured OS that applies security measures specified by the OS vendor and retains no non-essential programs, protocols, or services.) The secured host includes storage devices and accessories. Both the service and the target host environment must be configured and deployed through a secure configuration management and reliable provisioning mechanisms. The service makes use of a common identity management solution that provides repository and supporting mechanisms for verifying an entity and its associated credentials, for logging, and for reporting all activities.
The spokes represent the following 12 core security services applicable to an application or a service.
- Authentication provides the process of verifying and validating the evidence and eligibility of an entity to carry out a desired action.
- Authorization provides the process of verifying and validating the rights and privileges granted to the authenticated entity.
- Confidentiality provides mechanisms of protecting the information during transit or in storage from intentional or unintentional unauthorized entities.
- Integrity provides the mechanisms for maintaining the information tamper-proof and unmodified by unauthorized entities.
- Policy provides the rules and procedures that can provide access control directives or a regulatory function to all entities.
- Auditing provides a series of records of events about an application or service activity. These records are maintained to support forensic investigation. It also helps in determining regulatory compliance.
- Management provides the mechanisms for centrally administering all security operations.
- Availability provides mechanisms for ensuring reliability and timely access to the application or service and also its prolonged continuity in the event of a disaster or service interruption.
- Compliance provides the assurance of a degree of constancy and accuracy by adherence to standards or regulatory requirements.
- Logging provides the mechanisms for recording events that can provide diagnostic information in case of errors, problems, and unexpected behaviors. The recording of these events is usually not driven by business requirements and is generally short-term and transient in nature. Failure to log such events will usually not necessitate cancellation of a transaction.
- PKI provides key management support for applying cryptographic mechanisms to protect data, transactions, and communication using a public-key infrastructure.
- Labeling is a process of classifying information based on roles and responsibilities to prevent unauthorized disclosure and failure of confidentiality.
The above-mentioned security services are the guiding security principles for providing a robust security architecture. Applications or services can be reviewed with these security measures during their design phases or at appropriate phases prior to deployment.
The Wheel Edge
The wheel edge represents the perimeter security: the network security components such as routers, firewalls, packet-filtering appliances, intrusion detection systems (IDS), crypto accelerators, and other devices that sit between the Internet and your network. They make up the solution for protecting the network perimeter from connection attacks based on IP addresses, TCP ports, protocols, and packet filters.
Across the service and OS and all the way to the perimeter security, every security principle must be addressed as a service that contributes to the overall security architecture. In some cases, many of these security principles, represented as spokes in the wheel, are only applicable to a few components of the overall application or a service. Nevertheless, each component within the system must be examined to determine the associated risks and trade-offs. Adopting a structured security methodology helps to ensure that all security principles are addressed and captured during the software development life cycle or prior to production.
About the author
Christopher Steel, CISSP, ISSAP, is the President and CEO of FortMoon Consulting and was recently the Chief Architect on the U.S. Treasury's Pay.gov project. He has over fifteen years' experience in distributed enterprise computing with a strong focus on application security, patterns, and methodologies. He presents regularly at local and industry conferences on security-related topics.
Ramesh Nagappan is a Java Technology Architect at Sun Microsystems. With extensive industry experience, he specializes in Java distributed computing and security architectures for mission-critical applications. Previously he coauthored three best-selling books on J2EE, EAI, and Web Services. He is an active contributor to open source applications and industry-standard initiatives, and frequently speaks at industry conferences related to Java, XML, and Security.
Ray Lai, Principal Engineer at Sun Microsystems, has developed and architected enterprise applications and Web services solutions for leading multinational companies ranging from HSBC and Visa to American Express and DHL. He is author of /J2EE Platform Web Services/ (Prentice Hall, 2004).