In my last post, titled Network Visibility: Using Dashboards to Tell a Deeper Story, we discussed how the dashboard feature of Scrutinizer can be an asset to multiple departments. I’ve had the opportunity to work with clients who had a one- or two-person shop and some who had multiple departments. There has been one common thing across all these deployments: by employing the features of the dashboard engine, they were able to reduce the time it takes to find what they are looking for. In this section, we will explore the network security department.
When it comes to network traffic monitoring, a single and unified view of your networking infrastructure is essential in ensuring that your environment is correctly watched over. It’s common to have hundreds, if not thousands, of routing and optimizing devices in today’s global networks. This tends to make monitoring things like traffic load, application usage, host usage, and more a mission-critical feature.
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.