![](https://habrastorage.org/getpro/habr/upload_files/c65/0b7/444/c650b7444126dd71cd8eb970b9d9e775.png)
Всем привет! Я живу за городом, и у меня есть своя лужайка с газоном, за которой нужно ухаживать, периодически косить. Это занимает несколько часов. В выходные хочется провести больше времени с семьей и на лужайку сил не остается. Поэтому я приглашаю помощников по хозяйству, которые косят траву и, соответственно, освобождают мне время на что-то более важное и интересное. Становясь старше и опытнее, понимаешь, что если есть возможность купить время, это нужно обязательно сделать. То же самое можно применить и к бизнесу. Если компания зрелая, руководство понимает ценность бизнеса, как он устроен, как работает и как приносит деньги, то оно также понимает, что вынужденный простой обойдется компании гораздо дороже, чем средства, затраченные на ИТ-инфраструктуру.
Меня зовут Артём Мелёхин, я занимаюсь продвижением нового направления Positive Technologies, а именно продвижением подхода к определению времени атаки и вероятных маршрутов хакеров.
Представим, что нам известно, сколько времени понадобится хакеру, чтобы добраться до системы, которая отвечает за стабильность бизнеса компании. Мы посчитали, сколько ему потребуется дней или часов, чтобы бизнес организации перестал работать или приносить прибыль. Зачем? Чтобы удлинить его злонамеренный маршрут и не допустить серьезного ущерба для атакуемой компании!
В этой статье я расскажу про наш подход к определению времени атаки и вероятных маршрутов хакеров и о том, что нужно предпринять с точки зрения ИТ-инфраструктуры, чтобы максимально усложнить путь атакующему. В дальнейших статьях (если это вам будет интересно) с удовольствием разберем домены, с которыми мы работаем, расскажем, почему это важно, а также на примерах покажем, как можно существенно усилить киберустойчивость компании за счет правильной настройки ИТ-инфраструктуры.
Суть подхода
В исследованиях, докладах и на вебинарах экспертов нашей компании часто звучит мысль, что защитить всё невозможно. Невозможно и не нужно. Но как-то ведь нужно измерять защищенность? Если невозможно защититься от всех атак, защищайтесь от тех, что приносят наибольший ущерб. Если нельзя защитить всё, защищайте самое ценное. На этом базируется принцип результативной кибербезопасности, которая утверждает, что важна защита наиболее ценных информационных активов, компрометация которых может вызвать реализацию недопустимых для организации событий (мы иногда используем термин «недопустимый ущерб»). Этот принцип заложен в наши метапродукты – MaxPatrol O2 и MaxPatrol Carbon, помогающие выявить угрозы, которые могут привести именно к недопустимому событию. Этот принцип лежит и в основе нашего подхода.
Обучение нашему подходу занимает несколько дней, и описать в одной статье все подробности просто невозможно, но я постараюсь отразить основные шаги.
? Разговор всегда нужно начинать с владельца бизнеса.
Как правило, именно владелец бизнеса лучше всех знает его особенности, его сильные и слабые стороны. Именно с владельцем бизнеса мы начинаем разговор и задаем простой вопрос: «Что должно произойти, чтобы ваш бизнес перестал существовать или его работа была максимально затруднена и невыгодна?» и получаем следующие варианты ответов:
Поскольку бизнес держится только на мне, соответственно, не должно стать меня (моя жизнь окажется в опасности или я отойду от дел).
Вывели очень крупные суммы со счета компании.
Утекли данные клиентов: если мне перестанут доверять, значит, и бизнесу конец.
Клиентов через системы моей компании заразили вредоносом (атака на цепочку поставок).
Отлично! Вот вам и список недопустимых событий, а следовательно, и цели атакующего (которые мы называем «целевые системы», или ЦС). Идем дальше.
Зная цель, нужно понять, как атакующий может до нее добраться, какими маршрутами и что для этого нужно сделать? И тут нам потребуется помощь тех, кто лучше всех знает ИТ-инфраструктуру компании — CIO, CTO, CISO. С ними мы прорабатываем вопросы, связанные с топологией ИТ-инфраструктуры, ее составом, и выделяем ключевые информационные системы, через которые можно добраться до ЦС, а также ограничения, которые существуют.
![Выделение ключевых и целевых систем Выделение ключевых и целевых систем](https://habrastorage.org/getpro/habr/upload_files/66c/2b7/4f8/66c2b74f86352b8faee4310f01c1dbf4.png)
Итак, мы определили КС и ЦС, поняли, какие действия нужно предпринять атакующему, чтобы реализовать недопустимое событие. Как видно из рисунка выше, атакующий может попасть на веб-сервер или завладеть учетной записью на почтовом сервере, выйти за пределы DMZ, попасть на компьютер бухгалтера и т. д. Теперь нужно построить вероятные маршруты атакующего!
И тут наступает магия математики и различных метрик, на основе которых мы рассчитываем киберустойчивость.
![Потенциальный маршрут атакующего . Потенциальный маршрут атакующего .](https://habrastorage.org/getpro/habr/upload_files/b73/266/dea/b73266dead756c2054d1197f4314ac24.png)
Основная задача подхода — достижение и поддержание такого состояния IT-инфраструктуры, при котором реализация недопустимого события максимально затруднена и шумность реализации атаки повышена до состояния, когда атака будет заметна службе информационной безопасности.
В основе оценки киберустойчивости лежит подход, разработанный Positive Technologies. Каждый инцидент имеет жизненный цикл в соответствии с определением реагирования на ИИБ из NIST 800-61 Rev 2:
Подготовка.
Идентификация инцидента.
Локализация угрозы.
Устранение угрозы.
Восстановление (смягчение последствий реализации угрозы).
Действия после инцидента.
Мы представили жизненный цикл инцидента на прямой, нанесли на него стадии атаки — см. рисунок ниже.
![Метрики киберустойчивости Метрики киберустойчивости](https://habrastorage.org/getpro/habr/upload_files/57d/56e/c57/57d56ec575698460c84926a47f84e89f.png)
За основную метрику действий атакующего мы взяли время атаки — Time to Attack (ТТА): время от первоначального доступа до начала реализации недопустимого события. С ней мы и будем работать дальше. Есть еще одна метрика — Time to Contain (TTC): время локализации инцидента. Это время от категоризации инцидента (то есть когда становится ясно, что делать) до окончания локализации (блокирования и изоляции агента угрозы), но на данном этапе она определяется экспертно.
Зная шаги, которые нужно проделать атакующему в ИТ-инфраструктуре, можно определить вероятные маршруты атаки. Для этого нужно собрать данные с ИТ-инфраструктуры по пути следования атакующего, создать так называемую матрицу достижимости и загрузить полученные файлы в математическую модель для расчета. На выходе мы получаем граф достижимости целевой системы, тактики и техники, которые будут использованы, и время, которое потребуется для реализации атаки. Подробнее см. рисунок ниже.
![Недопустимое событие: несанкционированный доступ к бизнес-системе ERP Недопустимое событие: несанкционированный доступ к бизнес-системе ERP](https://habrastorage.org/getpro/habr/upload_files/fc1/343/64d/fc134364d40822b996e6a439a63c8657.png)
Итак, посчитав маршрут и время атаки, нужно ответить на вопрос: а что нужно сделать, чтобы путь атакующего был долгим, сложным и «шумным»?
Чтобы ответить на него, нужна большая экспертиза в ИТ и сотни выполненных проектов по инфраструктуре, сетевой части, нужна экспертиза в разработке, разных системах, в том числе и прикладных.
Следующий шаг — формирование инициатив, или проектов. Набор инициатив (проектов) мы формируем исходя из нашей экспертизы и достаточно хорошего понимания ИТ-инфраструктуры клиента (не зря же мы собирали столько параметров с узлов и сетевого оборудования). Хотел бы обратить внимание, что недостаточно просто просканировать узел и получить информацию об уязвимостях — мы идем глубже и собираем порой совершенно уникальную информацию.
Под каждый конкретный проект для каждой конкретной компании вырабатывается отдельный список мер.
Например, проект по модернизации сети может включать в себя такие меры, как:
сегментация сети;
использование правил доступа из одного сегмента сети в другой;
выделение DMZ.
Другой пример проекта — IT-харденинг, который подразумевает усиление или изменение парольной политики, настройку уведомлений и т. д.
Итак, меры выработаны, проекты определены, произведена оценка влияния выбранных мер на метрики киберустойчивости (см. рисунок ниже). Кстати, эти визуализации очень «заходят» бизнесу.
![Визуализация метрик киберустойчивости Визуализация метрик киберустойчивости](https://habrastorage.org/getpro/habr/upload_files/44b/6e6/d5f/44b6e6d5fccee026ca62059739124c9f.png)
Что дальше? Дальше нужно это реализовать. Это непростая задача, которая требует грамотного подхода со стороны интегратора, ресурсов со стороны клиента (как правило, это специалисты, которые будут содействовать интегратору). Но выполнение инициатив будет означать готовность клиента перейти на следующий шаг и проверить свою киберустойчивость на площадке багбаунти.
Важно сказать, что этот подход разработан с учетом того, что им будут пользоваться наши партнеры и клиенты, то есть мы разрабатываем открытый стандарт для всех желающих сделать свой бизнес и бизнес своих заказчиков более киберустойчивым.
Заключение
Эта статья — первая из цикла статей про подход к определению киберустойчивости ИТ-инфраструктуры. Здесь я лишь вкратце коснулся нашего подхода. Показал, что в его основе лежит сильный математический аппарат для расчета метрик киберустойчивости. В следующих материалах рассмотрим составные части (подсистемы) ИТ-инфраструктуры и остановимся подробнее на том, какие рекомендации можно применить к каждой из них для увеличения времени атаки, покажем, как наш подход работает на практике. Словом, не переключайтесь!
![](https://habrastorage.org/getpro/habr/upload_files/d54/45d/fa8/d5445dfa8f64bd321fc025e2e1ef3f09.jpg)
Артём Мелёхин
Заместитель директора по развитию бизнеса инфраструктурных проектов, Positive Technologies
Комментарии (16)
ErshoffPeter
02.09.2024 12:42вынужденный простой обойдется компании гораздо дороже, чем средства, затраченные на ИТ-инфраструктуру
- прощу прощения, за пессимизм, но за свои тридцать лет в ИТ регулярно встречаю ответ на такой вопрос ответ "никогда такого не было и не будет никогда пока мы тут работаем, а если что - вы всё быстро почините и исправите".
Но в целом удаётся договорится и риски снизить насколько это возможно.
При этом косяки (операционные риски) самого ИТ, подрядчиков и даже вендоров лежать в другой плоскости, чем эта статья.
ePGfree
02.09.2024 12:42А что мешает работникам вот такой компании которая собрала все эти данные по инфраструктуре самим взломать защищаемую компанию?
mkader
02.09.2024 12:42+1Узость этого мира ... это 100% станет известно, и общие репутационные потери просто убьют компанию. Поэтому одно из Недопустимых Событий самого Positive Technologies - подтвержденная утечка пентестерского отчета.
devops_sergeant
02.09.2024 12:42Даже не узость... Просто в какой-то момент это может быть использовано самими positive для шантажа и захвата компаний. В реалиях корпоративных войн иб компании одновременно и самые полезные и самые страшные
mkader
02.09.2024 12:42+1Не сработает по причине выше. Но человеческие фантазии безграничны, особенно без опоры на практику и прецеденты на конкретном рынке.
petrovich4
02.09.2024 12:42Поддержу Михаила и скажу, что CISO и CIO компании должны предвидеть все все возможные векторы атак, "дружить", знать недопустимые события для компании, постоянно отслеживать попытки компрометации ИТ-инфраструктуры и иметь план действий на случай атаки и придерживаться его.
itGuevara
02.09.2024 12:42По терминам. ГОСТ Р 57580.3-2022:
3.28 операционная надежность (в условиях возможной реализации информационных угроз); киберустойчивость: Способность финансовой организации обеспечивать непрерывность функционирования бизнес- и технологических процессов (3.1) с учетом целевых показателей операционной надежности в условиях возможной реализации информационных угроз.
Вроде как киберустойчивость = операционная надежность?
Каким классификатором понятий пользуетесь, из какого NIST и другого стандарта? Словарь терминов, но с некой иерархией и смежными областями, чтобы понять как кто с кем соотносится.
Похожее уже спрашивал (обеспечение непрерывности и т.п.)
vmpotapov
02.09.2024 12:42Киберустойчивость - способность организации продолжать нормальную деятельность под кибервоздействием. Причина отказа может быть сугубо внутренней и иметь совершенно случайный характер. Например, поломка (отказ) жёсткого диска, процессора, порта, и пр. по собственным причинам, без внешнего воздействия. А вот киберустойчивость - это как раз про внешнее воздействие. Если следовать букве ГОСТа, то эти термины во многом эквивалентны.
Мы используем различные стандартны и фреймворки в нашей терминологии - я думаю их легко с десяток может набраться.
itGuevara
02.09.2024 12:42Киберустойчивость \ кибервоздействия - в каких попугаях (единицах) измеряете? Как классифицируете, например, Инсайд (мошенник - сотрудник) - это кибератака?
Мы используем различные стандартны и фреймворки в нашей терминологии - я думаю их легко с десяток может набраться.
Почему бы их тут и не перечислить?
Однако я больше про большой толковый и главное - не противоречивый словарь по терминологии. Хотелось бы иерархический словарь - таксономию, в идеале онтологию, типа InformationSecurityOntology
Онтология InformationSecurityOntology в редакторе онтологий Protege
alker
02.09.2024 12:42Как мне кажется, цели атакующего и недопустимые события - не обязательно совпадающие списки. Первый список шире. С одной стороны подход "от недопустимых событий" упрощает понимание целей работы отдела ИБ для руководства, с другой стороны важно не забывать и про другие цели атакующего - это важно уже для сотрудников отдела ИБ.
Смущает то, что в статье по архитектуре решений ИБ вы отталкиваетесь от целей, определяемых только недопустимыми событиями.
petrovich4
02.09.2024 12:42Результативная кибербезопасность - это наш подход. В статье мы также отталкиваемся от тех событий, которые могли бы нанести максимальный ущерб бизнесу или полностью его остановить. Первое, что мы советуем, это определить те события, которые приведут бизнес к наибольшим потерям или полностью его остановят. Предполагаем, что остальное не так важно и бизнес к этому готов. Если же не готов, то это повод задуматься.
Например, вывод из строя ERP-системы совместно с резервным копированием может иметь серьезные последствия для бизнеса, если нет иной возможности восстановления. И это реальный пример из проектов.alker
02.09.2024 12:42Допустим, утечка персональных данных на предприятии не является недопустимым событием, значит ли это что сервер на котором они находятся не будет целью атакующего? Нет.
Если подходить комплексно, то нужно рассматривать весь спектр событий информационной безопасности.
Тем не менее, на суть статьи этот момент не влияет.
Shaman_RSHU
Очень интересная и важная тема. Если не секрет - а какой процент владельцев бизнеса отправляют за недопустимыми событиями к какому-нибудь из одних своих замов, у которых однобокий взгляд?
mkader
Это как раз "правильно" в плане типового проекте - после определения НС на уровне Владельца бизнеса - его детализацией занимается владелец бизнес-процесса и дальше идет уже декомпозиция на соответствующие ИТ-системы. Как показывает практика сильно не одной компании - такой подход как раз и работает.
Shaman_RSHU
Так я говорю про то, что владелец бизнеса сразу отправляет к замам за НС, даже не удосуживаясь сказать список, по которым они будут детализировать. Пока что-нибудь не случиться - никаких предварительных мер предпринимать не будут.
petrovich4
На самом деле, очень много владельцев, акционеров и собственников бизнеса приходят с запросом о безопасности с гарантированным результатом. Но тут и для заместителя очень важно убедить владельца бизнеса в том, что ему нужно инвестировать свое ценное и дорогое время для определения и выявления недопустимого ущерба (они же недопустимые события).