Many are running some form of DevOps, however, not all are âdoing the basicsâ when it comes to security. Sure, it functions, but can something catch you out later down the line?
Below are some of the main principles that organizations should be running, if DevOps is adopted.
Getting The Basics Done
1. Build a security-focused culture: Foster a mindset where security is ingrained in every step of the development process, from initial design to deployment and ongoing maintenance. Encourage collaboration between development, security, and operations teams to identify and address security risks early on.
Security canât be involved in the last step. It has to be embedded and understood by all. The understanding part is easier said than done, and for those running âas isâ, selling the notion of âsecurity wonât interfereâ isnât an easy task. Highlighting the whys, and showing a clear strategy will reduce the friction, however, as it wonât feel like youâre implementing security to tick a box.
2. Adopt a DevSecOps approach: Integrate security practices into the DevOps workflow, making security an integral part of the continuous integration and continuous delivery (CI/CD) pipeline. This enables automated security checks and vulnerability scans to be embedded into the development process, proactively identifying, and resolving security issues before they reach production.
Step one was more around people. This step is more about action. Talking about security doesnât stop the bad guys, so itâs important that strategy and design are tangible. Frameworks and baselines may look good, however not all fit every environment. Following common security methods and being too strict wonât fly with DevOps. Understanding needs to go both ways, and Security teams need to understand that balance is key. Developers canât jump through lengthy checks and boundaries every time they commit.
3. Automate security testing: Utilize automated security testing tools to perform static and dynamic application security testing. Static application security testing (SAST) analyses source code to identify potential vulnerabilities, while dynamic application security testing (DAST) scans running applications to detect vulnerabilities during runtime.
Make sure automation is at the heart of any design. Guardrails and governance are great, but if they require large amounts of manual effort; they will fall flat. Automation is your savior. Look for tools that allow you to configure your boundaries to meet your risk appetite and automate responses to multiple instances. These automated checks may still require manual effort; however, this should be at the end of the line, or odd/special circumstances.
4. Employ infrastructure as code (IaC): Use IaC tools to automate the provisioning and configuration of infrastructure resources, ensuring consistent and secure deployment environments. IaC enables the versioning and auditing of infrastructure changes, making it easier to track and roll back changes if necessary.
What it also does is bridge the gap between infrastructure and developers. In most organizations, multiple towers will be involved in setting up the requested infrastructure, and the developer is given the result. Often this is time-consuming, and far too disjointed to be called âleanâ. Instead, look to automate as much of the manual tedious effort as possible. Building resources in the cloud, could be done by a person, however, if itâs just rinse and repeat, couldnât this be templated in code, and shared?
This doesnât mean migrating every process into codeâââthat doesnât make sense. Instead, target key areas and start to build a registry as you go. That way, there is more of an understanding, than just doing it because.
5. Define Repo Security: As soon as you start hosting code, that repo becomes a target. There should be a clear understanding of how your organization is going to interact with your repo. This includes setting network and access limitations to ensure your repo is being accessed from locations/ devices you trust.
Threats donât just come from the outside. Accidents, negligence, or disgruntled employees can occur. Controls can be put in place to reduce damage, such as:
- Blocking direct changes at main.
- Enforcing access reviews (Includes QA for Prod).
- Separating out key templates and only allowing them to be referenced (not modified).
Remember, these are just some of the core basic principles that will need to be adopted. Taking the time to define a clear path forward, and having Security embedded in the roots will only bring benefits.
DevOps and DevSecOps arenât just processes that you can enable with a toggle. They take time to mature and get right. Itâs a journey. Just make sure all key players are coming along.
Amoranio đ 
Leave a comment