При росте числа атак игнорировать процесс исследования защищенности программного обеспечения не получается, но и затягивать сроки выпуска новых функций из-за таких исследований тоже не выход.
.png "Рустэм Хайретдинов, руководитель проекта Appercut, заместитель генерального директора ГК InfoWatch")
Все уже смирились с тем, что меры информационной безопасности, оправдываемые заботой о нас с вами, все больше замедляют привычные процессы. Двухфакторная аутентификация вместо еще недавно применяемой пары логин/пароль, капча «докажите, что вы не робот», подтверждение онлайн-оплаты кодом из СМС. Безопасность — это мелкое неудобство в обмен на уменьшение рисков, говорим мы себе, вспоминая, что до массовых терактов предполетный досмотр был гораздо быстрее и не таким строгим: не запрещали проносить в самолет жидкости, не надо было разуваться и снимать ремни и т. п.
Разработчики за долгие годы привыкли к тому, что после написания очередной версии своей программы они должны отдать ее на долгие месяцы в исследовательскую лабораторию, чтобы после многочисленных тестов получить заключение о безопасности созданного ПО. Если же это программное обеспечение будет обрабатывать различные виды охраняемых законом данных (к примеру, персональных данных), то понадобится специальная лаборатория, которая даст заключение о соответствии нового продукта требованиям к функциональности и об отсутствии в исполняемом коде недекларированных возможностей — на основании этого документа еще через месяц выдается сертификат. Если вы добавили в программное обеспечение некоторое исправление, выпустили обновление или заплату, то придется пройти процедуру повторной сертификации, хотя и ускоренную — «всего» за месяц. До последнего времени такой подход устраивал разработчиков, ведь и аудит на защищенность, и даже сертификация не были насущно необходимы бизнесу, они относились скорее к некоторым формальным требованиям регуляторов.
Однако современные корпоративные продукты, особенно предназначенные для обслуживания потребителей, разрабатываются не за полгода и даже не за месяц, а гораздо быстрее. Стандартный «спринт» — единица создания продукта по методу гибкой разработки (agile) — длится две недели. Иначе говоря, отдав программное обеспечение на исследование в специализированную лабораторию на пару месяцев, мы получим заключение о безопасности поза-поза-поза-поза прошлой версии. В сочетании с возросшей активностью хакеров (дня не проходит, чтобы СМИ не сообщили о крупном взломе и многомиллионных потерях) такой подход постепенно перестает устраивать бизнес. При росте числа атак игнорировать процесс исследования защищенности не получается, но и затягивать сроки выпуска новых функций из-за таких исследований тоже не выход.
С одной стороны, бизнес стремится быстрее реагировать на происходящие изменения, поскольку на современном рынке выживают те, кто предложил потребителю новую услугу первым и смог обслужить его дешевле других, а значит — автоматизированно. С другой стороны, обеспечение безопасности корпоративных приложений пока осталось на уровне прошлого века — все методы исследования приложений на защищенность рассчитаны на многомесячный цикл разработки, когда функциональные изменения происходят раз в полгода или даже год. К тому же процесс этот итерационный: приложение исследуется, выдаются замечания, происходит торг («эти уязвимости исправляем, а эти оставляем, поскольку нет времени»), по итогам которого часть уязвимостей устраняется. Затем проводится новое исследование — и так до тех пор, пока приемщики программного обеспечения не придфут к компромиссу между срочностью задач и рисками. Сроки завершения всего проекта определяются именно этим этапом, поэтому если новая функциональность и разрабатывается за две недели, то для обработки реальных конфиденциальных данных она будет доступна лишь через несколько месяцев.
Пока исследователи взаимодействуют с разработчиками в парадигме «вы сначала сделайте, а мы потом начнем исследовать, предъявим найденные изъяны, подождем, когда исправите, и будем исследовать снова», никакого agile — ни в разработке новой функциональности приложений, ни в появлении новых бизнес-процессов — ждать не приходится. Пока с этой проблемой сталкиваются только большие компании, прежде всего банки и лидеры электронной коммерции, где конкуренция за пользователей уже чрезвычайно высока, но рано или поздно она коснется всех тех, кто разрабатывает программное обеспечение для обслуживания клиентов самостоятельно или с помощью контрактных исполнителей.
Что придет на смену исправно работающей десятилетиями процедуре исследования приложений на защищенность, пока неочевидно. Это могут быть и хорошо известные, но до сих пор очень формализованные и дорогие процедуры безо-пасной разработки (Security Development Life Cycle, SDLC), не исключено появление и новых подходов. Некоторые компании уже сейчас экспериментируют с включением исследователей безопасности в небольшие команды разработчиков — это позволяет находить и исправлять уязвимости на раннем этапе, когда их относительно просто и дешево исправить. Безусловно, свое слово должны сказать и системы автоматизации исследования защищенности — рутинные операции наверняка будут выполняться роботами, элементы такой автоматизации уже работают почти так же точно, как человек, значительно опережая его в производительности. И пока не сказал своего слова искусственный интеллект — первые внедрения элементов самозащищающихся систем уже работают в продуктиве.
Осталось изобрести самосертифицирующиеся системы…