Unflattening a Flat Network – Adventures in Network Segmentation

In October I had the honor of speaking at the Lancope Vision conference about my experience in network segmentation.  I have spent the last few months establishing a program to segment a very large network.  It is based heavily on netflow and algorithmic identification of where enclaves should be.  I have finally cleaned up the slides for publishing.  Please read the notes along with each slide as they will be hard to understand otherwise.

Unflattening a Flat Network – Adventures in Network Segmentation:Slides

(EDIT: Video of the talk can be found at http://vimeo.com/78941693)

Since giving the talk, I have done additional work.  I am currently working on other methods for cluster creation as well as identifying the interactions between clusters to help identify groupings of hosts.  This all also eventually leads to algorithmic profiling of a network, predominantly the legitimate usage.  The profiling algorithms could then easily be run against packet captures of malicious network traffic and new traffic compare to both the legitimate and malicious profiles to identify malice on a network.  This work is still ongoing.

Model the Good With the Bad

When security monitoring appliances were originally envisioned, it was believed that the purpose was to "visualize risk" as Davi Ottenheimer (@daviottenheimer) put it.  However, for all of the fancy visualizations, the most useful part of a Security Information and Event Monitor (SIEM) is the list of correlated events.

That has lead us to realize the real benefit is in being able to prioritize potential malice on the network for investiagtion and identify data correlated with the potential malice.  We can see this in the rise of Splunk as a SIEM.  Now many SIEM producers are working toward this approach.

The next logical step is to develop models for malicious activity to help identify attackers in the massive amounts number of observations available.  But as we go forward with this approach, we need to not lose sight of the importance of modeling legitimate access as well.  

If we only model malice, the question we have to ask about any given observation of the network is "Does this observation match the model of malice?"  As a binary question, this is very hard to answer.  It will be very rare that something exactly matches the model.  If we don't have an exact match, it becomes a fairly arbitrary question as to whether the partial match is malicious or not.

However, if you model legitimate use along with malicious use, the question changes.  Now you can ask, "Does this observation match the model of malice more than the model of legitimate use?"  This is a much easier question to answer and provides real comparisons.  It also lets you monitor the hosts in an observation to watch for movement in the observation.  Over multiple observations you should be able to identify a host who's observations trend away from legitimate use towards malicious use.

Ultimately, the availability of innumerable observations of our network is opening up new options for   detection of malice on the network. Whether machine learning, subjective, or other approaches are used for modeling activity, they will all be more effective if we model not just the malicious activity, but the legitimate use as well.

Derbycon

I had a great time talking about graph theory and infosec at Derbycon 3.0.  Derbycon is an incredible gathering and I am honored to have been a part of it.  Other than a few technical glitches, the presentation went great (even the demo worked) and the room was packed.  If you weren't able to make it, you can either watch the video when it's posted or, if there's enough interest, I'll see if I can give it at another conference.  I'd love to have a 50 minute time slot to give the talk so I can give a bit more love to each of the slides.  If you want the charts or any of the links from my presentation, you can see them here.  Again, I'm so thankful to have both attended and spoke at Derbycon.  Thank you to everyone who's taken the time to speak with me here.  I'll see you at ISSA, Skydogcon, or BsidesNash!

UPDATE: If you want watch my derbycon talk, you see it on: irongeek.com.

UPDATE: You can also listen to my first podcast with Rafal Los at: his podcast.

Cyber Attack Graph Schema (CAGS) 1.0

While the concept of attack graphs has been discussed, once thing that is lacking is a standard definition for an attack graph.  This blog hopes to resolve that by presenting a new standard: the Cyber Attack Graph Schema (CAGS) 1.0

1.    All property names must be lower case

2.    Nodes must have the following properties:

1.    "class": May be "actor", "event", "condition", "attribute"

2.    "cpt": must be a JSON string in the format defined at http://infosecanalytics.blogspot.com/2013/03/conditional-probability-tables-in-json.html

3.    "start": The time the node is created. Time should be in ISO 8601 combined date and time format (e.g. 2013-03-14T16:57Z)

4.    "id": Assigned by database.

3.    Nodes must have property "label".

4.    The "label" property of nodes of "class" "event", "condition", or "actor" will contain a string holding a narrative describing the actor, event, or condition

5.    The "label" property of nodes of "class" "attribute" must contain a JSON formatted string with a single "{'type':'value'}" pair. Type is the type/name of the attribute and value the value.

6.    Nodes of any class MAY have property "comments" providing additional narrative on the node

7.    Nodes of any class MAY have property "finish" providing a finish time for the node. Time should be in ISO 8601 combined date and time format (e.g. 2013-03-14T16:57Z)

8.    Edges must have the following properties:

1.    "source": the id of the source node

2.    "target": the id of the target node

3.    "id": id assigned by the database

4.    "relationship":

1.    Value of "influence" if "source" property "class" is "attribute" and "target" property "class" is "event" or "condition".  Value of "leads to" if "source" property "class" is "event", "threat"

2.    Value of "influence" if "condition" and "target" property "class" is "actor", "event", or "condition"

3.    Value of "described by" if "source" property "class" is "event", "condition", or "actor" and "target" property "class" is "attribute"

4.    Value of "described by" if both "source" and "target" property "class" are "attribute"

5.    "directed": value of "True"

9.    Edges may have a property "confidence" with an integer value from 0 to 100 representing the percent confidence

10.                    Edges must be directed

11.                    Nodes and Edges may have additional properties, however they will not be validated and may be ignored by the attack graph.

12.                    Nodes and Edges missing values may still be accepted if the value can be filled in.

Disincentivizing Delaying Risk Mitigation

There is an ongoing issue in infosec:  the never-ending risk.  This is a risk that infosec has identified but the project would rather not mitigate.  The project cannot refuse to address the risk, but they can do the next best thing: agree to mitigate the risk, but never actually implement the mitigation.

This cycle normally starts with the infosec review and the project agreeing to mitigate the risk, hopefully in a set amount of time.  That time rolls around and infosec conducts a review of the progress in implementing the mitigation.  This is where things start to fall apart.  Rather than answering that they have followed the plan and mitigated the risk, the project indicates that they've made little to no progress.  Infosec has no choice but to accept a new mitgation schedule and meet months later.  Infosec can't spend its valuable resources following the schedule week to week so another period of time passes and nothing has been accomplished.  The cycle continues.

The primary driver of this cycle is that infosec cannot say 'no'.  It can't say no initially (or maybe put its foot down on a few issues which did get fixed) and it gets harder to say 'no' as time passes.  If the risk was acceptable for the last 6 months, it becomes harder and harder to justify to senior leadership why it won't be acceptable for the next 6 months.

There is an option though.  You don't have to say know, you have to say "yes but".  Think of it as saying, "yes, you can do whatever it was that you wanted to do, but only while you hop on one foot while patting your belly, rubbing your head, and singing Yankee Doodle."  In reality, this may be, "yes, you may use FTP, however each file must be encrypted individually and the password snail mailed to the receiver".  The goal is to both reduce risk and disincentivize delaying implementing a real mitigation (such as using SFTP).

An alternate is to decrease the time frame for review.  If the project doesn't know when they will have it mitigated, approve use for only 1 month.  At the renewal, they should be required to provide the mitigation plan.  If they don't know how long it will take to come up with a mitigation plan, give approval for 1 week.  At 1 week they should have a schedule for creating the mitigation plan (effectively a schedule to create a schedule).

This only works if they have to prepare significantly more for a renewal than you do.  There should be assessments, forms, plans, briefing charts, etc that they have to prepare for the renewal and that you only have to read.  The goal is to make renewals more time consuming for them than for you.  That way increasing the number of renewals is burdensome on them and not on you, again disincentivizing delaying a mitigation.

Regardless of which way you go, it must be tied to risk.  If you cannot show that the reason you are requiring the extra work or quicker turns is to help minimize risk, you really are simply generating make-work which will not be tolerated at your level or at upper levels.  Also, you must be absolutely responsive.  You once they decide to mitigate the risk you must help and support their solution so that you do not impede the work.

Ultimately, while it sounds harsh to disincentivize delaying mitigation through additional work, in many cases it, is unfortunately necessary.  Unless the project is benevolent, they will do what they are incentivized to do and most of the time; only infosec is incentivized to mitigate risk before it is realized.  By disincentivising delaying mitigation, you are simply balancing the scales to help ensure a quality product.

Tied in Silk Ropes - A subtler way to infosec

After reading the Infosec Jerk's Problem blog, I wanted to suggest another way of dealing with the constant struggle between infosec and the rest of the organization.   It's a method I've used to great effectiveness in multiple situations and it normally leaves all parties happy, (or at least not unhappy with you).

Lets take an example, department X comes by with a new requirement to open ports between Y and Z.  The standard infosec answer is 'no'.  The normal resolution is "how big an issue is X willing to make this to get what they want"?  Can they push it high enough that they can overwride infosec?

Compassionately, you could listen to their arguements, try to see it from their point of view, maybe consider different design options.  Many times though, they won't want to change the design and even if you understand their view, your view is still what your view was.

I have a different approach. In true Mafia style, I do you a favor; maybe you do me a favor one day.  Rather than make their life harder, request something in return that they don't care about.  In the above example, ask them to install a suite of monitoring equipment.  You didn't tell them 'no'.  You didn't even change their design.  You might even have provided the equipment yourself.  Instead, you simply asked that they return the favor of you allowing them to do what they wanted by them helping you do what you wanted.  It's mutually beneficial.

However, you're going to pick your side of the favor wisely.  Your goal is not to solve this one-off problem but create a change in how business is done.  If you ask EVERY person who wants to open ports to install that monitoring suite, well, that suite has now become standard for boundaries.  If every time someone asks to plug A into B, even temporarily, you request they simply put in a firewall (even if it has almost no rules), eventually, a firewall becomes standard for connecting things.

What about when people ask you to agree to not raising a fuss when they want to do something that causes security risk, (and we're speaking relatively minor)? You say, "yes, that's fine, but I need you to fill out this risk form.  I'll analyze it and accept it."  You've now created a risk acceptance and tracking program.  The next step is to say "Well yes, I'll sign the risk form, but I need to include when you DO plan on patching."  Now you have them generating mitigation plans.  You'll follow with, "Ok, but I want an update when you do mitigate it.  If I don't get one, I'll check up and potentially rescind the acceptance".  Now you have continuious oversight.  Finally, you'll get to the point where you can say, "gee, I don't think this risk is acceptable.  We should elevate."  In effect you've established a risk program without ever having to force fight anyone to get it.

This works for many things.  It can be installing new systems, allowing vulnerabilities to persist, making new connections, opening ports, etc.  You can get all sorts of things out of it:  firewalls, IDSs, policies, procedures, authority, and more.  And the people will love you for doing it.  You'll be tieing the binds of security tight, but you'll be doing it softly and slowly with silk ropes.  In the end the ties that bind will be just as tight and secure as if you'd tried to force them on people, but you'll have done it without having to have a single fight.

When Educating Doesn't Work

I used to sell computers at Circuit City. Their hiring test said I'd be great at it. I wasn't, for one reason: I tried to educate people. I would try to teach them why one computer was different from another, and how certain characteristics were better for one use then another. I'd even leave them with a simple choice: "buy X for gaming, buy Y for business stuff.”

That was too much. It wasn't until much later that I realized they wanted to tell me what they wanted to do, then have me point to a single computer and tell them to buy it. Why did I make this mistake? I'm a highly cerebral intellectual. I want to know about the man behind the curtain. And, erroneously, I assume others do as well.

This is a problem we face in information security today. While less technical people – the sales person at your local mattress firm, say – may not really try and educate, but simply settle for influencing you, we try to educate on the honest belief that educated people will make the right decision. However, that’s not how it works. People buy what they want first, then (maybe) what they think they need second.

What we should do is try to influence them. Our job is to make them want what they need and think it's their idea. This doesn't mean giving them what they ask for. That would be the exact opposite of influencing. Instead, we want to change what they want, in order to align with what is best for them from an infosec standpoint.

The next time you’re trying to get a client or customer to take a certain action, don’t forget to influence. At the end of the day, you may even be able to influence them to want to be educated.  But the first task is to do what is right by them and that will probably require influencing them first.