Робо-страж: защита интернет-банка по Кевину Костнеру
В 2014 году активный рост привел банк из Топ-50 (80 офисов по всей России, штат – больше 1500 сотрудников) к вполне закономерному решению запустить интернет-банк для физических лиц.
Для службы ИБ задача была поставлена так:
- надо выпустить сервис «как есть», то есть времени для всестороннего тестирования нет;
- изменения будут идти постоянно, поскольку допускается, что сервис интернет-банка будет обновляться;
- увеличение штата не предусмотрено.
Из такой постановки задачи следовало, что защита должна быть:
- автоматической, то есть система защиты должна самостоятельно принимать решения, а не делегировать принятие решения дежурным аналитикам информационной безопасности – их просто нет.
- интегрированной, то есть не представлять из себя набор несвязанных модулей по защите от разных видов угроз, поскольку это увеличит нагрузку на персонал;
- активной, то есть иметь возможность работать в режиме блокирования атак, а не в режиме оповещения о них.
Ситуация достаточно типовая для кризисного времени: банк не собирался расширять штат сотрудников и при этом не выводил защиту нового ресурса на аутсорсинг. На это наложилась срочность бизнес-задачи: началась рекламная кампания, времени для совершенствования функционала интернет-банка не было, решено было начать с малого и постепенно добавлять функционал.
Традиционный подход к защите веб-ресурсов выглядит так: внедряется много разных полезных пассивных устройств – различные сканеры уязвимостей (статические и динамические), WAF, antiDDoS. Когда эти устройства покажут начавшуюся атаку, дежурная смена операторов вручную «отбивает» атаку, например, переключает трафик на центр очистки или блокирует доступ к некоторым функциям или с некоторых адресов. Однако в данном случае это не представлялось возможным – бюджет проекта не подразумевал никаких дополнительных вакансий, всё надо было решить в рамках существующего штатного расписания, в котором люди и так были перегружены.
В идеальной модели безопасной разработки, когда разработчики действуют рука об руку со службой информационной безопасности и уязвимости приложения купируются на ранних стадиях, эта задача имела красивое решение. Но в реальном мире, где разработчики живут своей жизнью, а служба информационной безопасности подключается на последних стадиях, такую задачу решить в принципе невозможно – уязвимости в приложении обычно находятся уже тогда, когда исправлять что-то уже довольно долго и дорого.
Получилось, что есть реальная ситуация, в которой задача не решается и есть идеальная ситуация, где она решается с лёгкостью. Как в анекдоте, в котором мышкам посоветовали стать ежиками и тогда все их проблемы с хищниками закончатся. «А как же мы, мышки, станем ежиками?» - «Не грузите меня деталями, я консультант и занимаюсь стратегией». Мы оказались именно в такой ситуации.
Для начала мы рассмотрели классические подходы.
Вариант 1. Фантастический
Сделать всё правильно: внедрить SDL, научить программистов, найти на это бюджеты. Отладить процессы непрерывной разработки с постоянным встраиванием систем безопасности. Для нас этот вариант не подходил. Долго и дорого.
Вариант 2. Советский
Получить право вето. Пугать бизнес и программистов. Такой вариант – поставить шлагбаум и пока не будут исправлены все уязвимости, не вводить систему в действие – вполне рабочий в государственных организациях, но для коммерческого банка он был не приемлем.
Вариант 3. Поэтапное сотрудничество
Мы выбрали третий путь: встроиться и стать полезным. Мы стали искать пути к сотрудничеству и с бизнесом (обеспечивать рабочий функционал и отсутствие инцидентов информационной безопасности), и с разработчиками (помогать им разрабатывать безопасные приложения с помощью «мягкой силы»).
Отношения защищаемой системы и системы защиты проходят четыре этапа.
Первый базовый этап – это защита «Как есть». Вот объект, а вот навешанная на него защита.
Второй этап – мы начинаем изучать объект перед его защитой. Технически это выглядит как запуск различных сканеров, результат работы которых позволяет понять уязвимые места защищаемой системы и прикрыть их особенно тщательно. Этот этап назовём «Адаптация».
Дальше начинается этап, который мы назовём «Компенсация», когда мы видим: чтобы объект был в безопасности, ему необходимо измениться. И защита сама сообщает объекту, какие функции надо изменить, чтобы защита шла легче и эффективнее.
Великолепный пример перехода от фазы «Адаптация» к «Компенсации» – фильм «Телохранитель» с Кевином Костнером и Уитни Хьюстон. Там объект защиты – взбаломошная певица. Сначала профессиональный телохранитель пытается защищать её, адаптируясь к её поведению, позволяя «объекту защиты» исчезать без предупреждения, бросаться в толпу поклонников и так далее. Такая стратегия не даёт результата – происходит нападение. После инцидента певица становится более покладистой, начинает слушаться своего телохранителя, даже не смотря на ложные срабатывания, и всё заканчивается хорошо. В принципе это и есть единение безопасности и объекта защиты.
Последний этап взаимодействия объекта защиты и системы защиты – стадия полного слияния, «Интеграция». В этом случае безопасность является не сторонней системой, а функцией объекта. В нашем случае такое решение было недоступно, поэтому мы остановились на предыдущем этапе.
.jpg)
Иллюстрация 1. Этапы развития отношений объекта защиты и защиты
Главную трудность представляли постоянные изменения. Герман Греф как-то заявил, что в Сбербанке они стремятся к десяткам тысяч изменений в день. Соответственно, и нам нужно было готовиться к чему-то подобному, пусть и в меньшем масштабе и перезакладываться на рост частоты изменений. Первая мысль была о системе самообучения, но традиционные системы обучаются на реальном трафике несколько часов, поэтому самообучающая система сохранит качество распознавания атак при изменениях максимум в десяток изменений за день.
Но нашлось другое решение.
Когда веб-приложение изменяется, мы последовательно исследуем его двумя сканерами: статическим и динамическим. Статический сканер генерирует гипотезы о наличии уязвимостей, динамический их проверяет, отбрасывая неэксплуатируемые в конкретном контексте. По найденным эксплуатируемым уязвимостям выпускаются виртуальные патчи, запрещающие определённые обращения к определённым функциям сайта. Таким образом, достигается компромисс между разработкой, которая ориентируется на фичи, и ИБ, которая делает эксплуатацию объекта относительно безопасной.
Иллюстрация 2. Другое решение
В результате у нас получилось компромиссное решение, которое устроило и ИБ, и бизнес, потому что оно оказалось одновременно и сравнительно дешевым, и гибким, и функциональным. Решение не потребовало увеличения штата, работает автоматически и «в разрыв», поскольку предложенный алгоритм свёл ложные срабатывания к минимуму.
Интернет-банк был запущен в августе 2015 года. В первый же день обнаружилась весьма неприятная уязвимость, которая, к большому нашему удовольствию, безукоризненно заблокировалась виртуальным патчем, с одновременной выдачей разработчикам задания на изменение сразу в систему баг-трекинга. Система продолжает работать, атаки отбиваются, бизнес-заказчик доволен.
.png)