Pragmatic Approach to Security

Security, security, security. It keeps CIO’s awake just thinking about it. Just ask the US State Government CIOs. The challenging thing about IT security is that it covers nearly every aspect of IT from design and build around networks, platforms, applications through to threats, risks, mitigations and identity. The good news is that the budget for IT security seems to be on the rise. With all that extra money, the only question worth asking is what to spend it on?

Apart from simply suggesting that the extra cash could be spent on complying with the top cyber intrusion mitigations identified by the Australian Signals Directorate with their Top 4 and their extended Top 35 – as valuable as they are, perhaps those extra funds could be spent on the basics surrounding good design. In this case I’m referring to the pragmatic use of:

  1. Network zones.
  2. Controlled ingress and egress points.
  3. Layered security.
  4. Redundancy in your controls.

Although it is important to note that each organisation is different and the nature of the data stored, the infrastructure and application topology and the use cases surrounding systems, end points and information can be wildly diverse there are still a common set of approaches one can take. So lets explore these good design approaches:

1. Network Zones

I’ve seen some organisations with almost zero security zones and I’ve seen some organisations with so many zones I wondered how anything got done. The right number of zones is largely academic in my view but there has to be a common sense approach right ? So lets start with:

  1. You will need a DMZ. In fact, you may even have two DMZ’s. One for external users – an absolute must and one for internal business systems users – a maybe. The decision to stand up an internal DMZ should be made around:
    1. The nature of the information collected, processed or retrieved.
    2. The quantity of the staff. The greater the number of staff, logic states the greater the risk that someone will do something wrong.
    3. When an internal DMZ will actually reduce the risk and consequences of real threats when considering alternate methods. This ties back to nature of the information in point 1.
    4. When you can control the number of the ingress and egress IP addresses and ports to a relatively small number. There is little point creating an additional DMZ if your firewall rules suggest you will have swiss cheese for a firewall.
  2. You should segment off your users and corporate systems into a separate zone from your business systems.
  3. Your business systems should be in a separate zone.
  4. Your SAP system should be segmented in its own zone. Allowing foreign nationals in to support the system is bad enough but allowing foreign nationals into a system that is not isolated as much as possible is just bad insurance.
  5. Your databases should be in a separate zone – after all information is the primary focus of almost every system.
  6. Any data that is classified higher that the network’s classification will have to be in a separate zone (also known as an enclave).
  7. Management Zone.

The tricky part is knowing how to further segment your business systems. I’d suggest the following rules of thumb when it comes to considering whether to or not:

  • Some COTs systems may end up being in their own security zone because the design of them presents far too many IT security problems when it come to alignment with current security architecture.
  • Systems that receive, process and store information of a certain classification but has multiple level of classified users that access information with different classifications.
  • Non production environments versus production environments.

Remember, more security zones = more costs. Do not underestimate the effort required to build a new zone, maintain that zone and make changes to that zone when you have a new system to deploy into it. They should only be considered with care.

2. Controlled Ingress and Egress Points

Although we use network firewalls as the primary control point in to/out of a security zone, network firewalls represent the front door to a building. They allow controlled access in. Controlled access through the front door is great but it is by no means the be all and end all. We’ll explore this further in a minute.

Even though there are an enormous amount of defined protocols in use, most modern systems communicate with the user or another system via a small subset of protocols. These being:

  1. HTTP (Person to System & System to System varieties).
  2. A Messaging/Queueing protocol (System to System).

To further complicate the issue of controlled ingress/egress points for a zone, many systems may actually have multiple instances of a service or application to accommodate high volumes of usage. There are a number of ways to address access to multiple instances (a.k.a multi-node systems) but generally speaking, a load balancing service is used.

But we still haven’t broached the topic of application layer security (Layer 7 security). This, as I noted earlier was the thing over and above the be all and end all. Even though the traditional network firewall is controlling access through the front door, we still need to run the people through the metal detector. Application layer security is that metal detector and there is a massive amount of resources available to help, Just as Microsoft, GIAC or Applicure.

When you look at all these factors:

  1. Systems use a discrete set of protocols.
  2. Systems can generally be accessed via a load balancing service.
  3. Systems require a Layer 7 firewall.

You can almost combine all these elements to restrict access to your business systems security zone to a single device that will act as :

  1. Reverse proxy.
  2. Load Balancer.
  3. Layer 7 firewall.

There are a number of products that can perform these functions. The crux of this section is that controlled ingress/egress to a security zone can and should largely be controlled via a single device.

3. Layered Security

Layered security is fundamentally about ensuring the security of each of your 7 OSI layers are appropriately addressed. SANS has a good write up on layered security and the US Department of Homeland Security has a small quick guide on some of the security attacks that occur across the layers. PWC released a report a couple of years ago that showed the spread of security attacks across the different layers. In essence, the foundation of good security is that security controls must be in place across all the OSI layers. For instance there is little point in doing half a job by say

  • Having a network firewall in front of your server to prevent access to most of the ports available.
  • Having your operating system up to date with security patches with well defined file system ACL’s.
  • Implementing application white listing on that server.

if you are running a web server with poorly coded web apps such that simple SQL injection can be successful in extracting all the data from the database.

4. Redundancy in Your Controls

One valuable lesson I learnt is to ensure you have redundancy in your controls. Remember, nothing is perfect. An organisation may have excellent policies, staff may be of good character and you keep your operating system and application patches up to date and you have excellent separation across your network and security zones. All this (and everything else you do) means you maintain pretty good security. But what if one of those controls fails ? After all, people ignore policies, your techies can and do fail to maintain patch updates, and applications always have bugs that can be exploited.

The best way to the reduce risk of a security incident is to have redundancy in your controls. For instance:

  • To mitigate your application from suffering from poor coding practices, ensure you have a layer 7 firewall.
  • To mitigate the risk that the service account your application uses to access a database has poorly defined permissions within the database ensure you have a database firewall in front of the database that only permits the the particular service account (from that particular server) can only execute the required SQL queries.
  • To mitigate the risk that your virtual server’s hypervisor leaks data across virtual machines, create appropriate affinity rules – or run different clusters for different classified systems.
  • To mitigate the risk that a user accidentally points a non-production system to a production system, ensure you have appropriate zones or other security controls in place such as local software firewalls, authentication and authorisation controls whereby different accounts are used across different environments.
  • To mitigate the risks that staff ignore policies, have appropriate logging with triggered alerts for anomalous behaviour.


Irrespective of your IT security budget and before investing your dollars on fantastic enhancements, architect your environment in such a way that you:

  1. Separate your systems into appropriate zones.
  2. Have well defined and controlled ingress/egress points to those zones.
  3. Ensure you have adopted a layered security approach. This correlates to the term sometimes heard – Defence in Depth.
  4. Ensure you have redundancy in your security controls to ensure you are not reliant on a single control to mitigate a risk.

We’ve covered a lot and really have only touched the surface when it comes to IT security so feel free to add and lets discuss this further !


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s