An Information Security Policy is the cornerstone of an Information Security Program. It should reflect the organization’s objectives for security and the agreed upon management strategy for securing information.
In order to be useful in providing authority to execute the remainder of the Information Security Program, it must also be formally agreed upon by executive management. This means that, in order to compose an information security policy document, an organization has to have well-defined objectives for security and an agreed-upon management strategy for securing information. If there is debate over the content of the policy, then the debate will continue throughout subsequent attempts to enforce it, with the consequence that the Information Security Program itself will be dysfunctional.
[ Also see CSOonline.com’s IT Security Management: The Basics ]
There are a plethora of security-policy-in-a-box products on the market, but few of them will be formally agreed upon by executive management without being explained in detail by a security professional. This is not likely to happen due to time constraints inherent in executive management. Even if it was possible to immediately have management endorse an off-the-shelf policy, it is not the right approach to attempt to teach management how to think about security. Rather, the first step in composing a security policy is to find out how management views security. As a security policy is, by definition, a set of management mandates with respect to information security, these mandates provide the marching orders for the security professional. If the security professional instead provides mandates to executive management to sign off on, management requirements are likely to be overlooked.
A security professional whose job it is to compose security policy must therefore assume the role of sponge and scribe for executive management. A sponge is a good listener who is able to easily absorb the content of each person’s conversation regardless of the group’s diversity with respect to communication skills and culture. A scribe documents that content faithfully without embellishment or annotation. A good sponge and scribe will be able to capture common themes from management interviews and prepare a positive statement about how the organization as a whole wants its information protected. The time and effort spent to gain executive consensus on policy will pay off in the authority it lends to the policy enforcement process.
Good interview questions that solicit management’s opinions on information security are:
* How would you describe the different types of information you work with?
* Which types of information do you rely on to make decisions?
* Are there any information types that are more of a concern to keep private than others?
From these questions, an information classification system can be developed (e.g. customer info, financial info, marketing info, etc), and appropriate handling procedures for each can be described at the business process level. (Editor’s note: See also Jason Stradley’s provocative take on data classification and related issues.)
Of course, a seasoned security professional will also have advice on how to mold the management opinions with respect to security into a comprehensive organizational strategy. Once it is clear that the security professional completely understands management’s opinions, it should be possible to introduce a security framework that is consistent with it. The framework will be the foundation of the organization’s Information Security Program, and thus will service as a guide for creating an outline of the information security policy.
[ Also see CSOonline.com’s Security and Business: Communication 101 ]
Often, a security industry standards document is used as the baseline framework. For example, the Security Forum’s Standard of Good Practice (www.securityforum.org), the International Standards Organization’s, Security Management series (27001, 27002, 27005, www.iso.org), and the Information Systems Audit and Control Association’s Control Objectives for Information Technology (CoBIT, www.isaca.org). This is a reasonable approach, as it helps to ensure that the policy will be accepted as adequate not only by company management, but also by external auditors and others who may have a stake in the organization’s Information Security Program.
However, these documents are inherently generic and do not state specific management objectives for security. So they must be combined with management input to produce the policy outline. Moreover, it is not reasonable to expect the management of an organization to change the way the organization is managed in order to comply with a standards document. Rather, the information security professional may learn about good security management practices from these documents, and see if it is possible to incorporate them into the current structure of the target organization.
It is important that security policy always reflect actual practice. Otherwise, the moment the policy is published, the organization is not compliant. It is better to keep policy as a very small set of mandates to which everyone agrees and can comply than to have a very far-reaching policy that few in the organization observe. The Information Security Program can then function to enforce policy compliance while the controversial issues are simultaneously addressed.
Another reason that it is better to keep policy as a very small set of mandates to which everyone agrees is that, where people are aware that there are no exceptions to policy, they will generally be more willing to assist in getting it right up front to ensure that they will be able to comply going forward. Once a phrase such as «exceptions to this policy may be made by contacting the executive in charge of….» slips into the policy itself or the program in which it is used, the document becomes completely meaningless. It no longer represents management commitment to an Information Security Program, but instead communicates suspicion that the policy will not be workable. A security professional should consider that if such language were to make its way into a Human Resources or Accounting policy, people could thus be excused from sexual harassment or expense report fraud. A security professional should strive to ensure that information security policy is observed at the same level as other policies enforced within the organization. Policy language should be crafted in such a way that guarantees complete consensus among executive management.
For example, suppose there is debate about whether users should have access to removable media such as USB storage devices. A security professional may believe that such access should never be required while a technology executive may believe that technology operations departments responsible for data manipulation must have the ability to move data around on any type of media. At the policy level, the consensus-driven approach would produce a general statement that «all access to removable media devices is approved via a process supported by an accountable executive.» The details of the approval processes used by the technology executive can be further negotiated as discussions continue. The general policy statement still prohibits anyone without an accountable executive supporting an approval process from using removable media devices.
In very large organizations, details on policy compliance alternatives may differ considerably. In these cases, it may be appropriate to segregate policies by intended audience. The organization-wide policy then becomes a global policy, including only the least common denominator of security mandates. Different sub-organizations may then publish their own policies. Such distributed policies are most effective where the audience of sub-policy documents is a well-defined subset of the organization. In this case, the same high level of management commitment need not be sought in order to update these documents.
For example, information technology operations policy should require only information technology department head approval as long as it is consistent with the global security policy, and only increases the management commitment to consistent security strategy overall. It would presumably include such directives as «only authorized administrators should be provided access capable of implementing operating system configuration changes» and «passwords for generic IDs should be accessed only in the context of authorized change control processes.» Another type of sub-policy may involve people in different departments engaged in some unusual activity that is nevertheless subject to similar security controls, such as outsourcing information processing, or encrypting email communications.
On the other hand, subject-specific policies that apply to all users should not be cause to draft new policies, but should be added as sections in the global policy. Multiple policies containing organization-wide mandates should be discouraged because multiple policy sources make it more difficult to accomplish a consistent level of security awareness for the any given individual user. It is hard enough to establish policy-awareness programs that reach all in the intended community, without having to clarify why multiple policy documents were created when one would do. For example, new organization-wide restrictions on Internet access need not be cause to create a new «Internet Access» policy. Rather, an «Internet Access» section can be added to the global security policy. Another caveat for the security professional using the sub-policy approach is to make sure sub-policies do not repeat what is in the global policy, and at the same time are consistent with it. Repetition must be prohibited as it would allow policy documents to get out of sync as they individually evolve. Rather, the sub-documents should refer back to the global document and the two documents should be linked in a manner convenient for the reader.
Even while giving sub-policies due respect, wherever there is an information security directive that can be interpreted in multiple ways without jeopardizing the organization’s commitment to information security goals, a security professional should hesitate to include it in any policy. Policy should be reserved for mandates. Alternative implementation strategies can be stated as a responsibility, standard, process, procedure, or guideline. This allows for innovation and flexibility at the department level while still maintaining firm security objectives at the policy level.
This does not mean that the associated information protection goals should be removed from the Information Security Program. It just means that not all security strategy can be documented at the policy level of executive mandate. As the Information Security Program matures, the policy can be updated, but policy updates should not be necessary to gain incremental improvements in security. Additional consensus may be continuously improved using other types of Information Security Program documents.
Supplementary documents to consider are:
Roles and responsibilities — Descriptions of security responsibilities executed by departments other than the security group. For example, technology development departments may be tasked with testing for security vulnerabilities prior to deploying code and human resources departments may be tasked with keeping accurate lists of current employees and contractors.
Technology standards — Descriptions of technical configuration parameters and associated values that have been determined to ensure that management can control access to electronic information assets.
Process — Workflows demonstrating how security functions performed by different departments combine to ensure secure information-handling.
Procedures — Step by step instructions for untrained staff to perform routine security tasks in ways that ensure that the associated preventive, detective, and/or response mechanisms work as planned.
Guidelines — Advice on the easiest way to comply with security policy, usually written for non-technical users who have multiple options for secure information-handling processes.
What an Information Security Policy Includes
This leaves the question: what is the minimum information required to be included in an Information Security Policy? It must be at least enough to communicate management aims and direction with respect to security. It should include:
1. Scope — should address all information, systems, facilities, programs, data, networks and all users of technology in the organization, without exception
2. Information classification — should provide content-specific definitions rather than generic «confidential» or «restricted»
3. Management goals for secure handling of information in each classification category (e.g. legal, regulatory, and contractual obligations for security, may be combined and phrased as generic objectives such as «customer privacy entails no authorized cleartext access to customer data for anyone but customer representatives and only for purposes of communicating with customer,» «information integrity entails no write access outside accountable job functions,» and «prevent loss of assets»)
An Information Security Policy is the cornerstone of an Information Security Program. It should reflect the organization’s objectives for security and the agreed upon management strategy for securing information.
In order to be useful in providing authority to execute the remainder of the Information Security Program, it must also be formally agreed upon by executive management. This means that, in order to compose an information security policy document, an organization has to have well-defined objectives for security and an agreed-upon management strategy for securing information. If there is debate over the content of the policy, then the debate will continue throughout subsequent attempts to enforce it, with the consequence that the Information Security Program itself will be dysfunctional.
[ Also see CSOonline.com’s IT Security Management: The Basics ]
There are a plethora of security-policy-in-a-box products on the market, but few of them will be formally agreed upon by executive management without being explained in detail by a security professional. This is not likely to happen due to time constraints inherent in executive management. Even if it was possible to immediately have management endorse an off-the-shelf policy, it is not the right approach to attempt to teach management how to think about security. Rather, the first step in composing a security policy is to find out how management views security. As a security policy is, by definition, a set of management mandates with respect to information security, these mandates provide the marching orders for the security professional. If the security professional instead provides mandates to executive management to sign off on, management requirements are likely to be overlooked.
A security professional whose job it is to compose security policy must therefore assume the role of sponge and scribe for executive management. A sponge is a good listener who is able to easily absorb the content of each person’s conversation regardless of the group’s diversity with respect to communication skills and culture. A scribe documents that content faithfully without embellishment or annotation. A good sponge and scribe will be able to capture common themes from management interviews and prepare a positive statement about how the organization as a whole wants its information protected. The time and effort spent to gain executive consensus on policy will pay off in the authority it lends to the policy enforcement process.
Good interview questions that solicit management’s opinions on information security are:
* How would you describe the different types of information you work with?
* Which types of information do you rely on to make decisions?
* Are there any information types that are more of a concern to keep private than others?
From these questions, an information classification system can be developed (e.g. customer info, financial info, marketing info, etc), and appropriate handling procedures for each can be described at the business process level. (Editor’s note: See also Jason Stradley’s provocative take on data classification and related issues.)
Of course, a seasoned security professional will also have advice on how to mold the management opinions with respect to security into a comprehensive organizational strategy. Once it is clear that the security professional completely understands management’s opinions, it should be possible to introduce a security framework that is consistent with it. The framework will be the foundation of the organization’s Information Security Program, and thus will service as a guide for creating an outline of the information security policy.
[ Also see CSOonline.com’s Security and Business: Communication 101 ]
Often, a security industry standards document is used as the baseline framework. For example, the Security Forum’s Standard of Good Practice (www.securityforum.org), the International Standards Organization’s, Security Management series (27001, 27002, 27005, www.iso.org), and the Information Systems Audit and Control Association’s Control Objectives for Information Technology (CoBIT, www.isaca.org). This is a reasonable approach, as it helps to ensure that the policy will be accepted as adequate not only by company management, but also by external auditors and others who may have a stake in the organization’s Information Security Program.
However, these documents are inherently generic and do not state specific management objectives for security. So they must be combined with management input to produce the policy outline. Moreover, it is not reasonable to expect the management of an organization to change the way the organization is managed in order to comply with a standards document. Rather, the information security professional may learn about good security management practices from these documents, and see if it is possible to incorporate them into the current structure of the target organization.
It is important that security policy always reflect actual practice. Otherwise, the moment the policy is published, the organization is not compliant. It is better to keep policy as a very small set of mandates to which everyone agrees and can comply than to have a very far-reaching policy that few in the organization observe. The Information Security Program can then function to enforce policy compliance while the controversial issues are simultaneously addressed.
Another reason that it is better to keep policy as a very small set of mandates to which everyone agrees is that, where people are aware that there are no exceptions to policy, they will generally be more willing to assist in getting it right up front to ensure that they will be able to comply going forward. Once a phrase such as «exceptions to this policy may be made by contacting the executive in charge of….» slips into the policy itself or the program in which it is used, the document becomes completely meaningless. It no longer represents management commitment to an Information Security Program, but instead communicates suspicion that the policy will not be workable. A security professional should consider that if such language were to make its way into a Human Resources or Accounting policy, people could thus be excused from sexual harassment or expense report fraud. A security professional should strive to ensure that information security policy is observed at the same level as other policies enforced within the organization. Policy language should be crafted in such a way that guarantees complete consensus among executive management.
For example, suppose there is debate about whether users should have access to removable media such as USB storage devices. A security professional may believe that such access should never be required while a technology executive may believe that technology operations departments responsible for data manipulation must have the ability to move data around on any type of media. At the policy level, the consensus-driven approach would produce a general statement that «all access to removable media devices is approved via a process supported by an accountable executive.» The details of the approval processes used by the technology executive can be further negotiated as discussions continue. The general policy statement still prohibits anyone without an accountable executive supporting an approval process from using removable media devices.
In very large organizations, details on policy compliance alternatives may differ considerably. In these cases, it may be appropriate to segregate policies by intended audience. The organization-wide policy then becomes a global policy, including only the least common denominator of security mandates. Different sub-organizations may then publish their own policies. Such distributed policies are most effective where the audience of sub-policy documents is a well-defined subset of the organization. In this case, the same high level of management commitment need not be sought in order to update these documents.
For example, information technology operations policy should require only information technology department head approval as long as it is consistent with the global security policy, and only increases the management commitment to consistent security strategy overall. It would presumably include such directives as «only authorized administrators should be provided access capable of implementing operating system configuration changes» and «passwords for generic IDs should be accessed only in the context of authorized change control processes.» Another type of sub-policy may involve people in different departments engaged in some unusual activity that is nevertheless subject to similar security controls, such as outsourcing information processing, or encrypting email communications.
On the other hand, subject-specific policies that apply to all users should not be cause to draft new policies, but should be added as sections in the global policy. Multiple policies containing organization-wide mandates should be discouraged because multiple policy sources make it more difficult to accomplish a consistent level of security awareness for the any given individual user. It is hard enough to establish policy-awareness programs that reach all in the intended community, without having to clarify why multiple policy documents were created when one would do. For example, new organization-wide restrictions on Internet access need not be cause to create a new «Internet Access» policy. Rather, an «Internet Access» section can be added to the global security policy. Another caveat for the security professional using the sub-policy approach is to make sure sub-policies do not repeat what is in the global policy, and at the same time are consistent with it. Repetition must be prohibited as it would allow policy documents to get out of sync as they individually evolve. Rather, the sub-documents should refer back to the global document and the two documents should be linked in a manner convenient for the reader.
Even while giving sub-policies due respect, wherever there is an information security directive that can be interpreted in multiple ways without jeopardizing the organization’s commitment to information security goals, a security professional should hesitate to include it in any policy. Policy should be reserved for mandates. Alternative implementation strategies can be stated as a responsibility, standard, process, procedure, or guideline. This allows for innovation and flexibility at the department level while still maintaining firm security objectives at the policy level.
This does not mean that the associated information protection goals should be removed from the Information Security Program. It just means that not all security strategy can be documented at the policy level of executive mandate. As the Information Security Program matures, the policy can be updated, but policy updates should not be necessary to gain incremental improvements in security. Additional consensus may be continuously improved using other types of Information Security Program documents.
Supplementary documents to consider are:
Roles and responsibilities — Descriptions of security responsibilities executed by departments other than the security group. For example, technology development departments may be tasked with testing for security vulnerabilities prior to deploying code and human resources departments may be tasked with keeping accurate lists of current employees and contractors.
Technology standards — Descriptions of technical configuration parameters and associated values that have been determined to ensure that management can control access to electronic information assets.
Process — Workflows demonstrating how security functions performed by different departments combine to ensure secure information-handling.
Procedures — Step by step instructions for untrained staff to perform routine security tasks in ways that ensure that the associated preventive, detective, and/or response mechanisms work as planned.
Guidelines — Advice on the easiest way to comply with security policy, usually written for non-technical users who have multiple options for secure information-handling processes.
What an Information Security Policy Includes
This leaves the question: what is the minimum information required to be included in an Information Security Policy? It must be at least enough to communicate management aims and direction with respect to security. It should include:
1. Scope — should address all information, systems, facilities, programs, data, networks and all users of technology in the organization, without exception
2. Information classification — should provide content-specific definitions rather than generic «confidential» or «restricted»
3. Management goals for secure handling of information in each classification category (e.g. legal, regulatory, and contractual obligations for security, may be combined and phrased as generic objectives such as «customer privacy entails no authorized cleartext access to customer data for anyone but customer representatives and only for purposes of communicating with customer,» «information integrity entails no write access outside accountable job functions,» and «prevent loss of assets»)
Как я писал политику безопасности +7
Информационная безопасность
Рекомендация: подборка платных и бесплатных курсов 3D-моделирования — https://katalog-kursov.ru/
Так получилось, что за последние несколько лет мне довелось несколько раз написать «с нуля» и внедрить в разных компаниях политику информационной безопасности, а также понаблюдать, как это делают коллеги по цеху. В предлагаемой заметке делается попытка обобщить полученный опыт и упомянуть про грабли, оставившие наиболее заметный след на лбу автора. Сразу оговоримся, что далее речь пойдет не о рекомендациях по защите от вирусов или выбору стойкого пароля, а в основном о логике, структуре и назначении подобных документов.
А зачем, собственно?
Варианты ответа могут встречаться разные: выполнение распоряжения мудрого руководства, формальное соответствие каким-либо внешним требованиям, желание внедрить загадочные «лучшие практики» или просто давно назревшая потребность формализовать принятые в компании правила безопасности (а не объяснять их на словах каждый раз).
Будем считать, что политика безопасности – это фиксирование внутренних договоренностей между фунциями ИТ, ИБ и ключевыми пользователями от бизнеса о том, что и как необходимо защищать. Под этой простой формулировкой скрывается несколько важных тем, в том числе – расстановка приоритетов, планирование ресурсов, согласие по поводу практических методов реализации и механизмов контроля (не)сделанного. Напомню, что нам нужно не только написать красивую и правильную политику, но и добиться её внедрения на практике.
Другими словами, политика безопасности устанавливает «единые правила игры», является ориентиром для всех вовлеченных товарищей, при этом закрывает ряд формальных требований законодательства и любых внешних проверяющих, а также радует руководство очевидными доказательствами бурной деятельности подразделения по ИБ.
Дорогие читатели
Во время разработки политики безопасности крайне важно представлять себе целевую аудиторию. Маловероятно, что у нас получится написать документ, одинаково пригодный для зампреда правления, начальника отдела системного администрирования и рядового сотрудника склада.
Обычно для руководства готовится презентация (если нужно предложить план действий, варианты решения проблемы или проинформировать о результате), поэтому структура такого документа ничем не отличается от материалов других функциональных подразделений. Когда речь идет о правилах безопасности для пользователей, то это либо памятка на страничку с полем для подписи после ознакомления, либо материалы для системы дистанционного обучения с красивыми картинками.
Целевая аудитория политики безопасности – это руководители и специалисты ИТ-службы, отдела по защите информации, проектного офиса, ключевые пользователи и все прочие обитатели офиса, так или иначе связанные с разработкой, внедрением и поддержкой ИТ-систем. Также не стоит забывать о подрядчиках и консультантах, выполняющих схожие функции по заказу нашей организации.
Точное понимание целевой аудитории дает отличный фильтр, влияющий на то, какое требование включить в политику безопасности, а какое – отбросить; какую формулировку использовать, чтобы впоследствии заставить это требование работать. Проиллюстрируем это на классическом примере с парольной политикой, попутно проигнорировав возможные возражения по поводу качества требуемого пароля:
Пароль должен содержать не менее 6 символов, в том числе как минимум одну заглавную букву и одну цифру.
и альтернативный вариант:
Необходимо реализовать проверку, что выбранный пользователем пароль содержит не менее 6 символов, в том числе как минимум одну заглавную букву и одну цифру.
Первое утверждение отлично подойдет для правил по безопасности для пользователей, и то скорее в справочном (а не директивном) порядке, а вот второе прекрасно может быть реализовано как техническое требование безопасности к ИТ-системе.
Прежде чем спорить
Термины и определения – один из самых важных разделов нашей будущей политики. Хорошие определения нужны для того, чтобы дать читателю (и по совместителю – исполнителю) четкое представление о предмете и сделать более понятными все выдвигаемые в тексте требования.
Определения проще всего взять из законодательства, стандартов или Википедии, но не факт, что они будут легко читаться и отвечать особенностям той организации, для которой мы разрабатываем политику безопасности. Поэтому для ключевых терминов может оказаться проще и лучше написать определения самостоятельно, сверяясь с упомянутыми выше источниками.
Практика показывает, что после нескольких итераций разработки политики глоссарий содержит примерно 30-40 жизненно необходимых терминов, включая как и узкоспециальные понятия (двухфакторная аутентификация, например), так и более универсальные сущности (сервер, мобильный компьютер, и т.п.), если они не были определены ранее в других политиках или общем глоссарии организации.
Закон и порядок
Разобравшись с терминами и определениями, самое время посмотреть на структуру содержательной части документа. Общепринятым подходом является брать состав разделов международного стандарта ISO 27002 (или соответствующего ему ГОСТа) или базироваться на любом другом источнике, комплексно описывающем основные принципы защиты информации. Понятно, что и структура, и содержание разделов могут сильно отличаться в зависимости от профиля деятельности нашей организации.
В качестве примера перечислим минимальный набор тем, которые имеет смысл отразить в разрабатываемой политике:
- Организационная структура ИБ и объекты защиты (кто, что и почему защищает – про риски, классификацию активов, распределение ролей и обязанностей).
- Контроль доступа (по сути, правила взаимодействия участников процесса и объектов защиты).
- Управление изменениями (про то, как наши системы должны безопасно и контролируемо переходить из одного состояния в другое).
- Мониторинг и аудит (способы оценки и подтверждения текущего состояния защищенности).
Очевидно, что список разделов можно разбить на менее крупные части и дополнить другими важными темами, но одним из достоинств приведенного выше варианта представляется именно минимальность и достаточность.
Ну и еще одна важная со смысловой точки зрения деталь – политика безопасности может являться описательной («as is», фиксируется текущее состояние) или директивной («to be», что должно быть сделано). Директивный вариант представляется более понятным для чтения и логичным для последующего применения, так как обычно «уже сделано» гораздо меньше, чем «будет сделано».
А судьи кто?
Хорошо, если в организации есть отдел ведения нормативно-справочной информации или другие ребята, помогающие в нелегком деле разработке нормативных документов. Если же их нет, хорошо бы не забыть о едином хранилище для черновиков и уже утвержденных политик, порядке присвоения версий и, конечно же, типовом шаблоне для документа. Все это поначалу может показаться немного лишним, но при разработке последующих версий политики окажет неоценимую помощь.
Рекомендуется дать избранным коллегам ссылку на черновик документа и предложить задать вопросы про итогам прочтения, чтобы получить непосредственную обратную связь. Если свеженаписанная политика будет с пониманием воспринята, например, упертым сисадмином Сергеем, ветераном режимно-секретного отдела Игорем Степановичем и гордым обладателем сертификата PMI Иваном, то можно считать, что самая строгая проверка качества документа пройдена.
И еще один момент. Как только основная работа над политикой будет закончена, нас ждет проверка орфографии и правил пунктуации. Наверняка в организации найдется хотя бы один сотрудник, который знает их лучше вас и не упустит шанс с удовольствием рассказать всем о найденных в тексте ошибках.
Согласие и примирение
Как известно, процесс согласования любого нормативного документа – отдельная песня, начиная со словесных баталий за отдельные неудобные формулировки и заканчивая квестом по кабинетам с целью получения необходимого набора подписей. Отметим, что косвенным образом трудоемкость этого этапа влияет на частоту обновления политики безопасности и, следовательно, на практическую пользу написанного текста. Так как никому не хочется лишний раз участвовать в этом действии, документ зачастую устаревает раньше, чем его успевают полностью согласовать и утвердить.
Чтобы сократить бессмысленные телодвижения на этом этапе и упростить процедуру согласования политики безопасности, была предложена и затем успешно обкатана примерно следующая схема:
- К разработке документа в качестве консультантов привлекаются ключевые сотрудники подразделений, через которые будет проходить согласование. Это подчеркивает ощущение их вовлеченности в процесс и уменьшает риск отказа от исполнения уже принятой политики.
- На уровне руководства обычным бумажным образом проводится договоренность о том, что согласование политик ИТ и ИБ будет осуществляться в электронном виде и фактом утверждения документа является публикация очередной версии политики на корпоративном портале. Бумажные версии при необходимости подписываются в фоновом режиме.
- Процесс согласования переводится в режим «если нет замечаний к определенной дате, то считаем согласованным», а полученные с опозданием возражения и поправки включаются в следующую версию документа. Попутно такой подход неплохо дисциплинирует всех участников процесса.
Ну и отдельно отметим, что в перечень согласующих лиц должны быть включены руководители всех подразделений, сотрудники которых и будут исполнять описанные в политике требования. Как правило, это будут ИТ, безопасники, юристы и кадровики.
Успешность внедрения
При разработке политики безопасности мы всегда должны держать в голове необходимость её последующего внедрения. Можно предложить следующие критерии успеха:
- Целевая аудитория знакома с текстом документа и понимает изложенные в политике требования.
- Большая часть требований политики выполняется на практике, а для невыполненных требований внедрена процедура обработки исключений.
- Существует возможность объективно и независимо проверить предыдущие два утверждения.
Рассмотрение процедуры обработки исключений выходит за рамки этого материала, но отметим самое важное. Наличие универсального механизма принятия решений в ситуациях, не описанных в политике безопасности или противоречащих ей (при невозможности устранить нарушения), является крайне полезным инструментом управления безопасностью.
Про грабли (вместо заключения)
Еще раз кратко перечислим типовые проблемы, с которыми можно столкнуться при написании политики безопасности:
- «А это вообще про что?» – требования, не находящие своего читателя (исполнителя) или обращенные в никуда.
- «Муть какая-то…» – нечеткая терминология, непонятные формулировки требований политики.
- «Полная хрень!» – Сложности при согласовании и внедрении из-за активного противодействия ключевых пользователей, мнение которых не было учтено.
- «Разве документы так пишутся?!» – Игнорирование правил оформления, стилистические, орфографические и пунктуационные ошибки.
Ну и, конечно же, автор будет рад любым вопросам и замечаниям, которые могут возникнуть после прочтения этой заметки.
Пример разработки политики безопасности организации
- Что нужно для создания политики безопасности
- Компоненты архитектуры безопасности
- Примеры подходов:
- Пример подход предприятия IBM
- Пример стандарта безопасности для ОС семейства UNIX
- Пример подхода компании Sun Microsystems
- Пример подхода компании Cisco Systems
- Пример подхода компании Microsoft
- Положение о политике информационной безопасности предприятия
Что нужно для создания политики безопасности
Основной этап построения защищенной информационной системы, это этап разработки политики безопасности. Подробная политика нужна для создания эффективной системы безопасности предприятия.Далее показано основные шаги обеспечения безопасности:
- Уточнение важности информационных и технологических активов предприятия;
- определения уровня безопасности для каждого актива, а так же средства безопасности которые будут рентабельными для каждого актива
- Определение рисков на угрозы активам;
- Привлечение нужных денежных ресурсов для обеспечения политики безопасности, а так же приобретение и настройка нужных средств для безопасности;
- Строгий контроль поэтапной реализации плана безопасности, для выявление текущих прощетов а также учета изменения внешних факторов с дальнейшим изменением требуемых методов безопасности;
- Проведение объяснительных действий для персонала и остальным ответственным сотрудникам
Следующие требования к политикам безопасности составлены на ряде ошибок и проб большинства организаций:
Политики безопасности должны:
- указывать на причины и цели создания политики безопасности;
- осматривать, какие границы и ресурсы охватываются политикой безопасности;
- определить ответственных по политике безопасности;
- определить условие не выполнение и так званное наказание
- политики безопасности должны быть реальными и осуществимыми;
- политики безопасности должны быть доступными, краткими и однозначными для понимания;
- должна быть золотая середина между защитой и производительностью;
Основные шаги по разработке политики есть:
- создание адекватной команды для создание политики;
- решить вопросы об возникающих особенностях при разработки.
- решить вопросы об области действии и цели создании политики;
- решить вопросы по поводу ответственных за создания и выполнения данного документа;
Нужно проанализировать локальную сеть на локальные атаки. Сделав основные шаги нужно проанализировать есть ли выход локальной сети(seti_PDH или seti_dwdm) в интернет. Ведь при выходе сети в интернет возникает вопрос о проблемах защиты информации в сетях. Потом какие компьютеры и сетевые сервисы используются уже в сети. Определить количество сотрудников по ряду критерию. К примеру скольким нужен доступ в интернет, сколько пользуется электронной почтой и другими онлайн сервисами. Также определить есть ли удаленный доступ к внутренней сети. Самый главный вопрос, через который должны быть определенны все вопросы, это «Входит ли этот сервис с список требований для проведение бизнеса?»
После проведения анализа и систематизации информации, команде нужно перейти к анализу и оценки рисков.Анализ рисков — это самый важный этап формирования политики безопасности (рис.1).
Рисунок 1
На этом этапе реализуются следующие шаги:
- анализ угроз информационной безопасности которые непосредственно обозначены для объекта защиты;
- оценка и идентификация цены информационных и технологических активов;
- осмотр вероятности реализации угроз на практике;
- осмотр рисков на активы;
После осмотра рисков на активы нужно переходить к установке уровня безопасности который определяет защиты для каждого актива. Есть правило, что цена защиты актива не должна превышать цены самого актива
Рассмотрим создания одного из процессов безопасности. Процесс показано на рис.2.
- Вход, допустим это пользователь делает запрос на создания нового пароля;
- механизм, определяет какие роли участвуют в этом процессе.Пользователь запрашивает новый пароль у Администратора;
- Управление — описывает сам алгоритм который управляет процессом. При запросе нового пароля, пользователь должен пройти аутентификацию;
- Выход, это результат процесса. Получение пароля.
Рисунок 2
Компоненты архитектуры безопасности
Физическая безопасность, важный компонент так как заполнение физической области где находятся компоненты объекта защиты не однородно. Если в здании находятся не только сотрудники организации, но и другие люди нужно учитывать все моменты защиты. Реализация физической защиты приводится к определению компонентов компьютерной сети, которые должны быть защищены физически, так как они могут подвергаться угрозам таким как потеря конфиденциальности, доступности и целостности.
Нужно обозначить области с различным уровнем безопасности:
- открытые, область физической среды в которые могут заходит как сотрудники так и другие люди
- контролируемые, область физической среды которая должна быть закрыта при отсутствии контроль или присмотра
- особо контролируемые, это область где ограничен доступ даже сотрудникам с повышенными правами доступа
Логическая безопасность характеризует уровень защиты активов и ресурсов в сети. Включает в себя механизмы защиты в сети (идентификация, аутентификация, МЭ, управление доступом и тд). также должен быть обозначен метод обнаружения ошибок при передачи информации. Также нужно учитывать algoritm_pokryivayusccego_dereva.
Ресурсы делят на две категории, которые подвержены угрозам:
- Ресурсы ОС;
- Ресурсы пользователя.
- Возможно теоретически, ресурсы которые находятся за физическим доступом организации, к примеру спутниковые системы;
Определение полномочий администратору, должны быть четко обозначены и также все их действие должны логироватся и мониториться. Также есть администраторы которые следят за контролем удаленного доступа к ресурсам.
Функции:
- должны определить полномочия для каждой системы и платформы;
- проверять назначение прав авторизованным пользователям.
Управление тревожной сигнализацией важный компонент, так как для немедленного реагирования залог в предотвращении атаки. Пример процессов для обнаружения проблем и тревог:
- каждое нарушение безопасности должно давать сигнал события;
- Одно событие не есть поводом для утверждения, они должны накапливаться;
- должен быть порог, с которым сравнивают данные и дают вывод по конкретным действиям.
Пример подход предприятия IBM
Специалисты IBM считают, что корпоративная деятельность должна начинаться с создания политики безопасности. При этом при создании рекомендуется держатся международного стандарта ISO 17799:2005 и смотреть политику предприятия как неотъемлемый кусок процесса управления рисками (рис.3). Разработку политики безопасности относят к важным задачам предприятии.
Рисунок — 3
Специалисты IBM выделяют следующие этапы разработки политики безопасности:
- Анализ информационных предприятия, который могут нанести максимальный ущерб.
- Создание политики безопасности, которая внедряет методы защиты которые входят в рамки задач предприятия.
- Разработать планы действий при ЧС для уменьшения ущерба.
- Анализ остаточных информационных угроз. Анализ проводится на основе главных угроз.
Специалисты IBM рекомендуют реализовать следующие аспекты для эффективной безопасности предприятия:
- Осмотр ИТ-стратегии, определение требований к информационной безопасности и анализ текущих проблем безопасности.
- Осмотр бизнес-стратегии предприятия.
- Разработка политики безопасности, которая учитывает ИТ-стратегии и задачи развития предприятия.
Рекомендуемая структура руководящих документов для реализации информационной безопасности показана на рис.4.
Рисунок — 4
IBM под стандартами подразумевает документы, которые описывают порядок и структуру реализации политики безопасности в таких аспектах как авторизация, контроль доступа, аутентификация, идентификация и тд. Такие стандартны могут быть изменены относительно требований политики безопасности, так как на них влияют уже немножко другие угрозы, более специфические. IBM подразумевает создание стандартов для:
- анализа информационных угроз и методов их уменьшения
- создание норм и правил безопасности разных уровней предприятия
- уточнение методов защиты, которые будут реализованы на предприятии
- конкретное определение процедур безопасности
- анализ ожиданий относительно результатов от сотрудников и компании в целом
- реализация юридической поддержки
Стандарты создаются с помощью практик или/и процедур. В них детализируются сервисы, которые ставятся на ОС, а так же порядок создание других моментов. IBM предлагает особенности подхода к разработке документов безопасности (рис.5).
Рисунок — 5
Пример стандарта безопасности для ОС семейства UNIX
Область и цель действия — документ описывает требования по защите ПК, которые работают на ОС unix.
Аудитория — персонал служб информационной безопасности и информационных технологий.
Полномочия — Отдел предприятия по информационной безопасности наделяется всеми правами доступа к серверам информационной системы предприятия и несет за них ответственность. Департамент управления рисками утверждает все отклонения от требований стандарта.
Срок действия — с 1 января по 31 декабря … года.
Исключения — Любые отклонения от реализации стандарта должны быть подтверждены в отделе предприятия по информационной безопасности.
Поддержка — Любые вопросы которые связанны с стандартом, задавать в отдел информационной безопасности.
Пересмотр стандарта — пересматривается ежегодно.
Пример подхода компании Sun Microsystems
Специалисты Sun считают, что политика есть необходимой для эффективной организации режима информационной безопасности предприятия. Они же под политикой безопасности подразумевают стратегический документ, в котором описаны требования и ожидания руководства предприятии. Они рекомендуют создать подход сверху-вниз, сначала создать политику безопасности, а потом уже строить архитектуру информационной системы. К созданию политики безопасности они рекомендуют завлечь таких сотрудников подразделений как:
- управление бизнесом
- отдел защиты информации
- техническое управление
- департамент управления рисками
- отдел системного/сетевого администрирования
- юридический отдел
- департамент системных операций
- отдел кадров
- служба внутреннего качества и аудита
Основной назначение политики безопасности — информирование руководство и сотрудников компании от текущих требованиях о защите данных в информационной системе.
Идея политики безопасности к основным идеям относят:
- назначения ценности информационных активов
- управление остаточными рисками; R = H × P, где Н — оценка ущерба, Р — вероятность угрозы
- управление информационной безопасностью
- обоснованное доверие
Принцип безопасности — это первый шаг при создании политики, к ним относят:
- Ознакомления — участники информационной системы обязаны быть ознакомлены о требованиях политики безопасности и о ответственности.
- Ответственность — ложится на каждого пользователя за все его действия в информационной сети.
- Этика — деятельность сотрудников компании должна быть в соответствии со стандартами этики.
- Комплексность — должны учитываться все направления безопасности.
- Экономическая оправданность — все действия развитии предприятия должны быть экономически оправданными.
- Интеграция — все направления политики, процедур или стандартов должны быть интегрированы и скоординированы между собой.
- Своевременность — все противодействия угрозам должны быть своевременны.
- Демократичность — все действия по защите активов на предприятии должны быть в нормах демократии.
- Аккредитация и сертификация — компания и все ее действия должны быть сертифицированы
- Разделение привилегий — все права сотрудников должны быть разделены относительно их допуска к ресурсам.
Пример подхода компании Cisco Systems
Специалисты Cisco считают, что отсутствие сетевой политики безопасности приводит к серьезным инцидентам в сфере безопасности. Определение уровней угроз и типов доступа, которые нужны для каждой сети разрешает создать матрицу безопасности (табл.1). Такая матрица есть отправной точной в создании политики безопасности.
Таблица 1.
| Система | Описание | Уровень риска | Типы пользователей |
|---|---|---|---|
| АТМ-коммутаторы | Основные сетевые устройства | Высокий | Сетевые администраторы |
| Сетевые маршрутизаторы | Сетевые устройства распределения | Высокий | Сетевые администраторы |
| Коммутаторы доступа | Сетевые устройства доступа | Средний | Сетевые администраторы |
| ISDN/dial up -серверы | Сетевые устройства доступа | Средний | Сетевые и системные администраторы |
| Межсетевые экраны | Сетевые устройства доступа | Высокий | Администратор безопасности |
| Серверы DNS и ВРСЗ | Сетевые приложения | Средний | Сетевые и системные администраторы |
| Внешние почтовые серверы | Сетевые приложения | Низкий | Администраторы и пользователи |
| Внутренние почтовые серверы | Сетевые приложения | Средний | Администраторы и пользователи |
| Серверы баз данных Oracle | Сетевые приложения | Средний или высокий | Администраторы баз данных и пользователи |
Под предупреждением нарушений специалисты Cisco считают подтверждение модификаций в системах безопасности. К таким изменениям можно отнести:
- списки контроля доступа
- конфигурация межсетевых экранов
- версия ПЗ
- конфигурация SNMP
Также согласно RFC 2196 должна быть обработка инцидента. Обработка инцидента — алгоритм реагирования на разные ситуации. Шаги по обработке:
- определения приоритета и типа атаки
- анализ времени начала/конца атаки
- анализ источника атаки
- анализ затронутых устройств атакой
- запись в журнал
- действия по остановки или уменьшения последствий атаки
- изолирования пострадавших участков системы
- уведомление соответствующих лиц
- защита доказательств атаки
- восстановление работоспособности изолированных участков
Пример подхода компании Microsoft
В сеть предприятия каждый день приходит близко 8 млн. почтовых сообщений, и 6.5 млн сообщений циркулируют внутри компании. Microsoft создала стратегию безопасности, которая состоит из:
- миссия корпоративной безопасности
- принципы операционной безопасности
- модель принятия решений, которая основана на осмотре рисков
- тактическое определение приоритета работы по уменьшению рисков
Подход компании Symantec
Политика определяет, почему предприятие защищает свои данные и активы. Стандарты — что предприятие будет делать для защиты и управления безопасностью информации. Процедуры описывают, как именно предприятие будет выполнять то, что описано в документах выше стоящих. Компания Symantec описывает следующие этапы разработки политики безопасности.
- Анализ и оценка информационных активов— что нужно защищать и с какими целями и задачами.
- Анализ угроз безопасности — выявление источников потенциальных проблем. Анализ возможных ущербом относительно угроз.
- Анализ информационных рисков — самый сложный этап, так как нужно определить вероятности угроз и сопутствующий ущерб.
- Определение ответственности — выбор людей или команду которая должна заниматься такими вопросами на предприятии.
- Создание комплексного документа — создание политики на основе дополнительных документов то ли законодательных то ли внутри корпоративных.
- Реализация — Политика должна четко описывать механизмы реализации защитных действий.
- Управление программой безопасности — область применения.
Что во внимании ? Для эффективной работы политики нужно что бы:
- учитывались цели бизнеса
- была реальной
- держала баланс между безопасностью и производительностью
- все сотрудники могли ознакомится с содержимым политики
- не противоречила другим документам компании и требованием законодательства
- определяла четко ответственность сотрудников
- была обновляемой
Иерархическая структура документации по информационной безопасности
Оптимальное и контролируемое обеспечение информационной безопасности (далее – ИБ) требует наличия пакета документов, системно описывающих цели и взаимосвязи процессов по их достижению. Классически такая документация разделяется по уровням, иерархия ее построения визуально представляется в виде пирамиды, демонстрируемой на рисунке 1.
Стоит отметить, что количество уровней иерархии документации в организации определяется спецификой организации и может быть различно. Наиболее часто встречается 3-х и 4-х уровневая иерархия документации.
Создавать и развивать комплексную систему ИБ необходимо, руководствуясь едиными принципами и подходами. В противном случае, конечный результат может представлять собой разрозненный набор технических средств и организационно-распорядительных документов организации, который нельзя будет назвать «системой» и эффективность которого будет невысока. Потраченные организацией материальные ресурсы не дадут ожидаемого эффекта. Распространена ситуация, когда подразделение ИБ планирует свою деятельность, исходя из исключительно внутреннего понимания бизнес-процессов организации, субъективно определяет актуальные цели и задачи ИБ. При этом стандартно возникают проблемы с обоснованностью целесообразности внедрения той или иной технологии ИБ в организации, с выделением и обоснованностью бюджета на ИБ.
Первый уровень иерархической структуры документации по информационной безопасности
Разработка Концепции или стратегии ИБ нацелена на решение указанных проблем. Концепция / стратегия ИБ должна отражать позицию руководства организации в вопросах обеспечения ИБ и определять цели, задачи и общие принципы, в соответствии с которыми будет строиться комплексная система ИБ. Концепция или стратегия ИБ должна представлять собой высокоуровневый документ, определяющий развитие комплексной системы ИБ в организации на несколько лет вперед.
Мировой опыт
Крупные зарубежные компании рассматривают ИБ как неотъемлемое свойство архитектуры организации. Под архитектурой организации понимается набор принципов, подходов и технологий. При этом все элементы архитектуры организации должны быть пронизаны архитектурой ИБ [1]. Взаимосвязь архитектур представлена на рисунке 2.
При формировании архитектуры ИБ необходимо описать в формализованном виде процессы, ролевые обязанности персонала, технологии и типы информации, используемые в организации. Рекомендуется учитывать не только текущие потребности организации, но и задачи бизнеса на будущее. Критически важно увязывать задачи ИБ с основной концепцией развития организации.
Отечественный подход
Для крупных отечественных холдингов характерна разработка двухуровневых Концепций / стратегий развития, вызванная масштабом организации. Так, в АО «РЖД» утверждена общая стратегия развития [2] и функциональные стратегии по направлениям развития [3]. При этом вопросы обеспечения ИБ не только выделены в отдельное направление [4], но и отражены в документах по иным направлениям стратегического развития холдинга [3].
Менее крупные корпорации и организации ограничиваются либо одноуровневой концепцией ИБ [5]-[9], либо Политикой ИБ [10]-[11].
Концепция / стратегия ИБ, как и любой другой документ, может разрабатываться с различным вниманием к деталям и нуждам конкретной организации. Однако одним из основных требований, которым должны соответствовать такого рода документы, является комплексность, поскольку, если какие-либо нюансы не будут учтены в документе, то они могут быть упущены вовсе.
Поэтому Концепция / стратегия ИБ должна учитывать самые различные моменты:
- требования федерального законодательства, требования законодательства субъекта Российской Федерации, требования регуляторов, отраслевые требования;
- национальные федеральные и целевые программы;
- стандарты ИБ;
- угрозы ИБ, актуальные для данной организации;
- мировые практики;
- современные и перспективные тренды и т. д.
Как сделать?
Формальные требования к структуре или оформлению Концепции / стратегии ИБ отсутствуют, но по сложившейся практике Концепция / стратегия ИБ строится согласно логике «объект защиты – угрозы – меры защиты» и основывается на лучших практиках, в т. ч. мировых. В общем случае Концепция / стратегия ИБ содержит:
- основные цели и задачи ИБ;
- основные принципы обеспечения ИБ;
- описание объекта защиты;
- верхнеуровневую модель угроз и нарушителя безопасности информации;
- описание общих методов обеспечения ИБ;
- принципы управления ИБ;
- описание организации работ по обеспечению ИБ (состав мероприятий);
- меры обеспечения ИБ;
- разделение ответственности и порядок взаимодействия;
- принципы оценки и контроля;
- нормативно-методическое обеспечение;
- механизм реализации Концепции / стратегии ИБ;
- ожидаемый эффект.
Особо отметим, что типовых Концепций / стратегий ИБ не существует. Концепция / стратегия ИБ – исключительно практический документ, максимально соответствующий нуждам конкретной организации.
Для построения архитектуры комплексной системы ИБ необходимо осуществить ряд взаимосвязанных действий, объединенных единым стратегическим замыслом и представленных в структурированном виде. Процесс разработки Концепции / стратегии ИБ отражен на рисунке 3.
Иные варианты
В случаях, когда организации ограничиваются разработкой политики ИБ, следует исходить из того, что политика ИБ становится основным высокоуровневым документом организации, определяющим подходы, методики достижения целей ИБ через постановку стратегических целей, формирующим подходы к построению моделей угроз и атак, а также методики выявления, оценки и прогнозирования рисков ИБ. Наиболее полно требования к форме, содержанию и задачам политики ИБ сформированы в банковской сфере [12]-[14]. Так же можно отметить идентичность политик ИБ органов государственной власти [15]-[16] или органов здравоохранения [17]-[18], в силу серьезного централизованного ведомственного и отраслевого регулирования сферы их деятельности. Для коммерческих организаций характерна более узкая направленность политики ИБ на обеспечение безопасности персональных данных в организации [19]-[20].
Это важно учесть
Наиболее существенное влияние на состав и содержание разделов политики ИБ организации оказывает актуализация законодательства Российской Федерации и Евразийского экономического союза [21].
Так, в 2006 году с целью регулирования отношений, связанных с обработкой персональных данных (далее – ПДн), были внесены изменения в законодательство Российской Федерации [22]. Мерами, направленными на обеспечение выполнения оператором обязанностей, определенных российским законодательством, предусмотрена обязательная разработка и утверждение в каждой организации политики обработки персональных данных [23]. Разработка данной политики невозможна без интеграции технических и организационных средств защиты ПДн в комплексную систему ИБ организации.
Внесение отдельного состава административного правонарушения за нарушение требований о защите информации (за исключением информации, составляющей государственную тайну), установленных федеральными законами и принятыми в соответствии с ними иными нормативными правовыми актами Российской Федерации, заставило организации перейти от формального исполнения требований российского законодательства в виде утверждения типового пакета документации по ИБ к организации реальных процессов обеспечения и управления ИБ [24].
В дальнейшем были законодательно урегулированы отношения, связанные с обработкой государственного информационного ресурса в государственных информационных системах [25].
Возросшая степень автоматизации и информатизации объектов критической информационной инфраструктуры Российской Федерации привела в 2016 году к необходимости выделения вопросов обеспечения безопасности критической информационной инфраструктуры в отдельную область законодательства [26].
Выполнение требований по защите ПДн, установленных нормативными правовыми актами Российской Федерации, приводит к необходимости формирования многоуровневой экономически обоснованной комплексной системы ИБ в организации.
Обеспечение безопасности ПДн у крупного оператора связи достигается:
- определением угроз безопасности ПДн при их обработке в информационной системе персональных данных (далее – ИСПДн);
- применением организационных и технических мер по обеспечению безопасности ПДн при их обработке в ИСПДн, необходимых для выполнения требований к защите ПДн, исполнение которых обеспечивает установленные Правительством Российской Федерации уровни защищенности ПДн;
- применением прошедших в установленном порядке процедуру оценки соответствия средств защиты информации;
- оценкой эффективности принимаемых мер по обеспечению безопасности ПДн до ввода в эксплуатацию ИСПДн;
- учетом машинных носителей ПДн;
- обнаружением фактов несанкционированного доступа к ПДн;
- восстановлением ПДн, модифицированных или уничтоженных вследствие несанкционированного доступа к ним;
- установлением правил доступа к ПДн, обрабатываемым в ИСПДн, а также обеспечением регистрации и учета всех действий, совершаемых с ПДн в ИСПДн;
- контролем за принимаемыми мерами по обеспечению безопасности ПДн и уровнем защищенности ПДн в ИСПДн [27].
Второй уровень иерархической структуры документации по информационной безопасности
На втором уровне иерархии документации по обеспечению ИБ находятся документы, определяющие правила, требования и принципы, используемые применительно к отдельным областям ИБ, видам и технологиям деятельности организации – частные политики ИБ. Кроме того, в состав документов данного уровня рекомендуется включить стандарты технологий обеспечения ИБ организации [28].
Для обеспечения взаимодействия направлений ИБ не рекомендуется повторение одинаковых правил и (или) требований в различных частных политиках ИБ. Включение в частную политику ИБ правила и (или) требования, содержащегося в другой частной политике ИБ, целесообразно осуществлять посредством соответствующей ссылки.
Частные политики ИБ формируются на основании принципов, требований и задач, определенных в Концепции / стратегии ИБ организации, с учетом детализации, уточнения и дополнительной классификации информационных активов и угроз, определения владельцев информационных активов, анализа, оценки рисков и возможных последствий реализаций угроз ИБ в границах области действия регламентируемой области ИБ или технологии.
Базовый набор частных политик ИБ
Комплектность частных политик ИБ определяется исходя из используемых в организации информационных технологий, технических и организационных мер ИБ – элементов комплексной системы ИБ. Базовый набор элементов комплексной системы ИБ приведен на рисунке 4.
Проверка качества частной политики ИБ
В частные политики ИБ организации рекомендуется включать положения, определяющие:
- Цели и задачи ИБ, на обеспечение которых направлена частная политика.
- Область действия политики ИБ, определение объектов (активов) защиты, уязвимостей, угроз и оценка рисков, связанных с объектами защиты.
- сведения о виде деятельности, на обеспечение ИБ которой направлено действие положений частной политики; о совокупности информационных технологий, применяемых в рамках выполнения данного вида деятельности; об основных технологических процессах, реализующих указанные технологии.
- Определение субъектов (ролей), на которых распространяется действие документа. В качестве субъектов (ролей) могут рассматриваться как структурные подразделения организации, так и отдельные исполнители.
- Содержательную часть документа (требования и правила).
- Обязанности по обеспечению ИБ в рамках области действия частной политики ИБ, описание функций субъектов (ролей) над управляемыми объектами в рамках регламентируемых технологических процессов.
- Положения по контролю реализации частной политики ИБ.
- Ответственность за реализацию и поддержку документа.
- Условия пересмотра документа [12].
В силу высокой изменчивости информационных технологий, технологий обеспечения ИБ и появления новых средств ИБ, а также с ростом возможностей нарушителя ИБ, рекомендуется установить период актуализации частных политик ИБ в один год.
Для проверки полноты разработанных частных политик ИБ желательно составлять контрольные листы. Например, для политики управления инцидентами ИБ можно предложить проверку наличия следующих положений:
- Определение в организации ролей процесса управления инцидентами ИБ (роли по обнаружению, классификации, реагированию, анализу и расследованию инцидентов ИБ).
- Описание процедур процесса управления инцидентами, включающих:
- процедуры обнаружения инцидентов ИБ;
- процедуры информирования об инцидентах причастных лиц / организаций;
- процедуры классификации инцидентов и оценки ущерба, нанесенного инцидентом ИБ;
- процедуры реагирования на инцидент;
- процедуры анализа инцидентов ИБ (в т. ч. определение источников и причин возникновения инцидентов, оценка их последствий) и оценки результатов реагирования на инциденты ИБ (при необходимости с участием внешних экспертов в области ИБ).
- Назначение в организации ответственных за выполнение ролей процесса управления инцидентами ИБ (роли по обнаружению, классификации, реагированию, анализу и расследованию инцидентов ИБ).
- Описание процедур хранени и распространения информации об инцидентах ИБ, практиках анализа инцидентов ИБ и результатах реагирования на инциденты ИБ.
- Описание процедуры ознакомления работников организации о порядке действий при обнаружении нетипичных событий, связанных с ИБ, и порядке информирования о данных событиях.
- Описание процедур регистрации и контроля действий работников организации при обнаружении нетипичных событий ИБ, и порядок информирования о данных событиях.
- Описание порядка планирования, принятия, фиксации и выполнения решений по выявленным инцидентам ИБ для предотвращения повторного возникновения инцидентов.
- Описание порядка осуществления контроля выполнения процедур процесса управления инцидентами ИБ.
- Описание порядка актуализации документации процесса управления инцидентами ИБ [12].
С чего начать?
Управление доступом
Управление доступом к защищаемым информационным ресурсам организации — наиболее существенная функция, реализуемая комплексной системой ИБ организации. Без реализации процесса управления доступом к информационным ресурсам организации невозможно обеспечить защиту от несанкционированного доступа к ним.
Риски для информации и средств обработки информации организации, являющиеся следствием бизнес-процессов, в которых участвуют сторонние организации, необходимо определять и реализовывать соответствующие меры и средства контроля и управления прежде, чем будет предоставлен доступ [29].
При необходимости разрешения доступа сторонней организации к средствам обработки информации или к защищаемым информационным ресурсам организации следует проводить оценку рисков ИБ для актуализации существующих мер контроля и управления ИБ в организации.
Доступ сторонних организаций к защищаемым информационным ресурсам организации не должен предоставляться до реализации соответствующих мер и до подписания соглашения, определяющего сроки и условия подключения или доступа к защищаемым информационным ресурсам.
Необходимо предусмотреть осведомленность сторонних организаций об исполнении надлежащим образом требований ИБ, а также убедиться в юридическом закреплении ответственности и обязательств сторонних организаций в отношении доступа, обработки, передачи или иных действий с защищаемыми информационными ресурсами организации.
Если управление ИБ осуществляется в рамках договоров аутсорсинга, то в договорах должно быть оговорено, каким образом третья сторона будет гарантировать поддержание адекватного уровня ИБ организации, определенный оценкой риска, а также адаптацию к выявленным рискам и изменениям рисков.
Некоторые из различий между аутсорсингом и другими формами обеспечения услуг третьими сторонами включают в себя вопросы ответственности, планирование переходного периода и возможного срыва операций в течение данного периода, планирование мероприятий на случай непредвиденных ситуаций и тщательность проверок, а также сбор и управление информацией по инцидентам ИБ. Поэтому важно, чтобы организация планировала и управляла переходом к договорам аутсорсинга и применяла соответствующий процесс управления изменениями и перезаключения договоров либо окончания действия договоров. В договоре необходимо учитывать процедуры непрерывной обработки на случай, если третья сторона окажется неспособной поставлять свои услуги, для предотвращения какой-либо задержки по организации замены услуг.
Управление инцидентами ИБ
Одним из важных процессов в комплексной системе ИБ организации является процесс управления инцидентами ИБ. Наличие корректной политики управления инцидентами ИБ и функционирующий на ее основе процесс управления инцидентами ИБ позволяют поддерживать комплексную систему ИБ в актуальном состоянии (проводить мероприятия по совершенствованию комплексной системы ИБ), корректируя как набор мероприятий по обеспечению ИБ, так и внося изменения в планирование мероприятий ИБ в организации.
Основными целями процесса управления инцидентами ИБ являются минимизация потерь организации, вызванных инцидентами ИБ, и снижение риска возникновения повторных инцидентов ИБ за счет обеспечения оперативности выявления инцидентов ИБ и реализации эффективного управления разрешением инцидентов ИБ. Выявление событий ИБ в масштабе реального времени и их правильная классификация как инцидентов ИБ позволяет организации существенно снизить материальные и репутационные потери от компьютерных атак, а также понизить издержки от «ложных срабатываний» комплексной системы ИБ. Оптимизируется состав сил и средств организации, назначаемых на ликвидацию последствий инцидентов ИБ.
К основным задачам процесса управления инцидентами ИБ относятся:
- быстрое обнаружение инцидентов ИБ;
- обеспечение эффективного разрешения инцидентов ИБ;
- координация реагирования на инциденты ИБ и информирование в установленные нормативными документами сроки заинтересованных внешних организаций;
- минимизация нарушений порядка работы и повреждения данных ИС организации, восстановление в кратчайшие сроки работоспособности информационных систем организации при их нарушении в результате инцидента ИБ;
- обеспечение получения достоверной и полной информации о нарушениях ИБ в организации;
- обеспечение сохранности и целостности доказательств возникновения инцидента ИБ, создание условий для накопления и хранения точной информации об имевших место инцидентах ИБ, о рекомендациях;
- обучение персонала организации действиям по обнаружению, устранению последствий и предотвращению инцидентов ИБ.
Как правило, политика управления инцидентами ИБ включает описание целей и задачей процесса; состава событий ИБ и критериев классификации событий ИБ как инцидентов ИБ; стадий процесса управления инцидентами ИБ, ролей работников, задействованных на стадиях процесса управления инцидентами ИБ; организационной структуры процесса управления инцидентами ИБ.
Правильно организованный процесс управления инцидентами – это:
- четкое определение ролей и ответственности всех специалистов за качественное и своевременное обнаружение и реагирование на инциденты ИБ;
- оперативная информация для мониторинга эффективности принимаемых защитных мер;
- прозрачность контроля эффективности работы сотрудников структурных подразделений;
- повышение качества взаимодействия специалистов в смежных ИТ- и бизнес-подразделениях;
- превентивное определение мер по улучшению состояния ИБ.
В настоящее время законодательство Российской Федерации активно развивается в целях нормативного и методического обеспечения централизованного сбора информации об инцидентах ИБ, с дальнейшими скоординированными в масштабах всей страны действиями по предотвращению компьютерных атак и ликвидации их последствий. Вопросы оперативного выявления и своевременного реагирования на инциденты ИБ в организации стали вопросами государственной важности и влияют на безопасность Российской Федерации.
Заключение
Информационная безопасность остается сегодня важнейшим элементом развития цифровой экономики Российской Федерации. Расширение электронного взаимодействия участников рынка и масштабное использование новых информационных технологий невозможно без глубокой интеграции культуры информационной безопасности во все сферы деятельности коммерческих организаций и государственных структур страны. Политики ИБ, будучи наиболее эффективным инструментом по повышению в организациях культуры информационной безопасности, остаются значимым фактором и в современных условиях. Более того, с усилением «цифровизации» процессов экономической деятельности и государственного управления в Российской Федерации роль политик ИБ будет только возрастать.
Используемые источники:
[1] Информационный бюллетень «Архитектура и стратегия информационной безопасности Cisco».
[2] Стратегии развития холдинга «РЖД» на период до 2030 года, утвержденная советом директоров ОАО «РЖД» от 23 декабря 2013 г. № 19.
[3] Стратегия научно-технологического развития холдинга «РЖД» на период до 2025 года и на перспективу до 2030 года (Белая книга).
[4] Концепция по обеспечению кибербезопасности ОАО «РЖД.
[5] Концепция обеспечения информационной безопасности ЗАО «Страховая компания «Диана».
[6] Концепция информационной безопасности информационных систем персональных данных администрации Шемуршинского района.
[7] Концепция информационной безопасности информационных систем персональных данных ГАОУ СПО «Республиканский базовый медицинский колледж имени Э.Р. Раднаева».
[8] Концепция информационной безопасности информационных систем Министерства социальной, семейной и демографической политики Удмуртской Республики.
[9] Концепция информационной безопасности информационных систем персональных данных ООО «АТЭКС ПЛЮС».
[10] Политика информационной безопасности ФГБУ «ПИЯФ» НИЦ «Курчатовский институт».
[11] Политика информационной безопасности ГПОАУ ЯО «Ярославского педагогического колледжа».
[12] СТО БР ИББС-1.0-2014 «Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Общие положения».
[13] РС БР ИББС-2.0-2007 «Методические рекомендации по документации в области обеспечения информационной безопасности в соответствии с требованиями СТО БР ИББС-1.0».
[14] СТО БР ИББС-1.2-2014 «Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Методика оценки соответствия информационной безопасности организаций банковской системы Российской Федерации требованиям СТО БР ИББС-1.0-2014».
[15] Политика информационной безопасности комитета Ставропольского края по делам архивов.
[16] Политика информационной безопасности при работе с персональными данными в администрации Нефтекумского городского округа Ставропольского края.
[17] Политика информационной безопасности в ГАУЗ «СП №8».
[18] Политика информационной безопасности информационных систем персональных данных ГУЗ «Поликлиника №5».
[19] Политика Torex в области информационной безопасности.
[20] Политика информационной безопасности ООО «Юсодент».
[21] Соглашение о порядке защиты конфиденциальной информации и ответственности за ее разглашение при осуществлении Евразийской экономической комиссией полномочий по контролю за соблюдением единых правил конкуренции.
[22] Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных».
[23] Постановление Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных».
[24] «Кодекс Российской Федерации об административных правонарушениях» от 30.12.2001 № 195-ФЗ.
[25] Федеральный закон от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации».
[26] Федеральный закон от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации».
[27] Политика «Обработка персональных данных в ПАО «МТС» ПТ-010-3.
[28] ГОСТ Р ИСО/МЭК 27002-2012 Информационная технология (ИТ). Методы и средства обеспечения безопасности. Свод норм и правил менеджмента информационной безопасности.
[29] «План мероприятий по направлению «Информационная безопасность» программы «Цифровая экономика Российской Федерации» (утв. Правительственной комиссией по использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности (протокол от 18.12.2017 № 2).
Автор:
Валерий Комаров, специалист по защите информации, отдел методологии ИБ, Управление ИБ, ДИТ города Москвы.
Разработка
политики безопасности является ключевым
этапом построения защищенной
информационной системы или сети. Следует
отметить, что составление политики
безопасности является только началом
осуществления общей программы обеспечения
безопасности организации. Детальная
программа обеспечения безопасности
необходима для создания эффективной
системы безопасности организации на
основе разработанной политики
безопасности.
3.3.1 Основные этапы обеспечения безопасности
Основными
этапами программы обеспечения безопасности
являются следующие:
-
определение
ценности технологических и информационных
активов организации; -
оценка
рисков этих активов (сначала путем
идентификации тех угроз, для которых
каждый актив является целевым объектом,
а затем оценкой вероятности того,
что эти угрозы будут реализованы на
практике); -
установление
уровня безопасности, определяющего
защиту каждого актива, то есть мер
безопасности, которые можно считать
рентабельными для применения; -
формирование
на базе предыдущих этапов политики
безопасности организации; -
привлечение
необходимых финансовых ресурсов для
реализации политики безопасности,
приобретение и установка требуемых
средств безопасности; -
проведение
разъяснительных мероприятий и обучения
персонала для поддержки сотрудниками
и руководством требуемых мер безопасности; -
регулярный
контроль пошаговой реализации плана
безопасности с целью выявления текущих
проблем, учета изменения внешнего
окружения и внесение необходимых
изменений в состав персонала.
Опыт
показал, что в целом организации получают
существенную выгоду от реализации
хорошо разработанной методологии
решения указанных выше задач. К политикам
безопасности предъявляются следующие
основные требования:
-
политики
безопасности должны:
-
указывать
цели и причины, по которым нужна политика; -
описывать,
что именно охватывается этими политиками; -
определить
роли, обязанности и контакты; -
определить,
как будут обрабатываться нарушения
безопасности;
-
политики
безопасности должны быть:
-
реальными
и осуществимыми; -
краткими
и доступными для понимания; -
сбалансированными
по защите и производительности [22].
Первыми
шагами по разработке политики безопасности
являются следующие:
-
создание
команды по разработке политики; -
принятие
решения об области действия и целях
политики; -
принятие
решения об особенностях разрабатываемой
политики; -
определение
лица или органа для работы в качестве
официального интерпретатора политики.
Ко
всем разрабатываемым политикам
безопасности целесообразно применять
унифицированный процесс проектирования
с единообразными требованиями к
политикам.
Одним
из первых шагов является создание
команды по разработке политики
безопасности организации. Иногда
эту команду называют группой, комиссией
или комитетом. Команда создается
руководством организации, которое
должно осознавать важность информационной
безопасности и полностью реализовать
свою позитивную роль в успешной
разработке, принятии и внедрении этой
политики.
В
состав команды следует включать
квалифицированных специалистов, хорошо
разбирающихся в требованиях бизнеса,
информационных технологиях и безопасности,
юриста и члена руководства, который
сможет проводить в жизнь эту политику
безопасности. К работе этой команды
должны быть также привлечены администраторы
безопасности и системные администраторы,
представитель от сообщества пользователей.
Размер
команды по разработке политики зависит
от масштаба и области действия политики.
Крупномасштабные политики могут
потребовать команды из 5-10 человек, в то
время как для политик небольшого масштаба
достаточно только одного или двух
человек.
Как
только создана такая команда, ее первым
шагом является анализ
требований бизнеса. Члены
команды с различными позициями и точками
зрения должны проанализировать требования
бизнеса к использованию компьютерных
и сетевых сервисов. Когда мнения некоторых
членов этой команды не совпадают,
столкновения их интересов и пересечения
разных отраслей знания при обсуждении
требований бизнеса позволяют получить
более полную и объективную картину, чем
при обычном опросе людей, работающих
в области маркетинга, продаж или
разработки [22].
На
этом этапе анализируются и решаются
следующие вопросы. Какие компьютерные
и сетевые сервисы требуются для бизнеса
и как эти требования могут быть
удовлетворены при условии обеспечения
безопасности? Скольким сотрудникам
требуется доступ в Интернет, использование
электронной почты и доступ к
intranet-сервисам?
Зависят ли компьютерные и сетевые
сервисы от удаленного доступа к внутренней
сети? Имеются ли требования по доступу
к Web?
Требуются ли клиентам данные технической
поддержки через Интернет? При анализе
каждого сервиса следует обязательно
задаваться вопросом: «Имеется ли
требование бизнеса на этот сервис?» Это
самый важный вопрос.
После
анализа и систематизации требований
бизнеса команда по разработке политики
безопасности переходит к анализу и
оценке рисков. Использование информационных
систем и сетей связано с определенной
совокупностью рисков. Анализ рисков
является важнейшим этапом формирования
политики безопасности (рисунок 3.2).
Иногда этот этап называют также анализом
уязвимостей или оценкой угроз. Хотя эти
термины имеют несколько различающиеся
толкования, конечные результаты сходны.
|
|
|
Рисунок |
На
этапе анализа рисков осуществляются
следующие действия:
-
идентификация
и оценка стоимости технологических и
информационных активов; -
анализ
тех угроз, для которых данный актив
является целевым объектом; -
оценка
вероятности того, что угроза будет
реализована на практике; -
оценка
рисков этих активов [23].
Оценка
риска выявляет как наиболее ценные, так
и наиболее уязвимые активы, она позволяет
точно установить, на какие проблемы
нужно обратить особое внимание. Отчет
об оценке рисков является ценным
инструментом при формировании политики
сетевой безопасности.
После
оценки рисков активов можно переходить
к установлению
уровня безопасности, определяющего
защиту каждого актива, то есть мер
безопасности, которые
можно считать рентабельными для
применения.
В
принципе, стоимость
защиты конкретного актива не должна
превышать стоимости самого актива.
Необходимо
составить подробный перечень всех
активов, который включает такие
материальные объекты, как серверы и
рабочие станции, и такие нематериальные
объекты, как данные и программное
обеспечение. Должны быть идентифицированы
директории, которые содержат
конфиденциальные файлы или файлы
целевого назначения. После идентификации
этих активов должно быть проведено
определение стоимости замены каждого
актива с целью назначения приоритетов
в перечне активов.
Для
контроля эффективности деятельности
в области безопасности и для учета
изменений обстановки необходима
регулярная
переоценка рисков.
После
проведения описанной выше работы можно
переходить к непосредственному
составлению политики безопасности. В
политике безопасности организации
должны быть определены используемые
стандарты, правила и процессы безопасности.
Стандарты
указывают,
каким критериям должно следовать
управление безопасностью. Правила
подробно
описывают принципы и способы управления
безопасностью. Процессы
должны
осуществлять точную реализацию правил
в соответствии с принятыми стандартами.
Кроме
того, политика безопасности должна
определить значимые для безопасности
роли
и
указать ответственности
этих ролей. Роли
устанавливаются во время формулирования
процессов [22].
Обычно
процесс
состоит
из одного или более действий, где каждое
действие
включает
четыре компонента (рисунок 3.3):
-
Вход,
например
запрос пользователем нового пароля. -
Механизм,
реализующий
данное действие и указывающий средства
или роли, с помощью которых это действие
выполняется. Другими словами, механизм
определяет, какие роли вовлечены в это
конкретное действие. В нашем примере
такими ролями являются пользователь,
запрашивающий новый пароль, и администратор
безопасности. -
Управление,
описывающее
алгоритм или условия, которые управляют
этим действием. Например, стандарт
может задать следующее условие: при
запросе нового пароля инициатор запроса
должен успешно пройти аутентификацию. -
Выход,
который
является результатом этого действия.
В нашем примере таким выходом является
сообщение пользователю нового пароля.
Связывая
вместе все действия, входящие в процесс,
мы получаем точное представление
результирующего процесса и ролей,
необходимых для исполнения этого
процесса. В данном примере процесс
состоит из одного действия — обновления
пароля пользователя; роли идентифицируются
как Пользователь и Администратор
безопасности. Стандарты, правила и
процессы должны быть документированы
в рамках политики для целей аудита.
|
|
|
Рисунок |
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
Нашли ошибку? Пожалуйста, напишите нам.
Если вы хотите разместить публикацию, перейдите на страницу Добавить материал.
Если вы хотите вступить в клуб, пожалуйста, зарегистрируйтесь (вход тут).
Если вы хотите воспользоваться платными услугами, напишите нам, указав компанию, которую вы представляете, а также продукт или услугу, которые вы хотите рекламировать.
PR сервис от CISOCLUB в Telegram: t.me/cisoclub_pr.