Firstly, it's important to classify the data that the Web application uses. Where is it stored and how is it accessed and processed? Next, identify and evaluate the risks to this data and the systems and applications that handle it. This process is known as threat modeling and should really be carried out during the application-design stage. By analyzing a Web application from an attacker's point of view, you will gain a better understanding of how and why it may be targeted, and how best to mitigate any identified risks. The process also results in documentation that identifies and justifies the Web application's security requirements.
These Web application security requirements should align with the organization's overall security policy, which defines the objectives of how to legally protect its data. From here, decide how best to protect the Web application against any identified threats and reduce the risk to sensitive information. I have no doubt that rewriting some of the application's code, logic and functionality will remove some of the vulnerabilities. That effort should be supplemented by additional security devices, but your policy and strategy should make it clear what you need these devices to protect and from what.
When looking at threat-mitigation devices after building a Web application, review which types of threats they safeguard against. Some will provide safeguards against multiple threats, such as viruses, spyware and malware. Others may focus on a specific threat subsegment, such as securing instant messaging communication channels. Pay close attention to the depth of coverage and the technical approaches that each vendor uses to provide protection of one or more security areas. One problem with many attacks on application data is that they travel over valid client requests and responses; SQL injection is a classic example of this. Therefore, traditional perimeter defense technologies, such as packet-filter firewalls, are no longer adequate.
Performance and scalability are other important considerations. Some security devices may be limited as to how many transactions they can scan per hour. Other appliances may have networking limitations or only provide capabilities to protect a narrow range of application protocols. I think the key questions to answer when selecting a security device are:
1. What does it need to do based on corporate security policy objectives and requirements?
2. How will it fit into the existing network? Do the in-house skills exist to use it correctly and effectively?
3. How will it affect existing services and users, and at what cost?
4. What additional services does it provide that are of use?
Obviously all devices used to protect or process data need to be installed correctly. Installation needs to follow a four-step security lifecycle: secure, monitor, test and improve. This is a continuous process that, once followed through to completion, loops back on itself in a constant cycle of protection. Before any device is connected to the network, ensure that it has been hardened, applying patches as well as taking the time to configure the device for increased security. Be sure to reference your security policy during configuration to ensure the device is set up to do the job intended and in accordance with corporate security guidelines. Having spent time selecting and installing network defenses, it is important to conduct a penetration test to ensure they actually work as expected and deliver the desired protection. By simulating an attack, you can evaluate whether your site still has potential vulnerabilities.
For future reference, you must, of course, document any changes made based on the findings of a pen test and ensure configurations aren't changed unintentionally or without due process. You must also control physical as well as logical access to all network security devices. Relying just on perimeter security will not keep applications secure. Defenses must be built at every level: physical, network, and critically, application. Using the threat modeling process will ensure that security is also built into Web applications, increasing their resilience and reducing their reliance on perimeter security devices.
This was first published in February 2010