Thursday 27 January 2011

Facebook and SSL

*               *               *               *

I see that FaceBook has decided to support SSL.


Maybe they read my Previous Post and got frightened - but maybe again they didn't.


*               *               *               *

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

Saturday 22 January 2011

European Data Protection Legislation and SSL

Summary
Many major websites do not use SSL to protect personal data as it travels across the internet. This was highlighted by the publication of the Firesheep Firefox extension in late 2010. This post looks at what European Data Protection Legislation has to say about the use of SSL to protect personal data. 

Very little as it turns out.  

It really only says that "appropriate measures" must be taken to protect the data. The UK and Ireland were examined a bit more detail. In these two countries, some of the accompanying notes to the legislation talk about encryption, but it is vague. The situation in other EU countries was not reviewed.

So, it seems to be unclear whether websites that transmit personal data across the internet in cleartext are in breach of European Data Protection Legislation. However, based on the experience with Google Streetview, the combined EU Data Protection bodies should be in a position to put pressure on these websites to configure and use SSL properly. 

Most information security professionals would think that SSL is a basic security measure.

Feedback is welcome - especially on the situation in other EU countries.

Background
The Firesheep Firefox extension shows how easy it is to hijack user sessions on websites that do not implement SSL properly. In summary, you can use Firesheep to steal personal data (names, addresses etc.) from many major websites that do not use SSL or only use it during authentication.

So what does European Data Protection legislation have to say about SSL? Are websites who do not use SSL to protect personal data in breach of Data Protection Legislation?

European Data Protection Legislation and American Websites
First of all a quick note about American companies. Most of the major websites are run by American companies. You might wonder whether they care about European Data Protection legislation or what the relationship is. The answer is the  Safe Harbor program administered by the US Department of Commerce.

Essentially it means that companies who sign up to the Safe Harbor program agree to comply with EU Data Protection rules. In general, the major websites do sign up. You can search the list at:
There is even a separate Swiss List at:
So eventhough the websites are run by American companies, European Data Protection legislation is relevant.

European Data Directive
The main security driver for the protection of personal data in the EU is
DIRECTIVE 95/46/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 24 October 1995

Article 17 Security of processing of the Directive states:

  • "the controller must implement appropriate technical and organizational measures to protect personal data against accidental or unlawful destruction or accidental loss and against unauthorized alteration, disclosure or access, in particular where the processing involves the transmission of data over a network, and against all other unlawful forms of processing"

It says that "appropriate technical" measures must be taken  "in particular where the processing involves the transmission of data over a network". That implies that something should be done to protect personal data as it is being transmitted across the internet - but it does not mention SSL or encryption.

Every EU country has implemented the European Data Directive into its own legislation. Each EU country has a local Data Protection body who is responsible for enforcing this legislation in that country. The following sections look at two countries in a bit more detail - the UK and Ireland.

UK
In the UK the Information Commissioner's Office is responsible. Does the commissioner have anything to say? The ICO  document "Data Protection Good Practice Note - Collecting personal information using websites contains a number of questions. Question 9 is relevant:

Question 9:
  • We collect personal information through our website. Do we have to use an encryption-based transmission system?
Answer:

  • "You are responsible for processing personal information securely. You must adopt appropriate technical and organisational measures to protect the information you collect. It is difficult to see how you could do this without having a secure, encryption-based transmission system if the personal information is sensitive or poses a risk to individuals, for example, if it includes credit card numbers.

    You should be aware that although a secure transmission system will protect the personal information in transit, there is a potentially greater threat to the security of the information when it is decrypted and held on a website operator's server. Any sensitive personal information, or information that would pose a risk to individuals, should not be held on a website server unless it is properly secured by encryption or similar techniques."

Unfortunately, this answer is also not clear-cut. While it does talk about "a secure, encryption-based transmission system", it is only with respect to personal information that is "sensitive". And "sensitive personal information" has a special meaning. See the section "Sensitive personal information" in About the Code.

Ireland
The Data Protection Commissioner is responsible for personal data in Ireland. The document A Guide to the New Data Protection Rules is a bit more specific:
  • "Transmission over external networks, such as the internet, should normally be subject to robust encryption"

This would imply that SSL (or equivalent) should "normally" be used.

Other EU Countries
The legislation in other EU countries was not examined.

Conclusion
It seems to be unclear whether websites that transmit personal data in clear text are in breach of EU Data Protection legislation.

However the EU Data Protection bodies were able to force Google to make changes to its Streetview product to comply with Data Protection legislation. These same bodies should be in a position to force the major websites to configure and use SSL properly.

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

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

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/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:

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:

 

 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:
 

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

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