Security has been a challenge in the DevOps environment, even when many IT companies have embraced unique models like DevSecOps. This model integrates security and QA teams along with development and operations teams throughout the application lifecycle.
While DevOps may solve many challenges that exist in the software development process, it is not completely a foolproof approach to use as is, out of box; for example, it may not solve or rather may bring in newer new security challenges for the industry.
Left Shift of Security
The DevOps culture of continuous application creation, delivery and updates seems to be the perfect solution at first glance. However, from the perspective of security organizations and teams, this model complicates rather limits code analysis and adherence to other security routines before application deployment.
The exciting thing is that DevOps has an opportunity built into it to get security right. Teams can introduce security during the early phase of the development cycle, thus getting the chance to address issues from the very beginning. The traditional approach to software development follows a left to right path. It includes planning followed by coding, testing, and eventually, deployment. Security comes into the picture close to the deployment stage. It is anchored onto the code instead of being integrated from the beginning.
DevOps allows shifting everything to the left. Thus, security tasks can be moved to the left within the application development process.
Also Read: What does 2020 look like for DevOps?
The ASBA Approach
Recent developments have led to the creation of a new approach to cloud workload protection and monitoring. This new approach is known as Application Security Behavior Analytics or ASBA. There are 3 key components to this new approach to address the security challenges in the application:
1. Real-Time Application Behavior Profiling
Business applications usually have similar behaviors and communications with other entities. For example, an e-commerce application may look almost like an ERP software. Both applications involve synchronized activity between caches, web servers, databases, and load-balancers. There may be interconnected applications, web, and database servers all having correlated behaviors. For example, an increase in database activity may be connected with an increase in application server activity.
But there is a significant behavioral difference between an ERP and an e-commerce application. ERP is accessible only to users on a LAN, not on the internet. However, attackers with malicious intent usually don’t care about these meticulous behavioral characteristics. They think that once the enterprise security is breached, they will not be detected. And this is what usually happens.
The ASBA approach is capable of discovering crucial anomalies. For example, it can detect an anomaly involving a database that has become busy when the front-end server remains idle. Any deviations from the standard baseline may be a sign of malicious attacks, including those from inside or outside. It may be a sign that the network has been accessed from an unusual or unrecognized location and at unusual hours. This approach can detect such incidents in the real-time, facilitating quick response, automated remedy, and forensic investigation.
The new system profiles the behavior of applications to create a foundational model of regular activity. This helps detect anomalous activities and potential threats. This is done by monitoring almost endless parameters against each workload which includes their processes, relationships, dependencies, and temporal fluctuations. This data is then compared with data sourced from other workloads.
2. CI/CD & SDLC Security Monitoring
An increasing number of organizations using digital information are using new and innovative development techniques. However, as part of the process, they usually expose themselves to new potential threats by creating new openings of a security breach.
CI/CD works by accessing an organization’s IP. Unfortunately, it doesn’t have a dedicated security cover. However, it needs protection against insider threats, process leaks, and external attackers. CI tools are quite capable and are effective in automating development functions such as workflows, promotions, quality gates, and defect tracking, amongst others. Any attack or failure can mean the organization can suffer massive damages.
A breach or failure in the CI toolchain can stop software development activities and prevent recovery of services that may have failed. This is where the ASBA approach can help enhance security and fix potential loopholes. It can profile, identify, alert, and diminish failures or loopholes in the toolchain. It can do the same for the processes delivered by the toolchain before significant damage is inflicted.
ASBA monitors different elements which includes anyone or any system that may have gained access to the source repository. It can also monitor those who may have pulled from the CI/CD tool, where changes may have been made to the workflow. ASBA is also capable of providing forensic data and eventually blocks any unwanted and unauthorized activities.
When third-party code is used in the development, it creates another kind of security risk. The threat becomes even more profound when open-source components are included. The combination of vulnerabilities within the code and dependency trees with the inefficiencies of scanners in detecting flaws, causes a significant increase in security risks.
The new ASBA approach creates effective protection through the detection of behavior anomalies. It provides this defense without concern for the technique used for the attack.
Development teams may use test-driven development (TDD) on a routine basis for automating software testing. Yet very few teams embrace required security validation. Very few product teams assess the implementation of code, APIs, and artifacts from the security perspective before release. Code quality and analysis have been evaluated for their security advantages and they cannot be relied upon entirely.
The new approach can develop a system of crucial feedback loop. This can increase security within the validation stage.
3. Run-Time Security
In an ideal world, a deployed software includes all security lessons learnt during the process of development and testing. However, in the real world, this is hardly ever the case. ‘Testing during production’ is usually the norm in the DevOps environment. However, it is nothing more than a maxim because deployment operations, architectures, scale and other elements during production stand apart from each other. This distinct nature of each element increases further after A/B and other tests, deployment, and operations.
Also Read: Performance Testing Within DevOps Practices
ASBA helps in addressing the vast gap that gets created between application testing and deployment. It provides insights as part of the feedback system, leading to optimization of reliability engineering. This makes it easier to achieve service-level goals.
ASBA offers answers that are actionable and prevents the need to query unstructured data. This is made possible because of the real-time alerts and forensic auditing potential of this approach. This is a big step forward from the conventional application performance management solutions. Hence, there is the visibility of potential risks through the entire SDLC. This is also the case during the deployment and operation of the application.
The Need to Bridge the Communication Gap
While this new ASBA approach is meant to plug most of the security loopholes in DevOps, it is also essential for security practitioners to bridge the communication gap existing between the security team and the other teams within the organization. Even today, security is mostly an afterthought, largely due to the lack of understanding and awareness amongst teams.
As the world continues to move towards DevOps, security teams must point out and elaborate on their concerns in a language that is readily understandable for the operation and development teams.. It is recommended for security teams to emphasize the priorities of the development and operations teams and also help them align with the jargon they use. When the security team understands what the other teams care about, they can contribute to the latter’s success too
Security Threats – The Scenario
Security breaches can cause much more damage than just affect the operations in the short-term. They can also cause long-term and expensive disruptions. The 2017 Uber breach incident is a perfect example here. A developer had mistakenly published credentials on a popular software development hosting service. Even when this was a mistake that was common during the process of code compilation within the agile development environment, hackers were quick to fabricate a breach that affected more than 50 million users and 0.6 million drivers.
So what can the DevOps community do in addition to following the new ASBA approach to enhance security? A highly secure DevOps environment should run on separate tools, policies, and processes to enable secure and quick releases. The security breach mentioned above could have been thwarted, by a final security scan which detected any embedded credentials within the code.
When all these approaches come together, it can create an almost impenetrable environment for software development, deployment, and management. Significant developments are taking place in the DevOps environment in terms of security enhancements. This makes it easier for more organizations to embrace this model in the near future making the digital world not just experience rich but also safe and secure