Как система становится безопасной?

В какой момент времени можно сказать — моя сеть, устройство, приложение — безопасно?

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

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

Известно множество практических подходов, которые говорят, как делать системы более безопасными. К примеру, стандарт ГОСТ Р 56939−2024 (он же стандарт на РБПО — разработку безопасного ПО) описывает требования к процессам жизненного цикла разработки программ с точки зрения безопасности. Существуют и другие рекомендации, как более общие, так и более детализированные. Есть аспекты, о которых имеет смысл подумать до разработки — например, соответствие стандартам или риски цепочки поставок. Есть и требования после разработки, к эксплуатации, например, к смене пароля.

Однако насколько безопасным должно быть устройство или программа, и как это выразить в конкретном наборе технических мер? Сколько таких разнообразных мер требуется, и насколько строгими они должны быть?

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

Модель зрелости безопасности (англ. Security Maturity Model, SMM)^[1] предоставляет пространство выбора мер защиты, применяемых до, во время и после разработки системы. Ядро модели состоит из 18 возможных практик безопасности, структурно разделенных на домены — управление, реализация, укрепление. Например, практика контроля доступа реализуется при разработке системы как часть функционала, а практика обновлений — при эксплуатации, для укрепления безопасности. Каждой практике может быть уделено больше или меньше внимания. Этот аспект называется полнотой реализации (от 1 до 4). Могут предъявляться специальные требования к реализации практики, например, для промышленных устройств обновление производится в технологические окна.

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

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

При формировании профиля, согласно методике SMM, заинтересованные стороны начинают с постановки целей для системы, и идут от общего к частному. Заранее сформированный профиль зрелости безопасности даст основу для реализации требований ИБ оптимальным образом. По сути, такой подход называется конструктивной информационной безопасностью (англ. security by design).

Англоязычный термин «by design» означает, что про безопасность (или какое-то другое свойство системы) начинают думать во время ее создания, и даже до него — еще с этапа замысла. Конструктивная информационная безопасность не является новым видом безопасности и не противопоставляется другим подходам и технологиям, нацеленным на повышение надежности и защищенности систем в цифровом мире. Это набор подходов и принципов, который позволяет точнее и аккуратнее ставить задачи по обеспечению информационной безопасности и решать их наиболее подходящими методами и на подходящих этапах создания и эксплуатации систем.

Этот набор подходов и принципов не просто сочетается с такими современными методами как Shiftleft, DevSecOps, SDLC и SSDLC, РБПО, а интегрирует их, что оказывает положительное влияние на защищенность системы. Сочетается он и с моделью зрелости: последняя помогает сформировать верное представление о целях безопасности с точки зрения бизнеса и облечь это представление в технические термины.

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

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

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

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