Defence in Depth: Security Control Assessment, Indication of Compromise, and Purple Teaming

Security Control Assessment (SCA) is used to validate whether a security control is implemented, working, and deployed in a proper way.

We managed to compromise several major global companies that we’ve worked with. Not because they didn’t invest in security. They had great security. And they had invested in brilliant security products.

But there is a gap between having all these controls in place and validating them in-depth.

For example, in one of our assessments, we were able to bypass a multi-factor authentication because the redirection rule was not configured correctly.

Another client had DLP (data loss prevention software) in place which was meant to stop information leakages or exfiltration. Anyone trying to copy and paste the information in a file or email would be detected and an alert sent to the SOC team. What if anyone sent the same information inside the metadata of a Word file? It was not flagged, and it was possible for an attacker to exfiltrate the data. So the configuration needed to be adjusted to also include that situation.

Clients have told us often about the many systems and controls they had in place to protect them. But since they were not implemented in a proper way, we were able to bypass them.

Hence, we realised that traditional assessments or pen tests are not enough here. We need a specific assessment of that target to see whether the given security control is implemented correctly. In other words, to validate a security control in-depth.

SCA can target anything: a firewall, a DLP, a WAF, or any sort of protection. And it does not necessarily need to be a product. It could also be a process or an in-house mechanism.

With SCA, we help clients make sure that they extract value from their sometimes-huge investments. SCA is not about breaking a security product. It’s about seeing whether the rules are configured in a proper way that addresses a real-time attack and ensuring there is cyber ROI (return on investment) together with the true value of the solution being demonstrated.

Indication of Compromise (IOC) validation is a process wherein we enact a compromise and check if the SOC/NOC team is effectively responding to the attack vector on time. The impact of a compromise depends on how responsive the SOC (security control operations) team is, and IOC is testing their vigilance.

To better understand IOC, let’s think of a house. You install doors, windows, locks, and other security systems to keep strangers out. Red teaming is proactive. A red team will try to break the door, find an open window, or a broken lock. IOC is more reactive. The team is already inside your house, going through your fridge and cupboards. What do you do now? How do you get them out of your house?

Examples of indications of compromise:

• unexpected traffic of DNS;
• downloading software used to do exploitation;
• logging in from multiple locations.

If the examples above are being detected, is the SOC team taking any action? Are they trying to find out who downloaded the software? Who is trying to log in? The SOC team has to be present right then and there to act. Eight hours (i.e., how long we were able to sit in a client’s network without detection) is enough time to do a lot of damage. The response time should therefore be measured in minutes.

The work for SCA and IOC is similar, but the output is different. SCA is checking the effectiveness of the configuration of a control or of a whole product. In IOC, the team checks the effectiveness of the response to the compromise – so not only the product, but the human standing there seeing and alert, validating it, and acting upon it.

An SCA report will show any misconfiguration in a deployed security mechanism. An IOC report will include the attack vectors that were tested and the corresponding response from the SOC/NOC team.

Purple teaming is the umbrella for SCA and IOC and it bolsters cyber resilience by optimising security measures, reducing vulnerabilities, and enabling organisations to proactively detect weaknesses in their security controls.

Traditionally, red teams are given a goal by the client and do stealth work trying to achieve it. In response, a blue team will receive alerts and act. However, in practice, we notice that often blue teams get alerted, but do nothing.

For example, we discovered a credential over the internet for a client and tried to log in from India, the US, Canada, and other locations. That simple attack activity was logged but there was no action on it. So the issue was not the security control, but that the SOC didn’t act upon the alerts.

Why? The root cause is that the SOC teams get so many alerts and so many logs, that they are confused about prioritising issues and about how to deal with them. That’s where purple teaming comes in to bridge the gap.

Purple teaming is a collaboration between red and blue teams, attacking, analysing logs, trying to block attacks, and ultimately improving the overall security structure. It enables us to find more attack vectors, make a rule out of them, and ensure that if any attacks are coming – actual attacks, those are being blocked easily.

Purple teaming adds a lot of value because it fine-tunes your whole security mechanism in place. It does real justice to the energy and efforts that have been put in place, but that may not have had thorough validation. You are validating your deployed security controls. And this gives you an assurance that if someone is attacking, an alert will be triggered and a proper response will happen.

We are still in the old age of doing a pen test wherein a company comes, they are given a bunch of IP addresses, they run some of scanners, and then validate it, and send a report. They are not heavily involved in ensuring that the remediation is done in a proper way and that controls are being validated. We are proposing a new approach to pen testing and to cyber security as a whole, which is more holistic and focused on retesting, remediation, interaction with Cyber operations and aftercare.

“My biggest recommendation is that even if you have the most expensive security software in place, validate it and fine-tune it to ensure it works as expected. Ensure that you are validating its effectiveness by doing real-time attacks because the effectiveness of a product or a mechanism comes to light only when it is tested correctly”, says Balaji Gopal, VP of Technical Services at Chaleit.

He goes on to explain that when it comes to monitoring, most clients are doing an 8 out of 10. There are logs in place, and everything is good. As far as response goes, most clients are doing 1 out of 10. Monitoring is of course useless if it is not acted upon.

“For example, we sat inside a network for almost 8 days! We literally retained major access for 8 days without any sort of response from the SOC or the EDR solutions in place”, he adds. That’s the risk of not validating security solutions in depth.

Here is what one of our clients had to say:

At the end of the day, even with the best intentions, with all the training, and configurations done according to benchmarks, organisations can be vulnerable. Expensive software alone, no matter how brilliant, does not make you secure.

With SCA, IOC, and Purple Teaming, we have been helping clients avoid human error, misconfiguration, and a lack of validation. In fact, these services were born out of client interactions. We noticed a need and a gap and decided to do something about it.

If you’d like to fine-tune your security mechanism or if you’re not sure what type of assessment is right for your company, let’s talk and drive value together.