Tag Archive for: network segmentation

Understanding the UnitedHealthcare Data Breach: The Importance of Good Segmentation

/by

After receiving a call from KCBS to comment on the UnitedHealthcare data breach, I was reminded of the critical importance of cybersecurity measures and proactive solutions like RedSeal in safeguarding sensitive information.

The Impact on Patients and Healthcare Organizations

The repercussions of the UnitedHealthcare data breach extend beyond the confines of the company itself. Patients whose personal and medical information may have been compromised face the unsettling reality of potential identity theft, fraud, privacy breaches, and in this case, health implications with a nationwide outage of some of the largest prescription processors. Moreover, healthcare organizations are left vulnerable to reputational damage, legal liabilities, and regulatory penalties.

The swift response by Change Healthcare to halt the spread of the incident is commendable. By implementing effective containment measures and building segmentation into network design, they demonstrated the importance of proactive cybersecurity strategies especially in mitigating the impact of such breaches.

Segmentation: Building Stronger Defenses

In the face of evolving cyber threats, healthcare organizations must prioritize robust cybersecurity measures to protect sensitive data and maintain the trust of their patients. A critical step, which Change Healthcare executed effectively, is incorporating segmentation into network design. This strategic approach enabled them to isolate and contain potential threats, shutting down access swiftly.

By dividing networks into distinct segments and implementing access controls based on user roles and permissions, organizations can contain breaches and limit the lateral movement of attackers within their infrastructure.

The Importance of Transparency and Disclosure

Another noteworthy aspect of the UnitedHealthcare data breach is the transparency and prompt disclosure of pertinent details surrounding the incident. Unlike in years past, where data breaches were often shrouded in secrecy and only disclosed months or even years later, the current landscape emphasizes the importance of timely and transparent communication.

Moving Forward: Strengthening Cyber Defenses

As the healthcare industry continues to confront evolving cyber threats, proactive measures and collaborative efforts are essential to fortify defenses and safeguard sensitive information.

By embracing cybersecurity solutions and prioritizing segmentation and transparency, healthcare organizations can mitigate risks, protect patient data, and uphold the integrity of their operations. As the adage goes, “good fences make good neighbors,” and investing in robust cybersecurity defenses is paramount to safeguarding the future of healthcare.

RedSeal can play a pivotal role in enhancing security.

RedSeal acts as a vital tool in mapping out defensive boundaries within the network. It provides organizations with a comprehensive overview of their network architecture, allowing them to understand how different segments interact and where potential vulnerabilities lie. With RedSeal, organizations can accurately assess their defensive posture and make informed decisions to block moving threats before they spread.

In times of uncertainty, one thing remains clear: proactive cybersecurity measures and innovative solutions like RedSeal are indispensable allies in the ongoing battle against cyber threats. Let us heed the lessons learned from this incident and collectively work towards a safer and more secure future for all.

Contact us for a demo www.redseal.net

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.

When Moving to the Cloud, Don’t Overlook Resources On-Premises

/by

Today’s cloud infrastructure is complex and constantly evolving. In the cloud, security controls are implemented by developers and DevOps teams while on-premises controls are implemented by the firewall/network operations teams. These can create significant knowledge gaps, leading to unknown attack points.

Most security spending these days is focused on the cloud and treated as a silo, but you can’t afford to ignore your on-prem resources and how the two entities work together.

Challenges with Protecting Cloud and On-Premises Resources

With resources moving to the cloud, most of the attention moves to cloud security and protecting the cloud perimeter and resources. Yet on-prem resources also have connections and exposure. However, you need a comprehensive security strategy that protects both cloud and on-premises resources.

Many organizations and vendors struggle with getting this comprehensive picture. For example, in many companies, in-house teams are responsible for managing on-prem resources while other teams or third-party providers monitor the security of cloud resources. At the same time, you have DevOps teams that are constantly evolving the cloud environment.

Different Languages

The products and tools being used in the cloud and on-premises domains are often disconnected and speak different languages as do the teams using them.

The problem is not people, however. It’s often the tools being used, like having a separate doorman on the front door (cloud) and back door (on-prem), and they both speak different languages and often have competing goals. While security teams are focused on mitigating exposure, DevOps teams are looking for a faster way to bring products to market. Competing goals can only aggravate language barriers.

Even highly skilled teams may not understand how other teams work. The technology is different, the configurations are different, and some nuances require expert interpretation and experience. Few team members will be conversant in both on-prem and cloud resources.

Greater Complexity

More than 90 percent of large organizations already employ multi cloud strategies; 80 percent use hybrid clouds.

This creates an even greater complexity for security and management. For example, Amazon Web Services (AWS), Microsoft Azure, and Google Cloud use different names for instances and virtual machines. Azure calls them virtual machines (VMs), while Amazon has Elastic Cloud Compute (EC2) and Google has the Google Cloud Compute Engine.

Even when the same term is used, it can mean different things. For example, a virtual private cloud (VPC) exists in both AWS and Google, but they are different and operate differently.

This only increases the language barrier that hinders a comprehensive approach to security.

Lack of Understanding of Shared Responsibility

Organizations also assume their cloud service provider (CSP) will protect assets in the cloud. While CSPs such as AWS, Azure, Google Cloud, Oracle Cloud, and others provide robust security for their networks, it’s still the customer’s responsibility to protect their data.

Gartner estimates that 99 percent of cloud security failures are the fault of the customer, not the CSP. The sheer volume of configuration settings and pathways to critical resources makes it difficult to manage security in the cloud. When you add in on-premises data centers or servers that are connected, the infrastructure becomes even more complex.

Constant monitoring and continuous compliance should be a shared responsibility between providers and organizations.

Not Monitoring Resource Misconfigurations

Most vendor security solutions are only as effective as how they’re configured. Yet few are monitoring that and telling you where these configurations are causing potential problems.

You need a comprehensive, end-to-end understanding of your cloud and on-prem infrastructure to analyze every configuration and security policy. While you may have cloud security tools for each environment, you need complete cloud network visibility to protect your infrastructure, look for exposure, and find security gaps.

Are You Seeing the Whole Picture?

Nearly every organization has at least some on-premises that are connected. The challenge often comes when it’s time to configure the right access for communication. You need to ensure that nobody on the cloud side can attack on-prem resources or vice versa. That’s why total visibility is essential.

If you’re not seeing the whole picture, it’s easy to miss attack points. Securing your infrastructure requires you to detail what you have, how it’s connected, and what’s at risk.

You need to:

  • Know what you have in your total infrastructure
  • Understand how everything is connected
  • Determine where your exposure is — all attack paths to cloud and on-premises
  • Uncover what policies or configurations created the exposure

Only then can you remediate problems and plug security gaps. You must understand how your cloud and on-prem resources are all interconnected to determine and mitigate your total risk.

Managing Cloud and On-Prem Resources

Some organizations turn to Cloud Native Application Protection Platforms (CNAPP) as a way to provide visibility amid the complexities and the constant evolution of hybrid resources. Yet all existing CNAPP solutions don’t understand on-Premises and are insufficient to identify access via all attack path and associated risk. Most tools call into the application programming interfaces of cloud service providers, looking for misconfigurations at the compute and container levels. However, they don’t fully understand end-to-end access.

CNAPP is an important weapon in the battle to secure the cloud, but most vendor solutions simply do not provide the total visibility you need across cloud and on-prem resources. RedSeal solves these problems.

RedSeal on-premises and RedSeal Stratus in the cloud provide a complete view of the entire infrastructure. They identify the gaps in your security by pinpointing attack points and any hidden pathways. This analysis also determines the underlying reason why these attack points exist and what needs to happen to remediate them.

RedSeal solutions also work across borders. They provide the platform to speak to DevOps and firewall/network operations teams in the right way, helping eliminate language barriers. This way, you get benefits across borders for cloud and on-prem, enabling you to identify security issues across the entire infrastructure by driving collaborations between the teams and building trust.

Protect Your Entire Infrastructure

On-premise and cloud resources cannot be protected in a silo. Working in tandem with a shared responsibility model, a hybrid solution with RedSeal provides continuous monitoring and compliance across both on-prem and cloud resources, identifies gaps, and helps you protect your entire infrastructure.

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.

How Secure Is Your Pharma Research Data?

/by

The use of big data and advanced analytics is now essential for innovation across the pharmaceutical and healthcare industries. However, working with vast amounts of data — experimental data, clinical trial data, patient data — has become a double-edged sword as organizations face immense challenges in protecting data integrity and ensuring data security in today’s digital environment.

Meanwhile, the global pharmaceutical market will grow above $2 billion by 2028 at a compound annual growth rate (CAGR) of 5.7% between 2022 and 2028. With revenue depending on research and innovation and more of the processes going digital, pharma research data has become a prime target for threat actors who use various means to breach companies’ systems and steal their sensitive information.

Let’s review key data security issues that pharma research companies face and how to protect your sensitive information to help you navigate the complex cybersecurity environment.

Is Pharma Research Data Secure?

Unfortunately, no. The pharmaceutical industry has seen many data breaches in recent years.

In an analysis of 20 pharma companies, five had experienced over 200,000 data exposures and breaches. Some had as many as 400,000 exposures. Another study revealed that over 50% of hospitals, biotech firms, and pharmaceutical companies have more than 1,000 sensitive files accessible to all employees. 33% of these organizations have over 10,000 files exposed to every staff member.

IBM’s Cost of Data Breach 2022 report found that data breaches cost the pharma industry an average of $5.01 million between March 2021 and March 2022. Additionally, the high data regulation environment means these companies see costs accrue years following a breach due to regulatory and legal fees, further impacting an organization’s financial health.

Data breaches in the pharma industry can also lead to direr consequences than in many other sectors. For example, leaked intellectual properties and clinical trial data can lead to reputational damage and lost revenue that could take years to remedy.

Top Pharma Research Data Security Issues

Here are the key cybersecurity challenges faced by pharma companies:

Supply Chain Attacks: Pharma research requires collaboration among various parties, such as research institutions, suppliers, contractors, and partners. The complex ecosystem creates a large attack surface threat actors can exploit. For example, they can infiltrate your network via a vendor with a less secure system. Without complete visibility into their environment, many organizations are left in the dark until it’s too late.

Ransomware Attacks: Due to the need to access critical information in their research, pharma companies are prime targets for ransomware attacks. Especially in companies with lax access controls, hackers can infect just one employee’s device with malware to infiltrate the entire network and lock down access to data for the whole company.

Phishing Scams: Threat actors can use social engineering techniques to trick employees, partners, and researchers into giving up their credentials to access the company’s network and exfiltrate data. Again, an organization without proper access control makes it much easier for hackers to move laterally across its systems.

Emerging Technologies: New platforms, cloud technologies, and Internet of Things (IoT) devices are invaluable in accelerating research and development processes. But they also present inherent cybersecurity risks because of the expansive environment and numerous endpoints. If companies spread their data on multiple platforms without mapping their inventory, they could leave sensitive data out in the open.

Mergers and Acquisitions (M&A): The pharmaceutical industry saw 182 M&A deals in Q2 2022. When two companies merge, their IT infrastructures must work seamlessly with each other, including their cybersecurity protocols and monitoring systems. Mapping all the data to maintain visibility and assessing vulnerabilities can be challenging, leaving the new entity at a higher risk of compromise.

How to Protect Pharma Research Data:

Here are some steps pharma companies can take to protect their research data:

  1. Visualize Access Across Your Network Environment: You can’t protect what you can’t see. You must map your environment and all digital assets to connect the dots, identify blind spots, reveal inconsistencies, and interpret access control. You can then prioritize vulnerabilities based on access and eliminate gaps in your scanner coverage.
  2. Deploy End-to-End Encryption for Data Sharing: Use a robust encryption solution to support data sharing within the organization and with third parties. This way, authorized personnel can use sensitive information without risking exposure. Choose a scalable, database-agnostic encryption technology that can be deployed in the cloud or on-premises to help protect data at rest, in transit, and in use.
  3. Enforce a Zero-Trust Policy and Least-Privilege Access: Least-privilege access is a vital component of a zero-trust framework that continuously authenticates a user’s identity to allow access to protected information. Access control is granted based on the principle that end users should see no more than the data they need to do their job. This approach can help minimize damage even if an employee’s account is compromised and limit a hacker’s lateral movement within your network.
  4. Implement a Comprehensive Incident Response Plan: It’s not a matter of if but when your infrastructure will come under attack, and a well-designed incident response plan is key to containing the damage and minimizing loss. Having an up-to-date model of your network can help accelerate incident response by locating the compromised device and determining which digital assets hackers can reach from the entry point.

Protect Pharma Research Data with a Bird’s-Eye View of Your Network

The first step in strengthening your defense is to know where all your data is and who can access the information. The insights can help you identify vulnerabilities, take remediation actions, and implement continuous compliance monitoring. But mapping all the moving parts, including every connection to the internet, is easier said than done.

RedSeal Stratus gives you an in-depth visualization of the topography and hierarchy of your security infrastructure. It helps you identify critical assets inadvertently exposed to the internet and shows your multi-cloud inventory and connectivity, so you can quickly detect changes in the environment.

Get in touch to see how we can help you proactively improve your security posture and protect your pharma research data.

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.