More
CALL To Details
To Know
-
Lot's to lose
10 steps for more secure applications
CALL To Details
—
Dec 2020
Application Security was not always a top priority when teams delivered software. In fact, it was only a concern when the application was about to go into production or in the event of an attack. As a result of organisations' digitalisation, processes became digital and applications more exposed to threats.
Over the last years, security has become one of the priorities in software delivery. 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.
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 is 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 creating strategies to protect their information systems.
Modeling 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, you 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: use the vulnerabilities form, or alternatively contact the Security Testing team or even the Application Security team.
Application security should not be a consequence but 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.
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...
Imagine having a tailored and targeted document with all guidelines and policies to help you deliver better software. This document already exists and we call it The Rule Book.
The Rule Book is an ever-evolving document compiling guidelines, standards, community knowledge, and code examples, reflecting the perfect security maturity stage where every application should be. The information is targeted according to the user's professional profile and as far as it is a community document, it can receive contributions from everyone, so it can evolve. If you want to contribute, just submit it in this form.
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. As an alternative use community knowledge like OWASP, for example for Java, DotNet, or even Docker.
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.
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 teams' 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 not fixing it. Most important is to always report the vulnerabilities.
Handling exceptions in your application is not always an easy task. Mistakes in this process can lead to sensitive data leaking or unexpected and uncontrolled behaviours. Specific and detailed error messages can help attackers to know more about the system.
Stack traces and detailed error messages can show technical information about your environment or architecture. For example, “invalid username” or “invalid password” instead of “invalid login data” help attackers as much as it helps users.
Logging is one of the most important parts of troubleshooting and debugging, but it also helps in terms of auditing, intrusion detection, and forensics. Use an extensible logging framework that will help you to make the correlation in logs, so you can trackback any action. Don't forget to verify regulation and policies applying to sensitive data. Sometimes you can't log everything you want.
Before starting to code your application you must decide how to control the access to your system: who can access it and what features or data can be accessed (Authorization vs Authentication).
Retrofitting the access control after the application is built can be painful, so make sure to manage and control all the rules in a central server-side system/component instead of spread controls in the business logic, use only server-side data and rules, and deny access by default. Before accessing any resource, user authentication and authorisation must be verified. It's better to deny than to wrongly allow .
One of the key principles in development is to validate inputs, outputs, and processes. You should never trust the input. Validating data on the client-side is only useful to guide the user in terms of usability but it doesn't prevent someone "in the middle" - between client and server - from changing the data.
Validation between components, depending on the architecture and development methodology can also be in place. If there are components or libraries reused by several teams and it's not possible to control their development lifecycle, they should be treated as untrusted.
As access control should be implemented with a deny by default policy, validations should implement whitelisting techniques instead of blacklisting. Whitelisting will list all the allowed scenarios, excluding all other scenarios by default - so you don't forget to exclude any.
This recommendation is part of the OWASP Top 10 proactive controls, and deep-dived here in the OWASP Cheat Sheet for input validation, both good resources with several solutions.
Application security is not about common sense knowledge. It is a composite discipline with specific terms, complex processes, and many tools to help secure your development process.
If you don't feel prepared to secure your deliverables you should join the application security community, find tailored security training for your needs and spread this knowledge within your team.
Training is not only about attending sessions, but also being an active community member, researching for vulnerabilities and solutions and sharing this knowledge with your peers.
Every customer, market, or region can have specific regulations, laws, or policies. Before starting to build your application, make sure to verify the applicable policies and make sure your team knows every constraint that must be in place.
Sometimes people tend to look at security policies as "just something to bother us". However, keep in mind that a policy is just a compilation of the best security practices and guidelines applicable to a context, helping you to deliver more secure applications.
Non-compliance to relevant policies may lead an application to a situation where you can't deploy it to a productive environment, but worse than that, you will have to refactor features or even the architecture. In later stages of development, it can be painful. Not being compliant will not improve your self-image of competence.
These 10 steps for more secure applications address the essential aspects to look for when addressing application security. Maybe some of these aspects have already been met, but there is certainly room for improvement. The specific application you are delivering may need those steps to be adapted, so be aware of the context and the constraints and perform the changes needs. Remember: no one knows your application better than you do.
Application Security was not always a top priority when teams delivered software. In fact, it was only a concern when the application was about to go into production or in the event of an attack. As a result of organisations' digitalisation, processes became digital and applications more exposed to threats.
Over the last years, security has become one of the priorities in software delivery. 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.
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 is 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 creating strategies to protect their information systems.
Modeling 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, you 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: use the vulnerabilities form, or alternatively contact the Security Testing team or even the Application Security team.
Application security should not be a consequence but 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.
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...
Imagine having a tailored and targeted document with all guidelines and policies to help you deliver better software. This document already exists and we call it The Rule Book.
The Rule Book is an ever-evolving document compiling guidelines, standards, community knowledge, and code examples, reflecting the perfect security maturity stage where every application should be. The information is targeted according to the user's professional profile and as far as it is a community document, it can receive contributions from everyone, so it can evolve. If you want to contribute, just submit it in this form.
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. As an alternative use community knowledge like OWASP, for example for Java, DotNet, or even Docker.
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.
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 teams' 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 not fixing it. Most important is to always report the vulnerabilities.
Handling exceptions in your application is not always an easy task. Mistakes in this process can lead to sensitive data leaking or unexpected and uncontrolled behaviours. Specific and detailed error messages can help attackers to know more about the system.
Stack traces and detailed error messages can show technical information about your environment or architecture. For example, “invalid username” or “invalid password” instead of “invalid login data” help attackers as much as it helps users.
Logging is one of the most important parts of troubleshooting and debugging, but it also helps in terms of auditing, intrusion detection, and forensics. Use an extensible logging framework that will help you to make the correlation in logs, so you can trackback any action. Don't forget to verify regulation and policies applying to sensitive data. Sometimes you can't log everything you want.
Before starting to code your application you must decide how to control the access to your system: who can access it and what features or data can be accessed (Authorization vs Authentication).
Retrofitting the access control after the application is built can be painful, so make sure to manage and control all the rules in a central server-side system/component instead of spread controls in the business logic, use only server-side data and rules, and deny access by default. Before accessing any resource, user authentication and authorisation must be verified. It's better to deny than to wrongly allow .
One of the key principles in development is to validate inputs, outputs, and processes. You should never trust the input. Validating data on the client-side is only useful to guide the user in terms of usability but it doesn't prevent someone "in the middle" - between client and server - from changing the data.
Validation between components, depending on the architecture and development methodology can also be in place. If there are components or libraries reused by several teams and it's not possible to control their development lifecycle, they should be treated as untrusted.
As access control should be implemented with a deny by default policy, validations should implement whitelisting techniques instead of blacklisting. Whitelisting will list all the allowed scenarios, excluding all other scenarios by default - so you don't forget to exclude any.
This recommendation is part of the OWASP Top 10 proactive controls, and deep-dived here in the OWASP Cheat Sheet for input validation, both good resources with several solutions.
Application security is not about common sense knowledge. It is a composite discipline with specific terms, complex processes, and many tools to help secure your development process.
If you don't feel prepared to secure your deliverables you should join the application security community, find tailored security training for your needs and spread this knowledge within your team.
Training is not only about attending sessions, but also being an active community member, researching for vulnerabilities and solutions and sharing this knowledge with your peers.
Every customer, market, or region can have specific regulations, laws, or policies. Before starting to build your application, make sure to verify the applicable policies and make sure your team knows every constraint that must be in place.
Sometimes people tend to look at security policies as "just something to bother us". However, keep in mind that a policy is just a compilation of the best security practices and guidelines applicable to a context, helping you to deliver more secure applications.
Non-compliance to relevant policies may lead an application to a situation where you can't deploy it to a productive environment, but worse than that, you will have to refactor features or even the architecture. In later stages of development, it can be painful. Not being compliant will not improve your self-image of competence.
These 10 steps for more secure applications address the essential aspects to look for when addressing application security. Maybe some of these aspects have already been met, but there is certainly room for improvement. The specific application you are delivering may need those steps to be adapted, so be aware of the context and the constraints and perform the changes needs. Remember: no one knows your application better than you do.
Application Security was not always a top priority when teams delivered software. In fact, it was only a concern when the application was about to go into production or in the event of an attack. As a result of organisations' digitalisation, processes became digital and applications more exposed to threats.
Over the last years, security has become one of the priorities in software delivery. 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.
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 is 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 creating strategies to protect their information systems.
Modeling 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, you 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: use the vulnerabilities form, or alternatively contact the Security Testing team or even the Application Security team.
Application security should not be a consequence but 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.
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...
Imagine having a tailored and targeted document with all guidelines and policies to help you deliver better software. This document already exists and we call it The Rule Book.
The Rule Book is an ever-evolving document compiling guidelines, standards, community knowledge, and code examples, reflecting the perfect security maturity stage where every application should be. The information is targeted according to the user's professional profile and as far as it is a community document, it can receive contributions from everyone, so it can evolve. If you want to contribute, just submit it in this form.
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. As an alternative use community knowledge like OWASP, for example for Java, DotNet, or even Docker.
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.
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 teams' 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 not fixing it. Most important is to always report the vulnerabilities.
Handling exceptions in your application is not always an easy task. Mistakes in this process can lead to sensitive data leaking or unexpected and uncontrolled behaviours. Specific and detailed error messages can help attackers to know more about the system.
Stack traces and detailed error messages can show technical information about your environment or architecture. For example, “invalid username” or “invalid password” instead of “invalid login data” help attackers as much as it helps users.
Logging is one of the most important parts of troubleshooting and debugging, but it also helps in terms of auditing, intrusion detection, and forensics. Use an extensible logging framework that will help you to make the correlation in logs, so you can trackback any action. Don't forget to verify regulation and policies applying to sensitive data. Sometimes you can't log everything you want.
Before starting to code your application you must decide how to control the access to your system: who can access it and what features or data can be accessed (Authorization vs Authentication).
Retrofitting the access control after the application is built can be painful, so make sure to manage and control all the rules in a central server-side system/component instead of spread controls in the business logic, use only server-side data and rules, and deny access by default. Before accessing any resource, user authentication and authorisation must be verified. It's better to deny than to wrongly allow .
One of the key principles in development is to validate inputs, outputs, and processes. You should never trust the input. Validating data on the client-side is only useful to guide the user in terms of usability but it doesn't prevent someone "in the middle" - between client and server - from changing the data.
Validation between components, depending on the architecture and development methodology can also be in place. If there are components or libraries reused by several teams and it's not possible to control their development lifecycle, they should be treated as untrusted.
As access control should be implemented with a deny by default policy, validations should implement whitelisting techniques instead of blacklisting. Whitelisting will list all the allowed scenarios, excluding all other scenarios by default - so you don't forget to exclude any.
This recommendation is part of the OWASP Top 10 proactive controls, and deep-dived here in the OWASP Cheat Sheet for input validation, both good resources with several solutions.
Application security is not about common sense knowledge. It is a composite discipline with specific terms, complex processes, and many tools to help secure your development process.
If you don't feel prepared to secure your deliverables you should join the application security community, find tailored security training for your needs and spread this knowledge within your team.
Training is not only about attending sessions, but also being an active community member, researching for vulnerabilities and solutions and sharing this knowledge with your peers.
Every customer, market, or region can have specific regulations, laws, or policies. Before starting to build your application, make sure to verify the applicable policies and make sure your team knows every constraint that must be in place.
Sometimes people tend to look at security policies as "just something to bother us". However, keep in mind that a policy is just a compilation of the best security practices and guidelines applicable to a context, helping you to deliver more secure applications.
Non-compliance to relevant policies may lead an application to a situation where you can't deploy it to a productive environment, but worse than that, you will have to refactor features or even the architecture. In later stages of development, it can be painful. Not being compliant will not improve your self-image of competence.
These 10 steps for more secure applications address the essential aspects to look for when addressing application security. Maybe some of these aspects have already been met, but there is certainly room for improvement. The specific application you are delivering may need those steps to be adapted, so be aware of the context and the constraints and perform the changes needs. Remember: no one knows your application better than you do.
.png)
