Tag Archive for: Network Security

Top Reasons State and Local Governments Are Targeted in Cyberattacks

/by

Ransomware attacks affected at least 948 U.S. government entities in 2019 and cost local and state governments over $18 billion in 2020. These agencies are prime targets for cyberattacks. Their dispersed nature, the complexity of their networks, the vast amounts of valuable personal data they process and store, and their limited budget prevent them from staying current with the latest best practices.

Strengthening your defense starts with understanding the top reasons why threat actors choose to target state and local governments. Then, implement the latest technologies and best practices to protect your organization from attacks.

Reason 1: The Vast Number of Local and State Government Agencies

There are 89,004 local governments in the U.S., plus numerous special districts and school districts. That equates to 2.85 million civilian federal employees and 18.83 million state and local government employees — each representing a potential target for threat actors.

Since it takes only one person to click on one malicious link or attachment to infect the entire system with ransomware, the large number of people who have access to sensitive data makes government entities prime targets for social engineering attacks.

Moreover, the dispersed nature of these networks makes it extremely challenging for government agencies to gain visibility of all the data and activities. When one agency suffers an attack, there are no procedures or methods to alert others, coordinate incident response plans, or prevent the same attack from happening to other entities.

Reason 2: These Agencies Process Valuable Personal Information

How much personal data have you shared with state and local government agencies? Somewhere in their dispersed systems reside your social security number, home addresses, phone numbers, driver’s license information, health records, etc. The information is attractive to cybercriminals because they can sell it on the dark web or use it for identity theft.

Many of these agencies also hire contractors and sub-contractors to handle their computer systems or process user data. The more people with access to the data, the larger the attack surface — creating more opportunities for supply chain attacks where criminals target less secure vendors to infiltrate their systems.

Without the know-how or resources to partition their data or implement access control, many government agencies leave their door wide open for criminals to access their entire database. All malicious actors have to do is target one of the many people who can access any part of their systems.

Reason 3: They Can’t Afford Security Experts and Advanced Tools

Almost 50 percent of local governments say their IT policies and procedures don’t align with industry best practices. One major hurdle is that they don’t have the budget to offer wages that can compete with the private sector and a workplace culture to attract and retain qualified IT and cybersecurity professionals.

Meanwhile, cybercriminals are evolving their attack methods at breakneck speed. Organizations must adopt cutting-edge cybersecurity software to monitor their systems and detect intrusions. Unfortunately, the cost of these advanced tools is out of reach for many government entities due to their limited budgets.

Moreover, political considerations and bureaucracy further hamstring these organizations. The slow speed of many governmental and funding approval processes makes preparing for and responding to fast-changing cybersecurity threats even more challenging.

Reason 4: IoT Adoption Complicates the Picture

From smart building technology and digital signage to trash collection and snow removal, Internet of Things (IoT) tools, mobile devices, and smart technologies play an increasingly vital role in the day-to-day operations of local governments.

While these technologies help promote cost-efficiency and sustainability, they also increase the attack surface and give hackers more opportunities to breach a local government’s systems and networks —  if it fails to implement the appropriate security measures.

Unfortunately, many agencies jump into buying new technologies without implementing proper security protocols. Not all agencies require IoT devices to perform their functions. You should therefore balance the cost and benefits, along with the security implications, to make the right decisions.

How Government Agencies Can Protect Themselves Against Cyberattacks

An ounce of prevention is worth a pound of cure. The most cost-effective way to avoid the high costs of ransomware attacks and data breaches is to follow the latest cybersecurity best practices. Here’s what state and local governments should implement to stay safe:

  • Complete visibility into your entire IT infrastructure to provide a comprehensive view into all the possible hybrid network access points to understand what’s connected to your network and what data and files are most at risk. This way, you can prioritize your data security resources.
  • Intrusion detection and prevention systems (IDS and IPS) protect your wired and wireless networks by identifying and mitigating threats (e.g., malware, spyware, viruses, worms), suspicious activities, and policy violations.
  • A mobile device management (MDM) solution allows administrators to monitor and configure the security settings of all devices connected to your network. Admins can also manage the network from a centralized location to support remote working and the use of mobile and IoT devices.
  • Access control protocols support a zero-trust policy to ensure that only compliant devices and approved personnel can access network assets through consistent authentication and authorization, such as multi-factor authentication (MFA) and digital certificates.
  • Strong spam filters and email security solutions protect end users from phishing messages and authenticate all inbound emails to fence off social engineering scams.
  • Cybersecurity awareness training for all employees and contractors helps build a security-first culture and makes cybersecurity a shared responsibility, which is particularly critical for fending off social engineering and phishing attacks.
  • A backup and disaster recovery plan protects agencies against data loss and ransomware attacks by ensuring operations don’t grind to a halt even if you suffer an attack.

Final Thoughts: Managing the Many Moving Parts of Cybersecurity

Cybersecurity is an ongoing endeavor, and it starts with building a solid foundation and knowing what and who is in your systems.

You must map your networks, take inventory of every device, and know where all your data is (including the cloud) to gain a bird’s-eye view of what your security strategy must address. Next, assess your security posture, evaluate your network against your policies, and prioritize resources to address the highest-risk vulnerabilities. Also, you must continuously monitor network activities and potential attack paths to achieve constant visibility, prioritize your efforts, and meet compliance standards.

State and local governments worldwide trust RedSeal to help them build digital resilience. Request a demo to see how we can help you gain visibility of all network environments to jumpstart your cybersecurity journey.

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.

Why Visualizing the Entire Healthcare Attack Surface Is Critical

/by

In recent years, the healthcare sector has been steadily adopting web and cloud-based technologies and shifting towards an internet-enabled system to improve quality of care.

However, along with the limitless benefits that the internet offers — like sharing information, simplifying operational processes, tracking workflows, enhancing connectivity, and storing and organizing data — is an increased risk of cyberattacks, data breaches, and other types of fraud. This makes hospitals and healthcare organizations increasingly vulnerable to advanced threats and targeted attacks.

According to recent reports, data breaches in the healthcare sector have been rising at an alarming rate for the last five years. In 2020, during the COVID-19 pandemic, email-based attacks increased by 42%, so it’s no wonder that more and more healthcare organizations are adopting a robust, multi-faceted strategy to improve their security posture. Hospitals’ expanding digital footprint also complicates their network infrastructures, making complete visibility into the entire attack surface extremely essential to managing cyber risks effectively.

Expanding Healthcare Attack Surface Risks

The widespread use of wireless technology is undoubtedly beneficial to the healthcare system. Wireless technology enables healthcare IT infrastructures to run data center servers, medical equipment, tools and applications, and other devices like smartphones, tablets, and USB drives. Organizations stay connected to deliver effective operations and consistently informed care.

These connected devices help in patient monitoring, medication management, workflow administration, and other healthcare needs. However, the increased number of devices connecting to the network also broadens the attack surface — meaning more entry points for unauthorized access and therefore the need for enhanced infrastructure visibility to mitigate risks.

Why Complete Visualization Is Essential

From booking an appointment to setting foot in the doctor’s clinic or hospital, patients go through several processes and interact with different interconnected devices and software systems. While a connected environment ensures a seamless patient experience, the different touch points provide more opportunities for attackers to gain access to sensitive data.

Currently, there are 430 million linked medical devices deployed globally, connected through Wi-Fi, Bluetooth, and radio transmission. The sheer amount of sensitive and personal information healthcare systems capture and process is why their systems are desirable targets. Therefore, it is critical to safeguard the data stored in these systems.

Protected health information (PHI), such as credit card and bank account numbers, and personal identification information (PII), such as social security numbers, are data cybercriminals find particularly alluring. Selling this sensitive information on the dark web is a very profitable business.

Even just a small part of the healthcare technology spectrum may lead to the greatest cybersecurity gaps, allowing criminals to exploit vulnerabilities and gain access to sensitive data. The resulting cyber crimes directly impact organizational productivity and brand reputation.

Here are a few risks that are most detrimental to healthcare businesses’ bottom lines and reputations.

  • Ransomware: Healthcare services are notably vulnerable to ransomware attacks because they depend on technology to a significant extent, considering the nature of their day-to-day operations. Health records are highly rewarding for criminals because each patient, hospital, or confidential record can command a hefty price in the underground market.
  • Phishing: Phishing attacks are quite common in healthcare. Attackers target the most vulnerable link in the security chain, i.e., people, to make their jobs easier. Through social engineering, users click on malicious attachments or links, thereby infecting their systems and losing access. The repercussions can be disastrous and the losses unimaginable. For instance, a Georgia diagnostics laboratory recently discovered that an employee’s compromised email account led to a phishing attack, impacting 244,850 individuals. The attackers were able to acquire patient information and then attempted to divert invoice payments.
  • Cloud Storage Threats: Many healthcare providers are now switching to cloud-based storage solutions for better connectivity and convenience. Unfortunately, not every cloud-based solution is HIPAA-compliant, making them clear targets for intruders. Healthcare companies must implement access restrictions more carefully and encrypt data properly before transmitting. Additionally, complete visualization of the attack surface is necessary to prevent data breaches, data leaks, improper access management, and cloud storage misconfiguration.

How to Protect Expanding Healthcare Attack Surfaces

Attack surface analysis can help identify high-risk areas, offering an in-depth view of the entire system. This way, you can better recognize the parts that are more vulnerable to cyber threats and then review, test, and modify the security strategies in place as necessary.

Healthcare IT administrators must secure the network infrastructure using stringent policies and procedures like enforcing strong passwords, properly configuring firewalls, setting up user access permissions, and ensuring authorized access to assets and resources. They must also monitor and properly configure all the devices connected to the network — be it standard healthcare devices or personal devices of patients and workers. In addition, a strong encryption policy can help increase data security, making it difficult for cyber attackers to penetrate the system.

Conducting regular attack surface scans can also mitigate cyberattack risks. This helps ensure security control measures are adequate and that decision-makers have the data they need to make informed decisions regarding the organization’s cybersecurity strategy. Also, all types of software and related updates for medical devices must be tested prior to installation.

Secure Your Entire Healthcare Network with RedSeal

Healthcare organizations often hesitate to invest in cloud security solutions. But the average cost of a healthcare breach is $9.23 million, which is far more than the cost of professional cloud security solutions. Additionally, healthcare institutions deal with extremely sensitive information, and fines for data security noncompliance can be extremely costly. Healthcare security leaders must be able to effectively visualize their entire attack surface to bolster their cybersecurity defenses.

RedSeal offers award-winning cloud security solutions that provide comprehensive, dynamic visualization of all connected devices. We partner with leading network infrastructure suppliers to provide comprehensive network solutions and professional services. This way, you can see and secure your entire network environment.

Contact us to learn how we can help strengthen your network security.

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.

Purdue 2.0: Exploring a New Model for IT/OT Management

/by

Developed in 1992 by Theodore J. Williams and the Purdue University Consortium, the Purdue diagram — itself a part of the Purdue Enterprise Reference Architecture (PERA) — was one of the first models used to map data flows in computer-integrated manufacturing (CIM).

By defining six layers that contain both information technology (IT) and operational (OT) technology, along with a demilitarized zone (DMZ) separating them, the Purdue diagram made it easier for companies to understand the relationship between IT and OT technologies and establish effective access controls to limit total risk.

As OT technologies have evolved to include network-enabled functions and outward-facing connections, however, it’s time for companies to prioritize a Purdue update that puts security front and center.

The Problem with Purdue 1.0

A recent Forbes piece put it simply: “The Purdue model is dead. Long live, Purdue.”

This paradox is plausible, thanks to the ongoing applicability of Purdue models. Even if they don’t quite match the reality of IT and OT deployments, they provide a reliable point of reference for both IT and OT teams.

The problem with Purdue 1.0 stems from its approach to OT as devices that have MAC addresses but no IP addresses. Consider programmable logic controllers (PLCs). These PLCs typically appear on MAC addresses in Layer 2 of a Purdue diagram. This need for comprehensive visibility across OT and IT networks, however, has led to increased IP address assignment across PLCs, in turn making them network endpoints rather than discrete devices.

There’s also an ongoing disconnect between IT and OT approaches. Where IT teams have spent years looking for ways to bolster both internal and external network security, traditional OT engineers often see security as an IT-only problem. The result is IP address assignment to devices but no follow-up on who can access the devices and for what purpose. In practice, this limits OT infrastructure visibility while creating increased risk and security concerns, especially as companies are transitioning more OT management and monitoring to the cloud.

Adopting a New Approach to Purdue

As noted above, the Purdue diagram isn’t dead, but it does need an update. Standards such as ISA/IEC 62443 offer a solid starting point for computer-integrated manufacturing frameworks, with a risk-based approach that assumes any device can pose a critical security risk and that all classes of devices across all levels must be both monitored and protected. Finally, it takes the position that communication between devices and across layers is necessary for companies to ensure CIM performance.

This requires a new approach to the Purdue model that removes the distinction between IT and OT devices. Instead of viewing these devices as separate entities on a larger network, companies need to recognize that the addition of IP addresses in Layer 2 and even Layer 1 devices creates a situation where all devices are equally capable of creating network compromise or operational disruption.

In practice, the first step of Purdue 2.0 is complete network mapping and inventory. This means discovering all devices across all layers, whether they have a MAC address, IP address, or both. This is especially critical for OT devices because, unlike their IT counterparts, they rarely change. In some companies, ICS and SCADA systems have been in place for 5, 10, even 20 years or more, while IT devices are regularly replaced. As a result, once OT inventory is completed, minimal change is necessary. Without this inventory, however, businesses are flying blind.

Inventory assessment also offers the benefit of in-depth metric monitoring and management. By understanding how OT devices are performing and how this integrates into IT efforts, companies can streamline current processes to improve overall efficiency.

Purdue Diagram

 

Controlling for Potential Compromise

The core concept of evolving IT/OT systems is interconnectivity. Gone are the days of Level 1 and  2 devices capable only of internal interactions, while those on Levels 3, 4, and 5 connect with networks at large. Bolstered by the adoption of the Industrial Internet of Things (IIoT), continuous connectivity is par for the course.

The challenge? More devices create an expanding attack surface. If attackers can compromise databases or applications, they may be able to move vertically down network levels to attack connected OT devices. Even more worrisome is the fact that since these OT devices have historically been one step removed from internet-facing networks, businesses may not have the tools, technology, or manpower necessary to detect potential vulnerabilities that could pave the way for attacks.

It’s worth noting that these OT vulnerabilities aren’t new — they’ve always existed but were often ignored under the pretense of isolation. Given the lack of outside-facing network access, they often posed minimal risk, but as IIoT becomes standard practice, these vulnerabilities pose very real threats.

And these threats can have far-reaching consequences. Consider two cases: One IT attack and one OT compromise. If IT systems are down, staff can be sent home or assigned other tasks while problems are identified and issues are remediated, but production remains on pace. If OT systems fail, meanwhile, manufacturing operations come to standstill. Lacking visibility into OT inventories makes it more difficult for teams to both discover where compromise occurred and determine the best way to remediate the issue.

As a result, controlling for compromise is the second step of Purdue 2.0. RedSeal makes it possible to see what you’re missing. By pulling in data from hundreds of connected tools and sensors and then importing this data into scan engines — such as Tenable — RedSeal can both identify vulnerabilities and provide context for these weak points. Equipped with data about devices themselves, including manufacturing and vendor information, along with metrics that reflect current performance and behavior, companies are better able to discover vulnerabilities and close critical gaps before attackers can exploit OT operations.

Put simply? Companies can’t defend what they can’t see. This means that while the Purdue diagram remains a critical component of CIM success, after 30 years in business, it needs an update. RedSeal can help companies bring OT functions in line with IT frameworks by discovering all devices on the network, pinpointing potential vulnerabilities, and identifying ways to improve OT security.

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.