Join your hosts, Anton Chuvakin and Timothy Peacock, as they talk with industry experts about some of the most interesting areas of cloud security. If you like having threat models questioned and a few bad puns, please tune in!
You had posted a blog analyzing the whitehouse ZT a memo on the federal government’s transition to “zero trust”, what caught your eye about the Zero Trust memo and why did you decide to write about it?
What’s behind the federal government’s recommendations to deprecate VPNs and recommend users “authenticate to applications, not networks”?
What do these recommendations mean for cloud security, today and in the future?
What do you think would be the hardest things to implement in real US Federal IT environments?
Are there other recommendations in the memo to think about as organizations design zero trust strategies for their infrastructure?
What are some of the challenges of implementing zero trust in general?
What is your key learning about the state of SOC today? What one SOC trend are you hearing the most or most interested in?
What is your best advice to SOCs that are permanently and woefully understaffed?
Many SOC analysts are drowning in manual work, and it is easy to give advice that “they need to automate.” What does this actually entail, in real life?
What is, in your view, the most critical technology for a modern SOC? Is it SIEM? Is it SOAR? Is it EDR?
What is the best advice for a SOC that was handed cloud on a platter and was told to monitor it for threats?
Occasionally, we hear that “SOC is dead.” What is your response to such dire SOCless predictions?
Anna Belak, Director of Thought Leadership @ Sysdig
23:23
Topics covered:
One model for container security is “Infrastructure security | build security | runtime security” - which is most important to get right? Which is hardest to get right?
How are you helping users get their infrastructure security right, and what do they get wrong most often here?
Your report states that “3⁄4 of running containers have at least one "high" or "critical" vulnerability“ and it sounds like pre-cloud IT, but this is about containers? This was very true before cloud, why is this still true in cloud native? Aren’t containers easy to “patch” and redeploy?
You say “Whether the container images originate from private or public registries, it is critical to scan them and identify known vulnerabilities prior to deploying into production.“ but then 75% have critical vulns? Is the problem that 75% of containers go unscanned, or that users just don’t fix things?
“52% of all images are scanned in runtime, and 42% are initially scanned in the CI/CD pipeline.“ - isn’t pipeline and repo scanning easier and cheaper? Why isn’t this 90/10 but 40/50?
“62% detect shells in containers” sounds (to Anton) that “62% zoos have a dragon in them” i.e. kinda surreal. What’s the real story?
Containers are at the forefront of cloud native computing yet your report seems to show a lot of pre-cloud practices? Are containers just VMs and VMs just servers?
What makes the malicious document problem a good candidate for machine learning (ML)? Could you have used rules?
“Millions of documents in milliseconds,” not sure how to even parse it - what is involved in making it work?
Can you explain to the listeners the motivation for reanalyzing old samples, what ground truth means in ML/detection engineering, and how you are using this technique?
How fast do the attackers evolve and does this throw ML logic off?
Do our efforts at cat-and-mouse with attackers make the mice harder for other people to catch? Does massive-scale ML detections accelerate the attacker's evolution?
