CISSP Reloaded–Domain 3: Telecomms & Network Security

This is the 3rd part on my CISSP Reloaded where I am revisiting the 10 CISSP domains I studied for many years ago to see what has changed and how much of it I have retained as well as adding in my own personal thoughts, experiences and rambles into the mix. Read domain 1, intro and risk management http://www.j4vv4d.com/?p=433 and domain 2, access controls at http://www.j4vv4d.com/?p=438

 

Domain 3; by far the most daunting of domains when I first picked up the book all those years ago. Network security is so important yet because it’s complex, a lot of companies end up doing it wrong. It’s complex because not as many people ‘properly’ understand the security implications of the network and also because most companies don’t even know what their network comprises of.

When you go through the theory of network security, it’s a bit like travelling on the roads of a developed country whilst being aided by a comforting female voice spoken in perfect English via an onboard GPS. “After 400 yards, turn left”. All the roads are well lit, the road markings are nicely painted on and colour co-ordinated. The speed limit is observed by everybody and people maintain a safe distance from one another.

The first time you’re dropped with an incident in the middle of an organisation, you find that this road network is more like a series of half-beaten trails in some abandoned bush path. If you’re lucky, you’re given a compass and a rusty machete to try and hack your way to your destination.

This really is a big domain and neither can the CISSP material nor can I do it justice by trying to break down the concepts into one domain. Hence why the CISSP is often referred to as being an inch deep and a mile wide in terms of the knowledge it imparts. So if you’re recruiting a network security expert and they have a CISSP. Don’t assume the CISSP taught them anything usable. Of course I could say that for most domains, but this is by far most true for network security.

The CISSP material has a lot of the theory behind how networks operate, talks about the OSI Model, what TCP/IP is, gives examples of different types of networks, network monitoring and of course the be all and end all of all network security – Firewalls <insert sarcastic gasp here>.

Different books and materials will cut this domain in different ways. Personally, I like to divide this into two halves.

1.How the network works

This half has little to do with pure security, but lays the foundations of the concepts of how a network actually works. Along with network types etc.

2.Network devices

Covers the hardware, software and other magical beans that shape, tunnel, morph and direct how traffic traverses the network and by virtue, how to make sure the securest route is taken.

1.Understanding the Network:

Protocols & Layered architecture:

Protocols – The cornerstone of every healthy network. They’re what make the whole world go around.

In some ways protocols are a bit like the U.N. They allow different devices from all over the world who speak in different languages and have different cultures to speak to one another without the boring monotone of a translator. It allows the president of Nairobi to pass messages over to the King of Saudi about oil exploration, while the Japanese can converse with Europe over their latest car emission regulations. It’s all very clever and well organized.

To aid all these protocols talking amongst themselves on different topics, at different depth of detail, there is the concept of a layered architecture. This breaks down the complex communications process into simpler sub-layers and enables interoperability. It also means you can change the way one layer works without having to change every single layer.

There are different layered models, but everyones favourite is the OSI (open systems interconnect) model, whose 7 layers in all their their glory are:

7: Application

6: Presentation

5: Session

4: Transport

3: Network

2: Data Link

1: Physical

In this layered model, when data is sent from one computer to another, it starts at layer 7, the application layer, down through each layer to layer 1, the physical layer. Passes across the physical medium i.e. your cat5 cable or fibre or whatever it may be and then on the destination computer up from layer 1 to layer 7.

As the data passes through each layer on the source computer, it gets ‘tagged’ by each layer and when it reaches the destination computer, each tag is picked up by the corresponding layer.

I’ve found in my notes reference to OSI Security services and mechanisms which I don’t recall reading but they are listed as follows:

OSI Security Services

1.Authentication

2.Access Control

3.Data Confidentiality

4.Data integrity

5.Nonrepudiation

6.Logging and monitoring

OSI Security Mechanisms

1.Encipherment

2.Digital Signature

3.Access Control

4.Data integrity

5.Authentication

6.Traffic padding

7.Routing control

Looking back at these, they are quite nice lists. Especially the security services, which is applicable to more than just networking. In fact, if you added availability to that, it would be a more advanced form of the CIA triad that you could refer to in any risk assessment scenario.

TCP/IP

The most famous rockstar of the net has to be Trasmission Control Protocol/Internet Protocol or TCP/IP. It’s a suite of protocols that make the internet work. It’s what the OSI model would look like if it went on the atkins diet as it only has four layers instead of seven.

4: Application

3: Host to Host

2: Internet

1: Network Access

The TCP/IP Protocols

The TCP/IP suite is made up of a number of protocols.

If all this terminology of protocols and models and layers is getting confusing, I don’t blame you. I’m getting confused just writing about this. So lets break it down into something my simple brain can process a bit better.

Protocols are like musicians. One may be a drummer, the other plays guitar, you have a vocalist and so on.

The TCP/IP suite of protocols is like a rock band made up of different members. Actually it’s more like an orchestra because you have a number of different instruments in there. But let’s look at the key players in the TCP/IP rock band:

Drums: TCP

In the corner in the back, providing the intro and the beat is TCP. TCP packets are sequenced to match the original transmission sequence number and retransmits any that are lost or damaged. A drum kit is expensive and a bit slow. But it keeps the beat and reliable.

Electric Guitar: UDP

Over on the electric guitar, is the head banging UDP. It doesn’t care if you can hear anyone else over it’s noise, it’s lost in its own world. It’ll blast them tunes out, having an entire generation either jumping off the sofa’s playing the air guitar or putting their fingers in their ears. It’s not reliable like TCP, it doesn’t care if you receive the message or not. It just streams and streams until it can stream no more.

Vocals: IP

The main star on the vocals is Internet Protocol (IP). All hosts on a network are assigned an IP address. It makes sure that each packet is assigned the IP address of the sender and receiver. It’s the glue that holds the stuff together. It’s not guaranteed that every packet will indeed reach it’s destination, but IP will make a good stab at it.

Whats funny is that all those years ago, my notes state that there is a ‘new’ initiative called IPv6 coming soon because we’re all out of current IP addresses and then every man, woman, child and dog will be able to get their own IP address. Ah yes, the promise of IPv6, the holy grail that we’ve waited so long for. Whilst on the topic of IP addresses, it’s probably worth making yourself familiar with IP Addressing and the different classes and how they work, the fact that IPv4 uses 32 bits for its addresses and IPv6 uses 128 bits. Again, the CISSP is too shallow to teach you enough about this.

Band Manager: ARP

A good band manager liaises with many outlets gathers information for their band. Typically this involves contract negotiations and striking a good deal for their band. ARP does a similar fact-finding mission in that it finds out what the MAC address for a device that is configured with a particular IP address?

Record Label: RARP

The record labels do the opposite of what the band manager is trying to do and try to pay the band as little as possible. To drag on this poorly thought out analogy, RARP knows what the MAC address is but is asking what the IP address is.

I promise this analogy sounded a lot better in my head when I started writing this.

Groupies:

I’m going to be lazy and call everything else groupies who hang around following the band everywhere such as:

ICMP

Telnet

FTP

SMTP

Etc.

There are others too, but listing them out won’t achieve much and I can’t go into details of each protocol, not least because my band analogy won’t stretch that far and I would always recommend that if you want to learn the technical aspects of networking in more detail after your CISSP, to choose a dedicated networking course or two or three and a whole lot of practice.

2.Network Devices:

As I’ve mentioned several times already, my notes are old and maybe the course material has been updated. But the CISSP when I done it, had a bias towards firewalls, talking about the different types of firewalls and the types of firewall architectures. It’s all good stuff to a degree. But every device on your network has a security impact. Each device on your network is an entry and or exit point. It could introduce vulnerabilities or can be bought up to harden your security like a Rottweiler.

Also, one has to consider the plethora of security devices that are out there claiming they will shape your traffic to meet your needs, kill a suspicious packet dead on sight and produce you lovely pretty graphs with blinking lights showing how all your network is being secured.

The difficulty I’m faced with at this point is that technologies are evolving and so are the attack avenues. A few years ago there weren’t too many wireless points within organisations. Today you can’t drive past an office without picking up a wifi signal.

So let me deviate from the CISSP course material I have a bit more than I already have deviated (don’t worry, the CISSP material is more of a guideline than actual rule).

If you cast your mind back to Domain 2 where we touched upon the three types of controls (protective, detective and recovery). We can apply the same principles here. We want to implement devices that will protect the network, detect if there is malicious activity on the network and help network recovery.

But, before we go all running headfirst into battle, lets rewind a bit more and go to Domain 1 where we talked about risk management. We would first need to determine what we are securing the network against and why and if the controls we are implementing are appropriate to the risk.

Wow that’s a bit of a mouthful! If you find it difficult to keep jumping back and forth between domains, you may find it easier to go all “Memento” on it and have the domains tattooed on yourself to remind yourself of what they are.

Think of it like this. You’re barricaded in your base and you hear that the enemy is about to attack. You have land mines, machine guns and anti-aircraft guns. But, you only have enough time to deploy one of these. Which one will you deploy?

This is more or less what a risk assessment situation is. You try to guess what is the most likely way the enemy will attack. Will it be foot soldiers? Or Tanks? Or Helicopters?

Now I know some of your smartasses out there will probably try to be clever and say you’ll use a modified machine gun with armour piercing rounds or something James Bond-esque like that so it can take out soldiers, tanks and helicopters alike like a hot knife through butter.

That maybe so, but what if I throw in another dynamic. What if you don’t know what the enemy’s motives are? Huh?

This is where the network is a lot more interesting than your traditional application or data security because the attacker has several different options here.

1.They could be attacking the network directly to bring it down (e.g. a DOS)

2.They could only want to attack the data that is travelling along the network, e.g. sniffing credentials off the wire.

3.Perhaps they want to inject malicious traffic into the network to use it to get to a database, or maybe simply corrupt the data that is on the network.

4.Launch a man in the middle attack by redirecting the network through them

5.Use the network to smuggle data out of your databases to them.

6.Use your network to launch an attack on somebody else

7.Etc

As you can see, there are lots of different scenarios here. Sometimes the aim of the attacker is to break your network, and sometimes it’s in their interest that the network remains up and healthy.

Which is why in theory it’s a great idea to segment your network depending on the type of data and traffic and risk assessment of that network segment. Which is what PCI DSS intends to get you to do by segregating card data from the rest of the network. This is a great idea in practice. For many many years people have been preaching that the days of the M&M network model are dead i.e. a hard crispy exterior with a soft interior and that now one should strive to implement a segmented and fully hardened network.

In reality, most organisations still have an M&M network model with a few firewalls on the outside and an internal network so flat you could use it to align a spirit level.

On top of that, large organisations have typically swallowed other organisations over the years. The process usually resembles something out of the human centipede. Note, if you haven’t seen the film, you probably don’t want to see it. It’s very gross. But that’s how the network looks. Pretty gross. So you could be a small 3^rdparty in the Isle of Man who once were granted remote access to troubleshoot a stand-alone server in an unmanned facility. But from there you could easily and merrily navigate yourself through the entire organization.

I’ve seen many organisations like this. Sure, you may be fortunate enough to be working for an organisation that has it’s network nailed down. But not the ones I’ve been in. In fact, one had everything on their flat internal network. Including the door access control systems. Which meant that you could add yourself (your badge) onto the ACL of any door in the entire organisation…. Globally. Including datacenters, offices and the electronic safes.

OK there is a slow shift away from the flat network. Helped quite a lot by PCI DSS, even if it is begrudgingly. The benefits of this is that people are more aware and open to the idea of network segmentation and creating zones of trust etc. So you create secure zones surrounded by well tuned and configured devices like bouncers in black suits, dark glasses and earpieces who escort the president around. The data that is of most importance is locked in your safest zone and other data in other zones accordingly.

OK that was a bit about flat networks and the challenges you’ll face trying to convince people that you need to change it. Which, in many ways is what you’ll be spending a lot of time doing in network security. Convincing people of the right way of doing things. You’ll come across managers who heard a great sales pitch from a product vendor and they’re all star-struck by how wonderful the product is and you have to slowly calm him down and explain why that certain product isn’t a great idea, not necessarily because it’s a bad product, but because it wouldn’t work well in your current setup. This type of discussion isn’t very easy.

Imagine it like this. If you’re a parent or an uncle or aunt and you have a child out shopping with you. If you let them pick up a toy in the shop and you wander around the shop with them holding onto the toy. Try to get them to put the toy back in the shelf before leaving without them throwing a fit.

It’s true, they won’t care how expensive the toy is, or the fact that you know they will grow bored of it within 15 minutes of getting home, they want it. So you will either end up buying them the toy… or you will get them to put it down with promises of getting them something else that is bigger and better than that toy.

Unless you are my mum, in which case a few stern words and a threatening look is all you need to convince 8 year old me to put the toy back.

This should give you an idea of what it is like when trying to convince bosses who aren’t necessarily technical people what network devices will help or hinder the company’s security.

Devices

There are lots of different types of devices used in the network. You have things like repeaters, bridges, routers, switches etc. They all have their own function. For example bridges are used to connect LAN segments. Taking this as an example, a bridge works with MAC addresses and forwards onto the local or another network segment that it is bridging. Sure enough this doesn’t seem like a security device, it’s just a connectivity device. But think about it. Why do you segment your network? If you segmented it for a particular reason, why would you then want to bridge it? The introduction of an unnecessary bridge could undermine your security design. The same can be said for the majority of network devices. They may not be labeled as security devices but they impact security. You need to be able to ensure they are used wisely.

Additionally, it’s not just dedicated network devices that can act as a network device. What I mean is that any end-user connected machine can act as a multitude of different devices. Do you know all the devices that are currently on your network and what they are doing?

Firewalls

Firewalls are covered in great detail in the CISSP book covering the different types of firewalls and their generations. Be it a packet filtering firewall, stateful inspection firewall, a proxy firewall or a plain firewall firewall.

Nowadays you even have web application firewalls which are meant to be great at protecting your web apps.

Where you have internal secure zones, you end up with an army of firewalls and citrix servers protecting your data.

The average person would be forgiven to think that had Darth Vader installed a firewall on the Deathstar we would have Vaders face on our currency today.

Yes, firewalls are protective devices. Their function is similar to a bouncer. Standing at the door. Depending on the type of bouncer you get different levels of vetting on people entering and leaving your premises. A bouncer may only ask to see your ID card and let you pass. Others may have a metal detector on them and perform a quick sweep and others may subject you to a full body search. On the other hand, you can get a bouncer who isn’t really told anything and just hangs around trying to look mean but not stopping or challenging anyone who is entering or leaving.

A bouncer is only really effective when you train and teach them to be vigilant against the threats that you are looking for. Who not only check people entering your premises, but also check what’s leavingyour premises.

If you make them too vigilant, then they’ll slow the process down like airport security and have everyone removing their shoes and mothers sipping their own breast milk out of the bottles. Nobody likes over-restrictive checking. So it becomes a fine balancing act as to what type of firewall you want deployed at which part of your network and how you configure the rules in order to get maximum efficiency. Yes, load balancers and all those kinds of good things help spread the load. But eventually the traffic will meet a firewall.

Well, I say that, but there are a lot of companies today who don’t have any firewalls. To be fair, they are smaller companies, or small segments of larger companies, but it hasn’t made much of a difference.

On the flip side, some companies have what can only be described as a firewall fetish. They have a love of firewalls that can only be matched to a womans love of shoes. Just how a woman can never have enough pairs of shoes in different colours and designs to go with every occasion. Some companies just deploy firewall on top of firewall. If there’s an audit finding, rather than try to address the root cause or suffer a system outage while they reconfigure their network, they solve the problem by simply adding another firewall. Firewalls help you pass compliance checks.

To assist in this, there is a whole industry that has cropped up where certain vendors have produced devices to help you manage your firewalls and your network at large. They will analyse your firewall rules and point out where you have redundant or conflicting rules in place. Or map out the route that can be taken from one side of the network to another in order to gain access to an application that was otherwise thought of as being inaccessible.

Just think about it. How lazy are network administrators that they need to buy additional devices that monitor and analyse those devices that they bought in order to monitor and secure the network.

Which is precisely why no IT product will give you security out of the box. They can help you in achieving your security objectives, but you need to know what those objectives are yourself beforehand.

There are other devices and applications organizations will implements. Such as web filtering to check and block what websites employees can and cannot access from their desktop. Which is great if you have an idea as to what you want to block and why. Usually organisations will buy one of these products and get it running to block nearly everything. Then some developer will say they need access to forums for troubleshooting purposes, a CEO will need access to the Apple store to download games on his *corporate* iPad, an employee climbing a mountain for charity will want their charitable giving site unblocked and pretty soon you end up with a bucket load of exceptions. So what security risk is your web filtering product actually defending against when you have all these holes in it?

The internet and web applications are important to understand and consider when designing your network. If your traffic is going over the standard internet (port 80) or HTTPS (443), then your firewalls are pretty useless. So you have to consider the impact of a malicious payload coming into your network onto an end user device. Or the opposite, where all your data can be merrily marched out the organization over port 443 and nobody would raise an eyebrow.

Intrusion Detection Systems (IDS)

The most common ‘detective’ devices on the network would be your IDS’s. Be they network based or Host based.

If you’re wondering what the difference between a network and host based IDS is. It works a bit like this. A network IDS sits on the network and monitors all the traffic going by. A host based IDS resides within a particular host or machine and is only concerned with monitoring what’s happening on that host only.

Also, like how anti-virus acts, IDS will raise alerts based on signature matching or behaviour.

Signature matching works by telling the IDS the pattern you’re looking for. A bit like telling an undercover agent to look out for a person who is 6 foot tall, bald headed, clean shaven and has a tattoo of an eagle on the back of his neck. The agent will then look out for these characteristics or signature and anytime he spots someone who matches those characteristics he will radio in to base that he’s spotted the tango.

Behaviour based matching is where you tell the agent to look out for people who are acting differently to how the majority of others are acting. So for example, if most people take the life up to the top of the Empire State building, the person who opts to take the stairs is exhibiting odd behaviour. It may not be wrong, maybe they’re just a fitness fanatic, but it’s different behaviour so an alert is generated.

The problem with most places is that nobody bothers looking at the alerts or logs generated. For a lot of companies, the money they spent in buying and installing IDS devices would have been better invested in an Icelandic bank prior to them going bankrupt.

For this reason, you can get just as much benefit from trawling through the logs of your millions of network devices such as your firewalls, gateways, routers etc to determine what happened. Again you’re in luck because vendors have produced even more products that will help you aggregate your logs. So you purchase devices to monitor and gather logs and then go and buy another set of devices to bring all those logs together to form some meaningful data.

Of course by meaningful data, I’m referring to absolutely gorgeous dashboards with traffic lights and satellite images showing what’s happening in your network. It’s a great perk for the underpaid staff working in the SOC (Security Operations Centre) because as long as you project these dashboards onto banks of screens on the wall in front of them and give them chairs that contain 10% more padding than the rest of the office inside their secure locked facility. They won’t feel like there are underpaid inmates. Instead, they’ll think of themselves as NASA engineers working on matters concerning life and death. You will frequently hear them uttering the phrase “Houston, we have a problem”. Granted this is usually on discovery of the fact that the coffee machine is out of milk, but it keeps them motivated.

Like any detective controls, monitoring systems won’t prevent a breach or attack. But if you spot them early enough, you can do something about it. Unfortunately, what happens a lot of the time is that an incident happens and nobody realizes until news of their breach makes the headlines. At which point, the company has to bring in external auditors and network forensic investigators who will go through all the logs on all the devices in an attempt to piece together what happened. This is a time-consuming, expensive and difficult process. At the very least – the very least, make sure you do one thing.

Take the logs from all your network devices, each and every one of them and ship them across in real time to a secure location. And I mean a secure location. Because you will get breached and chances are you won’t detect it and once you’re told about it you won’t be allowed to investigate it because it’s too late. So at least you can point the forensic investigator to the logs repository so they can take a copy and piece together what happened in an easier way.

Incident Response

Once you detect a network breach or suspicious activity on your network, what do you do? Having monitoring controls in place is all very good, but useless unless you have a plan of action as to what to do.

Yeah yeah put that CIRT document away that explains your Computer Incident Response Team and how it will rappel down the side of a building like SAS special forces storming the Iranian embassy in 1980 and order will be restored. It may look good on paper, but responding to incidents for most company’s become a messy and bungled operation.

Following on from the monitoring controls, you need to first know that an incident has occurred before you can respond to it. Some are pretty easy to detect, for example, if a botnet is DDOS’ing your network, you’ll see it pretty quickly because your website will fall over and start crying like a baby that it can’t handle the pressure.

Depending on how the attack is being perpetrated, you may take different steps. Maybe you’ll start blocking certain IP address ranges, so you’ll say any IP address originating from Eastern Europe or Asia is dropped. However, if your primary business already originates from Eastern Europe, by blocking that region you’d be impacting a lot of your legitimate customers. This is where you need to understand your business, undertake the impact analysis of your actions before an incident takes place. Otherwise, in the heat of the moment, when you’re all blurry eyed at 3am on a conference call speaking in hushed voices so as not to wake the baby, you’re going to make the wrong decision.

But what about the less extreme incidents. Are your monitoring controls effective enough to detect those? Does your incident response plan factor in how to respond without using a canon to kill a fly?