I’ve been a bit lax with the blog lately and for that I’m sorry.  The reason will be clear in a few weeks when I hope to be able to make an announcement.  For now though I’d like to just provide my apologies.

This post started out as my commentary on two recent articles that appeared in CSO Magazine concerning the data breach at Heartland Payment Systems (“Heartland CEO on Data Breach: QSAs Let Us Down” and “SQL Injection Attacks Lead to Heartland, Hannaford Breaches.”) 

Now what I do to write these posts is basically sit down and let it just flow out of me.  I then go back and do a little clean up as needed.  Sometimes the clean up needed is so much I just trash the post.  Other times I realize that a concept that came up late post is really what the post should have been about in the first place.  That is the case this time.  So I’ve basically thrown out three quarters of the pontificating (which you really didn’t want to hear anyway) and focused on the analogy that information security is much like professional cooking. As I put this together I glanced down at the word count and realized that this was growing to be much more than the simple post that I initially envisioned.  So what I’ll do is break it up into a few parts to try and get my point across.  Let me know if I was successful. 

How did I come up with this analogy?  Well it was mainly sparked by a comment made by Heartland CEO Robert Carr in the first article mentioned above.  That comment was:

“The audits done by our QSAs (Qualified Security Assessors) were of no value whatsoever. To the extent that they were telling us we were secure beforehand, that we were PCI compliant, was a major problem. The QSAs in our shop didn’t even know this was a common attack vector being used against other companies. We learned that 300 other companies had been attacked by the same malware. I thought, ‘You’ve got to be kidding me.’ That people would know the exact attack vector and not tell major players in the industry is unthinkable to me. I still can’t reconcile that.”

In this first part I’m going to set up the analogy and then dive into it within the subsequent posts. 

While I’ve been critical of some of the statements that Mr. Carr has made in the past I basically think that he has done a great job in responding to the crisis his company is in.  True he may have been forced into this response by circumstances but I’m not going to look a gift horse in the mouth.  A CEO of a major corporation has finally come to realize the importance of information security in the daily operations of his company.  However you look at it that is a good thing.  That he has become proactive in advancing our cause is an even better thing. 

What concerns me though is Mr. Carr’s statement.  He may be doing the right thing but I don’t want him to do it for the wrong reason because in the end it won’t help us out, it may even hurt us. 

You see Mr. Carr’s statement smacks of “missing the forest for the trees.”  He seems to understand that he must do something but doesn’t really understand the real reason behind it.  So this is my effort to try and shed some light onto the subject.  Will Mr. Carr ever read this?  Who knows but that really isn’t important as long as this helps someone.  So if this makes sense and you want to use it go right ahead.  (Just give me credit in some way.)

Let me take a stab at reconciling the issue.  The QSAs didn’t necessarily fail.  They audited to a known and accepted standard.  PCI DSS didn’t even necessarily fail; it is what it is a standard.  What failed you was the commonly held assumption that compliance equals security. 

When push comes to shove, SQL injection has been around for a long time so the fact that systems are still regularly found to have input validation issues is surprising.  Since we can’t blame the QSAs should we blame the developers?  We could but again we’d be missing the forest for the trees.  These are but symptoms of the problem.  How do we get at the problem?  In trying to get a handle on this I’ll try my hand at a little analogy.  That being that Information Security is a lot like professional cooking.  I’ll illustrate this by first focusing on how recipes are a lot like standards (Part Two) and then I’ll move on to broaden the image by relating what we do in information security to working in a professional kitchen.

Tags: Compliance, CSO Magazine, Data Breach, developers, Heartland Payment Systems, information risk management, insider threat, PCI, PCI DSS, professional cooking, professional kitchen, QSA, recipes, risk management, Robert Carr, SQL Injection, standards

This week saw the release of the 2009 Data Breach Investigations Report put out by Verizon.   This one is different from last year’s report in that it only deals with 2008 as opposed to a three year period (2004-2007) like the last one.  It is also based upon firsthand evidence collected by Verizon’s investigative response teams.  This is good and it is bad.  It is good in the fact that their analysis of root causes is probably very accurate (as opposed to relying on someone else’s experiences).  On the other hand it is bad in that their analysis of industry and organization size to data breach is heavily influenced by their customer base.  As a result I am intentionally not going to pay any attention to these results/correlations. 

It is also important to recognize that all such studies are biased in some way.  It is very hard to conduct any study like this and not introduce some sort of bias be it through the wording of questions to the selection of the data set analyzed.  Rather than throw out all studies, it is important to put their findings within the proper context before applying the findings to your own decision-making process.  What follows is my attempt to do that. 

Findings of note:

·         A vast majority of data breaches come from outside the organization (43%) or from multiple sources (39%).  Multiple sources appears to be defined as a combination of external, internal, and/or partner sources. 

·         The source of external attacks comes primarily from Eastern Europe, East Asia, and North America.  During the period between 2004 and 2007, these regions accounted for 59% of the attacks; In 2008 they accounted for 82%.   Beyond the region, nearly two-thirds of the attacks could not be traced to any specific entity other than IP.  Of the one’s that were traced most were connected with some sort of organized crime.  In fact Verizon points out an amazing statistic: 91% of all compromised records in 2008 were attributed to organized crime activity. 

·         A majority of the breaches involving business partners involved the lax security practices of the partner who was administering client-side systems. 

·         Error is a significant contributing factor in nearly all data breaches.  This one is very interesting to me because if the study is accurate in this regard it means that most organizations already have the tools they need.  In other words you don’t really need that new shiny box with the binky lights on the outside to protect your network.  The error comes from misconfigurations, omissions, programming errors, process breakdowns and poor decisions.  Verizon took the time to clarify their use of the term omission.  An omission could be defined as the failure to follow through on enacted policies and/or procedures and is distinctly different from misconfigurations and programming errors.  A common problem with compliance focused security programs (my own assessment, not Verizon’s). 

·         A vast majority of organizations were either fully targeted (28%) or opportunistically targeted (44%) (Combined 72%)  A fully targeted attack is where the victim was chosen before the means to exploit them was discovered.  Opportunistic targeting involves the victim being targeted because of a known weakness or vulnerability such as running a version of software with known exploitable vulnerabilities.  Verizon provides a suggestion with which I fully concur – organizations need to determine if they will be identified as a target of choice or a target of opportunity.  If a target of choice then they need to be prepared to fend off determined and sophisticated attacks, if a target of opportunity then minimize the opportunities for exploitation. 

·         Online Data is the most frequently compromised asset by far (94% compared to End user systems 17%).  This is important from the prioritization sense.  While it is fashionable to institute elaborate means to protect offline data, mobile devices, and end-user systems the money would be better spend on securing application servers and databases first.  (Incidentally this is the only instance in Verizon’s analysis where I felt that the comparison between the percentage of breaches and the percentage of records compromised had relevance.)   

·         87% of breaches could have been avoided had the organization implemented simple (53%) or intermediate (34%) level controls.  This falls in line with the Pareto Principle (aka the Principle of Least Effort) as it applies to protecting information where in 80% of the issues can be resolved with only 20% of the effort (time and money). 

 

Now my interpretation of Verizon’s findings underscores my belief that most of what is needed to protect an organization’s information assets already exists within the organization.  The findings speak to improving change and configuration management programs along with a more complete integration of security into an organizations system development life cycle (SDLC).  It also speaks to ensuring that business partners with whom you share critical data (be it transferring it to their systems or granting them access to yours) be required to comply with the same level of security that you employ within your own environment. 

The bottom line is that these improvements do not need to cost a lot of money.  Most of them come from focusing on the basics and doing them well – over and over again. 

Tags: 2009 Data Breach Investigations Report, Data Breach, external threat, insider threat, internal threat, misconfiguration, omission, Online Data, opportunistic targeting, Pareto Principle, partner threat, poor decisions, Principle of Least Effort, Prioritization, process breakdowns, programming errors, target of choice, target of opportunity, targeted attack, third-party threat, threat source, Verizon, vulnerability, weakness

This is Part Three of a multi-part series on the Insider Threat.  I’m interested in what motivates this type of individual, the patterns of behavior, and what organizations can do to reduce the likelihood that a malicious insider can impact their business.  In Part One, I relayed my own story of experience with what was most likely a malicious insider.  In Part Two, I reviewed some research that examines the insider threat and the pattern of behavior exhibited by malicious insiders.  In Part Three I’ll examine what can be done to mitigate the threat malicious insiders pose to organizations. 

I’ll have to ask you to bear with me just a little longer concerning the academic material. I promise that I’ll show you how it can be applied to real life situations. 

We talked about the interrelated behavior loops that influence the behavior of the malicious insider and how these behavior loops interact and influence each other.  Ironically, the very actions of trust and empowerment that have proven so beneficial to workplace satisfaction and performance appear to be the very things that support the transformation of trusted insiders to malicious insiders (with the appropriate motivation of course).  Should we change the way we manage people and reduce the level of employee trust and empowerment in order to combat the insider threat?  Of course not but doesn’t mean that we can’t do anything about the malicious insider. 

 Typically this would be the beginning of a discussion about the technical tools used to monitor and control access to information but I am not going to talk about technical controls.  Technical controls only constitute one-third of the information security equation.  The other two parts are People and Process.  I am of the belief that effective information security is based first on the human element.   Successful information security/information risk management programs are build first on understanding the people using the information systems.  Then on the processes they use to accomplish their jobs (both manual and electronic).  Finally technological controls are chosen as appropriate for both the users and their processes. 

Let me start out with saying that there is no way that you will be able to totally eliminate the insider threat.  The concepts that I will be addressing are intended to reduce the risk to acceptable levels not eliminate it. 

One of the reasons the authors of Preliminary System Dynamics Maps of the Insider Cyber-threat Problem chose not to deal with what motivates a malicious insider is that there can be as many different motivators as there are malicious insiders.  If it is not efficient to focus on the individual then we must focus on how individuals act within our organizations.  That is the study of Social Cognition. 

Much of the understanding we have on this process can be tied to experiments of many psychologists and social scientists starting with the work of psychologist Stanley Milgram in the 1960’s and subsequently built upon over the years.  These experiments have lead to the development of five principles of social cognition:

• 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.

I’ll be releasing a white paper shortly that discusses these principles in greater detail however what is important to this discussion is that individuals exhibit a tendency to conform their behavior to that of the groups to which they belong.  Another interesting aspect of this principle is that while group dynamics can alter individual reactions, these very same individuals tend to seek other individuals when in need rather than groups (Link A and Link B). What is surprising is that we (as individuals) are largely unaware of the influence that social situations have on their behavior. 

The next principles deal with how we interpret the world around us.  Studies have shown that our perception of the world is constructed by our understanding of abstract concepts; therefore, their environment is interpreted as direct perceptions of reality.  This can be illustrated by the interpersonal misunderstandings that can occur when people from different cultures interact.  (This can also be attributed to the “us versus them” attitude that we experience as information security professionals.) 

Individuals base their own self-knowledge much the same way they perceive the world around them.  In the same way that individuals are unaware that their interpretations of their environment are influenced by how they define abstract principles, these abstract concepts also influence an individual’s perception of self.

So what does all this mean? 

The practical application of these principles can increase the level of security or risk awareness within the organization by focusing our efforts on the group (individual behavior tends to conform to that of the larger group) and support this by instituting a mentor program to monitor individual development (individuals tend to seek other individuals when in need rather than groups). 

Since perception of the world around us (and of ourselves) is governed by our understanding of abstract concepts, we must institute programs to influence the abstract concepts of risk management within our organizations.  This means that we must directly address Corporate Culture.

Each organization has a unique persona.  Corporate Culture is a system of shared meaning held by the individuals who make up the corporation.  Changing corporate culture can be challenging and can be viewed similarly to product branding.  It conveys a sense of identity for its employees and facilitates a commitment to an overall goal or objective rather than individual goals and objectives. You must first accurately gauge what the organizations perceptions of information security are before you can design a program to alter these perceptions. 

This program must focus on an organization’s unique perceptions and include reinforcement (both positive and negative) in addition to education.  This is where most traditional security awareness and training programs fail.  They focus solely on training not on changing behavior.  The basic principles of information security have been taught to employees for so many years now that most employees could recite them from memory if asked.  The problem is that this knowledge is not translating into behavior. 

Using the concepts here we can influence the behavior maps that we discussed in Part Two.  We can keep the perception of risk high despite the high level of trust we want to foster in the environment.  This in turn helps to maintain adequate levels of funding and detective capability for information security.  A corporate culture that is risk-aware is also one that can positively influence a disgruntled insider so that they are less likely to become a malicious insider. 

At the end of the day there is no way to totally eliminate the insider threat however if we approach this problem in the right way we can stack the deck in our favor and reduce the risk to acceptable levels.

(FYI – If Social Cognition interests you as much as it interests me then I suggest that you start with an excellent article by Dr. Matthew Lieberman on the subject.)

Tags: behavior, corporate culture, culture, insider threat, malicious insider, People, perception, Process, reality, security awareness, security controls, social cognition, stanley milgram, technology, training, Trust

This is Part Two of a multi-part series on the Insider Threat.  I’m interested in what motivates this type of individual, the patterns of behavior, and what organizations can do to reduce the likelihood that a malicious insider can impact their business.  In Part One, I relayed my own story of experience with what was most likely a malicious insider.  In this part I will review some research that examines the insider threat and the pattern of behavior exhibited by malicious insiders.  I’ll wrap up this discussion in Part Three where I examine what can be done to mitigate the threat malicious insiders pose to organizations.  This may get a little academic for a while but if you can stick with me through the end of Part Three I promise that I’ll show you how it can be applied to real life situations. 

There have been numerous studies on the insider threat and perhaps the most compelling is one that I found over at Carnegie Mellon University’s CyLab website (Management and Education of the Risk of Insider Threat).  The report is a few years old (Preliminary System Dynamics Maps of the Insider Cyber-threat Problem) but I believe the basic tenets still hold true.  (If anyone knows of any other studies please send me the information as I’d love to read them.)  Let me cover the highlights quickly as the study is quite enlightening when it comes to the behavior exhibited by trusted insiders turned malicious.  By understanding this behavior, we are one step closer to being able to mitigate the risk associated with malicious insiders. 

The study involved twenty-five researchers from eight different institutions.  These researchers represented a variety of disciplines (computer science, information security, law enforcement, psychology, etc) and came together in an attempt to develop system dynamics maps of the insider threat problem.   There are many challenges in attempting to do what these researchers have done (the report covers these challenges so I will only allude to them here) but nonetheless, I believe they have establish a behavior map that simply and accurately lays out the cause and effect mechanisms existing within malicious insider behavior.  (At least it is consistent with the cases that I’ve been exposed to). 

The figure below shows a simplified number of behavior loops to simplify and focus the discussion.  (The full loops shown in the report’s appendices are quite fascinating.  If you have any interest at all in this subject, it would be worth your time to read through them.)

 

The researchers crafted scenarios around the three interconnected behavior loops.  These loops are:

• The Detection Trap (R1 on the image);
• The Trust Trap (R2 on the image); and
• Unobserved Emboldening (R3 on the image.)

The Detection Trap (R1) illustrates the trap that most organizations fall into.  As an organizations perceived risk increases, so does the investment.  This typically results in an increase in the organizations capability to detect malicious behavior within their environment.  With an increase in detection capability comes an increase in the number of detected precursor behaviors of malicious activity.  This increases the perceived risk within the organization feeding back into the loop.   While this is true, its inverse is also true.  As the perceived organizational risk diminishes (through any number of means, most typically the application of appropriate security controls) so does incentive for funding security at current levels.  Without appropriate funding an organizations detection capability is reduced.  This reduction in capability also impacts the amount of detected precursor activity which in turns feeds the loop all over again.  As can be seen by the image, this is complicated by the interaction the other behavior loops. 

The Trust Trap (R2) illustrates the potentially negative impact that trust can have within an environment.  Trust is a good thing to have within an organization.  It is indicative of supportive corporate cultures and can in many ways reduce the motivation which feeds the transformation of trusted insiders to malicious insiders.   An untended consequence of this trusting environment is that an increase in trust can lead management to believe that their organization does not need the capability to detect malicious behavior from their employees.  This reduction in detection capability would then result in the inability of the organization to detect if violations of acceptable behavior are occurring.  This inability to detection violations can reinforce the conclusion that the detective capability is not needed lowering the organizations perceived risk thus feeding the Detection Trap loop. 

The final behavior loop in this behavior map is the Unobserved Emboldening (R3) loop. This loop is intertwined with The Detection and Trust Traps and is fed by the concept of motive.  The researchers in the study decided not to actually define the various types of motive but rather to recognize that it is a necessary trigger for malicious activity.  By treating motive generically, we focus on the pattern of behavior rather than specifics of individual motivation. 

The actor in this behavior loop is the insider.  At this point they are trusted and motivated to become classified as a malicious insider but have not as of yet become one.  These insiders initiate a series of events that serve to “probe organizational defenses” as the report puts it.  If these events are undetected or ignored it lowers the risk the insider perceives in carrying out malicious behavior.  As the insider’s perception of risk decreases they become emboldened to continue this precursor activity.  The activity continues until the insider’s threshold for risk decreases to a point where the insider is willing to accept the risks involved in carrying out an attack. 

Understanding how these behavior loops interact and influence each other is an important step towards designing and implementing controls that help us to mitigate the risk from malicious insiders.  Ironically, the very actions of trust and empowerment that have proven so beneficial to workplace satisfaction and performance may be the very things that support the transformation of trusted insiders to malicious insiders.  In Part Three of this series we will examine this conundrum and offer suggestions on how to address these issues within your organization.

Tags: behavior map, Carnegie Mellon University, CyLab, insider threat, malicious insiders, MERIT, System Dynamics

My apologies in advance for this being such a long post. 

I’ve held off commenting on the case of a disgruntled San Francisco administrator who was jailed for launching his own denial of service attack on his employer.  Initially the reason was that I didn’t want to make a post that simply repeated what everyone else was saying.   You see the Insider Threat is one that is personal to me.  My wife lost her job as a result of what was very likely the work of a malicious insider.  I’m interested in what motivates this type of individual, the patterns of behavior, and what companies can do to reduce the likelihood that a malicious insider can impact their business. 

I’ve spend the week or so since I’ve heard of this most recent case reflecting on the insider threat and reviewing some research material that I’ve come across over the years.  I started a project a few years ago during my master program but have let it sit around since I graduated.  Now may be the time to dust off the research and revisit the topic.  This will be the first post in a multi-part series on the insider threat and possible how it can be managed within an organization.  But first my story:

When I first started in this business, my wife was able to get me a job with her company in the network support group.  We worked for a medium sized company in the Washington D.C. suburbs.  The support department was pretty small; only five people doing everything from answering the phone and running desktop support calls to server and infrastructure administration.  We were it so we did it all.  This is where I cut my teeth. 

Since no one else wanted the responsibility, I took over the firewalls, routers, and the security aspects of the company DMZ.  I learned a lot in those days and ended up getting a GIAC certification to fill in some of the gaps in my knowledge.  Things went well and when the company decided to migrate from Novell to Windows 2000 I was asked to prepare a security briefing for the IT steering committee.   My boss and I worked on a strategy to segregate the company’s information and control access via least privilege.  (Pretty standard really)  The problem is that we were shot down. 

The division heads wanted the free flow of information so that people could “collaborate.”  Everyone in their respective divisions could access any of the other work going on within the division and at times across divisions.  As work on various projects would ebb and flow, resources were transferred from one project to another and back again necessitating the need to access different types of information.  The division heads did not want to disrupt their ability to do this. 

We explained that this situation was normal and that while our plan would restrict access it wouldn’t hamper anyone’s ability to do their work.  A request for a change in access could be responded to within one business day in most cases, two days in rare circumstances.   We were still denied – nothing should interfere with the work being done.   In hindsight I also think that they were uncomfortable with the fact that we could audit and track what was being done with their information.  This was an organization that grew up from a “mom and pop” type beginning and grew organically.  Everyone was trusted and any threat was perceived to be from outside. 

About four months prior to these discussions someone new showed up at work.  This was an individual who had worked as a subcontractor for the company on one short term project and was known to a division head.  He just started showing up every morning, got someone to let him in, and squatted in an office.  Since the office wasn’t being used at the time he received permission to use that office.  They liked having him around “in case” work requiring his skills be required.   Let’s call him “Joe.”

“Joe” was a very nice older gentleman.  He was soft spoken and apparently well liked among the staff on that floor.  We found out that he wasn’t an employee when he called in a trouble ticket for his computer not being able to print.  The problem was that he didn’t have a log in thus he wasn’t able to map the print queue.  We reported this to our boss and when he went upstairs to investigate the division head, a vice president, said we shouldn’t worry about it.  She apparently liked having staff that didn’t impact her overhead when they didn’t have work.  So we documented this and moved on.  “Joe” figured out how to map the printer directly so his issue was solved.  (We were running Windows 98 workstations that allowed guest access and any device with an internal IP could surf the web.  Yup, we lost those battles too.  Again this was against corporate culture.)

Within a year “Joe” was hired on full time and worked on some projects in the same division as my wife.  As work would ebb and flow, he tried to get onto a few projects but apparently he had worn out his welcome because some projects preferred to work shorthanded rather than take him on.  Nothing much was thought about “Joe” really and I had all but forgotten about him.  After a few years I had progressed as far as I could and although I knew I’d miss my colleagues and the company it was time to move on.  I moved on to a systems integrator across town to start my new life as a consultant. 

A few months after I left my wife and I found out that we were expecting our first born.  We were excited and began planning on the future.  My wife still worked at my former company.  She was the Deputy Project Manager for a multi-million dollar government contract.  The company was very family friendly and since the project was set up to pretty much run itself they agreed that it would be alright for her to step back from the project for a year and then come back.  We were overjoyed.  We trimmed our budget to the bare minimum so that we could save her paycheck.  We needed to have some savings if she was going to stay at home to raise our son the first year.  We made it eleven months as our son decided to show up a month early.

While my wife was home with our son, the contract she was working for came up for its normal recomplete.  The government had already awarded all of its option years and by law had to recomplete it.  No one was concerned.  Everyone at the government agency loved the work that was being done as well as the people working on the project.  Everyone working with the federal government at the state and local level loved the work that was being done.  The company went into this recomplete about as strong as any company could. 

Little did they know about what “Joe” was doing.  You see “Joe” was apparently upset that he wasn’t allowed to work on certain projects and that he wasn’t promoted into a senior management position.  He shared his frustration with management but when his concerns went unanswered he kept his feelings to himself. 

About the time the Request for Proposals (RFP) was released by the government, “Joe” resigned and went to work for another company in the next county.   Surprisingly enough, this same company bid against my wife’s company on the RFP although they had no previous experience doing that sort of work or working for this government agency.  Apparently they had the right answers because they were able to successfully win the RFP with a slightly lower bid.  Oh yeah, and while “Joe” wasn’t named on their proposal response.  He ended up having a senior position on that account.  (According to unofficial sources from the government agency.)

Coincidence?  Perhaps but experience tells me that it was unlikely.  The resulting aftermath was that most of the people that worked on that project were laid off.  Had my wife still officially been on maternity leave they would have had to find something for her to do but she had changed that status two months previously to “on-call” for a reason that escapes me right now.  Subsequently she was also laid off. 

Did “Joe” take valuable project information to his new company?  Honestly, no one will ever be able to prove it.  The principle of least privilege wasn’t followed when setting up access.  Everyone was pretty much given access to everything within the company.   The network group wasn’t allowed the resources to audit access to critical information.  There are any number of plausible scenarios but the one that has “Joe” copying all the proprietary information on the project then leaving for a position with a competitor who ended up being awarded the work is the most plausible. 

What triggers this sort of behavior?  I’m not sure anyone can say for sure but in the coming weeks I’ll explore this concept.  In Part Two I’m going to look at some research that has been conducted into the insider threat as well as how people act and learn in groups in an attempt to build a basis for Part Three which will deal with how these concepts can be applied to help an organization properly manage the insider threat.

Tags: denial of service, disgruntled worker, insider threat, locked out, San Francisco