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

Стандарты СУИБ

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

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 27002, общепризнаны как лучшие методы, применимые к большинству организаций и легко приспосабливаемые для организаций разной величины и структуры. Другие стандарты семейства стандартов СУИБ рекомендуют выбор и применение мер защиты, изложенных в стандарте ISO/IEC 27002, для СУИБ.

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

Меры защиты следует выбирать из стандарта ISO/IEC 27002 или других перечней, или создавать новые при особой необходимости. Следует осознавать, что некоторые меры защиты могут не подойти для каждой ИС или среды или быть неприемлемыми для всех организаций.

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

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

Выбор мер и средств ИБ должен быть задокументирован в Положении о применимости для соблюдения требований ИБ.

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

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

Постоянное улучшение

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

Действия по улучшению содержат следующее:

— анализ и оценка существующей ситуации для определения сфер улучшения;

— формирование целей улучшения;

— поиск возможных решений для достижения целей;

— оценка этих решений и осуществление выбора;

— реализация выбранного решения;

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

— формализованные изменения.

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

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

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

— политика ИБ, цели и деятельность, ориентированная на цели;

— подход и структура для разработки, внедрения, контроля, сопровождения и улучшения ИБ, соответствующие корпоративной культуре;

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

— понимание требований защиты информационных активов, достигаемое применением управления рисками ИБ (см. ISO/IEC 27005);

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

— эффективный процесс управления инцидентами ИБ:

— эффективный подход к управлению непрерывностью бизнеса;

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

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

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

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

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

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

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

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

— повышение доверия заинтересованных сторон к организации;

— удовлетворение социальных нужд и ожиданий;

— более эффективное экономическое управление инвестициями в ИБ.

На этом рассмотрение стандарта ISO/IEC 27000 заканчиваем.

Сертификация СУИБ

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

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

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

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

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

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

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

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

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

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

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

5. Работы по внедрению недостающих механизмов контроля, которые включают в себя 3 основные составляющие:

— подготовка и повышение осведомленности сотрудников (обучение и тренинги);

— подготовка документации СУИБ (политики, стандарты, процедуры, регламенты, инструкции, планы);

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

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

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

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

Использование ISO/IEC 27001—2005 как национального стандарта, в то время как уже введен в действие ISO/IEC 27001—2013, а также неотрегулированность системы сертификации средств защиты информации серьезно затрудняет выполнение одного из главных требований стандарта — соответствие действующему законодательству.

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

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

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

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

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

2. Требования к суиб (стандарт ISO/IEC 27001:2013)

В 1998 году появилась вторая часть британского национального стандарта — BS 7799—2 «СУИБ. Спецификация и руководство по применению», в 2002 году она была пересмотрена, а в конце 2005 года была принята в качестве международного стандарта ISO/IEC 27001 «ИТ. Методы защиты. СУИБ. Требования». 25 сентября 2013 года состоялось последнее обновление стандарта.

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

Предисловие

0. Введение

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

2. Нормативные ссылки

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

4. Контекст организации

5. Лидерство

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

7. Поддержка

8. Эксплуатация

9. Оценка результативности

10. Улучшение

Этапам модели «РDСА» соответствуют следующие разделы стандарта:

— планирование;

— эксплуатация;

— оценка результативности;

— улучшение.

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

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

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

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

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

Разделы «2.Нормативные ссылки» и «3.Термины и определения» пропускаем.

4. Контекст организации

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

Организация должна определить:

— заинтересованные стороны, имеющие отношение к СУИБ;

— требования этих заинтересованных сторон, имеющих отношение к ИБ.

Организация для определения сферы применения СУИБ должна определить границы и возможность применения СУИБ.

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

— внешние и внутренние аспекты;

— требования заинтересованных сторон;

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

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

5. Лидерство

Лидерство и обязательства

Высшее руководство должно продемонстрировать лидерство и обязательства в отношении СУИБ путем:

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

— обеспечения интеграции требований СУИБ в процессы организации;

— обеспечения того, чтобы ресурсы, необходимые для системы менеджмента информационной безопасности, были доступны;

— информирования о важности достижения результативности УИБ и о соответствии требованиям СУИБ;

— обеспечения того, что СУИБ позволяет достигать желаемых результатов;

— поддержки и управления персоналом, способствующим эффективности СУИБ;

— содействия постоянному улучшению;

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

Политика

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

— соответствовать целям ИБ;

— содержать цели ИБ или обеспечивать основу для достижения целей ИБ;

— включать обязательства по соблюдению требований ИБ;

— включать обязательства по постоянному улучшению СУИБ.

Политика ИБ должна быть:

— доведена до персонала организации;

— доступна как документированная информация;

— доступна всем заинтересованным сторонам.

Организационные роли, обязанности и полномочия

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

Высшее руководство должно обозначить обязанности и полномочия для:

— обеспечения соответствия СУИБ требованиям этого стандарта;

— оповещения высшего руководства о результативности СУИБ.

6. Планирование (1-й этап «РDСА»)

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

— определение целей ИБ и мер по их достижению;

— действия по обработке рисков и возможностей.

Определение целей ИБ и мер по их достижению

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

Цели ИБ должны:

— соответствовать политике ИБ;

— быть измеримыми (если это возможно);

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

— быть известны соответствующему персоналу организации;

— обновляться по мере необходимости.

Организация должна сохранять документированную информацию о целях ИБ.

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

— что будет сделано;

— какие ресурсы потребуются;

— кто будет нести ответственность;

— когда меры будут реализованы;

— как будут оцениваться результаты.

Действия по обработке рисков и возможностей

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

— обеспечение того, чтобы СУИБ позволило достигать желаемых результатов;

— предотвращение или уменьшение нежелательных эффектов;

— обеспечение непрерывного совершенствования.

Организация должна планировать:

— процессы оценки и обработки рисков;

— действия по осуществлению и интеграции работ в процессах СУИБ и оценке их результативности.

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

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

На основании процесса оценки рисков ИБ организации следует:

— установить и поддерживать критерии для рисков ИБ, которые состоят из критериев для проведения оценки и принятия рисков ИБ;

— определить риски ИБ:

• применить процесс оценки рисков ИБ для выявления рисков, связанных с потерей конфиденциальности, целостности и доступности информации в рамках СУИБ (§);

• определить владельцев рисков;

— проанализировать риски ИБ:

• определить реалистичную вероятность возникновения рисков §;

• определить потенциальные последствия, которые могут возникнуть в случае возникновения рисков §;

• определить уровни риска;

— оценить риски ИБ:

• сравнить результаты анализа рисков с установленными критериями для рисков;

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

— гарантировать, что повторная оценка рисков ИБ позволит получить логичные, обоснованные и сопоставимые результаты.

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

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

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

На основании процесса обработки рисков ИБ организации следует:

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

— определить все элементы управления, которые необходимы для реализации выбранного варианта обработки рисков ИБ;

— сравнить определенные элементы управления с теми, которые приведены в Приложении А и убедиться в том, что не были упущены необходимые элементы;

— разработать Положение о Применимости (англ. Statement of Applicability, SoA), которое содержит необходимые элементы управления и обоснования их включения (независимо от того, реализованы они или нет), а также обоснования исключений элементов управления из Приложения А;

— сформулировать план по обработке рисков ИБ;

— согласовать с владельцами рисков план по обработке рисков ИБ и получить (от владельцев рисков) согласие на принятие остаточных рисков ИБ.

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

7. Поддержка

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

— ресурсы;

— компетенции;

— осведомленность;

— коммуникации;

— документированная информация.

Ресурсы

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

Компетенции

Организация должна:

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

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

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

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

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

Осведомленность

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

— о политике ИБ;

— о вкладе в повышение результативности СУИБ, включая выгоды от улучшения состояния ИБ;

— о последствиях в результате не выполнения требований СУИБ.

Коммуникации

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

— о чем сообщать;

— когда сообщать;

— кому сообщать;

— кто должен участвовать в коммуникациях;

— процессы осуществления коммуникаций.

Документированная информация

СУИБ организации должна включать документированную информацию:

— требуемую настоящим стандартом;

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

Степень (детализация) документированной информации для СУИБ одной организации может отличаться от другой в зависимости от:

— размера организации и ее вида деятельности, процессов, продуктов и услуг;

— сложности процессов и их взаимодействия;

— компетенции персонала.

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

— идентификацию и описание (например: название, дата, автор или ссылка);

— оформление (например: язык, версия ПО, рисунки) и тип носителя (например: электронный, бумажный);

— рассмотрение и утверждение на предмет пригодности для применения и адекватности.

Документированная информация СУИБ должна управляться для обеспечения:

— доступности и пригодности для использования;

— адекватной защиты (например: от потери конфиденциальности, неправильного использования или потери целостности).

Для управления документированной информацией организация должна рассмотреть следующие мероприятия (где применимо):

— распространение информации, доступ, восстановление и использование;

— хранение и сохранность, в том числе сохранение удобочитаемости;

— контроль изменений (например, управление версиями);

— архивирование и уничтожение.

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

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

8. Эксплуатация (2-й этап «РDСА»)

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

— оперативное планирование и контроль;

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

— обработка рисков ИБ.

Оперативное планирование и контроль

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

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

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

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

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

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

Организация должна сохранять документированную информацию о результатах оценки рисков ИБ.

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

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

9. Оценка результативности (3-й этап «РDСА»)

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

— мониторинг, измерение, анализ и оценка;

— внутренний аудит;

— анализ со стороны руководства.

Мониторинг, измерение, анализ и оценка

Организация должна оценивать состояние ИБ и результативность СУИБ.

Организация должна определить:

— что необходимо отслеживать и измерять, в том числе процессы ИБ и элементы управления;

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

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

— кто должен осуществлять мониторинг и измерения;

— когда результаты мониторинга и измерений должны быть проанализированы и оценены;

— кто должен анализировать и оценивать эти результаты.

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

Внутренний аудит

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

— на предмет соответствия собственным требованиям организации для своей СУИБ и требованиям настоящего стандарта;

— с целью оценки результативности внедрения и поддержки.

Перед проведением аудита организация должна определить программу, критерии и сферу применения для каждого аудита, а также аудиторов.

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

Организация должна обеспечить:

— объективность и беспристрастность процесса аудита;

— направление результатов аудитов руководству соответствующего уровня;

— хранение документированной информации как свидетельства о программе аудита и результатах аудита.

Анализ со стороны руководства

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

Анализ со стороны руководства должен включать следующее:

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

— изменения внешних и внутренних аспектов, которые имеют отношение к СУИБ;

— обратную связь о состоянии ИБ, включая:

• несоответствия и корректирующие действия;

• результаты мониторинга и измерений;

• результаты аудита;

• результат достижения целей ИБ;

— обратную связь от заинтересованных сторон;

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

— возможности для постоянного улучшения.

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

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

10. Улучшение (4-й этап «РDСА»)

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

— корректирующие действия;

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

Корректирующие действия

При появлении несоответствия организация должна:

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

— оценить необходимость принятия действий для устранения причин несоответствия с целью предотвращения его повторения или появления в другом месте, для этого:

• изучить несоответствие;

• определить причину несоответствия;

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

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

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

— при необходимости внести изменения в СУИБ.

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

— характере несоответствий;

— любых корректирующих действиях;

— результатах корректирующих действий.

Постоянное улучшение

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

3. Свод правил управления ИБ

(стандарт ISO/IEC 27002:2013)

В 2000 году первая часть британского национального стандарта BS 7799—1 «Практические правила управления ИБ» была принята в качестве международного стандарта ISO/IEC 17799 «ИТ. Практические правила управления ИБ». В 2005 году на его основе был разработан новый международный стандарт ISO/IЕС 27002 «ИТ. Meтоды защиты. Свод норм и правил управления ИБ», который был опубликован в июле 2007 года. Последнее обновление стандарта состоялось 25 сентября 2013 года.

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

Стандарт состоит из 14 разделов, посвященных мерам безопасности, которые все вместе содержат, в целом, 34 основные категории безопасности и 114 мер защиты:

1) политика ИБ (1);

2) организация ИБ (2);

3) безопасность, связанная с персоналом (3):

4) управление активами (3);

5) управление доступом (4);

6) криптография (1);

7) физическая и экологическая безопасность (2);

8) безопасность операций (7);

9) безопасность связи (2);

10) приобретение, разработка и поддержка ИС (3);

11) взаимоотношения с поставщиками (2);

12) управление инцидентами ИБ (1);

13) аспекты ИБ при управлении непрерывностью бизнеса (2);

14) соответствие требованиям (2).

Каждая основная категория безопасности включает в себя:

— цель ИБ;

— меры достижения этой цели.

Описание мер ИБ структурируется таким образом:

— меры и средства ИБ;

— рекомендации по их реализации.

1. Политика ИБ

1.1. Руководящие положения для ИБ

Цель: Реализовать требования политики ИБ и обеспечить поддержку для ИБ в соответствии с требованиями бизнеса и действующим законодательством.

Политика ИБ предполагает следующие мероприятия:

— документирование;

— пересмотр.

Документирование

Меры и средства

Политика ИБ документируется оформлением, утверждением, публикованием и доведением до персонала и внешних заинтересованных сторон.

Рекомендации по реализации

В лучшем случае, политика ИБ должна устанавливать ответственность руководства, а также излагать подход организации к УИБ.

Политика ИБ должна содержать требования:

— стратегии бизнеса;

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

— защиты от существующих и потенциальных угроз ИБ.

Политика ИБ должна содержать положения по:

— определению ИБ, ее целей и принципов для руководства действиями по обеспечению ИБ;

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

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

— процессов управления изменениями и исключениями.

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

Примерами таких задач могут быть:

— управление доступом;

— классификация активов;

— физическая и экологическая безопасность;

— следующие требования к пользователям:

• использование активов;

• чистый стол и чистый экран;

• политика коммуникаций;

• мобильные устройства и удалённая работа;

• ограничения на установку ПО;

— передача информации;

— защита от вредоносного ПО;

— управление техническими уязвимостями;

— управление средствами криптографии;

— безопасность коммуникаций;

— защита персональных данных;

— взаимоотношения с поставщиками.

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

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

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

Пересмотр

Меры и средства

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

Рекомендации по реализации

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

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

2. Организация ИБ

Организацию ИБ определяют следующие составляющие:

— внутренняя организация;

— мобильные устройства и удалённая работа.

2.1. Внутренняя организация

Цель: Создать структуру управления для инициирования и управления внедрением и обеспечением ИБ в организации.

Внутренняя организация сферы ИБ предполагает следующие мероприятия:

— определение ответственности;

— разделение обязанностей;

— контакт с властями;

— контакт со специальными группами.

Определение ответственности

Меры и средства

Все ответственности в поле ИБ должны быть определены и закреплены.

Рекомендации по реализации

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

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

Сферы ответственности должны быть зафиксированы.

В частности, необходимо учесть следующее:

— активы и процессы ИБ должны быть идентифицированы и определены;

— личная ответственность за каждый актив и процесс ИБ должна быть обозначена и ее детали задокументированы;

— уровни авторизации должны быть определены и задокументированы;

— назначенные быть ответственными в сфере ИБ должны быть компетентными и в курсе всех событий в этой сфере;

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

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

Разделение обязанностей

Меры и средства

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

Рекомендации по реализации

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

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

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

Контакт с властями

Меры и средства

Необходимые контакты с органами власти должны поддерживаться.

Рекомендации по реализации

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

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

Контакт со специальными группами

Меры и средства

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

Рекомендации по реализации

Членство в группах или форумах следует рассматривать как средство для:

— повышения знания о «передовом опыте» и достижений ИБ на современном уровне;

— обеспечения уверенности в том, что понимание проблем ИБ является современным и полным;

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

— возможности получения консультаций специалистов по вопросам ИБ;

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

— организация подходящих связей для обеспечения обработки инцидентов ИБ.

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

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

ИБ при управлении проектом

Меры и средства

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

Рекомендации по реализации

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

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

— цели|задача| ИБ входили в проектные цели|задачу|;

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

— ИБ была частью всех фаз|стадии| используемой проектной методологии.

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

2.2. Мобильные устройства и удалённая работа

Цель: обеспечить безопасность удалённой работы и использования мобильных устройств.

Этот раздел рассматривает обеспечение ИБ при использовании:

— мобильных устройств;

— удалённой работы.

Мобильные устройства

Меры и средства

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

Рекомендации по реализации

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

Политика мобильных устройств должна рассматривать:

— регистрацию мобильных устройств;

— требования физической защиты;

— ограничения на установку ПО;

— требования к версиям ПО мобильных устройств и применению патчей;

— ограничения на подключение к информационным сервисам;

— управление доступом;

— криптографические средства;

— защита от вредоносного ПО;

— дистанционное выключение, удаление или блокировку;

— резервное копирование;

— использование веб-сервисов и веб-приложений.

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

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

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

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

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

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

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

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

Типовые различия:

— некоторые протоколы беспроводной безопасности несовершенны и имеют известные недостатки;

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

Удалённая работа

Меры и средства

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

Рекомендации по реализации

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

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

— предлагаемые условия удаленной работы;

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

— внедрение доступа к виртуальному рабочему столу, предотвращающего обработку и хранение информации на личном оборудовании;

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

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

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

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

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

— требования в отношении антивирусной защиты и межсетевых экранов.

Руководства и соглашения должны содержать следующее:

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

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

— предоставление приемлемого коммуникационного оборудования, в том числе безопасного удаленного доступа;

— физическую безопасность;

— роли и директивы семейного и гостевого доступа к оборудованию и информации;

— обслуживание и поддержку аппаратного и программного обеспечения;

— предоставление страховки;

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

— аудит и мониторинг безопасности;

— аннулирование пользователя, его прав доступа и возврат оборудования после завершения удаленной работы.

3. Безопасность, связанная с персоналом

Безопасность, связанную с персоналом, обеспечивают мероприятия:

— перед приемом на работу;

— во время работы;

— при увольнении или изменении должности.

3.1. Перед приемом на работу

Цель: Гарантировать, что сотрудники и подрядчики понимают свою ответственность и подходят для должностей, на которые они рассматриваются.

Перед приемом на работу проводятся следующие мероприятия:

— проверка благонадежности;

— трудовой договор.

Проверка благонадежности

Меры и средства

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

Рекомендации по реализации

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

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

— проверку подлинности документов об образовании и профессиональной квалификации;

— проверку биографии кандидата (на предмет полноты и точности);

— наличие положительных рекомендаций, в частности, в отношении деловых и личных качеств претендента;

— более детальную проверку, например, кредитоспособности или наличия судимости.

Если кандидат претендует на специальную роль в сфере ИБ, организация должна удостовериться в том, что он имеет необходимую:

— компетенцию для выполнения роли;

— степень доверия, если роль критична для организации.

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

Организация для процедур проверки должна определить критерии и ограничения, например, кто имеет право проверки, кто, когда и почему проводит проверку.

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

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

Трудовой договор

Меры и средства

Трудовой договор должен устанавливать ответственность сотрудника и подрядчика и организации в сфере ИБ.

Рекомендации по реализации

Условия работы сотрудников и подрядчиков должны отражать политику ИБ и, кроме того, разъяснять и устанавливать:

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

— правовую ответственность и права, например в части законодательства о защите персональных данных или авторском праве;

— обязанности по классификации информации и управлению активами, связанными с информацией, средствами обработки информации и информационными сервисами;

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

— действия, которые должны быть предприняты в случае несоблюдения требований ИБ.

Роли и ответственности в сфере ИБ должны быть доведены до кандидатов до их приема на работу.

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

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

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

3.2. Во время работы

Цель: Гарантировать, что все сотрудники и подрядчики осведомлены о своей ответственности и корректно выполняют свои обязанности в сфере ИБ.

Во время работы ИБ обеспечивают следующие составляющие:

— ответственность руководства;

— осведомленность в сфере ИБ;

— дисциплинарный процесс.

Ответственность руководства

Меры и средства

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

Рекомендации по реализации

Руководство обязано обеспечить уверенность в том, что сотрудники и подрядчики:

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

— обеспечены рекомендациями по формулированию их предполагаемых ролей в сфере ИБ в рамках организации;

— заинтересованы следовать политике ИБ организации;

— достигли уровня осведомленности в сфере ИБ, соответствующего их ролям и обязанностям в организации;

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

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

— осведомлены о необходимости информирования любым способом о нарушениях политик и процедур ИБ.

Руководство должно демонстрировать поддержку политик, процедур и мер ИБ и быть образцом для подражания.

Осведомленность персонала

Меры и средства

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

Рекомендации по реализации

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

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

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

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

Обучение в сфере ИБ должно также охватывать такие аспекты, как:

— утверждение приверженности руководства ИБ во всей организации;

— необходимость ознакомления с применяемыми правилами и обязательствами ИБ и их выполнения в соответствиис политиками, стандартами, законами, нормативами, контрактами и соглашениями;

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

— базовые процедуры ИБ (такие как оповещение об инциденте ИБ) и основные меры защиты (такие как аутентификация, антивирус, чистый рабочий стол);

— контактные источники дополнительной информации и консультация по мерам ИБ, включая дополнительные материалы по обучению в сфере ИБ.

Обучение должно происходить периодически. Те, кто получил новую должность или роль, к которой предъявляются другие требования ИБ, должны пройти обучение сначала с учетом новых требований (но не как новички) до начала выполнения своих ролей.

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

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

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

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

Дисциплинарный процесс

Меры и средства

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

Рекомендации по реализации

Не следует начинать дисциплинарный процесс, не получив предварительного подтверждения того, что нарушение ИБ произошло.

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

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

Дисциплинарный процесс может также стать мотивом или стимулом для уважительного отношения к требованиям ИБ.

3.3. Увольнение или изменение должности

Цель: Защищать интересы организации при увольнении или изменении должности сотрудника.

Увольнение или изменение обязанностей

Меры и средства

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

Рекомендация по реализации

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

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

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

4. Управление активами

Управление активами определяют следующие составляющие:

— ответственность за активы;

— безопасность активов;

— безопасность носителей информации.

4.1. Ответственность за активы

Цель: Определить активы организации и соответствующие ответственности по их защите.

Ответственность за активы обеспечивают следующие мероприятия:

— инвентаризация активов;

— принадлежность активов;

— использование активов;

— возврат активов.

Инвентаризация активов

Меры и средства

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

Рекомендации по реализации

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

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

Владение активом и классификация информации должны быть определены в отношении каждого актива.

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

Принадлежность активов

Меры и средства

Активы, содержащиеся в описи, должны иметь владельцев.

Рекомендации по реализации

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

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

Владелец актива должен:

— удостовериться, что активы инветаризированы;

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

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

— принять надлежащие меры в случае уничтожения или разрушения актива.

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

Использование активов

Меры и средства

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

Рекомендации по реализации

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

Возврат активов

Меры и средства

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

Рекомендации по реализации

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

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

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

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

4.2. Безопасность информации

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

Безопасность активов обеспечивают следующие мероприятия:

— классификация информации;

— маркировка информации;

— обработка активов.

Классификация информации

Меры и средства

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

Рекомендации по реализации

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

Владельцы информационных активов должны нести ответственность за их классификацию.

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

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

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

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

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

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

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

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

— разглашение не приносит вреда;

— разглашение вызывает небольшое затруднение и оперативное неудобство;

— разглашение имеет серьезное короткое влияние на операции или тактические цели;

— разглашение имеет серьезное влияние на долговременные стратегические цели или подвергает деятельность организации риску.

Маркировка информации

Меры и средства

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

Рекомендации по реализации

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

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

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

Выходные данные ИС, содержащие информацию, классифицированную как чувствительную или критичную, должны иметь соответствующую классификационную метку.

Маркировка классифицированной информации является ключевым требованием для соглашений по распространению информации. Физические метки и метаданные являются общепризнаной формой маркировки.

Обработка активов

Меры и средства

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

Рекомендации по реализации

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

Необходимо рассмотреть следующие рекомендации:

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

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

— соответствие защиты любых копий информации уровню защиты исходной информации;

— хранение ИТ активов в соответствии с рекомендациями изготовителей;

— четкая маркировка всех копий носителей информации для авторизованного получателя.

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

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

4.3. Безопасность носителей информации

Цель: Предотвратить несанкционированные действия с информацией, хранящейся на носителях информации.

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

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

— уничтожение носителей;

— транспортировка носителей.

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

Меры и средства

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

Рекомендации по реализации

Необходимо рассмотреть следующие рекомендации:

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

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

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

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

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

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

— должна вестись регистрация носителей для уменьшения возможности потери данных;

— сменные дисковые накопители разрешается использовать только в случае, обусловленном потребностями бизнеса;

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

Процедуры и уровни авторизации должны быть задокументированы.

Уничтожение носителей

Меры и средства

Если носитель больше не нужен, он должен быть надежно уничтожен в соответствии с формальной процедурой.

Рекомендации по реализации

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

Необходимо рассмотреть следующие рекомендации:

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

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

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

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

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

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

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

Транспортировка носителей

Меры и средства

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

Рекомендации по реализации

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

— должен использоваться надежный транспорт или курьеры;

— список разрешенных курьеров необходимо согласовывать с руководством;

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

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

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

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

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

5. Управление доступом

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

— правила разграничения доступа;

— управление доступом пользователей;

— ответственность пользователя;

— управление доступом к системе и приложениям.

5.1. Требования разграничения доступа

Цель: Ограничить доступ к информации и средствам обработки информации.

Требования по управлению доступом определяют следующие составляющие:

— правила разграничения доступа;

— доступ к сетям и сетевым сервисам.

Правила разграничения доступа

Меры и средства

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

Рекомендации по реализации

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

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

Правила должны учесть следующее:

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

— политики распространения информации и авторизации, например, общепризнанные принципы и уровни ИБ и классификацию информации;

— согласованность между правами доступом и политиками классификации информации систем и сетей;

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

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

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

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

— требования к периодическому пересмотру управления доступом;

— аннулирование прав доступа;

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

— роли привилегированного доступа.

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

— установление правил на основании предпосылки «Запрещено все, что не разрешено» вместо «Разрешено все, что не запрещено»;

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

— изменения пользовательских разрешений, инициированные автоматически ИС и администратором;

— наличие правил, требующих определенного утверждения перед введением в действие и не требующих.

Правила разграничения доступа должны поддерживаться формальными процедурами и определять ответственности.

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

Два общепризнанных принципа правил разграничения доступа:

— знание: наличие доступа только к информации, необходимой для выполнения задач (разные задачи/роли означают разную потребность знаний и следовательно разный профиль доступа);

— использование: наличие доступа только к средствам обработки информации, необходимым для выполнения задачи/работы/роли (ИТ оборудование, приложения, процедуры, кабинеты).

Доступ к сетям и сетевым сервисам

Меры и средства

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

Рекомендации по реализации

Следует сформулировать политику использования сетей и сетевых услуг.

В политике необходимо рассмотреть:

— сети и сетевые услуги, к которым разрешен доступ;

— процедуры авторизации для определения того, кому и к каким сетям и сетевым услугам разрешен доступ;

— процедуры и средства управления по защите доступа к сетевым подключениям и сетевым услугам;

— средства доступа к сетям и сетевым услугам (например, VPN или беспроводной сети);

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

— мониторинг использования сетевых сервисов.

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

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

5.2. Управление доступом пользователей

Цель: Обеспечить авторизованный доступ пользователей и предотвратить неавторизованный доступ к системам и сервисам.

Управление доступом пользователей обеспечивают следующие мероприятия:

— регистрация и ее отмена;

— предоставление доступа;

— пересмотр прав доступа;

— удаление или изменение прав доступа.

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

— правами привилегированного доступа;

— паролями.

Регистрация и ее отмена

Меры и средства

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

Рекомендации по реализации

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

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

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

— периодическую идентификацию и деактивацию или удаление ненужных идентификаторов пользователя;

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

Разрешение или запрет доступа к информации и средствам ее обработки состоит из следующих двух этапов:

— создание и активация или деактивация идентификатора пользователя;

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

Предоставление доступа

Меры и средства

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

Рекомендации по реализации

Процесс предоставления доступа должен включать:

— получение полномочий от собственника ИС или сервиса для их использования;

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

— гарантию того, что права доступа не будут активированы (например, провайдером услуг) до завершения процедур авторизации;

— ведение централизованной записи прав доступа, предоставленных идентификатору пользователя для доступа к ИС и сервисам;

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

— периодический пересмотр прав доступа вместе с собственниками ИС и сервисов.

Пересмотр прав доступа

Меры и средства

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

Рекомендации по реализации

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

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

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

— полномочия привилигированных прав доступа должны пересматриваться чаще;

— присвоение привилегий должно регулярно проверяться, чтобы излишних привилегий никто не имел;

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

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

Меры и средства

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

Рекомендации по реализации

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

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

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

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

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

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

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

— ценность активов, доступных в настоящий момент.

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

Управление правами привилегированного доступа

Меры и средства

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

Рекомендации по реализации

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

Необходимо рассмотреть следующие шаги:

— определение прав привилегированного доступа в отношении каждой системы или процесса, например, ОС, СУБД, приложения и пользователей, которым эти привилегии должны быть присвоены;

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

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

— определение требований по сроку действия прав привилегированного доступа;

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

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

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

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

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

Управление паролями

Меры и средства

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

Рекомендации по реализации

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

— пользователи должны подписать заявление о сохранении персонального пароля в тайне и хранить групповые пароли членов группы (например, при общем доступе); это подписанное заявление должно содержать сроки и условия трудоустройства;

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

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

— временные пароли следует выдавать пользователям безопасным способом, необходимо исключить использование незащищенного (открытого) текста сообщений электронной почты;

— временные пароли должны быть уникальны для каждого пользователя и не должны быть легко угадываемыми;

— пользователи должны подтверждать получение паролей;

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

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

5.3. Ответственность пользователя

Цель: Сделать пользователя ответственным за хранение информации аутентификации (пароля).

Пользование паролем

Меры и средства

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

Рекомендации по реализации

Всем пользователям надо посоветовать следующее:

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

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

— менять секретную информацию аутентификации при малейшем признаке компрометации;

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

• легко запомнить;

• не содержит того, что можно легко угадать, или какую-либо персональную информацию (например, имена, номера телефонов, даты рождения и т. п.);

• неуязвим для словарных атак (т. е. не содержит слов, включенных в словари);

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

• если временный, сразу сменить при первом входе в систему;

— не делиться индивидуальной секретной информацией аутентификации пользователя;

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

— не использовать одну и ту же секретную информацию аутентификации для бизнес и не бизнес-целей.

Применение технологии «единого входа» (Single Sign-On, SSO) или других инструментов управления секретной информацией аутентификации снижает ее объем и тем самым может повысить эффективность ее защиты. Однако эти инструменты могут усилить влияние от разглашения секретной информации аутентификации.

5.4. Управление доступом к системе и приложениям

Цель: Предотвратить несанкционированный доступ к системе и приложениям.

Управление доступом к системе определяют следующие составляющие:

— процедуры безопасного входа;

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

Управление доступом к приложениям обеспечивают следующие мероприятия:

— ограничение доступа к информации;

— использование системного ПО;

— управление доступом к исходным кодам программ.

Процедуры безопасного входа

Меры и средства

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

Рекомендация по реализации

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

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

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

Правильная процедура входа должна:

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

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

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

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

— защищать от перебора попыток входа;

— регистрировать успешные и неуспешные попытки входа;

— повысить событие безопасности в случае выявления потенциальных попыток и реального нарушения мер защиты входа;

— отображать следующую информацию после завершения успешного входа:

• дату и время предыдущего успешного входа;

• детали любых неуспешных попыток входа, начиная с последнего успешного входа;

— не отображать введенный пароль;

— не передавать пароли открытым текстом по сети;

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

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

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

Если пароли передаются открытым текстом в течение сеанса входа по сети, они могут быть перехвачены сетевой «sniffer» — программой (анализатором трафика).

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

Меры и средства

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

Рекомендации по реализации

Система управления паролями должна:

— предписывать использование индивидуальных идентификаторов пользователя и паролей для установления ответственности;

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

— предписывать использование качественных паролей;

— заставлять пользователей менять временные пароли при первом начале сеанса;

— предписывать регулярную смену паролей и по необходимости;

— вести учет ранее использованных паролей и предотвращать их повторное использование;

— не отображать пароли на экране при их вводе;

— хранить файлы паролей отдельно от прикладных системных данных;

— хранить и передавать пароли в защищенной форме.

Ограничение доступа к информации

Меры и средства

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

Рекомендации по реализации

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

Для обеспечения ограничения доступа необходимо рассмотреть следующее:

— создание пунктов меню управления доступом к прикладным функциям системы;

— контроль, к каким данным может получить доступ конкретный пользователь;

— контроль прав доступа пользователей, например, чтение, запись, удаление, изменение;

— контроль прав доступа других прикладных программ;

— ограничение информации, содержащейся в выходных данных;

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

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

Меры и средства

Использование системного программного обеспечения (далее — ПО), способного обойти меры защиты системы и приложения, должно быть ограничено и строго контролироваться.

Рекомендации по реализации

Необходимо рассмотреть следующие рекомендации:

— использование процедур идентификации, аутентификации и авторизации для системного ПО;

— отделение системного ПО от прикладного;

— ограничение использования системного ПО минимальным числом доверенных авторизованных пользователей;

— авторизация на специальное использование системного ПО;

— ограничение доступности системного ПО, например, на время внесения санкционированных изменений;

— регистрация всех использований системного ПО;

— определение и документирование уровней полномочий в отношении системного ПО;

— удаление или блокирование ненужного системного ПО;

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

Контроль доступа к исходному коду программы

Меры и средства

Доступ к исходному коду программы должен быть ограничен.

Рекомендации по реализации

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

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

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

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

— персонал поддержки не должен иметь неограниченный доступ к библиотекам исходного кода программ;

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

— распечатки (листинги) программ следует хранить в безопасной среде;

— в журнале аудита должны фиксироваться все обращения к библиотекам исходного кода программ;

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

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

6. Криптография

6.1. Средства криптографии

Цель: Обеспечить корректное и эффективное использование криптографии для защиты конфиденциальности, достоверности и/или целостности информации.

Управление средствами криптографии определяют следующие составляющие:

— политика использования средств криптографии;

— управление ключами.

Политика использования средств криптографии

Меры и средства

Политика использования средств криптографии для защиты информации должна быть разработана и внедрена.

Рекомендации по реализации

При разработке политики криптографии необходимо учитывать следующее:

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

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

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

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

— роли и ответственности, например, кто отвечает за:

• внедрение политики;

• управление ключами, включая генерацию ключей;

— стандарты, которые должны быть приняты для эффективной реализации во всей организации (какое решение используется для каких бизнес-процессов);

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

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

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

— конфиденциальности — шифрованием чувствительной или критичной информации как хранимой, так и передаваемой;

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

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

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

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

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

Управление ключами

Меры и средства

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

Рекомендации по реализации

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

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

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

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

— генерации ключей для различных криптосистем и приложений;

— изготовления и получения сертификатов открытых ключей;

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

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

— замены или обновления ключей, включая правила и сроки замены ключей;

— действий в отношении скомпрометированных ключей;

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

— восстановления ключей, которые были утеряны или испорчены;

— резервного копирования или архивирования ключей;

— уничтожения ключей;

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

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

7. Физическая и экологическая безопасность

Физическую и экологическую безопасность определяют следующие составляющие:

— зоны безопасности;

— безопасность оборудования.

7.1. Зоны безопасности

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

Зоны безопасности определяют следующие составляющие:

— периметр физической безопасности;

— работа в зонах безопасности;

— зоны доставки и погрузки/разгрузки.

— управление физическим доступом;

— защита помещений и оборудования;

— защита от окружающей среды.

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

Меры и средства

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

Рекомендация по реализации

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

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

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

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

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

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

— должны быть установлены физические барьеры для предотвращения несанкционированного физического доступа и экологического загрязнения;

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

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

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

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

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

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

Работа в зонах безопасности

Меры и средства

Процедуры работы в зонах безопасности должны быть разработаны и внедрены.

Рекомендации по реализации

Необходимо рассмотреть следующие рекомендации:

— о существовании зоны безопасности и проводимых там работах персонал должен быть осведомлен только в случае необходимости;

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

— пустующие зоны безопасности необходимо физически запирать и периодически просматривать;

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

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

Зоны доставки и погрузки/разгрузки

Меры и средства

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

Рекомендации по реализации

Необходимо рассмотреть следующие рекомендации:

— доступ к зоне доставки и погрузки/разгрузки из-вне здания должен быть ограничен только уполномоченным персоналом;

— зона доставки и погрузки/разгрузки не должна предоставлять персоналу поставщика при погрузке и разгрузке доступа к другим частям здания;

— должна быть обеспечена безопасность внешних дверей зоны доставки и погрузки/разгрузки в то время, когда внутренние двери открыты;

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

— поступающий материал должен регистрироваться при въезде на площадку в соответствии с процедурами управления активами;

— по возможности, ввозимые и вывозимые грузы должны быть физически разделены;

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

Управление физическим доступом

Меры и средства

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

Рекомендация по реализации

Следует принимать во внимание следующие рекомендации:

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

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

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

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

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

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

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

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

Защита помещений и оборудования

Меры и средства

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

Рекомендации по реализации

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

— ключевое оборудование должно быть расположено в местах, где ограничен доступ посторонних лиц;

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

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

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

Защита от окружающей среды

Меры и средства

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

Рекомендации по реализации

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

7.2. Безопасность оборудования

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

Безопасность оборудования определяют следующие составляющие:

— размещение и защита оборудования;

— вспомогательное оборудование;

— кабельная безопасность;

— обслуживание оборудования.

— перемещение активов;

— безопасность активов вне территории организации;

— безопасное уничтожение активов;

— безопасность оборудования без присмотра;

— политика чистого рабочего стола и экрана.

Размещение и защита оборудования

Меры и средства

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

Рекомендации по реализации

Необходимо рассмотреть следующие рекомендации для защиты оборудования:

— оборудование следует размещать таким образом, чтобы свести к минимуму доступ в рабочие зоны;

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

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

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

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

— необходимо установить правила приема пищи, питья и курения вблизи средств обработки информации;

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

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

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

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

Вспомогательное оборудование

Меры и средства

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

Рекомендации по реализации

Вспомогательное оборудование (например, связи, электро-, водо-, газоснабжения, канализации, вентиляции, кондиционирования) должно:

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

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

— регулярно проверяться и тестироваться на предмет уверенности в их должном функционировании;

— при необходимости иметь сигнализацию выявления неисправности;

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

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

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

Кабельная безопасность

Меры и средства

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

Рекомендации по реализации

Следует рассмотреть для кабельной безопасности следующие рекомендации:

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

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

— для чувствительных или критичных систем дальнейшие меры защиты должны включать:

• использование бронированного кабелепровода и закрытие комнат и боксов на контрольных и конечных точках;

• использование электромагнитного экранирования для защиты кабелей;

• проведение технических чисток и физических проверок кабелей на предмет подключения устройств перехвата;

• контроль доступа к коммутационным панелям и кабельным помещениям.

Обслуживание оборудования

Меры и средства

Оборудование должно правильно обслуживаться для обеспечения его непрерывной доступности и целостности.

Рекомендации по реализации

Следует рассмотреть для обслуживания оборудования следующие рекомендации:

— оборудование должно обслуживаться в соответствии с рекомендуемой поставщиком периодичностью и техническими регламентами;

— техническое обслуживание и ремонт оборудования должны проводиться только уполномоченным персоналом;

— следует хранить записи обо всех неисправностях и всех видах технического обслуживания;

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

— все техническое обслуживание, предусмотренное полисом страховки, должно быть выполнено;

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

Перемещение активов

Меры и средства

Оборудование, информация или ПО не должны перемещаться за пределы организации без предварительного разрешения.

Рекомендации по реализации

Необходимо учитывать следующие рекомендации:

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

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

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

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

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

Безопасность удаленных активов

Меры и средства

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

Рекомендации по реализации

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

Необходимо учесть следующие рекомендации для защиты удаленных активов:

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

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

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

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

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

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

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

Безопасное уничтожение оборудования

Меры и средства

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

Рекомендации по реализации

Оборудование перед уничтожением или повторным использованием должно быть проверено на наличие носителей информации.

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

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

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

— процесс шифрования достаточно сильный и охватывает весь диск (включая свободное пространство, файлы подкачки и т. п.);

— длина ключей достаточна для противодействия атакам перебора;

— ключи шифрования содержатся в тайне (например, не хранятся на самом диске).

Методы безопасной перезаписи носителей могут быть разными в зависимости от технологии носителей. Инструменты перезаписи следует проверять на предмет соответствия технологии носителей.

Безопасность оборудования без присмотра

Меры и средства

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

Рекомендация по реализации

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

Пользователям рекомендуется:

— завершать активные сеансы по окончании работы, если отсутствует соответствующий механизм блокировки, например, защищенная паролем экранная заставка;

— выйти из приложений и сетевых сервисов, если они не нужны;

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

Политика чистого стола и экрана

Меры и средства

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

Рекомендации по реализации

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

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

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

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

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

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

8. Безопасность операций

Безопасность операций определяют следующие составляющие:

— операционные процедуры;

— контроль системного ПО;

— защита от вредоносного ПО;

— мониторинг и логи.

— резервное копирование;

— управление техническими уязвимостями;

— проведение аудита ИС.

8.1. Операционные процедуры

Цель: Обеспечить правильное и безопасное использование средств обработки информации.

Операционные процедуры обеспечивают следующие мероприятия:

— документирование процедур;

— управление изменениями;

— управление мощностью;

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

Документирование процедур

Меры и средства

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

Рекомендации по реализации

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

Операционные процедуры должны определять эксплуатационные инструкции, включающие:

— инсталляцию и конфигурацию систем;

— обработку и управление информацией, как автоматизированное, так и ручное;

— резервное копирование;

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

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

— необходимые контакты поддержки, в том числе внешней, на случай неожиданных эксплуатационных или технических проблем;

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

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

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

— процедуры мониторинга.

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

Меры и средства

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

Рекомендации по реализации

В частности, необходимо рассмотреть следующие аспекты:

— определение и регистрацию существенных изменений;

— планирование и тестирование изменений;

— оценку возможных влияний таких изменений, включая влияния на ИБ;

— формальную процедуру утверждения предлагаемых изменений;

— проверку соответствия требованиям ИБ;

— подробное информирование об изменениях всех заинтересованных лиц;

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

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

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

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

Управление мощностью

Меры и средства

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

Рекомендации по реализации

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

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

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

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

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

— удаление устаревших данных (чистка диска);

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

— оптимизация групповых процессов и режимов;

— оптимизация логики приложения и запросов базы данных;

— запрет или ограничения трафика для ресурсоемкого сервиса, если он не критичен для бизнеса (например, потоковое видео).

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

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

Меры и средства

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

Рекомендации по реализации

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

Необходимо рассмотреть следующие вопросы:

— правила перевода ПО между состояниями разработки и эксплуатации должны быть определены и задокументированы;

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

— изменения в эксплуатируемых системах и приложениях должны тестироваться в среде тестирования прежде, чем будут применены в них;

— тестирование не должно проводиться в эксплуатируемых системах, кроме исключительных случаев;

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

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

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

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

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

Поэтому разделение сред разработки, тестирования и эксплуатации целесообразно для снижения риска непредвиденного изменения или несанкционированного доступа к эксплуатационному ПО и бизнес-данным.

8.2. Контроль системного ПО

Цель: Обеспечить целостность операционных систем (далее — ОС).

Установка системного ПО

Меры и средства

Должны быть внедрены процедуры контроля установки системного ПО

Рекомендация по реализации

Для контроля изменений системного ПО необходимо рассмотреть следующие рекомендации:

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

— ОС должны содержать утвержденный исполняемый код и компиляторы;

— приложения и системное ПО следует внедрять только после всестороннего и успешного тестирования; тесты должны охватывать пригодность, безопасность, влияние на другие системы, удобство использования и проводиться на отдельных системах; все соответствующие библиотеки программных исходных кодов должны быть обновлены;

— должна использоваться система контроля конфигурации для контроля всего внедренного ПО и системной документации;

— следует внедрить стратегию отката перед осуществлением изменений;

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

— предыдущие версии приложений ПО следует хранить на случай непредвиденных обстоятельств;

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

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

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

8.3. Защита от вредоносного ПО

Цель: Обеспечить защиту информации и средств ее обработки от вредоносного ПО.

Меры защиты от вредоносного ПО

Меры и средства

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

Рекомендации по реализации

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

— создание формальной политики запрета на использование неразрешенного ПО;

— внедрение средств обнаружения или предотвращения использования неразрешенного ПО (например, ведения «белого списка»);

— внедрение средств обнаружения или предотвращения использования известных и подозреваемых вредоносных сайтов (например, ведения «черного списка»);

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

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

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

— установка и регулярное обновление ПО обнаружения и исправления вредоносного ПО по сканированию компьютеров и носителей информации в качестве меры предосторожности или на регулярной основе;

следует проводить сканирование на наличие вредоносного ПО перед использованием:

• любых файлов, полученных с помощью сетей или других носителей;

• электронных почтовых прикрепленных файлов и загрузок;

• веб-сайтов;

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

— подготовка соответствующиих планов по обеспечению непрерывности бизнеса в части восстановления после вредоносных атак, включая все необходимые меры по резервному копированию и восстановлению данных и ПО;

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

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

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

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

— изоляция от окружающей среды реального катастрофического влияния.

8.4. Резервировное копирование

Цель: Обеспечить защиту от потери данных.

Резервируемая информация

Меры и средства

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

Рекомендация по реализации

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

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

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

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

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

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

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

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

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

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

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

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

8.5. Протоколирование и мониторинг

Цель: Записывать события и получать фактические данные.

Протоколирование и мониторинг обеспечивают следующие мероприятия:

— протоколирование событий;

— защита логов;

— ведение логов пользователей;

— синхронизация часов.

Протоколирование событий

Меры и средства

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

Рекомендации по реализации

Логи должны включать, при необходимости:

— идентификаторы пользователей;

— системные действия;

— даты, время и детали ключевых событий, например начало и завершение сеанса;

— идентичность и местоположение устройства, по возможности, и идентификатор системы;

— регистрацию успешных и отклоненных попыток доступа к системе;

— регистрацию успешных и отклоненных попыток доступа к данным или другим ресурсам;

— изменения конфигурации системы;

— использование привилегий;

— использование системного и прикладного ПО;

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

— сетевые адреса и протоколы;

— сигналы тревоги системы управления доступом;

— активация и деактивация систем защиты, таких как антивирусы и системы обнаружения вторжения;

— запись операций, сделанных пользователем в приложениях.

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

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

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

Защита логов

Меры и средства

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

Рекомендации по реализации

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

— изменения типов записываемых сообщений;

— редактирование или удаление файлов логов;

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

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

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

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

Логи пользователя

Меры и средства

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

Рекомендации по реализации

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

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

Синхронизация часов

Меры и средства

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

Рекомендации по реализации

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

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

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

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

8.6. Управление техническими уязвимостями

Цель: Предотвратить использование технических уязвимостей.

Управление техническими уязвимостями обеспечивают следующие мероприятия:

— обработка технических уязвимостей;

— ограничение на установку ПО.

Обработка технических уязвимостей

Меры и средства

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

Рекомендации по реализации

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

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

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

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

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

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

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

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

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

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

• отключение сервисов или возможностей, связанных с уязвимостью;

• адаптирование или добавление средств контроля доступа, например, сетевые экраны или границы;

• расширенный мониторинг для выявления актуальных атак;

• повышение осведомленности об уязвимости;

— следует вести журнал аудита для всех предпринятых процедур;

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

— в первую очередь надо обращать внимание на системы с высоким уровнем риска;

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

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

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

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

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

Ограничение на установку ПО

Меры и средства

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

Рекомендации по реализации

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

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

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

8.7. Проведение аудита ИС

Цель: Минимизировать влияние аудиторских действий на действующие системы.

Контроль аудита систем

Меры и средства

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

Рекомендации по реализации

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

— аудиторские требования в отношении доступа к системам и данным следует согласовать|согласиться| с соответствующим руководством;

— контекст технических аудиторских тестов следует согласовать|согласиться| и контролировать|управлять, контролировать|;

— аудиторские тесты должны| иметь ограничение доступа к ПО и данным в виде «только для чтения»;

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

— требования специальной или дополнительной|аддиционной| обработки следует определить|опознать| и согласовать|согласиться|;

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

— все факты доступа|подход, припадок, прирост, приступ, проход| нужно контролировать и протоколировать, чтобы остался документальный след|хвост|.

От автора

В 1969 году была основана Ассоциация аудита и контроля ИС «ISACA» (Information System Audit and Control Association), которая в настоящее время объединяет около 20 тысяч членов из более чем 100 стран. Ассоциация координирует деятельность более чем 12 тысяч аудиторов ИС. Официальный сайт: www.isaca.org.

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

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

«CoBiT» (Control оbjectives for information and related technologies — Контрольные объекты информационных и смежных технологий) — это открытый стандарт, первое издание которого в 1996 году было продано в 98 странах по всему миру и облегчило работу профессиональных аудиторов в сфере информационных технологий.

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

Основополагающее правило, положенное в основу «CoBiT»: ресурсы ИС должны управляться набором естественно сгруппированных процессов для обеспечения организации необходимой и надежной информацией. Версию 4.1 стандарта на украинском языке можно скачать на сайте «ISACA».

9. Безопасность связи

Безопасность связи обеспечивают следующие мероприятия:

— управление сетевой безопасностью;

— передача информации.

9.1. Управление сетевой безопасностью

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

Управление сетевой безопасностью определяют следующие составляющие:

— сетевые меры защиты;

— безопасность сетевых сервисов;

— разделение в сетях.

Сетевые меры защиты

Меры и средства

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

Рекомендации по реализации

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

— следует установить обязанности и процедуры управления сетевым оборудованием;

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

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

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

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

— системы должны проходить в сети аутентификацию;

— подключения системы к сети должны ограничиваться.

Безопасность сетевых сервисов

Меры и средства

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

Рекомендации по реализации

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

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

Сетевые сервисы включают обеспечение подключений, личные сетевые сервисы и сети платных услуг (англ. value added network, VON) и управленческие решения по сетевой безопасности, такие как сетевые экраны и системы обнаружения вторжения. Диапазон таких сервисов простирается от простого неуправляемого траффика до комплексных платных услуг.

Особенностями безопасности сетевых сервисов могут быть:

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

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

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

Разделение в сетях

Меры и средства

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

Рекомендации по реализации

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

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

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

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

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

9.2. Передача информации

Цель: Поддерживать безопасность информации, передаваемой внутри организации и в любую стороннюю организацию.

Передачу информации определяют следующие составляющие:

— политика передачи информации;

— соглашения о передаче информации;

— электронный обмен информацией;

— соглашение о неразглашении.

Политики передачи информации

Меры и средства

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

Рекомендации по реализации

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

— процедуры защиты передаваемой информации от перехвата, копирования, модификации, ложной маршрутизации и разрушения:

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

— процедуры защиты передаваемой чувствительной электронной информации в форме прикрепленного файла;

— политику или руководящие принципы приемлемого использования средств связи;

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

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

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

— контроль и ограничения использования средств коммуникаций, например, автоматической пересылки электронной почты на внешние адреса;

— напоминание сотрудникам о принятии мер предосторожности, чтобы не раскрыть конфиденциальную информацию;

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

— напоминание сотрудникам о проблемах использования факсимильных аппаратов или сервисов, а именно:

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

• умышленное и неумышленное программирование машин для отправки сообщения на специальные номера;

• отправка документов и сообщений на неправильный номер из-за попадания не туда или неправильно записанных номеров.

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

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

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

Соглашения о передаче информации

Меры и средства

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

Рекомендация по реализации

Соглашения о передаче информации должны включать следующее:

— обязанности руководства по контролю и уведомлению о передаче, рассылке и получению информации;

— процедуры обеспечения отслеживаемости и неотказуемости;

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

— эскроу соглашения (хранятся у третьего лица и вступают в силу только при выполнении определенного условия);

— стандарты идентификации курьера;

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

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

— технические стандарты записи и считывания информации и ПО;

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

— поддержка цепочки поставок транзитной информации;

— применимые уровни контроля доступа.

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

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

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

Электронный обмен сообщениями

Меры и средства

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

Рекомендации по реализации

Необходимо учитывать следующие рекомендации ИБ:

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

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

— надежность и доступность сервиса;

— законодательные требования, например, по использованию ЭЦП;

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

— строгие уровни аутентификации доступа со стороны общедоступных сетей.

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

Соглашение о неразглашении

Меры и средства

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

Рекомендации по реализации

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

Чтобы определить требования NDA, необходимо учесть следующие факторы:

— определение информации, подлежащей защите (например, конфиденциальная информация);

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

— необходимые действия при окончании срока действия NDA;

— обязанности и действия подписавших NDA лиц по предотвращению несанкционированного разглашения информации;

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

— разрешенное использование конфиденциальной информации и права подписавших NDA лиц по ее использованию;

— право на аудит и мониторинг деятельности, связанной с конфиденциальной информацией;

— условия возврата или уничтожения информации в случае приостановления действия NDA;

— план действий на случай нарушения NDA.

NDA должно соответствовать действующему законодательству и нормативам.

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

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

10. Покупка, разработка и сопровождение ИС

Покупка, разработка и сопровождение ИС определяют следующие составляющие:

— требования безопасности ИС;

— ИБ при разработке ИС;

— тестовые данные.

10.1. Требования безопасности ИС

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

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

— анализ требований ИБ;

— ИБ сервисов в общедоступных сетях;

— ИБ транзакций прикладных сервисов.

Анализ требований ИБ

Меры и средства

Требования ИБ должны быть включены в требования для новых ИС или по усовершенствованию действующих ИС.

Рекомендации по реализации

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

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

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

Требования ИБ должны также содержать:

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

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

— информирование пользователей и операторов об их обязанностях и ответственностях;

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

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

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

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

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

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

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

ИБ сервисов в общедоступных сетях

Меры и средства

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

Рекомендации по реализации

Необходимо, чтобы ИБ прикладных сервисов в общедоступных сетях содержала следующее:

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

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

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

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

— уровень доверия к целостности ключевых документов;

— требования защиты любой конфиденциальной информации;

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

— степень проверки платежной информации, предоставленной заказчиком;

— выбор наиболее подходящей расчетной формы платежа для защиты от мошенников;

— уровень защиты конфиденциальности и целостности сведений о заказе;

— предотвращение потери или дублирования сведений о сделке;

— ответственность, связанная с любыми фиктивными сделками;

— страховые требования.

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

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

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

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

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

ИБ транзакций сервисов

Меры и средства

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

Рекомендации по реализации

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

— использование электронных подписей каждым участником сделки;

— все аспекты сделки, т. е. обеспечение уверенности в том, что:

• пароли всех пользователей проверены и действительны;

• сделка остается конфиденциальной;

• приватность всех участников сохраняется;

— каналы связи между всеми участниками зашифрованы;

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

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

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

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

10.2. ИБ при разработке ИС

Цель: Обеспечить разработку и внедрение ИБ в рамках жизненного цикла разработки ИС.

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

— политика ИБ при разработке;

— управление изменением ИС;

— анализ приложений после изменений ОП;

— ограничение изменений пакетов программ.

ИБ при разработке ИС обеспечивают следующие меры:

— разработка безопасных систем;

— безопасность среды разработки;

— аутсорсинг разработки;

— тестирование безопасности;

— приёмное тестирование.

Политика ИБ при разработке

Меры и средства

В организации должны быть установлены и применены правила разработки ПО и ИС для разработок внутри организации.

Рекомендации по реализации

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

— безопасность среды разработки;

— руководство по безопасности жизненного цикла разработки ПО:

• безопасность методологии разработки ПО;

• правила написания безопасного кода для каждого используемого языка программирования;

— требования безопасности в фазе проектирования;

— контрольные точки безопасности на этапах проектирования;

— безопасные хранилища;

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

— требуемые знания по безопасности ПО;

— способность разработчиков избегать, находить и фиксировать уязвимости.

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

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

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

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

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

Меры и средства

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

Рекомендации по реализации

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

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

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

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

Процедуры управления изменениями должны включать (но не ограничиваться):

— ведение учета согласованных уровней полномочий;

— обеспечение изменений, введенных уполномоченными пользователями;

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

— идентификация всех субъектов ПО, информации, баз данных и аппаратных средств, требующих изменений;

— идентификация и выбор критического кода безопасности для минимизации вероятности проявления известных слабых мест безопасности;

— получение формального одобрения на детальные предложения по изменениям перед началом работы;

— одобрение уполномоченного пользователя всех изменений до их реализации;

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

— управление версиями ПО для всех обновлений;

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

— внедрение изменений в согласованное время и без нарушений бизнес-процессов.

Изменение ПО может привести к изменению среды и наоборот.

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

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

Анализ приложений после изменений операционной платформы

Меры и средства

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

Рекомендации по реализации

Этот процесс должен охватывать:

— анализ прикладных программ и процедур целостности на предмет отсутствия нарушений после изменений операционной платформы:

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

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

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

Ограничение изменений пакетов программ

Меры и средства

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

Рекомендации по реализации

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

— риск компрометации встроенных средств контроля и процедур целостности;

— необходимость получения согласия поставщика ПО;

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

— последствия в случае, если организация в результате внесенных изменений станет ответственной за дальнейшее сопровождение ПО;

— совместимость с другим ПО при использовании.

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

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

Разработка безопасных систем

Меры и средства

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

Рекомендации по реализации

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

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

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

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

Безопасность среды разработки

Меры и средства

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

Рекомендации по реализации

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

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

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

— соответствующие внешние и внутренние|внутриконтурные| требования, например, правила или политики|полиса|;

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

— надежность персонала, работающего в среде разработки;

— степень|степень| аутсорсинга в разработке системы |разработкой|;

— необходимость разделения сред разных|другого| разработок |разработки|;

— контроль доступа к среде разработки |разработки|;

— мониторинг изменения|замены| среды и кода, хранящегося|запоминает, аккумулирует| там;

— хранение резервных копий|запоминают, аккумулируют| в|у| удаленном безопасном месте|местоположения, месторасположения||узла, участка|;

— контроль |контролируйте| движения данных из среды и в среду разработки.

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

Аутсорсинг разработки

Меры и средства

Организация должна руководить аутсорсингом разработки системы и мониторить его.

Рекомендации по реализации

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

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

— договорные требования к безопасным методикам по созданию, кодированию и тестированию;

— предоставление внешнему разработчику применимой модели угроз;

— приемные испытания качества и точности результатов;

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

— предоставление доказательства достаточного тестирования на предмет отсутствия вредоносного ПО;

— предоставление доказательства достаточного тестирования на предмет наличия известных уязвимостей;

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

— договорное право на аудит мер защиты и процессов разработки;

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

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

Тестирование безопасности

Меры и средства

Тестирование функциональности безопасности должно осуществляться в течение ее разработки.

Рекомендации по реализации

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

Независимое тестирование должно (и для внутренней|собственный|, и для аутсорсинговой разработки|разработки|) гарантировать, что|который| системные работы проведены именно так, как ожидалось. Степень тестирования должна соответствовать важности и типу|натуре, характеру| системы.

Приёмное тестирование

Меры и средства

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

Рекомендации по реализации

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

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

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

10.3. Тестовые данные

Цель: Обеспечить защиту данных, используемых при тестировании.

Защита тестовых данных

Меры и средства

Тестовые данные должны тщательно подбираться, защищаться и контролироваться.

Рекомендации по реализации

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

Необходимо применять следующие принципы для защиты тестовых данных:

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

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

— после завершения тестирования всю операционную информацию следует немедленно удалить из среды тестирования;

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

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

11. Взаимоотношения с поставщиками

Взаимоотношения с поставщиками определяют следующие составляющие:

— ИБ в отношениях с поставщиками;

— управление оказанием услуг.

11.1. ИБ в отношениях с поставщиками

Цель: Обеспечить защиту активов организации, доступных поставщикам.

ИБ при взаимоотношении с поставщиками определяют следующие составляющие:

— политика ИБ в отношениях с поставщиками;

— включение ИБ в договор с поставщиками;

— ИКТ цепочки поставок.

Политика ИБ в отношениях с поставщиками

Меры и средства

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

Рекомендации по реализации

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

— определение и документирование типов поставщиков, например, ИТ сервисы, программы логистики, финансовые сервисы, компоненты ИТ инфраструктуры, которым организация предоставит доступ к своей информации;

— стандартный процесс и жизненный цикл управления отношениями с поставщиком;

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

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

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

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

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

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

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

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

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

— условия, при которых требования и меры ИБ должны быть прописаны в соглашении, подписываемом обеими сторонами;

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

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

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

Включение ИБ в договор с поставщиками

Меры и средства

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

Рекомендации по реализации

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

Следующие условия должны быть рассмотрены на предмет включения в договор для удовлетворения определенных требований ИБ:

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

— классификация информации в соответствии со схемой классификации организации; при необходимости, сопоставление схем классификации организации и поставщика;

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

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

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

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

— политики ИБ, соответствующие специфике договора;

— требования и процедуры управления инцидентами (особенно уведомление и сотрудничество при реагировании на инцидент);

— осведомленность и обучение требованиям специальных процедур и требованиям ИБ, например, реагирования на инцидент или процедур авторизации;

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

— договорные партнеры, включая контактное лицо для решения вопросов ИБ;

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

— право аудита мер защиты и процессов поставщика, вытекающих из договора;

— процессы устранения дефекта и решения конфликта;

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

— обязательства поставщика выполнять требования ИБ организации.

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

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

ИКТ цепочки поставок

Меры и средства

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

Рекомендации по реализации

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

— определить требования ИБ для покупки ИКТ продуктов или сервисов в дополнение к общим требованиям ИБ в отношениях с поставщиками;

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

— для ИКТ продуктов — поставщики должны распространять требования ИБ по всей цепочке поставок, даже если эти продукты содержат компоненты, купленные у других поставщиков;

— внедрение процесса мониторинга и допустимых методов проверки поставляемых ИКТ продуктов и сервисов на соответствие установленным требованиям безопасности;

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

— уверенность в том, что критичные компоненты и их происхождение может быть отслежено по цепочке поставок;

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

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

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

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

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

Рассматриваемая ИКТ цепочка поставок включает в себя «облачный» компьютерный сервис.

11.2. Управление оказанием услуг

Цель: Поддерживать согласованный уровень ИБ и оказания услуг согласно договоров с поставщиками.

Управление оказанием услуг обеспечивают следующие меры:

— мониторинг и пересмотр услуг;

— управление изменениями услуг.

Мониторинг и пересмотр услуг

Меры и средства

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

Рекомендации по реализации

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

— мониторинга уровней оказания услуг для проверки соблюдения договоров;

— анализа отчетов поставщика об оказании услуг и проведения регулярных рабочих встреч согласно договоров;

— проведения аудитов поставщиков в соответствии с отчетами независимых аудиторов, по возможности, и принятия мер по указанным в них вопросам;

— обеспечения информации об инцидентах ИБ и анализа этой информации в соответствии с договорами и соответствующими руководствами и процедурами;

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

— решения всех выявленных проблем и управления ими;

— пересмотра аспектов ИБ в отношениях со своими поставщиками;

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

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

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

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

Управление изменениями услуг

Меры и средства

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

Рекомендации по реализации

Следующие аспекты должны быть рассмотрены:

— изменения в договорах с поставщиками;

— изменения, сделанные организацией для:

• усовершенствования действующих услуг;

• разработки новых приложений и систем;

• модификации или обновления процессов и процедур организации;

• новых или изменения мер по решению инцидентов ИБ и улучшению безопасности;

— изменения услуг поставщика для:

• изменения или усовершенствования сетей;

• использования новых технологий;

• выбора новых продуктов или новых версий/релизов;

• новых инструментов и сред разработки;

• изменения места расположения средств оказания услуг;

• замены поставщиков;

• субподряда другого поставщика.

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

12.1. Управление инцидентами ИБ и улучшение

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

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

— ответственность и процедуры;

— оповещение о событиях;

— оповещение о недостатках;

— оценка событий и решения.

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

— реагирование на инциденты;

— извлечение уроков из инцидентов;

— сбор правовых доказательств.

Ответственность и процедуры

Меры и средства

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

Рекомендации по реализации

Необходимо учитывать следующие рекомендации:

— ответственные лица должны гарантировать, что следующие процедуры разработаны и адекватно функционируют внутри организации:

• процедуры планирования и подготовки реагирования на инцидент;

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

• процедуры регистрации действий по управлению инцидентами;

• процедуры сбора правовых доказательств;

• процедуры оценки событий, уязвимостей и решения событий;

• процедуры реагирования, включая эскалацию, восстановление и оповещение всех заинтересованных сторон (внутренних и внешних);

— процедуры должны обеспечивать уверенность того, что:

• компетентный персонал решит проблему инцидента внутри организации;

• контактные лица для выявления инцидентов и оповещения о них определены;

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

— процедуры отчетов должны содержать:

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

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

• ссылку на формальный дисциплинарный процесс в отношении сотрудников, допустивших бреши ИБ;

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

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

Оповещение о событиях ИБ

Меры и средства

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

Рекомендации по реализации

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

Ситуации, относящиеся к событиям ИБ, включают:

— неэффективную меру защиты;

— брешь в целостности, конфиденциальности и доступности информации;

— человеческие ошибки;

— несоответствие политике и правилам;

— бреши в мерах физической безопасности;

— неконтролируемые системные изменения;

— сбои системного или прикладного ПО;

— нарушения доступа.

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

Оповещение о недостатках ИБ

Меры и средства

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

Рекомендации по реализации

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

Оценка событий и решения

Меры и средства

События ИБ должны быть оценены и по ним должно быть принято решение, если они классифицированы как инциденты ИБ.

Рекомендации по реализации

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

Если организация имеет свою группу реагирования на инциденты ИБ (далее — ГРИИБ), оценка и решения могут быть переданы в ГРИИБ для повторной оценки и утверждения результатов.

Результаты оценки и решения должны быть детально зафиксированы для дальнейшего изучения и анализа.

Реагирование на инциденты ИБ

Меры и средства

На инциденты ИБ надо реагировать в соответствии с документированными процедурами.

Рекомендации по реализации

На инциденты ИБ должны реагировать ответственный за это сотрудник и другие специалисты организации или сторонние специализированные группы.

Реагирование должно содержать следующее:

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

— проведение, при необходимости, правового анализа инцидента;

— эскалацию, при необходимости;

— уверенность, что все предпринятые действия правильно зафиксированы для дальнейшего анализа;

— передача информации об инциденте и его деталях всем заинтересованным сторонам (внутренним и внешним);

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

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

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

Извлечение уроков из инцидентов ИБ

Меры и средства

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

Рекомендации по реализации

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

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

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

Сбор доказательств

Меры и средства

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

Рекомендации по реализации

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

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

Процедуры должны учитывать:

— цепочки поставок;

— безопасность доказательства;

— безопасность персонала;

— роли и ответственности задействованного персонала;

— компетентность персонала;

— документацию;

— инструктаж.

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

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

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

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

13. Аспекты ИБ при управлении непрерывности бизнеса

Аспекты ИБ при управлении непрерывности бизнеса определяют следующие составляющие:

— непрерывность ИБ;

— избыточность средств.

13.1. Непрерывность ИБ

Цель: Непрерывность ИБ должна быть неотъемлемой частью систем управления непрерывностью бизнеса организации.

Непрерывность ИБ обеспечивают следующие меры:

— планирование;

— внедрение;

— проверку, пересмотр и оценку.

Планирование непрерывности

Меры и средства

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

Рекомендации по реализации

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

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

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

Внедрение непрерывности

Меры и средства

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

Рекомендации по реализации

Организация должна быть уверена, что:

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

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

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

В соответствии с требованиями непрерывности ИБ организация должна установить, документировать, внедрить и поддерживать:

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

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

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

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

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

Проверка, пересмотр и оценка непрерывности

Меры и средства

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

Рекомендации по реализации

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

Организация должна проверять непрерывность управления ИБ следующим:

— тренировка и тестирование функциональности процессов, процедур и мер защиты непрерывности ИБ для гарантии их соответствия целям непрерывности ИБ;

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

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

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

13.2. Избыточности средств

Цель: Обеспечить доступность средств обработки информации.

Доступность средств обработки информации

Меры и средства

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

Рекомендации по реализации

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

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

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

14. Соответствие требованиям

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

— выполнение требований;

— пересмотр (аудит) ИБ.

14.1. Выполнение требований

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

Выполнение требований определяют следующие составляющие:

— определение требований;

— интеллектуальная собственность;

— защита записей;

— конфиденциальность;

— криптографические средства.

Определение требований

Меры и средства

Все соответствующие требования должны быть четко определены, задокументированы и поддерживаться в актуальном состоянии для каждой ИС и организации.

Рекомендации по реализации

Специальные меры защиты и индивидуальные обязанности по выполнению законодательных, нормативных и договорных требований следует также определить и задокументировать.

Менеджеры должны идентифицировать все законодательство, применяемое в организации, для определения соответствия бизнеса его требованиям. Если организация осуществляет бизнес в других странах, менеджеры должны рассмотреть его соответствие требованиям этих стран.

Интеллектуальная собственность

Меры и средства

Должны быть внедрены соответствующие процедуры для обеспечения соответствия требованиям, связанным с правами интеллектуальной собственности и использованием лицензионного ПО.

Рекомендация по реализации

Следующие рекомендации следует учитывать в отношении защиты любого материала, который может содержать интеллектуальную собственность:

— публикация политики соблюдения прав интеллектуальной собственности, определяющей законное использование ПО и информационных продуктов;

— покупка ПО у заслуживающих доверия поставщиков для гарантии того, что авторское право не нарушается;

— поддержка осведомленности сотрудников о политиках по защите прав интеллектуальной собственности и уведомление о намерении применить дисциплинарные санкции в отношении нарушителей;

— поддержка соответствующих реестров активов и выявление всех активов, к которым применимы требования по защите прав интеллектуальной собственности;

— хранение подтверждений и доказательств прав собственности на лицензии, мастер-диски, руководства по эксплуатации и т. п.;

— внедрение контроля, что максимальное число разрешенных пользователей не превышено;

— проведение проверок установки только разрешенного ПО и лицензированных продуктов;

— внедрение политики поддержки соответствующих лицензионных условий;

— внедрение политики утилизации или передачи ПО сторонним организациям;

— соблюдение сроков и условий применения ПО и информации, полученной из общедоступных сетей;

— запрет дублирования, конвертации в другой формат или извлечения из коммерческих записей (фильм, аудио), если другое не разрешено законом об авторском праве;

— запрет копирования полностью или частично книг, статей, отчетов и других документов, если другое не разрешено законом об авторском праве.

Права интеллектуальной собственности включают авторство ПО и документа, права оформления, торговые знаки, патенты и лицензии.

Фирменное ПО обычно поставляется в соответствии с лицензионным соглашением, которое определяет лицензионные сроки и условия, например, ограничение использования ПО на других машинах или ограничение копирования кроме резервного. Важность и осознание прав интеллектуальной собственности должно быть доведено до сотрудников, разрабатывающих в организации ПО.

Законодательные, нормативно-правовые и договорные требования могут ограничивать копирование приватных материалов. В частности, они могут требовать использования только тех материалов, которые разработаны организацией или внедрены в организации разработчиком. Нарушение прав собственности ведет к законному действию, содержащему процедуры штрафования и криминального преследования.

Защита записей

Меры и средства

Записи должны быть защищены от потери, уничтожения, фальсификации, несанкционированного доступа в соответствии с законодательными, нормативными, договорными и бизнес-требованиями.

Рекомендации по реализации

После принятия решения о защите определенных организационных записей должна быть продумана соответствующая классификация на базе шкалы классификации организации. Записи должны быть категоризированы по типам, например, бухгалтерия, базы данных, транзакции, аудит и операционные процедуры, с указанием сроков хранения и типа их носителей, например, бумажный, микрофиша, магнитный, оптический. Любые криптографические ключи, имеющие отношение к зашифрованным архивам и цифровым подписям, должны храниться для дешифровки записей, пока они сохраняются.

Рассмотрению следует подвергнуть возможность износа носителей, на которых хранятся записи. Процедуры обращения и хранения носителей должны быть внедрены в соответствии с рекомендациями изготовителя. При выборе электронных носителей процедуры контроля доступа к данным (читаемости носителя) в течение срока хранения носителей должны быть обеспечены для защиты от потери из-за какого-либо технологического изменения.

Системы хранения данных должны выбираться такие, чтобы требуемые данные могли быть восстановлены в течение допустимого срока и приемлемом формате в зависимости от выполненных требований.

Система хранения и обработки должны обеспечить идентификацию записей и срока их хранения в соответствии с национальным или региональным законодательством или правилами. Эта система разрешит уничтожение записей по окончани этого срока, если они не нужны организации.

Для соответствия целям защиты записей организация должна предпринять следующее:

— разработать рекомендации в отношении сроков, порядка хранения и обработки, а также уничтожения записей;

— составить график хранения с указанием записей и периода, в течение которого их необходимо хранить;

— поддерживать ведение учета источников получения записей.

Некоторые записи следует хранить для соблюдения законодательных, нормативных или договорных требований, а также для поддержки важной бизнес-деятельности. К ним относятся записи, которые могут потребоваться как доказательство, что организация работает по законодательным и нормативным правилам для гарантии защиты от возможного гражданского или уголовного дела или подтверждения финансового статуса организации для аукционеров, сторонних организаций и аудиторов. Национальный закон или норматив может устанавливать период времени и содержание данных для хранения информации.

Конфиденциальность

Меры и средства

Конфиденциальность и защита персональных данных должна быть обеспечена, как того требует соответствующее законодательство и нормативы.

Рекомендации по реализации

Политика данных организации по конфиденциальности и защите персональных данных должна быть разработана и внедрена. Эта политика должна быть доведена до сведения всех лиц, участвующих в обработке персональных данных.

Соблюдение этой политики и всех применимых требований законодательных и нормативных актов по защите персональных данных требует наличие соответствующей структуры управления и контроля.

Как правило, это достигается путем назначения должностного лица, отвечающего за защиту персональных данных, которое должно предоставить инструкции менеджерам, пользователям и поставщикам услуг в отношении их персональной ответственности и специальных процедур, обязательных для выполнения.

Обеспечение ответственности за обработку персональных данных и осведомленности о принципах их защиты должно осуществляться в соответствии с законодательством и нормативами. Надлежащие технические и организационные меры по защите персональных данных должны быть внедрены.

Криптографические средства

Меры и средства

Криптографические средства должны использоваться согласно всех соответствующих договоров, законов и нормативов.

Рекомендации по реализации

Следующие вопросы необходимо рассматривать по соблюдению соответствующих договоров, законов и нормативов:

— ограничения на импорт или экспорт компьютерных аппаратных и программных средств, предоставляющих криптографические функции;

— ограничения на импорт или экспорт компьютерных аппаратных и программных средств, созданных с применением криптографических функций как дополнительных;

— ограничения на применение шифрования данных;

— принудительные и произвольные методы доступа органов власти к информации, зашифрованной с помощью аппаратных и программных средств для обеспечения конфиденциальности содержания.

14.2. Проверки ИБ

Цель: Убедиться, что ИБ внедрена и управляется в соответствии с организационными политиками и процедурами.

Проверки ИБ обеспечивают следующие меры:

— независимая проверка ИБ;

— соответствие политикам и стандартам;

— проверка технического соответствия.

Независимая проверка ИБ

Меры и средства

Подход организации к управлению ИБ и ее внедрению (т. е. цели и элементы управления, политики, процессы и процедуры ИБ) должен независимо проверяться через запланированные интервалы или когда происходят значительные изменения.

Рекомендации по реализации

Независимая проверка должна инициироваться руководством. Она необходима для обеспечения уверенности в сохраняющейся работоспособности, адекватности и эффективности подхода организации к управлению ИБ. Проверка должна включать в себя оценку возможностей улучшения и необходимость изменений подхода к безопасности, в том числе политику и цели управления.

Такая проверка должна осуществляться специалистами, не зависимыми от проверяемой сферы, например, службой внутреннего аудита, независимым менеджером или сторонней организацией, специализирующейся на таких проверках. Специалисты, привлекаемые к таким проверкам, должны обладать соответствующими навыками и опытом.

Результаты независимой проверки должны записываться и сообщаться руководству, инициировавшему проверку. Эти записи следует хранить.

Если в результате независимой проверки устанавлено, что подходы организации к управлению ИБ и ее внедрению неадекватны, например, задокументированные цели и требования не соблюдаются или не соответствуют направлению ИБ, изложенному политиках ИБ, руководству следует рассмотреть корректирующие действия.

Соответствие политикам и стандартам

Меры и средства

Менеджеры должны регулярно проверять в пределах своей ответственности соответствие информационных процессов и процедур политикам, стандартам и другим требованиям безопасности.

Рекомендации по реализации

Менеджеры должны определить, как проверять то, что требования ИБ, предусмотренные политиками, стандартами и другими применимыми правилами, соблюдены. Для эффективной регулярной проверки следует использовать инструменты автоматического измерения и оповещения.

Если в результате проверки было выявлено какое-либо несоответствие, менеджерам следует:

— определить причины несоответствия;

— оценить необходимость действий для достижения соответствия;

— реализовать соответствующее корректирующее действие;

— проверить эффективность предпринятого корректирующего действия и выявить любые недостатки и слабые места.

Результаты проверок и корректирующих действий, предпринятых менеджерами, следует записывать и эти записи хранить. Менеджеры должны доложить о результатах независимому аудитору при проведении такого аудита в сфере их ответственности.

Проверка технического соответствия

Меры и средства

ИС должны регулярно проверяться на соответствие политикам и стандартам ИБ организации.

Рекомендации по реализации

Проверка соответствия ИС техническим требованиям должна осуществляться, как правило, с помощью автоматических инструментальных средств, которые генерируют технические отчеты для последующего анализа техническим специалистом. В альтернативном случае, ручные отчеты (при необходимости, поддерживаемые соответствущими программными инструментами) оформляются опытным системным инженером.

Если проводится тестирование на проникновение или оценка уязвимостей, следует соблюдать осторожность, поскольку такие действия могут привести к компрометации безопасности системы. Такие тесты должны планироваться, документироваться и повторяться.

Любая проверка технического соответствия должна проводиться компетентным, уполномоченным персоналом или под руководством такого персонала.

Проверки технического соответствия должны включать испытания ОС для гарантии того, что аппаратные и программные средства установлены правильно. Этот тип проверки требует специальной технической экспертизы.

Проверки соответствия также содержат, например, тестирование на проникновение и оценку уязвимостей, которые могут провести независимые эксперты, специально привлеченные для этой цели по контракту. Это может быть использовано для выявления уязвимостей в ИС и проверки эффективности мер и средств защиты в предотвращении несанкционированного доступа к этим уязвимостям.

Тестирование на проникновение и оценка уязвимостей обеспечивает фиксацию специфического состояния ИС в определенный момент. Эта фиксация ограничена теми частями ИС, которые тестируются в момент попытки проникновения. Тестирование на проникновение и оценка уязвимостей не заменяет оценки риска.

4. Разработка СУИБ (стандарт ISO/IЕС 27003:2010)

В 2010 году Международная организация по стандартизации опубликовала новый стандарт ISO/IЕС 27003 «ИТ. Методы защиты. СУИБ. Руководство по реализации СУИБ».

Он посвящён вопросам успешной разработки и внедрения СУИБ в соответствии с требованиями ISO/IEC 27001. Стандарт ISO/IЕС 27003 описывает процесс формирования требований и проектирования СУИБ от начала проекта и до подготовки планов внедрения.

Указан процесс получения согласия руководства на внедрение СУИБ, дается детализация проекта внедрения СУИБ, даются рекомендации по планированию проекта внедрения СУИБ, результатом которого является окончательный план внедрения СУИБ.

Планирование внедрения СУИБ состоит из 5 этапов:

1) получение одобрения руководства для проектирования СУИБ (раздел 5);

2) определение области действия и политики СУИБ (раздел 6);

3) проведение анализа организации (раздел 7);

4) проведение анализа и планирование обработки рисков (раздел 8);

5) разработка СУИБ (раздел 9).

Каждый раздел содержит следующую информацию:

— цели (что необходимо достичь);

— действия для их достижения.

Описания действий структурированы в виде исходных данных, рекомендаций и выходных данных.

Исходные данные — описывают отправную точку, например, наличие документированных решений или выходных данных других действий, описываемых в стандарте;

Рекомендации — содержат подробную информацию, позволяющую выполнить данное действие;

Выходные данные — описывают результат (ы) или документ (ы), получаемые после выполнения действия.

1. Одобрение руководством проектирования СУИБ

Цель: Получить одобрение руководства путем определения случая применения СУИБ для предприятия и подготовки плана проекта.

Исходные данные: Описание случая применения СУИБ для данного предприятия, включающее приоритеты и цели внедрения СУИБ, а также структуру организации для СУИБ.

Рекомендации: Составить первоначальный план проекта СУИБ.

Выходные данные: Описание случая применения СУИБ для данного предприятия и первоначальный план проекта СУИБ с описанием ключевых этапов.

Одобрение руководством проектирования СУИБ определяют следующие процессы:

1) определение приоритетов организации для разработки СУИБ;

2) определение предварительной области действия СУИБ;

3) техническое обоснование и план проекта СУИБ для получения санкции руководства.

1.1. Определение приоритетов организации для разработки СУИБ

Исходные данные:

— стратегические цели организации;

— обзор существующих систем управления;

— перечень действующих нормативно-правовых и договорных требований к ИБ.

Рекомендации: Выполнить сбор существенной информации, показывающей значение СУИБ для организации. Организация должна определить, зачем нужна СУИБ, определить цели внедрения СУИБ и запустить проектирование СУИБ.

Выходные данные:

— документ, излагающий цели, приоритеты в области ИБ и требования организации к системе СУИБ;

— перечень нормативно-правовых и контрактных требований к ИБ организации;

— описание характеристик организации, местонахождения, активов и технологий.

1.2. Определение предварительной области действия СУИБ

Определение предварительной области обеспечивают следующие процессы:

— разработка предварительной области;

— определение для нее ролей и сфер ответственности.

1.2.1. Разработка предварительной области

Исходные длиные: Выходные данные 1.1.

Рекомендации: Определить структуру организации для реализации СУИБ.

Выходные данные:

— изложение обязательных требований к УИБ, определяемых руководством организации, и обязательств, накладываемых на организацию извне;

— описание того, как части области действия СУИБ взаимодействуют с другими системами управления;

— перечень целей предприятия в области УИБ;

— перечень важнейших бизнес-процессов, активов, организационных структур и регионов, где будет использоваться СУИБ;

— соотношение существующих систем управления, регулирования, соответствия и целей организации;

— характеристики организация, местонахождение, активы и технологии.

1.2.2. Определение для предварительной области ролей и сфер ответственности

Исходные данные

— выходные данные 1.2.1;

— список заинтересованных сторон, которые получат выгоду в результате реализации проекта СУИБ.

Рекомендации: Определить роль организации в реализации проекта и ответственных лиц за УИБ, а для сотрудников должны быть определены роли и сферы ответственности на основе квалификации, требуемой для выполняемой работы.

Выходные данные: представляют собой документ или таблицу, описывающую роли и сферы ответственности с указанием имен и организацию, необходимую для успешного внедрения СУИБ.

1.3. Техническое обоснование и план проекта СУИБ для получения санкции руководства

Одобрение руководства и выделение ресурсов для реализации проекта внедрения СУИБ должны быть получены путем определения случая применения СУИБ для предприятия и подготовки плана проекта СУИБ.

Исходные данные:

— выходные данные 1.1;

— выходные данные 1.2.

Рекомендации:

Информация по случаю применения СУИБ для предприятия и первоначальный план проекта СУИБ должны охватывать следующие вопросы:

— цели и конкретные задачи;

— выгоды для организации;

— предварительная область действия СУИБ, включая затрагиваемые бизнес-процессы;

— важнейшие процессы и ф акторы для достижения целей СУИБ;

— описание проекта высокого уровня;

— первоначальный план внедрения СУИБ;

— определенные роли и сферы ответственности;

— требуемые ресурсы (технологические и людские);

— соображения, касающиеся внедрения СУИБ, включая существующую систему ИБ;

— временная шкала с ключевыми этапами;

— предполагаемые затраты;

— важнейшие факторы успеха;

— количественное определение выгод для организации.

Руководство должно утвердить описание случая применения СУИБ для предприятия и первоначальный план проекта, чтобы составить поручения для всей организации и начать реализацию проекта СУИБ.

Выходные данные:

— документированное одобрение руководством выполнения проекта СУИБ с распределенными ресурсами;

— документированное описание случая применения СУИБ для данного предприятия;

— начальное предложение по проекту СУИБ с основными этапами, такими как выполнение оценки риска, реализация проекта, внутренний аудит и проверки, осуществляемые руководством.

2. Определение области действия, границ и политики СУИБ

Цель: Определить области действия и границ СУИБ и разработать политику СУИБ.

Определение области действия и границ СУИБ обеспечивают предварительные процессы:

— определение организационной и физической областей действия и границ СУИБ;

— определение области действия и границ информационных и коммуникационных технологий (далее — ИКТ);

Определение областей действия и политики СУИБ также обеспечивают заключительные процессы:

— объединение всех областей действия и границ СУИБ;

— разработка политики СУИБ и получение одобрения руководства.

2.1. Определение организационной области действия и границ

Исходные данные:

— выходные данные 1.2 — документированная предварительная область действия СУИБ, охватывающая:

• соотношения существующих систем управления, регулирования, соответствия и целей организации;

• характеристики организации, ее местонахождения, активов и технологий.

— выходные данные 1.1 — документированное утверждение руководством внедрения СУИБ и запуск проекта с необходимыми распределенными ресурсами.

Рекомендации: Одним из методов определения организационных границ является определение сфер ответственности, не перекрывающих друг друга, чтобы облегчить назначение подотчетности в организации.

На основе такого подхода анализируемые организационные границы должны определять всех сотрудников, участвующих в сфере УИБ, и эти границы должны быть включены в область действия СУИБ. Если некоторые процессы в организации выполняются сторонними организациями, эти зависимости должны быть четко задокументированы.

Выходные данные:

— описание организационных границ СУИБ, включая обоснования исключения каких-либо частей организации из области действия СУИБ;

— функции и структура частей организации, находящихся в области действия СУИБ;

— определение информации, подлежащей обмену в рамках области действия СУИБ, и информации, обмен которой осуществляется через границы СУИБ;

— процессы в организации и сферы ответственности за информационные активы в области действия СУИБ и за ее пределами;

— процесс в иерархии принятия решений, а также ее структура в рамках системы СУИБ.

2.2. Определение области действия и границ ИКТ

Исходные данные:

— выходные данные 1.2 — описание предварительной области действия СУИБ;

— выходные данные 2.1 — определение организационной области действия и границ.

Рекомендации: Определение области действия и границ ИКТ может быть получено на основе анализа имеющихся информационных систем. Элементы ИКТ включают все части организации, которые хранят, обрабатывают или передают важную информацию, активы или являются важными для других частей организации, входящих в область действия СУИБ.

Границы ИКТ должны включать описание следующих элементов:

— инфраструктура связи, в которой ответственность за ее управление входит в компетенцию организации, располагающей различными технологиями (например, беспроводные и проводные сети или сети передачи данных и телефонной связи);

— ПО в рамках организационных границ, используемое и контролируемое организацией;

— аппаратное обеспечение ИКТ, требуемое для сетей, приложений или производственных систем;

— роли и сферы ответственности, связанные с аппаратным обеспечением ИКТ, сетью и ПО.

Выходные данные:

— информация, обмен которой осуществляется как в рамках области действия СУИБ, так и через ее границы;

— границы ИКТ для СУИБ с обоснованием исключения из области действия СУИБ каких-либо элементов ИКТ, находящихся под управлением организации;

— информация об информационных и телекоммуникационных системах, описывающая, какие из них находятся в пределах области действия СУИБ вместе с ролями и сферами ответственности для этих систем.

2.3. Определение физической области действия и границ

Исходные данные:

— выходные данные 1.2 — описание предварительной области действия СУИБ;

— выходные данные 2.1 — определение организационной области действия и границ;

— выходные данные 2.2 — определение области действия и границ ИКТ.

Рекомендации: Определить помещения, обьекты и оборудование в организации, которые должны стать частью СУИБ. При этом сложнее работать с информационными системами, пересекающими физические границы, и для этого требуется:

— периферийное оборудование;

— средства связи с информационными системами клиентов и обслуживание, предоставляемое сторонними организациями;

— применение соответствующих средств связи и уровней обслуживания.

Физические границы должны включать описание следующих элементов:

— функций или процессов с учетом их физического местонахождения и степени контроля их организацией;

— специального оборудования, используемого для размещения аппаратного обеспечения ИКТ или данных, применяемых в СУИБ.

Выходные данные:

— описание физических границ СМИБ с обоснованием для исключения каких-либо физических границ, находящихся под управлением организации, из области действия СМИБ;

— описание организации и ее географических характеристик, относящихся к области действия СМИБ.

2.4. Объединение всех областей действия и границ СУИБ

Исходные данные:

— выходные данные 1.2 — описание предварительной области действия СУИБ;

— выходные данные 2.1 — определение организационной области действия и границ;

— выходные данные 2.2 — определение области действия и границ ИКТ;

— выходные данные 2.3 — определение физической области действия и границ.

Рекомендации: Свести все исходные данные в один документ.

Выходные данные: Документ, описывающий область действия и границы СУИБ, должен содержать следующую информацию:

— ключевые характеристики организации (функция, структура, активы и область действия и границы ответственности для каждого актива);

— процессы в организации, находящиеся в области действия СУИБ;

— предварительный перечень активов, находящихся в области действия СУИБ;

— конфигурация оборудования и сетей, находящихся в области действия СУИБ;

— схемы объектов, определяющие физические границы СУИБ;

— описание ролей и сфер ответственности в рамках СУИБ и их связи со структурой организации;

— описание и обоснование исключений каких-либо элементов из области действия СУИБ.

2.5. Разработка политики СУИБ и получение одобрения руководства

Исходные данные:

— выходные данные 2.4 — документированная область действия и границы СУИБ;

— выходные данные 1.2 — документированные цели внедрения СУИБ;

— выходные данные 1.3 — описание случая применения и проект плана СУИБ.

Рекомендации: Обычно политика безопасности организации является политикой высшего уровня. Она подкрепляется более конкретными политиками, включая политику ИБ и политику СУИБ. В свою очередь, политика ИБ может подкрепляться более детальными политиками по конкретным предметам, относящимся к аспектам ИБ.

Многие из этих политик описываются в стандарте ISO/IEC 27002, например, политика ИБ подкрепляется политиками, касающимися контроля доступа, политики чистого рабочего стола и экрана, использования сетевых служб и криптографического контроля. В некоторых случаях возможно включение дополнительных уровней политики.

Согласно стандарту ISO/IEC 27001 требуется, чтобы организации имели политику СУИБ и политику ИБ. Согласно стандарту ISO/IEC 27035 требуется, чтобы организации имели политику управления инцидентами ИБ.

Эти политики могут разрабатываться как равноправные политики — политика СУИБ может подчиняться политике ИБ или наоборот. В то же время политика управления инцидентами ИБ является составной частью политики СУИБ.

Содержание политики основано на контексте, в котором работает организация.

При разработке любой политики нужно учитывать следующие составляющие:

— цели и задачи;

— стратегии для достижения целей;

— структуру и процессы организации;

— требования политик более высокого уровня.

Любая политика содержит следующие разделы:

— введение;

— область действия;

— цели, принципы;

— сферы ответственности;

— ключевые результаты;

— связанные политики.

Краткое содержание политики:

1. Введение — краткое объяснение предмета политики.

2. Область действия — описывает части или действия организации, находящиеся под влиянием политики.

3. Цели — описание назначения политики.

4. Принципы — описание правил, касающихся действий и решений для достижения целей. В некоторых случаях может быть полезным определить ключевые процессы, связанные с предметом политики, и затем — правила выполнения процессов.

5. Сферы ответственности — кто отвечает за действия по выполнению требований политики. В некоторых случаях этот пункт может содержать описание организационных соглашений, а также сферы ответственности лиц с определенными ролями.

6. Ключевые результаты — описание результатов, получаемых предприятием, если цели достигнуты.

7. Связанные политики — описание других политик, относящихся к достижению целей, обычно с представлением дополнительных подробностей, касающихся отдельных предметов.

Выходные данные: Задокументировання политика СУИБ, утвержденная руководством.

3. Проведение анализа требований к ИБ

Цель: Определить требования, которым должна соответствовать СУИБ, определить активы и получить данные по текущему состоянию ИБ в рамках области действия СУИБ.

Информация, собранная в процессе анализа ИБ, должна:

— стать основной для управления;

— определять и документировать условия для внедрения СУИБ;

— обеспечивать четкое и обоснованное понимание возможностей организации;

— учитывать определенные обстоятельства и положение в организации;

— определять требуемый уровень защиты информации;

— определять сбор и обработку информации, требуемые для всего предприятия или его части, находящейся в рамках предложенной области действия СУИБ.

Проведение анализа требований к ИБ определяют следующие процессы:

1) определение требований к ИБ для СУИБ;

2) определение активов в рамках СУИБ;

3) проведение оценки ИБ.

3.1. Определение требований к ИБ для СУИБ

Исходные данные:

— выходные данные 1.1 — приоритеты организации для разработки СУИБ;

— выходные данные 2.5 — политика СУИБ.

Рекомендации: Для каждого процесса в организации и задачи для специалиста требуется принять решение в отношении того, насколько важной является информация, т. е. какой требуется уровень защиты. Требуется базовое краткое описание проанализированной информации по процессам в организации и системам ИКТ.

Для получения подробных требований к ИБ для СУИБ следует рассмотреть следующие вопросы:

— предварительное определение важных информационных активов и текущего состояния защиты информации;

— определение представлений организации и их влияния на будущие требования к ИБ;

— анализ видов обработки информации, системного ПО, коммуникационных сетей, определения действий и ресурсов для информационных технологий и т. д.;

— определение всех обязательных требований (законодательства, договоров, стандартов и соглашений с клиентами, условий страхования и т. д.);

— определение уровня информированности в области ИБ и определение требований к обучению в отношении каждого подразделения.

Выходные данные:

— определение основных процессов, функций, объектов, информационных систем и коммуникационных сетей;

— информационные активы организации;

— классификация важнейших процессов (активов);

— требования к ИБ, сформулированные на основе обязательных требований;

— перечень известных уязвимостей, которые должны быть устранены в результате выполнения требований к ИБ;

— требования к обучению и образованию в области ИБ в организации.

3.2. Определение активов в рамках СУИБ

Исходные данные:

— выходные данные 2.4 — область действия и границы СУИБ;

— выходные данные 2.5 — политика СУИБ;

— выходные данные 3.1 — требования к ИБ для процесса СУИБ.

Рекомендации: Для определения активов в рамках области действия СУИБ необходимо указать следующую информацию:

— уникальное наименование процесса;

— описание процесса и связанные с ним действия (создание, хранение, передача, удаление);

— важность процесса для организации (критический, важный, вспомогательный);

— владелец процесса (подразделение организации);

— процессы, обеспечивающие исходные и выходные данные этого процесса;

— приложения ИТ, поддерживающие процесс;

— классификация информации (конфиденциальность, целостность, доступность и другие важные для организации свойства).

Выходные данные:

— определенные информационные активы основных процессов в организации в рамках области действия СУИБ;

— классификация важнейших процессов и информационных активов с точки зрения ИБ.

3.3. Проведение оценки ИБ

Необходимо провести оценку ИБ путем сравнения текущего состояния ИБ в организации с целями организации.

Исходные данные:

— выходные данные 2.4 — область действия и границы СУИБ;

— выходные данные 2.5 — политика СУИБ;

— выходные данные 3.1 — требований к ИБ для процесса СУИБ;

— выходные данные 3.2 — активы в рамках области действия СУИБ.

Рекомендации: При оценке ИБ анализируется текущая ситуация в организации путем использования следующей информации и определяется текущее состояние ИБ и недостатки в документации:

— изучение предпосылок на основе важнейших процессов;

— классификация информационных активов;

— требования организации к ИБ.

Для успешной оценки ИБ важными являются следующие действия:

— перечисление соответствующих стандартов;

— определение требований к управлению, установленных на основе политики ИБ, обязательных требований, результатов прошедших проверок или оценок рисков;

— использование этих документов для приблизительной оценки существующих требований к уровню ИБ.

Подход к проведению оценки ИБ следующий:

— выбрать важные бизнес-процессы и этапы процессов, касающиеся требований к ИБ;

— составить подробную блок-схему, охватывающую основные процессы, включая инфраструктуру;

— обсудить и проанализировать с ключевыми сотрудниками существующую ситуацию в организации в отношении требований к ИБ;

— определить недостатки в управлении путем сравнения существующих средств управления с определенными требованиями к управлению;

— определить и задокументировать текущее состояние организации.

Выходные данные: Документ, описывающий состояние ИБ в организации и обнаруженные уязвимости.

4. Проведение оценки и планирование обработки рисков

Цель: Определить методологию оценки риска, определить, проанализировать и оценить риски ИБ, чтобы выбрать варианты их обработки и средства ИБ.

Проведение оценки и планирование обработки рисков определяют следующие процессы:

1) проведение оценки рисков;

2) выбор средств ИБ;

3) получение санкции руководства на внедрение и использование СУИБ.

4.1. Проведение оценки рисков

Исходные данные:

— выходные данные раздела 2 — область действия и политика СУИБ;

— выходные данные раздела 3 — состояние ИБ и информационные активы;

— ISO/IEC 27005 — управление рисками ИБ.

Рекомендации: Оценка рисков состоит из следующих мероприятий:

— идентификация рисков;

— измерение рисков;

— оценивание рисков.

При оценке рисков необходимо определить:

— угрозы и их источники;

— меры защиты;

— уязвимости;

— последствия нарушений ИБ.

При оценке риска нужно также осуществить:

— оценку уровня риска;

— оценку влияния инцидента на организацию;

— сравнение уровня риска с критериями оценки и приемлемости.

Выходные данные:

— описание методологий оценки рисков;

— результаты оценки рисков.

4.2. Выбор средств ИБ

Исходные данные:

— выходные данные 4.1 — результаты оценки риска;

— ISO/IEC 27002 — правила СУИБ;

— ISO/IEC 27005 — управление рисками ИБ;

— ISO/IEC 27035 — управление инцидентами ИБ.

Рекомендации: Важно продемонстрировать, как выбранные меры и средства защиты могут снизить риск и вероятность возникновения инцидента. В случае снижения риска установление соотношения между каждым риском (вероятным инцидентом) и выбранными средствами является полезным для разработки СУИБ.

Разработка плана обработки инцидентов

Цель плана обработки инцидентов ИБ — обеспечить подробную документацию, описывающую процессы и процедуры обработки событий, инцидентов и уязвимостей ИБ и их взаимодействия. План обработки инцидентов ИБ приводится в действие при обнаружении события ИБ или сообщении об уязвимости ИБ.

Каждая организация должна использовать план в качестве руководства для:

— реагирования на события ИБ;

— определения того, становятся ли события ИБ инцидентами;

— управления инцидентами ИБ до их разрешения;

— реагирования на уязвимости ИБ;

— идентификации полученных уроков при обработке инцидентов, а также необходимых улучшений СУИБ;

— реализации улучшений СУИБ.

Выходные данные:

— перечень выбранных мер и средств защиты;

— планы обработки рисков и инцидентов.

4.3. Получение санкции руководства на внедрение и использование СУИБ

Исходные данные:

— выходные данные 1.4 — утвержденный начальный проект СУИБ;

— выходные данные раздела 2 — область действия и политика СУИБ;

— выходные данные 4.1 — результаты оценки риска;

— выходные данные 4.2 — планы обработки рисков и инцидентов.

Рекомендации: Необходимо получить одобрение высшего руководства для принятия решения о принятии остаточных рисков, а также санкцию на фактическое использование СУИБ. Эти решения должны основываться на оценке рисков и вероятности их возникновения в результате внедрения СУИБ, в сравнении с рисками, возникающими в случае, когда СУИБ не применияется.

Выходные данные:

— письменное одобрение руководством внедрения СУИБ;

— утверждение руководством планов обработки рисков и инцидентов;

— положение о применимости, включающее выбранные меры и средства защиты.

5. Разработка СУИБ

Цель: Составить конечный план внедрения СУИБ путем разработки системы безопасности организации на основе выбранных вариантов обработки риска, а также требований, касающихся записей и документов и разработки средств управления, объединяющих меры безопасности ИКТ, физические и организационные процессы и разработку специальных требований для СУИБ.

При разработке СУИБ следует принять во внимание следующие аспекты:

— безопасность организации;

— безопасность ИКТ;

— безопасность физических объектов;

— особые требования к СУИБ.

Безопасность организации охватывает административные аспекты ИБ, включая ответственность за обработку риска.

Безопасность ИКТ охватывает аспекты ИБ, связанные с ответственностью за снижение рисков при выполнении операций с ИКТ.

Безопасность физических объектов охватывает аспекты ИБ, связанные, в частности, с ответственностью, возникающей при проработке физического окружения, например, зданий и их инфраструктуры, за снижение риска.

Особые требования к СУИБ охватывают аспекты соответствии СУИБ требованиям ISO/IEC 27001 в отличие от предыдущих аспектов.

Разработку СУИБ определяют следующие процессы:

1) разработка системы ИБ организации;

2) разработка системы ИБ ИКТ и физических объектов;

3) создание условий надежного функционирования СУИБ;

4) разработка окончательного плана проекта СУИБ.

5.1. Разработка системы ИБ

Разработку системы ИБ обеспечивают следующие разработки:

— конечной структуры организации для ИБ;

— основы для документирования СУИБ;

— политики ИБ;

— стандартов и процедур обеспечения ИБ.

5.1.1. Разработка конечной структуры организации для ИБ

Необходимо сопоставить функции, роли и сферы ответственности в организации, связанные с ИБ, с обработкой рисков.

Исходные данные:

— выходные данные 1.1.2 — таблица ролей и сфер ответственности;

— выходные данные 2.3 — область действия и границы СУИБ.

— выходные данные 2.4 — политика СУИБ;

— выходные данные 3.1 — требования к ИБ для процесса СУИБ;

— выходные данные 3.2 — активы в рамках области действия СУИБ;

— выходные данные 3.3 — результаты оценки ИБ;

— выходные данные 4.1 — результаты оценки рисков;

— выходные данные 4.2 — планы обработки рисков и инцидентов;

— ISO/IEC 27002 — правила СУИБ;

— ISO/IEC 27035 — управление инцидентами ИБ.

Рекомендации: При разработке структуры организации и процессов для внутренних операций СУИБ следует попытаться создать их и обьединить с уже существующими, если это практически применимо.

Согласно стандарта ISO/IEC 27035, в первую очередь, необходимо создать группу технической поддержки, чтобы обеспечить поддержку всех аспектов информационных технологий и связанной с ними обработки информации. Как только приходит сообщение о событии ИБ, группа поддержки обрабатывает его в фазе обнаружении и оповещения.

Во вторую очередь, необходимо создать в организации специальную группу реагирования на инциденты ИБ (ГРИИБ). Целью ее создания является обеспечение организации соответствующим персоналом для оценки, реагирования иа инциденты ИБ и извлечения уроков из них, а также необходимой координации всех заинтересованных сторон и процесса обмена информацией.

Кроме того, организация обеспечить взаимодействие с внутренними подразделениями и внешними организациями, которые имеют отношение к управлению событиями, инцидентами и уязвимостями ИБ в организации.

Важно определить, какой орган в схеме обеспечения политики управления инцидентами ИБ руководитель ГРИИБ оповещает о серьезных инцидентах ИБ. Процедуры общения со СМИ и ответственность за это общение также должны быть согласованы с высшим руководством. Эти процедуры должны определить представителя организации по работе со СМИ и его взаимодействие с ГРИИБ.

Выходные данные: Документ, описывающий структуру организации, роли и сферы ответственности.

5.1.2. Разработка основы для документирования СУИБ

Необходимо проконтролировать записи и документы в системе СУИБ путем определения основы, которая позволит выполнить требования по текущему контролю записей и документов в системе СУИБ.

Исходные данные:

— выходные данные 1.3 — первоначально утвержденный проект СУИБ;

— выходные данные 2.4 — область действия и границы СУИБ;

— выходные данные 2.5 — политика СУИБ;

— выходные данные 5.1.1 — структура организации, роли и сферы ответственности;

— ISO/IЕС 27002 — правила СУИБ.

Рекомендации: Документация по СУИБ должна включать записи решений руководства, обеспечивать возможность отслеживания действий для принятия решений и разработки политики руководством и воспроизводимость записанных результатов.

Необходимо осуществлять управление документами СУИБ и сделать их доступными персоналу. Эти действия включают:

— учреждение административной процедуры управления документами СУИБ;

— подтверждение соответствия формата документов перед изданием;

— обеспечение определения изменений и текущего состояния редакций документов;

— защита и контроль документов как информационных активов организации.

Также требуется сохранять записи состояния внедрения системы для всей фазы «PDCA», а также записи об инцидентах и событиях ИБ, записи об обучении, навыках, опыте и квалификации, внутреннем аудите СУИБ, корректирующих и предупреждающих действиях и организационные записи.

Для контроля записей необходимо выполнить следующие задачи:

— документировать меры и средства контроля и управления, требуемые для идентификации, хранения, защиты, поиска и удаления данных, и документировать продолжительность хранения;

— определить, что и в какой степени должно записываться в процессах управления организацией;

— если соответствующим законодательством определен какой-либо период хранения, он должен быть установлен в соответствии с этими требованиями.

Выходные данные:

— документ, описывающий требования к записям СУИБ и контролю документации;

— хранилища и шаблоны требуемых записей СУИБ.

5.1.3. Разработка политики ИБ

Необходимо документировать стратегическую позицию руководства и администрации, связанную с целями ИБ в отношении использования СУИБ.

Исходные данные:

— выходные данные 1.1 — приоритеты организации для разработки СУИБ;

— выходные данные 1.3 — первоначально утвержденный проект СУИБ;

— выходные данные 2.4 — область действия и границы СУИБ;

— выходные данные 2.5 — политика СУИБ;

— выходные данные 3.1 — требования к ИБ для процесса СУИБ;

— выходные данные 3.2 — активы в рамках области действия СУИБ;

— выходные данные 3.3 — результаты оценки ИБ;

— выходные данные 4.2 — планы обработки рисков и инцидентов;

— выходные данные 4.3 — положение о применимости;

— выходные данные 5.1.1 — структура организации для ИБ;

— выходные данные 5.1.2 — основы документирования СУИБ;

— ISO/IЕС 27002 — правила СУИБ.

Рекомендации: Политика ИБ документирует стратегическую позицию организации в отношении ИБ во всей организации. Объем и структура политики ИБ должны подкреплять документы, которые используются на следующем этапе процесса для введения СУИБ.

Для больших организаций со сложной структурой (с широким спектром различных областей деятельности) может возникнуть необходимость создания общей политики и множества политик более низкого уровня, адаптированных к конкретным областям деятельности.

Предлагаемая политика (с номером версии и датой) должна быть подвергнута проверке и утверждена в организации руководством. Затем она доводится до сведения каждого работника организации надлежащим способом, чтобы стать доступной и понятной для читателей.

Выходные данные: Задокументированная и утвержденная руководством политика ИБ.

5.1.4. Разработка стандартов и процедур обеспечения ИБ

Исходные данные:

— выходные данные 2.4 — область действия и границы СУИБ;

— выходные данные 2.5 — политика СУИБ;

— выходные данные 4.2 — план обработки рисков,

— выходные данные 4.3 — положение о применимости;

— выходные данные 5.1.1 — структура организации для ИБ;

— выходные данные 5.1.2 — основы документирования СУИБ;

— выходные данные 5.1.3 — политики ИБ;

— ISO/IEC 27002 — правила СУИБ.

Рекомендации: В процессе разработки стандартов и процедур должны участвовать представители разных частей организации, попадающих в область действия системы СУИБ. Участники процесса должны иметь полномочия и являться представителями организации.

Стандарты и процедуры ИБ должны впоследствии использоваться в качестве основы для разработки подробных технических и оперативных процессов.

Документация должна предоставляться каждому сотруднику организации, попадающему в область действия СУИБ. Стандарты и процедуры по ИБ должны применяться ко всей организации или точно указывать, какие роли, системы и подразделения попадают под их действие.

Процесс редактирования и проверки должен быть определен на ранней стадии. Необходимо создать стратегию и технологию распространения информации об изменениях политики ИБ.

Выходные данные:

— стандарты ИБ:

— процедуры обеспечения ИБ для получения стандартов ИБ.

5.2. Разработка системы ИБ ИКТ и физических объектов

Исходные данные:

— выходные данные 2.5 — область действия и границы СУИБ;

— выходные данные 2.6 — политика СУИБ;

— выходные данные 3.2 — требования к ИБ для процесса СУИБ;

— выходные данные 3.3 — активы в рамках области действия СУИБ;

— выходные данные 3.4 — результаты оценки ИБ;

— выходные данные 4.3 — положение о применимости;

— ISO/IEC 27002 — правила СУИБ.

Рекомендации:

Необходимо документировать следующую информацию:

— имя лица, ответственного за внедрение мер защиты;

— приоритет внедряемых мер защиты;

— задачи или действия по внедрению;

— установление времени, в течение которого должно быть внедрено средство защиты;

— лицо, перед которым нужно отчитываться о внедрении мер защиты по его завершению;

— ресурсы для внедрения (рабочая сила, требуемое пространство, затраты).

Сферы ответственности за процесс первоначального внедрения обычно включают:

— задание целей управления с описанием предполагаемого планируемого состояния;

— распределение ресурсов (объем работ, финансовые ресурсы);

— реальное заданное время внедрения мер защиты;

— варианты объединения с системами безопасности ИКТ, физических объектов и организации.

Сферы ответственности за процесс фактического внедрения включают:

— разработку каждого из средств защиты для области безопасности ИКТ, физических объектов и организации на оперативном уровне рабочего места;

— конкретизацию каждой меры защиты в соответствии с согласованным проектом;

— предоставление процедур и информации для органов управления и учебных курсов, способствующих информированию в сфере безопасности;

— оказание помощи и внедрение средств управления на рабочем месте.

ИБ должна быть объединена в процедуры и процессы, применяемые во всей организации. Если для части организации или третьей стороны окажется трудным внедрение этих процедур и процессов, соответствующие стороны должны сообщить об этом немедленно, чтобы согласовать решение проблемы. Решение по подобным вопросам включает изменение процедур или процессов, перераспределение должностей и сфер ответственности и адаптацию технических процедур.

Результаты внедрения средств ИБ должны быть следующими:

— план внедрения, в котором подробно описывается внедрение средств защиты, например, график, структура группы по внедрению и т. д.;

— записи и документация по результатам внедрения.

Выходные данные:

Структурированный подробный план внедрения средств управления, связанных с безопасностью ИКТ и физических обьектов, включает:

— подробное описание;

— сферы ответственности за разработку и внедрение;

— предполагаемые временные шкалы;

— связанные задачи;

— требуемые ресурсы;

— собственность (линии отчетности).

5.3. Создание условий для надежного функционирования СУИБ

Создание условий для надежного функционирования СУИБ предполагает разработку следующих документов:

— план проверок, проводимых руководством;

— программа обучения в области ИБ.

5.3.1. План проверок, проводимых руководством

Необходимо разработать план, обеспечивающий участие руководства и выдачу поручений на проверку работы СУИБ и проводимых улучшений.

Исходные данные:

— выходные данные 2.4 — область действия и границы СУИБ;

— выходные данные 2.5 — политика СУИБ;

— выходные данные 4.3 — положение о применимости;

— выходные данные 5.1.3 — политики ИБ;

— ISO/IEC 27004 — проведение измерений СУИБ.

Рекомендации: Проверка руководством действия по внедрению СУИБ должна начинаться на самых ранних стадиях задания условий для СУИБ и описания случая применения СУИБ и продолжаться вплоть до регулярных проверок операций СУИБ.

Планирование проверок, проводимых руководством, включает установление времени и способа проведения проверок. Чтобы запланировать проверку, необходимо определить, какие должностные лица должны в ней участвовать. Назначенные должностные лица должны быть утверждены руководством и проинформированы об этом как можно раньше

Проверки, проводимые руководством, должны основываться на результатах измерений СУИБ и другой информации, накопленной за время использования СУИБ. Эта информация используется для выполнения действий руководством для определения готовности и эффективности СУИБ.

До проведения проверки руководством необходимо запланировать внутренний аудит. Результаты внутреннего аудита СУИБ являются важными исходными данными для проверок СУИБ, проводимых руководством.

Внутренний аудит СУИБ должен включать проверку того, эффективно ли внедряются и обеспечиваются меры защиты, процессы и процедуры СУИБ и соответствуют ли они:

— требованиям ISO/IEC 27001;

— действующему законодательству и правилам;

— другим требованиям ИБ.

Предварительным условием для проведения проверок СУИБ, проводимых руководством, являются данные его постоянного мониторинга. В процессе мониторинга СУИБ должны документироваться его результаты, которые записываются и сообщаются руководству.

Информация, предоставляемая руководству, может включать следующее:

— отчеты об инцидентах за последний период использования СУИБ;

— отчеты по внедрению СУИБ и обнаруженные несоответствия;

— результаты других регулярных проверок;

— рекомендации по улучшению СУИБ.

Выходные данные: Документ, содержащий план организации проверок, проводимых руководством, и включающий:

— исходные данные, требуемые для проверки СУИБ руководством;

— процедуры проверок, проводимых руководством и касающихся аспектов аудита, мониторинга и измерения.

5.3.2. Программа обучения в области ИБ

Исходные данные6

— выходные данные 2.4 — область действия и границы СУИБ;

— выходные данные 2.5 — политика СУИБ;

— выходные данные 3.1, — требований к ИБ для процесса СУИБ;

— выходные данные 4.2 — план обработки рисков;

— выходные данные 4.3 — положение о применимости;

— выходные данные 5.1.3 — политики ИБ;

— выходные данные 5.1.4 — стандарты и процедуры ИБ;

— обзор общей программы обучения в организации.

Рекомендации: Руководство отвечает за обучение, чтобы сотрудники, назначенные на определенные должности, имели необходимые знания для выполнения требуемых операций. Содержание программы образования и обучения должно помогать всем сотрудникам знать и понимать значение и важность операций по обеспечению ИБ, в которых они участвуют, и то, как они могут способствовать достижению целей.

Программа обучения с целью информирования по вопросам ИБ должна обеспечивать составление записей по обучению в области ИБ. Эти записи должны регулярно проверяться для обеспечения получения требуемого обучения всеми сотрудниками. Необходимо назначить должностное лицо, ответственное за этот процесс.

Материалы по обучению в области ИБ должны быть разработаны таким образом, чтобы они были связаны с другими обучающими материалами, используемыми в организации, особенно, учебные курсы для пользователей ИС. Обучение по существенным аспектам ИБ должно включаться в каждый учебный курс для пользователей ИС.

Обучающие материалы по ИБ должны включать, как минимум, следующие пункты в зависимости от целевой аудитории:

— основные термины ИБ;

— риски и угрозы ИБ;

— четкое определение инцидента ИБ: рекомендации по его обнаружению, устранению и отчетности;

— политики ИБ, стандарты и процедуры организации;

— сферы ответственности и каналы отчетности, связанные с ИБ;

— рекомендации по оказанию помощи в повышении уровня ИБ;

— рекомендации, связанные с нарушениями ИБ и отчетностью;

— координаты получения дополнительной информации.

Необходимо определить группу по обучению ИБ, которая может выполнять следующие задачи:

— создание и управление записями по ИБ;

— составление и управления материалами по обучению;

— проведение обучения.

Выходные данные:

— материалы по обучению в области ИБ;

— формирование программ обучения в области ИБ, включая роли и сферы ответственности;

— планы обучения в области ИБ;

— записи, показывающие результаты обучения работников в области ИБ.

5.4. Разработка окончательного плана проекта СУИБ

Исходные данные:

— выходные данные 2.4 — область действия и границы СУИБ;

— выходные данные 2.5 — политика СУИБ;

— выходные данные 5.1 — разработка системы ИБ;

— выходные данные 5.2 — разработка системы ИБ ИКТ и физических объектов;

— выходные данные 5.3 — разработка ИБ, связанной с СУИБ;

— ISO/IEC 27002 — правила СУИБ.

Рекомендации: Действия, требуемые для внедрения выбранных средств управления и выполнения других действий, связанных с системой СУИБ, должны быть оформлены в виде подробного плана внедрения как части конечного проекта СУИБ. Подробный план внедрения системы также может подкрепляться описаниями предложенных инструментов и методов внедрения.

Поскольку проект СУИБ включает множество различных ролей в организации, важно, чтобы действия были четко определены для ответственных сторон и план был распространен на ранних стадиях проекта во всей организации.

Выходные данные: Выходные данные этого действия представляют собой окончательный план проекта внедрения СУИБ.

5. Управление рисками иб (стандарт ISO/IEC 27005:2010)

В начале 2006 года был принят первый британский национальный стандарт в сфере управления рисками ИБ BS 7799—3, который в 2008 году получил статус международного стандарта ISO/IEC 27005 «ИТ. Методы защиты. Управление рисками ИБ».

Новый стандарт ISO/IEC 27005 заменил сразу две части морально устаревшего технического стандарта ISO/IEC TR 13335 (TR — technical report — технический отчет) «ИТ. Методы защиты»: часть 3 «Методы управления безопасностью ИТ» и часть 4 «Выбор защитных мер», на базе которых он и был разработан.

В 2011 году была принята последняя редакция стандарта ISO/IEC 27005, в котором были пересмотрены и обновлены в соответствии с требованиями следующих документов:

— ISO 31000:2009 — Управление рисками — Принципы и руководства;

— ISO/IEC 31010:2009 — Управление рисками — Методики оценки рисков;

— ISO Guide 73:2009 — Управление рисками — Словарь.

Систематический подход к управлению рисками ИБ необходим для того, чтобы идентифицировать потребности организации, касающиеся требований ИБ, и создать эффективную СУИБ.

Усилия по обеспечению ИБ должны эффективно и своевременно рассматривать риски там и тогда, где и когда это необходимо. Управление рисками ИБ должно быть неотъемлемой частью всех видов деятельности, связанных с УИБ, а также должен применяться для реализации и поддержки функционирования СУИБ организации.

Управление рисками ИБ должно быть непрерывным процессом. Данный процесс должен устанавливать контекст, поддерживать оценку и обработку рисков, обеспечивать использование плана обработки риска для реализации, содействовать выработке рекомендаций и решений.

Управление рисками ИБ связано с анализом того, что может произойти, и какими могут быть возможные последствия, прежде чем выработать решение о том, что и когда должно быть сделано для снижения риска до приемлемого уровня.

Управление рисками ИБ должно способствовать следующему:

— идентификации рисков;

— оценке рисков, исходя из последствий их реализации для бизнеса и вероятности их возникновения;

— изучению вероятности и потенциальных последствий данных рисков;

— установлению порядка приоритетов в рамках обработки рисков;

— установлению приоритетов мероприятий по снижению имеющих место рисков;

— привлечению заинтересованных сторон к принятию решений об управлении рисками и поддержанию их информированности о состоянии управления рисками;

— эффективности проводимого мониторинга обработки рисков;

— проведению регулярного мониторинга и пересмотра процесса управления рисками;

— сбору информации для усовершенствования подхода к управлению рисками;

— подготовке менеджеров и персонала в сфере управления рисками и необходимых действий, предпринимаемых для их уменьшения.

Стандарт содержит описание процесса управления рисками ИБ и связанных с ним видов деятельности, основной обзор которых даётся в разделе 6.

Все действия по управлению рисками ИБ описываются в следующих разделах:

1) установление контекста (сферы применения) — в разделе 7;

2) оценка риска — в разделе 8;

3) обработка риска — в разделе 9;

4) принятие риска — в разделе 10;

5) обмен информацией о рисках — в разделе 11;

6) мониторинг и улучшение — в разделе 12.

Все составляющие управления рисками в каждом разделе структурированы в виде входных данных, действий, руководства по реализации и выходных данных.

Входные данные: идентифицируется любая информация, требуемая для выполнения деятельности.

Действие: описывается деятельность.

Руководство по реализации: предоставляется руководство по выполнению действия.

Выходные данные: идентифицируется любая информация, полученная после выполнения деятельности.

Процесс управления рисками ИБ может быть итеративным для таких видов деятельности, как оценка риска и/или обработка риска. Итеративный подход к проведению оценки риска может увеличить глубину и детализацию оценки при каждой итерации. Итеративный подход даёт хороший баланс между уменьшением времени и усилия, затрачиваемого на определение средств контроля, в то же время, по-прежнему обеспечивая уверенность в том, что высокоуровневые риски рассматриваются соответствующим образом.

Контекст впервые устанавливается тогда, когда проводится оценка высокоуровневого риска. Если она обеспечивает достаточную информацию для эффективного определения действий, требуемых для снижения риска до приемлемого уровня, то задача является выполненной и следует обработка риска. Если информация является недостаточной, то проводится другая итерация оценки риска с помощью пересмотренного контекста (например, критерии оценки рисков, критерии принятия рисков или критерии влияния), возможно на ограниченных частях полной области применения (точка принятия решения о приемлемости риска № 1).

Эффективность обработки риска зависит от результатов оценки риска. Возможно, что обработка риска не будет сразу же приводить к приемлемому уровню остаточного риска. В этой ситуации может потребоваться, если необходимо, другая итерация оценки риска с изменёнными параметрами контекста (например, оценка риска, принятие риска или критерии влияния), за которой последует дополнительная обработка риска (точка принятия решения о приемлемости риска № 2).

Деятельность по принятию риска должна обеспечивать уверенность в том, что остаточные риски однозначно принимаются руководством организации. Это особенно важно в ситуации, когда внедрение средств контроля не осуществляется или откладывается, например, из-за стоимости.

Важно, чтобы во время всего процесса управления рисками ИБ и их обработки осуществлялся обмен информацией относительно риска между руководством и персоналом. Даже до обработки рисков информация об идентифицированных рисках может быть очень ценной для осуществления управления инцидентами и может способствовать снижению потенциального ущерба.

На этапе планирования СУИБ осуществляются установление контекста, оценка риска, разработка плана обработки риска и принятие риска. На этапе реализации СУИБ осуществляются действия по снижению риска до приемлемого уровня в соответствии с планом обработки риска. На этапе проверки СУИБ осуществляются мониторинг и пересмотр обработки риска по результатам обработки инцидентов и изменений обстоятельств. На этапе улучшения СУИБ осуществляются любые корректирующие действия по усовершенствованию, включая повторное инициирование процесса управления рисками ИБ.

Следующая таблица суммирует действия по управлению рисками ИБ, относящиеся к 4-м этапам функционирования СУИБ:

1. Установление контекста (сферы применения)

Входные данные: Вся информация об организации, уместная для установления сферы применения управления рисками ИБ.

Действие: Для установления контекста организации необходимо определить:

— основные критерии управления рисками;

— сферы действия и границы;

— организационную структуру управления рисками.

Руководство по реализации: Необходимо определить цель управления рисками ИБ, так как она влияет на общий процесс и на сферу применения, в частности. Этой целью может быть:

— поддержка СУИБ;

— правовое соответствие и свидетельство должного внимания;

— подготовка плана обеспечения непрерывности бизнеса;

— подготовка плана реагирования на инциденты;

— описание требований ИБ для продукта, услуги или механизма.

Выходные данные: Спецификация основных критериев, сфера действия и границы, структура для процесса управления рисками ИБ.

1.1. Основные критерии

Должны быть разработаны следующие критерии управления рисками ИБ:

— оценки риска;

— воздействия риска;

— принятия риска.

Дополнительно организация должна оценить, доступны ли необходимые ресурсы для:

— выполнения оценки риска и установления плана обработки риска;

— определения и осуществления политики и процедуры, включая реализацию управления рисками;

— контроля мониторинга;

— мониторинга процесса управления рисками.

Критерии оценки риска

При разработке критериев оценки рисков необходимо учитывать следующее:

— стратегическая ценность обработки бизнес-информации;

— критичность затрагиваемых информационных активов;

— нормативно-правовые требования и договорные обязательства;

— важность для бизнеса доступности, конфиденциальности и целостности информации.

Кроме того, критерии оценки рисков могут использоваться для определения приоритетов для обработки рисков.

Критерии воздействия

Критерии воздействия должны разрабатываться и определяться, исходя из степени ущерба от события ИБ, учитывая следующее:

— уровень классификации информационного актива, на который оказывается влияние;

— нарушения ИБ (например, потеря конфиденциальности, целостности или доступности);

— ухудшение бизнес-операции;

— потеря ценности бизнеса и финансовой ценности;

— нарушение планов и конечных сроков;

— ущерб для репутации;

— нарушение нормативно-правовых или договорных требований.

Критерии принятия риска

Организация должна определять собственную шкалу уровней принятия риска.

При разработке критериев принятия риска следует учитывать, что они могут:

— включать многие пороговые значения с желаемым уровнем риска, но при условии, что при определённых обстоятельствах руководство будет принимать риски, находящиеся выше указанного уровня;

— выражаться как количественное соотношение оценённой выгоды к оценённому риску для бизнеса;

— включать требования для будущей дополнительной обработки, например, риск может быть принят, если имеется согласие на действия по его снижению до приемлемого уровня в рамках определённого периода времени.

Критерии принятия риска должны устанавливаться с учётом:

— критериев бизнеса;

— правовых и регулирующих аспектов;

— операций;

— технологий;

— финансов;

— социальных и гуманитарных факторов.

1.2. Область применения и границы

Область применения процесса УИБ необходимо определять для обеспечения того, чтобы все значимые активы принимались в расчёт при оценке риска. Кроме того, необходимо определять границы для рассмотрения тех рисков, источники которых могут находиться за данными границами.

При определении области применения и границ должна учитываться следующая информация, касающаяся организации:

— стратегические цели бизнеса организации, стратегии и политики;

— процессы бизнеса;

— функции и структура организации;

— нормативно-правовые и договорные требования;

— политика ИБ;

— общий подход к управлению рисками;

— информационные активы;

— местоположение организации и географические характеристики;

— ограничения, влияющие на организацию;

— социальная и культурная среда.

Примерами области применения управления рисками ИБ могут быть ИТ-приложение, ИТ— инфраструктура, бизнес-процесс или определённая часть организации.

1.3. Организационная структура

Необходимо устанавить организационную структуру организации и обязанности ответственных лиц для процесса управления рисками ИБ.

Главными ролями и обязанностями в такой структуре являются:

— разработка процесса управления рисками ИБ в организации;

— идентификация и анализ заинтересованных сторон;

— определение ролей и обязанностей всех сторон, как внутренних, так и внешних;

— установление требуемых взаимосвязей между заинтересованными сторонами;

— определение путей принятия решений;

— определение документов, которые необходимо вести.

2. Оценка рисков ИБ

Входные данные: Установленные критерии, сфера действия и границы, организационная структура для процесса управления рисками ИБ.

Действие: Оценку риска обеспечивают следующие меры:

— идентификация рисков;

— измерение рисков;

— оценивание рисков.

Руководство по реализации: Риски должны быть идентифицированы, количественно определены или качественно описаны и расставлены в соответствии с приоритетами, исходя из критериев оценки риска и целей организации.

Риск представляет собой комбинацию последствий, вытекающих из нежелательного события, и вероятности возникновения события. Оценка риска количественно определяет или качественно описывает риски и даёт возможность руководителям расставлять риски в соответствии с приоритетами согласно установленным критериям.

Оценка риска определяет ценность информационных активов, идентифицирует применимые угрозы и уязвимости, которые существуют (или могут существовать), идентифицирует существующие средства контроля и их влияние на идентифицированные риски, определяет потенциальные последствия и, наконец, расставляет выведенные риски в соответствии с приоритетами и ранжирует их по критериям оценки рисков.

Выходные данные: Перечень оценённых рисков, расставленных в соответствии с приоритетами согласно критериям оценки риска.

2.1. Идентификация рисков

Целью идентификации рисков является определение того, что могло бы произойти, чтобы нанести потенциальный, и чтобы получить представление о том, как, где и почему мог иметь место этот вред.

Для идентификация рисков необходимо идентифицировать следующие объекты:

— активы;

— угрозы;

— средства защиты;

— уязвимости;

— последствия.

2.1.1. Идентификация активов

Входные данные: Область применения и границы для оценки риска, перечень составных частей, включающий владельцев, местоположение, функцию и т. д.

Действие: Должны быть идентифицированы активы, входящие в установленную область применения, и определены их владельцы.

Руководство по реализации: Ответственность за каждый актив должен нести его владелец, который должен быть в организации определён или назначен. Чаще всего владелец актива является наиболее подходящим лицом, способным определить реальную ценность актива для организации.

Можно выделить два вида активов:

— первичные активы: бизнес-процессы и информация;

— активы поддержки всех типов: аппаратные средства и ПО, сети и сайты, организационная структура и персонал.

Все определения ценности активов должны быть сведены к общей основе. Это можно сделать с помощью критериев, которые могут использоваться для оценки возможных последствий, вытекающих из потери конфиденциальности, целостности, доступности, неотказуемости, учётности, подлинности или надёжности активов.

Они включают в себя:

— нарушение законодательства и/или предписаний;

— ухудшение функционирования бизнеса;

— потеря «неосязаемого капитала»/негативное влияние на репутацию;

— нарушения, связанные с личной информацией;

— создание угрозы личной безопасности;

— неблагоприятное влияние на обеспечение правопорядка;

— нарушение конфиденциальности;

— нарушение общественного порядка;

— финансовые потери;

— нарушение бизнес-деятельности;

— создание угрозы для безопасности окружающей среды.

Другим подходом к оценке последствий может быть:

— прерывание сервиса;

— потеря репутации и доверия клиента;

— нарушение внутреннего функционирования;

— нарушение функционирования третьей стороны;

— нарушение законов/предписаний;

— нарушение договора;

— опасность для персонала / безопасность пользователей;

— вторжение в частную жизнь пользователей;

— финансовые потери;

— финансовые потери, связанные с непредвиденными случаями или ремонтом:

— потеря товаров / денежных средств / активов;

— потеря клиентов, поставщиков;

— судебные дела и штрафы;

— потеря конкурентного преимущества;

— потеря технологического/технического лидерства;

— потеря эффективности/надёжности;

— потеря технической репутации;

— снижение способности к заключению соглашений;

— промышленный кризис (забастовки);

— правительственный кризис;

— материальный ущерб.

После установления критериев ценности активов организация должна согласовать шкалу, которая будет использоваться в масштабах организации. Первым шагом является принятие решения о числе используемых уровней. Обычно может использоваться любое число уровней от 3 (например, низкий, средний и высокий) до 10 в соответствии с подходом, используемым организацией для всего процесса оценки риска.

Организация может определить собственные границы для ценности активов, такие как «низкая», «средняя» или «высокая». Эти границы должны оцениваться в соответствии с выбранными критериями (например, для возможных финансовых потерь они должны быть даны в денежном выражении, но при рассмотрении угрозы личной безопасности, определить денежную ценность может быть затруднительно).

Выходные данные: Перечень активов, подлежащий управлению рисками, и перечень бизнес-процессов, связанных с активами, и их ценность.

2.1.2. Идентификация угроз

Входные данные: Информация об угрозах, полученная от владельцев активов, пользователей, в результате анализа инцидента, а также из других источников, включая реестры известных угроз.

Действие: Угрозы и их источники должны быть идентифицированы.

Руководство по реализации: Угроза обладает потенциалом причинения вреда активам. Должны быть идентифицированы и случайные, и умышленные источники угроз. Угроза может проистекать как из самой организации, так и вне её пределов. Угрозы должны идентифицироваться в общем и по виду (например, неавторизованные действия, физический ущерб, технические сбои).

Некоторые угрозы могут влиять более, чем на один актив. В таких случаях они могут являться причиной различных влияний, в зависимости от того, на какие активы оказывается воздействие

Используя реестры угроз или результаты прежних оценок угроз, не следует забывать о том, что происходит постоянная смена значимых угроз, особенно, если изменяются бизнес-среда или информационные системы.

Выходные данные: Перечень угроз с идентификацией вида и источника. Например, угрозы могут быть преднамеренными, случайными и экологическими. Особое внимание должно быть обращено на человеческие источники угроз.

2.1.3. Идентификация средств защиты

Входные данные: Документация средств защиты, планы обработки рисков и инцидентов.

Действие: Идентификацию средств защиты необходимо провести, чтобы проверить их эффективность и достаточность и избежать ненужных расходов, например, на их дублирование.

Если средства защиты не работают, как ожидалось, это может стать причиной уязвимости. Одним из способов количественно оценить действия средств защиты — посмотреть, как оно уменьшает вероятность угрозы и использования уязвимости или влияние инцидента.

Существующее или планируемое средство защиты может идентифицироваться как неэффективное или недостаточное, или необоснованное. Если его посчитали необоснованным или недостаточным, средство защиты необходимо проверить, чтобы определить стоит ли его удалить, заменить его другим, более подходящим, или стоит оставить его на месте, например, по стоимостным причинам.

Для идентификации существующих или планируемых средств защиты могут быть полезны следующие мероприятия:

— просмотр документов, содержащих информацию о средствах защиты (например, планы обработки рисков и инцидентов);

— проверка вместе с людьми, отвечающими за ИБ, и пользователями, какие средства защиты действительно реализованы для рассматриваемого информационного процесса или системы;

— обход здания с проведением осмотра физических средств защиты, проверка наличия существующих и реализованных средств защиты на предмет правильной и эффективной работы;

— рассмотрение результатов внутренних аудитов.

Выходные данные: Перечень всех существующих и планируемых средств защиты, их нахождение и состояние использования.

2.1.4. Идентификация уязвимостей

Входные данные: Перечни известных угроз, активов и существующих средств защиты.

Действие: Необходимо идентифицировать уязвимости, которые могут быть использованы угрозами, чтобы нанести ущерб активам или организации.

Руководство по реализации:

Уязвимости могут быть идентифицированы в следующих областях:

• организация работ;

• процессы и процедуры;

• установившиеся нормы управления;

• персонал;

• физическая среда;

• конфигурация ИС;

• аппаратные средства, ПО и оборудование связи;

• зависимость от внешних организаций.

Наличие уязвимости не причиняет вреда само по себе, так как необходимо наличие угрозы, которая воспользуется ею. Уязвимость, не имеющая соответствующей угрозы, может не требовать внедрения средства контроля, но должна осознаваться и подвергаться мониторингу на предмет изменений.

Уязвимости могут быть связаны со свойствами актива, которые могут использоваться способом и с целью, отличающимися от тех, которые планировались при приобретении или создании актива. Уязвимости, возникающие из различных источников, подлежат рассмотрению, например, те которые являются внешними или внутренними по отношению к активу.

Выходные данные:

— перечень уязвимостей, связанных с активами, угрозами и средствами защиты;

— перечень уязвимостей, не связанных с подлежащей рассмотрению угрозой.

2.1.5. Идентификация последствий

Входные данные: Перечни активов, бизнес-процессов, угроз и уязвимостей, связанных с активами, и их ценность.

Действие: Должны быть идентифицированы последствия для активов, которые могут быть результатом потери конфиденциальности, целостности или доступности. Последствием может быть потеря эффективности, неблагоприятные операционные условия, потеря бизнеса, ущерб, нанесённый репутации и т. д.

Эта деятельность идентифицирует ущерб для организации или последствия для организации, которые могут быть обусловлены сценарием инцидента, оказываемой угрозой, использующей определённую уязвимость в инциденте ИБ. Последствия могут быть временными или постоянными, как в случае разрушения активов.

Необходимо определять последствия сценариев инцидентов на основе таких факторов:

— времени на расследование и восстановление;

— потерь (рабочего) времени;

— упущенной возможности;

— нарушений охраны труда и безопасности;

— финансовых затрат на устранение последствий;

— ущерба для репутации и т. д.

Выходные данные: Перечень сценариев инцидентов с их последствиями, связанными с активами и бизнес-процессами.

2.2. Измерение риска

Измерение риска обеспечивают следующие меры:

— разработка методологии измерения риска;

— оценка последствий инцидента;

— оценка вероятности инцидента;

— измерение уровня риска.

2.2.1. Разработка методологии измерения риска

Методология измерения риска может быть качественной или количественной, или смешанной, в зависимости от обстоятельств. На практике качественная оценка часто используется первой для получения общих сведений об уровне риска и выявления основных значений рисков. Позднее может возникнуть необходимость в осуществлении количественного анализа основных значений рисков, поскольку качественный анализ является более бытрым и менее затратным.

Дополнительная информация (отсутствует в стандарте)

Предлагаемое на рынке ПО ориентировано в основном на уровень ИБ, несколько превышающий базовый уровень защищенности. Для решения данной задачи были разработаны программные комплексы анализа и контроля рисков, основанные на:

— качественной методике — COBRA, FRAP, RA2 art of risk;

— количественной методике — SecureWatch;

— смешанной методике — CRAMM, MSAT, vsRisk, РискМенеджер, ГРИФ.

Качественные методики

FRAP (Facilitated Risk Analysis Process)

Методика разработана Томасом Пелтиером в 2000 году. Оценка рисков производится для вероятности возникновения угрозы и ущерба от нее по 3-уровневой шкале (низкая, средняя, высокая). Определяется 4-уровневая оценка риска (A, B, C, D) в соответствии с правилом, задаваемым построенной матрицей рисков 3х3.

COBRA (Consultative Objective and Bi-Functional Risk Analysis — www.riskworld.net)

ПО разработано компанией «C&A Systems Security» в 1997 году. Методика представляет требования стандарта ISO/IEC 17799 в виде тематических вопросников (check list’s), на которые следует ответить в ходе оценки рисков. Далее введенные ответы автоматически обрабатываются, и формируется итоговый отчет c текущими оценками информационных рисков компании и рекомендациями по их управлению.

RA2 art of risk (ранее RA Software Tool) — ПО уже не поддерживается

В методике реализован простой для понимания процессный подход, общие требования к которому изложены в ISO/IEC 27001. Процесс управления рисками может настраиваться под потребности конкретной организации. Для успешной оценки и управления рисками необходимо собирать информацию из различных источников в организации.

Количественные методики используют шкалу с числовыми значениями и последствий, и вероятности, применяя данные из различных источников. Качество анализа зависит от точности и полноты числовых значений и от обоснованности используемых моделей. В большинстве случаев количественная оценка использует фактические данные за прошлый период, обеспечивая преимущество в том, что она может быть напрямую связана с целями ИБ и проблемами организации.

SecureWatch (ранее RiskWatch: http://riskwatch.com)

ПО разработано в 1988 году компанией «RiskWatch International» при участии Национального института стандартов и технологий США, Министерства обороны США и Канады и является по сути стандартом государственных организаций США.

Смешанные методики

CRAMM (UK Government Risk Analysis and Management Method) — ПО уже не поддерживается

Методика разработана компанией «BIS Applied Systems Ltd» пo заказу британского правительства и является государственным стандартом Великобритании. Получивший широкое распространение в мире, данный стандарт используется как в коммерческих, так и государственными организациями Великобритании с 1985 года.

vsRisk (www.vigilantsoftware.co.uk — www.itgovernance.co.uk)

Новая методика, разработанная компаниями «IT Governance» и «Vigilant Software» для оценки рисков ИБ в соответствии с требованиями стандарта ISO/IEC 27001. Также методика соответствует стандартам ISO/IEC 27005 и NIST SP 800—30.

Microsoft Security Assessment Tool (http://technet.microsoft.com/ru-ru/security/cc185712)

Методика состоит из более чем 200 вопросов, охватывающих инфраструктуру, приложения, операции и персонал. Вопросы, связанные с ними ответы и рекомендации выводятся из общепринятых практических рекомендаций, стандартов, таких как ISO 17799 и NIST-800.

ГРИФ (www.dsec.ru)

Комплексная система анализа и управления рисками информационной системы в составе пакета «Digital Security Office 2006», разработанная российской компанией «Digital Security». Использует два алгоритма: модель информационных потоков и модель анализа угроз и уязвимостей.

Риск Менеджер (www.srisks.ru)

Система автоматизации управления рисками, аудита, контроля, мониторинга безопасности банковских и других критических систем, инфраструктур и бизнес-процессов, разработанная Институтом системного анализа Российской Академии Наук.

2.2.2. Оценка последствий инцидента

Входные данные: Перечень идентифицированных сценариев инцидентов, включая идентификацию угроз, уязвимостей и затронутых активов, последствий для активов и бизнес-процессов.

Действие: Влияние бизнеса на организацию, которое может быть результатом возможных или фактических инцидентов ИБ должно быть оценено с учётом последствий нарушений ИБ (потеря конфиденциальности, целостности или доступности активов).

Руководство по реализации: Это значение влияния бизнеса может быть выражено в качественной или количественной формах, однако, любой метод присвоения денежного эквивалента может дать больше информации для принятия решений и, следовательно, сделает возможным более эффективный процесс принятия решений.

Определение ценности активов начинается с классификации активов в соответствии с их критичностью с точки зрения их важности для осуществления бизнес-целей организации.

Затем определяется восстановительная стоимость актива с учетом стоимости:

— восстановления и замены информации;

— последствий для бизнеса от потери или компрометации актива.

Определение ценности активов является ключевым фактором оценки влияния сценария инцидента, поскольку инцидент может затрагивать более, чем один актив. Различные угрозы и уязвимости могут иметь различное влияние на активы. Оценка последствий является, поэтому, связанной с определением ценности активов или делается исходя из анализа влияния на бизнес.

Выходные данные: Перечень оценённых последствий сценария инцидентов, выраженных по отношению к активам и критериям влияния на активы.

2.2.3. Оценка вероятности инцидента

Входные данные: Перечни идентифицированных сценариев инцидентов, включая идентификацию угроз, затрагиваемые активы, используемые уязвимости и последствия для активов и бизнес-процессов. Кроме того, список всех существующих и планируемых средств контроля и состояния их реализации и использования.

Действие: Должна быть оценена вероятность действия сценариев инцидентов.

Руководство по реализации: После идентификации сценариев инцидентов необходимо оценить вероятность каждого сценария и возникающее влияние, используя качественные или количественные методы оценки.

Здесь нужно учитывать тот факт, как часто возникают угрозы и насколько легко могут быть использованы уязвимости, рассматривая:

— опыт и применимую статистику вероятности угроз;

— для источников умышленных угроз: мотивацию и возможности, которые будут меняться с течением времени, и доступные для возможных нарушителей ресурсы, а также восприятие привлекательности и уязвимости активов возможным нарушителем;

— для источников случайных угроз: географические факторы, например, близость к химическому или нефтеперерабатывающему заводу, возможность экстремальных погодных условий и факторы, которые могут оказывать влияние на ошибки персонала и сбои оборудования;

— уязвимости в индивидуальном плане и в совокупности;

— существующие средства контроля и то, насколько эффективно они снижают уязвимости.

Выходные данные: Перечень сценариев инцидентов с количественной или качественной оценкой вероятности их реализации.

2.2.4. Измерение уровня риска

Входные данные: Перечень сценариев инцидентов с их последствиями, касающимися активов, и бизнес-процессов и их вероятности (количественных или качественных).

Действие: Должно быть осуществлено измерение уровня рисков для всех значимых сценариев инцидентов.

При измерении риска присваиваются значения вероятности и последствий риска. Эти значения могут быть качественными или количественными. Измерение риска основывается на оценённых последствиях и вероятности. Измеренный риск является комбинацией вероятности нежелательного сценария и его последствий.

Для примера идентифицируем значения ценности активов, используя числовую шкалу от 0 до 4. Следующим шагом идентифицируем каждый вид угрозы, каждую группу активов, с которой связан данный вид угрозы, чтобы сделать возможной оценку уровней угроз и уровней уязвимостей.

Ценность активов, уровни угроз и уязвимостей приводим к табличной форме (матрице), чтобы для каждой комбинации идентифицировать соответствующую меру риска на основе шкалы от 0 до 8. Значения заносятся в матрицу структурированным образом.

Для каждого актива рассматриваются уязвимости и соответствующие им угрозы. Теперь соответствующая строка в таблице устанавливает значение ценности актива, а соответствующая колонка — вероятность возникновения угрозы и уязвимости. Например, если актив имеет ценность 3, угроза является «высокой», а уязвимость «низкой», то мера риска будет равна 5.

Аналогичная матрица является результатом рассмотрения вероятности сценария инцидента с учетом влияния на бизнес. Получаемый в результате риск измеряется по шкале от 0 до 8 и может быть оценён по отношению к критериям принятия риска.

Таблица может быть использована также, чтобы связать факторы последствий для активов с вероятностью возникновения угрозы (принимая в расчёт аспекты уязвимости). Первый шаг состоит в оценивании последствий для активов по заранее определённой шкале, например, от 1 до 5, для каждого находящегося под угрозой актива (колонка 2). Второй шаг состоит в оценивании вероятности возникновения угрозы по заранее определённой шкале, например, от 1 до 5, для каждой угрозы (колонка 3).

Третий шаг состоит в вычислении меры риска путём умножения значений колонок 2 и 3. Наконец, угрозы могут быть ранжированы в порядке соответствующей меры риска. Отметим, что значение «1» в колонках 2 и 3 соответствует наименьшим последствиям и вероятности угрозы, а в колонке 5 — наибольшей опасности.

Выходные данные: Перечень рисков с присвоенными уровнями значений.

2.3. Оценивание риска

Входные данные: Перечень рисков с присвоенными уровнями значений и критерии оценки риска.

Действие: Уровень риска должен сравниваться с критериями оценивания и принятия риска.

Руководство по реализации: Характер решений, относящихся к оцениванию риска, и критерии оценивания риска, которые будут использованы для принятия этих решений, должны были быть определены при установлении сферы применения СУИБ. Для оценивания рисков должны сравниваться измеренные риски с критериями оценивания риска, выбранными на 1-м этапе управления рисками ИБ.

Критерии оценивания риска, используемые для принятия решений, должны согласовываться с определённой сферой применения СУИБ и принимать в расчёт цели организации, мнения заинтересованных сторон и т. д. Решения, связанные с оценкой риска, обычно основываются на его приемлемом уровне. Совокупность множества рисков низкого и среднего уровня может дать в итоге общий риск более высокого уровня.

При этом следует учесть следующее:

— свойства ИБ — если один критерий не актуален для организации (например, потеря конфиденциальности), то все риски, влияющие на этот критерий, могут быть также не актуальными;

— значимость бизнес-процесса, поддерживаемого конкретным активом или их совокупностью — если процесс определён как имеющий низкую значимость, связанные с ним риски должны рассматриваться в меньшей степени, чем риски, влияющие на более важные процессы.

Оценивание риска основывается на понимании сути риска, полученном на этапе его анализа, для принятия решений о будущих действиях. Решения должны включать в себя следующее:

— должны ли быть предприняты какие-то действия;

— приоритеты при обработке риска, учитывающие измеренные уровни рисков.

Выходные данные: Перечень рисков с назначенными приоритетами в соответствии с критериями оценки риска в отношении сценариев инцидентов, которые приводят к этим рискам.

3. Обработка рисков ИБ

Входные данные: Перечень рисков с назначенными приоритетами в соответствии с критериями оценки риска в отношении сценариев инцидентов, которые приводят к этим рискам.

Действие: Должен быть осуществлен выбор варианта обработки рисков, соответствующих мер и средства защиты, и разработан план обработки рисков.

Руководство по реализации:

Обработку риска обеспечивают следующие меры:

— поиск решений;

— выбор варианта обработки;

— реализация обработки;

— оценка остаточного риска.

Предусмотрены следующие варианты обработки риска:

— снижение;

— сохранение;

— избежание (предотвращение);

— перенос.

Вариант обработки риска должен выбираться на основе результатов оценки риска, ожидаемой стоимости реализации и выгоды от этого варианта. Выбирается тот вариант, когда значительное снижение риска может быть достигнуто при относительно небольших затратах. Неблагоприятные последствия риска необходимо снижать до разумных пределов и независимо от каких-либо абсолютных критериев.

Некоторые виды обработки рисков могут быть эффективными для более, чем одного риска (например, обучение и осведомлённость персонала). План обработки риска должен чётко определять порядок приоритетов, в котором должна реализовываться обработка отдельных рисков. Порядок приоритетов может устанавливаться с использованием различных методов, включая ранжирование рисков и анализ соотношения «затраты — выгода».

Идентификация существующих средств защиты может определять те средства, которые превышают текущую потребность также и с точки зрения сравнения затрат, включая поддержку. Если рассматривается удаление избыточных или ненужных средств защиты (особенно, если расходы на поддержку этих средств контроля велики), должны приниматься во внимание факторы ИБ и стоимости. Поскольку средства защиты оказывают влияние друг на друга, исключение избыточных средств может в итоге снизить эффективность использования всех оставшихся средств защиты.

Варианты обработки риска должны учитывать:

— как риск осознается сторонами, которых он касается;

— наиболее соответствующие пути взаимоотношений с этими сторонами.

После того как определён план обработки риска, необходимо определить остаточные риски. Это включает обновление или повторную операцию оценки риска, принимая во внимание ожидаемый эффект от предполагаемой обработки риска. Если остаточные риски по-прежнему не будут удовлетворять критериям принятия риска организации, может возникнуть необходимость дальнейшего процесса обработки риска, прежде чем перейти к принятию риска.

Выходные данные: План обработки риска и остаточные риски — предмет обсуждения для принятия решения руководством организации.

3.1. Снижение риска

Действие: Уровень риска должен быть снижен выбором таких средств защиты, чтобы остаточный риск был оценён как приемлемый.

Руководство по реализации: Средства управления рисками могут обеспечивать одну или несколько следующих функций: контроль, предупреждение, сдерживание, снижение, исправление, предотвращение.

Во время выбора средств важно «взвешивать» стоимость их приобретения, реализации, функционирования, администрирования, мониторинга и поддержки по отношению к ценности защищаемых активов. Кроме того, рентабельность инвестиций с точки зрения снижения риска, и потенциал для использования новых возможностей бизнеса, предоставляемых определёнными средствами защиты.

Существует много ограничений, которые могут влиять на выбор средств. Технические ограничения, такие как требования к функционированию, вопросы управляемости (требования операционной поддержки) и совместимости могут препятствовать использованию определённых средств защиты или могут вводить ошибку персонала, или аннулирующую средство защиты, вселяя ложное чувство безопасности, или даже увеличивающую риск, по отношению к тому как если бы не имелось никакого средства защиты (например, требования использования сложных паролей без соответствующего обучения, что может привести к записи паролей пользователями).

Более того, может произойти так, что средства защиты будут влиять на производительность. Менеджеры должны работать над идентификацией решения, которое удовлетворяет требованиям производительности, в то же время гарантирует достаточную ИБ. Результатом этого первого шага является перечень возможных средств защиты с их стоимостью, выгодой и приоритетом реализации.

При формировании рекомендаций и реализации средств защиты должны приниматься в расчёт различные ограничения: операционные, эксплуатационные, технические, временные и кадровые, финансовые, юридические, культурные, этические и экологические.

Операционные ограничения

Операционные ограничения, такие как потребность круглосуточной работы, производя при этом резервное копирование, могут приводить к сложной и дорогостоящей реализации средств защиты, если они не встраиваются в проект с самого начала.

Эксплуатационные ограничения

Неудобный интерфейс «человек-машина» будет вызывать ошибки персонала и может приводить к инцидентам. Средства защиты должны выбираться с целью обеспечения оптимальной простоты использования наряду с достижением приемлемого уровня остаточного риска для бизнеса. Применение средств защиты, которые трудно использовать, будет влиять на их эффективность, так как пользователи могут пытаться обходить или игнорировать их, насколько это возможно.

Технические ограничения

Реализация средств защиты для существующих информационных процессов или систем может затрудняться несовместимостью аппаратного или ПО. Новые средства управления могут быть не реализованы при наличии несовместимости с существующими.

Например, план использования биометрии для физического контроля доступа может вступать в конфликт с существующей системой управления доступом, основанной на наборе ПИН-кода. Стоимость перехода на новые средств защиты должна включать элементы, которые будут добавляться к общим расходам на обработку риска.

Временные ограничения

Например, средства защиты должны быть реализованы в течение срока предоставления услуг или использования системы или информации. Может быть период времени, который руководители организации считают подходящим для подверженности определённому риску.

Кадровые ограничения

Следует учитывать затраты на оплату совокупности специальных навыков для реализации и управления средствами защиты, а также возможность перемещения персонала на разные площадки при неблагоприятных рабочих условиях. Другие аспекты, такие как дискриминация одними членами персонала других, не проходивших проверку мастерства и благонадёжности, могут иметь важные следствия для политик безопасности и практических приёмов обеспечения безопасности. Требование проведения такой проверки до оформления найма представляет собой нормальную и наиболее безопасную практику.

Финансовые ограничения

Должны прилагаться все усилия, чтобы не превысить установленный бюджет и достичь финансовой выгоды благодаря использованию средств защиты. Однако в некоторых случаях может не быть возможности достичь желаемой безопасности и уровня принятия риска из-за бюджетных ограничений.

Юридические ограничения

Обеспечение соответствия действующему законодательству может предписывать определённые виды средств защиты, включая обеспечение защиты персональных данных и финансовый аудит, но может также не допускать использования других средств, например, шифрования.

Культурные ограничения

Не все средства защиты могут применяться во всех странах. Например, возможно реализовать досмотр сумок в странах Европы, но не в странах Ближнего Востока. Культурные ограничения нельзя игнорировать, потому что многие средства контроля зависят от активной поддержки персонала.

Этические ограничения

Этические ограничения могут препятствовать реализации таких средств защиты, как сканирование сообщений электронной почты персонала или видеонаблюдение за ним. Секретность информации может также меняться в зависимости от этических принципов региона или правления. Они могут больше касаться одних секторов индустрии, но не касаться других, например, правительства и здравоохранения.

Экологические ограничения

Факторы окружающей среды, такие как климатические условия, окружающая природная и городская география, могут влиять на выбор средств защиты. Например, обеспечение сейсмостойкости может быть необходимым в некоторых странах, но ненужным в других.

3.2. Сохранение риска

Если уровень риска соответствует критериям принятия риска, то нет необходимости реализовывать дополнительные средства контроля и риск может быть сохранен.

3.3. Предотвращение риска

Когда идентифицированные риски считаются слишком высокими или расходы на реализацию других вариантов обработки риска превышают выгоду, может быть принято решение об отказе от деятельности или изменении условий, при которых проводится эта деятельность.

Например, в отношении рисков, вызываемых стихийными бедствиями, наиболее выгодной альтернативой может быть физическое перемещение средств обработки информации туда, где этот риск не существует.

3.4. Перенос риска

Перенос риска — это передача риска сторонней организации, которая может наиболее эффективно управлять им. Перенос риска может создавать новые риски или модифицировать существующие, поэтому может быть необходима дополнительная обработка риска.

Перенос может быть осуществлён с помощью страхования, которое будет поддерживать последствия, или заключения договора с внешней организацией для проведения мониторинга системы и предотвращения угрозы, прежде чем она приведёт к ущербу.

4. Принятие риска ИБ

Входные данные: План обработки риска и оценка остаточного риска являются объектами решения руководства организации о принятии риска.

Действие: Должно быть принято и формально зарегистрировано решение о принятии рисков и ответственности за это решение.

Руководство по реализации: После обработки риска необходимо определить остаточные риски и осуществить принятие риска. Если остаточные риски удовлетворяют критериям принятия риска организации, руководство принимает решение о принятии риска.

Если остаточные риски не удовлетворяют критериям принятия риска организации, возможны следующие варианты решения руководства:

— дальнейшая обработка риска до снижения его уровня до приемлемого;

— принятие риска с обязательным обоснованием такого решения.

Выходные данные: Перечень принятых рисков с обоснованием тех рисков, которые не соответствуют критериям принятия риска.

5. Обмен информацией о рисках

Входные данные: Вся информация о рисках, полученная в результате управления рисками.

Действие: Принимающие решение представители организации и внешних организаций должны обмениваться информацией о рисках и совместно ее использовать.

Руководство по реализации: Обмен информацией о рисках представляет собой деятельность, связанную с достижением соглашения всех участвующих сторон о том, как осуществлять совместное управление рисками путём использования всей известной информации о рисках.

Обмен информацией будет обеспечивать уверенность в том, что все участвующие стороны понимают, на основании чего принимаются решения и причины необходимости определённых действий. Необходимо обеспечить, чтобы осознание риска всеми сторонами, а также осознание ими выгод могло быть идентифицировано и задокументировано, а лежащие в основе причины были чётко поняты и учтены.

Обмен информацией должен осуществляться с целью достижения:

— обеспечения доверия к результатам управления рисками;

— сбора информации о рисках;

— совместного использования результатов оценки рисков и представления плана их обработки;

— предотвращения или снижения вероятности возникновения и последствий нарушений ИБ из-за отсутствия взаимопонимания между сторонами;

— поддержки принятия решений;

— получения новых знаний об ИБ;

— координации действий по реагированию для уменьшения последствий какого-либо инцидента;

— выработки чувства ответственности сторон по отношению к рискам;

— повышения осведомлённости.

Координация сторон может быть достигнута посредством формирования соответствующих коллегиальных органов (комитетов), на заседании которых могут проходить обсуждения вопросов о рисках и выработке решений по обработке и принятию рисков.

Выходные данные: Постоянное понимание и координация процесса управления рисками ИБ.

6. Мониторинг и улучшение

Цель мониторинга рисков состоит в наблюдении за прогрессом выполнения принятых планов (предотвращения рисков и смягчения их последствий), количественными параметрами, условиями, определяющими применение плана обработки рисков, и в информировании ответственных лиц в случае наступления риска.

Мониторинг рисков — процесс отслеживания идентифицированных рисков, мониторинга остаточных рисков, идентификации новых рисков, исполнения плана обработки рисков и оценки его эффективности. Непрерывный мониторинг может поддерживаться внешними сервисами, которые обеспечивают информацию о новых угрозах или уязвимостях.

Необходимо проводить непрерывный мониторинг следующих факторов:

— новые активы, которые были включены в сферу действия управления рисками;

— изменение ценности активов, например, вследствие изменившихся бизнес-требований;

— новых угроз, которые могут быть активными вне и внутри организации, и которые ещё не оценивались;

— вероятности того, что новые или увеличившиеся уязвимости могут позволить угрозам их использовать;

— идентифицированные уязвимости для определения тех уязвимостей, которые становятся подверженными новым или повторно возникающим угрозам;

— повышенное влияние последствий оценённых угроз, уязвимостей и рисков, объединение которых имеет результатом неприемлемый уровень риска;

— инциденты ИБ.

Мониторинг рисков важен для эффективной реализации действий, запланированных на предыдущих этапах. Он обеспечивает своевременное исполнение превентивных мер и планов по смягчению последствий и выполняется с помощью признаков, указывающих на возможность то, что события риска произошли или произойдут в ближайшее время.

Примеры параметров, к которым могут быть привязаны признаки рисков и за которыми может проводиться мониторинг:

— количество «открытых» (найденных и неисправленных) ошибок системы;

— среднее за неделю количество сверхурочных часов работы на одного сотрудника;

— еженедельное количество изменений в требованиях к разрабатываемой системе;

— изменения бизнес-процессов;

— своевременность выделения требуемых ресурсов;

— техническое обеспечение работ.

Мониторинг и улучшение рисков является последним этапом управления рисками и включет следующие мероприятия:

— мониторинг и пересмотр рисков;

— анализ и улучшение управления рисками.

6.1. Пересмотр рисков

Входные данные: Вся информация о рисках, полученная в результате управления рисками.

Действие: Риски и их факторы (ценность активов, угрозы, уязвимости, вероятность риска) должны подвергаться мониторингу и пересмотру с целью идентификации любых изменений на ранней стадии.

Руководство по реализации: Пересмотр рисков должен проводиться регулярно, согласно расписанию, составленному на этапе планирования. В процессе мониторинга рисков может возникать необходимость в проведении идентификации новых рисков, пересмотре состояния известных рисков и планировании дополнительных мероприятий по обработке рисков.

Выходные данные: Непрерывное согласование управления рисками с бизнес-целями и критериями принятия риска.

6.2. Анализ и улучшение

Входные данные: Вся информация о рисках, полученная в результате управления рисками.

Действие: Процесс управления рисками должен постоянно подвергаться анализу и улучшению.

Руководство по реализации: Постоянный анализ необходим для обеспечения уверенности в том, что результаты оценки и обработки рисков, а также план обработки рисками соответствуют реальным обстоятельствам. Необходимо регулярно проверять, что критерии измерения риска и его элементов по-прежнему остаются действительными и согласующимися с бизнес-целями, стратегиями и политиками ИБ.

Эта деятельность должна уделять внимание:

— правовой сфере и условиям окружающей среды;

— сфере конкуренции;

— подходу к оценке риска;

— ценности и категориям активов;

— критериям влияния на активы и процессы;

— критериям оценки риска;

— критериям принятия риска;

— полной стоимости эксплуатации активов;

— необходимым ресурсам.

Организация должна обеспечивать уверенность в том, что ресурсы оценки и обработки рисков постоянно доступны для пересмотра рисков, рассмотрения новых или изменившихся угроз и уязвимостей и соответствующего уведомления руководства.

Анализ должен обеспечить изменение или улучшение подхода, методологии или инструментальных средств, используемых в зависимости от:

— идентифицированных изменений;

— итерации оценки риска;

— цели процесса управления рисками (например, непрерывность бизнеса, устойчивость к инцидентам, совместимость);

— объекта процесса управления рисками (например, организация, бизнес-подразделение, информация, приложение, подключение к Интернет).

Выходные данные

Непрерывная значимость процесса управления рисками ИБ для бизнес-целей организации.

6. Управление инцидентами иб

(стандарт ISO/IEC 27035:2011)

В 2004 году Британским институтом стандартов был опубликован стандарт ISO/IEC TR 18044 «ИТ. Методы защиты. Управление инцидентами ИБ». В дальнейшем на его базе подкомитетом SC 27 «Методы защиты» совместного технического комитета ISO/IEC JTC 1 «Информационная технология» был разработан международный стандарт ISO/IEC 27035 «ИТ. Методы защиты. Управление инцидентами ИБ», который был опубликован в 2011 году.

Основные понятия

Событие ИБ — это определенное состояние ИС (услуги или сети), указывающее на возможное нарушение ИБ, отказ защитных мер, а также неизвестная ситуация, связанная с ИБ.

Инцидент ИБ — нежелательное событие, которое может нарушить бизнес-процесс и угрожать ИБ.

Возникновение события ИБ не обязательно означает, что попытка была успешна или что оказано какое-либо влияние на конфиденциальность, целостность и/или доступность, т. е. не все события ИБ классифицируются как инциденты ИБ.

Инциденты ИБ могут быть преднамеренными (например, вредоносное ПО или злоумышленные действия) или случайными (например, человеческие ошибки или стихийные бедствия), а также создаваться техническими или физическими средствами. Их последствиями могут быть несанкционированное разглашение, модификация, уничтожение или недоступность информации, или повреждение или воровство активов, содержащих информацию.

Угроза путем использования уязвимости ИС (сервисов или сетей) вызывает возникновение события ИБ и как результат инцидента по отношению к активу (подставленного под угрозу этой уязвимостью).

Рисунок показывает эти отношения объектов в цепи инцидента ИБ. Затемненные объекты существуют изначально и воздействуют на остальные объекты в цепи, которая приводит к инциденту ИБ.

Цели управления инцидентами

Ключевой частью стратегии ИБ организации должны стать процедуры, которые будут обеспечивать структурный плановый подход к управлению инцидентами ИБ. В принципе главная цель — это предотвращение или снижение воздействия инцидентов ИБ, чтобы сократить вызванные ими прямые и косвенные затраты.

Для минимизации воздействия инцидентов ИБ необходимо по отношению к ним сделать следующие первоначальные шаги:

— остановить и задержать,

— уничтожить,

— анализировать и оповестить, и

— последующие шаги.

Цели структурного планового подхода к управлению инцидентами ИБ должны гарантировать следующее:

— события ИБ обнаружены и эффективно анализируются, в частности, определяется, нужно ли их классифицировать как инциденты ИБ или нет;

— идентифицированные инциденты ИБ были оценены и подвергнуты реагированию в самой соответствующей и эффективной форме;

— негативные последствия инцидентов ИБ на организации и ее бизнес-процессах минимизируют соответствующие средства защиты как часть реагирования на инциденты, возможно в соединении с соответствующими элементами плана кризисного управления;

— известные уязвимости ИБ оценены и обработаны соответствующим образом;

— быстро извлечены уроки из инцидентов, уязвимостей ИБ и соответствующего управления. Это должно увеличить возможности предотвращения появления будущих инцидентов ИБ, улучшить внедрение и использование мер защиты и всю схему управления инцидентами ИБ.

Чтобы достичь этого, организация должна гарантировать, что инциденты документируются в соответствии со стандартами категоризации и классификации инцидентов ИБ и разделяются в соответствии с метриками, выведенными из совокупности данных на протяжении определенного времени. Это дает ценную информацию, чтобы помочь стратегическому процессу принятия решения, инвестируя в меры и средства ИБ.

Выгоды от структурного подхода

Первоначальные действия организации с учетом структурного подхода к управлению инцидентами ИБ, могут группироваться следующим образом:

— обеспечение осведомленности в вопросах ИБ;

— сокращение негативного влияния на бизнес;

— оправдание расхода бюджета и ресурсов;

— усиление внимания к предотвращению инцидентов ИБ;

В дальнейшем выполняются корректирующие действия, которые могут группироваться следующим образом:

— усиление приоритетности;

— усиление правовой экспертизы;

— улучшение состояния ИБ;

— улучшение управления рисками ИБ;

— обеспечение вклада в политику ИБ.

Обеспечение осведомленности в вопросах ИБ

Структурный подход к управлению инцидентами ИБ предоставляет узконаправленную информацию о программах обеспечения осведомленности в вопросах ИБ. Эта информация является источником реальных примеров, на которых можно показать, что инциденты ИБ действительно происходят именно в данной организации, а не где-либо еще. Таким образом, можно продемонстрировать выгоды быстрого получения информации о решениях. Более того, подобная осведомленность в вопросах ИБ позволяет снизить вероятность ошибки, возникновения паники и (или) растерянности у людей в случае появления инцидента ИБ.

Сокращение неблагоприятного воздействия на бизнес

Структурный подход к управлению инцидентами ИБ может способствовать снижению уровня негативных воздействий, связанных с инцидентами ИБ, на бизнес. Последствия этих воздействий могут включать в себя немедленные финансовые убытки, а также долговременные потери, возникающие от ущерба, нанесенного репутации и кредитоспособности организации.

Оправдание расхода бюджета и ресурсов

Хорошо продуманный структурный подход к управлению инцидентами ИБ способствует обоснованию и упрощению распределения бюджетов и ресурсов внутри подразделений организации. Кроме того, выгоды получает и сама система управлению инцидентами ИБ. Такие выгоды связаны со следующими условиями;

— использование менее квалифицированного персонала для идентификации и фильтрации ложных сигналов тревоги;

— обеспечение лучшего руководства действиями квалифицированного персонала;

— привлечение квалифицированного персонала только для тех процессов, где требуются его навыки, и только на той стадии процесса, где его содействие необходимо.

Кроме того, структурный подход к управлению инцидентами ИБ может включать в себя процедуру приостановки «отметки времени» с целью возможности выполнения «количественных» оценок обработки инцидентов ИБ в организации. Это делает возможным, например, предоставление информации о времени разрешения инцидентов с различными приоритетами на различных платформах.

Усиление внимания к предотвращению инцидентов ИБ

Использование структурного подхода к управлению инцидентами ИБ может способствовать усилению внимания к предотвращению инцидентов внутри организации, в том числе проведению идентификации методов против новых угроз и уязвимостей. Анализ данных, связанных с инцидентами, позволяет определить модели и тенденции появлении инцидентов, тем самым способствуя усилению внимания к предотвращению инцидентов и, следовательно, определению соответствующих действий по предотвращению возникновения инцидентов.

Усиление приоритетности

Структурный подход к управлению инцидентами ИБ создает прочную основу для системы установления приоритетов при проведении расследований инцидентов ИБ, в том числе использование эффективной шкалы категоризации и классификации. При отсутствии четких процедур существует риск того, что расследования проводятся в непостоянном режиме, когда реагирование не инциденты осуществляется по мере их появления или как реакция на указание руководства. Это может помешать проведению расследования в последовательности, соответствующей идеальному установлению приоритетов там, где оно действительно необходимо.

Усиление правовой экспертизы

Четкие процедуры расследования инцидентов могут обеспечить правильность и правовую допустимость сбора доказательств и их обработки. Это имеет большое значение в случаях инициирования дальнейшего дисциплинарного или судебного разбирательства.

Улучшение состояния ИБ

Структурный процесс обнаружения и оповещения, оценки и принятия решения, связанного с событиями и инцидентами ИБ, обеспечит быструю идентификацию и реагирование. Это улучшит общую безопасность, обеспечивая средство предотвращения подобных инцидентов ИБ в будущем. В дальнейшем осуществляется классификация инцидентов ИБ в соответствии с разработанными метриками и их накопление. Это способствует доверию к организации, которая может продемонстрировать применение лучших практик по управлению инцидентами ИБ.

Улучшение результатов оценки и управления рисками ИБ

Использование структурного подхода к управлению инцидентами ИБ способствует:

— сбору более качественных данных для идентификации и определения характеристик различных типов угроз и связанных с ними уязвимостей;

— предоставлению данных о частоте возникновения идентифицированных типов угроз.

Полученные данные о негативных последствиях инцидентов ИБ для бизнеса будут полезны для анализа этих последствий. Данные о частоте возникновения различных типов угроз намного повысят качество оценки угроз. Аналогично, данные об уязвимостях намного повысят качество будущих оценок уязвимостей.

Обеспечение вклада в политику ИБ

Информация, предоставляемая схемой управления инцидентами ИБ, может обеспечить ценные входные данные для анализа результативности и последующего улучшения политик ИБ (и другой документации, связанной с ИБ). Это относится к политикам и другой документации как на уровне организации, так и для отдельных систем, сервисов и сетей.

Фазы управления инцидентами

Управление инцидентами ИБ состоит из 5 фаз:

1) планирование и подготовка;

2) обнаружение и оповещение;

3) оценка и принятие решения;

4) реагирования;

5) извлечение уроков.

Первая фаза включает предварительные действия по разработке и внедрению схемы управления инцидентами ИБ, а другие четыре фазы — оперативные действия по ее реализации и совершенствованию. Последовательность и краткое содержание этих фаз показано на рисунке.

1 фаза — планирование и подготовка

Эффективное управление инцидентами ИБ требует соответствующего планирования и подготовки. Для реализации эффективной схемы управления инцидентами и уязвимостями организация должна провести ряд предварительной действий после необходимого планирования.

Фаза подготовки включает в себя следующие первоначальные мероприятия:

— разработка политики управления инцидентами ИБ и утверждение ее руководством;

— интеграция управления инцидентами ИБ во все политики;

— разработка схемы управления инцидентами ИБ;

— тестирование схемы управления инцидентами ИБ, ее процессов и процедур.

Также фаза подготовки включает в себя следующие организационные мероприятия:

— создание группы реагирования на инциденты ИБ (далее — ГРИИБ);

— создание технической и другой поддержки (включая организационную и операционную);

— взаимодействие с внутренними и внешними организациями;

— обеспечение осведомленности и обучения персонала.

1.1. Разработка политики управления инцидентами ИБ и утверждение ее руководством

Организация должна оформить свою политику управления событиями, инцидентами и уязвимостями в виде свободно распространяемого документа как часть политики СУИБ (см. ISO/IEC 27001) или как часть политики ИБ (см. ISO/IEC 27002). Размер, структура, вид бизнеса организации и сфера ее программы управления инцидентами ИБ являются решающими факторами для определения, какие из этих факторов применить. Организация должна охватить политикой управления инцидентами ИБ каждого, кто имеет доступ к информационным системам и местам их размещения.

Этому должно предшествовать выявление уязвимостей ИБ организации, убеждение в необходимости управления инцидентами ИБ и осознание всех выгод от этого организации в целом и ее подразделений в отдельности.

Организация должна обеспечить документальное утверждение политики управления инцидентами ИБ высшим руководством. Политика должна быть доступна для каждого сотрудника и подрядчика и доведена путем инструктажа и обучения.

Политика управления инцидентами ИБ должна включать в себя следующие вопросы:

1) важность управления инцидентами ИБ для организации и утверждение высшим руководством этого управления и его схемы;

2) общее представление об обнаружении события ИБ, оповещении о нем и сборе соответствующей информации и ее использования для определения инцидентов ИБ. Это общее представление должно содержать перечень возможных событий ИБ, а также информацию о том, как сообщать о ней, что, где и кому сообщать и как обращаться с новыми событиями ИБ;

3) общее представление об оценке инцидентов ИБ, включая перечень ответственных лиц, оповещения об инцидентах и дальнейших действий ответственных лиц;

4) краткое изложение действий после подтверждения того, что событие ИБ является инцидентом ИБ;

5) ссылку на необходимость правильной регистрации всех действий по управлению инцидентами ИБ для дальнейшего анализа и непрерывного мониторинга для обеспечения безопасного хранения электронных свидетельств на случай их востребования для судебного разбирательства или внутреннего дисциплинарного расследования;

6) действия, следующие за разрешением инцидента ИБ, включая извлечение урока из инцидента и улучшение процесса, следующего за инцидентом ИБ;

7) общее представление об оповещении и обработке уязвимостей ИБ;

8) подробности места хранения документации схемы, включая процедуры хранения;

9) общее представление о деятельности ГРИИБ, включающее следующие вопросы:

— организационную структуру ГРИИБ и весь основной ее персонал, включая лиц, ответственных за:

• информирование высшего руководства об инцидентах,

• работу с запросами и следующие за этим действия, и

• связь со сторонними организациями (при необходимости);

— положение об управлении ИБ, конкретизирующее полномочия ГРИИБ, в рамках которых она будет его осуществлять. Это положение должно включать в себя, как минимум, формулировку целевого назначения, определение области деятельности ГРИИБ и подробности об учредителе ГРИИБ и его полномочиях;

— формулировку целей ГРИИБ применительно к основной ее деятельности. Для выполнения своих функций персонал должен участвовать в оценке, реагировании и управлении инцидентами ИБ для их успешного разрешения. Цели и предназначение ГРИИБ очень важны и требуют четкого и однозначного определения;

— определение сферы деятельности ГРИИБ. Обычно в сферу деятельности ГРИИБ организации входят все ИС, сервисы и сети организации. В некоторых случаях для организации может потребоваться сужение сферы действия ГРИИБ. При этом необходимо четко документировать, что входит и что не входит в сферу ее деятельности;

— идентификация учредителя ГРИИБ — старшего должностного лица, который санкционирует действия ГРИИБ и устанавливает уровни ее полномочий. Осведомленность об этом поможет всему персоналу организации понять предпосылки создания и структуру ГРИИБ, что является важной информацией для формирования доверия к ней;

— взаимосвязи с организациями, обеспечивающими специализированную внешнюю поддержку, как например, группы правовой экспертизы;

9) общее представление о техническом и других механизмах поддержки;

10) общее представление о программе обеспечения осведомленности и обучения управлению инцидентами ИБ;

11) перечень правовых и нормативных аспектов, предполагаемых к рассмотрению.

1.2. Интеграция управления инцидентами ИБ во все политики

Организация должна включить содержание управления инцидентами ИБ в содержание политики ИБ и политики управления рисками и описать это содержание в политике управления инцидентами. Интеграцию всех политик необходимо осуществить как на корпоративном уровне, так и на системном, сервисном и сетевом уровнях.

Интеграция всех политик ИБ должна быть нацелена на следующее:

— описание важности управления инцидентами ИБ, особенно схемы оповещения и обработки инцидентов ИБ;

— указание ответственности руководства за надлежащую подготовку к инцидентам ИБ и реагирования на них, т. е. схему управления инцидентами ИБ;

— обеспечение согласованности разных политик;

— обеспечение планового, систематического и спокойного реагирования на инцидент ИБ для минимизации его негативного влияния.

Организация должна поддерживать и обновлять корпоративные политики ИБ и управления рисками, а также специальные политики ИБ систем, сервисов или сетей. Эти политики должны иметь четкие ссылки на корпоративную политику управления инцидентами ИБ и соответствующую ему схему.

Политики должна содержать следующие разделы:

— обязательства руководства по отношению к ней;

— описание политики;

— описание схемных процессов и соответствующей инфраструктуры;

— требования по обнаружению, оповещению, оценке и управлению событиями, инцидентами и уязвимостями ИБ;

— четкое определение персонала, ответственного за авторизацию и/или проведение определенных критических действий (например, перевод системы в режим внешней недоступности или даже ее отключение).

Политики должны содержать требование о создании соответствующих механизмов проверки. Эти механизмы должны обеспечить уверенность в том, что информация, полученная в результате обнаружения, мониторинга и разрешения инцидентов ИБ и рассмотрения известных уязвимостей ИБ, используется в качестве входных данных для обеспечения эффективности корпоративных политик ИБ и управления рисками и специальных политик ИБ для систем, сервисов и сетей.

1.3. Разработка схемы управления инцидентами ИБ

Цель схемы управления инцидентами ИБ — обеспечить подробную документацию, описывающую процессы и процедуры обработки событий, инцидентов и уязвимостей ИБ и их взаимодействия. Схема управления инцидентами ИБ приводится в действие при обнаружении события ИБ или сообщении об уязвимости ИБ. В некоторых организациях схема может называться планом реагирования на инцидент ИБ.

Необходимо использовать схему в качестве руководства для выполнения следующих первоначальных действий:

— реагирование на события ИБ;

— определение того, является ли событие ИБ инцидентом;

— управление инцидентами ИБ до их разрешения.

Также необходимо использовать схему в качестве руководства для выполнения следующих завершающих действий:

— реагирование на уязвимости ИБ;

— идентификация полученных уроков и улучшений схемы и/или безопасности в целом;

— реализация идентифицированных улучшений.

Схема управления инцидентами ИБ предназначена для всего персонала организации и задействованных в схеме сторонних организаций, включая лиц, ответственных за:

— обнаружение и оповещение о событиях ИБ (постоянный или контрактный персонал организации и ее компаний);

— оценку и реагирование на события и инциденты ИБ, их разрешение и улучшения ИБ и самой схемы (группа поддержки, ГРИИБ, руководство, пресс-секретари и юристы);

— оповещение об уязвимостях ИБ (постоянный или контрактный персонал организации и ее компаний) и всего связанного с ними.

Следует также учитывать пользователей сторонних организаций, которые сообщают об инцидентах ИБ и связанных с ними уязвимостях. и, кроме того, государственные и коммерческие организации, предоставляющие информацию об инцидентах ИБ и уязвимостях.

Документация схемы управления инцидентами ИБ должна содержать следующую информацию:

— описание политики управления инцидентами ИБ;

— описание схемы управления инцидентами ИБ в целом;

— подробные действия, процедуры и данные всех фаз управления инцидентами.

Схема должна содержать определенную информацию каждой фазы

Для 1-й фазы — планирование и подготовка:

— стандартизированный подход к категоризации и классификации инцидентов/событий ИБ для обеспечения единого подхода. Во всяком случае решение должно быть основано на фактических или планируемых неблагоприятных воздействиях на бизнес-операции организации и соответствующих директивах;

— стандартизированные форматы базы данных уязвимости / инцидента / события ИБ для обмена информацией, который обеспечивает возможность совместного использования сравнительных результатов сообщений/тревог, улучшает аварийную информацию и допускает более точное представление об угрозах и уязвимостях информационных систем;

— директивы для решения, требуется ли антикризисная деятельность в течение каждого процесса, и для кого и каких процедур. На основании директив по обеспечению документации схемы управления инцидентами ИБ кто-либо, оценивая событие, инцидент или уязвимость ИБ должен знать, в каких обстоятельствах необходимо расширить вопросы, и для кого их нужно расширить. Кроме того, есть непредвиденные обстоятельства, когда это может быть необходимо. Например, незначительный инцидент ИБ смог разростись до серьезного, или кризисная ситуация не была разрешена должным образом, или незначительный инцидент ИБ в течение недели смог стать главным инцидентом ИБ. Директивы должны определить типы событий и инцидентов ИБ, типы антикризисной деятельности и кто может ее инициировать;

— процедуры, которые гарантируют, что все действия по управлению инцидентами ИБ должным образом зафиксированы, и что лог-анализ проводит уполномоченный персонал;

— процедуры и механизмы, которые гарантируют, что режим изменений контроля поддерживается, обеспечивая мониторинг событий, инцидентов и уязвимостей ИБ и обновление отчетов о событиях / инцидентах / уязвимостях ИБ, а также обновление непосредственно схемы;

— процедуры правового анализа инцидента ИБ;

— процедуры и директивы по использованию систем обнаружения вторжения (Intrusion Detection System, IDS) и предотвращения вторжения (Intrusion Prevention System, IРS), которые гарантируют обеспечение связанных с ними правовых и нормативных аспектов. Директивы должны включать перечень преимуществ и недостатков обеспечения контроля вторжений;

— директивы и процедуры взаимосвязаны с техническими и организационными механизмами, которые установлены, внедрены и задействованы для того, чтобы предотвращать возникновение инцидента ИБ и сокращать их вероятность, и обрабатывать инциденты ИБ по мере их возникновения;

— материал для осведомленности и программы обучения по вопросам управления событиями, инцидентами и уязвимостями ИБ;

— процедуры и спецификации для тестирования схемы управления инцидентами ИБ;

— схема организационной структуры управления инцидентами ИБ;

— сферы полномочий и ответственности ГРИИБ в целом и ее членов в отдельности;

— важная контактная информация.

Для 2-й фазы — обнаружение и оповещение:

— обнаружение и оповещение о событиях ИБ (человеком или автоматическими средствами),

— сбор информации о событиях ИБ,

— обнаружение и оповещение об уязвимостях ИБ,

— полная запись всей собранной информации в базе данных уязвимости / инцидента / события ИБ.

Для 3-й фазы — оценка и принятие решения:

— проведение группой поддержки оценки события ИБ (включая, если потребуется, его детализацию), используя принятую шкалу классификации событий / инцидентов ИБ с определением возможности его классификации как инцидента ИБ,

— подтверждение ГРИИБ, является ли событие инцидентом ИБ, поэтому им нужно применять другую оценку, используя принятую шкалу классификации событий / инцидентов ИБ, чтобы подтвердить детали события (потенциального инцидента) и его влияния на ресурс (категоризация). Это нужно завершить решением о том, кто, как и с каким приоритетом обработает подтвержденный инцидент ИБ,

— оценка уязвимости ИБ (которая еще не создала события и потенциальный инцидент ИБ) с принятием решения о необходимости ее обработки, кто, как и в том, какой приоритет.

— полная запись всей информации в базе данных уязвимости / инцидента / события ИБ.

Для 4-й фазы — реагирования:

— отчет ГРИИБ для определения, находится ли инцидент ИБ под контролем, и:

• если инцидент под контролем, инициировать реагирование немедленно (в реальном времени) или позже,

• если инцидент не под контролем или возможно серьезное влияние на критические сервисы организации, инициировать кризисные действия вплоть до эскалации антикризисного управления;

— определение всех функций и организаций (внешних и внутренних), необходимых для схемы управления инцидентами;

— локализация и ликвидация инцидента ИБ путем смягчения или предотвращения расширения границ и степени воздействия инцидента;

— оповещение о существовании инцидента ИБ или любых связанных с этим деталей других внутренних и внешних лиц или организаций;

— документальное завершение и внесение записей об успешнм разрешении инцидента ИБ в базу данных уязвимостей / инцидентов / событий ИБ;

— проведение правового анализа, если потребуется;

— проверка правильности регистрации всей деятельности для дальнейшего анализа,

— сбор и сохранность результатов правовой экспертизы;

— поддержка режима контроля изменений и обновлений базы данных уязвимостей / инцидентов / событий ИБ;

— поиск взаимосвязей с уязвимостями ИБ.

В документации схемы управления инцидента ИБ предусматривается возможность как немедленного, так и более длительного реагирования на инциденты ИБ. Для всех инцидентов ИБ требуется своевременная оценка потенциальных негативных воздействий, как кратковременных, так и более длительных (например, крупномасштабное бедствие может произойти через некоторое время после первого инцидента ИБ). Более того, некоторые виды реагирования могут потребоваться для совершенно непредвиденных инцидентов ИБ, когда возникнет необходимость в специальных защитных мерах. Даже для этой ситуации организация должна включить в схемную документацию общее руководство по таким специальным защитным мерам.

Для 5-й фазы — извлечение уроков:

— идентификация уроков обработки инцидентов и уязвимостей ИБ;

— идентификация и внедрение улучшений средств защиты (новых и/или усовершенствованных) как в соответствии с политикой управления инцидентами ИБ, так и в результате полученных уроков;

— идентификация и внедрение улучшений оценки и управления рисками ИБ в результате полученных уроков;

— рассмотрение, насколько эффективны процессы, процедуры, форматы отчетов и/или организационная структура в оценке каждого инцидента ИБ и восстановлении после него и работе с уязвимостью ИБ, и на основании полученных уроков идентификация и внедрение улучшений схемы управления инцидента ИБ и ее документации;

— обновление базы данных уязвимостей / инцидентов / событий ИБ;

— проведение, если потребуется, дальнейшей правовой экспертизы;

— взаимосвязь и обмен результатами обзора с доверенными сторонами (если организация пожелает).

При разработке схемы необходимо учитывать следующие факторы:

— категории и классы инцидентов;

— формы учета инцидентов;

— рабочие процедуры;

— доверие персонала;

— конфиденциальность информации

Категории и классы инцидентов

Категория инцидента / события ИБ зависит от вида угрозы. Инциденты ИБ могут быть вызваны преднамеренными или случайными действиями человека или природными катаклизмами, техническими или физическими средствами.

Шкала классификацииинцидента / события ИБ зависит от степени серьёзности воздействия инцидентов / событий на активы или бизнес-операции организации.

Такая шкала может быть простой и иметь только 2 класса инцидента:

— значительный;

— незначительный.

Шкалу можно сделать более сложной, имеющую 4 класса инцидента:

— класс IV — очень серьёзный;

— класс III — серьёзный;

— класс II — менее серьёзный;

— класс I — несерьёзный.

Очень серьёзные инциденты — те, которые:

— воздействуют на очень важные ИС,

— приводят к катастрофическим бизнес-потерям или

— вызывают огромные социальные проблемы (увольнения).

Серьёзные инциденты — те, которые:

— воздействуют на очень важные или важные ИС,

— приводят к серьезным бизнес-потерям или

— вызывают большие социальные проблемы (забастовки).

Менее серьёзные инциденты — те, которые:

— воздействуют на важные или обычные ИС,

— приводят к значительным бизнес-потерям или

— вызывают значительные социальные проблемы (митинги).

Несерьёзные инциденты — те, которые:

— воздействуют на обычные ИС,

— приводят к незначительным бизнес-потерям или их отсутствию,

— вызывают незначительные социальные проблемы или их не вызывают,

— не требуются никаких действий и нет последствий.

Взимосвязь категорий и классов

Категория и класс серьёзности инцидента ИБ часто взаимосвязаны. Одна категория инцидента ИБ может иметь различные классы серьёзности в зависимости как от бизнеса, так и природы инцидента ИБ, например, мотива, цели, времени, уровня.

Формы отчета об инцидентах

Формы отчета об уязвимости / инциденте / событии ИБ ведутся для:

1) полноты персонального описания события ИБ (не членом группы управления инцидентами ИБ), которое вносится в базу данных уязвимости / инцидента / события ИБ;

2) использования персоналом управления инцидентами ИБ для изначального оповещения о событии ИБ и дальнейших записей по оценке инцидента и т. п. до тех пор, пока инцидент не будет разрешен.

В базе данных уязвимости / инцидента / события ИБ записывается каждая стадия обновления. Полнота записи в базе данных уязвимости / инцидента / события ИБ затем облегчает деятельность по разрешению инцидента;

3) полноты персонального описания уязвимости ИБ (которая еще не вызвала события ИБ и потенциальный инцидент ИБ), которое вносится в базу данных уязвимости / инцидента / события ИБ.

Рекомендуется использовать международные стандартизированые форматы для электронного обмена и ввода данных об инциденте, интегрированные в электронну базу данных уязвимости / инцидента / события ИБ. В современном мире черчение схемы на бумаге занимает много времени. Однако нарисованная на бумаге схема может понадобиться в случае, когда невозможно использовать ее электронный вариант.

Процедуры

Перед тем, как приступить к работе с схемой управления инцидентами ИБ, необходимо иметь в наличии документированные и проверенные процедуры. В документации по каждой процедуре должны указываться лица из группы поддержки и/или ГРИИБ, ответственные за использование и управление этой процедуры. Такие процедуры должны обеспечить сбор и безопасное хранение электронных доказательств, что должно непрерывно контролироваться на случай судебного разбирательства или внутреннего дисциплинарного расследования.

Более того, должны существовать документированные процедуры, включающие в себя не только действия группы поддержки и ГРИИБ, но и процедуры, задействованные в правовой экспертизе и кризисных действиях, если они не задействованы где-либо еще, например, в плане обеспечения непрерывности бизнеса. Очевидно, что эти документированные процедуры должны полностью соответствовать документированной политике управления инцидентами ИБ и другой документации схемы управления инцидентами ИБ.

Необходимо иметь в виду, что не все процедуры являются общедоступными. Например, нежелательно, чтобы весь персонал организации знал подробности о работе ГРИИБ при взаимодействии с ней. ГРИИБ должна обеспечивать наличие общедоступного руководства, включая информацию, полученную из результатов анализа инцидентов ИБ, которая находится в легкодоступной форме, например во внутренней сети организации.

Более того, иногда нежелательно раскрывать некоторые детали схемы управления инцидентами ИБ, чтобы сотрудник организации не мог помешать процессу расследования. Например, если банковский служащий, присваивающий денежные средства, осведомлен о некоторых деталях схемы, то он может лучше скрывать свою деятельность от следствия или иным образом препятствовать обнаружению и расследованию инцидента ИБ и восстановлению после него.

Содержание оперативных процедур зависит от многих критериев, особенно связанных с характером уже известных потенциальных событий и инцидентов ИБ и типами задействованных активов ИС и их средой. Так, некая оперативная процедура может быть связана с определенным типом инцидентов или с типом продукции (например, межсетевые экраны, базы данных, ОС, приложения), или со специфической продукцией. В каждой оперативной процедуре должно быть четко определено, какие шаги необходимо предпринять и кем. Она должна отражать опыт, полученный как из внутренних, так и внешних источников (например государственные и коммерческие ГРИИБ, или аналогичные группы, а также поставщики).

Для обработки уже известных типов событий и инцидентов ИБ должны существовать оперативные процедуры. Необходимы также оперативные процедуры, которым надо следовать, если тип обнаруженного инцидента ИБ или события неизвестен.

В этом случае рассматривают следующие аспекты:

— процесс оповещения для обработки таких исключительных случаев;

— указания, определяющие время для получения одобрения реагирования на инцидент со стороны руководства с целью избежания задержки реагирования;

— предварительно одобренное делегирование принятия решения без обычного процесса одобрения.

Документируемые процедуры и действия необходимо приспособить к использованию форм регистрации, т. е. ассоциировать с определением события, инцидента и уязвимости ИБ, со ссылками на процедуры использования резервных копий данных и системы, сервисов и/или сетей и планов антикризисного управления.

Оперативные процедуры для ГРИИБ с документируемыми процессами и обозначенной ответственностью и распределением ролей соответствующих лиц для выполнения разных видов деятельности (одно лицо может играть более, чем одну роль в зависимости от размера, структуры и вида бизнеса организации) должны включать в себя:

— прекращение работы поврежденной системы, сервиса и/или сети в том случае, если это было заранее согласовано с управлением информационными технологиями и/или бизнесом;

— продолжение работы поврежденной системы, сервиса и/или сети (подключенной и действующей);

— мониторинг данных, получаемых на входе и выходе поврежденной системы, сервиса и/или сети;

— активацию процедур резервирования и кризисного управления и действий согласно политики ИБ (системы, сервиса и/или сети);

— безопасное хранение электронных доказательств для дальнейшего судебного разбирательства или дисциплинарного расследования;

— предоставление деталей инцидента ИБ сотрудникам организации и внешним организациям.

Доверие персонала

ГРИИБ играет очень важную роль для полной ИБ организации и требует привлечения всего организационного персонала к поиску, решению и расследованию инцидентов ИБ. Доверие каждого сотрудника, как своей организации, так и сторонних организаций, — это фундаментальное положение для ГРИИБ. Принятие анонимности применительно к сообщениям о уязвимости, событии и инциденте ИБ может быть полезно для формирования доверия.

Организация должна гарантировать, что схема управления инцидентами ИБ учитывает ситуации, когда важно обеспечить анонимность лица или организации, сообщающих о потенциальных инцидентах или уязвимостях ИБ при особых обстоятельствах. У каждой организации должны быть положения, в которых четко разъяснялись бы важность сохранения анонимности или ее отсутствия для лиц и организаций, сообщающих о потенциальном инциденте или уязвимости ИБ. ГРИИБ может потребоваться дополнительная информация, не сообщенная изначально информирующим об инциденте лицом или организацией. Более того, важная информация об инциденте ИБ может быть получена от первого обнаружившего его лица.

Другой подход, который может быть принят ГРИИБ, — выиграть пользовательское доверие, используя понятные и эффективные процессы. ГРИИБ должен работать, чтобы обучить пользователей, объяснить, как работает ГРИИБ, как защищает конфиденциальность собранной информации и как управляет пользовательскими сообщениями о событии, инциденте и уязвимости ИБ.

ГРИИБ должна быть способна эффективно удовлетворять функциональные, финансовые, правовые и политические потребности конкретной организации и быть в состоянии соблюдать осторожность при управлении инцидентами ИБ. Деятельность ГРИИБ должна также подвергаться независимому аудиту с целью проверки эффективности ее функционирования.

Эффективным способом реализации независимости контроля является отделение цепочки сообщений о реагировании на инцидент и уязвимость ИБ от общего оперативного руководства и возложение на старшего менеджера непосредственных обязанностей по управлению реагированием на инциденты и уязвимости. Финансирование работы группы, во избежание чрезмерного влияния на нее со стороны, также должно быть отдельным.

Конфиденциальность информации

Схема управления инцидентами ИБ может содержать конфиденциальную информацию, и лицам, занимающимся инцидентами и уязвимостями, может потребоваться доступ к ней. Поэтому во время обработки необходимо обеспечивать анонимность этой информации, или персонал должен подписать соглашение о конфиденциальности (неразглашении) при получении доступа к ней.

Если уязвимость / инцидент / событие ИБ регистрируют через общую систему управления проблемами, то конфиденциальные подробности, возможно, придется опустить. Кроме того, организация должна гарантировать, что схема управления инцидентами ИБ обеспечивает контроль за передачей сообщений об инцидентах и уязвимостях ИБ сторонними организациями, включая СМИ, партнеров по бизнесу, потребителей, юридические организации и общественность.

1.4. Создание ГРИИБ

Цель создания ГРИИБ — обеспечение организации специальным персоналом для оценки инцидентов ИБ, реагирования на них и извлечения соответствующих уроков, а также необходимой координации, управления, обратной связи и передачи информации. ГРИИБ содействует снижению физического и финансового ущерба, а также ущерба для репутации организации, связанного с инцидентами ИБ.

Состав и количество персонала, а также структура ГРИИБ должны соответствовать масштабу и структуре организации. ГРИИБ может быть штатной или внештатной, или иметь смешанную структуру. Штатная ГРИИБ может иметь и внештатных сотрудников для решения специальных задач (ИКТ, правовая экспертиза, связи с общественностью, аутсорсинг и т. п.), которые тесно сотрудничают с ГРИИБ в период обработки инцидента ИБ.

В зависимости от размера, структуры и природы бизнеса организации, член ГРИИБ может также выполнять более, чем одну роль в пределах ГРИИБ. Внештатная группа может также возглавляться руководителем ГРИИБ, который будет руководить группами специалистов в областях специфических знаний, например, обработка атак вредоносного ПО в зависимости от типа инцидента ИБ.

Члены группы должны быть доступны для контакта так, чтобы их имена и имена лиц, их замещающих, а также подробности о контакте с ними были доступными внутри организации. В документации схемы управления инцидентами ИБ (а не в положениях политики) должны быть четко указаны необходимые детали, включая любые документы по процедурам и формы отчетов.

ГРИИБ может состоять из специальных групп с обозначенными для каждой обязанностями, например:

— планирования;

— мониторинга;

— реагирования;

— анализа и т. п.

Группа планирования отвечает за планы действий ГРИИБ. Она разрабатывает различные политики и планы ИБ, предоставляет их для утверждения вышестоящему руководству, сотрудничает со всеми заинтересованными лицами и организациями, регистрирует и утверждает отчеты об уязвимостях;

Группа мониторинга отвечает в реальном времени за контроль и фактическую операционную деятельность, как например, мониторинг / обнаружение / идентификация событий ИБ, регистрация инцидента и его предотвращение;

Группа реагирования принимает отчет группы контроля о возникновении инцидента, выполняет повторный анализ и действия по расследованию и восстановлению, а также разрабатывает адекватную стратегию;

Группа анализа в сотрудничестве с группой реагирования выполняет углубленный анализ, в том числе сравнительный анализ инцидентов.

Руководитель ГРИИБ обязан:

— немедленно принимать меры для решения инцидента на основании заранее делегированных полномочий;

— иметь отдельную линию для связи с руководством, изолированную от обычных бизнес-коммуникаций;

— обеспечить высокий уровень знаний и мастерства всех членов ГРИИБ, а также постоянную поддержку этого уровня;

— поручать расследование каждого инцидента наиболее компетентному члену ГРИИБ.

Уровень полномочий руководителя ГРИИБ и членов его группы должен позволять предпринимать необходимые действия для решения инцидента ИБ. Однако действия, которые могут оказать неблагоприятное влияние на всю организацию в отношении финансов или репутации, должны согласовываться с высшим руководством. Поэтому важно уточнить, кого в схеме обеспечения политики управления инцидентами ИБ руководитель ГРИИБ оповещает о серьезных инцидентах ИБ.

Взаимодействие с заинтересованными сторонами

Процедуры общения со СМИ и ответственность за это общение также должны быть согласованы с высшим руководством и задокументированы. Эти процедуры должны определить представителя организации по работе со СМИ и его взаимодействие с ГРИИБ.

Организация должна установить взаимодействие ГРИИБ с внешними организациями (заинтересованными сторонами), в число которых входят следующие:

— контрактный персонал внешней поддержки,

— национальная ГРИИБ,

— сервис-провайдеры, в том числе поставщики телекоммуникационных и интернет-услуг,

— службы охраны правопорядка,

— аварийные службы,

— соответствующие правительственные органы,

— юридические службы,

— официальные лица по связям с общественностью и/или представители СМИ,

— бизнес-партнеры,

— потребители,

— общественность.

1.5. Техническая и другая поддержка

Быстрое и эффективное реагирование на инциденты ИБ осуществляется гораздо легче, когда все необходимые технические и другие средства поддержки получены, подготовлены и протестированы.

Мероприятия поддержки включают в себя:

— доступ к деталям активов, которые своевременно обновляются, и их связям с бизнес-функциями;

— доступ к задокументированным процедурам кризисного управления;

— документированные и опубликованные процессы коммуникаций;

— использование базы данных уязвимостей / событий / инцидентов ИБ и технических средств для быстрого пополнения и обновления базы данных, анализа ее информации и упрощения процессов реагирования (иногда сделанные вручную записи также оказываются востребованными и используются организацией);

— использование стандартного формата и протокола обмена для получения и обработки тревоги или информации об уязвимостях / событиях / инцидентах с целью оперативного обеспечения осведомленности персонала и возможности повторного использования;

— средства сбора и анализа правовых доказательств;

— адекватные соглашения кризисного управления для базы данных уязвимостей / событий / инцидентов ИБ.

Технические средства, используемые для быстрого пополнения, обновления баз данных, анализа информации и баз данных и облегчения процессов реагирования на инциденты ИБ, должны поддерживать:

— быстрое получение отчетов о уязвимости / инциденте / событии ИБ;

— уведомление предварительно отобранного внешнего персонала соответствующими средствами (например электронная почта, факс или телефон), то есть запрашивая поддержку надежной доступной базы данных (включая бумажные и другие резервные копии) и средство передачи информации безопасным способом (при необходимости);

— соблюдение мер предосторожности, соответствующих оцененным рискам, для гарантирования, что линия коммуникации или интернет не прослушиваеться и остается доступной во время атаки на систему, сервис и/или сеть (возможно, потребуется предварительное планирование механизмов альтернативной связи);

— соблюдение предосторожностей, соответствующих оцененным рискам, для сохранения доступности электронной связи, реализуемой через Интернет или иным образом, во время атаки на систему, сервис и/или сеть;

— процесс сбора всех данных об ИС, сервисе и/или сети и всех обрабатываемых и сохраненных данных;

— использование криптографического контроля целостности, если это соответствует оцененным рискам, для содействия в определении наличия изменений и того, какие части системы, сервиса и/или сети и данные подверглись изменениям;

— упрощение архивирования и защиты собранной информации (например, применяя ЭЦП к лог-файлам и другие свидетельства перед хранением в автономном режиме на носителях, предназначенных только для чтения на устройствах CD или DVD ROM);

— подготовка распечаток (например, лог-файлов), в том числе, демонстрирующих процессы развития и разрешения инцидента ИБ и системы охраны вещественных доказательств при их передаче;

— восстановление штатного режима работы системы, сервиса и/или сети с помощью процедур, связанных с кризисным управлением:

• тестирование резервных копий,

• защита от вредоносного ПО,

• хранение исходных носителей с системным и прикладным ПО,

• хранение загрузочного носителя системы,

• хранение безопасных патчей для системы и приложений.

Атакованная ИС, сервис и/или сеть могут функционировать неправильно. Поэтому работа технического средства (программного или аппаратного обеспечения), необходимого для реагирования на инцидент ИБ, не должна быть основана на системах, сервисах и/или сетях, используемых в организации.

Все технические средства должны быть тщательно отобраны, правильно внедрены и регулярно тестироваться (включая тестирование полученных резервных копий). По возможности, технические средства реагирования на инциденты должны быть полностью автономными.

Группа поддержки организации обеспечивает поддержку всех аспектов информационных технологий и связанной с ними обработки информации, поэтому играет ключевую роль в управлении инцидентами ИБ. Как только приходит сообщение о событиях ИБ, группа поддержки обрабатывает их в фазе обнаружении и оповещения.

Группа поддержки должна рассмотреть собранную информацию и сделать первичную оценку события ИБ, является ли оно инцидентом. Если событие не является инцидентом, группа поддержки им занимается. Если событие является инцидентом, группа поддержки может им заниматься, однако в большинстве случаев ответственность за работу с инцидентом необходимо передать ГРИИБ.

Группа поддержки на каждом предприятии может быть построена разнообразными способами (имеется в виду реализации процессов поддержки). Существует несколько моделей службы поддержки, например: централизованная, локальная, виртуальная — с единым телефонным центром и т. д. Группа поддержки может быть организована как в целях обслуживания внешних клиентов (аутсорсинг и т. п.), так и внутренних (подразделение ИТ-департамента на крупных предприятиях).

Правильно организованная техподдержка (Help Desk, Service Desk) всегда начинается с регистрации всех обращений конечных пользователей, служит единой точкой для общения пользователя с подразделением ИТ.

На больших предприятиях техподдержка часто организована по двухуровневому принципу:

— пользователь обращается с вопросом в службу поддержки по телефону или с помощью электронной заявки (электронная почта, или специальные сервисы подачи заявок);

— оператор (1-я линия поддержки, Call-center) регистрирует обращение, при возможности помогает пользователю самостоятельно, либо передаёт заявку на 2-ю линию поддержки и контролирует ее выполнение;

— 2-я линия поддержки получает заявки от 1-й линии, работает по ним, при необходимости привлекая к решению проблемы специалистов из других отделов предприятия (системные и сетевые администраторы, поддержка специального ПО и оборудования и т. д.).

Основные механизмы технической поддержки должны быть следующими:

— внутренний аудит ИБ (для оценки уровня безопасности и отслеживаемых уязвимых систем);

— системы обнаружения вторжения;

— устройства мониторинга и защиты сети;

— антивредоносное ПО.

Дополнительные механизмы технической поддержки могут быть следующими:

— технологическое отслеживание новых видов угроз и атак;

— управление уязвимостями (включая безопасное обновление и исправление уязвимых систем);

— логи аудита и ПО их мониторинга.

Эти механизмы должны содержать документированные ответственности и оперативные процедуры действий группы поддержки.

1.6. Осведомленность и обучение персонала

Весь персонал должен пройти обязательное обучение и все виды инструктажей, чтобы быть осведомленным о функционировании схемы управления инцидентами ИБ, ее выгодах и как обнаруживать, анализировать, оценивать события, инциденты и уязвимости ИБ и реагировать на них. Обучение и инструктаж должны повторяться после каждого изменения в составе персонала.

Осведомленность и обучение всего персонала организации очень важны для обеспечения успеха структурного подхода к управлению инцидентами ИБ. Оперативная эффективность и качество структурного подхода к управлению инцидентами ИБ основана на таких факторах, как обязательное сообщение об инциденте, качество сообщения, легкость использования, скорость передачи и тренинги. Организация должна гарантировать, что роль управления инцидентами ИБ должна активно поддерживаться как часть общей программы обучения и обеспечения осведомленности в вопросах ИБ.

Программа обеспечения осведомленности и соответствующий материал должны быть доступны для всего персонала, включая новых служащих, пользователей сторонних организаций и подрядчиков. Должна существовать специальная программа обучения для группы поддержки, членов ГРИИБ, а при необходимости — для персонала, ответственного за ИБ, и специальных администраторов. Каждой группе, непосредственно участвующей в управлении инцидентами, могут потребоваться различные уровни подготовки, зависящие от типа, частоты и значимости их взаимодействия со схемой управления инцидентами ИБ.

Инструктажи по обеспечению осведомленности должны содержать:

— преимущества, полученные в результате структурного подхода к управлению инцидентами ИБ, как организацией, так и ее персоналом;

— основы работы схемы управления инцидентами ИБ, включая сферу ее действия и технологию работ по управлению событиями, инцидентами и уязвимостями ИБ;

— способы оповещения о событиях, инцидентах и уязвимостях ИБ,

— внесение информации об инциденте в базу данных событий, инцидентов и уязвимостей ИБ,

— обеспечение конфиденциальности источников (при необходимости);

— соглашения об уровнях сервиса схемы;

— уведомление о результатах — на каких условиях будут информированы источники;

— любые ограничения, налагаемые соглашениями о неразглашении;

— полномочия организации по управлению инцидентами ИБ и ее линия оповещения;

— кто и как получает сообщения от схемы управления инцидентами ИБ.

В некоторых случаях желательно специально включать подробности обеспечения осведомленности об управлении инцидентами ИБ в другие программы обучения (например, в программы ориентирования персонала или в общие корпоративные программы обеспечения осведомленности в вопросах ИБ). Этот подход к обеспечению осведомленности может предоставить ценную информацию, связанную с определенными группами сотрудников, и может улучшить эффективность и результативность программы обучения.

До ввода в действие схемы управления инцидентами ИБ весь персонал должен быть ознакомлен с процедурами обнаружения и оповещения о событиях ИБ, а специальный персонал — с процедурами последующих процессов.

После ввода схемы в действие необходимо проводить регулярные инструктажи по ИБ для всего персонала и курсы специальной подготовки персонала, ответственного за ИБ. Подготовка должна включать специальные упражнения и тестирование членов группы поддержки и ГРИИБ, а также персонала, ответственного за ИБ.

Кроме того, осведомленность и учебные программы нужно дополнить созданием и поддержкой «горячей линии» персонала управления инцидентами ИБ для того, чтобы минимизировать задержки в сообщении и обработке событий, инцидентов и уязвимостей ИБ.

1.7. Тестирование схемы управления инцидентами ИБ

Организация должна планировать регулярные проверки и тестирование процессов и процедур управления инцидентами ИБ для выявления потенциальных недостатков и проблем, которые могут появиться в течение этого управления.

Испытания должны проводиться периодически, чтобы не только проверить схему в реальной ситуации, но и проверить, как ГРИИБ ведет себя под влиянием сложного инцидента, моделируя реалные атаки, отказы или дефекты. Специфическое внимание нужно уделить созданию сценариев, основаных на реальных угрозах ИБ. Испытания должны включить не только ГРИИБ, но и все подразделения организации и внешние организации, которые задействованы в управлении инцидентами ИБ.

Любые изменения, возникающие в результате анализа реагирований на инциденты ИБ, должны подвергаться строгой проверке и тестированию перед введением измененной схемы в действие.

После завершения этой фазы организация должна быть полностью готова к надлежащей обработке инцидентов ИБ.

2 фаза — обнаружение и оповещение

Оперативный процесс схемы управления инцидентами ИБ состоит из 3-х фаз:

— обнаружение и оповещение;

— оценка и принятие решения;

— реагирования.

Первая фаза оперативного процесса включает обнаружение, сбор сведений и оповещение как о возникновении событий ИБ, так и о существовании уязвимости ИБ, которая еще не вызвала событие ИБ и потенциальный инцидент ИБ.

Любое сообщение персонала как об уязвимости ИБ, так и о нарушении неинформационной безопасности, должно быть оценено и обработано уполномоченным техническим персоналом. Информация об уязвимостях и их устранении должна быть внесена в базу данных событий / инцидентов / уязвимостей ИБ, управляемую ГРИИБ.

Для этой фазы организация должна выполнить следующие действия:

1) обнаружение и оповещение о событии или уязвимости ИБ, что включает в себя:

— предупреждение системы мониторинга безопасности, таких как системы обнаружения и предотвращения атак на приложения (Intrusion Detection System / Intrusion Prevention System, IDS/IPS), «приманки» для хакеров в виде виртуальных ресурсов, например, вэб-сервер (honeypot), имитации открытого порта в системе для введения хакеров в заблуждение (tarpits), антивирусная программа, СУИБ, системы мониторинга и корреляции логов событий и другие,

— предупреждение систем сетевого контроля, таких как брандмауэры, сканеры сетевого трафика, вэб-фильтры и другие,

— предупреждение партнеров, продавцов или групп совместного использования информации об известных и появляющихся векторах атаки,

— результат анализа информации логов устройств, сервисов, хостов и других систем,

— результат деятельности систем технической поддержки (help desk),

— сообщения пользователей,

— уведомления внешних организаций, таких как другие ГРИИБ, Интернет-провайдеры, поставщики телекоммуникационных услуг, аутсорсинговые компании или национальная ГРИИБ;

2) сбор сведений о событии ИБ или уязвимости;

3) регистрация всех действий, результатов и соответствующих решений для дальнейшего анализа группой поддержки;

4) регистрация в системе мониторинга инцидентов.

2.1. Обнаружение события

События ИБ могут быть обнаружены непосредственно лицом или лицами, заметившими что-либо, вызывающее беспокойство и имеющее технический, физический или процедурный характер. Обнаружение может осуществляться, например, датчиками охранно-пожарной сигнализации путем передачи сигналов тревоги в заранее определенные места для осуществления человеком определенных действий.

Технические события ИБ могут обнаруживаться автоматически, например, это могут быть сигналы тревоги, производимые устройствами анализа записей аудита, межсетевыми экранами, системами обнаружения вторжений, антивирусным ПО, в каждом случае стимулируемые заранее установленными параметрами этих устройств.

Возможными источниками обнаружения события ИБ могут быть:

— пользователи,

— линейные менеджеры и руководители службы безопасности,

— клиенты,

— ИС технической поддержки (help desk — поддержка 1-го уровня),

— подразделение ИТ, в том числе Центр сетевых операций и Центр безопасных операций (поддержка 2-го уровня),

— поставщики услуг (в том числе интернет-провайдеры),

— ГРИИБ,

— другие сотрудники и персонал, которые могут обнаружить аномалии в течение их ежедневной работы,

— СМИ (газеты, радио, телевидение и т. п.),

— веб-сайты (публичные веб-сайты ИБ, веб-сайты специалистов по ИБ, веб-сайты служб ИБ и т. п.).

2.2. Оповещение о событии

Вся собранная информация, касающаяся событий или инцидентов ИБ, должна храниться в базе данных событий / инцидентов ИБ, управляемой ГРИИБ. Информация, сообщаемая в течение каждого процесса, должна быть как можно более полной, чтобы обеспечить наиболее прочную базу для оценок и принятия решений, а также для предпринимаемых действий.

Независимо от причины обнаружения события ИБ, лицо, непосредственно обратившее внимание на нечто необычное или оповещенное автоматическими средствами, несет ответственность за инициирование процесса обнаружения и оповещения. Этим лицом может быть любой представитель персонала организации, работающий постоянно или по контракту.

Персонал должен следовать процедурам и использовать форму отчета о событии ИБ, определенную схемой управления инцидентами ИБ, с целью привлечения внимания группы поддержки. Следовательно, важно, чтобы весь персонал был ознакомлен с рекомендациями, относящимися к вопросу оповещения о возможных событиях ИБ, включая формы отчета, имел доступ к ним и знал сотрудников, которых необходимо оповещать о каждом случае появления события ИБ. Необходимо, чтобы весь персонал организации был осведомлен о форме отчета, что способствовало бы его пониманию системы управления инцидентами ИБ.

В форме отчета о событии регистрируется такая первоначальная информация:

— время / дата обнаружения,

— результаты наблюдения,

— контактная информация.

Заполненная форма (бумажная или электронная) должна быть использована персоналом ГРИИБ только при регистрации события (потенциального инцидента) ИБ в системе мониторинга инцидентов. После обработки события форма будет содержать более полную информацию после получения отчетов о расследованном событии ИБ.

Мониторинг событий ИБ (потенциальных инцидентов) должен обеспечиваться, как правило, автоматическими средствами. Использование информационной системы играет существенную роль для того, чтобы заставить персонал следовать установленным процедурам и процессам. Также очень полезно сохранить записи о том, кто сделал, что и когда, детали которых могут указать на ошибки в процессе обработки события ИБ (потенциального инцидента).

Обработка конкретного события ИБ зависит оттого, что оно собой представляет, а также от последствий и воздействий, к которым это событие может привести. Для многих людей принятие решения о способе обработки события выходит за пределы их компетентности. Поэтому сотрудник, информирующий о событии ИБ, должен заполнить форму отчета так, чтобы в ней было как можно больше информации, доступной ему на тот момент, при необходимости поддерживая связь со своим руководителем.

Форму отчета о событии ИБ нужно передать безопасным способом в группу поддержки, а копию — руководителю ГРИИБ. Группа поддержки должна работать, по возможности, круглосуточно (24 ч/7д).

Руководитель ГРИИБ должен назначить одного члена группы или сотрудника, ответственного за все входящие сообщения (по электронной почте, телефону, факсу, другим автоматическим средствам коммуникаций), заполнение формы учета и ведение переговоров. Эта ответственность может еженедельно передаваться от одного члена ГРИИБ другому. Назначенный член ГРИИБ делает оценку и принимает надлежащие меры для оповещения заинтересованых сторон в обработке инцидента ИБ.

Следует подчеркнуть, что при заполнении формы отчета важна не только точность содержания, но и своевременность заполнения. Не следует задерживать предоставление формы учета события ИБ по причине уточнения ее содержания. Если сообщающий сотрудник не уверен в данных какого-либо поля в форме учета, то это поле должно быть помечено, а уточнение — предоставлено позже.

Также следует признать, что некоторые механизмы оповещения (например, электронная почта) сами являются вероятными целями атаки. При наличии или прогнозировании проблем оповещения должны использоваться альтернативные средства связи. Это необходимо, когда возможны атаки на систему и перехваты форм учета несанкционированными лицами. Альтернативными средствами связи могут быть нарочные, телефон, текстовые сообщения. Такие альтернативные средства должны использоваться на ранних стадиях расследования, когда становится очевидным, что событие ИБ будет переведено в категорию инцидента, особенно, если он может считаться значительным.

Следует заметить, что, хотя в большинстве случаев группа поддержки должна сообщать о событии ИБ с целью его дальнейшей обработки ГРИИБ, могут быть случаи, когда событие ИБ может быть обработано немедленно группой поддержки. Чтобы освободить ГРИИБ от двойной нагрузки, целесообразно обучить группу поддержки проводить такую же оценку, какую осуществляет ГРИИБ, и применять стандартные (заранее спланированные) контрмеры для решения инцидента на месте.

Событие ИБ можно быстро распознать как ложную тревогу или успешно решить. В этих случаях форму учета необходимо заполнить и отправить местному руководству, а также ГРИИБ с целью ее регистрации в базе данных уязвимостей / инцидентов / событий ИБ. В этом случае лицо, сообщающее о «закрытии» события ИБ, может предоставить информацию, требуемую для заполнения формы отчета ГРИИБ об инцидентах ИБ. В этом случае такая форма отчета об инциденте ИБ должна быть заполнена и отправлена по инстанции группой поддержки.

3 фаза — оценка и принятие решения

Вторая фаза оперативного использования схемы управления инцидентами ИБ включает оценку информации о событии ИБ и принятие решения о том, является ли оно инцидентом.

В этой фазе организация должна выполнить следующие действия:

1) проведение группой поддержки оценки события ИБ, является оно инцидентом или ложной тревогой, и если это — не ложная тревога, требуются ли дальнейшие действия. При оценке нужно применить согласованную шкалу классификации инцидента / события ИБ (в том числе определение воздействия события на активы / сервисы) и принять решение, нужно ли событие классифицировать как инцидент ИБ.

Определяя воздействие события (возможного инцидента) на ИБ, организация должна идентифицировать следующее:

— область воздействия (физическая или логическая),

— попадающие под влияние активы (информация, процессы, сервисы и приложения),

— возможное влияние на ключевые сервисы;

2) проведение ГРИИБ оценки результатов оценки группы поддержки для подтверждения, является ли событие инцидентом. В случае необходимости, нужно применить другой метод оценки, используя согласованную шкалу классификации инцидента / события ИБ с детализацией события (возможного инцидента) и затронутого ресурса (категоризация). Этот процесс нужно завершить принятием решения, как с подтвержденным инцидентом ИБ нужно обращаться, кому и с какой приоритетностью.

Необходимо использовать заранее определенный процесс распределения приоритетов, чтобы назначить ответственного за каждый инцидент ИБ и определить безотлагательность обработки и реагирования на инцидент ИБ, в том числе, немедленное реагирование, правовой анализ и необходимые взаимосвязи;

3) расширение, при необходимости, сферы принятия решений (эскалация) для дальнейших оценок и/или решений;

4) регистрация всех действий, результатов и соответствующих решений для более позднего анализа;

5) сбор и безопасное хранение электронных доказательств и его мониторинг на случай судебного разбирательства или дисциплинарного расследования;

6) поддержка режима контроля изменений при отслеживании инцидента ИБ и обновлении данных о нем и актуальности базы данных события / инцидента / уязвимости ИБ.

Вся информация, касающаяся события, инцидента или уязвимости ИБ, должна быть внесена в базу данных события / инцидента / уязвимости ИБ, управляемую ГРИИБ. Информация, полученная на протяжении каждого действия, должна быть как можно более полноценной, чтобы гарантировать актуальность базы данных для осуществления необходимых оценок, решений и действий.

После обнаружения и оповещения о событии ИБ дальнейшая деятельность заключается в следующем:

7) распространение ответственности за действия по управлению инцидентами ИБ на всю иерархию персонала по оценке, решению и действиям, включая персонал, не связанный с ИБ;

8) внедерение формальных процедур действий каждого оповещеного лица по пересмотру и исправлению отчета, оценке ущерба и оповещению соответствующего персонала (с индивидуальными действиями в зависимости от типа и серьезности инцидента);

9) применение директив по ведению документации о событии ИБ и последующих действиях для инцидента ИБ, если событие ИБ классифицируется как инцидент;

10) обновление базы данных события / инцидента / уязвимости ИБ.

Эта фаза должна включать оценку информации о выявленных уязвимостях ИБ (которые еще на эксплуатируются и не могут вызвать события и возможные инциденты ИБ) с решениями о том, кто, когда и с какой приоритетностью будет их устранять.

3.1. Оценка и предварительное решение группы поддержки

Принявший отчет о событии ИБ сотрудник группы поддержки должен подтвердить его получение, ввести в базу данных уязвимостей / инцидентов / событий ИБ и проанализировать. Далее должностное лицо должно попытаться получить любые уточнения от сообщившего лица о событии ИБ и собрать требуемую дополнительную информацию, считающуюся общедоступной, как от сообщившего о событии лица, так и из любого другого источника.

Затем представитель группы поддержки должен провести оценку для определения, является ли событие ИБ инцидентом (на основании согласованой в организации шкалы классификации инцидентов). Если событие ИБ определяется как неопасное (ложное), необходимо заполнить форму отчета и передать в ГРИИБ для записи в базу данных уязвимостей / инцидентов / событий ИБ и дальнейшего анализа, а также создать копии для сообщившего о событии лица и его руководителя.

Информация и другие доказательства, собранные на этой стадии, могут потребоваться в будущем для дисциплинарного или судебного разбирательства. Лицо или лица, выполняющие задачи сбора и оценки информации, должны хорошо знать требования по безопасному хранению свидетельств.

Кроме даты и времени выполнения действий необходимо документировать:

— что наблюдалось, делалось (включая использованные средства) и почему;

— место хранения доказательств;

— как доказательства архивировались (если необходимо);

— как выполнялось подтверждение доказательств (если необходимо);

— детали безопасного хранения материалов и последующего доступа к ним.

Если событие ИБ определено как вероятный инцидент ИБ, а сотрудник группы поддержки имеет соответствующий уровень компетентности, то проводится дальнейшая оценка. В результате могут потребоваться корректирующие действия, например идентификация дополнительных аварийных защитных мер и обращение за помощью в их реализации к соответствующему лицу.

Если событие ИБ определено как значительный инцидент (по шкале классификации, принятой в организации), то об этом необходимо немедленно проинформировать руководителя ГРИИБ.

Может потребоваться объявление кризисной ситуации и, как следствие, уведомление менеджера кризисного управления о возможной активизации плана кризисного управления с одновременным информированием руководителя ГРИИБ и вышестоящего руководства. Однако наиболее вероятна ситуация передачи инцидента ИБ непосредственно в ГРИИБ для дальнейшей оценки и выполнения соответствующих действий.

Каким бы ни был следующий шаг, группа поддержки должна заполнить форму отчета максимально подробно. Форма отчета об инциденте ИБ должна содержать следующую информацию о нем:

— общее представление;

— возможная цель;

— возможная причина;

— степень значительности;

— принятые меры.

Потенциальное или фактическое негативное влияние инцидента ИБ на бизнес организации может привести к следующим проблемам:

— несанкционированное разглашение информации,

— несанкционированная модификация информации,

— отрицание информации;

— недоступность информации и/или сервиса,

— уничтожение информации и/или сервиса,

— снижение эффективности сервиса.

В первую очередь необходимо определить, какую категорию последствий будет иметь инцидент ИБ. Для категорий должны использоваться соответствующие рекомендации по категорированию потенциальных или фактических воздействий для внесения их в отчет по инцидентам ИБ.

Примерами категорий последствий могут быть:

— финансовые убытки/прерывание бизнес-операций;

— ущерб коммерческим и экономическим интересам;

— ущерб информации, содержащей персональные данные;

— нарушение правовых и нормативных обязательств;

— сбои операций управления и бизнес-операций;

— утрата престижа организации;

— телесные повреждения или смерть;

— социальные проблемы.

Если инцидент ИБ был разрешен, то отчет должен содержать детали предпринятых мер и полученных уроков (например, меры для предотвращения повторного события или подобных событий). После наиболее подробного, по мере возможности, заполнения форма отчета должна быть представлена в ГРИИБ для ввода в базу данных уязвимостей / инцидентов / событий ИБ и анализа в будущем.

Если время расследования превысило время, ранее определенное политикой управления инцидентами ИБ, то по его истечении должен быть составлен промежуточный отчет.

Важно, чтобы группа поддержки, оценивающая инцидент ИБ, знала требования рекомендаций, содержащихся в документации схемы управления инцидентами ИБ, например:

— когда и кому необходимо направлять материалы об инциденте;

— что при осуществлении всех действий группы поддержки необходимо выполнять процедуры контроля изменений.

3.2. Оценка и подтверждение инцидента ГРИИБ

Оценка и подтверждение решения о том, является ли событие ИБ инцидентом, входит в обязанности ГРИИБ. Принявший отчет об инциденте сотрудник ГРИИБ должен:

— подтвердить его получение (должен быть заполнен группой поддержки максимально подробно);

— ввести его в базу данных события / инцидента / уязвимости ИБ (если этого не сделала группа поддержки, и обновить базу данных, если необходимо);

— собрать дополнительную информацию о событии ИБ (от группы поддержки, заполнившего отчет сотрудника или какого-либо иного источника);

— проанализировать содержание отчета.

Если все еще остается какая-либо неопределенность относительно подлинности инцидента ИБ или полноты полученной информации, то сотрудник ГРИИБ должен провести вторую оценку для определения реальности или ложности инцидента ИБ (используя согласованую в организации шкалу классификации инцидентов). Если инцидент ИБ определен как ложный, необходимо заполнить отчет о событии ИБ, добавить его в базу данных уязвимостей / инцидентов / событий ИБ и передать руководителю ГРИИБ. Копии отчета необходимо передать группе поддержки, лицу, сообщившему о событии, и его/ее местному руководителю.

Необходимо провести сравнительный анализ инцидента ИБ с любым другим инцидентом / событием, переданным в ГРИИБ. Важно проверить, сопоставим ли инцидент с любым другим событием / инцидентом, или это новый инцидент. Взаимосвязь инцидентов также важна в распределении приоритетов усилий ГРИИБ.

Если инцидент ИБ определен как «реальный», то сотрудник ГРИИБ, при необходимости привлекая коллег, должен провести дальнейшую оценку.

Целью дальнейшей оценки инцидента ИБ является подтверждение следующей информации о нем:

— общее представление;

— цель;

— причина;

— степень значительности;

— последствия;

— принятые меры.

Рассматривая потенциальное или фактическое неблагоприятное воздействие инцидента ИБ на бизнес организации, в соответствии с полученными данными необходимо подтвердить, какие последствия этому воздействию соответствуют.

Чтобы облегчить процесс адекватного реагирования на инцидент ИБ, им должен заниматься самый компетеный сотрудник или группа сотрудников в ГРИИБ. В частности, когда одновременно обрабатывается несколько инцидентов ИБ, приоритет зависит от уровня реагирования на инцидент ИБ.

Приоритеты нужно устанавливать в зависимости от степени неблагоприятного воздействия инцидента ИБ на бизнес и затрачиваемых усилий по реагированию на инцидент ИБ. Для инцидентов с одинаковым приоритетом одним из показателей приоритетности является усилие, требуемое для реагирвания на них. Например, перед обработкой инцидента, требующего значительных усилий, сначала обрабатывают инцидент, который легко решается.

4 фаза — реагирования

Третья фаза оперативного использования схемы управления инцидентами ИБ включает реагирования на инциденты ИБ в соответствии с действиями, согласованными в фазе оценки и принятия решения. В зависимости от решения реагирование может быть немедленным в реальном времени или с малой задержкой и желательно с проведением правового анализа.

В этой фазе ГРИИБ выполняет следующие первоначальные действия:

— немедленное реагирование (локализация инцидента);

— оценка контроля инцидента;

— последующее реагирование;

— передача информации об инциденте.

Также ГРИИБ выполняет при необходимости следующие действия:

— кризисные действия;

— правовая экспертиза;

— эскалация (расширение сферы принятия решений);

— документирование и контроль внесения изменений в схему.

Как только любой инцидент ИБ успешно обработан, этот процесс нужно формально завершить и записать информацию в базу данных уязвимости / инцидента / события ИБ. Эта фаза также включает создание отчетов об уязвимости ИБ в соответствии с действиями, определенными в фазе оценки и решения. Как только любая уязвимость детально обработана, она должна быть записана в базу данных уязвимости / инцидента / события ИБ.

4.1. Немедленное реагирование

После подтверждения инцидента ГРИИБ выполняет следующие действия:

— немедленное реагирование,

— регистрация подробностей в форме отчета,

— введение в базу данных,

— уведомление сотрудников о требуемых действиях.

Результатом данных действий может быть принятие аварийных защитных мер (например, отключение атакованной ИС, сервиса и/или сети по предварительному соглашению с соответствующим руководством ИТ-подразделения и/или управления бизнесом) и/или определение дополнительных защитных мер и уведомление сотрудников организации о принятии этих мер.

Если аварийные защитные меры не применены, то нужно определить серьезность инцидента ИБ, используя заранее разработанную в организации шкалу классификации, и если инцидент ИБ достаточно серьезен, то об этом необходимо непосредственно уведомить вышестоящее руководство. Если очевидна необходимость объявления кризисной ситуации, менеджер кризисного управления должен быть оповещен о возможной активизации плана кризисного управления, причем об этом необходимо проинформировать руководителя ГРИИБ и вышестоящее руководство.

Процесс реагирования на инциденты ИБ включает следующие действия:

— ограничение их неблагоприятных влияний,

— улучшение ИБ.

Первоначальной целью схемы управления инцидентами ИБ должна быть минимизация неблагоприятных влияний на бизнес, в то время как идентификация нападающего нужно рассматривать второстепенной целью.

ГРИИБ также является ответственным за возвращение поврежденных устройств в такое безопасное рабочее состояние (при возможности), которое исключит повторное возникновение инцидента, а также за соответствующее обновление базы данных событий / инцидентов / уязвимостей ИБ.

Примерные действия

Первой реакцией на преднамеренную атаку на ИС, сервис и/или сеть может быть ее неотключение от Интернета или другой сети, что даст возможность функционирования критически важных бизнес-приложений и сбора информации о нарушителе при условии, если он не знает, что находится под наблюдением.

1) Однако при принятии такого решения нужно учитывать, что нарушитель может почувствовать, что находится под наблюдением, и предпринять действия, наносящие дальнейший ущерб атакованной ИС, сервису и/или сети и данным, а также разрушить информацию, которая способствует его отслеживанию.

2) Важно, чтобы при принятии соответствующего решения была техническая возможность быстро и надежно изолировать атакованную ИС, сервис и/или сеть. Это даст возможность локализовать инцидент.

Предотвращение повторного возникновения инцидента является более приоритетной задачей. Кроме того, необходимо учитывать то, что нарушитель выявил уязвимость, которую необходимо устранить так быстро, чтобы он не успел нанести значительного ущерба. Это очень важно в том случае, когда нарушитель не является злоумышленником и не хочет нанести ущерба.

Что касается других инцидентов ИБ, кроме преднамеренной атаки, то их источник должен быть идентифицирован. Может потребоваться отключение ИС, сервиса и/или сети или изоляция соответствующим их частей (после получения предварительного согласия руководства подразделения ИТ и/или управления бизнесом) на время внедрения защитных мер. Для этого может потребоваться больше времени, если уязвимость ИС, сервиса и/или сети окажется существенной или критически важной.

Второй реакцией на преднамеренную атаку может быть активация дополнительных методов отслеживания действий нарушителя (например, honeypots — «приманки» для хакеров в виде виртуальных ресурсов). Это действие должно осуществляться на основе процедур, задокументированных в схеме управления инцидентами ИБ.

Информация, которая могла быть повреждена в результате инцидента ИБ, должна быть проверена ГРИИБ по резервным записям на предмет модификации или уничтожения. Может возникнуть необходимость проверки целостности журналов регистрации (логов), поскольку злонамеренный нарушитель может подделать их с целью сокрытия следов проникновения.

Обновление информации об инцидентах

Независимо от последующих действий ГРИИБ должна обновить отчет об инциденте ИБ с максимальной детализацией, добавить его в базу данных событий / инцидентов / уязвимостей ИБ и оповестить об этом руководителя ГРИИБ.

Необходимо обновлять следующую информацию об инциденте:

— что собой представляет;

— как, чем или кем был вызван;

— на что повлиял или мог повлиять;

— как изменялась его серьезность;

— как обрабатывался до сих пор.

Если инцидент ИБ разрешен, то отчет должен содержать подробности предпринятых защитных мер и полученных уроков (например, дополнительные защитные меры, которые следует предпринять для предотвращения повторного события или подобных событий). Обновленный отчет следует добавлять в базу данных событий / инцидентов / уязвимостей ИБ и уведомлять руководителя ГРИИБ и других лиц по их требованию.

ГРИИБ должна обеспечить безопасное хранение информации об инциденте ИБ с целью проведения дальнейшей правовой экспертизы и возможного использования в суде как доказательств.

Для инцидента ИБ, повлившего на ИТ, необходимо выполнить следующие действия.

После первоначального обнаружения инцидента ИБ все непостоянные данные должны быть собраны до момента отключения пораженной системы, сервиса и/или сети. Предназначенная для сбора информация должна содержать сведения о памяти, кэше, регистрах и деталях любых функционирующих процессов.

При этом необходимо:

— в зависимости от характера инцидента ИБ провести полное дублирование свидетельств правовой экспертизы пораженной системы, сервиса и/или сети на случай судебного разбирательства или резервное копирование логов и важных файлов;

— собрать и проанализировать журналы (логи) соседних систем, сервисов и/или сетей, например, маршрутизаторов и межсетевых экранов;

— всю собранную информацию хранить только на неперезаписываемых носителях;

— при выполнении копирования свидетельств правовой экспертизы обеспечить присутствие не менее двух лиц для подтверждения того, что все действия были выполнены согласно действующему законодательству:

— документировать и хранить вместе с исходными носителями спецификации и описания сервисных команд, которые используются для дублирования свидетельств правовой экспертизы.

Дальнейшая деятельность

После определения реальности инцидента ГРИИБ должна выполнить и другие важные действия:

— проведение правовой экспертизы;

— информирование ответственных лиц за передачу информации о фактах и предложениях (для чего, в какой форме и кому).

Как только собрана полная информация об инциденте ИБ, она должна быть внесена в базу данных событий / инцидентов / уязвимостей ИБ и доложена руководителю ГРИИБ.

Если время расследования превысило заранее установленное в организации время, то должен быть составлен промежуточный отчет.

Член ГРИИБ при оценке инцидента ИБ должен на основании руководящей документации схемы управления ими знать следующее:

— когда и кому направлять материалы,

— действовать согласно процедур контроля изменений.

Если возникают или могут возникнуть проблемы со средствами электронной коммуникации, включая попадание ИС под атаку, информирование соответствующих лиц должно осуществлять альтернативными методами (лично, по телефону, передача текста).

Если инцидент ИБ является серьезным и/или была определена кризисная ситуация, руководитель ГРИИБ, получив санкцию руководителя службы ИБ и руководителя организации, должен сообщить об этом всем подразделениям, которые вовлечены в инцидент ИБ как внутри организации, так и за ее пределами.

Для быстрой и эффективной организации передачи информации необходимо заранее установить надежные средства и способы связи, не зависящие от системы, сервиса или сети, на которые может воздействовать инцидент ИБ. Такие меры предосторожности могут включать в себя назначение резервных компетентных представителей организации на случай отсутствия кого-либо из ее основных руководителей.

4.2. Оценка контроля инцидентов ИБ

После того, как член ГРИИБ осуществил немедленные реагирования на инцидент ИБ, соответствующий правовой анализ и коммуникации, необходимо быстро установить, находится ли он под контролем. При необходимости член ГРИИБ может проконсультироваться с коллегами, руководителем ГРИИБ и/или другими специалистами и группами.

Если подтверждается, что инцидент ИБ находится под контролем, то член ГРИИБ должен инициировать любые требуемые реагирования, правовой анализ и коммуникации для его завершения и восстановления нормальной работы пораженной ИС.

Если не подтверждается, что инцидент ИБ находится под контролем, член ГРИИБ должен инициировать кризисные действия.

Если инцидент ИБ связан с потерей доступности, методология оценки того, находится ли инцидент ИБ под контролем, должна определять время от возникновения инцидента ИБ до восстановления нормальной ситуации.

Организация должна определить период возможной недоступности каждого актива на основании результатов оценки рисков ИБ, который определит временные параметры восстановления обслуживания сервиса или доступа к информации. Если время восстановления превышает период возможной недоступности актива, инцидент ИБ, возможно, не находится под контролем, и необходимо принять решение об эскалации.

Если инцидент ИБ связан с потерей конфиденциальности, целостности и т. п. нужны другие виды решений для определения, находится ли ситуация под контролем и нужно ли действовать в соответствии с планом кризисного управления в организации.

4.3. Последующее реагирование

Определив, что инцидент ИБ находится под контролем и не является объектом кризисной ситуации, член ГРИИБ должен определить необходимость и вероятные способы дальнейшей обработки инцидента ИБ.

Последующее реагирование может включать в себя следующие действия:

— восстановление пораженных систем;

— предотвращение повторного возникновения инцидента;

— активация дополнительных средств мониторинга систем.

Восстановление пораженных систем, сервисов и/или сетей до нормального рабочего состояния может быть достигнуто исправлением известных уязвимостей или отключением скомпрометированных элементов. Если степень инцидента ИБ неизвестна из-за повреждения логов в течение инцидента, всю систему, сервис и/или сеть необходимо перестроить.

Предотвращение повторного возникновения инцидента или подобного ему события ИБ. Например, если причиной инцидента ИБ является отсутствие какого-либо патча в ПО, об этом надо немедленно уведомить поставщика. Если причиной инцидента ИБ стала известная уязвимость, она должна быть исправлена соответствующим обновлением. Любая ИТ конфигурация, связанная с проблемами в результате инцидента ИБ, в дальнейшем должна быть пересмотрена.

Другие меры по снижению вероятности повторного возникновения ИТ инцидента или подобного ему события ИБ могут включать изменение системных паролей и отключение неиспользуемых сервисов.

Активация дополнительных средств мониторинга систем, сервисов и/или сетей должна содействовать обнаружению необычных или подозрительных событий, которые могут оказаться признаками инцидентов ИБ. Такой мониторинг поможет также глубже раскрыть инцидент ИБ и идентифицировать другие системы ИТ, которые подверглись компрометации.

Может также возникнуть необходимость в активации специальных реагирований, задокументированных в соответствующем плане кризисного управления, которые можно применить к инцидентам ИБ как связанным, так и не связанным с ИТ. Специальные реагирования должны быть предусмотрены для всех аспектов бизнеса, связанных не только непосредственно с ИТ, но также с поддержкой ключевых функций бизнеса и последующим восстановлением, в том числе, телефонных коммуникаций, персональных уровней и физических объектов.

После успешного завершения действий по реагированию на инцидент ИБ все данные об этом ГРИИБ должна внести в форму отчета и базу данных события / инцидента / уязвимости ИБ и уведомить соответствующий персонал.

4.4. Реагирования на кризисные действия

Может случиться так, что после оценки контроля инцидента ГРИИБ придет к выводу, что он не находится под контролем и должен обрабатываться в режиме кризисного управления в соответствии с заранее разработанным планом.

Лучшие варианты обработки всех возможных типов инцидентов ИБ, которые могут повлиять на доступность и, в некоторой степени, на целостность ИС, должны быть определены в плане кризисного управления организации. Эти варианты должны быть непосредственно связаны с приоритетами бизнеса организации и соответствующими временными рамками восстановления бизнес-процессов и, следовательно, с максимально приемлемым временем простоя ИТ, телекоммуникаций, оборудования и персонала.

Стратегия кризисного управления должна определить требуемые меры и структуры:

— меры поддержки и кризисного управления;

— организационную структуру и обязанности;

— структуру и положения плана кризисного управления.

План кризисного управления и защитные меры для поддержки активации этого плана, протестированные и признанные удовлетворительными, должны создать основу для ведения эффективных кризисных действий.

В случае отсутствия контроля над инцидентом в зависимости от его вида кризисные действия требуют профессионального реагирования на инцидент и активации имеющегося плана кризисного управления.

План кризисного управления содержит активацию:

— средств пожаротушения и процедур эвакуации;

— средств предотвращения наводнения и процедур эвакуации;

— средств предотвращения взрыва бомбы и процедур эвакуации;

— специальных расследований технических атак;

— специальных расследований мошенничества в ИС.

4.5. Правовая экспертиза

Если в ходе предыдущей оценки была определена серьезность инцидента ИБ и необходимость сбора доказательств, ГРИИБ должна провести правовую экспертизу инцидента для дисциплинарного или судебного разбирательства. В целях проведения более тщательной экспертизы конкретного инцидента ИБ необходимо применять следственные методы и средства, основанные на ИТ и поддерживаемые документированными процедурами, которые до этого не использовались в управлении инцидентами ИБ.

Для проведения правовой экспертизы могут использоваться технические (например, средства аудита и восстановления) и программные средства, защищенные служебные помещения, а также соответствующий персонал. Каждое действие правовой экспертизы должно быть полностью задокументировано, включая предоставление соответствующих фотографий, составление отчетов об анализе результатов аудита, проверку логов восстановления данных. Квалификация лиц, проводивших правовую экспертизу, должна быть задокументирована так же, как и результаты профессионального тестирования.

Необходимо также документировать любую другую информацию, способную продемонстрировать объективность и логический характер правовой экспертизы. Все записи о самих инцидентах ИБ, деятельности, связанной с правовой экспертизой этих инцидентов, и т. д., а также соответствующие носители информации должны храниться в физически защищенной среде и контролироваться соответствующими процедурами для предотвращения доступа к ним неавторизованных лиц с целью модификации записей.

Средства правовой экспертизы, основанные на применении ИТ, должны точно соответствовать правовым нормам с целью исключения возможности оспаривания этого соответствия в судебном порядке и, в то же время, в них должны учитываться все текущие изменения в технологиях. В физической среде ГРИИБ необходимо создавать необходимые условия, гарантирующие неоспоримость свидетельств правовой экспертизы.

Со временем, несомненно, возникнет необходимость разработки требований к анализу свидетельств правовой экспертизы в контексте многообразия инцидентов ИБ, включая мошенничество, кражу и акты вандализма. Следовательно, для содействия ГРИИБ потребуется большее число средств, основанных на ИТ, и вспомогательных процедур для получения необходимой информации в информационной системе, сервисе и/или сети, включая восстановление информации, подвергшейся стиранию, шифрованию или искажению. Эти средства должны учитывать все аспекты, связанные с известными типами инцидентов ИБ и документироваться в процедурах ГРИИБ.

В современных условиях правовая экспертиза должна охватить всю сложную инфраструктуру ИТ, в которой расследование распространяется на всю операционную среду, включая множество серверов (в том числе файловый, связи, печати и почтовый), а также средства удаленного доступа. Существует много инструментальных средств, включая средства поиска текстов, ПО формирования изображений и пакеты программ для правовой экспертизы.

Обязательными процедурами правовой экспертизы являются сохранение доказательств в неприкосновенности и их проверка на предмет противостояния любым оспариваниям в суде. Важно, чтобы правовая экспертиза проводилась на точной копии исходных данных с тем, чтобы избежать сомнений в целостности исходных носителей в ходе аналитической работы.

Общий процесс правовой экспертизы должен охватывать следующие виды деятельности:

— обеспечение защиты целевой системы, сервиса и/или сети в процессе проведения правовой экспертизы от появления недоступности, изменений или другой компрометации, включая вредоносное ПО (в том числе вирусы), и каких-либо влияний на их нормальную работу;

— назначение приоритетов сбора доказательств, т. е. рассмотрение их от наиболее до наименее изменчивых (что в значительной степени зависит от характера инцидента ИБ);

— идентификация всех необходимых файлов в предметной системе, сервисе и/или сети, включая нормальные файлы, файлы, кажущиеся уничтоженными, но не являющиеся таковыми, файлы, защищенные паролем или иным образом, и зашифрованные файлы;

— восстановление как можно большего числа стертых файлов и других данных;

— раскрытие IP-адресов, имен хостов, сетевых маршрутов и информации Web-сайтов;

— извлечение содержимого скрытых, временных файлов и файлов подкачки, используемых как прикладное, так и системное ПО;

— доступ к содержимому защищенных или зашифрованных файлов (если это не запрещено законодательством);

— анализ всех возможно значимых данных, найденных в специальных (обычно недоступных) областях памяти на дисках;

— анализ времени доступа к файлу, его создания и изменения;

— анализ логов системы / сервиса / сети и приложений;

— определение деятельности пользователей и/или приложений в системе / сервисе / сети;

— анализ электронной почты на наличие исходной информации и ее содержания;

— проведение проверок целостности файлов с целью обнаружения файлов, содержащих «троянского коня», и файлов, изначально отсутствовавших в системе;

— по возможности, анализ физических доказательств ущерба имуществу, например отпечатков пальцев, результатов видеонаблюдения, логов системы сигнализации, логов доступа по пропускам и опроса свидетелей:

— обработка и хранение добытых потенциальных доказательств так, чтобы избежать их повреждения, приведения в негодность и предотвращения просмотра конфиденциального материала несанкционированными лицами. Следует подчеркнуть, что сбор доказательств всегда должен проводиться в соответствии с правилами судопроизводства или слушания дела, для которых возможно представление данного доказательства;

— получение выводов о причинах инцидента ИБ, необходимых действиях и времени их выполнения с приведением свидетельств, включая список соответствующих файлов, включенных в приложение к главному отчету;

— обеспечение экспертной поддержки для любого дисциплинарного или правового действия (при необходимости).

Методы выполнения вышеуказанных действий должны документироваться в процедурах ГРИИБ.

ГРИИБ должна обладать разнообразными навыками в обширной области технических знаний (включая знание средств и методов, которые, возможно, будут использоваться нарушителем), опытом проведения анализа/расследования (с учетом защиты используемых доказательств), знанием нормативно-правовых положений и постоянной осведомленностью о тенденциях, связанных с инцидентами ИБ.

Необходимо учесть следующее:

— некоторые организации могут не иметь своих юристов, поэтому вынуждены обращаться к сторонним юридическим службам;

— сбор правовых доказательств в случае нанесения значительного ущерба может оказаться отправной точкой для возможного возбуждения уголовного дела, т. е. усилия и затраты могут быть оправданы;

— отказ от привлечения специалистов для фиксации правовых доказательств может привести к невозможности судебного разбирательства.

4.6. Коммуникации

Во многих случаях, когда ГРИИБ подтвердила реальность инцидента ИБ, возникает необходимость информирования конкретных лиц как внутри организации (вне обычных линий связи между ГРИИБ и руководством), так и за ее пределами, включая СМИ. Для этого могут потребоваться несколько этапов, например, подтверждение реальности инцидента ИБ и его подконтрольности, определение инцидента ИБ как объекта кризисного управления, завершение инцидента ИБ и завершение отчета о нем.

В случае необходимости осуществления передачи информации необходимо определить, кому нужно знать, что и когда. В таком случае необходимо определить получателей информации и в зависимости от скорости и полноты получения информации разделить их на группы, например:

— прямые внутренние получатели (кризисный персонал, персонал СУИБ и т. п.);

— прямые внешние получатели (внешняя ГРИИБ, партнеры, поставщики и т. п.);

— другие внешние получатели, например, телевидение, пресса и/или другие СМИ.

Каждая группа может нуждаться в разного рода информации, которую она будет получать с определенной скоростью по выделенному организацией каналу. Одной из основных задач передачи информации после решения инцидента ИБ является гарантирование того, что прямые внешние и внутренние посредники получат более полную информацию и раньше других внешних контактов.

Для оказания содействия такой деятельности целесообразно заранее подготовить конкретную информацию с целью быстрой адаптации ее к обстоятельствам возникновения конкретного инцидента ИБ и предоставления этой информации прессе и/или другим СМИ.

Если информация, относящаяся к инцидентам ИБ, должна освещаться в прессе, то это нужно сделать в соответствии с политикой распространения информации организации. Информация, подлежащая распространению среди общественности, должна быть проанализирована ответственными лицами, например, координатором по связи с общественностью, руководителем ГРИИБ и высшим руководством.

4.7. Расширение сферы принятия решений (эскалация)

Если инцидент ИБ не находится под контролем и содержит реальную угрозу бизнесу, организация может осуществить эскалацию инцидента ИБ, т. е. расширить сферу принятия решений. Это нужно для того, чтобы активировать имеющийся план обеспечения непрерывности бизнеса, информируя высшее руководство, внешнюю ГРИИБ и другие заинтересованные организации.

Эскалация может потребоваться вслед за процессами оценки или происходить в ходе процессов оценки, если проблема становится очевидной на ранней стадии ее обнаружения. Группа поддержки и ГРИИБ, которые могут принять решение об эскалации, должны иметь соответствующие директивы в документации схемы управления инцидентами ИБ.

4.8. Документирование и контроль внесения изменений

Все, кто причастен к управлению инцидентами ИБ, должны документально фиксировать все свои действия для дальнейшего анализа. Информацию об этих действиях вносят в форму отчета об инцидентах ИБ и в базу данных события / инцидента / уязвимости ИБ, непрерывно обновляемую в течение всего времени действия инцидента ИБ от первого сообщения до завершения анализа инцидента ИБ.

Эта информация должна храниться с применением средств защиты и обеспечением соответствующего режима резервирования. Кроме того, изменения, вносимые в процессе мониторинга инцидента ИБ, обновления форм отчета и баз данных уязвимостей / инцидентов / событий ИБ, должны вноситься в соответствии с формально принятой схемой контроля внесения изменений

5 фаза — извлечение уроков

Эта фаза наступает, когда инциденты ИБ решаются/завершаются, и включает извлечение уроков из результатов обработки инцидентов (и уязвимостей) и управления ими.

Организация в результате полученных уроков должна обеспечить следующие действия:

— идентификацию полученных уроков;

— идентификацию улучшений мер защиты (новых и/или усовершенствованных) и их внедрение в соответствии с политикой управления инцидентами ИБ;

— идентификацию улучшений пересмотра оценки и управления рисками ИБ и их внедрение;

— идентификацию улучшений схемы управления инцидентами ИБ и ее документации и их внедрение в результате пересмотра эффективности процессов, процедур, форматов отчетов и/или организационной структуры, используемых в реагировании, оценке и разрешении инцидента ИБ и связанных с ним уязвимостей ИБ;

— обновление базы данных события / инцидента / уязвимости ИБ;

— коммуникации и распространение результатов пересмотра в пределах доверенного сообщества;

— рассмотрение возможности уведомления партнерских организаций об идентифицированных угрозах, инцидентах, связанных с ними векторах атаки и уязвимостях, для оказания помощи в предотвращении возникновения тех же проблем.

Деятельность по управлению инцидентами ИБ является итерационной, и таким образом организация должна осуществлять регулярные улучшения элементов ИБ. Эти улучшения должны осуществляться на основе пересмотров данных об инцидентах ИБ и реагированиях на них и известные уязвимости ИБ, а также современных тенденций.

5.1. Идентификация полученных уроков

После завершения инцидента ИБ важно быстро идентифицировать уроки, извлеченные из его обработки, и предпринять соответствующие действия. В дальнейшем могут быть также идентифицированы уроки, извлеченные из оценки выявленной уязвимости ИБ и соответствующего решения.

Полученные уроки могут рассматриваться с точки зрения:

— новых или изменившихся требований к мерам защиты;

Это могут быть технические или нетехнические (включая физические) меры защиты. В зависимости от извлеченных уроков требования могут включать в себя необходимость быстрого обновления материалов и проведения инструктажа с целью обеспечения осведомленности в вопросах ИБ (как для пользователей, а так и другого персонала) и быстрого пересмотра и издания директив и/или стандартов по ИБ.

— новых или изменившихся данных об угрозе и уязвимости, которая вносит изменения в существующие результаты оценки и управления рисками ИБ;

— изменений в схеме управления инцидентами ИБ и ее процессах, процедурах, формах учета и/или организационной структуре и базе данных события / инцидента / уязвимости ИБ.

Организация должна рассматривать полученный опыт не только в рамках отдельного инцидента / уязвимости ИБ, но и проводить проверку наличия тенденций / шаблонов появления предпосылок к инцидентам ИБ, которые могут быть использованы в интересах определения потребности в защитных мерах или изменениях подходов к устранению инцидента ИБ. Целесообразно также проведение тестирование ИБ, в особенности оценки уязвимостей, после повлиявшего на ИТ инцидента ИБ.

Поэтому необходимо регулярно анализировать базы данных события / инцидента / уязвимости ИБ для осуществления:

— идентификации тенденций / шаблонов:

— идентификации проблемных областей;

— анализа сфер применения превентивных мер для снижения вероятности появления инцидентов.

Существенная информации, получаемая в процессе обработки инцидента ИБ, должна направляться для анализа тенденций / шаблонов (обработки уязвимости ИБ). Это может в значительной мере способствовать ранней идентификации инцидентов ИБ и обеспечивать предупреждение о том, какие следующие инциденты ИБ могут возникнуть на основе предшествующего опыта и документов.

Необходимо также использовать информацию об инцидентах ИБ и соответствующих им уязвимостях, полученную от государственных и коммерческих ГРИИБ и поставщиков.

Тестирование ИБ и оценка уязвимостей системы, сервиса и/или сети, следующие за инцидентом ИБ, не должны ограничиваться только системой, сервисом и/или сетью, пораженных этим инцидентом ИБ, а должны распространить на любые связанные с ними системы, сервисы и/или сети.

Детальная оценка уязвимостей проводится для того, чтобы выявить их существование в других системах, сервисах и/или сетях, и исключить вероятность появления новых уязвимостей. Она должна проводиться регулярно, поэтому проводимая после инцидента повторная оценка уязвимостей должна быть частью, а не заменой непрерывного процесса оценки.

Необходимо опубликовывать итоговый анализ инцидентов и уязвимостей ИБ для обсуждения его на каждом совещании руководства организации по вопросам обеспечения ИБ и/или на других совещаниях, касающихся общей политики безопасности.

5.2. Идентификация улучшений мер защиты и их внедрение

В процессе анализа, проведенного после решения инцидента ИБ, может быть определена необходимость новых или измененных мер защиты. Однако может случиться так, что их немедленное внедрение будет невозможно по финансовым или эксплуатационным причинам; в этом случае они должны быть предусмотрены в долгосрочных планах организации.

Периодически организация должна осуществлять обновление и/или внедрение новых мер защиты. Это могут быть технические (включая физические) средства, которые потребуют обновления учебного материала для инструктажа персонала и пересмотра директив по ИБ. Системы / сервисы / сети организации должны также периодически подвергаться оценке уязвимостей с целью непрерывного повышения их надежности.

Анализ связанных с ИБ процедур и документации может проводиться сразу после инцидента (выявления уязвимости) или позже. После инцидента (выявления уязвимости) ИБ необходимо обновить политики и процедуры обеспечения ИБ с учетом собранной информации и проблем, возникших в процессе управления инцидентами ИБ. Постоянной задачей ГРИИБ и руководителя ИБ организации является распространение в организации обновленных вариантов политики и процедур обеспечения ИБ и доведение их до персонала ИБ.

5.3. Идентификация улучшений пересмотра результатов оценки и управления рисками и их внедрение

В зависимости от серьезности и степени влияния инцидента (потенциального влияния выявленной уязвимости) ИБ может появиться необходимость пересмотра результатов оценки и управления рисками ИБ с учетом новых угроз и уязвимостей. По результатам обновления результатов оценки и управления рисками ИБ может возникнуть необходимость обновления и/или внедрения новых мер защиты.

5.4. Идентификация улучшений схемы управления инцидентами и их внедрение

После разрешения инцидента руководитель ГРИИБ должен проанализировать все произошедшее, чтобы количественно оценить эффективность всех реагирований на инцидент ИБ. Подобный анализ предназначен для идентификации успешно задействованных элементов схемы управления инцидентами ИБ и определения потребности в любых улучшениях.

Важным аспектом анализа, проводимого после реагирования на инцидент, является применение полученной информации в схеме управления инцидентами ИБ. Если инцидент ИБ является серьезным, то после его решения необходимо провести совещание всех заинтересованных сторон, владеющих информацией о нем.

На этом совещании должны рассматриваться следующие вопросы:

— работали ли должным образом процедуры, принятые в схеме управления инцидентами;

— существуют ли процедуры или методы, которые способствовали бы обнаружению инцидентов;

— были ли определены процедуры или средства, которые использовались бы в процессе реагирования;

— применялись ли процедуры, помогающие восстановлению систем после идентификации инцидента;

— была ли передача информации об инциденте всем задействованным сторонам эффективной в процессе обнаружения, оповещения и реагирования.

Все предложения по улучшению схемы управления инцидентами ИБ, полученные в результате совещания, должны быть задокументированы. Области схемы, предназначенные для улучшений, должны быть проанализированы и принято решение о варианте их реализации. Изменения в процессах, процедурах и формах учета должны быть тщательно проверены и протестированы перед применением на практике. После реализации улучшений в документацию схемы должны быть внесены изменения, а обновленный вариант документации — доведен до персонала ИБ.

5.5. Другие улучшения

В течение фазы извлечения уроков могут быть идентифицированы и другие улучшения, например, изменения в политике ИБ, стандартах, процедурах и конфигурациях аппаратного и программного обеспечения.

Content

Управление информационной безопасностью
Стандарты СУИБ
Вадим Гребенников

1. Семейство стандартов управления информационной безопасностью

1.1. История развития стандартов управления информационной безопасностью

1.2. Стандарт ISO/IEC 27000—2014

Введение

2. Требования к суиб (стандарт ISO/IEC 27001:2013)

1. Сфера применения

4. Контекст организации

5. Лидерство

6. Планирование (1-й этап «РDСА»)

7. Поддержка

8. Эксплуатация (2-й этап «РDСА»)

9. Оценка результативности (3-й этап «РDСА»)

10. Улучшение (4-й этап «РDСА»)

3. Свод правил управления ИБ (стандарт ISO/IEC 27002:2013)

1. Политика ИБ

2. Организация ИБ

3. Безопасность, связанная с персоналом

4. Управление активами

5. Управление доступом

6. Криптография

7. Физическая и экологическая безопасность

8. Безопасность операций

9. Безопасность связи

10. Покупка, разработка и сопровождение ИС

11. Взаимоотношения с поставщиками

12. Управление инцидентами ИБ

13. Аспекты ИБ при управлении непрерывности бизнеса

14. Соответствие требованиям

4. Разработка СУИБ (стандарт ISO/IЕС 27003:2010)

1. Одобрение руководством проектирования СУИБ

2. Определение области действия, границ и политики СУИБ

2.1. Определение организационной области действия и границ

3. Проведение анализа требований к ИБ

3.2. Определение активов в рамках СУИБ

4. Проведение оценки и планирование обработки рисков

5. Разработка СУИБ

5. Управление рисками иб (стандарт ISO/IEC 27005:2010)

1. Установление контекста (сферы применения)

2. Оценка рисков ИБ

3. Обработка рисков ИБ

4. Принятие риска ИБ

5. Обмен информацией о рисках

6. Мониторинг и улучшение

6. Управление инцидентами иб (стандарт ISO/IEC 27035:2011)

Основные понятия

Цели управления инцидентами

Фазы управления инцидентами

1 фаза — планирование и подготовка

2 фаза — обнаружение и оповещение

2.1. Обнаружение события

3 фаза — оценка и принятие решения

4 фаза — реагирования

5 фаза — извлечение уроков