Популярность Web-приложений как основного инструмента онлайн-бизнеса растет из года в год, одновременно с этим все больше привлекая злоумышленников. Между тем, согласно исследованиям Contrast Security, порядка 80% Web-приложений в среднем содержат до 45 уязвимостей, из которых по крайней мере одна имеет высокий уровень критичности. Такая ситуация свидетельствует о недостаточном внимании к вопросам безопасности в процессе разработки. С внедрением методологий ускоренной разработки DevOps положение еще более усугубляется. О том, как выйти из данной ситуации и обеспечить информационную безопасность в условиях быстрой разработки, мы поговорили с Денисом Безкоровайным, генеральным директором ProtoSecurity. Поводом для этого интервью стал доклад, с которым он выступил на конференции «Agile, DevOps и ITIL – инструменты цифровизации», организованной издательством "Открытые Системы".

Журнал сетевых решений/LAN: В условиях ускоряющейся разработки приложений отставание в реализации мер безопасности становится все более критическим. Как обеспечить должную безопасность приложений в таких условиях?

Денис Безкоровайный: Да, действительно, скорость разработки увеличивается из года в год. Раньше новый релиз появлялся один раз в квартал или один раз в год, сейчас же, в условиях возрастающей конкуренции, все заказчики стремятся как можно быстрее реализовывать новый функционал. В связи с этим приходится сокращать циклы разработки: релизы выпускаются несколько раз в неделю или даже в день, так что стандартный подход, когда о безопасности задумывались лишь в самом конце, при такой модели работает очень плохо.

 

LAN: Как выйти из создавшейся ситуации?

Безкоровайный: Прежде всего если не владельцы бизнеса, то владельцы приложений должны уделять приоритетное внимание безопасности и осознавать, как последствия взломов, компрометаций и утечки данных скажутся на прибыли компании. Кроме того, необходимо пересмотреть роль специалиста по ИБ: из охранника/надзирателя, который мешает всем процессам и вставляет палки в колеса, как его часто воспринимают, он должен превратиться в партнера и ИБ-коуча.

По статистике, на одного специалиста по информационной безопасности приходится в среднем 100–200 разработчиков. В таких условиях обеспечить должный контроль крайне сложно, а значит, необходимо делиться компетенциями и делать их частью общего процесса. То есть безопасностью должны заниматься не только специалисты по ИБ, но и разработчики, тестировщики, менеджеры продукта. Правильная организация этих процессов и вовлечение в них всех команд, внедрение и насаждение культуры информационной безопасности и есть новая задача ИБ-специалистов.

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

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

Приступив уже сегодня к пересмотру роли и функций информационной безопасности в процессе разработки приложений: во-первых, сделав ИБ общей ответственностью различных команд, во-вторых, внедрив методологии DevSecOps в процесс разработки, — компания получит конкурентное преимущество в самое ближайшее время.

 

LAN: Методология интеграции принципов безопасности в ускоренный цикл разработки известна под различными названиями: DevSecOps, SecDevOps и DevOpsSec. Чем они отличаются?

Безкоровайный: По сути DevSecOps, SecDevOps и DevOpsSec — это один подход, применяемый с одной и той же целью, но с разными акцентами на безопасности. Иначе говоря, кто-то ставит ИБ на первое место, кто-то — на последнее. Отсюда и возникли термины DevSecOps, SecDevOps и DevOpsSec.

Чтобы разобраться в самом подходе, необходимо иметь представление о том, что такое DevOps. Раньше в разработке выделялись различные зоны ответственности — каждый отвечал исключительно за свой участок. Разработчики не имели представления о том, где в реальной инфраструктуре будет использоваться приложение, как его станут масштабировать и т. д. А системные администраторы и служба эксплуатации занимались вопросами инфраструктуры и были склонны возлагать ответственность на программистов, если ОС и серверы функционировали без сбоев, но при этом фиксировались какие-то неполадки в работе приложения. Такое перекладывание ответственности тормозило процесс выпуска релизов, снижая тем самым общую эффективность разработки.

Именно в связи с реальной надобностью в переломе ситуации и сформировалась парадигма объединения практик разработки, администрирования и тестирования в рамках общего процесса создания приложения, именуемая DevOps. Важно отметить, что сейчас все еще не существует единого стандарта DevOps — это скорее некий общий подход, когда ответственность за приложение разделена между всеми, кто участвует в его создании и обслуживании.

Точно так же, как и в ситуации с возникновением естественной необходимости в создании DevOps, появилась потребность во встраивании безопасности в этот подход. Ведь нет такой точки на временной шкале разработки приложения, когда наступает момент для обеспечения безопасности, — ранее защиты не было, а теперь ее пора внедрить. Так не бывает. Этим нужно заниматься все время, на каждом этапе жизненного цикла приложения. В результате и возникла идея объединения DevOps и ИБ.

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

Совершенно ясно, что невозможно сделать каждого разработчика специалистом по ИБ, поскольку это разные области деятельности и требуют разного уровня подготовки. Однако, согласно концепции DevOps, администраторам необходимо иметь представление об особенностях функционирования программного продукта, а разработчикам — о «поведении» их кода в реальной среде. Точно так же в соответствии с DevSecOps специалисты по ИБ должны внедрять базовые концепции информационной безопасности на уровнях разработки и администрирования.

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

Разработчики должны все время помнить о задаче обеспечения ИБ и следовать принципам безопасной разработки приложений хотя бы в той мере, чтобы не допускать базовых ошибок. А руководители должны ввести соответствующие KPI. Например, каждую неделю выпускается очередной релиз. Метрикой качества кода с точки зрения безопасности может служить количество повторяющихся уязвимостей в коде, то есть тех, что ранее уже были выявлены и некорректно устранены. Или количество новых уязвимостей и т. д.

Тогда служба ИБ получит рычаги влияния на разработчиков и возможность мотивировать их на выполнение установленных требований.

Другая задача ИБ — защитить среду, в которой приложение работает: контейнеры, системы распределенных вычислений, виртуальные машины, серверы. Ведь чем сложнее приложение, тем больше точек отказа — мест возможного проникновения злоумышленников.

 

LAN: Насколько включение мер безопасности в DevOps замедляет процесс разработки?

Безкоровайный: Процесс разработки замедляет как раз традиционный подход ИБ — например, применение сканеров для анализа кода на завершающем этапе создания приложения.

Конечно же, внедрение методологии DevSecOps, ее притирка и отладка требуют определенных усилий и чреваты задержками на первых порах: необходимо найти и внедрить нужные инструменты, обучить людей. Однако, когда процесс отлажен, разработка будет идти с прежней скоростью и при этом будет безопасной.

Если же пытаться делать по старинке (быстрая разработка, а потом проверка на безопасность), то, помимо замедления сроков релизов продукта, это приведет к постоянному торгу относительно выбора изменений, которые необходимо внести в код для его защиты.

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

В России, насколько мне известно, масштабных инцидентов наподобие кражи у компании Equifax персональных данных о 143 млн американских граждан пока не происходило, но озабоченность состоянием безопасности приложений на высококонкурентных рынках возрастает, и компании готовы вкладывать средства в безопасную разработку.

 

LAN: Внедрение методологии DevSecOps и ей подобных не гарантирует 100-процентной защиты приложений. Все равно необходимо использовать средства и системы защиты. Не проще ли сделать акцент именно на них?

Безкоровайный: Дополнительные средства защиты, конечно же, нужны как средство лечения симптомов. Однако внешняя защита наименее надежна, ведь ни один поставщик соответствующих решений не дает никакой гарантии. Как ни один разработчик антивирусов не несет ответственности в случае вирусной эпидемии, так и ни один производитель средств защиты Web- и мобильных приложений не заявляет о защите на 100%. Это в принципе невозможно.

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

Использование внешних средств безопасности — это некая дополнительная, компенсационная мера. Основная — выявление уязвимостей в коде приложения.

Ведь успешное отражение атаки — это не итог борьбы со злоумышленником, это всего лишь передышка, которую нужно использовать для поиска уязвимостей в коде и их устранения. И это первое, что необходимо сделать, так как средство безопасности может сегодня работать, а завтра окажется неэффективным, например, из-за ошибки в конфигурации, запуска виртуальной машины в другом ЦОДе и т. п.

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

 

LAN: Между тем на рынке начали появляться решения, поставщики которых обещают обеспечить автоматизированную защиту приложений. Насколько на них можно полагаться?

Безкоровайный: Применение алгоритмов машинного обучения в автоматизированных системах защиты, конечно, перспективно, к тому же количество атак и инцидентов постоянно возрастает и проанализировать их все вручную, чтобы обновить сигнатуры, уже невозможно. Однако пока нет никаких гарантий точности работы и полноты этих алгоритмов.

Да, действительно, на рынке Web Application Firewall и систем защиты Web-приложений вместо сигнатурного метода (или в дополнение к нему) набирает популярность применение эвристических методов, с помощью которых система учится понимать, что является нормальным поведением, а что — аномальным. Однако после внедрения таких систем возникает немало проблем: их обучение занимает достаточно много времени, а после обновления программного продукта алгоритмы приходится перестраивать, поскольку изменение логики работы пользователя воспринимается как аномальное поведение. Это приводит к ложным срабатываниям, требует дополнительных усилий по администрированию такой системы и т. д.

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

Беседовал Дмитрий Ганьжа, главный редактор «Журнала сетевых решений/LAN»