Securing DevOps Using Deception and Denial

Source:-https://securityboulevard.com

As organizations increasingly utilize DevOps for software development and IT operations, DevOps environments have become a priority target for would-be cybercriminals. Throughout the development process, it is critical to continually assess whether attackers have injected malicious code into the environment, and the nature of DevOps development can make this a challenge. DevOps works according to continuous integration/continuous delivery (CI/CD) mechanisms, and there are specific areas where attackers can interface with CI/CD. Identifying ways to derail those attacks is a critical part of DevSecOps, and deception and denial technology has emerged as a valuable tool capable of mitigating risk during each phase of DevOps development.

Deception and denial technology steps in to divert attack tactics such as credential access, when attackers steal credentials that point to CI/CD systems; AD reconnaissance, which can allow attackers to find CI/CD servers; and lateral movement and privilege escalation, which can enable attackers to own the CI/CD systems. Breaking down DevOps into four distinct phases (plan, build, deploy and operate) is a helpful way to illustrate the potential value of deception and denial. Each phase has areas where the technology can derail attackers attempting to infiltrate and exploit DevOps environments.

DevOps and Security: A Look at Each Phase
Plan Phase

Although the Plan phase takes place primarily offline, there are still opportunities to deploy deception, such as placing decoy file servers or decoy code repositories. Active development necessitates using active code repositories, and attackers can potentially get access to the code, alter it and spread malware to every system in the network. Fake code repositories, decoy documents and other deception assets can derail attackers. It’s is also worth noting that because DevOps uses web-based project management tools, fake instances of those tools can act as decoys. Breadcrumbs can deploy to the endpoints, pointing to decoy systems. One can also use decoy network shares that point to file servers. And this is just the planning phase; once the build phase begins, things really get going.

Build Phase

As its name implies, this is where actual software development starts. CI/CD solutions automate build/test cycles, and attackers may seek to go after computers, target operating systems, exploit Active Directory or otherwise attempt to disrupt development using tools such as Powershell. Attackers are looking for specific servers, such as code repositories, by doing AD reconnaissance. The deception assets laid down during the plan phase come in handy here, as the build phase is when attackers actually attempt to infiltrate them. Defenders can also set up a decoy Jenkins server or GitHhub code repositories for the attackers to target instead of the primary systems.

Deploy Phase

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 in some way, they will be passing credentials, secrets, keys or access tokens of some kind. Attackers will look for these because some developers may hard-code credentials into the relevant files, which 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.

Creating decoy configuration files or decoy credentials and embed them in configuration files is helpful. It is best to use these alongside the secure method of adding passwords to configuration files—a one-time use password for each run of the configuration is effective and secure. Putting deceptive credentials alongside the real access method is a great way to trick and derail attackers.

Operate Phase

This phase is where testing and observation happens. If an attacker has gained access to the deployment or the CI/CD system, the network 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 attack surface.

Putting It All Together
Throughout all phases of the CI/CD cycle, there are opportunities for cyber deception to help derail attackers—but choosing the right deception and denial solution remains important. Not all deception solutions can engage attackers during every phase of the DevOps pipeline. Understanding the specific ways in which deception and denial can operate within a DevOps environment can help organizations ask the right questions when identifying the right solution for them. Look for a provider with a comprehensive suite of deception tools that can help derail attackers in every DevOps phase through a combination of lateral movement tracking, fake credentials, network decoys and other essential deception tools. The best way to deal with DevOps threats is to detect them before they can strike—and deception and denial remain the ideal way to do just that.