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;
- Requirements including security requirements
- Secure designs
- Threat modelling
- Static code analysis
- Peer code review – focus on quality and maintainability not just ‘pure’ security
- Dynamic application analysis / web application scanning
- Penetration testing
- Associated processes – found flaws are fixed at each stage of the process
- Clear risk assessment and ownership processes
- 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.
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.
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.
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.
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!
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.