The following question was once posed to me by an IT Executive…
“How do you choose the products, projects, initiatives for the security team? Is it strategic or is it based on the flavor of the month”.
Sheepishly I had to admit there was a lot of “flavor of the month” to what we were trying to accomplish, he knew we were practicing “Shotgun Security”. Security professionals are human beings and are just as susceptible as everyone else to the shock and awe of a new vulnerability. There are so many sources of doomsday information out there that it’s hard not to become a reactionary agency. My team and many others are or were certainly guilty of this. We had been called out and it was time to adjust how we operated. Enter the Critical Security Controls.
The Critical Security Controls started its life as an exercise being ran by the Office of the Secretary of Defense. Like a lot of organizations out there, the Department of Defense struggled to prioritize cyber security spending. They turned to the NSA (National Security Agency) who has plenty of experience in cyber attacks. The NSA along with the SANS Institute and the Center for Internet Security came up with a list of controls based upon actual attacks. For an extensive history write up on the history of the Critical Security Controls go here.
My experience with the Critical Security Controls has been really great thus far. It’s a framework that is technology agnostic, focuses on what attackers are actually doing, and comes with metrics that can be reported throughout the organization. These are all nice, but for most security shops the nicest part of the framework is it’s something that is nearly impossible to be 100% compliant with so any step you take is considered effective instead of focusing on what you have left to do. When an organization gets over the hump of understanding that perfection is nearly unattainable we can finally focus on the items that can be completed to strengthen our security posture. This is why I love the Critical Security Controls.