Data security is a constant challenge for most organizations, but leveraging your IT management data can make it easier
Data security improvements can be an expensive necessity, but there are ways to make those improvements for free using your network and systems management data.
While your network and systems management platform can’t replace your SIEM or IDS, making these improvements can improve your efficiency in a variety of valuable ways.
- Due to the different specializations of the software, management data-based security has strengths that many security platforms lack in a cheap or easily accessible manner.
- Some of the benefits discussed below may also be possible with IDS, but no one has their IDS operating on every single port in their environment.
- Using existing tools instead of new ones reduces labor burden, allowing you to save time and money on training, maintenance, and administrative overhead.
- Further, integrating security functionality into your overall IT management platform can go a long way to improving overall security awareness in your command center. This also can reduce the time required to respond to security incidents by increasing visibility across multiple teams.
- This is especially effective if you integrate your SIEM, IDS, and IPS alerts directly into your main command center console. The Netreo platform provides some very simple web-based APIs to make this really easy.
5 Ways to Improve Data Security
1. Watch network traffic for unusual behavior.
If you monitor down to the individual switch port level, which we always recommend, you’ll have very granular data that can be used to spot changes in behavior.
A sudden spike in traffic can be an easy way to spot an infected system or one that’s starting to perform network scans or other kinds of reconnaissance. To make sure you don’t miss anything, you monitor the access switch ports too. This lets you keep an eye on end-user systems without the overhead and hassle of installing end-point monitoring software on every system. Additionally, this can even help find issues that the endpoint monitoring could miss if the intruder can disable or evade it.
Looking for sudden spikes in inbound traffic from the perspective of the switch is a great way to find the sources of this kind of traffic, and you can even track it across multiple switches, routers, and firewalls.
A long term change in overall traffic levels, or a big jump in background traffic levels is a clear indication that the system is now being used differently. So, the question then becomes if this change in behavior is explicable. We have one customer who used this method to discover that an IT worker had begun running backups of their database to his local hard drive. You can better believe they had a good talk with him about proper backup process and data security.
In order to find this unusual behavior, you will need to have a way to spot it without constantly generating manual baselines. After all, a huge spike in traffic on a specific day of the month might be totally normal for the system. Netreo solves this problem with our anomaly detection technology.
Netreo keeps a lot of high-resolution telemetry and statistics for this data, which is leveraged to automatically generate a baseline behavior model. We then compare current behavior with what is normal for the time of day, day of the week, or other time-based measurement. You can set the sensitivity to high, medium, or low, depending on your tolerances and environment, and what the usual range of that statistic is, to fine-tune the process. You can also run this data manually, on demand.
That information is then used to detect when something unusual is happening, and we can flag that as an anomaly that can then generate alerts or reports. This allows you to find those unexpected behaviors, and be notified about them or push them to your SIEM for analysis.
You also want to watch what’s happening between the devices. In addition to looking for anomalies in overall bandwidth, you can also use the data to monitor network-layer constructs like Quality of Service (QoS) and VRF instances. This extends your visibility into finding things like QoS misconfigurations where you’re sending traffic into the wrong queue. It also allows you to find traffic that’s been sent across the wrong VRF; which could be a security problem even if it’s not an active intrusion and gives us another place to look for unusual traffic, especially if it’s coming from many separate sources.
2. Leverage the anomaly detection technology at the process level.
Netreo watches each running process on every monitored system and records the CPU usage, memory usage, and a total number of processes, 24 hours a day, 7 days a week. When you extend the anomaly detection to that level as well, it is extremely helpful.
One of the obvious data points to monitor is the total number of running processes or new running processes. Being notified as soon as a new process appears on a system can be a great indicator that some investigation is needed. This is especially true if your current IDS/IPS doesn’t extend into the server OS level, which a lot of companies can’t afford. It’s also important to consider that not all IDS systems would flag it, such as when a server suddenly starts running a browser or installer.
You should also watch for sudden changes in CPU or memory usage by an existing process. This is often a good idea for performance reasons anyway. Nevertheless, if there’s a spike in SQL CPU usage beyond what’s normal for that time of day, it could indicate a surge in unauthorized login attempts.
You can also watch other kinds of process behaviors, like the number of database queries or locks or the number of logged-in users, as unusual activity there can also be a potential security issue you’d want to investigate.
3. Monitor logging anomalies
While doing so is often the realm of your SIEM, there are some things you can do here that might help to supplement that using anomaly detection. Watching every single possible log message – and trying to flag the ones that might mean a problem – is usually too noisy and difficult to do well. Additionally, the firewall logs are probably already being processed by the SIEM. So the way that you watch them is by doing things like looking for statistical anomalies in the log.
Sudden spikes in the total volume of logs produced can indicate all kinds of things, including security issues, brute-force attacks, or even just software bugs causing problems. Since you’re watching the number of log messages as well as the type, this gives you an interesting perspective to look for unusual behaviors. And of course, you can still drill into the log messages themselves in order to troubleshoot or do forensics once the system has flagged an anomaly.
You can also create rules to filter the log messages you’re monitoring. If you want to count just the login failure messages, for example, you could easily do that as well.
You can create static thresholds to spot when things are going completely off the rails, but anomalies are easier to use. If the application has a huge spike of logins every Monday morning, but almost none on Friday, creating a static alert isn’t going to work very well when there’s a sudden spike on a Friday due to a compromised credential.
4. Using configuration management data for security
This might seem like an obvious one, but even if you’re already using configuration management data, there are a few key points to making sure it’s part of the security process. The first question to ask is where those change alerts are going. Is it to the network team, or security team, or both? What about change management data?
This is especially important for watching changes to your firewall configurations. It sounds obvious but you’d be surprised how often this doesn’t happen. Sometimes it’s just because the security team and the network team aren’t communicating well. But having everyone aware of when – and what – is changing in device configurations can save a lot of troubleshooting time.
Pay special attention to when these configuration change alerts are happening. Do you have pre-defined and approved change windows? You might want to pay special attention to any that are coming in outside those windows.
You should also make sure that you’ve integrated these alerts with your SIEM or ticketing system.
Most importantly, ascertain that every time a configuration change alert comes in it’s being audited and reviewed against your change control process so that you know that unapproved changes aren’t getting made to your infrastructure or firewalls.
5. Watching Traffic Flow Data
You can use technologies already built into your infrastructure devices like Netflow or IPFIX to gather information about who exactly is talking to whom on the network, and what protocols are in use.
Watching for the sudden appearance of new protocols on the network is a great way to keep aware of what’s going on in the environment. However, this can be a little tricky in larger environments. For instance, you might have teams deploying new applications on a near-constant basis, and if you don’t have good change control communication, you may not always know when new applications are coming online.
One of the easy things to look for is spikes in control type traffic, as these are definitely red flags that something is not right. This could be a sudden surge in routing updates, ICMP traffic, DNS requests, or even an unexpected spike in VPN traffic. Maybe a remote worker is downloading data to work offline, or maybe he’s copying the customer database to sell to a competitor – either way, it’s worth looking into.
Monitoring your application response times
Monitoring your application response times doesn’t at first seem to have a security implication, but it definitely can. Brute force attacks or DDoS attacks can cause your application to slow down, and this data can be correlated with other server performance metrics to see if the traffic is legitimate or not.
This is especially important for cloud-hosted systems, as we might not have deep access to server-level information. In many hosting environments, you may have no OS visibility at all, so managing the top-layer performance is the only real metric you have to work with, depending on how your application is instrumented.
Cloud providers often build in some level of DDoS protection, but rarely provide any protection against brute force or password replay style attacks. So, you can’t control – or in most cases, even see – all of the traffic to and from the system.
An easy way to do this is to use anomaly detection to watch for sudden changes in response time. This can also be a great performance data management tool, as well.
See the big picture
Once you have all this great data, you need to make sure you’re sharing it. By making the data available to everyone in the value stream, everyone shares a common view of reality, which aids in communications, and demonstrates transparency, which enhances trust.
A big key to making this successful is to make it easy and quick to access the information. Teams won’t feel like they need to have their own monitoring, which can create a lot of alert noise and redundant effort, as well as creating admin, support, and maintenance spend issues.
If the audience is non-technical (and there are always some non-technical people to keep in the loop), don’t hesitate to simplify or abstract the data into easier to understand formats. One way to do this is with our business workflow views, which allow you to roll an entire application and all its component parts into a single percentage score.
Sharing this data can take a number of forms, depending on what works for your environment. APIs, common share pages or intranet pages, unauthenticated status pages, and information radiators.
An information radiator is just a system designed to display important status information in a public area. For example, a monitor on the wall of a hallway everyone walks through. The team can display application views, or more technical ones depending on the audience. This allows you to keep all the teams in sync, not just for status data, but also useful operational metrics like response time or transaction velocity.
Using information radiators also allows us to actively demonstrate core values such as that the team has nothing to hide from visitors (customers, stakeholders, etc.), and has nothing to hide from itself. It acknowledges and confronts problems.
Integrating with SIEM tools
One of the things we have talked about is integrating all this data with your SIEM, and rolling security alerts into your dashboards. For inbound alerts from the SIEM, this is easy. Netreo has a very simple API available that will let your other systems ‘push’ alerts directly into our platform that you can then display on custom dashboards and views. This can also be integrated into all of your command center operations.
For integrating outbound messages, for example, configuration change alerts or anomaly alarms, you have a number of different choices. You can use webhooks, JSON, or even email messages, Syslog, or SNMP traps, if that’s all your platform can support.
We provide a simple way to edit the format of these messages, so you can make sure they’re customized into a format that your SIEM can easily process and parse. You can also include a wide variety of information in those messages; including documentation information like serial numbers, asset tags, run-book information, or on-site responsible contact information.
You can then use our incident data management rules to control how these messages are routed, and even control that depending on the type of message, the time of day, or the day of the week. Request Netreo’s IT Infrastructure Management Platform demo and see how you can improve your company’s security!
