An Example Framework for an Information Security Policy

22 October 2021 by mikevarian Security

Introduction

It has long been good practice for organizations to establish and maintain an Information Security Policy, and with each passing year they become increasingly important. As technology become ever more useful and pervasive, it also becomes more complex to use securely, and more difficult for employees to know what is expected of them and what they can do to ensure security. At the same time, insurance companies, regulations, and new laws are demanding more of organizations and businesses to protect sensitive data.

We offer this framework to assist in your establishment of a new information security policy, or assist in your review of an existing policy. Information security policies are an overlap of technical, operational, and legal considerations. For this reason, while NorthSky is able to offer perspective in the form of technical consulting, legal and operational input and review is important.

In addition to this framework, your cyber-liability insurance provider may offer their own guidance, examples, and requirements. We highly recommend involving your insurer in your annual policy review. In particular, some providers have very strict requirements for how you respond to a suspected incident in order for that incident to be covered.

Why this isn't a template

While it may check a box on a compliance questionnaire, there is no such thing as an effective one-size-fits all policy template. The best and most useful policies are those which are highly personalized for your organization: how you operate, what systems you use, how you store and transmit data, and what specifically you need to protect the most.

In other words, while it may be more work up-front to develop a personalized policy, when done properly it pays dividends in the form of organizational buy-in and tangible security improvements.

Information Security Policy Example Framework

Purpose

General into of the policy and its objectives.

Scope

Broad definition of who this policy applies to, and what types of systems, data, networks, environments, activities, etc that the policy covers.

Classifications

Classifications are critical in defining policy that is practical and users will be able to follow. This section defines different classification levels for types of data, systems, and credentials as appropriate for your organization.

A policy that demands onerous and arduous practices throughout every bit of a user's work is a policy that won't be followed. It is much better to start with a minimal policy that focuses on the most sensitive data and that everyone can follow and buy into, than an overly broad policy that is so oppressive nobody follows it.

For example, a password to a bank account is much more important to protect than a password for a Netflix login. These should be classified separately with the rest of the policy setting proportional requirements for each classification. In the simplest sense, a bank account password is Sensitive, and the Netflix password Non-Sensitive. You probably want to prohibit staff from putting Sensitive passwords on post-it notes stuck to their monitor, but for Non-Sensitive passwords maybe that's acceptable if it helps someone be more efficient.

Classifications should also take into consideration specific regulatory requirements that might apply to your organization. HIPAA, PCI, GDPR each provide their own data classifications and scope, as well as specific requirements that must be in place for that data. All of that should be incorporated into the information security policy.

An example set of classification tiers:

  • Sensitive/Restricted: card data, PHI, social security numbers, banking information, passwords to financial systems, master passwords to password managers, system administrator passwords, payroll systems.
  • Confidential: internal or customer data which is bound by contract to be kept confidential.
  • Unrestricted or Non-Sensitive: Information and accounts that are not sensitive or confidential, but are also not public. By nature, if these were compromised the resulting fallout would be minimal.
  • Public: Information and accounts that can be freely shared without protection.

Minimum Access Policy

It is generally a good practice to define an overarching minimium access policy. A minimum access policy is a statement that all users, access, accounts, permissions should be set up with the minimum access that is needed for the duty or function to be performed. If a user doesn't need access to something as part of their job, even if they could be trusted with it, they should not be granted access to that data.

An implemented minimum access policy reduces the chances of accidental data exposure in the course of doing business, and also can minimize the damage in the event of a compromise.

Secure Handling of Information

Based on the classification, this section defines how information should be properly stored and transmitted:

  • Designed and prohibited storage locations: which company systems, drives, cloud services can and can not be used to store each classification of data.
  • Designated and prohibited methods for transmitting data: As detailed as necessary, how each type of information can be received from others and transmitted to others in an appropriately secure way.
  • How data and systems are to be securely deleted or destroyed when they are no longer needed. This can include both virtual deletion and physical destruction or retirement.

It can be helpful here to define categories of systems to reference in other policy requirements. i.e. Approved password managers, or secure company cloud drives.

Password Policy

For each classification of password, define:

  • Where and how passwords are to be stored. (Important)
  • Multi-factor or 2-factor authentication requirements. (Important)
  • Uniqueness vs. reuse requirements: Whether or not a password must be unique and not used for any other systems, and what that means to be unique. (Important)
  • Minimum password length and complexity requirements.
  • Password composition requirements, such as prohibited words (don't use the company name, seasons, birthdays which are easy to guess).
  • Sharing requirements: If and how that password can be shared with others.
  • Aging / Rotation: When and if a password needs to be changed based on its age or other factors like suspicion of compromise, employee turnover, etc.
  • Security questions: How to handle and set answers for security questions, given how easy it is to find common answers via public information like maiden names and elementary schools.
  • What to do in the event that a limitation of some 3rd party system prevents a user from meeting all the requirements of this policy.

In particular regarding uniqueness: It is strongly recommended to enforce uniqueness on sensitive passwords, ensuring that they are in no way the same or similar to any other password (sensitive or otherwise). If one system is compromised, often passwords are extracted and then the attacker will test to see what other accounts those passwords will get them into. A unique password will limit their ability to compromise additional accounts. Also if a sensitive password is the same as a non-sensitive password, protections for that password are bypassed.

Out of Band Authorization Policy

Specify what types or categories of actions, transactions, disclosures, and disbursements that require an "out-of-band" (OOB) confirmation in the event they are initiated electronically. Out-of-band authorization means taking communication outside of the channel in which it was received to confirm the request was valid and that the original communication can be trusted.

For example, if an employee emails the payroll administrator requesting that their paychecks be deposited to a different bank account. An OOB policy might require that payroll administrator to confirm the change verbally, over the phone, or via text message before processing it.

This is an important control to help protect against the risks of impersonation in spear-phishing/whaling attacks - where an attacker sends an email appearing to be legitimate with their own information. Example situations where an OOB policy may be most warranted:

  • Paycheck bank deposit changes.
  • Any wiring or transferring of money to an external bank account.
  • Any disclosure of sensitive information, such as W2s or paystubs, financials, or tax returns.
  • Payment of invoices which were not expected or previously approved.

Network Policy

Requirements for how networks must be configured and protected, such as use of firewalls, certain network security technologies, VPNs/remote access.

Computer Security Policy

Requirements for how company computers must be configured and maintained: antivirus, patching, passwords, administrative access, disk encryption, approved applications, screen locks, remote access software.

Remote Access Policy

Requirements around under what circumstances remote access is allowed, by whom, and through what method or procedure.

Physical Security Policy

Requirements related to locking doors and cabinets, security alarms, cameras, clean desk policy.

Acceptable Use Policy

Definition of acceptable ways that company systems, emails, networks, software, and devices are allowed to be used and what is prohibited.

Common areas to cover here are social media usage, video games, pornography, personal shopping/email, hateful or abusive activity, etc. It can be helpful to pull examples from other companies to develop an AUP.

Personal Device Policy

In what way personal devices are allowed to be used in the course of work, if they are allowed to access company information, how the devices must be maintained, configured, and secured. While it is the employee's device, this spells out their responsibility in safeguarding company information and continuing to follow company policy in use of that device for work purposes.

Some organizations may also add a Work From Home section to address home-specific concerns such as:

  • Network/internet speed, reliability, and responsibility requirements.
  • How to keep company technology safe and secure from housemates, guests, kids, and even pets.
  • Use of proper surge protectors.
  • Whether or not company devices and materials need to be locked or secured in any way.
  • Allowed/prohibited use of company technology when working at home (or perhaps just a reminder that the Acceptable Use Policy continues to apply when working from home).
  • Who is allowed/not allowed to use company technology located at home.

Important to consider here what happens if an employee's personal device is lost or stolen, if a family member or friend of that employee gets access to their device, or what happens if the employee departs their employment on unfriendly terms and they may be uncooperative.

Vendor/Contractor Requirements

Any requirements in the selection and use of vendors or independent contractors.

For example, vendor systems or services dealing could be mandated to support MFA, a certain type of logging, or maintain certain security/compliance certifications.

Data Retention Policy

What, if any, data needs to be explicitly held for a certain period of time and/or to be securely deleted upon reaching a certain age or in event of a certain action occurring. Data retention may be dictated by certain regulatory, industry, or tax requirements - and also insurance companies may be interested to know how much old data (which can translate into liability) you hold onto.

For example: if you have a customer, client, or member who you are no longer working with, do you have a policy on when you delete that information? For longtime clients or members who have been with you for years, do you keep all information related to them for forever or do you limit that history at some point?

Backup Policy

Definition of minimum requirements for backup of company data and systems.

Suspicion of Incident

What is to happen when there is any suspicion of an incident resulting in data compromise, destruction, disclosure, or policy violation - even if accidental.

Incident Response

What is to happen in the event of an incident. It is highly advisable to ensure that this is in-line with any insurance requirements so a response effort doesn't inadvertently exclude coverage for a claim. Some organizations will also include their legal counsel as part of the initial response contacts.

Disaster Recovery

Response and recovery plan for an event that interrupts or severly inhibits operations. Common incidents to consider:

  • Outages at key 3rd party vendors, systems, services
  • Website outages
  • Power outages
  • Hazardous weather
  • Illness or incapacitation of key personnel
  • Key system or equipment failure

Regular Review

Define how often and in what manner this policy or these policies are to be reviewed and kept current.

Designation

Designation of who is ultimately responsible for maintaining these policies and overseeing their implementation and enforcement.

Final Thoughts

Often an Information Security policy becomes a set of individual policies, or even blends in with your normal operational procedures. In this case, it is good to make sure that the policies all fit together in a hierarchy and do not conflict with one another. Often over time, individual policies and procedures have a risk of each setting requirements on the same area. This becomes confusing if someone has to look in multiple places for the whole picture, or if policies start to diverge and disagree with one another as they get updated by different groups at different times.

Related posts