shopping cartShop
Call Us: 888 641 0500


New Security Policy Map for US CyberSecurity Framework

In February 2014, NIST released version 1.0 of the Framework for Improving Critical Infrastructure Cyber-security.   The frameworks is intended to be a “voluntary” set of standards that can help small and medium sized businesses develop an information security program.   (Part of the problem, of course, is that we don’t need another framework – but a rational and scaled down version of other frameworks such as NIST 800-53 or ISO 27002 that would make sense for small businesses.)  While the framework is currently voluntary, some speculate that it could become a default standard for evaluating smaller businesses and contractors that have a part of the critical infrastructure.

Mapping ISO 27002 to the CyberSecurity Framework

For those organizations that base their information security program on the ISO 27002 information security standard, we have developed a new policy map between the control categories of ISO 27002:2013 and the Cyber Security Framework.  This mapping should help your organization rationalize security controls across these two frameworks.  For existing customers, this mapping also includes references to the sample information security policies found within Information Security Policies Made Easy.

Download the ISO 27002:2013 to Cyber Security Framework Mapping Document.



The ROI of Pre-Written Information Security Policies

Often it is difficult to justify security policy development to management.   In many cases, this is due to a lack of understanding on just how detailed and complex policy writing can be.  “Just go find a template on the internet.”   For those of you who have tried this approach, you quickly discover that there is much more to the process IF you want to create a set of quality, consistent policy documents.

Buy or Build?

For those of you still struggling to justify the purchase of a policy package, download our whitepaper The ROI of Pre-Written Information Security Policies.   In this short paper we present a simple model for estimated the cost of writing information security policies.  Understanding this cost is the best way to computer a “return on investment” of purchasing a quality set of templates such as Information Security Policies Made Easy.

Understanding the Total Cost of Policy Development

But remember, developing information security policies is only one part of the ongoing management process.  To better understand the entire life-cycle costs of developing and maintaining policies, read our whitepaper The Total Cost of Information Security Policy Management.   Using these tools should help you estimate the costs of your policy development project, including using in-house resources versus outside consultants.



New Point-of-Sale Device Security Policy

The piercing lens of information security changes focus quite often.  In recent weeks the security vulnerability lens is focused on point-of-sale (POS) devices.  And there seems to be good reason.  The Target breach, perhaps the largest reporting breach in history, seems to be the result of malicious software inserted into these devices via a network hole and stolen vendor credentials.   As the news of the breach was unfolding, the National Cyber Investigations Joint Task Force (NCIJTF) issued new warnings about sophisticated malware attacks directly targeting POS devices.  While malicious software is a threat, the devices are also prone to physical tampering, prompting a new set of controls within the latest update to PCI-DSS 3.0.

As part of our ongoing updates to our PolicyShield Security Policy Subscription, we have added a new sample information security policy:  Point-of-Sale (POS) Device Security Policy.  This new security policy has controls that help mitigate the risks of malware infection, as well as the risks of physical tampering and theft.  The new sample policy is free to all existing PolicyShield subscribers.


How to Structure Information Security Policies

We talk to customers every day about  security policies.   One of the most common questions we receive is this:  How should we structure our information security policies?  When we dig deeper, we usually find that this is a really a two-part question regarding policy structure.

  1. First, how should we name and organize our documents.
  2. Second, what content or detail should go in each policy document.   These are both great questions and we will address each separately.

Why the Confusion?  HIPAA, PCI, FERC, NIST – Oh My!

Why do people struggle with this basic starting point for developing policies?  In our opinion, this has to do with the various and confusing outlines of different information security frameworks and laws such as ISO 27002, HIPAA,PCI-DSS and NIST.    People who (quite naturally) want to base their security policies on an established standard fall into a trap.  These common frameworks are designed to organization information security requirements, not form an outline for security policies.  For example, the NIST 800-53 outline is heavily biased toward technology.  The first major section of PCI-DSS is devoted almost entirely to managing firewalls.

These common frameworks are designed to organization information security requirements, not form an outline for security policies.

As an example, the first control objective (5.1 Information Security Policy Document) of ISO 27002 requires that an organization have a written security policy.  It does not specify how they will organized or grouped.  If you simply adopt the ISO 27002 outline, you will find it very difficult to place certain items, such as Acceptable Use of Assets, which are targeted at end-users.  The topic of IT Risk Management (which is called out in HIPAA and NIST) is not even part of the 11 domains listed.  The NIST outline specifies that written policies and procedures are required in each of the 17 different domains.   But if you simply adopt the NIST 800-53 outline, you will have challenges addressing common items like Third Party Security or Internet Acceptable Use.

The Common Policy Approach

We recommend a simple approach that is based on subject matter and target audience.  We use this approach in our Common Policy Library (CPL).  Using the CPL approach, information security policies are broken into a set of 10-20 policy documents, each covering a specific topic.  These topics are chosen to overlap with the most common requirements of various laws and regulations.  (Notice, we didn’t say ALL of the topics, but most of them.)    Here is a sample list of documents using the CPL outline:

  1. IT Risk Management Policy (Risk Assessment)
  2. Security Program Policy (Policy, Planning, Personnel)
  3. Asset Management Policy (Inventory, Acceptable Use, Protection)
  4. Information Management Policy (Collection, Classification, Storage, Disposal)
  5. Third Party Security Policy (Assessment, Contracts)
  6. Personnel Security Policy (Screening, training, termination)
  7. Access Control Policy (Systems, Accounts, Passwords)
  8. Network Security  Policy  (Firewalls, Structure, Wireless)
  9. Physical Security Policy(Visitors, IT Systems)
  10. Operations Management (Configuration, Change Control, Malware)
  11. Application Security Policy (Development, Testing)
  12. Security Incident Management Policy (Reporting, Response, Investigation)
  13. IT Business Continuity Policy    (backup, Business Continuity)
  14. Security Monitoring Policy (Logging, Audit, Monitoring)
  15. Customer Privacy Policy
  16. Employee Data Privacy Policy

Using this approach, each policy document contains all of the essential controls fora broad security topic (or domain using ISO terminology.)   Each documents contains a set of more specific policies, usually between five and twenty statements per document.   This provides enough detail to mitigate the risks of each category, but does overwhelm the stakeholders with information.  (This is the approach we use with our information security policy library.)

In many cases, these topics align nicely with major categories of the ISO 27002 standard or NIST 800-53.   Just as important is the fact these topics also have a specific target audiences (or “stakeholders”.   For example, a Security Program Policy is generally targeted at management, oversight committees or external auditors.  A Personnel Security Policy is targeted at hiring manager and the Human Resources department.   Having a well-defined set of stakeholders makes each policy easier to review, update, approve and manage.  This point is worth repeating:

Having a well-defined set of stakeholders will make any policy easier to approve and manage.

Avoid  The One-To-Many Policy Approach

Some information security practitioners use what we call the “One to Many Approach”.  In this approach, the organization has a single, overarching policy document with a group of very high-level policy statements.  An example would be, “Company X protects access to all sensitive data”.  These documents then refer to a group of  “standards” documents to provide more detail.  In our experience, this approach simply creates another level of abstraction that does not help get security policies written and approved.

Information Security Policies Versus Standards and Procedures

Another key to this approach is to make sure that these documents contain only “policy” statements.  In other words, these documents describe very specific rules for what behavior and processes and technologies will be implemented within the organization.   But they don’t specify how they will be implemented.  For example, the Incident Management Policy can (and should) require that the organization develop specific incident response procedures.  But these procedures should be in separate documents that refer back to the policy they are designed to support.  (Procedures support and implement policies.)  As another example, a baseline standard for an operating system can list the specific settings for parameters, accounts, and services.  But these details should never be part of a security policy.  Standards can be updated as frequently as needed.

Off the Shelf and Into Action

One of the great advantages of organizing security policies by topic and stakeholders (organizational roles) comes during implementation.   For example, most information security regulations specify that personnel should be training on the policies that apply to them.   When an organization mixes technical management and personnel policies in a single document, this becomes very difficult.   When you limit each document to a limited set of policy statements, and then limit those to a specific audience, the process is very simple.  Using this approach makes it very simple to use automated policy management tools.

Summary: Effective Security Policy Structure

In summary, break your security policy development into a series of policy documents covering various topics.   Anywhere from 10 to 30 documents is common, depending on the size and scope of the organization.   Within each document, have a group of specific security policy statements (from 5 to 25 is common.)   Try to break up the topics to match the requirements of your business as well as the target audience.  This approach not only makes it easy for your organization to demonstrate compliance with a specific law, but it will dramatically reduce the effort required to manage each policy.








Information Security Policies for PCI-DSS V3

The PCI Security Standards Council just released Version 3.0 of the Payment Card Industry Data Security Standard (PCI-DSS), the set of requirements for protecting credit card data.  The update had some significant changes, including a greater focus on third-party information security.

There are many articles describing the new changes to PCI-DSS V3, including a nice summary of changes from the Council, so we won’t duplicate that effort here.  For our purposes, we wanted to look at the implications for information security policy development, so we will focus our analysis on Requirement 12:  Maintain and Information Security Policy.

Requirement 12 – A misnomer

First, Requirement 12 “Maintain an Information Security Policy” is essentially misnamed.  While it does outline the specific requirements of written information security policies (12.1), it should really be named “Maintain an Information Security Program” – since it covers all of the organizational aspects of information security, including risk assessments, personnel security, and third-party security.  Unfortunately, this name carried forward to the new update.

This confusing name just adds to the overall global confusion regarding security compliance and security policy.  Customers met with these requirement go looking for a single “information security policy” – when in fact what they need is a SET of information security policies and procedures that document their information security program.

PCI-DSS Information Security Policy Requirements

PCI has always been a strange standard compared with other outlines like ISO 27002 or NIST.  While the PCI recommendations go into specific detail in areas like firewall management and configuration (what we might refer to as a “standard” or even technical configurations), requirement 12 makes much higher-level statements about security policy.

12.1 Changes – Security Policies Moved

One of the key PCI-DSS requirements is that the organization have written security policies and procedures that cover each of the security categories.   But now they say it a bit differently.

One of the major changes in the outline was to take the previous requirement (12.1) to have written policies and procedures and spread it out into the various topic sections.  So rather than saying you must “have policies and procedures that cover the PCI-DSS topics” it simply adds that requirement at the end of each section (physical security, access control, etc.)  This is more in line with the NIST SP 800-53 approach.  But it adds little in the way of guidance or clarity.   This approach also seems to leave out the requirements to document the previous 11 categories of the standard, which is clearly not the case.

PCI-DSS Information Security Policies in 4 Steps

So what DOES PCI-DSS V3 really say about Information Security Policy?   Let us try to summarize in four basic steps:

1. Written security policies should document the overall structure of your information security program, (as such, written information security policies are key pieces of evidence for auditors and assessors seeking to validate your program)

2. You must have written information security policies and procedures that cover all of the control categories of your security program.  (Access control, physical security, personnel security, incident response, etc.) (12.1)

3. Like your program, information security policies must be reviewed and updated to reflect changes in your program and security environment, (12.2)

4. Your written policies should be distributed to the key personnel that need to follow them. (12.1)

Not surprisingly, this is what ISO 27002 says about written policies (5.1) and HIPAA says about information security policy.  Did we need another standard with another numbering system?  We’ll let you be the judge of that.

The bottom line is that these are the core components of any effective information security policy program.  If your organization adopts these best practices, then addressing the specific requirements of different regulations will basically fall into place.

About Information Shield

Information Shield publishes the leading library of information security policy templates, including Information Security Policies Made Easy.   Our products allow organizations to quickly document their information security program for compliance with regulations and frameworks including PCI-DSS, HIPAA, NIST, ISO 27002 and CoBIT.



ISO 27002:2013 Change Summary Heatmap

The British Standards Institute (BSI)  recently released an updated version of ISO/IEC 27002 – Code of Practice for Information Security Controls.  This was the first major update since the 2005 release.  Many organizations are interested in how the changes will impact their information security program.

What Really Changed?

In our review, very little in the way of information security substance was changed in this version.  While several controls were added and several more removed, the update is largely an exercise in moving and renumbering.  The essential “key” controls are still required – they have just been moved to a different location.

Some of the key moves seem justified – like consolidating all third-party security controls into one domain.   (Understanding the rationale for renaming the domain “Supplier Relationships” from ‘Third-Party” is more difficult.)  While some sections such as 5.0 Information Security Policy remained unchanged, several areas such as Operational Security had major changes.

The ISO 27002:2013 Change Heat Map

In our efforts to decipher the changes between ISO 27002:2005 and 2013, we found it very difficult to wade through the vast numbering changes.  In order to help our clients manage this information, we created a change “heat map”.  In short, the map uses color coding to try to indicate areas of large change (red) versus areas that remained similar (green).

The heat map aligns both of the versions (like this sample image) to try to visualize what was maintained, added and removed between versions.

So what does this mean for Information Security Policies?

Most organizations will change little with this update -  unless they included specific ISO 27002 references in written policy documents.  In that case, they will have to change a large number of references.  (Which it might make sense to remove for future versions!)

The core requirements to develop, maintain and distribute written information security policies are still key to the standard.   (As they are with every information security regulation.)   The work will be in deciding how and when to address  the new control objectives, and then include those within your written information security policies.  In future releases of  our PolicyShield Security Policy Subscription and Information Security Policies Made Easy, we will include any needed sample policies to fill in the gaps.

 Get the ISO 27002 Change Summary Heat Map here.





Information Security Policies According to NIST

Five Best Practices from NIST 800-53

In April 2013, NIST made the final updates to their complete catalog of information security requirements, Special Publication 800-53 Revision 4 – Security and Privacy Controls for Federal Information Systems and Organizations.  The catalog is BIG – it contains hundreds of information security and data privacy requirements organized into 17 different topic categories.  Each category is called a “family”, and covers a key information security topic such as access control (AC), incident response (IR) or physical security (PE).

For people not familiar with FISMA or NIST, this document is essentially the security “encyclopedia” for how to protect systems and organizations.  As such, even organizations that are not required to comply with federal information security laws still reference the NIST standards for guidance on all things security.

So what does NIST SP 800-53 say about written information security policies?  In this article we take a slice through the outline and pull out the requirements as they relate to information security policies.  For this article, we will use the NIST family Access Control (AC) as a working example.  The result is a list of five key principles of information security policies according to NIST:

1: Written information security policies and procedures are essential

The first control in every domain is a requirement to have written information security policies.  The specific requirement says:

The organization Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]: (1) An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance;

Notice the term “documents”.  This implies that policies need to be written down.  While this seems obvious, many organization still fall short in documenting their specific security policies.  (This is often sites as the greatest deficiency when audits are conducted for HIPAA/HiTECH by the OCR.)  The second part calls for written procedures to support the policy:

(2)    Procedures to facilitate the implementation of the access control policy and associated access controls; and

Each of the 17 other control categories (or families) follows the same format, with the first requirement always calling for written for policies and procedures.  What this also implies is that the policy document for each section covers the key controls required for that domain.   For example, within Access Control (AC), your Access Control Security Policies could cover:  Account management (AC-2), access enforcement (AC-3), information flow enforcement (AC-4), separation of duties (AC-5) and so on.  While NIST also specified a minimum set of these controls, the typical organization may choose a smaller subset.  But the structure can remain the same – one or more policy statements for each topic.

2: Security policy documents must have a defined structure

NIST SP 800-53 also goes into detail about what needs to be covered within the security policies.  The requirement for an Access Control Policy specifies that the organization develop:

(1)    An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance;

For example, each document should cover the “scope” of the organization or systems that the policy applies to.  It should also include references to specific organizational roles required to take action as part of the policy.  To address these requirements, each policy and procedure document should have a standard format with sections addressing each of these required areas.  A standard format not only speeds up the review and update cycle, it helps the written information security policies integrated with other standard corporate policies.   A similar standard format is built into each of the 30 sample policy documents included within Information Security Policies Made Easy.

3:  Security policies must be periodically updated

The NIST guidance is once again very specific about this requirement.  Written information security policies and procedures need to updates to reflect the latest changes in the organization.

The organization: (b) Reviews and updates the current: (1) Access control policy [Assignment: organization-defined frequency]; and (2) Access control procedures [Assignment: organization-defined frequency].

Notice that the requirement allows the organization to set a specific time-period or frequency for updates.  A common time period is annually for information security policies.  Information security procedures can be updated at the same period or triggered as part of a policy update.  For example, the organization may update the Employment Termination Procedure to reflect new requirements, but the Personnel Security Policy that requires this procedure can remain unchanged.

4: Security policies must be distributed to the organization

Information security policies and procedures are not effective unless the drive organizational behavior.  To do this, policy and procedure documents need to be distributed to the users in the organization so they can be read and understood.

The organization Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:

Some other implied requirements come from the need to “disseminate.”  First, organizations should target specific policies to user groups and roles within the organization.  For example, all users do not need to be aware of the contents of the Network Security Policy, while all users should know how to safely use the internet and email.   Another implied requirement is that these documents are understood.  The organization should perform due-diligence in educating users on the security requirements of their jobs, including the information security policies and procedures that apply to them.

5: Security policies must be managed with a defined process

The previous four elements lead up to this key requirement:  Organizations must establish a formal management process for information security documents.  This requires that the organization treat information security policy documentation as an ongoing project, not a one-time event.   This implies several other requirements, such as assigning ownership to each policy document and to the entire policy management process.  How can an organization possibly manage the specific security policy elements – including reviewing, management commitment, coordination and compliance – without a management process?  Sadly, this is where many organizations fail.  The development of information security policies is delegating to a single individual as a part-time project with minimum visibility into management, rather than being treated as a project that requires funding and resources.  While this approach may get the organization by, it usually fails after the first major audit.  As always, up-to-date information security policies are key pieces of evidence to support due-diligence.


While your organization may not be required to comply with FISMA, the NIST family of publications can provide excellent guidance on developing and managing an information security program.  When it comes to written information security policies, the message is clear:  Security and privacy policies need to be living documents.


Example:  The full catalog listing for AC-1 within NIST SP 800-53.


Control:  The organization:

a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:

  1. An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
  2. Procedures to facilitate the implementation of the access control policy and associated access controls; and

b. Reviews and updates the current:

  1. Access control policy [Assignment: organization-defined frequency]; and
  2. Access control procedures [Assignment: organization-defined frequency].

Supplemental Guidance:  This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the AC family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9.

Control Enhancements:  None.

References:  NIST Special Publications 800-12, 800-100.

Priority and Baseline Allocation:

P1 LOW   AC-1 MOD   AC-1


Security Policies Key to HIPAA BA Compliance

In January the Department of Health and Human Services (HHS) released the much-awaited final updates to the HIPAA Security, Privacy and Enforcement Rules. These updates, known as the “Omnibus Rule” were required by the HITECH Act and have been in proposal form since 2010.  The new law incorporates some major changes in the HIPAA security and privacy rules, including a new focus on the risk of third party vendors (aka Business Associates).

300,000 Business Associates Impacted

Perhaps the most sweeping change was the extension of HIPAA to “make business associates of covered entities directly liable for compliance with certain of the HIPAA Privacy and Security Rules’ requirements.”  In short, Business Associates (BA) that process electronic health information (ePHI) are now required to conform to the same data protection requirements as covered entities (CA).  In addition to the compliance requirements, the legal liability of HIPAA violations was also extended to the vendors.

According to HHS, an estimated 250,000 to 400,000 new organizations will be required to comply with HIPAA security requirements.  This represents a substantial number of small and medium-sized businesses that are suddenly faced with the burden of compliance.

In addition to this compliance requirement on the vendors, each covered entity (CA) will be required to perform due-diligence in screening, managing and assessing third party vendors.  As usual, a key part of this validation will be the effectiveness of the written information security policies of the business associate.

§ 164.308 Administrative safeguards.

“(8) Standard: Evaluation. Perform a periodic technical and nontechnical evaluation, based initially upon the standards implemented under this rule and, subsequently, in response to environmental or operational changes affecting the security of electronic protected health information, that establishes the extent to which a covered entity’s or business associate’s security policies and procedures meet the requirements of this subpart.”

The Cost of Compliance – Are they serious?

Here’s the good news – if you believe HHS, you can charge these new compliance efforts to your corporate credit card.  It its required economic impact analysis, HHS estimates the total impact of this new compliance effort of business associates to be between 22 and 113 million.  If you assume the highest estimate for 400,000 organizations -  this works out to be roughly $250 per organization.  (Are they serious?)  In the real world, these costs will likely be much higher.  A robust information security program that can be validated by a third party is not a small effort.   At Information Shield we are doing our part by offering cost-effective solutions to help you establish and document your written information security program.

Solutions for the Human Side of Security

HIPAA Compliance should not just be a documentation exercise.  If your organization is going to make the effort, why not create a sound information security program that actually reduces risk?  Information Shield solutions help you accomplish this sensible goal.  We have everything you need to manage the “people” side of information security and privacy:  quality information security policies, security awareness training and compliance management.  You can spend millions of dollars on technical security (firewalls, antivirus, spam filtering, IDS) and still have a breach with ONE human mistake.




New Guidance Requires Social Media Security Policies

In January 2013, the Federal Financial Institutions Examination Council (FFIEC) posted a set of proposed guidelines for financial institutions to maintain compliance in the world of social media.   The document entitled “Social Media: Consumer Compliance Risk Management Guidance,” includes a number of specific recommendations for financial institutions that must protect customer information.  The FFIEC security requirements are key for GLBA compliance.

People + Information = RISK

As is often the case with security recommendations, information security policies are a key part of the equation.  In fact, one of the key “reputational risk” areas highlighted in the document concerns employee use of the social networking sites.   To quote from the official document:

“Financial institutions should be aware that employees’ communications via social media—even through employees’ own personal social media accounts—may be viewed by the public as reflecting the financial institution’s official policies or may otherwise reflect poorly on the financial institution, depending on the form and content of the communications. Employee communications can also subject the financial institution to compliance risk as well as reputation risk. Therefore, financial institutions should establish appropriate policies to address employee participation in social media that implicates the financial institution.”

After the comment period is complete, some version of these guidelines will be part of the official requirements. Accordingly, institutions will be expected to use the guidance in their efforts to ensure that their policies and procedures provide oversight and controls commensurate with the risks posed by their social media activities.

While these requirements are for financial institutions, the lessons are valid for every organization.  Studies show that 80% of employees access some type of social networking sites at work.  And where there are people and information together – there is risk.

Sample Social Media Security Policies

Does your organization have Social Media Acceptable Use Policies in place?  The PolicyShield Security Policy Subscription includes sample documents including Acceptable Use of Social Networking, which provides policies for safe use of online communities and social sites.  An additional sample, Corporate Use of Social Networking provides policies for organizations that are actively using social media to engage customers.  Don’t reinvent the wheel!  We have incorporated the latest social media risks into our standard security policy templates.


The Six Pillars of Personnel Security Policy

The insider threat is often discussed among the top information security risks facing organizations.  In fact, for the first time in seven years of doing the study, the 2012 Ponemon Data Loss survey listed internal mistakes by insiders is the number one cause of data breaches.  What is an insider threat?

This term is loosely used to describe current or former employees doing damage to the organization.  These can be malicious actions, such as stealing confidential information, or accidental, such as sending confidential information in an email attachment.  Within the world of information security policies, risks involved personnel are addressed with the Personnel Security Policy.

Challenges of Personnel Security

Personnel security is an extremely challenging area of security.  In order to function, an organization must allow access to sensitive data.  But in an instant, a trusted employee can become an attacker.  A recent court ruling involving stolen corporate data by a former employee is a perfect illustration.

In short, the court ruled that since the employee had legitimate access to the information at the time it was taken, they could not be prosecuted under state law or federal anti-hacking laws.  It was clear that the employee violated written security policy.  But it wasn’t clear that this constituted a criminal act under current laws.

On the surface, this would seem like a death-blow to the entire notion of having information security policies.  But the situation is complicated, because not all policy violations are criminal acts.   For example, one piece of information that was not revealed in the court case could have been critical – did the employee sign a non-disclosure agreement (NDA)?  If stealing confidential information does not constitute “hacking” in the eyes of the law, would violation of an NDA made any difference?  In any case, the entire episode is a good chance to look at the entire area of personnel security.  While firewalls and intrusion detection and malware get much of the spending, the cases always come down to people.

The Objectives Personnel Security

Before diving into the details, what are the high-level objectives of a personnel security policy?  Generally, there are two.  The first is to protect sensitive information by securely managing the “life-cycle” of employment.  Generally, the life-cycle has three phases – per-employment, during employment, and post-employment.  (For example, the ISO 27002 Standard uses this breakdown.)  But another important objective of a personnel security policy is to establish key governance points regarding information security.  In short, the organization wants to make sure that the rest of their security policies are enforceable.  This means taking proper steps to educate employees on both general information security requirements as well on organization specifics such as how to report an information security incident.  This second set of governance controls are most often overlooked in weak personnel security policies.

Core Elements of Personnel Security

So what are key areas that should be covered in a personnel security policy to best protect the organization?  By analyzing a combination of best practices, real incidents and regulatory requirements, several key areas jump out as critical. While there are a lot of elements to personnel security, we choose to refer to these as the “Six Pillars”.

Pillar 1:  Screening

Screening is the process of verifying a prospective employee’s credentials and suitability for the job.  Most often this is in the form of a background check.  The general idea is to make sure that former criminals are not hired or placed in positions of trust within the organization.  But employee screening can take on many different levels, depending on the nature of the organization and the position being screened.  Other example security policies may require a credit check or emotional stability test, or a check with references at previous employers.  Many insiders who commit crime have a history of human resources issues at current a previous employers.

Pillar 2: Contracts

This pillar is less obvious, but just as important when it comes to governance and the ability to take  action against employees who violate security policies and also commit crimes.  Controls related to contracts include employment agreements, non-compete agreements, non-disclosure agreements and intellectual property agreements.  Contracts are designed to protection intellectual properly from being stolen or lost.

Pillar 3: Security Policy Acknowledgement

Every employee or contractor with access to information must be made aware of the information security policies that apply to them.  In most organizations, this includes a high-level “Code of Conduct” as well as acceptable use policies such as Internet Acceptable Use.   But sometimes ignored is this key governance piece:  Making certain that employees formerly acknowledge that they have read and understood the written policies.  While this control is rarely called out within security regulations or frameworks, it is critical for policy enforcement.   Many court cases have gone the way of employees who were fired for policy violations, but claimed ignorance of the policies.  Without a written acknowledgement, few organizations can defend against the claim of being unaware of policies.

Pillar 4: Security Education

One of the most often ignored aspect of personnel security is awareness and education. Employees must be trained on basic information security principles so they can recognize common threats such as phishing attacks.  Study after study has demonstrated that human error is at the root cause of a majority of data breaches.  In addition to basic security education, employees should also be trained on the information security policies of the organization.  (See Pillar 3)

Pillar 5: Monitoring

Although employees are by definition trusted by the organization, their behavior still must be monitored at some level.  The type and level of monitoring depends on many factors, including the sensitivity of the data being used, the overall security posture of the organization, or even government requirements.  At a minimum, the organization should monitor all security-related user activity on systems.  Many organizations choose to monitor internet and web traffic.  Whatever the security posture on monitoring, it is best to inform the employees on how they are being monitored.   The disclaimer of “no expectation of privacy” generally applies when using corporate resources.  But if that policy is not communicated to employees, legal trouble is possible in any attempts to use the the information for sanctions.

Pillar 6:  Termination Procedures

The final essential component of personnel security is having proper termination procedures in place and enforced.  Once an employee is no longer employed (or has indicated that they are going to leave), both logical and physical access must be terminated.  In addition, the exit process usually involves the return of organizational property such as laptops or access badges. There is a reason that termination procedures are required in nearly every information security regulatory framework.  In many cases former employees have been able to access their employer’s network – either via their own login ID or a shared ID that was created – and steal data or plant malicious software.

Other Resources

For those interested in more details regarding insiders threats, the Insider Threat Center at Carnegie-Mellon has publish numerous research papers that are freely available.  At Information Shield, we have incorporated most of these results into our sample security policies within the PolicyShield Security Policy Subscription.  For those who need to develop Personnel Security Policies, Information Security Policies Made Easy contains over 80 specific sample security policies just on personnel security alone.


Older posts «