What are worse case, likely and best case security incident scenarios?

Matthew Hackling

Matthew has over ten years experience operating solely in the area of information security, holds a Bachelors degree in security management from ECU and is also a CISSP. He is a former Account Director in Deloitte’s Security & Privacy Services practice. Matthew has led security testing teams on assessments of large core systems replacement projects for banking institutions. He operates more in the area of information security governance these days, despite his urges still stay a bit technical. Hence he plays with backtrack linux, metasploit and new web application security assessment tools in his rare free time. Currently he runs his own consultancy called Ronin Security Consulting and holds the title of General Manager of Security Testing at Enex TestLab. He is an active member of the Australian Information Security Association, and held the office of Melbourne Branch Executive for a number of years. Matt’s security blog is called Infamous Agenda and he is an active twitter user with the handle @mhackling

When executives are making decisions they like to know the best case and the worst case for their decisions so that they can measure risks. This is because from risk comes reward! A government agency that takes no risks, offers no valuable services. A company that takes zero risks will go out of business. Every service/product/deal always has an inherent risk associated with it.

In the context of information security, a best case is pretty much the same for every scenario. The typical best case you could hope for is that the system or service you are securing will be used for a long time and will eventually be decommissioned without compromise, with any known security incidents reported. If you’ve spent nothing to secure it, perhaps you "bet the farm" and won the lottery—quite a gamble.

Depending on your "risk appetite" if you spent some money on securing the system, at the end of the time period you will see it as either a prudent investment that reduced risk throughout the lifecycle of the system, or an example of opportunity-cost because critical funding was misplaced at the time.

The worst case scenario in the information security context is the true inherent risk of the system or service. This is where a compromise has occurred and all security controls failed— or they were not even implemented in the first place. The organisation's protective security controls failed to block an attack, the detective security controls failed to detect the attack and the security incident response was un-organised and ineffective—and the organisation was actually notified by a third party, maybe even the media.

The worst case scenario is a breach occurring, with information disclosed or modified and fraud or identity theft or similar resulting. For example, a web server is compromised by a targeted attack. The firewall configuration is not effective and the internal network is penetrated. The customer database is exfiltrated and this also accidentally contains cardholder data because truncation is not being performed. The incident is not detected, so widespread fraud and identify theft occurs and the organisation’s bank actually notifies them of the theft, requiring an investigation. A fine is likely, as well as a class action lawsuit, media coverage, share price impact and other adverse outcomes.

The more likely security incident scenario is that the organisation’s controls are tested, and prove effective. For example, a web server is compromised, but the firewall configuration is effective and contains the intrusion. The intrusion detection system doesn't detect the compromise but a system administrator does his daily checks and identifies the incident. A security incident is declared and response is timely—containing and recovering from the incident. No adverse media coverage or reputational damage is encountered, and embarrassing calls from banks are avoided.

It is important to always consider the worst case scenario, as this helps us as information security professionals to think like an attacker and design "defence in depth" into our solutions by imagining all that can go wrong. However our design decisions should always be tempered while thinking about the most likely security incident scenario. This helps you to select cost effective security controls commensurate with risk.

So a few common sense maxims for you to consider in your practice:

1. Hope for the best, plan for the worst. Don't undercook security controls protecting high risk systems. 2. No tin foil hats. Don't overcook security controls protecting low risk systems. 3. Explain to stakeholders the most likely security incident scenario. Avoid sowing Fear Uncertainty and Doubt (FUD) in your interactions. 4. Use the most likely security incident scenario to drive the selection of security controls. 5. Use the most likely security incident scenario to drive the decision to penetration test (otherwise you'll test everything based on a worst case scenario). 6. Use the worst case scenario to select key security controls for enhanced assurance. The worst case helps you identify the key controls that prevent, contain and respond to incidents.

Follow @CSO_Australia and sign up to the CSO Australia newsletter.

Tags: scenarios, incident