Expertly Documenting Your Security – Managing Policies, Standards, Baselines, Guidelines and Procedures

In my previous blog about what “security” actually means, I explained the two types – holistic and contextual – and why they matter to your business. Continuing on our journey, I’ll now dig a bit deeper and classify essential levels of security every company should be aware of.
Let’s first address security documentation. What does it mean, what are the use cases and what document hierarchy is appropriate? With a number of misconceptions around documentation (with most coming from the lack of a clear vision of the need and use of said documents), today’s post is dedicated to this often-neglected topic.


Pre-documentation – Three things to keep in mind

Before anyone starts writing any type of documentation, he or she should clearly define the use case and the goal this documentation aims to achieve. Whether you want to document the steps of a procedure in order to re-create a task later on, want to inform readers, or are stating a plan for the future through writing rules, policies and requirements – it’s all reflected largely in the document’s structure and wording.

Another thing to consider is the audience. When creating a procedure for a more technical crowd, using technical language and depending on the expertise of the reader to understand the steps is completely fair. On the other hand, this approach fails when creating a security awareness document with the purpose of educating non-IT staff.

A third factor to note when documenting security is structure. You have to know which preexisting documents set necessary requirements, and which act as guidelines to help you meet those necessary requirements in your own documentation.

Like with laws and regulations, there is always a clearly defined hierarchy of documentation, where one law precedes another – or one is an executive order and the other is a high-level policy. Similarly, one approach for your security documentation is to introduce a tiered hierarchy – gluing together the goal, audience and structure of your documentation.


Tier 1 –Addressing needs and desires

To successfully shape an information security program, senior management must propagate their information security vision and strategy to set the course for the company’s security efforts. Without it, all activities will become haphazard and ineffective due to a lack of direction. Setting clear needs also helps determine the company’s priorities.

Usually the top security document within a company is the Information Security Policy, which reflects the organization’s security strategy, sets the ground rules and defines the responsibilities of everyone involved. It is the core of all activities within the company and targets every employee, contractor and even third parties engaged in company business.

As it reflects the entire company’s security needs, the language must be easy to understand for technical and non-technical people alike; it outlines the “musts” and “mustn’ts” while being technology-independent, avoiding frequent changes. After all, nobody expects the vision and strategy of a company to change frequently. An example of a good statement from an Information Security Policy is, “The company’s equipment must be protected from unauthorized access”.
body-picture.jpg


Tier 2 – Adhering to strict requirements

The next level of documentation is the Security Standard, which shows how to fulfill the needs stated in the policy by providing more details. An example of a clause from the Security Standard (related to the previously mentioned example) is, “An automatic logoff mechanism is enabled for every employee PC and activates after 5 minutes of inactivity”.

It’s important to note the Security Standard is also independent from the technology stack. Standards should avoid being tightly coupled with technical solutions, to maintain value and fulfill the predefined goal even when technology changes.

A special case for a Security Standard is a Security Baseline. This document details the minimally allowed set of requirements for the use case. We could say our baseline requires logoff to happen after 10 minutes of inactivity – whereas at the same time, have standards for a highly confidential environment where only 5 minutes of inactivity triggers the logoff procedure. That way, we can make minimal changes and still be able to address special needs and environments.


Tier 3 – Stating how-to’s and recommendations

The last level of security includes the Security Procedure and Security Guideline. The Procedure provides technical information on how to actually implement the standard to meet the goal. Rather than explaining the company’s vision and relation to a specific security requirement, the Security Procedure concentrates on outlining technical information and necessary steps. (The reasoning behind the Procedure is not to be emphasized here, as the goal is to have clear, actionable technical information.) Continuing with our example, we could have a Procedure that states how to configure Microsoft Windows to log off a user after a specified inactivity time.
A Guideline on the other hand is a soft recommendation that helps the company follow the policy and adhere to the requirements from the standard. This type of document shows the most flexibility and addresses what should be done or is recommended. An example of a guideline would be, “Employees should either lock their workstation when leaving the desk or perform a logout procedure from remote servers when finished working on them”.


Repository – Make it accessible

Lastly, it’s important to make the company’s security documents available for the targeted audience. While often omitted, it’s pointless to have a document that’s never accessed, read and/or updated. There are a number of approaches on how to store and maintain the documents – some implement advanced versioning systems and keep track of all references, updating when necessary. Others simply allow quick collaboration for swift updates. When making the decision on which to use, it’s important to take into account the company’s security culture – whether it’s flexible or not – and existing collaboration techniques. After all, the most important goal is to have the documents accessible to everyone involved – to share information and keep data up to date.

We can help you overcome these security challenges. Luxoft helps companies structure and build Information Security frameworks adhering to best practices around security documentation, security process design and security management. Over the years, Luxoft InfoSec has provided consultancy and advisory services to peers from a number of industries, gaining knowledge and experience that is now being replicated, adapted and contextualized for future customer needs. Together with our deep industry focus, we deliver holistic and contextual InfoSec services – what’s necessary for businesses to survive in this digital age.

For more information, contact us by clicking here.

Stay tuned for our next blog, which will focus on security culture and how it influences companies as a whole.

Marcin Swiety
InfoSec Director, Luxoft Digital

Marcin Swiety

A seasoned Information Security professional dedicated to business and delivery management in cybersecurity space. He has built and managed internal and external Information Security Services in areas like Data Center, Infrastructure, Network, Outsourcing and Software. He is a white-hat expert and decorated cybersecurity veteran, holder of CISSP, CISM, CISA, CEH, WCSD and ITIL certifications. He is passionate about how InfoSec can play a business enabler role for the digital transformation era.

Check all posts by Marcin Swiety

Related content

You hear it in the news – security breaches and new information-stealing cyberattacks are becoming more and more common. The year 2016 had a 556% increase from 2015, with over 4 billion records leaked. But the total for 2017 is already over a stagger...