Identify and Close Before the Bad Actor Exploits

/by

It happened again yesterday. I was taking a break on my back porch and listening to the Colorado summer rain when an alert hit my phone: news of another breach. They seem to be coming with a disturbingly increasing regularity and with ever more serious consequences. For example, one company, Code Spaces, was completely destroyed when they refused to pay an attacker who then destroyed their customers’ data. The Energetic Bear group accessed utilities’ networks and could have launched attacks against them. In all likelihood, the number, extent, and veracity of these attacks will simply continue to expand.

telescope-smaller_0So what do you do? The good news is that the steps are well known and understood: place security controls into your network to isolate a set of subnetworks (typically called “zones”) and both set and monitor the potential access paths between the zones. This is the first set of defenses against attacks, and one which many organizations do not fully deploy.

It is common for me to see organizations that partially deploy zones – but do not monitor their implementation. This is akin to the multi-petabyte database that contains one incorrect byte of information: you can trust none of the information as a result.

So, the first step is to create clear and concise zones in your network and to analyze all potential access paths through your network to be sure that your zone rules are respected network-wide.

Do you do this? If so, what’s your approach?

The Reality Gap

/by

A couple years ago in a conference room with a window looking out on the Arizona desert, two of us sat down with a customer to talk about their network. I asked to see their best network diagram, which he left to retrieve. When he returned, he rolled it out to its full length on the conference table. He began telling me of a number of inaccuracies that he knew while I looked in the lower right corner for the annotation.

reality-gapThe plot was years old. When I speak to groups of engineers, I often ask how old they think the average organization’s network diagram is. While the guesses vary from 2 to 5 years, everyone recognizes that they are woefully out of date. And that’s a huge deal for attempting to understand and protect your network.

…by the way, in my experience, the average is 5 years old! As a result, many of the technologies deployed didn’t even exist when the last map was made. Making the map current never seems to get to the top of the priority stack, either.

The truth is that if you can’t see it, you can’t secure it. If you don’t know what your network really looks like, you can’t possibly be certain your security controls are properly deployed. Even if you have designed a security architecture aligned with the best practices of network security zones such as those outlined in the PCI DSS, if your architecture isn’t reflected in the operational network, it’s effectively moot.

Similarly, the network and security design teams create a network design that they intend to align with the architecture.

However, when it gets implemented, does it align? Does it stay aligned as equipment changes, requirements evolve, and needs expand? How would you know?

That, of course, is the 100 million-customer-data-record question.

What do you think is the best answer?

We’re Living in Mud Huts

/by

In the modern world, we depend on so many standards to protect us in our everyday lives – without even realizing it. For example, when we walk into a building we expect it will not fall down, even in an earthquake.  But before we walk in, we don’t demand to see the drawings, the engineering, or the credentials of the builder and inspectors.  We don’t even want to see the final certificate of occupancy: we just assume that the building has been constructed according to good, complete standards.

Regrettably, the networking world is not quite to this standard of design and implementation.  Yet, today we completely depend on the networks for business and assume that they are generally well architected, built well, and up to whatever standards of protection and compliance there are.  However, we continually read warnings about doing banking online on a public WiFi network, or change our passwords because people can steal them from company directories, and so on.  Yikes!

hut1You see, networks have been built by so many people over decades, largely without standards for design, inspection and operation, and have grown so large and complex, that basically it’s as if we were living in mud huts from 2000 BC.  Is that any way to conduct your critical business? In a mud hut, that is easily brought down, vulnerable to natural and man-made disasters, and not very comforting on the security front?

I wouldn’t live in a mud hut.  And I doubt you would either.  So, if your network is large, complex, and built by many people over a long period of time, there is a good chance that it may not be as secure as it should be for your business.  Ask your CISO what standards have been used in building your network.  PCI? FISMA? HIPAA? These are just a few, but they are a good start to addressing the needs of good and proper network architecture and design.  But these standards have to be repeatedly checked because the network in which they are implemented changes all the time.  In reality, there aren’t any great standards.  And until there are, and networks are rebuilt in accordance with them, every CEO needs to understand the risk of running his business out of a mud hut.

What Keeps CEOs Up at Night?

/by

Post 3 – What keeps CEOs up at night?

As a CEO, getting a good night’s sleep is harder and harder these days.  We used to worry about competition, labor problems, regulatory issues, financing issues, sales and, if our company was public, our stock price.  In the 21st century there is a new worry – cyber threat.  Cyber attacks are real and they can be devastating.  Cyber threats come in all shapes, sizes, types, and intentions.  And they are, for the most part, completely automated.

ceo-night1Every business depends on its networks, and we have every indication that dependency is increasing at a dramatic pace.  These networks and the technology that makes them run are constantly changing.  They evolve to suit the needs of business, and they are improved in performance and security by new products.  Unfortunately, they are often built without a big view architecture in mind: “just make it work” is often the order of the day.

As CEO, knowing that these networks run more and more of your business, you should be asking your team – is it better today than yesterday?  Is it more secure today than yesterday?  What happened on our network yesterday?

Getting this data in a standard, understandable form is no small task.  Further, because things change often, the CEO needs to know the answer to this question often.  The geeks still build and operate the networks though the business people use them – kind of like cars and roads.  You don’t need to know how they are built, but you do need to know they are safe and reliable.  As CEO, you must care whether your network is safe and reliable and that you have a team in place that can do make it so.

Somewhere Over the Spreadsheet

/by

Two years ago I was standing in front of a group of security geeks in Santa Barbara for BSides LA talking about the sophisticated tools that most network engineers use — like “ping” and “traceroute” and even Excel — and about how the broad range of tools available typically didn’t get used in a primordial jungle of our enterprise networks. Recently, Wired concurred, outlining the widespread use of spreadsheets for a broad range of business functions.

new-spreadsheet1It is embarrassingly common for us to find the majority of network management information in spreadsheets. Lists of devices, lists of firewall rules, hierarchies of networks. All laid out in nicely formatted tabs within multiple spreadsheet workbooks, often stored in SharePoint or Google Docs. But, always, devoid of context and the real meaning of the elements.

This isn’t to say that there isn’t a place for spreadsheets, of course, but I would challenge you to think through how you are using them and whether or not they are giving you the information you need to know rather than believe what your network is really doing.

For example, a couple years ago I was visiting a major retailer as they were working through their PCI audit. They presented the auditor with an annotated spreadsheet containing all of the firewall rules within their infrastructure. The auditor, for his part, recognized that evaluating firewall rules out of context masks the reality of the way a network operates, and asked to review the PCI zones using RedSeal. The insights for the organization and the auditor were rapid and clear, and the organization was able to take steps to improve their overall security as a result.

So, although spreadsheets are valuable for building lists of the “stuff” that makes up your environment, they are no substitute for automation that can show you and tell you what you don’t know you don’t know. What do you keep in spreadsheets? What do you wish your spreadsheets could tell you? What’s the strangest experience you’ve had with spreadsheets?

JIE-READY STEP 4: Develop artifacts for IA and ATO

/by

The design and implementation phases of JRSS and JIE will, very likely, receive a significant amount of scrutiny from Information Assurance (IA) to ensure that numerous standards and guidelines are followed. The goal of this scrutiny is to obtain an Authorization to Operate (ATO). There are many different components of the IA process and developing artifacts to support the ATO effort (unfinished sentence?). RedSeal will provide some unique analysis artifacts that without RedSeal would be extremely cumbersome and time-consuming to obtain. At a high level these items include STIG checking for devices, segment access validation, validation of configuration against standard or gold build, and logical zone compliance.

jiestep4RedSeal’s model of the network will allow for faster artifact development and the development of these artifacts BEFORE deployment. The RedSeal platform has the capability to combine any components of the model (hosts, devices, subnets, etc.) into logical groups. These are referred to as zones (sometimes also called segments or enclaves). Because RedSeal understands all the access in the network, the platform is capable of presenting and measuring all access into and out of the zone and between all other zones or the network at large. It is also possible to write business or policy decisions against those access paths and track those decisions for compliance purposes. This RedSeal use case will assist JRSS and JIE with meeting or exceeding the Department of Defense Ports, Protocols, and Services Management (PPSM) guidelines. These guidelines will be applied to the Joint Regional Security Stack (JRSS) and the components that comprise the stack.

Assessing network access by logically zoning or grouping is one piece of the puzzle. RedSeal will also be assessing the components of the JRSS for compliance with other standards of configuration as mentioned earlier, such as STIGs and gold builds. These device level checks are somewhat customizable as well. Certain components of STIGs require modification to meet the environment, and RedSeal allows for that customization within STIG specific checks. It also allows for full customization or creation of device-level checks in the event a new verification check is needed. Within the RedSeal platform, not only is the security of the network analyzed, the security of the component stack providing the security services is analyzed and verified as well.

The Department of Defense has already begun building JRSS and assessing legacy networks. Understanding that legacy infrastructure, ensuring it is effective and efficient, assessing security and meeting compliance during design and migration and beyond, are critical steps. Are you ready for JIE? RedSeal Networks is.

JIE-READY STEP 3: Visualize before migration

/by

The phase between design and implementation for JRSS and JIE is critical. During this phase the most important thing is to have full visibility of the entire JIE infrastructure, even before it is migrated. RedSeal provides the bridge mechanism needed during this critical assessment phase.

Visualization can lead to deeper understanding of the current behavior of segmentation and the effectiveness of controlling access to these segments or enclaves, which in turn helps in reducing redundancy and increasing efficacy.

 

jiestep3

Visualization, identification and measurement allows you to identify and measure all the avenues of access, understanding them visually and through technical reports. RedSeal provides identification and measurement that are not restricted to live networks or devices. The model can be created using proposed configurations or design considerations and present what the network and controls will look like before deployment or in between deployment and cut over. This distinct capability will provide the bridge mechanism needed during critical assessment phases between design and implementation for JRSS and JIE.

Another benefit of the RedSeal network model is faster artifact development, as we will discuss in the next post.

Another Day, Another Breach

/by

On Wednesday, August 20th, UPS announced that a breach may have compromised customer data during up to 105,000 transactions between January and August. While UPS is to be commended for coming forward so quickly, this breach underscores the truth that organizations with highly sophisticated and advanced capabilities in information technology aren’t inoculated against breaches. It is easy to think that organizations that are breached must not be focused on their technology or current in their capabilities. This breach shows us how very wrong that thinking is. In fact, just last month, Fortune wrote an article about how challenging UPS’s analysis must be, and how they solve it with technology.

Ultimately, this is a lesson to every organization that the combination of complexity and continuous change–including planned and organic growth of technology deployed and the inexorable advancement of technology–mean that it’s virtually impossible to even be aware of all the potential paths of attack, much less be able to protect against them. Gone are the days of having sufficient understanding of the network in the heads of one or two people, allowing fast and accurate analysis and countermeasures.

Unfortunately, today no human being can possibly know what the network is capable of allowing to happen.

It is critical for all enterprises to deploy not only reactive security analysis such as IDS/IPS, but also to use a cyberattack prevention system to analyze their entire network as it is actually implemented, to expose all potential paths and to provide guidance in plugging inappropriate holes. Otherwise, we will continue to see more and more breaches, with broader and more devastating impact. Enterprises must take action by using cyberattack prevention to avoid being the next casualties.

JIE-READY STEP 2: Defense in depth

/by

Defense in depth is a term and idea that is not new to the information technology world. A classic implementation at the network level of defense in depth is segmentation, or building enclaves. In certain cases, segmentation was taken to an extreme level, resulting in massive decentralization of computing environments. Unfortunately this decentralization does not remove the need for these segments or enclaves to communicate with other information assets. Thus the segments or enclaves are connected to the network from which they may have originally been divested. This does not mean that security controls restricting or monitoring access to these enclaves was removed. What it does mean is that there is a very high likelihood of major redundancy implemented while attempting to secure or control these segments.

jiestep2The RedSeal model can be leveraged to not only identify these redundancies visually, but to also identify the efficacy of these controls by measuring access across and through the entire network. Investigating one segment of the network and the control mechanisms related to the segment is not sufficient. The network must be measured as a whole operating entity or system to effectively identify all possible access and points of control. Through these means, RedSeal will be providing another unique benefit to JRSS and enhancing the preparedness for JIE.

Understanding the current behavior of segmentation and the effectiveness of controlling access to these segments or enclaves will assist with reducing redundancy in the current operational system while increasing efficacy. There may be too many rules in a firewall creating overly-restrictive access and operational bog to the system. There may be too many routers providing similar or identical access to systems, between systems, or across network boundaries. Perhaps there are too many layers of load balancing performing additional address translations and VIP presentations that are not only difficult to manage but not really providing any more security. RedSeal will identify and measure all the avenues of access and represent it visually and via a myriad of reporting techniques in technical depth.

Our next blog will discuss Step 3 – Visualization before Migration.

JIE-READY STEP 1: Know what you have

/by

The first and arguably most critical step in any data center consolidation or migration is to first understand what you have. Most complex or large-scale networks have grown so rapidly over the years or decades that there is no clear picture of the functioning system. As the opportunity to refresh large-scale global infrastructure becomes available today, experts are building security in on the front end. The challenge is understanding what exists today, how it is (or isn’t) being secured, and then designing the security requirements in tandem with the new system/network. RedSeal Networks provides a unique perspective on what is happening today on the network, how the network is actually connected, and the efficacy of security controls deployed in the network.

jie-step-1RedSeal Networks can provide this unique perspective by aggregating the configurations of core components that comprise the network, more specifically routers, firewalls, load balancers and switches. The RedSeal platform then analyzes these configurations and creates a model of the network. This is a visual representation of the network itself, but it is also a full model of all possible access based on the devices and the configurations of those devices. This model is a critical first step in understanding the DoD infrastructure today and will be the foundation upon which RedSeal will continue to provide unique data for the success of JRSS and JIE.

The model of networked infrastructure that RedSeal is providing to the JRSS project will not only help understand access at a high level. This model allows the capability to drill down into specific access areas, enclaves, single path analysis, and even model access that doesn’t yet exist. It is this flexibility that will allow architects and design experts to understand, from a high level down to fine detail, what is working today and what is not, so the new infrastructure can be designed effectively and efficiently.

Our next blog post will address Step 2 – Defense in Depth.