Прощайте границы компетенций между ИТ и ИБ

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

Новые угрозы

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

Но гипотетически каждое изменение бизнес-системы несёт в себе угрозы. Новые строчки кода могут нести в себе уязвимости или намеренные закладки. Новая учётная запись сотрудника во внутренней системе или клиента во внешней может быть создана с легко подбираемым паролем или с необоснованно высокими привилегиями. Также и новый процесс может содержать в себе возможности для мошенничества. Поэтому при «навесной» архитектуре безопасности каждое изменение в бизнес-системе должно вести к перенастройке системы защиты. Еще пять лет назад такой проблемы не было – изменения информационных систем проходили хорошо, если раз в месяц, а чаще – раз в квартал, было время не спеша провести тестирование системы в лаборатории и обезопасить себя, заказав сторонний аудит безопасности. Сегодня в большинстве банковских систем изменения идут уже раз в 2-3 дня, в промышленности существенно реже, а в электронной коммерции наоборот, чаще. В этих условиях у служб, отвечающих за информационную безопасность, теоретически есть возможность изучить новые функции и изменить настройки «навесных» систем защиты. Однако, что и как смогут сделать защитники информации с системами защиты, если изменения будут идти каждый час, каждую минуту? В чём смысл пентеста (от “penetration test”– “тест на проникновение”), если он длится неделю, а изменения идут ежедневно? О защищённости какой системы вы получите отчёт после пентеста?

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

Ретроспектива ИБ 

Если посмотреть на стадии развития отношений систем защиты с защищаемым объектом, то можно увидеть, что прямо сейчас происходит смена парадигм. Было время, когда защита бизнес-систем была организована одинаково, независима от того, что они защищали, без учёта их особенностей. Затем защищаемые системы стали достаточно сложными и появились «адаптивные» системы защиты, изучающие объект защиты перед тем, как его защищать и настраивающие систему защиты под конкретное состояние объекта. Расцвет таких систем породил огромное количество сканеров безопасности, однако такие сканеры были пассивными и не интегрированными в систему защиту, что привело к расцвету концепции «пассивной безопасности». Она подразумевает, что системы защиты не отражают атаки самостоятельно, а сообщают о подозрительных событиях и аномалиях, а решения об активной защите на основе этой информации принимают сотрудники службы защиты. Такой подход возник из-за того, что современные системы защиты недостаточно хорошо справляются с точностью определения атак, генерируя большое количество ложных срабатываний. Если дать им возможность принимать решения, а не просто информировать дежурную службу об аномалиях, то слишком много чувствительных для бизнеса процессов будет остановлено. Как следствие, в компаниях растёт количество сотрудников службы информационной безопасности, для поддержки работы систем пассивной безопасности на важных бизнес-приложениях вводятся круглосуточные дежурные смены.

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

Следующее поколение систем защиты бизнес-систем не только изменяет свои настройки в зависимости от состояния системы, но и даёт рекомендации по изменению самой защищаемой системы, то есть связь «система защиты» - «защищаемы объект» становится двухсторонней. Никакая система защиты не справится с защитой системы, которая не помогает себя защищать, а наоборот, противодействует этому. Подобная взаимосвязь объекта и системы защиты позволяет вернуться к активной защите, поскольку эта взаимосвязь позволяет кардинально решить проблему ложных срабатываний.

Agile-примеры

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

В этих случаях разработчики «выкатывают» релиз, который вы разворачиваете в тестовой среде и анализируете различными сканерами. Предположим, вы нашли одну критическую уязвимость, но вы нашли её, когда приложение уже собрано, его разработка в текущей версии уже закончилась, релиз сдан – возможно, исправление займёт много времени и человеческих ресурсов, чего зачастую бизнес не может себе позволить – новая функция нужна ему здесь и сейчас. Поэтому, скорее всего, риски эксплуатации этой уязвимости будут приняты, а функционал будет запущен в продуктив. Остается верить и надеяться, что при атаке на эту уязвимость сработают средства защиты. Но такой подход в последние годы привёл к тому, что количество атак на прикладном уровне, с учётом особенностей заказных приложений, растёт опережающими темпами.

Где же выход? Скорее всего, следует ожидать, что будет работать сочетание нескольких подходов – концентрация ответственности (разработка-средства защиты-инфраструктура) в одних руках, полная автоматизация управления настройками систем защиты и продвижение анализа защищённости «вглубь разработки». Последнее означает, что анализировать защищённость надо ещё в процессе кодирования, когда стоимость исправления ошибки в людях и часах сравнительно невелика. Поэтому службы информационной безопасности при переходе бизнеса к гибким быстроменяющимся системам должны поменять не только средства защиты на более эффективные и интегрированные, но и изменить сам подход к защите, подключаться к рабочим группам, реализующим бизнес-функции на более ранних этапах, и использовать принципы continuous security для защиты информационных систем своей компании.

Или ИТ и ИБ поменяются, адаптируясь под новые требования безопасности бизнеса. Или интересы бизнеса сместят нас...