Brianne Fahey

analysis

When a List Won’t Do

by

A Microsoft Technet article by John Lambert from 2 years ago includes this quote, and I’ve seen it used many times since then:

“Defenders think in lists. Attackers think in graphs.”

To me, this statement means that there are multiple possible paths available to get to an end if you can pivot and reorient while working through an environment. The environment may have been designed in a systematic hierarchy to maximize organization efficiency, but that doesn’t mean a wily actor can’t create their own circuitous route.

I mentioned in a previous post that I’ve been learning to dabble in Graph Databases. In fact, I am working to build a graph representation of the connections and pivots available in the logs and data typically available to an analyst in an investigation (inspired by one of my favorite parts of the Investigation Theory course).

Unlike a relational database, a graph database uses nodes, edges, and properties to build and describe relationships. Wikipedia describes the graph theory behind a graph database better than I can, but I put together the visualization below before my free trial of MindJet MindManager expired. If you can determine your nodes, labels, properties, and relationships – you can connect and visualize the net of assets and relationships in your scope. Let’s use the sample graph visualization of two colleagues names Bob and Cathy.

  • Nodes contain properties and are tagged with labels.
    • The person is a node, the property is their name and the labels are their position and their prestige.
  • Relationships connect nodes, have direction, and contain properties.
    • The relationships describe how the nodes (persons) are working and hiring.

I’ve been learning Neo4j to build a graph database.  Download this free Graph Databases ebook from O’Reilly to get started.  I’ve also watched some videos in an Intro to Neo4j course hosted by Lynda (which normally has a cost but can be accessed with my library card for free via the elearning offerings on my local library’s website). I’d also like to buy Learning Neo4j Graphs and Cypher book and video from Packt Publisher in the future.

In the starter use case I’m building out in my own Neo4j instance, the nodes are both data sources and data elements, and the relationships describe where the data elements are contained. The idea behind this is that if an analyst had one piece of data and wanted to get to another piece of data, they could explore the graph to see which nodes they have available to traverse in order to pivot the data from what you have to what you want.

For instance, if you have the IDS Alert available providing you a signature and protocol, but you need to know the details of the certificate used in the transaction, you can pivot fro the IDS alert through the PCAP and SSL Transaction to get to your destination.

I am still experimenting, I know my test data is imperfect.  Ideally, you could research the sources and elements available within your enterprise to create your Cypher code and output a visual database that allows you to look or query for a solution path. Somehow it feels much more impressive when you look at the connections for the data elements of a dozen or so different data sources at once.

This is a solid idea for a learning opportunity and a rough first implementation try. I’ll think on it some more and work to eventually hone something useful and repeatable that doesn’t take much effort to keep up to date. If you have any input, feel free to use the contact form on my website and reach out.

I Think, Therefore I Am An Analyst

by

There are a lot of tools to learn in the cybersecurity trade. There are a lot of sources willing to teach you about those tools.  There are not many people interested in teaching you how to think like an analyst.

I just finished the 3rd course in my Chris Sanders’ Applied Network Defense trilogy: Investigation Theory. Before this course, I’d taken and reviewed Chris’ Effective Information Security Writing and Practical Packet Analysis.

Investigation Theory is a course designed to help an analyst develop a mindset to investigate any type of security event or alert. The course is built to take roughly 10 weeks and you can pace yourself to finish faster or slower.  Although it is offered fully online, Chris organizes the course so that a new group starts it together every few months.  The benefit of this is that no only do you have the ability to interact with the instructor Chris Sanders in the online course board, you also have the opportunity to post thoughts to and respond to questions from other students.  I definitely took something away from reading other students’ answers to Chris’s posted questions at the end of many lectures.

In addition to lectures, the course includes student community discussion, recommended reading, bonus lectures, and interactive investigation labs.

Nothing helps ideas stick better than hands-on practice.

The labs were challenging. I had to try most of them several times before I submitted the correct answer.  But I learned ideas of questions to ask and places to look for leads to those answers.

One of my favorite sections in the Investigation Theory course was built around explaining the value provided by different types of analysis data. It focused on the likely available sources in an investigation like packet captures, netflow data, IDS alerts, OSINT, and an armful of different log types. The lecture described the pros and cons of the source and highlighted opportunities to aggregate and pivot on data attributes provided.

I’m proud to have finished this course.  I would recommend it.  It is less technically specific than Practical Packet Analysis, but it is full of insights that will work for a security analyst no matter what tools and tactics you have experienced.

You can a course description, pricing, and registration information at the Applied Network Defense site.

Typically Mean Averages

by

I wonder if I am a typical security analyst?

But what is typical?  Hard to tell what an average is since for every person near the core of the bell curve, there are quite a few outliers keeping things both challenged and balanced.  If asked to describe the typical security analyst, I would throw out a few generalizations based on what I’ve encountered in my experiences.

A profile performed by DataUsa.io has put together a slick Profile of the Average Security Analyst. The typical analyst experiences a solid salary, strong job growth, highly educated peers, demanding technical skill requirements, and a roughly 75% white 75% male field.

From https://datausa.io/profile/soc/151122/

Sounds awesome. And intimidating.

Everyone has their own reasons for moving to a Security Analyst role. I fit some of the general averages noted above, but not all. Certainly diversity of people bring diversity of thought.  If one of the main tenants of a secure enterprise is “Defense in Depth“, then certainly you should invest energy into building defense by diversity. Perhaps it is wise for both your layers of security and your team resources be deep, diverse, adept, and agile.

I don’t always love difficult people, but I do love challenging work.

I don’t see myself as a typical analyst because I bring differences in thought and approach.  I ask questions. I draw connections. I talk to people in the business. I look for ways to align things. I act with a goal in mind.  I draw it out or write it down and hone it till it works or throw it out and take another path toward the goal. I aim to evolve and improve. When I want to learn about someone I ask them out for a coffee walk or a breakfast.  I sometimes make songs out of the ideas I’m working through or take a doodling break to try to think into a breakthrough.

I do see myself as a typical analyst because I like to make order out of chaos. I want to understand what happened and enact protections. I often feel exhausted after a day with a lot of people interactions.  I easily memorize IP addresses and hostnames while I research events but I don’t always remember the names of my people I just met. I believe that Ex Machina and Black Mirror are equally awesome and terrifying because they’re tangibly realistic.

In this industry, the pace is fiery fast and the challenges are densely packed. The targets move and I’m sure the typical averages will also.

Find a Flow

by

If you can see it, you can get to it.

When I think through the parts of an event analysis, I look to put things in order and in perspective on my way from a hypothesis to a conclusion. Putting together a thought outline that works for me was a good excuse to test out LucidChart.

In my example, I start by enumerating the actor’s profile and the activity that generated a signal.  If I can source, trace, and verify the details pulled out of the logs to connect activities to an IP or a piece of hardware or an application or a procedure or an owner, I can work to build out the story and resolve my questions. When the case requires input from an investigation partner like human resources, you’ll have a solid frame of notes and findings to rely on for that discussion.

One of the reasons I chose this scenario as an example is because I believe a successful analysis is a complete analysis. Thorough, of course – to your personal quality level, but not necessarily ending the the proving out of malicious activity. Vetting that activity can be anomalous and still acceptable is a decent outcome.

You don’t have to catch a bad guy to do a good job.

Build a structure that works for you.  Once you establish your flow and create a template, you’ll start to save some time without sacrificing quality. Find your flow and go catch yourself some answers.