Security Architecture

After formulating a conceptual security model identifying the key security features, we need to define candidate security architecture that represents an architect's view of the eRewards portal security. This means that we will make further architecture decisions to support development that allow us to start to tie together the security components in a cohesive application architecture. We will not bore down to the object level, but we will start to define services and subsystems that contribute to the end-to-end security. Upon identifying the candidate security architecture, we will perform a detailed risk analysis and identify mitigation strategies. We will also perform a trade-off analysis to meet the security criteria and support the business and architectural decisions.

Part of the job is already done. Due to business decisions, we have already decided to use a third-party identity management provider. This will drive a lot of the candidate architecture, because it imposes several constraints to begin with. Now we have to come up with a few high-level application components adopting security patterns. This will help us to illustrate candidate security architecture.

Figure 14-5 shows the logical representation of candidate security architecture for the eRewards portal. We adopted the core security patterns to represent the key security requirements in the logical tiers of the application architecture.

Figure 14-5. eRewards portal candidate security architecture

In the Web tier, we will use a Secure Base Action pattern for centralizing and coordinating all security-related tasks with Web components such as JSPs and Servlets. We will make use of an Authentication Enforcer pattern to authenticate Web requests and to verify authentication information established by our third-party Identity Provider.

In the Business tier, we will use a Secure Session Façade pattern that can contain and centralize all EJB interactions within a secure session. We will use an Obfuscated Transfer Object to protect the business data in a transfer object during transit.

To ensure Web service communication with service providers, we will make use of the Secure Message Router pattern, which facilitates applying message-level and transport-level security mechanisms before sending messages to Order management service and Membership service. To ensure secure sending and receipt of messages with service providers, we will make use of the Message Interceptor Gateway and Message Inspector patterns that allow us to enforce security mechanisms at the transport-level and the message-level, and to verify messages for standards compliance and other content-level vulnerabilities.

The candidate security architecture also consists of components at the network and host layers. Perimeter security design, DMZ architecture, patch management, and intrusion-detection systems are other key components that need to be part of the candidate security architecture artifacts. Because the scope of this book targets the application-level security solutions, we will assume that those tasks have been completed with as much due diligence, using known industry best practices.

Risk Analysis and Mitigation

After deriving the candidate security architecture, we will analyze the architecture for known risks in terms of potential threats and vulnerabilities and identify mitigation strategies to avoid them. We will study the risksboth qualitative and quantitativelyin light of architecture tiers, possibility of occurrence (expressed in terms of the number of prospects), probability (expressed in terms of likelihood of possible occurrences), impact (expressed in terms of effect that affects the overall architecture), and exposure (expressed as the level of acceptability). We will also identify the issues that expose those potential risks and how to mitigate them by identifying potential security patterns, best practices, and solutions.

Table 14-1 shows the risk analysis and mitigation strategies for a partial list of known risks and vulnerabilities. A complete risk-analysis document is available at the companion Web site (http://www.coresecuritypatterns.com).

Table 14-1. Risk Analysis and Mitigation

No	Known Risks	Tier/Component	Possibility of Occurrence (Single/Multiple)	Probability 1 Low 3 Medium 7 High 10 Extreme	Impact 1 Low 5 Medium 7 High 10 Extreme	Exposure 1 Low 5 Medium 7 High 10 Unacceptable
1	DoS/DDoS	Web tier	Multiple	10	10	10
	Issue: The portal is vulnerable to DoS/DDoS attacks because it is directly accessible over the Internet. There are many possibilities for carrying out DoS/DDoS by sending fake requests, initiating a flood of high-volume connections, malicious data injection causing buffer overflow, and exploiting application/configuration-specific weaknesses. These types of attacks usually consume Web/application server-specific system resources and deny accepting further user requests. During these attacks, if a legitimate user makes a portal access request, the request may fail completely or the page may take longer to download, and then making further transactions may not be possible. Mitigation: The preventive measures for DoS and DDoS include implementing router filtering to drop connections from untrusted hosts and networks and configuring fault-tolerant and redundant server resources. In addition, the Web/Application server must be configured to perform host-name verification, identifying fake requests and denying them from further processing. At the application level, the Web server may adopt security patterns such as Secure Pipe, Intercepting Web Agent, and Intercepting Validator.
2	XML-DoS	Web Services	Multiple	10	10	10
	Issue: The Web service endpoints are vulnerable to XML-DoS, where an attacker can perpetuate XML-based and content-level attacks by sending malformed messages, replaying legitimate messages, sending abnormal payload size, and sending non-compliant messages. These attacks lead to resource-intensive XML parsing, causing endless loops, buffer overflow, endpoint crash, or denial of further service processing. Mitigation: The safeguards and preventive measures for XML-DoS can be carried out by adopting Message Interceptor Gateway and Message Inspector patterns. These patterns secure access to Web service endpoints from message-level threats and vulnerabilities.
3	Man-in-the-Middle	Web Tier Web Services	Multiple	5	5	10
	Issue: The Web portal and Web service endpoints are vulnerable to man-in-the-middle attacks, where an unauthorized user is able to read or modify the business transactions or messages sent between two endpoints. The service provider or requester is not aware that the communication channel, the business transaction, or the message exchange is being compromised. Mitigation: The preventive measures for safeguarding Web tier components and Web services communication is done by implementing transport-layer security using SSL/TLS or IPSEC protocols. At the application level, the components can make use of Secure Pipe pattern.
5	Message-Level Security	Web Tier Web Services	Single	5	5	10
	Issue: The messages exchanged between Web service endpoints is vulnerable to malicious data injection, identity spoofing, message validation failure attacks, replay of selected parts, schema poisoning, and element/parameter tampering. Mitigation: Protecting Web service endpoints from processing malicious messages is done by enforcing message-level security and processing messages for endpoint-specific security criterion. The Web service endpoint can make use of the Message Inspector pattern.
6	Protecting Sensitive Information	Business Tier	Multiple	5	7	5
	Issue: The data passed around in the Business tier is subject to logging and auditing. This data will often contain sensitive information such as a person's credit card number or personal bank information. If this data gets logged, it may be subject to inspection by unauthorized parties and leave open the possibility of identity theft. Mitigation: To ensure that sensitive data does not get inadvertently output to a log file or an audit table, the Web service endpoint can use an Obfuscating Transfer Object pattern.
7	Restricting Access to Business Components	Business Tier	Multiple	1	9	5
	Issue: An attacker who has gained access to the internal network may attempt to communicate directly with the Business tier EJBs using RMI and thus by-pass the Web tier security protocols. This would allow the attacker to gain unauthorized access to Business tier services. Mitigation: Use a Secure Session Façade pattern to ensure that security is checked on the Business tier as well as on the Web tier. This can be done in conjunction with the Container Managed Security or Policy Delegate patterns.

In real-world scenarios, after the qualitative risk analysis, a quantitative risk analysis has to be performed. This helps identify all key risk elements and estimate the projected loss of value for each risk, such as infrastructure cost, potential threat, frequency, business impact, potential loss value, safeguard option, safeguard effectiveness, and safeguard value. Based on that information, we can estimate the potential losses and compute the annual loss expectancy (ALE), which helps to make a business case for identifying security countermeasures and safeguards. Refer to Chapter 8, "The Alchemy of Security DesignMethodology, Patterns, and Reality Checks," for more information about quantitative risk analysis.

Trade-Off Analysis (TOA)

After risk analysis, it becomes important to validate the quality of the security architecture, weighing the choices of security options, features, and alternatives. A trade-off analysis helps the security architect to make better decisions and allows justification of financial requirements that relate to the multiple security criteria, possible options, and recommendations.

For the Web tier, we need to perform a trade-off analysis of SSL Encryption options. The factors we need to consider are price and performance. Table 14-2 shows the trade-off analysis of the different SSL Encryption options.

Table 14-2. Trade-off AnalysisEffect Matrix for SSL Encryption

	In Software on Web Server	Hardware Accelerator Web Server	Dedicated Hardware Device	Remarks
SSL Encryption	1	+1	+5	-
	2	2	2	-

Table 14-3 illustrates the TOA effect matrix for weighing different choices for identifying a load-balancing option for the eRewards portal.

Table 14-3. Trade-Off AnalysisEffect Matrix for Load Balancing

	Bastion Hosts with Web Server Reverse-Proxy Load Balancing	Web Load-Balancer Appliances	Web Servers	Remarks
Web application Load-balancing	+7	+8	+5	-
	8	8	8	-

On the Business tier, we need to examine different data obfuscation strategies. The considerations for data obfuscation strategies include performance, security, and implementation costs. Table 14-4 shows the comparisons of the data obfuscation strategies.

Table 14-4. Load Data Obfuscation Trade-Off Analysis (Effect Matrix)

	Masked List Strategy	Encryption Strategy	XML Encryption Strategy	Remarks
Data Obfuscation Strategies	+1	5	8	-
	2	8	8	-

A TOA artifact is also available at the companion Web site (http://www.coresecuritypatterns.com). Refer to Chapter 8, "The Alchemy of Security Design: Methodology, Patterns, and Reality Checks," for more information about trade-off analysis.

Applying Security Patterns

To address the key security requirements defined at the beginning of the chapter, and based upon the outcome of our risk analysis and trade-off analysis, we have identified a set of security patterns for use within the application. These patterns are identified as part of the mitigation strategy identified for the associated risks. These patterns are highlighted (in black boxes) in Figure 14-6.

Figure 14-6. eRewards portal application: security patterns used

To mitigate known risks, the application architecture, including the Web portal and service providers, will make use of the following security patterns:

• Secure Pipe: Provides transport-level data confidentiality and data integrity between the client, the portal, and the partners. Using client certificate-based mutual authentication also ensures non-repudiation.

• Secure Base Action: Acts as centralized security manager for the Web tier. It coordinates authentication, validation, and security logging for all Web requests.

• Authentication Enforcer: Authenticates clients by verifying identity information passed by third-party Identity Provider.

• Intercepting Validator: Validates input passed in from Client.

• Secure Logger: Logs all security-related activity to a secure store.

• Secure Service Façade: Provides security to all Service Provider components. Provides auditing facilities through the Audit Interceptor.

• Audit Interceptor: Captures audit events using the Secure Session Façade strategy.

• Obfuscated Transfer Object: Acts as a generic Transfer Object and employs a Masked List Strategy for obfuscating sensitive data written to logs and audit trails.

• Secure Message Router: Handles messages to multiple endpoints securely, applying message-level security and the SSO token.

• Message Inspector: Verifies messages for message-level security mechanisms including authentication, authorization, signature, and encryption, and identifies content-level vulnerabilities.

• Message Interceptor Gateway: Acts as the entry point for enforcing security on the incoming and outgoing XML traffic. It ensures transport-level security and verifies messages for standards compliance, conformance to mandatory XML schemas, message uniqueness, and peer authentication of originating host. It makes use of the Message Inspector pattern for verifying message-level security threats and vulnerabilities.

These patterns address the key security requirements and mitigate those identified risks that span the Web-, business-, and Web Service tiers. We specifically chose not to address implementations of the Identity tier because such implementations are best performed by the third-party Identity Provider that is chosen by the eRewards portal owner. In this portal scenario, the Identity Provider is identified as a Liberty-enabled security infrastructure whose implementation is not discussed.

Other Security Patterns Used

To address other security requirements of data confidentiality, data integrity traceability, auditability, and accountability specific to the infrastructure, we chose to use the following application security design patterns:

• The Secure Pipe pattern ensures that the channel or transport layer between the client and the server or between servers is protected. For client-to-server communication, SSL is used to support communication privacy and integrity. This applies to the online portal as well as the back-end application infrastructure.

• The Intercepting Web Agent pattern applies to both the Web server and the application server when configuring the Web server plug-in to intercept requests for verifying the originating hosts and request parameters in order to identify fake or forged requests, potential DoS, and man-in-the-middle attacks.

• The Intercepting Validator pattern helps validate the input parameters prior to performing user authentication and service invocation.

• The Secure Logger pattern provides logging services capability to the Web tier application server infrastructure. It is used in both the Web portal and the back-end application server. It captures all events and messages, including the identity, requested operations, and results returned. This supports the security requirements of an audit trail and traceability of application requests, state of requests, and failures.

• The Audit Interceptor pattern is a Business tier security pattern that provides a centralized means for recording audit events. It allows developers to declaratively define events that will be captured to an audit log for long-term retention. It prevents developers from having to programmatically define audit events across the Business tier by intercepting service requests and auditing events based on a centralized event catalog. It is essential to support audit reporting and compliance security requirements in both the Web portal and the service provider's environment.

Security ArchitectureDetailed Components

Security services associated with the business services in the Web, business, and Web Services tiers address the security requirements of authentication, authorization, data privacy or confidentiality, availability, data integrity, and non-repudiation. The Client logs in with the Web portal, and the controller servlet manages the user interaction. The Authentication Enforcer and Secure Base Action patterns handle the user authentication (authentication) and redirect the user to the Identity Provider for authentication services (and thus for single sign-on). Upon successful authentication, the Client makes selections for browsing the online catalog, placing an order, or requesting order fulfillment for the merchandise ordered (see Figure 14-7).

Figure 14-7. eRewards portal security architecturedetailed components

In the portal, each exposed business service is represented using a servlet to handle the business processing. To interact with service providers, the servlets use JAX-RPC handlers to invoke remote Web services. In cases of service providers using the J2EE environment, the servlets communicate with their presentation components, such as JSPs and servlets to invoke their business EJBs.

After enforcing authentication and authorization, the catalog servlet enables a Client to browse through the merchandise catalog and select specific product items to place into their shopping carts. The catalog servlet uses a JAX-RPC handler to invoke a remote catalog Web service over HTTPS. The Secure Message Interceptor pattern intercepts the SOAP message to examine the user credentials and signature in the SOAP service request (data privacy and data integrity).

The order management servlet takes a product or a group of product items selected in the catalog service and places an order with the back-end order management system using a membership service servlet. It uses a membership servlet to retrieve the membership award balance and verify if the requesting Client is eligible and entitled to redeem the merchandise (authorization). The membership servlet communicates with the membership service servlet over HTTPS, which uses the Secure Session Façade pattern to delegate to the back-end membership service, which is implemented in EJBs. Upon successful verification of the membership award balance, the order management servlet will issue a document-style SOAP service request over HTTPS using a JAX-RPC handler to invoke the remote order management service. The handler will make use of a Secure Message Router pattern to route the SOAP messages to the relevant service providers or external partners, applying all required message-level security mechanisms. It ensures that the SOAP message is also encrypted and digitally signed to provide message-level confidentiality and integrity so that the message can be viewed only by the intended recipient.

Web Tier

On the Web tier, the Secure Pipe pattern was chosen to provide a secure communication channel. This protects communications between the client and the application from eavesdropping, man-in-the-middle attacks, and data injection or corruption. The Secure Base Action pattern is part of the entry point into the application and server to enforce security on the front-end in conjunction with other Web-tier security patterns. The Authentication Enforcer provides us with a means for encapsulating and decoupling the mechanism used for authentication from the actual establishment of the client's identity. Because the actual authentication is performed outside the application by a trusted external Identity Provider, the actual job of the Authentication Enforcer is simply to verify the trusted provider and its credentials. The encapsulation of the authentication mechanism assures us that if, in the future, authentication is moved back into the application, those changes will be isolated in one spot and not impact the rest of the Web tier. The Intercepting Validator is responsible for validating and cleansing the data passed in on the HTTP request. This provides protection from data corruption attacks such as SQL injection attacks, cross-site scripting attacks, and malformed requests aimed at crashing the site. Finally, the Secure Logger logs all of the relevant information about the request to a secure store so that if intruders did gain access to the application, they would not be able to alter the logs and conceal their attack.

Business Tier

On the Business tier, the Secure Session Façade pattern is used to provide a secure entry point into the business services. It has the responsibility of ensuring that auditing and any other security function is performed prior to service invocation. In this case, auditing is delegated to the Audit Interceptor, which audits service invocations, responses, and exceptions as defined declaratively. The Obfuscated Transfer Object is used to pass data between the Web tier and the Business tier and between service providers in the Business tier. It takes responsibility for obfuscating sensitive data passed back and forth, thereby removing that responsibility from service providers themselves. That way, credit card numbers, bank information, and other account details are not improperly written out to logs or the audit store.

Web Service Tier

The Web Service tier consists of the Secure Message Router, the Message Inspector, and the Message Interceptor Gateway. The Secure Message Router is used to provide message-level security between the portal and the trading partners. It configures the SSO capabilities between the partners and notifies them of global logout events. Additionally, it provides transformation of incoming messages to the message formats required by the service providers. The Message Interceptor Gateway sits in front of the Web Services interface to the application. It acts as a proxy and facilitates enforcement of channel-level security, including creation of SSL connections, IP verification, and some URL access control. It delegates data validations to the Message Inspector.