As sophisticated cyberattack campaigns increasingly target the U.S. public and private sectors during the COVID era, the White House and federal agencies have taken steps to protect critical infrastructure and remote-work infrastructure. These include Executive Order 14028 and the Office of Management and Budget’s Memorandum M-21-31, which recommend adopting Zero Trust policies, and span software supply chain security, cybersecurity threat management, and strengthening cyberattack detection and response.

However, implementation can be a challenge for many agencies due to cost, scalability, engineering, and a lack of resources. Meeting the requirements of the EO and OMB guidance may require technology modernization and transformational changes around workforce and business processes.

Today we are announcing Autonomic Security Operations (ASO) for the U.S. public sector, a solution framework to modernize cybersecurity analytics and threat management that’s aligned with the objectives of EO 14028 and OMB M-21-31. Powered by Google’s Chronicle and Siemplify, ASO helps agencies to comprehensively manage cybersecurity telemetry across an organization, meet the Event Logging Tier requirements of the White House guidance, and transform the scale and speed of threat detection and response. ASO can support government agencies in achieving continuous detection and continuous response so that security teams can increase their productivity, reduce detection and response time, and keep pace with – or ideally, stay ahead of – attackers.

While the focus of OMB M-21-31 is on the implementation of technical capabilities, transforming security operations will require more than just technology. Transforming processes and people in the security organization is also important for long-term success. ASO provides a more comprehensive lens through which to view the OMB event logging capability tiers, which can help drive a parallel transformation of security-operations processes and personnel.

Modern Cybersecurity Threat Detection and Response

Google provides powerful technical capabilities to help your organization achieve the requirements of M-21-31 and EO 14028:

Security Information & Event Management (SIEM) – Chronicle provides high-speed petabyte-scale analysis, and is capable of consuming log types outlined in the Event Logging (EL) tiers in a highly cost-effective manner.

Security Orchestration, Analytics, and Response (SOAR) – Siemplify offers dozens of out-of-box playbooks to deliver agile cybersecurity response and drive mission impact, including instances of automating 98% of Tier-1 alerts and driving an 80% reduction in caseload.

User and Entity Behavior Analytics (UEBA) – For agencies that want to develop their own behavioral analytics, agencies can use BigQuery, Google’s petabyte scale data lake, to store, manage, and analyze diverse data types from many sources. Telemetry can be exported out of Chronicle, and custom data pipelines can be built to import other relevant data from disparate tools and systems, such as IT Ops, HR and personnel data, and physical security data. From there, users can leverage BQML to readily generate machine learning models without needing to move the data out of BigQuery. For Google Cloud workloads, our Security Command Center Premium product offers native, turnkey UEBA across GCP workloads.

Endpoint Detection and Response (EDR) – For most agencies, EDR is a heavily adopted technology that has broad applicability in Security Operations. We offer integrations to many EDR vendors. Take a look at our broad list of Chronicle integrations here.

Threat intelligence – Our solution offers a native integration with VirusTotal, has the ability to operationalize threat intelligence feeds natively in Chronicle, and integrates with various TI and TIP solutions.

Community Security Analytics

To increase collaboration across public-sector and private-sector organizations, we recently launched our Community Security Analytics (CSA) repository, where we’ve partnered with the MITRE Engenuity Center for Threat-Informed Defense, CYDERES, and others to develop open-source queries and rules that support self-service security analytics for detecting common cloud-based security threats. CSA queries are mapped to the MITRE ATT&CK® framework of tactics, techniques and procedures (TTPs) to help you evaluate their applicability in your environment and include them in your threat model coverage.

“Deloitte is excited to collaborate with Google Cloud on their transformational public sector Autonomic Security Operations (ASO) solution offering. Deloitte has been recognized as Google Cloud’s Global Services Partner of the Year for four consecutive years, and also as their inaugural Public Sector Partner of the Year in 2020,” said Chris Weggeman, managing director of GPS Cyber and Strategic Risk, Google Cloud Cyber Alliance Leader, Deloitte & Touche LLP. “Our deep bench of more than 1,000 Google Cloud certifications, capabilities spanning the Google Cloud security portfolio, and decades of delivery experience in the government and public sector makes us well-positioned to help our clients undertake critical Security Operations Center transformation efforts with Google Cloud ASO.”

Cost-effective for government agencies

To help Federal Agencies meet the requirements of M-21-31 and the broader EO, Google’s ASO solutions can drive efficiencies and help manage the overall costs of the transformation. ASO can make petabyte-scale data ingestion and management more viable and cost-effective. This is critical at a time when M-21-31 is requiring many agencies to ingest and manage dramatically higher volumes of data that had not been previously budgeted for.

Partners

We’re investing in key partners who can help support U.S. government agencies on this journey. Deloitte and CYDERES both have deep expertise to help transform agencies’ Security Operations capabilities, and we continue to expand our partners to support the needs of our clients. A prototypical journey can be seen below.

“Cyderes shares Google Cloud’s mission to transform security operations, and we are honored to deliver the Autonomic Security Operations solution to the U.S. public sector. As the number one MSSP in the world (according to Cyber Defense Magazine’s 2021 Top MSSPs List) with decades of advisory and technology experience detecting and responding to the world’s biggest cybersecurity threats, Cyderes is uniquely positioned to equip federal agencies and departments to go far beyond the requirements of the executive order to transform their security programs entirely via Google’s unique ASO approach,” said Robert Herjavec, CEO of CYDERES. “As an original launch partner of Google Cloud’s Chronicle, our deep expertise will propel our joint offering to modernize security operations in the public sector, all with significant cost efficiency compared to competing solutions.” said Eric Foster, President of CYDERES.

Embracing ASO

Autonomic Security Operations can help U.S. government agencies advance their event logging capabilities in alignment with OMB maturity tiers. More broadly, ASO can help the U.S. government undertake a larger transformation of technology, process, and people, toward a model of continuous threat detection and response. As such, we believe that ASO can help address a number of challenges presently facing cybersecurity teams, from the global shortage of skilled workers, to the overproliferation of security tools, to poor cybersecurity situational awareness and analyst burnout caused by an increase of data without sufficient context or tools to automate and scale detection and response.

We believe that by embracing ASO, agencies can help agencies achieve:

10x technology, through the use of cloud-native tools that help agencies meet event logging requirements in the near term, while powering a longer-term transformation in threat management;

10x process, by redesigning workflows and using automation to achieve Continuous Detection and Continuous Response in security operations;

10x people, by transforming the productivity and effectiveness of security teams and expanding their diversity; and

10x influence across the enterprise through a more collaborative and data-driven approach to solving security problems between security teams and non-security stakeholders.

To learn more about Google’s Autonomic Security Operations solution for the U.S. public sector, please read our whitepaper. More broadly, Google Cloud continues to provide leadership and support for a wide range of critical public-sector initiatives, including our work with the MITRE Engenuity Center for Threat-Informed Defense, the membership of Google executives on the President’s Council of Advisors on Science and Technology and the newly established Cyber Safety Review Board; Google’s White House commitment to invest $10 billion in Zero Trust and software supply chain security, and Google Cloud’s introduction of a framework for software supply chain integrity. We look forward to working with the U.S. government to make the nation more secure.

Visit our Google Cloud for U.S. federal cybersecurity webpage.

Related posts:

Autonomic Security Operations for the U.S. Public Sector Whitepaper

“Achieving Autonomic Security Operations: Reducing toil”

“Achieving Autonomic Security Operations: Automation as a Force Multiplier”

“Advancing Autonomic Security Operations: New resources for your modernization journey”

Corporate firewalls typically include a massive number of rules, which accumulate over time as new workloads are added. When rules stack up piecemeal like this, misconfigurations occur that, at best, create headaches for security administrators, and at worst, create vulnerabilities that lead to security breaches.  

To address this, we have introduced the Firewall Insights module in our Network Intelligence Center, which provides a single console for managing Google Cloud network visibility, monitoring and troubleshooting. 

What are Firewall insights?

Historically, there hasn’t been an easy way to deal with the accumulation of complicated firewall rules. That was until we created Firewall Insights, which provides metrics reports and insight reports. These two reports contain information about firewall usage and the impact of various firewall rules on your VPC network. Even better, these insights and metrics are integrated into your Google Cloud Console for the VPC firewall and are also available via APIs.

You can use metrics reports to verify that firewall rules are being used appropriately and as intended. This report can uncover leftover rules from the past that are not actively used, review that the firewall rules allow or deny what is intended, perform live debugging of connections dropped, and leverage Cloud Monitoring to discover malicious attempts to access your network. 

You can use insight reports to identify firewall misconfigurations, detect security attacks, and optimize and tighten your security rules.

Let’s take a look at how these reports work.

Metrics Report, a deeper dive

Metrics insights analyzes your VPC firewalls usage by tracking metrics such as firewall hit counts and last used.  Let’s check this out with an example:

When you navigate to your VPC network and click on Firewall, ensure that you have selected Logs, Hit count and also Last hit in the column display options:

After this is enabled, now you should be able to see your VPC firewall rules with the hit count and last hit metrics. In the image below you can see that if logs are not enabled for rules, hit count and last hit metrics will not be collected. If logs are enabled, these details are collected, and shown in the VPC firewalls console.

As you can see in Figure 1.2, each firewall rule which has logging enabled will show hit counts, so based on the example above, the rule “uc1-db4-deny-http”  has been hit 109,154 times, the last time being 2021-03-10 (13:10:00). If you want to dive even deeper, you can click on the hit count and this will bring you to the logs viewer page where you can expand these logs and analyze all the details:

In order to enable logs for a particular firewall rule, you can edit it and turn logs on. By default, metadata is added in firewall logs. If you want to reduce the log size, you can do so by excluding these additional fields. Excluding these metadata fields will not impact the functionality of Firewall Insights.

From the “Firewall” page, you can also multi-select a group of firewall rules and turn on all logs at once.

Firewall rule usage metrics are accurate only for the period of time during which Firewall Rules Logging is enabled.

Insights Report, a deeper dive

Insights Report provides an intelligent analysis of the configuration of your firewalls. A report can contain one or more insights. 

We will see examples now about the different insight reports which include:

• Shadowed firewall rules
• Allow rules with no hit in the last six weeks
• Deny rules with hits in the last 24 hours

By definition, a shadowed rule is a VPC firewall rule that is completely overshadowed by one or more firewall rules with higher or equal priority. We call that shadowing rules. Let’s see an example on how to find shadowed rules:Let’s say that you try to use ping between two VMs but it fails. Let’s take a look at the firewall rules applied to the VM:

If we look closely, we can see that there are two rules with the same target tag, and those are almost identical except their source IP range. The IP range of the deny rule “uc1-app2-deny-all” includes the IP range of the rule allow “uc1-app2-allow-app1”. Therefore, we can see that “uc1-app2-allow-app1” is shadowed by “uc1-app2-deny-all”, and the ping between these VMs failed due to that.

To avoid such incidents in the future, Firewall Insights provides you with a convenient list of rules overshadowed by other firewall rules.

To see shadowed rules, you can click on the column selector, and add “Insights” to the firewall and route details:

Once this is applied, you will be able to see shadowed rules here:

Alternatively, you can navigate to Network Intelligence > Firewall Insights, where we will see the shadowed rule report:

If we click on the insight we will get more details:

Going back to the firewall insights card (Figure 1.8), we can also identify that “uc1-db4-allow-app3” is shadowed by a combination of two rules and if we clicked on the insight this would provide all the details.

From the Firewall Insights dashboard, let’s move on to “allow rules with no hit”, where we can see firewall rules that have not logged any hits in the past six weeks. Such rules could be as a result of a misconfiguration, or leftover rules from past deployments. Tighten your security boundaries by identifying and removing such rules. If we go back to Network Intelligence > Firewall Insights, we can see allow rules with no hit:

We can drill down to view the full list of rules with no hit. We can see, for instance, one of the rules, the bottom one “uc2-app1-allow-internet”, might be a leftover rule to allow internet access from a past deployment, which means it has little likelihood of being hit in the future. So you may want to consider removing it from the rule set:

Click on the firewall rule to review all the details, and take a look at the prediction, which is made based on the hit pattern that we saw for similar rules in the same organization:

Let’s go back to the Firewall Insights dashboard and move on to the last category, “deny rules with hits in the last 24 hours”, which help you capture the traffic blocked by deny rules. These traffic types could indicate external attacks into your VPC network, or compromised VM instances attempting to send traffic out of your network. Let’s examine future hit prediction on a firewall rule. Navigate to Network Intelligence > Firewall Insights and take a look at the deny rules with hits card:

If your click on the “uc4-web-deny-web” rule, you can see the hit count monitoring, and if you click on the hit number we can dive deeper in the logs:

These tips should help you effectively leverage Firewall Insights to gain better control over a massive firewall rule set. Automate shadowed rule detection, quickly troubleshoot misconfigured rules, effortlessly pinpoint the overgranting rules hidden in the rule set, and identify the failed attempts to break into your network that were rejected by your firewall rules. 

To learn more about Firewall Insights, please refer to our documentation. Additionally, to see how we’re advancing intelligent automation in network security, check our recent blog post.

A critical component of any security operations team’s job is to deliver high-fidelity detections of potential threats across the breadth of adversary tactics. But increasingly sophisticated threat actors, an expanding attack surface, and an ever-present cybersecurity talent shortage make this task more challenging than ever.

Google keeps more people safe online than anyone else. Individuals, businesses and governments globally depend on our products that are secure-by-design and secure-by-default. Part of the “magic” behind Google’s security is the sheer scale of threat intelligence we are able to derive from our billions of users, browsers, and devices.

Today, we are putting the power of Google’s intelligence in the hands of security operations teams. We are thrilled to announce the general availability of curated detections as part of our Chronicle SecOps Suite. These detections are built by our Google Cloud Threat Intelligence (GCTI) team, and are actively maintained to reduce manual toil in your team.

Our detections provide security teams with high quality, actionable, out-of-the-box threat detection content curated, built and maintained by Google Cloud Threat Intelligence (GCTI) researchers. Our scale, and depth of intelligence, gained by securing billions of users everyday, gives us a unique vantage point to craft effective and targeted detections. These native detection sets cover a wide variety of threats for cloud and beyond, including Windows-based attacks like ransomware, remote-access tools (RAT), infostealers, data exfiltration, suspicious activity, and weakened configurations.

With this launch, security teams can smoothly leverage Google’s expertise and unique visibility into the threat landscape. This release helps understaffed and overstressed security teams keep up with an ever evolving threat landscape, quickly identify threats, and drive effective investigation and response. With this new release, security teams can:

• Enable high quality curated detections with a single click from within the Chronicle console.
• Operationalize data with high-fidelity threat detections, stitched with context available from authoritative sources (such as IAM and CMDB).
• Accelerate investigation and response by finding anomalistic assets and domains with prevalence visualization for the detections triggered.
• Map detection coverage to the MITRE ATT&CK framework to better understand adversary tactics and techniques and uncover potential gaps in defenses.

Detections are constantly updated and refined by GCTI researchers based on the evolving threat landscape. The first release of curated detections includes two categories that cover a broad range of threats, including:

• Windows-based threats: Coverage for several classes of threats including infostealers, ransomware, RATs, misused software, and crypto activity.
• Cloud attacks and cloud misconfigurations: Secure cloud workloads with additional coverage around exfiltration of data, suspicious behavior, and additional vectors.

Let’s look at an example of how you can put curated detections to work within the Chronicle dashboard, monitor coverage, and map to MITRE ATT&CK®.

An analyst can learn more details around specific detections and understand how they map to the MITRE ATT&CK framework. There are customized settings to configure deployment and alerting, and specify exceptions via reference lists.

You can see each rule which has generated a detection against your log data in the Chronicle rules dashboard. You can observe detections associated with the rule and pivot to investigative views. For example, here is the detection view from the timeline of an Empire Powershell Stager launch triggered by the Windows RAT rule set. You can also easily pivot to associated information and investigate the asset on which it was triggered.

By surfacing impactful, high-efficacy detections, Chronicle can enable analysts to spend time responding to actual threats and reduce alert fatigue. Our customers who used curated detections during our public preview were able to detect malicious activity and take actions to prevent threats earlier in their lifecycle. And there’s more to come. We will be delivering a steady release of new detection categories covering a wide variety of threats, community-driven content, and other out-of-the-box analytics.

Ready to put Google’s intelligence to work in your Security Operations Center? Contact Google Cloud sales or your customer success CSM team. You can also learn more about all these new capabilities in Google Chronicle in our product documentation.

Many security leaders head into the cloud armed mostly with tools, practices, skills and ultimately the mental models for how security works that were developed on premise. This leads to cost and efficiency problems that can be solved by mapping their existing mental models to those of the cloud.

When it comes to understanding the differences between on-premises cybersecurity mental models and their cloud cybersecurity counterparts, a helpful place to start is by looking at the kinds of threats each one is attempting to block, detect, or investigate.

Traditional on-premise threats focused on stealing data from databases, file storage, and other corporate resources. The most common defenses of these resources rely on layers of network, endpoint, and sometimes application security controls. The proverbial “crown jewels” of corporate data were not made accessible with an API to the outside world or stored in publicly accessible storage buckets. Other threats aimed to disrupt operations or deploy malware for various purposes, ranging from outright data theft to holding data for ransom.

There are some threats that are specifically aimed at the cloud. Bad actors are always trying to take advantage of the ubiquitous nature of the cloud. One common cloud-centered attack vector that they pursue is constantly scanning IP address space for open storage buckets or internet-exposed compute resources.

As Gartner points out, securing the cloud requires significant changes in strategy from the approach we take to protect on-prem data centers. Processes, tools, and architectures need to be designed using cloud-native approaches to protect critical cloud deployments. And when you are in the early stages of cloud adoption, it’s critical for you to be aware of the division of security responsibilities between your cloud service provider and your organization to make sure you are less vulnerable to attacks targeting cloud resources.

Successful cloud security transformations can help better prepare CISOs for threats today, tomorrow, and beyond, but they require more than just a blueprint and a set of projects. CISOs and cybersecurity team leaders need to envision a new set of mental models for thinking about security, one that will require you to map your current security knowledge to cloud realities.

As a way to set the groundwork for this discussion, the cloud security transformation can start with a meaningful definition of what “cloud native” means. Cloud native is really an architecture that takes full advantage of the distributed, scalable, and flexible nature of the public cloud. (To be fair, the term implies that you need to be born in the cloud to be a native, but we’re not trying to be elitist about it. Perhaps a better term would be “cloud-focused” or doing the security “the cloudy way.”)

However we define it, adopting cloud is a way to maximize your focus on writing code, creating business value, and keeping your customers happy while taking advantage of cloud-native inherent properties—including security. One sure way to import legacy mistakes, some predating cloud by decades, into the future would be to merely lift-and-shift your current security tools and practices into the public cloud environment.

Going cloud-native means abstracting away many layers of infrastructure, whether it’s network servers, security appliances, or operating systems. It’s about using modern tools built for the cloud and built in the cloud. Another way to think about it: You’ll worry less about all these things because you’re going to build code on top of that to help you move more quickly. Abandoning legacy security hardware maintenance requirements is part of the win here. To put another way, security will follow in the steps of IT that has been transformed by the SRE and DevOps revolution.

You can extend this thinking to cloud native security, where some of your familiar tools combine with solutions provided by cloud service providers to take advantage of cloud native architecture to secure what’s built and launched in the cloud. While we talked about the differences between on-prem targeted threats compared to threats targeting cloud infrastructure, here are other vital areas to re-evaluate in terms of a cloud security mental model.

Network security

Some organizations practice network security in the cloud as if it were a rented data center. While many traditional practices that worked reasonably well on-premise for decades, along with many traditional network architectures, are either not applicable in the cloud or not optimal for cloud computing.

However, concepts like a demilitarized zone (DMZ) can be adapted to today’s cloud environments. For example, a more modern approach to DMZ would use microsegmentation and govern access by identity in context. Making sure that the right identity, in the right context, has access to the correct resource gives you strong control. Even if you get it wrong, microsegmentation can limit a breach blast radius.

Becoming cloud native also drives the adoption of new approaches to enterprise network security, such as BeyondProd. It also benefits organizations because it gets them away from traditional network perimeter security to focus on who and what can access your services—rather than where requests for access originated.

Although network security changes driven by cloud adoption can be enormous and transformational, not all areas shift in the same way.

Endpoint security

In the cloud, the concept of a security endpoint changes. Think of it this way: A virtual server is a server. But what about a container? What about microservices and SaaS? With software as a service cloud model, there’s no real endpoint there. All along your cloud security path, users only need to know what happens where.

Here is a helpful mental model translation: An API can be seen as sort of an endpoint. Some of the security thinking developed for endpoints applies to cloud APIs as well. Securing access, permissions, privileged access thinking can be carried over, but the concept of endpoint operating system maintenance does not.

Even with automation of service agents on virtual machines in the cloud, insecure agents may increase risks because they are operating at scale in the cloud. Case in point: This major Microsoft Azure cross-tenant vulnerability highlighted a new type of risk that wasn’t even on the radar of many of its customers.

In light of this, across the spectrum of endpoint security approaches, some disappear (such as patching operating systems for SaaS and PaaS), some survive (such as the need to secure privileged access,) and yet others are transformed.

Detection and response

With a move to the cloud comes changes to the threats you’ll face, and changes to how you detect and respond to them. This means that using on-prem detection technology and approaches as a foundation for future development may not work well. Copying all your on-premises detection tools and their threat detection content won’t reduce risks in the way that most cloud-first organizations will need..

Moving to the cloud provides the opportunity to rethink how you can achieve your security goals of confidentiality, integrity, availability, and reliability with the new opportunities created by cloud process and technology.

Cloud is distributed, often immutable, API-driven, automatically scalable, and centered on the identity layer and often contains ephemeral workloads created for a particular task. All these things combine to affect how you handle threat detection for the cloud environment and necessitate new detection methods and mechanisms.

There are six key domains where threats in the cloud can be best detected: identify, API, managed services, network, compute, and Kubernetes. These provide the coverage needed related to network, identity, compute, and container infrastructure. They also provide specific detection mechanisms for API access logs and network traffic captures.

As with endpoint security, some approaches become less important (such as network IDS on encrypted links), others can grow in importance (such as detecting access anomalies,) while others transform (such as detecting threats from the provider backplane).

Data security

The cloud is changing data security in significant ways, and that includes new ways of looking at data loss prevention, data encryption, data governance, and data access.

Cloud adoption sets you on a path to what we at Google call “autonomic data security.” Autonomic data security means security has been integrated throughout the data lifecycle and is improving over time. At the same time, it makes things easier on users, freeing them from having to define and redefine myriad rules about who can do what, when, and with which data. It lets you keep pace with constantly evolving cyberthreats and business changes, so you can keep your IT assets more secure and make your business decisions faster.

Similar to other categories, some data security approaches wane in importance or disappear (such as manual data classification at cloud scale), some retain their importance from on-prem to cloud unchanged, while others transform (such as pervasive encryption with effective and secure key management).

Identity and access management

The context for identity and access management (IAM) in the cloud is obviously different from your on-premise data center. In the cloud, every person and service has its own identity and you want to be able to control access.

Within the cloud, IAM gives you fine-grained access control and visibility for centrally managing cloud resources. Your administrators authorize who can act on specific resources, giving you full control and visibility to manage cloud resources centrally. What’s more, if you have complex organizational structures, hundreds of workgroups, and a multitude of projects, IAM gives you a unified view into security policy across your entire organization.

With identity and access management tools, you’re able 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 and time. These policies help ensure that the appropriate security controls are in place when granting access to cloud resources.

The concept of Zero Trust is strongly in play here. It’s the idea that implicit trust in any single component of a complex, interconnected system can create significant security risks. Instead, trust needs to be established via multiple mechanisms and continuously verified. To protect a cloud-native environment, a zero trust security framework requires all users to be authenticated, authorized, and validated for security configuration and posture before being granted or keeping access to cloud-based applications and data.

This means that IAM mental models from on premise security mostly survive, but a lot of underlying technology changes dramatically, and the importance of IAM in security grows significantly as well.

Shared fate for greater trust in cloud security

Clearly, cloud is much more than “someone else’s computer.” That’s why trust is such a critical component of your relationship with your chosen cloud service providers. Many cloud service providers acknowledge shared responsibility, meaning that they supply the underlying infrastructure but leave you responsible for many seemingly inscrutable security tasks.

With Google Cloud, we operate in a shared fate model for risk management in conjunction with our customers. We believe that it’s our responsibility to be active partners as our customers deploy securely on our platform, not delineators of where our responsibility ends. We stand with you from day one, helping you implement best practices for safely migrating to and operating in a trusted cloud.

Get ready to go cloud native

We offer you several great resources to help you prepare for cloud migration, and guide you as you review your current security approaches for signs of on-prem thinking.

Listen to our podcast series where Phil Venables, Vice President, CISO at Google Cloud, and

Nick Godfrey, Director, Financial Services Security & Compliance and member of Office of the CISO at Google Cloud, join me in a discussion on preparing for cloud migration (Podcast 1, Podcast 2). You can deepen your cloud native skills by earning a Professional Cloud Security Engineer certification from Google.

When technology just works, it’s easy to trust. But too often, we place our trust in technology that doesn’t deserve it. When we do this with technology to provide healthcare, we put the safety of patients and the security and reliability of our global healthcare system at risk.

The institutions that make up our global healthcare system also place their trust in cybersecurity measures and technology to keep their systems running and repelling the unceasing wave of attacks they face. We often hear about the institutions that succumb to cyberattacks, but we don’t read much about the institutions that have been successful at defending their digital perimeter, and ultimately protected their ability to treat and protect patients.

Why were some institutions successful and others not as much? What cybersecurity capabilities made the healthcare institution resilient from these attacks? As we covered in our previous post on how healthcare can strengthen its cybersecurity resilience, establishing visibility and antifragility practices are necessary to repel attackers and build trust in the security and reliability of the technology our global healthcare system relies on.

As we continue our series on healthcare and cybersecurity, we’ll focus next on establishing sustainable visibility mechanisms so cybersecurity teams working in our global healthcare system can secure and preserve patient care and safety.

Visibility is akin to a patient taking 20 different medications but their doctor only knows about 10 of them. That’s the current state of many healthcare organizations’ relationship to the technology used on their networks and systems: They aren’t always aware of what technology is in use, whether it has vulnerabilities, how serious those vulnerabilities are, or how one weakness could lead to another or cascade out of control.

Visibility maps those technology assets (including the software, hardware, configurations, protections, who built it, and where the component parts come from) and help prioritize the importance of those assets in keeping systems and networks secure, no matter how complex the healthcare organization’s use of technology might be.

Building effective visibility

Building visibility into technology assets requires a structured approach. As mentioned in the first blog in this series, using a guide like the NIST Cybersecurity Framework (CSF) provides an important mental model we can use to get a clear picture of the strengths and weaknesses of an organization’s cybersecurity risk profile, and how it applies to the assets the organization seeks to protect.

Cybersecurity author and leader Sounil Yu’s book Cyber Defense Matrix provides an important interpretation of the NIST CSF framework that can help us better understand what visibility we have into technology assets and how they are protected. Visibility is about more than just seeing all assets we have all at once. It’s also about understanding which assets are mission-critical and must be protected at all costs versus which ones are perhaps important but less crucial overall. Without the right balance, we end up trying to protect everything while not protecting what matters enough. This is where structural awareness comes in.

Structural awareness, or the conscious understanding and state of an organization’s assets, is established as one implements controls captured in the NIST CSF functions Identify and Protect. These controls focus on identifying assets, their bill of materials, their creators, their dependencies on other assets, the protections and vulnerabilities they have, and the threats they face. While visibility helps create an accurate map of technology assets, structural awareness builds on that visibility and answers questions such as, “What are the ways the threat actor could compromise that asset? What could be lost? How would it most likely happen? Would I know?”

Yu says that structural awareness is efficiently achieved with the help of automation, and is not as people-intensive as many practitioners, decision-makers, and executives might think. If a cyberattack is like an explosion, cybersecurity teams’ structural awareness helps them understand how the explosion could happen before (or ‘left of’) it goes ‘boom’.

It’s also important to remember that while structural awareness is related to situational awareness in some ways, they are different concepts. Situational awareness refers to mechanisms that are used to detect and respond to an event. Structural awareness mechanisms are ‘left of boom,’ or mechanisms that protect your assets so that events don’t happen. The goal is to stay ‘left of boom’ and avoid being ‘right of boom’. Being proactive in your protections and being ready to respond in either case is really important, nonetheless.

Thinking about assets in terms of users, devices, networks, applications and workloads and data (asset classes), and adopting mechanisms to discover assets of each type through visibility controls suggested by the NIST CSF, will lead to developing structural awareness. Structural awareness can help avoid the boom, but if the boom does happen, it can also help shape the situational awareness needed to react. The Cyber Defense Matrix is an ongoing project, and you can read more about it (and contribute to it) here.

Framing asset discovery for resilience

Cybersecurity teams must map out their organizations’ most critical healthcare services and systems that support them, but that’s easier said than done. Asset discovery can feel overwhelming. Trying to find, count, and audit the hardware, software, users, and data down to the component across even a small part of one’s technology footprint can feel like pushing a dead car up a steep hill. The way to make this easier is to prioritize this effort in the parts of the business where the impact of a quality or safety issue has the potential to create the most harm to the organization and those who depend on it.

A smart place to begin the process to find and evaluate the measurements that an institution uses to monitor those processes.

Healthcare providers: Start with the quality and safety measurements which must be submitted to various regulatory agencies in order to maintain licenses to operate.

• Health insurers: Look at the performance improvement metrics used to ensure subscriber benefits, quality requirements, and legal mandates are being met.
• Health IT services: Use service level agreements for measuring contract compliance with things like uptime, recovery time and point objectives, and response turnarounds.
• Life sciences organizations: Begin with the relevant Good Practice definitions and the metrics used to monitor quality and safety levels of products and services.

When analyzing the types of technology unique to healthcare – like network-connected medical devices such as infusion pumps, implantable pacemakers, ventilators, EKG equipment, and MRI machines – it’s important to ask what are the immediate safety hazards if there was a cyberattack. Not sure how to answer that question? The International Medical Device Regulators Forum produced a risk categorization model that could be helpful in framing that response. Operational technology, like blood bank and sample refrigerators, climate control, air handling, infection control and pneumatic tube systems, may also be used to identify and prioritize inventory efforts.

Once priorities have been set, teams can begin gathering data on critical services, the owners of those services, the systems those owners rely on, and the technology itself.

Inventory tactics on Google Cloud

Building service-technology mapping is not a one-time exercise. Organizations should take the time to automate inventory creation and maintenance, so they can maintain an up-to-date view of all the items in their environment at any given time. This is especially for organizations that have highly dynamic environments.

Google Cloud provides best practices on discovering and cataloging assets in its Cloud Architecture Center. Implement controls found in the Identity and Protect categories using the NIST Framework & Google Cloud technical paper. Automation is your friend when building and maintaining a complete and accurate inventory. Google Cloud Asset Inventory and Security Command Center can be used to inventory a variety of resources running in Google Cloud. Cloud Build, Google Cloud’s CI/CD platform, implements SLSA 1 and provides a trustworthy audit of software artifacts deployed through a managed pipeline. Cloud DLP inventories and labels data stored on Google Cloud Storage and services like BigQuery.

Meanwhile, a number of Google Cloud Marketplace partners have solutions that can help build a comprehensive inventory, and innovation continues to improve our technological options. One emerging field of security technology, called attack surface management, helps discover previously-unknown assets. Finally, our next blog on resilience discusses how to use a software bill of materials (also known by the breezy acronym SBOM) to gain visibility and structural awareness into applications.

It’s important to remember that when starting down this path, the goal is not to gain 100% visibility into every single component on every single device attached to every network supporting every service running. Success or failure is not achieved when the inventory process has reached an arbitrarily-determined ‘percentage complete.’ We want to prioritize expanding visibility and developing structural awareness on assets where safety and quality are at risk, so we can improve their resilience.

And finally, we feel it’s important to emphasize that in the past, healthcare industries have focused mainly on protecting the confidentiality of data. While that’s important, we must evolve security programs beyond protecting confidentiality as its primary (and some cases, only) focus.

To be resilient, we must design and build cybersecurity capabilities that deliver safety, integrity, and availability of the technology that cares for patients directly. As we gain visibility into the technology we depend on to keep us healthy, we improve our understanding about which parts of it we can trust, and which parts we can’t. Improving visibility is an important early step on our path to resilience.