{"id":13643,"url":"\/distributions\/13643\/click?bit=1&hash=a8215ceddd252b2083ce5ad9aec744ff1eefa9bc3de1c4cbfdb18016cc439e99","title":"\u0412\u044b\u0431\u0435\u0440\u0438\u0442\u0435\u0441\u044c \u0438\u0437 \u043b\u043e\u0432\u0443\u0448\u043a\u0438 \u00ab\u043c\u043d\u043e\u0433\u043e\u0440\u0443\u043a\u043e\u0433\u043e \u0428\u0438\u0432\u044b\u00bb","buttonText":"\u041a\u0430\u043a?","imageUuid":"6f999284-e19c-51a5-b74d-c3d432185ecb","isPaidAndBannersEnabled":false}
IT-образование
CodeInside

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

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

«Что такое модель угроз и нарушителя?»

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

Сначала пойдем простым путем и поищем определение на просторах интернета. Как итог – определение Роскомнадзора используется практически везде. Звучит оно так:

Модель угроз и нарушителя – это «совокупность предположений о возможных угрозах и возможностях нарушителя, которые он может использовать для разработки и проведения атак в рамках разрабатываемой системы».

Теперь разберёмся с основной целью написания документа (оставлю небольшую ремарку: в целом, модель нарушителя – это больше описание «бумажной безопасности»).

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

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

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

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

Нормативно-методическая база

С моей точки зрения, необходимо сделать небольшое формальное отступление и перечислить ФЗ, которые, как раз-таки, регламентируют написание данного документа:

  • Федеральный закон от 27.07.2006 года № 149-ФЗ «Об информации, информационных технологиях и о защите информации» (ред. от 09.03.2021);
  • Федеральный закон от 27.07.2006 года № 152-ФЗ «О персональных данных»;
  • Требования к защите персональных данных при их обработке в информационных системах персональных данных, утвержденные постановлением Правительства Российской Федерации от 01.11.2012 г. № 1119;
  • Требования к защите автоматизированных систем управления субъектов критической информационной инфраструктуры – в соответствии с положениями Федерального закона от 26.07.2017 г. № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»;

Итак, я думаю, что со списком ФЗ тоже все понятно.

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

Содержание модели угроз

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

Для того, чтобы понять, что конкретно должно содержаться в модели, обратимся снова к нормативным документам ФСТЭКа, а именно к 17 приказу.

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

Вы не поверите, но это все. С другой стороны, хоть требование и небольшое, оно довольно содержательное.

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

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

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

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

  • описание информационной системы – тут все достаточно тривиально – необходимо привести назначение, цели создания системы, предполагаемую структуру/архитектуру. Также здесь есть раздел «Охрана помещений». Тут описываем, как охраняются помещения в рабочее и внерабочее время и т.д.;
  • описание угроз безопасности – если коротко, то здесь нужно именно копипастить текст из БДУ (база угроз ФСТЭК), потому что в модели угроз должно быть «описание угроз», отделаться идентификаторами не получится;
  • модель нарушителя – здесь можно разделить эту часть на классическую и новую. Классическая – это та самая, где описаны потенциальные нарушители 1, 2 и далее категорий. Практическую же ценность представляет раздел «Нарушители согласно банку данных угроз ФСТЭК России». Раздел представляет ценность так как сами угрозы из банка данных угроз ФСТЭК привязаны к нарушителям с низким, средним и высоким потенциалом;
  • возможные уязвимости – в данном разделе необходимо перечислить возможные классы уязвимостей для конкретной информационной системы. А чтобы придать этому списку солидности, возьмем этот список не из головы, а из ГОСТ Р 56546-2015 «Защита информации. Уязвимости информационных систем. Классификация уязвимостей информационных систем»;
  • способы реализации угроз – в этом разделе необходимо описать возможные способы, как программные, так и аппаратные;
  • последствия от нарушения свойств безопасности информации – назвали этот раздел именно так, потому что, по сути, по определению опасности угроз, это является определением последствий. Итак, опасность угроз может быть низкой, средней или высокой, в зависимости от этого, незначительные негативные, просто негативные или же значительные негативные последствия наступают при реализации угрозы соответственно. Специалисты здесь часто спорят – должна ли опасность угроз определяться один раз и быть константой для всех угроз или же нет. Методикой это не оговорено, поэтому можно и так, и так. Наш подход промежуточный – мы определяем опасность угроз в зависимости от нарушения конфиденциальности, целостности или доступности при реализации конкретной угрозы.

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

Выводы

  • определяем классы защищаемой информации в разрабатываемой системе;
  • корректируем требования для дальнейшей разработки с учетом «хотелок» ФСТЭК;
  • составляем перечень нарушителей, которые могут нанести ущерб вашей системе (как внутренние, так и внешние);
  • не забываем про перечень возможных угроз в рамках вашей системы;
  • проводим оценку найденных уязвимостей (придется задуматься, как защититься);
  • получаем (бесценный!) опыт работы с 17-м приказом ФСТЭК.

Было полезно? Будем рады получить обратную связь и узнать о вашем опыте в этом вопросе ✌

0
Комментарии
Читать все 0 комментариев
null