Author: Hillel Solow, Cloud Security Architect and Evangelist, Check Point Software Technologies
Prevention of risk is top of mind for many in both our personal and professional lives. This holds true now more than ever with not only the covid-19 pandemic but also the proliferation of attack vectors targeting our personal and business information.
The questions then becomes, how do we consider the “prevention is better than cure” approach when thinking about the security of our applications? In general, runtime security 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 built to minimize risks? What if we configured applications in a way that removed bad packets and the need for packet filtering?
These concepts have been around for years, but not all organizations have been quick to adopt them. Here are four reasons why your organization should adopt a security practice based on prevention rather than detection:
1. Lower your risk level
The traditional “detect & remediate” model is limiting because there is an inherent lag between deploying an application and remediating any detected vulnerabilities. While many security organizations are sophisticated enough to detect vulnerabilities or breaches, it takes an additional costly level of expertise to remediate them. With so many tools on the market, organizations often lack employees who proficient in a specific platform or tooling. Whether the remediation entails additional security vendors or attention from internal stakeholders with specific expertise, any lag will come at cost of hiring the right expert or finding the right tool.
2. 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 a total contrast with 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 the engagement and alignment of all stakeholders (i.e. security, compliance, development) within an organization before deployment.
3. Reduce costs
Imagine 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. At the end of the day, remediation always involves disruption and that’s 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 had to pick their battles in the current status quo, by configuring security 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 the application passes security checks.
4. Lower false positives
When logic is applied to the application in staging, customers remain un-impacted. This is because overzealous 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, until someone in security creates an exception to the rules.
With logic, Artificial Intelligence and Machine Learning are combined with customer exceptions to provide better outcomes and highlight the security and compliance alerts that matter.
It’s no secret that in a cloud environment more of your risk comes from configuration mistakes such as bad code or network configurations. Many vulnerabilities exist because of the lack of synergy, and subsequent misconfigurations, between DevOps and security.
It is important for these teams to Shift Left and develop tooling and templates that apply the security and compliance parameters needed early in development, have them scanned throughout the lifecycle, and remediate any gaps—automatically.
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.