Three steps to improving DevOps security

As Australian organisations increasingly embrace a DevOps strategy, many are becoming aware of the risks it poses to IT security.

DevOps, a set of practices that automate and integrate the efforts of software development and IT teams, is designed to streamline processes and get new applications up and running more quickly. It involves continuous integration and continuous delivery (CI/CD) mechanisms that get code into production environments faster than traditionally.

While this can offer significant benefits for an organisation, it can also cause issues when ensuring effective security. Throughout the DevOps process, it is essential to continually assess whether cybercriminals have injected malicious code into the environment, yet the nature of DevOps can make this a challenge.

There are specific areas where attackers can interface with CI/CD, and identifying ways to prevent these attacks is increasingly crucial. For this reason, deception and denial techniques have emerged as an effective way that IT security teams can get the job done.

A deception and denial strategy aims to divert an attack before a cybercriminal can access an organisation’s IT infrastructure. The best way to understand how the approach can work is to break down DevOps into four distinct phases:

  • Phase one – plan:
    This initial phase takes place mostly offline. However, there are still opportunities to deploy deception techniques such as placing decoy file servers or code repositories. Active development necessitates using active code repositories, and cybercriminals can potentially get access to that code, alter it, and spread malware to every system on the network.

    Taking time to deploy fake code repositories, decoy documents, and other deception assets can derail these attempts. Also, because DevOps uses web-based project management tools, introducing decoy tool instances can misdirect attack activities. It’s also possible to use decoy network shares that point to file servers.

  • Phase two – build:
    The next phase is where the actual software development activity begins. CI/CD solutions automate the build and test cycles, and attackers may go after the development infrastructure, target operating systems, exploit Active Directory, or otherwise attempt to disrupt development using tools such as PowerShell.

    Attackers are usually looking for specific servers, such as code repositories, and do so by conducting Active Directory reconnaissance. For this reason, the deception assets introduced during the plan phase now gain significance, as the build phase is when attackers actually attempt to infiltrate them. IT security teams can also opt to set up a decoy Jenkins server or GitHub code repository for attackers to target instead of the primary systems.

  • Phase three – deploy:
    Naturally, computer code doesn’t deploy itself. Those wishing to deploy it must have the appropriate rights to let the operating systems execute the code, which means that they will be using credentials, keys, or access tokens of some kind. Attackers will look for these because some developers may hard-code credentials into files that are not secure. If attackers gain possession of these credentials, they can obtain access to the entire code deployment and have sufficient rights to deploy any code they want to any system.

    For this reason, creating decoy configuration files or credentials and embedding them in configuration files is helpful. The recommendation is to use these alongside the secure method of adding passwords to configuration files. Putting deceptive credentials alongside the real access method is a great way to trick and derail an attack.

  • Phase four – operate:
    The fourth phase is the one in which testing and observation occur. If a cybercriminal has gained access to the network, the decoys now come into play. Attackers will attack network decoys because they mimic the standard production endpoints, thinking they are targeting another system to deploy their custom malware.

    Once deployed, endpoint lures can lead attackers to the decoy systems. Looking for misconfigurations to remove stolen credentials for CI/CD systems (especially those sitting on developer endpoints) can also reduce the overall attack surface.

Constant engagement is key

Throughout all the steps that occur during the CI/CD cycle, there are opportunities for cyber deception steps to protect against attacks. However, it’s important to choose the most appropriate deception and denial tools to get the job done. Not all tools can engage attackers during every phase of the DevOps process.

The most effective way to detect and prevent DevOps attacks is to have the means to catch cybercriminals before they can strike. For this reason, deception and denial are the most appropriate strategies that an IT security team can use.