Despite heavy investments in security operations centres (SOCs) and increasingly sophisticated cyber defence tools and services, we still see attackers successfully breaching even the largest enterprises with the biggest cyber security budgets.
This tells us that organisations are failing in the basic principle of prevention before detection, and that many SOCs are failing in their primary mission of security monitoring and alerting to help organisations detect and remediate attacks early.
The number of breaches and extended dwell times indicate we are not detecting what we should be detecting.
To address these failings, businesses need to go back to basics. They need to use their Centre for Internet Security benchmarks and hardening to prevent attacks and reduce attack surface areas, increase visibility, and use the visibility available in the SOC to feedback hardening use cases into business and operations.
While the larger organisations and managed SOC services generally have their SOCs properly set up and configured, many smaller organisations often don’t have resources at the necessary level. They may not have the skills, processes and architecture they need, and they are neglecting their foundational security, resulting in them layering detection services on a weak foundation.
Improving cyber security is not always a matter of procuring more solutions − it's often about correctly configuring what the company has.
In some cases, operations teams don't have the capacity and ability to properly configure systems at the beginning. In others, hardening the system could hamper quick and easy deployment, so they may opt to harden it later.
However, this means they do not have a properly established foundation, and going back to harden it after the fact requires time, effort and skills they simply don’t have. Whatever the underlying reasons, the result remains the same − vulnerable systems.
Audit policy fails
One of the basics that should not be neglected is properly configuring audit policies from the outset, because from a SOC perspective, WYSIWYG (what you see is what you get).
If companies don’t ensure audit policies are correctly configured, they:
- Won’t trigger the detections that are configured as they won’t get the data needed.
- Will waste time, money and resources on logging data that has little security relevance.
- Will waste human resources trolling through useless data, leading to analytical fatigue.
- Will not have a consistent view over the environment.
A key challenge here is that many policies are compliance-focused but not necessarily security-focused. Compliance and security do not always work hand-in-hand, with many compliance policies regarded as noise from a cyber security perspective.
While compliance policies may provide a good view of what users are doing, security policies need to drill a lot deeper, covering scripts and activities in the back-end.
These broader, deeper policies cannot simply all be switched on: they depend on each organisation’s specific attack surface, assets and risk profile, and also depend on the available budget.
Every organisation’s key assets and attack surface differ − in a web retailer, massive sales portals might be a priority, while for another organisation, the most important asset may be IP. It is important to first identify critical assets and ensure key attack surfaces are secured.
Generally, in a Microsoft-based client environment, for example, the broadest cover is needed. I would recommend covering all servers, EDRs, web proxies and zero trust platforms, and plugging in log details from existing security solutions.
Since most attacks start at workstations, it would be ideal to include them too; however, it’s not necessarily financially viable and business-wise to cover them.
Balancing budget with security
In most cases, businesses have a limit to what they can afford, and security spend is reactive. However, improving cyber security is not always a matter of procuring more solutions − it's often about correctly configuring what the company has.
Building security into every system should be approached in much the same way one builds a house: you don't design a home with 25 doors, because 25 security gates are expensive.
Likewise, you need to build securely by specifying security requirements and budgeting and architecting to meet these requirements upfront.
Improving SOCs and their ability to harden systems also depends a great deal on the skills deployed in the environment.
Cross-skilling is important, because to ensure companies have resilient, secure systems, they need a combination of theoretical knowledge, security expertise, and the insights from people with experience in the operational sphere.
We need to see more analysts sitting with the likes of network engineers and Microsoft server admins, who can offer insights on the real impacts of implementations on the environment. They can add insights like: “From an architecture perspective, this is what we can change without breaking it.”
Share