SANS GMON / SEC511 Review

I completed my SANS GMON / Continuous Monitoring certification. I’m pleased with the process.

My training history is a web app course at DerbyCon (amazing for the cost) in 2011 or so, Tao Security‘s old Black Hat course on security monitoring and the Black Hat version of Offensive Countermeasures, both at Black Hat 2010? Offensive Countermeasures was interesting, but I’ve never been in an environment I could apply any of it.

SANS SEC511 felt like a five day version of Tao Security’s course. I wish this course had existed when I was new.

SEC511 covered a wide range of tools you’d likely encounter in an enterprise and the labs covered some of the more functional open source alternatives. It just seemed to make sense. BroBro is a must for security monitoring while ModSecurity is a bit of a bastard to work with and less likely to provide value in most environments.

The exam was more tailored around understanding the tools and designing a functioning environment for monitoring. I was concerned the test was going to be a memory game of understanding the various flags in tools.

If you’re reading this and are concerned about the test, @Hacks4Pancakes guide for SANS on her website is fantastic.

BSidesLV 2016 – Pros Versus Joes

I participated in the Pros V Joes CTF competition at BSides Las Vegas this year. It was intense.

The setup on day one is that you are a member of a blue team entering a compromised environment. You have multiple tasks: respond to service requests, maintain uptime for a couple services such as WordPress and ftp, find artifacts left behind by the attackers, and repel new attacks. The attackers don’t attack for the first two hours.

The environment was very well designed. We had vSphere to see most systems. There was a nice mix of Windows end point and server versions, a few Linux systems, an Asterisk PBX, and a pfSense firewall. I’m happy it was a pfSense firewall. I’m told they used Cisco ASA in previous years. The ASA is extremely rough to manage, I’d prefer to never see one again.

We started by doing network discovery, patching, and checking configurations. We also started responding to customer requests via calls, tickets, and emails. The tickets were all pretty basic and represented real world requests in this situation. Through network discovery, we found a few systems the customer neglected to mention to us.

Our failing was our lack of experience with Asterisk. We focused on other systems as we knew those systems. The red team immediately hit it when they were able to attack and took it down. While the phone wasn’t under SLA, we couldn’t receive tickets via phone and started receiving email tickets asking us to fix the phone system.

Day two was a repeat of the day one environment with some minor changes. A member of the read team would join us and we would be battling the other blue teams. We could start attacking each other immediately. Given the results of day one, the PBX was the main target. Everyone’s PBX immediately went down. I’d suggested a strategy of immediately blocking the Internet from our environment and taking the SLA hit while we patched. We decided against the strategy, hoping we could remediate fast enough.

Would I participate again: Yes!

Reviewing Splunk For Enterprise Security

I gave a brief presentation on using Splunk for Enterprise Security after having used Splunk for a while.  Here is a summary of my thoughts:

Splunk for Enterprise Security seems to primary be two things.  A ticketing system and a investigation system.

The ticketing system is alright.  I’d already had Splunk integrated in to an enterprise ticketing system.  From the ticketing perspective, Splunk ES is relatively weak.  Alerting / notifications and metric tracking leave a lot to be desired.

The investigation system is built on two explorer dashboards, one for identities and one for assets.  If I view an asset for example, Splunk ES can show Windows events, IDS events, and firewall events all in a single dashboard.  It is very polished.  I’d suspect an organization further along in Splunk may already have a home brew version of this.  My previous environment had something in the infant stages of this.

Splunk for Enterprise Security is heavily built on data models.  I’d argue the Knowledge Object course is more useful to a security practitioner than the Using Enterprise Security or Administering Enterprise Security course.  If you’ve already been using Splunk for a while, you likely already have dashboards and alerts with functionality similar to Splunk for Enterprise Security.  The ES training seemed focused on understanding the dashboards more than understanding the underlying Splunk ES architecture.

If you’ve been using Splunk for a few years, Enterprise Security isn’t going to wow you.  You’ve already got plenty of alerts and dashboards to compete with the package out of the box.  It will however allow you to build much better searches going forward.  Having used it for a few months, I have correlations in Splunk ES that I doubt I could have ever written as alerts in Splunk.

When do you move on?

I am shifting industries.  The first 6 years of my information security career have been in steel manufacturing.  I’ve accepted a job securing an organization in the medical sector.  This should be interesting.

My current employer has on site medical facilities.  I’m familiar with their demands, though they were primarily Citrix and your basic medical equipment.  It’s been a long time since the operating rooms have been active at the mills, though operating rooms (and morgues) exist at the facilities.

I’m ready for the challenge.

Steel Mills & Air Gaps

By now every has read that a German steel company suffered a cyber attack.  There isn’t really much to say about the attack itself.  We don’t have any good information.  How did the attackers get in, what systems were being used by the mill, etc?

Benjamin Sonntag, a software developer and digital rights activist, told Reuters: “We do not expect a nuclear power plant or steel plant to be connected to the internet.”

Power plants are regulated.  They have NERC to ensure there is at least a base level of security.  Much like PCI compliance, there are plenty of interesting interpretations of the rules for maintaining compliance that organizations use.  Metal production lacks any regulation.

I’m hoping Benjamin’s original statement was longer and the BBC cut him short.  Mills are all connected to the internet in some capacity.  For a background on the metal industry, it is in extremely rough shape and has been going through consolidation.  Mills are constantly shutting down as efficiency is gained.  Metal is a critical sector of the economy, so governments prop up manufacturers through tariffs or subsidies.

Given the organizations have limited financial resources, a strong degree of arrogance (the government needs us), and no regulations, security is extremely lax.  Most mills have a basic degree of segmentation, but there are issues.  Our argument is to segment production systems, but what does that mean?

The production network may be secure, but the process monitoring could be on the business network.  A producer is unlikely to have the people to run a process while the monitoring is down.  Sure, it theoretically can run safe, but do you really want to test that when it could lead to catastrophic results?

Much like we in the security industry are outsourcing, so are metal manufacturers.  We have our MSSPs and appliances that connect out for updates and health checks.  Production systems do the same thing.  These organizations have tunnels or direct links to various contracted companies.  How secure are these tunnels?  Target was breached via an HVAC vendor.  Most of these companies have extremely strong connections to their suppliers and customers to the point that some share the same facility.  Extracting (mining) companies, shipping companies (boat / rail / road), pre-processing, byproducts, support services, and customers may share the same plot of land for larger operations.

Medium Difficulty Security

I have been thinking about the PaulDotCom argument that good security is hard. Obviously it is. Application Whitelisting is way harder than AntiVirus from a deployment perspective. I’m going to try some compromises that are medium difficulty. My goal is for these to be a stepping stone towards the hard changes.

My first change is implementing honey IP ranges and honey DNS entries as a stepping stone towards full honeypots. I’ve already got the easy monitors for network scanning. They are pretty worthless. I entered requests to get a couple blocks of IP ranges reserved across the network. I asked for ranges mixed in to various user environments, server evironments, etc. I’ve also got DNS entries reserved. Some are straight from the dnsrecon list, others are custom based on the business as well as key employees. I don’t have honeypots yet, but this seems like a decent start.

My second change is that I’m investigating web filter whitelisting for non-standard domains. I’ve already got the dynamic services (no-IP, dyndns) blocked with a few exceptions. My next step is going to be to do the same for the under-used TLDs. If it isn’t com, net, edu, gov, or mil, I am considering a whitelisting approach. So for instance, we have no business in Libya. Ly will be blocked with the exception of