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

1.

Анализ рисков в управлении
информационной безопасностью
Доцент ИКТИБ ЮФУ, к.т.н.,
Князева М.В.

2.

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

3.

• Кибертерроризм, технологии Internet of Things (IoT),
современные уязвимости ПО и аппаратуры.
• Риски промышленных систем (АСУ, АСУ ТП, SCADA)
* SCADA (аббр. от англ. Supervisory Control And Data Acquisitionдиспетчерское управление и сбор данных) - программный пакет,
предназначенный для разработки или обеспечения работы в реальном
времени систем сбора, обработки, отображения и архивирования
информации об объекте мониторинга или управления. SCADA может
являться частью АСУ ТП, АСКУЭ, системы экологического
мониторинга, научного эксперимента, автоматизации здания и т. д.
SCADA-системы используются во всех отраслях хозяйства, где
требуется обеспечивать операторский контроль за технологическими
процессами в реальном времени. Данное программное обеспечение
устанавливается на компьютеры и, для связи с объектом, использует
драйверы ввода-вывода или OPC/DDE серверы. Программный код
может быть как написан на одном из языков программирования, так и
сгенерирован в среде проектирования.
Иногда SCADA-системы комплектуются дополнительным ПО для
программирования промышленных контроллеров.
Такие SCADA-системы называются интегрированными и к ним
добавляют термин SoftLogic.

4.

• Риски утечки информации
Персональные данные, коммерческая тайна, тайна переписки
ФЗ-149 «Об информации, информационных технологиях и о защите
информации»:
Ст.7 Общедоступная информация;
Ст. 8 Право на доступ к информации;
Ст. 9 Ограничение доступа к информации;
Уголовный кодекс РФ:
Ст. 138 УК РФ определяет уголовную ответственность за незаконный
доступ к конфиденциальным персональным данным, за нарушение тайны
переписки, телефонных разговоров, почтовых, телеграфных и иных
сообщений.
Ст. 183 УК РФ определяет ответственность за коммерческую и банковскую
тайны.
• Риски электронных расчетов
ФЗ-161 «О национальной платёжной системе», 2012г.
Положение «Об утверждении положения по защите информации в
платежной системе». Введены меры по защите информации, в том числе
расчет рисков ИБ. И организация системы обеспечения ИБ.

5.

Стандарты и практики по
управлению рисками ИБ

6.

• Международный стандарт ISO 27 005:2011
• COBIT 5 for Risk (ИТ-риски), 2013
• NIST SP 800-30
• РС БР ИББС – 2.2

7.

Международный стандарт
ISO 27 005
ГОСТ ИСО/МЭК 27005:2022
ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ,
КИБЕРБЕЗОПАСНОСТЬ И ЗАЩИТА ЧАСТНОЙ ЖИЗНИ
Руководство по управлению рисками информационной
безопасности.
Требования и руководства
Information security, cybersecurity and privacy protection —
Guidance on managing information security risks
https://fstec.ru/tk-362/standarty/proekty/proekt-natsionalnogostandarta-gost-r-iso-mek-27005

8.

Область применения
Данный документ содержит руководство,
способствующее организациям:
— выполнять требования стандарта ИСО/МЭК
27001:2022, касающиеся действий в отношении рисков
информационной безопасности;
— выполнять действия по менеджменту риска
информационной безопасности, в частности по оценке
и обработке риска информационной безопасности.
Данный документ применим ко всем организациям,
независимо от типа, размера или сферы деятельности.
ГОСТ ИСО/МЭК 27001:2022

9.

Предоставляет руководство по менеджменту
риска информационной безопасности в
организации.
Он обеспечивает рекомендации для
менеджмента рисков информационной
безопасности в организации, в особенности
поддерживая требования СМИБ (ISMS)
согласно ISO/IEC 27001.
*Не обеспечивает определённой методологии
для менеджмента рисков информационной
безопасности.
ГОСТ ИСО/МЭК 27001:2022

10.

Анализ риска
8.2.1 Идентификация риска
8.2.1.1 Введение в идентификацию риска
8.2.1.2 Идентификация активов
8.2.1.3 Идентификация угроз
8.2.1.4 Идентификация существующих средств контроля
8.2.1.5 Идентификация уязвимости
8.2.1.6 Идентификация последствий
8.2.2 Измерение риска
8.2.2.1 Методология измерения риска
8.2.2.2 Оценка последствий
8.2.2.3 Оценка вероятности инцидента
8.2.2.4 Измерение уровня риска
8.3 Оценивание риска
9 Обработка рисков информационной безопасности
9.1 Общее описание обработки риска
9.2 Снижение риска
9.3 Сохранение риска
9.4 Предотвращение риска
9.5 Перенос риска
10 Принятие риска информационной безопасности
11 Обмен информацией относительно риска информационной безопасности
12 Мониторинг и пересмотр риска информационной безопасности
12.1 Мониторинг и пересмотр факторов риска
12.2 Мониторинг, анализ факторов риска

11.

• Последствия (consequence): результат события , влияющего на
цели. Результатом события может быть одно или более последствий.
Последствия могут быть выражены качественно и количественно.
Начальные последствия могут вырасти через цепную реакцию.
• Менеджмент (control): мера, которая изменяет риск [Руководство
ISO 73:2009]. Средства менеджмента для информационной
безопасности включают любой процесс, политику, процедуру,
направляющую линию, практику или организационную структуру,
которая может быть административной, технической, управляющей,
или законодательно принятой, которые изменяют риск
информационной безопасности.
• Внешний контекст (external context): внешняя среда, в которой
организация стремится к достижению своих целей [Руководство ISO
73:2009]
• Внутренний контекст (internal context): внутренняя среда, в которой
организация стремится к достижению своих целей [Руководство ISO
73:2009].
Основные термины

12.

Внутренний контекст (internal context): внутренняя среда, в которой
организация стремится к достижению своих целей [Руководство ISO
73:2009].
• руководство, организационную структуру, функции и обязательства;
• политику, цели и стратегии для их достижения;
возможности, рассматриваемые в отношении ресурсов и знаний
(например, капитал, время, персонал, процессы, системы и
технологии);
• информационные системы, информационные потоки и процессы
принятия решений (как официальные, так и неофициальные);
• взаимосвязи с внутренними заинтересованными сторонами, их
восприятие и ценности;
• культуру организации;
• стандарты, руководящие указания и модели, принятые
организацией;
• форму и объем контрактных взаимоотношений.
ГОСТ ИСО/МЭК 27001:2022

13.

Идентификация риска (risk identification): процесс выявления,
исследования и описания рисков.
[Руководство ISO 73:2009]
1. Идентификация включает идентификацию источников риска,
событий, их причин и возможных последствий.
2. Идентификация риска может включать статистические данные,
теоретический анализ, обоснованную точку зрения и заключение
специалиста, а также потребности заинтересованной стороны.
Обработка риска (risk treatment): процесс изменения риска.
Обработка риска может включать:
• избегание риска посредством принятия решения не начинать или не
продолжать деятельность, в результате которой возникает риск;
• принятие риска или увеличение риска для достижения цели;
• устранение источника риска;
• изменение возможности возникновения;
• изменение последствий;
• разделение риска с другой стороной или сторонами (включая
договоры и финансирование риска;
• принятие риска на основании обоснованного решения.

14.

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

15.

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

16.

Идентификация активов:
Входные данные: Область применения и границы для
подлежащей проведению оценке риска, перечень
составных частей, включающий владельцев,
местоположение, функцию и т.д.
Действие: Должны быть идентифицированы активы,
входящие в установленную область применения
[связано с ISO/IEC 27001, 4.2.1 перечисление d) 1)].
Руководство по реализации:
Активом является нечто, имеющее ценность для
организации и, следовательно, нуждающееся в защите.
При идентификации активов следует иметь в виду, что
информационная система состоит не только из
аппаратных и программных средств.
Идентификация риска

17.

В прикладных методах анализа рисков обычно
рассматриваются следующие классы активов:
• оборудование (физические ресурсы);
• программное обеспечение (системное, прикладное,
утилиты, другие вспомогательные программы);
• информационные ресурсы (базы данных, файлы, все виды
документации);
• системные интерфейсы (внешние и внутренние возможные
соединения);
• люди, которые пользуются и поддерживают IT систему (в
штате/ контракт);
• миссия IT системы (system mission) – процесс,
выполняемый IT системой;
• сервис и поддерживающая инфраструктура (обслуживание
СВТ, энергоснабжение, обеспечение климатических
параметров и т.п.).

18.

B.1 Примеры идентификации актива
Чтобы определить ценность актива, организация сначала
должна идентифицировать свои активы (на соответствующем
уровне детализации). Можно выделить два вида активов:
первичные активы:
• бизнес-процессы и действия;
• информация;
активы поддержки (на которые полагаются первичные
элементы области применения) всех типов:
• аппаратные средства;
• программное обеспечение;
• сеть;
• персонал;
• сайт;
• организационная структура.
Приложение В, ISO 27 005

19.

В.2 Определение ценности активов
Критерии, которые могут использоваться для оценки возможных
последствий, вытекающих из потери конфиденциальности,
целостности, доступности, неотказуемости, учётности,
подлинности или надёжности активов, включают:
• нарушение законодательства и/или предписаний;
• ухудшение функционирования бизнеса;
• потеря "неосязаемого капитала"/негативное влияние на
репутацию;
• нарушения, связанные с личной информацией;
• создание угрозы личной безопасности;
• неблагоприятное влияние на обеспечение правопорядка;
• нарушение конфиденциальности;
• нарушение общественного порядка;
• финансовые потери;
• нарушение бизнес-деятельности;
• создание угрозы для безопасности окружающей среды.

20.

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

21.

Другим подходом к оценке последствий может быть:
• опасность для персонала/безопасность пользователей;
• вторжение в частную жизнь пользователей;
• финансовые потери, связанные с непредвиденными случаями или
ремонтом:
касающиеся персонала; касающиеся оборудования; касающиеся
исследований, отчётов экспертов;
• потеря товаров/денежных средств/активов;
• потеря клиентов, потеря поставщиков;
• судебные дела и штрафы;
• потеря конкурентного преимущества; потеря
технологического/технического лидерства;
• потеря эффективности/надёжности;
• потеря технической репутации;
• снижение способности к заключению соглашений;
• промышленный кризис (забастовки); правительственный кризис;
• увольнения;
• материальный ущерб.

22.

В.3 Оценка влияния
Инцидент безопасности может оказывать влияние более чем на один актив или только
на часть актива. Влияние связано со степенью успешности инцидента. Как следствие,
существует важное различие между ценностью актива и влиянием, происходящим в
результате инцидента.
Влияние рассматривается как имеющее либо незамедлительный (операционный)
эффект, либо будущий (бизнес-) эффект, который включает финансовые и рыночные
последствия. Непосредственное (операционное) влияние бывает прямым или
косвенным.
Прямое:
a) финансовая восстановительная стоимость потерянного актива (части актива);
b) стоимость приобретения, конфигурирования и установки нового актива или
резервной копии;
c) стоимость приостановленных из-за инцидента операций, пока услуга,
предоставляемая активом (активами), не будет восстановлена;
d) влияние приводит к нарушению информационной безопасности.
Косвенное: а) издержки упущенных возможностей (финансовые ресурсы,
необходимые для замены или восстановления актива, использовались бы
где-то в другом месте);
b) стоимость прерванных операций;
с) возможное злоупотребление информацией, полученной в результате
нарушения безопасности;
d) нарушение установленных законом или регулятивных обязательств;
e) нарушение этических норм поведения.

23.

Идентификация уязвимости
Входные данные: Перечни известных угроз, перечни активов и
существующих средств контроля.
Действие: Необходимо идентифицировать уязвимости, которые
могут быть использованы угрозами, чтобы нанести ущерб активам
или организации [связано с ISO/IEC 27001, 4.2.1 перечисление d)
3)].
Руководство по реализации:
Уязвимости могут быть идентифицированы в следующих областях:
• организация работ;
• процессы и процедуры;
• установившиеся нормы управления;
• персонал;
• физическая среда;
• конфигурация информационной системы;
• аппаратные средства, программное обеспечение и аппаратура
связи;
• зависимость от внешних сторон.

24.

Определение критериев вероятности наступления
рискового события будет зависеть от таких факторов,
как:
a) случайные или природные явления (события);
b) степень подверженности соответствующей информации
или актива, связанного с информацией, той или иной угрозе;
c) возможность эксплуатации уязвимости злоумышленником;
d) возможность технологических сбоев;
e) опасность неквалифицированных и/или умышленных
человеческих действий или бездействий.
Вероятность может быть выражена в терминах вероятности
(вероятность того, что событие произойдет в данный период
времени) или в частотных терминах (условное среднее число
событий за данный период времени).
Критерии вероятности

25.

В соответствии с ИСО/МЭК 27001:2022, 6.1.3 d),
Заявление о применимости (SOA, от англ. «Statement of
Applicability») должно содержать по крайней мере:
a) необходимые мероприятия по управлению рисками
[см. 6.1.3 b) и c)];
b) мотивированное обоснование включения их в
заявление о применимости;
c) свидетельства о внедрении необходимых
мероприятий по управлению рисками;
d) обоснование исключения любой из мер обеспечения
информационной безопасности, указанных в ИСО/МЭК
27001:2022, приложение A.
ГОСТ ИСО/МЭК 27001:2022

26.

Для каждого рассматриваемого риска план обработки рисков должен включать следующую
информацию:
— обоснование выбора способов обработки рисков, включая ожидаемые затраты и выгоды,
которые будут получены;
— персональную ответственность за утверждение и реализацию плана менеджмента риском;
— предлагаемые действия;
— требуемые ресурсы, включая непредвиденные расходы;
— показатели эффективности;
— ограничения;
— сведения о требуемой отчетности и мониторинге;
— критерии завершенности мероприятий, включенных в план;
— статус внедрения запланированных мероприятий.
ГОСТ ИСО/МЭК 27001:2022

27.

COBIT 5 for Risk
(ИТ-риски)

28.

COBIT 5 for Risk (ИТ-риски)

29.

• COBIT 5 for Risk (ИТ-риски), 2013г.
- инсайдерская угроза, ошибки в разграничении
доступа: собственные сотрудники могут нарушать работу
процессов, модифицировать клиентскую информацию,
проводить фиктивные транзакции в финансовых системах,
проводить несанкционированные изменения или,
например, вступая в сговор, способствовать утечкам
конфиденциальной информации за пределы компании.
- человеческий фактор: многим успешным атакам
предшествует сбор информации о будущем объекте атаки,
в чем злоумышленникам помогают техники фишинга.
- ошибки при исполнении стандартных операций:
установка обновлений или бэкапирование, что при
определенных обстоятельствах может приводить к потере
данных и/или прерываниям ИТ-услуг.
- несанкционированные изменения, ненадлежащий
уровень тестирования (отсутствие сред, моделей и
сценариев тестирования), а как следствие с высокой
вероятностью инциденты.

30.

• COBIT 5 for Risk (ИТ-риски)
- проблемы масштабирования. Причины – отсутствие
целевой модели архитектуры, неработающий процесс
управления мощностями, отсутствие CMDB. Виновником
также может быть бизнес, который во время не передает
информацию о планах по развитию и грядущих
изменениях, чем осложняет жизнь всем участникам
сервисных отношений.
- отсутствие практик планирования архитектуры, как
причина многих бед, связанных с появляющимися
несовместимостями, дублированиями и проблемами с
безопасностью. Следствие - сроки и стоимость проектов,
ИТ-ценность бизнеса.
- невыполнение обязательств подрядчиками в эпоху
аутсорсинга, «облаков» и SIAM.
*SIAM – это целостный подход к руководству, обеспечению
качества и управлению многочисленными подрядчиками, как
внешними, так и внутренними. SIAM гарантирует, что все
стороны понимают свои роли и ответственность и могут
предоставлять необходимые результаты и отвечать за них;

31.

COBIT 5 for Risk (ИТ-риски)
Рассматриваются ИТ-риски в связи с рисками бизнеса, процесс
управления рисками взаимодействует с другими процессами в
организации.
Управление рисками рассматривается и как процесс
(совокупность процессов), и как функция (набор элементов
факторов влияния (enablers)). Детально рассматриваются все 7
факторов влияния.
Приведены 111 типовых сценариев рисков.
Документ сочетает лучшие идеи и модели других "лучших
практик" по управлению рисками (ISO 27005, ISO 31000, COSO,
Risk IT). На них периодически даются ссылки, приводятся
подробные таблицы соответствия. Это довольно удобно, можно
использовать COBIT 5 for Risk в качестве единой
интегрированной методологии ( Принцип 3 из COBIT5
Framework ).
Примеры, модели и таблицы приведены в описании фактора
влияния "6.Информация".
Даются рекомендации по составлению "Risk Profile", "Risk
Communication Plan", "Risk Report", "Risk Awareness Programme",
"Risk Map", "Risk Universe", "Appetite and Tolerance", "Key Risk
Indicators", "Emerging Risk Issues and Factors", "Risk Taxonomy",
"Business Impact Analysis", "Risk Event", "Risk and Control
Activity Matrix", "Risk Assessment".

32.

33.

COBIT 5 for Risk рассматривает подход к управлению рисками с
двух точек зрения: risk function и risk management.
В первом случае говорится о том, что нужно иметь в организации,
чтобы построить и поддерживать систему управления рисками.
Во втором мы рассматриваем ключевые процессы руководства
(governance) и управления для оптимизации рисков и регулярные
процедуры для идентификации, анализа, реагирования и
отчетности по рискам.
В части risk function рассматриваются все 7 факторов влияния
(enablers) применительно к управлению рисками:
1.Принципы, политики и подходы;
2.Процессы;
3.Организационная структура;
4.Культура, этика и поведение;
5.Информация;
6.Услуги, инфраструктура и приложения;
7.Персонал, навыки и компетенции.

34.

COBIT 5 for Risk, в части risk management 2
ключевых процесса:
EDM03 Ensure Risk Optimisation,
APO12 Manage Risk.
(Они детально описаны в Приложении С),
модель сценариев рисков и типовые
сценарии, даются рекомендации по обработке
рисков, в частности, по уменьшению риска
В Приложении D "Using cobit 5 enablers to
mitigate it risk scenarios" приведены довольно
подробные таблицы по снижению рисков для
каждой из 20 категорий сценариев.

35.

36.

В документе рассматриваются 111 типовых сценариев риска

37.

КАТЕГОРИИ для СЦЕНАРИЕВ РИСКА:
01-Portfolio establishment and maintenance
02-Programme/project life cycle management
03-IT investment decision making
04-IT expertise and skills
05-Staff operations
06-Information
07-Architecture
08-Infrastructure
09-Software
10-Ineffective business ownership of IT
11-Selection/performance of third-party suppliers
12-Regulatory compliance
13-Geopolitical
14-Infrastructure theft
15-Malware
16-Logical attacks
17-Industrial action
18-Environmental
19-Acts of nature
20-Innovation

38.

Группа information. Эта группа выбрана из-за наличия сценариев, в
результате которых происходит утечка информации (сценарии 0603, 0604,
0605, 0606, 0608, 0609, 0610).

39.

Для каждого сценария определен тип риска:
P (primary) - высокая степень соответствия;
S (secondary) - низкая степень соответствия);
• IT benefit/value enablement risk (Strategic) - риски,
связанные с упущенными возможностями использования
ИТ для повышения эффективности и результативности
бизнес-процессов или в качестве возможности для новых
бизнес-инициатив.
• IT programme and project delivery risk (Project Delivery)
- риски, связанные с вкладом ИТ для разработки новых
или развитием существующих бизнес решений.
• IT operations and service delivery risk (Operational) риски, связанные с операционной стабильностью,
доступностью, защитой и возможностью восстановления
ИТ-сервисов, проблемы с которыми могут привести к
убыткам.

40.

41.

Национальный институт
стандартов США
NIST Special Publications 800
Series
NIST SP 800-30
NIST SP 800-53
Risk Management Guide for Information
Technology Systems

42.

NIST – National Institute of Standards and Technology –
американский национальный институт стандартизации, аналог
отечественного Госстандарта.
В его составе функционирует компетентный и имеющий серьезный
вес в США центр по компьютерной безопасности CSRC,
объединяющий специалистов федеральных служб, университетов,
крупнейших ИТ-компаний США.
Центр публикует с начала 1990-х годов Стандарты (FIPS) и более
детальные разъяснения/рекомендации (Special Publications) в
области информационной безопасности.
Специальные публикации (Special Publications, SP) 800 серии,
представляющие собой рекомендации, руководства, технические
спецификации и ежегодные отчеты по вопросам
информационной безопасности в рамках компетенций NIST ;
Специальные публикации (Special Publications, SP) 1800 серии,
содержащие практические советы и решения по
кибербезопасности, наглядно демонстрирующие применение
стандартов и лучших практик .

43.

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

44.

SP 800-213 "IoT Device Cybersecurity Guidance for the Federal Government:
Establishing IoT Device Cybersecurity Requirements“
SP 800-60 Классификация информации и информационных систем по
требованиям к безопасности методика классификатор
Методика присвоения и классификатор (рекомендуемые значения) уровней влияния
нарушения конфиденциальности, целостности и доступности в зависимости от вида
(назначения) обрабатываемой информации.
SP 800-118 Управление паролями
Существующие угрозы при использовании парольной аутентификации, обеспечение
безопасности хранения парольной базы, атаки социальной инженерии.
SP 800-37 Управление рисками ИБ в федеральных информационных системах
Детализированная методика управления рисками ИБ, роли и зоны ответственности
участников процесса, описание сопутствующих документов.
SP 800-34 Планирование обеспечения непрерывности в федеральных
информационных системах
Взаимосвязь различных уровней обеспечения непрерывности, оценка влияния
различных видов инцидентов на сервис, выбор стратегий, разработка и тестирование
планов, основные технологии обеспечения непрерывности функционирования
информационных систем и сервисов
Управление информационной безопасностью

45.

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

46.

47.

NIST Special Publication 800-53 “Security and Privacy
Controls for Federal Information Systems and
Organizations”
Abbr
Control family
Адаптированный перевод
AT
Awareness and Training
Осведомлённость и обучение
AU
Audit and Accountability
Аудит и отчётность
CA
Security Assessment and Authorization
Авторизация и оценка безопасности
CM
Configuration Management
Управление конфигурацией
CP
Contingency Planning
Планирование непрерывности бизнеса
IA
Identification and Authentication
Идентификация и аутентификация
IR
Incident Response
Реагирование на инциденты
MA
Maintenance
Обслуживание/техническая поддержка
MP
Media Protection
Защита носителей информации
PE
Physical and Environmental Protection
Защита от бедствий и физическая безопасность
PL
Planning
Планирование
PS
Personnel Security
Безопасность персонала
RA
Risk Assessment
Оценка рисков
SA
System and Services Acquisition
Приобретение систем и сервисов
SC
System and Communications Protection
Защита систем и коммуникаций
SI
System and Information Integrity
Целостность систем и информации
PM
Program Management
Управление программой ИБ

48.

49.

Контроли безопасности согласно NIST Special Publication
800-53
1. Common.
Основные контроли, которые могут наследоваться
различными системами и имеют воздействие вне масштабов
отдельно взятой ИС. Система наследует контроль
безопасности в случае, если он осуществляет свою функцию
безопасности в этой ИС, однако был разработан, реализован,
оценен, авторизован вне этой ИС.
2. System-specific
Контроль находится в зоне ответственности владельцев
конкретной ИС.
3. Hybrid
Часть контроля функционирует в качестве общего, а часть в
качестве системного контроля. Например, контроль IR-1
может определять политики реагирования на инциденты в
масштабах всей организации, однако конкретные процедуры
реагирования определяются для отдельных систем.

50.

Контроли NIST 800-53 и ISO 27001
Таблица 1. Слева представлены контроли ISO 27001, справа
соответствующие им контроли из NIST 800-53
Таблица 2. Обратное соответствие:

51.

Многоуровневое управление рисками по
NIST SP 800-53, NIST SP 800-30
В процессе управления рисками рассматриваются три уровня,
действующих в различном масштабе (Рис. 1):
Уровень 1: Организация
Уровень 2: Миссия, Бизнес процессы
Уровень 3: Информационные системы

52.

Многоуровневое управление рисками по
NIST SP 800-53
Уровень 1
Предоставляет возможность определения приоритетов бизнес задач и функций организации,
которые выливаются в инвестиционную стратегию и решения по бюджетированию, тем самым
обеспечивая финансово-выгодные («cost-effective») и эффективные ИТ решения,
соответствующие требованиям производительности, а также целям и задачам организации.
Уровень 2 включает:
1. Определение бизнес-процессов, необходимых для обеспечения бизнес задач и функций
организации;
2. Определение категорий безопасности выделенных информационных систем, необходимых
для исполнения бизнес-процессов;
3. Включение требований ИБ в бизнес-процессы;
4. Выбор ИТ архитектуры (включая ИБ) для способствования реализации требований ИБ в
информационных системах организации и среде их функционирования.
Уровень 3
Для обработки рисков на уровне информационных систем используется Risk Management
Framework (или сокращённо RMF) — набор инструментов по управлению рисками,
представленный на Рис. 2.
Этот Фреймворк является одним из основополагающих и связующих звеньев многих публикаций NIST,
посвящённых тематике информационной безопасности, ИТ и управления рисками.
Более подробно информация о его внедрении представлена в документе NIST SP 800-37. Публикация
NIST SP 800-53 (и соответственно весь цикл этих статей) посвящена в частности второму шагу
RMF: выбору контролей безопасности.

53.

Рисунок 2. Risk Management Framework

54.

RISK MANAGEMENT FRAMEWORK
Шаг 1. Категорирование ИС основываясь на FIPS Publication 199
«оценка угроз»;
Шаг 2. Выбор набора исходных контролей безопасности,
основываясь на результатах категорирования ИС, и применение
руководства по «подгонке» («tailoring») *адаптация*;
Шаг 3. Внедрение контролей безопасности, документирование
процессов проектирования, разработки и реализации контролей;
Шаг 4. Оценка контролей безопасности для определения того, в
какой степени контроли корректно внедрены, работают как
положено, и предоставляют необходимый результат в смысле
достижения требований ИБ, предъявляемых к ИС.
Шаг 5. Авторизация эксплуатации ИС, основывающаяся на рисках,
возникающих для организации, отдельных лиц и т.д. в результате
функционирования и использования ИС, и решении о принятии
этих рисков;
Шаг 6. Мониторинг контролей безопасности в ИС и среде
функционирования на постоянной основе для определения
эффективности контролей, необходимости изменений ИС и среды
функционирования и соответствия требованиям законодательства.

55.

Определение критичности ИС по NIST
Методика FIPS Publication 199 «Standards for Security
Categorization of Federal Information and Information
Systems»
В процессе подготовки к выбору подходящего базового
набора контролей безопасности для ИС организации и
их среды функционирования прежде всего необходимо
произвести определение критичности информации,
которая будет обрабатываться, храниться или
передаваться этими ИС.
Этот процесс в документах NIST называется
категоризацией ИС и описан в документе FIPS
Publication 199 «Standards for Security Categorization of
Federal Information and Information Systems».

56.

Методика FIPS Publication 199 «Standards for Security
Categorization of Federal Information and Information
Systems»
В основе категоризации лежит оценка возможного
негативного воздействия на ИС. Результаты этого процесса
позволяют отобрать необходимые контроли безопасности для
адекватной защиты ИС, выбрав соответствующий базовый
набор мер.
Выделяются три уровня потенциального воздействия утраты
объекта безопасности на организацию и отдельные лица:
низкий, средний и высокий.
Потенциальное воздействие является
низким/средний/высоким, если –
утрата конфиденциальности, целостности, доступности
может привести к
ограниченному/значительному/критичному негативному
влиянию на деятельность организации, её активы и
отдельные лица.

57.

Конфиденциаль
ность
Целостность
Доступность
Информация о Среднее
контрактах
Среднее
Низкое
Системная
информация
Низкое
Низкое
Низкое
Оцениваемая
система
Среднее
Среднее
Низкое
Критичность
Среднее
Таблица 1. Категорий безопасности и критичности информации и
информационных систем

58.

NIST SP 800-30 standard for technical risk assessment
NIST SP 800-30 Стандарт для оценки рисков ИТ-инфраструктуры
Чтобы определить вероятность будущего неблагоприятного события, угрозы для ИТсистемы должны быть связаны с потенциальными уязвимостями и элементами управления
для ИТ-системы ( ИТ-риск менеджмент).
Воздействие соотносится с величиной вреда, который может быть вызван угрозой
применения уязвимости.
Уровень воздействия определяется потенциальными последствиями на ключевые бизнеспроцессы и создает относительную ценность для затронутых ИТ-активов и ресурсов
(например, чувствительность критичности компонентов и данных ИТ-системы).
Оценка риска по методологии включает в себя девять основных этапов:
Шаг 1 Характеристика системы
Шаг 2 Идентификация угроз
Шаг 3 Идентификация уязвимостей
Шаг 4 Контрольный анализ
Шаг 5 Определение правдоподобия
Шаг 6 Анализ воздействия
Шаг 7 Определение риска
Шаг 8 Контрольные рекомендации
Шаг 9 Документация результатов

59.

60.

61.

Preliminary Cybersecurity Framework

62.

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

63.

Фреймворк делится на 3 основных части:
1. Ядро (the Framework Core)
Ядро представляет собой набор действий или так называемых функций
(functions), категорий (categories) и подкатегорий (subcategories) и
информативных ссылок по ИБ (informative references), общих для некоторого
набора критических ресурсов. Схематически ядро представлено в виде
таблицы:
Идентификация
Защита
Обнаружение
Реагирование
Восстановление

64.

Фреймворк делится на 3 основных части:
1. Ядро (the Framework Core)
Категории (categories) являются подразделами функций, например,
управление активами, контроль доступа, обнаружение вторжений.
Подкатегории (subcategories) представляют собой дальнейшее деление
Категорий, но не являются исчерпывающим набором активностей данной
Категории. Например: «физические активы организации подвергаются
инвентаризации», «сбор оповещений со всех систем ИБ производится
централизованно в единой системе».
Информативные ссылки (informative references) указывают на конкретные
разделы руководств, практик и стандартов, иллюстрирующие методы
выполнения конкретных работ по управлению рисками ИБ. Приводятся
ссылки на контроли безопасности из NIST SP 800-53 или ISO/IEC 27001:2013.

65.

Фрагмент первой функции “IDENTIFY - ID” - ИДЕНТИФИКАЦИЯ

66.

Фрагмент первой функции
“IDENTIFY - ID” - ИДЕНТИФИКАЦИЯ
Категория (category), рассматриваемая в данном примере,
представляет собой процедуру управления активами (Asset
Management - AM): персонал, устройства, системы и
поддерживающая инфраструктура - являются примерами активов,
с помощью которых компания достигает свои бизнес-цели и их
необходимо оценивать в соответствие со значимостью и рискстратегией.
Подкатегория (subcategory) представлена следующей структурой:
ID.AM-1: Физические устройства и системы
ID.AM-2: Программное обеспечение и платформы
ID.AM-3: Организационная коммуникация и упорядоченные
потоки данных
ID.AM-4: Внешние ИС и каталоги
ID.AM-5: Ресурсы, приоритезированные на основе показателей
критичности и бизнес-ценности ПО, аппаратуры, информации и
устройств.
ID.AM-6: Человеческие ресурсы, персонал и распределение
ответственности.

67.

Фрагмент второй функции “PROTECT-PR“ - ЗАЩИТА
Access Control (AC) – Управление доступом:
PR.AC-1: Элементы и сущности управляются для авторизованных
устройств и пользователей.
PR.AC-2: Физический доступ к устройствам контролируется и
является безопасным.
PR.AC-3: Удаленный доступ является контролируемым.
PR.AC-4: Разрешения на доступ осуществляется в соответствие с
политикой безопасности.
PR.AC-5: Сетевая целостность защищается.
Пример для элемента «PR.AC-1 Элементы и сущности управляются
для авторизованных устройств и пользователей» представлен в
таблице ниже.

68.

Фрагмент второй функции “PROTECT-PR“ - ЗАЩИТА
Awareness and Training (AT) – Осведомленность и обучение
Категории Awareness and Training (AT) – «Осведомленность и
обучение» пользователей соответствует требование международного
стандарта ISO/IEC 27 001, приложение А.8.2.2. «Осведомленность,
обучение и переподготовка в области информационной безопасности»,
а так же контроля по документу NIST SP 800-53 NIST Special
Publication 800-53 “Security and Privacy Controls for Federal Information
Systems and Organizations” AT-3.
Категория Awareness and Training (AT) – «Осведомленность и
обучение» содержит 5 подкатегорий, связанных с управлением
персоналом, разграничением зон ответственности и назначением ролей
пользователей.

69.

Фрагмент второй функции “PROTECT-PR“ - ЗАЩИТА
Data Security (DS) – Безопасность данных
Данная категория представлена процедурами управления информацией и записями для реализации
конфиденциальности, целостности и доступности такой информации. Подкатегории представлены девятью
элементами:
PR.DS-1: Защита данных в состоянии покоя.
Категории соответствует требование международного стандарта ISO/IEC 27 001, приложение А.15.1.3 Защита
учетных записей организации и А.15.1.4 Защита данных и конфиденциальность персональной информации.
PR.DS-2: Защита данных в процессе перемещения.
Категории соответствует требование международного стандарта ISO/IEC 27 001, приложение А.10.8.3 Защита
физических носителей при транспортировке.
PR.DS-3: Безопасность активов в момент утилизации, трансформации или модификации, перемещении.
Категории соответствует требование международного стандарта ISO/IEC 27 001, приложение А.9.2.7 Вынос
имущества с территории организации и А.10.7.2 Утилизация носителей.
PR.DS-4: Соответствующая способность гарантировать доступность активов и информации.
Категории соответствует требование международного стандарта ISO/IEC 27 001, приложение А.10.3.1 Управление
производительностью (Необходимо осуществлять прогнозирование, мониторинг и корректировку потребляемой
мощности системы для обеспечения требуемого уровня ее производительности).
PR.DS-5: Защита от утечки данных.
PR.DS-6: Защита интеллектуальной собственности.
PR.DS-7: Уничтожение незначимых (ненужных) активов.
PR.DS-8: В процессе системной разработки используется отдельная среда для тестирования.
Категории соответствует требование международного стандарта ISO/IEC 27 001, приложение А.10.1.4
Разграничение средств разработки, тестирования и эксплуатации (Средства разработки, тестирования и
эксплуатации должны быть разграничены в целях снижения риска несанкционированного доступа или изменения
операционной системы).
PR.DS-9: Защита сохранности и конфиденциальности личных и персональных данных.

70.

Фрагмент второй функции “PROTECT-PR“ - ЗАЩИТА
Information Protection Process and Procedures (IP) – Процедуры и процессы
защиты информации:
Maintenance (MA) – Поддержание работоспособности:

71.

Фрагмент третьей функции “DETECT-DE“- ОБНАРУЖЕНИЕ
Anomalies and Events (AE) – Выявление аномалий и событий ИБ:
Данная категория указывает на необходимость контроля и обнаружения аномалий и
событий ИБ с учетом критерия времени и потенциального воздействия на системы.
Подкатегории указывают на необходимость идентификации и управления ключевыми
бизнес-операциями, определения событий ИБ и соотнесения их с целями атак,
необходимости сбора и корреляции информации о кибербезопасности из различных
источников (примерами могут быть базы данных и шаблоны атак CAPEC, SCAP
перечни и др.), необходимости оценки потенциального влияния событий ИБ,
оповещения о границах и начале инцидента ИБ.

72.

Фрагмент третьей функции “DETECT-DE“- ОБНАРУЖЕНИЕ
Security Continuous Monitoring (CM) – Непрерывный мониторинг безопасности
Категория «Непрерывный мониторинг безопасности» представлен восьмью подкатегориями,
описывающими меры по мониторингу ИБ для информационных систем и активов для
определения событий кибербезопасности и верификации эффективности защитных мер.
Речь идет о мониторинге сетей (подкатегория DE.CM-1), физического окружения
(подкатегория DE.CM-2), активности пользователей (например, на основе систем UBA –
User Behaviour Analytics), а так же обнаружения и отслеживания вредоносной активности. К
данной категории так же относятся меры по обнаружению неавторизованного мобильного
кода, мониторингу провайдеров внешних сервисов, мониторингу неавторизованных
ресурсов и анализу уязвимостей.

73.

Фрагмент третьей функции “DETECT-DE“- ОБНАРУЖЕНИЕ
Detection Process (DP) – Процедура обнаружения

74.

Фрагмент четвертой функции “RESPOND - RS“ - РЕАГИРОВАНИЕ
Response Planning (RP.PL) – Планирование процедуры реагирования
Communications (CO) – Коммуникации
Analysis (AN) – Анализ
Mitigation (MI) – Уменьшение (смягчение)
Improvements (IM) – Улучшение

75.

Пятая функция “RECOVER - RC“ - ВОССТАНОВЛЕНИЕ
Recovery Planning (RP) – Планы восстановления
Improvements (IM) – Улучшения
Communications (CO) – Коммуникации
Процедуры восстановления систем после инцидентов ИБ обычно включают планы восстановления, сроки и
стратегии.
В состав процедуры восстановления может входить восстановление системы с образа, восстановление данных с
резервной копии, тестирование системы, выполнение правильных настроек.
Категория подразумевает заранее проработанные процедуры по различным вопросам в области компьютерной
безопасности, в частности, процедурам обеспечения непрерывности, процедурам восстановления после аварий,
процедурам резервного копирования данных. В некоторых случаях команда реагирования на инциденты (incident
response team) или ситуационный центр SOC (security operation center) должна быть готова к работе с широким
спектром возможных инцидентов.

76.

77.

Фреймворк делится на 3 основных части:
1. Ядро (the Framework Core)
2. Профили (the Framework Profile)
3. Уровни реализации (the Framework Implementation Tiers)