According to the U.S. Department of Labor, Bureau of Labor Statistics the unemployment rate in the U.S. is 6.7% – up two (2) percentage points in the past year.  In the United Kingdom, the BBC reports that nearly ten (10) million working age people are “not in paid employment.  This includes the 1.8m unemployed, plus another 7.9m who are deemed to be ‘economically inactive’.”  That is Britain’s highest rate in 11 years.  Europe’s largest economy, Germany, is expected to contract by up to 3% in 2009.  Japan’s unemployment rate is also on the rise (3.9%) with the number of unemployed estimated to be 2.56 million.

Unfortunately all forecasts for at least the next year show the jobless and layoff trends increasing. 

It is a sad but true fact that disgruntled employees can pose one of the greatest risks to a company’s sensitive information and resources.   Is your company laying off people?  Does it have a procedure to terminate physical and logical access to systems immediately upon termination?  Is it being followed?

Are you sure and are you willing to bet your company’s future on it?

An overwhelming majority of those who are laid off do not do anything that would be dishonest but it only takes one employee to cause a problem as we saw in the Terry Childs case earlier this year. 

In order to appropriately protect critical information it is important to know exactly what it is and more importantly where it is located?  When was the last time you cataloged all of your company’s critical information? Is it located in a central location, isolated pockets, or scattered all over the network and user workstations?  Who has access to that information?

I once worked in a company where each division stored their information (that which wasn’t saved to individual user desktops of course) in division level folders on shared network drives.  All of the information within these folders was available to anyone within that division.  When we migrated the network operating system from Novell over to Microsoft Active Directory, my boss and I recommended tightening the access controls on the information.  We were shot down.  To paraphrase one Vice President at the time: “We often collaborate across multiple groups so our people need to be able to get access to everything – besides nothing bad has ever happened before so why change things now?”

Of course she was right, nothing bad had ever happened.  At least to the best of their knowledge nothing bad had happened.  Another way to look at this is that the company decided to accept the risk.   This is all well and good but three years later things were another story.  (I had left the company for greener pastures the year before the incident.) 

You see they had laid off an employee just before they had to recomplete a rather large contract.  The company was a shoe-in to win the work; the recomplete was just a formality.  It was a formality until they lost the recomplete to a company that had never done that sort of work before.  Apparently they were underbid by almost 25%. 

It wasn’t until someone remembered that the laid off employee had gone to work for the company that won the contract that they put two and two together.  The problem was that they couldn’t prove anything.  The laid off employee never worked on that project and in by all accounts should never have had access to the projects information.   The problem was that EVERYONE had access to the information.  Not only did everyone have access but auditing access to information was thought too obtrusive by senior management so it wasn’t authorized. 

Did the laid off employee walk out with critical information that caused the company to lose the bid?  Who knows for sure?  In my mind it would be a mighty big coincidence if he didn’t but that doesn’t mean anything. 

Was the employee’s account disabled when he was terminated?  That I don’t know for sure.  Knowing how that operation worked I’d venture to say that if the account wasn’t deactivated that day then it was the very next one.  It all depended on if notification had been sent by HR at the appropriate time.  I do know that he had plenty of forewarning that layoff’s were coming and the time in which to copy the information.  (According to my sources)    

While it is very important to terminate both physical and logical access of an employee upon termination, it is equally important to take steps to protect and control access to information and critical services before you get to the point where you’re terminating people.   Some of the activities that I recommend are:

• Information Categorization;
• Position Categorization;
• Auditing access to critical information; and
• Establish a log management program.

As I said earlier, you need to know the characteristics of your critical information and where it resides.  That really is the basis of a solid risk based approach anyway.  Secondly you need to develop a program that assigns a risk designation to all positions based upon their access to and control over critical information.  (The program should also include screening criteria but that is another post.) Third you need to audit access to critical information once you know what you need to be watching and who has the right to access it. (You can’t realistically watch everything so limit your scope).  Fourth you need a way to manage all of this additional information so that it can be useful and not simply a waste of time and money. 

One final note – don’t forget or neglect to put these controls in place for your IT staff.  They often have access to most, if not all, of the critical information in any organization simply due to the nature of their jobs.  While a disgruntled sales person may make off with a list of customers, a disgruntled member of the IT staff can cause far greater damage as was illustrated by the aforementioned Terry Childs case.    

Layoffs aren’t pretty and while we feel for those who are laid off we are still responsible for protecting our company’s information.  We shouldn’t blind ourselves to the risk posed by those unfortunate enough to be laid off.  Remember it’s not personal, just business.

Tags: auditing, Britain, Bureau of Labor Statistics, Department of Labor, disabled accounts, disgruntled employees, Europe, Germany, information categorization, it's not personal - just business, Japan, jobless, laid off, layoffs, log management, position categorization, termination, Terry Childs, unemployment, United Kingdom

I received this question the other day:

My CFO and I were discussing compliance with SOX and the GLB the other day and we got into an argument about whether we should be doing security assessments or security audits as the best way of meeting our obligations under these laws.  Can you help me with what I should say about the differences and provide some guidelines on how my company can use these appropriately to meet our compliance requirements?

The lines between auditing and assessing are often blurred.  In the strictest sense, an audit is a measurement of compliance with a standard or a set of criterion and an assessment is a measurement of effectiveness.  Using these strict interpretations, an audit can be looked upon as objective and an assessment can be viewed as subjective. 

Let me place each of these activities into context as perhaps that will shed some light on the differences between the two activities and how they can be blended thus causing the confusion that you experienced with your CFO. 

Audits typically can be imagined as a series of Yes/No or multiple choice questions: “Does the organization….?”  The answers to these questions are designed to highlight areas of non-compliance or gauge how far from compliance an organization is. 

Let us take a look at an example:

“Does the organization have a policy concerning the separation of duties?  Yes/No”

This is a typical audit question.  This question simply asks for the presence of a policy that addresses the separation of duties.  In order to verify this, an auditor would need to see a copy of that policy. 

An assessment would go a bit further and ask to see procedure on how the policy will be implemented and then interview multiple people in order to ascertain if the policy and procedure is being followed.  A judgment is then made concerning how effective the control is (the control being a policy on the separation of duties). 

Audits tend to weight answers to questions in an attempt to also reach some sort of judgment concerning the level of compliance.  Personally, I have an issue with this practice. 

Audits strive to be objective measures.  When the answers to an audit questionnaire are weighted, the auditor is actually making judgments concerning how important certain questions are in the attainment of compliance.  This provides a very subjective foundation to what is suppose to be an objective exercise.  (In my humble opinion of course)

Assessments on the other hand are intended to be subjective and opinionated.  Assessments attempt to place their subject into context.  Referring back to the question above an assessment statement might look something like this:

“Organization XYZ does not have a specific policy on the separation of duties within their network environment.  The organization indicates that funding concerns have limited the size of the network support staff making this control impractical.  In order to compensate, a detailed auditing and review program has been instituted.  Audit logs are reviewed daily and serve as an adequate compensating control.”

The difference between auditing and assessing computer systems is rather clear when using strict definitions of audit and assessment however in practice the line between the two has become blurred.  The benefits of each are often confused thus leading to disagreements such as you experienced with the CFO. 

I prefer to utilize both activities in their strictest sense.  I audit to determine where I am compliance and where I am not compliant.  I also then expand upon these findings to ascertain how well this level of compliance is actually securing the computer system.  I can then make two statements concerning the system: its level of compliance and how effective that level of compliance really is in terms of achieving the goals of the regulation being applied. 

I hope this helps to illustrate the concept.  Please keep those questions coming. 

Tags: assessment, audit, Compliance, measurement

I gave a talk a little while ago about using some of the principles of social psychology when developing and delivering effective security awareness and training programs.  During the talk a member of the audience asked the following question. 

“It seems to me that what you are doing is tricking people into doing what you want.  How is using social psychology any different from what cults do to trick their followers into obeying their rules?”

Now, I certainly do not want to give the impression that I’m advocating some sort of mind control experiment in order to get people to follow corporate policies.  If you will permit me to take a few minutes to explore social psychology (or more specifically: social cogitation), I believe that you will see how this knowledge can be useful in tailoring training programs to be more effective without “brainwashing” the students.

One of the issues with trying to change someone’s behavior is that it is most often done through negative means – punishing bad behavior.  What this does is really just address the symptom rather than the true problem.  Social Cognation is the study of how people process social information, especially its encoding, storage, retrieval, and application to social situations.  In other words, it is the study of how we apply what we know in social situations. 

Social Cognition has five main principles:

• The Power of the Situation over Behavior,
• Blindness for Situational Influences,
• Social Perception and Self-Perception are Constructive Processes,
• Blindness for the Constructed Nature of Social and Self-Perception, and
• Self-Processes are Social.

While a full blown discussion on these topics is well beyond the scope of this short blog post, let me quickly address these and show you how knowledge of these principles can help focus Security Awareness and Training programs to maximize retention without “brainwashing.”

Studies have shown, and I’m sure that you have all experienced it; individuals often act differently in social situations.  Call it peer pressure, group mentality, mob influence; it is all the same thing.  This affect can have both positive and negative influences.  What is more, this influence is typically unnoticed by the individuals experiencing it.  We are often blind to the influence our environment has upon us.  We aim to harness this principle to create an atmosphere, which is conducive to sound information security practices and hopefully by drawing on this principle, gain an increase in policy compliance. 

Perception is the process of acquiring, interpreting, selecting, and organizing sensory information.  Perception is an important influence on the organization of our mind and how we interact with our environment or in other words our perception of the world is constructed by our understanding of abstract concepts.

If our social perception is based on currently activated mental representations, motives, and processes then by introducing and reinforcing new representations and motives we can change the way that information security is perceived.  Of course, again, studies have shown that we, as individuals, are often blind to this process occurring within our minds. 

Finally, studies have shown that individuals base their own self-knowledge much the same way they perceive the world around them.  The understanding of abstract principles that filter an individual’s perception of the world around them also filter the individual’s perception of self.  This really addresses the core problem of information security. 

Information security by its very nature is not social.  We ask you not to allow other individuals to follow you through secure doors, we ask you to be suspicious of emails and unknown files, we ask you to question and report requests for confidential information.  All of these are essentially anti-social behavior and they often run against what we have been taught growing up. 

These concepts are so ingrained into each of us that it takes quite a bit of effort to cause a change in perception.  A program incorporating these concepts seeks to go back to the way that we all learned about the world around us in order to focus on activities that underscore the importance of information security in terms of its benefit to the collective social group.  We wish to show the importance of following these principles in terms of the benefit felt by each of us individually and in turn the benefits felt by the group as a whole.  It turns information security from an anti-social behavior to the truly social behavior that it should be. 

Is this brainwashing?  Well, I certainly don’t think so.  Brainwashing is typically done in such a way that the person being brainwashed doesn’t realize the affect that is occurring.  We are being upfront and honest about our means and our goals. Having an open and honest dialogue about information security within your organization is a healthy and beneficial activity.

Tags: brainwashing, group mentality, mind control, mob influence, peer pressure, perception, security awareness, situation, social cognition, social psychology, training

Okay so I spent the week in DC and attended the pilot presentation of the NIST’s Risk Management – An Organizational Perspective course and I thought that I’d share my thoughts on it with everyone. 

First off the course is intended to provide an overview of the methodology for managing organizational risk unsurprisingly called the Risk Management Framework (RMF) developed by NIST and aimed at Federal Agencies. 

When I accepted the invitation to go I really didn’t give it much thought and showed up expecting to sit through an overview class that would be presenting some new information.  When I got there I realized that what NIST wanted was feedback on the content and presentation.  Ever one to have an opinion, I was delighted to provide constructive feedback.

The course is based on their Special Publication 800-39 document: Managing Risk from Information Systems: An Organizational Perspective.  The primary audience is of course the federal government but it contains tried and true principles familiar to anyone who manages risk.  What is surprising is that after all these years many organizations focus on what I call “point solutions” and not on organizational risk.  I’ve seen this happen at federal agencies as well as private institutions in more than a few different industries.  So with this in mind it is important to keep repeating the obvious until people begin to take some notice – enter this course.

Apparently NIST is planning on developing both an executive overview of the document as well as a three to five day overview course for government people who will have “hands-on” responsibilities with regard to risk management in the federal government (but no actual experience) – two very different audiences.  The problem with the pilot course is that it tried to cover both audiences at the same time. 

Now I’m not knocking NIST here.  Course development is not as easy a task as it may seem.  There are many different types of learners as well as different levels of detail required depending upon the audience.  I’ve been developing and delivering similar training for over five years now so I know first hand how hard it can be.  When you sit down to prepare the material it can often become difficult to accurately judge the level of detail needed so my hat is off to NIST for opening themselves up to criticism.   

The level of expertise and experience of the people sitting in that room was daunting.  With over 10 years of experience I was probably one of the more junior people there.  Just about everyone else had just over 15 years and came from a variety of different backgrounds.  If you were looking for constructive criticism, I can’t think of a better group to get it from though. 

Now when you typically get that many smart, experienced people in the room there is always someone who wants to promote their own agenda – it didn’t happen this time though.  Everyone listened and gave very good advice and their considered opinions.  It was very collegic and team oriented.   I think that everyone felt that they were contributing to the greater good and was happy to be able to do so. 

We occasionally had a hard time not getting caught in the weeds.  When you’ve been doing this for a while you tend to know which minutiae are important and what isn’t.  The problem becomes squaring that with the level of detail required by the target audience.  NIST’s presentation had that same problem.  At times it was just right for an executive level of detail and at others it dove down into the weeds.  While everyone in the room followed along, I’m not so sure a new person would have.  The group’s comments reflected that opinion too. 

One new thing that I heard (and it’s possible that I haven’t been paying attention as I’ve been focusing on the private sector for a while) is that NIST plans to release what they call Quick Start guides.  These are intended to be the “Cliff Notes” for the special publications.  They showed us one as an example and I thought it was just the right level and length for an executive summary.  It was enough to give you a context and an idea of what you needed to know before you dove deeper into the content of the actual Special Publication. 

All in all it was a pretty good few days.  NIST has a very difficult job.  When most people sit down to develop standards and guidelines they have a specific audience in mind.  That audience tends to be somewhat specific – either a specific industry or a specific organization.  NIST’s audience must span the entire federal government with all the different organizational cultures from all the different agencies.  What they come up with must be applicable in all those different environments.  Give too much information and it isn’t applicable in some environments; give too little and it isn’t applicable in any environment. 

This course will probably go a long way towards rectifying some of the criticism thrown at NIST over the years.  This week was a great opportunity to talk with the authors of the document and learn what they went through in order to create the documents.  Many of the issues we brought up were debated by NIST when the documents were created and we were able to gain the insight of their intent.  I hope in turn NIST will incorporate these insights into their Risk Management course.  That will go a long way to reducing some of the confusion that is out there.  I have every expectation that it will. 

All in all I had a great couple of days.  I met some wonderful and knowledgeable new colleagues, renewed old friendships, and gained a little more insight into this topic that we call Risk Management.

Tags: management, NIST, organizational perspective, risk, risk management, SP 800-39