<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Cloud on Alex Maestretti</title>
    <link>https://retiari.us/tags/cloud/</link>
    <description>Recent content in Cloud on Alex Maestretti</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 01 Aug 2016 12:46:56 +0000</lastBuildDate>
    
	<atom:link href="https://retiari.us/tags/cloud/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>AWS Ops Rig</title>
      <link>https://retiari.us/posts/aws_ops_rig/</link>
      <pubDate>Mon, 01 Aug 2016 12:46:56 +0000</pubDate>
      
      <guid>https://retiari.us/posts/aws_ops_rig/</guid>
      <description>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.</description>
    </item>
    
  </channel>
</rss>