jump to navigation

“Tell me, Show me, Convince me”; Policies, Enforcement, and Auditing August 7, 2012

Posted by Chris Mark in cybersecurity, Risk & Risk Management.
Tags: , , , , , , , ,
add a comment

I was speaking with a client yesterday about policies and auditing.  He asked me a question and it reminded me of what I told my clients for years regarding policies.  First, it is important to remember that a policy is NOT a document. The document is a record of the policy that was passed and tool for disseminating the policy. It should be a reflection of the policy that has been approved by management.  Simply having a written document does not mean you have a policy.  The policy must be approved, documented, disseminated, and enforced.  Second, it is important to remember that writing and approving a policy is the easy part.  Ensuring adherence with the policy  and enforcing the policy is the difficult part.  Make no mistake.  A policy that is not enforced will not be followed for very long.  People are inherently lazy (this writer included).  We take the path of least resistance.  Policies require difficult, often inefficient methods.  Without enforcement, they will fall by the wayside.  Third;writting, approving and documenting a policy is often much easier than implementing the policy.  Consider the following example.  Company X passes a policy that requires all computer and IT users’ access be modeled on “need to know” and “model of least privilege” (standard model).  This alone requires an audit of every person’s existing privileges, as well as identification and documentation or their roles and responsibilities.  Then each role would need to have access levels documented and assigned.  As you can see, a simple one line policy statement may have deep implications.  Finally, it is important to ensure that your company adheres to the documented policies.  This is a three step process I describe as “tell me, show me, convince me”

1) Show the auditor that you have a documented policy that is updated, approved by management and disseminated to employees.

2) demonstrate to the auditor that you are currently in compliance with the policy.

3) convince the auditor that you have a history of following the policy by producing relevant documentation/evidence to show compliance over time. (last 3 months, last 6 months).

By using the tell me, show me, convince me model with policies and departments you can have confidence that your policies are being enforced, and followed.

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

Posted by Chris Mark in InfoSec & Privacy, Risk & Risk Management.
Tags: , , , , , , ,
add a comment

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.

%d bloggers like this: