Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles
(untagged)

Application Security: Agreement

0.00/5 (No votes)
23 Sep 2014 1  
Application security - business agreement

Building An Application Security Program: Business Agreement

Starting An Application Security Program

Getting Business to agree to start an application security program is one of the hardest obstacles you will face.
In the light of the ever ending stream of large organizations that continue to get hacked and exposed, business appetite for having and/or starting an application security program should be at an all time high. With the latest and according to kerbs, the largest credit card breach ever revealed Home Depot is reeling trying to contain the damage to the business after compromising 56 million credit cards. An application security program isn’t sexy, from a pure business perspective, it’s an expense with no sense of revenue generation (which is the wrong way to consider it). However, every level of an enterprise type organization or any organization that takes customer money, processes credit cards should be asking Can this happen to us? The answer is yes & it will. Therefore, the next question should be What are we doing about it? .

The business justification for building an application security program is quite simple. How many of those 56 million credit card users, are now shopping at Home Depot’s competitor? The answer is quite simple. I’ve never bought anything at home depot without spending at least 100$ and I’ve certainly spent 100$ at Home Depot in a year. Let's assume 50% of the Home Depot’s customer’s won’t shop at Home Depot anymore. That results in a net loss of 2.8 Billion dollars annually for Home Depot. IF I am a business individual and you tell me I can spend, 1,10,100 million dollars to save 2.8 billion annually that be common sense. It’s time businesses stop playing Russian roulette and start taking application security seriously. Would an application security program have totally prevented the Home Depot incident? I seriously doubt it, however it could and would have seriously mitigated the loss.

Understanding Business’s Reluctance

I’ve often said & debated with some very smart software folks in any line of business, whether it’s been a business I’ve worked in where technology and software sales were the main form of our revenue generation or whether software was used to enable business and drive users to enable use to purchase products. Essentially where the software enables the purchase of some other product, like insurance, or investments. The debate is that software developers, leads and some architects want to create amazing world class software. They think their job is to create software. I disagree I think their job is to create business value through software.

It's relatively easy to understand how a piece of software generates revenue, either customers pay for that software for their own uses, such as Office, OS’s, Anti Virus. Or software generates revenue through SAAS – where your software does something great and people pay per transaction. Or your software generates revenue through support contracts, you might give the software away for free, but charge for custom features, enhancements. Lastly, your software might allow the purchase of investments, or insurance, the very last model is that you develop software to retain your customers because your competitors have the software and if you don’t, your customers will take their business else where. Under all of these avenues, it’s easy to conclude and through a valid analytics program measure how much software is being used and how your users are using the software and therefore how much money is being generated. Therefore, business can realize an ROI on their investment in software products.

The problem is it’s virtually impossible to have your software make money without collecting money from some party, in order to collect payment one needs to collect the data required to process that payment. What is the ROI on the data collected? This is a much harder question to answer, what is that data worth? The data is collected as an artifact almost that’s needed to realize the ROI on the software, but once it’s collected, you can’t sell it! Well you can, but that is a sleazy gray area to walk and depending on your industry and what you’re selling could be subject to several lawsuits.

Application Security exists to fundamentally protect the data. If one considers all the recent cyber attacks of late, the attackers didn’t try to deface self pay terminals @ Home Depot, no they wanted the data. Application Security shouldn’t be about protecting the application, if an attacker manages to break into my network and erase the application, all they’ve done is irritate me I can rebuild/redeploy the application, or restore from backups, at the end of the day the whole procedure costs the company maybe a few thousand dollars. Attackers want the holy grail the data.

This puts those advancing application security or trying to build an application security program in an very tough spot, the data doesn’t make the business any money, and it’s difficult to realize the ROI on the data, the business doesn’t want to lose the data but are very reluctant to spend money and invest money in security because 1. It has no ROI because it’s protecting something with no inherit ROI. This problem is further compounded by the fact that would be attackers realize the damage and the value of that stolen data, they also realize that applications are an ever increasing target for stealing that data.

Mitigating Risk

A solid application security program is all about mitigating risk, it’s unfortunate but when one tries to mitigate a risk, and justify security spending to business, one tries to quantify a potential loss of the data. How do you quantify a potential loss of data? Well, through Risk management strategies, threat modeling, security testing to determine how risky an application is and what the likelihood will be that it leaks data or could be breached. However you cannot and I repeat cannot substitute a potential loss of data for revenue or turn it into revenue, if you cannot turn it into revenue, then it cannot be considered an ROI. Therefore there is no ROI on risk mitigation, and since security is all about risk mitigation, there is no ROI on application security.

If potential loss can’t be turned into revenue generation, then how does one justify an application security program to business? Well, one has to start with what they know, a security program is about mitigating the risks, and anyone who knows anything about security can begin to identify the risks. As part of a risk mitigation AKA security strategy, one should be able to identify the risks associated with vulnerabilities in applications, once the risks or threats are identified, you can proceed.

STEP 1. Figure out the current risks/threats in your environment

The common vulnerability scoring model version 2 gives you an excellent way to communicate that risk in a way the business can understand what it means.

Valuation of Information

I know I said information cannot have an ROI but it can have a value to the business. After you’ve been able to identify and gather the threats within the application, there is solid proof that these attacks are possible against the applications and can be realized, the next task you have is to figure out how to value the information that will be stolen. Daniel Moody wrote a great paper on the value of information and a model to measure the information by, it can be found Making your Case.

Keep in mind that a solid application security program is not an all or nothing program, it’s a progressive case that is going to require many discussions many opportunities to buy in from the business. If the business is really resistant start small, and grow your case, start with a critical application or a critical server. Define success & collect your metrics to demonstrate your success. Without business buy in at multiple levels, your security program will probably fail. It will run for a while but it eventually it will run out of steam, funding will be reallocated and it will be non-existent, it’s essential to get buy in from all levels of management within your organization.

If you’re having trouble identifying your threats or generating a buy in from business, do something radical, suggest funding a study or an audit from a third party auditing company. Most accounting firms are now providing security audit services and then there are the ones that specialize in security, unfortunately sometimes it requires something radical and a third party to validate what you’re saying to get management buy in, start with that proposal to get your project off the ground. Of course, once a security auditing company identifies the security vulnerabilities and you present it to management, build your security program around fixing those vulnerabilities. The important thing to remember is you can’t just fix the issues you have to build a path to sustainability, otherwise the same issues that caused the vulnerabilities the first time will just reintroduce more vulnerabilities.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here