https://retiari.us/tags/aws/ Recent content in AWS on Alex Maestretti Hugo -- gohugo.io en-us Fri, 15 Jun 2018 12:56:35 -0700 https://retiari.us/posts/geekwire/ Fri, 15 Jun 2018 12:56:35 -0700 https://retiari.us/posts/geekwire/ Inside the private event where Microsoft, Google, Salesforce and other rivals share security secrets. https://retiari.us/talks/first_2018_podcast/ Thu, 07 Jun 2018 12:56:35 -0700 https://retiari.us/talks/first_2018_podcast/ A podcast for FIRST 2018 on how the Netflix SIRT operates. https://retiari.us/talks/aws_forensics_reinvent/ Mon, 07 Aug 2017 12:56:35 -0700 https://retiari.us/talks/aws_forensics_reinvent/ A talk from Re:Invent 2017 on how to look for evidence on disk in AWS. https://retiari.us/talks/aws_hunting_sans/ Fri, 07 Apr 2017 12:56:35 -0700 https://retiari.us/talks/aws_hunting_sans/ A talk from SANS Threat Hunting Summit 2017 on how to look for adversary activity in AWS. https://retiari.us/posts/dfir_aws/ Thu, 11 Aug 2016 00:24:23 +0000 https://retiari.us/posts/dfir_aws/ I previously discussed some of the challenges and opportunities of working in a public cloud when it comes to forensic response. Since you don’t own the datacenter, traditional tactics of grabbing boxes and imaging drives with write-blockers don’t apply. The goal is still to capture an unaltered image of both the disk and live memory, preferably without any interaction with the target system. Network traffic is another useful optic, and in traditional models can be captured out-of-band without disturbing the target through taps. The reality is it is often inefficient to answer your questions, especially fleet-wide, by capturing full live memory and performing analysis on it, in which case you might consider live response capabilities as well to query the running system. The danger is that by interacting with the system you might alter the evidence or tip off the adversary. Ideally you will have already logged relevant activity and stored it off target. All of these optics are valuable, and their value compounds when combined. In deception it is difficult to control multiple channels; so for example, while the OS might lie, it is hard for that lie to stand up to correlation across network data. In AWS the snapshot API for EBS-backed instances is an excellent tool. https://retiari.us/posts/security_monitoring_cloud/ Mon, 08 Aug 2016 00:24:23 +0000 https://retiari.us/posts/security_monitoring_cloud/ What should security monitoring look like in an AWS EC2 environment? Consider an EC2 environment running standard Linux AMIs with two use cases: detection and response. Detection is best supported by streams of real time events emitted by the endpoints. You can run signatures, heuristics and ML on these streams to detect suspicious conditions and trigger automated response: block, bounce, increase level of monitoring, etc. Response generally involves a human who wants to ask questions about the entire fleet, a subset or a single instance. With public cloud there is a new layer of relevant information, in our case from CloudTrail, CloudWatch, VPC flow logs, and other AWS sources. More on those later; we also need traditional system-level monitoring of instances from our side of the shared responsibility model. For detection ‘pull’ is not ideal. Many solutions rely on polling on some interval which results in a window between pulls. An attacker that is aware of your logging then has an opportunity to cover their tracks. For detection I prefer push or event driven solutions. A system event occurs, a log entry is created and immediately sent off-instance to remote analysis and storage. The drawback is limited context available at the moment of generation with which to determine relevance. https://retiari.us/posts/aws_ops_rig/ Mon, 01 Aug 2016 12:46:56 +0000 https://retiari.us/posts/aws_ops_rig/ Every responder needs a solid platform from which to operate. Something fast, secure and pre-loaded with relevant tools. Conducting incident response in a public cloud is the same as traditional IR but different. The public cloud is after all just other people’s servers; however, the ‘other people’s’ part changes things up a bit. You can’t roll into Amazon’s data center and grab a disk out of the rack, but Amazon provides an API for that. The concept they have put forward is ‘shared responsibility’ in which they handle the hypervisor and below, and above that is on you. We are moving towards a serverless approach to forensic response leveraging lambda functions and Amazon APIs; however, there is always a need for a solid ops box stocked with tools and enough permissions to get the job done. Design Goals: AWS EC2 native - leverage AWS APIs; minimize external dependencies - can’t rely on much in a crisis. Ephemeral instances - Spin up fresh, clean and quick; and kill them off once needed data is persisted to S3. Tools for response on Debian/Ubuntu AMIs with headless server (no GUI). Use corporate services day-to-day, but provide fallback options if they are down.