The vast majority of corporate developers truly believe that application security is not their concern, assuming that network and engineering groups will build their environment in a secure way. But what about application security? Are you ready for the code audit?
Application Security Isn't Getting the Attention It Deserves
When most people in the corporate world talk about "security," they mean the security of the network, operating system, and servers. Organizations that want to protect their systems against hacker attacks invest a lot of time, effort, and money ensuring that these three components are secure. Without this secure foundation, systems cannot operate securely.
However, even if the network, server, and operating system are 100% secure, vulnerabilities in the application itself make a system just as prone to dangerous attacks as unprotected networks, operating systems, and servers would. In fact, if an application has security vulnerabilities, it can allow an attacker to access privileged data, delete critical data, and even break into the system and operate at the same priority level as the application, which is essentially giving the attacker the power to destroy the entire system. Consequently, the security of the application is even more important than the security of the system on which it's running. Building an insecure application on top of a secure network, OS, and server is akin to building an elaborate fortress, but leaving the main entryway wide open and unguarded.
There is a simple explanation to why this happens: tight project deadlines and unawareness of potential consequences. Project managers believe that answering that annoying review of the corporate security group takes care of everything. Not every project is reviewed by experienced enterprise architects, and even if it is, Java security is not one of the major skills of Java architects.
Most Developers Don't Know How To Write Secure Code
Most developers have no idea what writing secure code involves. Most have never thought about writing secure code - probably in response to the corporate world virtually ignoring application security, and very few have ever had to try writing secure code. Some developers have heard that buffer overflows and SQL injections can cause security problems, but that's about the extent of most developers' security knowledge.
When developers are asked to make applications secure, they start trying to find security bugs in the application - after it's been built. For example, they might look for dangerous method calls and remove them, using an application vulnerability scanner, or using a security mechanism such as mod_security or an application firewall to prevent exploitation. However, this bug-finding strategy isn't sufficient to meet today's complex security requirements, such as those mandated by the Sarbanes-Oxley Act . Testing problems out of the application is both inefficient and largely ineffective. Independent, end-of-process bug finding alone can't and on't expose all possible security vulnerabilities.
With penetration testing, which involves trying to mimic an attacker's actions and checking if any tested scenarios result in security breaches, security vulnerabilities will go unnoticed unless the tester has the skill and luck to design the precise attack scenarios required to expose them. Considering that there are thousands, if not millions, of possible scenarios for even a basic application, odds are some vulnerabilities will be overlooked. However, it takes only one security vulnerability to compromise the security of an application and its related systems - opening the door to attacks, as well as fines for not complying with security mandates.
Furthermore, penetration testing can fail to catch the most dangerous types of problems. Let's assume that you have a Web application to test, and this application has a backdoor that gives admin privileges to anyone who knows to supply a secret argument, like h4x0rzRgr8 = true. A typical penetration test against a Web application uses known exploits and sends modified requests to exploit common coding problems. It would take years for this test to find this kind of vulnerability through penetration testing. Even an expert security analyst would have a tough time trying to exploit this. What about a difficult-to-reach section of code in the error-handling routine that performs an unsafe database query? Or the lack of an effective audit trail for monitoring security functions? These kinds of problems are often entirely overlooked by even a diligent penetration test.
Other popular end-of-process security testing techniques - such as using static analysis to check whether code follows a standard set of security rules such as "Do not use java.util.Random" or "Use java.security.SecureRandom" - might expose some of the vulnerabilities that penetration testing overlooks, but come with their own share of problems. For instance, consider some of the weaknesses of trying to identify security vulnerabilities through static analysis. One is that these patterns don't consider the nuances of actual operation; they don't factor in business rules, or general security principles. If you have a Web application that lets your customer see their competitor's account by adding one to the session ID, this is a very serious problem. However, this kind of problem escapes static analysis because it doesn't involve a dangerous function call. Security assessment, in this sense, isn't always a bug to find, but a design problem to verify. Another problem is false positives. Static analysis can't actually exploit vulnerabilities; it can only report potential problems. Consequently, the developer or tester must review every reported error and then determine if it indicates a true problem, or a false positive. Sophisticated static analysis methods can improve accuracy, but ultimately, a significant amount of time and resources must be spent reviewing and investigating reported problems and determining which actually need to be corrected.
Complying with Sarbanes-Oxley
To comply with Sarbanes-Oxley (SOX), public companies need to effectively define and verify security policies for their financial and record-keeping applications.
Public companies are now required by SOX to implement and verify effective security for their financial and record-keeping applications. To comply with this requirement, it's necessary to establish an effective application security policy and verify that the policy is actually implemented in the code and reflected in the system functionality. By security policy we mean a document that defines best practice secure coding standards, secure application design rules, security testing benchmarks, privacy requirements, as well as custom security requirements.
According to SOX, having a security policy has evolved from a "nice-to-have" feature to an essential business requirement. Companies that don't establish and implement effective security policies could now be found to be negligent and face significant fines for failing to comply with SOX. A lot of developers and managers still treat security like they treat quality - they try to get as much quality/security as they can to the best of their knowledge, but often settle short of complete quality/security. However, systems that aren't 100% secure aren't acceptable under SOX. If development managers don't recognize this, they could cause their companies tremendous liabilities.
Defining a security policy doesn't satisfy SOX requirements; the specification items defined in the policy must actually be implemented in the code. In other words, the specification must truly be seen as requirements - not as suggestions or guidelines, as is typically the case with functionality specifications. The specifications defined in the security policy must be implemented…no ifs, ands, or buts. If your corporate information group doesn't have resources to enforce this, your architecture group may have to take this responsibility.
What's required to ensure that the security policy is implemented in the code? First, code should be statically analyzed to enforce the organization's security policy on the client and server sides. Static analysis typically looks for potentially dangerous function call patterns and tries to infer if they represent security vulnerabilities (for instance, to determine if code has unvalidated inputs, and if unvalidated inputs are passed to specific functions that can be vulnerable to attack).
Next, thorough automated penetration testing should be done to confirm that the security policy has been implemented correctly and operates properly. In addition, security should be verified through unit testing, runtime error detection, and SQL monitoring.
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.