<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>IR on Alex Maestretti</title>
    <link>https://retiari.us/tags/ir/</link>
    <description>Recent content in IR on Alex Maestretti</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Fri, 16 Sep 2016 12:11:02 +0000</lastBuildDate>
    
	<atom:link href="https://retiari.us/tags/ir/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>Fixing Incident Response</title>
      <link>https://retiari.us/posts/fixing-ir/</link>
      <pubDate>Fri, 16 Sep 2016 12:11:02 +0000</pubDate>
      
      <guid>https://retiari.us/posts/fixing-ir/</guid>
      <description>What makes detecting and responding to malicious activity on information systems so difficult? Incident Response and investigation can be incredibly intellectually rewarding. You get to puzzle together what transpired and take action to defend your systems, while working against a wily and adaptive adversary. On a bad day, however, you will find that most of the puzzle pieces are missing and there is no wily adversary present, only a deluge of false positive security events being happily emitted by an expensive PRNG called a SIEM. The core issues are volume of activity on, coupled with the complexity and change of, the systems you are defending. Traditional IT management compounds these issues rendering effective response impossible. DevOps, microservices and cloud infrastructure, in solving for scalability and development velocity, also offer solutions to these core security problems, and have the potential to Make IR Great Again.
IR allows you to exercise a wide range of security skills. The diversity of events that one encounters ensures a varied and engaging workflow that continues to challenge. It takes not only a keen intellect and technical skill, but a body of experience from which to draw. Often there is no runbook, so you cobble together inferences from similar past cases and drive on.</description>
    </item>
    
    <item>
      <title>AWS DFIR</title>
      <link>https://retiari.us/posts/dfir_aws/</link>
      <pubDate>Thu, 11 Aug 2016 00:24:23 +0000</pubDate>
      
      <guid>https://retiari.us/posts/dfir_aws/</guid>
      <description>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.</description>
    </item>
    
  </channel>
</rss>