The “how” of security has dramatically changed with cloud computing, but the underlying strategies still remain very similar. There are many new opportunities to adopt the power and benefits of the cloud within our security strategies and programs and it has never been a better time to be a cyber security professional.
The underlying concepts are the same for all public cloud computing platforms, but the “how” of security varies based on each provider. Since AWS is still the dominant cloud service provider, I decided to share this example based on AWS today.
In the example in this article, we have a CloudWatch alarm monitoring EC2 instances and automatically recovering an instance via a Lambda function if a system’s status check fails due to loss of network connectivity. When an alarm is triggered and the recover action is initiated, you will get an automated notification by Amazon SNS! Now that is pretty slick if you ask me.
In the cloud we can automate our security controls and processes like never before and in this example today, I share how you can use AWS to architect a simple, but highly effect solution for logging, monitoring, and alerting using native AWS Services.
Get My Free Cloud Security Journal
Refer to the diagram below and then read my notes that correspond to each reference letter for A, B, C, D, and E.
(A) CloudWatch Agents
In the example that I share with you in this article, you could install the CloudWatch Agent on EC2 instances to allow communications between CloudWatch and each EC2 instance. Once the agent is up and running properly, you can send OS and application logs from your EC2 instances as well as your on-premise servers to Amazon CloudWatch for monitoring and analysis.
Amazon CloudWatch is a monitoring and observability service built for DevOps engineers, developers, site reliability engineers (SREs), and IT managers. CloudWatch provides you with data and actionable insights to monitor your applications, respond to system-wide performance changes, optimize resource utilization, and get a unified view of operational health. CloudWatch collects monitoring and operational data in the form of logs, metrics, and events, providing you with a unified view of AWS resources, applications, and services that run on AWS and on-premises servers. You can use CloudWatch to detect anomalous behavior in your environments, set alarms, visualize logs and metrics side by side, take automated actions, troubleshoot issues, and discover insights to keep your applications
(B) CloudWatch Events
CloudWatch events can deliver a near real-time stream of system events to AWS resources. For example, it is common to create snapshot of an Amazon EBS volume and this would quality as an event that can be monitored and alerted on. By using very simple rules, you can match events and send them to one or more targets for processing. CloudWatch Events lets you process AWS-provided events as well as custom events too.
(C) AMS Lamba
In this simple example, I am using AWS Lambda for part of an automated remediation solution. Once an event meets a specific rule, such as a failed security check, an AWS Lambda function can be triggered to remediate the issue.
AWS Lambda lets you run code without provisioning or managing servers, so it is extremely easy to build automated security processes. The best part with Lamda is that you only pay for the time when your code is running and there is no charge when you code is not running.
AWS Lambda is a serverless compute service that lets you run code without provisioning or managing servers, creating workload-aware cluster scaling logic, maintaining event integrations, or managing runtimes. With Lambda, you can run code for virtually any type of application or backend service – all with zero administration. Just upload your code as a ZIP file or container image, and Lambda automatically and precisely allocates compute execution power and runs your code based on the incoming request or event, for any scale of traffic. You can set up your code to automatically trigger from 140 AWS services or call it directly from any web or mobile app. You can write Lambda functions in your favorite language (Node.js, Python, Go, Java, and more) and use both serverless and container tools, such as AWS SAM or Docker CLI, to build, test, and deploy your functions.
(D) Amazon SNS
The Amazon SNS (Simple Notification Service) is a perfect choice for this solution because it is flexible, fully managed messaging and mobile notification service that can coordinate the delivery of messages to subscribing endpoints and clients. You have the ability to fan out messages to a large number of subscribers, including distributed systems and services, and mobile devices. Subscribers can include Amazon SQS Queue, web servers, email addresses, SMS text message, mobile devices and even Lambda functions! Follow this SNS tutorial and be up and running in minutes.
(E) CloudWatch Alarm
CloudWatch alarms can be trigged through changes in metrics to send notifications or automatically make changes to the resources you are monitoring. In my example, we have a CloudWatch alarm monitoring EC2 instances and automatically recovering an instance via a Lambda function if a system’s status check fails due to loss of network connectivity. When an alarm is triggered and the recover action is initiated, you will get an automated notification by Amazon SNS! Now that is pretty slick if you ask me.
And this is just a simple example of what can be done. You can get creative and build in custom automated workflows and totally take control of your security processes like never before.
Tim Layton specializes in demystifying the complexities and technical jargon associated with cloud computing security and risk management for business stakeholders across the enterprise. Tim is a cloud security thought leader defining actionable and defensible strategies to help enterprise stakeholders make risk-based decisions and prioritize investments in the new digital frontier.
Stay Connected With Tim Layton
Get My Free Cloud Security Journal
COMMON CYBERSECURITY RISK TERMS DEFINED
Threat: Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, or modification of information, and/or denial of service. (NIST 800–30)
Threat: potential cause of an unwanted incident, which can result in harm to a system or organization. (ISO 27001)
Vulnerability: Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source. (NIST 800–30)
Vulnerability: weakness of an asset or control that can be exploited by one or more threats. (ISO 27001)
Likelihood: A weighted factor based on a subjective analysis of the probability that a given threat is capable of exploiting a given vulnerability or a set of vulnerabilities. (NIST 800–30)
Likelihood: chance of something happening. (ISO 27001)
Risk: A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. (NIST 800–30)
Risk: effect of uncertainty on objectives. (ISO 27001)
Security Controls: The management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information. (NIST 800–30)
Compensating Security Control: A management, operational, and/or technical control (i.e., safeguard or countermeasure) employed by an organization in lieu of a recommended security control in the low, moderate, or high baselines that provides equivalent or comparable protection for an information system. (NIST 800–30)
Impact Level: The magnitude of harm that can be expected to result from the consequences of unauthorized disclosure of information, unauthorized modification of information, unauthorized destruction of information, or loss of information or information system availability. (NIST 800–30)
Residual Risk: Portion of risk remaining after security measures have been applied. (NIST 800–30)
Security Posture: The security status of an enterprise’s networks, information, and systems based on information assurance resources (e.g., people, hardware, software, policies) and capabilities in place to manage the defense of the enterprise and to react as the situation changes. (NIST 800–30)
Get My Free Cloud Security Journal