Why Prevention Beats Remediation – InApps 2022

Prevention is top of mind for many this new year, as we eagerly await the rollout of the COVID-19 vaccine. As it is in the healthcare sector, we know that the most powerful tool to defend against threats is to prevent them from starting in the first place.

Consider the precautions implemented by airports. While it may feel like years since any of us have ventured through an airport security line, and it might be a while before we do so again, there is already talk of airport security including some form of rapid COVID-19 testing — based on the premise that prevention is better than any cure.

Applying that principle to security, it is interesting to think about how we view the security of our applications. Runtime security essentially involves deploying applications that may or may not be at risk, while concurrently running complex and costly agents in an attempt to (possibly) mitigate the risks.

What if security and development teams shifted their mindsets to address the possibility of deploying applications that are built to minimize risks? What if we configured applications in a way that removed bad packets and the need for packet filtering?

The concepts around shifting left have been around for years, but not all organizations have been quick to adopt them. Here are four reasons why your organization should adopt shift-left security practice:

Lower Your Risk Level

In a traditional “detect & remediate” mode, there is an inherent lag between deploying an application and remediating any detected vulnerabilities. Many security organizations are sophisticated enough to detect vulnerabilities or breaches, but it takes an additional costly level of expertise to remediate. Whether the remediation entails additional security vendors or attention from internal stakeholders with specific expertise, any lag will come at cost.

Align All Stakeholders Towards Timely Deliveries

In prevention mode, an organization cannot deploy an application without it being built with security in mind. Everyone’s priority becomes security-centric code. This is in total contrast to the “detect & remediate” approach; where once an application has been deployed, it is the security organization’s responsibility to gather the necessary stakeholders to plan and execute the remediation process. Prevention allows us to engage and align all stakeholders within an organization before deployment.

Reduce Costs

Can you quantify the disruption involved with fixing something that has already been deployed? The time and resources it takes to test, re-deploy and communicate the fix with your customers? Remediation always involves disruption and that is just not good for business. By lowering the overall disruption imposed on organizations and customers, a prevention approach enables enterprises to optimize all of their resources. Too many security organizations have to pick their battles in the current status quo, by configuring thresholds in order to maintain production levels. It is faster and more cost-effective to write code that is secure, to begin with. Rather than having a developer fix something post-deployment, it is much more efficient for the DevOps team to tweak code so that the application will pass security checks.

Lower False Positives 

When logic is applied to the application in staging, customers remain un-impacted. This is because over-zealous blocking has ceased — reducing the number of false alerts (better known in the industry as “false positives”) and its related costs. Blocking too enthusiastically on a live application means that too many customers will be impacted with interruptions to chase until someone creates an exception to the rules. With logic, AI and ML are combined with customer exceptions to provide better outcomes and highlight the alerts that matter.

Conclusion

It’s no secret that in a cloud environment more of your risk comes from configuration mistakes (bad code or network configurations). Many vulnerabilities exist because of the lack of synergy between DevOps and security, and the subsequent misconfigurations.

Detection after the fact is an important first step, but now is the time to figure out how much you can understand about the security of your code — and leverage tools — before you deploy and shift the code into your pipeline.

Feature image via Pixabay.