when was the last time we retired a security control?

In his talk, Josh asked a really thought provoking question:  When was the last time that the information security community retired a control?  If you take a look at lists of recommended security controls from 10 or even 20 years past, you will see many of the same measures that are found in the latest PCI, COBIT and other prescriptive documents.  Each year, a few new must have controls are added, much to the chagrin of CSOs and security personnel (who then have to spend more of their limited time and resources implementing new controls as well as maintaining existing ones) and to the delight of auditors (who get job security and longer audit checklists to fill out, and thus more billable hours).  This approach of continuous “improvement” of security “standards” is just not scalable, given most organizations’ unwillingness to fund the corresponding infinite growth of security resources (how unreasonable!).

Why is this happening?  Josh’s theory (with which I agree) is that auditors and standards writers tend to be very conservative.  In their minds, once a control is written down, it becomes revealed truth, and having more controls must ensure a higher level of security, right?  As a result, many organizations (especially those in heavily regulated industries like Finance, Health Care and payment card processing) seem to fear their auditors more than the attackers who the security folks are supposed to be fending off.   We have to make sure that we can check all of the boxes and get “good grades” on our audits and assessments, whether or not the controls being tested are relevant and provide real protection.

This model leads to a stifling of innovation in the info sec industry, according to Corman.  Since most info sec spending is concentrated around passing audits and fulfilling regulatory and compliance requirements, we continue to spend most of our time and money on legacy controls which may or may not be very effective at addressing evolving (and quite dangerous) threats.  We get that warm and fuzzy feeling from passing the audit, but that does not necessarily mean that we are well protected.  Security vendors respond to this pattern and concentrate their product offerings in spaces which address the tried and true controls they know that their customers need to meet.  They are simply not incented to come up with new ideas and better products and their marketing departments spend most of their time figuring out how to spread FUD and convince CSOs that their existing products somehow address the mind numbingly scary threat du jour.

A couple of examples come to mind:

Anti malware software – signature based anti malware software is having a harder and harder time keeping up with the threats we expect it to protect against.  More and more evil code is produced from toolkits which generate custom versions that differ from the AV vendors’ signatures just enough to slip by the defenses.  In a number of recent cases, totally customized, highly targeted code has been used to infect machines of interest and extract valuable information.  It seems to me that signatures are becoming less and less effective as controls against malware and that protections based on system behavior make much more sense.  Yet we still buy, deploy, maintain and update lots of signature based AV software, so that we can check the proper audit boxes and vendors don’t have real incentive to come up with new and more effective defensive products.

Passwords – One of the most frequent complaints I get from users at my company is that our password policies (long passwords with different types of characters that need to be changed pretty frequently) are a pain in the posterior.  I feel for them… complicated passwords that are changed frequently do provide protection against some threats, but it seems to me that the main threat to passwords today is malware which grabs the password as it is typed – and it doesn’t matter how long, complicated and frequently changed the password is.  Yet, we still enforce our password policy.  Part of the reason is that the policy does provide a certain level of protection against some threats, but in reality, we have kept the policy mainly because our business partners (customers, regulators, etc.) expect us to have such a policy and would look askance at us if we didn’t.  (In spite of recent research suggesting that the negative economic effects of these policies may exceed their protective benefit).

So… what do we need to do as an industry?  I think we need to start a dialog in which we take a long, hard look at the security controls we “require” and answer some key questions about them:

• What is the threat that this control addresses?
• Is the threat we are protecting against still a threat?  If so, has the nature of the threat changed significantly?
• How can we update the control requirements to better address the threat using currently available technology or processes?
• What new technology (if any) do we need from vendors in order to address the threat as it stands today?

The big question is how to get this discussion going… conferences like Security B-Sides, Defcon and the like are great places to start talking, but we need to find a way to get the mainstream security media and standards bodies to participate… going to be giving this a bit of thought and would love to hear from you with ideas!