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:

1. Develop securely for the technology
2. 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:

• OWASP Top 10
• OWASP Cheat Sheets 
• OWASP Secure Coding Practices Quick Reference Guide
• Microsoft Security Development Lifecycle
• OWASP Top 10 for .NET developers
• The OWASP Top Ten and ESAPI (J2EE) 
• Using the OWASP PHP ESAPI 
• Python Security 

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:

• Data Classification and Security (Article on this blog) 
• Payment Card Industry Data Security Standard (PCI DSS) 
• European Data Protection Directive

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/Hacktivist
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 and corresponding security controls.

Some Links:

• Threats - some thoughts (Another article on this blog)
• OWASP Threat Risk Modeling 

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:

• OWASP ASVS 
• OWASP Code Review Project 
• OWASP Testing Project

 

 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, EU Cookie Directive, Privacy Notices etc.)

 
Some Links (Mostly UK Related):

• Privacy Notices
• Terms and conditions: checklist for selling on-line 
• Principal Regulatory influences on UK web applications 

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