In the realm of enterprise software, most test strategies simply aren't implemented at a strategic level - and that extends to the critical area of security testing. Despite the necessity for this discipline, motivating for a strategic enterprise-wide security testing strategy (STS) can be challenging, especially where testing is not taken seriously or seen as an exercise to keep customers and regulators happy.
The recent ITWeb Security Summit demonstrated the outdated and flawed notion of 'we'll never be hacked/compromised'. Speaker after speaker made clear that most companies are probably already breached to some degree. The summit therefore called for a mindset change: accept that the breaches have already occurred, and aim to minimise damage with hackers already inside the firewall.
Your STS must consider this aspect in addition to the protocols you already have in place to keeping unwanted visitors out.
When considering a risk-based approach, test managers must consider a few things when creating an STS for their enterprise.
* Departing assumptions. Assume a breach has already occurred and test for it. Understand the level of this risk and impact of this assumption on the application and organisation. Include the traditional assumption of attacks from outside your security architecture.
* Intent. Consider the intent of a breach. One is showing off - others include theft of funds and trade secrets, or malicious damage. Strategy and risk analysis should consider each intent and approach the security testing from these angles.
* Objectives. Any test strategy should considering whether or not you can continue doing business after a breach. Consider security aspects such as continuity, data integrity and confidentiality.
* Risk. Enterprise-wide STSes must consider associated risks with each of the components at each of the levels of the security architecture. The risks should indicate the impact of the loss of any specific piece of information on the enterprise.
* Organisational blind spots. To be effective, compel stakeholders to recognise blind spots in the security strategy. Be clear on the organisational challenges posed by a breach. Be realistic about the reality and assumptions made when determining risks associated with breaches.
* Consider all aspects of the security architecture.
- Layers. Consider the network and infrastructure, system software, application layers and the human element. Include how each component at each of the layers is vulnerable.
- People. The weakest link in any security architecture is the human element. The compromised element of your security architecture could be an employee.
- Other security components. Consider every component placed in the architecture in the context of security. For instance, if decoys or deception components are part of the overall security strategy, ensure that tests cover these.
- Breach responses. Test strategies should test the mechanisms in which breaches will be contained by the relevant stakeholders.
* Test continuously. Testing should occur continuously; vary test attack vectors and areas of possible contamination.
Any robust security testing approach has to balance cost, time and resources. A proven approach is to build and expand your strategy incrementally, focusing effort, time and budget on the highest risk areas and information, while acknowledging that breaches may occur in less important areas.
But even where a strategic approach is taken, be warned. It is a technically and politically complex undertaking and requires deep thinking and understanding in collaboration with a wide range of stakeholders across business and technology disciplines.
Share