Tip:
Highlight text to annotate it
X
[Music]
Hi everyone I’m Illeana Armstrong VP of editorial with SC Magazine welcoming you to
yet another edition of SC In Focus. And here with my now at RSA in San Francisco is Andy
Chou, co founder and CTO of Coverity which offers development testing products to automatically
test source code. So thank you so much for joining us here.
Thank you for having me.
So there’s likely not a security professional around and certainly there are a few developers
around who would not agree that security should be built in from the get go. Whether it be
software product application, whatever. But problems still exist. So first off what’s
the disconnect? And what can companies to better to ease the process?
Well I think that part of the problem is that security has been a reactive kind of activity
for a lot of organizations and development is fundamentally a proactive one. So I think
part of the problem is no really address security early enough in the software development process.
So for example bringing security into the requirements process, Bring security into
the way the code is written, bringing sec into the way the code its tested. So I think
bringing all those activities early into the process can really help make it more efficient
and cheaper and easier to build soft sec in. As opposed to trying to test it in and patch
things after the fact. Now you are never going to get rid of patching entirely, but I think
by taking a more proactive approach, companies can really reduce the number of incidents
out there.
And certainly getting developers and security professionals to work a lot more closely together
would help the process.
And frankly there is a really big cultural gap there. I think that security professionals
and developers have famously not gotten along. I think part of it has to do with process
and part of it has to do with they are in different organizations. Development has a
fundamentally different goal than security; they are there to deliver products and services
that add value. And they have deadlines and they have bonuses attached to those deadlines
and security looks like something that is in the way of them getting their job done.
Whereas from the security perspective, there are huge risks in the applications being developed
and developers don’t always pay attention to the small things they could do much earlier
that could really reduce those risks. And so there is just tension. I think traditionally,
that tension has resulted in a fair amount of friction, but overtime I think, many organizations
at the forefront of this have learned to bake things in more efficiently and it doesn’t
have to be a confrontational relationship. And if they work together and have goals then
they can work on the same kind of activities that really help security and help deliver
better products.
Very good. And certainly working on those goals early on and really understanding that
process would be most helpful right?
Absolutely, one of the things, just a small example, often security organizations when
they do an assessment, of an application they come out with a report that says, here is
a pile of vulnerabilities to address. And there is a PDF document they hand back to
developers and say go do something about this. Developers don’t work that way, right? They
have bug tracking systems. They have processes for dealing with all sorts of problems. Security
is not the only organization that has a stake in their time. So QA, of course customers
and the fires that they have definitely play a role. And so, how can you work with the
existing processes that development uses to triage and prioritize their work I think is
critically important for security to be effective.
Very good. So third party apps. We have been hearing a lot about the vulnerabilities in
these applications. There are some individuals who say professionals out there who say, maybe
there are so many 3rd party apps that are just riddled with these vulnerabilities. You
should throw them out. But many cant and users are dependent on these to do their day to
day jobs. How can organizations get a better handle on the vulnerabilities in many of these
3rd party applications?
So certainly applications such as Java browser plug-ins have been in the headlines. And I
think there’s been some call in the government, for example, to turn it off. If you don’t
need it, turn it off. For some users that might be viable, because they really don’t
have any use for it necessarily in the browser, but for other users it’s not viable. They
have applications that are critical. I think a lot of security, like I said, is about dealing
with the problem after the software is already out there. And when that happens, you really
only have a few choices. You can put mitigations in place. You can patch. You can keep your
software up to date, but there’s limited options. I think that by focusing on earlier
stage interventions, you can get the software out there before it has vulnerabilities. The
fact that people are testing the software for security after it’s already out there,
I think is just a really late stage intervention. A zero day is fundamentally a flaw in software
that is already out there and released. Why not catch it earlier so it never has the chance
to see the light of day? So that’s our perspective on the problem and I think that while the
vast majority, if you look at the vendors at RSA this year, probably 90% of them are
all about what to do about deployed software. And who is really looking at the root of the
problem. I think there’s relatively little attention being paid to that, partly because
a lot of organizations only buy the software, they don’t develop it themselves. But they
also do develop web applications and internal applications that do have developers and do
have vulnerabilities and they do something about those proactively. While I’m not saying
you don’t want to do anything with 3rd party software, I think that really the focus should
be on building it right in the first place.
Very good. But in the meantime then, you just have to look at these secondary mitigating
factors to kind of catch those.
Well you know, we’ve been dealing with the short term approach of patching and trying
to deal with bad software for a long time now. I mean at some point, someone’s got
to say, “what are we doing to avoid the problem in the first place.” And I think
the Cyber Security Legislation doesn’t really get all the way there, but it’s starting
to raise the bar in terms of attention level paid to this problem because as a user if
I click on an email attachment, why should I expect that to take over my machine? It
shouldn’t have to do that, it looks like a file that opens up in Word, or whatever
other application, why shouldn’t it just work? Its buggy software, ultimately, that
results in that. People have expectations built in that they have to train everybody
for this stuff. And yes, but really, can we live with that forever? I think that’s something
we really need to think about.
So here we are. We are at RSA. We’ve got usually every year we hear some issues, some
threats, some technology, really kind of come to the floor when it comes to the discussion
points at this conference. What are you expecting? What do you think will be the most often discussed
issue at the conference?
One of the things we’ve been watching is this new cyber security push in the federal
government and one of the things that didn’t get a lot of play in the press, but I think
is really interesting is that the National Defense Authorization Act of 2013 essentially
mandated that the DOD put together a strategy for many aspects of cyber security including
one that is important to us which is software assurance. And that’s a really fundamental
change, I think, and it’s the beginnings. It’s only for one department of the Federal
Government but I think it’s the beginnings of something much bigger and I think we will
see that coming. And I think we will see a lot of discussion about what’s actually
happening, what are the decision makers within the government thinking or how are they collaborating
with the industry to figure out how to solve this big problem.
And that was my next question, given the fact that we are seeing some of these cyber mandates
kind of, or even a guidance now, that recently came out from the White House push this notion
about having the critical infrastructure companies work more closely with agencies, would you
expect then to see software assurance program and guidelines, kind of, reach some of these
private companies?
Absolutely. Part of what the Federal Government has considered doing is not necessarily mandating
at this stage, but starting to put in place the idea that software that’s acquired by
the government is going to have to meet some basic software assurance guideline standards.
It’s a very tough thing to apply intelligently, software is a very diverse thing, it’s not
just one kind of software we are talking about. Software that goes into a weapon system is
very different from a web application or a banking system, or something that manages
a power grid. So, I think it really depends on how intelligent they are about, essentially
having that standard crafted to a particular domain that they have to apply to. If they
do that right, I think it can have a huge impact on the cyber security stance that we
have in this nation.
Well thank you so much Andy, I really appreciate it. We certainly got a lot of guidance on
how to deal with some of the vulnerabilities or many vulnerabilities and software we rely
on. I want to thank Andy for being here and thank you for joining us, yet again, for another
edition of InFocus.