Track metrics and stay focused on threats: Achieving Autonomic Security Operations
2837
Of your peers have already read this article.
2:30 Minutes
The most insightful time you'll spend today!
What’s the most difficult question a security operations team can face? For some, is it, “Who is trying to attacks us?” Or perhaps, “Which cyberattacks can we detect?” How do teams know when they have enough information to make the “right” decision? Metrics can help inform our responses to those questions and more, but how can we tell which metrics are the best ones to rely on during mission-critical or business-critical crises?
As we discussed in our blogs, “Achieving Autonomic Security Operations: Reducing toil” and “Achieving Autonomic Security Operations: Automation as a Force Multiplier,” your Security Operations Center (SOC) can learn a lot from what IT operations discovered during the Site Reliability Engineering (SRE) revolution. In this post, we discuss how those lessons apply to your SOC, and center them on another SRE principle—Service Level Objectives (SLOs).
Even though industry definitions can vary for these terms, SLI, SLO, and SLA have specific meanings, wrote the authors of the Service Level Objectives chapter in our e-book, “Site Reliability Engineering: How Google runs production systems.” (All subsequent quotes come from the SLO chapter of the book, which we’ll refer to as the “SRE book.”)
- SLI: “An SLI is a service level indicator—a carefully defined quantitative measure of some aspect of the level of service that is provided.”
- SLO: “An SLO is a service level objective: a target value or range of values for a service level that is measured by an SLI.”
- SLA: An SLA is a Service Level Agreement about the above: “an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain.”
In practice, we measure something (SLI) and we set the target value (SLO); we may also have an agreement about it (SLA).
This is not about cliches like “what gets measured gets done” here, but metrics and SLIs/SLOs will to a large extent determine the fate of your SOC. For example, SOCs (including at some Managed Security Service Providers) that obsessively focus on “time to address the alert” end up reducing their security effectiveness while making things go “whoosh” fast. If you equate mean time to detect or discover (MTTD) with “time to address the alert” and then push the analyst to shorten this time, attackers gain an advantage while defenders miss things and lose.
How to choose which metrics to track
One view of metrics would be that “whatever sounds bad” (such as attacks per second or incidents per employee) needs to be minimized, while “whatever sounds good” (such as successes, reliability, or uptime) needs to be maximized.
But the SRE experience is that sometimes good metrics have an optimum level, and yes, even reliability (and maybe even security). The book’s authors, Chris Jones, John Wilkes, and Niall Murphy with Cody Smith, cite an example of a service that defied common wisdom and was too reliable.
“Its high reliability provided a false sense of security because the services could not function appropriately when the service was unavailable, however rarely that occurred… SRE makes sure that global service meets, but does not significantly exceed, its service level objective,” they wrote.
The SOC lesson here is that some security metrics have optimum value. The above-mentioned time to detect has an optimum for your organization. Another example is the number of phishing incidents, which may in fact have an optimum value. If nobody phishes you, it’s probably because they already have credentialed access to many of your systems – so in your SOC, think of SLI optimums, and don’t automatically assume zero or infinite targets for metrics.
Three specific quotes from the SRE book remind us that “good metrics” may need to be balanced with other metrics, rather than blindly pushed up:
- “User-facing serving systems generally care about availability, latency, and throughput.”
- “Storage systems often emphasize latency, availability, and durability.”
- “Big data systems, such as data processing pipelines, tend to care about throughput and end-to-end latency.”
In a SOC, this may mean that you can detect threats quickly, review all context related to an incident, and perform deep threat research—but the results may differ for various threats. A fourth guidepost explains why your SOC should care even about this: “Whether or not a particular service has an SLA, it’s valuable to define SLIs and SLOs and use them to manage the service.” Indeed, we agree that SLIs and SLOs matter more for your SOC than any SLAs or other agreements.
Metrics matter, but so does flexibility
When considering the list of most difficult questions a security operations team can face, it’s vital to understand how to evaluate metrics to reach accurate answers. Consider another insight from the book: “Most metrics are better thought of as distributions rather than averages.”
If the average alert response is 20 minutes, does that mean that “all alerts are addressed in 18 to 22 minutes,” or that “all alerts are addressed in five minutes, while one alert is addressed in six hours?” Those different answers point to very different operational environments.
What we’ve seen before in SOCs is that a single outlier event is probably the one that matters most. As the authors put it, “The higher the variance in response times, the more the typical user experience is affected by long-tail behavior.” So, in security land, that one alert that took six hours to respond to was likely related to the most dangerous activity detected.
To address this, the book advises, “Using percentiles for indicators allows you to consider the shape of the distribution.” Google detection teams track the 5% and 95% values, not just averages.
Another useful concept from SRE is the “error budget,” a rate at which the SLOs can be missed, and tracked on a daily or weekly basis. It’s a SLO for meeting other SLOs.
The SOC value here may not be immediately obvious, but it’s vital to understanding the unique role security occupies in technology. In security, metrics can be a distraction because the real game is about preventing the threat actor from achieving their objectives. Based on our own experiences, most blue teams would rather miss the SLO and catch the threat in their environment. The defenders win when the attacker loses, not when the defenders “comply with a SLA.” The concept of the error budget might be your best friend here.
The SRE book takes that line of thinking even further. “It’s both unrealistic and undesirable to insist that SLOs will be met 100% of the time: doing so can reduce the rate of innovation and deployment.”
More broadly, and as we said in our recent paper with Deloitte on SOCs, rigid obeisance is its own vulnerability to exploit. “This adherence to process and lack of ability for the SOC to think critically and creativity provides potential attackers with another opportunity to successfully exploit a vulnerability within the environment, no matter how well planned the supporting processes are.”
To be successful at defending their organizations, SOCs must be less like the unbending oak and more like the pliant but resilient willow.
Track metrics but stay focused on threats
A third interesting puzzle from our SRE brethren: “Don’t pick a target based on current performance.”
We all want to get better at what we do, so choosing a target goal for improvement based on our existing performance can’t be bad, right? It turns out, however, that choosing a goal that sets up unrealistic or otherwise unhelpful, or woefully insufficient, expectations can do more harm than good.
Here is an example: An analyst handles 30 alerts a day (per their SLI), and their manager wants to improve by 15% so they set the SLO to 35 alerts a day. But how many alerts are there? Leaving aside the question of whether it is the right SLI for your SOC, what if you have 5,000 alerts, and you drop 4,970 of them on the floor. When you “improve,” you still drop 4,965 on the floor. Is this a good SLO? No, you need to hire, automate, filter, tune, or change other things in your SOC, not set better SLO targets that seemingly improve upon today’s numbers.
To this, our SRE peers say: “As a result, we’ve sometimes found that working from desired objectives backward to specific indicators works better than choosing indicators and then coming up with targets… Start by thinking about (or finding out!) what your users care about, not what you can measure.”
In the SOC, this probably means start with threat models and use cases, not the current alert pipeline performance.
SOC guidance can sometimes be more cryptic than we’ve let on. One challenging question is determining how many metrics we really need in a typical SOC. SREs wax philosophical here: “Choose just enough SLOs to provide good coverage of your system’s attributes.”
In our experience, we haven’t seen teams succeed with more than 10 metrics, and we haven’t seen people describe and optimize SOC performance with fewer than 3. However, SREs offer a helpful, succinct test: “If you can’t ever win a conversation about priorities by quoting a particular SLO, it’s probably not worth having that SLO.”
SLOs will get to define your SOC, so define them the way you want your SOC to be, the book advises. “It’s better to start with a loose target that you tighten than to choose an overly strict target that has to be relaxed when you discover it’s unattainable. SLOs can—and should—be a major driver in prioritizing work for SREs and product developers, because they reflect what users care about.”
Importantly, make SLOs for your SOC transparent within the company. As the SREs say, “Publishing SLOs sets expectations for system behavior.” The benefit is that nobody can blame you for non-performance if you perform to those agreed upon SLOs.
Finally, here are some examples of metrics from our teams at Google. In addition to reviewing all escalated alerts, they collect and review weekly:
- event volume
- event source counts
- pipeline latency
- triage time median
- triage time at 95%
Analyzing these metrics can reveal useful guidance for applying SRE principles and ideas with their detection and response teams.
Event volume: What we need to know here is what is driving the volume. Is the event volume normal, high, or low—and why? Was there a flood of messages? New data source causing high volume? What caused it? Any bad signals? Or is there a problematic area of the business that needs strategic follow-up to implement additional controls?
Event source count: Are there signals or automation that’s behaving abnormally? Is there new automation that’s misbehaving? Counting events for each source call makes for a decent SLI.
Pipeline latency: Here at Google, we aim for a confirmed detection within an hour of an event being generated. The aspirational time is 5 minutes. This means that the event pipeline latency is something that must be tracked very diligently. This also means that we must scrutinize automation latency. To achieve this, we try to remove self-caused latency so that we’re not hiding the pain of bad signals or bad automation.
We triage median and 95p time: We track the response time to events. As the SRE book points out, tracking only a single average number can get you in trouble very quickly. Note that triage time is not the same as time to resolution, but more of a dwell time for an attacker before they are discovered.
Incident resolution times: When you have a SLI but not a SLO, this can be the proverbial elephant in the room and create all sorts of bad incentives to “go fast” instead of “go good.” Specifically, SLO without SLI causes harm from encouraging the analysis to resolve quickly and potentially increase the risk of missing serious security incidents, especially when subtle signals are involved.
When reviewing alert escalations, we look to determine if the analysis is deep enough, if handoffs contain the right information for our response teams, and to get a sense of analyst fatigue. If analysts are phoning in their notes, it’s a sign that they’re over a particular signal or that there are a ton of duplicate incidents and we need to drive the business in some way.
By measuring these and other factors, metrics allow us to drive down the cost of each detection. Ultimately, this can help our detection and response operation scale faster than the threats.
Related posts:
- “Achieving Autonomic Security Operations: Automation as a Force Multiplier”
- “Achieving Autonomic Security Operations: Reducing toil”
- “Taking an autonomic approach to security operations” video
- “New Paper: “Future Of The SOC: Process Consistency and Creativity: a Delicate Balance” (Paper 3 of 4)”
- “New Paper: “Autonomic Security Operations — 10X Transformation of the Security Operations Center””
- “EP75 How We Scale Detection and Response at Google: Automation, Metrics, Toil” podcast episode
Register to Watch July’s Security Summit
2913
Of your peers have already read this article.
1:30 Minutes
The most insightful time you'll spend today!
Together we can solve for the future of cloud security. Join us to learn how you can stay ahead of the next generation of threats with Google Cloud – whether you need to keep your organization secure in the cloud, on-premises, or in a hybrid environment. Get fresh insights from industry leaders and engage in interactive sessions that can help you solve your most critical security challenges.
Our digital event has ended, but you can still explore our sessions on demand.
The Security Summit is part of our digital Google Cloud Summit series. Check out the other events in the series to explore Google Cloud technology applications in various industries and dive into our latest digital innovations.Original air date:20 July 2021 21:30 Register to watch on demand.
Introducing New Capabilities for Secure Transformations
2751
Of your peers have already read this article.
2:30 Minutes
The most insightful time you'll spend today!
Organizations large and small are realizing that digital transformation and the changing threat landscape require a grounds up effort to transform security. At Google Cloud, we continue to invest in our vision of invisible security where advanced capabilities are engineered into our platforms, operations are simplified, and stronger security outcomes can be achieved.
We made five major security announcements at Google Cloud Next:
- Introducing Chronicle Security Operations, to help detect, investigate, and respond to cyberthreats with the speed, scale, and intelligence of Google
- Introducing Confidential Space, to help unlock the value of secure data collaboration
- Advancing digital sovereignty on Europe’s terms, to address growing demand for cloud solutions with high levels of control, transparency, and sovereignty
- Introducing Software Delivery Shield, to help improve software supply chain security
- New and expanded Google Cloud partnerships with leaders across the security ecosystem
Today at Next ‘22, we’re introducing additional new security products, partnerships, and solutions across security analytics, anti-fraud measures, device security, Zero Trust, and open source software security to help our customers around the world address their most pressing security challenges.
Our Assured Open Source Software service, which we announced earlier this year, is now available in Preview. Assured OSS enables enterprise and public sector users of open source software to easily incorporate the same trusted OSS packages that Google uses into their own developer workflows. You can sign up for the Preview of Assured OSS here.
Security teams must continually measure and manage risk in their cloud environments. Earlier this year we acquired Foreseeti, a startup focused on attack simulation and risk quantification. We’re excited to announce that the integration of Foreseeti’s groundbreaking technology, which can help teams understand their exposure and prioritize contextualized vulnerability findings, will be coming to Security Command Center in Preview in Q4. Security Command Center will use Forseeti’s advanced attack path simulations to help you apply targeted remediations before attackers can take advantage of high-risk vulnerabilities.
To help organizations better manage risks in their online channels, reCAPTCHA Enterprise and Signifyd will partner to bring to market a joint anti-fraud and abuse solution. This solution will combine the behavioral analysis capabilities of reCAPTCHA Enterprise with the anti-fraud capabilities of Signifyd to help enterprises reduce abuse, account takeovers, and payment fraud.
We continue to invest in new initiatives with our BeyondCorp Alliance partners. Palo Alto Networks customers can now pair Prisma Access with BeyondCorp Enterprise Essentials to help secure private and SaaS app access while mitigating internet threats across managed and unmanaged devices with a secure enterprise browsing experience.
We now package best practices and implementation experience for our customers in Zero Trust Advisory solutions. Our Cybersecurity Action Team and select partners can help guide you through the Zero Trust journey with exploratory workshops, architecture reviews, customized recommendations, and implementation support.
Google Cloud Armor, which was instrumental in stopping the largest Layer 7 DDoS attack to date, was named a Strong Performer in The Forrester Wave™: Web Application Firewalls, Q3 2022. This is our debut in the WAF Wave, and it’s encouraging to see the recognition for the product in this market segment.
Google Workspace has received several security updates and advances. They bring data loss prevention (DLP) to Google Chat to help prevent sensitive information leaks, new Trust rules for Google Drive for more granular control of internal and external sharing, and Client-side encryption (CSE) in Gmail and Google Calendar to help address a broad range of data sovereignty and compliance requirements. You can learn more in our Workspace blog.
Learn more at Google Cloud Next
Our growing team at Google Cloud Security remains focused on delivering solutions that can make governments and enterprises safer with Google, in our trusted cloud and through products that bring our security capabilities to on-premises environments and other clouds. Learn more about these announcements and capabilities by attending the Security sessions at Google Cloud Next all this week and on-demand soon after.
Quick Recap on Google Cloud: Latest News, Launches, Updates, Events and More
12916
Of your peers have already read this article.
2:00 Minutes
The most insightful time you'll spend today!
Want to know the latest from Google Cloud? Find it here in one handy location. Check back regularly for our newest updates, announcements, resources, events, learning opportunities, and more.
Tip: Not sure where to find what you’re looking for on the Google Cloud blog? Start here: Google Cloud blog 101: Full list of topics, links, and resources.
Week of May 24-May 28 2021
- Google Cloud for financial services: driving your transformation cloud journey–As we welcome the industry to our Financial Services Summit, we’re sharing more on how Google Cloud accelerates a financial organization’s digital transformation through app and infrastructure modernization, data democratization, people connections, and trusted transactions. Read more or watch the summit on demand.
- Introducing Datashare solution for financial services–We announced the general availability of Datashare for financial services, a new Google Cloud solution that brings together the entire capital markets ecosystem—data publishers and data consumers—to exchange market data securely and easily. Read more.
- Announcing Datastream in Preview–Datastream, a serverless change data capture (CDC) and replication service, allows enterprises to synchronize data across heterogeneous databases, storage systems, and applications reliably and with minimal latency to support real-time analytics, database replication, and event-driven architectures. Read more.
- Introducing Dataplex: An intelligent data fabric for analytics at scale–Dataplex provides a way to centrally manage, monitor, and govern your data across data lakes, data warehouses and data marts, and make this data securely accessible to a variety of analytics and data science tools. Read more.
- Announcing Dataflow Prime–Available in Preview in Q3 2021, Dataflow Prime is a new platform based on a serverless, no-ops, auto-tuning architecture built to bring unparalleled resource utilization and radical operational simplicity to big data processing. Dataflow Prime builds on Dataflow and brings new user benefits with innovations in resource utilization and distributed diagnostics. The new capabilities in Dataflow significantly reduce the time spent on infrastructure sizing and tuning tasks, as well as time spent diagnosing data freshness problems. Read more.
- Secure and scalable sharing for data and analytics with Analytics Hub–With Analytics Hub, available in Preview in Q3, organizations get a rich data ecosystem by publishing and subscribing to analytics-ready datasets; control and monitoring over how their data is being used; a self-service way to access valuable and trusted data assets; and an easy way to monetize their data assets without the overhead of building and managing the infrastructure. Read more.
- Cloud Spanner trims entry cost by 90%–Coming soon to Preview, granular instance sizing in Spanner lets organizations run workloads at as low as 1/10th the cost of regular instances, equating to approximately $65/month. Read more.
- Cloud Bigtable lifts SLA and adds new security features for regulated industries–Bigtable instances with a multi-cluster routing policy across 3 or more regions are now covered by a 99.999% monthly uptime percentage under the new SLA. In addition, new Data Access audit logs can help determine whether sensitive customer information has been accessed in the event of a security incident, and if so, when, and by whom. Read more.
- Build a no-code journaling app–In honor of Mental Health Awareness Month, Google Cloud’s no-code application development platform, AppSheet, demonstrates how you can build a journaling app complete with titles, time stamps, mood entries, and more. Learn how with this blog and video here.
- New features in Security Command Center—On May 24th, Security Command Center Premium launched the general availability of granular access controls at project- and folder-level and Center for Internet Security (CIS) 1.1 benchmarks for Google Cloud Platform Foundation. These new capabilities enable organizations to improve their security posture and efficiently manage risk for their Google Cloud environment. Learn more.
- Simplified API operations with AI–Google Cloud’s API management platform Apigee applies Google’s industry leading ML and AI to your API metadata. Understand how it works with anomaly detection here.
- This week: Data Cloud and Financial Services Summits–Our Google Cloud Summit series begins this week with the Data Cloud Summit on Wednesday May 26 (Global). At this half-day event, you’ll learn how leading companies like PayPal, Workday, Equifax, and many others are driving competitive differentiation using Google Cloud technologies to build their data clouds and transform data into value that drives innovation. The following day, Thursday May 27 (Global & EMEA) at the Financial Services Summit, discover how Google Cloud is helping financial institutions such as PayPal, Global Payments, HSBC, Credit Suisse, AXA Switzerland and more unlock new possibilities and accelerate business through innovation. Read more and explore the entire summit series.
- Announcing the Google for Games Developer Summit 2021 on July 12th-13th–With a surge of new gamers and an increase in time spent playing games in the last year, it’s more important than ever for game developers to delight and engage players. To help developers with this opportunity, the games teams at Google are back to announce the return of the Google for Games Developer Summit 2021 on July 12th-13th. Hear from experts across Google about new game solutions they’re building to make it easier for you to continue creating great games, connecting with players and scaling your business. Registration is free and open to all game developers. Register for the free online event at g.co/gamedevsummit to get more details in the coming weeks. We can’t wait to share our latest innovations with the developer community. Learn more.
AirAsia’s CIO Speaks Up: Why He Decided, What He Did
3322
Of your peers have already read this article.
2:45 Minutes
The most insightful time you'll spend today!
At AirAsia, we operate a fleet of more than 270 aircraft across 23 markets, fly to more than 150 destinations and carry 100m guests each year. We’ve also been named the world’s best low-cost carrier for 11 years running. To accomplish all of this, we rely heavily on our 22,000 Allstars (employees). As AirAsia co-founder Tony Fernandes likes to say, “it has always been about the people.”
With Cloud Identity in place, our IT department can spend less time worrying about managing multiple on-premises directory servers and and can instead focus on delivering value to our Allstar employees.
–Declan Hogan, Group CIO, AirAsia
In my role as CIO, it’s critical that I give our Allstars the tools and technology they need to get their jobs done, while at the same time ensuring that our company’s data is protected and secure. While this is challenging enough in normal circumstances, we’re also in the midst of rapidly moving from legacy on-premises technologies to the cloud. Google Cloud has been a critical partner for us in this journey.
Identity Challenges
AirAsia, like many other enterprises, has relied on a legacy on-premises directory for many years. As our company has quickly grown and expanded to new markets and regions, we’ve had to manage multiple servers across a number of on-premises data centers and the public cloud, which has proved costly and time-consuming.
Our Allstars, located all across Asia, need to easily access a number of legacy on-premises apps in addition to a growing number of SaaS apps. As a business, we also needed a more seamless integration between our HR system of record and our identity solution for user provisioning and lifecycle management.
Deploying Cloud Identity is a key step towards enabling the BeyondCorp (or zero trust) security model, which we feel is the best approach to strengthen our security posture and fight modern threats.
–Declan Hogan, Group CIO, AirAsia
Solving these challenges with our existing on-premises directory was simply not feasible for us.
In recent years, we partnered with Google Cloud to help drive our digital transformation, including moving dozens of workloads and apps to Google Cloud Platform (GCP), deploying G Suite as our collaboration and productivity solution for all of our employees, and replacing thousands of Windows laptops with fast and secure Chromebooks.
We brought up our identity concerns with the Google Cloud team, and after a number of conversations, we decided to deploy Cloud Identity, Google’s cloud-based identity and access management solution, to help address the identity challenges we were facing.
Why Cloud Identity for AirAsia?
We ended up choosing Cloud Identity for a few key reasons. Here at AirAsia, we are eager to move to the cloud as quickly as possible, and moving identity management to the cloud is a key enabler of this and our broader digital transformation. Managing identities from the cloud also enables us to have a single identity and set of credentials for each employee, which they can use to access all of the applications they need to be productive, both in the cloud and on-premises.
In addition, deploying Cloud Identity is a key step towards enabling the BeyondCorp (or zero trust) security model, which we feel is the best approach to strengthen our security posture and fight modern threats.
Cloud Identity also integrates seamlessly with our existing technologies, which includes not only Google Cloud products like GCP, G Suite, and Chrome OS, but also third party tools like Citrix, Papercut, and others.
And finally, Cloud Identity offered us significant cost and resource savings. With Cloud Identity in place, our IT department can spend less time worrying about managing multiple on-premises directory servers and and can instead focus on delivering value to our Allstar employees.
Building Effective Visibility into Technology Assets Used in Healthcare
3177
Of your peers have already read this article.
4:00 Minutes
The most insightful time you'll spend today!
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.
More Relevant Stories for Your Company
AppSheet: Reduce Shadow IT and Accelerate Development of Enterprise-grade Apps
Google Cloud findings suggest that nearly 40 percent of organizations' investments are consumed by shadow IT and can be a detractor to the adoption of cutting-edge tools and solutions. Also, about 51 percent of the surveyed executives are of the opinion that the inability to adapt to digital transformation trends
5 Compelling Ways to Practice the Principle of Least Privilege for Security Leaders
When it comes to security, managing access is a foundational capability—whether you’re talking about a physical space or your cloud infrastructure. If you were securing an office, you wouldn’t give every employee a master key that can open the front door, the mailbox, and the safe. Likewise, when you’re securing
A Security Practitioners Guide to Best Practice GCP Security
Building secure services using GCP is easy, when you know all the tools available to you. Selecting the right services and configurations to meet your security needs requires you to know your tools. In this practical session, you will go beyond the theory, and will go through best practices for
Google Maps Platform Can Elevate FinTech Experience with Less Risks and Higher Security
The financial services industry is changing—an estimated $68 trillion in wealth transferring from baby boomers to millennials.1 This means financial service providers will have to deliver the speed, ease-of-use, technological sophistication, and tailored services that millennials have come to expect. In fact, half of all millennials are willing to switch to
