<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Posts on Peak Secure Blog</title>
    <link>https://blog.peaksecure.net/posts/</link>
    <description>Recent content in Posts on Peak Secure Blog</description>
    <generator>Hugo -- 0.139.4</generator>
    <language>en</language>
    <lastBuildDate>Sun, 27 Jul 2025 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://blog.peaksecure.net/posts/rss.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Scaling the Patching in Vulnerability Management</title>
      <link>https://blog.peaksecure.net/posts/vuln-mgmt/</link>
      <pubDate>Sun, 27 Jul 2025 00:00:00 +0000</pubDate>
      <guid>https://blog.peaksecure.net/posts/vuln-mgmt/</guid>
      <description>&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;A vulnerability management (VM) program is one of the basic pillars of any security program (&lt;a href=&#34;https://www.nist.gov/cyberframework&#34;&gt;ID.RA-01 in NIST CSF&lt;/a&gt;). 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.&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;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?&lt;/p&gt;
&lt;/div&gt;</description>
    </item>
    <item>
      <title>Building a Product Security Program</title>
      <link>https://blog.peaksecure.net/posts/prod-sec-program/</link>
      <pubDate>Sun, 25 May 2025 00:00:00 +0000</pubDate>
      <guid>https://blog.peaksecure.net/posts/prod-sec-program/</guid>
      <description>&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;How do you define and build a product security program?&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;First, the answer depends on whether you are &amp;#34;only&amp;#34; 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 &lt;em&gt;additionally&lt;/em&gt; need to secure the infrastructure that runs your software and safeguard your customer’s data.&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;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.&lt;br/&gt;
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.&lt;/p&gt;
&lt;/div&gt;</description>
    </item>
    <item>
      <title>Secrets Management</title>
      <link>https://blog.peaksecure.net/posts/secrets-mgmt/</link>
      <pubDate>Sat, 29 Mar 2025 00:00:00 +0000</pubDate>
      <guid>https://blog.peaksecure.net/posts/secrets-mgmt/</guid>
      <description>&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;I have heard something like the following a few times: &amp;#34;You should store all your secrets in a secrets management system. This is the only secure approach for managing your secrets&amp;#34;.&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;This is not universally true. Furthermore, what does &amp;#34;secure&amp;#34; in this context even mean? What are the alternatives to using a secrets management system and why should they be less secure?&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;/div&gt;</description>
    </item>
    <item>
      <title>SBOM - State of Tooling</title>
      <link>https://blog.peaksecure.net/posts/sbom-tooling/</link>
      <pubDate>Thu, 30 Jan 2025 00:00:00 +0000</pubDate>
      <guid>https://blog.peaksecure.net/posts/sbom-tooling/</guid>
      <description>&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;For some general information on what SBOM is all about, there is a &lt;a href=&#34;https://www.wired.com/sponsored/story/dropping-an-sbom-on-your-software-supply-chain/&#34;&gt;Wired article&lt;/a&gt; on &amp;#34;the Modern Day SBOM&amp;#34; 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).&lt;/p&gt;
&lt;/div&gt;</description>
    </item>
    <item>
      <title>Event Driven Security Automation</title>
      <link>https://blog.peaksecure.net/posts/security-automation-4/</link>
      <pubDate>Mon, 09 Dec 2024 00:00:00 +0000</pubDate>
      <guid>https://blog.peaksecure.net/posts/security-automation-4/</guid>
      <description>&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;The automation examples presented in the previous blog posts, &lt;a href=&#34;https://blog.peaksecure.net/posts/security-automation-2/&#34;&gt;asset data collection&lt;/a&gt; and &lt;a href=&#34;https://blog.peaksecure.net/posts/security-automation-3/&#34;&gt;EASM&lt;/a&gt;, were time triggered.&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;For reading this blog post you should be familiar with the &lt;a href=&#34;https://blog.peaksecure.net/posts/security-automation-1/&#34;&gt;post that introduced the security automation platform&lt;/a&gt; and have a basic understanding of &lt;a href=&#34;https://kubernetes.io/docs/concepts/&#34;&gt;Kubernetes concepts&lt;/a&gt;.&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&#34;sect1&#34;&gt;
&lt;h2 id=&#34;_argo_events&#34;&gt;Argo Events&lt;/h2&gt;
&lt;div class=&#34;sectionbody&#34;&gt;
&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;Argo Workflows only supports triggering workflows manually or via a time schedule. &lt;a href=&#34;https://argoproj.github.io/argo-events/&#34;&gt;Argo Events&lt;/a&gt; can be used to trigger a workflow from a variety of event sources like webhooks, message queues, etc.&lt;/p&gt;
&lt;/div&gt;</description>
    </item>
    <item>
      <title>External Attack Surface Monitoring (EASM)</title>
      <link>https://blog.peaksecure.net/posts/security-automation-3/</link>
      <pubDate>Sat, 07 Dec 2024 00:00:00 +0000</pubDate>
      <guid>https://blog.peaksecure.net/posts/security-automation-3/</guid>
      <description>&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;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 &lt;a href=&#34;https://blog.peaksecure.net/posts/security-automation-1/&#34;&gt;first blog post&lt;/a&gt;.&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;What is EASM? There are definitions from different vendors that offer this as a service, like &lt;a href=&#34;https://www.tenable.com/products/attack-surface-management&#34;&gt;Tenable&lt;/a&gt;, &lt;a href=&#34;https://www.crowdstrike.com/platform/exposure-management/easm/&#34;&gt;Crowdstrike&lt;/a&gt; or &lt;a href=&#34;https://www.rapid7.com/fundamentals/external-attack-surface-management-easm/&#34;&gt;Rapid7&lt;/a&gt;.&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;My own definition of EASM:&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&#34;ulist&#34;&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;Every organization has assets, and some of these assets are exposed to the Internet.  E.g. web application servers, load balancers, VPN Gateways, …​&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;These assets might have known vulnerabilities (CVEs)&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Alternatively, these assets might be misconfigured, like a web application that grants anonymous access or uses a default username/password for admin access&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Ideally, we want to be able to detect these issues across all assets that are owned by the organization&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;/div&gt;</description>
    </item>
    <item>
      <title>Automated Asset Inventory</title>
      <link>https://blog.peaksecure.net/posts/security-automation-2/</link>
      <pubDate>Sun, 01 Dec 2024 00:00:00 +0000</pubDate>
      <guid>https://blog.peaksecure.net/posts/security-automation-2/</guid>
      <description>&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;Asset inventory is considered an essential part of any security program. For example, it is listed as the very first item on the &lt;a href=&#34;https://www.cisecurity.org/controls/cis-controls-list&#34;&gt;18 CIS Critical Security Controls&lt;/a&gt;.&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;/div&gt;</description>
    </item>
    <item>
      <title>Building a Security Automation Platform</title>
      <link>https://blog.peaksecure.net/posts/security-automation-1/</link>
      <pubDate>Sun, 01 Dec 2024 00:00:00 +0000</pubDate>
      <guid>https://blog.peaksecure.net/posts/security-automation-1/</guid>
      <description>&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;/div&gt;</description>
    </item>
  </channel>
</rss>
