Continuous monitoring in the cloud: Two steps to make it a reality
Limited Time Offer!
For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!
Source – searchcloudsecurity.techtarget.com
When automating and orchestrating security controls for DevOps deployment pipelines, security teams need to secure source code and build processes and promotions to cloud environments.
Once systems and applications are running in the cloud, security teams also need to ensure a continuous monitoring feedback loop is in place for all the assets running in cloud provider environments. This has caused a number of issues for many organizations due to the lack of tool maturity or availability for performing monitoring, intrusion detection and reporting in the cloud. However, this is changing rapidly, and many teams are finding that they can implement a wide range of controls and automate prevention, detection and response in many cases.
Continuous monitoring in the cloud consists of two core elements. First, security teams need to implement baseline monitoring and logging for virtual machine instances, containers and cloud services in general, including activity within software-as-a-service environments. Baseline monitoring can be accomplished by gathering and processing logs made available via cloud service provider APIs — such as Amazon Web Service (AWS) CloudTrail logs — gathering specific instance logs, performing image and instance integrity validation to ensure the environment is sound, and gathering any networking logs that may be available, such as flow logs for virtual private clouds in AWS.
A number of tools for storing and monitoring logs are now available through Microsoft Azure Security Center or with AWS Lambda and AWS Config.
AWS Config is a highly capable engine for generating excellent quality monitoring data. AWS Config can be set to monitor configuration changes and to track when specific types of events occur. You can also monitor historical events and configuration status over time. AWS Config is an excellent part of a robust monitoring strategy in AWS, since you can track changes to many major service configurations and asset configurations over time and send detailed notifications via a number of methods to security and operations teams.
For security teams, the key to implementing continuous monitoring for cloud assets is integrating the appropriate monitoring controls into software-defined configurations and templates early in the process. For example, any system instances should include installed agents or boot/install scripts that install and run local security agents and tools when the system comes online.
There are several commercial options for this kind of local host control, including security-as-a-service platforms like CloudPassage and Dome9. These tools rely on lightweight agents to configure, control and monitor all cloud instances through a cloud-based portal.
Security Monkey, an open source tool developed by Netflix, can do many of the same things. Security teams can configure a policy to apply to all instances via the agent or service, which then monitors the systems for all changes or activities.
Vulnerability scanning
The second requirement for continuous monitoring in the cloud is scanning within the cloud for vulnerabilities. Any scanning tools used in the cloud should integrate with cloud provider APIs — meaning the scans are preauthorized through account and API integration — enable detailed scheduling and provide simple ways to export results that can be analyzed with monitoring tools both in the cloud and in the on-premises data center.
Most vulnerability scanning vendors, such as Tenable, BeyondTrust, Qualys, Rapid7 and others, have adapted products to work natively in cloud environments, and these scanning tools can be scheduled to scan cloud assets on a frequent basis. Amazon Inspector can also perform vulnerability scans within the AWS environment.
The key to successfully developing the cloud feedback loop is building automated triggers that alert or perform remediation actions based on specific conditions. For example, security teams could receive alerts when specific log file events occur or instance files change. These same triggers could execute code in more advanced tools, like AWS Lambda, to quarantine a running instance — for example, if a scan reveals critical vulnerabilities — or even to perform automated forensic evidence capture.
Security teams need to embrace security automation and orchestration in the cloud for both deployment and production monitoring and alerting, and this will happen more readily as the tools and cloud provider environments mature.