I’ve made it past the mid-way point, I think a bit of self-back patting are in order! This is the 6th 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 the other domains here: (Domain 1) (Domain 2) (Domain 3) (Domain 4) (Domain 5)
The operations security domain is like a fresh breath of air amongst an overly theoretical world. It’s like a renegade cop who’s on the same mission as the rest of the force, but who goes against the grain in order to get things done without the red tape. Secops guys are the ones on the ground who get the job done while pencil pushers put on weight and eat donuts behind the desk telling everyone who’ll listen about their glory days.
Some may argue that operations security is primarily focused around IT security and bring up the age old argument of IT vs Information security and all the baggage that comes along with that. It’s an argument as old as whether PC’s are any better than Macs, Ninja’s could beat Pirates or Cagney was better than Lacey.
What it boils down to is that someone has to do the doing. There’s a guy who has to change the firewall rules that get approved, someone who has to reset a password and someone else to backup data. These all fall under operations and we need to appreciate what this entails and make sure it gets done in a secure manner.
There’s a bit in my notes about the orange book and some of the sections relevant to operations security which we can explore.
Covert Channel Analysis
A covert channel is just what it sounds like. A path that’s not usually used for communication, is used as such. For example as a child many of you may have tried the old trick of taking two plastic cups, poking small holes in the middle and threading a piece of string through the bottom and tying a knot. You could then use it to talk to a friend who was usually sat across the room from you. I’m not sure if it ever worked, in fact it may have been an urban myth. But despite the fact it worked or not, you were using two cups and a piece of string which were never intended to be communication devices, as a communication device. This wasn’t really a covert channel, it’s more a way of communicating using devices that weren’t meant to be used for communication. Now if you could do it in a way that no-one else could see, then that would make it a covert channel.
Similarly, people can use computer applications and resources to convey messages in a way that they were not intended to.
Some of you may be thinking that coming up with new communication channels would be tough, but it’s not. It’s just about looking at what’s you already have and how you can use it in a way different from what the manufacturer intended. This is what a hacker typically does as a whole. They look at a system or application or device and think to themselves what else they could use the device for. Very McGuyver in their approach.
My notes state there are two types of covert channels. Covert storage channels and timing channels. Apparently covert storage channels isn’t about sewing a hidden pocked on the inside of your shirt. It’s about changing space on a hard drive or the attributes of a file. Sounds a bit like storing some data on a disk or changing a file to me. There’s no mention of steganography, but I’m assuming that would be a covert storage channel. If you’re not familiar with steganography, it’s a method usually deployed in images (not always) where another image or information is hidden within the image in a way that it’s not detectable. I’ll refrain from making another Inception comment about an image within an image.
Covert timing channels work by altering time but without the use of a flux capacitor. It’s got some jargon about how changing the system time or the time it takes for a process to execute. Again, there are no examples I can find in my notes or book, but one that comes to mind is timing-based blind SQL injection.
Blind SQL injection is what Daredevil does when pen testing. <badum tssshh>. But in essence you send a query to the SQL database and it doesn’t give any meaningful response, so you’re effectively blind. However, by measuring the time it takes for a response to come back, you can extract data. There are technical books that will explain the technique in detail if you’re interested, but you won’t need to know that for the purposes of the CISSP. No, a CISSP never goes too technical, we’ve only got an inch of water to paddle in! Come to think of it, it’s how bats navigate. The blind ones emit a loud sound (the SQL query) and when the sound bounces back of an object, they form a picture of what it is and how near or far it is. The bounce back of sound will vary depending on distance which will be reflected in a longer or shorter time. I think it’s a good idea to start referring to Blind SQL injection as BatVision. It would make penetration test reports a bit more interesting.
Segregation of Duties
Segregation of duties goes beyond simply splitting the workload in half. Despite my best efforts to convince my wife that me making the mess, while she cleans it up is segregation of duties she doesn’t believe me; and rightly so. There’s a bit of theoretical stuff in my notes so I’ll ignore them for now.
You’re probably familiar with Spider-man’s phrase of “With great power comes great responsibility.” The problem is that in real life, people just can’t handle the power. Or we just don’t trust anyone enough to have that power because if going out into town on a Saturday night has taught us anything, it’s that people just aren’t responsible. In fact, they only pretend to be responsible when they’re around their kids and want them growing up thinking that their parents are rational and intelligent people. The question is, what is that power and how important is it that it is not misused. Let’s take for example the launch of a missile. That’s not something you want one person to be able to do on their own. So you may have 2 or 3 or more people who need to be involved in the process in order to authorize that launch. That way you don’t get some guy hitting the wrong button and saying oops.
Hopefully you get the concept. It’s about taking one activity that is super powerful and then splitting it out amongst 2 or more people so that one person can’t have all the power and turn into a power-crazed madman intent on taking over the world. The real question is which activities do you decide to segregate. Don’t be one of them sheep and simply enforce segregation of duties just because that’s the way it’s always been done. Do it because it’s right.
For example, in a bank, a junior clerk may be able to transfer a certain amount of money, maybe $1000. Anything over this amount and the transfer request will go to their supervisor who has to double check and authorize before the payment is made.
Money is usually an easy benchmark to use, anything over $x and you need a separation of duty. Some banks even enforce this for all amounts regardless of how small the value is.
But think about other situations and circumstances, where maybe you’d like segregation of duties, but can’t because operational requirements would deem it impractical. If we take our missile launch sequence again, we will note that the duty is divided amongst several people and although it’s not a slow process, it’s not exactly a task that gets completed in a couple of seconds either. However, an armed policeman doesn’t have time when faced with a dangerous criminal to pull out his gun, while another person loads it and a 3rd person authorises the firing. It’s just the one person who performs the entire task, even though it more often than not leads to fatal results.
So, in an operational environment, think about what the process is and the importance of it. Talk to the business who run the process and understand what their views are. Then totally ignore them and just quote the policy that references you need segregation of duties (no don’t). Of course you should never ignore the business. Come to a conclusion together as to how important a particular process or function or role is. How much power does that give to one person and are we happy giving that person all that power. If not, then segregate that stuff out. But maybe we can’t due to wanting to keep efficiency levels up. In which case think of other ways you can minimize the risks. Give the people training, get them to sign their lives away, put CCTV camera’s over their shoulder. Remember, operational security is fun and it’s only limited by your imagination.
Rotation of duties
Similar to segregation but not quite is the rotation of duties. This is a tough one to implement, because in small organisations it’s difficult to achieve (very much like segregation) and in large organisations it does incur a large overhead. You hire an expensive firewall administrator and then every 4 weeks you take him off firewall administrative duties so they can staple papers for a couple of weeks to rotate their job and lessen the chance they can collude with anyone else to commit a fraudulent act. This means you need to hire another equally qualified and hence expensive administrator to cover the first ones duties whilst he is on rotation. Not saying this doesn’t happen, but I haven’t really witnessed it. The only variation of this that I have seen in several places is a mandatory 1 or 2 week break per year that is mandated for employees. This states that each employee will take a minimum of a week or 2 off in one go. The principle is the same as rotation in as much as you hope that you can detect any wrongdoing whilst the employee is off. However, with advancements in real-time monitoring tools, the effectiveness of this control can be debatable.
As discussed before, don’t implement controls just for the sake of implementing controls or because that’s just how it’s always been done. In a lot of environments you may find rotation of duties does not help security at all. In other places it could be a very useful tool.
Trusted Recovery
Imagine you had a top assassin whom you spent millions on training over many years. He ends up failing a mission and getting shot, but survives. Unfortunately he loses his memory in the process and on top of that, he comes back to bite you. This is what we don’t want our systems to do when they crash or fail. Firstly, we need to have controls in place that prepare for failure. The simplest example is that of having data backups so that when your system does go poof, you know that you haven’t lost years of work. Secondly, you need to check the controls and processes that fire up when a system is being restored. Does it recover files or roll back to a previous version? Will a reboot of a machine allow someone to login as an administrator with no password?
If we’re looking at an IT system that fails, when looking at recovery go through all the different layers and examine how they recover. The operating system may recover in a safe state, but does the database, or the application or any other component recover in a slightly different way? Could that be a vulnerable point?
Change Management
Change management means well, it really does. But people just don’t seem to like it. Maybe it’s because organisations have made change management overly bureaucratic, or maybe it’s because project managers are too lazy to want to fill out another form. The purpose behind change management is to, well, manage changes to a live environment. It’s a pretty simple process, the person proposing the change will document the change and everything they believe it will impact. The various teams will review the changes from their end (including security) and give the seal of approval to allow it to proceed, or ask any questions, or even reject the changes.
What you quickly come to realize, is that even the sometimes most mundane of changes have a security impact and as if you’re lucky enough to be on the change approval board you need to look at a change from all angles to make sure it doesn’t affect the current security setup. I remember once a colleague of mine received a change request come through which seemed a simple enough moving of an application from one server to another. It seemed to be more of a capacity issue so it was approved and went ahead. Only when we started seeing one application after the other become unavailable did we realize something wasn’t quite right. Of course, the old server had more deeper links to the running than anyone had anticipated. This was the old days of NT4.0 and there was a lot of scripts with hardcoded information.
It’s not always the big changes that one has to worry about. You see, if you’re making a change to your payment platform, everyone is aware that security is of paramount importance and will focus on it. It’s the smaller changes that sometimes catch people out.
Also bear in mind that not everyone has the same definition of what constitutes a change. Or more specifically what changes are significant enough that they warrant the need to go through change management. The level at which that is set is a business decision as to how much they want to oversee changes. But the basis of security operations is that every security activity is in effect a change. Be that a password reset, granting access to a file, making a firewall rule change etc. Everything is a change and therefore you should analyse each one of these processes with the same mindset. I’m not saying raise a change request for each password that gets reset. But rather look at the process by which a password gets reset. Is there the right level of authorization in place, do the administrators know how to reset the password properly, is the password communicated to the end user in a secure manner, is there an audit trail of the password change? These are all things you need to be looking at on a daily basis. Don’t wait for an auditor to come in and pick holes in your process.
It reminds me of a time a colleague was asked to create a temporary account that expired in 2 week. He made the mistake of making a change at the global settings for the domain so that all users passwords were to expire in 2 weeks. What that resulted in was that every user whose password was due to expire suddenly found themselves locked out. A small change, but big impact. How could this have been prevented? Well clearly not employing a numpty would have helped. But also having the process for creating temporary accounts documented would have been a good idea. We were over-reliant on the expertise (or lack in this case) of individuals and paid the price.
Another time another colleague was working on a project which had just ended and he had to remove a large number of user accounts. Rather than going into domain manager and deleting each userID individually, he wrote a CACLs script to do delete these accounts in one quick sweep. I can’t remember the exact syntax of CACL’s scripts, but these were little scripts you could write in notepad and save as a .bat file which used to execute all the commands in one go. Anyway, he made an error in the script, possibly missed out a backslash or something and when he ran the script it began to duly delete every single account in the domain. Luckily or not, the guest account on Windows NT cannot be deleted so it stopped when it reached that. Phones were rang, incidents were logged and team leaders had their butt’s kicked.
Eventually we managed to restore from backup and by the end of the day everything was running smoothly again. But it delivered an important message that stays with me to this day. Which is that CACLs is the work of the devil. Well other than that, the fact that all changes are important. Security is all about change. We’re not here to stop change, but rather facilitate change in a manner that is as secure as possible and doesn’t compromise the business objectives.
Woah getting a bit philosophical in my old age. Let’s move on.
Least Privilege
The principle of least privilege, is to give people only the minimum amount of access and rights needed for them to carry out their job. There’s a whole lot of jibba jabba in my notes about this, but if you’re say implemented a role based access control system, then by definition each role should be designed with least privilege in mind and hence as long as you put people in the correct roles, they should only have access to what they need. Least privilege usually works like being on a diet. You cut out all the crap from your daily food intake and survive on lettuce, a thin slice of grilled chicken and bottled water because according to some Dr. at some university, that’s the least amount of food you need to survive. But after a few days the cravings will begin. You know the chocolate, crisps and fried chicken will seem oh ever so appetizing and despite your best intentions, you’ll fall into the trap and your diet will be long gone. The same thing ends up happening with least privilege. An administrator will accept it at first, but then think that if only they had access to that extra terminal or function, it would make their life so much easier and jobs could get done so much quicker.
Operator Job Functions
I can imagine that this section was written by a man in a grey suit who speaks in a highly nasal and patronizing voice, who likes to collect coins on the weekend and is a member of the local fishing society. Maybe I’m just out of touch with the operations departments, but do you have operators, analysis, tape librarians and other such titles for people doing very specific roles? Nowadays with everything in the ‘cloud’ I’m sure everyone just gets on with doing what needs to be done. This is another overall failing of the CISSP course material in which it tries to guess the type of organisation you will work in and what kind of jobs need to be done and assigning certain labels to them. In reality each company has their own way of working with their own job functions. If you work for a small company you’ll probably be more hands on in a lot of different areas. Whereas in larger organisations your role may be more specific and you’ll be left with being in charge of a much more limited set of activities.
I’m probably going to sound like a scratched record again (think of it as a corrupted MP3 file which loops the same line over and over) but as the security professional, you should understand how your organisation works. Take time to look at the IT infrastructure and all the parts that process information that needs to be secured and make sure all the activities are covered. Even where roles are defined, take time to understand what those roles actually entail. Just because someone has the title of backup operator, don’t assume they are responsible for all backups. At one organisation there was a team called the crypography team. I was looking for email encryption so I asked them what they had and how I could install it. They told me that they were only responsible for the HSM’s in the datacenters and for email encryption I’d have to ask the Windows Administration Team. Yeah, job titles don’t mean much. Don’t believe me? Have a search on LinkedIn and see what grand job titles people assign themselves.
Record Retention
How long do you keep your receipts for? Well, if you’re like me then unless I’m planning on claiming back expenses from the business, I usually throw them away. If they are incriminating, then I make sure I cross shred them and throw them in different bins randomly across town. This what records retention is about. How long do you keep records for? There are two reasons you retain records, either for business needs or for regulatory requirements. So your local laws may stipulate that you must keep a record of all customer emails or forms for a period of 6 years. From a business perspective, if you offer customers a 5 year guarantee with the product they purchase, then you need to at least maintain a record of that for 5 years.
There are usually some records retention experts who will look at your local regulations and help define the retention policy for you. With storage being a lot cheaper than what it was 10 years ago, meeting most requirements isn’t much of a problem. Terabytes of storage are available very cheaply, so don’t cut corners with your storage costs. Otherwise your business will end up like the guy from memento. A limited short term memory that gets over-written very quickly. So unless you want to spend time tattooing information on your body and scribbling notes on the back of polaroid pictures, it’s a good idea to invest in storage that meets your requirements.
On the flip side, just because storage is so cheaply available, it doesn’t mean you should keep all data forever. There are equally important requirements for you to delete data after certain periods of time. So don’t hoard data unnecessarily. From a security point of view the more data you’re storing, that’s more data you need to protect. Also, when someone says they’re deleting data, make sure it’s permanently deleted. Last thing you want is one of your company’s hard drives turning up on ebay full of customer details.
Monitoring and auditing
Back in the day, nobody in our team used to enjoy doing the monitoring tasks. It was dull and it was boring. Our team leader would constantly remind us that “monitoring is not a dirty word” and how it’s an important and vital task. Yet despite knowing this, it killed our souls. Granted, we didn’t have access to fancy dashboards or real-time alerting so we’d daily have to run a report against all the systems and painstakingly go through the logs of interest line by line to determine if anyone accessed or tried to access anything they should or shouldn’t have. By and large it was uneventful. But every now and then we’d find an overnight shift operator had signed into a system with the emergency access account and there was no incident or emergency change to justify the access. That’s when the pain of monitoring was channeled into a formal and harshly worded email to that operators line manager. Informing him of the misdemeanor and demanding an explanation into the act, ending with an implied threat of escalating higher if answers weren’t given.
It’s not that we were vindictive or bad people. It just happens to be that one of the side effects of monitoring is it will leave you a bitter and twister person. There are lots of fancy technological solutions nowadays that make the whole process easier and smoother. But the basics are still the same. First you need to be clear as to what you’re looking for, once you’ve found it, you need to know what to do with an alert. I was once at a company who were suffering an attack. Someone was asked to look at the IDS logs and people started looking at each other, blank looks were exchanged and heads were scratched. This online portal of theirs had been online for over 2 years and had IDS sensors deployed. The problem was that no-one had ever looked at them, in fact no-one even knew how to access the logs.
Then you have auditing, which is almost identical to monitoring, except it’s done at a later date. It’s about going through the systems and logs making sure everything are working as intended. It’s more of a Columbo style activity, where an auditor will look at samples of logs, check procedures and interview operators. They too suffer from the side effects of monitoring and end up losing their personality in the process. This is why a lot of auditors can come across cold, bitter and just anxious to find something wrong with your processes to give you a red finding. You have internal and external audits. Both of which have their pro’s and con’s. External auditors are more reputable because they are perceived to be totally independent, but they have no idea of the organisation so it becomes all too easy to pull the wool over their eyes. Setting the scope becomes an elaborate dance routine and people clean up a certain portion of their environment just for the external auditors.
Internal audit have more understanding of the organisation and thus makes it more difficult to direct them away from problem areas. But because they are internal, politics can come into the equation. If the head of audit plays golf with the head of security, the results may be very different than had the head of security taken the job that the head of audit desired. It’s no different from those internal affairs departments that are portrayed within police movies. You have the internal investigator who has it in for the sergeant and will do everything in his power to pin charges of corruption on him. Of course in the end we find out it was the lady in the accounts department who was behind it all and the auditor and the sergeant become best buddies which is where it becomes fantasy because you’ll never see a security person sharing some bromance with an auditor.
These are just some of the fun aspects of working in large organisations. It’s not worth worry about these because there’s little one can do. As a security profession, concerning yourself with red audits is a waste of time. You need to focus on doing what you do best, securing the assets that need securing and making sure you do whatever is right. It can be a thankless job at times, but we’re not in the business of being thanked, we’re in the business of keeping information secure.
There are some other bits and pieces covered in my notes but none of them seem worth mentioning here. Secops is one of those areas of security where you really will learn a lot more about it by actually doing it. It’s not such an area which you can learn by theory alone. Additionally, it will give you an appreciation of how security works on the ground. It’s all too easy for someone to do a masters in information security and then sit as a consultant writing policies that state how roles should be segregated and how monitoring should be carried out. But they won’t fully appreciate the impact these decisions make. When something becomes too inconvenient, naturally people will start bypassing the process in order to get the job done. Or maybe I’m just sentimental about it because I started out my career in a secops role.
Javvad Malik 