Corporate Cloud Compliance
Cloud compliance is difficult and scary; how do you do it? How are you able to comply with all the regulations on your plate when hosting with Amazon or Rackspace? This article will teach you how.
Join the DZone community and get the full member experience.Join For Free
How many times have you finished a 1,000-piece puzzle? How about a serious game of Monopoly? Both of these activities have parallels with the process of meeting compliance regulations.
Even a solid strategy and a lot of patience won’t get you far — you may even find yourself wanting to give up.
Puzzles and Monopoly are games, of course; Compliance Regulations are real life. And there’s a huge difference between the two. For many companies, attaining compliance and passing audits is non-negotiable — operations, systems, and security professionals (as well as other stakeholders) don’t have the option of giving up. But understanding and abiding by the extensive list of requirements — whether it’s for HIPAA, SOX, ISO, SOC 2, or any of the other compliance matrixes in use today — can seem like a major hurdle.
Well, here’s the good news: The task becomes a lot more logical and manageable when an integrated security platform like Threat Stack is incorporated into your operations. In addition to providing comprehensive cloud security, Threat Stack also drives a process that addresses each of the three key areas (see below) that underpin most major regulatory standards — thereby enabling a straightforward framework for meeting compliance in the cloud. Threat Stack also automatically establishes the audit trail that supports internal controls, procedures, and reports that are needed to meet compliance regulations.
The three areas I just referred to are:
- Continuous Monitoring (to ensure you are capturing data relevant to your auditing requirements in a reliable manner)
- Vulnerability Management (so you can understand where risks lie in your environment and report on their acceptance or remediation)
- Reporting (to provide a current picture as well as a historical view of events and data)
Continuous Security Monitoring
Continuous monitoring of activities such as user logins, third-party service activity, workload activity, and modifications to data, acts as an early warning system to detect security incidents and also pinpoints non-compliant behaviors. It serves as a strong form of validation that your prescribed or self-prescribed controls have been implemented across your entire environment.
Monitoring generates real-time data about what is happening in your environment, which is a basic requirement for just about every security compliance regulation — from HIPAA to PCI DSS to ISO 27001 and more. It provides intelligence from deep within systems to help security professionals and those responsible for audits understand who did what and when in their environments, with their customer data, and whether this action was typical or according to policy.
More specifically, it details the who, what, where, when, and how of compliance events, including:
- Unauthorized exposure or modification of data and configurations
- Activity at the operating system, application, and database levels
- Access control incidents
- New user creation or user deletion
- User modification, such as password resets
- Installation of software, especially outside of standard workflows (build pipeline)
- ...and much more
Another critical component is understanding when key files are accessed or modified. In other words, File Integrity Monitoring (or FIM), allows you to validate whether there have been unauthorized modifications to critical system, configuration, or content files. With FIM in place, compromises can be detected the moment file activity deviates from the norm, and therefore it is considered a best practice that all companies should implement. For example, FIM will track and alert when users access private SSL certificates — especially if the user touching them isn’t the web server.
One common auditing requirement is to know every piece of software that is installed in your environment, including third-party dependencies, and whether any of them have known vulnerabilities (e.g. CVEs). Threat Stack assists in meeting these requirements by analyzing all the software installed in your environment, comparing it to a database of known vulnerable software.
This is especially important in a “trust but verify” world where smaller development-focused teams are continuously pushing updates into the production environment. Even if your organization employs a robust build pipeline as a control choke point for software deployments, you still need to effectively monitor your environment to determine whether unexpected (third-party) workloads are being introduced, and whether they are known to be vulnerable.
Vulnerability Management should be a fundamental component of your overall security strategy, of course, but it also contributes significantly to meeting compliance requirements.
Real-Time Reporting, Historical Records & Retention
Complete records are integral to strong security and all compliance systems. Throughout this post, we’ve seen that real-time reporting is critical to the capture of activities that could be a security concern. With Threat Stack, these records form a continuous timeline that allows you to view events leading up to a compliance or security incident, the incident itself, and activities leading out of the incident. This gives incident handlers and after the fact auditors a much more complete picture of what really happened than is possible with other systems, such as log analysis tools. As a result, attesting to meeting controls effectively becomes a continuous process as well since it’s built on top of continuous monitoring.
The retention of these records and events is just as critical as obtaining them. Most compliance regulations, including SOX, PCI DSS, and SOC 2, dictate that security event and alert information be held for an extended period of time. For some, this period can be as short as 30 days; others require several years.
Often it is a requirement to store this data in an independent repository that is separate from your own environment, so that no matter what happens to the data on your servers, the reports stay intact for regulatory and investigatory purposes. While Threat Stack’s Cloud Security Platform™ can be that retention and reporting tool, some users wish to also maintain their own archive of alerts, either for compliance or security reasons. Any organization can achieve this simply with Threat Stack’s webhooks API, piping relevant alerts into any secondary platform of choice (AWS S3, a SIEM, etc.).
Implementing the Compliance Framework
Together, the three areas outlined above ensure a strong compliance and auditing story based on a comprehensive management framework. Not only do you have a single window into your data, systems, and users, but also you have the ability to remediate quickly, based on automatically generated, contextualized data. And following remediation, extensive data files enable “replays” of incidents for further analysis, identification of most at risk areas, and continuous improvement.
To summarize, the framework ensures that you have a roadmap to follow and enables you to satisfy the main requirements that are common to all major compliance systems through:
- Continuous Monitoring: attaining continuous telemetry and insights by monitoring deeply within and throughout your systems to ensure integrity of data and systems
- Vulnerability Management: acting swiftly to restore integrity when deviations or lapses occur, understanding when unexpected workloads pop up or build pipelines are circumvented
- Reporting: using current data to verify the status of data and systems and to aid in analysis and remediation; maintaining historical records
For more guidance on building out your company’s compliance strategy, set up a call for a quick Threat Stack demo and a discussion about your approach to cloud security and compliance.
Published at DZone with permission of Sam Bisbee, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.