Category Archives: Ideas

Thinking Graphically To Protect Systems

I recently read this post on TechNet regarding the difference in approaches between attackers and defenders.  Specifically that defenders tend to think of their environment in terms of lists:

  • Lists of data
  • Lists of important systems
  • Lists of accounts
  • etc

But, attackers “think” in graphs.  Meaning that they think of the environment in terms of the interconnections between systems.

I’ve been pondering this thought since I read the TechNet post.  The concept seems to partly explain what I’ve written about in the past regarding bad risk decisions.

My one critique of the TechNet post is that it didn’t (at least in my view) clearly articulate a really important attribute of thinking about your network as a graph: considering the inter-connectivity between endpoints from the perspective of each endpoint.

In our list-based thinking mode, we have, for instance, a list of important systems to protect and a list of systems that are authorized to access each protected system.  What is often lost in this thinking is the inter-connectivity between endpoints down-stream.  As the TechNet article describes it:

“For the High Value Asset to be protected, all the dependent elements must be as protected as thoroughly as the HVA—forming an equivalence class.”

The pragmatic problem I’ve seen is that the farther we get away on the graph from the important asset to be protected, the more willing we are to make security trade offs.  However, because of the nature of the technology we are using and the techniques being successfully employed by attackers, it’s almost MORE important to ensure the integrity of downstream nodes on the graph to protect our key assets and data.

This creates a tough problem for large networks, and I found the comments on the TechNet post slightly telling: “Can you tell me the name of the tool to generate these graphs?”  The recommendations in the TechNet post are certainly good, however often too vague…  “Rethink forest trust relationships”.  That sounds like sage advice, but what does it mean?  The problem is that there doesn’t appear to be a simple or clean answer.  To me, it seems that we need some type of methodology to help perform those re-evaluations.  Or, as I’ve talked about a lot on my podcast, we need a set of “design patterns” for infrastructure that embody sound security relationships between infrastructure components.

Another thought I had regarding graphs: graphs exist at multiple layers:

  • Network layer
  • Application layer
  • User ID/permission layer (Active Directory’s pwn once, pwn everywhere risk)
  • Intra-system (relationship between process/applications on a device)

Final Thoughts (for now)

The complexity of thinking about our environments in graphs shouldn’t dissuade us from using it (potentially) as a tool to model our environment.  Rather, that complexity, to me, indicates that we should likely be thinking about building more trusted and reliable domains (the abstract definition of domain) that relate to each other based on the needs of protecting “the environment”, and less about trying to find some new piece of security technology to protect against the latest threats.

Want To Get Ahead? Create Something!

I get a lot of requests lately asking for career advice.  I’m not sure why, as I don’t feel like I’m a paragon of success or wisdom, but I have tried to help with things like a guide for getting into information security.

Yesterday, I was spending quality time as my dog’s favorite chew toy reflecting on this more and something really obvious hit me.  Painfully obvious.  The most direct way to establish a place in the industry is by creating and contributing.

Think about it: who are the people you respect in this industry?  Even outside this industry?  Why do you respect them?  How do you even know about them?

I will bet it’s because they are creators.

So, my advice for those wanting to get into, or advance in information security is to create something:

  • Conference presentations
  • Open source software
  • Informative blog posts
  • Podcasts

The point is to participate.  It will focus you on getting better and learning.  It will help you meet people.  It will establish you as someone who can add value.

Security Chaos Monkey

Netflix implemented a wonderfully draconian tool it calls the chaos monkey, meant to drive systems, software and architectures to be robust and resilient, gracefully handling many different kinds of faults. The systems HAVE to be designed to be fault tolerant, because the chaos monkey cometh and everyone knows it.

I believe there is something here for information security. Such a concept translated to security would change the incentive structure for system architects, engineers and developers. Currently, much design and development is based around “best case” operations, knowingly or unknowingly incorporating sub-optimal security constructs.

For lack of a better name, I will call this thing the Security Chaos Monkey (SCM). The workings of a SCM are harder to conceive of than Netflix’s version: it’s somewhat straight forward to randomly kill processes, corrupt files, or shut off entire systems or networks, but it’s another thing to automate stealing data, attempting to plant malware, and so on. In concept, the SCM is similar to a vulnerability scanning system, except SCM’s function is exploitation, destruction, exfiltration, infection, drive wiping, credential stealing, defacement and so on.

One of the challenges with the SCM is the extreme diversity in potential avenues for initial exploitation and subsequent post exploitation activities, many of which will be highly specific to a given system.

Here are some possible attributes of a security chaos monkey:

• Agent attempts to copy random files using random user IDs to some location off the server

• Agent randomly disables local firewall

• Agent randomly sets up reverse shells

• Agent randomly starts listening services for command and control

• Agent randomly attempts to alter files

• Agent randomly connects a login session under an administrative ID to a penetration tester

An obvious limitation is that SCM likely would have a limited set of activities relative to the set of all possible malicious activities, and so system designers may simply tailor their security resilience to address the set of activities performed by SCM. This may still be a significant improvement over current activities.

The net idea of SCM is to impress upon architects, developers and administrators that the systems they build will be actively attacked on a continual basis, stripping away the hope that the system is protected by forces external to it. SCM would also have the effect of forcing our IT staff to develop a deeper understanding of, and appreciation for, attack methods and methods to defend against them.