News & Commentary

2/9/2016
01:30 PM
Kunal Anand
Kunal Anand
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

How (And Why) AppSec Is Important To Your Business

WhiteHat founder Jeremiah Grossman and Prevoty founder & CTO Kunal Anand share their perspectives on the past and future of application security.

At the OWASP Conference in San Francisco, WhiteHat Founder Jeremiah Grossman and Prevoty founder & CTO Kunal Anand discussed the importance of application security, the most critical AppSec vulnerability, and how two name-brand companies influenced their views and careers. 

Second in a series of Dark Reading interviews with cybersecurity experts by cybersecurity experts.

Kunal Anand: Why are companies doing such a bad job fixing vulnerabilities?

Jeremiah Grossman: Really, most of the time, it comes down to just a raw development environment ROI. [CIOs/CSO] have a choice to make, a very difficult choice. Do they create revenue-generating features that if they don't ship, will for a fact, cost the company money or do they decide to use those limited development resources they have to fix vulnerabilities that might get exploited and might cause the company money.

KA: I think about legacy applications as a brush fire waiting to happen. The thing that we noticed is that legacy applications have lots of problems -- and the developers who worked on them aren't at the company anymore. There are no budgets associated with it. No one knows in some cases where that code even is. It's just this thing that's running in a production environment.

KA:  What would you say has been the biggest change in application security over the last five years, or even 10 years?

JG: I think the biggest change in the threat landscape is SQL injection, which first came on the scene Christmas day 1998. Today, it’s the vulnerability that's causing us the most grief. Bad guys didn't start using it really until about 2005 or so, or maybe even 2007, [and] we've had the vulnerabilities in websites for 10, 15 years or more. We've all known [about] it, but a lot of us [who’ve] been around in application security for a while, were always wondering when [SQL injection attacks were] actually going to happen. Well, they happened [within] the last three to five years.

KA: What are you seeing from the boardroom? Are board members starting to care more about security?

JG: It's only been in the last 18 months that there actually seems to be board-level interest. I'm getting pinged, "Can you come talk to our board about this cyber security stuff and explain the landscape?" They want to know what questions to ask, how to read the answers and those sorts of things. I think the reason is because the losses are now very big. I mean $100 million plus lawsuits. CEOs getting fired. Class action lawsuits.                           

KA: Applications are the center of everything and you could argue that applications are your business. Is it [too] much of a stretch to say an attack on your applications is an attack on your business?

JG: It's probably pretty close. If the business asks, “If we turned off the website, how much of our business would go away? Then you'll know [from the answer] what the apps mean to your business. For some companies, it's 5%. Some none. Some, it's everything. 

Image Source: Prevoty
Image Source: Prevoty

KA: How did you get started in application security? 

JG: Application security found me, I didn't choose it. One day, summer '99, somebody had found vulnerabilities in Yahoo, eBay and Amazon and I couldn't figure out why this was newsworthy because I thought everybody already knew websites have little bombs and that no one exactly knew how to secure them.

Everybody has hobbies. Paint pictures. Play video games. I break software. That's what I do. Because of the vulnerability in Yahoo mail, I went home and I signed up for a new Yahoo mail account and then I proceeded to hack into my own Yahoo mail account.  It took me about 50 minutes and in a way I guess you could say I was breaking into 120 million other people's Yahoo account.  I told Yahoo what I found. I sent them an e-mail anonymously and they reported back saying, "Thank you very much. Let us know if we can send you a t-shirt." For me that was awesome. I was in cloud nine. I get to hack in Yahoo and get a t-shirt. It's great and they said, "Let us know if you find out any more." I said, okay, and by another week goes by, I dropped another half dozen issues on them.

I was curious about who I was communicating with over there and (found out) it was one of the two founders of Yahoo, who was David Filo, and I was blown away. Those emails actually led to a job at Yahoo doing what I do for the rest of Yahoo. Web security wasn't a term back then. Application security wasn't a term back then and so, that was really, really the start of the industry and the start of my career.

KA: My start in application security is totally different. I had no concept of application security or security at all. I started off my career at NASA GPL and I worked there as a software engineer across lots of different projects. There was a big company in Los Angeles that was up and coming: MySpace. I always have a hard time when looking people in the eye and telling with a straight face that I went from NASA to MySpace.

At that time, the Samy worm had already happened. Security was obviously an issue at MySpace, and so I jumped in and Dan Kaminsky taught me everything about application security. I did not know anything at all about cross-site scripting, SQL injection. Dan and I worked together to try and eradicate cross scripting for MySpace, building filters, security tools and that was my first exposure to application security.

JG: With security, it's not enough to find one vulnerability, you have to find all vulnerabilities at all times, because you know that you're going to get hacked and you're the web security guy and that's not a good fun position to be in.

At WhiteHat, we scan lots and lots of websites. We find oodles of vulnerabilities and, statistically, only half the issues for good reasons or bad reasons, we can abate. But only half the vulnerabilities get fixed and the ones that do get fixed, take between two and six months on average to get fixed. Remediation is a major problem. It's not enough for WhiteHat or anybody else just to find problems if they're never [going to] get fixed. 

Video of the complete Q&A can be viewed here

More on this topic: 

 

Interop 2016 Las VegasFind out more about security at Interop 2016, May 2-6, at the Mandalay Bay Convention Center, Las Vegas. Register today and receive an early bird discount of $200.

Kunal Anand is the co-founder and CTO of Prevoty, a next-generation application security platform. Prior to that, he was the Director of Technology at the BBC Worldwide, overseeing engineering and operations across the company's global Digital Entertainment and Gaming ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
White House Cybersecurity Strategy at a Crossroads
Kelly Jackson Higgins, Executive Editor at Dark Reading,  7/17/2018
The Fundamental Flaw in Security Awareness Programs
Ira Winkler, CISSP, President, Secure Mentem,  7/19/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-14492
PUBLISHED: 2018-07-21
Tenda AC7 through V15.03.06.44_CN, AC9 through V15.03.05.19(6318)_CN, and AC10 through V15.03.06.23_CN devices have a Stack-based Buffer Overflow via a long limitSpeed or limitSpeedup parameter to an unspecified /goform URI.
CVE-2018-3770
PUBLISHED: 2018-07-20
A path traversal exists in markdown-pdf version <9.0.0 that allows a user to insert a malicious html code that can result in reading the local files.
CVE-2018-3771
PUBLISHED: 2018-07-20
An XSS in statics-server <= 0.0.9 can be used via injected iframe in the filename when statics-server displays directory index in the browser.
CVE-2018-5065
PUBLISHED: 2018-07-20
Adobe Acrobat and Reader 2018.011.20040 and earlier, 2017.011.30080 and earlier, and 2015.006.30418 and earlier versions have a Use-after-free vulnerability. Successful exploitation could lead to arbitrary code execution in the context of the current user.
CVE-2018-5066
PUBLISHED: 2018-07-20
Adobe Acrobat and Reader 2018.011.20040 and earlier, 2017.011.30080 and earlier, and 2015.006.30418 and earlier versions have an Out-of-bounds read vulnerability. Successful exploitation could lead to information disclosure.