Threats- Some Thoughts

During the analysis phase of the application development life cycle, it is worth looking at the security threats which your application may face.  OWASP defines the following general threats for online web applications:

Threat Name	Description
Accidental Discovery	An ordinary user stumbles across a functional mistake in your application, just using a web browser, and gains access to privileged information or functionality
Automated Malware	Programs or scripts, which are searching for known vulnerabilities, and then report them back to a central collection site.
The Curious Attacker	A security researcher or ordinary user, who notices something wrong with the application, and decides to pursue further.
Script Kiddies	Common renegades, seeking to compromise or deface applications for collateral gain, notoriety, or a political agenda
The Motivated Attacker	Potentially, a disgruntled staff member with inside knowledge or a paid professional attacker
Organized Crime	Criminals seeking high stake payouts, such as cracking e-commerce or corporate banking applications, for financial gain.

Other general threat types are:

• Denial of Service Attacks
• Environmental/Infrastructure Threats

The threats that you should be concernd about normally reflect the classification of the data that your application processes. For example if you are developing an online bank, you will need to have particular measures in place to tackle the last two OWASP threat types, Motivated Attacker and Organized Crime. However if your application is processing publicly available information such as product data, then it is unlikely that Organized Crime will be interested. You will mainly  be concerned about the first four threat types.

The threats that you are worried about will also influence the level of assurance that you want to have in your development. For the first four threat types, you might decide that assurance to  OWASP ASVS level 1 is sufficient. For the other threat types, higher levels of ASVS assurance may be required.

Many breaches result from loss of unprotected portable devices (USB memory sticks, laptops etc.) . If your application contains functionality which depends on the use of these type of devices, then this could well be your biggest source of accidental threat. That is why it is well worth while drawing some Data Flow Diagrams  to find out where the data is going within the application - and outside.

Normal good secure development lifecycle practices should protect you against the first four  OWASP threat types. For example proper implementation of SQL injection mitigation controls (stored procedures etc.) will prevent mass SQL Injection type attacks from being successful.

Motivated Attacker - Insider Threat

It is difficult to protect against an "insider attack". It is not easy to stop your DBA walking away with the entire corporate database. Bruce Schneier outlines five basic techniques to help mitigate the insider attack:

• Limit the number of trusted people.
• Ensure that trusted people are also trustworthy -  Background checks
• Limit the amount of trust each person has - Compartmentalization
• Give people overlapping spheres of trust -Separation of duties
• Detect breaches of trust after the fact and prosecute the guilty - Audit Trails

To combat the motivated attacker you will need to think about the higher levels of ASVS assurance.

Organized Crime

If you are worried about Organized Crime, then you probably already work for an organization (e.g. bank) who has appropriate measures in place.Use these.

Denial Of Service Attacks (DOS)

DOS attacks against organisations are becoming more popular especially against political type bodies. You will know whether you are likely to be a target for such attacks. Brian Honan has some general advice on his blog about what to do. An important point is to have a relationship with your ISP.

Environmental/Infrastructure Threats

Other threats which could cause a problem are hardware/infrastructure type issues which impact on availability. If a hard disk crashes, or there is a flood or a power outage, what measures are in place to get the application online again? Depending on the organization that you work for, you may already have procedures in place to handle these types of situations. Having a good backup/restore plan (which has been tested) is usually a good starting point.

Summary

When starting out on your development, think about the threats which you may face. Good secure development practices should prevent the most common types of application security threats.

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

Data Flow Diagrams and Security Requirements

High Level Diagram

Updated: June 1st 2012

Dataflow Diagrams (DFD) can be really useful in helping you specify your security requirements when starting on a new web development project. Although there is a whole literature around the use of DFDs, you don't necessarily have to do anything fancy or complicated. Use simple boxes to show where data will be stored  and lines to indicate where data flows.

Before embarking on the DFDs, classify the type of data that you will be processing. Is it personal data, payment card data etc.?

Draw the DFD diagram at a fairly high level. It should contain boxes to indicate where data will be stored, and then lines between the boxes to indicate the data flows. Include any other important components such as end-users or other devices.

Simple Use Cases or stories will help you work out where data will be stored and where it flows.

An important concept is that of Trust Boundaries. This is where data comes from someplace or goes somewhere which you don't inherently trust. The internet is one obvious place - but it can also be within your own organisation. Data is coming from a different department, and you don't necessarily trust the data that they transmit.

High Level Diagram - with simple DFD

When you have drawn the diagram, then begin to look at security related issues. Threat Modelling is often used to help work out the security risks that you need to address. An issue with formal Threat Modelling is that it can be a relatively complicated technique. It is easy to lose sight of what you are trying to achieve. However, if you or your organisation are familiar and comfortable with the concept of Threat Modelling, then use it.


For the purposes of this exercise I am going to concentrate on a checklist or question based approach.

Data Stores

Your DFD will show where data is stored. For each of these locations ask the following types of questions. The answers will depend to an extent on the Data Classification of the information.

• Do we need to store the data here? Ideally, data should be stored in as few places as possible. So, for example, if your DFD indicates that data is going to be stored on an external USB stick or a laptop, this should raise a red flag.
• Do we need (all) this data? In some cases you may be storing excessive amounts of data. Data Protection Legislation requires that you only store as much information as you need.
• Do we need to take special measures to protect this data?   If you are processing data which falls under Data Protection Legislation then you would need to encrypt any data which is stored on portable media, such as USB sticks or laptops. For payment card information, you would need to protect data in a manner as set down by the PCI DSS standards.
• Who should have access to the data?  
• How do you control access to the data?  
• How do you monitor access to the data?  
• How long does the data need to be retained for?    
• What happens to devices at the end of their life cycle?  Devices which store sensitive or confidential information should be securely destroyed at the end of their life. Otherwise they might end up being advertised on ebay.

Data Flows

The next step is to look at data flows using similar types of questions. Of particular importance here is whether data flows across trust boundaries. You should have indicated these in your DFD.

So these are the types of questions for the data flows.

• Do you need to protect the confidentiality of the data?   If data is flowing across the trust boundary, such as the internet, then you will need to protect the data. Typically you will use technology such as SSL or its more modern variation, TLS.
• Do you need to protect the integrity of the data?   Maybe we need to check digital signatures on the data to make sure that it has not been tampered with.
• Do you need to validate the data?   Implement data validation etc., Using the techniques outlined in the OWASP Top 10. If it crosses a trust boundary then data validation should be used.
• Do we need all this data?   If the data contains excessive information, then delete the excess.
• How was the source authenticated?   If the information is crossing a trust boundary, then we need some mechanism to confirm the identity of the sender. Typically some sort of logon mechanism is used for authentication.
• Are there any other measures which are necessary?  For example, to prevent message replay or message deletion.

Document your answers to the above questions. They should help you specify the security requirements that your application will need to meet. For example, now you should have a better idea of where you need to encrypt your data, perform validation, authenticate the user etc.

Some Gotchas

There are a number of areas where you need to be careful. Typically, these are the areas where data may be stored and you haven't thought about it.

Where is your backup stored? If it is stored externally, then you may need to think about mechanisms such as encryption.

Do you plan to use copies of your live production data in your test environment? Remember, that even though it's being used in the test environment, it still is live data and should have the same level of protection applied to it.

Do you write data to application log files or other similar type locations? You should make sure that this functionality is disabled on production systems.

Do you write sensitive data to your audit trail? Make sure not to write sensitive information such as passwords, names and addresses etc to your audit trail.

What about troubleshooting? Situations will arise where you need to extract production data to assist in troubleshooting. This could mean enabling application logging, or copying files to other systems where it can be analysed. You should have procedures  in place to make sure that this information is deleted when the troubleshooting has been completed. Also disable any logging which you may have turned on during the troubleshooting.

Conclusion

Data Flow Diagrams (DFD) are a useful tool in helping you specify the security requirements that your application needs to meet. The approach shown here is relatively simple and informal. In particular, it does not use Threat Modelling techniques to analyse your risks. To look at Threat Modelling in more detail, visit the Microsoft Secure Development Life-cycle (SDL) website which goes in to the technique in more detail. The approach I have shown here is more suited to development teams where there is no or only a limited security program in place.

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

ISSS Security Lunch - October 2010 - Review

Update 10/10/2010:  ISSS sent on a link to the presentation slides which I have included in the Links section at the bottom.
 
I attended the  Information Security Society Switzerland (ISSS) Security Lunch in Zürich on October 6, 2010. It was a civilised affair consisting of a sit down lunch, with a security presentation given between the first and main courses. About 20 people were present. I didn't know that ISSS existed until a few weeks ago.

The president of the ISSS, Thomas Dübendorfer gave a brief introduction to the speaker, Prof. Dr. Hartmut Pohl. Prof. Pohl is the CEO of softScheck which is a spin-off from the Hochschule Bonn-Rhein-Sieg  in Germany. Peter Sakal was also there to answer questions.

In his talk, Prof. Pohl gave an overview of their Secure Development Life Cycle (SDLC) which is called Rapid in-Depth Analysis (RiDA). The approach is similar to the Microsoft Secure Development Lifecycle (SDL). This is perhaps not surprising, since Microsoft is one of their partners.  RiDA places great emphasis on Threat Modelling, Fuzzing and Static Analysis. An important goal is to identify vulnerabilities before the project is actually launched. To achieve this, RiDA employs best-of-breed fuzzing tools to get the optimum results.  Code coverage is a significant driver. In their testing, softScheck aims to cover between 75% and 85% of the actual codebase.

Prof. Pohl provided statistics which show, that  RiDA identifies on average 50 critical vulnerabilities per application tested.

RiDA is a sound approach, as it provides a formalised SDLC methodology. But I can imagine that it is not cheap as, for example, the fuzzing tools require a lot of manual interaction. However, Prof Pohl argued that it is still a lot more cost effective to identify the vulnerabilities during the development phase than to wait until they are found in the wild.

As an aside, I wonder if that is always the case - especially in the web environment. A few weeks ago, a Cross Site Scripting (XSS) vulnerability was discovered in Twitter. While this was no doubt a bit embarrassing for Twitter, and perhaps did some reputational damage, they did have it fixed in a day or two. So it didn't cost too much and the issue itself will be quickly forgotten - except by us information security people.

Rapid in-depth Analysis is a contender in the drive to minimize security bugs, but you will probably need deep pockets to derive all the benefits. This implies serious commitment to security from company management.



Links:

• Presentation Slides (PDF)
• softScheck (German)
• Information Security Society Switzerland (ISSS) (German)
• Microsoft SDL
• XSS and Twitter

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

OWASP London Chapter Meeting October 2010 - Review

Last Friday night (October 1st 2010), I attended the OWASP chapter meeting in London. There were about 40 people present. A show of hands indicated that the majority of these were developers. It was held in the offices of Barclays Capital in Canary Wharf, so thanks to them for hosting the event.

How I Met Your Girlfriend - Samy Kamkar

Samy Kamkar was the first speaker on the agenda. Samy is well known because of the MySpace worm with which he was associated a number of years ago. He's kept a low profile since because, how to put this diplomatically, he was otherwise occupied.

However, he is now back in action and in the middle of his European tour. His talk was entitled How I Met Your Girlfriend. It was a highly entertaining talk, where his goal was to get the girl. The girl, in this case, being the girlfriend of a colleague. I think it was fictitious, although he was never quite clear on this point!

The talk covered a wide range of topics, from how to deconstruct a PHP session ID, to extracting the MAC address from a router, through to using Google location services to locate a physical address. I won't go into the details here. You should go to one his talks if you get a chance.

The talk was entertaining and informative, but ultimately slightly depressing. Depressing, not because of Samy, but because of the conclusion: the types of attacks he was demonstrating put yet another nail in the coffin of any illusions that we might have had about privacy. It's with O'Leary in the grave ¹. The discussion afterwards centred mostly on this privacy issue.

His European tour continues for the next few weeks. You can find more details on his website samy.pl.

Padding Oracle attacks (and ASP.NET 0-day) - Justin Clarke

In the second half of the meeting, Justin Clarke talked about the Padding Oracle vulnerability and gave a demonstration of his company's PadBuster tool.

Justin is OWASP's man in London.

For those of you who don't know, the Padding Oracle attack has been all the rage in the last few weeks. The attack targets weaknesses in the implementation of AES used in Microsoft asp.net, although it is not only Microsoft technology that is vulnerable. Last week Microsoft issued an out of sequence security patch. Everyone should apply this patch, even though Microsoft classified it only as being important and not critical.

Anyway, back to the talk. Justin gave a short overview of what the attack is about and how it works. It essentially targets the padding mechanism that is used to encrypt data (such as the viewstate) sent back by the application to the browser.

In the second half of his talk, Justin gave a live demonstration of the Gotham Digital Science PadBuster tool which is designed to automate the attack. The tool took a certain amount of tender love and care to get it to work - but work it did. It returned the contents of the web.config file from the sample asp.net application.

If you are involved in web application development, the main lesson to be taken from this, is that you should keep an eye out for any newly discovered vulnerabilities in the software components that you rely on. And then to make sure that you apply any relevant workarounds or patches that are issued.

Again, this was an enjoyable and informative talk with the added tension of the live demo. You can download a copy of PadBuster from here


With the business of the evening concluded, the chairman called a halt to proceedings. We adjourned to the local public house, where we told each other lies.

¹ William Butler Yeats: September 1913

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

Data Classification and Security Requirements

At the start of a web development project you should think about the security requirements that your application needs to meet.  What legislation, industry standards etc. are relevant? One handy way to do this is to classify the type of data that the application will process. The classification can help you work out the security requirements. In addition, many information security standards such as the ISO 27001 family,recommends the use of data classification.

Here are a number of classifications which may be useful.

Public Data

This includes information that is published to a website and is available to the general public. Examples are general product or company information. The main security drivers here are probably corporate governance rules and general good web security practices (OWASP Top 10). Confidentiality is not really an issue as you want people to see it. However, the integrity is important. Malicious users should not change it.

Public data is usually either purely static or database driven.  For static html the main risk to be addressed is OWASP Top 10 - Security Misconfiguration (A6).  For a database driven website, the main risks are the standard injection and  validation issues OWASP Top 10 A1, A2 etc.. 

Personal Data

If your website processes names and addresses, then your application will need to comply with local Personal Data legislation. This is probably the most common type of classification. EU countries have implemented the European Data Directive (Directive 95/46/EC) into national legislation. The  Information Commissioner's Office is responsible in the UK. In Ireland it is managed by the Data Protection Commissioner).  Other EU countries will have corresponding bodies.

In the US state of Massachusetts the relevant law is  "201 CMR 17.00: STANDARDS FOR THE PROTECTION OF PERSONAL INFORMATION OF RESIDENTS OF THE COMMONWEALTH" which is in force since March 2010.

You should become familiar with the relevant data protection legislation in your jurisdiction.

Payment Cards

If you "store, process or transmit" payment card information your application will need to comply with the Payment Card Industry - Data Security Standard (PCSI DSS ). Requirement 6 is the main one for web application security, although many of the requirements apply.

Money

This is a broad category covering such applications as online banking etc. There are many security drivers here such as Federal Deposit Insurance Corporation  (e.g. on multiple factor authentication), the European Payments Council etc.

Intellectual Property

For intellectual property, the main security driver will be corporate governance rules and internal organisation standards.

Summary

Those are just some data classifications which you can use in determining what are the security requirements that your application needs to meet.  There are many more depending on the sector that you are in.

Your company or organisation may have internal standards or policies that your application will need to comply with.  In fact, this is the first item you should research. This applies especially to larger or multinational organisations.

To summarise, if you are starting out on a new web development project, one of the first things you should do is to classify the type of data that your application will be processing. The classification will help you identify the security requirements that your application will need to meet.

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

Is the mobile phone becoming the universal authentication device?

Update 13/10/2010 : It now looks like Facebook is going down the same route with   One Time Passwords It looks like the question I posed in my original post (below) has been answered!

Is the mobile phone becoming the universal authentication device?  Are the days of website authentication using passwords only, coming to an end?

In the last number of months Microsoft has introduced "single-use codes" for its Windows Live Sign-In.


More recently Google announced that is introducing two-step verification initially to its Google App Premier accounts and says that "in the coming months, Standard Edition and hundreds of millions of individual Google users will be able to enjoy this feature as well."

Both of the above companies are main-stream consumer websites with hundreds of millions of users. Even though they are taking different approaches, the mobile phone is the common factor. They are perhaps acknowledging that password based authentication is no longer sufficient.

By doing this, the companies are raising the "security bar". Is it possible that a corresponding "shift" will take place over the next few years in the thinking of general consumers? Users may expect to use their mobile phones for authentication and decide that password-only based websites are not secure enough.

More importantly, the authorities may come to a similar conclusion. When the Data Protection Act states that "appropriate security measures" must be taken, will that come to mean that passwords by themselves are no longer "appropriate"? 

On the consumer banking front, Credit Suisse is rolling out an SMS based system in place of its RSA SecureId device.

Will Facebook etc. go down the mobile phone route for authentication? Update13/10/2010. Facebook has

If you are developing web applications, you should keep an eye on this space. Otherwise you may be left behind.

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

OWASP ASVS "Level 0 - No Verification"

According to OWASP, the Application Security Verification Standard (ASVS)
   "can be used to establish a level of confidence in the security of Web applications."

ASVS is a great idea, eventhough my efforts to introduce it have been 100% unsuccessful. Any takers?

The standard defines four verification levels ranging from 1 to 4. Broadly speaking you can verify the security of your applications based on a specific level. For the least critical applications you might verify to level 1 - which is basically an automated scan. If it passes the scan, then the application is secure enough.

For the most critical applications you could verify to level 4. This includes manual testing, code reviews of all code (including external libraries).

Level 0 - No Verification
I think that there is an implied 5th level which is "Level 0 - No Verification". Basically we have no level of confidence in the security. Most current applications probably fall into this level. The applications have not been subject to any security verification. This does not mean that they are not secure. But since they have not been verified, we can have no confidence in the security so they fall into our imaginary ASVS Level 0.

This begs the question, should ASVS formally include "Level 0 - No Verification"? Probably not. No point really! Developers could claim that their applications have been verified to Level 0 - which defeats the purpose.

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

UK Information Commissioner (ICO) Enforcements and Website Hacks

Summary

I did a brief analysis of the enforcement notices that have been handed out by the UK Information Commissioner (ICO) to organisations found to be in breach of the Data Protection Act. The idea was to see how many incidents were a result of a website hack (SQL Injection, XSS etc.)  About 100 enforcements are listed on the  ICO website covering the period from January 2008 to August 2010.

I found that none of the breaches were the result of a website hack. No SQL injection, XSS, CSRF attacks etc. The vast majority were related to unencrypted USB sticks, CDs, laptops etc. which have been lost or stolen.

Details

The Information Commissioner's Office (ICO) is responsible for the enforcement of the Data Protection acts (as well as other legislation) in the UK.

The ICO Enforcements page contains a list of enforcement notices that they have undertaken against organisations found to have been in breach of Data Protection legislation. The notices generally contain a short description of the breach as well as the remedial action which the implicated organisation undertakes to implement.

What is of interest from a web application security perspective is an analysis of the security incidents to see how many were caused by a website vulnerability - basically whether a website had been hacked.

I did a brief (not-very-scientific) analysis of the enforcements which have been published on the ICO website and focussed on the description of the breach.There were slightly fewer than 100 enforcements between 16 January 2008 and 26 August 2010. 

I categorised the incidents as follows:

Unencrypted Media is where an incident occurred following the loss or theft of a device which contained personal information and was not encrypted. This could be a laptop, CD, USB memory stick, old hard drive etc. It also includes a number of cased where users sent out unencrypted emails to the wrong recipient. For example the Royal Wolverhampton Hospitals NHS Trust enforcement has the following description :

The report concerned an unencrypted CD, with no password protection, which contained scans of patient charts from the Intensive Care Unit of the data controller's Heart and Lung Unit, and was allegedly found at a bus stop near the data controller's premises and passed to the newspaper anonymously."

Loss of Paper Records covers incidents where paper records were involved. This could be where patient records were found in a waste skip etc.. An example is the NCL (Bahamas) Ltd  which suffered a theft where:

the printout contained names, addresses, dates of birth, National Insurance numbers, salary details and full bank account details for around 80 employees."

Website Hack includes situations where a website was hacked. We would expect to see OWASP Top 10 type vulnerabilities being exploited which resulted in a breach of personal data.

Others is a catch-all for other types of incidents described in the enforcements. This could be where the organisation processes personal data in an unfair manner. For example they collect too much data.

Results

Here are the results of the analysis of the approximately 100 enforcements:

Category	Approximate Number Incidents
Unencrypted Media	70
Loss of Paper Records	20
Others	4
Website Hacks	0

A number of points to note. None of the incidents resulted from a website hack. No SQL Injection. No XSS. No CSRF. The vast majority resulted from the loss of an unencrypted device - or similar.

Can we conclude that OWASP (in the UK at least) can pull down the shutters - a job well done?  Probably not. 

But if I were an information security manager trying to prioritise the following projects:

• Do something about web application security
• Do something about USB/laptop encryption

Guess which one would go in second place.

Notes:

The numbers are approximate because in some cases the incident will have two causes. In other cases, a single enforcement notice covers multiple incidents.

There is not yet a requirement to notify the authorities of a data breach. So the figures probably do not tell the whole story.

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

A CEO with a Problem

Dear CEO,

Last night you went to bed content in the knowledge that your company was in good shape and that you were making big bucks. But, things have a habit of moving quickly. It's now 5 AM. You somehow find yourself booked to go on the major TV networks between 7 and 8 AM. You have to explain how somebody broke into your corporate database and stole the details of around one million customers. The hackers used something called SQL (pronounced 'sequel' by the way) injection. This story broke while you were in dreamland.

What do you do? All around, people are losing their heads, but not you. That is why you are CEO and the others aren't. You are determined to grasp victory from the jaws of defeat. You see an opportunity. Whether you like it or not, you're going to get airtime across these networks. You have, as ex-British prime minister Margaret Thatcher once put it, the oxygen of free publicity. Make the most of it. There are only two hours to prepare. Don't forget that tomorrow this will be yesterday's news, and the opportunity will be history. 

First step is to get the lawyers on the phone. Make sure that you don't incriminate yourself or the company. Always run the plans by the legal people. Next, contact your IT department. Don't forget these are the idiots who caused the problem in the first place - and don't let them forget it either. They should ensure that there is enough capacity in place to handle the extra visitors who will go to your website as a result of this incident. Get your marketing department to come up with great deals and to publish them on the website as soon as possible. When curious people visit the website during the day, hopefully the offers they see there will encourage them to stay as new customers. A cynical move maybe, but all is fair in love and…...

Plan what you want to say during the interviews. Here are some ideas:

• Be contrite but confident.
• Apologise to your customers for any inconvenience.
• Reassure them that the company will do everything possible to protect against any loss.
• Announce that you will facilitate access to credit monitoring programs.
• Emphasise the exceptional nature of this event by making the following kinds of statements: 'first indications are, this was an extremely sophisticated attack'
• Stress that the company already has robust information security practices in place, but you will be revisiting them.
• Say that you already have got external experts in to investigate the incident and that you will look to implement whatever recommendations these experts make.
• State that you will vigorously pursue the perpetrator responsible for this incident.

And now comes the opportunity: As this is a breaking story, emphasise that you will be posting updates to the website on a regular basis. Customers should visit to get the latest information. Make sure to mention the company's URL as many times as possible. This is the chance to advertise your wares both to existing customers and to potential new customers. Obviously, you can't say this explicitly in the interviews. But the visitors who came to watch the car-crash will hopefully remain as customers - enticed by the promotions that your marketing department create this morning. You have two hours to set all this in motion. Remember to get approval for the plans from the lawyers. Finally, use the last half-hour to run through some mock interviews.

Best of luck!

SIX MONTHS LATER:

OK, so things didn't work out. You are now the ex-CEO. But it did come with a useful golden handshake. You can now concentrate on the golfing handicap. 

OR:

Things worked out really well. After a brief hiccup, you increased your sales, and as a result of all the free publicity you received, you now have 10% more customers. Granted, you had to put aside some costs in the current accounting period, but they are manageable.  Ironically, you are now recognized as a world expert on crisis management!

The final item is to contact me, so I can tell you where to send the check!

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

OWASP Related Links for Developers

These are a few useful links for developers relating to popular development environments. 

OWASP Top 10 for .NET developers
  http://www.troyhunt.com/2010/05/owasp-top-10-for-net-developers-part-1.html

The OWASP Top Ten and ESAPI (J2EE)
  http://www.jtmelton.com/2009/01/03/the-owasp-top-ten-and-esapi/

Using the OWASP PHP ESAPI
  http://jackwillk.blogspot.com/2010/06/using-owasp-php-esapi-part-1.html

Python Security
  http://www.pythonsecurity.org/

Don't forget all the resources on the OWASP website.

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

Audit Trail Basics

Updated: May 4th 2012 to add reference to OWASP Logging Cheat Sheet

Updated: August 26th 2010 to add reference to The European Payment Council document

Anybody who has looked at the Payment Card Industry Data Security Standard (PCI)  will know that audit activities are an important requirement. An audit trail will maintain a record of significant events, such as logon, logoff, password changes etc. From an information security perspective an audit trail is an important control as it can be used to help monitor what is happening - and to notice if anything unusual is taking place. In addition it should be able to help recreate what happened in the event of an investigation. Most web applications do not have a proper audit trail. There might be various log files. But it can be difficult to use these in helping to recreate what happened.

However, if the audit requirements are considered at the start of a project, it is easy to build in the appropriate infrastructure to support it. At its most basic, it is a simple API that can be called from anywhere within the application. The Audit API should include the userID, type of event (e.g. logon, logoff), success or failure, timestamp, description.  Then call the API whenever a significant event occurs - such as logon, logoff. The audit API can then write the event to a permanent store. This could be a database table, a Syslog Server or similar. With the basic infrastucture in place, there are a number of other considerations. A mechanism is needed to view the audit trail. Another question is how long the audit trail should be retained for.

Requirement 10 of PCI goes into much more detail as to what is expected if you are processing payment cards. For example, the audit trail should be tamper-proof. This becomes important when the audit trail is used during formal investigations.

Basic Steps
Here are the basic steps you should think about at the start of the application.

1. Define an audit API called something like WriteAuditEvent. The API should take at least the following parameters; userID, eventType (logon, logoff etc.),success or failure flag, description. Make sure that the audit trail does not contain sensitive information - especially passwords.
2. Define the initial list of audit event types. These should include all significant user lifecycle actions, such as logon, logoff, change password etc. More events will depend on the functionality of your application.
3. Call the WriteAuditEvent from the application when the events occur.
4. WriteAuditEvent should write the details (including timestamp) to an audit store. This could be a database table, file, Windows event log, Syslog Server etc. Ideally this store should be tamper proof.
5. Develop a mechanism for querying the audit trail. This should be fairly flexible to allow you to focus on certain events or users.
6. Decide how long the audit log should be retained for.

There's a lot more that could be written about audit trails. However those are some basic steps. It is easy to build in simple audit trail functionality if you think about it at the start of your development.

Some Links:

• You can download the PCI Standard from here here (PDF) 
• How to Do Application Logging Right talks about some technical aspects.
• Have a look at the OWASP API and AppSensor 
• In June 2010, the European Payment Council published THE USE OF AUDIT TRAILS IN SECURITY SYSTEMS: GUIDELINES FOR EUROPEAN BANKS
• OWASP Logging Cheat Sheet 

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

Forgotten Password Mechanisms....again

In  a previous  blog entry I gave my 2 cents worth on what to think about when handling the "Forgotten Password" mechanism in online applications.

I just came across Password Reset Survey  which does a short review of how the password reset is handled on a number of major sites*. It's worth reading, but here is the conclusion:

"There isn't a clear conclusion to draw here - sites do things differently, and in some cases have what seem to be pretty easily breakable password reset mechanisms. I'd imagine that all of these mechanisms work well enough - the cost of breakins is less than the cost of making things more secure and difficult for users. But I'd encourage people to think of ways that the password reset process could be made more secure and usable so that sites could rally around a better mechanism."

I have also mentioned the following academic paper before:

•  The password thicket: technical and market failures in human authentication on the web

When developing your online application, you need to think about how you are going to handle the forgotten password mechanism.

*The sites reviewed are:
Google, Yahoo, Microsoft (Hotmail, Live etc), Apple, Facebook, Twitter, MySpace, LinkedIn, Amazon, Ebay, Craigslist, Paypal, Wikipedia

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

User Lifecycle - Part II

Introduction
The first article in this two part series looked at user identification, and registration. The second part, considers other important phases of the user lifecycle:

• Logon
• Forgotten password
• Change password
• Logout
• Account deletion

User Lifecycle - Logon
At this stage the user has registered. As part of the registration phase, the user will have entered their email address and chosen a password. This article assumes that the application uses the email address as their username.

1. To logon, the user enters their email address and password on a logon screen. These credentials are sent via SSL/TLS to the application for verification.
   
2. The username and password are verified. The first step is to verify that the email exists. If the email address does not exist, then an error is returned to the user. However, the error message should be generic, saying that the incorrect credentials were entered. It should not say which credential (email address or password) was incorrect. This is to prevent harvesting of valid email addresses.
3. If the email address exists, then the next step is for the application to verify the password. To verify the password, the application should take the entered password and hash it, using the same salting and hashing values that were used at registration. If the hashed value of the entered password and the stored hashed password match, then the application can log the user in successfully.
4. The browser can display the timestamp of the previous successful logon.
   

Some notes to the logon:
To help prevent brute-force automated attacks, only allow a login attempt every few seconds. The normal user will not notice the delay, however it will significantly slow down the rate at which an automated script can attempt to logon.

After a few unsuccessful logon attempts (e.g. five), consider disabling the account for a few minutes (e.g. five) before the user can attempt to logon again. Again the purpose of this is to prevent brute-force attacks.

User Lifecycle - Forgotten Password
The forgotten password mechanism is a tricky part of the user lifecycle. Many websites just email out the password in cleartext. This is a very poor practice, as the password could be intercepted in transit. It will also remain in the user's inbox, where it could be read by a casual user. In addition, many users will reuse the same password across multiple websites. So a casual user who sees the password gets access to several applications.

In an ideal world, the user contacts a customer support assistant (CSA). After the user successfully confirms their identity to the CSA, the CSA will reset the password for the user.

However, this is often not a financially acceptable option. It is expensive to operate. The alternative is usually based on secret questions and an email link. Care needs to be taken in implementing this solution. It is certainly not suitable for all applications and needs to be thought through.

The following steps outlines a general approach and leaves several issues unresolved. The mechanism you ultimately implement will depend on the application, the type of data that is being processed and the relationship with the user.

During the registration phase, the user created a number of secret questions and answers. These are now used for the forgotten password mechanism.

1. If the user has forgotten the password, the user clicks on the forgotten password link which brings the user to the forgotten password page.
   
2. On this page, the user is asked to enter the email address. If the email address exists, the application sends a unique forgotten password email link to the user at that email address. Whether the email address exists or not, the user should be told that an email has been sent. This is to prevent harvesting of valid email addresses. The password link should be time-limited.
3. When the user clicks on the link in the email, they are brought back to the secret question page.
   
4. The user is presented with a number of the secret questions (e.g three) which were answered during the registration phase. The user must answer the three questions using the same answers that were entered during the registration phase.
   
5. If the user answers the questions correctly, they are brought to the password entry page. As during the original registration phase, the user must enter a password and confirm password page. The password must conform to the chosen password complexity rules.
   
6. Once the new password has been set, the forgotten password link should be deactivated. If the user goes through the password mechanism, then sensitive information (e.g. payment card numbers etc.) should be deleted.
7. Once the password has been changed, a notification email should be sent to the user.
   

The issue remains, what happens if the user cannot remember the answers to the secret questions. This effectively locks the user out of the application - which is usually not what the website operator wants. It comes down to a tradeoff between usability and security. At this stage it might be possible to consider other options. For example the user can send in a letter via normal mail requesting that their password be reset. Ultimately, it is important that the forgotten password mechanism be at least as difficult as the normal logon. It cannot be stressed enough that this element of the user lifecycle needs to be carefully worked out.

User Lifecycle -Change Password
The application should also have an option to for a user to change the password. Usually this facility is available when the user has logged on. The password update screen should require the user to enter their old password, the new password and the confirm password (which is the same as the new password). The new password should comply with the chosen complexity rules.

After the password has been updated, it would be worthwhile sending a notification email to the user.

User Lifecycle - Logout
The application needs have a logout option. A logout button should appear on every page of an authenticated session.

User Lifecycle -Account Deletion
At some stage the user may wish to end their relationship with the website. How this happens may depend on the type of data that is being processed. Personal data legislation usually states that data be held only as long as is necessary. This would imply that if the user wants to delete their account, all data associated with that account should be deleted as well.

However other types of applications (especially financial) may require that transaction records be held for a number of years.

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

User Lifecycle - Part I

Introduction
Originally published July 20th 2010
Updated July 28th 2010
Updated June 2012 - Slow Password Hashing
Management of the user lifecycle in online web applications is generally fairly poor. For example, the forgotten password mechanism is often a weak link. Web applications regularly email out the password in cleartext. This is not good. The password then remains in the user's inbox. Anybody who gets access to the email will be able to see the password.

The lifecycle covers all phases of the user's interaction with the website, starting with the registration/enrolment phase, through logon, logoff, and account deletion.

The password thicket: technical and market failures in human authentication on the web is an academic paper that "report the results of the first large-scale empirical analysis of password implementations deployed on the Internet". It is well worth reading and gives excellent information about logon and password practices.


This series of articles discusses some good practices in relation to the user lifecycle. It covers the important phases. It is aimed at web applications that rely on passwords as the authentication mechanism, as well as secret questions to handle the forgotten password mechanism.

Disclaimer

Your mileage may vary. Passwords are not suitable for all web applications. Depending on the type of data that your application processes, you may need to use two factor authentication or some other approach. This would apply, for example, in the banking sector.

You need to decide if a password based authentication approach and the use of secret questions as the forgotten password mechanism are secure enough for your development.

User Lifecycle- Identification

Some applications may require formal identification of potential users. This could be for anti-money laundering or other legislative purposes. The would-be users may need to provide proof of identity (e.g. passport) and proof of address (e.g. utility bills). They might have to go to a physical location in order to do this.

This scenario is probably beyond the scope of this document. However, it does mean that it might be possible to distribute logon credentials (e.g. passwords or activation codes) during the physical encounter.

User Lifecycle- Registration

If users decide to create an account with your website, these are some steps to consider:

1. On the registration screen, the user enters an email address.
2. The application checks to see if the email address is already being used. This step could be abused by an attacker to harvest a list of valid email addresses. Captcha technology could be used to prevent this. However this can put potential users off.
3. If the email address is available, the application then sends an email containing a unique activation link, to the email address. The main reason for this is to ensure that the user controls this email address.
4. The user clicks on the email activation link and is brought back to the website to complete registration.
5. The user enters the password and confirmation password on the password entry screen.
6. The application then checks that the chosen password meets the appropriate complexity requirements (e.g minimum length, mixture of letters and numbers etc.) and stores the password.
   
   The next step is to prepare for the forgotten password mechanism (otherwise known as the second logon mechanism). The most popular approach is to use some sort of secret questions.
   
7. The application should present the user with a list of secret questions (e.g. 20). The user must provide answers to a number of these (e.g. six). The good security questions website discusses security questions in more detail and also provides potential lists of questions.
8. When the user has entered the security answers, the user should be forcibly logged out. A notification email should be sent to the user confirming that the account has been created.
9. The user should then have to login again before continuing to use the website.

Some Notes:

• The email activation link should be time limited to something like 24 hours. If the user does not click on the link within this period, the account should be deactivated.
• Once the user has clicked on the activation link, the link should be deactivated.
• The HTML autocomplete field should be disabled on all sensitive fields.
• An attacker could (ab)use steps 1 and 2 to harvest email addresses of accounts which already exist. Consider using Captcha technology to prevent this.
• Use SSL/TLS to protect all communication related to the user lifecycle. In fact, just use SSL/TLS everyplace.
• Sensepost has a password strength checker with more information.
• Password should be stored using salt and hash techniques. Consideration should be given to using slow password hashing algorithms such as bcrypt. Older algorithms such as MSD5 should not be used . The password must not be stored in cleartext. In fact the password should never be visible in cleartext.

Future Article:
In a future article I will cover further phases in the lifecycle:

• Logon
• Forgotten password
• Update password
• Logoff
• Account deletion

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

Session Management - Some Good Practices

Updated: April 9th 2012. Mainly addition of new HTTP headers to reflect developments over the last year or so.
 
"Broken Authentication and Session Management" is in at number 3 in the OWASP Top 10 - 2010 (up from number 7 in OWASP Top 10 - 2007). So here are a few good practices for managing sessions:

• Mark session cookies as secure
• Set the HTTPOnly flag on session cookies
• Generate a new session cookie on successful logon
• Have a Logout button on all pages where the session is authenticated. This should terminate the session.
• Set the AUTOCOMPLETE to off on sensitive HTML fields/forms such as credit card numbers:
  <INPUT NAME="name" AUTOCOMPLETE=OFF>
• Use the http meta refresh for browser timeouts. This will redirect to a timeout page after a period of inactivity:
  <meta http-equiv="refresh" content="300;url=timeoutpage " />
• Set caching parameters to prevent sensitive data from being left on browser
  
  1. Pragma: no-cache
  2. Cache-Control: no-cache
  3. Expires: -1

These are some other useful HTTP headers, which may or may not be supported by your user's browsers. Many of these are easy security wins. Set them once and forget about them and they should not have any negative impact. You need to find out how to implement them in your environment.

• Strict Transport Security - STS. This forces the browser to use SSL/TLS when connecting.
• X-Frame-Options: DENY or SAMEORIGIN. These control the handling of frames.
• X-XSS-Protection is a Microsoft Internet Explorer option aimed at helping to prevent XSS attacks in IE
• X-Content-Type-Options: nosniff  This tells the browser not to try and guess the content type of responses. However, your application should always set the proper content type in its responses.
• Content Security Policy - CSP.  This is aimed at preventing XSS. Essentially it tells browsers where content can be loaded from.  This is a very useful addition, but does require some effort to understand and implement correctly.

For details on how to implement them in your environment, use your favourite search engine.

Useful Links

• Wikipedia: Strict Transport Security - STS 
• Mozilla X-Frame-Options 
• Microsoft IE Internals X-XSS-Protection
• Microsoft X-Content-Type-Options
• W3 Content Security Policy Specification
• OWASP Session Management Cheat Sheet

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

Tuesday Top Tip - Autocomplete

The following screenshot is from a Credit Card payment page which I regularly use.


I use Firefox mostly. When I double-click on the CVV2 field, the value that I used the previous time appears. The same applies to all the other Credit Card fields (number, name, address, etc). While this is great from a usability perspective, it's bad from a security point-of-view. A casual user in an Internet cafe scenario could easily get a list of valid credit cards by just double clicking on these fields. The Expiration Date is the only field which is not prefilled.

To prevent this from happening on your website, make sure to set the AUTOCOMPLETE field to OFF. You can do this at the HTML field or form level:

• <INPUT NAME="name" AUTOCOMPLETE=OFF >

That's Tuesday's Top Tip #1

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

OWASP Talk Dublin June 30th 2010

Here is the link to the talk that I gave at the OWASP Dublin meeting held on June 30th 2010. The title was:

"Define Security Requirements - A practical approach "

The link is about half-way down (JUN 2010) on the OWASP Ireland page.

The actual slides from the presentation are here.

In the talk I outline some steps that you should take at the beginning of a web development project to help you define security requirements. There are also some suggestions for good practice in relation to session management.

Finally, I have some slides about the User Life Cycle good practices, which I never got to during the talk. This section suggests good practices around the various stages:

• Identification
• Registration/Enrolment
• Logon/Logoff
• Forgotten Password Mechanism
• Logoff/Account Deletion

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