<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>disk on Alex Maestretti</title>
    <link>https://retiari.us/tags/disk/</link>
    <description>Recent content in disk on Alex Maestretti</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 22 May 2017 12:05:48 +0000</lastBuildDate>
    
	<atom:link href="https://retiari.us/tags/disk/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>Disk Forensics Pipeline</title>
      <link>https://retiari.us/posts/disk-forensics-pipeline/</link>
      <pubDate>Mon, 22 May 2017 12:05:48 +0000</pubDate>
      
      <guid>https://retiari.us/posts/disk-forensics-pipeline/</guid>
      <description>Last week we hosted colleagues from Google, AirBnB and Adobe to work on a joint effort to improve our disk forensics capability. Our goal is to move towards a streaming model for disk forensics by updating various existing tools that are built around the concept of imaging a single machine and creating a file. In a cloud environment we need to image multiple (even hundreds) of machines and process all those images into meaningful event data. Acquisition is fairly painless via API, but then what to do with the resulting snapshots?
We are working towards a cloud agnostic streaming service for disk forensics. To get there we are currently focusing on acquisition in AWS and then sending those snapshots through Plaso for processing, pushing results into ElasticSearch, which is then fronted by Timesketch for analysis. I filed a number of issues with Timesketch to move us towards this, and we are working with the Plaso maintainers as they do some refactoring as well, but even now, with a few hacks, we can compose a system that achieves our goals.
Acquisition Currently we have a set of boto scripts that enables us (Netflix SIRT) to capture snapshots of a group of instances within AWS.</description>
    </item>
    
    <item>
      <title>What to Monitor on Instance</title>
      <link>https://retiari.us/posts/what-to-monitor-on-instance/</link>
      <pubDate>Wed, 17 Aug 2016 00:24:23 +0000</pubDate>
      
      <guid>https://retiari.us/posts/what-to-monitor-on-instance/</guid>
      <description>I think of security relevant endpoint data within three domains: disk, memory and network. There are plenty of other taxonomies one could use. Disk, is generally addressed with File Integrity Monitoring (FIM). Memory, I am really talking about process execution, so anything that is exec’d and what it subsequently does (ie syscalls). Network, data transiting through external interfaces. Of course all three domains overlap - network configurations are stored on disk, sockets are opened with system calls, etc. There are also other useful optics like user identity and access that span these primitives.
To cover these areas on our production systems we look to the Linux audit framework. Audit provides two types of rule; file and system call. With these two primitives any other type of desired monitoring can be built. In fact ‘file’ is simply a wrapper on the open() syscall. In addition to system call monitoring, Linux system logging functions provide pre-built enrichments that correlate and present low level data in a more relevant format. For example auth.log should be captured, rather than trying to rebuild those events from syscalls yourself. The logging landscape in Linux is rather convoluted and evolving (ex. systemd-journald), so your configurations are likely to be distribution specific.</description>
    </item>
    
  </channel>
</rss>