As you embark on a substantial digital project, adhering to the GOV.UK Service Manual at each project stage, reaching the go-live phase raises the question of whether the service includes ‘protective monitoring’ for accreditation. This implies that the team must invest time and effort in acquiring or establishing a Security Operations Centre (SOC).
Establishing a Security Operations Centre (SOC) is a substantial undertaking, demanding a significant investment of time and financial resources. This blog explores the feasibility of organizations designing systems to mitigate the need for a comprehensive SOC.
What is the functioning mechanism of a SOC?
A Security Operations Center (SOC) is typically managed by a distinct team separate from operational staff, ensuring a division of responsibilities between those overseeing digital services and those analyzing logs for security purposes.
The SOC commonly employs specialized tools, with the Security Information and Event Management (SIEM) tool being the most prevalent. This tool receives input from logs and various data sources, conducts correlation and rule checks, and generates alerts for further assessment. Licensing for SOC tools can be costly, with enterprise-focused solutions usually having higher expenses and often necessitating annual renewal.
A Security Operations Center (SOC) team is usually composed of:
- security analysts handling events and alerts
- security engineers overseeing the tools (as well as integrating projects into the SOC)
- certain types of managerial and administrative roles
- a function dedicated to threat intelligence
Encountering a security incident without logs to ascertain the events and having to communicate this to higher-ups is an undesirable situation. In certain scenarios, logs may be necessary for legal and forensic reasons, making it crucial to demonstrate a secure chain of custody regarding their handling and integrity.
Some SIEM tools provide cryptographic integrity and log validation features to assess whether logs have undergone tampering. A SOC is frequently an effective approach to guaranteeing the integrity of logs.
Nevertheless, establishing your own SOC can be both costly and time-intensive. An alternative is to outsource the SOC. However, external SOC analysts might not possess the specific knowledge of, for instance, a project’s architecture and may not respond to alerts as swiftly as an internal SOC.
GPG13: addressing the unspoken challenge
CESG, the predecessor of the NCSC, released a ‘good practice guide’ (GPG) outlining protective monitoring, commonly referred to as GPG13. Risk management personnel often insisted on GPG13 compliance as a prerequisite for launching a service, turning protective monitoring into a mere checkbox activity. The marketing material for SOC tools frequently touted their products as ‘GPG13 compliant,’ further contributing to the checkbox mentality.
As applications and services diversified in architecture and technology stacks, service owners had little incentive to identify and monitor risks beyond those outlined in GPG13. Although GPG13 was deprecated before the NCSC’s establishment, some customers still reference it in their assurance processes. To distinguish the ‘GPG13 approach to protective monitoring’ from the NCSC’s current strategy, I will use the term ‘security monitoring’ for services built using cloud-native technologies.
How does the cloud impact security?
In 2013, the UK government implemented a ‘Cloud First’ policy, encouraging government departments to prioritize cloud solutions over traditional on-premises deployments.
How does this shift to the cloud affect our security needs? In cases where deployments shift from on-premise infrastructure to managed IaaS through a lift-and-shift approach, the need for a SOC remains unchanged. This is because there is no inherent shared responsibility model to reduce operational responsibility. By adhering to and implementing the NCSC’s cloud security guidance, organizations can increasingly leverage the monitoring tools provided by the cloud provider, reducing reliance on SIEM, SOCs, or specialized security personnel.
A key benefit of a SOC is its ability to identify and alert on risks specific to the environment. This necessity persists with security monitoring, highlighting the ongoing importance of identifying and monitoring custom alerting.
What, without a SOC?
So, what alternative approaches are currently being employed in lieu of a comprehensive SOC? Here are some strategies that government projects are presently embracing:
- Fully embracing a cloud-native architecture
Implementing services that exclusively rely on ‘cloud-native’ solutions, capitalizing on the benefits of robust identity management tailored to service usage, and avoiding the operational burdens associated with deploying, patching, and troubleshooting services traditionally hosted on VMs. - Completely hands-off production
Implemented services in which engineers never directly interact with production services, except through closely monitored and audited break-glass solutions. This has minimized system risks and diminished the need for security monitoring use cases. - Environmental isolation
Utilizing distinct cloud accounts for functions requiring segregation. For instance, cloud accounts storing security monitoring logs and services not meant to be accessed (even in a break-glass scenario) are hosted separately, with stringent access controls and alert mechanisms in position. - Streamline log gathering
Cloud-native services provide their logs (along with services for aggregation and analysis). As security monitoring needs are streamlined, so is the event logging process. Event logs now adhere to consistent formats and can be gathered and stored in the cloud. Certain cloud providers offer features addressing log integrity, such as storing checksums that can be employed to authenticate log integrity and prove beneficial during an audit. - Substituting SIEM
Government agencies with established central SOCs discover that incorporating services is a labor-intensive process. Opting for straightforward architectures has enabled some to eliminate the need for a SIEM by expanding their cloud-native logging solution and integrating rules and alerting directly into the platform. Adhering to secure development practices ensures that the operations team retains security responsibilities, obviating the need for a separate security team. Proficient Incident Management, along with a clear understanding of roles and responsibilities, remains essential. - Emergency Access
Occasionally, direct access to production becomes necessary, whether for operational reasons like examining performance issues or as part of a security incident response. In certain projects, the operations team is tasked with handling investigations and incident management, facilitated by comprehensive documentation of processes, robust access and change control measures, and rigorous system auditing. Access is restricted to a specific timeframe, and all actions are subject to audit and oversight by other team members. - Ensuring Log Integrity
All these efforts would be in vain if the logging ceases without detection. Services can be infused with canary tokens, triggering alerts or errors if the token goes unnoticed within a specified timeframe.
Final thoughts
In the realm of OFFICIAL-level services, the emphasis should be on a ‘cloud-first’ approach, incorporating all previously mentioned aspects to enhance and streamline security monitoring.
For platforms like AWS, there are specific, cloud-native tools such as GuardDuty, Security Hub, CloudTrail, CloudWatch. Instead of setting up a traditional SIEM, this approach empowers operational teams to manage monitoring within these straightforward and inherently secure environments. This empowerment not only simplifies processes but also leads to the creation of standardized templates for security monitoring, akin to current practices in infrastructure deployment.
When considering the necessity of a SOC for a project, it’s crucial to assess if the SOC’s roles can be fulfilled through alternative means:
- Is log access for incident investigation essential? Properly configured cloud-native services can fulfill this need, but it’s important to think about log retention and who has the authority to access or delete these logs.
- Do you need real-time attack detection? The limited attack vectors in cloud-native/serverless architectures, due to their single-purpose components and managed infrastructure, require reevaluation of potential threats and setting up targeted alerts.
- How are incidents managed? In a serverless context, the nature of alerts differs, and operational teams are often better positioned to spot unusual activities than a general SOC analyst. It’s critical to ensure these teams are trained to recognize and escalate suspicious activities effectively.
The NCSC still recognizes the relevance of SOC and protective monitoring systems in the security toolkit. For certain enterprise IT systems (like endpoints) and traditional IaaS architectures (especially those above the OFFICIAL classification), reactive monitoring remains essential. Additionally, centralized SOCs offer the advantage of detecting widespread attacks targeting multiple services within an organization.