As I wrote the security policy
It so happened that over the past few years I had the opportunity to write “from scratch” several times and implement information security policies in different companies, as well as observe how our colleagues in the shop do. In the proposed note, an attempt is made to summarize the experience gained and mention the rake, which left the most noticeable mark on the author's forehead. Immediately make a reservation that the following discussion will not focus on recommendations for protection against viruses or the choice of a strong password, but mainly about the logic, structure and purpose of such documents.
Variants of the answer may be different: fulfillment of the order of wise leadership, formal compliance with any external requirements, a desire to introduce mysterious "best practices" or simply a long overdue need to formalize the company's security rules (and not explain them in words every time).
We will assume that the security policy is the fixation of internal agreements between the functions of IT, information security and key users of business on what needs to be protected. There are several important topics under this simple formulation, including - prioritization, resource planning, agreement on practical implementation methods and control mechanisms (not) done. Let me remind you that we need not only to write a beautiful and correct policy, but also to achieve its implementation in practice.
')
In other words, the security policy establishes “uniform rules of the game”, is a guideline for all involved comrades, at the same time closes a number of formal requirements of the law and any external auditors, and also pleases the management with obvious evidence of the turbulent activities of the security department.
During the development of a security policy, it is extremely important to imagine the target audience. It is unlikely that we will be able to write a document equally suitable for the deputy chairman of the board, the head of the system administration department and an ordinary warehouse employee.
Usually, a presentation is prepared for the management (if you need to propose an action plan, solutions to the problem or inform about the result), therefore the structure of such a document is no different from the materials of other functional divisions. When it comes to safety rules for users, this is either a reminder on the page with a field for a signature after review, or materials for a distance learning system with beautiful pictures.
The target audience of the security policy is the managers and specialists of the IT service, the department for information security, the project office, key users and all other office dwellers, one way or another connected with the development, implementation and support of IT systems. Also, do not forget about the contractors and consultants who perform similar functions commissioned by our organization.
Accurate understanding of the target audience provides an excellent filter that influences which requirement to include in the security policy, and which - to drop; what wording to use to make this requirement work later. We illustrate this with a classic example with a password policy, along with ignoring possible objections to the quality of the required password:
Terms and definitions are one of the most important sections of our future policy. Good definitions are needed in order to give the reader (and by part-performer) a clear idea of the subject and make all the requirements put forward more clear in the text.
Definitions are easiest to take from legislation, standards or Wikipedia, but not the fact that they will be easy to read and respond to the characteristics of the organization for which we are developing a security policy. Therefore, it may be easier and better for key terms to write definitions on their own, referring to the sources mentioned above.
Practice shows that after several iterations of policy development, the glossary contains about 30-40 vital terms, including as well as highly specialized concepts (two-factor authentication, for example), and more universal entities (server, mobile computer, etc.), if they have not been previously defined in other policies or the organization’s general glossary.
Having dealt with the terms and definitions, it's time to look at the structure of the content of the document. The generally accepted approach is to take the composition of sections of the international standard ISO 27002 (or its corresponding GOST) or be based on any other source that comprehensively describes the basic principles of information security. It is clear that the structure and the content of the sections can vary greatly depending on the profile of our organization.
As an example, we will list the minimum set of topics that it makes sense to reflect in the policy being developed:
Obviously, the list of sections can be divided into smaller parts and supplemented with other important topics, but one of the advantages of the above option is precisely the minimal and sufficiency.
Well, one more important detail from the semantic point of view is that the security policy can be descriptive (“as is”, the current state is fixed) or directive (“to be”, what should be done). The directory variant seems to be more readable and logical for later use, since usually “already done” is much less than “will be done”.
It is good if the organization has a department for maintaining reference information or other guys who help in the difficult task of developing regulatory documents. If they are not there, it would be good not to forget about a single repository for drafts and already approved policies, the procedure for assigning versions and, of course, the standard template for the document. All of this may seem a little superfluous at first, but it will be of great help in developing subsequent versions of the policy.
It is recommended to give the selected colleagues a link to the draft document and suggest asking questions about the results of the reading in order to get immediate feedback. If a freshly written policy is perceived with understanding, for example, by a stubborn system administrator Sergei, a veteran of the regime-secret department Igor Stepanovich and a proud PMI certificate holder Ivan, then we can assume that the most rigorous quality control of the document has been passed.
And one moment. As soon as the main work on the policy is completed, we are waiting for a spell check and punctuation rules. Surely in the organization there will be at least one employee who knows them better than you and will not miss the chance to gladly tell everyone about the errors found in the text.
As you know, the process of agreeing on any regulatory document is a separate song, starting with the verbal battles for some inconvenient wording and ending with a quest for offices to get the necessary set of signatures. Note that indirectly, the complexity of this stage affects the frequency of updating the security policy and, consequently, the practical benefits of the written text. Since no one wants to take part in this action once again, the document is often outdated before it can be fully coordinated and approved.
In order to reduce the senseless gestures at this stage and simplify the procedure for agreeing on a security policy, the following scheme was proposed and then successfully tested:
Well, separately, we note that the list of coordinating persons should include the heads of all departments whose employees will fulfill the requirements described in the policy. As a rule, it will be IT, security guards, lawyers and personnel officers.
When developing a security policy, we must always keep in mind the need for its subsequent implementation. The following success criteria can be proposed:
Consideration of the exception handling procedure is beyond the scope of this material, but we note the most important. Having a universal decision-making mechanism in situations that are not described in or contradicting the security policy (if it is impossible to eliminate the violations) is a very useful tool for managing security.
Once again we briefly list the typical problems that can be encountered when writing a security policy:
And, of course, the author will be glad to any questions and comments that may arise after reading this note.
And why, exactly?
Variants of the answer may be different: fulfillment of the order of wise leadership, formal compliance with any external requirements, a desire to introduce mysterious "best practices" or simply a long overdue need to formalize the company's security rules (and not explain them in words every time).
We will assume that the security policy is the fixation of internal agreements between the functions of IT, information security and key users of business on what needs to be protected. There are several important topics under this simple formulation, including - prioritization, resource planning, agreement on practical implementation methods and control mechanisms (not) done. Let me remind you that we need not only to write a beautiful and correct policy, but also to achieve its implementation in practice.
')
In other words, the security policy establishes “uniform rules of the game”, is a guideline for all involved comrades, at the same time closes a number of formal requirements of the law and any external auditors, and also pleases the management with obvious evidence of the turbulent activities of the security department.
Dear readers
During the development of a security policy, it is extremely important to imagine the target audience. It is unlikely that we will be able to write a document equally suitable for the deputy chairman of the board, the head of the system administration department and an ordinary warehouse employee.
Usually, a presentation is prepared for the management (if you need to propose an action plan, solutions to the problem or inform about the result), therefore the structure of such a document is no different from the materials of other functional divisions. When it comes to safety rules for users, this is either a reminder on the page with a field for a signature after review, or materials for a distance learning system with beautiful pictures.
The target audience of the security policy is the managers and specialists of the IT service, the department for information security, the project office, key users and all other office dwellers, one way or another connected with the development, implementation and support of IT systems. Also, do not forget about the contractors and consultants who perform similar functions commissioned by our organization.
Accurate understanding of the target audience provides an excellent filter that influences which requirement to include in the security policy, and which - to drop; what wording to use to make this requirement work later. We illustrate this with a classic example with a password policy, along with ignoring possible objections to the quality of the required password:
The password must contain at least 6 characters, including at least one capital letter and one number.and alternative:
It is necessary to implement the verification that the password chosen by the user contains at least 6 characters, including at least one capital letter and one number.The first statement is perfect for user security rules, and then rather in a reference (rather than prescriptive) order, but the second one can be perfectly implemented as a technical security requirement for an IT system.
Before you argue
Terms and definitions are one of the most important sections of our future policy. Good definitions are needed in order to give the reader (and by part-performer) a clear idea of the subject and make all the requirements put forward more clear in the text.
Definitions are easiest to take from legislation, standards or Wikipedia, but not the fact that they will be easy to read and respond to the characteristics of the organization for which we are developing a security policy. Therefore, it may be easier and better for key terms to write definitions on their own, referring to the sources mentioned above.
Practice shows that after several iterations of policy development, the glossary contains about 30-40 vital terms, including as well as highly specialized concepts (two-factor authentication, for example), and more universal entities (server, mobile computer, etc.), if they have not been previously defined in other policies or the organization’s general glossary.
Law and order
Having dealt with the terms and definitions, it's time to look at the structure of the content of the document. The generally accepted approach is to take the composition of sections of the international standard ISO 27002 (or its corresponding GOST) or be based on any other source that comprehensively describes the basic principles of information security. It is clear that the structure and the content of the sections can vary greatly depending on the profile of our organization.
As an example, we will list the minimum set of topics that it makes sense to reflect in the policy being developed:
- The organizational structure of information security and the objects of protection (who protects what and why - about risks, classification of assets, distribution of roles and responsibilities).
- Access control (in fact, the rules of interaction of participants in the process and objects of protection).
- Change management (about how our systems should safely and controlledly go from one state to another).
- Monitoring and auditing (methods for assessing and confirming the current state of security).
Obviously, the list of sections can be divided into smaller parts and supplemented with other important topics, but one of the advantages of the above option is precisely the minimal and sufficiency.
Well, one more important detail from the semantic point of view is that the security policy can be descriptive (“as is”, the current state is fixed) or directive (“to be”, what should be done). The directory variant seems to be more readable and logical for later use, since usually “already done” is much less than “will be done”.
Who are the judges?
It is good if the organization has a department for maintaining reference information or other guys who help in the difficult task of developing regulatory documents. If they are not there, it would be good not to forget about a single repository for drafts and already approved policies, the procedure for assigning versions and, of course, the standard template for the document. All of this may seem a little superfluous at first, but it will be of great help in developing subsequent versions of the policy.
It is recommended to give the selected colleagues a link to the draft document and suggest asking questions about the results of the reading in order to get immediate feedback. If a freshly written policy is perceived with understanding, for example, by a stubborn system administrator Sergei, a veteran of the regime-secret department Igor Stepanovich and a proud PMI certificate holder Ivan, then we can assume that the most rigorous quality control of the document has been passed.
And one moment. As soon as the main work on the policy is completed, we are waiting for a spell check and punctuation rules. Surely in the organization there will be at least one employee who knows them better than you and will not miss the chance to gladly tell everyone about the errors found in the text.
Consent and reconciliation
As you know, the process of agreeing on any regulatory document is a separate song, starting with the verbal battles for some inconvenient wording and ending with a quest for offices to get the necessary set of signatures. Note that indirectly, the complexity of this stage affects the frequency of updating the security policy and, consequently, the practical benefits of the written text. Since no one wants to take part in this action once again, the document is often outdated before it can be fully coordinated and approved.
In order to reduce the senseless gestures at this stage and simplify the procedure for agreeing on a security policy, the following scheme was proposed and then successfully tested:
- The development of the document as consultants involves key employees of the divisions through which coordination will take place. This emphasizes the feeling of their involvement in the process and reduces the risk of not implementing the already adopted policy.
- At the management level, it is generally agreed that the IT and IB policies will be coordinated electronically and the fact that the document is approved is the publication of the next version of the policy on the corporate portal. Paper versions are signed in the background if necessary.
- The approval process is translated into the mode “if we don’t have any comments by a certain date, we consider it agreed”, and objections and amendments received late are included in the next version of the document. Along the way, this approach disciplines well all participants in the process.
Well, separately, we note that the list of coordinating persons should include the heads of all departments whose employees will fulfill the requirements described in the policy. As a rule, it will be IT, security guards, lawyers and personnel officers.
Successful implementation
When developing a security policy, we must always keep in mind the need for its subsequent implementation. The following success criteria can be proposed:
- The target audience is familiar with the text of the document and understands the requirements set out in the policy.
- Most of the policy requirements are implemented in practice, and for the outstanding requirements, an exception handling procedure is implemented.
- It is possible to objectively and independently verify the previous two statements.
Consideration of the exception handling procedure is beyond the scope of this material, but we note the most important. Having a universal decision-making mechanism in situations that are not described in or contradicting the security policy (if it is impossible to eliminate the violations) is a very useful tool for managing security.
About rake (instead of the conclusion)
Once again we briefly list the typical problems that can be encountered when writing a security policy:
- “Is it really about what?” - demands that do not find their reader (performer) or are turned nowhere.
- “Some sort of turbidity ...” - vague terminology, incomprehensible formulations of policy requirements.
- “Complete crap!” - Difficulties in coordination and implementation due to active opposition from key users whose opinions were not taken into account.
- “Are the documents written like this ?!” - Ignoring the rules of design, stylistic, spelling and punctuation errors.
And, of course, the author will be glad to any questions and comments that may arise after reading this note.
Source: https://habr.com/ru/post/275811/
All Articles