Less frequently occuring... things

Frequency analysis is a powerful tool in a variety of disciplines including cryptoanalysis, digital forensics and incident response. I may have first heard of its application to DFIR from Rob Lee, who was working for Mandiant at that time. Peter Silberman, also from Mandiant touched on the benefits of "least frequency analysis," here. Harlan Carvey has discussed the concept as well. I blogged about using the technique a few years back and coming full circle, Mandiant has expanded on the concept in their excellent data stacking post.

If you're working at scale and collecting large amounts of host level data in comma, tab (or other single character) separated values files, I've written a Powershell script, Get-Stakrank, which you may find useful for analysis. I've written up a use-case scenario in the readme.md file in the github repo for the project.

I intend to build a similar script for working with xml data as there are some common tools that produce XML output.

Security debt: SDLC for the best, plan for the worst

Microsoft's Trustworthy Computing initiative celebrated its 10th anniversary in 2012. Many diligent companies have adopted secure software development life cycles aimed at delivering more secure products or protecting their own assets. These initiatives are "front-end" heavy, that is to say, they invest significant time and resources in the early stages of development through security threat modeling, code reviews, penetration testing, and the like -- all in an attempt to build more secure products from the start -- the front-end.

For all the value these front-end efforts provide, they aren't perfect. Complex systems can be difficult for even experienced experts to fully understand. Trust boundaries too often aren't. Applications aren't always accurately decomposed. Threats may be missed or under-estimated. Despite their best efforts, organizations still find themselves compromised and having to respond to breaches. Nevertheless, I have no doubt the problems would be worse if these organizations weren't investing in these front-end activities.

Given the inevitability of breaches, many organizations should focus some portion of their SDLC-like initiatives on the "back-end" of security -- the incident response, investigation and remediation side. Having an IR plan is a start, dedicated head-count for IR is a good step, but think beyond that. If you have an IR team but don't give them the tools to do their job effectively, the costs of inefficient investigations and inadequate remediations add up quickly.

Many organizations invest on the front-end to build secure systems. Mature organizations recognize that even their best efforts will fail and they make investments to build systems that facilitate incident detection, response and remediation.

Go ahead and threat model your apps, review the code, pen test them, but go beyond that. Design applications to log information that will be meaningful for incident responders. Design your systems to forward logs to secure locations where they can be reviewed by automated systems and manually using efficient interfaces. Architect your information systems to facilitate efficient investigations. Enable your investigators with tools for collecting data from hundreds, thousands, tens of thousands of systems worldwide. Plan your deployments for maximum efficiency, but remember when the shit hits the fan, some cycles will be needed for investigations, factor that in to your capacity planning.

Security debt doesn't just come from bugs in your code. If you're not designing your systems to make investigations efficient, you're accruing debt that will eventually come calling.

Dump the schema for Windows Security Events

Here's a useful Powershell one-liner for getting at the Windows Security Event Log schema:
(get-winevent -listprovider microsoft-windows-security-auditing).events

You may want to save the output to a varialbe:
$events = (get-winevent -listprovider microsoft-windows-security-auditing).events

Here's an example of the output: