|---Module:text|Size:Small---|
Application Security was not always a top priority for teams throughout a software development lifecycle. In fact, it was only a concern when the application was about to go to production or in the event of an attack.
However, as a result of organisations’ digitalisation, processes became digital and applications are more exposed to threats, which has put security in the centre stage of software delivery over the last years. It is not a product one can buy, but rather an evolutional process that should be implemented as soon as possible.
So, let’s look at 10 steps for (more) secure applications.
1. Know your enemies, model your application threats, and manage your risks and vulnerabilities.
In most situations, the “who, what, where, how” that allows organisations to respond to attacks remains unknown. In the direct aftermath of an attack, it’s this information that will allow organisations to recover their assets, limit damages and restore security to the environment. Consuming adversary intelligence and anticipating these answers will allow to create strategies to protect their information systems.
Modelling your application threats will improve knowledge on the delivery process risks and strategies about what to secure and how to do it. Security is a process – not a product –, so during the delivery one should mitigate vulnerabilities. But if any appear, don’t panic: vulnerabilities can be managed and resolved according to the in-place remediation processes.
Knowing a vulnerability and doing nothing about it is assuming the damage that can arise from its exploitation. If you discover a vulnerability and you are not able to fix it, then report it.
2. Introduce security in the design phase.
Application security should not be a consequence, but rather a principle. Waiting for customer penetration or vulnerability assessments can lead the team to a situation where the remediation will be painful (and costly). Imagine if you have to refactor or even redesign a system component just a few days before it goes live.
Making sure security is introduced in the early stages of the functional analysis and solution design gives the team time to think about risks and options to build a more secure solution, using security standards, tools and best practices. The Secure Software Development Lifecycle defines what should be the team’s concerns across all development processes, what to do and the security controls that must be in place.
3. Use an application security rule book.
Are you aware of all the guidelines you should follow to secure your applications? Software development is changing every day: new requirements, new policies, new vulnerabilities and technology evolution make Application Security a true challenge. Having a tailored and document with all guidelines and policies helps you delivering better software, reflecting the perfect security maturity stage in which every application should be.
4. Know and secure the application languages, third-party libraries, and component security specifications.
An information system can be built with a lot of components: application servers, databases, programming languages, third-party libraries, etc. Are you aware of the security specification for every component of your architecture?
For every pre-built component security documentation should exist, so rely on official documentation to support the usage of those components.
For every language, there are security recommendations to check, before you start coding. Review your code and your architecture using the most valuable asset you have: your team. Peer review is essential to detect security problems in your applications.
For every component, you should search about known vulnerabilities; the open-source libraries are not excluded and there are tools to check vulnerabilities on dependencies.
5. Build security testing into development.
Why not find security issues in an early stage of the delivery process? In a Secure Software Development Lifecycle, the team should implement security controls in specific points. Static and dynamic code analysis, penetration testing, and vulnerability assessments should be used to ensure the security quality of your team’s code. Most of the testing tasks can be automated using tools integrated into your CI/CD pipelines, but if needed and depending on the context, teams can also execute manual security testing. Make sure to cover your security code (e.g. authentication, access control, auditing) and business-critical features with unit and integration tests.
Don’t forget: security testing is about fixing vulnerabilities, so don’t be afraid to break your pipeline until the issue is fixed or until you manage the risk of not fixing it. Most importantly: always report the vulnerabilities.
Find the other 5 steps here.
.jpg)
