How can you assess the maturity of security practices in DevOps?

Devops and security integration was destined to become a major focus for projects. Now we have a name for this integration and its called DevSecOps. One key implementation of DevSecOps is to integrate security inherently into every phase of the project and not to see its as a separate process or project phase. Depending upon your underlying architecture, there are various security modules that have matured into production grade solutions for devops. Gone are the days when people wanted to follow best practices for security. Now we have to adhere to a model and implement its guidelines with CI and CD phases to get release ready.

Assessing the maturity of security practices in DevOps involves: Policy and Process: Evaluate the presence & effectiveness of security policies/processes integrated into DevOps workflows. Automation: Assess the extent of security automation, including vulnerability scanning, code analysis & automated compliance checks. Shift-Left Security: Analyze how early in the development cycle security is addressed (shift-left), focusing on secure coding practices. Security Testing: Evaluate the use of security testing tools & practices, such as SAST, DAST, SCA & penetration testing. Access Control: Examine the implementation of least privilege access & IAM policies. DevSecOps Integration: Security integration into the DevOps pipeline as a process.

Deny everything unless needed. Go by the thumb rule when you’re setting the security culture and awareness with your processes. So many mistakes can be avoided just by awareness as most of the times the security issues are encountered just because someone had the privilege but not the awareness and accidentally put the entire project on jeopardy. Make people aware by showing them the consequences of their mistakes and educate them on the standards by following a set model. Never implement security as custom adhoc procedure.

Devops is all about automation and if we want security to be integral to Devops then it has to be managed automatically via tools and softwares. Follow the following guidelines: 1. Restrict access via roles and Active Directory to the infrastructure 2. Use scanning tools like sonar, blackduck to automatically identify CI issues 3. Monitor CD pipelines and implement deployments only via designated roles 4. Continuous scan your infra with tools like falcon and nuevector to check state of deployed binaries. Most importantly nothing can go undetected when there is an issue so make sure dashboard and radars are properly integrated

There are tools in market that can define a maturity curve for your products with respect to security. Make use of tools like skyhigh that can provide a very simple evaluation process. Key here is to not take manual or personal advice to justify feedback’s. Use tools to improve your overall quality of security and define your priorities based upon the feedbacks you get. Security feedbacks are different from other types of feedbacks, here let the system determine the severity and the priority too.

Security governance comes very handy in defining accountability. In simple words we need to define who is going to do what and thats the simplest way to define governance. Start by having the objectives and roles defined and then use the feedbacks of the previous stages to adapt to new situations and requirements. Key element here is to have singleton definitions and reduce overlaps.