I was going through some tweets last week and came across a tweet by @rybolov touting the most interesting blog post he will read all month about code scanning and regulatory capture. It’s from Mary Ann Davidson, the CSO of Oracle and entitled, “Those Who Can’t Do, Audit.” While I’m not an auditor (and never have been), I’ve performed many-an-assessment in my career so I thought I’d take a look at the re-purposed cliché titled post.
The first thing you will notice is that the post really isn’t about auditors, it’s about static code analysis. If I can distill the meat of the post down (and cull the 2/3s that compose fat/rant), her point is that certain groups have created a FUD-driven market for their products and services based on historical security vulnerabilities in Commercial Off-The-Shelf (COTS) software, but companies should trust their vendors to handle security from within the black box instead of using those FUD-driven products. See, according to her, vendors are in the business of coding securely, not getting features out the door ahead of their competitors and embedding themselves so far into their customers’ businesses that replacing them is too costly((OK, I’m making a bit of a joke here. After reading the post, this is how she came across.)).
Trust is an interesting concept. Americans are overly-trusting and accommodating as a society which is one of the reasons why social engineering works so well. Why should you trust someone? What have they done for you recently and in the past to earn that trust? I can remember many a discussion with my parents after breaking some rule where trust had to be EARNED back. Why should I trust you? You have not demonstrated that you can code securely or at find vulnerabilities effectively((Mary Ann points this out in her discussion around a vendor notifying them of several vulnerabilities in their code.)).
I do want to point out a couple of things she got right. First, the security bugs of COTS software is potentially damaging if the right people got access to it. In addition, tools don’t find every security vulnerability, and often the results are riddled with false positives. Running a tool without manual interaction causes havoc for large software vendors, especially if they are asked to comment on each finding. That is the reason why you pay someone to do it on your terms, with manual interaction, and provide those results to your customers.
Speaking of customers, what about their perspective? If an Oracle zero-day vulnerability leads to a data breach, will Oracle pay compensatory damages to the company? I bet if you go back and look at the Master Services Agreement and the End User License Agreements of Oracle and other vendors, you will find they will not. Seeming less and less like a partnership. If I’m a CIO, COO, CISO, CFO, or CEO, I reject the “Trust us, we got this” attitude and say, “prove to me through some intermediary that I recognize as a trusted authority.” Especially when “all customers get the same information at the same time and the same level of information.” On THEIR terms, not yours.
Sorry big software company, your vulnerability history doesn’t lead me to blindly trust you.
It seems like we need audit to help those that don’t.
Possibly Related Posts:
- Selective Domain Filtering with Postfix and a SPAM Filtering Service
- Preventing Account Takeover, Enable MFA!
- Proofpoint Patches URL Sandbox Bypass Bug
- Improve Outbound Email with SPF, DKIM, and DMARC
- Life after G-Suite/Postini