The Shifting Landscape of Security Controls, Part 3
Last month the Center for Internet Security released an update to its Critical Security Controls. Here's the final installment in a three post breakdown of the changes they made.
For the last installment in this series (read parts 1 and 2 here) I will look at the final 5 controls on the latest CIS Critical Security Controls list. While these are the bottom of the list, the insights these tools can bring to the infosec team is instrumental; so much so that #20 – despite being last on the list – is a requirement for PCI certification and is being expanded for PCI DSS version 3.0. To conclude I examine the companion document that provides guidance on something I’ve heard directly that many security leaders struggle with: quantifying security.
I’ll start with those controls that didn’t change position. Account Monitoring & Control remained in its previous spot at #16. Despite being near the bottom, this provides a valuable preventative measure. Simply stated, those accounts that are no longer needed should be removed. Often this falls off the radar of the infosec team because it seems such a mundane task, yet these accounts represent an unnecessary, and frequently unmonitored, entry point for attackers. If you create logins for a handful of auditors that give them wide access to company data, why would you leave these potentially privileged accounts alive with no need for them? Giving this control its due can limit the attack surface and ensure the true attack surface can be more efficiently watched. Eliminate the additional door to the bank vault if you don’t need it.
The last control in the list, Penetration Testing & Red Team Exercises (#20), also didn’t move from the previous version of the CSC. I find it curious that this control is the final one on the list; every single company that is subjected to PCI compliance is bound by the expanded standard that requires penetration testing. Why, despite the emphasis by PCI – an organization that strives to secure billions of credit cards and billion upon billions of annual transactions – is this so low on the list? My belief is that penetration testing is easy to do, but difficult to do effectively and consistently. The tools are readily available, with many of the top tools being open source software, yet the challenge comes from what to do with these tools. There is a great deal of art that goes with the science of pen testing; infosec professionals may not be comfortable with this broad grey stripe in their security program.
Of the remaining three controls, two fell considerably from the previous version: Security Skills Assessment dropped 8 spots down to #17, while Application Security Software dropped 12 spots to #18. Training is another area that is easy to do but significantly more challenging to do in a way that is impactful and regular enough to truly change employee behavior. Training can also get a bad reputation when organizations treat it as a static, one-off event that is often nothing more than several days spent in a conference room or in online courses. The employees put it off and only do it when their manager says it needs to be done; the employees look for ways to minimize the pain. But at the end of the day, when phishing is still succeeding, user training is not going away. With the high profile corporate breaches and the growth of ransomware and other attacks hitting employee machines, user education is too often coming from experience rather than in the classroom.
The next control I will discuss is the one that took the largest drop this year, yet still remained on the list – Application Security Software checks in at #18. A solid foundation is the key to a good house, and a well-designed application starts with security; yet this is near the bottom of the controls list. Part of the challenge here is the task of designing secure software by team members who may not be security experts to begin with. Other controls like Vulnerability Assessment (#4) are closer to the top of the list and act as a safety net in some sense; ideally the security is built in, yet often times the product needs to get out the door, and function takes priority over security.
The final control to analyze is #19, Incident Response and Management, which dropped one slot in this updated list. I am surprised this falls so low on the list. Given the number of breaches taking place, being able to understand what happened for both immediate reaction and long term strategic response is imperative. Adding a better lock to the back door is useless if I don’t know that the thief enters through a window. Organizations that invest in solutions here, whether via in-house software or through a third party, have a better understanding of what happened in an incident, including what was taken and what was not. How many breaches have come out to state that X million records were compromised, then a few days later that number changes, typically up, then it changes again? Damage control is hard enough without moving the target.
A complementary document to the CSC is the Measurement Companion that strives to help infosec professionals define how to quantify each of these controls. During conversations with prospects and customers I’ve often discussed how to quantify security, and almost always have been met with an answer that is vague at best. While this companion is not the Holy Grail, it does go a long way to help set objective metrics for a security program. The document outlines 95 quantifiable tests for controls’ effectiveness, though of that nearly 1/3 have no guidance around upper and lower control limits. With this a security professional must establish their baseline and look for ways to improve. The other challenge is the breadth of the control limits, ranging from a 10x range up to a 168x range. The bottom line is that this document represents a starting point and that you must apply logic to it to determine what will work best for your organization and your risk profile. Clearly companies that operate on a global scale, accept credit cards, and allow liberal employee software and device usage would face different challenges than that of a domestic business with a few tightly controlled machines in a single location.
What’s next? Now that you have a better understanding of the revised controls list it is time to put it in action. This can be as simple as a mental checklist or go all the way to a detailed audit by a third party to document exactly how well your organization stacks up to this framework. As your company moves along the security maturity curve, a deeper understanding of these controls will lead to better discussions around security and ultimately bring better decisions on how to best protect your critical resources.