Tag Archive for: Tales from the Trenches

Tales from the Trenches: Vol 2 — They have access to WHAT?!

/by

Since 2004, RedSeal has helped our customers See and Secure their entire complex network. And while those customers may have understood the value of understanding their environment, how it was connected and see what’s at risk, there is often an “Aha” moment when the true significance is clear. The stories of these moments are lore within the walls of RedSeal. But these tales so clearly illustrate the value of RedSeal beyond just theory that we think they’re worth sharing. In the words of our team in the field, the ones working directly with our customers, this blog series will share the moments where it all gets real.

In this edition of the series, Nate Cash, Senior Director, Federal Professional Services/ Director of Information Security at RedSeal looks at a unique application for RedSeal, eliminating potential threats before they could happen.

They have access to WHAT?!

I’m always surprised at the new use-cases we come up with on site with RedSeal. There is a lot of information about a customer’s environment that allows us to answer questions pretty easily, if you know where to look. One Monday morning as I showed up to the office, before I was able to grab coffee, a SOC analyst stopped me at the door to ask me a very simple question, “We have a bunch of site-to-site VPNs with a few business partners, what can they access?”

On the surface this seems like a simple request, “How quickly do you need this information?” I responded. “Last Saturday.” Suddenly the caffeine rush I needed seemed like a long ways off. Turns out, one of the business partners of this customer was breached over the weekend and they notified this customer of the potential. The SOC had been manually mapping out the configs and drawing the paths on the white board, when I came in.

Staring at the board I thought, “There has to be a better way.” When the eureka moment happened. I fired up RedSeal and found the devices which lead to the business partners. In order to map across the VPN tunnels, we needed the config files from the other end. Of course, our business partners were not going to give that up, so I took the configs from our end, and reversed the ACLs changed the IPs based on the tunnel configs and reimported them into RedSeal.

10 min later we were able to answer the question, “what does this business partner have access to?” the answer, 1 server in the DC on 3 ports. But that one server had access to over 20 other servers which increased the downstream risk. This was a fun exercise where we got to see the power of RedSeal and how it can be used to quantify the real risk to the organization and reduce it by putting controls into place.

Once the incident was contained, we decided to go through, and hand jam the rest of the business partners VPN configurations into the model so the SOC would have this information in the event another partner was compromised. After writing up the configs and placing them into the model we found a couple of business partners with configurations that allowed any traffic on any port across.

Firewall engineers know, that sometimes during troubleshooting they’ll configure a device to allow anything across and verify that the firewall is or is not blocking an application. My theory is that these two partners were having issues with traffic going across or getting the VPN tunnel up, and put these rules in as placeholders, probably around two or three A.M. and when things “worked” they were going to come back later to fix them, and never got the time.

But this exercise allowed us to find a major security misconfiguration. If one of those two business partners with the ‘allow any traffic’ were the ones compromised over the weekend this story would have had a much different outcome. In security having a complete picture of your environment is key to being secure. What you don’t know can hurt you.

Interested in how RedSeal can help your team? Click here to set up a demo or an introductory call.  

Tales from the Trenches: Vol 1 — In security, consistency is key.

/by

Since 2004, RedSeal has helped our customers See and Secure their entire complex network. And while those customers may have understood the value of understanding their environment, how it was connected and see what’s at risk, there is often an “Aha” moment when the true significance is clear. The stories of these moments are lore within the walls of RedSeal. But these tales so clearly illustrate the value of RedSeal beyond just theory that we think they’re worth sharing. In the words of our team in the field, the ones working directly with our customers, this blog series will share the moments where it all gets real.

The first in this series is by Nate Cash, Senior Director, Federal Professional Services/ Director of Information Security at RedSeal.

In security, consistency is key.

Once at a customer site while going through the install of RedSeal, we were going over the hardening standards. I clicked on a couple of configurations to start showing how we could go about setting up best practice checks. I had inadvertently pulled up a device which has not been updated in over five years. The customer was shocked, this is one of the many times where I have had to stop mid-sentence while the person I worked with, reached out to someone to “fix the problem.”

The problem is not the fact the device is had not been updated, but somehow their process missed it. This device was just one of many. The first thing we did with RedSeal was develop a set of custom checks to see how many devices passed or failed the latest hardening standard. Once set we started data collections. In 15 min we saw 30% of the devices were not running their latest hardening standards. 

30% of their network devices were not using the latest encryption, had management ACLs set to an old subnet which was now known as their guest subnet, inconsistent SSH versions, telnet still enabled, and some devices pointed to old radius servers, falling back to local accounts. Luckily their firewall blocked the guest subnet from anything internal but, their network management tool still couldn’t access 100% of the devices.

Fixing the underlying problem, not the result of the problem.

With the latest hardening standards in hand, the network engineers got an emergency change request and started logging in to update their configurations. Each device required firmware upgrades, followed by configuration changes. While this was a big undertaking, each day that passed we could grab the numbers and see trending on remediation and report to management.

Once we got the model complete, we found a couple of firewalls that blocked their network management solution from accessing 100% of their network devices. Once the customer opened their firewall, the networking team could start pushing the config to all of the devices. 

As luck would have it, the customer was currently undergoing a review of a new hardening standard. We took the new standard, and I showed them how to create checks for each of the configuration points. At the end of the day, the customer had 75 individual checks for each of the network devices. Upon data collection RedSeal will run those checks against each of the configurations automatically and we could ensure that all network devices passed all of checks required for their baseline configuration. 

This customer had a unique process where devices about to be deployed were plugged into the network and received a static DHCP address. Their network management tool would push the baseline to the config, then the engineers would login the next day to assign the interface Ips per the documentation. The rest of the hardened config was automagically configured by the tool. With this in hand, we were able to add the ‘staging area’ to RedSeal. With every data collection we noticed random inconsistencies where some device would get the whole config and others did not, using those same checks. 

Using RedSeal and custom checks this customer is able to push configs, then double check the config took properly before deploying out into their network. They had better visibility ensuring that all of their devices were hardened, were more confident that automating the work were consistently driving the results they wanted, had a double check with the automation, and essentially reduced their risk significantly, just by checking the configs of their network devices.

Interested in how RedSeal can help your team? Click here to set up a demo or an introductory call.