Secure by design

Алексей описывает привычный цикл: продукт разрабатывают в отрыве от безопасности, перед публикацией появляются безопасники, и начинается «исправить, доработать, переделать». Екатерина Рудина, которая в «Лаборатории Касперского» занимается аналитикой безопасности промышленных систем и интернета вещей и работает с национальными и международными комитетами по стандартизации, называет это стратегией тушения пожаров: здесь критическая уязвимость, там архитектурный недостаток, и каждая находка наращивает общую проблему, пока не скажешь «стоп». Её альтернатива — аналогия с «Тремя поросятами»: дом из соломы развалился, дом из веточек развалился, дом из кирпичей, как ни странно, тоже развалился, и только на третий раз возникает вопрос, нельзя ли сразу строить так, чтобы здание стояло само, не шаталось, не продувалось всеми ветрами и держалось, даже если его приходят разрушать. Тот же подход, применённый к коду и системе в широком смысле слова, и называется Security by Design.

Сергей Рогачёв, который делает защищённую платформу KasperskyOS, а в безопасность пришёл из разработки операционных систем и виртуализации, уточняет: в определениях это не конкретная методология, а общий майндсет, из которого вырастают разные практики. Думать о безопасности в конце пути поздно — дизайн уже не поменять, а правки в архитектуре тяжело имплементировать, поэтому работу смещают как можно раньше, вплоть до стадии концепции продукта, ещё до функциональных требований; это и есть Shift Left. Спектр подходов широк: формальный SDL от Microsoft, собственная методология внутри «Лаборатории Касперского», менее формальные эвристики, паттерны проектирования, базовые принципы. Александр добавляет рамку из своего опыта: сначала объединили Dev и operations, потом к аббревиатуре добавляли буквы — Sec, Data. Смысл один: качество, надёжность, безопасность и работу с данными не добавляют постфактум, их проектируют. Просто безопасность дальше от разработчика, чем, например, тестирование.

Зачем этим заниматься, объясняет Сергей — по его признанию, непривычно для себя, не с технической стороны: бизнес всё чаще намекает, что дело упирается в деньги. Отложенная безопасность — это не только злые безопасники, которые развернут и заставят переделывать. Продукт может оказаться не готов доставлять клиентам ценность: система должна обеспечивать какое-то свойство из триады конфиденциальности, целостности и доступности, а она его не обеспечивает. Дальше идут патч-менеджмент, переделка архитектуры и новые итерации переработки — уже на стадии поддержки, куда вкладывают людей, деньги и машинные ресурсы. Классический SDL действительно удлиняет путь от задумки до выпуска, зато поддержка выходит дешевле. Александр переводит это в совокупную стоимость владения: написать код — одно, а годами поддерживать, развивать и патчить — другое, и нет ничего более постоянного, чем временное. Бизнесу он предлагает говорить прямо: фичи будут дороже, зато потом не придётся чинить всё в разгар инцидента или утечки.

Екатерина предпочитает русский термин «конструктивная безопасность» и сводит разговор к целеполаганию: что мы вообще считаем безопасностью для конкретного продукта. Лет сорок-пятьдесят назад было просто — конфиденциальность, целостность, доступность, и всё это про информацию. Сегодня добавились готовность систем, способность электростанции выдать нужное количество энергии за срок и не меньше, скорость реакции на события, надёжность, которая всегда считалась отдельным понятием, и приватность, которая может конфликтовать с общественной безопасностью. Рецепт для любого проекта дешёвый: сесть и за полчаса выписать три, пять, семь пунктов о том, что для вашего приложения безопасное поведение, а что нет. Александр объясняет, почему целеполагание забывают: пока инцидента не случилось, в него трудно поверить, а измерить безопасность заранее так же непонятно, как надёжность. Сергей добавляет аббревиатуру ЦПБ — цели и предположения безопасности: устройство на лестничной клетке и устройство на охраняемой территории завода защищают от разных классов угроз, и это законный повод где-то срезать углы.

Нужен ли Secure by Design стартапу, которому ещё нечего есть? Екатерина отвечает через масштабируемость: на волне импортозамещения отечественный стартап делает не прошивку под конкретное железо, а платформу для программируемых логических контроллеров, а платформу нужно уметь гибко кастомизировать. Дальше идёт реальный пример, название которого она сознательно не произносит: фреймворк промышленной автоматизации запускается под Linux от рута, а плагины с кастомным кодом подгружаются прямо в адресное пространство этого процесса. Любая уязвимость плагина стороннего разработчика компрометирует всю платформу, каждая ошибка получает высокий рейтинг CVSS, а совет «прогоните статический анализатор» ситуацию не меняет; фреймворк давно разошёлся по миру, и фарш назад не провернуть. Александр отвечает через риск-модель: недельный проект с партнёрами, без персональных данных и с промокодами, — это одно, а движок, через который идут клиентские операции и платежи, — другое. Углы можно срезать на прототипе, но, подтвердив гипотезу, решение переделывают и не пускают времянку в прод.

Что делать, если продукт уже сделан небезопасно и атаки участились? Сначала тушить пожары, отвечает Екатерина. Сергей добавляет, что дальше нужен итеративный подход: провести анализ, найти недоверенные куски, которые работают с пользовательским вводом, и вынести их в контейнеры или компартменты, максимально ограниченные по привилегиям, с единственным известным каналом связи наружу. Примерно так устроен Google Chrome, где части, работающие с кодом страницы и скриптами, депривилегированы, и падение такого компартмента бьёт только по доступности. Где всему этому учиться, участники расходятся мягко: Екатерина ставит на базовое инженерное образование и опыт смежных отраслей вроде функциональной безопасности в автомобилестроении, Александр — на книги, в том числе на книгу Google про безопасные и надёжные системы с её разбором инцидент-менеджмента глазами безопасности. Прозвучало и такое мнение: Secure by Design по книжкам не выучить, серьёзных курсов один из участников не видел — качать надо архитектуру ПО и общее понимание информационной безопасности, к которому хорошо ведёт фундаментальный труд Бишопа.