Monday 29 August 2011

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:
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

Wednesday 24 August 2011

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:

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

Thursday 4 August 2011

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:

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

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