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
Kaspersky Lab Seeks Injunction Against US Government Ban
Jai Vijayan, Freelance writer,  1/19/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The Year in Security: 2017
A look at the biggest news stories (so far) of 2017 that shaped the cybersecurity landscape -- from Russian hacking, ransomware's coming-out party, and voting machine vulnerabilities to the massive data breach of credit-monitoring firm Equifax.
Flash Poll
[Strategic Security Report] Navigating the Threat Intelligence Maze
[Strategic Security Report] Navigating the Threat Intelligence Maze
Most enterprises are using threat intel services, but many are still figuring out how to use the data they're collecting. In this Dark Reading survey we give you a look at what they're doing today - and where they hope to go.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.