Earlier this year I worked on a document that addressed some of the common misconceptions about Scrutinizer. One of the subjects that caught my attention was Scrutinizer’s ability to mitigate insider threats. Honestly, I really wanted to dig deeper on all the subjects on my list, but the marketing team frowned on me passing along a hundred-page report when they were really looking or two-page fact sheet with links. As time passed, the idea of Scrutinizer’s ability to monitor, detect, and mitigate these types of threats kept on tugging at me. So when I got the opportunity to talk more about it, I jumped on it.
In today’s digital world, nothing is safe. Just today I came across this post that talks about hackers attacking network printers. It’s not far-fetched to think that your printers are a major cyberattack vector, but how can this type of attack affect your network? More importantly, how can you monitor for it?
Why should your endpoints be an important part of your network security strategy? Because even though they are out in the wild, endpoints are part of your network! We really should stop viewing endpoint devices as being separate from the rest of the network. The truth is, once an endpoint device connects to your network, it is part of your LAN/WAN and is a security concern. This means that each device with a remote connection creates a potential entry point for security threats.
In my spare time, limited as it might be, I have been taking a deep dive class on anonymous browsing. Specifically, it goes into great detail on ways to hide under the radar and on many of the legal aspects of both sides. So far the class has been right up my alley!
Net neutrality has been a big player in the business and technology news for the past few weeks. It’s clearly a controversial subject. From the sidelines, the biggest question seems to be, “How will service providers’ peering changes impact my business?”
This month I was working with a customer who was having a hard time understanding what AP MAC was being reported by Scrutinizer when using a Cisco Wireless LAN Controller. Honestly, I didn’t know everything that I needed to know about the subject so I decided to dig deeper and learn how our customers were using Cisco’s WLCs on their networks.
Sometimes, opportunity comes from necessity. In the past week I was working on a larger deployment that had multiple compliance concerns. One of the specific rules required that we provide a fault tolerant solution. As you might have guessed, this required me to document how Scrutinizer leverages our Flow Replicator to provide the required fault tolerance. So when it came time to write my blog, it seemed logical to take the information that I gathered and share it with our blog community!
In the past, network admins used packet capture technology to dig down into what was happening on their network. For troubleshooting general networking issues, this was good. But networks grew, issues became global, and security became a main player in an admin’s day. Sadly, this growth presented some problems with using packet capture technology.
I love working with schools. I love seeing young students exploring technology that I could only dream about when I was younger. (In some ways, I guess that is why I live by a major university here in North Carolina.) So when I am scheduled to meet with a school, I know that it is going to be an exciting call. Yesterday was no exception.
I was working with an evaluator the other day who needed an example of how to use the Scrutinizer API to generate data and export it to a CSV file. Honestly, I knew how the API functioned, but didn’t have much experience using it. With that in mind and being the daredevil that I am, I figured this evaluator’s request would be the perfect opportunity to roll up my sleeves and get my hands dirty.