The Economist article on cyber-security - A Spook Speaks

This week, The Economist has an article on business and cyber-security.

"Its costs may be hard to count, but cybercrime has companies worried."

They also have an online debate to accompany the article.

On the one hand, the article doesn't say very much. But it is worth reading because this is the type of article about information security that business people are more likely to see. And these are the kind of people who we should be trying to get our info sec message across to.  It helps to be able to reference resources in publications such as The Economist.

Useful Links:

• The Economist: A spook speaks 
• The Economist: Cybersecurity Debate

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Tuesday Top Tip - Slow Password Hashing

Like Slow Cooking, Slow Password hashing seems to be in vogue at the moment, using hashing algorithms such as bcrypt or PBKDF2. Troy Hunt has a mega in-depth look at the subject on his blog,  with an emphasis on asp.net. This comes after recent incidents such as with LinkedIn and eHarmony.

So the general recommendation would seem to be that for new projects you should consider using a slow password hashing algorithm to protect your users' passwords. I say "consider using" because there is a performance overhead associated with using these approaches which you need to be aware of.

However.....

It's also worth remembering that if you end up in a situation where you are praying that a slow hashing algorithm will protect passwords and save you, then you have other BIGGER problems.

To get at your well hashed passwords in the first place, an attacker will likely have hacked your database anyway and gotten at the other information held in the database: names, addresses etc. This is the bigger issue. Somehow, hackers get access to the LinkedIn password table in the first place.

So before embarking on a major exercise to introduce slow password hashing, it's worth spending time ensuring that the baddies can't get at the password table in the first place. 

Useful Links

• Troy Hunt: Our password hashing has no clothes  
• 365 days of Slow Cooking
• BBC:LinkedIn passwords leaked by hackers
• CNET: Analysis: eHarmony had several password security fails

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Spread Betting Websites and Security Controls

Summary

Should spread betting websites be using two factor authentication and shorter session timeouts?

Background

The spread betting company, Spreadex, recently sued a customer in a London court for £50,000 which the customer had lost through trades in Spreadex. The customer claimed that the transactions had been made by his girlfriend's young son. The boy had access to the laptop to play games over a number of days, and seems to have initiated the transactions which caused the losses.

Interestingly, the court found for the customer on the basis that he couldn't be expected to read through all the pages of terms and conditions and, thus, the contract was unfair. We'll see if Spreadex appeals.

The Security Angle

However from a security perspective it throws up a number of interesting issues.

The first point to make is that spread betting websites involves money. As the court case shows, a customer can make or lose a significant amount of money on the website. When hard cash is involved, you really need to think about the security mechanisms.  This applies to both the punter and the website.

The consumer needs to be careful about the environment where he uses the application. If he uses the PC to make bets worth thousands of pounds then you have to question whether the PC can also be used as a general toy.

Website Security

But the focus of this blog is on website security. Given the value and classification of data that spread betting sites process then the types of security controls build into the application are important. So here are a number of thoughts:

Is single factor authentication sufficient to protect these financial transactions? Most online banking websites use some form of two-factor authentication to authorise transactions. Like online banks, the spread betting application involves significant transactions. Should they not consider using two factor authentication also? No doubt this would be an expensive undertaking and could well be overkill. Another option would be forcing the user to reenter their password when a transaction is initiated. This would probably have prevented this incident.

Timeouts are also an important security mechanism. After a period of inactivity the application session should timeout. The next time the customer uses the application, he should be forced to logon again. Absolute timeouts force a session to terminate after a defined period of time, regardless of whether the user has been active or not. Could shorter timeouts have helped in this situation?

Now, these type of security mechanisms hit directly into the usability/security conundrum. The more security controls you have, the more user unfriendly the application  becomes. So it can be a difficult balancing act.

Bottom line is that you need to consider your security requirements at the start of any development project. A threat analysis should not only cover direct threats against your application, but  also cover threats which happen on the end-user environment.

Useful Links:

• The Register: Online bookie can't scoop £50k losses made by 5-year-old 
• Metro: Boy, 5, made £50,000 loss on spread-betting website

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Data Deletion and DFDs

The Information Commissioner's Office (ICO) in the UK just handed out a £325,000 fine to  Brighton and Sussex University Hospitals NHS Trust after decommissioned hard drives were sold on eBay. Basically drives containing very sensitive information which were meant to have been destroyed, somehow found their way onto eBay. The NHS trust is appealing the decision.

When creating your Data Flow Diagrams (DFDs) you should also think about secure deletion of data from devices when they have reached the end of their life. In addition to asking how data is stored on devices, you should also ask what happens to these devices (hard drives etc.) when they have reached the end of their life.

Make sure to have proper procedures in place to prevent this kind of thing happening.



Useful Links

• ICO hands out biggest ever fine to 'surprised' NHS Trust 
• ICO Notice (PDF)

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Tuesday Top Tip - EU Cookie Directive Deadline in the UK Fast Approaching

If you are in the UK, you have four days to become (finally) compliant with the EU cookie directive. The (real) deadline is May 26th 2012. A year ago, the Information Commissioner gave you a year to comply. So what to do?

Approach 1 - Information Commissioner's Office - ICO

A relatively simple approach is to copy the approach taken by the Information Commissioner's office (ICO) itself. Go to the ICO  website and you will see the following at the top of the page.

You can click on the "I accept cookies..." button to accept cookies. If you don't click, each time you go to the site you will see that message. If you do click, then you won't see it again.

Approach 2 - BT

A more comprehensive approach comes from BT. When you go to the BT website, you will be prompted with the following window

 

If you click on the Change settings, you are presented with the following which allows you to set the level of cookies that you will accept using a drag bar. You then choose Save and Close.

So those are two approaches. The ICO one is more simple and might be easier to implement in the short term. The BT approach is more elegant but would take longer to implement.


Useful Links

• ICO Website 
• ICO Cookie Guidance
• BT Website
• Wall Street Journal: U.K. Cookie Crackdown Begins
• The Register: ICO: Managed to comply with Cookies Law? Go help the other kids 

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

2 Microsoft Research Papers to Read

Two interesting papers from Microsoft Research, both from June 2011. Interesting because they seem to go against the prevailing trend that we are all doomed as a result of poor security. They are worth reading to get an alternative point of view. You can skip over the mathematical equations if that is not your thing.

"Sex, Lies and Cyber-crime Surveys" argues that cyber crime surveys are in general pretty rubbish. It discusses the difficult of performing surveys properly, especially on relatively rare phenomena. From section 4.3:

• "Our assessment of the quality of cyber-crime surveys is harsh: they are so compromised and biased that no faith whatever can be placed in their findings."

Of particular interest to application security people is the following from the conclusion:

• "The importance of input validation has long been recognized in security. Code injection and buffer overflow attacks account for an enormous range of vulnerabilities. You should never trust user input" says one standard text on writing secure code. It is ironic then that our cyber-crime survey estimates rely almost exclusively on unverified user input. A practice that is regarded as unacceptable in writing code is ubiquitous in forming the estimates that drive policy. A single exaggerated answer adds spurious billions to an estimate, just as a buffer overflow can allow arbitrary code to execute."

The second paper, "Where Do All The Attacks Go?" tries to answer the question "Why isn't everyone hacked everyday?" Here's the abstract:

• "The fact that a majority of Internet users appear unharmed each year is diffcult to reconcile with a weakest-link analysis. We seek to explain this enormous gap between potential and actual harm. The answer, we find, lies in the fact that an Internet attacker, who attacks en masse, faces a sum-of-effort rather than a weakest-link defense. Large-scale attacks must be profitable in expectation, not merely in particular scenarios. For example, knowing the dog's name may open an occasional bank account, but the cost of determining one million users' dogs' names is far greater than that information is worth. The strategy that appears simple in isolation leads to bankruptcy in expectation. Many attacks cannot be made profitable, even when many profitable targets exist. We give several examples of insecure practices which should be exploited by a weakest-link attacker but are extremely difficult to turn into profitable attacks."

The main conclusion is that it is difficult to calculate risk accurately if you are basing your calculations on cyber-crime surveys. It is more useful just to concentrate on the impact of a threat.

Useful Links:

• Microsoft Research: Sex, Lies and Cyber-crime Surveys
• Micrososft Research: Where Do All the Attacks Go?

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

SDLC Quick Reference Updated

I have updated the SDLC Quick Reference. The reference is essentially a list of security related tasks which you should think about at the start of an online development.

By following these steps, you are much more likely to develop a more secure end-result.

The main change from the previous version is the first section. You should identify a list of technologies that the application will use. Then find out how to use these technologies securely, both in development and in deployment.

Useful Links:

•  SDLC Quick Reference

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Toshiba UK, ICO and OWASP Top 10 A4 error

The UK Information Commissioner's Office (ICO) has ruled that Toshiba UK breached the UK Data Protection Act by publishing the personal details of 20 competition entrants on its website. According to The Register:

• "A security fault with the incremental numbering of the competition entrants registration URL created the potential for access to other customers' personal data for a two-month period," the regulator said.

By changing the values in the URL, it was possible to see the details of other users. It looks like this was an OWASP Top 10 2010-A4-"Insecure Direct Object References" issue.

When designing your own application you need to perform authorization checks to ensure that the user has permission to access the requested resource. The OWASP Top 10 gives more guidance on how to implement this.

It's surprising how few of the ICO undertakings are related to web site issues. You can look at the ICO's "Taking Action" page to get a feel for what type of issues cause problems.

Useful Links on this blog:

• Analysis of ICO "Taking Actions" for 2011 
• ICO Data Protection Principles and Online Application Design

Useful Links:

• OWASP Top 10 2010-A4-Insecure Direct Object References 
• The Register: Tosh UK rewards competition hopefuls by exposing their privates
• ICO Press Release
• Undertaking signed by Toshiba UK (PDF)
• ICO Taking Action Page 

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Tuesday Top Tip - John Melton's Year of Security (for Java)

If you haven't come across it yet, you should head over and have a look at John Melton's Year of Security For Java series. Each week he covers a different security topic.

While the series is aimed at Java, a lot of the entries so far are general and apply to any environment.

Useful Links

• Year of Security For Java 

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Security out of the box

A small experiment. Take the following simple HTML file which allows a user to enter a value in a HTML form and submit it:

<HTML>
<BODY> 
<BR>

<BR><BR>
Submit something:
<BR>
<FORM method="post">
   <input type="text" size="100" name="namexss" ><br>
   <input type="submit" name="submit" value="Submit Form"><br>
</FORM>

</BODY> 
</HTML>

PHP

 If you name this file  testxss1.php and execute it using a simple XSS type attack as shown

When you press Submit Form, the form is accepted and PHP doesn't complain.

ASP.NET

If you name this file testxss1.aspx and execute it using the same XSS attack string, you will get a nice error:

Asp.net recognizes that an XSS attack was attempted and per default blocks it.

Conclusion

It shows how different frameworks offer different levels of security"out of the box". This is the exact same file. But run it through asp.net and you get better XSS protection.  It's important that you understand the security features that your chosen technologies offer you.


These tests used default versions of  asp.net version 4 and php version 5.3.3 installed locally on IIS. It is not very scientific and is not intended to show that any framework is better than another. The aim is to show that different products support security in different manners and that development teams need to understand their specific chosen products.

 

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Tuesday Top Tip - Qualys SSL Labs

If you are configuring SSL on your website or online application (and you should be these days), use the resources over at Qualys SSL Labs.

The SSL/TLS Deployment Best Practices gives good advice. Read this before your purchase your SSL certificate and follow its advice. For example, it talks about how to use SSL properly in your application design, what key length to use etc.

What I particularly like is the SSL Server Test facility. After you have configured your SSL certificate, go to the SSL Server Test page.  Enter your URL in the Domain Name field (but make sure to check the "Do not show the results on the boards" box). Click the Submit button and SSL Server Test will analyze your SSL configuration.

This takes a few minutes, but will give you a result. You should be looking to get an A. It will tell you of any problems in your SSL configuration. Fix those and resubmit.

Keep repeating until SSL Server Test gives you an A....and then you can feel smug.

Useful Qualys Links:

• Qualys SSL Labs 
• SSL TLS Deployment Best Practices (PDF)
• SSL Server Test

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

XSS , OWASP Top 10, Verizon DBIR 2012

Last week, Verizon released their annual Verizon Data Breach Investigation Report (DBIR) 2012.

This report investigated 855 incidents involving "174 million compromised records".

XSS (Cross Site Scripting) is not mentioned in the document. (The 2011 edition at least mentioned it). This implies that Verizon has not found XSS to be a significant cause of the incidents that it investigated.

The conclusion seems to be that while XSS is regularly found in online applications, it does not seem to be exploited very much, so the risk associated with XSS is (relatively) low.

According to OWASP:

The OWASP Top 10 "presents a more concise risk focused list of the Top 10 Most Critical Web Application Security Risks."

The OWASP Top 10 currently has XSS as the number 2 risk, ahead of such issues related to credentials (passwords etc). The potential problem with this ranking is that organisations will prioritize their application security programs based on the OWASP Top 10. This means they could be placing too much emphasis on topics such as XSS and not enough emphasis on topics such as credential management.

It will be interesting to see the rankings in the next edition of the  OWASP Top 10 201?

Useful Links

• Verizon DBIR 2012 
•  OWASP Top 10 2010

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Struts OGNL Security Issue - Are You Vulnerable?

Background

A High rated vulnerability was discovered in the Struts framework a month or so ago. All versions of Struts from 2 to 2.3.1.1 are vulnerable According to the Struts team the vulnerability :

• "allows a malicious user to bypass all the protections (regex pattern, deny method invocation) built into the ParametersInterceptor, thus being able to inject a malicious expression in any exposed string variable for further evaluation."

Compass Security have put together a useful tutorial describing the issue.

A few questions:

• Is your company vulnerable?
• Would you even know  if you are vulnerable?
• Do you even know if your company is using Struts?

Simple Fix
The fix is pure and simple - Upgrade to Struts 2.3.1.2
But then to quote Oscar Wilde:

"The truth is rarely pure and never simple. "

Discussion
The problem is that there are huge numbers of applications running vulnerable versions of Struts which are unlikely to have been patched with the new version. This could be because companies neither know about the vulnerability nor know that their online applications are using Struts. In many cases the applications have been in production for a few years and the development teams have long since moved on.

While the applications may have been secure at launch, the discovery of the Struts vulnerability now means that these applications are vulnerable. This could well mean that a company is no longer PCI DSS compliant.

While the Simple Fix above is simple, the reality is that it won't be applied because organizations do not know that they are vulnerable.

This is especially a problem with open-source type libraries and frameworks. There is no standard mechanism for publishing information on vulnerabilities. They fall between the cracks. Operations staff are usually aware of OS type vulnerabilities, but not of these types of application frameworks or libraries.

A joint study conducted by Sonatype and Aspect Security found that more than 50 percent of the world’s largest corporations have open source applications with security vulnerabilities.

Real Fix
The real fix lies in having a proper Secure Development Life Cycle in place - in particular a post-production process for identifying newly discovered security vulnerabilities and ensuring that appropriate security fixes are applied.

So here are suggested steps:

1. When a new application is being rolled out to production, make sure that it is registered with the corporate Asset Register. This should include information about any frameworks, libraries etc. that the application relies on.
2. The operational risk team should monitor for any vulnerabilities in the libraries and frameworks.
3. If vulnerabilities are discovered, the operational risk team can look in the corporate Asset Register to identify any impacted applications
4. Appropriate fixes can then be applied

Useful Links:

• Details on Apache Struts Website 
• Compass Security Movie - Tutorial 
• Struts 2.3.1.2.
• Sonatype and Aspect Security Study on use of vulnerable Open Source Components
• Oscar Wilde Quote 

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

The Economist on Passwords

This week's edition of  "The Economist" has both a leader and  article devoted to computer passwords.

According to the leader: "An analysis by Verizon, an American telecoms firm, found that the biggest reason for successful security breaches was easily guessable passwords"

The following extract from the article is especially relevant for developers:

"One obvious answer would be for sites to limit the number of guesses that can be made before access is blocked, as cash machines do. Yet whereas the biggest sites, such as Google and Microsoft, do take such measures (and more), many do not. A sample of 150 big websites examined in 2010 by Mr Bonneau and his colleague Sören Preibusch found that 126 made no attempt to limit guessing.

How this state of affairs arose is obscure. For some sites, laxity may be rational, since their passwords are not protecting anything particularly valuable, such as credit-card details. But password laxity imposes costs even on sites with good security, since people often use the same password for several different places.

One suggestion is that lax password security is a cultural remnant of the internet’s innocent youth—an academic research network has few reasons to worry about hackers. Another possibility is that because many sites begin as cash-strapped start-ups, for which implementing extra password security would take up valuable programming time, they skimp on it at the beginning and then never bother to change. But whatever the reason, it behoves those unwilling to wait for websites to get their acts together to consider the alternatives to traditional passwords."

When developing your websites, how you manage passwords is vital.

A few ideas:

• Disable account (at least temporarily) after a number of failed logon attempts
• Don't allow the most common x hundred passwords. You can get lists from the internet.
• When people create new passwords remind them not to use the same password as they have used elsewhere.
• Use the chip shop approach - hash and salt the passwords to store them. In other words, don't store passwords in cleartext.

Links:

• Economist Leader: A security patch for your brain 
• Economist Article: Speak, friend, and enter 

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Kia Cee'd

Judge: Your client is accused of trying to hack into the website of Mr Smith's garage - using a technique which I understand is called "SQL Injection".

Defense Lawyer: Your Honour, my client was only doing a search for a Kia Cee'd, which he is interested in purchasing

***********************
Do a Google Search for Kia Cee'd SQL and you will conclude that Kia should really have been a bit more careful when choosing this name!

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Hello Switzerland Magazine article on Consumerization

March 22nd 2012 
Update 1: The article is now online . Scroll through to page 13. 
Update 2: This trend is often called BYOD (Bring Your Own Device)



I have an article in the Spring 2012 edition of the Hello Switzerland magazine.  It discusses the impact of "consumerization"  in companies and organisations. This is where staff members use their own devices (smartphone and tablets) to access corporate information.

The article itself is pitched at a fairly high level. The main message is that consumerisation is a trend which is increasing. While offering many advantages, consumerisation also has its risks. The important thing for organisations to do is to recognise that this risk exists --and then to manage it.



Note: On Friday 2nd March, 2012 at 7pm, I am giving a BERNnet talk on Smartphone and tablet security in Bern. This is aimed primarily at normal end users. More information on BERNnet (PDF)

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

ICO Taking Action - 2011 Analysis

Summary
I did an analysis of the UK's Information Commissioner's (ICO) "Taking Action" incidents for 2011. There were approximately 80 incidents  where the ICO took action, after personal data breaches. Of these:

• 26 were related to  unencrypted media (e.g. lost or stolen laptop or USB memory stick); 
• 24 were caused by a misadventure of some sort with paper records; 
• 14 resulted from data being electronically sent (e.g. email or fax)  to the wrong recipient;
• 12 came from an application or website issue; 
•  4 were categorised under "other".

The lesson for security managers is that most incidents involving personal data are caused by relatively mundane type events, not advanced hacking attacks. Security awareness training for people should reinforce the message: be careful when processing personal data and do not use USB sticks. Technical measures include encryption of laptops etc.

Detail
The UK's Information Commissioner (ICO) lists the actions he has taken against individuals or organisations found to have been in breach of the UK Data Protection Act. I did an analysis of the incidents for the year 2011. The main purpose is to analyze the causes of these incidents to gather metrics.


I divided the incidents into 5 categories:

• Unencrypted Media - this includes such items as loss or theft of unencrypted media such as USB sticks or laptops. 
• Loss of Paper Records - including incidents where physical documents are misplaced, lost, found in a waste bin, or similar.
• Electronic Records Missent - where personal data is sent electronically to the wrong recipient using either email or FAX
• Website/Application Issue - where the action results from some sort of application or website issue.
• Other - which did not fit into any other category

Results
The following table shows the results:

Category	Number Incidents
Unencrypted Media	26
Loss of Paper Records	24
Electronic Records Missent	14
Website/Application Issue	12
Other	4
Total	80

The ICO does not usually say whether an actual loss occured as a result of any incident. There are a number of incidents where you get two for the price of one. For example a laptop is stolen along with paper records.

The results show that the majority of incidents have  relatively simple or mundane causes. Advanced hacking techniques were generally not employed. The lessons to be taken from this analysis are that basic security measures will prevent the majority of these incidents:

• Security awareness training to reinforce the message that people should be careful when pressing the send button.
• Do not use USB sticks
• Encrypt laptops (and USB sticks if they must be used)

I hope to do a more detailed analysis of the Website/Application issues in a future blog entry.
There is a spreadsheet on Google Docs of the analysis (See Useful Links)


I did a similar type analysis of ICO enforcements in 2010 (See Useful Links)

Useful Links

• ICO: Taking Action - Undertakings, Enforcements and Monetary Penalties
• UK Information Commissioner (ICO) Enforcements and Website Hacks  (Entry on this blog)
• ICOTakingAction - Google Docs Spreadsheet analysis of results

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Proposed EU Data Protection - Data Security

On January 25th, 2012, the EU proposed a comprehensive new General Data Protection Regulation.

Data Security is  covered in Section 2 which includes Articles 30, 31 and 32 which begins on page 59 of the proposed regulation

Here is the main security text from article 30: 

"The controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risks represented by the processing and the nature of the personal data to be protected,having regard to the state of the art and the costs of their implementation.

The controller and the processor shall, following an evaluation of the risks, take the
measures referred to in paragraph 1 to protect personal data against accidental or
unlawful destruction or accidental loss and to prevent any unlawful forms of
processing, in particular any unauthorised disclosure, dissemination or access, or
alteration of personal data."

It also talks about "solutions for privacy by design and data protection by default", so implying that you should think about security from an early stage.

Article 31 covers notification of a personal data breach - and gives 24 hours for a breach to be notified.

Article 32 gives more details on communication of a personal breach.

At this stage this is only a proposal which may or may not become law in the fullness of time.

Useful Links:

• EU Data Protection website
• Text of Proposed Regulation (pdf) 

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Tuesday Top Tip and SSL

Another Tuesday Top Tip.

If you say in your privacy policy or statement that the security of your users is of the highest importance;  that you will meet and exceed all security best practices, legislative requirements and any other "good security thing" that you can think off, can you at least make sure that you use SSL.

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Business Risk: Selling AppSec to Business Leaders

Use compliance and reputation risk concerns based on these risk survey findings to persuade management  to invest in your Application Security programs

The table towards the bottom shows the top 25 lists of business risks as given by two different groups. The first list comes from the Lloyd's Risk Index 2011 featuring content from the Economist Intelligence Unit (EIU). The second is slightly older and is taken from the Ernst & Young Business Risk Report 2010.

These show the risks that business leaders are worried about.

What are the risks that can be leveraged to try and improve investment in Application Security programs? There's little point in saying "Guinness Application Security is good for you".  However, we can try to leverage the risks that senior management are worried about.

Compliance and Reputation would seem to be the two main arguments that we can put forward.

Compliance

Both surveys feature "changing legislation" or  "regulation and compliance" towards the top of the risks that business leaders are concerned about.  In our field,  this would include such topics as PCI DSS, Data Protection legislation, HIPAA etc. Our first argument would go along the lines :

• "We need to improve our application security program in order to comply with XYZ"

From my experience PCI DSS is definitely a strong motivator. Some companies realize that they need to comply and are undertaking security initiatives: something that would probably not have happened if PCI DSS did not exist.

Reputation
The other main risk which we can use seems to be Reputation. The Lloyd's Risk index has Reputational Risk at number 3 while the E&Y Business Risk Report has it at number 19. I presented the E&Y table at a recent OWASP Switzerland chapter meeting. The general concensus at that event was that companies are worried about reputation and so the Lloyd's Risk Index placement at 3 is more accurate.

The argument here is:

• "We need to improve our application security program in order to protect our reputation. Look at what happened to SONY, Stratfor, etc...."

Cyber Attacks
The Lloyd's Risk index mentions malicious cyber attacks as risk number 12 and cyber-risks (non malicious) at 19, whereas the E&Y report does not mention them specifically.

	Lloyd's Risk Index 2011	The Ernst & Young Business Risk Report 2010
1	Loss of customers/Cancelled orders	Regulation and compliance
2	Talent and skills shortages	Access to credit
3	Reputational risk	Slow recovery or double-dip recession
4	Currency fluctuation	Managing talent
5	Changing legislation	Emerging markets
6	Cost and availability of credit	Cost cutting
7	Price of material inputs	Non-traditional entrants
8	Inflation	Radical greening
9	Corporate liability	Social acceptance risk: corporate social responsibility
10	Excessively strict regulation	Executing alliances and transactions
11	Rapid technological changes	Inability to innovate
12	Cyber attacks (malicious)	Maintaining infrastructure
13	High taxation	Emerging technologies
14	Failed investment	Taxation risk
15	Major asset price volatility	Pricing pressures
16	Theft of assets/Intellectual Property	Resource scarcity
17	Fraud and corruption	Consumer demand shifts
18	Interest rate change	Global (re)alignment
19	Cyber risks (non-malicious)	Reputation risks
20	Poor/Incomplete regulation	Energy shocks
21	Critical infrastructure failure	Supply chain and "extraprise"
22	Government spending cuts	Managing new business models
23	Supply chain failure	Capital allocation
24	Pollution/Environmental liability	Intermediary power
25	Sovereign debt	Shifting demographics

Summary
Compliance and reputation risks are probably the two main risks to leverage when you are trying to convince management to invest in application security.  This type of approach might seem a bit underhand - but all is fair in love and war.

Links to surveys(PDF):

• Lloyds Risk Index 2011
• Ernst and Young Business Risk Report 2010 

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot