Twenty-Four Seven Security

Listen to or download the 7:57 minute podcast below:

Download file

What follows is a transcript of my podcast with Jack Danahy, Founder and Chief Technology Officer of Ounce Labs and one the industry's most prominent advocates for software security assurance. In this podcast we discuss the security perils of outsourcing application development, whose responsibility it is to assure that applications are secure, how to actually make sure they are secure, and what Jack thinks the future of application outsourcing is both in terms of risk and reward.

What are some of the main security problems that arise when a company outsources their application development?

I would probably characterize them in two buckets and the first is communication. And we learned this early on as outsourcing was taking off in terms of functionality that organizations had to be pretty specific about what they wanted, if they wanted to get the most value out of the outsourcing. So it's sort of - say to the first one is communication and the second one is enforcement where functionality is something again, which can be designed for.

It can also be fairly easily tested for and people know how to do that well. In security, the combination of these two things takes a slightly different form. A lot of organization haven't really stopped themselves internally to think about what security means for an application, or business purpose to which they're going to an outsourcer, nor have they thought hard about how they're going to check to make sure that those things have been done.

So sometimes, what we're seeing most is a lack of communication of what exactly an application is going to do and what's going to require in terms of security. And then on the back end, they're often times is a lack of sufficient enforcement technique and technology to be certain that the application has delivered satisfies those security requirements.

Great. Isn't it the responsibility of the company developing the application to make sure it is secure?

Yeah, I think that's exactly the right point. And the problem is that security is not a word that means the same thing for every application or to every organization. So I'll give you an example. If I'm simply hosting up a website, and all its going to be doing is soliciting market feedback for something, and is fairly straightforward, and is not taking in private information, or exposing private information, then its level of security is by its nature going to naturally be lower than will be an application which is being developed perhaps to do payment, or transaction processing, or point-of-sale.

So as a result, the outsourcing group that's responsible for developing the application, may very well develop a perfectly secure application for some definition of security, but it may not fully understand the business purpose of the application is going to be put to. And as a result, it may not be secure enough for that purpose. So the answer is, yes, they should design a secure application, but back to my earlier point on communication, it's the responsibility of the organization asking them to build it to define what that means.

How common is it to have security vulnerability in an outsourced application?

I think, first off, its very, very common to have security vulnerabilities in a lot of different kinds of applications. One of the reasons why Ounce Labs is having the success we are is because a lot of organizations recognize that great applications meant to do a certain job whether it was perhaps not intended to be networks automatically, or that was intended to take in less secure data, and either the landscape, or the information needed has changed, aren't necessarily designed to be as secure as they should be.

So this is not simply within the purview of outsourced applications but it's pretty general. Outsourced applications are even more problematic, mainly, because of the fact that the organization developing it sometimes misses on the requirements for security for the groups that are actually asking them to build it.

And a good example of this would be any number of the outsourced applications that have resulted in some of the private information leakage. And many even times, it's a well-built application that simply didn't understand that the information was going to be a private style information.

How can a company make sure their applications then are free of vulnerabilities when they're outsourcing?

I think one of the things we want to talk about in terms of an outsourced application when we talk about vulnerabilities is the first version, or the first flavor of vulnerabilities we care about, are those which sort of omitted problems, right. So I forgot to tell the provider that this information is going to be private and they should make sure that they never store it, or they only store it encrypted, or something like that.

And so the great way to do that is just tell them up front. The information that's coming in this particular part of the application is going to be private, its confidential for me, or its going to be private from the user, so please be sure when you build your application that only authorized people can touch it, and only the people who the people who are sending it in really know what it looks like, and if you have to store it, its stored in a safe manner. Right.

So that is one of the big places where adding this kind of value can help by giving them that information upfront. Once the software arrives, best efforts being what they are, it's still the responsibility of the organization who's going to be running the software to ensure that the software as delivered is going to meet those security requirements.

So we definitely recommend using software analysis technology such as Ounce Labs to go through that application and be able to very conclusively say every time this data comes in, its encrypted, or its always destroyed and never stored, or that the authorization model is sufficient to make sure that the wrong people don't have access to it.

So it's this combination of being upfront, and taking the time, and sort of having sort of the internal rigor to define clearly for the outsourcer what it should look like, and then having both within your contract language as you define those requirements, this capacity to do enforcement, and then actually doing the enforcement on the back end so when it lands you can check to make sure it's what you thought it was.

What are some of the warning signs that you might not want a company to develop your applications?

Well, a lot of what we see is some really substantial, favorable traction among the outsourcing community for taking on this style of requirement gathering this additional rigor in the development process.

But if you run into a company that says that they do not want to be held to this, that they don't want the contract language to say that you're going to reserve the right to check the code to make sure that it's secure, or that you're going to be asking them to do a specific set of things that you will later enforce within the contract with languages and sometimes with cost recovery. If they're unwilling to accept that, that should really raise a massive warning flag because either number one, their expectation is that they're likely to make makes a mistake and not deliver it.

Or number two, that their existing processes are pretty rigidly defined and so it's difficult for them to move off of those to support your needs from a security perspective. Or number three, that they have a lot turnover perhaps in terms of their personnel and so they don't have a sense of confidence that the actual people who will be doing the development are capable of manufacturing an application to the standards that you've given them.

So the main warning sign we look for are organizations, which are reticent to support what, I think, are very, very straightforward security requirements, which look a lot like functional requirements that most organizations are happy to take on.

Now, what do you see as the future for both outsourcing in terms of both the risk and the rewards?

Well, I think that there continues to be a great deal of motion not just from the cost-saving perspective, which clearly is one of the early drivers of outsourcing but the capacity of outsourcing to allow organizations to focus more directly of their core businesses. So financial services institutions can focus on great financial attractions with their partners, or healthcare agencies can focus on healthcare and not on application development.

So I think that the ongoing rewards will remain largely the same as they have been with his capacity of folks in your core business and achieve these cost savings. And I think the risks as more organizations begin to treat security as a fundamental almost functional requirement, I think, what you'll find a happening is that the risks will actually go down.

I don't think the risk are going to increase because I think the biggest risks existed when organizations didn't feel comfortable asking for more secure applications, didn't feel comfortable in their definition. In order to feel comfortable, sort of demanding that they be allowed to reserve the right to audit these things after they get delivered.

So I think what you're actually going to see is that the rewards will continue to maintain their value and that the risks will actually decline as organizations take advantage of the knowledge that they can as for specific security characteristics which will protect them from liability, and that they will actually be able to enforce those when they come over the wall so that they will be more with in keeping their own internal and external compliance guidelines.