Разное

Методика определения угроз безопасности информации в информационных системах: Обзор проекта новой методики моделирования угроз безопасности информации

Содержание

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

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

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

Как сейчас регулируется вопрос моделирования угроз?



Определение актуальных угроз безопасности информации требуется для самых разнообразных объектов: ИСПДН, ГИС, АСУ ТП, значимые объекты КИИ, ИС финансовых организаций (далее при совместном упоминании – «информационные системы»). Следовательно, обработка информации с использованием таких объектов требует четкого понимания кто (или что) и каким образом может стать причиной нарушения информационной безопасности.

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

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

Ключевые особенности новой методики

Область применения Методики

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

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

Использование БДУ ФСТЭК при моделировании угроз безопасности

Основным источником информации об угрозах станет БДУ ФСТЭК, а также базовые и типовые модели угроз безопасности. Если для значимых объектов КИИ и ГИС такой подход предполагался и ранее, то вопрос использования (или неиспользования) БДУ по отношению к ИСПДн теперь получил однозначный ответ.

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

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

Порядок моделирования угроз безопасности

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

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

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

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

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

Подробнее хочется остановиться непосредственно на порядке определения актуальности угроз безопасности.

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

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

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

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

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

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

Также необходимо обратить внимание, что согласно новой Методике, нарушитель может обладать одним из четырех уровней потенциала (базовый, базовый повышенный, средний и высокий), в то время как БДУ, при описании источника угроз, использует лишь 3 уровня (низкий, средний, базовый). Как правильно в этом случае обеспечить корреляцию – вопрос, который также остается без ответа.

4. На заключительном этапе осуществляется анализ возможных тактик и техник реализации угроз. Для определения возможных сценариев атак, Методика предлагает использовать приведенные в ней тактики и техники, а также дополнительную информацию из БДУ ФСТЭК или иных баз данных компьютерных атак (по всей видимости здесь имеются в виду матрица ATT&CK и аналогичные походы).

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

Выдержка из матрицы тактик и методик, представленной в документе:

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

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

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

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

Определение угроз безопасности для инфраструктуры, размещаемой на внешних хостингах

Особое внимание уделяется вопросу разделения ответственности при моделировании угроз для информационных систем, размещаемых во внешних ЦОД и облачных сервисах.

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

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

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

Поддержание модели угроз в актуальном состояние

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

Но перейдем к дальнейшим этапам жизненного цикла модели угроз. Подразумевается, что в течение всего периода эксплуатации информационной системы, модель угроз должна актуализироваться с учетом изменения требований законодательства, изменения архитектуры и условий функционирования системы, выявления новых угроз безопасности информации. Таким образом, обновление БДУ ФСТЭК должно повлечь за собой и обновление всех разработанных и используемых моделей угроз безопасности информации. С учетом того, что внесение изменений в БДУ событие относительно частое (от 1 до 3 раз в год, в соответствии с представленной в базе информацией), возвращаться к вопросу актуализации модели угроз придется регулярно.

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

Удалась ли новая Методика?

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

Из очевидных плюсов обновленной Методики стоит отметить:

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

Вместе с тем, при прочтении Методики отчетливо ощущается, что это лишь проект, а не финальная версия методического документа:

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

И что же дальше?

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

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

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

Владислав Павлов
Специалист отдела аудита и консалтинга, Акрибия

Информационное сообщение ФСТЭК России от 9 апреля 2020 г. N 240/22/1534

Информация о материале

Просмотров: 5416

+ 1 — 0

Оценить:

 

 

В соответствии с подпунктом 4 пункта 8 Положения о Федеральной службе по техническому и экспортному контролю, утвержденного Указом Президента Российской Федерации от 16 августа 2004 г. N 1085, ФСТЭК России разработан проект методического документа «Методика моделирования угроз безопасности информации».

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

Методический документ должен применяться совместно с банком данных угроз безопасности информации ФСТЭК России (bdu.fstec.ru).

В целях реализации положений методического документа планируется модернизация раздела «Угрозы» банка данных угроз безопасности информации ФСТЭК России (bdu.fstec.ru).

Проект указанного документа размещен на официальном сайте ФСТЭК России www.fstec.ru в разделе «Техническая защита информации/Документы/Проекты».

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

Предложения и замечания по проекту методического документа принимаются до 30 апреля 2020 г.

 

Заместитель директора

ФСТЭК России

В.Лютиков

 

 

N п/п

N пункта проекта Методики

Содержание замечания (предложения)

Предлагаемая редакция пункта проекта Методики

1

     

     

n

     

 

БДУ — Угрозы

Описание угрозы Угроза заключается в возможности внедрения и запуска вредоносного кода от имени доверенного процесса на любом из ресурсных центров грид-системы и его автоматического распространения на все узлы грид-системы.

Данная угроза обусловлена слабостями технологии грид-вычислений – высоким уровнем автоматизации при малой администрируемости грид-системы.

Реализация данной угрозы возможна при условии наличия у нарушителя привилегий легального пользователя грид-системы
Источники угрозы
  • Внутренний нарушитель со средним потенциалом
  • Внешний нарушитель со средним потенциалом
Объект воздействия Ресурсные центры грид-системы
Последствия реализации угрозы
  • Нарушение конфиденциальности
  • Нарушение целостности
  • Нарушение доступности

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

Кибербезопасность

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

Документ устанавливает единый методический подход к определению угроз безопасности информации и разработке моделей угроз безопасности информации в государственных информационных системах, защита информации в которых обеспечивается в соответствии с требованиями о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах, утвержденными приказом ФСТЭК России от 11 февраля 2013 г. N 17 (зарегистрирован Минюстом России 31 мая 2013 г., per. N 28608).

Методика не распространяется на определение угроз безопасности информации, составляющей государственную тайну.

Методика предназначена для:

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

Читать также: “О системе защиты национальных информационных ресурсов” >>

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

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

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

ФСТЭК предлагает специалистам в области информационной безопасности заинтересованных органов государственной власти и организаций рассмотреть проект методического документа и направить предложения по указанному проекту на адрес электронной почты [email protected]

Предложения и замечания принимаются до 10 июня 2015 года.

Читать также: “Особенности обеспечения безопасности информации в информационных системах органов местного самоуправления” >>

Эксперт по информационной безопасности Андрей Прозоров в своем блоге оценил документ как “неплохой”, однако отметил ряд недостатков. Прозоров подтвердил Экспертному центру электронного государства, что самыми заметными недостатками являются следующие.

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

Также Прозоров отмечает, что методический документ используется для оценки угроз информации в государственных ИС и может быть применен и для ПДн, при этом методика не распространяется на ГТ (об этом сказано в п.1 “общие положение”). Но почему-то нет отсыла к другим видам информации ограниченного доступа, в том числе “служебной тайны” / ДСП. Да, с термином есть сложности, но основной пользователь документа – госорганы, можно ли им использовать данный документ для защиты своей информации, не попадающей в ГосИС?

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

как скрестить ежа и ужа

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

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

В результате перед разработчиком модели угроз стоит выбор: либо сделать две модели нарушителя по разным методикам, либо пытаться объединить подходы обоих регуляторов в едином документе.

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

В связи с выходом новых документов ФСТЭК и ФСБ, интересно насколько сблизились подходы регуляторов к к описанию потенциальных нарушителей. Стала модель нарушителя более логичной?

Модель нарушителя по ФСТЭК

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

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

Нарушители со средним потенциаломимеют возможность проводить анализ кода прикладного программного обеспечения, самостоятельно находить в нем уязвимости и использовать их. К таким нарушителям ФСТЭК относит террористические и криминальные группы, конкурирующие организации, администраторов системы и разработчиков ПО.

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

Возможности нарушителей по ФСБ

Как уже говорилось выше, у ФСБ своя методика угроз, с криптосредствами и СФ 🙂 В недавно вышедших методических рекомендациях приводится 6 обобщенных возможностей нарушителей:
1) Возможность проводить атаки только за пределами КЗ;
2) Возможность проводить атаки в пределах КЗ, но без физического доступа к СВТ.
3) Возможность проводить атаки в пределах КЗ, с физическим доступом к СВТ.
4) Возможность привлекать специалистов, имеющих опыт в области анализа сигналов линейной передачи и ПЭМИН;
5) Возможность привлекать специалистов, имеющих опыт в области использования НДВ прикладного ПО;
6) Возможность привлекать специалистов, имеющих опыт в области использования НДВ аппаратного и программного компонентовсреды функционирования СКЗИ.

Эти возможности соответствуют классам криптосредств (СКЗИ). В зависимости от того, какую возможность мы признаем актуальной, необходимо использовать СКЗИ соответствующего класса. Подробнее это детализировано в другом документе — в приказе ФСБ №378.

Конкретных примеров нарушителей (террористы, конкуренты и т.д.) в своих новых документах ФСБ не дает. Но вспомним, что ранее были методические рекомендации ФСБ 2008 г.. В них то как раз рассказывалось о 6 типах нарушителей, которые обозначались как Н1- Н6. Возможности описанные в новых документах ФСБ соответствуют тем самым нарушителям Н1 — Н6 из старых методических рекомендаций.

Объединяем нарушителей ФСТЭК и ФСБ

Если прочесть описание возможностей нарушителя, то можно заметить, что оба регулятора уделяют внимание возможностям нарушителя по использованию НДВ. Сравнив описания нарушителей у ФСТЭК и ФСБ, получим примерно следующее:

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

Выбираем подходящих нарушителей и избавляемся от остальных

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

В случае государственной информационной системы, приглядимся к п.25 приказа ФСТЭК №17. В нем сказано:

В случае, если система не относится к ГИС, стоит взглянуть на три типа угроз из ПП 1119:

Угрозы 1 типа явно может использовать только нарушитель с высоким потенциалом. Угрозы 2 типа — нарушитель со средним потенциалом, а угрозы 3 типа — с низким. Поскольку большинство операторов рассматривают актуальными только угрозы 3 типа, то потенциал у нарушителей будет низкий.

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

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

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

Информационное сообщение о разработке проекта методики было зарегистрировано 09.04.2020. До 30 апреля был открыт сбор замечаний по проекту в указанной форме.

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

Сказать, что многие ждали новую методику, это не сказать ничего. Подобный документ был необходим, как «глоток свежего воздуха». В настоящий момент не существует документа, который разложит по полочкам знания для разработки модели угроз. Моё опасение, как аналитика, состоит в том, что и этот проект могут не утвердить, и всё так и останется в подвешенном состоянии. А интеграторам и сотрудникам ИБ в компаниях придется и дальше продолжать разрабатывать модель угроз по существующим методикам, одна из которых так и осталась проектом:
Что нового в методике?
1. Данная методика унифицирована, то есть рассчитана сразу на несколько видов информационных систем. В пункте 1.2. перечислены системы и сети, к которым может применяться настоящая методика:

  • персональные данные;
  • информационные (автоматизированные) системы;
  • автоматизированные системы управления;
  • информационно-телекоммуникационные сети, в том числе отнесенных к объектам критической информационной инфраструктуры Российской Федерации;
  • информационно-телекоммуникационные инфраструктуры;
  • центры обработки данных;
  • облачные инфраструктуры.

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

3. Ранее ФСТЭК России в проекте методики от 2015 года уже ссылался на БДУ . Так что в новом документе этот пункт был ожидаем.

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

5. Визуально этот проект методики стал понятнее, чем её неизданный предшественник. Текст стал менее витиеватым, а из-за разбиения на пункты стал более структурированным. По всему документу прослеживаются примеры.

6. В пункте 2.3 представлена схема проведения процесса моделирования угроз. В проекте методики от 2015 года тоже был перечень действий, которые необходимо было выполнить в соответствии с документом, однако в проекте методики от 2020 года разработан наиболее чёткий процесс моделирования. В схеме представлены исходные данные, необходимые для моделирования, этапы выполнения моделирования и, конечно, какой должен быть результат. Несмотря на то, что процесс моделирования рассмотрен схематически, он существенно упрощает понимание структуры документа и принципы построения модели угроз.

7. Проект от 2020 года выделяет зоны ответственности для операторов и поставщиков услуг в следующих категориях информационной инфраструктуры: ЦОД или облачная инфраструктура, принадлежащая поставщику услуг. Рекомендации по взаимодействию с поставщиком услуг представлены в пунктах 2.11-2.12. В настоящих пунктах рассмотрены несколько вариантов взаимодействия с поставщиком услуг.

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

9. Проект методики выделяет два этапа развития информационной инфраструктуры проверяемой компании:

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

Для каждого из этапов предусмотрен свой сценарий моделирования угроз безопасности.

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

Для систем и сетей, которые уже эксплуатируются в информационной инфраструктуре, ФСТЭК России предлагает оценивать возможность использования уязвимостей посредством тестирования на проникновение в периметр компании.

10. Методика рассматривает следующие источники угроз:

  • техногенные источники;
  • антропогенные источники.

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

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

11. В новом проекте регулятор разработал таблицу с целями нарушителей, в которой отразил большее количество возможных мотивов (целей). В пункте 5.7 был представлен перечень действий, необходимых для фиксации в модели нарушителя. Также ФСТЭК России предложил в документе пример основных видов тактики и соответствующие им техники, применяемых нарушителем при реализации угроз безопасности информации: при моделировании угроз теперь необходимо проводить оценку возможности реализации нарушителем тактик и соответствующих им техник, в соответствии с предложенным примером. Тактики и техники (способы) реализации можно соотнести с угрозами из БДУ ФСТЭК. При определении сценариев атак мы сможем перебрать большее количество потенциально опасных событий и избежать их наступления.

12. При моделировании угроз, уровень опасности угрозы определяется на основании оценки нескольких показателей:

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

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

Для перечисления актуальных угроз ФСТЭК установил формат описания, в который включил следующие значения:

  • идентификатор;
  • наименование;
  • описание;
  • сценарии;
  • уровень опасности.

13. Еще одним интересным нововведением стало Приложение № 3, в котором регулятор привел пример структуры документа: Модель угроз безопасности информации.

Итоги
После рассмотрения методики, хотелось бы подвести итоги:

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

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

Автор: Анастасия Голдобина,  Руководитель отдела аналитики ГК Axxtel

Наш блог на Яндекс.Дзен

информационная безопасность
модель угроз
ФСТЭК России

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

Поделиться новостью:

Разработка Модели угроз, или Как одолеть “Джомолунгму” информационной безопасности? Кто такая МУ и почему ею интересуются ФСБ и ФСТЭК

Будь благословен Федеральный закон “О персональных данных”! Сколько увлекательных вечеров благодаря нему проводят сотрудники разных компаний за подготовкой к радушной встрече с инспекторами Роскомнадзора, ФСТЭК и ФСБ. О глобальной режиссуре этого сейшена мы уже писали. Теперь давайте разбираться с “бумажными” деталями. Один из обязательных пунктов программы — разработка так называемой “модели угроз” (МУ).

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

Итак:

Что она, вообще, такое, эта загадочная МУ, и для чего она нужна?

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

С помощью грамотных МУ можно повысить уровень ИБ и даже затраты на защиту оптимизировать, сосредоточившись на самых вероятных угрозах.

В общем, модель угроз — штука хорошая, полезная. И закон говорит, что без нее никак. Необходимость разработки этого документа законодательно закреплена вот здесь:

  1. Часть 2 статьи 19 закона №152-ФЗ «О персональных данных»: «Обеспечение безопасности персональных данных достигается, в частности: 1) определением угроз безопасности персональных данных при их обработке в информационных системах персональных данных».
  2. Приказы ФСТЭК 21, 17, 31 и 239 определяют, что формирование требований к защите информации должно основываться на определении угроз безопасности.

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

Модель угроз применяют при решении разных задач:

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

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

*

Содержание МУ

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

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

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

Кроме этого, в модели угроз должны присутствовать:

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

Теперь остановимся на некоторых пунктах чуть подробнее.

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

А контролируемая зона — это пространство (территория, здание, часть здания, помещение), в которое “дяде Феде” и любым другим персонажам с улицы вход заказан. Такой запрет касается не только посторонних лиц, но еще и транспортных, технических и других материальных средств.

Возвращаясь к пункту о нормативно-методических документах, на основании которых должна быть разработана Модель угроз, перечисляем эти самые документы:

  1. Базовая модель угроз безопасности персональных данных при обработке в информационных системах персональных данных (далее – ИСПДн).
    https://fstec.ru/component/attachments/download/289
  2. Методика определения актуальных угроз безопасности персональных данных при их обработке в ИСПДн.

    https://fstec.ru/component/attachments/download/290
  3. Состав и содержание организационных и технических мер по обеспечению безопасности персональных данных при их обработке в ИСПДн.

    https://fstec.ru/component/attachments/download/561
  4. Методический документ. Меры защиты информации в государственных информационных системах (если речь идёт о ГИС).

    https://fstec.ru/component/attachments/download/675

*

Враг: найти и обезвредить

Один из этапов разработки Модели угроз — создание Модели нарушителя безопасности. И тут наш скучный “бумажный” сюжет принимает практически детективный оборот. Художественный портрет нам, конечно, вряд ли понадобится, а вот классификация нарушителей — обязательно. В этом вопросе должна быть полная ясность.

По наличию права постоянного или разового доступа в контролируемую зону ИСПДн, нарушителей подразделяют на два типа:

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

Берем из базовой Модели угроз https://fstec.ru/component/attachments/download/289 список возможных нарушителей безопасности и определяем, кто из них может относиться к рассматриваемой ИСПДн. После этого переходим к определению актуальных угроз, которые могут реализовать установленные нами категории нарушителей.

*

По-настоящему опасно

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

Технические и эксплуатационные характеристики ИСПДн Уровень защищенности
Высокий Средний Низкий
По территориальному размещению
Распределенная ИСПДн, которая охватывает несколько областей, краев, округов или государство в целом +
Городская ИСПДн, охватывающая не более одного населенного пункта (города, поселка) +
Корпоративная распределенная ИСПДн, охватывающая многие подразделения одной организации +
Локальная (кампусная) ИСПДн, развернутая в пределах нескольких близко расположенных зданий +
Локальная ИСПДн, развернутая в пределах одного здания +
По наличию соединения с сетями общего пользования
ИСПДн, имеющая многоточечный выход в сеть общего пользования +
ИСПДн, имеющая одноточечный выход в сеть общего пользования +
ИСПДн, физически отделенная от сети общего пользования +
По встроенным (легальным) операциям с записями баз персональных данных
Чтение, поиск +
Запись, удаление, сортировка +
Модификация, передача +
По разграничению доступа к персональным данным
ИСПДн, к которой имеет доступ определенный перечень сотрудников организации, являющейся владельцем ИСПДн, либо субъект ПДн +
ИСПДн, к которой имеют доступ все сотрудники организации, являющейся владельцем ИСПДн +
ИСПДн с открытым доступом +
По наличию соединений с другими базами ПДн иных ИСПДн
Интегрированная ИСПДн (организация использует несколько баз ПДн ИСПДн, при этом организация не является владельцем всех используемых баз ПДн) +
ИСПДн, в которой используется одна база ПДн, принадлежащая организации — владельцу данной ИСПДн +
По уровню обобщения (обезличивания) ПДн
ИСПДн, в которой предоставляемые пользователю данные являются обезличенными (на уровне организации, отрасли, области, региона и т.д.) +
ИСПДн, в которой данные обезличиваются только при передаче в другие организации и не обезличены при предоставлении пользователю в организации +
ИСПДн, в которой предоставляемые пользователю данные не являются обезличенными (т.е. присутствует информация, позволяющая идентифицировать субъекта ПДн) +
По объему ПДн, которые предоставляются сторонним пользователям ИСПДн без предварительной обработки
ИСПДн, предоставляющая всю БД с ПДн +
ИСПДн, предоставляющая часть ПДн +
ИСПДн, не предоставляющие никакой информации +

Теперь включим энтузиазм на полную и попробуем разобраться с этой увлекательной таблицей.

Вот смотрите: каждой характеристике соответствует высокий, средний или низкий уровень защищенности. Нам нужно посчитать процент характеристик с разными уровнями защищенности. Если «высокий» и «средний» набрали 70% и выше, значит уровень исходной защищенности средний (Y1 = 5), если меньше 70%, то – низкий (Y1 = 10).

Второй параметр для определения актуальных угроз — Y2 (он же вероятность реализации угрозы) — может принимать такие значения:

0 – для маловероятной угрозы;

2 – для низкой вероятности угрозы;

5 – для средней вероятности угрозы;

10 – для высокой вероятности угрозы.

Из этих двух параметров определяется коэффициент реализуемости угрозы Y. Вычисляется он по формуле: Y = (Y1+Y2) / 20. В зависимости от полученного значения угроза относится к низкой, средней или высокой.

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

Перечень угроз есть в базовой модели угроз. Помимо нее существует база угроз безопасности, но ничто не мешает вам дополнить список собственными вариантами угроз. “Режиссерская версия”, так сказать.

*

Финальные “аккорды”

Отдельная глава в нашем суровом “романе об угрозах” — модель угроз безопасности ПДн при их обработке с использованием средств криптографической защиты информации (СКЗИ, это сфера интересов ФСБ России). Определяем в ней на основе модели нарушителя и угроз, относящихся к СКЗИ, класс криптографической защиты информации.

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

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

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

Если у вас остались какие-то вопросы (наверняка!), обязательно свяжитесь с нашей “группой оперативного реагирования”. Пароли, явки:
[email protected]; 8 (495) 983-04-12, 8 (800) 707-04-12.

Разработать модель угроз

Лучшие практики и методологии для безопасного SDL (LifeCycle)

В наши дни безопасность приложений может улучшить или разрушить целые компании. Так как же лучше защитить свой продукт?

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

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

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

Что такое жизненный цикл безопасной разработки (SDL)?

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

Каковы преимущества SDL?

Наиболее важными причинами для внедрения практики SDL являются:

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

SDL также имеет ряд дополнительных преимуществ, например:

  • Команды разработчиков проходят непрерывное обучение методам безопасного кодирования.
  • Подходы к безопасности становятся более единообразными в разных командах.
  • Клиенты доверяют вам больше, потому что видят, что их безопасности уделяется особое внимание.
  • Внутренняя безопасность улучшается, когда SDL применяется к внутренним программным средствам.

Каковы лучшие практики SDL?

Прежде чем мы обсудим, как добавить практики SDL в разработку программного обеспечения, давайте рассмотрим типичные рабочие процессы разработки.

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

Рис. 1. Цикл разработки Waterfall

В отличие от этого, гибкий рабочий процесс проходит через множество циклов, каждый из которых содержит один и тот же набор этапов:

Рис. 2. Цикл гибкой разработки

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

  1. Концепция и планирование
  2. Архитектура и дизайн
  3. Реализация
  4. Тестирование и исправление ошибок
  5. Выпуск и обслуживание
  6. Окончание срока службы

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

В следующих разделах мы даем обзор этих этапов разработки программного обеспечения и соответствующие рекомендации SDL.

1. Концепция и планирование

Целью этого этапа является определение концепции приложения и оценка его жизнеспособности. Это включает в себя разработку плана проекта, написание требований к проекту и распределение человеческих ресурсов.

Практики SDL, рекомендованные для этого этапа, включают:

  • Обнаружение SDL
    Обнаружение SDL начинается с определения целей безопасности и соответствия для вашего проекта.Затем выберите методологию SDL и напишите подробный план соответствующих действий SDL. Это гарантирует, что ваша команда решит проблемы безопасности как можно раньше.
  • Требования безопасности
    Подготовьте список требований безопасности для вашего проекта. Не забудьте включить как технические, так и нормативные требования. Наличие этого списка помогает легко определить и исправить потенциально несоответствующие области вашего проекта.
  • Тренинг по вопросам безопасности
    Учебные занятия предоставляют важные знания в области безопасности, начиная от базовых знаний об угрозах и заканчивая подробной информацией о безопасной разработке.Базовый тренинг по безопасности формирует у всех участников проекта образ мыслей о безопасности. На продвинутых курсах ключевые участники проекта учатся принципам безопасного проектирования.

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

2. Архитектура и дизайн

Цель этого этапа — разработать продукт, отвечающий требованиям.Это включает моделирование структуры приложения и сценариев его использования, а также выбор сторонних компонентов, которые могут ускорить разработку. Результатом этого этапа является дизайн-документ.

Практики SDL, рекомендованные для этого этапа, включают:

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

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

3. Реализация

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

Практики SDL, рекомендованные для этого этапа, включают:

  • Безопасное кодирование
    Руководства и контрольные списки напоминают программистам о типичных ошибках, которых следует избегать, таких как хранение незашифрованных паролей.Применение принципов безопасного кодирования устраняет многие тривиальные уязвимости и освобождает время для других важных задач.
  • Статическое сканирование
    Инструменты статического сканирования приложений (SAST) просматривают вновь написанный код и находят потенциальные слабые места без необходимости запуска приложения. Ежедневное использование инструментов статического сканирования позволяет выявить ошибки еще до того, как они появятся в сборках приложений.
  • Проверка кода
    Хотя автоматическое сканирование экономит много усилий, ручная проверка кода по-прежнему необходима для создания безопасных приложений.Своевременные проверки помогают разработчикам отмечать и устранять потенциальные проблемы, прежде чем они переключат внимание на другие задачи.

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

4. Тестирование и исправление ошибок

Цель этого этапа — обнаружение и исправление ошибок приложения. Это включает в себя выполнение автоматических и ручных тестов, выявление проблем и их устранение.

Практики SDL, рекомендованные для этого этапа, включают:

  • Динамическое сканирование
    Инструменты динамического сканирования приложений (DAST) выявляют уязвимости, моделируя хакерские атаки во время выполнения.Чтобы уменьшить количество ложных срабатываний, вы можете использовать комбинированный подход (IAST). Этот подход дополняет сканирование во время выполнения мониторингом выполняемого кода и потока данных приложения. Помимо обнаружения обычных уязвимостей, динамическое сканирование выявляет ошибки конфигурации, которые влияют на безопасность.
  • Фаззинг
    Фаззинг-тестирование включает в себя генерацию случайных входных данных на основе пользовательских шаблонов и проверку того, может ли приложение правильно обрабатывать такие входные данные. Инструменты автоматического фаззинга улучшают защиту от атак, использующих искаженные входные данные, например SQL-инъекций.
  • Тестирование на проникновение
    Рекомендуется пригласить стороннюю команду специалистов по безопасности для моделирования возможных атак. Внешние эксперты полагаются на свои знания и интуицию, чтобы воспроизвести сценарии атак, которые ваша команда может упустить из виду.

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

5. Выпуск и обслуживание

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

Практики SDL, рекомендованные для этого этапа, включают:

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

Применение этих методов помогает быстро и эффективно реагировать на возникающие угрозы.

6. Окончание срока службы

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

Действия SDL, рекомендованные для этого этапа, включают:

  • Хранение данных
    Правительства определяют политику хранения для некоторых типов данных.Двойная проверка политик хранения вашей компании на соответствие требованиям законодательства снижает риск непредвиденных штрафов.
  • Удаление данных
    По окончании срока службы приложения все конфиденциальные данные, хранящиеся в нем, должны быть тщательно удалены. Примеры таких данных — ключи шифрования и личная информация. Правильная утилизация данных в конце срока службы обеспечивает конфиденциальность такой информации и предотвращает утечку данных.

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

Какие существуют методологии SDL?

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

Таким образом, когда методология предлагает конкретные виды деятельности, вы все равно можете выбрать те, которые подходят вам лучше всего. Например: есть ли в вашем приложении онлайн-платежи? Если это так, и если методология рекомендует обучение безопасности для вашей команды, вы можете организовать для них тщательное обучение по PCI и SOX.

Популярные методологии SDL не привязаны к какой-либо конкретной платформе и достаточно широко охватывают все важные практики. Любой из них послужит отправной точкой для SDL в вашей компании.Конечно, перед принятием окончательного решения рекомендуется более внимательно изучить каждую из них. Вы также можете настроить их в соответствии с вашим циклом разработки программного обеспечения. В этой статье представлен обзор трех популярных методологий: Microsoft SDL, SAMM и BSIMM.

Методологии

SDL делятся на две категории: предписывающие и описательные. Предписательные методологии явно рекомендуют пользователям, что делать. «Описания» состоят из буквального описания того, что сделали другие компании.

Жизненный цикл разработки безопасности Microsoft (SDL)

Microsoft SDL изначально создавался как набор внутренних практик для защиты собственных продуктов Microsoft.В 2008 году компания решила поделиться своим опытом в виде продукта. Microsoft SDL — это предписывающая методология, которая дает компаниям советы по повышению безопасности приложений.

Рис. 3. Основные практики Microsoft SDL

Microsoft SDL постоянно тестируется на различных приложениях компании. Его разработчики регулярно придумывают обновления, чтобы реагировать на возникающие риски безопасности. Он охватывает большинство аспектов безопасности, за исключением соблюдения нормативных требований, а также хранения и удаления данных.

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

Модель зрелости обеспечения программного обеспечения OWASP (SAMM)

SAMM — это проект с открытым исходным кодом, поддерживаемый OWASP. Вклады поступают от большого количества компаний самых разных размеров и отраслей. Благодаря этому практически любая команда разработчиков может использовать SAMM для определения действий, наиболее соответствующих их потребностям.

Как и Microsoft SDL, это предписывающая методология. SAMM определяет шаблоны дорожных карт для различных типов организаций. Эти шаблоны обеспечивают хорошее начало для настройки практик SAMM в соответствии с потребностями вашей компании.

Рисунок 4. Основные практики SAMM

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

Модель безопасности здания в зрелости (BSIMM)

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

Рис. 5. Основные практики BSIMM

На момент написания последней версии (BSIMM 10) использовались данные 122 компаний-членов. BSIMM постоянно развивается, с ежегодными обновлениями, которые идут в ногу с последними передовыми практиками.

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

Как и SAMM, BSIMM обеспечивает три уровня зрелости для безопасных методов разработки. Вы можете использовать его для оценки текущего состояния процессов безопасности в вашей организации.

Начало работы с безопасной разработкой

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

  • Просмотрите популярные методики SDL и выберите наиболее подходящую.Сделайте это в начале вашего проекта. Цена задержки высока: чем раньше вы обнаружите потенциальные проблемы с безопасностью, тем дешевле их исправить.
  • «Помните о пробелах» — сопоставьте свои текущие методы обеспечения безопасности со списком действий SDL и определите пробелы.
  • Ознакомьтесь с примерами внедрения SDL в проектах, похожих на ваш. Рассматривайте их успешные шаги и учитесь на их ошибках.
  • Придумайте список практик, чтобы заполнить пробелы. Расставьте приоритеты и добавьте действия, повышающие безопасность, в дорожную карту вашего проекта.
  • Получите поддержку от руководства, оцените свои ресурсы и проверьте, собираетесь ли вы использовать аутсорсинг.
  • Обучите свою команду безопасности приложений и соответствующим правилам, чтобы повысить осведомленность о возможных угрозах.
  • «Сдвиг влево», выполняя каждую проверку безопасности как можно раньше в жизненном цикле разработки. Это сэкономит вам много ресурсов, поскольку цена устранения проблем с безопасностью со временем резко возрастает.
  • Автоматизируйте все, что вы можете.Воспользуйтесь преимуществами статических сканеров кода с самого начала написания кода. Добавьте инструменты динамического сканирования и тестирования, как только у вас будет стабильная сборка.
  • Не стесняйтесь нанять сторонних экспертов. Организуйте аудит безопасности, поскольку посторонняя точка зрения может выявить угрозу, которую вы не заметили.

Следование этим рекомендациям должно обеспечить вашему проекту хорошее начало и сэкономить деньги и рабочую силу.

.

Сертифицированный специалист по безопасности информационных систем (CISSP)

Сертифицированный специалист по безопасности информационных систем (CISSP) — это сертификат информационной безопасности для аналитиков безопасности. Он был создан Международным консорциумом по сертификации безопасности информационных систем (ISC). Сертификат был создан, чтобы гарантировать, что профессионалы в области компьютерной безопасности имеют стандартизированные знания в этой области. Получение сертификата сертифицированного специалиста по безопасности информационных систем может помочь вам сделать успешную карьеру в качестве специалиста по компьютерной безопасности.

ЧТО ТАКОЕ CISSP?

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

КАК СТАТЬ СЕРТИФИЦИРОВАННЫМ

Чтобы получить сертификат CISSP, вам потребуется не менее пяти лет полной занятости оплачиваемой работы аналитиком по безопасности в двух или более из восьми областей, охватываемых CISSP, таких как криптография и безопасность разработки программного обеспечения. доступны для лиц с высшим образованием и дополнительными полномочиями, если они одобрены (ISC). Вы также можете стать партнером (ISC) и получить CISSP, если вы соответствуете требованиям к опыту.Следующим шагом будет подготовка и сдача экзамена. Чтобы сдать экзамен, вам необходимо набрать минимум 700 баллов из 1000.

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

Для сертификации CISSP требуется ежегодная плата за обслуживание в размере 85 долларов в конце каждого года сертификации, и вы должны проходить тест каждые три года, чтобы оставаться участником с хорошей репутацией при сертификации. Вы должны зарабатывать как минимум 20 кредитов непрерывного профессионального образования (CPE) каждый год в течение трехлетнего цикла сертификации. Вы можете пройти повторную сертификацию, выполнив 40 ежегодных CPE и заплатив ежегодную плату за обслуживание.Эти занятия можно пройти в университете или на онлайн-курсах, посвященных вопросам безопасности.

КАК ПОДГОТОВИТЬСЯ К CISSP

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

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

ЗАЧЕМ ПОЛУЧИТЬ СЕРТИФИКАЦИЮ CISSP?

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

Burning Glass Technologies, сайт вакансий, сообщает, что почти четверть всех вакансий в сфере кибербезопасности в 2015 году запрашивала CISSP. Согласно (ISC), «сертифицированные профессионалы в области информационной безопасности зарабатывают в среднем на 25 процентов больше, чем их несертифицированные коллеги». Быть профессионалом по CISSP может привести к более высокой оплате и более быстрому продвижению в области аналитики безопасности. Профессиональные должности в области безопасности, такие как специалисты по сетевой безопасности, старшие инженеры по безопасности, менеджер по информационной безопасности или руководители службы безопасности, могут пройти обучение по сертификации CISSP.

.

Разработки в области информации и телекоммуникаций в контексте международной безопасности — UNODA

В декабре 2018 года Генеральная Ассамблея учредила два процесса для обсуждения вопроса безопасности при использовании ИКТ в период 2019-2021 годов: рабочую группу открытого состава и группу правительственных экспертов. Щелкните ниже для получения дополнительной информации.

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

Международная безопасность ИКТ в ООН

Вопрос информационной безопасности стоит в повестке дня ООН с 1998 года, когда Российская Федерация внесла проект резолюции по этому вопросу в Первый комитет Генеральной Ассамблеи ООН.Затем она была принята без голосования Генеральной Ассамблеей в качестве резолюции 53/70. С 2004 года пять групп правительственных экспертов (ГПЭ) продолжали изучать угрозы, создаваемые использованием ИКТ в контексте международной безопасности, и способы устранения этих угроз. Три из этих групп согласовали содержательные отчеты с выводами и рекомендациями, которые приветствовались всеми государствами-членами ООН. Кроме того, каждая ГПЭ основывалась на работе, проделанной предыдущей, добиваясь значительного совокупного прогресса по рассматриваемым вопросам.Отчеты ГПЭ были хорошо приняты Генеральной Ассамблеей Организации Объединенных Наций. В частности, доклад ГПЭ за 2015 год был принят консенсусом в резолюции 70/237. Эта резолюция «призывает государства-члены руководствоваться в использовании информационных и коммуникационных технологий отчетом Группы правительственных экспертов за 2015 год».

Работа групп государственных экспертов

Работа групп правительственных экспертов была сосредоточена на следующих темах:

  • Существующие и возникающие угрозы
  • Как международное право применяется при использовании ИКТ
  • Нормы, правила и принципы ответственного поведения государств
  • Меры доверия
  • Наращивание потенциала

В данном информационном бюллетене представлен обзор работы ГПЭ.

Ниже приводится список основных отчетов, согласованных прошлыми ГПЭ.

Годовые отчеты Генерального секретаря

С 1998 года Генеральный секретарь ежегодно представляет Генеральной Ассамблее доклады с изложением мнений государств-членов ООН по этому вопросу.
В 2019 году государствам-членам снова было предложено представить свои национальные мнения по этому вопросу в резолюциях 73/27 и 73/266. Эти мнения будут включены в годовой отчет Генерального секретаря о событиях в области информации и телекоммуникаций в контексте международной безопасности за 2019 год.

Повестка дня Генерального секретаря по разоружению

Генеральный секретарь ООН Антониу Гутерриш выразил обеспокоенность по поводу злонамеренного использования ИКТ. Поэтому он сделал продвижение мирной среды ИКТ одним из своих ключевых приоритетов. В мае 2018 года Генеральный секретарь обнародовал свою Повестку дня для разоружения. В Повестке дня он отмечает, что «глобальная взаимосвязанность означает, что частота и влияние кибератак могут быть все более широко распространенными, затрагивая экспоненциальное количество систем или сетей одновременно.Он также заявляет, что «в этом контексте злонамеренные действия в киберпространстве способствуют снижению доверия между государствами». Для решения этих проблем Генеральный секретарь включил два пункта действий в отношении киберпространства в план реализации.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *