Обзор Средства защиты информации и бизнеса 2006	подготовлен	При поддержке

Внутренние стандарты и регламенты в России и на Западе

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

Согласно принятому в июле 2006 г. Федеральному закону N149-ФЗ «Об информации, информационных технологиях и защите информации», одной из задач, которая должна быть решена для обеспечения безопасности информационных систем, является «предотвращение несанкционированного доступа к информации и (или) передачи ее лицам, не имеющим права на доступ к информации». Эта задача описывает общее направление, но не конкретизирует с помощью каких решений ее можно решить. Если опуститься на уровень ниже и обратиться, например, к стандарту Банка России по информационной безопасности, то мы увидим, что данная задача может быть решена с помощью широкого спектра защитных средств — межсетевые экраны, система предотвращения атак, система аутентификации и т.д.

Достаточно ли такой детализации? На уровне отраслевого стандарта да, но для конкретной организации этого мало — слишком много альтернатив — Cisco, Check Point, Juniper и т.д. Поэтому, какие бы грамотные законы и стандарты безопасности не существовали, они должны быть дополнены соответствующим преломлением в рамках конкретной организации — в виде внутренних регламентов и стандартов.

Иерархия стандартов и регламентов по информационной безопасности

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

Россия и Запад: форма или содержание

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

На Западе никто не спорит, что такая единая система нужна, но там она носит название «политика безопасности» (Security Policy). Кстати, если внимательно изучить западные материалы по информационной безопасности, вы нигде не встретите термина «Концепция информационной безопасности». По отношению к отдельным компаниям его просто не существует. Если этот термин и встречается, то только по отношению к целым государствам. Западные компании редко имеют документ, который был бы похож на наши «Концепции». Если они и есть, то это скорее некие заявления о безопасности (Security Statement), которые не рассчитаны на специалистов по защите информации и призваны показать внимание руководства компании к проблеме, не вдаваясь в технические детали (пример такого Security Statement может быть найден по адресу: http://www.japan-telecom.co.jp/english/security/).

Для специалистов же есть набор конкретных документов, рассматривающих отдельные вопросы обеспечения информационной безопасности предприятия — политика аудита, парольная политика, политика оценки рисков, политика защиты Web-сервера, политика работы с электронной почты и т.п. Все по делу, никакой воды. Возьмем, к примеру, некоторые из политик компании Cisco. Парольная политика — 3 страницы, 6700 знаков. Политика анализа рисков — 2 страницы, 4600 знаков. Политика защиты сетевого оборудования — 1 страница, 2800 знаков. Самая большая политика насчитывает всего 8 страниц и 18200 знаков; это политика классификации информации. При необходимости политика может ссылаться на дополнительные инструкции и руководства. Например, в случае с уже упомянутой парольной политикой, в подразделе «Создание паролей» идет ссылка на специальное руководство по правильному выбору паролей (1 страница, 2900 знаков).

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

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

Из чего состоит регламент?

Что же должен включать регламент информационной безопасности? В нем должны быть лаконично, но конкретно описаны требования к защите отдельного процесса. Так, регламент Cisco включает всего семь разделов (их число превышает «магическую» семерку только в очень редких случаях).

Введение описывает необходимость появления данного документа. В ряде случаев опускается.
Цель данного регламента — в данном разделе обозначены цели, которые мы хотим достичь данным документом. Например, для регламента управления паролями, это будет «установление стандартов для создания «сильных» паролей, их защиты и регулярной смены».
Область применения. Здесь описываются объекты или субъекты, которые должны выполнять требования данного регламента. Например, «данный регламент применяется ко всем сотрудникам, имеющим любую форму доступа к любым информационным ресурсам компании».
Регламент описывает сами требования. Например, регламент управления паролями в компании Cisco содержит 5 подразделов — «Создание паролей», «Изменение паролей», «Защита паролей», «Использование паролей при разработке приложений», «Использование паролей при удаленном доступе».
Ответственность. Описывает наказание за нарушение указанных в предыдущем разделе требований.
Заканчивается  документ разделами  термины и определения и историей изменений данного регламента. Последний пункт позволяет отследить все вносимые в документ изменения (дата, автор, краткая суть изменения).

Такая структура позволяет оставаться лаконичным и в сжатой форме (на 2-3 страницы) описать все основные моменты, связанные с предметом регламента безопасности.

Классификация регламентов

Когда говорят о регламентах и стандартах по информационной безопасности, то вспоминают обычно только об одном из их типов — операционных, описывающие сугубо технические процедуры такие как, например, конфигурирование средств защиты демилитаризованной зоны, реагирование на инциденты безопасности, интеграция различных защитных систем и т.д. А ведь это только верхушка айсберга или точнее его основание. Помимо операционных регламентов можно выделить еще 2 класса документов, стандартизующие вопросы безопасности в компании — это стратегические и бизнес-ориентированные. Первые очень похожи на наши «Концепции…», но носят более конкретный характер. Примером таких регламентов могут служить стандарты, в основе которых лежат ISO 17799 и 27001, ISO 13335, MITS, документы FIPS и GAO и т.д. Второй тип стандартов ориентирован на отличную от «безопасников» аудиторию — юристов, аудиторов, руководство компании (совет директоров и т.д.) и т.п. К ним относятся документы, в основе которых лежат требования HIPAA, FISMA, COSO, CoBIT и т.д.

Какие регламенты должны быть разработаны?

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

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

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

Во-вторых, портативные мобильные устройства — USB-диски, «флешки», iPod’ы и MP3-плееры, цифровые фотоаппараты. Первые два названных типа устройства миниатюрны, а значит, их можно незаметно пронести в офис и вынести всю конфиденциальную информацию. Оставшиеся типы устройств не воспринимаются как носители информации, но могут идеально выполнять эту роль.

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

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

В-пятых, беспроводные пользователи. Технология Wi-Fi повышает не только производительность сотрудников, но и опасность неконтролируемого проникновения внутрь защищаемой сети. Необходимо иметь политику использования точек беспроводного доступа в своей компании. И даже если у вас не разрешено использовать эту новую и эффективную технологию, то ваши пользователи могут придерживаться противоположного мнения. По статистике почти 99% всех несанкционированных установок точек беспроводного доступа совершают «нетерпеливые» сотрудники, жаждущие мобильности и повышения эффективности своей работы. А значит, необходимо регулярно контролировать радиоэфир в поисках несанкционированных беспроводных включений.

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

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

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

Нередко компании, не найдя на рынке необходимого программного обеспечения, самостоятельно занимаются его разработкой. При этом нельзя забывать о безопасности такого кода. К сожалению, большинство разработчиков сосредоточено на создании новых функций, а не на устранении ошибок, которых в среднем на 1000 строк кода существует 13-15. Учитывая, что обычное приложение содержит несколько десятков тысяч строк кода, то можно себе представить, сколько потенциальных проблем с безопасностью может возникнуть. Правила создания, и тестирования кода также должны быть задокументированы. 

Еще одним слабым местом являются бизнес-приложения. Говоря выше о наличие регламентов безопасности для приложений, имелось ввиду, что обычно они создаются для часто используемых пользовательских приложений, таких как браузеры, MS Office и т.п. Однако для бизнеса гораздо более важны ERP, CRM, SCM, SCADA-системы и различные СУБД, безопасность которых должна быть обеспечена в первую очередь. Однако на практике именно этот аспект ускользает из внимания специалистов по защите, которые обычно сосредотачивают свои усилия на сетевой безопасности.

Отдельное направление, которое обязательно должно учитываться в регламентах — взаимодействие приложений. Если о связи узлов на сетевом уровне написано уже немало, то о взаимодействии отдельных приложений (например, по протоколу SOAP или XML) обычно забывают, потому что это гораздо более серьезная тема, чем просто контроль IP-трафика — на этом уровне надо понимать бизнес-логику. Мало уметь обнаруживать атаки — надо реагировать на них, причем делать это быстро, не допуская ошибок. Чтобы следовать четкой процедуре, не отклоняясь от нее ни на шаг, и нужен соответствующий регламент.

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

Также должны быть прописаны правила взаимодействие с правоохранительными органами или операторами связи. Что делать, если ваш сайт взломали или на вашу компания совершается DoS-атака? К кому идти? Куда звонить? Именно эти вопросы описываются в регламенте взаимодействия с внешними структурами, ответственными за реагирование на инциденты.

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

Алексей Лукацкий