EU Data Protection Regulation - 3 versions so far

updated: 2nd August 2015

The new proposed EU Data Regulation is slowly moving its way through the machines of EU democracy. Here are links to the 3 proposals so far from various bits of the EU bureaucracy. Useful if you want to compare them.

Updated to include a link to the European Data Protection Supervisor opinion on the various proposals. There is also a link to an App of big pdf containing a side-by-side comparison plus the Supervisor's recommendation

EU Commission - 25th January 2012 

The original European Commission version is at:

• http://ec.europa.eu/justice/data-protection/document/review2012/com_2012_11_en.pdf

The general announcement is at:

• http://ec.europa.eu/justice/newsroom/data-protection/news/120125_en.htm

EU Parliament - 12th March 2014

The amended European Parliament version is at:

• http://www.europarl.europa.eu/sides/getDoc.do?type=TA&language=EN&reference=P7-TA-2014-0219

EU Presidency to Council  - 11th June 2015

This is the version submitted by the EU presidency to the European Council

• http://data.consilium.europa.eu/doc/document/ST-9565-2015-INIT/en/pdf

EU Data Protection Supervisor  - Opinion of July 27th 2015

This is the opinion plus comparison of the various versions

• https://secure.edps.europa.eu/EDPSWEB/edps/lang/en/Consultation/Reform_package

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

Application Security and Governance Task List

Last Update: 29th June 2015

Introduction

I have put together an Application Security and Governance Task List (See Useful Links below). This is an Excel Online document which can be viewed through any regular browser or downloaded and used in Microsoft  Excel which you should be able to use through most browsers. For those in a hurry, the Task List is under the tab 2-Task List

Task List

It gives a fairly high level list of tasks that should be considered at the start of a development project. It covers both security and more governance type issues.

 It is divided into a number of categories. Under each category, there are a number of tasks.

Use it just to browse the list of tasks and maybe spot some item which you had not already considered.. You can do this through your browser. The task list itself is in tab 2 - Task List in the spreadsheet.

Excel Expand/Collapse

You can also download it as an Excel spreadsheet and modify it in Excel. Use the Open in Excel or File|Save As  options in Excel Online for this. Columns D to G could come in useful here to track what needs to be done.

Use the Excel Expand and Collapse options on the Left Hand Side to show and hide the tasks.

Note: This is currently in Beta mode.

Useful Links

• Application and Security and Governance Task List - (Excel Online Document)

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

Information Security for Business-Where to Start

Update 5th July 2015, 28th June 2015

Where does a business or organisation start if they want to improve their information security stance?

Here are some ideas. The links are at the bottom of the post.

Council on CyberSecurity Critical Security Controls

• "The Council's Technology practice area is built upon the Critical Security Controls (the Controls), a recommended set of actions for cyber defense that provide specific and actionable ways to thwart the most pervasive attacks"

This is related to the Sans Institute Critical Security Controls - See below

The council also has its "First Five Quick Wins"

1.  application whitelisting (found in CSC 2);
2.  use of standard, secure system configurations (found in CSC 3);
3.  patch application software within 48 hours (found in CSC 4);
4.  patch system software within 48 hours (found in CSC 4); and
5.  reduced number of users with administrative privileges (found in CSC 3 and CSC 12).

These are related to the Australian Signals Directorate Top 4 - See below

SANS Institute Critical Security Controls

The SANS institute maintains a list of the top 20 critical security controls.

• The Critical Security Controls focuses first on prioritizing security functions that are effective against the latest Advanced Targeted Threats, with a strong emphasis on "What Works" - security controls where products, processes, architectures and services are in use that have demonstrated real world effectiveness

Australian Signals Directorate Top 4

The Australians Signals Directorate (ASD) maintain that:

• "At least 85% of the intrusions that ASD responded to in 2011 involved adversaries using unsophisticated techniques that would have been mitigated by implementing the Top 4 mitigation strategies as a package.

The  top 4 are:

1. Application Whitelisting
2. Patching Systems
3. Restricting Administrative Privileges
4. Creating a defence-in-depth system

--

Here are a number of programs from the The UK Government.

Cyber security guidance for business 

This guidance is aimed at business in general and starts off with board level responsibilities.It then describes  the "10 steps" to cyber security" which cover the following topics

1. Information Risk Management Regime
2. Home & Mobile Working
3. User Education & Awareness
4. Incident Management
5. Managing User Privileges
6. Removable Media Controls
7. Monitoring
8. Security Configuration
9. Malware Protection
10. Network Security

 Cyber Street Wise

Cyber street wise has the following "five essential tips for cyber safety" for your business

1. Install Updates and antivirus software
2. Use strong passwords
3. Only download from trusted sites and organisations
4. Beware of phishing emails
5. Review and protect your business' information

Cyber Essentials

First comes "Cyber Essentials"  which "is a government-backed, industry supported scheme to help organisations protect themselves against common cyber attacks."

This is more technical and covers the following five areas.

1. Boundary firewalls and internet gateways
2. Secure configuration
3. Access control
4. Malware protection
5. Patch management

It also states the following

"From 1 October 2014, [UK] government requires all suppliers bidding for certain sensitive and personal information handling contracts to be certified against the Cyber Essentials scheme."

Useful Links

• Council on CyberSecurity Critical Controls
• SANs Institute Critical Security Controls
  
• Australian Signals Directorate Top 4 Mitigation Strategies
• Cyber Street Wise 
• Cyber security guidance for business 
• Cyber Essential Scheme

   

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

FUD: A Plea for Intolerance

Another interesting paper from Cormac Herley at Microsoft Research

In it he talks about "Fear, Uncertainty and Doubt" (FUD)  and how

"Even a casual observer of computer security must notice the prevalence of FUD :non - falsifiable claims that promote fear, uncertainty or doubt (FUD)"

It is short at 5 pages and well worth reading.

Useful Link:

• FUD: A Plea for Intolerance

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

EU Data Protection Regulation - Application Security

Update: June 28th 2015

Progress is being made.....slowly. Here is a link to the version proposed by the European Council
http://data.consilium.europa.eu/doc/document/ST-9565-2015-INIT/en/pdf



The new EU Data Protection regulation took another step on its long road towards becoming law.  What does this mean for application design and security?

Originally proposed by the EU Commission in January 2012, the EU Parliament has now supported it (with lots of amendments to the original proposal). The next step on the long road is the EU Council of Ministers.

Who knows when/if this becomes law, but it is worthwhile being aware of it. It is long and complicated and will change.

What could this mean for application design and security? Here are some of the proposed amendments which may impact your application design and security when processing personal information of EU citizens. These are just the barest details based on the amendments proposed by the  EU parliament. There is more information in the links below.

Article 15 - Amendment 78 - Right to Rectification and Completion

In this amendment, the data subject can request that any information be corrected. For the application developer, this means that there should be some way to correct personal information that the application stores.

Article 16 - Amendment 79 - Right to Erasure

The data subject can request that their personal data be deleted. There are various conditions around this. Basically it means that application should have the ability to delete a user's information at their request.

Article  19 - Amendment 81 - Data Protection by Design and by Default

This is a core article from a security perspective. It talks about "protection by design", "risk", "entire lifecycle management of personal data from collection to processing to deletion". 

Security of personal data cannot be an afterthought. It must be considered from the start of the application design. 

Article 24 - Amendment 86 - Keeping of Records

This article essentially means that the application must keep an audit trail. It even mentions such items as "date and time". 

Article 27 - Amendment 90 - Security of Processing

This is another one directly related to application security. The main clause states that the data controller or processor must:

"implement appropriate technical and organisational measures and procedures to ensure a level of security appropriate to the risks represented by the processing and the nature of the data to be protected, having regard to the state of the art and the cost of their implementation."

Again this clause mentions risk. The article itself lists a number of more detailed requirements covering such security measures such as access control etc.

Useful Links

• EU Data Protection 12th March 2014 - Amendments proposed by EU Parliament

• http://www.theregister.co.uk/2014/03/12/european_parliament_waves_through_data_protection_reforms  

•  EU Press Release 12th March 2014 - Progress on EU data protection reform now irreversible following European Parliament vote

•  25th January 2012 - EU Commission proposes a comprehensive reform of the data protection rules

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

NIST Cybersecurity Framework

The NIST has just released the Cybersecurity Framework Version 1.0. This is mainly intended for improving critical infrastructure type facilities in the USA. However, it can potentially be applied to a much broader range of organisations across the world.

It covers 5 main functions of a cyber security framework.

• Identify
• Protect
• Detect
• Respond
• Recover

Each of these functions is then broken down into categories and the categories are further sub divided into subcategories.

This is two more than Bruce Schneier who defines Protect, Detect and Respond.

The basic idea is that you take the categories and analyze it to define your current profile. You then define a target profile and work out action plans and prioritizations to achieve the target profile.

It is not a very long document and much of the useful information is stored in the appendixes. It widely references other public standards.

Application Security

The framework does not have much to say about secure application development.  However it is extensible so you can add in your own categories and sub categories. It does talk about access control, data-at-rest and data-in-transit controls etc.

PR.DS-7 says:

The development and testing environment(s) are separate from the production environment

Useful Links

• NIST Press Release 
• http://www.nist.gov/cyberframework/upload/cybersecurity-framework-021214.pdf

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

Data Flow Diagrams and PCI DSS Version 3

I just noticed that the Payment Card Industry - Data Security Standard (PCI DSS) Version 3 has a new requirement at 1.1.3. The old 1.1.3 in PCI DSS version 2 is now requirement 1.1.4 in PCI DSS version 3.

PCI DSS Requirement 1.1.3

So what does new requirement 1.1.3 say?

"Current diagram that shows all cardholder data flows across systems and networks"

The testing procedure for this requirement says

"Examine data-flow diagram and interview personnel to verify the diagram:

• Shows all cardholder data flows across systems and networks.
• Is kept current and updated as needed upon changes to the environment.

And finally the guidance says

"Cardholder data-flow diagrams identify the location of all cardholder data that is stored, processed, or transmitted within the network. Network and cardholder data-flow diagrams help an organization to understand and keep track of the scope of their environment, by showing how cardholder data flows across networks and between individual systems and devices."

The Fundamentals

Data Flow Diagrams (DFD) are a powerful tool in many situations. Whether in the role of PCI QSA or security architect where you are trying to work out the appropriate level of security requirements. This new PCI requirement recognizes this. While PCI really only cares about payment cards, DFDs can and should also be used wherever you are analyzing data which is important to your organization.

A DFD consists of three main sections:

1. It shows the data flows - i.e. the networks etc. through which data passes.
2. It shows data storage areas. This indicates where data is stored within the system 
3. Finally the DFD highlights trust boundaries. This is where data travels across boundaries which are not trusted. The interface to the internet is typically a trust boundary.

A DFD need not be complicated. At its simplest it consists of a series of boxes indicating the data storages on a whiteboard while lines showing where data flows.

When creating a DFD, make sure to ask a series of questions such as:

• Where are backups held? 
• How are test systems and data handled. Remember, if live production data is used in a test system, the same level of security must apply as in the production system.
• Can users export data to desktops etc.?

These questions help build up a complete DFD picture.

When you have a good DFD, then you can start specifying the appropriate level of security controls that are required for each flow and storage within the DFD. For example, if sensitive data flows across the public internet then it should be encrypted using SSL. A DFD helps answer these types of questions.

DFDs and Application Security

DFDs apply when developing applications and choosing security controls. They help working out what type of security controls are required whenever data is at rest or in motion. When developing the security requirements for the application, the development team should develop appropriate DFDs. This should be done early in the development life cycle.  The DFDs can then be used to make sure that the proper security controls are in place which reflect the security drivers for the application. These security drivers can include data protection legislation, PCI DSS, internal corporate policies.

Useful Links

• PCI Security Standards Council
• PCI DSS Version 3
• Wikipedia: Data Flow Diagram

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

Mobile Phone Security Malware Statistics - Mobile Application Security

Which of the following statements do you believe? 

1. "Given that there are around 1.5 billion smartphones and tablets in the world, that means probably fewer than 15,000 of them are harbouring mischievous software." -  The Economist -  November 2013
2. "32.8 Million Android Phones Infected with Malware" - Techlicious.com - April 2013 based on information from NQ Mobile

(As a long time "Economist" reader, I probably tend to go with number 1.)

Does it matter?

If you are trying to make informed decisions around mobile phone security for yourself or your organisation, then it does matter. Go with statement number 1, then you will be trying to implement controls to ensure around the risk that the device will be lost or stolen (encryption, backups etc.)

Favour statment number 2, and you will be thinking more about security controls like anti-virus applications etc.

The Economist article goes on to say:

"Gartner, an information-technology consultancy based in Stamford, Connecticut, advises clients not to worry too much about malware penetrating their networks through the devices employees bring to work. It is the users themselves who are the problem. How, for instance, do companies prevent employees from innocently responding to “spear-phishing attacks” in the form of individually targeted, and very official-looking, e-mail or text messages, apparently from trusted colleagues, that request sensitive information? Security measures need to focus more on educating users, says Gartner, rather than on the relatively minor problem of mobile malware. "

Mobile Application Security

What about mobile application security? The OWASP Top 10 Mobile 2014 risk "M2 - Insecure Data Storage" says about the threat agent:

"Threats agents include lost/stolen phones and the possibility of in-the-wild exploit/malware gaining access to the device."

If you believe The Economist, you will give less weight to the malware risk in your application design and more prominence to the lost/stolen phone risk.

If the device itself is properly encrypted, then you will be less concerned about storing sensitive data on the device. Since the risk of malware is low, then it is unlikely that malware will steal the sensitive data.

(Ok - you should still  be careful about what data your application stores on the device.)

Useful Links

• Sex Lies and Cyber-crime Surveys - Microsoft Research
• OWASP Mobile Top 10 Project

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

Can InfoSec Actually Help Save Money

Can Information Security actually help save money? 

In terms of InfoSec, we usually think of the possible potential for future savings. Hopefully, the thinking goes, if we invest in appropriate security controls now, we will not be hacked in the future. Calculations based on this approach, such as Return On Security Investment (ROSI)  try to make this argument. It's an insurance policy.

But the present question is can we use InfoSec to actually achieve verifiable savings, now?

Availability

The third leg of the InfoSec triad is Availability (the other two, as you already know, being Confidentiality and Integrity). In general, availability means having information available when you need it. But the flip-side of this is what to do with information when you no longer require it. Can we make savings here?

In general, companies and organisations tend to keep information for ever. We are afraid to get rid of it, because we might need it for a rainy day. However there is a cost associated with this. Even though storage costs keep going down, the amount of information that we generate keeps increasing. And it costs money to store all this data. Hardware costs, personnel, backups etc.

If the data can be deleted, then can these associated costs can be saved?

The possible answer is to delete it when it is no longer available. In fact, data protection legislation usually says something along the lines of "Delete personal data when it is no longer needed". If we can achieve this, then not only are we likely to save costs, but we are also more likely to be in compliance with legislation.

What are the necessary steps?

Data Retention Policy

Develop a data retention policy. This will define how long data is to be kept and when it can be deleted. This may give rise to conflicting requirements based on the type or classification of data that is being processed. As mentioned earlier, personal data should be deleted when no longer needed. However, financial  or transactional data may need to be retained for a certain amount of time for audit purposes. Important is to identify the different types of data that you process - and then to define retention periods for the various classification types. 

This bit can be tricky as you need to consider other issues such as information that may need to be retained for litigation purposes.

Identification

The next step is to identify the locations where information is stored and to classify these based on the data retention policy.

Deletion

Finally, delete the data  based on the data retention policy and on classification type.  Then you can reuse the freed-up space for newer data.



Money saved.....hopefully!!

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

OWASP Switzerland Chapter Meeting December 2013

OWASP Switzerland

Highlights

At our recent chapter meeting (including beer and addictive crisps*), which was kindly hosted by Credit Suisse in Zürich, we had an interesting discussion about application security and OWASP. Obviously no definitive conclusion was reached - but then that is not the point.

Topics included whether OWASP is obsessed with XSS at the expense of other issues. If your application does not have an audit trail, is this as as big a risk as an XSS vulnerability. This could be generalized to ask if there is too much emphasis on the purely technical and not enough on more esoteric issues such as risk etc. It was noted that the OWASP Top 10 is now based on risk and also that the new OWASP CISO project attempts to address more management type concerns.

Discussion was also had about the open/closed source debate and what advantages each had. The consensus seems to be that both are here to stay. Development houses should have programs in place to handle both.

2014  Plans

For 2014 the OWASP Swiss chapter is planning 6 meetings beginning in February and every two months after that. Keep an eye on the mailing list and on the OWASP Switzerland website etc. for more details.

 

As usual if any of you would like to give a talk on any particular topic then don't be shy.

A few ideas:
- Agile development and security
- Risk and application security
- Demos of OWASP products

Useful Links

• OWASP Switzerland
• OWASP Switzerland Twitter: @OWASP_ch 
• OWASP Application Security Guide For CISOs Project
• OWASP Top 10

* Americans call them chips - but they're wrong.

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

PCI PA DSS and General Application Security

Introduction

This blog entry looks at how to use the PCI PA DSS in your general application security program.

 

The PCI PA DSS (Payment Card Industry Payment Application Data Security Standard) version 3 has just been released.   According to the standard:

"The PA-DSS applies to software vendors and others who develop payment applications that store, process, or transmit cardholder data and/or sensitive authentication data". 

It applies to software vendors who develop applications which process payment cards (credit or debit cards). This is separate from the main PCI DSS (Payment Card Industry Data Security Standard) which applies to any organization which stores, processes or transmits payment card information. The PA DSS is targeted at developers.

While this is aimed at applications which are used to process payment card information, it can also be used as a general standard for application security. If you are involved in application security, you should have a look at the PA DSS standard because you may get some useful tips from it.

The standard contains 14 requirements. While some of these are specific to payment cards, most of the requirements can apply to general application security. In the requirement simply replace "payment application" by "application" and cardholder data or PAN by "sensitive data" and the contents can apply to any application. The application is the software application that you are developing and "sensitive data" is any sensitive data that your application may be processing e.g. personal information. The phrase "software vendor"  can be replaced by software developer - essentially the team that is developing your application.

What is the best way to use the standard for general application security? When designing your application, go down through each of the requirements in the PA-DSS documents and ask the following types of questions.

• Does this requirement potentially apply to my application?
• What is the risk of not implementing this requirement in my application?

Alternatively, if you have a secure development program within your organization, go down through the PA-DSS, perform a gap analysis and see if there are tasks which you should incorporate into your security program.

For example, requirement 5 covers the elements of a secure development program. This should really be the first requirement. Are there sections in requirement 5 which you can incorporate into your program? Requirement 4 covers application audit trails. In particular, it includes the types of information that should be stored in the audit log itself. Audit requirements are often not included in general application security requirements. However this is one area which can be expensive to retrofit but relatively cheap to incorporate if it is included from the beginning of the development.

Download and read the PA-DSS standard itself. Each requirement consists of a number of different subsections. There are 3 columns. Column 1 gives the requirement itself. Column 2 describes the testing procedure that that an auditor or tester would follow to see if the requirement has been implemented correctly.  Column 3 gives general guidance.  In reviewing the standard, you should concentrate on columns 1 and 3.

The following sections give a very brief overview of each of the requirements. However you should download and read the actual standard.

Requirement 1:Do not retain full track data, card verification code or value (CAV2, CID, CVC2, CVV2), or PIN block data

This is fairly specific to payment card applications and is probably irrelevant to your application.

Requirement 2: Protect stored cardholder data

Read through the requirement. Where it talks about cardholder data or PANs (Primary Account Number)  replace it with "sensitive data" and see do any of the recommendations apply to your application. Does data need to be encrypted or masked in some way when it is being stored.

Requirement 3: Provide secure authentication features

Secure authentication features apply to any application where authentication is required. It talks about username requirements and the types of password features that may be used.

Requirement 4: Log payment application activity

This requirement covers audit trail considerations. Does your application need an audit trail? In particular, requirement 4.3 covers the data that an application should record. This requirement is often neglected.

Requirement 5: Develop secure payment applications

This covers good development practices and should probably be the first requirement. Production type data should not be used in test systems. It talks about secure code reviews, secure training for developers.  There should be a "formal process for secure development of  applications". Requirement 5.2 covers the OWASP Top 10 type risks.

Requirement 6: Protect wireless transmissions

This is fairly specific to payment type applications and probably does not apply to most general applications.

Requirement 7: Test payment applications to address vulnerabilities and maintain payment application updates 

Test the applications properly and keep them patched.

Requirement 8: Facilitate secure network implementation

Essentially this is saying that the application should not have a negative security impact on the environment in which it is to be deployed. For example it should not require that insecure services such as FTP are needed.

Requirement 9: Cardholder data must never be stored on a server connected to the Internet

Your sensitive application data must be stored securely. It should not be on a server connected directly to the internet.

Requirement 10: Facilitate secure remote access to payment application

If remote access is required to your web application then it should be implemented securely.  Remote access should only be enabled when it is required and should only be allowed from specific ip addresses. Two factor authentication should be implemented. Default usernames and passwords should be changed.

Requirement 11: Encrypt sensitive traffic over public networks

Any sensitive data that your application processes should be encrypted as it travels over the public network. In most cases this means using SSL/TLS over the internet. However note, the standard itself mentions a number of other technologies including bluetooth etc.

Requirement 12: Encrypt all non-console administrative access

Your application should not use technologies such as telnet for administrative access.  SSH, VPN, or SSL/TLS should be implemented.

Requirement 13 and Requirement 14

These probably do not apply to general applications.

Useful Links

• PCI Security Standards Council 
• PCI PA DSS Version 3

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

ISO 27001:2013, 27002:2013 and James Joyce

The latest versions of the two ISO flagship standards are now available through ISO and other standards organisations such as BSI

They are a bit like James Joyces's novel "Ulysses".  Everybody agrees it's great, but very few have actually read it.

The problem with the ISO standards is that they are expensive. Each one costs in the region of £100 . They are not for the casual user. On the other hand, they will be valid for the next 7 to 8 years, going by the lifespan previous versions. If you are seriously interested in Information Security, you should consider investing.

Of the two, 27002:2013 is probably the more useful. It lists various security controls that could be implemented across a range of areas.

The site http://www.iso27001security.com/html/27002.html gives a good overview of the contents of the 27002 standard.

If you don't want to fork out the money, then consider looking at the NIST special publication series.These are free. Start with Managing Information Security Risk. This is the flagship document in the series. Section 1.3 links to the other important documents within the special publication series. Note that the NIST documents are meant to align with the ISO standards

"The concepts and principles contained in this publication are intended to implement for federal information systems and organizations, an information security management system and a risk management process similar to those described in ISO/IEC standards"

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

So secure that it's insecure

A few months ago, Jeremiah Grossman, WhiteHatSec CEO, gave a detailed account of the efforts he had to go through to get access to his encrypted disk image.  He had forgotten his password.

Luckily, it all worked out in the end. With the help of very smart people, he managed to retrieve the password.

So we know the encrypted disk image was very secure since even he could not access it.

But was it secure?

Let's start with two definitions from ISO 27000:2012

Availability:
property of being accessible and usable upon demand by an authorized entity.

Information Security:
preservation of confidentiality (2.13), integrity (2.36) and availability (2.10) of information

The definitions show us that "availability" is an important aspect of information security. The data must be "available on demand". In this case, the data was clearly not available on demand. Therefore the preservation of availability was not achieved. This means that an information security "event" occurred.

The  encrypted disk image was so secure that it was insecure. The ultimate insider attack.

Agreed, the logic outlined above is a bit contorted, but you get the idea.

Most people think about security in terms of confidentiality - the system was "hacked". However, don't forget that availability is the third leg of the information security triad:

• confidentiality
• integrity
• availability

For a system to be secure, it must preserve all three properties.

Useful Links

• ISO/IEC 27000:2012 (Free) 
• WhiteHatSec blog:Password Cracking AES-256 DMGs and Epic Self-Pwnage

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

Irish Data Protection Commissioner - Annual Report 2012

The Irish Data Protection Commissioner released his annual report for 2012. It is worth having a quick look through the press release and  report to see what are the current issues. It is especially worth reading the appendix 4 on the INFOSYS system, which gives access to data held within the department of Social Protection's system.

To quote from the press release:

• "One of the major themes in this year’s report concerns the issue of sharing personal data in the public sector which has featured regularly in previous annual reports from this Office". 

The importance of audit trails is stressed in relation to who accessed data. This is of particular importance in the public sector where you usually don't have a choice as to whether you appear in the database or not. Usually in the private sector, you have some sort of say about the sites that you use.

A number of cases are highlighted where data was accessed inappropriately by users of the INFOSYS system.

In addition, some members of the Police Force are shown to have accessed the PULSE Police system inappropriately to look at information on celebrities.

This matters. 

A few weeks ago, the Irish Independent reported on the powers that the Revenue Commissioners now have. Revenue Commissioners boss Josephine Feehily told a Government committee: 

• "that tax officials can now trawl through reams of data, including bank accounts and mobile phone numbers, to spot cheats."

This sounds like the kind of stuff that the old East German secret police could only have dreamed of - and it will only get worse. Governance in relation to how public bodies manages personal data is vital. The audits carried out by the Data Protection Commissioner are critical in making sure that there is some sort of proper security in place.

• How is this data used?
• Is this data misused and abused?
• How is the "mobile phone" and "bank account" data made available to the Revenue?
• Is it deleted when no longer necessary?
• Who has access to this data?
• Is there an audit trail of all access?
• etc.....the list goes on.

One good thing is that the Commissioner says that his office is adequately funded.

Useful links

• Irish Data Protection Commissioner - 2012 Annual Report  
• Irish Data Protection Commissioner - 2012 Press Release
• Irish Independent: 'Big Brother' software will find tax cheats, says Feehily

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

ICO Breach Statistics 2012

In 2012 the ICO (Information Commissioner's Office) in the UK found 5 websites to be in breach of  data protection act.

The ICO lists the actions that it takes against organizations that it deems to be in breach of the Data Protection act. This also serves as a useful source of statistical information which this blog entry briefly explores. There are a number of different actions that the ICO can take.

• Monetary Penalty Notices, 
• Undertakings
• Enforcement Notices
• Prosecutions

Overall Statistics

For 2012 here are the overall statistics.

	Total for Action	Nr for Web Application
Monetary Penalty Notices	24	1
Undertakings	29	4
Enforcement Notices	03	0
Prosecutions	06	0
Overall Total	62	5

There were 62 incidents of which 5 relate to websites. Given the number of online applications that process personal information, 5 seems to be a remarkably small number.

Here is a high level overview of the web application incidents.

Monetary Penalty:

• 6th August: Sensitive personal information relating to 1,373 employees was published on the  website.

Undertakings:

• 1st March: Disclosure of personal information in training materials published on its website
• 17th April: a web design error that created the potential for unauthorised access to individual’s personal data 
• 18th April:  Two data security incidents which relate to the unauthorised disclosure of personal data on the data controller’s website.
• 30th November: A private area on the website was accessible to members of the public

The Rest of the Incidents

The rest of the cases are made up of a mixture of the usual suspects:

• Information being sent to the wrong recipient. 
• Paper files left in waste bins. 
• Unencrypted memory sticks. 
• Hard drives not securely erased at end of life.
• etc.

It is worth taking a look at the ICO website taking actions page to get a feel for the kind of problems that exist. There is no real pattern. Website issues are only a small proportion of the overall numbers. It shows how difficult it can be for a security manager to put a comprehensive security program in place.

Useful Links

• ICO Enforcement 

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

Information Security Error Caused Austerity

The headline of which we dream.

It looks like there was an Excel coding error in one of the main academic papers which brought this age of austerity upon us. The spreadsheet that the authors used is not accurate.

The Roosevelt institute blog has all the dirty details.

Now for the Information Security angle. We all know that information security is about protecting the confidentiality, integrity and availability of

According to ISO 27000, information security is the

• "preservation of confidentiality, integrity and availability of information"

Also according to ISO27000, integrity is the

• "property of protecting the accuracy and completeness of assets"

The Roosevelt blog shows that the Excel spreadsheet was not accurate.
Since the accuracy isn't protected, then there is an integrity issue.
And since there is an integrity issue, there is an Information Security issue.

QED.

Imagine having to tell the people of Europe that all these austerity measures are the result of an Information Security problem in an Excel Spreadsheet.

Useful Links

• Roosevelt Institute Blog: Researchers Finally Replicated Reinhart-Rogoff, and There Are Serious Problems. 
•  ISO/IEC 27000:2012 

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

ISO 2700x Standards on the Cheap(ish)

Most people agrees that ISO 2700x family of security standards are a good idea. But like James Joyce's Ulysses,  how many have actually read it? 

The big problem is that they are  expensive to acquire. A casual user is probably unwilling to fork out the money. Even in big organizations it can be difficult to get hold of the standards.

The two main standards ISO27001:2005 and ISO27002:2005 each cost  Swiss Francs CHF134.-- (approx $143.00)  each on the ISO store. And there are a lot more standards.

 Recently I discovered that you can purchase the main 27001 and 27002 copies of the standards from ANSI for $30 each. See Useful Links below. This is a big saving compared to the standard ISO price. The main difference is that the branding is from INCITS ((InterNational Committee for Information Technology Standards)). The text itself seems to be the same.  Of the two, the 27002 is the more useful, as it lists many best practice security controls or measures that you can implement in your organization. The other ISO2700X standards are not available so cheaply through ANSI.

You can also download ISO/IEC 27000:2012 "Information technology -- Security techniques -- Information security management systems -- Overview and vocabulary" for free.

Useful Links

•  ISO/IEC 27000:2012 (Free)
• ANSI INCITS/ISO/IEC 27001-2005 ($30)
• ANSI INCITS/ISO/IEC 27002-2005 ($30)
• Ulysses (Priceless) 

 

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

Which is it ? - Cyber Attacks cause Huge Losses or no Losses

Do cyber attacks cause real damage or not?

According to Bloomberg:

"The 27 largest U.S. companies reporting cyber attacks say they sustained no major financial losses, exposing a disconnect with federal officials who say billions of dollars in corporate secrets are being stolen." 

Are these companies telling the truth? These reports are based on recent filings with the Securities and Exchange Commission (SEC) so one would imagine they should be fairly honest.

According to the BBC:

"In 2012, the head of MI5 Jonathan Evans said the scale of attacks was "astonishing".

One major London listed company had incurred revenue losses of £800m as a result of cyber attack from a hostile state because of commercial disadvantage in contractual negotiations."

If it's a listed company, would they not have to reveal the loss in their annual report? Does anybody know who this company is?

If you are interested, it's worth reading the paper "Measuring the Cost of Cybercrime" by Ross Anderson and associates.

Useful Links:

• BBC: Anti-cyber threat centre launched
• Bloomberg: Cyberattacks Abound Yet Companies Tell SEC Losses Are Few
• Measuring the cost of CyberCrime (PDF)

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

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