3 уровня кибербезопасности

Разработчики ПО плохо разбираются в безопасности, потому что им претит сама мысль о том, что оно может нанести вред. Лидерские позиции в нашей индустрии занимают достаточно взрослые люди, которые росли во времена, когда компьютеры были не такими мощными и их использовали скорее для оптимизации рутинного труда, чем по необходимости. Тогда же, благодаря видеоиграм, к цифровым продуктам пришли первые коммерческие успехи. И до сих пор, по инерции, мы не думаем о безопасности ПО как о чём-то важном. Этот подход нужно изменить.

Но что же означает безопасность программного обеспечения? Легко представить надёжный или, напротив, смертельно опасный автомобиль. Так же просто вспомнить опасные или безвредные медицинские инструменты. Но код? Мне нравится думать о безопасности ПО как сущности с тремя уровнями заботы.

Уровень 1

Безопасность как защита

Многие годы единственной «безопасностью», о которой думали разработчики ПО, была «безопасность памяти». Мы придём к такому выводу, если будем считать, что «безопасность» — синоним слова «защита».

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

Этот контроль напрямую связан с распределением вычислительных ресурсов центрального процессора. Соответственно, управление ресурсами и защита памяти порождают проблему очерёдности в обслуживании пользовательских запросов (представьте, что вы заплатили за время, а кто-то другой запустил свой процесс, съевший всю память).

Учёные-информатики предположили, что эти уязвимости могут быть использованы в качестве оружия, и оно действительно почти сразу же и появилось в 1988 году под именем «червь Морриса». Подобные атаки продолжаются по сей день.

Уровень 2

Безопасность как предсказуемость

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

На этом уровне безопасность ПО сводится к предсказуемости (детерминизму). Экосистема, которая выросла вокруг неё, содержит типовые системы и правила проверки. Подобные методы изобретали не для того, чтобы решать проблемы безопасности. Но рост интереса к ним в академических кругах и их появление в инструментарии разработчиков стали прямым следствием того, насколько выросла осведомлённость о потенциальной опасности непредсказуемых систем.

Уровень 3

Безопасность как эргономика

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

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

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

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

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