Описание угроз, возникающих в связи с построением СЗИ. Вопрос по модели угроз - Форум по вопросам информационной безопасности

Прошу подсказать ответ на один вопрос по модели угроз.

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

Составляю модель угроз. Определяю актуальные угрозы, а, соответственно, нужные технические и оргмеры. В ходе выясняется, что необходимо внедрить двухфакторную идентификацию/аутентификацию: чтобы пользователи входили по связке логин-пароль-(Touch Memory например).

Вопрос: как быть с потенциальной угрозой "Хищение персонального идентификатора", которая появится после создания СЗИ? Рассматривать ли данную угрозу в исходной модели угроз?

Я предполагаю рассматривать, но в описании каждой из такого рода угроз (хищение/утрата ПИ, хищение носителей с резервными копиями, отключение АМДЗ...) пояснить, что данная угроза появится после создания СЗИ. Возможно, даже разделить на два списка. Я прав?

Вот примерный перечень угроз (они в моей модели немного по другому звучат), которые возникают у меня с созданием СЗИ:
2.2. Хищение носителей с резервными копиями
2.5. Преднамеренный вывод из строя и порча носителей с резервными копиями
2.6. Преднамеренный вывод из строя и порча ПИ
2.11. Хищение ПИ, либо его компрометация в результате передачи иным лицам
2.12. Перехват идентифицирующей информации ПИ с использованием аппаратных закладок, прикрепляемых к внешней части порта ввода/вывода считывателя ПИ, в разрыв его кабеля или путем подмены
2.13. Несанкционированное отключение аппаратных элементов СЗИ (вплане АМДЗ сервера)
3.14. Преднамеренное отключение компонент, изменение настроек элементов СЗИ от НСД, модификация файлов (исполняемых файлов, библиотек и файлов конфигурации) СЗИ от НСД
5.3. Утрата ПИ (вплане потеря без хищения)
5.4. Непреднамеренное отключение компонент, изменение настроек элементов СЗИ
6.4. Выход из строя носителей с резервными копиями
6.5. Одновременный выход из строя неотчуждаемых носителей и носителей с резервными копиями
6.7. Выход из строя ПИ
6.8. Сбои и выход из строя элементов СЗИ (вплане ПО и аппаратных эл-тов)

Вариант с объединением угроз в "хищение идентификатора и пароля" например, не рассматривается.

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

У меня тонкие клиенты + сервак + категория 1 + > 100к записей.

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

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

Спасибо :)

Дмитрий | 27338, подскажите, пожалуйста о каком ГОСТе идет речь.

Я как делаю: нам МУ нужна сначала для аттестующей фирмы, потом -- для РКНа. Соответственно, я делаю модель угроз АС. В общих положениях поясняю, что _ИС_ является ИСПДн.

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

Перечень этих угроз расширяю угрозами:
- физического воздействия;
- сбоями (ПО+техсредства);
- стихийными бедствиями, техногенными авариями;
- некоторыми другими.

Все это разбиваю на логические группы, провожу экспертн. оценку по Методике опр. акт. угроз.

AIB | 27347

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

> модель угроз - это не мертвый документ на все времена
Тоже понятно) В идеале, получается надо:
- разработать первую модель угроз, определиться с необходимыми орг. и тех. мерами -- угрозы для СЗИ не рассматривать;
- внедрить предлагаемые орг. меры (инструкции, СРД в выделенные помещения), закупить техсредства и установить их.
- разработать вторую модель угроз с угрозами первой + их новой оценкой + угрозы СЗИ, определиться с необходимыми дополнительными орг. мерами;
- дополнить все инструкции и прочую ОРД новыми требованиями.
- потом отправить на аттестацию со второй МУ;
- потом в РКН?

Хотелось бы все это оформить в одним документом, т.к. угроз, связанных с СЗИ не очень много...

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

Проконсультируюсь с науч. руком. и возможно, сделаю 2. :)

Только, разумеется, не "две модели угроз", а две версии моделей угроз.

- Первая версия модели
- Внедрение мер
- Приказ "О пересмотре модели угроз"
- Вторая версия модели
- Внедрение орг. мер, закрывающих угрозы СЗИ

ГОСТ Р 51275-2006
Я бы не стал оценивать угрозы для АС по методике для ПД. Какой вред нанесет субъекту ПД, полное уничтожение ИСПДн, вместе с АС и зданием в котором оно размещалось? Мы же не в матрице? Меня поражает, как много специалистов по ИБ заявляют, что 90% ИСПДн требуют еще, что-то кроме конфиденциальности.

- Первая версия модели .....
...
- Внедрение орг. мер, закрывающих угрозы СЗИ

Физики плачут. Не надо так, а то нас всех уволят.

"нарушители в первой модели у меня очень много могут и не поддаются четкому категорированию."

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

Дмитрий, спасибо за ГОСТ.

> Какой вред нанесет субъекту ПД, полное уничтожение ИСПДн, вместе с АС и зданием в котором оно размещалось?
Если вреда нет, то и угроза не рассматривается как потенциальная.

> 90% ИСПДн требуют еще, что-то кроме конфиденциальности.
Конкретно наша требует (оказывается госуслуга).

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

В качестве примера меры.
Утверждение начальником конечного списка лиц, имеющих право доступа в серверное помещение, включающего лиц:
1) имеющих право самостоятельного доступа в серверное помещение;
2) имеющих право доступа в сервеное помещение под контролем лиц, имеющих право самостоятельного доступа в серверное помещение (это уборщица например).

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

Это пример контроля доступа в сервачную. Явно выделяются четко:
- лица, имеющие право самостоятельного доступа в серверную (относятся к внутренним);
- лица, имеющие доступ под контролем первых (относятся к внешним).

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

Что есть сейчас: ключи от серверной лежат на ящике в кабинете. Как классифицировать?

> Физики плачут. Не надо так, а то нас всех уволят.
Дмитрий, по 51275-2006, разве я могу в модель включить угрозу 6.2.1.5 например "Блокирование доступа к ресурсам АС вследствие ошибок обслуживающего персонала при эксплуатации средств и систем ЗИ"?

Если включу, то как оценить вероятность?