DevOps could be viewed as combining development and operational efforts to increase the speed, efficiency, and security of application development and delivery. While the benefits of speed and efficiency are commonly associated with DevOps implementation, security aspects are often overlooked or undervalued. However, it is crucial to recognize the significance of security in this context. One might question whether DevSecOps addresses these concerns. Indeed, it should. However, in practice, security considerations are frequently introduced late in the process, long after decisions regarding code repositories, infrastructure, image promotion workflows, and other elements have been finalized.

Why does the security team tend to be the last to be informed about a process that could bring substantial benefits to all business units by enforcing policies in an automated fashion, saving time and effort for numerous teams company-wide? One possible reason is that security teams have been perceived as resistant to change, often seen as obstacles to technical initiatives that deviate from existing policies and guidelines.

In the past, this might have been the case, but there has been a shift in thought regarding security over the last 10 or so years. Changes in reporting structures, participation in quarterly governance meetings, and even the composition of board members reflect this evolving mindset. 

‍

Automation has played a pivotal role in the security landscape over the last 6-8 years, leading to the integration of developers into security-focused groups. These automation initiatives encompass diverse responsibilities such as log correlation and aggregation, executive summary dashboards, and the integration of Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) data into the Software Development Life Cycle (SDLC) process.

While most security groups have embraced the benefits of automation while, they have also experienced an epiphany. They recognize that automated enforcement of policies and standards has the potential to save hours of valuable time each week for all involved teams.  However, achieving this requires a cultural shift encompassing development, operations, and security.  During this transformative phase, numerous questions arise: Where should we begin? What will be the altered responsibilities? Who will assume ownership of these responsibilities? Will new processes be necessary, and if so, what will they entail? Will these processes align with existing policies?

Before delving into the steps that security teams should take, it is essential to address a critical decision that should have been made prior to embarking on this journey. Who will serve as the security champion within the development group that will help facilitate information sharing? A security champion is an individual who keenly observes potential issues that internal security groups should be aware of. Normally, they have already been selected, even if they are unaware of their designation. They are normally the ones that contact the security team to alert them of issues such as unsanctioned languages/packages being used, shadow IT being discovered, or the first people to contact the security team to provide feedback on quarterly phishing campaign.

Having a security champion in each technology group can help tremendously with staying informed about various technological initiatives undertaken throughout the company. This collaborative approach facilitates resource allocation for security initiatives across the entire DevOps adoption. When selecting a candidate, several factors should be considered, including their respected position within their work group, their influential voice in influencing teams, and their ability to foster positive working relationships.

Understanding how the development team intends to leverage the DevOps workflow is essential so another crucial action for the security team is to begin asking questions to determine reach that understanding. Important aspects to consider include deployment models, artifact repository, access models, and change management. These items need to be thoroughly discussed to gain a comprehensive understanding of the changes required. Additionally, this provides the security team with ample time to design automated solutions that can seamlessly integrate into the proposed workflow. Some examples of these solutions include configuration checks, code analysis, and vulnerability assessments, among others.

With the information gathered, the security team can proceed with designing and leveraging architecture that enforces controls while continuously monitoring and auditing configuration drift in an automated fashion. This proactive approach mitigates issues due to the environment being out of compliance with policy. Additionally, it enhances the efficiency of all security teams involved, including compliance, incident response, cyber, threat intelligence, and application security.

In conclusion, I have shared my evolving mindset over the course of my 14-year tenure in the industry. I've transitioned from a "default deny" mindset to a more comprehensive approach that involves asking critical questions before resorting to a default deny response—just kidding. I strive to evaluate how new technological endeavors can improve business operations from a security standpoint while simultaneously maturing and enhancing the overall security program by adhering to policies, standards, and guidelines through automated workflows. Furthermore, I hope to reshape the perception of security professionals among our counterparts, enabling us to be involved in the early stages of technological solution research within the environment.

‍

‍

Author: 
Asher Collings