RSA 2020 Reflection

As I mentioned in my past RSA reflection posts, I like the conference a lot — contrary to some of my industry peers — because I consider…

---

As I mentioned in my past RSA reflection posts, I like the conference a lot — contrary to some of my industry peers — because I consider it to be “an industry in a room” event. This makes it ideal to quickly soak up what is going on. So, yes, it may be an imperfect mirror of our industry, but a mirror nonetheless.

In 2020, the event started in the shadow of coronavirus / COVID-19, but apparently 36k people still showed up. Was it a good idea? At this point, given what we know now about the consequences, only time will tell. In any case, that time feels like years ago…

So, what are my observations and thoughts after RSA 2020?

General

• Many observers made comments about unclear and confusing messaging from many security vendors. Further, I’ve seen another interesting trend this year: vendor booths with no messaging at all where the salespeople just shouted “come see a demo.” I think this may indicate that the confusing messaging trend has run its course and hit its penultimate end. To me, this also means that some vendors have given up on trying to find the category or market segment where they belong (“It’s a bird? It’s a plane? Ah, whatever, come see a superdemo!”)
• One more thing I noticed is that some legacy vendors have caught up with newer trends and buzzwords. For example, a firewall vendor loudly proclaimed that they secure the cloud, while an anti-malware vendors boldly claimed to be EDR or even XDR.
• Funny enough, I’ve seen enough new vendors with extremely narrow focus. For example: we do sensitive data discovery in one or two types of cloud storage. In the past, some called them “feature vendors” and predicted their rapid demise. Guess what? Now even narrower vendors appeared… In fact, I’ve heard of somebody selling a “better” random number generator — and nothing else. BTW, some of them claimed that their advantage is that they are “focused “…

Zero Trust

• While another commentator opined that zero trust has declined since last year, I am not so sure. I’ve spotted zero trust labels stuck to many technologies with no real connection to the original Zero Trust Network Access (ZTNA) story. Zero trust was used way, way too broadly, sometimes to denote that the vendor simply does not trust something somewhere …
• I’ve seen “one click zero trust” (for microsegmentation in the cloud, I think), “zero trust for email”, “zero trust for physical security” (yes, really), “zero trust for OT” (naturally) and a wide range of others (zero trust inside CASB anybody? zero trust with encryption?)
• When asked about the specifics, some disappointed: one vendor explained to me that they are “zero trust” because they don’t trust access firewall rules with IP addresses in them …
• Note that apart from zero trust, it’s younger brother showed up: SASE (look it up!); I’ve seen at least two booths that mentioned it.

SOC, SIEM, Hunting

• Sadly, hunting went the way of zero trust noted above: in many vendor materials it just meant “something cool in security ops or detection” — fake hunting seems to have exploded for real in 2020…
• XDR was spotted in a few places; my impression was that it was somehow more popular with larger, legacy vendors and not start-ups (not sure why).
• You did guess that SIEM will get its own line, right? So, I’ve spotted a few vendors who now market as “SIEM” even though in recent past, they were merely log management… In reality, deciding if something is a useful SIEM is surprisingly hard.
• Strangely, MDR was not as visible as I expected — today, in this talent shortage era, a well-done MDR is practically a license to print money…

Network Security

• We live in an endpoint-centric world (sort of), but this RSA I’ve noticed a distinct revival of network-based detection and monitoring controls. Hey, somebody even launched a network IDS company. There was NTA and even NDR in a few places, sometimes coupled with a modern SOC story.
• Admittedly, the network crowd has it hard due to TLS / SSL and increasing bandwidth (and now lots more WFH and BYOD), but I also think that the “endpoint is all you need” crowd will ultimately lose the war, even after they won some recent battles.
• Do we need another signature-based NIDS and another flow-based “NTA”? I doubt it. But do we need to respect the network as a key channel of security visibility? For sure!

Cloud

• Given my employment, I’ve looked at cloud and multi-cloud security. I spotted quite a few vendors that deliver a layer of cloud security on top of [Instead of? Together with? With no regard for? :-)] the security that cloud providers has built.
• Why do they exist? Will they exist in the near future? I had a few fun discussions about this, including with some of the vendors. Now, their value proposition is clear for clients who use more than one cloud provider for many projects. Beyond that, they solve problems like these: client’s fear a cloud vendor lock-in, others want separation of duty controls, yet another group wants specific features that their CSP does not have, etc.
• For sure, I’ve seen a few of the container security vendors (and even Istio security one), but this was not a deluge. Are container threats a big deal yet? :-)

Data security and privacy

• This year, I also dug into data security and even a bit into privacy technologies.
• Here is the thing: I asked a few privacy-related vendors what their customers really buy from them and it turned out that the answer is “compliance” — this surprised me a bit. While there are voices that claim that “privacy is a human right”, those vendors didn’t really sell “human right” as a value proposition — they sold compliance …
• Overall, I feel that data security somehow lost much of the excitement in recent years. Think about it! EDR, threat hunting, mobile security, IoT security, even app security were generating a lot of excitement recently — but do you see anything new and exciting in data security? A new HSM model or updated data governance rule don’t have their own GOTHIC PANDA threat actor or a logo to promote their causes … Even data breaches lately showcased things other than data security (!).
• Oh, another anomaly I spotted: when some of the data security-related vendors talked about data they protect, they assume that data equals PII or another type of structured personal data. Why is that? Many secrets are in documents and slide decks too. Such narrow minded focus on structured data seems dangerous to me.
• Notably, in the past I assumed that DLP and UBA/UEBA would be another happy marriage but the reality today looks different. One part of DLP seems to be thriving — data discovery. As lots of data move to various clouds, nobody really knows where all this will end up. Hence data discovery start-ups and features to do this from the cloud providers were more visible than before.

NOT seen

• This year I’ve seen a lot less “AI craziness”, a lot less IoT / OT security (perhaps those who launched last year jumped the gun?) and as little insider threat as last year.

Enjoy! And stay safe, of course.

Past RSA Blog Posts:

• RSA 2019: Happily Not Over-AI’d
• RSA 2018: Not As Messy As Before?
• RSA 2017: What’s The Theme?
• RSA 2016: Musings and Contemplations
• RSA 2015: Rise of Chaos!!
• RSA 2013 and Endpoint Agent Re-Emergence
• RSA 2006–2015 In Anton’s Blog Posts!

---

Originally published at Medium.

So, Chronicle, Are You a SIEM?

With this post, I am about to answer the question everybody wants to know the answer for …

---

With this post, I am about to answer the question everybody wants to know the answer for …

… is Chronicle a SIEM?

However, if you are impatient and need to get the answer right now, here it is: Chronicle can address many modern security use cases that you would typically use a SIEM for.

Before I give a more nuanced answer, let’s agree on the foundations. Today’s technology and threat realities mean that there is a set of security monitoring capabilities that CISOs and their teams need.

Historically (since the late 1990s), most of such capabilities have been bundled together into a thing called “a SIEM.” Over the years, this SIEM concept has gathered more and more capabilities ranging from compliance reporting to security workflow management and machine learning algorithms for threat detection.

However, not every historic capability retains its relevance as times change. As I personally recall, in a 2002-era SIEM, management of large volumes of IDS alerts was at the center of the universe (features that correlated IDS alerts with firewalls logs were a big deal). Then by 2005, everybody was obsessing about compliance reports (one vendor claimed 13,000 reports out of the box). This may have made sense in an era when “buy for compliance, use for security” was the mantra and many SIEMs were paid out of compliance budgets.

But what is the center of gravity for today’s SIEM? Put differently, how would SIEM look like if it were invented in 2020?

Let’s think about it together. To start, every organization has a need to collect security (and other) telemetry, analyze it to find non-obvious problems (detection), investigate alerts/incidents, look for badness beyond alerts (threat hunting), initiate and support a response, and prove that the security architecture is working (reporting). Today, the budget line item for this is some form of SIEM and the product used is typically called some flavor of SIEM.

However, I bet if SIEM tools were born in 2020 and not in 1996, it would be cloud-based (hence essentially maintenance-free), blazing fast even on petabytes of data, able to collect data without onerous intake filtering, be effective for detection, investigation and hunting, use threat intelligence a lot and would present clean and enriched data to the users in the form of timelines and stories. On the other hand, it will focus less on compliance reports and pleasing auditors.

In essence, both technologies and use cases have shifted over time. Appliance SIEM was designed for a world of terabytes. This was “big data” 10–12 years ago. I remember a time when a “scalable” “enterprise” SIEM was able to retain a whopping 40TB of logs — imagine that! Can you “expand” such a toolset to handle petabytes? Maybe, but it won’t be pretty, and won’t be performant — and likely won’t be affordable. Can you upgrade your 1980s gasoline car to run on electricity? Eh … yes, some hobbyists in fact have done that. Will it be ideal for today’s requirements? For sure, the answer is no. Still, modern electric car makers didn’t invent a new category, even though very little in (say) a Tesla technology is similar to what a 1980s car had.

Similarly, can you optimally use an old on-premise SIEM for large scale searches, threat intel matching or even heavy analytics? No, because the amount of compute resources it would have access to is fixed. Hence you can operate primarily on the present, not past and present. This means that rules generally are focused on present-time detections, not deeper historical analysis. Incoming data is normalized into buckets, but not fused into timelines and enriched with past data.

Back to the topic, so is Chronicle a SIEM? We do serve an ever-increasing number of threat detection and monitoring use cases. Ultimately, it depends whether you believe SIEM should be mired in the past or started afresh for the future.

For example:

1. Do you think SIEM is a product that does compliance reporting on logs? If this is your main defining criteria, then we are not a SIEM today. However, note that compliance reports are much easier to build compared to, say, retroactive threat intel matching and sub-second enriched data search….

2. Do you think SIEM is a technology that detects threats using data and helps you manage security alerts? In this case, we are very much a SIEM, or at least as close to one as to make no difference. We also offer capabilities that few SIEMs have such as coverage of EDR and traffic data alongside with logs, and threat intel matching. At the same time, we have not yet finished building some features most other SIEMs have (like, say, traditional reports)

Finally, if not a SIEM, then what? “Security analytics” has been the favorite for some people. While I was not a fan of using this to label a product in the past, I can see its appeal, especially for a product that does not quite fit some of the narrow SIEM definitions. Some analyst firms in fact do use it to label product categories. In light of this, security analytics is the best alternative choice here, if you are not convinced by my logic about the modern SIEM use cases.

To summarize, use us like you would a SIEM — if SIEM were invented today!

---

Originally published at Medium.

So, Chronicle, Are You a SIEM?

With this post, I am about to answer the question everybody wants to know the answer for …

---

With this post, I am about to answer the question everybody wants to know the answer for …

… is Chronicle a SIEM?

However, if you are impatient and need to get the answer right now, here it is: Chronicle can address many modern security use cases that you would typically use a SIEM for.

Before I give a more nuanced answer, let’s agree on the foundations. Today’s technology and threat realities mean that there is a set of security monitoring capabilities that CISOs and their teams need.

Historically (since the late 1990s), most of such capabilities have been bundled together into a thing called “a SIEM.” Over the years, this SIEM concept has gathered more and more capabilities ranging from compliance reporting to security workflow management and machine learning algorithms for threat detection.

However, not every historic capability retains its relevance as times change. As I personally recall, in a 2002-era SIEM, management of large volumes of IDS alerts was at the center of the universe (features that correlated IDS alerts with firewalls logs were a big deal). Then by 2005, everybody was obsessing about compliance reports (one vendor claimed 13,000 reports out of the box). This may have made sense in an era when “buy for compliance, use for security” was the mantra and many SIEMs were paid out of compliance budgets.

But what is the center of gravity for today’s SIEM? Put differently, how would SIEM look like if it were invented in 2020?

Let’s think about it together. To start, every organization has a need to collect security (and other) telemetry, analyze it to find non-obvious problems (detection), investigate alerts/incidents, look for badness beyond alerts (threat hunting), initiate and support a response, and prove that the security architecture is working (reporting). Today, the budget line item for this is some form of SIEM and the product used is typically called some flavor of SIEM.

However, I bet if SIEM tools were born in 2020 and not in 1996, it would be cloud-based (hence essentially maintenance-free), blazing fast even on petabytes of data, able to collect data without onerous intake filtering, be effective for detection, investigation and hunting, use threat intelligence a lot and would present clean and enriched data to the users in the form of timelines and stories. On the other hand, it will focus less on compliance reports and pleasing auditors.

In essence, both technologies and use cases have shifted over time. Appliance SIEM was designed for a world of terabytes. This was “big data” 10–12 years ago. I remember a time when a “scalable” “enterprise” SIEM was able to retain a whopping 40TB of logs — imagine that! Can you “expand” such a toolset to handle petabytes? Maybe, but it won’t be pretty, and won’t be performant — and likely won’t be affordable. Can you upgrade your 1980s gasoline car to run on electricity? Eh … yes, some hobbyists in fact have done that. Will it be ideal for today’s requirements? For sure, the answer is no. Still, modern electric car makers didn’t invent a new category, even though very little in (say) a Tesla technology is similar to what a 1980s car had.

Similarly, can you optimally use an old on-premise SIEM for large scale searches, threat intel matching or even heavy analytics? No, because the amount of compute resources it would have access to is fixed. Hence you can operate primarily on the present, not past and present. This means that rules generally are focused on present-time detections, not deeper historical analysis. Incoming data is normalized into buckets, but not fused into timelines and enriched with past data.

Back to the topic, so is Chronicle a SIEM? We do serve an ever-increasing number of threat detection and monitoring use cases. Ultimately, it depends whether you believe SIEM should be mired in the past or started afresh for the future.

For example:

1. Do you think SIEM is a product that does compliance reporting on logs? If this is your main defining criteria, then we are not a SIEM today. However, note that compliance reports are much easier to build compared to, say, retroactive threat intel matching and sub-second enriched data search….

2. Do you think SIEM is a technology that detects threats using data and helps you manage security alerts? In this case, we are very much a SIEM, or at least as close to one as to make no difference. We also offer capabilities that few SIEMs have such as coverage of EDR and traffic data alongside with logs, and threat intel matching. At the same time, we have not yet finished building some features most other SIEMs have (like, say, traditional reports)

Finally, if not a SIEM, then what? “Security analytics” has been the favorite for some people. While I was not a fan of using this to label a product in the past, I can see its appeal, especially for a product that does not quite fit some of the narrow SIEM definitions. Some analyst firms in fact do use it to label product categories. In light of this, security analytics is the best alternative choice here, if you are not convinced by my logic about the modern SIEM use cases.

To summarize, use us like you would a SIEM — if SIEM were invented today!

---

Originally published at Medium.

To me, vuln data is waaaaaaaaaaaaaaaaaaaay more structured already compared to logs.

---

To me, vuln data is waaaaaaaaaaaaaaaaaaaay more structured already compared to logs. You guys in VM have a MUCH easier life :-)

---

Originally published at Medium.

Thanks a lot for your most thoughtful comment.

To paraphrase, if your 2004 SIEM had normalization problems, it was reasonable to hope that they will be fixed, say, by 2006. Now if the…

---

Thanks a lot for your most thoughtful comment. I think you are exactly right that it “ works very well in highly valid statistical domains or deterministic environments.” However, my fear is that the HUGE rise of tech search (whether commercial S or open-source E vendors) is proof that the number of such deterministic environments has shrunk OR that the labor to make your environment into on of those is seen as not worth applying.

To paraphrase, if your 2004 SIEM had normalization problems, it was reasonable to hope that they will be fixed, say, by 2006. Now if the same SIEM has normalization problem in 2020 under current conditions, my bet is they are NEVER getting fixed :-(

---

Originally published at Medium.

Road to Detection: YARA-L Examples — Part 4 of 3

Upon reading all of Part 1, Part 2 and Part 3 of my blog series that revealed our (Chronicle) approach to detection, many of you asked for…

---

Note: this blog series now exists in a cleaned-up full whitepaper form at https://hubs.ly/H0pvD_30

Upon reading all of Part 1, Part 2 and Part 3 of my blog series that revealed our (Chronicle) approach to detection, many of you asked for more YARA-L detection language examples.

Some of you also asked for a detailed language specification — it will take a few months to complete as our engine matures and we refine the detection logic a bit.

More examples with my explanations follow below;

Example 2 (see example 1 here) CLI Magic

The example below relies on regex match to a Windows command line (our UDM field udm.process.command_line). Where may such data appear? Typically, Endpoint Detection and Response (EDR) tools and/or sysmon. Today, many Chronicle customers send EDR and sysmon data into the platform. Note that not every EDR has detections for all the threats (naturally!) hence such post-processing of EDR data with YARA-L does deliver value. A traditional SIEM is not likely to even have a field for a command line arguments, by the way.

profile susp_powershell_download_file

{

meta:

author = “Chronicle Security”

description = “Rule to detect PowerShell one-liner to download a file”

version = “0.01”

created = “2019–12–16”

reference = “https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Windows%20-%20Download%20and%20Execute.md"

condition:

if re.regex(strings.lower(udm.process.command_line), “.*powershell.*net.webclient.*”) then

outcome.match()

end

}

Example 3 More EDR-ing

This is another simple rule that runs on EDR (or sysmon) data and relies on command line matching and also path matching (see udm.process.path below). It showcases conditions for grouping and flexible matching to several variables such as command line and process path. It also detects rather well and have been used to uncover things…

profile susp_process_with_variation_of_svchost

{

meta:

author = “Chronicle Security”

description = “Rule to detect process paths or command line execution of files with variations on svchost”

version = “0.01”

created = “2019–12–16”

function:

func CheckSvchostVariations()

if (

re.regex(strings.lower(udm.process.command_line), “.*(svch0st|svh0st|svhost|svchst|svchot|svchostexe)\.exe.*”) or

re.regex(strings.lower(udm.process.path), “.*(svch0st|svh0st|svhost|svchst|svchot|svchostexe)\.exe.*”)

) then

return true

end

return false

end

condition:

if ( CheckSvchostVariations() )

then

outcome.match()

end

}

Example 4 Registry Mess

This rule focuses on registry monitoring. Windows event logs or EDR data are the most likely source for this. The rule mixes event types with specific field values to detect interesting registry operations. This and many other rules are mapped to MITRE ATT&CK framework.

profile mitre_T1198_registry_modification_to_trusted_provider_list

{

meta:

author = “Chronicle Security”

description = “Detection for registry changes keys associated with Trusted providers”

reference = “https://attack.mitre.org/techniques/T1198/"

version = “0.01”

created = “2019–12–13”

function:

func ProviderListRegChange()

if ( (udm.metadata.event_type == “REGISTRY_MODIFICATION” or udm.metadata.event_type == “REGISTRY_CREATION” ) and

(

udm.target.Registry.registry_key == “HKLM\\SOFTWARE\\Microsoft\\Cryptography\\OID” or

udm.target.Registry.registry_key == “HKLM\\SOFTWARE\\WOW6432Node\\Microsoft\\Cryptography\\OID” or

udm.target.Registry.registry_key == “HKLM\\SOFTWARE\\Microsoft\\Cryptography\\Providers\\Trust” or

udm.target.Registry.registry_key == “HKLM\\SOFTWARE\\WOW6432Node\\Microsoft\\Cryptography\\Providers\\Trust”) )

then

return true

end

return false

end

condition:

if ( ProviderListRegChange() ) then

outcome.match()

end

}

Example 5 Too Late? Better Late Than Never

The rule below looks for ransomware dropping a ransom note. This may come from a wide range of data sources, centered on an endpoint (again, EDR and sysmon, as well as Windows logs — in some cases). Now, some of you may say “a ransom note? Isn’t it kinda the definition of ‘too late’?”

Well, sort of. I think this may mean detecting before more machines are infected, or (with some luck) detecting before the ransomware hits the proverbial open shares on your network.

profile ransomware_ryuk_ransomnote_created {

meta:

author = “blevene”

description = “Identify when a Ryuk Ransomware ransomnote has been written.”

version = “0.01”

created = “2019–12–16”

condition:

if (

udm.metadata.event_type == “FILE_WRITE”

and ( strings.to_lower(udm.target.file) = “RyukReadMe.html”)

or

strings.to_lower(udm.target.file) = “RyukReadMe.txt”

)

then

outcome.match()

end

}

Example 6 Detection Choices

This rule perhaps does not have much magic, but it does showcase a few more functions of the YARA-L language today. If you have multiple ways to detect something but want to channel them all into one detection as a result, this is an example of such a rule.

profile malware_powershell_empire

{

meta:

author = “Chronicle Security “

description = “Detection activity related to the OWAAuth malware”

reference = “https://attack.mitre.org/software/S0072/"

version = “1.2”

created = “2019–12–13”

updated = “2020–01–20”

function:

func ScheduledTaskSet()

if re.regex(strings.to_lower(udm.principal.process.command_line), “.*schtasks .*/tn updater.*”) then

return true

end

return false

end

func WritePayload()

if re.regex(strings.to_lower(udm.principal.process.command_line), “.*sal a new-object;iex\\(a io\\.streamreader\\(\\(a io\\.compression\\.deflatestream\\(\\[io.memorystream\\]\\[convert\\]::frombase64string\\(.*\\),\\[io\\.compression\\.compressionmode\\]::decompress\\)\\),\\[text.encoding\\]::ascii.*”)

then

return true

end

return false

end

condition:

if ScheduledTaskSet() or WritePayload() then

outcome.match()

end

}

Example 7 More Malware

This one matches more endpoint logs across multiple fields. In my view, this one demonstrates the YARA origin of the YARA-L language here (reminder: they are different languages for different purposes). Note that all of the fields below are matched via regexs, you don’t have to do it, but you have that choice.

Now this rule may have magic because it may trigger vs telemetry that does not actually constant the text below.

profile malware_win_dropper_sload

{

meta:

author = “Chronicle Security”

description = “Detection for sLoad dropper marker files”

reference = “https://www.microsoft.com/security/blog/2019/12/12/multi-stage-downloader-trojan-sload-abuses-bits-almost-exclusively-for-malicious-activities/"

version = “1.1”

created = “2019–12–16”

updated = “2020–01–28”

function:

func Marker()

if udm.metadata.event_type == “FILE_CREATION” and re.regex(strings.to_lower(udm.target.file.full_path), “.*\\_in\\$”)

and re.regex(strings.to_lower(udm.principal.process.command_line), “.*powershell.*”)

then

return true

end

return false

end

condition:

if Marker()

then

outcome.match()

end

}

Previous posts:

• Part 1
• Part 2
• Part 3

---

Originally published at Medium.