ÀÖÓ㣨Leyu£©ÌåÓý¹ÙÍø

Security operations monitoring in the traditional sense is often a beaten path for most large organizations.  What’s new for many however, is applying the concepts of automated, real-time alerting and streamlined responses to the fast-paced, rapidly changing landscape of DevOps.

Why is this important?

In the winter of 2020, the SUNSPOT malware demonstrated how sophisticated attackers may target software vendors. After achieving a foothold inside of an organization, attackers can compromise a build pipeline so that customers of an affected company’s software may be subject to compromise as well. So how can an organization monitor the integrity of their software build process to increase detection of malicious activity?

Where do I start?

What knowledge would make you feel better about your software development infrastructure itself, in addition to contributors and processes? Can you develop a list of questions that you’d like answered for each of the major steps in the build process?

Here are a few examples of security monitoring questions that may help identify potentially malicious behavior in software development:

In this approach, which some may refer to as automated governance, it goes without saying that not all use cases are equally attractive. What makes a use case better? Analyzing use case attributes like “ability to reduce risk� and “level of effort to implement� will help identify a first set of more valuable use cases. Another round of prioritization could come from answers to questions about the monitoring use cases such as:

• “Is the responsibility of this monitoring use case already addressed or made moot by a cloud-based Software as a Service offering in use?â€� If the answer is ‘yesâ€�, perhaps the build pipeline use case is deprioritized compared to others.
• Is this monitoring use case actually something we would alert on or just want to capture as an attestation (a declaration of evidence) for later use, such as in an audit?â€� If the answer is ‘just capture as an attestation for later useâ€�, perhaps the build pipeline use case is deprioritized compared to others.

The goal of putting your first few build pipeline security monitoring use cases in production should be to learn the process of their implementation, not inspire complete assurance of build pipeline. You may even include the buildout of such monitoring use cases as part of your organization’s regular security champion dialog or hackathons. If you crowdsourced the buildout of some such use cases to engaged security champion developers, is one new use case per month realistic? And of course, consider sending alerts from such monitoring beyond the classical security operations team to the developer teams� real time instant messaging collaboration tools. When done well, this can increase security awareness among broader development teams who may not yet consciously prioritize security and minimizes unnecessary “hand offs� � a core tenet of the “First Way� of DevOps and key to increasing process flow.

The suggestions above should provide a framework for what to monitor in your developers� build activity, how to implement them, and who gets alerted when something potentially malicious is identified. As more build pipeline monitoring use cases are implemented, confidence that your build pipeline and software development is trustworthy increases, the likelihood of serious security events decreases, and you can focus on innovation and delivering value to your customers.