From Google Cloud Blog: “New Cloud Security Podcast by Google is here”

Those who follow me on social media already knows this, but we have launched THE Cloud Security Podcast.

---

Those who follow me on social media already knows this, but we have launched THE Cloud Security Podcast.

TL;DR:

Find this on Google Podcasts, Apple Podcasts, Spotify, Stitcher and wherever else podcasts can be found. You can also download the episodes directly here. Follow @CloudSecPodcast.

The whole story from our GCP blog is cross-posted below:

Security continues to be top of mind for large enterprises as well as smaller organizations and businesses. Furthermore, cloud security continues to puzzle many security leaders and technologists. That is why we are excited to announce the launch of the Cloud Security Podcast by Google.

This podcast will bring you stories and insights on security in the cloud, delivering security from the cloud, and, of course, on what we’re doing at Google Cloud to help keep customer data safe and workloads secure. We’ll do our best to avoid security theater (but perhaps have some reverse security theater), and cut to the heart of real security questions and issues. We’ll question threat models and determine whether security tactics are deployed for the data subject’s benefit or just for organizational benefit.

We hope you’ll join us if you’re interested in the ways technology overlaps with process and bumps up against organizational design. We’re hoping to attract listeners who want to hear conventional wisdom questioned, who are curious about what lessons we can and can’t keep, as the world moves from on-premises computing to cloud computing.

Launching a podcast is a commitment to listeners and our guests. We’re starting out with three episodes available, each 20–25 minutes, and have plenty more planned for the next weeks and months. If you have topics you’re interested in hearing about, please reach out and let us know.

Your cloud security podcast hosts are Anton Chuvakin, Head of Solutions Strategy, and Timothy Peacock, Product Manager, both at Google Cloud. We both have long backgrounds in security, Anton with many years as a Gartner analyst, and Tim with nearly a decade of experience managing enterprise security products.

All of our episodes can be found below, and you can expect more to come every few weeks.

Episode 1 “Confidentially Speaking” (episode download link)

• Guest: Nelly Porter, Group Product Manager @ Google.
• Topics covered:
• What is confidential computing?
• What risks are mitigated by confidential computing?
• What types of organizations must adopt confidential computing?
• How and where the data is encrypted?
• Resources: Confidential computing at Google Cloud

Episode 2 “Data Security in the Cloud” (episode download link)

• Guest: Andrew Lance, Founder of Sidechain
• Topics covered:
• What is special about data security in the cloud?
• How data security plays in the shift from perimeter and network security to identity-based security?
• Can I use detective data security controls and turn them into preventative controls?
• Resources: “Designing and deploying a data security strategy with Google Cloud” paper

Episode 3 “Automate and/or Die?” (episode download link)

• Guest: Joe Crawford, formerly in charge of cloud-native security at a large bank
• Topics covered:
• Can we automatically remediate (or is it response!) vulnerabilities and threats in the cloud?
• Did you require humans to be in the loop for your automation? Is that still automation if we do?
• Does security’s fear of automation have a place in the cloud?

Future episodes

After the first three episodes above, the topics we plan to cover in the near future include:

• Zero trust approach to security
• Modern Security Operations Centers (SOC)
• Security during cloud migration
• Role of IAM in cloud security
• More on data security in the cloud
• The role of trust in cloud security
• Cloud-native network security
• Container security

Learn more

Find this on Google Podcasts, Apple Podcasts, Spotify, Stitcher and wherever else podcasts can be found. You can also download the episodes directly here.

You can reach your hosts on Twitter (@CloudSecPodcast), and we really hope to hear from you, whether you agree or disagree with our takes. Please also suggest new topics for us to cover!

See you at Cloud Security Podcast by Google.

---

Originally published at Medium.

SOC Threat Coverage Analysis — Why/How?

As I mentioned in Detection Coverage and Detection-in-Depth, the topic of threat detection coverage has long fascinated me. Back in my…

---

As I mentioned in Detection Coverage and Detection-in-Depth, the topic of threat detection coverage has long fascinated me. Back in my analyst days, we looked at it as a part of a security use case lifecycle process. For example, we focused on things like number and quality of alerts per SIEM use case, false/useless alert (“false positive”) numbers and ratios (to useful alerts), escalations to incident response, tuning, etc.

But what about a more comprehensive look at detection coverage inside each tool? Is there a way to assess the net threat coverage represented by the aggregate detection coverage inside each tool and then all tools? What about coverage analysis down to the rules presence, performance and quality?

A recent SIEM data analysis released by CardinalOps, a startup in the threat coverage space, suggests that the detection coverage gap is large at many organizations. Log source configuration errors, broken log collectors, insufficient breadth of rules, rule errors, noisy rules, and other factors contribute to poor coverage in the average organization. This got me thinking about this detection-in-depth and detection coverage again.

To an extent, some Breach and Attack Simulation (BAS) vendors try to go there. But ultimately this is NOT a job for a BAS that needs to retain its judge or arbiter role, rather than live deep inside the security operations machinery. Here we need something a lot more operational and a lot more plugged into the SOC tools and processes.

Also to an extent, MITRE ATT&CK (and especially CAR) would be helpful for this, but it is a framework, not a tool or even a methodology. You can MITRE content to map some of the threats to detections, but there are more things involved in obtaining and, especially, keeping your detection coverage map current.

So, how would I approach systematically looking at detection coverage in my SOC?

1. Do I know what threats I want to detect? Threat assessment process will answer that.
2. Do I know what detection content (rules, algorithms, models, etc) I need for this? Detection engineering or use case management process will lead to the right content here.
3. Do I know what data I need to run the detection content on? Some form of log/data source optimization process helps.
4. Am I collecting this data? A checklist can help here.
5. Is the data being collected in the right format, being parsed correctly (if needed) to drive the detection content in question?
6. Is the rule actually working in real life? Test automation process will reveal that.

A few of these needs to be run in a loop (“Is this working? Is this working after some system changes were made?”). This is a clear security engineering challenge and opportunity.

(P.S.: Related to this topic, I want to announce that I joined the Advisory Board of CardinalOps; they call this area Threat Coverage Optimization; they have a research report out)

Related blog posts:

• “Role of Context in Threat Detection”
• “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.

SOC Threat Coverage Analysis — Why/How?

As I mentioned in Detection Coverage and Detection-in-Depth, the topic of threat detection coverage has long fascinated me. Back in my…

---

As I mentioned in Detection Coverage and Detection-in-Depth, the topic of threat detection coverage has long fascinated me. Back in my analyst days, we looked at it as a part of a security use case lifecycle process. For example, we focused on things like number and quality of alerts per SIEM use case, false/useless alert (“false positive”) numbers and ratios (to useful alerts), escalations to incident response, tuning, etc.

But what about a more comprehensive look at detection coverage inside each tool? Is there a way to assess the net threat coverage represented by the aggregate detection coverage inside each tool and then all tools? What about coverage analysis down to the rules presence, performance and quality?

A recent SIEM data analysis released by CardinalOps, a startup in the threat coverage space, suggests that the detection coverage gap is large at many organizations. Log source configuration errors, broken log collectors, insufficient breadth of rules, rule errors, noisy rules, and other factors contribute to poor coverage in the average organization. This got me thinking about this detection-in-depth and detection coverage again.

To an extent, some Breach and Attack Simulation (BAS) vendors try to go there. But ultimately this is NOT a job for a BAS that needs to retain its judge or arbiter role, rather than live deep inside the security operations machinery. Here we need something a lot more operational and a lot more plugged into the SOC tools and processes.

Also to an extent, MITRE ATT&CK (and especially CAR) would be helpful for this, but it is a framework, not a tool or even a methodology. You can MITRE content to map some of the threats to detections, but there are more things involved in obtaining and, especially, keeping your detection coverage map current.

So, how would I approach systematically looking at detection coverage in my SOC?

1. Do I know what threats I want to detect? Threat assessment process will answer that.
2. Do I know what detection content (rules, algorithms, models, etc) I need for this? Detection engineering or use case management process will lead to the right content here.
3. Do I know what data I need to run the detection content on? Some form of log/data source optimization process helps.
4. Am I collecting this data? A checklist can help here.
5. Is the data being collected in the right format, being parsed correctly (if needed) to drive the detection content in question?
6. Is the rule actually working in real life? Test automation process will reveal that.

A few of these needs to be run in a loop (“Is this working? Is this working after some system changes were made?”). This is a clear security engineering challenge and opportunity.

(P.S.: Related to this topic, I want to announce that I joined the Advisory Board of CardinalOps; they call this area Threat Coverage Optimization; they have a research report out)

Related blog posts:

• “Role of Context in Threat Detection”
• “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.

This is coming later, but soon

---

This is coming later, but soon

---

Originally published at Medium.