Page 2 of 3   « previous page   next page »

In other words, security requirements should be defined, implemented, and verified just like other requirements.

For example, establishing a policy to apply user input validation immediately after the input values are received guarantees that all inputs are cleaned before they're passed down through the infinite paths of the code to wreak havoc. If this requirement is defined in the security policy and then verified as implemented in the code, the team doesn't need to spend countless resources trying to find and test every possibility for user input.

One of the best strategies for building security into the application is to define how code needs to be written to protect it from attacks then use static analysis to verify that the policy is implemented in the code. This article provides an overview of how this can be done.

Develop a Security Policy
Security policies are espoused by security experts such as OWASP and mandated for compliance by many regulations such as Sarbanes-Oxley that require organizations to demonstrate they have done "due diligence" in safeguarding application security and information privacy. Yet, although the term is mentioned frequently, it's not often defined. A security policy is a specification document that defines how code needs to be written to protect it from attacks. Security policies typically include custom security requirements, privacy requirements, security coding best practices, security application design rules, and security testing benchmarks.

What do you do if your team doesn't have a well-defined security policy? If the organization has designated security experts, they should be writing these requirements. If not, security consultants can be brought in to help develop appropriate requirements for the specific application under development. Obviously, this would require considerable interaction with the internal team members most familiar with the application.

The security policy should describe what kinds of resources require privileged access, what kind of actions should be logged, what kind of inputs should be validated, and other security concerns specific to the application. To be sure key requirements aren't overlooked, I recommend listing all the important assets that a given application interacts with then prioritizing them based on the importance of protecting each asset.

Verify that the Security Policy is Implemented in the Code
Having an effective security policy defined on paper won't translate into a secure application unless the developers follow it in writing their code. Static analysis can be used to automatically verify whether most security policy requirements are actually implemented in the code and identify code that still needs work, isolating the remaining security policy requirements that might require unit testing, component testing, peer code review, or other techniques.

Using static analysis to automatically verify the code's compliance to application-specific security policy requirements (for instance, for authentication, authorization, logging, and input validation) requires expressing those requirements as custom static analysis rules then configuring the tool to check those custom rules. Often, developing such custom rules is simply a matter of tailoring the static analysis tool's available security policy rule templates to suit your own policy. For instance, custom SOA security policy rules can be created from templates such as:

• Don't import WSDLs outside a certain domain
• Don't import schemas outside a certain domain

  Custom Java security policy rules can be created from templates such as:
  

• Ensure all sensitive method invocations are logged
• Allow only certain providers to be specified for the "Security.addProvider()" method
• Keep all access control methods centralized to enforce consistency

If you're developing in Java, you'd want to do static analysis to check industry-standard Java security rules such as:

• Validate an HttpServletRequest object when extracting data from it
• Use JAAS in a single centralized authentication mechanism
• Don't cause deadlocks by calling a synchronized method from a synchronized method
• Use only strong cryptographic algorithms
• Session tokens should expire
• Don't pass mutable objects to DataOutputStream in the writeObject() method
• Don't set custom security managers outside of a "main" method

  For SOA, you'd want to check industry-standard rules such as:
  

• Avoid unbounded schema sequence types
• Avoid xsd:any, xsd:anyType and xsd:anySimpleType
• Avoid xsd:list types
• Avoid complex types with mixed content
• Restrict xsd simple types
• Use SSL (HTTPS) in WSDL service ports
• Avoid large messages
• Use nonce and timestamp values in UsernameToken headers

String name = req.getParameter("name");

To comply with this rule, the code would have to be modified as follows:

try {
    String name = ISOValidator.validate(req.getParameter("name"));
} catch (ISOValidationException e) {
    ISOStandardLogger.log(e);
}

Page 2 of 3   « previous page   next page »