SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox
Logging matters
As I start to test product for the upcoming NAC reviews, in-line NAC being the first of many, one thing strikes me as truly annoying???the lack of decent logging and reporting within network devices. Without good logging, there is no...
Mike Fratto
August 17, 2007
4 Min Read
As I start to test product for the upcoming NAC reviews, in-line NAC being the first of many, one thing strikes me as truly annoying???the lack of decent logging and reporting within network devices. Without good logging, there is no way to troubleshoot problems and that hampers my productivity and more importantly, support desks productivity. Like you, I deploy these products in a network and try to make them run. Sure, I deploy products in a ???test network???, but my ???test network??? is my production network. If my production network breaks, I have to fix it. If I can???t make products work, I can???t write reviews (while we sometimes joke about running reviews with one line ???This product blows???, that wouldn???t be responsible or fair.) I tend to break stuff a lot, so I get plenty of time to troubleshoot issues. A lot of IT people I talk to often don???t even look at logging during procurement and come to regret that. The product has to do what you want, that???s a given, but once you buy it, you have to live with it.
Troubleshooting is all about information. If you can???t discover what the problem is, you can???t troubleshoot it. The ???reboot??? only works on PC, network gear tends to come back just the way you left it. Troubleshooting is compounded when products, like NAC appliances rely on external services like authentication to function. I was testing a product (I won???t say who yet. Wait for the review to come out) that uses an AD server to authenticate users. When I tried to authenticate as a user, the product was telling me the authentication was denied. I tried several times, each time progressively slower, because I could have fat fingered the credentials. Hell, I may have fat fingered the credentials multiple times. After the fourth or fifth attempt???mind you I am now deliberately typing with one finger???I gave up and tried to see what the problem is by looking at the product logs. Maybe the appliance isn???t talking to the directory or some other configuration issue. And there was nothing. Zilch. So I called support and they confirmed that they don???t log that information. I wonder what else they don???t log. Could you see how a support call might go if one of your users couldn???t authenticate?
User: Hello, support, I am trying to login to this web page and it won???t let me.Support: Did you try your username password? Try again.User: I did that several times with the same response.Support: Huh, I don???t see any errors.
Bad, bad, bad. When you are building a tool that purposely gets in the way of network connectivity like NAC does, you absolutely must provide the tools to troubleshoot problems. Here???s a short list of troubleshooting requirements every NAC product should have:
Don???t call system logs audit logs: Audit logs record an irrefutable chain of events with sufficient detail that you can recreate in the future the exact same steps. System logs are log entries that may or may not provide enough detail for audit purposes. I can tell you, most security products don???t log the right information for audit purposes.
Detailed logs: If you don???t log it, administrators can???t see it. Log relevant information in a format that is useable. Debug logs, while detailed, are generally not useful. Heck, let the admin adjust the log detail on the fly.
Export those logs: many companies have existing log processing, so offloading that data elsewhere in a common format like syslog is a good idea. XML formats with clearly defined DTD???s and documentation are useful, but also means more integration effort is required.
Have robust filtering: Inclusive filters are fairly common and let administrators define just the log entries they want to see, but you have to know what to look for a priori. Exclusive filtering is a god-send to troubleshooting because it???s easier to filter out noise and whittle the logs down to the relevant entries rather than guess at what you want to see.
Create filter definitions: let users save filter definitions. There is no point in replicating complex filters over and over again.
Log clients centrally: If there is client software involved, try to log as much data to the appliance rather than the client. Do you really want users reading cryptic messages off a screen? Alternatively, make it simple to extract logs on the client that can be sent via email to support.
Those are just a few items off the top of my head. The take away is that products like NAC that can impede network connectivity must also make it easy to troubleshoot problems.
Read more about:
2007About the Author
You May Also Like
More Insights
