Countermeasures and Remediation Strategies
There's a class of actions, normally referred to as countermeasures, that are taken in response to security threats. You can think of burglar bars on your windows or shredding your credit card statements as countermeasures. Remediation strategies apply to what you do after your security has been compromised. If we look at attacks on security, what you can do about them is generally determined by the timing of the attack.
Prevention: Preventing or deterring the attack before it occurs. We buy a home alarm system so that the burglar will hit the house next door rather than ours. We reinforce our door locks to make it harder for thieves to break down the door.
Detection: Finding out about the attack as or shortly after it occurs. Our home alarm system automatically dials the security company if a door or window is opened.
Remediation: Choosing what to do after the attack has happened. We assess whether anything has been burgled from our home. If something is missing, we file an insurance claim. We take what we've learned about our vulnerability and apply it as prevention for the next attack.
In all honesty, it seems to me that there has been way too much focus on preventing security breaches that have moderate exposure and relatively low risk of occurring. Resources might be better spent on reasonable detection and remediation. In addition, way too much money is spent on some types of prevention strategies. What is the point of requiring small trading partners to use strong algorithms for encryption and digital signatures if the machines they use to communicate with you are in open offices, left on and logged in 24 hours a day?
The best you can do (if you are given a choice) is to assess what your real exposures and risks are, and then try to strike a reasonable, cost-efficient balance between prevention, detection, and remediation. However, since most of the requirements imposed on you have to do with prevention countermeasures, let's look at some of the options you might be offered.
Is It a Requirement or Is It a Countermeasure?For those of us who have spent much time studying nonfunctional requirements, it comes as no surprise that there isn't universal agreement about how requirements like security are decomposed. That is why I chose a somewhat authoritative source like ITSEC when I broke down security into confidentiality, integrity, and availability. You may not be surprised, therefore, to know that there is also frequent disagreement about what constitutes a requirement versus a design option or mechanism that satisfies the requirement. For example, many people might regard a password-protected login as a requirement. Others might regard it more strictly as an authentication mechanism for enforcing access control, which ultimately has to do with satisfying the requirements of confidentiality and integrity. In this book I'm not going to split hairs with this type of theoretical debate. To set a frame of reference, I'll try to follow the framework and approach defined in ITSEC. You don't have to agree with it, but it at least will lend some consistency to how we consider the issues. |