Управление непрерывностью услуг и информационной безопасностью в рамках этапа Проектирования. Управление поставщиками. Система управления информационной безопасностью «Базовый уровень информационной безопасности операторов связи

Доброго времени суток, уважаемые!
Давно не писал на Хабр, не было времени, много работы было. Но теперь разгрузился и сформировались мысли для нового поста.

Общался с одним из товарищей, на которого взвалили труд по ИБ в организации (товарищ сисадмин), и он просил рассказать с чего начать и куда двигаться. Немного привёл мысли и знания в порядок и выдал ему примерный план.
К сожалению, такая ситуация далеко не единична и встречается часто. Работадатели, как правило, хотят что бы был и швец и жнец и на дуде игрец и всё это за один прайс. К вопросу о том, почему ИБ не нужно относить к ИТ я вернусь позже, а сейчас всё-таки рассмотрим с чего вам начинать, если такое случилось и вы подписались на подобную авантюру, то есть создание системы управления информационной безопасностью (СУИБ).

Анализ рисков

• Вероятность реализации
• Уязвимость

Риск - это возможность понести какие-либо потери (денежные, репутационные и тд), в связи с реализацией уязвимости.
Вероятность реализации - это насколько вероятно, что данная уязвимость будет эксплуатирована для реализации риска.
Уязвимость - непосредственно брешь в вашей системе безопасности, которая с некоей долей вероятности может нанести вред, то есть реализовать риск.

Есть множество методик, различных подходов к управлению рисками, расскажу об основах, остальное вам на первых порах в становлении СУИБ и не понадобится.
Итак вся работа по управлению рисками сводится либо к снижению вероятности реализации, либо к минимизации потерь от реализации. Соответственно риски могут быть приемлемыми и неприемлемыми для организации. Приемлемость риска лучше всего выражать в конкретных суммах потерь от его реализации (в любом случае даже, вроде бы, неосязаемые репутационные потери в итоге выливаются в упущенную прибыль). Необходимо решить с руководством какая сумма для них будет порогом приемлемости и сделать градацию (лучше 3-5 уровней для потерь). Далее сделать градацию по вероятности, так же как с потерями и потом оценивать риски по сумме этих показателей.
После проведения подготовительной работы, выделите реальные уязвимости вашей организации и проведите оценку рисков их реализации и потерь. В итоге вы получите 2 набора рисков - приемлемых и неприемлемых. С приемлемыми рисками вы просто смиритесь и не будете предпринимать активных действий по их минимизации (то есть мы принимаем, что минимизация этих рисков будет нам стоить дороже потерь от них), а с неприемлемыми есть 2 варианта развития событий.

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

Масштабы

Политика информационной безопасности

Концепция информационной безопасности

Положение о коммерческой тайне (конфиденциальной информации)

Аудит

Политика доступа

Физический доступ

Доступ в информационные системы

Построение сети

Удаленный доступ

Инциденты

Активы

Обучение

Заключение

P.S. если ставите минус, прокомментируйте, пожалуйста, дабы в будущем мне не допускать подобных ошибок.

Теги: Добавить метки

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

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

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

Процесс Управления Информационной Безопасностью способствует интеграции аспектов безопасности в ИТ-организацию с точки зрения поставщика услуг. Сборник практических рекомендаций по Управлению Информационной Безопасностью (BS 7799) дает руководство для разработки, введения и оценки мер безопасности.

15.1.1. Основные понятия

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

Конфиденциальность – защита информации от несанкционированного доступа и использования.

Целостность – точность, полнота и своевременность информации.

Доступность – информация должна быть доступна в любой момент предварительного согласованного временного интервала. Это зависит от непрерывности работы систем обработки информации.

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

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

Процесс Управления Информационной Безопасностью имеет две цели:

Выполнение требований безопасности, закрепленных в SLA и других требованиях внешних договоров, законодательных актов и установленных правил;

Обеспечение базового Уровня Безопасности, независимого от внешних требований.

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

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

15.2.1. Преимущества использования процесса

Информационная безопасность не является самоцелью; она должна служить интересам бизнеса и организации. Некоторые виды информации и информационных услуг являются для организации более важными, чем другие. Информационная безопасность должна соответствовать Уровню Важности Информации. Безопасность планируется путем соблюдения баланса между мерами безопасности, ценностью информации и существующими угрозами в среде обработки. Эффективное информационное обеспечение с адекватной защитой информации важно для организации по двум причинам:

Внутренние причины : эффективное функционирование организации возможно только при наличии доступа к точной и полной информации. Уровень Информационной Безопасности должен соответствовать этому принципу.

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

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

Организации и их информационные системы меняются. Стандартные шаблоны, такие как Сборник практических рекомендаций по Управлению Информационной Безопасностью (Code of Practice for Information Security Management), статичны и недостаточно соответствуют быстрым изменениям в ИТ. По этой причине деятельность, ведущаяся в рамках Процесса Управления Информационной Безопасностью, должна постоянно пересматриваться в целях обеспечения эффективности Процесса. Управление Информационной Безопасностью сводится к никогда не прекращающемуся циклу планов, действий, проверок и актов. Виды деятельности, проводимые в рамках процесса Управления Информационной Безопасностью или в других процессах под контролем Управления Информационной Безопасностью, описываются ниже.

Рис. 15.1. Процесс Управления Информационной Безопасностью (источник: OGC)

Требования заказчика изображены в правом верхнем углу, как входные данные процесса. Эти требования определяются в разделе о безопасности Соглашения об Уровне Сервиса как услуги по безопасности и обеспечиваемый Уровень Безопасности. Поставщик услуг доводит эти соглашения до ИТ-организации в форме Плана по безопасности, определяющего критерии безопасности или операционные Соглашения об Уровне Услуг. Этот план исполняется и результаты оцениваются. Затем план и способы его реализации корректируются, о чем Управление Уровнем Сервиса сообщает заказчику. Таким образом, заказчик и поставщик услуг вместе участвуют в формировании всего цикла процесса. Заказчик может изменить требования на основе получаемых отчетов, а поставщик услуг может скорректировать план или его реализацию на основе результатов наблюдения или поставить задачу изменения договоренностей, определенных в соглашении SLA. Функция контроля представлена в центре рисунка 15.1. Далее эта диаграмма будет использоваться при описании видов деятельности Процесса Управления Информационной Безопасностью.

15.3.1. Взаимоотношения с другими процессами

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

Рис. 15.2. Отношения между Процессом Управления Информационной безопасностью и другими процессами (источник: OGC)

Управление Конфигурациями

В контексте информационной безопасности процесс Управления конфигурациями имеет наибольшее значение, так как он позволяет классифицировать Конфигурационные Единицы (CI). Эта классификация определяет связи между Конфигурационными Единицами и предпринимаемыми мерами или процедурами безопасности.

Классификация Конфигурационных Единиц определяет их конфиденциальность, целостность и доступность. Эта классификация основана на требованиях безопасности соглашений SLA. Заказчик ИТ-организации определяет классификацию, так как только заказчик может решить, насколько важны информация или информационные системы для бизнес-процессов. При создании классификации Конфигурационных Единиц заказчик учитывает степень зависимости бизнес-процессов от информационных систем и информации. Затем ИТ-организация увязывает классификацию с соответствующими Конфигурационными Единицами. ИТ-организация должна также реализовать комплекс мер безопасности для каждого Уровня Классификации. Эти комплексы мер могут быть описаны как процедуры, например «Процедура обращения с носителями данных с личной информацией». В соглашении SLA могут определяться комплексы мер безопасности для каждого Уровня Классификации. Система классификации должна всегда быть совместима со структурой организации заказчика. Однако для упрощения управления рекомендуется использовать одну общую систему классификации, даже если ИТ-организация имеет несколько заказчиков.

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

Управление Инцидентами

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

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

Управление Проблемами

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

Управление Изменениями

Виды работ, выполняемых в рамках Процесса Управления Изменениями, часто бывают тесно связаны с безопасностью, так как Управление Изменениями и Управление Информационной Безопасностью взаимозависимы. Если достигнут приемлемый Уровень Безопасности, который находится под контролем Процесса Управления Изменениями, то можно гарантировать, что этот Уровень Безопасности будет обеспечиваться и после проведения изменении. Для поддержки этого Уровня Безопасности существует ряд стандартных операций. Каждый Запрос на изменения (RFC) связан с рядом параметров, которые определяют процедуру приемки. Параметры срочности и степени воздействия могут быть дополнены параметром, связанным с безопасностью. Если Запрос на изменения (RFC) может оказать значительное воздействие на информационную безопасность, потребуются расширенные приемочные испытания и процедуры.

В Запрос на изменения (RFC) также должны быть включены предложения по решению вопросов безопасности. Они опять же должны основываться на требованиях SLA и базовом Уровне Внутренней Безопасности, необходимом для ИТ-организации. Следовательно, эти предложения будут включать комплекс мер по обеспечению безопасности, основанный на Практических нормах по Управлению Информационной Безопасностью.

Желательно, чтобы руководитель Процесса Управления Информационной Безопасностью (а также, возможно, инспектор по безопасности от заказчика) был членом Консультативного комитета по изменениям (Change Advisory Board – CAB).

Однако это не значит, что по всем изменениям необходимо консультироваться с Руководителем Процесса Управления Информационной Безопасностью. В нормальной ситуации безопасность должна быть интегрирована в обычный рабочий режим. Руководитель Процесса Управления Изменениями должен иметь возможность решать, требуется ли ему или комитету CAB входная информация от Руководителя Процесса Управления Информационной Безопасностью. Точно так же руководитель Процесса Управления Информационной Безопасностью не обязательно должен участвовать в выборе мер для конкретных Конфигурационных Единиц затронутых Запросом на Изменения (RFC), так как для соответствующих мер уже должен существовать структурированный подход. Вопросы могут возникнуть только со способом реализации указанных мер.

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

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

Управление Релизами

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

Используется соответствующее аппаратное и программное обеспечение;

Аппаратное и программное обеспечение тестируются перед использованием;

Внедрение надлежащим образом санкционировано с помощью процедуры изменения;

Программное обеспечение является легальным;

Программное обеспечение не содержит вирусов, и вирусы не появятся при его распространении;

Номера версий известны и зарегистрированы в Базе Данных CMDB Процессом Управления Конфигурациями;

Управление развертыванием будет эффективным.

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

Управление Уровнем Сервиса

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

1. Определение потребностей заказчика в области безопасности. Естественно, определение необходимости в безопасности является ответственностью заказчика, так как эти потребности основаны на его интересах.

2. Проверка осуществимости требований заказчика по безопасности.

3. Предложение, обсуждение и определение Уровня Безопасности ИТ-услуг в SLA.

4. Определение, разработка и формулирование внутренних требований безопасности для ИТ-услуг (Операционные Соглашения об Уровне Услуг – OLA).

5. Мониторинг стандартов безопасности (OLA).

6. Составление отчетов о предоставляемых услугах.

Управление Информационной Безопасностью предоставляет Управлению Уровнем Сервиса входную информацию и поддержку для осуществления видов деятельности с 1 по 3. Виды деятельности 4 и 5 проводятся Управлением Информационной Безопасностью. Для деятельности 6 Управление Информационной Безопасностью и другие процессы предоставляют необходимую входную информацию. Руководители Процессов Управления Уровнем Сервиса и Управления Информационной Безопасностью после взаимных консультаций решают, кто реально занимается проведением этих операций. При составлении соглашений SLA обычно предполагается, что существует общий базовый Уровень Безопасности (baseline). Дополнительные требования заказчика по безопасности должны четко определяться в SLA

Управление Доступностью

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

Управление Мощностями

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

Управление Непрерывностью ИТ-услуг

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

15.3.2. Раздел по Безопасности Соглашения об Уровне Сервиса

Соглашение об Уровне Сервиса (SLA) определяет договоренности с заказчиком. Процесс Управления Уровнем Сервиса отвечает за соглашения SLA (см. также главу 10). Соглашение SLA является главной движущей силой всех процессов ITIL.

ИТ-организация определяет степень выполнения требований SLA, включая требования по безопасности. Определенные в SLA элементы безопасности должны отвечать соответствующим потребностям заказчика. Заказчик должен определить важность всех бизнес-процессов (см. рис. 15.3).

Рис. 15.3. Отношения между процессами (источник: OGC)

Эти бизнес-процессы зависят от ИТ-услуг; а поэтому и от ИТ-организации. Заказчик определяет требования к безопасности (требования к информационной безопасности SLA на рис. 15.3. отсутствуют) на основе анализа риска. На рис. 15.4. показано, как определяются элементы безопасности SLA.

Рис. 15.4. Составление раздела по безопасности в соглашении SLA (источник: OGC)

Элементы безопасности обсуждаются представителями заказчика и поставщика услуг. Поставщик услуг сравнивает требования к Уровню Услуг Заказчика со своим Каталогом Услуг, где описываются стандартные меры безопасности (базовый Уровень Безопасности). Заказчик может выдвигать дополнительные требования.

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

15.3.3. Раздел по Безопасности Операционного Соглашения об Уровне Услуг (OLA)

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

Пример . В Каталоге Услуг значится «управление авторизацией пользователей и частных лиц». Операционное Соглашение об Уровне Услуг конкретизирует это для всех определенных услуг, предоставляемых ИТ-организацией. Таким образом, реализация мероприятия определяется для подразделений, предоставляющих услуги UNIX, VMS, NT, Oracle и т. д.

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

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

15.4.1. Контроль – политика и организация информационной безопасности

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

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

Внутренние правила работы (политика) :

Разработка и реализация внутренних правил работы (политики), связи с другими правилами;

Цели, общие принципы и значимость;

Описание подпроцессов;

Распределение функций и ответственностей по подпроцессам;

Связи с другими процессами ITIL и их управлением;

Общая ответственность персонала;

Обработка инцидентов, связанных с безопасностью.

Организация информационной безопасности:

Структурная схема управления ;

Структура управления (организационная структура);

Более детальное распределение ответственностей;

Учреждение Руководящего комитета по информационной безопасности ;

Координация информационной безопасности;

Согласование инструментальных средств (например, для анализа риска и улучшения осведомленности);

Консультации специалистов;

Сотрудничество между организациями, внутреннее и внешнее взаимодействие;

Независимый аудит информационных систем;

Принципы безопасности при доступе к информации третьих сторон;

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

15.4.2. Планирование

Подпроцесс планирования сводится к определению содержания раздела соглашений SLA по вопросам безопасности при участии Процесса Управления Уровнем Сервиса и описанию деятельности, связанной с вопросами безопасности, проводимой в рамках Внешних Договоров. Задачи, которые в соглашении SLA определяются общими словами, детализируются и конкретизируются в форме Операционного Соглашения об Уровне Услуг (OLA). Соглашение OLA может рассматриваться как План по безопасности для организационной структуры поставщика услуг и как конкретный План по безопасности, например, для каждой ИТ-платформы, приложения и сети.

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

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

Подпроцесс планирования координируется с Процессом Управления Уровнем Сервиса по вопросам определения содержания раздела по безопасности соглашения SLA, его обновления и обеспечения соответствия его положениям. За эту координацию отвечает руководитель Процесса Управления Уровнем Сервиса.

Требования по безопасности должны определяться в соглашении SLA, по возможности в измеримых показателях. Раздел по безопасности соглашения SLA должен гарантировать, что достижение всех требований и стандартов безопасности заказчика может быть проконтролировано.

15.4.3. Реализация

Задачей подпроцесса реализации (внедрения) является выполнение всех мероприятий, определенных в планах. Этот подпроцесс может поддерживаться следующим контрольным списком действий.

Классификация и Управление ИТ-ресурсами:

Предоставление входных данных для поддержки Конфигурационных Единиц (CI) в базе CMDB;

Классификация ИТ-ресурсов в соответствии с согласованными принципами.

Безопасность персонала:

Задачи и ответственности в описании работ;

Отбор персонала;

Соглашения о конфиденциальности для персонала;

Обучение персонала;

Руководства для персонала по разрешению инцидентов, связанных с безопасностью, и устранению обнаруженных дефектов защиты;

Дисциплинарные меры;

Улучшение осведомленности по вопросам безопасности.

Управление Безопасностью:

Внедрение видов ответственности и распределение обязанностей;

Письменные рабочие инструкции;

Внутренние правила;

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

Отделение среды разработки и тестирования от операционной (рабочей) среды;

Процедуры обработки инцидентов (осуществляемые Процессом Управления Инцидентами);

Использование средств восстановления;

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

Внедрение мер защиты от вирусов;

Внедрение методов управления для компьютеров, приложений, сетей и сетевых услуг;

Правильное обращение с носителями данных и их защита.

Контроль доступа:

Внедрение политики доступа и контроля доступа;

Поддержка привилегий доступа пользователей и приложений к сетям, сетевым услугам, компьютерам и приложениям;

Поддержка барьеров сетевой защиты (фаервол, услуги доступа по телефонной линии, мосты и маршрутизаторы);

15.4.4. Оценка

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

Существует три вида оценки :

Самостоятельная оценка: проводится в первую очередь линейными подразделениями организации;

Внутренний аудит: проводится внутренними ИТ-аудиторами;

Внешний аудит: проводится внешними ИТ-аудиторами.

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

Оценка также проводится как ответное действие в случае возникновения инцидентов.

Основными видами деятельности являются :

Проверка соответствия политике безопасности и реализация Планов по безопасности;

Проведение аудита безопасности ИТ-систем;

Определение и принятие мер несоответствующего использования ИТ-ресурсов;

Проверка аспектов безопасности в других видах ИТ-аудита.

15.4.5. Поддержка

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

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

15.4.6. Составление отчетов

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

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

Примеры регулярных отчетов и включаемых в них событий:

Подпроцесс планирования:

Отчеты о степени соответствия соглашению SLA и согласованным ключевым показателям качества по вопросам безопасности;

Отчеты о внешних договорах и связанных с ними проблемах;

Отчеты об Операционных Соглашениях об Уровне Услуг (внутренние Планы по безопасности) и собственных принципах безопасности поставщика (например, по базовому Уровню Безопасности);

Отчеты о годовых планах по безопасности и планах действий.

Подпроцесс внедрения:

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

Перечень инцидентов, связанных с безопасностью и ответных мер, возможно, в сравнении с предыдущим отчетным периодом;

Определение тенденций возникновения инцидентов;

Состояние программы оповещения.

Подпроцесс оценки:

Отчеты об эффективности подпроцессов;

Результаты аудиторских проверок, анализа и внутренних оценок;

Предупреждения, определение новых угроз.

Специальные отчеты:

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

15.5.1. Критические факторы успеха и ключевые показатели эффективности

Критическими факторами успеха являются:

Полное понимание необходимости процесса со стороны руководства и его привлечение к процессу;

Привлечение пользователей к разработке процесса;

Точное определение и разделение ответственностей.

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

15.5.2. Функции и роли

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

15.6.1. Проблемы

Следующие аспекты имеют существенное значение для успешной реализации Процесса Управления Информационной Безопасностью:

Понимание необходимости процесса (понимание со стороны участников) : меры безопасности редко встречают быстрое положительное понимание со стороны персонала; чаще встречается сопротивление, а не одобрение. Пользователи возмущаются потерей определенных привилегий из-за введения мер безопасности, даже если эти возможности не являются существенными для их работы. Это объясняется тем, что привилегии дают им определенный статус. Поэтому необходима специальная работа по мотивации пользователей и получению согласия руководства на введение мер безопасности. Особенно в области Управления Информационной Безопасностью руководство должно показать пример («разъяснять курс» и «вести за собой»). При отсутствии инцидентов по безопасности у руководства может возникнуть искушение сократить расходы на Управление Безопасностью.

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

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

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

Управление Изменениями : часто при проведении изменений ослабевает качество оценки соответствия базовому Уровню Безопасности.

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

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

Чрезмерные надежды на технологию «неприступной крепости» : угрозы безопасности систем все чаще возникают в непредсказуемых местах. Сравните первые атаки вирусов ILOVEYOU и Nimda с первым примером атак Denial of Service (DoS). В то время как защита информации с использованием традиционного подхода «неприступной крепости» сохраняет свое значение, также приобретает важность подхода «встречных атак» при возникновении нарушений безопасности. Организация должна иметь возможность быстро направить ресурсы в место возникновения дефекта до того, как он сможет выйти из-под контроля.

15.6.2. Затраты

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

Примечания:

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

Request for Change – RFC.

Management Framework.

Information Security Steering Committee.

© Вадим Гребенников, 2018

ISBN 978-5-4493-0690-6

Создано в интеллектуальной издательской системе Ridero

1. Семейство стандартов управления информационной безопасностью

1.1. История развития стандартов управления информационной безопасностью

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

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

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

Зарождение принципов и правил управления ИБ началось в Великобритании в 1980-х годах. В те годы Министерство торговли и промышленности Великобритании (англ. Department of Trade and Industry, DTI) организовало рабочую группу для разработки свода лучших практик по обеспечению ИБ.

В 1989 году «DTI» опубликовало первый стандарт в этой области, который назывался PD 0003 «Практические правила управления ИБ». Он представлял собой перечень средств управления безопасностью, которые в то время считались адекватными, нормальными и хорошими, применимыми как к технологиям, так и средам того времени. Документ «DTI» был опубликован как руководящий документ британской системы стандартов (англ. British Standard, BS).

В 1995 году Британский институт стандартов (англ. British Standards Institution, BSI) принял национальный стандарт BS 7799-1 «Практические правила управления ИБ». Она описывал 10 областей и 127 механизмов контроля, необходимых для построения СУИБ (англ. Information Security Management System, ISMS), определенных на основе лучших примеров из мировой практики.

Этот стандарт и стал прародителем всех международных стандартов СУИБ. Как и любой национальный стандарт BS 7799 в период 1995-2000 годов пользовался, скажем так, умеренной популярностью только в рамках стран британского содружества.

В 1998 году появилась вторая часть этого стандарта – BS 7799-2 «СУИБ. Спецификация и руководство по применению», определившая общую модель построения СУИБ и набор обязательных требований, на соответствие которым должна производиться сертификация. С появлением второй части BS 7799, определившей, что должна из себя представлять СУИБ, началось активное развитие системы сертификации в области управления безопасностью.

В конце 1999 года эксперты Международной организации по стандартизации (англ. International Organization for Standardization, ISO) и Международной электротехнической комиссии (англ. International Electrotechnical Commission, IEC) пришли к выводу, что в рамках существующих стандартов отсутствует специализированный стандарт управления ИБ. Соответственно, было принято решение не заниматься разработкой нового стандарта, а по согласованию с «BSI», взяв за базу BS 7799-1, принять соответствующий международный стандарт ISO/IEC.

В конце 1999 года обе части BS 7799 были пересмотрены и гармонизированы с международными стандартами систем управления качеством ISO/IEC 9001 и экологией ISO/IEC 14001, а год спустя без изменений BS 7799-1 был принят в качестве международного стандарта ISO/IEC 17799:2000 «Информационные технологии (далее – ИТ). Практические правила управления ИБ».

В 2002 году была обновлена и первая часть стандарта BS 7799-1 (ISO/IEC 17799), и вторая часть BS 7799-2.

Что же касается официальной сертификации по ISO/IEC 17799, то она изначально не была предусмотрена (полная аналогия с BS 7799). Была предусмотрена только сертификация по BS 7799-2, который представлял собой ряд обязательных требований (не вошедших в BS 7799-1) и в приложении перечень условно обязательных (на усмотрение сертификатора) наиболее важных требований BS 7799-1 (ISO/IEC 17799).

На территории СНГ первой страной, которая в ноябре 2004 года приняла стандарт ISO/IEC 17799:2000 в качестве национального, была Беларусь. Россия ввела этот стандарт только в 2007 году. Центральный Банк РФ на его базе создал стандарт управления ИБ для банковской сферы РФ.

В составе ISO/IEC за разработку семейства международных стандартов по управлению ИБ отвечает подкомитет №27, поэтому была принята схема нумерации данного семейства стандартов с использованием серии последовательных номеров, начиная с 27000 (27k).

В 2005 году подкомитет SC 27 «Методы защиты ИТ» Объединенного технического комитета JTC 1 «ИТ» ISO/IEC разработал сертификационный стандарт ISO/IEC 27001 «ИТ. Методы защиты. СУИБ. Требования», пришедший на смену BS 7799-2, и теперь сертификация проводится уже по ISO 27001.

В 2005 году на основе ISO/IEC 17799:2000 был разработан ISO/IEC 27002:2005 «ИТ. Методы защиты. Свод норм и правил управления ИБ».

В начале 2006 года был принят новый британский национальный стандарт BS 7799-3 «СУИБ. Руководство по управлению рисками ИБ», который в 2008 году получил статус международного стандарта ISO/IEC 27005 «ИТ. Методы защиты. Управление рисками ИБ».

В 2004 году Британским институтом стандартов был опубликован стандарт ISO/IEC TR 18044 «ИТ. Методы защиты. Управление инцидентами ИБ». В 2011 году на его базе был разработан стандарт ISO/IEC 27035 «ИТ. Методы защиты. Управление инцидентами ИБ».

В 2009 году был принят стандарт ISO/IEC 27000 «ИТ. СУИБ. Общий обзор и терминология». Он предоставляет обзор систем управления ИБ и определяет соответствующие термины. Словарь тщательно сформулированных формальных определений охватывает большинство специализированных терминов, связанных с ИБ и используемых в стандартах группы ISO/IEC 27.

25 сентября 2013 года были опубликованы новые версии стандартов ISO/IEC 27001 и 27002. С этого момента стандарты серии ISO/IEC 27k (управление ИБ) полностью интегрированы со стандартами серии ISO/IEC 20k (управление ИТ-сервисами). Вся терминология из ISO/IEC 27001 перенесена в ISO/IEC 27000, который определяет общий терминологический аппарат для всего семейства стандартов ISO/IEC 27k.

1.2. Стандарт ISO/IEC 27000-2014

Последнее обновление стандарта ISO/IEC 27000 «ИТ. СУИБ. Общий обзор и терминология» состоялось 14 января 2014 года.

Стандарт состоит из следующих разделов:

– введение;

– сфера применения;

– термины и определения;

– системы управления ИБ;

– семейство стандартов СУИБ.

Введение

Обзор

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

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

Семейство стандартов СУИБ

Семейство стандартов СУИБ, имеющее общее название «Information technology. Security techniques» (Информационная технология. Методы защиты), предназначено для помощи организациям любого типа и размера в реализации и функционировании СУИБ и состоит из следующих международных стандартов:

– ISO/IEC 27000 СУИБ. Общий обзор и терминология;

– ISO/IЕС 27001 СУИБ. Требования;

– ISO/IEC 27002 Свод правил по управлению ИБ;

– ISO/IEC 27003 Руководство по реализации СУИБ;

– ISO/IEC 27004 УИБ. Измерения;

– ISO/IEC 27005 Управление рисками ИБ;

– ISO/IЕС 27006 Требования для органов, обеспечивающих аудит и сертификацию СУИБ;

– ISO/IEС 27007 Руководство по проведению аудита СУИБ;

– ISO/IEС TR 27008 Руководство по аудиту механизмов контроля ИБ;

– ISO/IEС 27010 УИБ для межсекторных и межорганизационных коммуникаций;

– ISO/IЕС 27011 Руководство пo УИБ для телекоммуникационных организаций на основе ISО/IEC 27002;

– ISO/IEС 27013 Руководство пo интегрированной реализации стандартов ISO/IEC 27001 и ISO/IEC 20000-1;

– ISO/IEС 27014 Управление ИБ высшим руководством;

– ISO/IEС TR 27015 Руководство пo УИБ для финансовых сервисов;

– ISO/IEС TR 27016 УИБ. Организационная экономика;

– ISO/IEС 27035 Управление инцидентами ИБ (в стандарте не указан).

Международный стандарт, не имеющие этого общего названия:

– ISO 27799 Информатика в здравоохранении. УИБ по стандарту ISO/IEC 27002.

Цель стандарта

Стандарт предоставляет обзор СУИБ и определяет соответствующие условия.

Семейство стандартов СУИБ содержит стандарты, которые:

– определяют требования к СУИБ и сертификации таких систем;

– включают в себя отраслевые руководящие принципы для СУИБ;

– руководят проведением оценки соответствия СУИБ.

1. Сфера применения

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

2. Термины и определения

Раздел содержит определение 89 терминов, например:

– информационная система – приложения, сервисы, ИТ активы и другие компоненты обработки информации;

– информационная безопасность (ИБ) – сохранение конфиденциальности, целостности и доступности информации;

– доступность – свойство быть доступным и готовым к использованию по запросу уполномоченного лица;

– конфиденциальность – свойство информации быть недоступной или закрытой для неуполномоченных лиц;

– целостность – свойство точности и полноты;

– неотказуемость – способность удостоверять наступление события или действие и их создающих субьектов;

– событие ИБ – выявленное состояние системы (сервиса или сети), указывающее на возможное нарушение политики или мер ИБ, или прежде неизвестная ситуация, которая может касаться безопасности;

– инцидент ИБ – одно или несколько событий ИБ, которые со значительной степенью вероятности приводят к компрометации бизнес-операций и создают угрозы для ИБ;

– управление инцидентами ИБ – процессы обнаружения, оповещения, оценки, реагирования, рассмотрения и изучения инцидентов ИБ;

– система управления – набор взаимосвязанных элементов организации для установления политик, целей и процессов для достижения этих целей;

– мониторинг – определение статуса системы, процесса или действия;

– политика – общее намерение и направление, официально выраженное руководством;

– риск – эффект неопределенности в целях;

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

– уязвимость – недостаток актива или меры защиты, которое может быть использовано одной или несколькими угрозами.

3. Системы управления ИБ

Раздел «СУИБ» состоит из следующих основных пунктов:

– описание СУИБ;

– внедрение, контроль, сопровождение и улучшение СУИБ;

– преимущества внедрения стандартов семейства СУИБ.

3.1. Введение

Организации всех типов и размеров:

– собирают, обрабатывают, хранят и передают информацию;

– осознают, что информация и связанные процессы, системы, сети и люди являются важными активами для достижения целей организации;

– сталкиваются с целым рядом рисков, которые могут повлиять на функционирование активов;

– устраняют предполагаемый риск посредством внедрения мер и средств ИБ.

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

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

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

По мере изменения рисков ИБ и эффективности мер защиты в зависимости от меняющихся обстоятельств организации следует:

– контролировать и оценивать эффективность внедренных мер и процедур защиты;

– идентифицировать возникающие риски для обработки;

– выбирать, внедрять и улучшать соответствующие меры защиты надлежащим образом.

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

3.2. Описание СУИБ

Описание СУИБ предусматривает следующие составляющие:

– положения и принципы;

– информация;

– информационная безопасность;

– управление;

– система управления;

– процессный подход;

– важность СУИБ.

Положения и принципы

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

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

Следующие основные принципы способствуют успешной реализации СУИБ:

– понимание необходимости системы ИБ;

– назначение ответственности за ИБ;

– объединение обязательств руководства и интересов заинтересованных лиц;

– возрастание социальных ценностей;

– оценки риска, определяющие соответствующие меры защиты для достижения допустимых уровней риска;

– безопасность как неотъемлемый элемент ИС и сетей;

– активное предупреждение и выявление инцидентов ИБ;

– обеспечение комплексного подхода к УИБ;

– непрерывная переоценка и соответствующее улучшение ИБ.

Информация

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

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

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

Информационная безопасность

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

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

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

Управление

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

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

Система управления

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

В части ИБ система управления позволяет организации:

– удовлетворять требования безопасности клиентов и других заинтересованных лиц;

– улучшать планы и деятельность организации;

– соответствовать целям ИБ организации;

– выполнять нормативы, законодательство и отраслевые приказы;

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

3.3. Процессный подход

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

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

Дополнительная информация (в стандарте отсутствует)

Родоначальником процессного подхода к управлению качеством принято считать американского ученого Уолтера Шухарта. Его книга начинается с выделения 3-х стадий в управлении качеством результатов деятельности организации:

1) разработка спецификации (техническое задание, технические условия, критерии достижения целей) того, что требуется;

2) производство продукции, удовлетворяющей спецификации;

3) проверка (контроль) произведенной продукции для оценки ее соответствия спецификации.

Шухарт одним из первых предложил линейное восприятие указанных стадий замкнуть в цикл, который он отождествил с «динамическим процессом приобретения знаний».

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

Американский ученый Эдвардс Деминг трансформировал цикл Шухарта в форму, наиболее часто встречаемую сегодня. Он, чтобы перейти от контроля качества к управлению качеством, дал более общие названия каждому из этапов, и, кроме того, добавил еще один, 4-й этап, с помощью которого он хотел обратить внимание американских менеджеров на то, что они недостаточно анализируют полученную на третьем этапе информацию и не улучшают процесс. Именно поэтому этот этап называется «воздействуй» (Act), и соответственно цикл Шухарта-Деминга называют моделью «PDCA» или «PDSA»:

– Plan – Планирование – идентификация и анализ проблем; оценка возможностей, постановка целей и разработка планов;

– Do – Реализация – поиск решения проблем и реализация планов;

– Check (Study) – Оценка результативности – оценка результатов реализации и выводы в соответствии с поставленной задачей;

– Act – Улучшение – принятие решений на основе полученных выводов, коррекция и улучшение работы.

Модель «PDCA» для СУИБ

Планирование – Реализация – Контроль – Улучшение

1. Планирование (разработка и проектирование): установление целей, политик, элементов управления, процессов и процедур СУИБ для достижения результатов, соответствующих общей политике и целям организации.

2. Реализация (внедрение и обеспечение функционирования): внедрение и применение политик ИБ, элементов управления, процессов и процедур СУИБ по оценке и обработке рисков и инцидентов ИБ.

3. Контроль (мониторинг и анализ функционирования): оценка результативности выполнения требований политик, целей ИБ и эффективности функционирования СУИБ и оповещение высшего руководства о результатах.

4. Улучшение (сопровождение и усовершенствование): проведение корректирующих и предупреждающих действий, основанных на результатах аудита и анализа со стороны руководства для достижения улучшения СУИБ

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

– качеством продукции ISO 9000;

– охраной окружающей среды ISO 14000;

– техникой безопасности и охраной труда OHSAS 18000;

– информационными сервисами ISO/IEC 20000;

– безопасностью пищевой продукции ISO 22000;

– информационной безопасностью ISO/IEC 27000;

– безопасностью ISO 28000;

– непрерывностью бизнеса ISO 22300;

– рисками ISO 31000;

– энергетикой ISO 50000.

3.4. Важность СУИБ

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

Принятие СУИБ является стратегическим решением для организации, и необходимо, чтобы это решение постоянно интегрировалось, оценивалось и обновлялось в соответствии с потребностями организации.

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

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

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

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

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

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

Успешное применение СУИБ важно для защиты информационных активов, поскольку позволяет:

– повысить гарантии того, что информационные активы адекватно защищены на непрерывной основе от угроз ИБ;

– поддерживать структурированную и всестороннюю систему оценки угроз ИБ, выбора и применения соответствующих мер защиты, измерения и улучшения их эффективности;

– постоянно улучшать среду управления организации;

– эффективно соответствовать правовым и нормативным требованиям.

3.5. Внедрение, контроль, сопровождение и улучшение СУИБ

Внедрение, контроль, сопровождение и улучшение СУИБ являются оперативными этапами развития СУИБ.

Оперативные этапы СУИБ определяют следующие составляющие:

– общие положения;

– требования ИБ;

– решающие факторы успеха СУИБ.

Оперативные этапы СУИБ обеспечивают следующие мероприятия:

– оценка рисков ИБ;

– обработка рисков ИБ;

– выбор и внедрение мер защиты;

– контроль и сопровождение СУИБ;

– постоянное улучшение.

Общие положения

Организация должна предпринимать следующие шаги по внедрению, контролю, сопровождению и улучшению ее СУИБ:

– определение информационных активов и связанных с ними требований ИБ;

– оценка и обработка рисков ИБ;

– выбор и внедрение соответствующих мер защиты для управления неприемлемыми рисками;

– контроль, сопровождение и повышение эффективности мер защиты, связанных с информационными активами организации.

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

Требования ИБ

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

– информационных активов и их ценности;

– бизнес-потребностей в работе с информацией;

– правовых, нормативных и договорных требований.

Проведение методической оценки рисков, связанных с информационными активами организации, включает в себя анализ:

– угроз активам;

– уязвимостей активов;

– вероятности материализации угрозы;

– возможного влияния инцидента ИБ на активы.

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

Оценка рисков ИБ

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

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

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

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

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

Стандарт ISO/IEC 27005 представляет руководство по управлению рисками ИБ, включая рекомендации по оценке, обработке, принятию, оповещению, мониторингу и анализу риска.

Обработка рисков ИБ

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

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

– применение соответствующих мер защиты для снижения рисков;

– осознанное и объективное принятие рисков в строгом соответствии с политикой организации и критерием принятия риска;

– предотвращение рисков путем исключения действий, приводящих к появлению рисков;

– обмен связанными рисками с другими сторонами, например, страховщиками или поставщиками.

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

Выбор и внедрение мер защиты

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

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

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

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

К техническим мерам можно отнести:

· защиту от несанкционированного доступа к системе,

· резервирование особо важных обеспечивающих подсистем,

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

· установку оборудования для обнаружения и тушения пожаров,

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

· установку резервных систем электропитания,

· оснащение помещений замками,

· физическое разграничение доступа персонала в помещения,

· установку систем сигнализации и т.д.

К организационным мерам относятся:

· охрана информационных систем,

· тщательный подбор персонала,

· исключение случаев ведения особо важных работ только одним человеком,

· наличие плана восстановления работоспособности системы после выхода ее из строя,

· организация и обслуживание предприятия информатики посторонними лицами, не заинтересованными в сокрытии фактов нарушения ее работы,

· универсальность средств защиты для всех пользователей (включая высшее руководство),

· разделение полномочий в области доступа к данным,

· возложение ответственности на лиц, которые должны обеспечить безопасность работы предприятия информатики.

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

Все большую известность при построении корпоративных систем управления информационной безопасностью (СУИБ) завоевывает международный стандарт ISO/IEC 27001:2005 «Информационные технологии. Методы обеспечения безопасности. Системы менеджмента информационной безопасности. Требования», в соответствии с которыми компании могут формализовать и структурировать процессы управления ИБ по следующим направлениям:

· разработка политики и организация ИБ,

· организация управления внутренними активами и ресурсами компании, составляющими основу ее ключевых бизнес-процессов,

· защита персонала и снижение внутренних угроз компании,

· физическая безопасность в компании и безопасность окружающей среды,

· управление средствами связи и эксплуатацией оборудования,

· разработка и обслуживание аппаратно-программных систем,

· управление непрерывностью бизнес-процессов в компании,

· соблюдение правовых норм по безопасности.

Существует ряд общепризнанных методик, помогающих эффективно управлять информационной безопасностью. Известна и широко используется методология моделирования угроз (Microsoft Threat Modeling Methodology), методика оценки риска DREAD, модель деления угроз на категории STRIDE (http://msdn.microsoft.com/ru-ru/magazine/cc700352.aspx).

У компании IBM - это методология Method for Architecting Secure Solutions (MASS), которая помогает выявить проблемы защиты, создать прочную архитектуру и выработать надежную политику защиты (www.redbooks.ibm.com).

Из известных и популярных методик необходимо вспомнить подход компании ISS к информационной безопасности, получивший название ADDME и который включает в себя 5 этапов.

1 этап - оценка (assess). На этом этапе осуществляется идентификация и инвентаризация всех ресурсов организации. На данном этапе осуществляются анализ риска (risk assessment), а также поиск уязвимостей (vulnerability assessment), тестирование на проникновение (penetration assessment) и оценка угроз (threat assessment).

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

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

4 этап - эксплуатация (manage and support). На этом этапе оценивается эффективность принятых мер и их соответствие положениям разработанной политики безопасности. В случае возникновения инцидентов, связанных с ее нарушением, реализуется разработанный на втором этапе план реагирования на инциденты и, как следствие, осуществляется пересмотр некоторых положений политики безопасности. Изменение технологии обработки информации, появление новых технологий защиты и т.п. также являются толчком к пересмотру разработанных документов.

5 этап - обучение (education). Обучение - это постоянный процесс, осуществляемый на всех этапах построения комплексной системы информационной безопасности. В нем участвуют все сотрудники организации: операторы, администраторы, руководители и т.д.

В идеальной компании процесс управления информационной безопасностью является проактивным (превентивным и постоянным).

Александр Астахов, CISA, 2006

Введение

Для многих российских компаний настало время задуматься об управлении безопасностью - ИТ-инфраструктура многих из них достигла уровня, требующего четко отлаженной координации. При построении системы управления безопасностью (СУИБ) эксперты рекомендуют опираться на международные стандарты ISO/IEC 27001/17799.

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

Система управления информационной безопасностью - что это такое?

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

Согласно ISO 27001, система управления информационной безопасностью (СУИБ) - это «та часть общей системы управления организации, основанной на оценке бизнес рисков, которая создает, реализует, эксплуатирует, осуществляет мониторинг, пересмотр, сопровождение и совершенствование информационной безопасности». Система управления включает в себя организационную структуру, политики, планирование, должностные обязанности, практики, процедуры, процессы и ресурсы.

Создание и эксплуатация СУИБ требует применения такого же подхода, как и любая другая система управления. Используемая в ISO 27001 для описания СУИБ процессная модель предусматривает непрерывный цикл мероприятий: планирование, реализация, проверка, действие (ПРПД).

Применение модели ПРПД к процессам СУИБ

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

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

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

Один из вариантов организационной структуры СУИБ

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

Создание подобной структуры управления является целью внедрения ISO 27001/17799 в организации. Один из основных принципов здесь - «приверженность руководства». Это означает, что такая структура может быть создана только руководством компании, которое распределяет должности, ответственность и контролирует выполнение обязанностей. Другими словами руководство организации строит соответствующую вертикаль власти, а точнее модифицирует существующую для удовлетворения потребностей организации в безопасности. СУИБ может создаваться только сверху вниз.

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

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

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

Сертифицировать или нет?

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

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

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

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

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

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

Подготовка к сертификации

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

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

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

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

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

На заключительном этапе осуществляется подготовка к сертификационному аудиту: анализируется состояние СУИБ, оценивается степень ее готовности к сертификации, уточняется область и границы сертификации, проводятся соответствующие переговоры с аудиторами органа по сертификации. Подробные рекомендации по созданию СУИБ и подготовки к сертификации содержатся в серии руководящих документов BSI BIP 0071-0073.

Точки преткновения

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

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

Столь же важно правильно представлять, где проходят границы СУИБ и каким образом она связана с другими системами управления и процессами организации. Например, система управления ИБ и система управления непрерывностью бизнеса (ВСМ) организации тесно пересекаются. Последняя является одной из 11 определяемых стандартом областей контроля информационной безопасности. Однако СУИБ включает в себя только ту часть BCM, которая связана с ИБ - это защита критичных бизнес процессов организации от крупных сбоев и аварий информационных систем. Другие аспекты BCM выходят за рамки СУИБ.

Стандарт - гарантия безопасности

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

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