О моделировании угроз01.03.2018 10:33

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

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

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

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

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

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

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

В контексте данной статьи нас будет в первую очередь интересовать этап формирования требований к защите.

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

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

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

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

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

• «Базовая модель угроз безопасности персональных данных при их обработке в информационных системах персональных данных», Федеральная служба по техническому и экспортному контролю, 2008 год
• «Методика определения актуальных угроз безопасности персональных данных при их обработке в информационных системах персональных данных», Федеральная служба по техническому и экспортному контролю, 2008 год.

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

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

Однако, возвращаясь 17-му приказу мы читаем следующее.

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

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

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

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

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

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

Про содержание документа «Модель угроз безопасности», процитирую 17 приказ, который от нас требует следующее:

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

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

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

© Habrahabr.ru