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

XSS and Verizon DBIR

I recently gave a short talk at OWASP Switzerland. One of the slides I showed was a figure taken from the Verizon 2011 Data Breach Investigations Report. (DBIR) (below) which was published in April 2011. The chart shows the type of hacking used as a percentage. The DBIR report looked at approximatelay 761 data breaches - not only those caused by web application vulnerabilities. It's worth reading.
 
The main discussion point at the chapter meeting was the value for Cross site scripting (XSS). According to the DBIR only 1% of data breaches are as a result of XSS vulnerabilites and less than 1% of stolen records. SQL injection accounts for 14%  (and 24% of records stolen), That said, there is no direct mapping from the types of hacking to the OWASP Top 10.

The value for XSS seems low given the focus that the AppSec community and OWASP place on it. One question that arises is whether these figures are accurate. Verizon does talk about "Sample Bias", but it should be noted that much of the data comes from outside organisations.

A few thoughts:

• Based on these figures it would be difficult to persuade managers with a limited security budget to invest significantly in preventing XSS.
• Issues with authentication and passwords are much more prevalent according to DBIR. Does this indicate that XSS should fall a few places in the next version of OWASP Top 10 and that "A3: Broken Authentication and Session Management" should climb? This, especially as the OWASP Top 10 is meant to reflect actual risk.
•  XSS vulnerabilities are prevalent in many web applications but are not actually exploited all that much to breach data.

Here is the DBIR chart. The quality isn't great. Best to see it in the original Verizon 2011 DBIR report on page 32. Figure 23 a few pages later is also interesting. It shows that Web Applications attacks were used in 22% of the breaches, but result in 38% of the records breached. So you get more bang for your buck if you attack an online application.

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

Veracode State of Software Security Report

I downloaded the Veracode State of Software Security Report Volume 4

Very useful reading for anybody interested in the state of software security.

One thing that struck me was the actual download process. To download the report, you have to register giving your contact details. Fair enough, Veracode wants to see who is reading their reports. However a few security related thoughts on this process:

• The registration process does not use SSL, so my contact details travel in clear text.
• The information is posted to:
• http://app-d.marketo.com/index.php/leadCapture/save

• Who is Marketo? I can see no privacy statement to say what happens to my contact details.

You can argue that if I was so worried about these points, why did I register? Good question....and I actually did give accurate details.

I have to ask myself whether am I over the top? Maybe, then again....

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

Individual Accountability in the Swiss Parliament

I recently did a tour of the Swiss Parliament  in Bern.  We got to sit at the desks in one of the two main chambers where the delegates meet and vote.

So to vote, the delegate has to press two buttons. The control button is on the front-left of the desk. The main Yes/No/Abstain buttons are on the back right of the desk. To vote, the user must press the control button and one of the main voting buttons at the same time. Both hands are occupied. The ideas is that the delegate cannot vote for an absent neighbour . Anyway that's what our guide said. 

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

To SSL or not to SSL

Update: November 29th, 2011. I have just noticed that Troy Hunt has posted an excellent article on SSL/TLS

I started a poll on LinkedIn. The question:

• "Should web applications which process Personally Identifiable Information (PII) be legally required to use SSL/TLS? "

with a simple Yes or No answer. There is a link to the LinkedIn poll at the bottom of this blog. However, I suggest you read through the following thoughts before answering.

The question could have been:

•  "Should web applications which process Personally Identifiable Information (PII)  use SSL/TLS? "

But that would have been easy. Most people would probably vote yes because SSL is A GOOD THING. The addition of  the "be legally required to" clause makes it more interesting.

What prompted this soul searching? I was recently looking through a UK based web site. The privacy policy states:

• "We take your individual privacy very seriously. We aim to ensure that this website meets and exceeds all relevant legal and regulatory requirements, including the Data Protection Act."

Great  - until you see that they don't use SSL to protect account information. This includes name, address, phone number etc.  In fact, you could argue that this website processes sensitive personal data under the Information Commission's Office (ICO) definition. According to the ICO, sensitive personal date " needs to be treated with greater care than other personal data". But no SSL on said website.

Is SSL Already an EU Legal Requirement?

Does the Data Protection Act require SSL? The UK version of the Act is a bit vague. Principle 7

states you "should have security that is appropriate to:

• the nature of the information in question; and
• the harm that might result from its improper use, or from its accidental loss or destruction."

Then the question becomes: "is SSL appropriate"?  The website operator can argue that they considered using SSL, but concluded that it wasn't appropriate. The Irish Data Protection commissioner goes a bit further in their security guidance, stating that encryption:

• "is considered an essential security measure where personal data is stored on a portable device or transmitted over a public network."

So no clear answer. 

Why Don't Website Operators Use SSL?

Maybe it's because:

• they genuinely don't even think about it. Although the little "https" lock on the browser is a fairly well known security measure. This is an InfoSec problem where awareness needs to be raised.
• it is easy to say something like  "We take your individual privacy very seriously" but then do nothing about it.That's lip service..
•  "Facebook don't use it - so why should we?" FB seems to be changing
• it's too difficult to configure. It probably takes a while, but it isn't that difficult
• it's because it's too expensive.  Google "SSL Certificate" and you can get a GoDaddy cert for €9.99
• it kills performance. According to Google,"SSL/TLS is not computationally expensive any more."
• SSL is broken and has been more or less every year since 1995. 
• users will keep getting security warnings as content switches between secure and non-secure
• apart from firesheep like utilities,  where is the evidence that the lack of SSL has really been exploited all that much?  

Reasons To Use SSL

SSL:

• does raise the infamous "security bar"
• is not too difficult to implement 
• comes in at number 9 in the OWASP Top 10
• is required by PCI DSS  
• gives you a nice warm feeling inside

Conclusion

But back to the original question. "Should SSL be legally required when processing PII?" The problem with this approach is that a requirement like this is very difficult to enforce. I think it would be much better trying to persuade developers and website operators to implement SSL rather than trying to use the crude hammer of legislation. So I think I will vote NO.

Here is the link to the Poll itself if you want to cast your vote:

• Should web applications which process Personally Identifiable Information (PII) be legally required to use SSL/TLS?  

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