This is my second post on my CISSP Reloaded where I am revisiting the 10 CISSP domains I studied for many years ago to see what has changes and how much of it I have retained as well as adding in my own personal thoughts and experiences into the mix. Read the introduction and first domain at http://www.j4vv4d.com/?p=433 

 

Controls

When you tell someone that they have a risk – they’ll either ignore you thinking you’re a doomsday naysayer (log it in their risk register and accept the finding). Thank you for bringing it to their attention and say their team will fix it straight away; or get that wide eyed crazy fearful look, grab you by the shoulders and shake you demanding to know what they should do before they all die.

This is where you need to be prepared with an answer. It’ which usually comes in the form of recommending controls. The types of controls you recommend can be broken down into three broad categories, protective, detective and recovery controls.

Protective Controls

As the name says, protective controls protect against threats. These are defensive measure. Although Dennis Rodman and Van Damme quoted in Double Team that the best defence is a strong offense, it’s usually illegal to go after bad guys before they’ve attacked you, so you need the next best thing which is a strong set of defensive measures to protect you.

It’s like those reporters you see providing coverage from a warzone. The poor bugger’s aren’t given a gun, but they’re given a nice PRESS labelled flak jacket and a bunch of soldiers trying to keep them safe long enough to deliver the important news that the army has achieved their key objective of blowing the shit out of a desert.

The Great Wall of China, was built as a protective control. If you can keep the enemy outside and not let them come in, then you have created a safe haven within. The control needs to be adequately strong enough to protect against the attackers. The Great Wall of China was a humongous structure which they obviously put a lot of effort into building it because it was deemed sufficient enough to stop attackers on foot and horseback. However, over time with the advent of air transport and explosives it’s pretty much useless beyond being a tourist attraction.

Like the story of the three little pigs. One made their house out of straw and the other of sticks and both of them were easily blown down by their attacker the wolf. Only the pig who built his house out of bricks was safe. But that will be only safe until the wolf doesn’t find himself a tank, or an RPG, or a bulldozer.

Just because someone says that their product or service will act as a protective control, it doesn’t mean that it will be effective. You need to understand who’s trying to get access and choose the control that will really protect you. Or rather, I should say, the control should protect you long enough for you to do something about it. Otherwise you might find yourself as the person holding a knife in a gunfight.

Detective Controls

Many will argue the case that Sean Connery was the best Bond ever. Personally i grew up more with Roger Moore so have fond memories of him in his white Safari suit delivering karate chops to render bad guys unconscious.

In one Bond film, Connery leaves his apartment but not before placing a few strands of hair at the cupboard joint and a layer of powder on his suitcase. Upon his return the hair strands have been broken and there are fingerprints embedded in the powder on the suitcase. This is a crude, but probably the most manliest set of detective controls ever used by a hero.

Having good detective controls are probably even more important than having protective controls. One cannot overstate the importance of having the ability to detect when something has gone wrong or when someone is in the process of attacking you.

A lot of food packaging has detective controls designed to ensure that the end product you receive is exactly what left the factory. So jars have lids that ‘depress’ once they have been opened. Or bottles have a plastic ring that splits on first use.

Tamper evident envelopes are used to send sensitive information such as PIN numbers for credit or debit cards.

Having detective controls means that you don’t have to be Sherlock Holmes to discover if an attack is being undertaken or someone has been rummaging through your digital drawers.

Recovery Controls

So they’ve busted past your protections and evaded your detection long enough to hit you with a stunning uppercut.

Can your business recover before the referee makes his 10 count.

Recovery controls are there to help a business recover from a perspective of having their information to hand. If your customer database is unavailable, how will that affect your ability to trade? You need to choose and implement the right controls on the right systems in order to keep going. One of the key aspects of recovery controls is designing them so that your critical systems are recovered first and fast.

In cold temperatures your hands and feet get coldest because the body draws blood in from the extremities in order to keep the core of your body warm. The body knows that it will survive without an arm or leg, but it won’t without a heart or lung. Be prepared to sacrifice a business limb if need be. Just like the guy in Saw who was willing to cut through his own leg in order to get away.

 

Access control models and methodologies

Looking through my old books I began scratching my head at the access control models and methodologies such as mandatory access control, discretionary access controls, non-discretionary access controls, centralised methods, decentrailsed methods, Kerberos, kryptoknight …. The list is endless and for the most part, meaningless to me.

This is very much the Queen’s English of security. Yes, it’s the right way to pronounce and has the correct grammar and punctuation. But in the real world, the street lingo is nothing like it. I don’t care if the correct term is “me and the King” or “King and I”, as long as the message is conveyed correctly that’s all that matters. Kind of, sort of. In most cases. Anyway, I’m going to conveniently ignore all of that because other than passing the CISSP exam, I really haven’t used any of that information. At least not consciously and definitely no using those terms.

When I think of access control and the pretty bits that go along with it, it’s probably best visualised like this:

Identity

The first step is establishing the identity of the user. You want and need an identity to be unique like a beautiful snowflake. A lot of people think of their name as being their identity. Which isn’t quite correct. When you meet someone in the physical world, it’s their unique face and body features form their identity. Their name is simply a label that isn’t really unique. Unless you’re the child of a celebrity and has the name “Stripulo-dupos-danagazis-Precious Pitt-Jolie”. Hence there may be several George’s at a party. But you end up differentiating between the short George, the tall George, the fat George or skinny George; the George with curly hair or the George with a ginger beard.

When a victim of a crime is to identify a criminal, they do so via a lineup to see if they can recognise them to confirm the identity.

Systems, applications etc, don’t know you by your name.

They know you by a unique identifier. This may take the guise of a user ID that a system administrator has setup for you. A lot of places decide on a naming convention such as initial.surname.

If you’re using an internet facing system, they usually opt to use your email address as your ID.

When you make a card purchase at a shop, your credit card is your identity.

If you’re pulled over by the police for speeding, your driving license is your identity.

When you cross country borders, your passport is your identity. Unless of course you’re hanging onto the underside of a lorry on the Eurostar.

Sometimes though, the identity needs to be just that the user is a guest. You don’t need to know anything beyond that and that is sufficient.

Once someone has informed you of their identity, you can take the next steps. In the case of a guest, you usually then go straight to authorisation. But if someone has identified themselves you usually move onto the next step of authentication.

But before we move onto authentication, lets take a moment to touch upon Identity Management. It’s a hot topic these days with identity and access management solutions being sold to companies left right and centre, and nearly all of them being a poor implementation. The technical solutions usually fail because the underlying process isn’t thought out well enough.

“Guns don’t kill people, people kill people.”

This saying is very much true when it comes to implementing security solutions. Technology doesn’t secure information, people secure information.

So what is identity management and how do we go about it. Well, in a nutshell, on your corporate systems you setup a user identity for a new starter. Let’s imagine it’s a simple setup on a windows domain and that’s the only ID a user has. Lets say there are 10,000 userID’s setup on the system. But HR says that they are only paying for 8000 employees. Do you know what those other 2000 userIDs are? Are they needed or not? Should they be deleted? Are they administrative accounts or system accounts? Or do they belong to contractors or 3^rd parties who need a valid ID but are not paid via HR’s payroll system.

Now imagine that you have 50 different systems within your organisation. Mainframes, databases, applications, infrastructure administrative accounts. So the problem compounds itself rapidly.

This is not a fictitious scenario, this is a very typical scene in most large organisations. Managing these ID’s becomes quite a headache.

If you refer to usual security texts or the corporate policy / standards, they will advise that a user ID needs to be revoked or deleted as soon as it is no longer needed. But who knows when an account is no longer needed? This is where you as a security professional are needed the most. You need to interact and engage the business to establish what is the best approach.

Maybe you can do a scan of accounts and find those which haven’t logged on for the last 30 or 60 days and disable them. Sure, this will capture a bunch of accounts that are no longer used, but what if someone has left the organisation but is still accessing their account? This control won’t detect them. Or maybe the business doesn’t want the exposure of having a potentially redundant account sitting on the system for up to 59 days.

Others will suggest deleting an account 90 days after it’s been disabled. I once remember this was about to be implemented at an insurance company. Luckily someone from the business spoke up before a mass deletion of redundant accounts was undertaken. Apparently, there legal requirements around maintaining an audit trail of who issued or processed an insurance policy or claim. By deleting the userID the records would no longer be reliable. So these ID’s needed to be kept for 6 years. That’s not something you’ll learn from a book. That’s something you’ll learn by understanding the business you’re trying to protect.

Authentication

OK so we’ve been told what a users identity is. The next step is to actually verify they say who they say they are.

The traditional authentication model that you will find in most books is something you know, have or are. So let’s take these concepts and expand on them slightly.

Something you know

This is the most common authentication model in place, usually referred to as a password. The classic example is that of Ali Baba and the password to open the cave being ‘open sesame’.

The benefits of a password are largely around the fact that they are relatively easy and inexpensive to implement. New and old systems support them, and if they need to be changed, it’s a pretty straightforward process.

The biggest disadvantage of passwords is the fact that you rely on people to set them and not share or write down their passwords. But we all know this doesn’t happen. Worse still, people are usually lazy and use one password on all their applications. Much like ‘open sesame’ they can be overheard and used by others quite easily. The techniques used to overhear or guess passwords are becoming more effective day by day thus reducing the security offered by passwords.

There are some variations that can be used to make the password more secure. Some systems will enforce a minimum password length and complexity rule to make sure they are harder to guess or brute force. Others will only ask for selected digits from the password, e.g. 1^st 4^th and 6^th digits to be entered so that even if someone is looking over your shoulder they won’t be privy to the whole password.

Other techniques could be agreeing a known pattern, such as the 3^rd word on page 2, column 3 of a particular newspaper for that day. This generally only works where the system can obtain the information on a daily basis or authentication is being carried out against a human.

Care needs to be taken around how passwords are stored and transmitted. The whole process needs to be handled with care to deter attackers. For some ideas as to how to better store passwords, you can view the video on “Don’t encrypt passwords” here: http://youtu.be/FYfMZx2hy_8

There are other ways of using the ‘something you know’ criteria. For example, if someone forgets their password, they are sometimes given the option of answering some other questions such as what their mothers maiden name is or their eye colour or favourite song. These all fall into the ‘something you know’ category but are about as strong as a wet tissue in most cases because a lot of people will know or can guess this.

When I was young there was a TV series I recall called Wiseguy. It followed an undercover special agent who had infiltrated a mob. Anyway, he would call up his contact and provide him with the password of the day which was a pre-agreed selection of words from that days newspaper. It would be the first word from the 2^nd paragraph on the front page, the 4^th word on the 7^th paragraph on the 9^th page and so on. So the actual words were different every day. But the method of finding these words remained the same and that was ‘something he knew’.

In day to day life we use the ‘something they know’ test to authenticate people all the time. If someone you meet says that they went to the same University as you did. You’ll ask them questions about certain things within the University that only a student would know. You’ll ask which lecturers they had, or how bad the food was on Fridays etc. If they answer correctly, you accept that maybe there were a student, or maybe they’re bluffing.

Something you have

Perhaps you have something unique that will give you access. Like a door key, a little token that generates a random number, or one ring that rules them all. The benefits of having something over just knowing something is that it saves on brainpower needed to remember a password so you can simply plug in your ‘thing’ or read a code off the ‘thing’ in order to be authenticated.

‘Things’ can mostly provide improved security than just using a password. However, the problem is that if your thing, like your house key is compromised. Let’s say someone made a copy of it. You have to change your entire door lock and get new keys cut for everyone in the house. Thus significantly increasing the running costs.

The other factor that drives up cost and or complexity of the ‘thing’ you have is that it should not be too easy to replicate or copy otherwise anyone could take a forged thing and get access to what they shouldn’t have.

Things like driving licenses and passports not only identify you by having your picture and details but can also authenticate you because generally speaking these documents are difficult to forge. Or at least that’s what we’re led to believe.

It’s a bit like those old romantic scenes where childhood lovers are split up through circumstance. But not before the girl tears a picture in half. Gives the boy her half of the picture and keeps the boys picture for herself. Many years later whilst the boy is brooding in a bar, he starts chatting to a girl, they eventually end up suspecting that they could very well be each others long lost love. They both pull out their half of the picture and join it together to make it whole again whilst a David Blunt song plays in the background. Sometimes half a picture is all you need to authenticate yourself and find love.

Something you are

You are a unique and special snowflake. Which is exactly why we can use you to authenticate yourself. Be it finger print matching, retina scanning, DNA matching, everything is unique. So you can prod, poke, scan, squeeze and scrape a person as much as you like until you can validate who they are.

I haven’t worked in any environments where they are mass-deployed so my knowledge of biometrics is pretty much at CISSP level.

Today, the biggest challenges with biometrics involve the accuracy of the readers, which aren’t great coupled with people’s general reluctance in voluntarily opting for more invasive personal scans. Finally, unlike a password or authentication device, if your blood, DNA, fingerprint etc is cloned, then you cannot ‘reset’ the password at all.

Authentication Continued

Now that we’ve covered the 3 basic forms of authentication, we have the opportunity to delve into these in a bit more detail to determine how lovely and complex authentication can become in real environments.

Authentication by who I believe you to be

What happens when someone has forgotten their password or lost their token and you have no equipment to conduct a retina scan on them – yet they insist they are who they say they are?

In the physical world, it sometimes boils down to whether the security guard believes the person. They would look into their eyes and go by their gut feeling that they look innocent enough and have a trusting face. So they let them in. This is the premise upon which social engineering attacks are carried out.

In electronic terms, we can revisit the ‘forgotten password’ button on a website example as covered in the ‘what you know’ form of authentication. A lot of times this is implemented in a manner to lessen calls going through to the helpdesk so it’s a self-administering solution. You click on the forgotten password button, answer a few questions on different pages such as your mothers maiden name, your eye colour and city you’re born in, and viola, the application believes you are who you say you are.

This is one of those ‘we don’t speak about this’ type of authentication models. Because strictly speaking it isn’t meant to be used for authentication unless you’ve forgotten your real details. But that’s a bit like saying fire exits shouldn’t be used by smokers to go out for a quick smoke. Just because it’s not designed with that function in mind, doesn’t mean it won’t be used for that purpose. How many fire exits can be used to get into your systems?

By referral

Referral authentication is what I’m calling SSO (single sign on) implementations. These are quite common in large corporate environments. You authenticate originally using a traditional method (have, know, are) but then you go to another different resource or website and it lets you in, not because you’ve authenticated yourself, but because it trusts the device that’s referring you. Trace the authentication path, you’d be surprised how many ‘hops’ away the real authentication took place. So you must have total faith in all the devices providing the referral in the middle. A weak link could lead to a whole lot of authentication headaches.

For the same resource, you may have different authentication models depending on who is referring someone. So if someone is coming from the internet you may want a more robust check undertaken, but if someone is accessing internally you just seamlessly let them come through.

Bear in mind, your whole authentication model then becomes based on trust. As long as you can trust the referring party to be secure, you’re ok. But that’s a BIG dependency.

If the boss walks into the office with a young boy and introduces him as his son, then no-one will question the fact he has no ID or looks like he belongs there. They will treat him as if he were the CEO himself.

By what I remember you to be

Familiarity breeds contempt.

Well in the case of security, familiarity breeds insecurity. Cookies remember your name so if you’ve authenticated once on a machine, when you go back, the machine assumes you’re the same person and greets you as such.

If you work at an office and say hello to the security guard every morning. If you get fired he may not know about it… so you can walk in whistling as usual saying good morning. If he asks about your pass, you can make a joke out of it… come on Bob, you should know me by now. What’s the matter? Getting forgetful in your old age?

You get the “remember me” buttons in a lot of web applications. The developers want users to visit them frequently and easily, so the implementation of this feature bypasses your authentication controls. But it can be used effectively which I’ll elaborate a bit more of further on.

Multi-factor authentication

This is the combination of 2 or more forms of authentication. Like using a password (something you know) in conjunction with something you have. For example when you go to take money out of a cash machine, you will get money when you present something you have, which is your cash card combined with something you know, your PIN number. That way if someone steals your card they can’t use it without knowing your PIN number and vice versa, if someone guesses your PIN number, it won’t be much use without your card, or a clone of your card.

Note that these must be two different forms of authentication types. I once had someone try to convince me that the application asks for a password (something you know) and then a separate PIN (something you know) which made it two factor authentication. The answer to that is no, it does not make it two factor authentication, it remains single factor but broken into two parts.

In most corporate environments remote access is usually protected by two factor authentication. Usually an RSA token is issued that has a number on it which changes every 60 seconds. So when a user logs on they have to provide their password (something they know) and the random number that is generated on the token at that time (something they have).

If you were really paranoid there is no reason why you couldn’t add in the 3^rd factor of biometrics into this, but I would that would be more for physical access to a facility or where you have to physically be present at a particular system i.e. you enter your password, plug in your key and have your retina scanned.

Authorisation

So your identity has been authenticated. But that’s not the end. We’ve now established beyond reasonable the identity of a user… but what does that give you access to? Do we give you access depending on your department, your criminal record, based on who your daddy is or how much money you have in your bank account?

There are many different factors that play into this and this makes it a messy thing to manage in a large and complex environment. Actually, even in a small environment it can get pretty troublesome to manage. Which is why most people opt for Role Based Access Controls or RBAC as it’s commonly known, because heaven knows we can never have enough acronyms.

What is a role based access control? Think of it like a family. Anyone who is a member of your immediate family may be allowed to live in your house. Anyone in your extended family is allowed to visit and maybe spend the weekend, but not live on a permanent basis. Friends may only be allowed to visit and others have no business being inside your house.

What this allows is an easy grouping of people into manageable chunks.

Similarly we can say, anyone in accounting has access to the systems that are needed to perform their job which is different from the access that people in marketing have.

You can proceed to make this granular as you like by saying a manager within the accounting department can process payments, whereas a clerk can only view and enter details.

This facilitates the whole concept of segregation of duties. Segregation of duties is where one task is so important and critical, it is too much for one man to handle. You see these types of things in movies where the order to launch the missile has been received and two geeky looking military officials each use their own key to activate the buttons on their consoles which they have to hit at the exact same time in order to launch.

In real life, it’s a little less interesting. It’s usually a spotty grad who spends time typing with two fingers a payment instruction for a client. Then in their semi-broken voice calls over “supervisoooor supervisoooor” and the supervisor then logs onto their own terminal, see’s the keyed instruction and approves or declines as necessary.

Of course, segregation fails when both the spotty grad and the supervisor hatch a plan together to perform the perfect heist. Putting that aside, it’s basically how we put users into roles based on what they do and those roles will give them access to the systems they need.

All pretty well and good isn’t it? Unless you’ve ever been fortunate enough to try to work out what access a particular role should have. Believe me it’s not easy. You need to make a list of every system and application which isn’t very well documented in most places. Then you have to go to each and every business unit and sit down with them for a nice long chat trying to extract from them the knowledge of what systems their team needs access to, and whether or not there needs to be more than one role created for different levels.

It’s a bit of a pain.

Levels of Authorisation

I didn’t find this mentioned in my books or notes, maybe its buried amongst some mundane detail. But it’s worth mentioning levels of authorisation and access.

If you’ve been following this up till now you’ll see there are some unconventional ways of authentication such as web applications ‘remembering’ who you are etc. I said there could be some benefits to these types of weaker authentication.

This is where collaborating with your business and again understanding what their drivers are and how they engage with their customers can be used for a better experience without sacrificing security.

It involves looking at authentication in a tiered manner for example something like this:

Level 0 – I don’t know who you are

Level 1 – I think I know who you are

Level 2 – I believe you but don’t totally trust you

Level 3 – You have my total trust.

So if your web application is saying level 0 and it has no idea who you are, that would trigger a certain level of authorisation. i.e. that user will be authorised to view the public pages no problem.

Level 1 is a bit like how when you visit Amazon’s website and it says Welcome back ‘Dave’. This is where the application thinks it knows who you are because previously when that computer visited Amazon it was properly authenticated as Dave. What this will do is show you some recommendations, and other useful bits of information that is more tailored for Dave. But what it shouldn’t do is give any personal information about Dave out. Because if this isn’t Dave, you’d be falling foul of data privacy legislation if you disclosed that Dave last bought a leopard skin mankini.

When you then want to make a purchase on Amazon (I’ll stick to the Amazon example for now) it will require a higher level of authorisation and hence ask for level 2 authentication. This would be your password. Once you’ve entered your password, you’re free to make the purchase and have the leopard skin mankini delivered to your doorstep.

However, suppose you wanted the leopard skin mankini delivered to a new address. Maybe as a present for your boss. The application won’t trust you to do that, because if you’ve gotten into my account by guessing my password you’re not really Dave. Therefore, to dispatch to a new address you’ll be asked to re-enter your credit card details i.e. authenticate at a higher level with 2FA in order to gain the necessary level of authorisation.

Ouch my head is hurting. But hopefully you get the general summary of what this is. It’s about using security effectively so that you don’t burden every single user to your website with cumbersome layers of authentication just to perform a simple task.

The way to work out how best to authenticate and authorise customers effectively isn’t very easy. You’ll need to work with the business and system administrators to get a picture of customer behaviour. Do most customers browse? How many make purchases? How often to they dispatch items to new addresses? What potential fraud avenues are there? Hopefully you can begin to appreciate how complex some of these issues become in the real world and authenticating and authorising a user isn’t as simple as the theory may have you believe.

Accountability

The final part is accountability, or being able to attribute accountability of which user accessed which resources and when. It basically means having good logs and monitoring tool in place.

These can be real time detection controls like having IDS’s on your host and network, or logs that you can use for analysis at a later date.

It’s like having a buzzer go off every time you open the door of the shop. The owner knows someone has entered there and then. Or you have CCTV cameras where you can review the recordings at a later time to see who entered the shop at that time.

I’ve got some bad memories about monitoring. Having spent countless days in my early years looking through IDS logs without the faintest clue as to what I was doing. Some would say I still don’t know what I’m doing… and they’re not far off.