Authored by: Carolyn Crandall, Chief Deception Officer, Attivo Networks – DevSecOps has become a hot topic in the cybersecurity community as organizations increasingly turn to DevOps for software development and IT operations. The continuous nature of DevOps development allows attackers the opportunity to insert malicious code that will then deploy throughout the network. The Continuous Integration/Continuous Delivery (CI/CD) mechanisms upon which DevOps operates present attackers with new ways to infiltrate the network. Deception has emerged as a pivotal way to mitigate those risks and address the challenges of securing DevOps environments.
DevSecOps means adding security to the DevOps cycle. DevOps, which combines application development with infrastructure deployment, has become increasingly important in today’s world, providing more agile functionality that allows developers to receive constant feedback on their code, enabling continuous improvement. Integrating security into the system means inserting it between the development side and the operations side. Creating a DevSecOps mentality can be challenging, as development has no inherent security requirement, and injecting it just before deployment will often result in shortcuts being taken that sacrifice security in favor of speed to market.
Throughout the development process, it is critical to continually assess whether attackers have introduced malicious code into the environment. There must also be checks and balances so that, if an attacker succeeds, there is a way to learn about it quickly. Unfortunately, in many cases, the answer to “How do you know?” is, “You don’t.” Code is text, and the best way to review code is still to eyeball it (this is why open-source software is generally considered more secure: there are more eyeballs on it). If a user can “commit” or finalize code, no one will know that they have inserted additional code without a thorough review. This awareness gap is why checks and balances exist to dictate who can look at or audit code. Development teams will also want to know if an attacker has gained credentials with the authority to commit code. Unchecked, these attackers can likely insert malware at will.
This possibility represents a severe problem. Since the best way to infiltrate a DevOps environment is to obtain the appropriate credentials, attacks on DevOps can start small—perhaps even as phishing attacks—to gain an initial foothold. And when attackers target code repositories, they may not just be after your code. They may be looking to ensure that they have a future foothold anywhere the application in development deploys. As a result, the ability to detect and derail these attacks before they can gain a foothold and deploy malicious code is critical. Deception technology is an innovative and increasingly deployed technology that gives defenders unique and non-invasive tools to work with during every DevOps phase.
One can look at DevOps in terms of four primary phases: Plan, Build, Deploy, and Operate. The Build, Deploy and Operate phases are where deception sees most of its use in a DevOps environment, although there are still opportunities to use cyber deception in the Plan phase. Below is an overview of these stages, as well as how attackers might try to affect them and how deception can derail them.
- Takes place primarily offline and involves laying the groundwork for development.
- Attackers will try to gain access to code, make alterations, and spread malware throughout the network.
- Fake code repositories, decoy documents, decoy network shares pointing to file servers, and other deception assets are useful here.
- Often uses Web-based project management tools to manage DevOps projects, and security teams can create fake instances of those tools.
- Where software development starts.
- Attackers will try to attack computers, target operating systems, AD, or other areas where they can disrupt development.
- Attackers will perform AD reconnaissance in search of high-value servers and code repositories.
- Fake repositories, decoy network shares, and other deception assets deployed during the Plan Phase can derail attackers here.
- Decoy Jenkins servers or Github code repositories also make attractive targets for would-be attackers here.
- Where those with appropriate rights deploy code.
- Attackers will attempt to acquire credentials with the authority to execute code.
- If attackers gain the right credentials, they may gain access to the code deployment to modify and distribute code throughout the system.
- It is best to use deception alongside other security methods, such as adding single-use passwords to configuration files.
- Defenders can embed decoy credentials in configuration files and place deceptive credentials alongside the real ones to trick attackers.
- Where testing and observation happen.
- Attackers will target production endpoints in the hopes of spreading their malware to other systems.
- If defenders have deployed network decoys appropriately, attackers will target these instead of the actual endpoints. Endpoint lures can then lead attackers to decoy systems.
- Since compromised credentials are an essential part of how attackers target DevOps, looking for misconfigurations and stolen credentials sitting on developer endpoints can further reduce the attack surface.
Building a Secure DevOps Future
DevOps is a cyclical, multi-phase process, but deception technology can step in to detect and derail attacks during every stage. Deception solutions offer organizations innovative new ways to secure their software development and IT operations. The comprehensive suite of deception and denial tools that Attivo Networks offers can help identify attackers targeting DevOps before they can strike. As DevOps grows ever more popular across a wide range of industries, these advanced detection and denial capabilities will only become more critical