Sunday, 27 November 2011

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:







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

Monday, 31 October 2011

Australian Online Applications Are Secure?

The Australian Defence Signals Directorate (DSD) published the Top 35 Mitigation Strategies to:
  • "mitigate targeted cyber  intrusions.  The  list  is  informed by DSD’s experience  in operational cyber  security,  including  responding  to  serious  cyber  incidents  and  performing  vulnerability   assessments and penetration testing for Australian government agencies.

According to DSD:
  • "Rankings are based on DSD’s analysis of reported security incidents and vulnerabilities detected by DSD in testing the security of Australian Government networks. "
However, if you review the 35 strategies, there is no mention of the need to develop applications securely. SQL Injection, XSS etc. are all missing.

Does this mean that Aussie Apps are secure? Have they got it sorted? (Eventhough they seem to be crap at bog ball ++ (and struggle at rugby))



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

    Saturday, 8 October 2011

    Installing Hacking-Lab Live CD

    In preparation for the OWASP Switzerland meeting on October 11th you should try to install the Hacking-Lab live CD.

    These are the simple steps I followed on a Windows 7 laptop.

    • Dowload the Virtual Appliance OVA file to your laptop
    • Download and install the Oracle Virtual Box  application onto your laptop
    • Double-click the .ova file through Windows Explorer and the appliance import process should commence on the Virtual Box application. You should see something like Fig 1:
    Fig. 1: Oracle VM Virtual Box Manager

    •  In  theVirtual Box Manager left-hand pane double-click on the LiveCD-Hacking-Lab-V5.55 entry. The LiveCD should start and after a short while  the Welcome screen as shown in Fig 2 should appear.
    Fig 2: Welcome Screen
    You should be ready to go now at the OWASP meeting.

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

    Tuesday, 4 October 2011

    OWASP Switzerland Chapter Meeting - October 11th



     OWASP Switzerland Chapter Meeting
     
    When: October 11th, 17:00 - 19:00
    Where:   ITACS by Bitterli Consulting AG
                   Stampfenbachstrasse 40
                   CH-8006 Zurich

    Price: Free (but you need to reserve a place)

    Topic:
    Presentation of the OWASP Top 10 by Cyrill Brunschwiler from Compass
    Security (http://www.csnc.ch/en/) followed by a hands-on session.


    More Information: OWASP Switzerland


    
    

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

    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