Всем привет!
Частенько бывает так, что понятные и очевидные профессионалам истины достаточно сложно объяснить не специалистам. Но я попробую.
Вот, например, надо построить дом. И не просто какой-то типовой стандартный, а по собственным хотелкам. Для этого приглашается архитектор, который вместе с заказчиком рисует эскизы и чертежи, потом всё это просчитывается и согласовывается, появляется проектная документация, подрядчик на проведение работ, техническая инспекция следит за качеством, параллельно дизайнеры рисуют внутренние интерьеры – обычные процессы при строительстве любого объекта сложности выше чем «рай в шалаше». Многие работы уникальны, и они производятся конкретно под требования заказчика, но само строительство идёт из стандартных материалов и изделий: кирпичей, арматуры, бетона.
Так и в разработке программных продуктов.
Большое количество работ уникальны, требуют архитекторов, дизайнеров, технической документации, инженеров-программистов, часто специфических знаний и умений. Но в процессе разработки любого софта используется также огромное количество стандартных кирпичей-библиотек, выполняющих различные «повседневные» функции. Как при строительстве из типовых кирпичей можно сложить стену, забор или трубу – так и в программных продуктах модули с совершенно различным функционалом (потребительскими качествами) используют множество унифицированных библиотечных функций-кирпичей.
Так вроде должно быть понятно всем. Но при чём здесь кибербезопасность?
А вот при чём: цифровые зловреды под стать строительным дефектам. Если нанести повреждения на готовый к заселению дом – это полбеды. Поправить, отштукатурить, покрасить и плитку переложить. А вот если проблема глубоко внутри конструкции? – ага, а вот это дорого больненько. Тоже самое и с софтом. Если к нему сверху прилипнет какая-то зараза, то можно полечить-подчистить-восстановить – и все дела. Но если цифровая дрянь проникнет в библиотеки и модули, из которых собирается конечный продукт? – ай, это ой. Обнаружить такого зловреда может оказаться весьма и весьма непросто, а тем более его выковырять из рабочего бизнес-процесса.
И примеры тому есть, да и немало.
Даже в глубокой древности, во времена Виндовз-98 был похожий инцидент, когда вирус CIH пробрался в дистрибутивы компьютерных игрушек нескольких производителей – и оттуда разлетелся по всему миру. Другая подобная засада произошла годами позже, когда в где-то в 2000х появилась кибер-зараза, проникавшая в библиотеки среды программирования Delphi.
Таким образом получается, что угрозу для личных устройств и корпоративных сетей могут представлять не только «залётные» кибер-негодяи, но и те злодеи, которые случайно или намеренно умудрились пролезть в «закрома» производителя программных продуктов, которым вы пользуетесь, и внедриться в «программные запчасти», из которых потом собирается готовый продукт. Вот так бывает.
«Ах вон оно что, Михалыч!» (с).
Чтобы стало ещё понятнее, давайте спроецируем тот же сценарий на всем нам знакомый поход в обычный продуктовый магазин. Да не просто так сходить, а во времена глобального пандемического шухера, когда от злобного биологического вируса потряхивает вообще всю нашу планету.
Так вот, выглядеть это событие будет примерно вот так. Взяли сумки, руки помыли, маску с перчатками надели, однако на этом ваши меры предосторожности заканчиваются. Далее начинается ответственность продавца и производителя, каждый из которых тоже должен следовать санитарным нормам. А ведь есть ещё и грузчики, упаковщики, кладовщики, системы хранения и транспортировки продукции и так далее! – и на каждом сегменте этой цепочки кто-то может случайно (или намеренно) чихнуть на вашу условную картошку!
Тоже самое и в нашем цифровом мире.
Цепочка поставок в современных гибридных экосистемах ИТ-разработки сложнее на пару порядков, а новых кибер-зловредов мы ловим более 300 тысяч КАЖДЫЙ ДЕНЬ! – причём их сложность постепенно возрастает. Проконтролировать то, насколько «чисто помыты руки и маска с перчатками» у разработчиков каждого отдельного софтверного компонента, и насколько эффективны системы киберзащиты многочисленных поставщиков облачных услуг в каждый конкретный момент – задача невероятно сложная. Особенно если используемый продукт опенсорсный, а сборка приложения – по-модному автоматизирована и работает совсем неразборчиво, на полном доверии, «на лету».
Тут стоить помнить, что атаки на цепочки поставок – это самый что ни на есть тренд продвинутого киберзлодейства! Например, группировка ShadowPad атаковала финансовые организации через решение популярного поставщика ПО для управления серверной инфраструктурой. Другие хитрецы атакуют библиотеки открытого кода, и коллеги из индустрии напоминают, что у разработчиков «крайне мало возможностей удостовериться, что устанавливаемые ими компоненты из различных библиотек не содержат зловредного кода».
Ещё пример – атака на библиотеки контейнеров, таких как Docker Hub. С одной стороны, использование контейнеров позволяет повысить удобство и скорость развертывания приложений и сервисов. С другой, некоторые разработчики ленятся создавать собственные контейнеры и скачивают их готовые образы – а там, сюрприз-сюрприз, как в шляпе волшебника может скрываться что угодно. Кролик, например. Вот такой:
В итоге, разработчики хотят выдать «на гора» работающий продукт как можно скорее, специалисты по автоматизации разработки (devops) ратуют за использование доступных компонентов и облачных платформ на всех этапах, безопасники пьют валерьянку (ну или чего покрепче), а пользователи продукта рискуют получить не одного троянского коня, а целый табун!
Но мы же не зря здесь существуем! :) Если есть сложные задачки – мы любим их решать… и не только математические :)
И – бьют барабаны, трубят трубы, свистят свистелки и сопят сопелки, оркестр играет туш, а восторженная публика в воздух чепчики кидает и аплодирует пока те в воздухе! – мы расширяем возможности нашего продукта Kaspersky Hybrid Cloud Security.
Дальше: все довольны!…
