Role of Context in Threat Detection

I got into a very insightful debate with somebody who will remain nameless in the beginning of this post, but will perhaps be revealed…

---

I got into a very insightful debate with somebody who will remain nameless in the beginning of this post, but will perhaps be revealed later. The debate focused on the role of context in threat detection.

Specifically, it is about the role of local context (environment knowledge, organization context, site details, etc) in threat detection. Can threat detection work well without such local context?

Now, some of you will say “yes, of course!” and will point at “success” (well, let’s not get into a fight over this) of anti-malware technology. After all, anti-malware tools promise to detect malware using vendor-created signatures that operate without any input from the customer about their environment (as a minor sidenote, if you “tune” AV then you do introduce that very local context). Note that for this discussion it does not matter that anti-malware will detect and then block (“prevent”) the threat (in other discussions, it definitely does).

The same line of thinking then affected intrusion detection as it was developing in the late 1990s. Intrusion detection systems (IDS) that had lots of signatures and so could detect something out of the box were “successful” (at least as a business) while those that expected customers to write signatures failed or had to evolve.

Then it was SIEM’s turn: SIEM vendors with lots of rules and reports were more successful (and now we have SOC Prime with lots of community rules). Next, it was security analytics tool sets with their “trained ML unicorns”: those with lots of pre-tuned algorithms seemed to be selling better. See the pattern yet? It seems like you can be successful with threat detection without any input from each specific client.

Now, let’s pause and think for a second! What if the industry was … well … if not wrong, but also not entirely right. What if truly successful threat detection must be a collaboration between the vendor and the customer?

In fact, it is easy to find examples of where canned and context-less threat detection does not work all that well. For this, let’s review how successful the detection technologies really are in regards to their use of local context data.

• Anti-malware mostly works (when it does) yet the ransomware epidemic continues and top-tier state-sponsored/-affiliated malware is almost never detected by traditional anti-malware tools. Along the same line, many initial loaders (that you may call “commodity”) aren’t well detected either, and it’s easier to obtain access to these as malicious tools than ever before. Finally, when used in large enterprises, AV is often tuned hence this local knowledge is in fact introduced.
• Network IDS and related technologies (like NDR) don’t really work or don’t work well without local context; at the very least, you will need to “tune” (i.e. add local context like “ignore this server, it always triggers that in legitimate traffic”). Untuned NIDS has long been a subject of many jokes, dating back to the 1990s, if not the 1980s.
• SIEM mostly does not work without a lot of local context, vendor-written SIEM rules never became “shoot and forget”, and you need to tweak them based on your environment and/or write your own rules. This is accepted by most sane SIEM vendors and customers.
• EDR would be a mixed bag, in this regard. Many EDR rules are naive pattern matching. Take a powershell execution with specific command line parameters. A rule may be tuned from 22,000 results all the way down to 17 because (say) PowerShell gets executed in a “suspicious” way all the time and local context (whitelist for system, process, application, etc) is needed. With ML-based EDR, the situation is … as far as I see… the same. Anomalies detected need local context to mean something.

(note that for attackers armed with “living off the land” techniques, the balance skews even further towards local context criticality for detection)

So, what can we learn from this? Threat detection today needs local context a lot more than people realize. Now, successful threat detection programs at elite enterprises, especially those that follow the “detection engineering” model all know this (this is why most/all of their detection logic is custom or customized, not OOB). But are they a rare exception rather than a trend?

And what does it mean for others? Well, you can hire “help” which here means an MSSP or an MDR (BTW, MDR label was born out of frustration with some MSSP threat detection offerings, so YMMV). However, please don’t automatically assume that “using an MSSP means that your local realities will be included in the detection process.” They will be — with quality MDRs and MSSPs, but you may also get canned off-the-shelf SIEM or even IDS alerts from some providers. You may need a combination of tools, services and — yes, still! — your own efforts.

Finally, this is where an ML unicorn will again emerge out of the bushes (or wherever they live…) and say “but we can just auto-learn local realities using my little machine brain.” And, presumably, “auto-learn” here will not mean “import from customer repository” (because many organizations simply lack such a thing, like they lack a current and correct list of assets). Well, can it happen? Sure, it can. In theory. Personally, it is easy for me to believe that it can happen, but I will also be the first to admit that I’ve never actually seen it happen … yet.

So, to summarize, we all need to think ….

• How well does threat detection really work without local context?
• How to best include local context in various detection tools and practices?
• How to select the vendor who will detect WITH you?
• How to practice detection jointly with the vendor or service provider rather than merely “consume” it?

P.S. Huge thanks to Brandon Levene for an idea for this post, for some of the examples and for a great discussion that almost became an argument :-)

P.P.S. I think this situation does not really change in the cloud; you need local cloud context to detect.

Related blog posts:

• “Why is Threat Detection Hard?”
• “Detection Coverage and Detection-in-Depth”
• “Can We Have “Detection as Code”?”
• “Chronicle Detect is Here”

---

Originally published at Medium.

New Paper: “Future of the SOC: SOC People — Skills, Not Tiers”

Back in August, we released our first Google/Chronicle — Deloitte Security Operations Center (SOC) paper titled “Future of the SOC: Forces…

---

Back in August, we released our first Google/Chronicle — Deloitte Security Operations Center (SOC) paper titled “Future of the SOC: Forces shaping modern security operations” (launch blog, paper PDF) and promised a series of three more papers covering SOC people, process and technology.

Here is the next paper “Future of the SOC: SOC People — Skills, Not Tiers” (PDF) and you can easily guess it focuses on the PEOPLE aspect of the SOC. As I often said, “A SOC is first a team, all the other stuff comes later” (or something like that).

My favorite quotes are below:

• “The genealogy of today’s [i.e. NOT the future SOC we are writing about — A.C.] SOC workforce model stems from the IT help desk. This approach originated from the application of the hierarchical industrial-age assembly line: passing issues from first to second line and further up. In simpler times, this model was sufficient — technology density was low and problems could be solved with in-person interactions, all at a minimal cost.” — overall, we now feel that IT helpdesk roots constrain the modern/future SOC and send its development in potentially wrong directions.
• ”A workforce model fit for an entirely different purpose may serve as a useful analog: the Special Forces Operational Detachment Alpha, also known as the “A Team.” As the primary operational element of a larger organization, this small team is composed of individuals with all the necessary skills to complete virtually any tactical operation autonomously.” — and if you want a more peaceful analogy, think QA [find and fix bugs], not helpdesk [wait for issues and handle them].

Example SOC skills

• “Another principle that works for large organizations is outsource capacity, but not capability. This relies on the fact that to outsource a function well, a degree of internal expertise is required to judge a provider, both in the beginning and over time. Hence, to outsource well, you need to have at least some expertise in the area” — you’ve seen me talk about it, and this is tricky in real life; to select a good partner for MSSP/MDR, you need enough knowledge to tell good from bad. Also, expect the SOC of the future to use some services for some things; “every SOC is a hybrid SOC.”
• ”SOCs can no longer pair every event with a human analyst. The model simply does not scale to today’s business, IT, and threats. This means automation and outsourcing, but it also means a different skill model, rather than a hierarchical pyramid of the past” — this is a bit meta and not terribly actionable, but I assure you — this is useful.
• “Unlike widgets on the production line, security events should be considered as part of contextual fabric. This implies that a naive per alert model is broken as well, just as the “SOC as a funnel” model” — remember that the SOC mission is threats, not alerts! To fix this, approach early alert triage differently (rather than “easy? fix. hard? punt!” of helpdesk)

Now, go and read the full paper “Future of the SOC: SOC People — Skills, Not Tiers” (PDF).

Two more SOC papers are coming, one on processes (we are writing this one now and it will be very fun!) and one on technology inside and around the modern SOC.

---

Originally published at Medium.

Cloud Migration Security Woes

As I hear of organizations dealing with security when migrating to the cloud, I occasionally observe cases of “extreme lift and shift.” I…

---

As I hear of organizations dealing with security when migrating to the cloud, I occasionally observe cases of “extreme lift and shift.” I use this label to describe a case when an organization wants to keep every single security technology that they use on-premise after they move to the public cloud. The list can be very long and tedious; it may include such staples as firewalls, anti-malware, SIEM, EDR, NIDS, and even network forensics and NDR.

Let’s ponder this situation without judgement. Two things come to mind first:

1. Focusing on controls vs control intent
2. Adapting to threat model changes

First, why are existing controls being replicated verbatim if there are cloud-style controls available from your cloud provider or from a cloud-focused third party vendor? Won’t you be better off if you “deduce” (or: find the documentation for) the intent of the existing controls and then deploy cloud controls that serve the same intent? “Better” here may mean both more effective, less expensive (!) and likely more secure. For example, you may have used a security configuration scanner on-premise, but now you can use the tools your cloud provider has for the same purpose?

Second, why are the same controls even considered if the threat model may be different? Assuming your on-premise controls served your compliance, security and risks perfectly (it IS possible, no?), why do you then assume that your requirements are the same in the cloud? In fact, you have robust evidence that they are not! Here is a trivial example: physical security is well taken care of so some threats are clearly gone from your model. There are in fact both added and removed threats. In theory, you now have a new class of insider threat. And you have a broad range of threats that either become irrelevant or are effectively addressed by the provider.

So.

Mini-conclusions / actions:

• When migrating to the public cloud, look at how your threats change as a result (this came out as “duh!” advice, but it seems needed nonetheless …)
• When reviewing your existing security controls before migration, look at their intent and then (if the changed threats above make this intent still relevant) consider cloud-focused/cloud-native controls to address the same intent.
• To do the above well, you do need to spend a bit of time learning about the cloud-native security controls (example)
• Don’t just copy/paste security stuff from the data center world to the cloud world!

P.S. Well, this came out more of an incomplete thought (because, frankly, there is a lot more security choices when migrating), but I feel that these two deserve a lot of attention.

Related blog posts:

• “Move to Cloud: A Chance to Finally Transform Security?”

---

Originally published at Medium.

Cloud Migration Security Woes

As I hear of organizations dealing with security when migrating to the cloud, I occasionally observe cases of “extreme lift and shift.” I…

---

As I hear of organizations dealing with security when migrating to the cloud, I occasionally observe cases of “extreme lift and shift.” I use this label to describe a case when an organization wants to keep every single security technology that they use on-premise after they move to the public cloud. The list can be very long and tedious; it may include such staples as firewalls, anti-malware, SIEM, EDR, NIDS, and even network forensics and NDR.

Let’s ponder this situation without judgement. Two things come to mind first:

1. Focusing on controls vs control intent
2. Adapting to threat model changes

First, why are existing controls being replicated verbatim if there are cloud-style controls available from your cloud provider or from a cloud-focused third party vendor? Won’t you be better off if you “deduce” (or: find the documentation for) the intent of the existing controls and then deploy cloud controls that serve the same intent? “Better” here may mean both more effective, less expensive (!) and likely more secure. For example, you may have used a security configuration scanner on-premise, but now you can use the tools your cloud provider has for the same purpose?

Second, why are the same controls even considered if the threat model may be different? Assuming your on-premise controls served your compliance, security and risks perfectly (it IS possible, no?), why do you then assume that your requirements are the same in the cloud? In fact, you have robust evidence that they are not! Here is a trivial example: physical security is well taken care of so some threats are clearly gone from your model. There are in fact both added and removed threats. In theory, you now have a new class of insider threat. And you have a broad range of threats that either become irrelevant or are effectively addressed by the provider.

So.

Mini-conclusions / actions:

• When migrating to the public cloud, look at how your threats change as a result (this came out as “duh!” advice, but it seems needed nonetheless …)
• When reviewing your existing security controls before migration, look at their intent and then (if the changed threats above make this intent still relevant) consider cloud-focused/cloud-native controls to address the same intent.
• To do the above well, you do need to spend a bit of time learning about the cloud-native security controls (example)
• Don’t just copy/paste security stuff from the data center world to the cloud world!

P.S. Well, this came out more of an incomplete thought (because, frankly, there is a lot more security choices when migrating), but I feel that these two deserve a lot of attention.

Related blog posts:

• “Move to Cloud: A Chance to Finally Transform Security?”

---

Originally published at Medium.

Usage Scenarios for Externalized Trust

As we discussed in “The Cloud trust paradox: To trust cloud computing more, you need the ability to trust it less”, there are situations…

---

As we discussed in “The Cloud trust paradox: To trust cloud computing more, you need the ability to trust it less”, there are situations where the encryption key really does belong off the cloud and so trust is externalized. While we argue that these are rarer than some assume, they absolutely do exist. Moreover, when these situations materialize, the data in question or the problem being solved is typically hugely important for an organization.

Here are three critical scenarios where keeping the keys off the cloud may in fact be truly necessary [and possible with Hold Your Own Key (HYOK) approach implemented via Google EKM].

Scenario 1 The Last Data to Go Up

As organizations migrate data processing workloads to the cloud, there usually is this pool of data that just cannot go. It may be the most sensitive, strictly regulated or the one with the toughest internal security control requirements.

This means that risk, compliance or policy reasons make it difficult if not impossible to send this data set to the public cloud provider for storage or processing. This use case often applies to a large organization that is heavily regulated (financial, healthcare and manufacturing come to mind). It may be the data about specific “priority” patients or data related to financial transactions of a specific kind.

However, the organization may be willing to migrate this data set to the cloud as long as it is encrypted and they have sole possession of the encryption keys. Thus, a specific decision to migrate may be made involving a combination of risk, trust, as well as auditor input. Or, customer key possession may be justified by customer interpretation of specific compliance mandates.

Examples of such highly sensitive data vary by industry and even by company. One organization may want to keep the keys that decrypt the credit card data, while others deal with citizen data, banking data or other sensitive personal information. Another organization may be driven by their interpretation of PCI DSS and internal requirements to maintain control of their own master keys in FIPS 140–2 level 3 HSMs that they own and operate for their cloud workloads.

Now, some of you may say “but we have the data that really should not go to the cloud.” I don’t want to use an analogy of horses vs cars (“but we have some people who prefer to ride a horse and will never use a car” may have worked in the 1920s), but the acceptance that digital transformation projects require the agility of the cloud powered by cloud practices and technologies is there to stay.

Scenario 2 Regional Regulations and Concerns

As cloud computing evolves, regional requirements start to play a larger role in how organizations migrate to the cloud and operate workloads in public cloud. This scenario focuses on a situation where an organization outside of the US wants to use a US cloud (because, frankly, there is no other kind), but is not comfortable with the provider having access to encryption keys for all data. Some of them may be equally uncomfortable with keys stored in any cryptographic device (such as an HSM) under logical or physical control of the cloud provider. They reasonably conclude that such an approach is not really HYOK.

This may be due to trust issues with the provider, regulations they are subject to, their government or all of the above. Furthermore, regulators in Europe, Japan, India, Brazil and other countries are creating or strengthening mandates for keeping unencrypted data and/or encryption keys within their boundaries. However, preliminary data indicates that some may accept the models where the encryption keys are in a sole possession of a customer and located in their country, and hence off the cloud provider premises (while the encrypted data is in the US)

As Thomas Kurian said here, “data sovereignty provides customers with a mechanism to prevent the provider from accessing their data, approving access only for specific provider behaviors that customers think are necessary. Examples of customer controls provided by Google Cloud include storing and managing encryption keys outside the cloud, giving customers the power to only grant access to these keys based on detailed access justifications, and protecting data-in-use. With these capabilities, the customer is the ultimate arbiter of access to their data. “

Examples may include specific industry mandates (such as TISAX in Europe) that either state or imply that the cloud provider cannot have access to data under any circumstances, that may necessitate not having any way for them to access the encryption keys.

Another variation is the desire to have the keys for each country specific data set in the respective country under the control of that country’s personnel. This may apply to banking data and will necessitate the encryption keys for each data set being stored in each country. A hypothetical example may be a bank that insists that all their encryption keys are stored under one mountain in Switzerland …

Yet another example covers the requirements (whether regulatory or internal) to have complete knowledge and control over the administrators of the keys, and a local audit log of all key access activity.

Scenario 3 Centralized Encryption Key Control

With this use case there is no esoteric threats to discuss or obscure audit requirements to handle. The focus here is on operational efficiency. As Gartner recently noted, the need to reduce the number of key management tools is a strong motivation for this.

It may sound like a cliche, but complexity is very much the enemy of security. Multiple presumably “centralized” systems for any task — be it log management or encryption key management — add to complexity burden and introduce new points for security to break and fall through the cracks.

In light of this, a desire to use one system for a majority of encryption keys, cloud or not, is understandable. Additional benefits may stem from using the same key management vendor as an auxiliary access control and policy point. A common set of keys reduces complexity and a properly implemented system with adequate security and redundancy outweighs the need to have multiple systems.

Another variant of this is a motivation to retain control over data processing by means of controlling the encryption key access. After all, if a client can push the button and instantly cut off the cloud provider from key access, the data cannot possibly be accessed or stolen by anybody else. Thus, centralization of their key management gives the cloud user a central location to enforce policies around access to keys and hence access to data-at-rest.

Conclusion

These scenarios truly call for encryption keys being both physically away from the cloud provider and away from their administrative control. This means that a customer-managed HSM device at the CSP location won’t do here.

• Read “The Cloud trust paradox: To trust cloud computing more, you need the ability to trust it less”
• If you are planning to keep encryption keys off the cloud, review the scenarios covered here. Do you have these or perhaps another one?
• Assess your data risks towards attackers, regulations, etc. Do threat modelling focused on your cloud data processing and see if you truly need to remove the keys from the cloud.
• Review services covered by Google EKM and partners to deliver KMS on-premise for keeping the keys

---

Originally published at Medium.