Tag Archive for: Tales from the Trenches

Tales from the Trenches: When Low-Risk is Actually High-Concern

/by

Since 2004, RedSeal has been instrumental in empowering our clients to comprehensively visualize and fortify their intricate networks. While our customers initially grasped the importance of understanding their network architecture, connections, and identifying potential risks, there’s often an enlightening “aha” moment when the true significance becomes unmistakable. These narratives, cherished within the confines of RedSeal, vividly exemplify the practical value of our platform beyond mere theory. In the words of our dedicated field team, who collaborates directly with our clients, this blog series aims to unveil the instances where the theoretical transforms into tangible reality. 

Today’s post is brought to you by Chris Morgan, Client Engagement Director 

 

In the realm of cybersecurity, where threats and vulnerabilities lurk aplenty, RedSeal stands as a beacon of innovation. Pioneers in network security analytics, RedSeal delivers actionable insights, enabling customers to close defensive gaps across their entire network. 

While reviewing a large medical provider’s network, we discovered several high- and medium-severity vulnerabilities within the network. However, it was the low-risk vulnerability we found to be of highest concern.  

Delving deeper into our investigation, we unearthed a situation of seismic proportions. Amidst the chaos of the COVID-19 era, the client’s IT team had inadvertently granted unrestricted access to a seemingly mundane printer. However, unbeknownst to them, and visible now only because of RedSeal, this printer served as direct access to more than 14,000 hosts within the client’s expansive network, opening access that could enable bad actors to directly invade much of the network. RedSeal’s comprehensive approach, merging risk and access, empowers genuine prioritization for clients. 

With a fresh eye toward restricting access, we worked with the medical provider to remediate the exposure immediately, tightening access controls for printers and implementing access logs, securing them for the future.  

At RedSeal, we’re committed to helping you fortify your digital infrastructure, for good. We proactively help visualize your network, identify attack paths, prioritize risk, and help you stay in compliance to ensure your business and customers stay secure. 

Reach out to RedSeal or schedule a demo today.

 

Tales from the Trenches: My network hasn’t changed!

/by

Since 2004, RedSeal has been instrumental in empowering our clients to comprehensively visualize and fortify their intricate networks. While our customers initially grasped the importance of understanding their network architecture, connections, and identifying potential risks, there’s often an enlightening “aha” moment when the true significance becomes unmistakable. These narratives, cherished within the confines of RedSeal, vividly exemplify the practical value of our platform beyond mere theory. In the words of our dedicated field team, who collaborates directly with our clients, this blog series aims to unveil the instances where the theoretical transforms into tangible reality.

Today’s post is brought to you by John Bays, Senior Security Solutions Consultant, Federal

MY NETWORK HASN’T CHANGED

Imagine navigating the landscape of a government entity, where a dedicated administrator went about their daily routine, firmly believing that a single login to the server was all it took to keep things ticking. Little did they know, a significant issue had quietly brewed beneath the surface – the network had remained unchanged for a considerable six-month stretch.

Approaching the situation with curiosity, I gently posed some questions.

  • How might they have overlooked the network’s lack of growth?
  • What led them to believe that everything was running smoothly without addressing potential issues?

This unfolding scenario morphed into a journey of understanding, aiming to uncover misconceptions and illuminate the broader responsibilities at hand.

Misunderstanding a role’s responsibility happens. At RedSeal, we know this and help ensure misunderstandings are laid to rest. Taking a supportive approach, I guided them through various aspects of the platform, emphasizing the value of active involvement. As the pieces fell into place, a realization dawned on this client – our exploration revealed numerous devices being added and removed from the network. This revelation painted a richer picture, demonstrating that their role was more intricate than they had initially perceived.

This experience turned out to be a valuable lesson for all involved, highlighting the importance of staying engaged and adapting to the ever-changing dynamics of the network environment. It wasn’t about fault-finding; rather, it underscored the need for continuous learning and awareness in the evolving tech landscape. After all, even the most dedicated administrators can benefit from a broader perspective on their responsibilities.

At RedSeal, we’re committed to helping you fortify your digital infrastructure, for good. We proactively help visualize your network, identify attack paths, prioritize risk, and help you stay in compliance to ensure your business and customers stay secure.

Reach out to RedSeal or schedule a demo today.

Tales from the Trenches: Vol 10 — You Don’t Know What You Don’t Know

/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 Michael Wilson, Senior Network Security Engineer, explains how RedSeal empowers customers to verify their contractors are following security best practices and have their organization’s best interest in mind.

You Don’t Know What You Don’t Know

In my customer’s environment, the network is segmented and managed by both the customer and several contracted partners. It is a difficult task to have visibility into an entire network that is distributed across several different contracted partners, let alone keep track of all of the devices and changes that can occur across a network. The adage of ‘you don’t know what you don’t know’ is very relevant in a situation like this. RedSeal has the ability to provide my customer with a single pane of glass to see all these network segments that are managed by different contracted partners.

The customer’s RedSeal deployment runs daily collection tasks, and the customer can see any changes that occur to their network from day to day. One morning, I logged into RedSeal and started my daily maintenance tasks, which includes ensuring that data collections ran correctly, and analysis was performed successfully, and I noticed that there was an increase in device count. This was a cause for investigation, as new devices being brought into RedSeal without any new data collection tasks is a possible indicator of compromise.

I notified the customer, and I started to investigate. I noticed that these changes occurred in the customer’s SDWAN environments. This SDWAN environment uses clusters to manage edge devices, and the customer has devices spread around in many different locations. The environment is managed by one of the customer’s contracted organizations and, previously, the environment used 4 clusters to serve all the customer’s edge devices in this SDWAN environment. The additional devices that RedSeal discovered were an additional 20 clusters that upped the total from 4 to 24. Once I started to arrange the new clusters on the map, I started to see that these new clusters were connected in such a way that they were serving specific geographic regions of the customer’s environment. This indicated the contracted partner was making significant changes to the SDWAN environment and the new devices were likely not an indicator of compromise.

Once I determined that this was likely a planned network change, I asked the customer if they were aware that these changes were planned and being implemented to the network. They were not aware of any plans and changes being implemented. I asked the customer to immediately verify that the changes were planned, and the customer discovered that not only were these changes planned, but they had never been notified of these planned changes. This demonstrated a significant lack of communication between the customer and their contracted partners. I was able to use RedSeal not only to discover network changes that occurred on the network, but a fundamental operational flaw of the entire customer’s workflow surrounding network changes. It gave the customer the ability ‘to know what they didn’t know’.

The risks that the customer was unknowingly accepting (and by default, unable to mitigate or remove) through this lack of communication was that the contracted partner was making changes to the customer’s network, which contains devices that have Payment Card Industry (PCI) data running through them. By making changes without consulting the customer, the contracted partner was potentially exposing the customer to a disastrous breach of customer financial information. The reason this could be the case is that the contracted partner does not control the entire customer network and changes in their network segment may unknowingly lead to security holes in other parts of the network that is managed by either the customer directly or another contracted partner. To top it off, the customer would have had no idea of this risk because they were unaware of what was happening on their network. RedSeal was able to become the stop gap and identify that risk and provide the information needed to make an informed and educated decision on what risks to accept, mitigate, or remove.

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

Tales from the Trenches: Vol 9 — The Law of Unintended Consequences, OR Some Doors Swing Both Ways

/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, explains how RedSeal can show you ALL the access from a network change, not just the one access you are expecting.

The Law of Unintended Consequences, OR Some Doors Swing Both Ways

“The law of unintended consequences” states that the more complex the system, the greater the chance that there is no such thing as a small change.

While working with a customer in the early days of my RedSeal Professional Services tenure, I looked for an opportunity to prove the capability of Zones & Policies. In an unfamiliar environment, the easy starting point is creating a policy that examines the access from “Internet to all internal subnets.”

It is easy to setup and easy to discuss the results, UNLESS the results say that most of the Internet can get to most of the internal network.

I thought “I MUST have done something wrong!” I got the impression that the customer felt the same thing, even though neither of us came right out and said it. So, I tore into it.

Using some ad hoc access queries and Detailed Path queries, we figured out the problem and why.

After looking into it, thinking something was amiss, it turned out that RedSeal was RIGHT. It seems there had been a pair of firewall rules for DNS requests:
SRC: inside, SRC PORT: any, DST: outside, DST PORT: 53, PROTOCOL: UDP
(and for the responses)
SRC: outside, SRC PORT: 53, DST: inside, DST PORT: any, PROTOCOL: UDP

At some point, because DNS resolutions got large enough that the responses did not fit in a single UDP packet, DNS needed to include TCP. So, someone simply made a small change and added TCP to each of these rules.

The unintended consequence was that you could reach just about any internal system from the Internet IF you initiated your request from port 53.

After this was verified by the firewall and networking teams, I might have well gone home. Everybody disappeared into meetings to discuss how to fix it, whether it could be done immediately or later that night, etc.

A little time later, I ALMOST felt guilty to point out that they had done pretty much the same thing with NTP, on port 123. (Almost…)

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

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 7 — You Can’t Always Get What You Want

/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 places customer questions in full network context and reveals an even better solution with RedSeal.

You Can’t Always Get What You Want

While working with a large customer with multiple, interconnected, environments, their greatest fear was that infection in one environment might cross over one environment into the others.

They had purchased a managed service, which meant I was the primary RedSeal Admin. They approached me with a request and it was obvious they were having a possible “incident”. It was obvious they didn’t want to provide TOO many details, but I’ve spent enough time on both sides of these topics that I was pretty sure what I was up against.

Their request was simple to say, but that doesn’t mean it was simple to perform. “Can you give us a report of all the firewall rules that control this particular subnet?” For RedSeal, I can perform some queries that will do a pretty poor job of that when you factor in the multiple ways to cover a block of addresses in a firewall policy, groups, large masks, even the use of “any”. All these would have to be detected, expanded, broken out and apart, etc. It’s largely a fool’s errand.

So I politely declined. I gave a brief explanation of the dynamics and the fact that firewall policies would also have to be weighed against, and in conjunction with, router ACLs, and even routing. I always say “the firewall rules are only the verb in the sentence of access”. I offered an alternative: “Tell me the IP address that has been compromised, and I’ll tell you all the subnets it might have accessed, and all the vulnerabilities it might have exploited in the process.”

The customer’s response was: “You can do THAT? THAT’S even better! Let’s do it!”

I explained that calculating access is the foundation of RedSeal. As Mick Jagger says “you can’t always get what you want, but you just might find — you get what you need”.

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 4 — Leveraging the Tools You Already Have

/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 Chris Naish, Sr. Sales Engineer, Federal at RedSeal explores prioritizing your risk mediation with RedSeal.

Leveraging the Tools You Already Have

Sometimes, you just need help understanding what you already have the ability to do…

Often while walking with customers along their RedSeal journeys, they’ll ask me, “Hey, what’s this Risk tab?”…

To prepare them for the coming screen of boxes of different colors and sizes, I preface the conversation by saying, “This might look intimidating at first, but I promise it’s not. It will make more sense shortly.” …

I’ll first take a brief detour to the Vulnerabilities tab in RedSeal and reiterate how on this tab, you’re essentially looking at the vulnerabilities in your environment one at a time. For any selected vulnerability, you’re able to see the related Host Count in the top frame, as well as the actual number of instances in the bottom frame (these counts may differ if the vulnerability in question can affect a host on more than one port).

Next, I’ll move over to the Risk tab and explain that by way of contrast, each of the boxes of different colors and sizes on the Risk map represents one of the hosts in your network. You can select any host and get related details in the bottom frame, including the vulnerabilities on that host.

But *why* are they all different colors and sizes?

The key to understanding the Risk Map layout is to click on Risk Map Controls on the left-hand side. Here you’ll be shown a series of drop-down menus, each with multiple options, which dictate how the host boxes appear, as well as how they’re grouped.

With this foundation laid, I explain that the main use case of the Risk tab is determining Mitigation Priority according to YOUR specific RedSeal topology. Say for example that you’re working with someone new to your patching team, who’s only responsible for Campus hosts. And they’re sitting next to you while you show them RedSeal’s capabilities. After a brief detour to Maps & Views to show them a RedSeal topology map that includes a Campus area, I might go back to the Risk tab and make this distinction: if you show them a simple Risk view, it may be perceived as overwhelming if you have a fair amount of vulnerabilities in your ENTIRE network that need to be patched. By way of contrast, if you INSTEAD manipulate the Risk Map Controls (and save the resulting layout) to display a Topology-based Mitigation Priority View, now the host(s) of concern for the Campus portion of your network can easily be seen. This can be done via the following drop-down menu selections: Group: First By Topology, Then By Primary Subnet; Appearance: Color By Downstream Risk, Size By Risk.

At this point, a customer’s wheels usually start turning and ideas come forth on how to make use of these concepts in THEIR RedSeal model and increase its’ value.

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

Tales from the Trenches: Vol 3 — Security Operations and Network Operations are always at odds. Or are they?

/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 tackles the potential friction between two departments with RedSeal.

Security Operations and Network Operations are always at odds. Or are they?

Empirically, using the greatest technical brevity, you could explain the two areas as:

  • Security Operations (SecOps) is about limiting where network traffic goes. They are also usually responsible for Vulnerability Scanners
  • Network Operations (NetOps) is about the uninterrupted, fast, network traffic flow

As you can see, these departments could easily be at odds – one is the brakes, the other the throttle. So, yes, they usually are at odds. Everything one wants can easily create work for the other, resulting in a back-and-forth pendulum of requests. SecOps to NetOps, “I need these ports shut down, they are creating security exposure…” NetOps to SecOps, “sure, you deal with the backlash…” Outcome, Finance to NetOps, “I can’t print paychecks…” NetOps emails SecOps the Finance department email and goes dark…. Net affect, neither department likes the other…

How does this involve RedSeal you may ask? RedSeal is in the unique position to work with both SecOps and NetOps and help both realize their Operational Goals and allow visibility into outcomes beforehand so that situations like the above don’t happen. This creates a positive working relationship between the teams.

Working with a large Health Organization, we were at the end of a Proof of Concept, and were having a meeting with the CISO, and the heads of SecOps, “Wendy”, and NetOps, “Bill”. We had been having problems with the NetOps people not providing the access required to gather device configuration files across the entire network fabric. NetOps was claiming they didn’t have the time. On the sly, we also heard that they thought providing us with the ability to gather the configs would only make work for them.

During this meeting Wendy was talking about the mountain of scan data she had and that prioritization was key to her work. I demonstrated how RedSeal could prioritized her patching routine(s) based on Network Access. Which, wait for it, requires the network device configuration files. Knowing that SecOps and NetOps were not friends, I decided to see if I could get a dialogue going, and at the same time incent NetOps to get us the access we required to gather the config files. So, I posed the question to Wendy of SecOps, “Wendy, are you scanning the entire network?” She said “yes.” I asked how she knew she could reach every host on the entire network? She said, “Bill told me I could.” I then said to Bill, “Is that what goes on the upcoming Audit, “Bill told me I could scan the entire network…”. Before he could reply I said, wouldn’t you like actual documentation showing that Wendy’s network reach was complete and entire network scans could and were taking place?

That is when the CISO chimed in and said “yes, we need that. How do we get that?” I said that if I had all the config files, I could provide you, Ms. CISO with your required audit documentation, which would eliminate Bills’ manual effort to supply the always asked for “ACL’s of all devices, not just the edge.” And, in addition, I can prioritize Wendy’s mitigation procedures and show the actual trending decrease in your exposure as her team works through the tickets. What followed was over an hour-long discussion of how RedSeal could provide value, focusing of tasks, and reduction of effort to both NetOps and SecOps, plus provide progress reporting to the CISO.

During the rest of the deployment NetOps was always willing to listen and quickly respond quickly to requests. The final outcome was that both teams, SecOps and NetOps, embraced the RedSeal Secure Methodology of Discover, Investigate and Act.

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