Who has the time, right?
You might laugh but the truth is, in the past few weeks you have become the guru of everything VPN on your company’s network. Questions are coming in left and right, and with a little time you have been able to dig into the data to find out who were your top VPN users, what applications they were using, and how your VPNs have been holding up.
Read moreWe’re all feeling it.
As a confident NetOps leader, you’ve made sure your business continuity plan had allowances for remote workers but BAM: in the blink of an eye, your company’s work-from-home policies became mandatory for everyone and your battleship of a plan now feels like it’s taking on water.
Read moreLast month the FBI posted ALERT AC-000113-TT, which mentions an increase in unidentified cyber actors exploiting a known SharePoint vulnerability to gain access to unprotected networks. The CVE-2019-1491 vulnerability was found late last year and Microsoft posted an out-of-band patch soon after. The FBI soon raised the alert after it received reports that multiple municipalities here in the states had been compromised.
Read moreSo far we have used the Scrutinizer API to build a dataset that tells us how many hits our top ten countries are getting. Next, we’ll explore how easy it is to use this data to populate an open source digital heat/attack map.
Read moreEvery once in a while I get the opportunity to sit down and work on things that are outside of the box when it comes to Scrutinizer. Well, this month was the perfect one for that. For a long time, I’ve wanted to create a geolocation-based heatmap of countries that are being visited on the network. Honestly, I have always had a fondness for heatmaps and attack maps, specifically geo-heatmaps. With that in mind, I decided to build a script that outputs countries and their hits. I’ll then take that data and populate an open source digital heat/attack map.
Read moreThe requirements of GDPR can be vague sometimes. I have had quite a few of my customers ask how we help companies with questions about GDPR compliance. Here are the three Scrutinizer abilities that they found to be the most valuable.
In Bob Noel’s post, “Three GDPR Requirements That Will Have a Big Impact on Your Organization,” the section on role definitions appears the be the most relevant to Scrutinizer.
Limiting what a user can see in Scrutinizer is relatively easy. Just click on Admin (1) > Security (2) > Users. Here, you can create users and define what group permissions (3) they have. You can also determine which authentication engine is used.
Under the User Group option, you can limit what members of that group can see.
Data Protection Officers can use Scrutinizer’s filtering engine, report designer, or IP groups to hide non-local host information from the user (or vice versa). This prevents network administrators from being able to visualize the remote hosts a local host is talking with. This hides sensitive information such as the site being contacted, but it allows you to keep an eye on the local network activities (i.e. those that are under your administrative domain).
As mentioned in the GDPR post by Bob Noel, being able to report on who has access to Scrutinizer and what they did is one of the requirements. If you click on Admin > Security > Audit Reporting, you can view and filter the audit logs.
In addition, the syslog server settings (Admin > Settings > Syslog Server) tell Scrutinizer to forward all internal alarms to an external syslog server/SIEM. For GDPR compliance, select the “Forward Access Log” option. That will provide a full account of all user actions, reports run, and filters applied in Scrutinizer.
GDPR requires that at any time, a user can ask that any information on them be deleted from the database. The administrator of Scrutinizer can delete information from the Scrutinizer database via SQL command line. We are investigating ways to provide a simple way to do this via the GUI or possibly command line.
If your requirements include improving your network monitoring posture, gaining deeper visibility, and meeting GDPR compliance, but you don’t know where to start, why not evaluate Scrutinizer?
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?
