Why Your Security Data Lake Project Will … Well, Actually …

Long story why but I decided to revisit my 2018 blog titled “Why Your Security Data Lake Project Will FAIL!” That post was very fun to…

---

Long story why but I decided to revisit my 2018 blog titled “Why Your Security Data Lake Project Will FAIL!” That post was very fun to write and it continued to generate reactions over the years (like this one).

Just as I did when I revisited my 2015 SOC nuclear triad blog in 2020, I wanted to check if my opinions, views and positions from that time are still correct (spoiler: not exactly…)

As a reminder, the post stated that most organizations building DIY security data lakes would not succeed in these glamorous endeavors. I also predicted that years of immense (and costly) suffering would await the most persistent of them (and, yes, very, very few would succeed beautifully). In the end, most would either reach dramatically diminished goals or would spend the time/money and in fact accomplish nothing useful for security.

Note that this blog was informed by my observations of the previous wave of security data lakes (dating back to 2012) and related attempts by organizations to build security data science capabilities. While some think that this lakey excitement is recent, in reality, it dates back a decade or more.

So, in 2012, we said:

“Finally, “collect once — analyze many times for many goals” that include security, fraud and (rarely) operations model seems to be appearing in some leading organizations. Using the concept of a “data lake” where every team that needs the data can dip, apply schema at data read time (If needed) and solve a broad set of problems motivated them to explore big data approaches. Of course, the misguided motivation of “everybody else is doing it” (which is patently not true in this case) seems to be driving some Hadoop pilots and other dabbling with big data.“

However, we are not living in 2012 or 2018 anymore — we are in 2022. My attempts to start this discussion on Twitter revealed both proponents and opponents of the view that perhaps nothing has changed. So, has it?

Let’s review the arguments. I propose to use the following dimensions to decide on this: what changed and what stayed the same.

What I think is still true or unchanged:

• Security people have not learned scaled data management and data analytics, namely building, maintaining, optimizing and evolving the data analytics stacks, and frankly using them effectively as well
• Large scale data analysis infrastructure is still really hard, and actually still costly (well, this has caveats, see below)
• Security data analytics talent shortage is still there, so if you have only a few people, they should use products, not build or maintain them (I used to joke around 2013 that the planet holds about 5 real security data scientists, two of whom are named Alex. Hi Alexes!)
• Security (at least detection and response) is still a big data problem, and threat detection is still hard
• Even a traditional SIEM (whether software or even SaaS) is hard for many organizations to operate and use (hence MDR and various managed models are still very popular)
• Processes around security operations, and detection and response at many organizations are still very immature. Move to cloud have not changed this and sometimes set the clock back
• Most threat detection still requires structured data and that means reliable collection, working parsers, data cleaning and other steps are still required, while key word searches only go so far.

What I think changed in significant ways:

• Amazing new cloud data storage platforms are now available, and cloud data storage is not onerous to implement and run, compared to circa 2012 Hadoop
• Many organizations have accepted cloud as the way to store large volumes of sensitive data; and some data more sensitive than logs
• There is a lot more data we need to collect and analyze, such as from the public cloud environments
• If well architected, cloud does allow for less costly scalable telemetry storage, coupled with dramatic decrease of costs to operate the system
• There is much more sanity and less silly excitement about the role of ML in particular and data analytics in general for security. Machine learning works, but alien ML magic unicorns have not landed (sorry for mixing the metaphors here)
• Cloud makes API integration between storage layer and security layer a lot easier and a lot more reliable; you no longer need to install two complex pieces of software and then pray for them to be friends. Data integration may be one API call away.
• Thus, it is easier to create a workable and maintainable integration between the storage stack and security stack (I agree with Omer here, for sure, and I think this is the biggest position change in my thinking)

Still, to me, the decisive issue is whether decoupled SIEM is a good idea, and for what types of organizations. To remind, decoupled SIEM is where data storage technology (a security data lake, essentially) is built by one vendor while security brains are built by another.

For sure, today many people still prefer integrated, and use single vendor toolset or even an MDR (MDR itself, by the way, may well use a decoupled stack). For example, look at the 2022 SIEM Magic Quadrant, and integrated vendors still feature prominently. Still, my former colleagues have this to say:

“Data decentralization enables more cost-effective deployments, with more up-to-date data, and is expected to be a key trend for SIEM over the next 18 months”. (SIEM MQ 2022)

(my other sort-of colleagues agree and say this: “Top [SIEM] disruptor: security analytics on top of independent datastores.”)

So, back when my original data lake posts were written, integrated was winning and decoupled was losing — and losing badly at that. Today, integrated is doing fine, but I don’t think decoupled is losing anymore.

In light of this, I am ready to say that your security data lake project may still fail, but it probably does not have to ;-)

Thanks to my dear friend Augusto Barros for a very helpful discussion. Thanks to Omer Singer for indirectly motivating me to write this.

---

Originally published at Medium.

This is awesome, let me see if I can create a gentlemanly "semi-counter-argument: and post it in a…

---

This is awesome, let me see if I can create a gentlemanly "semi-counter-argument: and post it in a few days.

---

Originally published at Medium.

Google Cybersecurity Action Team Threat Horizons Report #4 Is Out!

This is my completely informal, uncertified, unreviewed and otherwise completely unofficial blog inspired by my reading of our fourth…

---

This is my completely informal, uncertified, unreviewed and otherwise completely unofficial blog inspired by my reading of our fourth Threat Horizons Report (full version) that we just released (the official blog for #1 report, my unofficial blog for #2, my unofficial blog for #3).

My favorite quotes from the report follow below:

• “in Q2 threat actors frequently targeted weak and default-password issues for initial compromise, factoring in over half of identified Incidents.” [A.C. — that is not ‘Q2 of 1998’, that is 2022! Especially the ‘no credentials’ part, which to me smells like the 1980s, not even the 1990s]

Cloud Compromise Factors from TH #4 — Google Cloud

• “Once inside, threat actors frequently engaged in cryptomining, accounting for nearly two-thirds of incidents (65%).” and “cryptominer attacks are often partially or fully automated, dramatically reducing their time to exploit an available vulnerability.“
• “The high level of SSH activity suggests that organizations are using either no credentials or default credentials when spinning up cloud instances.” [A.C. — somebody from the IR firm whose name starts with ‘M’ told me the other week that ‘in the cloud, they still have the mid-2000s in regards to some security practices’ and this is a great, if sad, example of that!]
• “The controls fail to identify the malware assets’ nefarious nature as they check the assets’ context and external characteristics, instead of exploring their content in more depth.” and “10% of well-known, popular websites are seen to be distributing malware. Malware “legitimacy” is inherited from credible hosts.“ [A.C. — this to me is a fun reminder that naïve badness ‘blocklists’ fail]
• There is a lot of signed malware because “attackers often fraudulently accessed signing workflows or signing authorities to sign their code — increasing the likelihood of its downstream acceptance” [A.C. — the news here is not that they do, but that nasty “o” word — “often”]
• “Kimsuky, a nation-state threat actor, has been observed by researchers at Volexity accessing user Gmail account data through a hidden Chrome browser extension known as SHARPEXT. The group […] was able to install a malicious browser extension via phishing, leveraging pre-authenticated browser activity to read and exfiltrate data from other services such as Gmail content” and “installation of a developer-mode browser extension which, through a DevTools workaround, has its security warnings suppressed and targets a user’s cloud-accessed data” [A.C. — this is reasonably notable, and fairly scary too!]
• … and a useful reminder here that ”increased productivity provided by seamless SSO also provides broader access for attackers to otherwise confidential data.” [A.C. — ‘login once — get everywhere’ [if done wrong] heps both the good and bad actors, unless zero trust is also done well]
• “they brute-forced the instance’s password and enrolled their own device in the NGO’s multi-factor authentication (MFA) process” [A.C. — another reminder that MFA is not useful if anybody can enroll a malicious device into it]
• “Threat groups have been observed leveraging compromised service account credentials to run expensive cryptomining workloads in customer environments, but greater concern would arise should they choose to keep these actions covert and leverage the access for other nefarious activities. ” [A.C. — to me, this reminds us that relying on attackers being very noisy for detection is not a great strategy]

Now, go and read the report!

Related posts:

• Google Cybersecurity Action Team Threat Horizons Report #3 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #2 Is Out!
• Illicit coin mining, ransomware, APTs target cloud users in first Google Cybersecurity Action Team Threat Horizons report
• First report can be found here and full second here.
• All past and future reports are posted at Google Cybersecurity Action Team site.

---

Originally published at Medium.

Google Cybersecurity Action Team Threat Horizons Report #4 Is Out!

This is my completely informal, uncertified, unreviewed and otherwise completely unofficial blog inspired by my reading of our fourth…

---

This is my completely informal, uncertified, unreviewed and otherwise completely unofficial blog inspired by my reading of our fourth Threat Horizons Report (full version) that we just released (the official blog for #1 report, my unofficial blog for #2, my unofficial blog for #3).

My favorite quotes from the report follow below:

• “in Q2 threat actors frequently targeted weak and default-password issues for initial compromise, factoring in over half of identified Incidents.” [A.C. — that is not ‘Q2 of 1998’, that is 2022! Especially the ‘no credentials’ part, which to me smells like the 1980s, not even the 1990s]

Cloud Compromise Factors from TH #4 — Google Cloud

• “Once inside, threat actors frequently engaged in cryptomining, accounting for nearly two-thirds of incidents (65%).” and “cryptominer attacks are often partially or fully automated, dramatically reducing their time to exploit an available vulnerability.“
• “The high level of SSH activity suggests that organizations are using either no credentials or default credentials when spinning up cloud instances.” [A.C. — somebody from the IR firm whose name starts with ‘M’ told me the other week that ‘in the cloud, they still have the mid-2000s in regards to some security practices’ and this is a great, if sad, example of that!]
• “The controls fail to identify the malware assets’ nefarious nature as they check the assets’ context and external characteristics, instead of exploring their content in more depth.” and “10% of well-known, popular websites are seen to be distributing malware. Malware “legitimacy” is inherited from credible hosts.“ [A.C. — this to me is a fun reminder that naïve badness ‘blocklists’ fail]
• There is a lot of signed malware because “attackers often fraudulently accessed signing workflows or signing authorities to sign their code — increasing the likelihood of its downstream acceptance” [A.C. — the news here is not that they do, but that nasty “o” word — “often”]
• “Kimsuky, a nation-state threat actor, has been observed by researchers at Volexity accessing user Gmail account data through a hidden Chrome browser extension known as SHARPEXT. The group […] was able to install a malicious browser extension via phishing, leveraging pre-authenticated browser activity to read and exfiltrate data from other services such as Gmail content” and “installation of a developer-mode browser extension which, through a DevTools workaround, has its security warnings suppressed and targets a user’s cloud-accessed data” [A.C. — this is reasonably notable, and fairly scary too!]
• … and a useful reminder here that ”increased productivity provided by seamless SSO also provides broader access for attackers to otherwise confidential data.” [A.C. — ‘login once — get everywhere’ [if done wrong] heps both the good and bad actors, unless zero trust is also done well]
• “they brute-forced the instance’s password and enrolled their own device in the NGO’s multi-factor authentication (MFA) process” [A.C. — another reminder that MFA is not useful if anybody can enroll a malicious device into it]
• “Threat groups have been observed leveraging compromised service account credentials to run expensive cryptomining workloads in customer environments, but greater concern would arise should they choose to keep these actions covert and leverage the access for other nefarious activities. ” [A.C. — to me, this reminds us that relying on attackers being very noisy for detection is not a great strategy]

Now, go and read the report!

Related posts:

• Google Cybersecurity Action Team Threat Horizons Report #3 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #2 Is Out!
• Illicit coin mining, ransomware, APTs target cloud users in first Google Cybersecurity Action Team Threat Horizons report
• First report can be found here and full second here.
• All past and future reports are posted at Google Cybersecurity Action Team site.

---

Originally published at Medium.