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

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

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:
  1. Accidental Discovery
  2. Automated Malware
  3. The Curious Attacker
  4. Script Kiddies
  5. The Motivated Attacker
  6. Organized Crime
  7. -
  8. Denial of Service Attacks
  9. 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.

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

Some Links:

 

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:
 

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:
 

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:

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

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

    Posted by alexisfitzg at 19:09
    Labels: ,

    No comments:

    Post a Comment

    Subscribe to: Post Comments (Atom)