A vulnerability management (VM) program is one of the basic pillars of any security program (ID.RA-01 in NIST CSF). That doesn’t mean that it’s easy though. In fact, I think it can cause a lot of friction with the asset owners/manager who are ultimately responsible for patching their systems. The problem is that as your infrastructure and application landscape grows, including software dependencies, the number of reported CVEs will grow as well. This applies to host machine packages, container level packages and application level libraries. When you have hundreds of CVEs, or even more, how can you prioritize what should be patched first? ...
How do you define and build a product security program? First, the answer depends on whether you are "only" shipping software artifacts to your customer or operating something as a service. For the former, you need a secure development lifecycle. For the latter you will additionally need to secure the infrastructure that runs your software and safeguard your customer’s data. The goal of this post is to provide you with two things that will help you build your own security program: (1) ideas for defining an overall security roadmap / strategy and (2) ideas for security controls that will define the details of your roadmap. Instead of providing my own roadmap, templates or controls, I will provide you with references to comprehensive 3rd party documents that are available in the public domain. Most of this material are (de-facto) industry standards that represent best practices collaboratively written by many people over the years. There is no need to reinvent the wheel when you can reuse existing, high quality material. ...
I have heard something like the following a few times: "You should store all your secrets in a secrets management system. This is the only secure approach for managing your secrets". This is not universally true. Furthermore, what does "secure" in this context even mean? What are the alternatives to using a secrets management system and why should they be less secure? This post will explore secrets management from the perspective of cloud native applications. We will take a look at the different solution options for managing secrets. ...
Software Bill of Materials (SBOM) has been around for some time now. In this post we are going to look into (open source) tools that can be used to work with SBOMs. Unfortunately, we will identify common limitations and problems when working with SBOM related tools. For some general information on what SBOM is all about, there is a Wired article on "the Modern Day SBOM" that describes the use cases. Summarized in one sentence, an SBOM is a machine-readable document that contains different information elements that contains information related to a (released) software package. The primary security use case for the SBOM (in the context of this blog post) is the identification of known vulnerabilities and risks in the software supply chain. This allows tracking whether 3rd party libraries that are included in a software package contain vulnerabilities (CVEs). ...
The automation examples presented in the previous blog posts, asset data collection and EASM, were time triggered. In this post we are going to use external events as triggers for launching security tasks. This allows to respond to something happening in other systems. For reading this blog post you should be familiar with the post that introduced the security automation platform and have a basic understanding of Kubernetes concepts. Argo Events Argo Workflows only supports triggering workflows manually or via a time schedule. Argo Events can be used to trigger a workflow from a variety of event sources like webhooks, message queues, etc. ...
In this post we are looking at a more complex security automation example: we will implement an External Attack Surface Monitoring/Management (EASM) solution using a workflow orchestration engine, as described in the first blog post. What is EASM? There are definitions from different vendors that offer this as a service, like Tenable, Crowdstrike or Rapid7. My own definition of EASM: Every organization has assets, and some of these assets are exposed to the Internet. E.g. web application servers, load balancers, VPN Gateways, … These assets might have known vulnerabilities (CVEs) Alternatively, these assets might be misconfigured, like a web application that grants anonymous access or uses a default username/password for admin access Ideally, we want to be able to detect these issues across all assets that are owned by the organization ...
Asset inventory is considered an essential part of any security program. For example, it is listed as the very first item on the 18 CIS Critical Security Controls. Collecting asset data for as-a-service environments can be challenging. Assets on these platforms, i.e. virtual machines on the hyperscalers, can be very dynamic: they can created or deleted, or undergo configuration changes, rather frequently. Building an inventory of these resources should therefore be done with a relatively high frequency, e.g. once a day. This activity is therefore a good candidate for automation where it can be executed regularly based on a time-based schedule. ...
This post introduces the workflow model and a workflow orchestration engine as the foundation for building a security automation platform that can be used to automate various security tasks. The implementation of the actual tasks will be addressed in future blog posts. Keeping up to date with an organization’s infrastructure footprint (IaaS, PaaS, SaaS, classical data centers or office networks) and fast moving software development activities can be a challenge for security teams. ...