Why DevSecOps must strive for effective enforcement measures
Talking to prospects teaches more than reading market research. Recent customer engagements (unfortunately still virtual) made it loud and clear — businesses need 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, one issue 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 the new tech gets more complicated. First, the advantages rebalance the scales between security and productivity to development 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 the playbook. In other words, don't break anything, and introduce no disruption and no slowdowns.
'Effective' security has to detect. There are different approaches to integrating application protection technologies into the CI/CD pipeline. Each is trying to overcome the need for speed and minimise 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:
1. The solution does not cover the complete attack surface
2. The solution does not actively apply security enforcement.
Threats to applications go beyond exploiting code and logic vulnerabilities which are already more than enough to analyse and cope with. Keeping track of known vulnerabilities, the latest authentication and authorisation protocols, and different ways to hack them, is already an enormous task.
Applications today, especially in modern development environments, use APIs extensively to share and consume sensitive data, which is just as vulnerable and dedicated surgical technology to make sure there is no token abuse, excessive utilisation, 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, runtime application self-protection (RASP) is vulnerable to some attacks — denial of service is just one example.
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.
'Effective' security must secure. There is some fatigue from tools that provide visibility alone. Automated security testing, vulnerability scanners of web servers, operating systems, and even container images fall short on actual enforcement, making the developer take a few steps back and patch. When such alerts come in mass, it is far harder to prioritise and address them all.
A released version is water under the bridge for development teams until a security staff member tells them to patch a 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.
'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.
