Updated January 21st, January 2011.
The complete version is now at:
Updated January 13th, 16th 2011: Added Compliance Section + various other links
IntroductionThis 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- EducationThis 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.
General familiarisation with OWASP Top 10 and secure coding techniques.
- OWASP Top 10
- 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 RequirementsThis 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 DataThe 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.
|General Security Good Practices
|Data Protection Legislation
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.
Classify the data that your application will process and the corresponding security drivers.
- Data Classification and Security (Article on this blog)
- Payment Card Industry Data Security Standard (PCI DSS)
- European Data Protection Directive
2.2 Threat AnalysisPerform 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
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.
Do a simple Threat Analysis to decide on the main threats that the application may face.
2.3 Data Flow DiagramsDraw 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.
Develop Data Flow Diagrams and specify the security controls that are needed
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:
- Forgotten password
- Update password
- Account lockout/disable
- Account deletion
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.
Define the various user roles and the corresponding life cycle activities
2.5 AuthorisationDecide 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.
Define how the application will implement authorisation rules
2.6 Segregation of DutiesAre 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.
Find out if there are any areas in the application which requires segregation of duties
2.7 Audit TrailAn 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
Decide how the audit trail is to be implemented and what events are to be recorded.
2.8 Application LoggingRelated 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.
Decide how the application logging is to be implemented.
2.9 Data RetentionThe 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.
Find out how long data is to be retained for.
2.10 AvailabilityThe 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.
Decide how availability is to be ensured.
2.11 AssuranceDecide 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.
Decide on the level of assurance that you require in the application.
2.12 Other Compliance IssuesThere 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.
Are there other compliance issues to be resolved? (Terms and Conditions, 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
End of Part IAt 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.