Well, sort of. Lok at EDR and NDR vendors doing stuff in the cloud? They seem to think they are the answer, no? In essence, to me this really hingers on the question “is cloud different enough?” If somebody from the “cloud is just somebody’s computer” shows up for this discussion, I am pretty sure they’d argue against CDR. Still, I agree that #2 separate capability will be the outcomes, in the next 2–3 years perhaps.
Originally published at Medium.
Indeed, but I don’t think API sec has peaked yet; XDR may have
Originally published at Medium.
Originally written for the new Chronicle blog.
Originally written for the new Chronicle blog.
As security orchestration, automation and response (SOAR) adoption continues at a rapid pace, security operations teams have a greater need for a structured planning approach.
My favorite approach has been a maturity model, vaguely modeled on the CMM approach. For example, in my analyst days, I built a maturity model for a SOC (2018), a SIEM deployment (2018) and vulnerability management (2017).
Guess which one is missing? The one for SOAR! Now, why was it missing? In my estimation, there were too many doors to SOAR to plot a coherent yet universally applicable SOAR maturity model.
But with many Security Operations teams deploying and running SOAR for several years, I sense that a reasonably applicable adoption maturity model can be created. So here is a first attempt at it.
But first, let’s go through a few assumptions:
How do you use this in your environment?
Thanks to Google SOAR Solution Architecture Manager Oleg Siminel, and others from the Siemplify field team, for their support here.
Originally published at Medium.
One of the things I do every year at the RSA conference is to wander the expo halls trying to deduce themes and trends for the industry.
One of the things I do every year at the RSA conference is to wander the expo halls trying to deduce themes and trends for the industry.
Before I go into my specific observations, I wanted to share what impressed me the most this time. My first reaction was the normalcy of it all — it came as a shock as this was my first big event after, well, RSA 2020. It definitely felt like the industry was back, with all its goods and some of its bads. Economic challenges notwithstanding, there was definitely a lot of excitement in the air (not sure that the freshly laid off employees of vendors with huge expensive booths would relate to that however…)
So, what was the theme that came to me as I was wandering the halls? It was the past and the future. What does this mean, specifically?
As I was looking at the security vendors and their technologies, I realized that security vendors that apparently peaked in relevance, say, in the mid-2000s had huge booths and did brisk business, selling whatever they sold before. Serving the past is good business in security! At the same time, vendors that focus on securing modern cloud environments, all those CSPMs, CWPSs, CIEMs (don’t even!) and now SSPMs, CNAPPs and perhaps even CDRs are flooding the market seeking to secure the future. These vendors also have huge booths!
So, RSA floor strikes me as a perfect, if bizarre, blend of the past and the future of security. The past is strong, yet the future now is strong too! Cloud-natives and the growing ranks of “cloud immigrants” (those not born in the cloud, but who fully embraced it) live in the 2020s. At the same time, some organizations are moving to enter the 1990s or perhaps 2000s, in regards to their IT tools and practices. There are people buying their first SIEM in 2022. There are people adopting virtualization in 2022. There are people moving to “next-gen” firewalls (a great innovation of 2005) in 2022.
To further illustrate this point, one of the innovations sandbox participants showed the slide that mentioned that the VPN market alone today is larger than the entirety of all cloud security markets, defined broadly and loosely, and then rounded upwards. Somehow that fact blew my mind! Another related bit somebody shared with me was a concept of a “descendant vendor” — they are not dead, not dying, they are making good money, but nobody sane would think that they are an important part of the security future…
Securing the past is still good business, but now securing the future is also good business [not the distant future, BTW].
Now, onto the themes I’ve picked on.
XDR — XDR was everywhere, with many vendors touting open XDR (so, basically SIEM?), native XDR (can be anything) and several other types too. XDR itself is still crazy and undefined and there are signs that some vendors are making it even broader, fuzzier, like selling TIP as XDR. For examples, some were saying that they are “XDR for something” (like we are very broad but also somehow focused on one domain … say what?).
XDR’s older brothers — EDR and NDR — are now joined by DDR (one vendor claimed “Data Detection and Response”) and ITDR (no, not for IT, silly: “Identity Threat Detection and Response”). I have not spotted CDR this time, but maybe I should have — more on this below.
There was definitely a lot of MDR as well, as more organizations are looking for help with detection and response, while classic MSSPs are delivering annoyance rather than security operations excellence. In one area of the expo floor, you can walk past many booths and it would be all MDRs for miles and miles …
Zero trust is even more everywhere, and this one is turning silly quickly. A password manager claimed “zero trust for passwords” while a SIEM/UEBA vendor promised to reveal all zero trust secrets (I bet they use VPN internally…). A firewall management vendor claimed to “simplify zero trust.” An anti-DDoS vendor promised “better zero trust visibility.” Yet another proclaimed that ZTNA 1.1 is over — and I bet a fair number of organizations haven’t even registered that ZTNA truly arrived yet for them. As a side note, I did see some SASE, but a lot less than zero trust.
Cloud security is very visible! To me, it represents a big part of the security industry’s future (and its present for many too — see the above theme discussion). I also noticed that new vendors and even vendor categories are still appearing in this area, we are still very much in the Cambrian explosion here. So, we have a space with a growing number of vendors and categories, all morphing and fluidly evolving, and all that happens around what the cloud providers are doing in security. Very fun!
I noticed that the cloud security wave is still triggering a lot of “as code” promises by the vendors — spotted “forensics as code”, “cloud governance as code”, “detection as code” and a few others. This is cloud thinking percolating through the industry, slowly but surely. To me, this is a good thing!
BTW, I was looking for the emergence of CDR (Cloud Detection and Response) so I was talking to a few vendors building tools to do detection, investigation and response in the cloud. These would be covered in a separate post, but I think cloud IR would get exciting soon…
Naturally, I was also on a lookout for SIEM and how it is doing nowadays. Pretty much every SIEM vendor is a SIEM/SOAR/UEBA vendor. But why not just accept that in 2022, SIEM = SIEM + SOAR + UEBA? If your SIEM has no SOAR and UEBA, it is not really a SIEM anymore. As one such incomplete vendor claimed, “we are not a SIEM, we are a ‘SIEM replacement’”… hmm… OK, I agree “my engine, 2 doors and 3 wheels is not a car… but a car replacement.” Very credible, that. As a funny side note, one vendor’s booth asked: “Is your SIEM a money pit?” I think somebody should have added in crayon “… Can our not-quite-SIEM tool be that instead?”
Finally, a quick note on ML and AI. I think we are past the silly screaming phase of security ML and into the solid operationalization phase of a hype cycle here. I’ve seen decent examples of how companies used ML techniques for various security tasks and how they got good results, backed up with numbers and such. This took a few years, and some got there earlier, but we are definitely in the calmer waters in this regard.
What about things not seen or seen less: maybe it is just me, these below I’ve seen less than I expected:
UPDATE: listen to our RSA 2022 Reflections podcast episode here!
Related posts:
Originally published at Medium.
One of the well-advertised reasons for being in the office is about those “magical hallway conversations” (Google it). One happened to me a…
One of the well-advertised reasons for being in the office is about those “magical hallway conversations” (Google it). One happened to me a few days ago and led to a somewhat heated debate on the nature of modern threat detection.
It also resulted in this half-shallow / half-profound blog that relates detection to cooking and farming! Well, the magical discussion was over lunch, so this is perhaps logical.
Here on the blog I touched the subject of detection engineering quite a few times, yet I realize that many organizations prefer to rely on their security tool vendor content for threat detection. In essence, they want “detection consumption”, not detection engineering.
To me, this detection engineering-or-consumption conundrum boils down to two key dimensions: detection transparency and detection customizability. Naturally, these are not the dimensions that define good detection (for example, velocity and coverage play a lot too), but we focus on transparency and customizability here.
Specifically:
BTW, to me, transparency is what leads to trust in detection content, yet I agree with others who say that there are other ways to gain trust other than seeing the explicit detection code.
One analogy that came to us in a discussion was cooking. Naturally, this will be a big table (sorry, Anna)
Now, let’s discuss the examples from various detection tools.
For a good number of years, I’ve looked at SIEM customers using — or not — the detection content (rules, models, etc) provided with their product. Quite a few people told me that upon installing an SIEM product, they immediately discard all out of the box content. On the other hand, others told me that they did use the vendor-provided content after some modifications (some light, some heavy). Anyhow, all SIEMs have open and modifiable detection rules, and rely on ML (not open and modifiable) for some things.
Now, if we travel to the world of EDR, we see a lot fewer people writing custom detections. Some successful products don’t even offer an opportunity to write their own detections. We also see EDRs relying heavily on ML, “secret” threat intelligence and other opaque detection mechanisms. Overall, EDRs often have opaque and unchangeable directions (and use ML too) and clients are OK with that.
Now, if we get a time machine and travel to the world of NIDS, this same battle affected intrusion detection systems back in the day. Some products did not expose the logic of the signatures to clients while others did. Some products came without any detection logic, and assumed “all customers will cook” (these products mostly just died). My impression is that in the long run, the vendors with open signatures — like Snort — won the battle, but also that most customers ended up not creating their own signatures (and did light tuning at best). This 2006 (!) Gartner piece pretty much assumes most clients of NIDS/NIPS use vendor signatures with minimal tuning, some only focusing on higher fidelity signatures sets shipped by the vendor (“The signature set most enterprises enable is the vendor-recommended high-fidelity subset of total capability.”) The surviving NIDS had open detections, but clients often chose not to modify them or create their own.
For the remaining “classic” detection technology, NDR, I see a mixed bag of open and modifiable detections (usually zeek-based) and opaque (usually those that are ML-heavy). Thus, some NDRs have opaque and unchangeable directions while others offer open and modifiable ones. This does not really teach us anything, so whatevs.
As a side note, my impression is that many security professionals would undoubtedly answer yes to both questions (transparent and modifiable). For example:
However, surveys and reality don’t always match. Changes in threat landscape and changes in how organizations do IT may affect the operational reality, perhaps disrupting some accumulated detection wisdom.
For example, while signature creation and customization are valuable, no organization will create detection logic to detect threats against 800+ SaaS business applications. It is very likely that there are scenarios where cloud scale will drive people to opaque, but vendor-managed signatures and detections.
Finally, what about ML? The growth of ML and other non-deterministic detection techniques perhaps indicate that lack of transparency and modifiability is not a “red line”, as long — I think — the new methods are significantly better than the old ones (today, this is debatable).
The real question that I am driving at in this post and that caused our discussion to become heated is — what is the model that is best for the majority of organizations?
Frozen food? Meal kits? Gourmet cooking from scratch (probably not)? Or some hybrid approach? Do people want to just add salt to the ready-made recipe? Or replace truffles with Portobello mushrooms? Or meat with soy?
What do you think?
First, perhaps all this searching for “the” right answer is deluded? Perhaps, as often in security, the answer is “all of the above”?
This post comes with a hidden assumption, which is that a single meal is going to be eaten or all meals would be the same all the time.
In practice, an enterprise, particularly beyond a certain size, looks much more like a working farm than a single family having a meal. On a farm, we have a variety of needs: sometimes the raw strength of oxen to pull a plow, at times the speed and agility of a horse to wrangle wayward cattle, or the wise counsel of an elder farmer. Similarly, we feed these characters differently: our oxen eat silage, our horses hay, and grandma gets the best slice of lovingly prepared pie. A working farm has needs for all kinds of food, just as an enterprise can and should take advantage of each kind of detection!
For most companies it would be bananas (pun intended) to try to feed endpoint detection needs only with lovingly crafted hand tuned rules, just as our oxen don’t solely eat apple pie. At the same time, our business critical crown jewels don’t have merely the out of the box silage NIDS content, we carefully curate our alerts around our key management tooling, because we know grandma won’t eat hay.
So while we’ve spent a lot of time arguing what is best, I think what is truly best is finding the right kind of rule and detection content for the problem at hand, and finding the way for your rules and detection to work in harmony when it comes to prioritizing triggered alerts for triage, investigation, and response.
Thanks to Tim Peacock and to one unnamed, but very intelligent, security product manager for a profound discussion. Separate thanks to Tim Peacock for writing an inspired conclusion to this post!
Blogs about detection:
Originally published at Medium.
One of the well-advertised reasons for being in the office is about those “magical hallway conversations” (Google it). One happened to me a…
One of the well-advertised reasons for being in the office is about those “magical hallway conversations” (Google it). One happened to me a few days ago and led to a somewhat heated debate on the nature of modern threat detection.
It also resulted in this half-shallow / half-profound blog that relates detection to cooking and farming! Well, the magical discussion was over lunch, so this is perhaps logical.
Here on the blog I touched the subject of detection engineering quite a few times, yet I realize that many organizations prefer to rely on their security tool vendor content for threat detection. In essence, they want “detection consumption”, not detection engineering.
To me, this detection engineering-or-consumption conundrum boils down to two key dimensions: detection transparency and detection customizability. Naturally, these are not the dimensions that define good detection (for example, velocity and coverage play a lot too), but we focus on transparency and customizability here.
Specifically:
BTW, to me, transparency is what leads to trust in detection content, yet I agree with others who say that there are other ways to gain trust other than seeing the explicit detection code.
One analogy that came to us in a discussion was cooking. Naturally, this will be a big table (sorry, Anna)
Now, let’s discuss the examples from various detection tools.
For a good number of years, I’ve looked at SIEM customers using — or not — the detection content (rules, models, etc) provided with their product. Quite a few people told me that upon installing an SIEM product, they immediately discard all out of the box content. On the other hand, others told me that they did use the vendor-provided content after some modifications (some light, some heavy). Anyhow, all SIEMs have open and modifiable detection rules, and rely on ML (not open and modifiable) for some things.
Now, if we travel to the world of EDR, we see a lot fewer people writing custom detections. Some successful products don’t even offer an opportunity to write their own detections. We also see EDRs relying heavily on ML, “secret” threat intelligence and other opaque detection mechanisms. Overall, EDRs often have opaque and unchangeable directions (and use ML too) and clients are OK with that.
Now, if we get a time machine and travel to the world of NIDS, this same battle affected intrusion detection systems back in the day. Some products did not expose the logic of the signatures to clients while others did. Some products came without any detection logic, and assumed “all customers will cook” (these products mostly just died). My impression is that in the long run, the vendors with open signatures — like Snort — won the battle, but also that most customers ended up not creating their own signatures (and did light tuning at best). This 2006 (!) Gartner piece pretty much assumes most clients of NIDS/NIPS use vendor signatures with minimal tuning, some only focusing on higher fidelity signatures sets shipped by the vendor (“The signature set most enterprises enable is the vendor-recommended high-fidelity subset of total capability.”) The surviving NIDS had open detections, but clients often chose not to modify them or create their own.
For the remaining “classic” detection technology, NDR, I see a mixed bag of open and modifiable detections (usually zeek-based) and opaque (usually those that are ML-heavy). Thus, some NDRs have opaque and unchangeable directions while others offer open and modifiable ones. This does not really teach us anything, so whatevs.
As a side note, my impression is that many security professionals would undoubtedly answer yes to both questions (transparent and modifiable). For example:
However, surveys and reality don’t always match. Changes in threat landscape and changes in how organizations do IT may affect the operational reality, perhaps disrupting some accumulated detection wisdom.
For example, while signature creation and customization are valuable, no organization will create detection logic to detect threats against 800+ SaaS business applications. It is very likely that there are scenarios where cloud scale will drive people to opaque, but vendor-managed signatures and detections.
Finally, what about ML? The growth of ML and other non-deterministic detection techniques perhaps indicate that lack of transparency and modifiability is not a “red line”, as long — I think — the new methods are significantly better than the old ones (today, this is debatable).
The real question that I am driving at in this post and that caused our discussion to become heated is — what is the model that is best for the majority of organizations?
Frozen food? Meal kits? Gourmet cooking from scratch (probably not)? Or some hybrid approach? Do people want to just add salt to the ready-made recipe? Or replace truffles with Portobello mushrooms? Or meat with soy?
What do you think?
First, perhaps all this searching for “the” right answer is deluded? Perhaps, as often in security, the answer is “all of the above”?
This post comes with a hidden assumption, which is that a single meal is going to be eaten or all meals would be the same all the time.
In practice, an enterprise, particularly beyond a certain size, looks much more like a working farm than a single family having a meal. On a farm, we have a variety of needs: sometimes the raw strength of oxen to pull a plow, at times the speed and agility of a horse to wrangle wayward cattle, or the wise counsel of an elder farmer. Similarly, we feed these characters differently: our oxen eat silage, our horses hay, and grandma gets the best slice of lovingly prepared pie. A working farm has needs for all kinds of food, just as an enterprise can and should take advantage of each kind of detection!
For most companies it would be bananas (pun intended) to try to feed endpoint detection needs only with lovingly crafted hand tuned rules, just as our oxen don’t solely eat apple pie. At the same time, our business critical crown jewels don’t have merely the out of the box silage NIDS content, we carefully curate our alerts around our key management tooling, because we know grandma won’t eat hay.
So while we’ve spent a lot of time arguing what is best, I think what is truly best is finding the right kind of rule and detection content for the problem at hand, and finding the way for your rules and detection to work in harmony when it comes to prioritizing triggered alerts for triage, investigation, and response.
Thanks to Tim Peacock and to one unnamed, but very intelligent, security product manager for a profound discussion. Separate thanks to Tim Peacock for writing an inspired conclusion to this post!
Blogs about detection:
Originally published at Medium.
