Just scanning the code for known security bug patterns and performing some penetration testing isn't enough. You need to have a security policy that defines how the code should be built to safeguard security, as well as how the code should be tested to verify that the required security was implemented.

Security Policy
What does a security policy involve? First, you define how the code needs to be written so that it isn't vulnerable to attack. This policy should be designed to prevent both types of possible security bugs: bugs in the code that cause security mechanisms to malfunction, and security mechanisms that aren't implemented correctly. The first case tends to be a problem when critical security tasks such as input validation or authentication are handled differently in different parts of the code. Not only is this bad for maintainability, it's bad for security because it introduces more attack surfaces where vulnerabilities can hide.

When implemented, all security-related operations specified in the security policy should be concentrated in one segment of the application. You can then focus your resources on verifying and maintaining the security of that one critical module. This centralized security policy acts like a drawbridge for a castle: it isolates the area attackers can exploit and allows for a more focused defensive strategy.

Table 1 shows excerpts from a security policy for a Java-based application.

Outsourcing and Security
Application security is one of multiple issues that outsourcing brings to the corporate table. For example, can you allow developers in other countries to have access to such sensitive information as social security numbers and bank account numbers? In developing countries the chances of such information being stolen are higher. This introduces the additional expense of creating separate environments for such teams (installing separate database and J2EE servers, and deploying data-scrambling software).

If you are outsourcing support of you applications, have you arranged for auditing the administrator's actions? If a user has been granted access to particular screens or specific data, do you have a record of who did it and when?

In some cases companies even outsource the process of running penetration tests.

Summary
The main goal of this article was to bring your attention to potential issues and security holes in your applications. Set and enforce security policies in your organization and consider doing penetration tests and static analysis of Java code using automated software testing tools.

Sidebar

Sarbanes-Oxley and Information Technology
Sarbanes-Oxley Act was signed into law by President Bush in July of 2002. It requires public companies to improve the accuracy and reliability of corporate reports and disclosures to prevent and punish corporate fraud. It has provisions for auditor independence and corporate responsibilities and sets stringent standards for corporate executives. This act was named after Senator Paul Sarbanes and Representative Michael G. Oxley.

One section of the law says that financial reports must be accurate and have to be certified by a company's top executives on a quarterly basis. From an IT point-of-view, this not only means that the software that produces such reports must be accurate, but also that it must be secure enough to prevent attempts to modify reports during or after their creation. Another section forces corporations to set effective internal control for reporting. Among other inspections, independent auditors can check if the application software keeps track of the deletion or modification of sensitive data.

This law requires that changes in the financial state of a corporation must be made available to the public in a timely manner. For IT this means that the infrastructure must include disaster recovery sites and data replication procedures that ensure the availability of such information to the public even if the primary data center is down.

For more details you can refer to the document "IT Control Objectives for Sarbanes-Oxley" published online by the IT Governance Institute.

As you can guess, corporate executives don't really like this law. They now need to spend a substantial part of their revenues on complying with the Sarbanes-Oxley Act.

They also need to pay more attention to the software quality and security or else they may face punishments anywhere from losing their job to jail sentences. They also have to think twice before saying "I do" to their partner outsourcers from overseas.

From the IT perspective, this law generates more jobs and new projects, especially in compliance departments. This act may not be as big as the Y2K hype, but it will definitely bring more people to the IT industry.