Разрабатываем модель угроз и нарушителя для обеспечения безопасности коммерческой системы
Сегодня, наш системный аналитик Алина поделится опытом применения требований информационной безопасности в рамках проектирования коммерческой системы. В статье разберемся, что это такое и зачем нужно.
Первый и самый логичный вопрос, который возникает, когда видишь этот документ в списке требований от Заказчика.
Сначала пойдем простым путем и поищем определение на просторах интернета. Как итог – определение Роскомнадзора используется практически везде. Звучит оно так:
Модель угроз и нарушителя – это «совокупность предположений о возможных угрозах и возможностях нарушителя, которые он может использовать для разработки и проведения атак в рамках разрабатываемой системы».
Теперь разберёмся с основной целью написания документа (оставлю небольшую ремарку: в целом, модель нарушителя – это больше описание «бумажной безопасности»).
Для более точного понимания обратимся к нормативной документации, а именно – методике Федеральной службы по техническому и экспортному контролю (ФСТЭК). Получим следующее определение:
«Целью моделирования угроз безопасности информации является выявление совокупности условий и факторов, которые приводят или могут привести к нарушению безопасности обрабатываемой в системах и сетях информации (нарушению конфиденциальности, целостности, доступности, неотказуемости, подотчетности, аутентичности и достоверности информации и т.д., а также к нарушению или прекращению функционирования систем и сетей)»
Если вы впервые сталкиваетесь с требованиями информационной безопасности, то скорее всего вам будет «очень интересно, но ничего непонятно».
Будем проще – данная модель содержит перечень возможных нарушителей, которые могут скомпрометировать/навязать/испортить информацию в разрабатываемой системе; список угроз в соответствии с классом вашей системы и описание некоторых последствий, которые могут появиться, если нарушитель все-таки украдет вашу информацию.
С моей точки зрения, необходимо сделать небольшое формальное отступление и перечислить ФЗ, которые, как раз-таки, регламентируют написание данного документа:
- Федеральный закон от 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-м приказом ФСТЭК.
Было полезно? Будем рады получить обратную связь и узнать о вашем опыте в этом вопросе ✌