О моделировании угроз



    Вопрос обеспечения информационной безопасности Государственных Информационных Систем не только не теряет актуальности, но с развитием концепции электронного правительства и увеличением количества электронных услуг, становится более значимым. Так, около месяца назад большой резонанс на Хабрахабре вызвала статья «И так сойдёт… или как данные 14 миллионов россиян оказались у меня в руках».

    Используя терминологию проекта документа «Методика определения угроз безопасности информации в ИС», эту ситуацию потенциально можно описать следующим образом:

    • Орган государственной власти, орган местного самоуправления и организация, являющихся в соответствии с законодательством Российской Федерации обладателями информации, заказчиками и (или) операторами информационных систем: Федеральная служба по надзору в сфере образования и науки.
    • Источник угроз НСД в ИСПДн: внешние субъекты (физические лица)
    • В качестве возможных целей (мотивации) реализации нарушителями угроз безопасности информации в информационной системе могут быть: любопытство или желание самореализации; выявление уязвимостей с целью их дальнейшей продажи и получения финансовой выгоды;
    • Для достижения своей цели нарушитель выбирает наиболее слабое звено информационной системы: «Для получение информации о документе об образовании достаточно просто заполнить форму, передвинуть слайдер и нажать кнопку.»
    • Анализ прав доступа проводится, как минимум, в отношении следующих компонент информационной системы: программных, программно-технических и технических средств обработки информации; каналов связи, выходящих за пределы контролируемой зоны: в этом кейсе была выявлена возможность SQL Injection.
    • Также оценке подлежат последствия реализации угрозы, в том числе экономические, социальные, политические и т. д. Для примера посмотрим, что относится к социальным последствиям: Появление негативных публикаций в общедоступных источниках. Невозможность (прерывание) предоставления социальных услуг (сервисов). Другие последствия, приводящие к нарастанию социальной напряженности в обществе.
    • Пересмотр (переоценка) угроз безопасности информации осуществляется как минимум в случаях: выявления уязвимостей, приводящих к возникновению новых угроз безопасности информации или к повышению возможности реализации существующих; появления сведений и фактов о новых возможностях нарушителей. Уязвимость была закрыта, сервис временно не работал.

    Как известно, требования по защите Государственных Информационных Систем (ГИС) регламентируются приказом ФСТЭК от 11 февраля 2013 г. N 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах».

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

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

    Формирование требований к защите информации, содержащейся в информационной системе, осуществляется с учетом ГОСТ Р 51583 «Защита информации. Порядок создания автоматизированных систем в защищенном исполнении. Общие положения» и ГОСТ Р 51624 «Защита информации. Автоматизированные системы в защищенном исполнении. Общие требования» и в том числе включает:

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

    Как мы видим, приказом №17 отдельно вынесено определение угроз безопасности, а проверяющие органы запрашивают при проверках документ, под названием «Модель угроз».

    Итак, попробуем разобраться с данным документом.

    Непосредственно разработка модели угроз должна основываться на следующих документах ФСТЭК:


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

    Подробнее о проекте документа «Методика определения угроз безопасности информации в ИС» можно прочитать на Хабре в статье "Документ, который ждали".

    Однако, возвращаясь 17-му приказу мы читаем следующее.
    Угрозы безопасности информации определяются по результатам оценки возможностей (потенциала) внешних и внутренних нарушителей, анализа возможных уязвимостей информационной системы, возможных способов реализации угроз безопасности информации и последствий от нарушения свойств безопасности информации (конфиденциальности, целостности, доступности).
    В качестве исходных данных для определения угроз безопасности информации используется банк данных угроз безопасности информации (bdu.fstec.ru), а также иные источники, содержащие сведения об уязвимостях и угрозах безопасности информации.
    А вот здесь возникает заминка, банк данных создан, есть программные продукты автоматизирующие анализ защищенности в соответствии с данным банком, а вот упоминания про этот банк в действующих документах «Базовой модели» и «Методиках определения актуальных угроз» нет.

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

    Что нужно определить и учесть согласно приказу:

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

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

    Про содержание документа «Модель угроз безопасности», процитирую 17 приказ, который от нас требует следующее:
    «Модель угроз безопасности информации должна содержать описание информационной системы и ее структурно-функциональных характеристик, а также описание угроз безопасности информации, включающее описание возможностей нарушителей (модель нарушителя), возможных уязвимостей информационной системы, способов реализации угроз безопасности информации и последствий от нарушения свойств безопасности информации.»
    В общем виде приведу пример перечня пунктов, закрывающих данные требования (под спойлером)
    Используемые сокращения
    Термины и определения
    1 Общие положения
    2 Описание информационной системы и особенностей ее функционирования
    3 Формирование модели нарушителей
    3.1 Типы и виды нарушителей
    3.2 Совокупность предположений о возможностях, которые могут использоваться при создании способов, подготовке и проведении атак
    3.3 Определение типа нарушителей
    4 Описание угроз безопасности информации
    4.1 Описание уязвимостей ИС, используемых при реализации угроз несанкционированного доступа
    4.2 Описание объектов воздействия угроз несанкционированного доступа
    4.3 Описание последствий от нарушения свойств безопасности информации
    4.4 Описание носителей ПДн, являющиеся элементом технического канала утечки информации
    4.5 Описание технических каналов утечки
    4.6 Перечень угроз безопасности информации
    5 Определение актуальности угроз безопасности информации
    5.1 Определение уровня исходной защищенности информационной системы
    5.2 Определение актуальности угроз
    6 Заключение

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

    Естественно, если функции безопасности возложены не на системного администратора, такому специалисту в большинстве случаев потребуется помощь от знающих данную систему людей. Но наши реалии в большинстве случаев показывают, что заниматься всеми этапами приведения в соответствие с законодательством информационных систем приходится именно системным администраторам. Конечно, в крупных организациях в большинстве своем есть соответствующие штатные единицы, ответственные за безопасность. А если позволяет бюджет, то нанимаются специализированные организации, имеющие лицензии на соответствующий вид деятельности.
    Cloud4Y 169,98
    #1 Корпоративный облачный провайдер
    Поделиться публикацией
    Комментарии 3
    • 0
      Прочитал указанные документы ФСТЭК. Похоже, что их в тюрьме, от нечего делать, писал Митник. Самый свежак угроз — 2003 год.
      • 0
        В четверг был на конференции одной — раздавали двухтомник по компьютерной безопасности — int13 и прочие опасности досовских вирусов
      • 0
        Зачем ссылаться на проект документа 2015 года, который так и не утвержден?

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

        Самое читаемое