Even static environments require security. In this video, you’ll learn about layered security, network segmentation, tcp wrappers, application firewalls, and firmware version control.
<< Previous Video: Static OS EnvironmentsNext: RADIUS and TACACS >>
Static operating environments create a few additional challenges for security professionals to be able to mitigate risk. In this video, we’ll talk about some of the techniques we use, not only to mitigate risk on our traditional operating systems, but we’ll talk about how we can change these just a bit to take into account the static operating environments.
One thing that doesn’t change when you’re working in a static operating environment is the need for layered security. We want to have what we’ve always called defense-in-depth. There’s never just one single security device in place. We want to have different strategies and different processes in place so that we can every step along the way prevent that particular security risk from getting through our system.
The security controls themselves should also be very diverse. In fact, it might be a little different than the picture that shows exactly the same hurdle, one after the other. Instead, we might have hurdles that were different sizes and different widths to prevent the same type of attack from getting through our system. We would want to have a different firewalls and different IPSes.
And we might want to have different processes, all working together, to have this defense-in-depth. We want to also avoid any single points of failure. If the bad guy can bring down your firewall, there’s potential then for them to go right through all of your other security systems. So you might want to consider multiple firewalls, redundant intrusion prevention systems, and even multiple management systems so that if one management system goes down, you can still be alerted and get messages should any security concerns arise.
One very common defense against the bad guys would be to segment the network into different pieces. We might have one logical section of the network for internet traffic, another one for our DMZ. There may be a storage network. We might also have a separate network just for the management of the network. And our corporate environment may have another section all unto itself.
The idea here is to limit the impact of a breach in the network. If someone does make their way to the DMZ, we’ve already segmented out the rest of the network. And at least that particular breach would not be able to impact other parts of the organization. The segmentation may be physical. We might have separate switches, and separate routers, and separate security infrastructure for each individual section of the network.
Or we might set this up to be more logical. We might have separate zones and a firewall. We might separate out rules based on IP address, or destinations, or sources. By doing this, we can create a logical separation without needing additional hardware or infrastructure to be able to protect these parts of the network.
We want to think about how we want to separate out the network, and then create separate security policies based on these separate zones. So, for instance, you might require that nobody has any personally identifiable information in the DMZ. And you want to be sure that if any credit card information is transmitted that it never goes across the network, and it’s always encrypted when it does travel anywhere else in the network.
We created TCP wrappers as a very early form of application control. This allowed us to put a wrapper between the network and the service that was running over these network packets, to give us a little more visibility into the application that was going across our networks. And we used access control lists then to be able to manage whether certain types of application traffic could go over our network or not.
Today’s application firewalls take a complete holistic view of the traffic patterns that are going across the network and are performing deep packet inspection to be able to truly recognize all of the different applications that are going over the network. We can even get some very specific types of application definitions.
For instance, we can recognize general Facebook traffic, which is different than somebody trying to post to Facebook, which is also very different than somebody trying to chat on Facebook. Each one of these is seen as a separate application. And we can set controls in our application firewall to allow or disallow all of these very specific application types.
These application firewalls can also find very specialized applications like SCADA, where you really need to protect some of this very large industrial equipment from being accessed from anywhere on the outside. These embedded operating environments were built to perform a particular task. There’s very specialized software that works with very specialized hardware. And they’re always going to perform that task and nothing else.
Because of this, you don’t tend to have a lot of updates to the operating system or any other part of this embedded working environment. Some of these embedded systems were never designed to be updated. There’s no media that you can plug into the device. And if you do need to, for some reason, perform a firmware upgrade, you would have to completely remove the hardware and bring in a replacement unit that already has the new firmware on it.
Even these systems that do allow for updates aren’t necessarily designed to do things automatically. It’s usually a manual process to perform the upgrade to these devices. They don’t become part of your windows domain.
There’s no overall management software that pushes out updates automatically. It’s more of a time consuming process. And because of that it may be less of a priority, which is certainly a concern when it comes to dealing with security in these embedded operating environments.