Global Security, Privacy, & Risk Management

InfoSec 101: Technology doesn’t fail, People do… January 27, 2012

As research indicates that pirates are beginning to engage the services of data thieves to steal data from shipping companies, it is important that the maritime industry begin looking at securing not only their vessels but their data assets, as well. In my past life as a data security professional, I have had the opportunity to work with some very, large complex organizations.  As a consultant I was often involved in the remediation and after action of companies that had experienced a data theft or major compromise (hack).   After reviewing about 3,000 data compromise cases I can say with confidence that it is not the technology that fails in data compromises, it is the people.  I have yet to ever see a firewall decide to stay home from work or decide to change its own ruleset to open a port.  I have seen a number of instances where a firewall administrator forgot to close a port or bypassed the firewall for “just a minute” and forgot about the change.  I have never seen an intrusion detection system (IDS) decide to turn itself off because it was tired, I have seen many instances where the IDS was tuned incorrectly, or where it was turned off because it was sending too many alerts.  The scenario repeats over, and over.  Technology doesn’t get tired, it rarely fails (statistically modern airliners are as reliable as toaster ovens)  and it doesn’t complain, or make mistakes.

Human beings aren’t so fortunate.  We are lazy by nature.  I say this because we all will take the path of least resistance in everything we do.  We are also fallible, which means we make mistakes.  It is simply human nature.  Unfortunately, in security this characteristic is why security breaches occur.  A guard falls asleep.  A firewall admin opens a port and forgets to close it.  A janitor doesn’t lock a door after leaving a building. An employee forgets one step in a calculation.  The list goes on and on.   So how do we minimize the mistakes and mitigate the risk associated with human nature?  The answer is simple but the implementation is difficult.  Established processes and procedures documented in policy and…here is the hard part….. enforced.

I cannot tell you how many clients when asked if they have a security policy will say: “Well, we don’t have a documented policy…but we have an ‘informal policy’.”  Wrong answer!  If it is not formalized and approved by the appropriate authority (CIO, BOD, etc.) then it is NOT a policy…it is an informal practice.  When I hear this answer I always ask: “How confident are you that the informal policy you describe is being followed?”  The answer is inevitably: “well…probably not as frequently as it should be.”   This describes the vast majority of companies I have worked with.  Why?  The answer is again simple.  First, policies are difficult and time consuming to develop and implement.  Second, we don’t like to step on other people’s toes.  We want to trust our co-workers and employees.  By establishing an onerous policy we are saying to them: “you are not trusted.”  Lets call a spade a spade.  None of us like being told we can or can’t do something or being treated like we are not trusted.  Unfortunately in security it is absolutely imperative that we establish and enforce policies.  Defined policies which are effectively enforced give us the only confidence that tasks are being conducted: “consistently, and repeatedly.”  This is the key.

How do you develop policies and procedures?  That topic is much to deep for this blog post but here is a high level process to follow.

1) Take an inventory of assets and prioritize those assets. (intellectual property, human resources records, financial data).  You need to know what it is you are trying to protect before you can find a way to protect it.

2) Identify the who, what, where, why, when, and how of data access. Using the access control reports/system (Windows Active Directory, LDAP, etc.) and application information, identify the following: Who has access to the data (include applications, services and people), what data they can access, where the data is stored, why they have access (and whether they actually need access), when they have the ability to access (and whether it should be restricted) and how they access the data (direct SQL queries, applications, etc.)  Develop a matrix with all info included.

3) Develop a dataflow diagram.  Using the matrix above, and an existing logical network diagram, create a diagram that logically shows where all sensitive data (as identified in #1) is located and how it flows through the network (including all applications and devices).  This process will be enlightening.  Experiences suggests there will be a number of ‘ahaa’ moments where you find that people with no business need have access to very sensitive data.

4) Develop a ‘data control policy’ using model of least privilege and ‘need to know’.  This is the first policy.  Classify the types of data and decide who (people, applications, services) should be able to access which type of data, under what conditions (time, location, etc.) and provide a justification.  This should be based on a ‘need to know’. For example, a system administrator (system level access) should not have access to the financial accounting database nor be able to see financial accounting data unless his/her job requires.

5) Update your access control mechanism to reflect the data control policy.  Update user privileges and rights in Active Directory, or LDAP to reflect the data control policy.  The Access Control Policy is another step that will be covered in another blog post.

By using the 5 steps above, you will be well on your way to controlling and protecting your sensitive data assets.  Remember, policies are simply paper documents unless they are documented, approved by management, disseminated, and enforced.  Although enforcement is often difficult, employees need to understand that violating information security policies can be met with punishment up to, and including, termination, OR prosecution.