I came into the network security monitoring mission from an infrastructure management role. I was 'that guy' who might block ACL changes if the word 'any' occurred twice in the same line, insisting that the systems and development crew be more specific with application traffic flow. Security, for me, was an aspect of my work. The company that I worked for at the time would gladly allocate loads of cash for a great firewall or UTM device or some snazzy application delivery equipment, but it was a hard sell getting my hands on commercial detective tools. The spectrum of solutions that I had to sell to management, easiest to hardest, looked like this:
- Application delivery (makes us money)
- Preventative tools (keep the bad guys out)
- Monitoring tools (tells us what gets past the preventative tools)
So for monitoring tools I typically had to make do with what the Open Source world had to offer... which in my earlier infrastructure management days led to some interesting integration work and some of the worst cases of scope creep I've ever inflicted upon myself. I have a soft spot in my heart for infrastructure work - building a better, more elegant solution every time kept me coming into the office. Thus I built my security knowledge in the same vein, as an extension of what I learned in the infrastructure space.
So you may ask: now that you’ve inherited security duties alongside your regular regimen of network operations monitoring and maintenance. How do you work it into your daily routine along with everything else? Is it possible to incorporate security monitoring alongside all the other responsibilities you already have?
The answer is ‘Yes’.
In a very basic sense, the ultimate goal of a network operations administrator is to keep the company from losing money as a result of poor infrastructure performance or downtime. The goal of a security practitioner is to protect the company against financial loss through data corruption or theft and service outages as a result of malicious activity. So it’s “prevention of downtime” and “protection of data”. These two goals do seem to converge. Since these are twin and complementary goals, wouldn’t it be nice if the tools to achieve them were similar?
While the tooling isn’t identical, there is A LOT of overlap, especially when it comes to network security monitoring. Network security monitoring tools include technologies like NMAP to discover systems and the services running on them, as well as OpenVAS to discover vulnerabilities associated with the systems on your network. Next, you'll need intrusion detection system software like Snort (IDS and host-based IDS), log analysis and event correlation tools like SIEM to trigger alarms that require more investigation. Finally, you'll use netflow analysis and packet capture tools for in-depth analysis of the relevant traffic once an incident investigation starts. You'll also need access to the raw log data for specific incidents.
What would you do?
Here's a hypothetical (and believable) example of how a good SIEM tool can work for an infrastructure engineer who's inherited security responsibilities:
Background: A Web Developer in your company has control of a public-facing SFTP server, which is being used to move sensitive data in and out of the Company. You know that it's not the best solution, but the business agrees to own the risk.
Risk: If this data is exfiltrated it could have a deep, immediate, very negative financial impact on the Company.
Choose Your Own Adventure:
- Upon setting up the machine and before handoff to the Web Developer, you install the OSSEC agent for host-based intrusion detection and log delivery, and point it at your AlienVault USM.
- Hand it off and let the Web Developer concern himself with the security of the system and protection of the data.
Scenario: Outside entity deposits Sensitive Data onto SFTP server. Internal resources retrieve it but don't delete the file, so there it remains. An automated scanning host on the Internet picks up that SSH is open and starts trying to brute force the root account. If you chose option 1, you have an alarm in AlienVault that there is a host trying to brute-force the SFTP server within seconds of the commencement of the attack. You approach the Web Developer and work to secure the box by disabling the root account, limiting the public IPs that can access the machine and enforce some data purging policies. If you chose option 2, you find out weeks later from your ISP that you have a spamming host on one of your public IPs. Guess what- you may have an exfiltration event on your hands.
Outcome: Scenario 1 leads to an education opportunity for the Web Developer. Scenario 2 leads down a darker path, one that involves a degradation of the Company's email service and an investigation to see if any data made it into the wrong hands. With a moment's worth of work installing the OSSEC agent on the SFTP server, you've been able to foresee and prevent a service degradation and a security breach.
This sounds like a lot of complicated technology, and it can be if you're trying to string it all together from different products. Thankfully, AlienVault USM and OSSIM offer all of the network security monitoring technology you need to monitor the availability of network operations, and assure that data is protected. You can check out our free trial to try it for yourself.
What many customers I work with mention when they first start using USM was how they immediately gained an intimate understanding of their company’s infrastructure, and they started to see all the holes. Whether they’re design flaws or necessary for doing business, there they are staring you in the face. The challenge is to identify which of those "holes" will be one an attacker chooses to exploit, and that's a whole other topic on its own. I'll spend the next few blog posts talking about various aspects of network security monitoring, and how to put tools like log analysis and event correlation to work for you - so you can avoid surprises and keep the lights on. In the meantime, stay focused on the essentials.