Русский
Русский
English
Статистика
Реклама

Блог компании акрибия

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

30.07.2020 18:15:54 | Автор: admin


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

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

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


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

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

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

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



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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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



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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

Сертифицированные VS. несертифицированные средства защиты информации требования регулятора или реальная необходимость?

29.09.2020 12:13:11 | Автор: admin

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

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

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

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

Несколько слов о сертификации СЗИ

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

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

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

Типовые организации и применимые к ним НПА

Далее мы предлагаем рассмотреть на примере типовой организаций перечень применимых НПА и проанализировать имеющиеся в них требования о необходимости использования сертифицированных средств защиты информации.

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

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

  1. ГОСТ Р 57580, который приобретает статус обязательного документа для организаций, на которые распространяются требования Положений БР 672-П, 683-П.

  2. Ряд положений Банка России: Положения 382-П, 672-П, 683-П, устанавливающих обязательные для финансовых организаций требования к обеспечению защиты информации, выполнять которые в той или иной степени необходимо каждому банку.

  3. Приказ Минкомсвязи 321 и методический документ БР 4-МР, регламентирующие порядок защиты биометрических персональных данных, так как выбранный нами Банк взаимодействует с Единой биометрической системой.

  4. ФЗ О персональных данных и подзаконные акты, определяющие требования к обеспечению защиты персональных данных, так как Банк является оператором персональных данных, осуществляя обработку информации о своих работниках, клиентах и иных лицах.

  5. ФЗ О безопасности критической информационной инфраструктуры и подзаконные акты, так как нашему Банку принадлежат информационные системы, функционирующие в банковской сфере, в соответствии с чем он является субъектом КИИ

  6. И, возможно, даже СТО БР ИББС, если Банк продолжает использовать комплекс в качестве вектора ИБ-развития.

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

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

Какие НПА требуют использования сертифицированных решений в составе системы защиты?

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

Начнем с наиболее востребованного в последнее время документа ГОСТ Р 57580.1. Как вы наверняка знаете, сами по себе ГОСТ являются рекомендательными документами, которые могут переходить в разряд обязательных, если это предусмотрено каким-либо НПА. Положения 672-П, 683-П, Приказ Минкомсвязи 321, применимые к нашему Банку, устанавливают необходимость выполнять требования ГОСТ Р 57580.1. Итак, подробно изучив документ, можно сделать следующие выводы:

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

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

  3. Что касается использования СКЗИ, для организаций реализующих 1-ый уровень защиты, необходимо использовать сертифицированные ФСБ России СКЗИ. Для остальных организаций действует правило, согласно которому все используемые СКЗИ российского производства также должны быть сертифицированными.

Итак, с СКЗИ все достаточно просто, в то время как момент использования (или неиспользования) сертифицированных СЗИ оставляет некую недосказанность как организации понять, что для закрытия актуальных угроз ей необходимо использовать именно сертифицированные решения?

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

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

Примерно такого же подхода придерживается и ДИБ ЦБ РФ ниже представлена выдержка из ответов на вопросы о выполнении ГОСТ, которые мы направляли ранее.

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

Дальше по списку идет несколько Положений ЦБ РФ, давайте рассмотрим и их. Начнем с Положения ЦБ РФ 672-П. Требования документа распространяются на все кредитные организации, являющиеся участниками платежной системы Банка России, имеющими доступ к услугам по переводу денежных средств с использованием распоряжений в электронном виде. Предполагаем, что наш Банк относится к данному типу организаций. Поэтому приступаем к изучению документа:

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

  2. Документ требует использования СКЗИ и СЗИ, прошедших процедуру оценки соответствия требованиям.

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

Далее рассмотрим основные аспекты Положения ЦБ РФ 683-П, требования которого распространяются на все кредитные организации, в том числе и на наш Банк. Итак:

  1. Распространяется на все информационные системы кредитных организаций, задействованные в процессе перевода денежных средств.

  2. Требует использования сертифицированной криптографии, если применяются СКЗИ российского производства.

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

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

Наконец, Положение ЦБ РФ 382-П. Его выполнение обязательно для ряда кредитных организаций, в том числе и для Банка, так как он является оператором по переводу денежных средств. Данный документ:

  1. Распространяется на все информационные системы Банка, обрабатывающие защищаемую (в терминах Положения) информацию.

  2. Не содержит требования об обязательном использовании сертифицированных СЗИ.

  3. Требует использования сертифицированной криптографии, если применяются СКЗИ российского производства.

  4. Необходимо использовать СКЗИ в соответствии с эксплуатационной документацией.

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

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

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

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

  1. Требования распространяются на технологические участки сбора, передачи и обработки биометрических ПДн

  2. Использование информационных технологий и технических средств, соответствующих 2-му уровню защиты информации по ГОСТ Р 57580.

  3. Рекомендуется использовать сертифицированные СЗИ и СКЗИ.

  4. В отношении распространяемого банками своим клиентам программного обеспечения действует рекомендация по наличию сертификата или же проведенного анализа уязвимостей по ОУД.4.

Таким образом, ни Приказ Минкомсвязи 321, ни методический документ ЦБ РФ 4-МР не устанавливают требования об обязательном использовании сертифицированных СЗИ и СКЗИ для нашего Банка.

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

  1. В область защиты попадают все информационные системы, обрабатывающие какие-либо персональные данные.

  2. Все НПА требуют использования СЗИ, прошедших оценку соответствия.

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

  4. Обязательное использование СКЗИ для защиты персональных данных не предусмотрено. Если же принято решение об использовании СКЗИ, то они должны иметь сертификаты ФСБ России и соответствовать требованиям к классу СКЗИ.

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

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

  1. Требования распространяются на значимые объекты критической информационной инфраструктуры и их систему защиты.

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

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

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

Говоря о КИИ трудно не упомянуть и Государственную систему обнаружения, предупреждения и ликвидации последствий компьютерных атак. В соответствии с НПА, регулирующими ее функционирование, если организация использует средства ГосСОПКА (которые по своей сути являются СЗИ), то они должны иметь гарантийную и техническую поддержку российских организаций, а также возможность модернизации российскими организациями. Помимо этого, применяемые организацией СКЗИ должны иметь сертификаты ФСБ России. То есть если организация, например, решила стать корпоративным центром ГосСОПКА, то сертифицированные СКЗИ то, без чего ей не обойтись.

Так как ранее мы упоминали СТО БР ИББС, предлагаем рассмотреть и его требования на предмет наличия использования сертифицированных СЗИ. Тем более, что наш Банк продолжает усердно следовать определенному в данном документе подходу, что находит подтверждение в его [Банка] внутренней документации. Общие положения гласят:

  1. Если для защиты АБС от несанкционированного доступа и нерегламентированных действий используется не встроенные средства, а внешние СЗИ, они должны быть сертифицированы.

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

  3. Используемые СКЗИ должны иметь сертификаты или разрешение ФСБ России.

Таким образом, СТО БР ИББС устанавливает требования об использовании сертифицированных СКЗИ, а также в ряде случаев сертифицированных СЗИ для защиты банковской информационной инфраструктуры.

Заключение

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

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

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

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

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

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

Спасибо за внимание!

Владислав Павлов

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

Подробнее..

Перевод Googles Certificate Transparency как источник данных для предотвращения атак

12.01.2021 14:15:46 | Автор: admin

Мы подготовили перевод статьи Райана Сирса об обработке логов Googles Certificate Transparency, состоящей из двух частей. В первой части дается общее представление о структуре логов и приводится пример кода на Python для парсинга записей из этих логов. Вторая часть посвящена получению всех сертификатов из доступных логов и настройке системы Google BigQuery для хранения и организации поиска по полученным данным.

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

Часть 1. Parsing Certificate Transparency Logs Like a Boss

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

Одним из источников, которые мы интегрировали (и определённо одним из лучших), стал Certificate Transparency Log (CTL) - проект, начатый Беном Лори и Адамом Ленгли в Google. По сути CTL - это лог, содержащий неизменяемый список сертификатов, выпущенных CA, который хранится в дереве Меркла, что позволяет при необходимости криптографически проверить каждый сертификат. [*]

Чтобы понять, с какими объемами данных придется иметь дело, давайте посмотрим, сколько записей содержится в каждом логе из списка с сайта CTL:

```pythonimport requestsimport jsonimport localelocale.setlocale(locale.LC_ALL, 'en_US')ctl_log = requests.get('https://www.gstatic.com/ct/log_list/log_list.json').json()total_certs = 0human_format = lambda x: locale.format('%d', x, grouping=True)for log in ctl_log['logs']:log_url = log['url']try:log_info = requests.get('https://{}/ct/v1/get-sth'.format(log_url), timeout=3).json()total_certs += int(log_info['tree_size'])except:continueprint("{} has {} certificates".format(log_url, human_format(log_info['tree_size'])))print("Total certs -> {}".format(human_format(total_certs))) ```

На выходе получаем:

ct.googleapis.com/pilot has 92,224,404 certificatesct.googleapis.com/aviator has 46,466,472 certificatesct1.digicert-ct.com/log has 1,577,183 certificatesct.googleapis.com/rocketeer has 89,391,361 certificatesct.ws.symantec.com has 3,562,198 certificatesctlog.api.venafi.com has 94,797 certificatesvega.ws.symantec.com has 200,401 certificatesctserver.cnnic.cn has 5,081 certificatesctlog.wosign.com has 1,387,492 certificatesct.startssl.com has 293,374 certificatesct.googleapis.com/skydiver has 1,249,079 certificatesct.googleapis.com/icarus has 48,585,765 certificatesTotal certs -> 285,037,607

285,037,607 на момент написания статьи. Это не такой большой объем данных, но все равно придется приложить определенные усилия, чтобы эффективно организовать хранение и поиск по сертификатам. Подробнее об этом во второй части.

Spoiler

Комментарий переводчика

Стоит отметить, что API выдает количество записей в логе, значительную часть которых составляют PreCerts (о них далее) и не представляют особого интереса. Также важно учитывать, что сертификаты могут дублироваться между разными логами, к примеру, данный сертификат присутствует одновременно в 6 различных логах, поддерживаемых Chrome. Таким образом, реальное число сертификатов значительно меньше, чем суммарное число записей в логах.

Тем не менее, на момент написания перевода, учитывая только логи, удовлетворяющие политике Google и включенные в Chrome, в списке присутствует 46 логов, содержащие в сумме 6,861,473,804 записей, что уже потребует значительных ресурсов для полной обработки.

Анатомия CTL

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

```json// curl -s 'https://ct1.digicert-ct.com/log/ct/v1/get-entries?start=0&end=0' | jq .{  "entries": [    {      "leaf_input": "AAAAAAFIyfaldAAAAAcDMIIG/zCCBeegAwIBAgI...",      "extra_data": "AAiJAAS6MIIEtjCCA56gAwIBAgIQDHmpRLCMEZU..."    }  ]}```

Каждая запись содержит поля `leaf_input` и `extra_data` в формате base64. Обращаясь к RFC6962 видим, что `leaf_input` - закодированная структура MerkleTreeLeaf, а `extra_data` - PrecertChainEntry.

Про PreCerts

Мне потребовалось довольно много времени, чтобы разобраться, что вообще такое PreCert (можете попробовать сами, почитайте RFC, и, по всей видимости, я такой не один. Сохраню вам кучу времени на раздумья и поиски в гугле и сформулирую назначение PreCerts следующим образом:

PreCerts это отдельный тип сертификата, выпускаемого CA до того, как тот выпустит настоящий сертификат. Фактически, это копия исходного сертификата, но содержащая специальное расширение x509 v3, называемое `poison` и отмеченное как критическое. Таким образом, сертификат не будет валидирован как платформами, распознающими это расширение, и знающими что это PreCert, так и платформами, которые это расширение не распознают.

Мой опыт в ИБ говорит о том, что такая мера не сильно эффективна, хотя бы потому, что баги при парсинге x509/ASN.1 встречаются довольно часто и отдельные реализации могут быть уязвимы к различным махинациям, которые в конечном счете позволят валидировать PreCert. Я понимаю, зачем это было сделано, но складывается ощущение, что полностью убрать PreCerts и оставлять в CTL только сертификаты, действительно выпущенные CA, было бы намного разумнее.

Парсим бинарные структуры

Как для человека, занимающегося реверс-инжинирингом и время от времени участвующего в разных CTF, задача парсинга бинарных структур для меня не нова. Большинство людей в таких случаях обращаются к модулю `struct`, но много лет назад, во время работы на Филлипа Мартина, он познакомил меня с отличной библиотекой Construct, которая заметно упрощает парсинг подобных структур. Ниже приведены структуры, которые я использовал для парсинга, а также пример их использования для обработки записей:

```pythonfrom construct import Struct, Byte, Int16ub, Int64ub, Enum, Bytes, Int24ub, this, GreedyBytes, GreedyRange, Terminated, EmbeddedMerkleTreeHeader = Struct(    "Version"         / Byte,    "MerkleLeafType"  / Byte,    "Timestamp"       / Int64ub,    "LogEntryType"    / Enum(Int16ub, X509LogEntryType=0, PrecertLogEntryType=1),    "Entry"           / GreedyBytes)Certificate = Struct(    "Length" / Int24ub,    "CertData" / Bytes(this.Length))CertificateChain = Struct(    "ChainLength" / Int24ub,    "Chain" / GreedyRange(Certificate),)PreCertEntry = Struct(    "LeafCert" / Certificate,    Embedded(CertificateChain),    Terminated)``````pythonimport jsonimport base64import ctl_parser_structuresfrom OpenSSL import cryptoentry = json.loads("""{  "entries": [    {      "leaf_input": "AAAAAAFIyfaldAAAAAcDMIIG/zCCBeegAwIBAgIQ...",      "extra_data": "AAiJAAS6MIIEtjCCA56gAwIBAgIQDHmpRLCMEZUg..."    }  ]}""")['entries'][0]leaf_cert = ctl_parser_structures.MerkleTreeHeader.parse(base64.b64decode(entry['leaf_input']))print("Leaf Timestamp: {}".format(leaf_cert.Timestamp))print("Entry Type: {}".format(leaf_cert.LogEntryType))if leaf_cert.LogEntryType == "X509LogEntryType":    # В случае, если запись - обычный X509 сертификат    cert_data_string = ctl_parser_structures.Certificate.parse(leaf_cert.Entry).CertData    chain = [crypto.load_certificate(crypto.FILETYPE_ASN1, cert_data_string)]    # Парсим структуру `extra_data` чтобы получить оставшуюся часть цепочки    extra_data = ctl_parser_structures.CertificateChain.parse(base64.b64decode(entry['extra_data']))    for cert in extra_data.Chain:        chain.append(crypto.load_certificate(crypto.FILETYPE_ASN1, cert.CertData))else:    #  В случае, если запись - PreCert    extra_data = ctl_parser_structures.PreCertEntry.parse(base64.b64decode(entry['extra_data']))    chain = [crypto.load_certificate(crypto.FILETYPE_ASN1, extra_data.LeafCert.CertData)]    for cert in extra_data.Chain:        chain.append(            crypto.load_certificate(crypto.FILETYPE_ASN1, cert.CertData)        )

Получаем массив X509 сертификатов из цепочки с сертификатом из leaf_input в качестве первого элемента

```

Как можете заметить, Construct позволяет довольно легко определять бинарные структуры на Python.

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

Часть 2. Retrieving, Storing and Querying 250M+ Certificates Like a Boss

Сбор сертификатов

В соответствии с RFC, для получения записей из логов используется эндпоинт `get-entries`. К сожалению, задача осложняется ограничением на максимальное количество записей, которое можно получить в одном запросе (контролируется параметрами `start` и `end`), и большинство логов позволяют получить лишь 64 записи за раз. Однако CTL от Google, составляющие большинство всех логов, используют максимальный размер запроса в 1024 записи.

Spoiler

Комментарий переводчика

На момент написания перевода большинство логов Google (Argon, Xenon, Aviator, Icarus, Pilot, Rocketeer, Skydiver) предоставляют лишь по 32 записи для каждого запроса, но для ускорения получения записей можно одновременно отправлять несколько запросов на один и тот же лог, насколько позволяет пропускная способность, но работает такой подход не для всех логов.

Отдельные логи предоставляют возможность получать по 1024 и более записей за раз, но большинство CTL, помимо Google, выдает по 256 записей за один запрос.

Так как задача одновременно IO-bound (получение записей по http) и CPU-bound (парсинг сертификатов), для эффективной обработки необходимо будет подключить как асинхронность, так и многопроцессность.

Так как не было никаких инструментов, которые позволили бы легко и безболезненно получить и распарсить все CTL (помимо не особо примечательной утилиты от Google, было решено потратить немного времени и написать свой инструмент, который соответствовал бы всем нашим потребностям. Результатом стал Axeman, который использует asyncio и замечательную библиотеку aioprocessing для загрузки, парсинга и сохранения сертификатов в несколько CSV файлов, ограничиваясь при этом только скоростью интернет-соединения.

Эксплуатация облака

После получения инстанса (_прим. перев._ так в Google Cloud называются VM) c 16 ядрами, 32Гб памяти и SSD на 750Гб (спасибо Google за бесплатные 300$ на счете для новых аккаунтов!), я запустил Axeman, который загрузил все сертификаты меньше чем за сутки и сохранил результаты в `/tmp/certificates/$CTL_DOMAIN/`

Где хранить все эти данные?

На начальном этапе для осуществления хранения и поиска по данным был выбран Postgres, но, хотя я и не сомневаюсь, что с правильной схемой Postgres легко бы справился с 250 миллионами записей (в отличии от моей первой попытки, в которой на один запрос уходило примерно 20 минут!), я начал искать решения, которые:

  • позволяют дешево хранить большой объем данных

  • обеспечивают быстрый поиск

  • позволяют легко обновлять данные

Вариантов было несколько, но с точки зрения стоимости, почти все рассмотренные варианты (AWS RDS, Heroku Postgres, Google Cloud SQL) были весьма затратны. К счастью, так как наши данные в принципе никогда не изменяются, у нас появляется дополнительная гибкость в выборе платформы для размещения данных.

В целом, это как раз тот тип поиска по данным, который прекрасно ложится на модель map/reduce с использованием, к примеру, Spark или Hadoop Pig. Просматривая предложения различных провайдеров в категории big data (хотя в нашей задаче данных явно мало для включения в эту категорию), я наткнулся на Google BigQuery, который удовлетворяет всем обозначенным параметрам.

Скармливаем данные BigQuery

Загрузка данных в BigQuery осуществляется довольно легко, благодаря предоставляемой Google утилите gsutil. Создаем новый бакет для наших сертификатов:

Когда бакет готов, используем `gsutil` для транспортировки всех сертификатов в хранилище Google (а затем в BigQuery). После настройки аккаунта командой `gsutil config`, запускаем процесс загрузки:

```gsutil -o GSUtil:parallel_composite_upload_threshold=150M \       -m cp \       /tmp/certificates/* \       gs://all-certificates```

И видим следующий результат в нашем бакете:

Далее создаем новый датасет в BigQuery:

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

Так как схема нужна всякий раз при импорте очередного лога, воспользуемся опцией Edit as Text. Использованная схема:

```[    {        "name": "url",        "type": "STRING",        "mode": "REQUIRED"    },    {        "mode": "REQUIRED",        "name": "cert_index",        "type": "INTEGER"    },    {        "mode": "REQUIRED",        "name": "chain_hash",        "type": "STRING"    },    {        "mode": "REQUIRED",        "name": "cert_der",        "type": "STRING"    },    {        "mode": "REQUIRED",        "name": "all_dns_names",        "type": "STRING"    },    {        "mode": "REQUIRED",        "name": "not_before",        "type": "FLOAT"    },    {        "mode": "REQUIRED",        "name": "not_after",        "type": "FLOAT"    }]```

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

Что в итоге получилось

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

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

```SQLSELECT  all_dns_namesFROM  [ctl-lists:certificate_data.scan_data]WHERE  (REGEXP_MATCH(all_dns_names,r'\b?xn\-\-'))  AND NOT all_dns_names CONTAINS 'cloudflare'```

И всего через 15 секунд получаем результат со всеми punycode доменами из всех известных CTL!

Рассмотрим другой пример. Попробуем получить все сертификаты доменов Coinbase, записанные в Certificate Transparency:

```SQLSELECT  all_dns_namesFROM  [ctl-lists:certificate_data.scan_data]WHERE  (REGEXP_MATCH(all_dns_names,r'.*\.coinbase.com[\s$]?'))```

Всего через две секунды получаем все интересующие нас результаты:

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

Небольшая загадка

Проводя исследования, я обнаружил нечто странное. Домен `flowers-to-the-world.com` постоянно возникал в различных логах. Практически каждый лог имел огромное число сертификатов, содержащих этот домен:

```SQLSELECT  url,  COUNT(*) AS total_certsFROM  [ctl-lists:certificate_data.scan_data]WHERE  (REGEXP_MATCH(all_dns_names,r'.*flowers-to-the-world.*'))GROUP BY  urlORDER BY  total_certs DESC```

Whois позволяет определить, что этот домен принадлежит Google, так что мне интересно, не является ли это частью какой-то тестовой рутины. Если вы инженер Google, который может разузнать что-то у товарищей, занимающихся Certificate Transparency, было бы очень интересно услышать об этом.

Spoiler

Ответ инженера Google в комментариях под оригинальным постом

Привет, Райан. Пишет Пол Хэдфилд из команды Certificate Transparency.

`flowers-to-the-world.com` действительно принадлежит Google. Мы используем этот домен чтобы генерировать сертификаты, которые затем добавляются в каждый CTL в рамках периодической проверки логов на соответствие стандартам RFC6962. Проверка проводится с целью удостоверится, что логи работают в соответствии со стандартами и имеют приемлемый аптайм.

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

Если проследить полную цепочку при добавлении сертификата с `flower-to-the-world.com`, можно увидеть, что она заканчивается в корне со следующим эмитентом: C=GB, ST=London, O=Google UK Ltd., OU=Certificate Transparency, CN=Merge Delay Monitor Root

Надеюсь, это помогло.

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

В России, насколько нам известно, это первый такой продукт. В США и Китае у нас есть сильные конкуренты, но мы надеемся превзойти их по некоторым параметрам. Например, актуальность данных уже сейчас наша реализация поискового движка позволяет включать в поисковую выдачу данные, от сканов не старше минуты. На сегодняшний день Netlas.io доступен в формате "раннего доступа". Если есть желание потестировать переходите на сайт и регистрируйтесь.

Подробнее..

Обзор решения Proget MDM

14.05.2021 14:06:19 | Автор: admin

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

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

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

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

Рассмотрим основной функционал системы Proget MDM:

Контроль мобильных устройств

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

Управление приложениями

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

Настройка корпоративной среды

Автоматическая настройка корпоративных сервисов, таких как электронная почта, календарь, контакты, сети Wi-Fi, подключения к VPN, передача файлов и прочего. К слову, Proget MDM позволяет передавать файлы корпоративным пользователям на их устройства по защищенному шифрованному каналу через собственное приложение.

Отслеживание местоположения

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

Удаленное подключение

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

Очистка корпоративных данных

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

Интеграция с Active Directory

Система Proget MDM с лёгкостью интегрируется с корпоративной службой каталогов Active Directory по протоколу LDAP, что значительно упрощает её внедрение. Мобильные устройства возможно привязать к текущим учётным записям, упрощая тем самым взаимодействие с пользователями.

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

Политика лицензирования Proget MDM такая же простая и интуитивная, как и интерфейс. Решение лицензируется по количеству устройств (не пользователей), на этом всё. Редакций нет, лицензий на серверную часть нет. Все, что нужно знать количество устройств, которые будут управляться в системе. Всегда бы так, правда?

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

На подконтрольные устройства Proget MDM ставится по-разному, в зависимости от выбранного типа интеграции. Например, на личном смартфоне сотрудника можно быстро установить приложение Proget MDM прямо из Play Market, ввести учётные данные и готово. В случае с корпоративным смартфоном, настройка может заключаться в полном сбросе устройства с последующей неразрывной интеграцией Proget MDM. Для более прозрачного понимания взаимодействия системы с устройствами пройдёмся по типам интеграции (активации) доступных в решении Proget MDM:

Android MDM

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

Android Enterprise - Work Managed Device

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

Android Enterprise - Work Managed Device

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

К типам активаций, использующих аналогичный метод контейнеризации, относятся также Samsung Knox MDM и Samsung Knox Container. Данные интеграции максимально раскрывают богатые возможности Proget на устройствах компании Samsung.

iOS MDM

Тип активации, близкий по концепции к Android MDM, но при этом обладающий меньшим функционалом по воздействию на мобильное устройство. Обусловлено это политикой Apple, с чем разработчикам и пользователям приходится лишь смириться. При этом, iOS MDM предоставляет более расширенные возможности в плане тонких настроек системы и профилей безопасности. Контейнеризация не поддерживается. Интеграция не видоизменяет персонализацию устройства пользователя.

Windows MDM

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


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

Подробнее..

Использование TLS fingerprinting для выявления угроз

31.05.2021 14:10:41 | Автор: admin

В статье хотим рассказать про технологию TLS fingerprinting, про которую недостаточно материалов в русскоязычном сегменте. Попробуем это исправить. Статья частично переводит тематические материалы авторов описываемых методов (тут и тут), а также содержит описание практической реализации от Акрибии.

Не будем глубоко погружаться в детали работы SSL/TLS (далее будем говорить TLS), но кратко поясним детали.

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

Чтобы инициировать сеанс TLS, клиент отправляет пакет приветствия серверу после трёхстороннего установления связи TCP. Этот пакет и способ его создания зависят от пакетов и методов шифрования, используемых при создании клиентского приложения. Если сервер принимает соединение TLS, он ответит пакетом приветствия, тем самым продолжая согласование шифрования.

Поскольку согласование шифрования TLS передаётся в открытом виде, то можно отследить и идентифицировать клиентские приложения.

В этом и суть технологии TLS fingerprinting, если кратко. А теперь немного подробнее.

TLS fingerprinting

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

  • версия TLS;

  • версия записи TLS;

  • наборы шифров;

  • параметры сжатия;

  • список расширений.

Кроме того, данные собираются из трех конкретных расширений (если они доступны):

  • алгоритмы подписи;

  • алгоритм для шифрования данных;

  • хэш функция для проверки содержимого.

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

Почему это круто:

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

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

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

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

Например, к серверу Exchange могут обращаться только почтовые клиенты или браузер, если используется OWA, поэтому соединение из скрипта на Python будет подозрительным.

Итого: TLS Fingerprinting предназначен для быстрой идентификации известных TLS-соединений и отслеживания неизвестных TLS-соединений. Входные данные принимаются либо посредством прослушивания трафика, либо при чтении PCAP файлов.

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

  • пассивный метод с использованием хэшей JA3 и JA3S;

  • активный инструмент снятия отпечатков пальцев с сервера TLS хэши JARM.

JA3 и JA3S

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

Порядок полей следующий:

TLSVersion,Ciphers,Extensions,EllipticCurves,EllipticCurvePointFormats

Пример:

771,49196-49162-49195-52393-49161-49200-49172-49199-52392-49171-159-57-56-107-158-52394-51-50-103-22-19-157-53-61-156-47-60-10,0-23-65281-10-11-13-28,29-23-24-25,0

Если в ClientHello нет расширений TLS, поля остаются пустыми:

769,451091009836191899,,,

Эти строки затем хэшируются MD5. Пример отпечатка JA3:

c8446f59cca2149cb5f56ced4b448c8d

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

Порядок полей, следующий:

TLSVersion,Cipher,Extensions

Пример:

769,47,6528101135516

Если в Server Hello нет расширений TLS, поля остаются пустыми.

Пример:

769,47,

Эти строки затем хэшируются MD5 для создания 32-символьного отпечатка пальца.

Это отпечаток JA3S:

4835b19f14997673071435cb321f5445

JA3 и JA3S это методы снятия отпечатков TLS. JA3 отслеживает способ, которым клиентское приложение обменивается данными через TLS, а JA3S отслеживает ответ сервера. Вместе они создают отпечаток криптографического согласования между клиентом и сервером.

Теперь перейдем к описанию активного метода JARM.

JARM

JARM работает, активно отправляя 10 пакетов приветствия клиента TLS на целевой сервер и фиксируя определенные атрибуты ответов приветствия сервера. Затем агрегированные ответы сервера TLS хэшируются определенным образом для получения отпечатка JARM. JARM отправляет разные версии, шифры и расширения TLS в разном порядке для сбора уникальных ответов. Хэш JARM представляет собой гибридный нечеткий хэш, он использует комбинацию обратимого и необратимого алгоритма хеширования для создания 62-символьного отпечатка.

Отпечатки JARM можно использовать:

  • убедиться, что все серверы в группе имеют одинаковую конфигурацию TLS;

  • сгруппировать разрозненные серверы в сети Интернет по конфигурации, указав, например, что сервер может принадлежать Google, Yandex или Apple;

  • определить приложения или инфраструктуру по умолчанию;

  • выявить командные центры и других вредоносные серверы в сети Интернет.

Первые 30 символов состоят из шифра и версии TLS, выбранных сервером для каждого из 10 отправленных приветствий клиента. 000 означает, что сервер отказался согласовывать приветствие с этим клиентом. Остальные 32 символа представляют собой усеченный хэш SHA256 совокупных расширений, отправленных сервером, без учета данных сертификата x509. При сравнении отпечатков JARM, если первые 30 символов совпадают, но последние 32 отличаются, это будет означать, что серверы имеют очень похожие конфигурации, принимают одинаковые версии и шифры, но используют различные расширения, что не позволяет их считать полностью идентичными.

Исторически так сложилось, что индустрия кибербезопасности была сосредоточена в основном на индикаторах компрометации (IOC) и индикаторах атаки (IOA). То есть когда вредоносное ПО/хост и т.п. будут кем-то обнаружены, исследователи или вендоры платформ TI вычленяют уникальные или не очень признаки выявленного вредоноса или атаки типа IP, домена, хэша файла и т.п. и публикуют их в чёрных списках. Проблема в том, что к этому моменту вредоносное ПО уже распространено, и специалисты ИБ автоматически переходят в оборону.

Интернет-сканирование JARM в сочетании с другими метаданными и историческим анализом даёт возможность упреждающей идентификации IOC для новых вредоносов. Например, можно сканировать Интернет с помощью JARM, сопоставлять известные результаты JARM с историей домена, IP и репутацией вместе с данными сертификата для создания черного списка. Это позволяет перейти к возможности программного создания высокоточных списков блокировки до того, как первая вредоносная программа будет распространена.

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

Чтобы упростить процесс, можно использовать готовое решение. В настоящее время хэши JARM умеют считать продукты Palo Alto Networks и используют их API для обогащения целевого JARM.

Примеры реализации

Если нет возможности или желания использовать готовые решения от Palo Altoи пр., можно реализовать в своей инфраструктуре свое средство мониторинга трафика, например, на основе Zeek (ранее назывался Bro) популярного open-source продукта, заточенного специально для этого.

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

Zeek умеет выполнять снятие отпечатков TLS с помощью хэша JA3\JA3S.

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

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

Хэши JA3S, соответствующие вредоносам, достать чуть сложнее. Есть, например, небольшая подборка тут, есть и еще, нужно только искать или считать самостоятельно.

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

Далее приведем некоторые описания правил, которые мы реализуем у себя. Также есть неплохой доклад от Splunk с примерами алгоритмов и правил мониторинга по хэшам JA3/JA3S. Доступен здесь. Правила можно адаптировать под любую SIEM.

  • Выявление признака конкретного вредоноса по хэшам JA3\JA3S. Вот, например, готовые значения для Emotet и TrickBot:

    JA3 = 4d7a28d6f2263ed61de88ca66eb011e3 (Emotet)JA3S = 80b3a14bccc8598a1f3bbe83e71f735f (C2 Server Response)JA3 = 6734f37431670b3ab4292b8f60f29984 (Trickbot)JA3S = 623de93db17d313345d7ea481e7443cf(C2 Server Response)
    
  • Выявления нового хэша JA3, ранее не появляющегося в сети.

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

  • Выявления хэшей JA3 не из белого списка.

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

  • Выявления хэшей JA3\JA3S из чёрного списка.

Это правило нацелено на выявление хэшей заведомо вредоносного ПО.

  • Выявление обращений к C&C по хэшам JARM.

При выявлении обращения к TLS-серверу, неизвестному нам или ранее не появляющемуся в логах, необходимо посчитать его JARM хэш (можно вручную, можно скриптом или с использованием SOAR), при совпадении с хэшем, соответствующим известному C&C серверу, блокируем соединение, изолируем хост и расследуем инцидент.

  • Выявление JA3 хэшей, не характерных для системы.

При появлении на хостах с Windows JA3 хэшей, характерных для Linux или смартфонов (Android/IOS), стоит обратить внимание на такие хосты. Это может являться признаком работы вредоносов (ну или запущенного эмулятора/виртуалки в режиме NAT). Кейс особенно заслуживает внимание, если выявлен на рабочей станции обычного пользователя, далекого от мира IT.

  • Выявление JA3 хэшей, характерных для разных браузеров одного семейства.

Сейчас достаточно сложно на один хост поставить две разные версии Firefox или Chrome (виртуальные машины в режиме NAT не в счёт). Такое выявление может свидетельствовать о том, что злоумышленники пытались адаптироваться под установленный софт, но после обновления софта не успели или забыли обновить свой Fingerprint. Хост лучше изолировать и провести расследование.

  • Выявление JA3 хэшей, характерных для популярных сетевых библиотек языков программирования.

Ни для кого не секрет, что сейчас ВПО пишется не только на C/C++. Часто встречаются образцы, которые написаны на Python или Golang. Стандартные библиотеки, такие как requests (для python) или http (для Golang), имеют характерные отпечатки в рамках нескольких версий. В случае выявления такого хэша на рабочем месте разработчиков, вероятно, это нормально. Но, если хэши всплывут на рабочем компьютере рядового пользователя, то точно следует провести тщательную проверку, так как с большой вероятностью это будет свидетельством активности вредоноса. Также стоит поддерживать списки актуальных JA3 хэшей для популярных сетевых библиотек, чтобы минимизировать ложные срабатывания.

Важно: Список хэшей JARM (и JA3S тоже) необходимо регулярно пополнять новыми выявленными C&C серверами, полученную самостоятельно или от сторонних исследователей.

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


В завершении хотим подчеркнуть, что развитие и популяризация технологии TLS Fingerprinting, по нашему мнению, совсем не за горами, и способствует этому внедрение TLS 1.3.

В версиях стандарта TLS до 1.3 у клиента была возможность сообщать, к какому серверу он хочет обратиться SNI (Server Name Indication). Чаще всего в HTTPS для этого использовалось поле HOST, чтобы на одном IP и порту могли работать несколько HTTPS-сайтов. Соответственно и так, без всяких fingerprint, было видно, кто куда идет. Понятно, что речь идёт про легитимные обращения, атакующие всегда могли подделать SNI.

В стандарте TLS 1.3 появилась возможность шифровать имя запрашиваемого сайта Encrypted SNI (ESNI), и безопасники потеряли возможность видеть, куда идёт обращение.

Правда ESNI уже запретили в Китае, и были попытки блокировок в России. Однако ESNI стал часто встречаться, в том числе в инструментах злоумышленников, и без TLS fingerprinting становится сложно понимать, куда происходят обращения в сети.

Авторы статьи:

Михаил Кравченко, SOC-аналитик;

Александр Минин, руководитель направления Threat Intelligence @AAMinin;

Анна Шестакова, руководитель направления мониторинга ИБ.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru