Home

Week Roundup #1: June 17th - June 23rd

Quick roundup of the ~security~ stuff I've been working on in the past week!

Best [placeholder] of the Week

Album of the week:

• Animal Collective - Strawberry Jam is a "can't describe, won't describe" kinda album

Article of the week:

• Reversing UK mobile rail tickets by eta was an unecessarily deep dive into the inner workings of the UK’s train ticket systems

Video of the week:

• How Not to Get Sued with NIRVANA THE BAND THE SHOW will teach you about fair use, which is, useful(?)

Week Roundup

Projects:

• Started work on k8seccomp - a CLI tool for building and managing Linux security module profiles in Kubernetes

  • auto-seccomp-profile will attach a tracer to the running processes of a Kubernetes pod, log all system calls the containers makes, and dynamically generates a custom SecComp profile for the Pod
  • deploy-seccomp-profile to make it easy to deploy profiles to Pods. Issue is the Pod needs the profile on any of the Nodes it can run on, so this automates the process to deploy to one or many Nodes in the cluster
  • validate-apparmor-profile is a bit misplaced now (needs its own repo) but will validate an AppArmor profile and shout if there’s anti-patterns in use (e.g. write access to wildcarded resources)



• Worked on my Guide to Pragmatic Container Security

  • This is my first foray into writing a security guide, wanted to focus on something I’m actively working with at the moment
  • Aiming for this to be a purely pragmatic and practical approach, so ensuring the attacks we care about are outlined in each domain of the guide, how the controls actively mitigate the risk associated with these attacks, and further steps that can be taken to mature these controls
  • Focusing on the Runtime Security section of the guide (hopefully will have this ready to release next week!)
  • Limiting factor right now is having my own fully-fledged K8s cluster to work on so I can screenshot how to implement some of these recommendations (foreboding…)



• Trials and tribulations of setting up my own Kubernetes cluster

  • Wanted my own persistent cluster to help with some of the projects I’m working on (e.g. k8seccomp tool, container security guide)
  • Tried kind and minikube, but as both manage K8s pods as nested container it did not work well when messing with the kernel (and more importantly did not emulate production-grade K8s clusters)
  • Working now on deploying a rough-and-ready cluster in GCP

Articles and Videos

• <article> A Guide to Kubernetes Logs that Isn’t a Vendor Pitch

  • This is a rundown of all of the security logs available for a service running in a cloud-based Kubernetes cluster, by Graham Helton (one of the best security article writers about right now)
  • Utilises the Kuburrito model for breaking down the layers of logs available to monitor a cloud-cluster deployed app, with an emphasis on AuditPolicy logs being the killer source for security monitoring



• <video> The cloud is over-engineered and overpriced

  • While I don’t necessarily agree with everything said in the video (horizontal scaling and database management just is easier in the cloud) it’s a pretty good pause-for-thought on the delta between self-hosting and cloud-hosting



• <article> Building a Kubernetes purple teaming lab

  • This was an article about setting up a simple local minikube cluster with basic telemetry feeding into Sumo Logic
  • I was hoping for a little more of an in-depth runthrough of how to build a fully-fledged ‘purple team’ lab, but this is a nice intro
  • Would like to write my own guide for achieving this in the future, focusing on actual multi-node clusters and emulating/detecting attacks exploiting real vulnerabilities in containers and Kubernetes



• <article> Attackers deploying new tactics in campaign targeting exposed Docker APIs

  • Persistence go brrr, really interesting overview of a new cryptojacking campaign targeting publicly-exposed Docker engines (tut tut)
  • When I have more time I’d love to go through and highlight each area of the attack against logs that could be available, the folks running this campaign don’t seem to mind being fairly noisy so this seems like a great opportunity for layered detection rules



• <article> WTF is CDR?

  • Very entertaining and insightful article by James Berthoty on laying out exactly what a Cloud Detection & Response tool actually looks like, and how the industry has become hyper-fixated on ‘total cloud coverage’ to the detriment of actual cloud workload protection
  • In the article James argues that for the majority of companies, CDR should be just the culmination of Kubernetes API logs, container logs, and cloud logs
  • Seems like another case of vendors being unable (or unwilling) to see the wood for the trees, bolstered by an industry that is more obsessed with perceived ‘coverage’ than actionable insights