Как мы строили ИБ раньше и почему теперь это не работает?
Макрофреймворк по ИБ «Модель Аэропорт».
Как работать с рисками катастрофических инцидентов ИБ?
Зачем что-то менять?
Давайте сперва разберемся, как строилась информационная безопасность ранее и строится сейчас. Мы выделяем 3 крупные технологические эпохи c разными подходами к защите.
1. Бастион
Подход, характерный для обработки информации в бумажном виде или на изолированных АРМ / в сетях. Здесь используются способы защиты, проверенные тысячелетиями: решетки на окнах, сейфы, вооруженная охрана и проверка персонала. Есть области, где и сегодня лучший межсетевой экран — это толстый слой диэлектрика. Это характерно для защиты гостайны и некоторых критических технологических сетей.
2. Цифровой бастион
Классический подход, основанный на выстраивании периметра защиты для ИТ-инфраструктуры, где «враги» снаружи, а «свои» внутри. Неактуальность такой модели обсуждают уже лет 10, но на деле именно она до сих пор лежит в основе защиты большинства российских компаний и госучреждений, транслируется в «нормативке» регуляторов. И кое-где она до сих пор вполне применима, но, скорее, не для организаций целиком, а для отдельных защищенных сегментов внутри корпоративной инфраструктуры.
3. Аэропорт
Облачные сервисы, массовый удаленный доступ, непрерывное изменение ИТ-инфраструктуры, идеология DevOps, безумное число 0-day-уязвимостей, необходимость удобной работы с десятками корпоративных систем, подрядчиками, заказчиками из любой точки Земли и при этом ограниченные человеческие и финансовые ресурсы на ИБ — новая реальность Инфраструктуры 3.0. Эту инфраструктуру ни в какие бастионы не запрешь, а ее взлом практически невозможно предотвратить. Но руки опускать не стоит. С этим тоже можно работать.
Макрофреймворк «Модель Аэропорт»
Перед нами постоянно стоит задача синхронизации наших специалистов по ИБ в части подходов к защите. Где-то мы опираемся на готовые фреймворки, а порой создаем свои или компилируем. Например, так мы создали фреймворки по защите контейнерной инфраструктуры, облачных сервисов или по построению безопасных методов доступа подрядчиков в инфраструктуру. «Модель Аэропорт» стала макрофреймворком по ИБ, которая описывает то, как мы видим защиту современной крупной компании.
Современный аэропорт — это объект, который должен создать комфортные условия для миллионов пассажиров в год. При этом в случае, если злоумышленник доберется до самолетов или критических систем аэропорта, возможна катастрофа. Такая же дилемма сейчас сформировалась для ИТ. Взлом может привести к полной остановке бизнеса. Самый банальный сценарий: захват контроля над AD, распространение по всем машинам шифровальщика, зачастую еще и ворующего информацию до шифрования, уничтожение резервных копий.
Никому не придет в голову защищать все зоны аэропорта одинаково — с равной степенью тщательности проверять всю многомиллионную толпу на входе, на таможенном контроле и перед входом в зону прилетов. Попасть внутрь могут практически все: достаточно пройти через рамки металлоискателя. Но чем ближе пассажир к трапу самолета, тем строже правила. При входе в зону посадки придется не только показать документы и содержимое ручной клади, но и отправить в корзину для мусора все, что представляет хоть какую-то опасность. Каждое движение при этом фиксируется видеомониторингом, а служба охраны готова среагировать на любое подозрительное действие. Все выстроено так, чтобы злоумышленник не смог добраться туда, где его действия могли бы привести к катастрофе.
Такой же подход хорошо вписывается в потребности компаний с точки зрения ИБ, так как позволяет строить надежную защиту в условиях ограниченных ресурсов, то есть экономически эффективно.
Все риски в копании мы предлагаем разделить на 3 группы: катастрофические, серьезные и все прочие. Максимальный акцент должен быть на катастрофических сценариях, то есть на тех, реализация которых ставит компанию на грань выживания. Это могут быть очень крупные хищения, гибель людей, потеря всех корпоративных данных, длительная остановка основного бизнеса. Такой черный список для каждой компании свой. Необходимо трезво подойти к его составлению: привлечь менеджмент к этой задаче и не раздувать количество пунктов за счет сказочных сценариев. Очень важно не замыкаться в ИТ- и ИБ-блоках на этом этапе. Например, у нас в компании существеннейший вклад в формулирование сценариев катастроф внесли финансовый директор, главный бухгалтер и руководство департамента закупок и логистики.
Мы не можем просто «снизить риски» катастрофы. Нам нужно сделать ее вероятность близкой к нулю. Для катастрофических сценариев мы предлагаем расписать всю цепочку событий, которая может привести злоумышленника к успеху. Важно продумать, как злоумышленник двигался бы по ИТ-инфраструктуре: какие системы взламывал, какие СЗИ обходил, каких пользователей обманул. Составить такие цепочки последовательных действий можно только с участием руководителей и специалистов как бизнес-юнитов, так и ИТ. Когда цепочки событий будут готовы, их должны верифицировать пентестеры: «белые хакеры» должны пройти путем потенциального злоумышленника. Здесь цепочки событий уточняются, а многие просто отбрасываются как нереализуемые. Защита строится на рассечении этих цепочек событий. Как? Об этом ниже.
Важно обозначить границу, после которой мы считаем событие катастрофическим, чтобы не распыляться. Это должна быть, например, конкретная сумма потерянных денег (как вариант, миллиард рублей) или определенный масштаб техногенной катастрофы. Это делает работу фокусной, не распыляет внимания специалистов и экономит время.
Нас точно взломают, никаких непреодолимых периметров нет, а «защищенная внутренняя сеть» — не более чем миф.
Когда мы проводили такие работы в нашей компании, то решили несколько расширить моделирование не только на «катастрофы», но и на «события с очень неприятными последствиями». Для этого выбрали следующий критерий: опасность достаточно существенная, чтобы мы серьезно поменяли бизнес-процессы и смирились с потерей удобства работы, если будет необходимо. А уже этот критерий мы накладывали на разные негативные последствия.
Для остальных двух категорий («серьезных» и «прочих» рисков) такое моделирование в большинстве случаев окажется неподъемным. Здесь вполне можно обойтись традиционным риск-ориентированным подходом и проверенными лучшими практиками.
Как защититься?
Итак, мы сформулировали, от чего защищаемся. Вторая часть «Модели Аэропорт» посвящена тому, как выстроить работающую систему защиты в условиях ограниченных ресурсов.
Базовый принцип здесь такой:
Похитить у компании, скажем, 5 млн руб. можно сотнями способов. А вот 500 млн — это обычно куда меньшее число реалистичных сценариев.
Мы, конечно, не призываем бросить периметр компании на растерзание киберпреступникам. Но нужно быть реалистами: скорее всего, рано или поздно кто-то найдет способ пробраться через рамки металлоискателя на входе нашего аэропорта. И нужно встречать его во всеоружии. Поэтому наш макрофреймворк предполагает систему, состоящую из трех уровней защиты (см. рис. 1).
Задача первого уровня — сделать так, чтобы удачливый взломщик не смог быстро продвигаться по ИТ-инфраструктуре компании на пути к критически важным системам. Этот уровень защиты должен выиграть для нас время.
Самый эффективный, но сложный способ реализовать это — изменить бизнес-процессы так, чтобы нанести большой вред было трудно. Безопасность при этом обеспечивается за счет разделения полномочий, дополнительных подтверждений критических операций, а иногда и отказа от автоматизации на отдельных участках. Пойти на это можно не всегда, но для подтвержденных на практике катастрофичных сценариев это разумно.
Второй способ — изменение ИТ-инфраструктуры. Необходимо внимательно подходить к проектированию решений с использованием принципов ИБ, выстроить качественное сегментирование и управление доступом. Бодро маршировать по такой инфраструктуре у злоумышленника не получится. Впрочем, звучит это проще, чем есть на деле. Если инфраструктура не строится с нуля, перестраивать ее в действующей компании бывает достаточно хлопотно и затратно.
Третий способ — внедрение средств защиты и обучение пользователей — гораздо проще первых двух за счет того, что меньше влияет на привычное функционирование организации. Но это не означает, что нужно замыкаться только на нем, хотя это и привычный подход. Если ИТ-инфраструктура спроектирована совсем плохо, защитить ее не получится никакими СЗИ. Есть и бизнес-процессы, построенные так, что слишком большое число пользователей могут нанести внушительный ущерб, а стопроцентной защиты от фишинга или внутреннего злоумышленника не даст ни одно средство защиты.
У нас в компании существеннейший вклад в формулирование сценариев катастроф внесли финансовый директор, главный бухгалтер и руководство департамента закупок и логистики.
Задача второго уровня «Модели Аэропорт» — построить многоуровневый мониторинг и оперативное реагирование. Чтобы обнаружить развитие атаки до того, как нанесен существенный урон, мониторинг должен охватывать уровень и инфраструктуры, и работы бизнес-систем, а также учитывать данные, полученные с помощью киберразведки (OSINT и TI). Оперативному реагированию чаще всего мешает человеческий фактор, поэтому важно внимательно отнестись к составлению и отработке плейбуков, жестких SLA и автоматизации, где это возможно. Такой комплексный SOC уже не строится вокруг SIEM-системы, а использует ее всего лишь как один из инструментов.
Задача третьего уровня модели — испытать безопасность компании на прочность и залатать все обнаруженные дыры. Тестирование на проникновение, как лакмусовая бумажка, показывает ошибки, недочеты, неправильно заданные правила доступа. А киберучения или RedTeam выявят пробелы в навыках ИБ-специалистов и помогут им подготовиться к реальной атаке.
Киберучения лучше проводить под руководством инструкторов и с дополнительной отработкой сценариев, в которых чаще всего допускаются ошибки. Естественно, чтобы ничего не сломать в ИТ-инфраструктуре компании, учения стоит проводить на отдельном полигоне. В свое время мы построили у себя такой киберполигон, чтобы тестировать СЗИ и обучать своих сотрудников, а сейчас наш Jet CyberCamp предоставляется как кастомизированный коммерческий сервис.
Наш фреймворк «Модель Аэропорт», конечно же, опирается на существующие подходы. Например, здесь немало от концепции Zero Trust с ее принципами «never trust, always verify» и «perimeterless security», а в части моделирования катастрофичных сценариев много пересечений с концепцией «ИБ 2.0» от Positive Technologies. Даже саму аналогию с аэропортом мы подсмотрели у ИБ-специалистов из Société Générale. Это позволяет нам верить, что в «Модели Аэропорт» действительно сформулированы принципы, на которых будет строиться безопасность в 2020-х.