Let’s look into compartmentalization a little bit as it relates to security. A quick summary – we can use compartmentalization in our network or organization to get rid of unnecessary information flow. Lemme explain. Here’s an example shamelessly copied straight from Wikipedia.
An example of compartmentalization was the Manhattan Project. Personnel at Oak Ridge constructed and operated centrifuges to isolate Uranium-235 from naturally occurring uranium, but most did not know what, exactly, they were doing. Those that did know, did not know why they were doing it. Parts of the weapon were separately designed by teams who did not know how the parts interacted
If there was no NEED for certain sections of the organization to know about various other aspects, they were shut out from that portion. To use the example – if I’m an engineerer of the specialized pointed tip that goes on a rocket (I’ve seen the cartoons, it definitely has to be pointy), I may be asked to engineer that piece for the Manhattan Project. But do they need to tell me about their target location? Or even the payload of the rocket? Nah. They don’t. Compartmentalization baby.
MMmmmmkay so what. Well c’mon, be creative! How can we use this for our network?
Got anything yet?
I’ll give you some time while I explain a TOTALLY different (*cough*) security issue called pivoting. Say I want to get to SUPERSECRETSERVER:A. But it’s all the way on the “inside” of a network, protected by … security things … and … moats … or something. But let’s say KINDASUPERSECRETSERVER:B sits in between me and ..:A. W311, a5 an 3xtr4 1337H4X0R, I may not be able to get to ..:A, but I can get to …:B. Then from …:B, I can use that as a pivot point to get to A. Meaning B likely has more permissions than I had simply sitting outside the network, so I can use it as a stepping stone to get to my goal.
But what if …:A and …:B have no reason to talk to each other? One deals with the pointy end of rockets, the other with the target location of the bombs. What happens when I block off communication from …:A –> …:B? I stop that option! Y4y m3!
Back to real life. Let’s apply this to our CDC network. Think about your network – we’ve previously blocked out unnecessary communication from the outside (eyyy firewall), but what about internally?
- Create a hierarchical diagram of your network (give ample space between servers.)
- Where your servers have a need to communicate between each other, draw a connection between the two server.
- Does the connection need to be two-way?
- Write along the line which services/ports are needed.
- Are you surprised by how much/little communication is needed within your network? Do you see the security benefits of partitioning your network off like this?
- Go into your pfSense WebConfigurator and implement your newly created rules for your LAN network. (HINT: you already added rules on the external network [WAN], do the same, only select the “LAN”)