Методика оценки угроз безопасности информации: обзор методического документа ФСТЭК России

Введение

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

Какие задачи решает моделирование угроз

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

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

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

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

Как эти задачи решаются в мировой практике

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

Наиболее распространенный подход, принятый авторами методических документов (см., например, «A Taxonomy of Operational Cyber Security Risks» или «ENISA Threat Taxonomy») – привести классификацию (taxonomy) угроз и предоставить читателю самостоятельно решить, какие классы угроз актуальны для рассматриваемой ими информационной системы.

Для системы управления предприятием очевидна угроза, классифицируемая в таксономиях как «Fraud» (мошенничество). Очевидно также, что такую угрозу способен реализовать бухгалтер, трудовая функция которого включает в себя проведение платежные операции. Но может ли реализовать такую угрозу другой сотрудник организации или внешний нарушитель? Таксономия неспособна дать ответ на этот вопрос.

Более удачный пример классификации разработан Федеральным управлением по информационной безопасности Германии (Bundesamt für Sicherheit in der Informationstechnik, BSI). Авторы разработали всеобъемлющий (более 4700 страниц) каталог типовых объектов ИТ-инфраструктуры, характерных для них угроз и соответствующих им мер защиты («IT Grundschutz Catalogues», ранее известный как «IT Baseline Protection Manual»).

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

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

Еще более детальные сценарии реализации угроз можно построить методами «Cyber Kill chain», описанными в предыдущей статье. Основным источником сведений об угрозах, которые используются при таком моделировании, является база знаний MITRE ATT&CK.

Описанные выше методологии раскрывают информацию о типовых объектах ИТ-инфраструктуры, подверженных атакам нарушителя, и способах воздействия на них, но не описывают процесс моделирования угроз. Основной целью разработки методического документа ФСТЭК России являлось структурирование самого процесса моделирования угроз.

Процесс моделирования угроз в методическом документе ФСТЭК России

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

Согласно документу, моделирование угроз включает в себя решение следующих задач:

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

Рассмотрим эти задачи по отдельности.

Определение негативных последствий

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

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

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

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

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

К примерам негативных последствий, реально мотивирующих руководителей подразделений всерьез отнестись к вопросам безопасности, можно отнести:

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

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

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

Определение объектов воздействия

Перечень негативных последствий является отправной точкой для моделирования угроз. На втором этапе необходимо определить, воздействие на какие именно объекты может привести к наступлению таких последствий. Методический документ не детализирует, как именно должны определяться объекты воздействия, оставляя это на усмотрение эксперта, проводящего анализ уязвимостей. При этом:

• требуется использовать общий перечень угроз безопасности информации, опубликованный в банке данных угроз безопасности информации ФСТЭК России;
• наряду с ним требуется использовать низкоуровневые описания возможных способов воздействия, описанных в базах знаний CAPEC и Att&CK, а также в базах знаний типовых атак на веб-приложения WASC и OWASP.

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

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

1. Выбираем моделируемое негативное последствие, например – хищение денежных средств с расчетного счета предприятия.
2. Опрашиваем руководителей функциональных подразделений и определяем бизнес-процессы, в рамках которых выполняются платежные операции. К таким бизнес-процессам могут относиться оплата поставщикам, выплата заработной платы, оплата командировочных расходов, прямые финансовые операции и т. п.
3. Для каждого бизнес-процесса определяем какие именно операции могут быть скомпрометированы нарушителем для наступления моделируемого негативного последствия. Например, один из способов хищения денежных средств в бизнес-процессе выплаты заработной платы является добавление несуществующего работника в модуле кадрового администрирования.
4. Для каждой операции, которые могут быть скомпрометированы нарушителем, определяем компоненты информационной системы, которые используются при выполнении таких операций.
5. Для каждого такого компонента определяем, можно ли добиться моделируемого негативного последствия воздействием на такой объект. Так, нарушитель может добавить несуществующего работника, если получит контроль над сервером кадрового администрирования, сервер системы управления базами данных, который используется модулем кадрового администрирования, и т. п.

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

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

Финальный перечень объектов воздействия должен включать в себя как компоненты информационной системы, так и объекты ИТ-инфраструктуры предприятия.

Определение источников угроз безопасности информации

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

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

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

Вид нарушителя, в свою очередь, определяет уровень его возможностей. Методика определяет четыре уровня возможностей нарушителя: базовый (Н1), базовый повышенный (Н2), средний (Н3) и высокий (Н4). Подробное описание возможностей нарушителей разных уровней приведено в Приложении 8 методического документа. Вкратце их можно охарактеризовать следующим образом.

• Нарушитель уровня Н1 не является специалистом, он использует только известные уязвимости и бесплатные инструменты.
• Нарушитель уровня Н2 также использует только свободно распространяемые инструменты, но является специалистом. Он способен находить и использовать уязвимости нулевого дня на атакуемых объектах.
• Нарушитель уровня Н3 дополнительно к этому способен приобретать дорогостоящие инструменты и проводить лабораторные исследования по поиску уязвимостей нулевого дня в оборудовании и программных средствах, аналогичных используемым на атакуемых объектах.
• Нарушитель уровня Н4 способен внедрять программные и аппаратные закладки в серийно изготавливаемое оборудование и программное обеспечение, может использовать побочное электромагнитное излучение, наводки и скрытые каналы, умеет проводить долгосрочные APT-атаки и обладает неограниченными ресурсами.

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

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

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

Оценка способов реализации угроз

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

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

Угрозой признается возможной, если определяется нарушитель, целям которого соответствуют негативные последствия реализации угрозы, и возможности которого позволяют выполнить соответствующее воздействие. При этом вопрос «как нарушитель доберется до объекта воздействия» на этом этапе не рассматривается.

Оценка сценариев реализации угроз и актуальности угроз

Если угроза признается возможной, остается оценить может ли выбранный нарушитель практически реализовать угрозу, рассмотрев возможные сценарии реализации угрозы – последовательности тактик и техник действий нарушителя, посредством которой он мог бы из некоторого начального состояния получить возможности, необходимые для реализации угрозы. На практике это означает оценку того, может ли нарушитель из заданных стартовых условий “пройти” по ИТ-инфраструктуре организации и получить практическую возможность реализовать угрозу.

В соответствии с нормативными документами ФСТЭК России анализ угроз проводится на разных стадиях жизненного цикла информационной системы:

• на стадии создания системы;
• периодически на стадии эксплуатации системы.

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

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

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

Заключение

Подход к моделированию угроз, выбранный ФСТЭК России имеет свои достоинства и недостатки.

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

В то же время, сценарный подход к моделированию угроз требует от экспертов глубокого знания известных способов (техник, тактик) проведения компьютерных атак, а главное – времени. На рынке труда не так много специалистов, способных проводить анализ угроз с нужной степенью детализации, и это – общемировая проблема. Отчасти ее может облегчить автоматизация процесса, но только в части построения возможных сценариев. Как показывает практика, наиболее трудоемкой частью сценарного моделирования угроз является инвентаризация ИТ-инфраструктуры и анализ бизнес-процессов.

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

Сценарное моделирование угроз – один из первых шагов, который может позволить защищающейся стороне сократить отставание от атакующей. И, пожалуй, к главным достоинствам рассматриваемой методики можно отнести подталкивание специалистов по информационной безопасности к необходимости изучать основные информационные ресурсы по теме компьютерных атак и защиты от них, такие как MITRE ATT&CK и OWASP.

Автор:
Дмитрий Кузнецов, директор по методологии и стандартизации Positive Technologies.