Disclosures: The Vulnerability of Publicly Traded Companies

Tuesday, June 12, 2012

Fergal Glynn


Article by Nate Lord

Sam King, Veracode’s EVP of Corporate Development, recently gave a webinar titled Disclosures 2012: The Vulnerability of Publicly Traded Companies.

The webinar used 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.

At the end of the webinar Sam opened the floor for questions from the audience. We have highlighted a few of these questions below.

Q: Are these American companies only, or are there international companies as well?

King: The data set includes both US and non-US companies. The majority of these companies are US-based.

Q: Don’t many of these public companies depend on services like Gartner and others for gaging the risks they might be facing?

King: They do. Companies try to get smart on the topic of security in general and on the topic of application security specifically by reaching out to authorities in the space and industry experts such as Gartner, Forrester, the 451 Group, and a bunch of other analyst firms that cover this particular area.

What is lacking is looking at things like what percentage of applications have vulnerabilities like SQL Injection or Cross-site Scripting, or how many SQL injection vulnerabilities per MB of code a company can expect to see if they don’t pay their developers at all. If I do pay my developers, how quickly can I expect to see these vulnerabilities go away?

What we’ve been lacking is quantitative information that helps inform the debate around application security and increase awareness about application. That is what we are trying to fulfill by means of our State of Software Security reports. We want to take this data and use it to shape the conversation around application security so that our attention gets focused on the right things and our investments get made in the right areas.

Q: What is the most common hack that actually results in a data breach or loss of data for a public company?

(click image to enlarge)

King: The data that we have shared in this report is talking about the latest vulnerabilities that exist in software applications. According to the Web Hacking Incident Database, the number two root cause is SQL injection.

After SQL injection is denial of service, and then you really start to see a tapering off of the types of issues that are causing these breaches. You see in very small percentages things like banking Trojans, brute force attacks, and more.

Data from www.datalossdb.org shows a similar picture. Web is at 9%, which is a significant piece of that pie, and hacks, which could be either configuration issues or vulnerabilities in software applications, is at 32%. Together at 41% they compose a pretty big chunk of this pie chart that is caused by (or could be caused by) some weakness in your applications.

That’s really telling you that if you are interested in preventing breaches, protecting data, or data loss prevention (DLP), one of the best ways to protect that data is to go secure the applications that touch that data and provide a pathway to that data.

Q: What are the financial implications if SEC filings are poorly worded? Other than investor confidence are there any penalties that the SEC is issuing?

King: Right now this is a guidance rather than something mandatory that has to be followed. Where the financial penalties come in is what you end up paying in terms of breach cost if a breach happens to occur and other fines that might get levied against you if you are subject to, for example, PCI.

The other thing that you have to consider beyond fines and penalties is other types of downstream activities that you may have to engage in if a breach occurs. There is a precedence set by the FTC where they will file lawsuits on behalf of consumers when companies have lost consumer data as a result of these types of infrastructure weaknesses.

Again, that is public information – if you go to www.ftc.gov you can actually see a listing of all the different lawsuits that the FTC has brought against companies. In certain instances, there are explicit descriptions that say things like “there was a SQL injection vulnerability in a web-facing application that led to the compromise of thousands of records and poses a problem for consumers.”

When you see the language get so specific in these lawsuits, it means there is a great risk that if you are not preventing these vulnerabilities from occurring in your application, you open yourself up to having these types of lawsuits being filed against you.

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.

(click image to enlarge)

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.

Cross-posted from Veracode

Possibly Related Articles:
Enterprise Security
Information Security
SQl Injection Enterprise Security Risk Management Vulnerabilities Full Disclosure ROI Secure Coding Cross Site Scripting
Post Rating I Like this!
Daives bursten Training the developer do help. Impact of vulnerabilities like SQL Injection, XSS, CRSF are hard to mitigate then the vulnerabilities at the development stage itself.
It is difficult to calculate the ROI of vulnerability assessment.
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.