Historically, IT
security was primarily focused on network and endpoint security. Now,
as the best practices of security begin to catch-up to the mounting
threats posed by new technology, application development and the SDLC are suddenly within security's remit. 
Whilst many organisations understand the need for improved application security, few are implementing their programs in an efficient and effective way. As a result, the vast majority of application security programs find themselves riddled with gaping holes - holes that can be readily exploited by software vulnerabilities and malicious third-parties.
To help you plug some of the most common gaps found in application security programs, we're looking at three strategies you can take action on today.
For example, many organisations create controls that dictate the need to 'protect cardholder data', 'follow industry best practice', or even 'prevent applications from being vulnerable to the OWASP Top 10 threats'. These types of high-level policies do nothing to help on-the-ground security implementation.
To prevent applications succumbing to OWASP's top vulnerabilities, a developer has to go through a whole plethora of steps:
Without a shared understanding of their respective roles and responsibilities, it's extremely difficult for the two teams to engage in an effective way. In many organisations, this creates an all-too familiar problem: security throwing a context-less report at the dev team, and the dev team struggling to make sense of false positives and vulnerabilities. It's this disconnect that creates security's bad reputation in many organisations - and prevents two crucial security advocates from following effective policy.
To prevent this problem, security and development teams need to be less centralised - using a formal feedback loop to discuss security findings, and outline ways to resolve them. In many instances, developers simply lack the knowledge required to remediate against vulnerabilities. In other cases, security struggle to make sense of the reporting tools, and end up generating a ton of recurring false positives (something which heavily contributes to the problem of shelfware).
By facilitating open discussion between teams, and mandating ongoing security training, both teams will be empowered with the knowledge and authority necessary to improve security.
To highlight this, a full 75% of executives believe their application security is at a mature state - proactively dealing with potential vulnerabilities before they become a problem. In stark contrast, only 23% of technicians at the same organisations agreed. Whilst 2/3 of budget holders thought their security investment was bearing fruit, only 1/4 of on-the-ground staff agreed.
This is perhaps the most important point to raise: to close the gaps in your application security pogrom, you first have to be aware of them. Security is an ongoing, iterative process - and a mechanism for constantly assessing and reassessing potential threats, and your response to them, is a vital part of improving your organisation's security.
Whilst many organisations understand the need for improved application security, few are implementing their programs in an efficient and effective way. As a result, the vast majority of application security programs find themselves riddled with gaping holes - holes that can be readily exploited by software vulnerabilities and malicious third-parties.
To help you plug some of the most common gaps found in application security programs, we're looking at three strategies you can take action on today.
1) Create Role-Specific Policies, Not Just General Policies
Codified security policies are an important first step in developing application security. However, creating a standalone policy isn't enough to help developers and security teams translate intention into action. In order to mediate the distance between policy and practice, it's essential to create role-specific versions of crucial security documentation.For example, many organisations create controls that dictate the need to 'protect cardholder data', 'follow industry best practice', or even 'prevent applications from being vulnerable to the OWASP Top 10 threats'. These types of high-level policies do nothing to help on-the-ground security implementation.
To prevent applications succumbing to OWASP's top vulnerabilities, a developer has to go through a whole plethora of steps:
- Identifying which threats to prioritise (e.g. injection threats)
- Isolating and prioritising individual threats (e.g. SQL injection)
- Learning about suitable countermeasures, and identifying which are most relevant.
- Discovering how to implement these countermeasures in a specific development language.
2) Create a Feedback Loop Between Security and Developers
These overly-generalised security policies create a serious disconnect between two essential components of application security: the development team, and the security team.Without a shared understanding of their respective roles and responsibilities, it's extremely difficult for the two teams to engage in an effective way. In many organisations, this creates an all-too familiar problem: security throwing a context-less report at the dev team, and the dev team struggling to make sense of false positives and vulnerabilities. It's this disconnect that creates security's bad reputation in many organisations - and prevents two crucial security advocates from following effective policy.
To prevent this problem, security and development teams need to be less centralised - using a formal feedback loop to discuss security findings, and outline ways to resolve them. In many instances, developers simply lack the knowledge required to remediate against vulnerabilities. In other cases, security struggle to make sense of the reporting tools, and end up generating a ton of recurring false positives (something which heavily contributes to the problem of shelfware).
By facilitating open discussion between teams, and mandating ongoing security training, both teams will be empowered with the knowledge and authority necessary to improve security.
3) Ask Technicians to Assess the Maturity of Your Application Security Program
The application security maturity model is a valuable tool for assessing your efficacy in converting policy into practice. However, many organisations take an unintentionally blinkered approach to assessing their application security - turning exclusively to their directors and executives for insight. However, directors aren't always best placed to analyse security - and often look to very different hallmarks of efficacy than those a developer would turn to.To highlight this, a full 75% of executives believe their application security is at a mature state - proactively dealing with potential vulnerabilities before they become a problem. In stark contrast, only 23% of technicians at the same organisations agreed. Whilst 2/3 of budget holders thought their security investment was bearing fruit, only 1/4 of on-the-ground staff agreed.
This is perhaps the most important point to raise: to close the gaps in your application security pogrom, you first have to be aware of them. Security is an ongoing, iterative process - and a mechanism for constantly assessing and reassessing potential threats, and your response to them, is a vital part of improving your organisation's security.
No comments:
Post a Comment