Thursday 29 December 2011

XSS and Verizon DBIR

I recently gave a short talk at OWASP Switzerland. One of the slides I showed was a figure taken from the Verizon 2011 Data Breach Investigations Report. (DBIR) (below) which was published in April 2011. The chart shows the type of hacking used as a percentage. The DBIR report looked at approximatelay 761 data breaches - not only those caused by web application vulnerabilities. It's worth reading.
 
The main discussion point at the chapter meeting was the value for Cross site scripting (XSS). According to the DBIR only 1% of data breaches are as a result of XSS vulnerabilites and less than 1% of stolen records. SQL injection accounts for 14%  (and 24% of records stolen), That said, there is no direct mapping from the types of hacking to the OWASP Top 10.

The value for XSS seems low given the focus that the AppSec community and OWASP place on it. One question that arises is whether these figures are accurate. Verizon does talk about "Sample Bias", but it should be noted that much of the data comes from outside organisations.

A few thoughts:
  • Based on these figures it would be difficult to persuade managers with a limited security budget to invest significantly in preventing XSS.
  • Issues with authentication and passwords are much more prevalent according to DBIR. Does this indicate that XSS should fall a few places in the next version of OWASP Top 10 and that "A3: Broken Authentication and Session Management" should climb? This, especially as the OWASP Top 10 is meant to reflect actual risk.
  •  XSS vulnerabilities are prevalent in many web applications but are not actually exploited all that much to breach data.

Here is the DBIR chart. The quality isn't great. Best to see it in the original Verizon 2011 DBIR report on page 32. Figure 23 a few pages later is also interesting. It shows that Web Applications attacks were used in 22% of the breaches, but result in 38% of the records breached. So you get more bang for your buck if you attack an online application.



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

Wednesday 7 December 2011

Veracode State of Software Security Report

I downloaded the Veracode State of Software Security Report Volume 4

Very useful reading for anybody interested in the state of software security.

One thing that struck me was the actual download process. To download the report, you have to register giving your contact details. Fair enough, Veracode wants to see who is reading their reports. However a few security related thoughts on this process:
  • Who is Marketo? I can see no privacy statement to say what happens to my contact details.
You can argue that if I was so worried about these points, why did I register? Good question....and I actually did give accurate details.

I have to ask myself whether am I over the top? Maybe, then again....

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

Tuesday 29 November 2011

Individual Accountability in the Swiss Parliament

I recently did a tour of the Swiss Parliament  in Bern.  We got to sit at the desks in one of the two main chambers where the delegates meet and vote.

So to vote, the delegate has to press two buttons. The control button is on the front-left of the desk. The main Yes/No/Abstain buttons are on the back right of the desk. To vote, the user must press the control button and one of the main voting buttons at the same time. Both hands are occupied. The ideas is that the delegate cannot vote for an absent neighbour . Anyway that's what our guide said. 

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

Sunday 27 November 2011

To SSL or not to SSL

Update: November 29th, 2011. I have just noticed that Troy Hunt has posted an excellent article on SSL/TLS

I started a poll on LinkedIn. The question:
  • "Should web applications which process Personally Identifiable Information (PII) be legally required to use SSL/TLS? "
with a simple Yes or No answer. There is a link to the LinkedIn poll at the bottom of this blog. However, I suggest you read through the following thoughts before answering.

The question could have been:
  •  "Should web applications which process Personally Identifiable Information (PII)  use SSL/TLS? "
But that would have been easy. Most people would probably vote yes because SSL is A GOOD THING. The addition of  the "be legally required to" clause makes it more interesting.

What prompted this soul searching? I was recently looking through a UK based web site. The privacy policy states:
  • "We take your individual privacy very seriously. We aim to ensure that this website meets and exceeds all relevant legal and regulatory requirements, including the Data Protection Act."
Great  - until you see that they don't use SSL to protect account information. This includes name, address, phone number etc.  In fact, you could argue that this website processes sensitive personal data under the Information Commission's Office (ICO) definition. According to the ICO, sensitive personal date " needs to be treated with greater care than other personal data". But no SSL on said website.

Is SSL Already an EU Legal Requirement?
Does the Data Protection Act require SSL? The UK version of the Act is a bit vague. Principle 7
states you "should have security that is appropriate to:
  • the nature of the information in question; and
  • the harm that might result from its improper use, or from its accidental loss or destruction."
Then the question becomes: "is SSL appropriate"?  The website operator can argue that they considered using SSL, but concluded that it wasn't appropriate. The Irish Data Protection commissioner goes a bit further in their security guidance, stating that encryption:
  • "is considered an essential security measure where personal data is stored on a portable device or transmitted over a public network."
So no clear answer. 

Why Don't Website Operators Use SSL?
Maybe it's because:
  • they genuinely don't even think about it. Although the little "https" lock on the browser is a fairly well known security measure. This is an InfoSec problem where awareness needs to be raised.
  • it is easy to say something like  "We take your individual privacy very seriously" but then do nothing about it.That's lip service..
  •  "Facebook don't use it - so why should we?" FB seems to be changing
  • it's too difficult to configure. It probably takes a while, but it isn't that difficult
  • it's because it's too expensive.  Google "SSL Certificate" and you can get a GoDaddy cert for €9.99
  • it kills performance. According to Google,"SSL/TLS is not computationally expensive any more."
  • SSL is broken and has been more or less every year since 1995. 
  • users will keep getting security warnings as content switches between secure and non-secure
  • apart from firesheep like utilities,  where is the evidence that the lack of SSL has really been exploited all that much?  
Reasons To Use SSL
SSL:
  • does raise the infamous "security bar"
  • is not too difficult to implement 
  • comes in at number 9 in the OWASP Top 10
  • is required by PCI DSS  
  • gives you a nice warm feeling inside
Conclusion
But back to the original question. "Should SSL be legally required when processing PII?" The problem with this approach is that a requirement like this is very difficult to enforce. I think it would be much better trying to persuade developers and website operators to implement SSL rather than trying to use the crude hammer of legislation. So I think I will vote NO.

Here is the link to the Poll itself if you want to cast your vote:







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

Monday 31 October 2011

Australian Online Applications Are Secure?

The Australian Defence Signals Directorate (DSD) published the Top 35 Mitigation Strategies to:
  • "mitigate targeted cyber  intrusions.  The  list  is  informed by DSD’s experience  in operational cyber  security,  including  responding  to  serious  cyber  incidents  and  performing  vulnerability   assessments and penetration testing for Australian government agencies.

According to DSD:
  • "Rankings are based on DSD’s analysis of reported security incidents and vulnerabilities detected by DSD in testing the security of Australian Government networks. "
However, if you review the 35 strategies, there is no mention of the need to develop applications securely. SQL Injection, XSS etc. are all missing.

Does this mean that Aussie Apps are secure? Have they got it sorted? (Eventhough they seem to be crap at bog ball ++ (and struggle at rugby))



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

    Saturday 8 October 2011

    Installing Hacking-Lab Live CD

    In preparation for the OWASP Switzerland meeting on October 11th you should try to install the Hacking-Lab live CD.

    These are the simple steps I followed on a Windows 7 laptop.

    • Dowload the Virtual Appliance OVA file to your laptop
    • Download and install the Oracle Virtual Box  application onto your laptop
    • Double-click the .ova file through Windows Explorer and the appliance import process should commence on the Virtual Box application. You should see something like Fig 1:
    Fig. 1: Oracle VM Virtual Box Manager

    •  In  theVirtual Box Manager left-hand pane double-click on the LiveCD-Hacking-Lab-V5.55 entry. The LiveCD should start and after a short while  the Welcome screen as shown in Fig 2 should appear.
    Fig 2: Welcome Screen
    You should be ready to go now at the OWASP meeting.

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

    Tuesday 4 October 2011

    OWASP Switzerland Chapter Meeting - October 11th



     OWASP Switzerland Chapter Meeting
     
    When: October 11th, 17:00 - 19:00
    Where:   ITACS by Bitterli Consulting AG
                   Stampfenbachstrasse 40
                   CH-8006 Zurich

    Price: Free (but you need to reserve a place)

    Topic:
    Presentation of the OWASP Top 10 by Cyrill Brunschwiler from Compass
    Security (http://www.csnc.ch/en/) followed by a hands-on session.


    More Information: OWASP Switzerland


    
    

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

    Monday 29 August 2011

    Swiss Data Protection and Online Applications

    Update:18/9/2011 Major Revision


    If you are developing online applications in Switzerland which process personal information, what does Swiss Data Protection Legislation require you do to?

    This post looks at the major technical items and some of the implications that it may have for your online development project. There are two main items:
    • Federal Act on Data Protection
    • Ordinance to the Federal Act on Data Protection (OFADP)

    Federal Act on Data Protection
    The main piece of legislation is the "Federal Act  on Data Protection".  There are 39 articles divided into 8 sections. This blog reviews some of these articles and what it may mean for your development. It is not comprehensive but just a guide. It does not consider the later sections such as those dealing with processing by Federal Bodies

    Art. 3 Definitions

    Implications: Use the definitions section to decide if the legislation applies to your application and whether you are processing personal or sensitive personal information

    Art. 4 Principles

    Implications: The development should have a privacy statement or similar, which describes how personal data is used.

    Art. 5 Correctness of the data
    Implications: The application should somehow allow users view and update their personal information. This can be done either directly (by the user) or indirectly (e.g by an administrator).

    Art. 6 Cross-border disclosure
    Implications: You need to be careful about transferring personal data outside of Switzerland. In particular be wary of development teams and test teams who are based outside the country. "Test data" that they are using might still be real personal data.

    Art. 7 Data Security
    Implications: This is the main artcile on security. It states that: "Personal data must be protected against unauthorised processing through adequate technical and organisational measures". This is where good security practices such as the OWASP Top 10 come into play

    Art. 8 Right to information
    Implications: The application will need to allow persons to view their information.Typically the user be able to logon and view their information. The other main method is that the user can request to see their information from the data controller. The controller must then be able to retrieve the information from the application and make it available to the user.

    Art. 10a Data processing by third parties
    Implications: You may outsource processing to a third party. However the third party must have adequate levels of security in place.


    Art. 11a Register of data files
    Implications: Under certain circumstances you may need to register with the commissioner. For example, if you process sensitive personal information.


    Ordinance to the Federal Act on Data Protection (OFADP)
    The OFADP is the second major element of Data Protection legislation. From a security perspective there are two significant articles: 8 and 9.

    Art. 8 General measures
    Implications: Article 8 (general measures) states that people who process personal information:
    • shall ensure the confidentiality, availability and the integrity of the data in order to ensure an appropriate level of data protection
    The security measures that you take depend on a number of items, including the purpose and extent of processing, current state of the art and "an assessment of the possible risks to the data subjects". So some sort of risk analysis should be undertaken.

    Art. 9 Special measures
    Implications There are 8 (a-h) special measures.These talk about typical security controls such as security during transmission and storage, authentication, access control, etc. Of particular interest is clause h which states:
    • input control: in automated systems, it must be possible to carry out a retrospective examination of what personal data was entered at what time and by which person.
    Therefore, Clause h implies that your application must have a proper audit trail.

    So if you are implementing a system which processes personal information, then it is worth while reading down through the information in the following links.

    Useful Links:
    Note: These are English links. As each link says - "English is not an official language of the Swiss Confederation. This translation is provided for information purposes only and has no legal force."  However you can find links to all four official languages on the top of the HTML pages. This way nobody is offended - or everybody is offended equally.

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

    Wednesday 24 August 2011

    RBS and HAYS contractor rates snafu

    So, Hays recruitment "distributed an email disclosing the remuneration of thousands of contractors working for the state-backed Royal Bank of Scotland". Details are unclear, but a few questions from an Information Security perspective.
    • Why is this type of information lying around in an attachment?
    • Was the email attachment encrypted?
    • Why is there not some sort of Data Leakage Prevention (DLP) in place? A "Little Britain" type computer program which looks at the email recipients (800) plus attachment (3000 names) and replies "Computer says: Are you Sure?"
    • etc.
       
    Can your organisation learn any lessons, before it's too late? Here's an opportunity to get some extra security budget.

    Maybe our old friend the Data Flow Diagram (DFD) could have helped....here we go again.

    Useful Links:

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

    Thursday 4 August 2011

    Tallaght and Roscommon Hospitals Data Breaches and Data Flow Diagrams

    Updated: August 11th August to include Roscommon Hospital breach.

    Tallaght Hospital* in Dublin, Ireland, recently suffered a data breach. Details are unclear but it involved outsourcing of transcribing services to Uscribe, a company based in the Phillipines. Something went astray.

    In the Roscommon County Hospital incident, confidential paper medical records from patients treated in Midland Regional Hospital in Mullingar were discovered in a rubbish bin in the grounds of Roscommon County Hospital.

    Would simple Data Flow Diagrams (DFD) have prevented these? Don't forget that Data Protection legislation also applies to paper records.


    So here are some reminders. At the start of a project draw a simple DFD. This should show where data flows and where it is stored in the system. Don't forget to ask the following types of questions.
    • Does anybody export data to laptops, USB sticks etc.? (Danger Danger)
    • How are backups handled? Are they managed by third parties?
    • Is the same production data used by test systems, development companies etc.?
    • What about data used for trouble shooting, diagnositic purposes? Is that properly deleted when it is not longer needed?
    • Are processes in place to securely erase any hardware when it is being disposed of? 
    The same types of questions can be asked about paper based records.
    When you have indentified all the data flows and data storages, then you can ensure that you have adequate security measures in place for all of these points. In the case of Tallaght the DFD would have shown that data goes to the Phillipines. Since this is personal data, special measures for "Transfers Abroad" need to be in place. In the case of Roscommon, the DFD might show that paper records aren't destroyed securely.

    When you are embarking on your next project, don't forget to use a simple DFD.

    Some links:

    (*) Full Name "Adelaide and Meath Hospital, inc National Childrens Hospital, Tallaght"

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

    Saturday 18 June 2011

    CitiGroup Breach - 3 SDLC Activities that Failed


    CitiGroup recently admitted a security breach where hackers got details from lots of credit card customers. The attack itself seems to have been fairly simple. The attacker logged on normally to an account. They then ran a script which iterated through the account number in the browser address bar. According to the New York Times,  they "automatically repeated this exercise tens of thousands of times — allowing them to capture the confidential private data."   In OWASP Top 10 speak this was a insecure direct object reference vulnerability.

    It looks like a fairly simple vulnerability, although the details are unclear. But it should not have happened.  Here are three Secure Development Life Cycle  (SDLC) activities which, if implemented properly, would have probably prevented this attack*:
    1. Authorisation checks were not implemented properly to check that the logged on customer had permission to view the details for the requested account number. This is a failure in the analysis/design phase. Whenever a user initiates a request your application should check that the user has permission to execute this particular transaction. There are two basic levels. At a coarse level, check that the user has permission to access this page. At a finer level, the user may have access to a particular page. However, does the requested account (or resource) belong to this user?

      It may be that authorisation checks were designed correctly by CitiGroup, but not implemented by the development team. In this case the assurance/testing phase should have come to the rescue.
    2. During the assurance phase, this vulnerability should have been picked up. A penetration test which probed for various account numbers would most likely have caught this. Similarly a code review  would have indicated that something was wrong. This is what the OWASP Application Security Verification Standard (ASVS) is aimed at.
    3. Finally, Application Monitoring during operation did not recognise the suspicious behaviour that numerious requests were coming from a single account. If proper monitoring had been in place, Citi may been alerted much sooner (maybe in real-time) to the problem. The OWASP AppSensor project could help here.
    So learn the lessons. Make sure that you have an SDLC in place for your development process.
    Have a look at the SLDC Main Posts which shows the main SDLC related posts on this blog and what are the most important steps in a SDLC.

    Links:

     * Of course this is all speculation, since we don't know what really happened.

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

    Monday 13 June 2011

    Developing Securely for SmartPhones - A few Key Principles

    At AppSecEU last week, I attended Dan Cornell's (Denim Group)  presentation  on Security Testing Mobile Applications. You can view the slide deck on the Denim Group blog.

    Basically, Dan demonstrated how you can "root" the smartphone and then reverse engineer the application to do whatever you want. Slide 6 shows a "Generic Mobile Application Threat Model" for a SmartPhone app connecting to an enterprise application.  It shows the following threats:
    1. Malicious User
    2. Malicious User (bypassing Mobile Client)
    3. Malicious Mobile Application
    4. 3rd Party Services (Possibly Malicious)
    Nr. 2 is where a malicious user bypasses the smartphone completely and attacks the enterprise web services which the smartphone uses.

    Nr. 3 is a malicious application which is installed on the smartphone and can interfere with other installed applications.

    Nr. 4 is where the smartphone connects to 3rd party services which have been compromised.

    Key Principles

    So what  are the lessons when developing enterprise type apps for smart phones? Here are a few thoughts. These are based in part on a short conversation I had with Dan after his talk*.

    1. Treat the smartphone as an "untrusted device".
    2. If possible, don't store confidential information on the phone. 
    3. Develop your web services securely, as an attacker may discover the web services and attack them directly - bypassing the smartphone completely.
    4. Your web services should validate any input data and perform the necessary authorisation, access control, business logic checks etc.. Any validation performed on the phone should be repeated by the web service
    5. Use SSL to prevent man-in-the-middle type attacks.

    * These may not be an accurate reflection of Dan's views!

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

    Friday 10 June 2011

    My OWASP AppSec Europe 2011 Presentation

    I gave my presentation today at OWASP App Sec Europe 2011 today.

    Here is a link to the slide deck. 

    Note! It's in PDF format.

    The talk is aimed at the developerment team. At the start of a development project you should think a bit about security. In the presentation I go down through a simple structured list of security  tasks that you should address in order to gather the security requirements that the project should implement.

                       
                                              

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

    Sunday 5 June 2011

    Your OWASP AppSec EU Homework

    This is your homework if you are coming to my presentation at the OWASP App Sec EU talk  on Friday June 10th, in Dublin. I'm going to use this completely ficticous application - the Brochure Co (BCo) website. This post is to give a quick overview of the application and a number of use cases which it will implement.

    The main goal of the talk is to specify the security requirements that the application development team should incorporate during the implementation of the BCo website. 



    The presentation will describe a set of topics that should be covered during a security workshop which is held at the start of the project.

    Description
    Brochure Co (BCo) is a company that manages and distributes a range of printed brochures on behalf of its clients. These brochures are sent out via normal mail on a regular basis. The new online application will allow BCo  users to register online and choose the brochures that they want to receive through the normal mail.

    Use Case 1 - Registration
    BCo users register with the  Bco.demo website. They enter their name and postal address. They choose what brochures they want to receive.

    Use Case 2- Edit
    BCo users can logon to the site and modify their address details as well as change the range of brochures that they receive.

    Use Case 3- Delete
    BCo Users can delete their accounts when they no longer want to use the application

    Use Case 4- WebSite Admin Downloads Addresses

    On a regular basis, the BCo Website Admin logs on and downloads the list of BCo user names and addresses as well as the list of brochures that they want to receive. The list is downloaded as a CSV file to their laptop. The BCo Website Admin cleans up the list.

    Use Case 5 - WebSite Admin Forwards List

    The BCo website admin then sends the cleaned up list in a spreadsheet format to PrinterCo in an email. PrinterCo then prints the brochures and sends the brochures to the BCo users via normal mail.

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

    Thursday 26 May 2011

    ICO Website and Cookies Law - Strange

    The new cookies law comes into force in the UK today, although the ICO (Information Commissioner's Office) is allowing one year to comply with the new rules. The purpose is to ensure that:
    • "businesses and organisations running websites in the UK need to get consent from visitors to their websites in order to store cookies on users’ computers. "
    How the ICO does it 
    The  ICO on its website shows how it could be done - and it's strange. If you visit the website you are shown a fairly ugly header at the top:









    It gives you an option to say "I accept cookies from this site". So the first thing that strikes you is why is there is no option to say:
    • "I DO NOT accept cookies from this site."
    The ICO site uses Google Analytics to track visitors. You can go to the ICO Privacy Notice page and follow a link which allows you to download an AddOn from Google which might allow you to disable the cookies....but I doubt if many users will go to the effort of doing that.

    Fiddler shows me that if I don't click on the "I accept cookeis from this site" header and just leave it there, no traffic goes to Google Analytics

    So in effect, if you don't want to accept ICO cookies, the best thing is leave the header on top of the screen and not to click it. Just ignore it.



    Firefox - Do Not Track
    Do Not Track - DNT
    In addition I use Firefox 4 and I have set the option
    • Tell web sites I do not want to be tracked
     This is under "Tools!Options!Advanced!General". This sends a DNT request in the Request Header. So ideally the ICO should honour that and should never ask me in the first place whether I want to accept cookies.


    Conclusion
    The way the ICO website implements the new cookie law is not elegant.

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

    Friday 20 May 2011

    My OWASP AppSec Europe 2011 talk


    I'm giving a talk at the OWASP AppSec Europe talk in Trinity College, Dublin, Ireland on Friday June 10th at 11:10. It's part of the Prevent track.

    The talk is aimed at developers (or builders as OWASP calls them). At the start of a development project you should think a bit about security. In the presentation I will go down through a simple structured list of security  tasks that you should do in order to gather the security requirements that the project should implement.


    If you spend a few hours thinking about security early on, you could save yourself a whole lot of problems later on. A workshop with the relevant people is a suitable format for this. The list of tasks which the presentation outlines can form the basis for this security workshop.  

    In fact, you can use the list of tasks as the agenda for the workshop.

    A fictitious website which processes personal information (as defined by EU Data Protection Legislation) will be used as an example.

    Even QEII likes the list
    The list will include the following:
    • Data Classification
    • Simple Threat Analysis
    • Data Flow Diagram
    • User LifeCycle/Authentication etc.
    • Authorisation
    • Segregation of Duties
    • Audit Trail
    • Data Retention
    • Availability/Resilience
    • Other Compliance Issues


    If you spend a few hours at the start of a project going through this list, you will have a good idea of your security requirements and what you need to do. It is much better than trying to do this at the end.

    This is what I will try to get across in this talk. So if you are on the development side of the house and you are interested in a simple approach to specifying your security requirements then do come along to the talk.  It will be an XSS-free zone!


    The security list is based on Section 2 of  the SDLC Quick Reference

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

    Monday 2 May 2011

    ICO Data Protection Principles and Online Applications

    Schedule 1 to the UK Data Protection Act lists 8 data protection principles. You can read more on the Information Commissioner's Office (ICO) website here. If you are developing an online application which processes personal information what are the implications?

    This blog entry delves a bit deeper.

    Privacy Notice

    First, a short discussion about the "privacy notice". According to the ICO, this is the notice "that individuals are given when information about them is collected". Typically you will display it on your website.  The ICO has issued a Privacy Notices Code of Practice  "to help organisations draft clear privacy notices and to ensure they collect information about people fairly and transparently".

    Having a proper "Privacy Notice" in place is the main step you can take in adhering to a number of the Data Protection Principles.  So one of your first tasks is to develop an appropriate Privacy Notice and then to adhere to it.

    Data Protection Principles

    The following sections lists the principles and the implications they may have for your online development.

    Principle 1
    Personal data shall be processed fairly and lawfully and, in particular, shall not be processed unless –

    (a) at least one of the conditions in Schedule 2 is met, and

    (b) in the case of sensitive personal data, at least one of the conditions in Schedule 3 is also met.

    Implication: Have an appropriate Privacy Notice in place.
                                                                               *      *      *

    Principle 2
    Personal data shall be obtained only for one or more specified and lawful purposes, and shall not be further processed in any manner incompatible with that purpose or those purposes.

    Implication: Have an appropriate Privacy Notice in place.
                                                                               *      *      *

    Principle 3
    Personal data shall be adequate, relevant and not excessive in relation to the purpose or purposes for which they are processed.

    Implication: Have an appropriate Privacy Notice in place.
                                                                               *      *      *

    Principle 4
    Personal data shall be accurate and, where necessary, kept up to date.

    Implication: The application will need to be able to provide users with access to their personal information. The application should also have a mechanism to allow personal information to be updated. For example, if a user moves home, the application should have a facility in place which supports address updates. Either the user does this themselves directly by logging on, or a Customer Services Agent has the ability to do this on behalf of the customer.
                                                                               *      *      *

    Principle 5

    Personal data processed for any purpose or purposes shall not be kept for longer than is necessary for that purpose or those purposes.

    Implication: This should be covered under a data retention policy. The application will need a manual delete function which removes a user's personal information. Either the user does this themselves directly by logging on, or a Customer Services Agent has the ability to do this on behalf of the customer.

    The application may also need an automated delete mechanism which automatically erases customer information after a certain period of time or inactivity.

    You need to be careful about this principle as it may conflict with other requirements which force you to maintain records for a certain minimum period of time. This could especially be the case with financial transactions.

    Another tricky area is audit trails. How long should they be retained for?
                                                                               *      *      *

    Principle 6
    Personal data shall be processed in accordance with the rights of data subjects under this Act.

    Implication: Have an appropriate Privacy Notice in place.
                                                                               *      *      *

    Principle 7
    Appropriate technical and organisational measures shall be taken against unauthorised or unlawful processing of personal data and against accidental loss or destruction of, or damage to, personal data.

    Implication:  This is where the main information security good practices come into play. These include topics such as authentication, authorisation, encryption, audit trail, OWASP Top 10 etc. The Security Requirements section of the SDLC Quick Reference is essentially aimed at trying to meet the requirements of this principle.
                                                                               *      *      *


    Principle 8
    Personal data shall not be transferred to a country or territory outside the European Economic Area unless that country or territory ensures an adequate level of protection for the rights and freedoms of data subjects in relation to the processing of personal data. 

    Implication:  Before transferring personal data to a third country, you need to ensure that the third country has adequate levels of protection in place.  You need to be careful about using real personal information in development and test environments - especially if you outsource development to third parties.

    Subject Access Request

    One of the main rights which the UK Data Protection Act gives to individuals is the right of access to their personal information. A user can send a Subject Access Request  requiring you to provide them with a copy of the personal information that you hold about them.

    Implication:  Your application should provide functionality which supports this requirement. When a Subject Access Request arrives, your application should have a function which can return all information for that user.

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

    Tuesday 12 April 2011

    Switzerland, Hotel Check in and the Police

    An interesting item on Swiss National Radio DRS1 (German) this morning. In certain cantons, when you check-in to stay in a hotel, your details go straight to the police electronically. The police will then check to see if the hotel guest is a person of interest.

    The Data Protection Officer for Canton Zurich is not happy with this situation and is looking to get it changed. In the meantime, he suggests submitting as  little information as possible on checking in to the hotel. The other cantons mentioned are Lucerne and Basel Stadt. 

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

    Sunday 10 April 2011

    BBC Article on CEOP Website Security


    There is an article on the BBC about a security vulnerability found on the Child Exploitation and Online Protection Centre (CEOP) website. According to the BBC:

    "A member of the public found a form on the Child Exploitation and Online Protection Centre's website - to report alleged offenders - was unencrypted.
    Security experts have described the breach of data as a serious error which could have put children at risk.
    ...
    There will now be a full investigation by the Information Commissioner's Office.
    ...
    The unencrypted pages meant personal details entered on the site could have been visible to anyone with a sinister motive."

    So it looks like  the non-use of SSL on a website is a serious error which warrants a full invesitigation by the ICO.  Granted the CEOP processes sensitive information.


    What does all this mean? What about the gazillion other websites that children use and which don't force the use of SSL? Answers on a postcard......




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

    Thursday 7 April 2011

    OWASP Zürich Meeting Tuesday April 12th - I am Speaking

    I am speaking at the OWASP Zürich Meeting on Tuesday April 12th at 17:00. It looks like it will be held in the refined surroundings of the Rheinfelder Bierhalle in Niederdorf.

    The title of the talk is not really defined - but the Security Requirements Quick Reference will do for now .... or maybe the Security Requirements Cheat Sheet

    I intend covering the Security Requirements (Section 2) of my SDLC Quick Reference.  Basically how do you go about specifying the security requirements that your web application should meet. Topics will include data classification, data flow diagrams, threat analysis, etc.. The talk will use a simple ficticious website as a basis.

    So if you are interested in how you go about gathering security requirements for your application please come along.

    More details on the  OWASP Switzerland mailing list.

    PS: .....And if you can't attend the meeting do have a look at the  SDLC Quick Reference on this blog

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

    Friday 25 March 2011

    Winston Churchill on Passwords

    Winston Churchill quote on passwords:
     "It has been said that the password is the worst form of authentication except for all the others that have been tried."

     OK. He didn't say that (as far as I know). I paraphrased him slightly. Here is the alleged original quote:

    "It has been said that democracy is the worst form of government except all the others that have been tried."
    http://www.quotationspage.com/quote/364.html

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

    Tuesday 22 March 2011

    Tuesday Top Tip - Penetration Testing

    Most companies use application penetration testing towards the end of the development life cycle in order to identify security vulnerabilities. This can be a problem - especially if you had not thought about security earlier in the development process.

    What do you do if the pen test throws up major security issues?

    If it's late in the development cycle, then these issues will be expensive to address. So you are more inclined to ignore them. That could leave you vulnerable.

    Have you been in a position where a serious SQL injection vulnerability has been discovered two days before product launch? What to do? You know it would have been fairly simple to address if it had been discovered a lot earlier - but now it's not so simple.

    So here are some Tuesday Top Tips:
    1. You should think of application pen testing as a way to confirm that all your planned security measures have been implemented properly during the earlier development phases.
    2. Try to do some pen testing as early as possible in the development. If you discover issues, they should be less expensive to address - and you can integrate the lessons learned into the rest of the development.

    All this assumes that you have integrated security into the development lifecycle.

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

    Wednesday 16 March 2011

    Twitter Supports SSL

    Twitter now supports SSL. Unfortunately, like Facebook, you have to opt-in. You can set it using the "HTTPS Only" setting under your Account options.

    TWITTER

    1. Select "Profile" and then "Edit Your Profile"
    2. Down towards the bottom of the page you will see "HTTPS Only".
    3. Check the "Always use HTTPS" option
    4. Select "Save" to store your settings.


    Do it now - you know you should!



     .....AND DONT FORGET FACEBOOK

    To configure SSL in your Facebook account:
    1. Select "Account" and then "Account Settings"
    2. Select "Account Security"
    3. Under "Secure Browsing (https)" check the "Browse Facebook on a secure connection (https) whenever possible" option
    4. Select "Save" to store your settings
      .....AND IF YOU ARE DEVELOPING YOUR OWN WEB/ONLINE APPLICATIONS

    Configure your website so that it uses SSL. Your users will thank you. Actually they won't...but you can feel smug.

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

    Sunday 27 February 2011

    Overview of Main Posts

    This post gives an overview of the most important SDLC related posts in this blog.

    • SDLC Quick Reference  is a a quick reference checklist of security related items you should consider addressing during the development lifecycle of your web or online project. This is the main article.





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

      Sunday 13 February 2011

      Is Google Analytics illegal in Germany?




      Update May 25th 2012


      It looks like it's OK again  to use Google Analytics in Germany 
         
      Today I stopped using Google Analytics (GA) on this blog. The reason is that the German Data Protection Authorities have recently said that usage of GA is illegal. They are of the opinion that the way GA uses IP addresses breaches their laws.  I know that some readers of this blog come from Germany. How do I know? Google Analytics.


      This blog also uses StatCounter to analyse visitor traffic. StatCounter is based in the EU - Ireland. So that should be OK - at least in Europe. Anyway,  I prefer StatCounter so GA is no great loss.


      The irony is that this blog is hosted on Google Blogger which is based in the US. This should be OK because Google is signed up to the Safe Harbor framework. This roughly means that it is acceptable to store personal information of EU citizens on Google infrastructure.

      An added complication is that Google Blogger has a feature called Stats, which also offers visitor tracking functionality. This is separate to GA, so hopefully it will not be a problem. It is all a bit mind boggling!

      So should you remove Google Analytics from your website?


      Links:

      PS:  I have just noticed that the Information Commissioner's website in the UK uses Google Analytics. So maybe he shouldn't visit Germany anytime soon.

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

      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