Смарт ТВ 

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

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

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

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

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

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

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

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

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

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

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

15.2. Цели процесса

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

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

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

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

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

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

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

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

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

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

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

15.3. Процесс

Организации и их информационные системы меняются. Стандартные шаблоны, такие как Сборник практических рекомендаций по Управлению Информационной Безопасностью (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. Виды деятельности

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. Контроль процесса

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

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

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

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

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

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

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

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

15.6. Проблемы и затраты

15.6.1. Проблемы

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

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

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

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

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

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

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

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

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

15.6.2. Затраты

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

Примечания:

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

Request for Change – RFC.

Management Framework.

Information Security Steering Committee.

СИСТЕМА ДОБРОВОЛЬНОЙ СЕРТИФИКАЦИИ

«СВЯЗЬ – ЭФФЕКТИВНОСТЬ»

РОСС RU.М821.04ФБГ0

Система управления информационной безопасностью «Базовый уровень информационной безопасности операторов связи»

Требования, программа и методика сертификационных испытаний

1 Введение 1

2 Область применения 2

4.2.Требования к политикам оператора 5

4.3.Требования к функциональности 6

4.4. Требования к взаимодействию 7

5 Программа сертификационных испытаний 7

5.1. Объект испытаний 7

5.2. Цель испытаний 7

6 Методика проведения сертификационных испытаний 8

6.1. Условия проведения испытаний 8

6.2. Методика проверки 9

1 Введение

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

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

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

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

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

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

2 Область применения

      Настоящие Требования, программа и методика разработаны в соответствии с Положением о Системе добровольной сертификации «Связь – Эффективность» на базе Рекомендации сектора стандартизаций Международного Союза Электросвязи (МСЭ-Т) Серии X, Приложение 2, «Серии Х.800-Х849 МСЭ-Т – Приложение по базовому уровню информационной безопасности операторов связи».

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

3 Нормативные ссылки, определения и сокращения

3.1. В настоящих Требованиях, программе и методике использованы ссылки на следующие нормативные документы:

    Федеральный закон от 27 июля 2006г. № 149-ФЗ «Об информации, информационных технологиях и защите информации».

    Доктрина информационной безопасности Российской Федерации от 09 сентября 2000 г. № Пр-1895.

    Правила присоединения сетей электросвязи и их взаимодействия (утв. Постановлением Правительства РФ от 28 марта 2005 г., N 161).

    ГОСТ Р 50739-95 Средства вычислительной техники. Защита от НСД к информации. Общие технические требования.

    ГОСТ Р 52448-2005 Защита информации. Обеспечение безопасности сетей электросвязи. Общие положения.

    ГОСТ Р ИСО/МЭК 15408-2002 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий.

    ГОСТ Р ИСО/МЭК 27001-2006 Методы обеспечения информационной безопасности. Системы управления информационной безопасностью. Требования.

    ОСТ 45.127-99. Система обеспечения информационной безопасности Взаимоувязанной сети связи Российской Федерации. Термины и определения.

    Рекомендация сектора стандартизаций Международного Союза Электросвязи (МСЭ-Т) Серии X, Приложение 2, «Серии Х.800-Х849 МСЭ-Т – Приложение по базовому уровню информационной безопасности операторов связи».

3.2. В настоящих Требованиях, программе и методике использованы термины соответствующие определениям Федерального закона «О связи», а также дополнительно определены следующие термины и сокращения:

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

Антивирусное программное обеспечение – специальное программное обеспечение, предназначенное для выявления и деактивации (блокирования) вредоносного программного кода, специально созданного для нарушения целостности, доступности и конфиденциальности данных.

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

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

Лицензионное соглашение – договор между владельцем программного обеспечения и пользователем ее копии

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

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

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

Спам – незапрашиваемая корреспонденция, передаваемая в электронном виде (как правила, средствами электронной почты).

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

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

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

  1. Конфиденциальность - состояние информации, при котором доступ к ней осуществляют только субъекты, имеющие на него право.
  2. Целостность - состояние информации, при котором отсутствует любое ее изменение либо изменение осуществляется только преднамеренно субъектами, имеющими на него право;
  3. Доступность - состояние информации, при котором субъекты, имеющие право доступа, могут реализовывать его беспрепятственно.

Цель обеспечения информационной безопасности достигнута, если:

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

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

Процесс ISM должен включать в себя:

  • формирование, управление, распространение и соблюдение Политики информационной безопасности и других вспомогательных политик, которые имеют отношение к информационной безопасности. Политика информационной безопасности (Security Policy) - политика, определяющая подход организации к управлению информационной безопасностью .
  • понимание согласованных текущих и будущих требований бизнеса к безопасности;
  • использование контролей безопасности для выполнения Политики информационной безопасности и управления рисками, связанными с доступом к информации, системам и услугам. Термин " контроль безопасности " является заимствованным из английского языка и в данном контексте означает набор контрмер и мер предосторожности, применяемых для аннулирования, уменьшения рисков и противостояния им. То есть контроль безопасности состоит из проактивных и реактивных действий;
  • документирование перечня контролей безопасности , действий по их эксплуатации и управлению, а также всех связанных с ними рисков;
  • управление поставщиками и контрактами, требующими доступа к системам и услугам. Осуществляется при взаимодействии с процессом Управления поставщиками;
  • контроль всех "брешей" безопасности и инцидентов, связанных с системами и услугами;
  • проактивное улучшение контролей безопасности и уменьшение рисков нарушения информационной безопасности;
  • интеграция аспектов информационной безопасности во все процессы Управления услуг.

Политика информационной безопасности должна включать в себя следующее:

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

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

Политики утверждаются руководством бизнеса и IT и пересматриваются в зависимости от обстоятельств.

Чтобы обеспечивать информационную безопасность и управлять ею, необходимо поддерживать Систему управления информационной безопасностью. Система управления информационной безопасностью (Information Security Management System или ISMS) - система политик, процессов, стандартов, руководящих документов и средств, которые обеспечивают организации достижение целей управления информационной безопасностью. На рис. 6.3 показана структура ISMS, наиболее широко используемая организациями.


Рис. 6.3. ISMS

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


Рис. 6.5.

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

  1. превентивные - меры безопасности, которые предотвращают появление инцидента информационной безопасности. Например, распределение прав доступа.
  2. восстановительные - меры безопасности, направленные на уменьшение потенциального ущерба в случае инцидента. Например, резервное копирование.
  3. обнаруживающие - меры безопасности, направленные на обнаружение инцидентов. Например, антивирусная защита или система обнаружения вторжений.
  4. подавляющие - меры безопасности, которые противодействуют попыткам реализации угрозы, то есть инцидентам. Например, банкомат забирает у клиента карту после определенного количества неправильных вводов PIN-кода.
  5. корректирующие - меры безопасности, направленные на восстановления после инцидента. Например, восстановление резервных копий, откат на предыдущее рабочее состояние и т.п.

Входами процесса ISM являются:

  1. информация от бизнеса - стратегии, планы, бюджет бизнеса, а также его текущие и будущие требования;
  2. политики безопасности бизнеса, планы безопасности, Анализ рисков;
  3. информация от IT - стратегия, планы и бюджет IT;
  4. информация об услугах - информация от SLM , в частности Портфеля услуг и Каталога услуг, SLA/ SLR ;
  5. отчеты процессов и анализа рисков от ISM , Управления доступностью и Управления непрерывностью услуг;
  6. детальная информация обо всех инцидентах информационной безопасности и "брешах" в ней;
  7. информация об изменениях - информация от процесса Управления изменениями, в частности расписание изменений и их влияние на планы, политики и контроли информационной безопасности;
  8. информация о взаимоотношениях бизнеса с услугами, вспомогательными услугами и технологиями;
  9. информация о доступе партнеров и поставщиков к услугам и системам, предоставляемая процессами Управления поставщиками и Управления доступностью.

Выходами ISM являются:

  1. всеобъемлющая Политика информационной безопасности и другие вспомогательные политики, которые имеют отношение к информационной безопасности;.
  2. Система управления информационной безопасностью (ISMS), которая содержит всю информацию, необходимую для обеспечения ISM ;
  3. результаты переоценки рисков и ревизии отчетов;
  4. набор контролей безопасности , описание их эксплуатации и управления, а также всех связанных с ними рисков;
  5. аудиты информационной безопасности и отчеты;
  6. расписание тестирования планов информационной безопасности;
  7. классификация информационных активов;
  8. отчеты о существующих "брешах" в информационной безопасности и инцидентах;
  9. политики, процессы и процедуры для управления доступом поставщиков и партнеров к услугам и системам.

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

  1. защищенность бизнеса от нарушений информационной безопасности
    • процентное уменьшение сообщений о "брешах" в Сервис-деск;
    • процентное уменьшение негативного влияния на бизнес со стороны "брешей" и инцидентов;
    • процентное увеличение пунктов, касающихся информационной безопасности, в SLA.
  2. формирование четкой и согласованной политики информационной безопасности, учитывающей потребности бизнеса, то есть уменьшение количества несовпадений между процессами ISM и процессами и политиками информационной безопасности бизнеса.
  3. процедуры по обеспечению безопасности, которые оправданы, согласованы и утверждены руководством организации:
    • увеличение согласованности и пригодности процедур обеспечения безопасности;
    • увеличение поддержки со стороны руководства
  4. механизмы улучшения:
    • количество предложенных улучшений в отношении контролей и процедур;
    • уменьшение количества несовпадений, обнаруженных в процессе тестирования и аудита.
  5. информационная безопасность является неотъемлемой частью услуг и процессов ITSM , то есть увеличение количества услуг и процессов, в которых предусмотрены меры безопасности.

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

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

Проблематика

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

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

Решение

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

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

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

Компания «Инфосистемы Джет» оказывает широкий спектр услуг в области управления и обеспечения ИБ:

Разработка и внедрение СУИБ на основе стандарта ISO/IEC 27001

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

Разработка и внедрение отдельных процессов управления и обеспечения ИБ

Разработка и внедрение отдельных процессов управления и обеспечения ИБ (например, управления рисками, управления инцидентами, внутренних аудитов и т.д.) осуществляется в соответствии с требованиями международных и российских стандартов по ИБ (ISO/IEC 27001:2005, ISO/IEC 27002:2005, ISO/IEC 27005:2008, PCI DSS, СТО БР ИББС – 1.0 и др.), а также лучшими практиками в этой области.

Консультанты могут составить план-график последовательного внедрения процессов управления ИБ с целью дальнейшего объединения в единую СУИБ.

Подготовка к сертификации на соответствие требованиям международного стандарта ISO/IEC 27001

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

Компания «Инфосистемы Джет» осуществляет поддержку заказчиков при проведении аудитов и помогает устранить выявленные несоответствия.

Поддержка разработанной СУИБ или отдельных процессов

Компания «Инфосистемы Джет» осуществляет:

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

Преимущества работы с компанией «Инфосистемы Джет»:

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

Выгоды

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

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

Помимо этого, внедрение и сертификация СУИБ позволяет:

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

Опыт

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

Успешно выполнены пять крупных проектов по созданию и последующей подготовке СУИБ к сертификации на соответствие требованиям стандарта ISO/IEC 27001:2005 в компаниях:

  • ОАО «Межрегиональный Транзит Телеком»
  • ОАО «РОСНО»
  • ООО «Центр безопасности информации»
  • Askari Bank (Пакистан)
  • ООО «ЭЛЬДОРАДО»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Контроль

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

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

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

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

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

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

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

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

Реализация

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

Классификация и Управление ИТ-ресурсами:
- предоставление входных данных для поддержки Конфигурационных Единиц (CI) в базе CMDB;
- классификация ИТ-ресурсов в соответствии с согласованными принципами.

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

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

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

Оценка

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

Поддержка

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

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

Обслуживание должно быть достигнуто с помощью Plan-Do-Check-Act цикла, который является
формальным подходом, предложенным ISO 27001 для установления Информационной системы управления безопасностью. Это подробно описано в CSI.

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

Стратегическое выравнивание:
о Требования безопасности должны определяться корпоративными требованими
о Решения безопасности должны соответствовать процессам предприятия
о инвестиций в области информационной безопасности должны быть согласованы со стратегией предприятия и согласованными рисками

Доставка Значение:
о Стандартный набор методов безопасности, то есть требований Baseline Security соблюдении правил
о Правильно распределенные приоритеты и усилия для областей с наибольшей отдачей и бизнес- выгод
о Институционализированные и массовые решения
о Комплексные решения, охватывающие организацию и процесс, а также технологии о культуре постоянного улучшения

Управление рисками:
о Согласованный профиль риска
о Понимание подверженности риску
о Осознание приоритетов управления рисками
о Снижение риска
о Риск принятия / уважение

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

Управление ресурсами:
о Знание собраны и доступны
о документированы процессы и практики безопасности
о Разработано архитектура безопасности для эффективного использования ресурсов инфраструктуры
- обеспечение бизнес-процессов.