В последнее время крупные компании активно внедряют методологию гибкого (agile) проектного управления. Ее преимущества бесспорны, но невозможность оперативного обеспечения защиты бизнес-функций в рамках традиционного подхода (разделения этапов разработки и безопасности) является существенной проблемой. А значит, пришло время изменения этого подхода.
Методология agile подразумевает отказ от долгосрочного планирования бизнес-систем в пользу постоянных небольших изменений под влиянием внешних и внутренних потребностей. Лидеры применения данной методологии проводят тысячи функциональных изменений в день, и это – не предел.
Бесспорные «плюсы» такого подхода активно рекламируются: бизнес может быстро опробовать новую бизнес-функцию и сразу, без дорогостоящих исследований, получить обратную связь с пользователями. Гораздо меньше говорят о минусах. Одним из них является невозможность оперативного обеспечения безопасности бизнес-функций в рамках традиционного подхода, подразумевающего разделение функций защиты и разработки: сначала строится бизнес-система, а затем на нее «навешиваются» системы безопасности.
Каждое изменение бизнес-системы несет в себе угрозы, и при использовании «навесной» архитектуры безопасности любое изменение в бизнес-системе должно вести к перенастройке внешней системы защиты. Еще лет пять назад такой проблемы не было – информационные системы изменялись раз в квартал, а то и в полгода, поэтому компании успевали проводить тестирование в лаборатории или заказывать сторонний аудит безопасности. Сегодня изменения в финансовых системах происходят раз в два-три дня, а в системах электронной коммерции еще чаще.
Пока у служб, отвечающих за ИБ, еще есть возможность изучать новые функции и изменять настройки «навесных» систем защиты. Но что они станут делать, когда изменения начнут возникать чаще – каждый час, каждую минуту? Если пентест занимает три недели, а новый функционал появляется раз в неделю, то отчет пентестеров будет устаревать сразу: к моменту его выпуска система успеет поменяться дважды. К тому же результаты пентеста почти всегда приводят к необходимости вносить в системы какие-то изменения, что еще более удлиняет процесс.
Смена парадигмы
Рассмотрев стадии развития отношений систем защиты с защищаемым объектом, можно увидеть, что прямо сейчас происходит смена парадигмы.
Защита первых бизнес-систем реализовалась единообразно, без учета их особенностей. Когда бизнес-системы стали достаточно сложными, появились адаптивные системы защиты, предварительно изучающие объект и настраивающиеся в соответствии с его состоянием. Их распространение привело к использованию всевозможных сканеров безопасности, а затем – к расцвету пассивной безопасности: системы защиты не отражают атаки самостоятельно, а лишь сообщают оператору о подозрительных событиях и аномалиях. Причина применения такого подхода состоит в том, что современные системы защиты часто демонстрируют ложные срабатывания, и если перевести их в активный режим, важные для бизнеса процессы будут постоянно останавливаться.
Соответственно, до недавнего времени в компаниях росло количество сотрудников служб ИБ, обеспечивающих поддержку работы систем пассивной безопасности. И именно люди являются слабым звеном при атаках: многие из них оказывались успешными лишь из-за того, что дежурная смена действовала не вовремя или не должным образом. В период экономического кризиса ситуация еще больше усложнилась, поскольку далеко не все компании могут содержать квалифицированных ИБ-сотрудников.
А вот системы защиты следующего поколения не только изменяют свои настройки в зависимости от состояния бизнес-систем, но и дают рекомендации по изменению последних, то есть связь «система обеспечения безопасности – защищаемый объект» становится двусторонней. Такая взаимосвязь позволяет кардинально решить проблему ложных срабатываний и, соответственно, вернуться к активной защите. Это хорошо видно на примере действия активной взаимосвязи при построении бизнес-приложений на основе веб-технологий (их разработка переходит на методологию agile одной из первых).
Сегодняшняя ситуация
У вас есть веб-приложение и некий стратегический план его развития. Информация о конкретных функциях регулярно поступает от бизнес-руководителей, придумавших или углядевших у конкурентов новую услугу или функцию, которую «еще вчера» надо было бы реализовать в приложении.
Допустим, такой функцией является маркетинговая акция «Покупаешь диван – получаешь торшер за половину цены». Разработчики, которые действуют сами по себе, оперативно «выкатывают» релиз с формой «Добавить в заказ торшер за полцены» и различными рекламными «фишками» – например, вывешивают на странице заказа дивана баннер с ссылкой на торшеры.
Потом служба ИБ разворачивает этот релиз в тестовой среде и анализирует его с помощью различных сканеров. Ура, нашли критическую уязвимость, SQL-инъекцию в форме заказа! Надо бы исправить, но ведь приложение уже собрано, его разработка в текущей версии закончилась, спринт сдан и команда приступила к работе над следующим. Исправление займет некоторое время, для этого придется отвлечь команду разработчиков от новых функций, а склад переполнен торшерами, за чье хранение приходится платить. Скорее всего, в такой ситуации уязвимый функционал будет-таки введен в надежде на то, что торшеры раскупят раньше, чем хакеры найдут и проэксплуатируют уязвимость. Эта ситуация повторяется снова и снова, а в результате количество атак на прикладном уровне быстро растет.
В компаниях нет специалистов, ответственных за защищенность цифрового ресурса в целом: за программистов отвечает один сотрудник, за настройку средств безопасности – другой, а за инфраструктуру – третий. Поэтому оперативно решать, исправлять ли в данном случае приложение или принять риск, просто некому.
Что нужно сделать? Ввести единую точку принятия решений по всем аспектам цифрового бизнеса (бизнес-задача, функционал, разработка, настройка средств защиты, инфраструктура). Приблизить анализ защищенности к разработке: исправление уязвимостей, найденных еще на этапе кодирования, обходится на порядок дешевле и выполняется гораздо быстрее, чем устранение ошибок, обнаруженных при тестировании. И, конечно, автоматизировать управление настройками активных систем защиты в зависимости от изменений функционала.
Подход Continuous security
Работа с полностью автоматическими системами обеспечения безопасности веб-приложений (Continuous security) проходит так. Уже во время разработки статические сканеры устанавливают рискованные функции и дают рекомендации по их исправлению – в этот период выполнить его легко. Но даже если по каким-то причинам рекомендации не будут реализованы, к моменту сдачи приложения окажутся известны все его уязвимости и векторы атак на них.
Затем «эксплуатируемость» векторов атак можно будет оперативно проверить с помощью динамического сканера на уже собранном приложении при реальных настройках. В первую очередь понадобится исправить выявленные эксплуатируемые критичные уязвимости, а неэксплуатируемые отсеять. Впрочем, последние тоже рекомендуется исправить; можно изменить настройки или использовать уязвимый код в другом приложении. Проверка с помощью динамического сканера гипотез, полученных в результате статического анализа, позволяет добиваться оптимального сочетания полноты и точности анализа, сокращать время, необходимое для проведения автоматизированных пентестов (сканер уже в начале анализа знает, какой функционал как атаковать).
Для исправления найденных уязвимостей нужно время, а бизнес торопит? Continuous security подразумевает безопасный запуск даже уязвимых систем. Пока проблемы не устранены, система защиты будет блокировать опасный доступ к уязвимому функционалу. Информация об уязвимостях и способах их эксплуатации автоматически передается от пассивных средств защиты (сканеров) к активным – DDoS-фильтрам и межсетевым экранам прикладного уровня (WAF). Активные системы автоматически адаптируют свои настройки так, чтобы прикрывать уязвимый функционал, добавляя в фильтры виртуальные патчи – правила фильтрации, которые позволяют не пропускать опасные запросы к этому функционалу.
Подход Continuous security, обеспечивающий защиту гибкой разработки бизнес-приложений, гораздо эффективнее самообучения, используемого сегодня для адаптации настроек средств защиты под изменяющийся функционал. Средний срок полноценного самообучения средств защиты исчисляется часами (3–15 ч), а при неравномерном суточном трафике занимает больше суток (дабы не принимать временные аномалии за атаки). При этом на время обучения отключается режим защиты, иначе новый функционал будет принят старыми настройками за аномалию и заблокирован. А значит, при еще большем учащении обновлений функционала средства безопасности впадут в непрерывный режим самообучения и вовсе перестанут защищать объект.
В случае гибкой разработки жесткая обратная связь «от векторов атаки – к настройкам» оказывается эффективнее самообучения. С ее помощью удается достичь компромисса между разработкой, безопасностью и бизнесом. Если раньше в крупных организациях time-to-market (время между придумыванием бизнес-функции и ее запуском в промышленную эксплуатацию) составлял год или более, то сейчас никто не может себе позволить ждать так долго: ввод новых бизнес-функций происходит в финансовой сфере за два-три месяца, а в области электронной коммерции – за неделю. Оставаясь в рамках старой парадигмы «Дайте нам объект защиты, и мы его исследуем, а потом защитим», службы ИБ уже совсем скоро не смогут удовлетворять требования бизнеса.
Для адаптации к новым требованиям ИБ-подразделениям придется менять не только инструменты, но и общий подход – подключаться к рабочим группам, реализующим бизнес-функции на более ранних этапах, использовать принципы Continuous security для защиты информационных систем своей компании. Вполне возможно, что в результате трансформации процессов ИБ в полностью цифровых компаниях отдельная служба безопасности перестанет существовать и «размажется» по всем процессам.