This article is more than 1 year old
Continuous security and compliance for hybrid cloud, the Red Hat way
Tune in, turn on, run in the background, using Red Hat DevSecOps framework
Paid feature Assessing what can go wrong in a hybrid cloud environment can be daunting. Applications can be poorly coded, security vulnerabilities may be present but hard to detect or manage, and applications and the IT infrastructure may not be designed for DevSecOps.
Security layers designed to shield them can be misconfigured or not exist at all. Perhaps a developer or IT operations misunderstands and blindly trusts the default controls on a cloud platform and leaves valuable data exposed, and that’s before factoring in the danger from shadow IT.
It’s not that developers or employees are always being willfully careless - mistakes are inevitable in a complex IT environment. But human errors have become a big enough issue that Gartner has estimated that between now and 2025 “99 percent of cloud security failures will be the customer’s [rather than the service provider’s] fault.”
That might sound like an exaggeration today but there’s no doubt the rise of cloud and hybrid cloud have expanded the number of points of failures. Meanwhile, in the background is the troubled issue of maintaining compliance, and the need to dodge either delays to projects while software is fixed or fines for breaches after the fact.
Continuous compliance in a cloud world
Security controls are safeguards or countermeasures that organizations utilize to avoid, detect, counteract, or minimize security threats. Unfortunately, cloud compliance has always been a complex process and keeps becoming more so. The number of security controls that organizations must take account of is growing and their demands are becoming more onerous across multiple geographies.
In addition, many compliance frameworks were created 20-plus years ago and have older compliance requirements that do not apply to new cloud technologies (containers, Kubernetes, public cloud, etc.). Many of these older compliance frameworks assume that you are doing the security work after the server is deployed, and therefore focused on things like patching, vulnerability scanning, etc.
However, in a cloud environment, you have an immutable infrastructure so once you deploy, you don’t make changes. If changes are needed, you re-deploy vs directly change the systems. Security work that needs to be done is done before deployment (at the application lifecycle pipeline).
Compliance has become so demanding in cloud deployments that many organizations have moved from manual security checks to procedures based on continuous automated monitoring and compliance, notes Lucy Huh Kerner, Red Hat’s Director of Security Global Strategy and Evangelism.
This makes sense. Too many things change, not only between audits but from day to day and hour to hour. Misconfigurations and human errors can strike at any moment. Continuous security and compliance are how these issues can be prevented for better security and not merely for “check-the-box” compliance. Compliance is expensive and difficult but so too is non-compliance or real-world breaches.
“A lot of security checks in compliance frameworks were written 20-plus years ago and assume you are securing the system after the fact, once it has already been deployed,” says Kerner. But a lot of compliance controls from this long-ago era don’t apply to cloud technologies or take DevSecOps practices into account.
“You can’t deploy some of the recommended controls in a cloud or containerized immutable infrastructure,” says Kerner. “For example, a common recommended security control is to install third party security agents, such as anti-virus. However, in a containerized environment that is immutable, these types of policies don’t make sense.”
Therefore, security teams need to educate the compliance teams and auditors that this ‘defend the castle’ perimeter based security model is no longer sufficient and may not apply in an immutable cloud environment. Organizations also need to automate their continuous security and compliance to handle the scale that cloud technologies bring to detect and fix issues in an automated and repeatable way. Done properly, continuous security and compliance should be a constant iterative process of detecting and fixing issues rather than manually detecting and fixing issues in a reactive way.
Compliance-as-code for consistency, repeatability, and compliance at scale
The whole objective of continuous security and compliance is to minimize manual processes because these slow everything down. The question is how to make this work using automation, continuous integration/continuous deployment (CI/CD), and DevSecOps practices. This has given rise to the compliance-as-code concept which turns the prevention, detection, and remediation of non-compliance into a programmatic, automated process for consistency and repeatability to do security and compliance at scale.
At Red Hat, the ComplianceAsCode upstream project is used to codify and create security policy content for various platforms as well as products. Using this content, provided as both Security Content Automation Protocol(SCAP) and Ansible content, you can do automated security scanning and remediations for both compliance and vulnerabilities.
OpenSCAP, which is included in a Red Hat Enterprise Linux subscription, can perform compliance and vulnerability scanning on Red Hat Enterprise Linux systems and help teams identify and remediate problems as they crop up. OpenSCAP is a SCAP compliant scanner. SCAP scanners are driven by several different industry policies, profiles, and rules.
The SCAP Security Guide, which is based on the ComplianceAsCode project, includes Red Hat’s interpretation of the policies, rules, and related Ansible playbooks for remediation to facilitate automation of configuration and auditing.
Because this is integrated into Red Hat products, OpenSCAP allows for vulnerability and compliance from the get-go, right from when the system is first installed. In addition, scanning for a compliance standard is not just a one-off task. You need to scan your systems regularly to ensure that you are maintaining compliance with the standard and any deviation from the policy will need to be remediated.
With OpenSCAP and Red Hat Ansible Automation Platform, you can automate security and compliance scans and remediations at scale in hybrid environments. This means that you can use OpenSCAP using several products in Red Hat’s portfolio, including Red Hat Ansible Automation Platform, Red Hat Smart Management with Red Hat Satellite, and Red Hat Insights to scan across your deployment portfolio.
“Just as you’ve made an automated pipeline to create your applications, you need to embed compliance automation into your lifecycle,” says Kerner. “You don’t want to be carrying out checks and remediations manually since this will lead to human errors.”
You are using automation to save time and effort while removing human errors from the equation.
“And you want to automate not only the compliance and security checks, but you want to automate the remediations of these issues as well,” stresses Kerner. “The big thing the auditors want is for organizations to prove that their systems and applications have passed those security and compliance checks.” Logically, this must be done on a continuous basis rather than at the point of deployment at which point checking and fixing things becomes a major undertaking.
“The customer can use the OpenSCAP tool to scan all their Red Hat Enterprise Linux systems for vulnerabilities and compliance, while also getting scan reports for audits and Ansible playbooks for remediations.”
Since acquiring StackRox in early 2021, Red Hat now also has the ability to carry out Kubernetes cluster-wide compliance. Red Hat Advanced Cluster Security, powered by StackRox technology, will assess compliance across hundreds of controls for Center for Internet Security (CIS) benchmarks, payment card industry (PCI), Health Insurance Portability and Accountability Act (HIPAA), and NIST SP 800-190.
It will deliver at-a-glance dashboards of overall compliance across each standard’s controls with evidence export to meet auditors’ needs. In addition, it will provide a view of compliance details to pinpoint clusters, nodes, or namespaces that don’t comply with specific standards and controls across your Kubernetes clusters.
The world Kerner outlines is one in which robot sysadmins and automation do almost everything and humans are only engaged to oversee the admin function or to deal with unusual exceptions. Compliance and security are simply turned on all the time, running in the background.
Sponsored by Red Hat.
Biting the hand that feeds IT
