Miscommunications Between Security Teams and DevOps Teams Put Your Business at Risk
Daily, businesses are bombarded with risks from physical and financial to strategic and operational. Communicating these risks to employees is critical because it helps the organization sense and respond to threats as a cohesive unit. This communication also needs to encompass the IT, security and DevOps teams. Assuring that these teams have a clear understanding of where application security fits on the spectrum of business risk will go a long way towards helping developers understand their role in addressing security risks. On the flip side, a failure to communicate puts the entire business in jeopardy.
The adoption of DevOps is usually driven by business units striving to do more with less, while maintaining internal innovation and a keen responsiveness to customers. Ultimately, the fear for most leadership teams is that their company’s competitors will be more innovative and in their quest to keep up, they instead alienate customers, resulting in the loss of a sale. The security team is often on the trailing end of DevOps initiatives and not able to stop them. At best, they find themselves able to influence.
For security teams to properly communicate with business units – and DevOps teams – they need to understand where application security fits into the spectrum of risks the businesses prioritize. Accomplishing this will elevate the security team to the position of trusted advisor on matters of information risk. However, if they are unable to understand these risks they will likely be marginalized because too much security hurts organizations.
To avoid communication failures, first understand what development teams do not need from security. For instance, blanket “best practice” guidance divorced from technical reality such as, “encrypt all the data in the database”, is not helpful. Standards need to be appropriate for the application and actionable by the development teams. Security teams with little or no development experience often fall into this trap.
Additionally, if security testing is being performed, vulnerability information without curation is damaging. Tools produce false positives. These are situations where vulnerabilities have been identified, but the “vulnerabilities” reported do not reflect true weaknesses in the systems or software. Tools also misreport the severity of vulnerabilities they identify, leading to poor prioritization. When communicated to DevOps teams, false positives and mischaracterized vulnerabilities waste time and erode the credibility of the security organization.
In the best case, communicating vulnerabilities without context and support results in vulnerabilities not being fixed. In the worst case, development teams waste time applying ineffective fixes. Application security can be arcane and many development teams are not able to understand vulnerabilities without help. If they do not understand the information, they will not be able to properly assess the risk of vulnerabilities and will likely not know how to resolve them. Context and support are critical for development teams to be successful.
What do DevOps teams need in communications from security teams?
When security teams communicate vulnerabilities to developers, the vulnerabilities must be true positives that have been properly risk-scored, with explanations of their impact to allow DevOps teams to better evaluate. Targeted remediation advice is critical and it needs to be as specific as possible to the languages and frameworks used by the development teams. This makes it easier to address issues. Time spent fixing vulnerabilities is then efficient, vulnerabilities can be fixed in shorter time, and effective, vulnerabilities targeted for remediation are successfully fixed on the first try.
Security teams can also provide valuable guidance on the governance and compliance impact of vulnerabilities. If there are fines or service shutdowns that occur as a result of these issues, development teams need this information – characterized in plain terms – so that they can prioritize properly.
Expanding beyond communicating vulnerabilities, security teams can communicate system architecture advice on how applications can be better designed to remove aspects of the system from being in-scope for compliance requirements. For example, offloading card processing to a trusted 3rd party can remove systems from the requirement to be evaluated against the PCI-DSS. Another example is avoiding storing unnecessary personally identifiable information (PII) to avoid the risk associated with being a steward of that data. Marketers often want to store all the data they can access, but system designers need to understand the privacy and security impact – and the associated risks – of storing excessive data.
Miscommunications between security and DevOps teams put organizations at risk. Security teams must be able to communicate where application security fits into the spectrum of risks that affect a business. When a security team can assess these risks from all aspects – brand, financial, strategic – then they are best able to act as a trusted advisor to the DevOps team as they build and maintain secure systems.