The Reality Gap

Architecture, Design, and the Operational Network

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.

The plot was years old.Untitled-1When 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?

 

Leave a comment

Filed under Uncategorized

We’re Living in Mud Huts

By Ray Rothrock, CEO of RedSeal Networks

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!hut1

You 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.

 

Leave a comment

Filed under Uncategorized

What Keeps CEOs Up at Night?

By Ray Rothrock, CEO of RedSeal Networks

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.

Every business depends ceo-nighton 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.

Leave a comment

Filed under Uncategorized

Somewhere Over the Spreadsheet

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-spreadsheetIt 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?

Leave a comment

Filed under Enterprise, IT

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

By Brandon Hoffman, Federal CTO, RedSeal Networks

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.

 

Leave a comment

Filed under Uncategorized

JIE-READY STEP 3: Visualize before migration

By Brandon Hoffman, Federal CTO, RedSeal Networks

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.

JIEStep3Visualization 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.

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.

Leave a comment

Filed under Uncategorized

Another Day, Another Breach

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.

Leave a comment

Filed under Uncategorized