Showing posts with label WebApplicationSecurity. Show all posts

Sunday, 16 January 2011

Web Application SDLC Quick Reference

Update February 1st 2015. I have created an "Application and Security Governance Task List" Excel Online spreadsheet at bitly.com/15AyZdi This covers the same type of information as below. You can view the spreadsheet using a regular browser at the above link, or download it and use it in Excel

Version 1.1 Updated 6th May 2012. Mainly Phase 1 Education and Preparation

Introduction

This is a a quick reference checklist of security related items you should consider addressing during the development lifecycle of your web or online project. By investing some resources in security at the start of the project, you should be able to reap the rewards and end up with a much more secure product.

Comments are appreciated!

The goal of an information security program is not to build perfect security, but to make sure that you have an appropriate level of security. This is a vague definition but the answer will depend on a number of factors such as:

Data classification or asset value
Legislation (Data Protection Act)
Industry Standards (Payment Card Industry Data Security Standard - PCI DSS)
Corporate security policies and general risk appetite

This checklist is aimed at development teams who may not have any formal security approach in place - but do wish to incorporate appropriate security measures into their online development projects. It assumes a waterfall type approach to the development lifecycle. Defining the major security requirements that a project needs to meet happens during the analysis phase.

While the phases are described separately as in a "typical" waterfall type approach, the reality is that there will probably be a lot of overlap between the various phases. The Security Requirements, Design, implementation and subsequent phases will be happening in parallel. The aim of this reference is to highlight the major security related tasks which should be undertaken during each of the phases.

This quick reference does not discuss secure architecture or issues such as change management etc.

1- Education and Preparation

The first phase is a preparation and education phase in advance of the project. Hopefully the results from this phase can simply be reused across a lot of projects especially if you use the same technologies widely.

The first task is to provide the development team with security awareness and development training. This should cover issues such as the OWASP Top 10 list of vulnerabilities.

Then, identify and list the various components, libraries, technologies that the project will use. These could include Java/J2EE, Spring, Javascript, Struts, ASP.NET, Flash, JSON, Web Services Smartphones etc. The list is endless. Learn how to use these technologies securely. There are two main aspects here:

Develop securely for the technology
Deploy the technology securely

For these technologies, develop secure development and deployment guidelines that can be used by the development teams. The OWASP Top 10 of web application security risks is a good resource. The Top 10 are the most common vulnerabilities seen in online web applications. This stage will involve some research and work in developing the documentation.

Depending on the development framework or environment that you use, there are a number of resources which will help you in protecting against the OWASP Top 10 vulnerabilities.

Main Tasks:

Provide development team with security awareness and development training
Identify and list all the various technologies the project will use.
For these technologies, develop security documentation that can be used for development and deployment

Some Links:

2 - Security Requirements

This is perhaps the most important phase from a security perspective. This should be undertaken during the analysis phase of the project.

The main task here is to work out the security requirements that your project will need to meet.

2.1 Classify Data

The first thing to do is to classify the type of data that your application will process. The classification will be a major driver in specifying the security requirements. Based on the classification you can find out what security requirements you will need to comply with.

The following table shows a number of common classifications as well as their security drivers.

Classification	Security Driver
Public Data	General Security Good Practices
Personal Data	Data Protection Legislation
Payment Cards	PCI DSS
Money	Industry Standards
Intellectual Property	Corporate Governance

So for example if your application will process Personal Data then you will need to comply with Data Protection legislation.In Europe you will need to be familiar with the local implementation of the EU Data Protection Directive.

If your application processes Payment Cards, PCI DSS is the applicable standard.

You might have internal corporate policies or standards which give guidance.
The classification will influence a lot of the answers in subsequent sections of this checklist.

Main Task:

Classify the data that your application will process and the corresponding security drivers.

Some Links:

2.2 Threat Analysis

Perform a threat analysis. This is influenced by the data classification. The following is a (non-complete) list of possible threats:

Accidental Discovery
Automated Malware
The Curious Attacker
Script Kiddies
The Motivated Attacker/Hacktivist
Organized Crime
-
Denial of Service Attacks
Environmental/Infrastructure

The first six threats come from OWASP.

General "Good Security Practices" should protect against the first four threats.

Threats 5 and 6 are the difficult ones as they will require special consideration. For example it is difficult to protect against a DBA taking a copy of the customer database.

An online bank would be worried about Organized Crime. A political organisation may need to take measures against Denial of Service Attacks.

Decide on the threats that your application may face and the security controls you should put in place.

Main Task:

Do a simple Threat Analysis to decide on the main threats that the application may face and corresponding security controls.

Some Links:

2.3 Data Flow Diagrams

Draw data flow diagrams to indicate where data flows, where it is stored and where are the trust boundaries. Based on these decide on what security measures need to be taken. Again the controls here will be influenced by the data classification and corresponding security drivers.

For example, Payment Card related data needs to be protected when stored and encrypted when it travels across public networks. Personal data should be encrypted when travelling across public networks.

Be careful about where data goes to third parties. You could be responsible and so would need to ensure that these third parties have appropriate security measures in place. This applies for example for Payment Card and Personal Data classifications.

Also note the "incidental" data flows. For example where production data is used as test data, or production data is downloaded to local PCs for further analysis. This can lead to unintentional data loss.

Where data crosses "Trust Boundaries" you will need to think about authorisation, data validation etc.

Based on the results of the Data Flow analysis, you can specify security controls such as where data needs to be encrypted, authenticated, validated etc.

Main Task:

Develop Data Flow Diagrams and specify the security controls that are needed for each data store and data flow.

Some Links:

Data Flow Diagrams and Security (Another article on this blog)

2.4 User LifeCycle/Authentication etc.

Specify the user roles that the application will have. Generally, there will be a number of different roles:

Unauthenticated users
Authenticated users
Website administrators
Operational roles (DBAs etc.)

For each role define how to implement the user lifecycle covering the following phases:

Identification
Registration
Logon
Forgotten password
Update password
Logoff
Account lockout/disable
Account deletion

The data classification plays a role here. So for example financial type transactions may require two-factor authentication, while simple password based logons might be adequate for most situations.

The threat analysis carried out earlier will also have an input here. If the insider attack is a particular worry, then special measures may need to be taken with administrators or other operational type roles.

Main Task:

Define the various user roles and the corresponding life cycle activity security controls

Some Links:

User Lifecycle Part-i and II (Another article on this blog)

2.5 Authorisation

Decide how users are only going to get access to those resources that they are entitled to. There are two main levels. At a coarse level, a normal user should not be able to get access to the list of users. Only the administrator should be able to see the list of users. This can usually be implemented at a higher level. Normal users will simply be refused access to the view users page.

On a finer level, a normal user should only be able to get access to his own account, but should not be able to see an account belonging to another user. This is implemented at a finer level. Each user can access the accounts detail page - but logic within that page will need to decide whether that user can access a particular account number.

Another aspect is business rules. How will business rules be implemented. For example how to enforce the rule that a user can only transfer a certain amount of money to another account.

Depending on the classification, authorisation controls may include the use of a two factor device or similar. This is often the case in online banking.

Main Task:

Define how the application will implement authorisation rules

2.6 Segregation of Duties

Are there any areas which require segregation of duties. For example, in a payment system, a user from one role might be needed to create a payment. While another user has to authorise the payment.

Main Task:

Find out if there are any areas in the application which requires segregation of duties

2.7 Audit Trail

An audit trail is an important aspect of an information security system and can be used in situations such as dispute resolution. It is used to record significant events such as logon, logoff, user creation etc. Other events will depend on the type of application that is being developed. The PCI DSS standard has fairly strict requirements when it comes to audit trail.

Be careful not to include sensitive data such as passwords in the audit trail

Main Task:

Decide how the audit trail is to be implemented and what events are to be recorded.

Some Links:

Audit Trail Basics (Another article on this blog)

2.8 Application Logging and Monitoring

Related to the audit trail is the concept of application logging. This is more concerned with the performance of your application. From a security perspective, the main goal is to monitor for attacks or other suspicious activity.

You can build monitoring events into the application. These will look for suspicious events and react accordingly. The OWASP AppSensor project is a good resource here.

Main Task:

Decide how the application logging and monitoring is to be implemented.

Some Links:

Application Security Logging
How to Do Application Logging Right (Added January 13th 2011)
OWASP Logging Cheat Sheet (Added May 2012)
OWASP AppSensor Project (Added May 2012)

2.9 Data Retention

The data processed by your application may need to be retained for a certain period of time. Again this may depend on the data classification. Records of a financial transaction may need to be kept for a number of years. The general principle is to store the data for as long as is necessary but no longer.
In considering data retention, you will also need to decide how long to keep the audit trail records.

Main Task:

Find out how long data is to be retained for.

2.10 Availability

The third pillar of Information Security is Availability. How to ensure that the application is available in a timely manner. Depending on the level of availability that you require, you will need to put the appropriate resources in place. If 24/7 operation is required, then this will mean comprehensive resilience measures. However if it does not really matter if your application is offline for a few hours or a day, then you may decide that it is sufficient to rely on a restore from backup.

Main Task:

Decide how availability is to be ensured.

2.11 Assurance

Decide on the level of assurance that you require in the application. Depending on the type of application, you might want more or less assurance. For example you may decide that it is sufficient that the application passes an automated scan. At a higher level of security you may require that the application is subjected to a code review as well as an automated scan plus manual penetration test. The OWASP ASVS project is an invaluable resource in this regard.

Main Task:

Decide on the level of assurance that you require in the application.

Some Links:

2.12 Other Compliance Issues

Are there other compliance issues to be resolved? (Terms and Conditions, EU Cookie Directive, Privacy Notices etc.)

Some Links (Mostly UK Related):

At the end of this Security Requirements phase, you should have a document describing the security requirements that your application will need to meet.

3.0 - Design

In the design phase you takes the security requirements from the analysis phase and include them in the design. For example, the security requirements may state that data needs to be encrypted when travelling across a network. In the design phase, you will specify how it is to be encrypted, eg. using SSL.

This applies to the rest of the security requirements.

Another task is to decide how to implement measures to protect against the OWASP Top 10 list of web application risks.

Main Task:

Include the security requirements in your design.

4.0 - Implementation

During this phase, implement the measures as decided on during the earlier analysis and design phases.

This is probably the biggest phase of the project. However from a high level security perspective, the main task is to implement the security measures that were decided on earlier.

There will be problems to solve, in which case the previous phases will need to be revisited. Security measures may need to be redesigned

Main Task:

Implement the security controls that were designed in the previous phase.

5.0 - Verification

Earlier on in the analysis phase, you will have decided how the security of the application is to be verified. This could be a mixture of automated scans, manual penetration testing and code reviews.

Hopefully the result of this phase is mainly to confirm that the specified security measures have been implemented as per design.

Main Task:

Verify the application's security as per the security requirements.

6.0 - Release

When releasing the application to production, there are a number of security-related tasks which should be undertaken. Here are a few of them:

Make sure to use up-to-date versions of system components, frameworks, libraries, etc.
Security harden application components. Use available hardening checklists or guidelines to secure any configuration files, components, frameworks, databases etc. that are used in the application.
Remove any unnecessary resources. These includes temporary files, tutorials, user accounts etc.
Remove test accounts and test data

Main Task:

Release the application to production in a secure manner.
The deployment should use the guidelines as developed earlier in Phase 1

7.0 - Post Release

The main security-related tasks after the application has been launched include the following:

Monitor the audit trail and any application logging for any signs of malicious or unexpected activity
If any security vulnerabilities are discovered, develop and apply any necessary fixes
Apply any security related patches which vendors release
Based on the list of technologies that you identified earlier in Phase 1, monitor for any newly discovered vulnerabilities. For any newly discovered vulnerabilities apply the appropriate fixes.

The Operations team will play an important role here.

Main Task:

Monitor the application from a security perspective.
Apply any relevant security related patches or fixes

Summary

This post give a brief overview of the important elements of the Web Application SDLC. It is meant to be a quick reference or checklist. It is not meant to be a heavyweight SDLC

Any comments and feedback are welcome!

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

Monday, 3 January 2011

Web Application SDLC Quick Reference - Part I

Updated January 21st, January 2011.

The complete version is now at:

Web Application SDLC Quick Reference

Updated January 13th, 16th 2011: Added Compliance Section + various other links

Introduction

This is a two part series to cover a quick reference checklist of security related items you should consider addressing during the development lifecycle of your web or online project.

Items covered in this first part relate mostly to the analysis phase of the project, although a number relate to later phases of the life cycle. The second article in this series will look at security related issues which need to be addressed in later parts of the security development life cycle.

Comments are appreciated!

The goal of an information security program is not to build perfect security, but to make sure that you have an appropriate level of security. This is a vague definition but the answer will depend on a number of factors such as:

Data classification or asset value
Legislation (Data Protection Act)
Industry Standards (Payment Card Industry Data Security Standard - PCI DSS)
Corporate security policies and general risk appetite

1- Education

This does not apply to any particular project, but is more of a prepatory phase.

Become familiar with the OWASP Top 10 of web application security risks. These are the most common vulnerabilities seen in online web applications.

Depending on the development framework or environment that you use, there are a number of resources which will help you in protecting against the OWASP Top 10 vulnerabilities.

The Microsoft Secure Development LifeCycle SDL is another good resource.

Main Task:
General familiarisation with OWASP Top 10 and secure coding techniques.

Some Links:

2 - Security Requirements

2.1 Classify Data

Classification	Security Driver
Public Data	General Security Good Practices
Personal Data	Data Protection Legislation
Payment Cards	PCI DSS
Money	Industry Standards
Intellectual Property	Corporate Governance

2.2 Threat Analysis

Perform a threat analysis. This is influenced by the data classification. The following is a (non-complete) list of possible threats:

Accidental Discovery
Automated Malware
The Curious Attacker
Script Kiddies
The Motivated Attacker
Organized Crime
-
Denial of Service Attacks
Environmental/Infrastructure

2.3 Data Flow Diagrams

Data Flow Diagrams and Security (Another article on this blog)

2.4 User LifeCycle/Authentication etc.

Specify the user roles that the application will have. Generally, there will be a number of different roles:

Unauthenticated users
Authenticated users
Website administrators
Operational roles (DBAs etc.)

For each role define how to implement the user lifecycle covering the following phases:

Identification
Registration
Logon
Forgotten password
Update password
Logoff
Account lockout/disable
Account deletion

The classification plays a role here. So for example financial type transactions may require two-factor authentication, while simple password based logons might be adequate for most situations.

The threat analysis carried out earlier will also have an input here. If the insider attack is a particular worry, then special measures may need to be taken with administrators or other operational type roles.

Main Task:
Define the various user roles and the corresponding life cycle activities

Some Links:

User Lifecycle Part-i and II (Another article on this blog)

2.5 Authorisation

Another aspect is business rules. How will business rules be implemented. For example how to enforce the rule that a user can only transfer a certain amount of money to another account.

Depending on the classification, authorisation controls may include the use of a two factor device or similar. This is often the case in online banking.

Main Task:
Define how the application will implement authorisation rules

2.6 Segregation of Duties

2.7 Audit Trail

Audit Trail Basics (Another article on this blog)

2.8 Application Logging

Related to the audit trail is the concep of application logging. This is more concerned with the performance of your application. From a security perspective, the main goal is to monitor for attacks or other suspicious activity.

Main Task:
Decide how the application logging is to be implemented.

Some Links:

Application Security Logging
How to Do Application Logging Right (Added January 13th 2011)

2.9 Data Retention

2.10 Availability

2.11 Assurance

2.12 Other Compliance Issues

There may be other compliance issues that you need to address. The main ones would include privacy notices, terms and conditions which you may need to include on the website. There may be others depending on the classification.

Main Task:
Are there other compliance issues to be resolved? (Terms and Conditions, Privacy Notices etc.)

Some Links (Mostly UK Related):

End of Part I

At the end of this Security Requirements phase, you should have a document describing the security requirements that your application will need to meet.

The next installment will look at security issues which need to be resolved during the later phases of the development lifecycle. Most of these simply revolve around implementing the security requirements that have been developed here.

Comments welcome. Please leave them in the comments section below.

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

Tuesday, 28 December 2010

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

Monday, 25 October 2010

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

Tuesday, 28 September 2010

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

Tuesday, 21 September 2010

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

Thursday, 16 September 2010

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

Sunday, 29 August 2010

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

Thursday, 19 August 2010

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

Friday, 13 August 2010

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

Sunday, 11 July 2010

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