Why does the OWASP top 10 never change?

Or very rarely?

Subtext, how should we work to create more secure applications?

The OWASP top to remains largely unchanged over long periods of time.  We still see high profile breaches like Talk Talk caused by easy to protect against application attacks.  These fact imply many organisations are still failing to do ‘application security’ properly.

So why is application / development security so hard?  OR is it?

I think application security has historically had similar problems to other areas of security.  It is not seen as a business imperative, so business needs, new features, meeting client requests etc. all supersede security requirements in the priority list.

For many of us this is clearly not news.  However, given the number of incidents that still occur, it is clearly not a problem that has been solved.

For me solving this falls into 3 key areas;

  • Board level buy in for security, and specifically security throughout the development lifecycle – SDLC (Software / Systems Development Lifecycle).  This will ensure there is support for the costs and time associated with delivering a secure development programme.
  • Buy-in from the development teams.  Work with them to ensure they understand the reasons for, and benefits of secure development.
  • Making security part of the SDLC, by ensuring that the relevant tasks and processes are embedded as part of the standard lifecycle.  This will also ensure they are audited as part of that process.

I’ve spoken about board / exec by in for security before, and will do again.  There will also be another post in this series covering developer buy in as that is key to the process being successful.

The rest of this post will cover the areas that I think need to be covered in through the process in order to ensure the development process is as secure as possible.

Where these steps fall, how they are implemented, and how they are checked / monitored will vary from organisation to organisation.  They will also depend on the development processes in place such as Waterfall and Agile variants.

At a high level, these steps are;

  1. Requirements including security requirements
  2. Secure designs
  3. Threat modelling
  4. Static code analysis
  5. Peer code review – focus on quality and maintainability not just ‘pure’ security
  6. Dynamic application analysis / web application scanning
  7. Penetration testing
  8. Associated processes – found flaws are fixed at each stage of the process
  9. Clear risk assessment and ownership processes
  10. Developer Training

 

Requirements, including security requirements.

Any project must have some requirements.  These are what enable us to answer the question ‘what problem am I solving?’.  This also applies to BAU (Business As Usual) type development that may not fall under the project processes.

These requirements need to include the non-functional areas as well, of which security is one.  Security requirements should be as standardised as as much as possible to minimise the effort, and tailored as part of any project or work initiation phase.  To support this, ensure your application security team is closely embedded with the project teams, business analysts and developers.

Secure Designs

While this is more of a statement than process, I have included it to highlight that security teams need to be involved throughout the design process.  I would also recommend that security should be an approver of system and application designs.  This will ensure that meet security policies and requirements as well as meeting secure design principles.

Threat Modelling

This is the process of reviewing a system and assessing any potential threats to it, along with how to counter those threats.  The earlier in the process this can be accomplished the better as it allows the designers and developers to work with the potential threats in mind.  Although either an existing system, or at least a high level design is required to make this worthwhile.

I am personally a huge fan of threat modelling as it has multiple benefits for relatively low cost / effort;

  • More secure designs and development as the teams working on the solution will have a better understanding of the threats, and how to counter them.
  • A better understanding of the system, one of the artefacts from threat modelling is the DFD (Data Flow Diagram).  How many systems in your organisation have have detailed DFDs?  This fills that gap.
  • Under the radar security awareness training.  Without labelling it training, the security team gets to spend a decent amount of time with the design and development teams talking about threats to a system, the consequences if these threats are realised and how to protect against them.

Static Code Analysis

This is the use of a code analysis tool the performs automated scanning of the code and / or binaries for potential security weaknesses.  Good tools also provide remediation guidance for the discovered issues and a workflow for assigning the issues and documenting how it will be remediated or mitigated if your don’t already have a tool for this.

These tools will integrate with various development environments and source repositories, along with different development processes.  If you are not already using one I would recommend performing an analysis of the key players in the market to assess the best fit for your environment.

Peer code review

This is the process of ensuring different developers assess each others work.  This should include cross team assessments with a strong focus on code quality and maintainability as well as security.

Encouraging this process to be as open as possible, to enable open debate about the best way to code will definitely be beneficial.

While code quality may not be strictly a security concern in the traditional sense, the better written, commented and maintainable code is, the easier it will be to maintain the applications security over the longer term.  This is especially true as it is developed and worked on by multiple people and teams.

Dynamic Application Analysis / Web Application Scanning

Similar to the static scanning, this will be an automated process, carried out using a scanning tool.  This is the process of assessing a running application for security vulnerabilities.  These usually focus on areas of user interaction such as web pages so will not be suitable for all systems.

The need for a running system means these scans fit later in the process than the static scans, and usually fit well through the testing phase of any project / development work.

It should be noted that while these are more effort than static scanning, they should be considered especially for larger or more critical systems as they will find issues earlier and at a lower cost than pen testing, thus ensuring less issues are found later in the process.

Penetration Testing

This is the process of dedicated professionals, usually from a specialist third party attempting to ‘hack’ the solution.  This is usually the final check from a security perspective that a piece of development or an application is secure enough to go live.

Due to the costs and efforts involved it is likely that you will want to haver a clear process in place for when and how often pen tests are required.  Depending on your industry there may also be minimum regulatory requirements around how often systems are pen tested.

Associated processes

I have included this as a catch all to highlight that all of the above processes need to have agreed and working feed back loops to ensure the items they identify are assessed and remediation agreed.

Risk Assessment and Ownership process

Following the above point, and discovered vulnerabilities that cannot be fixed or mitigated will lead to a risk to the organisation.  This must be formally assessed in terms of the level of risk, and then accepted for an agreed period by an appropriately senior business owner.  The risk process is an entire topic of it’s own!

Developer Training

I was not sure whether to put this at the start or end of the list as it must be an ongoing process outside of any specific project or development work.  As well as ensuring that your developers have approbate levels of secure coding training, this should be seen as a key part of your engagement with the developers and getting their buy-in for secure development.

Depending upon the size of your organisation I would recommend a combination of on line computer based training (with a programme to increase the skill / knowledge on the courses over time and dependant on the experience of the developers), workshops and presentations from external companies, including pen testers.  For larger organisations secure development forums and ‘conferences’ could also be considered.

 

While nothing is completely secure, especially as complexity increases, if you follow these steps as part of the process you will end up with applications that are definitely not the ‘low hanging fruit’.  This will reduce your risk of any application related breach.  In addition it will mean that should you have a breach your organisation will honestly be able to say that they had done what they could to ensure secure applications, and the protection of the data you hold.

As final thoughts for today’s post, do not take these in isolation, this only covers the application part of your security, all the other key areas from network security to JML (Joiners, Movers, Leavers) processes must be in place to ensure an appropriately secure organisation.

K

 

 

 

2 thoughts on “Why does the OWASP top 10 never change?”

  1. Great article Kevin, and it should make perfect sense to every organisation, however it’s amazing in this day and age with breaches occurring by the minute how some organisations still can’t arrive at this conclusion.

    From my day to day experience we’re still coming across the same arguments/obstructions every day:
    – Too many organisations are still far too reliant on Pen Testing alone and truly believe that running this yearly/quarterly provides them with all the coverage they need – they ignore the fact that this is only one piece of the jigsaw, it’s simply a’point-in-time’ test and that it should be a continuous exercise 24×7, 365.
    – You mention the board, but I’m still amazed by how many Security Managers I meet that seem to be worried about upsetting their developers and use this as push back for not using a Vulnerability Scanning service. As you say, the key is the complete SDLC, but there’s a perception that if you check the code using tools like an Application Vulnerability Service scanning (both Static and Dynamic) code and then feed back the results to your developers, they’ll take offence at any negative findings in their code – surely we’re working in an age where Organisational Security is the number one goal so everybody should be pulling together and using every method possible to ensure that it’s met, it’s about learning from mistakes and not doing the same things over and over again.

    People will continue to watch the news, follow social media and see attacks growing in number and severity by the day and still convince themselves that they’re doing everything possible within their organisation to prevent them from happening – yet only a handful are taking all of the steps you outline above, so clearly they’re not. As you say, this is only a small part of a successful security posture but an essential one.

Leave a Reply

Your email address will not be published. Required fields are marked *