Breaking Down The Critical Security Controls: CSC 20 – Penetration Tests
The last one! Control number twenty is finally here. After many weeks of going through the Critical Security Controls, all twenty of them, the end has been reached. This control wraps all the other nineteen controls with a nice bow. The final control is Penetration Tests and Red Team Exercises.
When you look at all the prior nineteen controls you can sum up the last with two words – PROVE IT.
Here’s what the control says –
Test the overall strength of an organization’s defenses (the technology, the processes, and the people) by simulating the objectives and actions of an attacker.
After spending months putting in technology, processes and training your people in the practices of the controls it’s time to test them. The only way you can measure the effectiveness of your program is attempt to penetrate, compromise, breach and gain unauthorized access to your environment.
The concept of a white/gray hat team that conducts penetration tests on an environment is called a Red Team. This can apply to internal employees or 3rd party services hired to conduct the tests. These teams are not part of your day to day security operations typically. They are external, non-biased, hard to influence and their activities are not entirely known to the IT, security or response teams. This is the point of a red team.
The red team will conduct penetration tests through a variety of methods attempting to find gaps, exploit vulnerabilities, conduct social engineering against employees and other methods to gain access to a target. The only difference between a red team’s activities and an criminal’s is they are monitored and sanctioned by the business.
There are many purposes to these tests, each meant to identify and improve areas of your security program –
- Detection – Monitor IF and how long it takes the technology, processes or people to detect an attempt of an intrusion or an intrusion itself. This is the first line of defense. Even if your tech blocked the attempts, your detection processes should report on the attempt whether it’s successful or not. If the red team does penetrate or cause a disruption you move into the next phase.
- Response – Monitor the response team’s effectiveness. How long does it take to respond once an alert is sent. Minutes, hours, ever? Test the ability to properly categorize the risk. Escalation capability. Communication flows. Containment.
- Action – How long does it take to isolate, control and eliminate the breach?
- Post-Mortem – Do you know what damage was done? How did they get in? Review the ability to gather the data, can you? Ultimately can you find the gap that allowed for the access? A good red team will be forbidden to reveal how they got in, that defeats the purpose. Depending on the severity of the gap or lack in the teams this cannot be kept secret for long.
How Can It Be Exploited
This is it. Hackers, criminals, internal agents do anything and everything they can to break in, escalate access and take data. There is no pattern, no static path to this, it’s just an attack.
Just because you have tools and people in place means very little unless you regularly test them and improve on the results. Red teams are not witch hunts to fire people they are improvement exercises to make everyone’s skills sharper, the security stronger and confidence in the program’s capabilities and effectiveness as high as it can be. Some companies do these tests once a year, some do it monthly and others are continual. The environment is not static. One misconfiguration can open up the doors. Never assume. Trust but you must verify.
End of line.