There is no such thing as perfect security. Some may even say that the best security can hope to be is the “least breached” instead of the “overall safest.” An article by Jack Danahy echoes this point and suggests that doing something to solve a security issue is not always better than doing nothing at all:
Are organizations better off when, institutionally or experientially unable to address the real or complete issue, they choose to do “what they can do”? I don’t think so. Unless there is an uncommon (all right, never-before-seen) transparency about the security conditions that are not met by a chosen solution, there are two immediate results to the selection of the incomplete solution. The first is that the pressure and organizational commitment to resolve the issue is diluted and effectively removed. The second is that there is seldom an analysis of what percentage of the original risk is actually being mitigated.
Danahy warns that taking the feel-good course of action can open you and your company up to a number of security risks because it gives you the feeling and satisfaction of having done something about the problem without actually having changed the problem at all. He says that, in such cases, “the organization has now taken its institutional eye off the ball, and it is feeling good about doing something.” Danahy argues that the real root of the problem is that the ultimate purpose for security adjustments is being inaccurately defined. Fixing half of a problem may sound better than not fixing any of it, but it does not help that the other half of problem is still waiting to cause trouble. Danahy uses the example of having a fever to illustrate his point. If a person has a fever, taking a few aspirin and forgetting about it instead of looking into the root of the problem is ill advised. The fever will most likely persist until the cause behind it is named and dealt with. The same goes for security issues. Calming the effects of a security issue does not make the issue go away. If the issue is left unchecked, it could potentially fester into something much more dangerous. Instead of taking the “better than nothing” approach, Danahy offers five steps that will prove to be more valuable:
- Identify the type of assessment you are trying to do.
- Define the security characteristics that are required in the software or system.
- Communicate the trade-offs that will be made in deciding on the approach.
- Force transparency for your own partners.
- Embrace the aspirational nature of the finer-grained elements of security.
Most importantly, one needs to decipher the root of a problem before one hopes to properly address it. Danahy recommends giving yourself a mental test when you are dealing with security issues. Ask yourself if what you are doing would be best characterized as “best for our organization” or “better than nothing.” Unless the organization comes out on top, nobody wins.