Вычислительная сложность

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

В криптографии мы часто оперируем поятием "вычислительной сложности", например, теоретически выглядит несложно найти два множителя p и q модуля n = p*q в схеме RSA, да и факторизация выглядит предельно понятной операцией, теоретически, однако, на практике выполнить факторизацию модуля n вычислительно сложно. То, что теоретически злоумышленник может успешно факторизовать n нас не останавливает от использования схемы RSA, ибо на практике вероятность этого события невелика и мы принимаем этот остаточный риск...

... Современное программное обеспечение не пишется полностью с нуля: любой продукт содержит тысячи сторонних библиотек и, конечно, все они не лишены уязвимостей, и даже критических. Для оценки безопасности мы часто используем формальный подход: вот уязвимая версия компонента, надо этот компонент обновить, поскольку его "небезопасность" ведет к "небезопасности" всей системы. Однако, на практике глубоко лежащий компонент не всегда есть возможность обновить на новую версию (не хочется говорить "никогда нет возможности", но это, скорее, именно так). Более того, если компонентов у нас тысячи, то в любой момент времени мы будем иметь дело с десятками и сотнями уязвимых модулей и библиотек, а их обновление тянет за собой, если и не дополнительную разработку (допустим, есть обратная совместимость..., но все мы знаем печальную историю Microsoft, поэтому в общем случае не стоит на это рассчитывать), то огромный цикл разных видов тестирования, причем, чем глубже закопан обновляемый компонент, тем больше тестирования нам предстоит. Ну и, очевидно, установка смой последней версии не гарантирует отсутствие уязвимостей нулевого дня. Который год мы все наблюдаем рост supply chain атак, нередко как раз через уязвимые компоненты и библиотеках, в общем, проблема имеет место быть на практике.

И что же с этим делать?! Как в случае Threat hunting-а мы смирились с тем, что надо считать сеть уже атакованной, так и в обсуждаемом случае надо смириться с тем, что в нашем ПО гарантировано есть уязвимые компоненты, и вообще, наше ПО гарантировано уязвимо. Не стоит по этому поводу рефлексировать и стремиться добиться обновления всех сторонних компонентов и библиотек, это невозможно. А наши бесконечные усилия по обеспечению использования только последних версий всех сторонних библиотек - неэффективны и безрезультатны. На практике критично не наличие уязвимости, а возможности ее эксплуатации, поэтому наши высокие стремления надо переключить на обеспечение невозможности эксплуатации уязвимостей используемых нами компонент и библиотек. Помним, что мы боремся не с атакой, а с ущербом, поэтому, в целом, даже и эксплуатация может быть допустима, при условии, что атакующему технически сложно развить атаку, атакующему вычислительно сложно реализовать для нас ущерб. Ну а здесь уже работают всем известные старые подходы безопасности - Принцип минимума полномочий, контроль доступа, изоляция и эшелонированность средств обеспечеия ИБ, и компенсирующие контроли, типа непрерывного мониторинга.

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