Problems With Sharing Responsibility for Security
CEOs, boards of directors, DevOps, developers — it seems like everyone is responsible for security except for actual security teams. Our review of recent industry studies shows how confusion about job roles is causing potentially damaging conflict.
A new survey by Scale Venture Partners finds that 65% believe that someone in the C-suite is ultimately accountable for security. A majority of C-level executives would be understanding and help the security team in the event of a significant security breach, but 29% of chief information security officers (CISOs) in U.K. domain name broker Nominet’s latest report also believe the employee or contractor responsible for the breach would be fired. With their jobs on the line, security professionals are skeptical that cybersecurity is everyone’s job.
The latest “EY Global Information Security Survey” of senior business leaders found that there is mutual trust between security and IT teams at 80% of companies, but less than 40% can say that about security’s relationship with R&D and product development teams. The report highlights the fact that 36% of companies have cybersecurity teams join new business initiatives during the planning stage. Another 27% of companies get security involved in the design phase, with another 21% joining new initiatives in the build, test, or deploy stage. Given these results, it appears that companies are at least giving lip service to security teams’ importance.
Last year, we noted pockets of significant friction when security and non-security teams collaborate. In particular, companies in the midst of expanding DevOps have people in security roles discussing problems with these relationships. However, in that same study, from Snyk, 86% of the security-focused respondents believe security is a joint responsibility between security and “delivery” teams.
Yet another survey, this one by MongoDB, found disagreement among European developers and IT decision-makers (ITDMs) about who is most responsible for securing an application throughout its build. Twenty-nine percent of developers think the developer that built an application is most responsible. ITDMs are more likely to say a security specialist they are able to identify is most responsible (28%) and less likely to say cite developers (21%). It is worrisome that 12% of all respondents say that an unidentified security specialist is responsible — how can an unnamed, unknown team be held accountable?
MongoDB also found that 92% of developers believe they take appropriate precautions when building new applications. If developers are doing everything right in the build phase, perhaps security vulnerabilities in software dependencies are most problematic only as production applications age and need to be maintained. Or, maybe the security of cloud infrastructure is at the root of new threats.
Integrating security into build processes signals a DevSecOps tipping point, but the conflict between developers and security teams will continue as DevOps processes mature. We know developers overwhelmingly accept some responsibility for application security but lack time to address security effectively. Automation of scanning and testing into developer-centric helps reduce the likelihood and severity of security incidents. However, without specific key performance indicators (KPIs), developers are only vaguely held to account for security problems.
Security may be different in today’s cloud native world, but the bottom line of risk avoidance is constant. In the coming weeks, we hope to explore how DevOps practices are addressing security issues, especially in regards to problems with misconfigured cloud infrastructure.
MongoDB and Snyk are sponsors of The New Stack.
Feature image by Steve Buissinne from Pixabay.