Now that we’ve laid the ground work for the baseline differences between application and network architecture, we can get a little deeper into what each kind of work entails. In this post, excerpted from our book, Practical Cybersecurity Architecture, we take a closer look at technical considerations for a network architect and how one can address security at all layers of the network stack. This is because security shouldn’t just apply to a subset of the network, it should apply to all levels.
One of the most powerful conceptual tools in the IT world is the networking stack. Most technology practitioners have some familiarity with either the OSI or TCP/IP stacks. OSI (Figure 1) divides networking communications into seven layers (application, presentation, session, transport, network, data link, and physical):
The TCP/IP model (Figure 2) divides it into four layers (application, transport, internet, and link layers):
As you can see, each layer of the stack comprises specific technologies, protocols, software bindings, and other artifacts that accomplish a particular aspect of delivering data between nodes on a network. For example, protocols that encode individual bits as electrical signals on a wire or as individual pulses of light on an optical fiber are defined in layer 1 of both models (the physical and network access layer in the OSI and TCP/IP model respectively). Protocols that group together individual bits into more complex structures (frames and packets, for example) occur higher up in the stack, and protocols responsible for delivery of those packets to destinations outside the current local network are higher up still.
The point? This network stack concept is powerful because it allows a technology professional to deliberately limit or compartmentalize their scope to only a subset of the network rather than needing to weed through tremendous complexity each and every time they need to accomplish a particular task.
Engineers can focus only on one particular layer of the stack at a time; by doing so, they can “compartmentalize” complexities associated with other levels of the stack that aren’t relevant to the question they are trying to answer. For example, consider a network administrator looking to understand why traffic is not being read by a given application. They might start by looking to ensure that the network is routing traffic correctly to the destination – looking at the IP protocol at layer 3 of the OSI stack. From there, they can either diagnose and debug the problem or, if they are unable to solve the problem by looking at layer 3 in isolation, expand their analysis to include other layers and consider them each in isolation until they do.
The fact that the network stack is organized in this way adds both complexity as well as opportunity for the network cybersecurity architect. It adds complexity because the architect is responsible for all levels of the stack and therefore needs to account for all of them in their vision. This means that they need to factor all levels of the stack and how they are implemented in the organization into their planning; it also means that they need to select and apply appropriate security countermeasures in that plan. This adds complexity because, as anyone who’s looked at traffic on the network can tell you, there’s a lot of surface area when considering all layers of the stack. The fact that the architect’s role is so all-encompassing though also means that countermeasures they put in can either span multiple levels of the stack or target a different area of the stack other than where the problem occurs. For example, a network security architect seeking to address an application issue (layer 7 of the OSI stack) might target another level of the stack to resolve the problem.
As an example of this, consider an application that might not have a facility for strong authentication of users: maybe it requires a username and password but doesn’t use a secure channel such as TLS for the transmission of the username and password. Obviously, the ideal strategy is to address this – a layer 7 problem – at layer 7 itself. But what if that’s not feasible? Say, for example, that the application is supplied by an external vendor and they are unwilling or unable to close that particular issue. The architect then, knowing that there might not be an optimal layer 7 solution to the issue at hand, might decide to implement a solution at a lower level of the stack. For example, they might consider tunneling the traffic, using filtering rules to ensure that only users from inside a trusted zone can access the service, and so on.
The job of the network cybersecurity architect then is to ensure that the solutions that they create, the network design that they work with other stakeholders to build and hone, and the countermeasures that they deploy protect the network fully and comprehensively – that is, at each level of the stack.