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

ICO Website and Cookies Law - Strange

The new cookies law comes into force in the UK today, although the ICO (Information Commissioner's Office) is allowing one year to comply with the new rules. The purpose is to ensure that:

• "businesses and organisations running websites in the UK need to get consent from visitors to their websites in order to store cookies on users’ computers. "

How the ICO does it 
The  ICO on its website shows how it could be done - and it's strange. If you visit the website you are shown a fairly ugly header at the top:

It gives you an option to say "I accept cookies from this site". So the first thing that strikes you is why is there is no option to say:

• "I DO NOT accept cookies from this site."

The ICO site uses Google Analytics to track visitors. You can go to the ICO Privacy Notice page and follow a link which allows you to download an AddOn from Google which might allow you to disable the cookies....but I doubt if many users will go to the effort of doing that.

Fiddler shows me that if I don't click on the "I accept cookeis from this site" header and just leave it there, no traffic goes to Google Analytics

So in effect, if you don't want to accept ICO cookies, the best thing is leave the header on top of the screen and not to click it. Just ignore it.



Firefox - Do Not Track

Do Not Track - DNT

In addition I use Firefox 4 and I have set the option

• Tell web sites I do not want to be tracked

 This is under "Tools!Options!Advanced!General". This sends a DNT request in the Request Header. So ideally the ICO should honour that and should never ask me in the first place whether I want to accept cookies.


Conclusion
The way the ICO website implements the new cookie law is not elegant.

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

My OWASP AppSec Europe 2011 talk

I'm giving a talk at the OWASP AppSec Europe talk in Trinity College, Dublin, Ireland on Friday June 10th at 11:10. It's part of the Prevent track.

The talk is aimed at developers (or builders as OWASP calls them). At the start of a development project you should think a bit about security. In the presentation I will go down through a simple structured list of security  tasks that you should do in order to gather the security requirements that the project should implement.


If you spend a few hours thinking about security early on, you could save yourself a whole lot of problems later on. A workshop with the relevant people is a suitable format for this. The list of tasks which the presentation outlines can form the basis for this security workshop.  

In fact, you can use the list of tasks as the agenda for the workshop.

A fictitious website which processes personal information (as defined by EU Data Protection Legislation) will be used as an example.

Even QEII likes the list

The list will include the following:

• Data Classification
• Simple Threat Analysis
• Data Flow Diagram
• User LifeCycle/Authentication etc.
• Authorisation
• Segregation of Duties
• Audit Trail
• Data Retention
• Availability/Resilience
• Other Compliance Issues

If you spend a few hours at the start of a project going through this list, you will have a good idea of your security requirements and what you need to do. It is much better than trying to do this at the end.

This is what I will try to get across in this talk. So if you are on the development side of the house and you are interested in a simple approach to specifying your security requirements then do come along to the talk.  It will be an XSS-free zone!


The security list is based on Section 2 of  the SDLC Quick Reference

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

ICO Data Protection Principles and Online Applications

Schedule 1 to the UK Data Protection Act lists 8 data protection principles. You can read more on the Information Commissioner's Office (ICO) website here. If you are developing an online application which processes personal information what are the implications?

This blog entry delves a bit deeper.

Privacy Notice

First, a short discussion about the "privacy notice". According to the ICO, this is the notice "that individuals are given when information about them is collected". Typically you will display it on your website.  The ICO has issued a Privacy Notices Code of Practice  "to help organisations draft clear privacy notices and to ensure they collect information about people fairly and transparently".

Having a proper "Privacy Notice" in place is the main step you can take in adhering to a number of the Data Protection Principles.  So one of your first tasks is to develop an appropriate Privacy Notice and then to adhere to it.

Data Protection Principles

The following sections lists the principles and the implications they may have for your online development.

Principle 1
Personal data shall be processed fairly and lawfully and, in particular, shall not be processed unless –

(a) at least one of the conditions in Schedule 2 is met, and

(b) in the case of sensitive personal data, at least one of the conditions in Schedule 3 is also met.

Implication: Have an appropriate Privacy Notice in place.
                                                                           *      *      *

Principle 2
Personal data shall be obtained only for one or more specified and lawful purposes, and shall not be further processed in any manner incompatible with that purpose or those purposes.

Implication: Have an appropriate Privacy Notice in place.
                                                                           *      *      *

Principle 3
Personal data shall be adequate, relevant and not excessive in relation to the purpose or purposes for which they are processed.

Implication: Have an appropriate Privacy Notice in place.
                                                                           *      *      *

Principle 4
Personal data shall be accurate and, where necessary, kept up to date.

Implication: The application will need to be able to provide users with access to their personal information. The application should also have a mechanism to allow personal information to be updated. For example, if a user moves home, the application should have a facility in place which supports address updates. Either the user does this themselves directly by logging on, or a Customer Services Agent has the ability to do this on behalf of the customer.
                                                                           *      *      *

Principle 5

Personal data processed for any purpose or purposes shall not be kept for longer than is necessary for that purpose or those purposes.

Implication: This should be covered under a data retention policy. The application will need a manual delete function which removes a user's personal information. Either the user does this themselves directly by logging on, or a Customer Services Agent has the ability to do this on behalf of the customer.

The application may also need an automated delete mechanism which automatically erases customer information after a certain period of time or inactivity.

You need to be careful about this principle as it may conflict with other requirements which force you to maintain records for a certain minimum period of time. This could especially be the case with financial transactions.

Another tricky area is audit trails. How long should they be retained for?
                                                                           *      *      *

Principle 6
Personal data shall be processed in accordance with the rights of data subjects under this Act.

Implication: Have an appropriate Privacy Notice in place.
                                                                           *      *      *

Principle 7
Appropriate technical and organisational measures shall be taken against unauthorised or unlawful processing of personal data and against accidental loss or destruction of, or damage to, personal data.

Implication:  This is where the main information security good practices come into play. These include topics such as authentication, authorisation, encryption, audit trail, OWASP Top 10 etc. The Security Requirements section of the SDLC Quick Reference is essentially aimed at trying to meet the requirements of this principle.
                                                                           *      *      *


Principle 8
Personal data shall not be transferred to a country or territory outside the European Economic Area unless that country or territory ensures an adequate level of protection for the rights and freedoms of data subjects in relation to the processing of personal data. 

Implication:  Before transferring personal data to a third country, you need to ensure that the third country has adequate levels of protection in place.  You need to be careful about using real personal information in development and test environments - especially if you outsource development to third parties.

Subject Access Request

One of the main rights which the UK Data Protection Act gives to individuals is the right of access to their personal information. A user can send a Subject Access Request  requiring you to provide them with a copy of the personal information that you hold about them.

Implication:  Your application should provide functionality which supports this requirement. When a Subject Access Request arrives, your application should have a function which can return all information for that user.

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