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). …

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.

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? …

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]. …

Sometimes great old blog posts are hard to find (especially on Medium), so I decided to do a periodic (who am I kidding, occasional — not periodic) list blog with my favorite posts of the past quarter or so.

Here is my first. The posts below are ranked by lifetime views and topic. It covers both Anton on Security and my posts from Google Cloud blog.

Top 3 most popular posts of all times:

Security operations / detection &…

Security continues to be a top concern for cloud customers, and therefore continues to be a driver of our business at Google Cloud. However, specific security priorities vary wildly by vertical, by organization size, and by many other factors.

In fact, many “CISO priorities lists” are floating out there online and many people claim to know “what CISOs want.” My analyst years taught me to be skeptical about such claims, if only because there are vast differences between CISOs of different organizations, in terms of security maturity, for example. …

My post “Why is Threat Detection Hard?” proved to be one of the most popular in recent history of my new blog. In this post, I wanted to explore a seemingly obvious, while surprisingly fascinating aspect of detection: uncertainty.

Uncertainty? Are you sure, Anton? :-)

Well, maybe!

Let’s start our journey with exploring the classic fallacy, “if you can detect [the threat], why can’t you prevent it?” Back in 2016, I hit this point really hard here, and notice the first argument I made there. Threat detection, if done well, carries uncertainty, inherently and by design.

OK, you want to argue? Sure! Suppose you are one of those people who only wants to deploy rules / signatures that have exactly ZERO “false positives” hence removing a big chunk of the uncertainty, if not all of it. In some cases, this may be a hangover from having opaque vendor detections where a team couldn’t actually determine the logic of a signature beyond a cryptic string message. …

So, I’ve been doing some blogging at Google Cloud blog with most posts connected to products, launches, etc. However, I am also doing a fun blog series on DLP in the cloud. Blog 1 is here, and blog 2 is here — you can also see a long quote from the second one below.

Note that our DLP (called Cloud DLP because we loooove creative product names here) can do a lot of very cool “tricks” related to data transformation, data de-identification and even re-identification risk analysis (due to its privacy origins). These cool capabilities will be covered in the next blogs in the series, because, frankly, they are quite magical and deserve to be more known and used. …

While creating a recent presentation, I needed a slide on “threat detection is hard.” And it got me thinking, why is threat detection so hard for so many organizations today? We can trace the “cyber” threat detection to 1986 (“Cuckoo’s Egg”) and 1987 (first IDS) and perhaps even earlier events (like viruses of the early 1980s). This means we are “celebrating” ~35 years of cyber threat detection.

However, many organizations would gladly tell you today, in 2020, that “detection is hard” for them. But why? Naturally, I posted my draft slide on Twitter and lively discussion ensued.

As I result, I updated my slide to…

My old $employer blog has vanished and a lot of content of value to the community went down with it. Naturally, I do not own the IP and I cannot go to archive.org and bring it back to life.

However, I will make an exception for this post. Because it (and this is my ego talking, natch) exudes pure awesomeness!

— — — — — — — — — start repost — — — — — — — — -

About a year ago, I crowdsourced a collection of best/worst tips for Vendor Briefings (a one hour presentations from a technology vendor to a Gartner analyst) from other analysts, and now I finally found time to blog it, thanks for some motivation from the Twitterverse. …


Anton Chuvakin

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store