Sam King, CA Veracode's EVP of Corporate Development, recently gave a webinar titled Disclosures 2012: The Vulnerability of Publicly Traded Companies. The webinar used CA Veracode's Study of Software Related Cybersecurity Risks in Public Companies, a featured supplement to the State of Software Security Report. In the webinar, Sam examined risk management and disclosure practices for public companies dealing with security weaknesses at the software and application layer.
This post is a follow up to Part 1 of the Webinar Q&A that was posted earlier this week. Without any further ado, we have highlighted the remainder of the Q&A with Sam below.
Q: Are you at more risk with a cloud based application?
King: There is a greater sense of security concern associated with going to the cloud because suddenly companies feel that they are losing control – their data will reside in somebody else’s infrastructure, they might be using an application that is running somewhere else and interacting with other data, etc. But, if you look purely at the application layer and the vulnerabilities in an application that has been written by a staff member versus an application that has been written by a commercial off-the-shelf vendor, we haven’t found there to be that much of a difference. If you look at web applications and non-web applications, the overwhelming result is that common vulnerabilities that are frequently exploited are still occurring at a very high rate. So regardless of whether you’re talking about using a cloud application or buying commercial software from a vendor that is going to run inside your premises, the types of vulnerabilities that exist in these applications are going to be similar. I wouldn’t associate any greater level of concern in the case of the application layer with a staff application versus a commercial, off-the-shelf application.
Q: You mention in one of your slides that we’re not seeing any comparable difference between public companies and non-public companies in terms of the education of developers in the areas that they’re coding. Do you have any recommendations for helping developers learn to develop securely? What has been the effect of this focus on lean development/agile development?
King: We’re a security company, and I think often times security companies adopt a posture towards development teams that is not really conducive to having a productive conversation. The culture has very much been about scanning and coding – “We will scan your application and we will tell you everything that is wrong about it, even though we have never given you any guidance on how to do things correctly in the first place.” You can imagine that that would elicit a less-than-positive response from the party that receives this information. One of the things that we try to encourage organizations to do is to talk to the developer community about things they are doing right, and then talk about areas that require improvement. We actually had a project that we internally code-named “Project Greenlight” where we started including in our reports all the places where we saw developers implementing correctly. You know, “You are sanitizing user info correctly, good job,” and things like that. Then we talk about the areas that they need to go look at where things are implemented in a certain way that could potentially cause a security problem downstream. When you take that even-handed approach I think the response that you get around software security is going to be a little bit more productive, and it becomes a more constructive conversation as opposed to “Here’s everything that is wrong.”
The second thing that I would say is that training absolutely helps. In our State of Software Security Report Volume 4 that we published in December, we actually looked at the relationship between developer knowledge pertaining to application security fundamentals and the security of the applications that they were writing. What we found was that – now this seems intuitive – developers that performed well in the application security fundamentals test were also writing applications that scored higher when we first tested them from a security perspective. Basically, training pays off. Understanding the most commonly occurring vulnerabilities, like SQL injection, cross-site scripting, etc, is not that difficult, and if you impart that knowledge to your development team you will see it pay off in terms of more secure applications being written out of the gate.
If you are interested in Project Greenlight, please go check out that webinar here.
Q: What do you advise that security professionals do in order to make sure that communicating information about risks gets the appropriate amount of attention within an organization?
King: I think that the biggest challenge we have as security professionals is not associated with technology. The biggest challenge that we have is communication. We fall prey to this as well. I talk about many technical vulnerability types, but I think the most important thing is to demonstrate why it matters. I think we have to draw a straight line between the types of breaches that have occurred and the vulnerabilities in our software applications causing those breaches. The more strongly we can connect those two dots, the more effective the message is going to be. What are the consequences of that happening? If you are a company that cares about its brand and you end up losing you customer data – your intellectual property that has a direct impact on your competitiveness - because you didn’t prevent the commonly occurring vulnerabilities, that ultimately impacts your brand. That your management gets. If you are talking about customer confidence in an area where there is increasing competition for companies of all sorts because of the adoption of new technologies, that is an area that your management gets. Tying breaches to the loss of brand and customer confidence and tying the root causes of breaches to the vulnerabilities that exist in our software applications is what helps communicate this to management.
Q: Is there another SoSS Supplement planned? If so, what will be the focus?
King: I think the next one that we do will be the full report that we are going to start publishing annually and then we will likely do a feature supplement around delving deeper into the area of third-party vendor management/third-party risk management. We may potentially do a feature supplement on mobile applications since that is an area that we get a lot of attention on and we have the ability to look at the security of Android applications and iOS applications.