Why DevSecOps Should Strive for Effective Enforcement Measures

April 22, 2021

9102

This post is also available in: French German Italian Portuguese (Brazil) Spanish Russian

Talking to prospects teaches you more than reading market research. Recent customer engagements (unfortunately still virtual) made it loud and clear – businesses need effective security.

1. Defining Effective Security

There’s no need to reinvent the wheel every time. Modern application development, delivery architectures, and framework allow maximum flexibility to R&D teams. Also, off-the-shelf services, modules, and functions are available for simple integration. However, there’s one issue that complicates it all – the need to secure the availability of the application, and the integrity and confidentiality of its data.

Shopping for security solutions is easy –buy whichever technology addresses the threat(s). Managing it is where it gets more complicated. First and foremost, the advantages rebalance the scales between security and productivity to Dev teams. With that in mind, enterprises enjoy faster release cycles and time to market new capabilities at a reduced cost, giving more influence to Application Development and Delivery (AD&D) personnel over security-related decisions. Effective security has to be a part of your playbook. In other words, don’t break anything, and introduce no disruption and no slowdowns.

2. “Effective” Security Has To Detect

There are different approaches to integrate application protection technologies into the CI/CD pipeline. Each is trying to overcome the need for speed and minimize the impact on the environment – be it latency, resource footprint, or workload costs. In most cases, there are at least one of two deficiencies in ‘dev friendly’ approaches:

i. The solution does not cover the complete attack surface

ii. The solution does not actively apply security enforcement

i. Threats to applications today go beyond exploiting code and logic vulnerabilities – which are already more than enough to analyze and cope with. Keeping track of known vulnerabilities, the latest authentication and authorization protocols, and different ways to hack them is already an enormous enough task.

Applications today – especially in modern development environments – extensively use APIs to share and consume sensitive data, which are just as vulnerable and require dedicated surgical technology to make sure there is no token abuse, excessive utilization, or data theft using injections.

Other than API security Many services rely on integrating or serving bots and need to make a clear distinction between the good bots and bots with malicious intent. For the sake of being accepted by AD&D, RASP (Runtime Application Self Protection) is vulnerable to some attacks denial of service is just one example.

ii. From a DevOps point of view, applying security enforcement is risky. It can affect the user experience or maybe even break the flow, leading to runtime errors. The software development lifecycle (SDLC) has many blind spots in security, especially in today’s hybrid, multi-cloud architecture. For this very reason, many technologies provide alerts which is great.

3. “Effective” Security Must Secure

There is some fatigue from tools that only provide visibility. Automated security testing, vulnerability scanners of webservers, Operating Systems, and even container images come short on actual enforcement, making the developer take a few steps back and patch. When such alerts come in mass, it is much harder to prioritize and address them all.

A released version is water under the bridge for development teams until that moment when a security staff member comes and tells you to patch this vulnerability. If you can detect it- block it. Just remember to detect the full spectrum of threats. Nobody wants too many point solutions because it doesn’t necessarily result in a more robust security posture.

4. “Effective” Security Has To Remain Effective

The dynamic nature of an agile SDLC with frequent changes and updates to the app daily, can make security policies less accurate by the day. This process is unscalable and requires an FTE to work on rule updates, whitelisting, and exception handling.