Last updated at Tue, 26 Sep 2017 14:30:56 GMT
"Words matter” is something that comes out of my mouth nearly each day. At work it matters how we communicate with each other and the words we use might be the difference between collaboration or confrontation. The same happens with the security world, especially when we communicate with folks in IT or within the devops methodology. Last week this became highly apparent sitting with folks attending OWASP's annual AppSec USA, where they discussed the difference between a fix or fail.
The problem, in our world, often stems from the fact that security is oftentimes a scary concept, conjuring up thoughts of clowns lurking in the woods on the walk to school (my therapist told me to express my fears outwardly). Security means something is at risk and that if it doesn't get fixed immediately the world may come to a frantic halt. The truth, however, is that not all security threats are created equal and in most cases the need to prioritize fixes can eliminate the panic. The challenge is actually how security threats or vulnerabilities are presented to those outside of security. Imagine what a "security vulnerability report" does to the devops folks working the app your business uses to bill customers?
For years we've focused on finding all the vulnerabilities, prioritizing them based on business and threat context, and then ultimately throwing them over the wall to IT or devops. But security has been learning how to more effectively create a remediation workflow. In some cases this means true management of the workflow, analytics that tells you if a vuln has been patched, or dashboards fed from live data so decisions are made at the point of impact. All that stuff is great, but what if I said you also must have a reframing of what the word "security vulnerability" actually means?
Security Vuln or JIRA Ticket?
Back to my time with the OWASP crew in DC; and I'll be fully transparent that this idea came to me as I spoke with Rapid7 application security customers (check out AppSpider for more info). We talked a long time about the importance of collecting all the right application data for scanning and then prioritizing the vulns found. But the part of the conversation that really turned around my thinking was when we got to remediation. The functionality that these customers liked the most was the ability to not throw over a 2,300-page stale report (true story!) but instead translate found vulnerabilities directly into the devops ticketing system.
In this case it was a simple measure of taking what was found via application security testing and then placing that, with context, into JIRA. All of a sudden the devops team had a list of high-priority bug fixes, which they valued and would get to quickly, rather than a big security report that seemed to be more blame-game rather than helpful.
Words matter in security, as does intent. It's an important thing to consider as you build our your security program and discover the points of contact with IT and devops.
