Putting Security on Par with DevOps

Source- darkreading.com

DevSecOps: It’s not a very friendly acronym. It reeks of techno-babble, sounds a little military, and resists a consumer connection. But think again. This is a vital discipline that’s directly relevant to every enterprise and every individual, particularly within cloud infrastructures, and has long deserved greater attention.

Maybe that’s why we’re now seeing greater research and more discussion devoted to the subject. But what’s really at stake here? And what needs to happen next?

First, let’s understand the context. Cloud computing has transformed the way organizations create and manage digital services, and that includes a big change in how software is developed and deployed. DevOps was designed to break down silos among development, quality assurance and IT operations, and speed innovation in the process. This meant teams outside the IT orbit took control, and the always-on public cloud certainly helped.

But there was one little hiccup — as lines around ownership and accountability got blurred, security got left behind. Flexibility, yes; competitive advantage, sure; innovation, absolutely. Protection? Not so much. So, moving forward here’s a blueprint for gaining security without compromising productivity.

DevSecOps is nothing more — and nothing less — than the process of uniting the two main stakeholders, DevOps and security, in a spirit of collaboration. Many organizations have multiple DevOps teams, especially with multiple business units. That’s why it’s important for the security practice to own the cloud security program, which can encompass uniform monitoring and central visibility across all public cloud environments.

Another obstacle here is that DevOps is heavily automated, which is a good thing, while many aspects of traditional security involve manual audits. If DevSecOps is to work, security must be similarly automated, but professionals in this field worry that this will give rise to endless alerts. However, there have been major advances, and solutions are available to implement a fully automated security workflow that not only detects alerts but greatly eases the immediate resolution of key issues.

With that as the foundation, here are some best practices to build upon.

Automatic Discovery
Public cloud environments are constantly changing — that’s actually a major advantage —and it’s not feasible to manually audit the entire landscape for assets.

• Resource discovery: Discover cloud resources as soon as they’re created, modified, or terminated. An API-based approach for automated discovery is more scalable than an agent-based approach; some types of cloud resources don’t allow agents to be installed, which creates blind spots. This is especially important as organizations increasingly adopt serverless computing (e.g., AWS Lambda).
• Application profiling: Discover which applications are running on the hosts to better assess risk. For example, knowing that a publicly accessible host is running MongoDB software with a known vulnerability indicates higher risk than, for example, a publicly accessible web server with no vulnerabilities.

Automatic Threat Detection
The threat vectors in public cloud environments are the same as those in on-premises environments, but the approaches to detecting them are different.

• Risky configurations: Establish baseline configurations for cloud resources based on industry standards such as CIS, NIST, or PCI and automatically flag any deviations. For instance, an alert should be triggered if a user exposes a cloud storage service to the public.
• Vulnerable hosts: Correlate feeds from third-party vulnerability management tools with cloud data sets such as configurations, network traffic, etc. This helps pinpoint vulnerable hosts within an environment and offers the opportunity to prioritize the hosts for patching based on the severity of the risk. For example, it’s more important to patch hosts that are exposed to the Internet because they’re easier to exploit.
• Suspicious user activities: Baseline each user’s activity to establish “normal” behavior, which makes it easier to spot anomalous patterns. This will highlight threats such as intrusions via compromised user accounts, or even insiders acting maliciously.
• Network intrusions: Correlate network traffic data with data from your public cloud environment and third-party threat intelligence to detect suspicious activities. This detects threats such as cryptojacking, where attackers use organizations’ computing power to generate cryptocurrency.

Automatic Response
Once any risks are detected, they need automatic or immediate remediation.

• User attribution: Instead of inundating security teams with more alerts (they suffer from alert fatigue anyway), these should be routed directly to the responsible user. Besides dealing with the problem itself, this cuts down on unnecessary communication between security and DevOps. To be clear, this only works if the system can identify the responsible user, which requires an audit trail of user activities.
• Contextual alerts: Alerts must provide enough context to help the responsible user understand the risk and take appropriate action. For example, a security group that’s open is a problem, but not necessarily the highest risk. By contrast, knowing that an open security group is associated with a database that’s receiving traffic from a suspicious IP address definitely is a high risk and needs immediate remediation.
• Workflow integration: The alerts should be automatically sent to workflow management tools for further investigation or orchestration of the fix. This enables organizations to leverage existing workflows and playbooks.

Again, the fact that DevOps has crashed barriers and demolished silos, all to speed development and deployment, is a good thing. It’s time that security kept pace — and the tools to do that are now available.