You are currently browsing the tag archive for the ‘IDS’ tag.

In a bit of fun and interesting timing it turns out I’ll be going to flocon in New Orleans this January.

Since I’ve spent the past 2-3 years doing business risk and security architecture, national sector level strategy, policy, etc….but now find myself getting into the technical details of building a CERT (ICS-CERT, specifically)…it’s suddenly time to get more up to speed on flows and how people are using them these days (Especially since I’d previously spent most of my time with firewalls and IDS data and not netflow / SiLK stuff).

My work on and release of pkviz this past weekend has helped a bit to get me re-focused on data analysis and playing with correlation tools and methodologies, but I’m still finding it odd going back to my earlier technology-centric security role  – which I’d thought I’d given up.  My head space has to be completely different than it was and I have to work around what some have called my fatalistic belief that technical security measures and analysis are doomed to fail in the face of our complete lack of interest in doing business risk architectures.

What scares me a little, though, is when I’ve been talking to people and doing research lately, it seems the state of the art of IDS, Flows, SEMS, SIEMS, network data analysis, etc. hasn’t changed all that much in the past few years. More vendors have sold more products, but they still do the same (questionable) things it seems. What gives? Am I off base?

Still, I’m pretty excited to get back into this type of thing and about the con. Who’s going to be there?

(Needs Editing, but Im a bit stuck…so reviews and comments welcome.)

Years ago – in Mad Magazine – I saw an illustration of Alfred E. Newman sitting in a tire swing. At first glance everything seemed normal, but after a second if reflection I noticed that it was Alfred himself holding up the tire swing while sitting in it – a situation which obviously does not (heh) fly.

This is the image that came to mind when, after my last post on Data Visualization’s Lessons for Enterprise Security, I was asked questions like:

  • What does Operational Risk Management have to do with IDS monitoring directly?
  • What about better and more transparent auditing? Wouldn’t that help?
  • I don’t see how SABSA really applies to MSSP’s or IDS monitoring

My short answer is that no matter how you make your security tire swing or what you do while you’re sitting in it, as a security practice you have to be bolted to something independent that holds it all up. That’s “The Business” in case it’s not clear.

I’d like to address the IDS example, in particular, because I think it is very illustrative of the connection between detailed technical and high level business realities.  Please keep in mind that this is only a snapshot of the direct implications to a very small section of a much larger, very holistic process.  There are many secondary dependencies and repercussions which I do not address here (like tactical technical responses, incorporating lessons learned, strategic business decision making, etc.)

So, first of all, at a process level, IDS monitoring is pretty simple:

Get data -> Evaluate nature of data -> Evaluate implications of activity represented by data ->Respond to and/or continue getting data

No matter what environment you’re in, if you’re looking at IDS data (or doing any other monitoring, really), you do these four things. If you look a little closer, though, you begin to see that they are (or should be) repeated iteratively. This is because there are really multiple levels – or layers – at which security data can be evaluated (which, incidentally, looks a lot like any other protocol stack). Let’s say, conceptually, that there are five of them:

  1. Universal Technical Standards: This layer would consist of measuring activity against RFC’s, Protocol Standards, etc. Things that -should- work the same everywhere.
  2. Environmental Configuration: Here, traffic is evaluated against local configurations that might change from network to network. This includes the configuration of OS’s, Web Servers, Infrastructure Devices, etc.
  3. Data and Information Control: What happens to data riding on your network and IT obviously falls in the area of concern for IDS analysis.
  4. Timing and Behavioral Thresholds: Are things happening more frequently than normal? Less frequently? Uptime? User logins? Memory Usage? etc.
  5. Business Rules: Is the IT actually doing something that directly affects the business? Are manufacturing robots shutting down? Are internal company secrets being sent to competitors? Are you spamming the military?

So what is the intersection between these layers and enterprise business architecture or operational risk management? It looks, initially, like the only direct overlap is in layer 5, right? Not true.

First, each of these layers requires some level of the business context provided by business security architectures to even be effectively evaluated.

For example:

  • To evaluate security data against potential technical standards, analysts need to know what technologies are in place and deployed and in what manner. Exceptions and outliers are especially important.
  • From an environmental perspective, analysts would be well served by knowing the security policies that the configuarations and environment are supporting. E.g., what actions the configurations trying to prevent  or support (in terms of the other 5 layers)
  • The need to know what data belongs to what data policies and what those policies say is also fundamental.  Data policies are tied to conceptual business architecture, which is tied to contextual business assets and requirements.
  • System behavior is evaluated in part by knowing things like business schedules and processes. Is payroll being run every 4th Thursday? Are people going to be logging in from all over the world, or just certain locations? Should lab systems pull data from production systems?
  • Knowing what business functions are important to keep running, to what thresholds, and how IT systems support those is crucial when trying to understand the big picture and put “events” in terms of “incidents”.  Additional, it should be kept in mind that things like “reputation” and “customer satisfaction” are also considered business assets to protect.  Organizations have a need to protect those as well.

Secondly, and maybe more importantly, if you actually look at the process flow (below) you find that the analysis process always rolls up to an evaluation at layer 5 (the business rules) of the analysis stack.

From a process flow perspective, there are absolutely no analysis scenarios that do not terminate before completing a layer 5 business analysis (At the bottom of image).

(Click Image for Full Size View)


How does this work?

Analysis begins at one of these five layers – which one is first doesn’t really matter (they are often, in fact, done in parallel). Data is received and is evaluated against the criteria at the layer in question. If there are no exceptions, the same raw data is evaluated against the next layer in the chain. If an exception is found at any one of these layers, the impacts of that exception are then evaluated at all layers. So, for instance, if an analyst notices that there are “funny packets” that aren’t normal TCP/IP traffic while evaluating against “Technical Standards”, he or she then looks to see what the potential technical, environmental, data, behavioral, and business implications are of that traffic. For each of those, the analyst follows the process as if he’d just received new raw data.

This continues to happen until the original data has been run up the entire stack and a final business impact has been determined. Sometimes the path there is short because the answers are known or obvious, or complete data is unavailable to make a determination, or the entire process is followed at a very detailed level. Regardless, the logical process holds true in all cases and there is either a potential business impact or there isn’t.

Read that again: There is either a potential business impact or there isn’t. Without context, IDS monitoring can never be a security function.

The value of IDS monitoring never gets realized if exception events are not tied to business operating requirements and risk appetite (which only business stakeholders can determine). If that linkage is not formally made or that appetite not assessed, IDS monitoring fails. None of the five analysis layers are inherently worth evaluating if a business context for them does not exist and most can’t even be evaluated at all without that context.

What provides this context? Business Security Architecture and Risk Management.

What’s interesting, though, is that these things don’t work when isolated to security, as the original blog post (and others) pointed out. If you limit the scope of your activities to “security”, you end up with the tire swing with no tree. You have to account for and model your entire business formally to achieve security, What this says is that business security architectures are, at a very real level, just business architectures. There is no material difference between the two.

But why would you need a full fledged business-wide process to get this information to you (or your analysts)? Because it’s really hard and expensive to do without the practice and culture in place enterprise-wide. You might brute force it and get your answers once without it, but trying to keep that information up to date would be completely futile.

In closing, I’d like to reiterate that I’ve only discussed business security architecture and operational risk management’s impacts technical security operations (looking up). Of at least as much importance is its role in aiding executive or management decision makers in correctly assessing and responding to risk. This is accomplished by providing a very clear line of sight from the trenches to business assets and risk appetite (looking down).

I’ve spammed this particular link everwhere else I can think of, but still neglected to post it here on my blog.

Basically, I was approached a few months ago by a senior editor of Symantec’s online magazine “Norton Today” because they were interested in doing a piece on Art and Security. I was approached because of my old work in security data visualization and the fact that’d I’d started to rework and hang the pieces in art shows like Artomatic and My Space on 7th.

Anyway, the interview went really well (in addition to being a lot of fun) and it’s now online at:

(Edit: This link now appears down after a few months. Symantec has republished the article here: )

They used a few older images in their Flash slideshow (My fault – I didnt get them newer images in time).  These were the originals we used at NetSec to do analysis and which have been in a number of presentations (and were in the batch I sent to ArcSight as examples when they were still developing Interactive Discovery, iirc).

You can find the “art” versions that I’ve hung up in galleries at the following link:

I’m still interested in working more of these, but have been moving from graphing – which was a necessity of the business at the time – into a broader field of ontological information/concept representation in art.

(This is in addition to my media experimentation with / interest in projection. I think Id like to merge these two tracks together in the future, but havent gotten there yet.)

Hey all!

I’m going to be showing some data visualizations at the My Space on 7th art show in Washington, DC starting Friday, July 11 at the Touchstone Gallery! Everyone should come out. I took a look at the space and there’s some interesting work hanging already. (And I have to thank Paige, here, who unintentionally helped me decide what to show…but more on that in a later post.)

Oh. And there will be wine tasting opening night. :)

There will be three old, but reworked images and one new one created just for this show.  Only one has ever been printed before and they all look pretty fantastic.

The new one consists of two superimposed graphs (a paraplot and a scatterplot) of illegitimate traffic going to/from “” (that would be, uh, most of it).

The three older ones are:

Destination Port Traffic Volume (global sample)

(Test Data from custom developed SEM correlation  modules)

(Pcap data from 10,000 spam emails)

About Me

Jack Whitsitt

Jack Whitsitt

National Cyber Security. Risk. Multi-Dimensional Rainbows. Maker of conceptual lenses. Artist. Facilitator. Educator. Past/Future Vagabond. Drinks Unicorn Tears.

Follow me on Twitter

My Art / Misc. Photo Stream






More Photos

Get every new post delivered to your Inbox.

Join 35 other followers