Swiss Data Protection and Online Applications

Update:18/9/2011 Major Revision


If you are developing online applications in Switzerland which process personal information, what does Swiss Data Protection Legislation require you do to?

This post looks at the major technical items and some of the implications that it may have for your online development project. There are two main items:

• Federal Act on Data Protection
• Ordinance to the Federal Act on Data Protection (OFADP)

Federal Act on Data Protection
The main piece of legislation is the "Federal Act  on Data Protection".  There are 39 articles divided into 8 sections. This blog reviews some of these articles and what it may mean for your development. It is not comprehensive but just a guide. It does not consider the later sections such as those dealing with processing by Federal Bodies

Art. 3 Definitions

Implications: Use the definitions section to decide if the legislation applies to your application and whether you are processing personal or sensitive personal information

Art. 4 Principles

Implications: The development should have a privacy statement or similar, which describes how personal data is used.

Art. 5 Correctness of the data
Implications: The application should somehow allow users view and update their personal information. This can be done either directly (by the user) or indirectly (e.g by an administrator).

Art. 6 Cross-border disclosure
Implications: You need to be careful about transferring personal data outside of Switzerland. In particular be wary of development teams and test teams who are based outside the country. "Test data" that they are using might still be real personal data.

Art. 7 Data Security
Implications: This is the main artcile on security. It states that: "Personal data must be protected against unauthorised processing through adequate technical and organisational measures". This is where good security practices such as the OWASP Top 10 come into play

Art. 8 Right to information
Implications: The application will need to allow persons to view their information.Typically the user be able to logon and view their information. The other main method is that the user can request to see their information from the data controller. The controller must then be able to retrieve the information from the application and make it available to the user.

Art. 10a Data processing by third parties
Implications: You may outsource processing to a third party. However the third party must have adequate levels of security in place.


Art. 11a Register of data files
Implications: Under certain circumstances you may need to register with the commissioner. For example, if you process sensitive personal information.


Ordinance to the Federal Act on Data Protection (OFADP)
The OFADP is the second major element of Data Protection legislation. From a security perspective there are two significant articles: 8 and 9.

Art. 8 General measures
Implications: Article 8 (general measures) states that people who process personal information:

• shall ensure the confidentiality, availability and the integrity of the data in order to ensure an appropriate level of data protection

The security measures that you take depend on a number of items, including the purpose and extent of processing, current state of the art and "an assessment of the possible risks to the data subjects". So some sort of risk analysis should be undertaken.

Art. 9 Special measures
Implications There are 8 (a-h) special measures.These talk about typical security controls such as security during transmission and storage, authentication, access control, etc. Of particular interest is clause h which states:

• input control: in automated systems, it must be possible to carry out a retrospective examination of what personal data was entered at what time and by which person.

Therefore, Clause h implies that your application must have a proper audit trail.

So if you are implementing a system which processes personal information, then it is worth while reading down through the information in the following links.

Useful Links:

• Federal Act on Data Protection
• Art. 7 Data security

• Ordinance to the Federal Act on Data Protection (OFADP) 
• Art. 8 General Measures 
• Art 9 Special Measures 

Note: These are English links. As each link says - "English is not an official language of the Swiss Confederation. This translation is provided for information purposes only and has no legal force."  However you can find links to all four official languages on the top of the HTML pages. This way nobody is offended - or everybody is offended equally.

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

RBS and HAYS contractor rates snafu

So, Hays recruitment "distributed an email disclosing the remuneration of thousands of contractors working for the state-backed Royal Bank of Scotland". Details are unclear, but a few questions from an Information Security perspective.

• Why is this type of information lying around in an attachment?
• Was the email attachment encrypted?
• Why is there not some sort of Data Leakage Prevention (DLP) in place? A "Little Britain" type computer program which looks at the email recipients (800) plus attachment (3000 names) and replies "Computer says: Are you Sure?"
• etc.
   

Can your organisation learn any lessons, before it's too late? Here's an opportunity to get some extra security budget.

Maybe our old friend the Data Flow Diagram (DFD) could have helped....here we go again.

Useful Links:

• Sky News: Exclusive: Hays Discloses RBS Pay Deals
• The Register: Agency sends contractors' day rates to 800 RBS staff
• YouTube: Little Britain - Carol says No - Computer says No
• Data Flow Diagram
  

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

Tallaght and Roscommon Hospitals Data Breaches and Data Flow Diagrams

Updated: August 11th August to include Roscommon Hospital breach.

Tallaght Hospital* in Dublin, Ireland, recently suffered a data breach. Details are unclear but it involved outsourcing of transcribing services to Uscribe, a company based in the Phillipines. Something went astray.

In the Roscommon County Hospital incident, confidential paper medical records from patients treated in Midland Regional Hospital in Mullingar were discovered in a rubbish bin in the grounds of Roscommon County Hospital.

Would simple Data Flow Diagrams (DFD) have prevented these? Don't forget that Data Protection legislation also applies to paper records.


So here are some reminders. At the start of a project draw a simple DFD. This should show where data flows and where it is stored in the system. Don't forget to ask the following types of questions.

• Does anybody export data to laptops, USB sticks etc.? (Danger Danger)
• How are backups handled? Are they managed by third parties?
• Is the same production data used by test systems, development companies etc.?
• What about data used for trouble shooting, diagnositic purposes? Is that properly deleted when it is not longer needed?
• Are processes in place to securely erase any hardware when it is being disposed of? 

The same types of questions can be asked about paper based records.

When you have indentified all the data flows and data storages, then you can ensure that you have adequate security measures in place for all of these points. In the case of Tallaght the DFD would have shown that data goes to the Phillipines. Since this is personal data, special measures for "Transfers Abroad" need to be in place. In the case of Roscommon, the DFD might show that paper records aren't destroyed securely.

When you are embarking on your next project, don't forget to use a simple DFD.

Some links:

• Irish Data Protection Commissioner - Transfers Abroad
• UK Information Commissioner's Office -Sending personal data outside the European Economic Area (Principle 8)
  
• Data Flow Diagrams 

• siliconrepublic.com - Gardaí to probe data breach at Dublin hospital
• Irish Times - Patient data leak not confined to Tallaght hospital, says chief
• RTE - Roscommon Hospital 

(*) Full Name "Adelaide and Meath Hospital, inc National Childrens Hospital, Tallaght"

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

CitiGroup Breach - 3 SDLC Activities that Failed

CitiGroup recently admitted a security breach where hackers got details from lots of credit card customers. The attack itself seems to have been fairly simple. The attacker logged on normally to an account. They then ran a script which iterated through the account number in the browser address bar. According to the New York Times,  they "automatically repeated this exercise tens of thousands of times — allowing them to capture the confidential private data."   In OWASP Top 10 speak this was a insecure direct object reference vulnerability.

It looks like a fairly simple vulnerability, although the details are unclear. But it should not have happened.  Here are three Secure Development Life Cycle  (SDLC) activities which, if implemented properly, would have probably prevented this attack*:

1. Authorisation checks were not implemented properly to check that the logged on customer had permission to view the details for the requested account number. This is a failure in the analysis/design phase. Whenever a user initiates a request your application should check that the user has permission to execute this particular transaction. There are two basic levels. At a coarse level, check that the user has permission to access this page. At a finer level, the user may have access to a particular page. However, does the requested account (or resource) belong to this user?
   
   It may be that authorisation checks were designed correctly by CitiGroup, but not implemented by the development team. In this case the assurance/testing phase should have come to the rescue.
2. During the assurance phase, this vulnerability should have been picked up. A penetration test which probed for various account numbers would most likely have caught this. Similarly a code review  would have indicated that something was wrong. This is what the OWASP Application Security Verification Standard (ASVS) is aimed at.
   
3. Finally, Application Monitoring during operation did not recognise the suspicious behaviour that numerious requests were coming from a single account. If proper monitoring had been in place, Citi may been alerted much sooner (maybe in real-time) to the problem. The OWASP AppSensor project could help here.

So learn the lessons. Make sure that you have an SDLC in place for your development process.
Have a look at the SLDC Main Posts which shows the main SDLC related posts on this blog and what are the most important steps in a SDLC.

Links:

• SDLC Quick Reference 
• OWASP AppSensor Project
• OWASP ASVS
• OWASP Code Review
• OWASP Testing
• New York Times  
• The Register

 * Of course this is all speculation, since we don't know what really happened.

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

Developing Securely for SmartPhones - A few Key Principles

At AppSecEU last week, I attended Dan Cornell's (Denim Group)  presentation  on Security Testing Mobile Applications. You can view the slide deck on the Denim Group blog.

Basically, Dan demonstrated how you can "root" the smartphone and then reverse engineer the application to do whatever you want. Slide 6 shows a "Generic Mobile Application Threat Model" for a SmartPhone app connecting to an enterprise application.  It shows the following threats:

1. Malicious User
2. Malicious User (bypassing Mobile Client)
3. Malicious Mobile Application
4. 3rd Party Services (Possibly Malicious)

Nr. 2 is where a malicious user bypasses the smartphone completely and attacks the enterprise web services which the smartphone uses.

Nr. 3 is a malicious application which is installed on the smartphone and can interfere with other installed applications.

Nr. 4 is where the smartphone connects to 3rd party services which have been compromised.

Key Principles

So what  are the lessons when developing enterprise type apps for smart phones? Here are a few thoughts. These are based in part on a short conversation I had with Dan after his talk*.

1. Treat the smartphone as an "untrusted device".
2. If possible, don't store confidential information on the phone. 
3. Develop your web services securely, as an attacker may discover the web services and attack them directly - bypassing the smartphone completely.
4. Your web services should validate any input data and perform the necessary authorisation, access control, business logic checks etc.. Any validation performed on the phone should be repeated by the web service
5. Use SSL to prevent man-in-the-middle type attacks.

* These may not be an accurate reflection of Dan's views!

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

My OWASP AppSec Europe 2011 Presentation

I gave my presentation today at OWASP App Sec Europe 2011 today.

Here is a link to the slide deck. 

Note! It's in PDF format.

The talk is aimed at the developerment team. At the start of a development project you should think a bit about security. In the presentation I go down through a simple structured list of security  tasks that you should address in order to gather the security requirements that the project should implement.

                   
                                          

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

Your OWASP AppSec EU Homework

This is your homework if you are coming to my presentation at the OWASP App Sec EU talk  on Friday June 10th, in Dublin. I'm going to use this completely ficticous application - the Brochure Co (BCo) website. This post is to give a quick overview of the application and a number of use cases which it will implement.

The main goal of the talk is to specify the security requirements that the application development team should incorporate during the implementation of the BCo website. 

The presentation will describe a set of topics that should be covered during a security workshop which is held at the start of the project.

Description
Brochure Co (BCo) is a company that manages and distributes a range of printed brochures on behalf of its clients. These brochures are sent out via normal mail on a regular basis. The new online application will allow BCo  users to register online and choose the brochures that they want to receive through the normal mail.

Use Case 1 - Registration
BCo users register with the  Bco.demo website. They enter their name and postal address. They choose what brochures they want to receive.

Use Case 2- Edit
BCo users can logon to the site and modify their address details as well as change the range of brochures that they receive.

Use Case 3- Delete
BCo Users can delete their accounts when they no longer want to use the application

Use Case 4- WebSite Admin Downloads Addresses
On a regular basis, the BCo Website Admin logs on and downloads the list of BCo user names and addresses as well as the list of brochures that they want to receive. The list is downloaded as a CSV file to their laptop. The BCo Website Admin cleans up the list.

Use Case 5 - WebSite Admin Forwards List
The BCo website admin then sends the cleaned up list in a spreadsheet format to PrinterCo in an email. PrinterCo then prints the brochures and sends the brochures to the BCo users via normal mail.

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