Reality Checks

In the design process, architects and developers may have chosen multiple security patterns to meet the application security requirements. They may need to make certain compromises in order to meet other application requirements, such as application performance throughput or cost constraints. However, any trade-off should not sacrifice the overall business security requirements without proper sign-off by the business owners.

Table 8-12 shows application-specific security reality checks intended for ensuring production-quality security protection measures prior to deploying the J2EE-based applications or Web services to production. It is not meant to be exhaustive, but can be very handy for self-assessment.

Table 8-12. Security Reality Checks

Areas	Security Reality Check Item	Y/N	Remarks
Policy	Are there any documented security policies for J2EE-based or Web-servicesbased applications?		A written security policy is a key ingredient in a well-formed security architecture. The security policy document should clearly define the application, its users, and environment-specific security policies for the security design, implementation, and deployment. It should also then document associated procedures for securing the applications or the underlying infrastructure until its retirement.
Policy	Does the existing security policy cover the depth of application security that is associated with the following? Minimizing and hardening of the target operating system that runs the target applications Securing the application servers that run applications developed in J2EE or Web-services technologies Securing the business logic components and data objects Securing the production environment and the data center infrastructure.
Policy	Does the security policy cover the organizational standards, procedures, and design processes for data encryption, cryptographic algorithms, and key management?
Policy	Does the security policy cover any escalation procedure to manage security threats in case of security intrusion to the J2EE-based applications or Web services?
Policy	Do you have a business continuity plan that includes the business continuity of the application infrastructure to protect the applications and the associated risks?
Policy	How is the Security Policy communicated throughout the organization?		Options are e-mail, bulletin board system, newsletter, training sessions, and so forth. Security functions should not be treated as only security personnel's job. It should be considered as everyone's responsibility.
Policy	Is senior management aware of and supportive of the security policy? This includes regulatory requirements such as SOX, FISMA, and so forth		If not, security policy is doomed to be ignored. If management is not supportive of the current policy, but look to you to provide a secure architecture, chances are you will be blamed for everything bad down the road that occurs because of their reluctance to enforce security. It is important to make management aware of their responsibility in enforcing the policy.
Policy	Is there an application and data access-control security policy? Are access policy roles and groups clearly documented?		These are the policies for establishing roles and groups. A simple system, for example, will have users and administrators. A more complex system requires remote access management, personnel management, access to server administration, and so forth.
Policy	Are allowed and denied services and protocols documented? Is the network topology enabled with a firewall to protect the DMZ environment, including the hosts and applications?
Policy	Are the locations of physical management points to support policy accessed through routers, gateways, and bridges identified on network topology documentation and how often is documentation updated?		These stress the importance of topology documentation, which is the guide to identifying where possible breaches in data access security could occur.
Policy	Does control of data access conform to policy? Is there a privacy/encryption policy?		Encryption is typically required for services involving personal information, for example, online banking. Although efforts are usually made to only encrypt sensitive payloads in order to avoid the computing overhead that encryption incurs, it is often (especially for Web-based applications) the case that the encryption overhead is minimal compared to the communications overhead. SSL carries noticeable performance issues; to counter these overheads, it should make use of hardware acceleration with key storage.
Policy	How is data privacy ensured?		Online privacy is a very broad topic, but in our discussion we focus on the communication aspect, which is usually accomplished with encryption. It is important to pinpoint where the encryption is done, who is responsible for the product doing the encryption, and what technology/algorithm is being used. It is also important to know where the keys are stored and how they are managed. There are different methods for encrypting data between the client and a Web server, such as HTTP/SSL, which is transport-layer (or channel) encryption, and application-level encryption, which is encrypting data directly in the application. Data integrity can be accomplished through checksums or message digest algorithms. This is built into HTTPS, but at the application-level it must be implemented.
Policy	Are users aware of the need to ensure data privacy and follow information and data handling procedures. Are they aware of importance of using data sensitivity levels?
Policy	Is there an authentication and authorization policy?		These policies are more currently referred to as trust management. How is the trust established for a principal so that he or she is given authentication credentials and permitted authorization for certain functions? How is the trust maintained and terminated? Who is given the ability to give out these privileges? This portion of the security policy should lay these out in a step-by-step fashion.
Policy	Does policy prohibit sharing of authentication credentials, shared secrets, and so forth?		As stated previously, many headaches and finger-pointing episodes can be avoided by assuring a one-to-one relationship between each individual user and his or her authentication information. All actions and events should be traceable back to a unique credential (except for public access).
Policy	Does control of authentication and authorization conform to policy?		Password changes should be enforced regularly if a secure form of authentication such as S/KEY, smart cards, or biometrics are not used. This minimizes unauthorized users from borrowing or stealing passwords to access the system.
Policy	Is there a change management policy?		There should be a process in place for change management on both a system and a data level.
Policy	Is access provided on a "need to know" or "need to have" basis?		If accessing different databases, authentication should be performed on a per-transaction level. Access Control Lists are one way to accomplish this task.
Policy	Is access to data controlled so that users can only change that which they should have access to?		In many systems, the middle tier accesses all the back-end databases as one user. A sufficiently savvy client with access to one database may try to access another database or someone else's records. This is why access control should be performed on a per-transaction basis with sufficiently fine-grained control.
Policy	Do procedures for changing production systems and data exist?
Policy	Are access controls sufficiently flexible for users to do their jobs without compromising data confidentiality and integrity?		This can be accomplished in the ACL by specifying different levels of access (that is, read, write, append, modify, and create).
Policy	Does change management control conform to policy?		There should be a process in place to ensure that change management activities conform to a policy. This can be accomplished through routine reviews of log files.
Administration	Do you have a secure protection mechanism and well-defined procedures for key management (storing the key pairs used for authentication or generating digital signatures)? How are the key pairs managed? Where are they stored? Who can create, update, and manage key pairs?
Administration	Are the security design and administration control personnel separated?		Segregation of security design and administration is one of the security control best practices.
Administration	Do you have a regular security patch management process that applies to J2EE application servers, back-end application resources, and Web browsers?		There are new security threats discovered from time to time, especially for some operating systems and Web browsers.
Administration	How are security administration activities coordinated between locations?		Authorization databases may be mirrored; how is this process protected if separate systems are at separate locations or colocated using primary/secondary servers? Are the activities managed via delegated administration?
Administration	How is unauthorized access detected? Are automated detection tools in use? How are logs managed and reviewed?		Are repeated login failures detected and recorded? If repeated login failures are logged, there should be tools or mechanisms to monitor the logs and alert security personnel to possible hacking attempts.
Administration	Are security monitoring processes in use?		Efficient monitoring requires the use of intrusion detection systems (IDS) and filtering software that flags potential problems in accordance with the security policy in place. It is important that the IDS and filtering mechanisms are not performed during the creation of the audit trail; when problems arise, the more detail available from the audit trail, the better.
Administration	Are audit trails of authentication and authorization generated and reviewed?		Audit trails should record as much as possible and be reviewed with a healthy dose of filtering. No one will catch any problem in the middle of 1000 pages of normal access logs. It is important that any changes to authorization of existing users/groups be scrutinized.
Administration	What is the content of the audit trails?		At a minimum, an audit trail record should contain activity identification, the time of the activity, user identification, requested transaction, and results. Audits of administration changes should ideally contain old and new data.
Administration	Are audit trail mechanisms protected?		Most audit trail mechanisms, other than those that are directly related to a security product, are not protected from tampering. An attacker "covers his tracks" by removing incriminating entries from the audit trail and can foil detection. An authenticated audit trail can detect tampering; an audit trail to a write-only device (printer or CD-ROM) prevents tampering.
Quality of Services	Does your application security design support high availability of the security services, including the authentication of user credentials? In other words, have you included any design considerations to secure the application infrastructure, processes, and communications from loss or damage from disasters, accidents, or security attacks?		High availability of application security may include the use of hardware or software clustering of directory servers, Web Agents, Message Router Intermediaries, or any security service components.
Quality of Services	Do you have a recovery plan if your security components (such as Intercepting Web Agent and Secure Message Router Intermediary) are being compromised or fail to function? Do you have validation methods for verifying the integrity of those deployed components?		The recovery design of the security service component should be part of the design process. It should be represented in the infrastructure and/or application level.
Quality of Services	Does your application security design include any plan to predetermine the tolerance of application security failure?
Quality of Services	Does your application design include a recovery of the security services and provide an alternative infrastructure for the recovery while restoring the security services?
Quality of Services	Do you have a checklist of Java objects, Web services, XML messages, or any application design elements for which you need to evaluate or identify security threats?
Quality of Services	Do you have any risk management plan or any recovery strategies for each type of security breach?
Client Device Tier	Do you check for any suspicious "footprint" in the client devices (for example, PDA)?		Hackers may leave a suspicious footprint in the client devices for future "replay" or "exploit."
Client Device Tier	Are the key pairs stored securely in the local client device? How is the security assured?
Presentation Tier	How does the J2EE-based application design support login authentication?		Clear text password is strongly not recommended. It is considered highly insecure because the password can be sniffed on the network, but it may be sufficient with adequate protection that guarantees there is no danger of interception; at any rate, architects need to weigh those risks. Encrypted password via Kerberos tickets or SSL mechanisms. One-time passwords using a token device (for example, SecureID). Certificates (used with SSL). Browsers using SSL normally support server authentication via certificates. Client authentication using passwords over an HTTP/SSL connection is often used, but using client-side certificates are highly recommended.
Web Tier	How is the login information carried throughout the session execution: cookies, URL rewriting, or use of a security token?		Cookies in the clear-text form can be a source of attack. They should be encrypted, hashed, and timestamped to avoid session hijacking. URL rewriting must be protected using SSL and URL encoding/decoding mechanisms. Security tokens are set within the confines of an established security protocol such as SSL.
Web Tier	Does the session require encryption?		This is a measure of the importance of J2EE-based applications being dealt with. A positive answer means the bar has been raised for other security mechanisms, such as authentication, session state, and so forth.
Web Tier	Where is user authentication information stored?		Typically, there is a user lookup mechanism (database, LDAP, and so forth), which also holds authorization information about what the user is allowed to do now that we are confident he is who he says he is. However, certificate-based authentication may rely strictly on the certificate signature to ascertain authentication as well as authorization privileges.
Web Tier	Are local resources accessed use signed JARs?		A trusted applet or application (from a signed JAR) may perform actions outside of the normal Java sandbox, such as writing to the local machine's hard drive. Take care that the client sanctions these actions and make sure there is obfuscation that hides the business logic to protect the middle-tier business abstraction.
Web Tier	How is authentication done? How is authorized access controlled and how is authentication and authorization administered?
Web Tier	Is encryption hardware or software in use?		Hardware-based encryption is often more secure and has better performance. It provides a tamper-resistant solution. Software-based encryption is easier to install and change as necessary, but may be compromised if an attacker attains "root" access on the host machine.
Web Tier	How is encryption technology used?		It should be addressed in the application level, the network level, and at the host-environment level.
Web Tier	Does encryption technology use standard encryption algorithms widely recognized as being effective (for example, FIPS approved)?		There is a standard set of accepted encryption algorithms, many of which are in the public domain, but there are security products that use unproven encryption technology. Standard algorithms include Triple-DES, RSA, Diffie-Hellman, IDEA, RC2, RC4, and Blowfish. The newsgroup sci.crypt regularly publishes a FAQ that identifies features to look out for when reviewing an encryption security product.
Web Tier	Are there U.S. export or international laws to be considered while using encryption?		U.S. federal law currently restricts export of products using encryption technology. For an intranet environment where U.S. businesses have a presence overseas, this is not an issue. For a U.S. company offering services to overseas clients, this is an issue.
Web Tier	How is key management done?		Key management involves making sure each member of a communication has the correct key value to either encrypt or decrypt a data stream. Current encryption products involve the use of public-key technology, usually in the form of X.509 certificates. These are the certificates used by Web browsers from Netscape and Microsoft. The big problem today is finding out when a certificate has been revoked. A certificate always has an expiration date, but to date no standard method is in wide use for how to resolve premature certificate revocation; that is, revoking a fired employee's certificate.
Web Tier	How are secret keys kept private?		Some options: token device (for example, smart card), or password-encrypted file. Use of a plaintext file to store a secret key is risky because the key is easily compromised if the machine is successfully attacked, but such a measure is necessary for machines that need the ability to cycle without human intervention (typing a password or inserting a smart card). If an LDAP database is used, encryption between the LDAP server and the authenticating party should be considered.
Web Tier	What other authentication mechanisms are in place (smart cards, biometrics)?		Multifactor authentication combining smart card and biometric authentication is often considered as a reliable personal authentication option.
Web Tier	Is authentication tied to individual users?		Access can be granted to roles that can be assigned to individual users, thereby allowing user accounts to be tied to just one person. Efficiency is often realized by grouping similar types of users into one account. For some services (for example, the ubiquitous "anonymous" FTP account), it makes sense, but for most commercial services, an authenticated user should be an individual. This policy can assist clients with billing problems ("Who was logged on for 38 hours?") and help pinpoint liability when problems occur.
Web Tier	Are the Java security policy files and configuration files protected in the application server?		Is so, they should be protected with OS specific ACLs and residing on a read-only file system.
Web Tier	Do the application log files show the key-pair values and timestamps for troubleshooting?
Web Tier	Are the log files and audit trails stored and secured in isolated systems and accessible by authorized personnel only?
Web Tier	Are the XML schemas (or DTDs) used to validate the data quality as well as to detect any invalid data or suspicious actions?		Someone could potentially send a valid schema with a petabyte of data in it. This could cause more trouble for the application than a small file that was malformed. The schemas should include restrictions on the amount of data being sent to prevent this type of attack.
Business Tier	Is authentication and authorization used to control access to particular applications? Is authentication and authorization used to control access to particular data within applications?
Business Tier	Do users need to reauthenticate themselves for each type of access? Does the application make use of a shared security context propagation?
Business Tier	Does user authentication expire based on inactivity? How are unauthenticated users prevented from accessing network facilities? Is an authenticated session terminated after a period of inactivity ?		This helps pinpoint the extent of resources a malicious, unauthorized user can use up.
Business Tier	Are the authentication and authorization databases properly protected?		For password-based authentication, encryption of passwords is prudent. Certificate-based authentication databases need only contain public keys, that are by nature secure.
Business Tier	Are the EJB transfer objects obfuscated ?
Business Tier	Do you use the system ID (or one superuser ID) to update or access business data?		Applications should not use superuser IDs. In required circumstances, it should make use of role-based access control mechanisms to get access to what they need.
Business Tier	Is the JDBC communication with remote databases protected? Does it use encrypted communication to transmit JDBC statements?
Business Tier	Do you tightly couple the business logic with the security processing rules in the same application logic code?		N-tier application architecture design allows loose coupling of the business logic with security processing rules for better scalability.
Business Tier	Do you make use of role-based access to connect with back-end resources?		Role-based access is more secure, flexible, and scalable than user-based access.
Integration Tier	Are there any sensitive data encapsulated in a SOAP message?		Sensitive data in XML text encapsulated in a SOAP message can be easily snooped. Use of XML Signature and XML Encryption mechanisms to sign and encrypt sensitive payload in SOAP messages is often recommended.
Integration Tier	Are unused ports, OS services, and network devices disabled?		RPC ports are easily exploited for malicious attacks.
Integration Tier	Do you have security appliances to scan and inspect SOAP payload content and attachments for suspected malicious action?
Integration Tier	Are SOAP messages containing sensitive data or financial transaction encrypted and digitally signed during transit and storage?
Integration Tier	Can the intermediary (SOAP proxies) modify the message contents in SOAP messages? Do intermediaries make use of XML Signature?		Intermediaries must make use of XML signatures to prove the authenticity and privileges to modify the message contents.
Integration Tier	Do you protect all direct access to the WSDL ?		No public access to WSDL should be permitted unless the requesting entity is authenticated and authorized to download them.
Integration Tier	Does your application mandate selected encryption of the contents of sensitive business data in the SOAP messages?
Integration Tier	Do you encrypt SOAP messages that contain sensitive business data between SOAP proxies that route the messages?		SOAP proxies or intermediaries that route SOAP messages should be tamper-proof, and unauthorized access should not change the data contents. One way to provide data integrity and confidentiality is the use of XML Signature and Encryption.
Integration Tier	Have you properly set up individual user IDs for accessing the UDDI or ebXML service registry?		Some sites do not enforce access user IDs for the UDDI or ebXML service registry. Thus, hackers can easily hack in the service registry.
Integration Tier	Are your service registries highly available?		UDDI or ebXML service registries can be made highly available by hardware clustering or software clustering (for example, using vendor-specific replication features).
Integration Tier	Do you allow all users dynamic look-up of WSDL files and dynamic invocation of services?		WSDL can be dynamically looked up and then application can be invoked. The implication is that hackers may easily locate all Web services endpoints easily for future security attacks.
Integration Tier	Do you timestamp all SOAP messages?		Using timestamps allows identifying and preventing forged messages from further processing. It is also important to synchronize time throughout your environment.
Integration Tier	Do you set up any time-to-live token for all service requests?		Using time-to-live tokens helps detect DoS attacks using abnormal payloads and malicious messages requiring parsing with endless loops.
Integration Tier	Do you associate access control and rights for all requesting resources?
Integration Tier	Have you performed any security tests such as penetration tests or a regular host security scan for all intermediaries?		It is important to ensure that each of the host machines and network appliances is scanned for any suspicious footprint or unusual security-related activities. A security-host OS hardening and minimizing must be performed.