While investigating our SD-WAN value proposition with customers, I worked with one client who has Cisco IWAN for 250 branches uses Scrutinizer to monitor it all. I learned from the customer that they had to have the following SD-WAN performance reports.
Despite the hundreds of billions spent by companies over the last several years, malware continues to infect our networks, sabotage our systems and steal our intellectual property. Even with repeated failures, the investment continues to climb. Read more
Correlating NetFlow with RADIUS Usernames to improve context security awareness is something we have done for several vendors including Cisco ISE, Microsoft Network Policy Server, Forescouts CounterACT and others. Even with all of these supported, we still get approached with yet another RADIUS system that the customer wants us to pull usernames from and of course they want them correlated with the IP addresses found in the NetFlow and IPFIX we collect.
The good news is that we can do it. The other good news is that it’s relatively easy to do but, it does require some work. The caveat is that it will have to be assessed on a case by case basis. Most of the time, free solutions like FreeRADIUS and OpenRADIUS and commercial solutions like Cisco Prime will log the data to a file which is a big help.
In the logs we have reviewed, we’ve noticed that most are in a unique format. Some are one line in quoted CSV, others are multiple lines. And others like Cisco Prime don’t have all the details we need unless the log is set to trace mode. The kind of log we prefer to work with is called the “accounting log”. Which needs the following data in order for us to add username support more broadly:
- The client’s IP Address, FRAMED-IP-ADDRESS: Typically, the IP address of the dial-in host is not communicated to the RADIUS server until after successful user authentication. Communicating the device IP address to the server in the RADIUS access request allows other applications to take advantage of that information.
- User-Name: This is the username making the request regardless of whether the authentication is pass or fail. If we want to narrow it down, we could only export a flow if authentication passes via the Account-Response event which should be in the log.
- The Log must contain both the request and response requests
How it will Work
We use software that provides a modified tail mode which will watch an accounting log. It provides the intelligence to understand variations in the log format (E.g. single vs. multiline). It then extracts the data out. This process has to be done on a case by case basis in order to add support for a customer’s unique RADIUS solution.
Questions we get Asked
Q: Can Scrutinizer integrate with our RADIUS server?
A: Most likely. Can we have a copy of your RADIUS accounting log?
Q: Can Scrutinizer support the syslogs our RADIUS server can send?
A: Most likely. Can we get a sample of these syslogs?
Q: Our solutions sends data as Microsoft eventlogs. Can Scrutinizer support it?
A: Yes, our current release recognizes those eventlogs.
If you don’t need all of the technical detail, the bottom line is if you are ready to start correlating NetFlow with RADIUS usernames, we can help. Reach out to our team and be ready to share some sample data if we are being asked to support something we haven’t seen before.
It’s pretty safe to say that most users are well aware that companies like Google, Facebook, LinkedIn and hundreds of others are harvesting data out of their customer’s end user devices. What many aren’t aware of is that you don’t even need to be visiting their web sites or actively using their services for them to be constantly streaming data from your Internet connected device. Read more
When many of us think about malware, words like ransomware and key loggers immediately come to mind. Although these types of contagions can certainly be disruptive, an even bigger concern is an advanced persistent threat (APT). These types of insurgencies are not looking for the quick buck turnaround. In contrast to mom and pop malware, the APT goal is generally to get in, setup camp and spread by moving laterally within the organization. Rather than making the host suffer for a onetime event, the APT is in it for the long haul.
Advanced Persistent Threats
The reason the APT wants to stay inside an organization indefinitely is to perform reconnaissance for the command and control servers. They might search for files locally that contain certain names. They might log key strokes, read emails and look for intellectual property that may provide value to someone on the black market. Generally and APT isn’t interested in disrupting business as usual but, rather they want to compromise the intellectual property that makes the company valuable.
In order to find desired information, the infection needs to spread to other machines that can assist in the overall information gathering effort. To do this, the malware may take advantage of mapped drives or reach out to other machines the local host commonly connects to and this generally requires login credentials.
In the Verizon “2017 Data Breach Investigations Report” it was reported that 81% of hacking-related breaches leveraged either stolen and/or weak passwords.
Tracking Malware Lateral Movement
With a very high volume of lateral movements requiring authentication credentials, it became obvious to us that we needed to somehow monitor for authentications that appear out of the norm. As a result, we started maintaining a baseline of every username in the company as well as the corresponding machines that it authenticates to. Before we started triggering for changes in what employees were authenticating to we decided to allow for moderate changes over time. This lead to a baseline structure that can evolve as behaviors change however, for variances that are much larger than allowed thresholds, we can trigger events that lead to alarms and notifications.
Below is an example of the hosts that a single username has authenticated to:
Building in the above functionality into our flow collector was a logical progression for our Flow Analytics behavior monitoring system. Since we already integrate with Cisco ISE, Microsoft Active Directory, CounterACT, LDAP, Radius and others to gather usernames to IP address pairs, keeping track of who is authenticating to what over time was a relatively simple value add. It also brings significant value to our customer base.
Building a Behavior Baseline
By learning over a period of days or weeks – who is authenticating to what on a fairly regular basis, we can then start to recognize authentication behaviors that appear irregular or beyond a threshold of tolerance which of course triggers events. Now you can begin to see that once we have the data, we can start discovering what could be malware movement within the company.
Start Discovering Malware Movement
With the lions share of the most insidious forms of infections using stolen credentials for malware lateral movement, it seems obvious that corporations need to move toward some sort of authentication name and IP address pair behavior monitoring. Reach out to our team to learn more about this progressive strategy for uncovering how 81% of the malware on the market is spreading on internal networks.