Recently, a client of ours expressed interest in segmenting their existing, flat network. The existence of these types of non-segmented networks is still very prevalent, especially in the manufacturing, supply chain, and medical verticals. The primary reason the organization wished to move on this initiative was in an effort to reduce the scope of their PCI-DSS requirements. However, they also understood the risks to the organization in allowing business network assets (e.g. receptionist laptops, multi-function printers, etc.) to communicate with factory floor assets, such as expensive production steel presses, laser cutters, or chemical mixing systems, especially with Internet of Things (IoT) connectivity needs looming. One successful phishing attack on a user whose laptop can communicate to these production-critical systems could have potentially drastic outcomes on the organization’s ability to generate revenue. Right, so this story is starting out great! The organization is going to be (somewhat) proactive about reducing PCI scope and will be introducing network segmentation into their environment.  This will lower the likelihood that a simple and successful phishing attack could affect the production plant floors that the business relies upon to generate revenue. Awesome! What’s next?  

That Feel Good Session Was Short Lived

Our client reached out to their go-to network vendor and explained their intentions of segmenting their currently flat network to ensure proper separation between the IT networks and the OT (Operations Technology) networks. What they promptly received was a quote to create up to 10 VLANs on their core layer 3 switch for roughly a few hours’ worth of time. Now, don’t get me wrong, cash is king for most organizations, and getting good services for a good price is likely going to be a favored outcome. I personally do not make it a habit to look at a good deal on services and tell the consumer that they should probably be paying more for something like this.  

Hold My Beer!

HOWEVER, in this case there were so many things wrong with the proposed approach, it was necessary as a third-party consultant to break down the adjective “good” in the above phrase “good deal”. These are production networks and plants, where even the most minor disruption of the transmission of data from point A to point B could result in, minimally, an eight-hour loss of production and associated revenue. Not fully planning out such a large-scale initiative like this is essentially the networking version of “hold my beer!”  

Understanding Business and Functional Requirements

0. Foundationally, organizations looking at segmentation initiatives, irrespective of the business drivers, need to ensure that some of the basics of identity management are in place: data classification, documented portfolio ownership, and at least a basic level of directory-controlled, role-based access. The latter requirement does not, at least initially, need to be an enterprise-grade RBAC framework. We simply need to have some well-defined user classes that we can begin building user persona use case scenarios from.   1. With at least the basics in place, the first step in building a segmentation design is understanding what the problem statement is. Ultimately, the business need should be the priority at the leadership level. In my above example, the driver was reducing PCI scope by turning the existing, flat network into a more compartmentalized, segmented network with enforceable controls. This design is intended to limit access to cardholder data and the systems that touch it to user accounts with a business need to access said data. This segmentation model can also be used in creating controllable network segments for Internet of Things (IoT) devices. The rapid adoption of IOT technology is making this a prioritized initiative in many organizations. Other similarly important business use cases include restricting access to Intellectual Property (IP), protecting Personally Identifiable Information (PII) and restricting access to legacy unsupported operating systems.   2. The next step is to flesh out the existing, and relevant, user personas. In some environments, this can be done relatively quickly by looking at the defined Active Directory groups. Others, depending on the volume of groups and overarching AD design, perhaps not as much (your mileage may vary). Either way, the desired outcome is to have defined the relevant user personas within the organization, limiting persona groups to business needs that translate to addressing data and systems network segmentation. Keep it simple. Does HR have a legitimate business need to access confidential Research and Development (R&D) IP? If the answer is no, we can now document that as one of our functional requirements. Determining how we will perform the enforcement of the functional requirement isn’t critical at this point, and those decisions can be made once the final functional requirements are documented and the segmentation project moves into the architecture phase.   3. Once the organization’s user personas have been defined, it is necessary to build an application inventory if one does not already exist. This includes all cloud/hosted applications as well. Segmentation projects are inherently intended to create access barriers between defined portfolio systems and applications. Going into a segmentation project without a clear understanding of the enterprise’s current applications and associated services required to maintain day to day productivity is not highly recommended. You want to give yourself the highest possible chance that when you make the segmentation cutover, all applications and services are functioning as needed to ensure your production business systems are not disrupted.   4. Defining and understanding use-case scenarios should be documented next. These scenarios can be a relatively simple concept, like time synchronization across all network devices and servers. A more complex scenario could be verifying that all third-party hosts connecting remotely into the organization’s internal networks comply with the documented information security policy. Again, from an outcome perspective, the intent here is to define all of the likely interaction scenarios that user personas and/or systems themselves will require, ensuring as little disruption of production services as possible when the segmentation switch is thrown.   5. Finally, once the problem statement(s), user personas, application inventory, and use-case scenarios have been completed and documented, the last phase is to build-out the functional requirements. Each use-case scenario should now be linked to the necessary user personas and applications needed to ensure the business functionality remains uninterrupted. Additional data, such as cost benefits, difficulty and constraints, as well as any associated security requirements, will greatly assist whomever will be putting together the actual design and associated architecture.  

Lessons Learned

Having worked with a number of different organizations in this manner across several different verticals, I have seen this process not only be immensely beneficial from a business continuity perspective but also extremely valuable to the IT/IS side of the house. Walking through this kind of exercise gives the technical teams excellent insight into what each business unit/user persona does, and what they require to fulfill their roles and responsibilities. That is something that unfortunately not all organizations can accomplish (or sometimes even think about). This insight, in my opinion, is invaluable and almost always has the added benefit of teaching the IT/IS teams things they had not even realized about the user base they support. And, most importantly, you are not left holding someone else’s beer.  

Are you looking to understand the new risks that come with a connected IoT system? Listen to our webinar “IoT Security – Getting ahead of the digital impact to your business.”