Необходимость формализованной — то есть изложенной в письменном виде и утвержденной руководством — политики информационной безопасности в настоящее время осознается большинством предприятий. Рассмотрим различные аспекты формирования эффективных нормативных документов по обеспечению информационной безопасности.

Три причины формализации

Главной причиной появления политики безопасности обычно является требование наличия такого документа от регулятора — организации, определяющей правила работы предприятий данной отрасли. В этом случае отсутствие политики может повлечь репрессивные действия в отношении предприятия или даже полное прекращение его деятельности.

Кроме того, определенные требования (рекомендации) предъявляют отраслевые или общие, местные или международные стандарты. Обычно это выражается в виде замечаний внешних аудиторов, проводящих проверки деятельности предприятия. Отсутствие политики вызывает негативную оценку, которая в свою очередь влияет на публичные показатели предприятия — позиции в рейтинге, уровень надежности и т.д.

Еще одной причиной является внутреннее осознание руководством предприятия необходимости структурированного подхода к обеспечению определенного уровня безопасности. Обычно такое осознание наступает после внедрений ряда технических решений по безопасности, когда возникают проблемы управления такими решениями. Иногда сюда добавляются вопросы обеспечения безопасности персонала (Human Resources Security, куда входит как защита самих работников, так и защита от них), юридические аспекты и другие факторы, приводящие руководство предприятия к пониманию того, что обеспечение информационной безопасности выходит за рамки чисто технических мероприятий, проводимых ИТ-подразделением или другими специалистами.

Интересно, что, согласно исследованию по безопасности, проведенному компанией Deloitte в 2006 году, предприятия, которые имеют формализованные политики информационной безопасности, значительно реже подвергаются взлому. Это свидетельствует о том, что наличие политики является признаком зрелости предприятия в вопросах информационной безопасности. То, что предприятие внятно сформулировало свои принципы и подходы к обеспечению информационной безопасности означает, что в этом направлении была проделана серьезная работа.

Неэффективные политики

Само по себе наличие документа, озаглавленного «Политика информационной безопасности», не принесет существенной пользы предприятию, кроме, быть может, формального аргумента в споре, присутствует или отсутствует у него данная политика. Нас интересует, разумеется, в первую очередь эффективная политика безопасности.

Опыт показывает, что неэффективные политики безопасности можно разделить на хорошо сформулированные, но не практичные и на практичные, но плохо сформулированные.

Первая категория чаще всего встречается в случаях, когда специалисты по безопасности предприятия недолго думая берут готовую политику (скажем, из Internet) и, проведя минимальные изменения, утверждают ее для своего предприятия. Поскольку общие принципы безопасности у разных предприятий, даже различных отраслей, могут быть весьма схожи, такой подход достаточно широко распространен. Однако его использование может привести к проблемам, если от политики верхнего уровня понадобится спуститься к документам нижнего уровня — стандартам, процедурам, методикам и т.д. Поскольку логика, структура и идеи исходной политики были сформулированы для другого предприятия, возможно возникновение серьезных затруднений, даже противоречий в остальных документах.

Политики второй категории обычно появляются в случаях, когда возникает необходимость решить сиюминутные задачи. Например, сетевой администратор, устав бороться с попытками пользователей нарушать работу сети, в течение десяти минут набрасывает список из нескольких «можно» и «нельзя», называет его «Политикой» и убеждает руководство в необходимости его утверждения. Потом этот документ может годами использоваться на предприятии, создавая порой существенные проблемы, например при внедрении новых систем, и порождая огромное количество исключений для случаев, когда его нарушение допускается.

Создание эффективной политики

Как же разработать эффективную, практичную и хорошо сформулированную политику информационной безопасности, которая позволит предприятию не просто создать стройную систему нормативных документов, но и принесет определенные финансовые преимущества, например, сохранив инвестиции или предотвратив неэффективные вложения средств?

Понятия и документы

Сначала, как всегда, необходимо договориться о терминах. Под англоязычным термином policy понимают обычно достаточно широкий спектр документов. Порой, говоря о такой политике, даже подразумевают весь набор нормативной документации по информационной безопасности на предприятии. Мы же будем использовать следующие понятия:

  • концепция — политика верхнего уровня, определяющая общие принципы информационной безопасности для предприятия;
  • стандарты или правила — политики по отдельным направлениям информационной безопасности предприятия, формулирующие принципы и правила для данного направления;
  • процедуры — документы, описывающие права и обязанности участников одного или нескольких логически объединенных процессов обеспечения информационной безопасности;
  • инструкции или методики — документы, детально описывающие, как и что должно делаться в рамках направления, процесса или системы для обеспечения соответствия стандартам.

Поскольку мы будем говорить в основном о документе верхнего уровня, то есть о концепции, следует избегать попыток назвать его стратегией. В данном случае концепция — это статичный документ, определяющий принципы, а стратегия — динамический документ, определяющий цели и пути их достижения.

Кроме того, в общей схеме нормативного обеспечения информационной безопасности следует выделить документы, которые условно можно отнести к аварийному плану. Здесь тоже существуют понятия, которые иногда путают между собой. Наиболее известные из них пришли из западных практик безопасности, это план восстановления информационных систем после аварии или катастрофы (Disaster Recovery Plan, DRP); анализ негативных последствий реализации угроз информационной безопасности для бизнес-процессов предприятия (Business Impact Analysis, BIA); план восстановления бизнес-процессов после наступления негативных событий (Business Continuity Plan, BCP).

Начиная разрабатывать очередной документ, следует помнить о том, какое место он займет в общей структуре нормативного обеспечения предприятия. Поскольку все документы должны быть, с одной стороны, непротиворечивы, а с другой — взаимосвязаны, выбрать правильное место документа в структуре немаловажно. Соответственно, если при планировании разработки документа его будущее место в иерархии не может быть определено, возможно следует пересмотреть формат документа. Быть может, для сохранения логичности его надо разбить на два или более документов, либо, наоборот, включить отдельным разделом в уже существующий документ.

Иерархическая структура нормативного обеспечения

Структура концепции

Вернемся к рассмотрению политики верхнего уровня — концепции. Стандарт ISO 17799:2005 (раздел 5.1.1) описывает примерную структуру этого документа, который должен содержать разделы: определение информационной безопасности, ее цели и масштаб; поддержка информационной безопасности руководством предприятия в соответствии с бизнесом; структура информационной безопасности, описание контрольных механизмов, оценка и управление рисками; принципы и стандарты информационной безопасности, характерные для данного предприятия; роли и ответственность в области информационной безопасности; ссылки на прочие документы по безопасности.

Кроме того, целесообразно включить раздел, описывающий ключевые индикаторы производительности или другие виды метрик оценки эффективности работы в области информационной безопасности. Такие критерии верхнего уровня необходимы, с одной стороны, для руководителей предприятия, чтобы они имели возможность оценивать уже проделанную работу в области информационной безопасности, не углубляясь в технические подробности. С другой стороны, озвученные формализованные критерии позволяют руководителю по безопасности иметь представление о том, как будет оцениваться его работа.

Вот примеры таких высокоуровневых метрик.

Результаты внутренних и независимых проверок работы системы управления информационной безопасностью (СУИБ) в соответствии с установленным жизненным циклом. В отчет обязательно должен быть включен раздел, в котором указана оценка СУИБ в целом, а также по направлениям, перечисленным в методике проведения оценки, и определено состояние: соответствует требованиям, не соответствует, отсутствует или неприменимо.

Количество и детализация идентифицированных информационных рисков, подробное описание соответствующих им угроз и уязвимостей. Результат работ должен иметь прикладное значение, то есть риски должны быть описаны подробно, для удобства их последующего анализа. Кроме того, риски должны быть увязаны с угрозами или уязвимостями (группами уязвимостей). Как минимум должны быть рассмотрены риски, связанные с нарушением конфиденциальности, целостности и доступности.

Точность количественных показателей в оценке рисков. Если при оценке рисков применяется количественный подход, признаком качества процесса является точность определения размера потенциального ущерба и вероятности реализации события. Дополнительным инструментом оценки может быть отслеживание отраслевой (национальной или международной) статистики сходных негативных событий и сравнение с собственными прогнозными расчетами.

Количество принятых советом по информационной безопасности (или аналогичным органом на предприятии) решений по выработке мер противодействия рискам. Соотнеся количество указанных угроз и количество принятых соответствующих им решений, можно оценить качество управления информационной безопасностью.

Полнота и точность планов мероприятий по противодействию рискам. В планах должны быть обозначены наименование мероприятия, отдельные этапы, их описания, сроки выполнения и ответственное лицо.

Соответствие фактически внедренных решений по мерам противодействия утвержденным планам. Несвоевременное внедрение запланированных решений выявляется сравнением утвержденных планов внедрения и протоколов ввода в эксплуатацию соответствующих решений.

Освоение утвержденного бюджета по информационной безопасности. Низкое освоение бюджета свидетельствует об ошибках в планировании мероприятий по безопасности.

Оперативность и адекватность принимаемых мер по совершенствованию СУИБ или отдельных решений в соответствии с новыми появляющимися направлениями бизнеса, технологическими возможностями, условиями работы, атаками и уязвимостями и другими факторами. Поскольку можно с высокой степенью точности установить дату возникновения большинства появляющихся угроз, срок реализации мер противодействия демонстрирует оперативность реакции СУИБ.

Перечислим, на что еще следует обратить внимание в некоторых разделах концепции информационной безопасности.

Поддержка руководством предприятия мероприятий по информационной безопасности. Порой данный раздел не включается в политики вообще, либо состоит из одной — двух общих фраз о том, что безопасность важна и поддерживается руководством. Совершенно очевидно, что этот раздел должен быть более подробным. В нем, например, может содержаться принципиальный ответ на вопрос, возможно ли развитие того или иного направления бизнеса, если его безопасность не может быть обеспечена; отмечено, что никакое решение в области ИТ не может быть принято (никакое совещание не может быть проведено, никакой документ не может быть утвержден) без согласования с подразделением по информационной безопасности.

Определив соответствующие положения в данном разделе, мы можем избежать ряда проблем. Например, известны случаи, когда бизнес-пользователь злоупотребляет предоставленным ему доступом к Internet настолько, что наиболее эффективным вариантом является лишение его этого доступа как минимум до проведения расследования. С другой стороны, статус этого пользователя либо его функции требуют наличия постоянного доступа к Internet. В таком случае без соответствующего ранжирования приоритетов не обойтись, и во избежание злоупотреблений такие приоритеты должны быть закреплены документально.

Роли и ответственность

Распределение ролей и ответственностей потребуется во многих документах по безопасности. Поэтому принципиальное разделение целесообразно произвести уже в концепции. Предлагаются следующие типовые роли и ответственность участников процессов обеспечения информационной безопасности.

Владелец информационного ресурса — сотрудник, несущий конечную ответственность за информационную безопасность ресурса и определяющий правила использования ресурса. Владелец ресурса организует обеспечение информационной безопасности своего ресурса в виде формализованных правил, технических политик, настроек конфигурации, организационных мероприятий и регламентов.

Пользователь ресурса — сотрудник или привлеченный работник, использующий ресурс для своих производственных задач и несущий ответственность в соответствии с корпоративными стандартами в рамках правил, определенных владельцем.

Администратор ресурса — сотрудник, ответственный за применение правил использования ресурса, определенных владельцем. Администратор обязан осуществить и поддерживать настройку среды работы ресурса для применения технических средств, обеспечивающих поддержку правил использования ресурса. Он должен сообщать контролеру и/или владельцу о нарушениях, недостатках и ошибках, выявленных при работе с ресурсом.

Контролер ресурса — сотрудник, ответственный за соответствие ресурса правилам, которые установлены владельцем. Контролер обязан имеющимися средствами мониторинга и аудита обеспечить уверенность в соблюдении пользователями и администраторами правил использования ресурса либо выявлять факты нарушения таких правил. Он обязан принять меры для прекращения и предотвращения нарушений.

Подобное распределение ролей хорошо тем, что позволяет правильно планировать процессы и обязанности отдельных субъектов. Если при разработке документа обнаруживается, что роли пересекаются, это дает повод усомниться в правильности планирования данного процесса либо распределения обязанностей его субъектов.

Взаимоотношения

В данном разделе необходимо определить, например, взаимоотношения службы информационной безопасности со службой ИТ. Это поможет решить потенциальные конфликтные ситуации, в том числе в области бюджетов этих служб или полномочий представителей служб в отдельных информационных системах. Типовым разделением является придание ИТ-подразделению роли администратора, а службе информационной безопасности — роли контролера.

Кроме того, в разделе можно указать, на каких принципах строятся отношения со сторонними организациями, подразделив их на вышестоящие, партнерские и нижестоящие или подведомственные. Соответственно, необходимо определить, чьи стандарты безопасности будут приниматься, если выяснилось, что стандарты сторонней организации оказались выше или ниже стандартов вашего предприятия.

О чем не надо писать

При разработке концепции и других документов по безопасности важно оставаться в области применения данного документа. В противном случае придется в разных документах описывать подходы к одному и тому же процессу, а это может привести к возникновению противоречий или требованию избыточных ресурсов при выполнении процесса.

Например, в политике по конкретному направлению не стоит подробно описывать случаи нарушения этой политики, если, конечно, разрешение ситуации не требует специального подхода. В таком случае целесообразно сослаться на отдельную политику, например, по управлению инцидентами или нарушениями информационной безопасности. Такой вариант позволит единообразно реагировать на нарушения безопасности.

Другим негативным примером может быть описание общих принципов предоставления доступа или выбора пароля в каждой отдельной политике для конкретной информационной системы или сервиса. Целесообразнее в таких случаях отсылать к общей политике предоставления доступа или парольной политике.

Не стоит запрещать то, что все равно будет нарушаться, при условии, конечно, что эти нарушения не обернутся критическими последствиями для предприятия. Иначе массовость нарушений не позволит регулярно реагировать на них. А отсутствие реагирования на инциденты приведет нарушителей к мысли, что игнорировать требования безопасности допустимо. Например, не стоит запрещать неслужебную переписку по электронной почте или Web-серфинг Internet. Целесообразнее отметить, что такое использование не должно негативно влиять на выполнение сотрудником своих обязанностей либо указать конкретные разрешенные рамки — допустимое время, объем и т.д.

Документы не должны налагать обязанности, которые практически невыполнимы. Это также будет провоцировать сотрудников на нарушение политик. Например, до сих пор в документах по безопасности встречаются требования ежедневного полного сканирования жесткого диска рабочей станции на наличие вирусов. Или требование оформлять каждый, даже самый мелкий инцидент как письменный рапорт. Понятно, что буквальное выполнение таких требований может просто парализовать бизнес-процесс.

Документы не должны описывать то, для выполнения чего нет условий. В данном случае де-факто придется нарушать требование безопасности, что также приводит сотрудников к сомнению в незыблемости политик. Например, в документах может присутствовать требование к изъятию или проверке всех внешних носителей, поступающих в здание, где расположено предприятие. Однако многообразие современных средств хранения информации не позволяет их обнаружить без серьезной дорогостоящей аппаратуры. Даже случайно забыв предъявить внешний носитель и обнаружив, что он не был идентифицирован и изъят либо проверен, сотрудник или посетитель может составить мнение, что и другие требования политик можно обойти. При необходимости строгого контроля за внешними носителями целесообразнее использовать технические средства предотвращения несанкционированного копирования информации.

Лучшие практики

В заключение хотелось бы обратить внимание на контроль-ориентированный подход в области информационной безопасности. Применение контрольного механизма или контрольной процедуры позволяет обозначить точки приложения внимания при построении системы управления информационной безопасностью. Из аудиторской практики известно, что контроль может быть признан эффективным, если для него определены четыре параметра:

  • кто выполняет контроль — роль, должность или конкретный сотрудник, в обязанности которых входит выполнение соответствующих процедур;
  • когда выполняется контроль — указание срока или условий, когда необходимо выполнить процедуры;
  • что делается в рамках контроля — описание самих процедур;
  • свидетельства выполнения контроля — что остается по результатам выполнения процедур и на основании чего можно проверить факт и качество их выполнения.

При описании контролей в стандартах или процедурах разработчику политик стоит придерживаться именно такой схемы изложения, описывая все четыре параметра для каждой из процедур или отдельных процессов процедуры. Таким образом он обеспечит однозначное понимание сути процедуры и определит структуру эффективного контроля.

Искандер Конеев — менеджер группы технической интеграции, «Делойт и Туш СНГ», ikoneev@deloitte.ru