Modernizing the Nation’s Approach to Cyber Threat Management with Autonomic Security Operations

How Google can drive agencies’ ability to meet the White House cybersecurity analytics requirements of EO 14028 and OMB M-21–31

Iman Ghanizada, Asjad Nasir, Daniel B. Prieto, Haywaad Ahmadzai

Executive Summary

Attackers are increasingly capable of destabilizing public and private sector infrastructure

• Sophisticated cyber campaigns increasingly target the U.S. public and private sector, threatening both our individual security as Americans and national security.
• Attackers are constantly innovating and changing tactics. In the last year alone, they have increasingly automated ransomware attacks, targeted VPNs and COVID-related remote work infrastructure, executed novel software supply chain attacks, and disrupted US critical infrastructure.
• The expansion of visibility beyond on-premise environments to cloud, hybrid environments and Information Technology (IT) and Operational Technology (OT) systems has led to an exponential growth in data volume that agencies are not equipped to manage.

New federal policies are an important first step, but their effectiveness will ultimately depend on agencies ability to implement them.

• The White House signaled its commitment to addressing these challenges through EO 14028 which proposed cybersecurity enhancements spanning zero trust, software supply chain security, cyber threat management and more.
• To modernize cyber threat management, OMB issued M-21–31, a deliverable under the EO that clarified cyber logging obligations for federal agencies.
• Adherence to the recommendations set forth in EO 14028 and OMB M-21–31, can improve detection and response. However, their implementation remains infeasible for many agencies due to cost, scalability, engineering, and a lack of resourcing.
• Meeting the requirements of the EO and OMB guidance will require not just technology modernization, but also transformational changes to workforce and business processes.

Autonomic Security Operations can help departments and agencies overcome these hurdles to enhance their cybersecurity.

• Google developed Autonomic Security Operations, a solution to modernize threat management, in line with the objectives of EO 14028.
• ASO is a transformational approach to security operations, powered by cloud-native tools, to detect and respond to anomalous activity occurring within an agency.
• ASO can help federal agencies to achieve Google’s model of continuous detection and continuous response so defenders can effectively secure their systems from attackers.
• We’ve partnered with Deloitte and CYDERES to bring this end-to-end security operations solution to the Public Sector.
• We recognize that implementation of the requirements in EO 14028 is a multi-year journey, and look forward to helping agencies meet the requirements to improve their cybersecurity.

Introduction

In May of 2021 and iIn response to the “increasingly sophisticated malicious cyber campaigns” affecting public sector organizationsfederal organization’s government systems, in May of 2021, the White House released Executive Order 14028 (EO) on Improving the Nation’s Cybersecurity. The EO recognized that incremental improvements to cybersecurity are no longer sufficient to thwart attacks and that “to keep pace with today’s dynamic and increasingly sophisticated cyber threat environment, the Federal Government must take decisive steps to modernize its approach to cybersecurity.” In response, it outlined a set of measures designed to improve the security of public sectorfederal networks, assets, and supply chains, to better protect against, detect, and respond to cybersecurity threats — while investing in both the technology and personnel to match these modernization goals.

Understanding the complexity of proactively managing threats in modern computing environments, it’s imperative for public sector organizations to identify a holistic strategy to modernize their personnel, processes, and underlying technologies that support their security operations practice. The recommendations in Section 8 of the EO reflect the importance of strengthening investigative and remediation capabilities. As required under the EO, the White House Office of Management and Budget (OMB) published further guidance in this area through its Memorandum M-21–31 which made a number of recommendations for log management across federal agencies. It also established four tiers for agencies to measure the effectiveness of their threat logging systems.

To address the requirements, Google Cloud has developed a solution for cybersecurity analytics — Autonomic Security Operations (ASO) — that can help transform federal threat management and support agencies progress across the tiers set forth in OMB 21–31. ASO is powered by our proven detection and response platforms, Chronicle and Siemplify and augmented by additional tools that provide enhanced threat and business intelligence, curated technical content packs, supported integrations to over 300 partner products, and partners who can support our customers through their journey to achieving Autonomic Security Operations.

We recognize that modernizing threat management in the Public Sector is not simply a matter of adding new tools. It is part of a large transformation that will require coordinated and strategic investments in people, process, and technologies. Through ASO and other solutions, we hope to support the Public Sector’s journey to improve the security of our nation.

Achieving Autonomic Security Operations in the Public Sector

We define Autonomic Security Operations as a combination of philosophies, practices, and tools that improve an organization’s ability to withstand security attacks through an adaptive, agile, and highly automated approach to threat management. In this vision for security operations, cyber telemetry becomes the lifeblood of an organization — highly available, highly fluid, continuously analyzed, and highly automated — informing nearly all aspects of security operations in real- or near-real time. The approach is grounded in Google’s engineering practices, — particularly around DevOps, Agile, and Site Reliability Engineering.

To understand the transformational potential of ASO, it’s instructive to take a closer look at how the adoption of DevOps, Agile, and Site Reliability Engineering allowed software delivery teams to move away from the longstanding waterfall approach to software development.

In legacy software development, there was a common three phase approach — development, testing, and IT operations, the latter which focused on similar operations and incident response workflow focused on availability issues. This assembly-line approach to the SDLC was full of the same challenges that the Security Operations practice has — visibility, speed, quality, reliability, productivity, and all things between. Interestingly enough, when approaches were presented in compelling use cases, the excuses came up for many organizations.

• When Agile software development started being practiced as a way to iteratively improve collaboration and release times over the Waterfall framework, many organizations said they did not have the talent and resources to modernize until it became a very clear competitive disadvantage.
• When DevOps created the construct of continuous delivery and feedback, many organizations who were not practicing did not adopt it due to talent and resources until it became a competitive disadvantage.
• When Site Reliability Engineering became the de-facto practice to have a hyper-focus on automation and engineering improvements to reliability metrics, many organizations did not adopt it due to talent and resources until their lack of reliability became a competitive disadvantage.

What these practices have in common, is that their global adoption has transformed the way businesses are able to provide services to their customers, enter new markets, and scale on-demand without having to worry about the bottleneck of a highly siloed software development practice. Today, for practicing organizations, you do not hear CEOs and Board Members concerned about their ability to build software and deploy infrastructure. Banks can focus on banking, hospitals can focus on healthcare, and early stage companies can focus on achieving product-market fit. The technologies that are used today are built around this new behavior of how we work, not vice-versa, and the Cloud has rapidly accelerated this model. In a way, we can consider this on-demand elasticity an “autonomic” element of an organization’s technology function.

On the security front — too many organizations are trying to address the complex, multidisciplinary, and strategic problem of managing cyber threats with an outmoded operating model, a linear assembly-line process staffed with analysts and operators narrowly focused on reacting to a flood of mostly false alerts. What if the problem is not so much a talent shortage, as it is a failure to properly support, empower, and incentivize talent with the right business processes and technical resources? With the right tools and a re-imagining of the business process of threat detection, analysts can focus on higher-value-added activities. For example, instead of waiting until after a breach to conduct comprehensive forensic analysis, more analysts will be empowered to engage in proactive threat hunting, which in 2020 was added to NIST 800–53 as a best practice.

In reality, we don’t need everyone in the world to become a data scientist or an engineer, but we do need to disincentivize the assembly line approach to detection and response and restructure team members around a common framework that will give them the ability to leverage their creativity and curiosity. Cyber defenders join the government for the mission — to serve the public and protect the nation. Let’s empower them to solve the kinds of challenges they signed up for, and provide the opportunities for growth, impact, and innovation that can fuel their careers.

Why Autonomic Security Operations?

In concept, ASO is how we bring a set of practices and principles together to build a common framework of modernization that will give all organizations — large and small, SOC and SOC-less, the ability to build a modern, agile and scalable threat management practice, regardless of which technologies they use. ASO presents a paradigm-shift opportunity for the security operations industry. It can set a new standard for how threat management is approached, one that can inspire generational change from the existing practitioners to the learning practitioners the same way that DevOps transformed software development in the early 2000s.

Google provides a suite of Cloud-native capabilities to perform modern cyber threat detection and response. We’ve partnered with leading Global Systems Integrators and MSSPs to plan, scope, and deliver a multi-year Autonomic Security Operations transformation to organizations. Tailoring these capabilities to the Public Sector can help departments and agencies accelerate their ability to meet the requirements of EO 14028 and OMB M-21–31 regarding threat visibility and log management maturity.

The Public Sector’s longstanding challenges to modernization, with all the complexities in contracting, staffing, application ownership and management, siloed workloads, and expanded threat environments, we need a radical vision that will get every Government employee and contractor eager to collaborate and problem-solve this mission together. After all, supporting critical infrastructure and national security are public services that protect the American way of life and protect our democracy. If Federal security operations teams can transform themselves, they can become a model for recruiting cybersecurity and analytic talent, and a model for the transformation of security operations in other sectors.

As a reminder, we’re building up on the initial research in the Autonomic Security Operations — 10X Transformation of the Security Operations Center whitepaper. Revisit and review this paper to see some specific examples of 10X improvements across these areas. By 10X, we’re referring to the idea that as data needed to do effective detect and response work grows and attacker sophistication and capability grow, organization’s will need to increase scope and scale their security operations team times 10 (10x). Acquiring more bespoke tools and hiring highly technical staff to deal with these increases is not sustainable. data volume and attackers will exponentially increase, but headcount will not. To combat this eventuality an exponential increase in data, attackers, and complexity of modern architectures — we need creative solutions that can operate at scale.

Transforming People to Accelerate Continuous Detection and Continuous Response

There is a global shortage of skilled data analytics and cybersecurity professionals. Faced with this, the Federal government is challenged to recruit, train, and retain the cyber workforce they need for the future. The human capital challenges that the Public Sector faces, though, extend beyond just a global shortage of technical talent. Public Sector employees are inherently motivated by a deep commitment to public service and to the mission of their agencies, but with an aging federal workforce it is essential to be able to continue to attract and retain talent. That has become increasingly difficult when the work environment in the Public Sector can feel far removed from comparable professional environments in the private sector, especially as regards work-life balance and flexibility; coaching and development; career advancement; and the availability of modern technology tools.

Across all industries, hiring, retaining, and promoting candidates from diverse backgrounds can drive significant benefits. Google believes that much of the strength of our business stems from building a workforce that is more representative of our users and a workplace that creates a sense of belonging. When compared to other industries, the cybersecurity profession is more representative of diverse populations, but diverse communities are still lacking representation in leadership positions. Recent studies from the International Information System Security Certification Consortium (ISC2) (Innovation Through Inclusion: The Multicultural Cybersecurity Workforce) and McKinsey analyze these challenges, finding that organizations with diverse leadership teams perform better both financially and in terms of corporate culture, while also adding to the overall confidence of an organization’s security posture.

Adversaries have no organizational confines to adhere to and come from regions all across the globe. As they become increasingly persistent and sophisticated, the cybersecurity problems that defenders face require creative approaches to building defense in depth. The core element of transforming people in the modern security operations workforce is dependent on your ability to shift from an operations-centric workforce to a creative, solutions-oriented workforce. A diverse security workforce and leadership team can ensure you’re looking at solving these challenges from all angles, fostering creative problem solving, and cultivating perspectives that would not be derived from homogenous environments. We’re thrilled to see the public sector championing this approach with the White House Executive Order 13985 on Diversity, Equity, Inclusion, and Accessibility in the Federal Workforce.

When it comes to transforming the productivity of cybersecurity human capital in the Public Sector, significant opportunity lies in fully revamping the existing structure and workflow of security operations teams. Traditional security operations organizations rely on an assembly-line structure, built on a tiered analyst-centric approach. In this model, cases are individually managed through channels of escalation. Analysts at the front lines perform low-level case management, while more skilled workers build detection and hunt tools, manage ingestion pipelines, and conduct incident response. Too often, teams and critical data are siloed and disconnected from one another, and across the workforce there are significant disparities in skillsets, scope of work, and role expectations.

A more modern and agile security operations practice has a close collaboration with project teams. Some of the very well-running organizations have fully decentralized response to the project teams, but this is incredibly complex for most organizational structures. Whether managing the output of detection happens from a centralized security operations team or not, as long as we understand the aspirational workflow, how it’s achieved will vary from organization to organization. To eliminate the assembly-line process characterized by fragmented data, siloed teams, and escalation handoffs between tiered groups of analysts, the workflow of a modern security operations team is characterized by Continuous Detection and Continuous Response.

In modern threat management practices, the workflow is structured to enable the continuous improvement of detection and response functions. Teams are structured where they best fit, aligned to the complexities of your organizational structure. In the Federal space alone, there is a wide variety of Security Operations structures, from State and Local governments that may have small to no security operations teams at all, to large federal SOCs that provide services to agencies and are very disconnected from application owners. Not all organizations can follow decentralized end-to-end pipeline ownership, but knowing what the continuous loop looks like for your organization will help you identify gaps and realign your analysts to a model that makes the most sense for your organization.

For organizations that follow Detection Engineering principles and practices, it’s common that detection engineers own the full development and continual iteration of use cases, and they participate in most functions that support the improvements to their detection use cases. Detection Engineering in practice may not work for everyone, particularly in the Federal space, where different subcontractors own different bits of infrastructure and there are more rigid lines around collaboration. To transform, you may not need to break this entire rigidity, but you will need to get creative on how you can ensure your Security Operations practice evolves to a continually improving workflow.

Prescribing an exact methodology to follow will require assessing your current maturity across the key areas of the CD/CR model. Ask yourself the following questions

• Which one of these core processes do we perform today?
• How would we rank the maturity of this practice?
• Where can we radically improve our capabilities here? Is it with people, process, technology, or a combination of them?
• Who performs these functions? Where can we expand their reach?
• If we’re not performing these functions, where are they being done? Who are the key players, do we have close alignment with them?
• E.g. If your team is completely disconnected from the teams that handle data collection, and you have a use case that is missing key data from instrumentation, can you identify who drives this today? Do you have alignment? If you have a way to solve a visibility gap by deploying a set of instrumentation, how can you focus on the continual improvement?
• Can we align OKRs to these functions both from a team-level to the role expectations?
• What are the metrics we’re capturing across each function?
• Where can we upskill our analysts to take on more ownership of the pipeline?

Achieving the CD/CR vision is the pinnacle of your journey towards Autonomic Security Operations, so it’s important to understand some practical and concrete steps you can take to make progress within your organization.

As a first step, people managers should start thinking about how to re-align objectives and key results (OKRs) and performance metrics for security operations teams. For example, rewarding analysts based on how many cases they have resolved fails to address the proliferation of false alerts and analyst burnout. On the other hand, an analyst who helps develop detection use cases and identifies the signals needed to cut down false positives is reducing toil, driving productivity gains, and shifting the security operating model. When seeking to strengthen the cybersecurity workforce, the goal is not that everyone has to be an engineer. If you can instill and reward curiosity, critical thinking, and creativity in the minds of the analysts closest to the threats, you may find that your staff discovers clever ways to build solutions to problems.

Second, it’s important to acknowledge that not all organizations have the benefit of a dedicated Security Operations Center. Depending on where your security organization is in its journey, capable security partners can be critical to improving your threat management — from providing advisory, consulting, and staff augmentation services to ingesting all of your cybersecurity data and owning the entire detection and response workflow (e.g. MSSPs). There isn’t a one-size-fits-all approach for every organization to achieve Continuous Detection and Continuous Response. While ASO envisions aspirational team structures, process maps, and technology architectures, these are all reference concepts. As a partner, Google will help you assess your current level of maturity, define a target state, and develop a plan to get there.

The lessons we’ve taken from Site Reliability Engineering, DevOps, and Agile Software Development all point to the core catalyst of transformation — people. Aligning people to the aspirational workflow of modern software development led to the technological evolutions that allow organizations to scale on-demand today, including the creation of Cloud Computing. The delta between the aspirational security operations workflow and the current state of talent is where we take learnings from other disciplines and from industry leading security operations teams to help others cultivate a highly effective workforce. The only way we’re going to combat the talent shortage is by following working examples and finding ways to enable all organizations to get there. Consider improving your hiring program, increasing the retention of your workforce, improving career prospects and progression, finding intrinsic motivators to enable your team to operate at scale, and equipping them with the tools, investments, and resources to achieve this level of maturity.

Modernizing The Technology Stack

The technologies you leverage in your threat management practice can also vary for every organization. Some organizations prefer to build, others prefer to buy, some prefer managed tooling, others prefer flexibility and control.

One thing is for certain — we need to move away from the monolithic model of Security Operations where one application is paired alongside a fragmented assembly-line equipped with dozens of tools to solve the full workflow of detection and response. It was DevOps that led to the birth of the microservices model — monolithic architectures were barriers that inhibited rapid iteration, CI, CD, and everything in between. Consider the CD/CR feedback loop and ask whether your technology reduces friction in this workflow.

In pursuit of Autonomic Security, we need to move to solution stacks that are modular, extensible, and scalable, and which provide cloud-scale power and exponential process and productivity improvements over legacy tooling. Cost is an obvious element that also needs to be considered, as no Security Operations team possesses an unlimited budget. Just like a bank needs to focus on banking, a security operations team needs to focus on threats and not operational tasks like managing infrastructure. Some organizations have the capabilities to build everything in-house with a predominantly open source-led approach. Other organizations will need a guided approach with a technology stack to achieve ASO.

The extensibility of cybersecurity tools is incredibly important, as many organizations will be wedded to some existing tooling that they already rely on to process cybersecurity data. A closed system does not allow organizations to get creative on how they leverage their tools. Moreso, some organizations may not have a significant Security Operations presence and will need to partner with MSSPs to have them run the workflow — we have many customers who do this today.

To help the Public SectorFederal departments and agencies meet the requirements of the EO and OMB M-21–31, we’ve put together an opinionated architecture to modernize threat management. The EO requires log collection, aggregation, retention, exporting, SOAR, UEBA, Container Security, Endpoint Detection and Response, and has several recommendations regarding alignment to best practices. Before we dive into our Google-native architecture stack, it’s important to call out that we adhere to the important principles mentioned above — extensibility, cloud-scale, modularity, and cost-efficiency.

In the figure above, consider the CD/CR workflow when looking at the technologies. From left to right you will see data collection, analytics, decision-making, and there are also visible and invisible feedback loops that exist across every connector. This stack is extensible and offers over 300 integration points, can be built to consume any and all security data, operates at cloud-scale, and is mostly running on managed services at a cost-efficiency that makes petabyte-scale data ingestion feasible. This solution supports multi/hybrid-cloud environments, and we also have customers who do not use Google Cloud Platform but leverage our security stack in tandem with their other investments for their Security Operations teams.

Understanding the complexities of the public sector supply chain, there may be moments where an existing investment may be necessary while compliance and other requirements are met in developing tools — following the principles of ASO, this stack-based approach gives us the flexibility to solve each of these use cases as needed.

Mapping Solution to M-21–31

Modernizing the Public Sector approach to detection and response will require adhering to the principles of ASO. Without an investment in personnel and having the context of how continuous detection and continuous response can be achieved, many of the technologies needed to implement OMB M-21–31 will be difficult to adopt and harmonize across your program. As a baseline, it’s strongly recommended to consider the changes you’ll need to make across those two efforts while implementing a modern technology stack. To understand how we can achieve the requirements of the EO with Google Cloud capabilities, take a look at the requirements mapping below.

Event Logging Tier 1 — Basic Requirements

Requirement

Supports

Minimum Logging Data ✅

Time Standard ✅

Event Forwarding ✅

Protecting and Validating Log Information ✅

Passive DNS ✅

Exporting Log Data ✅

Logging Orchestration, Automation, and Response — Planning ✅

User Behavior Monitoring — Planning ✅

Basic Centralized Access ✅

Basic Logging

Agencies must ensure that required logs categorized as Criticality Level 0 are retained in acceptable formats for specified time frames described in the M-21–31 memo.

• Chronicle is a cloud service built as a specialized layer on top of core Google infrastructure. It is designed for enterprises to privately retain, analyze, and search the massive amounts of security and network telemetry they generate. Chronicle normalizes, indexes, correlates and analyzes the data to provide instant analysis and context on risky activity.
• Google Cloud Logging is a fully managed service that allows you to store, search, analyze, monitor, and alert on logging data and events from Google Cloud. You can collect logging data from over 150 common application components, on-premises systems, and hybrid cloud systems.
• Logging includes storage for logs through log buckets, a user interface called the Logs Explorer, and an API to manage logs programmatically. Logging lets you read and write log entries, query your logs, and control how you route and use your logs.
• Google Cloud’s operations suite provides agents for collecting logs from Linux and Windows VM instances.
• Chronicle supports logs categorized as criticality Level 0 — Level 3. See Appendix 1 below for a complete list of supported logs.

Event Forwarding

Agencies shall forward all required logging data, in near real-time and on an automated basis, to centralized systems responsible for security, information, and event monitoring (SIEM), bulk storage, and other analytical workflows or services. Data must be encrypted in transit between its source and destination. In addition, agencies must ensure the original logs can be replayed for future use.

• Chronicle ingests logging data using an internal data forwarding service such as the Chronicle Forwarder.
• Chronicle retrieves security data stored in a cloud service such as Google Cloud Storage, Amazon S3, and Azure Blob Storage.
• The Chronicle Ingestion API enables you to forward logs directly to Chronicle, eliminating the need for additional hardware or software (for example, forwarders) in your environment.
• Another method of ingesting your security data into the Chronicle is to use a Chronicle API feed to poll external data feeds. Chronicle supports API feeds for the types of log data listed in the following Chronicle API Feed Types table.
• Chronicle API uses the OAuth 2.0 protocol for authentication and authorization, and the data is encrypted in transit between its source and destination.

Protecting and Validating Log Information

Agencies shall ensure data integrity; cryptographic methods must protect logging facilities and log information from tampering and unauthorized access.

• Google Cloud employs a multi-layered security model to ensure data integrity, and all data stores are protected against tampering and unauthorized access. To learn more about our transparent trust model, Look at our trust principles here.
• Google Cloud encrypts all customer content stored at rest, without any action required from the customer, using one or more encryption mechanisms.
• Chronicle logically segregates and stores your security data into your account in an encrypted form. Data is accessed by the customer only, plus a limited number of Google personnel as necessary to support, develop and maintain the product.
• As outlined in our trust principles, all Google personnel follow rigorous security protocols to protect against tampering and unauthorized access.
• Our products regularly undergo independent verification of their security, privacy, and compliance controls, achieving certifications, attestations, and audit reports to demonstrate compliance such as SOC, ISO, NIST, FedRAMP. Look at the Compliance resource center for more information.
• Chronicle can be integrated into your single sign-on (SSO) solution. You can log in to Chronicle using the credentials provided by your enterprise. Role-based access control (RBAC) enables an administrator to tailor access to Chronicle features based on an employee’s role in your organization.
• For securing logs stored on GCP native services such as BigQuery or Cloud Storage buckets, Identity and Access Management (IAM) enables you to grant access to cloud resources at fine-grained levels, well beyond project-level access. You can create more granular access control policies to resources based on attributes like device security status, IP address, resource type, and date/time. These policies help ensure the appropriate security controls when granting access to cloud resources.

Passive DNS

Federal agencies shall implement a Domain Name System (DNS) logging system, including DNS requests made over encrypted DNS connections. Agencies shall implement accompanying analytics that allow for rapid identification of the host that sourced each DNS query.

• Cloud DNS is reliable, resilient, low-latency DNS serving from Google’s worldwide network with everything you need to register, manage, and serve your domains.
• Cloud DNS supports DNSSEC, protecting your domains from spoofing and cache poisoning attacks. When you use a validating resolver like Google Public DNS, DNSSEC provides strong authentication (but not encryption) of domain lookups. For more information about DNSSEC, see Managing DNSSEC configuration.
• All Cloud DNS logs are written to Cloud Logging, natively ingested in Chronicle. To learn more about DNS logs, see here.
• Additionally, Chronicle can ingest logs from multiple 3rd-party DNS sources. See the complete list here.

Exporting Log Data

Agencies shall provide logs and other relevant data as per applicable law.

• Chronicle enables you to export raw logs to Google Cloud Storage. Additionally, if you have formatted your log data using Chronicle’s Unified Data Model (UDM), you can export these logs from chronicle to BigQuery.
• Google Cloud Logging can route logs using sinks. You can route some or all of your logs to supported destinations such as Cloud Storage, Pub/Sub, and BigQuery.
• Our partners can help agencies develop standardized data exporting processes to ensure format standards are met.

SOAR and User Behavior Monitoring — Planning

Agencies at EL1 stage shall start planning on how to best implement SOAR and User Behavior Monitoring capabilities in their environment. Agencies are expected to finalize their implementation of this capability to achieve EL3 maturity Level.

• Leveraging SOAR and UEBA technologies in your SOC will require a plan of how these technologies will be leveraged, supported, and continually managed in your SOC.
• We offer native SOAR capabilities through Siemplify, alongside pre-built content packs that offer playbooks for common use cases in the Siemplify Marketplace.
• We offer out-of-box UEBA capabilities through Event Threat Detection, a sub-service within Security Command Center Premium, for UEBA targeted to Google Cloud workloads.
• For multi-cloud, on-premise, and other non-GCP use-cases, customers can integrate 3rd party UEBA tools into Chronicle or leverage BigQuery to develop their own UEBA.
• Our partners will work with you on identifying the best fit strategy, tailored to your organizational objectives and support the planning and development efforts for this use case.

Basic Centralized Access

Logs should be centrally aggregated by an agency component-level Enterprise Log Manager (ELM).

• Chronicle enables you to collect and centrally store petabytes of logs in a cost-optimized manner. You can export logs to a Cloud Storage bucket that you configure for extended log retention. Permissions can be granted to limit access to the logs as appropriate. In order to reduce long-term storage costs, you can use the object lifecycle management feature in Cloud Storage to move logs to Nearline or Coldline storage classes and delete them after the required retention period has passed.
• Role-based access control (RBAC) enables an administrator to tailor access to Chronicle features based on an employee’s role in your organization.

Event Logging Tier 2 — Intermediate Requirements

Requirement

Supports

Meeting EL1 Maturity Level ✅

Intermediate Logging Categories ✅

Publication of Standardized Log Structure ✅

Inspection of Encrypted Data ✅

Intermediate Centralized Access ✅

Intermediate Logging Categories

Required logs categorized as criticality level 1 and 2 must be retained in acceptable formats for specified timeframes, per the technical details in Appendix C of M-21–31.

• As outlined in EL1, logs categorized in varying criticality tiers can be retained in the acceptable format for the specified timeframes.

Publication of Standardized Log Structure

For all software developed by or on behalf of Federal agencies that produces logs and is deployed in Federal environments, Federal agencies shall provide a document detailing the structure (schema) for those logs to CISA.

• Our partners can support Federal agencies’ requirements to develop detailed documentation on the schema of logs.

Inspection of Encrypted Data

Logs should be centrally aggregated by an agency component-level Enterprise Log Manager (ELM). Traps for detecting data-stream disruption should be monitored by the component-level SOC. While not a requirement of M-21–31, it’s recommended that agencies follow zero trust principles and follow relevant guidance from OMB And CISA.

• Our Network Forensics open-source blueprint offers customers a mechanism to ingest full packet mirrored data, exported as Zeek metadata logs, natively ingested in Cloud Logging and in Chronicle. For organizations that need network packet and flow metadata for threat hunting, detection, and investigation use cases, this blueprint is available for deployment on GitHub.
• Google Cloud IDS delivers cloud-native, managed, network-based threat detection, built with Palo Alto Networks’ industry-leading threat detection technologies to provide high levels of security efficacy. Cloud IDS can help customers gain deep insight into network-based threats and support industry-specific compliance goals that call for the use of an intrusion detection system.
• Network Forensics can NOT be leveraged alongside Cloud IDS, it is either one or the other. They both use the underlying packet mirroring technology, but Cloud IDS does not surface packet flow metadata, rather, the Cloud IDS team builds threat analytics in partnership with Palo Alto Networks.
• For the purpose of the memorandum, there is a requirement for storing 72 hours of full PCAP on certain log types, this can be captured through packet mirroring. If agencies do not perform full traffic inspection, they can leverage our Network Forensics blueprint to capture Zeek metadata.
• Google pioneered the Zero Trust model, we offer a Zero Trust solution that is aligned to M-22–09 for organizations that also need to explore this solution.

Intermediate Centralized Access

Required logs categorized as criticality level 0 and 1 are accessible and visible for the highest-level security operations and the head of each agency. Required logs categorized as criticality level 2 are retained, at a minimum, at component level. Detecting data-stream disruption should be monitored by the component-level and top-level enterprise SOCs. The DNS logging system and accompanying analytics should be monitored. Cross-organizational analytics are established.

• As outlined in EL1, required logs in the varying criticality levels are centralized and role-based access controls can be implemented.
• Health status of log sources can be monitored through dashboards and give insights into potential data-stream disruptions.
• Ingesting DNS logs and leveraging pre-built and custom-built analytics are a core capability of the security stack.
• Cross-organizational analytics (e.g. operational fusion) can be designed, developed, and implemented on a use-case by use-case basis.
• Role-based access control can be implemented to manage access.

Event Logging Tier 3 — Advanced Requirements

Requirement

Supports

Meeting EL2 Maturity Level ✅

Advanced Logging Categories ✅

Logging Orchestration, Automation, and Response — Finalizing Implementation ✅

User Behavior Monitoring — Finalizing Implementation ✅

Application Container Security, Operations, and Management ✅

Advanced Centralized Access ✅

Advanced Logging Categories

Required logs categorized as criticality level 3 must be retained in acceptable formats for specified timeframes, per technical details described in Appendix C of M-21–31.

• As outlined in EL1 and EL2, logs categorized in varying criticality tiers can be retained in the acceptable format for the specified timeframes.

Logging Orchestration, Automation, and Response — Finalizing Implementation

​​Federal agencies must deploy SOAR playbooks to implement automated hunt and incident response activities.

• The Siemplify Security Operations Platform serves as a complete cloud-native security operations workbench — delivering serious orchestration, automation and response firepower. The platform benefits from Google’s scalability, maturity, telemetry and multi-cloud support — while continuing to provide a rich source of vendor-agnostic integrations. Key capabilities include:
• Playbooks — Synchronize people, processes and technology to reduce the amount of human intervention required in day-to-day tasks for more predictable and rapid incident response.
• Case Management — Ingest, prioritize, assign and investigate security alerts from all your detection tools with case management that is purpose-built for security operations.
• Investigation — Focus on threats, rather than alerts, to get to the root cause in seconds.
• Integrated Threat Intelligence — Automate the collection, management and sharing of threat intelligence with pre-integrated ThreatFuse.
• Collaboration — Bring your team together to drive results with effective and transparent communication.
• Dashboards & reporting — Improve performance and efficiency of your security team and rise above the daily firefighting.
• Crisis management — Coordinate hands-on incident response, inside and outside of the SOC.

User Behavior Monitoring — Finalizing Implementation

Federal agencies must leverage User and Entity Behavior Analytics (UEBA) to identify anomalous behavior and potential threats in their organization. At a minimum, UEBA monitoring should be configured to detect and alert on compromised user credentials, privileged-user compromise, improper asset access, compromised system/host/devices, and lateral movement of threat actors.

• Security Command Center Premium offers UEBA capabilities out-of-box through it’s threat detection suite. The analytics are pre-built based on highly curated threat indicators. Most use case requirements can be met natively in SCC Premium.
• These analytics are natively ingested in the Chronicle security platform, which customers can triage and investigate.
• Siemplify can be leveraged to develop automation and response playbooks on UEBA analytics.
• For multi-cloud use cases, customers can leverage our best-of-breed big data analytics capabilities such as BigQuery to enable high performance log analysis and insights into behavioral signals. BigQuery ML can be leveraged to develop and execute machine learning models on BigQuery data sets. Our partners have libraries of content developed for the use cases required by the memorandum.

Application Container Security, Operations, and Management

Container security and monitoring tools should be integrated with security information and event management (SIEM) tools to ensure container-related events are captured by the enterprise. Alternatively, in cases where the uses and privileges of containers are appropriately constrained by the orchestration layer, agencies may rely on SIEM tools present at that layer. As a best practice, Federal agencies shall ensure their hunt and incident response teams are equipped with the appropriate tools and training to identify incidents in container-based environments.

• Container Threat Detection is a built-in service for the Security Command Center Premium tier that continuously monitors the state of Container-Optimized OS node images. The service evaluates all changes and remote access attempts to detect runtime attacks in near-real time.
• Container Threat Detection detects the most common container runtime attacks and alerts you in Security Command Center and, optionally, in Cloud Logging. Container Threat Detection includes several detection capabilities, including suspicious binaries and libraries, and uses natural language processing (NLP) to detect malicious bash scripts.
• Leveraging a managed Kubernetes service such as Google Kubernetes Engine (GKE) provides native security controls to container workloads that offer defense-in-depth when combined with Container Threat Detection. There are various capabilities within GKE to protect your workloads across the many layers of the stack. To learn more about securing your GKE environment, read here.
• Chronicle integrates with Security Command Center to ingest findings from Container Threat Detection which is a built-in service for the Security Command Center Premium tier that continuously monitors the state of Container-Optimized OS node images. The service evaluates all changes and remote access attempts to detect runtime attacks in near-real time.
• Chronicle supports ingestion of logs at various layers of containerized infrastructure.
• Our partners have developed libraries of content for container-based use cases that can help enable and upskill security operations teams.

Advanced Centralized Access

Required logs across all criticality levels shall be accessible to highest-level security operations at the head of each agency.

• As outlined in EL1 and EL2, required logs in the varying criticality levels are centralized.
• Role-based access control can be implemented to manage access.

How to Achieve Autonomic Security Operations in the Public Sector

Modernizing your SOC in pursuit of ASO will require a well thought-out transformation of how you leverage your people, processes, and technologies across your threat management practice. As referred to in the Autonomic Security Operations Whitepaper, implementing the practices and principles of a modern SOC will require a cultural evolution that is championed by your leadership team and embodied across your organization. A feat of this magnitude will require a well thought out, multi-year strategy to modernize the program and the various use cases within your SOC.

In the Public Sector, the challenges inherent to the regulatory environment and risk-averse approach to technology expansion has made modernization a difficult undertaking. As of the latest cybersecurity mandate, we are seeing very strong signals that organizations are no longer treading lightly here and want to get ahead of the latest security challenges to unblock the technological opportunities that come with modern technology stacks. To relieve these challenges and aid the Public Sector in achieving the requirements of M-21–31 and the greater security operations modernization effort, we have partnered with Deloitte, CYDERES, and Accenture to deliver success to our clients.

Our Partners

Understanding that the journey will require significant investment in assessing your current state, planning your strategic investments, identifying milestones, resources, and executing on a transformation of this magnitude will require qualified partners who can provide unique capabilities that may serve your organization through managing all of the change. After all, an investment across the entire spectrum of your Security Operations practice is no easy feat. We will continue to introduce and expand more partners as we see fit, to bring the Autonomic Security Operations vision across the Public Sector. For more information about our partners, please visit our solutions page.

Conclusion

Adopting Autonomic Security Operations can reduce much of the toil that analysts have historically faced trying to achieve comprehensive situational awareness across an overproliferation of cyber tools. Evolving from a reactive state, analysts can confidently achieve full visibility, armed with the right data at the right time to detect, analyze and combat the most significant threats to the organization. While the Public Sector can not hire its way out of its cyber talent shortage, it can achieve the same ends by making the talent it does have dramatically more productive and agile. Adhering to the Continuous Detection and Continuous Response workflow becomes the key to building a proactive threat management practice.

The work we’re doing to advance the industry towards Autonomic Security Operations builds on the approach we had set out in the whitepaper, and while we’re supporting our Commercial and Federal clients on their journey, we’re continuing to invest in R&D initiatives under ASO with our Public and Private sector partners, including our latest sponsorship and participation in the MITRE Center for Threat Informed Defense. The core mission of cybersecurity is to protect the systems that underpin our lives, many of which our lives have become increasingly dependent on. Advancing our capabilities and sharing our knowledge with the industry will only support the democracy that we strive to uphold.

The requirements of the Executive Order and OMB M-21–31 are very thoughtfully devised and highlight gaps that most organizations have in their defenses. We look forward to supporting the Public Sector in this journey of modernization.