Tag Archive for: cyber security

Tales from the Trenches: Vol 8 — Is that what you are going to say to the Auditor?

/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 Brad Schwab, Senior Security Solutions Consultant addresses a tricky network scanning question and how to verify with RedSeal.

Is that what you are going to say to the Auditor?

One of the biggest elephant in the room questions for Security Operations groups that deal with Vulnerability Scanners is very simple to state, but very, very tricky to answer, “are you sure you are scanning the entire network?” Sounds like it should be a simple yes or no answer. However, with any network of scale, the answer can be almost impossible to verify.

I was in a high level meeting for a large Health Organization with the CTO, head of Network Operations (NetOps), the head of Security Operations (SecOps), along with other people that had different stakes in the performance and security of the network. Since the network was the main instrument supporting the “Money Engine” of the operation, all attendees were laser focused on answers to any questions.

At a certain point in the meeting Wendy, the head of SecOps was talking about the scanning program. More specifically, she was speaking about procedures created to scan the entire network. The entire network!? So, at this point, I had to ask the question, “how do you know you are scanning the entire network?” She pointed to Bill, the head of NetOps and said “Bill said I could…”. That is where I looked at Bill, and said “is that what you are going to put on the audit, “Bill said I could?” Now, Bill and I had a good working relationship, and he knew that I was having a bit of fun at his expense, however, others in the room weren’t going to gloss over the subject, and began to pepper both Bill and I with questions. I proceeded to line out where the difficulties were in answering, with the following questions:

  • Does the scanner have a complete list of all IP space on the network that needs scanned?
  • Are there any overlapping subnets? If so, that overlapped portion of a subnet is not visible to the scanner. Thus, creating a possible hiding place for a bad actor.
  • Is there any duplicate IP space in the network? – again creating blind spots to any scanner.
  • And finally, the hard part, does the scanner have logical access to the entire network? Even if the scanner is trying to scan a network subnet, if the network architecture via Access Control Lists and Routing is blocking the access or not granting the access, then the scan won’t be complete. On top of that, you will get no indication from the scanner that the scan didn’t work. Beyond the logical access issue, no one had thought of the other issues. I then explained how RedSeal automatically looks for subnets that have no scan data, thus possibly not part of the IP list giving to the scanner, overlapping subnets and duplicate IP space. At the same time, I explained how a RedSeal Access Query combined with our “show what is missing” feature can give you a list of everything that the scanner can’t reach because of network architecture.

I ended my explanation with “with these features, you can have comprehensive documentation of complete scanner coverage for your upcoming audit(s)…”

After less than a few days of work, we had provided a list to both NetOps and SecOps of additions and changes required by both teams to make their Vulnerability Program complete.

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

Tales from the Trenches: Vol 6 — Barely-Passive Aggressive

/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 Bill Burge, RedSeal Professional Services shows the network as configured, not necessarily as designed, with RedSeal.

Barely-Passive Aggressive

While working with a global reach chip manufacturer, a new member was added to those who helped manage RedSeal.

He had spent over a dozen years working his way up the Network Operations group to become one of their top network architects, and his knowledge of the network was determined to be of great value to the Security Architecture group.

As we were reviewing some of the RedSeal findings and giving him a tour of the capabilities of the deployment, it was pretty obvious he was neither impressed nor entertained. With his history of designing, building, and managing the network; he was almost offended that some product could tell him ANYTHING that he didn’t already know about his network.

Reviewing Model Issues, specifically Overlapping Subnets, I’m explaining how there can be multiple reasons why they might exist, but many times they are a simple typo in a netmask. We found such an example.

He proceeds to dig into the config with the intent of showing us how “RedSeal got it wrong”. (I’m preparing for this to spiral into a very bad scene.)
He finds the line, and he finds the typo.

The room gets REAL quiet and I’m holding my breath. Finally, he sits back in his chair and visibly deflates. He then offers “That’s probably been in there for over a DECADE!”
Then he starts laughing and says “I’m probably the person that put it in there!”

After that, he wanted to see “everything!”
He says “There’s 18 months worth of work to fix just the things I’ve seen today!”  His teammates point out to him: “Yes, but it’s not YOUR job anymore to fix it.” (Big smile.)

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

Tales from the Trenches: Vol 5 — Octet Dyslexia

/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, Bill Burge, RedSeal Professional Services exposes inconsistencies in policy definitions with RedSeal.

Octet Dyslexia

Numbers are a tricky business and more numbers equals more tricky, and sometimes our brains see what they want to see and not what is actually there.

While working on PCI audit prep using RedSeal Zones & Policies with a large manufacturer/distributor/retailer we were going over what Internet access existed from the Internet into their cardholder environment.

The customer had two external address blocks and some were allowed access through this path.

I’ll make up the address blocks, as 12.53.22.0 and 15.43.22.0.  In the table of access results was a block of inbound address that was 12.43.22.0 (or something like that).

I asked the customer about this external address block and they said “yeah, we have two external blocks”.  We did a few laps around this like the old “Who’s on first?” routine.

It wasn’t until I put a sample from this range along with samples from their two ranges that they were finally about to SEE that it was an amalgamation of their two ranges, just enough to fool the hurried mind.

A quick Whois determined that the range belonged to a Chinese university, IN CHINA.

We were able to use other features of RedSeal to determine all the device configurations that referenced this block and submit change requests to get them remediated.

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

 

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.