This week for the CompTIA Security+ Exam, I was reviewing the definition and importance of Security Controls. For those who aren’t studying for the exam, or those who have never worked in a secure environment, Security Controls are things that you do or actions that you take to accomplish one of two goals:
- Protect your organization and its infrastructure from threats
- Remediate harm from threats that have manifested themselves
In non-auditor speak, basically these are the things that you do that either allow you to protect your organization or infrastructure from harm, or to help repair the damage if the harm has already occured.
Security controls come in different flavors, depending on where they originate. For example, you have Administrative (Managerial) controls if the action you are taking is about controlling what people do within an organization; examples are things like establishing policies for what kinds of things you can do on work equipment. You have a Physical control if you are putting something into the real world to help protect you; think a fence or a lock on your server room door. You also have Technical controls, which are things you put in place that control how IT systems communicate with each other; things like Firewalls and encryption are examples of technical controls.
The prep course I’m using for this exam emphasized the need for the IT Types to think outside the box when it comes to security controls. Security is more than just firewalls and encryption and technical controls after all. Apparently there is concern from the certifying powers that be within the Cybersecurity realm that security has gotten too focused on the tech side (which is honestly kind of a duh! moment for anyone else peripheral to the tech world, but hey…at least they recognize it now!).
That got me thinking back to my experience working in secure, regulated technical environments. In my experience, the establishing of Security Controls for the organization is handled often by the Technical side of the house. The Tech experts meet with the Risk Management experts and maybe a few senior people to game out what kinds of risk exist to the organization or infrastructure, and then create security controls to address those issues. This seems like the perfect recipe to create myopic, technical-centered security controls that will be great for protecting an organization against one kind of risk, while completely missing the others.
So I had a thought….why not try crowdsourcing your security controls?
Frameworks are great, and you should definitely use them when it comes to establishing a Risk Register (log of the risks your org or infrastructure faces), but most of them are generic by necessity. Each organization and/or infrastructure is going to have its own unique risks that cannot be thought up by the outside. Who better to point out things that they see as risks than the employees? Actual users of the systems, who with a little prompting, can turn their eyes in their daily work to things that might be able to be improved or made more secure?
Asking a team of Risk Experts is never going to make an organization truly secure. Allowing your employees to participate not only helps you identify risks you hadn’t thought of, it helps foster the development of security culture within your organization…which is the goal of any good security program.
To make your organization truly secure, you need to take a broader view…so open up your security control meetings!