Asset management is one of the core components of many successful security programs. I am an advisor to Panaseer, a startup in the continuous compliance management space. I recently co-authored a blog post on my favorite security metric that is related to asset management:

How many assets are in the environment?

A simple number. A number that tells a complex story though if collected over time. A metric also that has a vast number of derivatives that are important to understand and one that has its challenges to be collected correctly. Just think about how you’d know how many assets there are at every moment in time? How do you collect that information in real-time?

The metric is also great to start with to then break it down along additional dimensions. For example:

• How many assets are managed versus unmanaged (e.g., IOT devices)
• Who are the owners of the assets and how many assets can we assign an owner for?
• What does the metric look like broken down by operating system, by business unit, by department, by assets that have control violations, etc.
• Where is the asset located?
• Who is using the asset?

And then, as with any metric, we can look at the metrics not just as a single instance in time, but we can put them into context and learn more about our asset landscape:

• How does the number behave over time? Any trends or seasonalities?
• Can we learn the uncertainty associated with the metric itself? Or in other terms, what’s the error range?
• Can we predict the asset landscape into the future?
• Are there certain behavioral patterns around when we see the assets on the network?

I am just scratching the surface of this metric. Read the full blog post to learn more and explore how continuous compliance monitoring can help you get your IT environment under control.

The Applied Security Visualization book is DONE and available in your favorite store!

Last Tuesday when I arrived at BlackHat, I walked straight up to the book store. And there it was! I held it in my hands for the first time. I have to say, it was a really emotional moment. Seeing the product of 1.5 years of work was just amazing. I am really happy with how the book turned out. The color insert in the middle is a real eye-catcher for people flipping through the book and it greatly helps making some of the graphs better interpretable.

I had a few copies to give away during BlackHat and DefCon. I am glad I was able to give copies to some people that have contributed by inspiring me, challenging me, or even giving me very specific use-cases that I collected in the book. Thanks everyone again! I really appreciate all your help.

People keep asking me what the next project is now that the book is out. Well, I am still busy. secviz.org is one of my projects. I am trying to get more people involved in the discussions and get more people to contribute graphs. Another project I am starting is to build out a training around the book, which I want to teach at security conferences. I have a few leads already for that. Drop me a note if you would be interested in taking such a training. Maybe I will also get some time to work on AfterGlow some more. I have a lot of ideas on that end…

During DefCon, I recorded a PodCast with Martin McKeay where I talk a little bit about the book.

I just finished reading the NIST 800-41 draft about “Guidelines on Firewalls and Firewall Policy“. The guideline does a great job of outlining the different types of firewalls that exist and how to correctly setup a firewall architecture.

The topic that falls fairly short is logging:

• Section 5.2.3 (Configuring Logging and Alerts) mentions logging very briefly.
• I am positively surprised that it mentions the logging of rule changes on the firewall, which is inherently hard in, for example, IPTables.
• NIST asks for storing the logs locally on the firewall. I don’t agree with that at all. I don’t care whether the logs are kept locally. What I really care about is that the logs are centrally collected. Or in a very small environment, that there are logs at all.
• I was really hoping that this was finally the document which would outline what to log exactly. What traffic should I be logging on the firewall? All the traffic? Just denied packets? Do you log on the incoming interface? And so on. None of these questions is addressed. Not even whether passed traffic should be logged at all. There should at least be some discussion around that.
• Log analysis is not mentioned either. I was hoping that aside from just logging recommendations, the guideline would quickly mention what to do with the log files. How do you use them? Are they meant mainly for forensic purposes or are they used for proactive analysis? This would help justify the storage cost of the logs and push some implementations to actually implement logging.

I sent this blog post to the authors of the guidelines. Hopefully they are going to address some of this. And again, the general structure and contents of NIST 800-41 are great!