Сообщество OWASP уже отличалось широко известным рейтингом Top 10 web уязвимостей и мало известным Top 10 kubernetes уязвимостей.
Почему решили сделать такой рейтинг и для CI/CD? Процессы, системы и окружения CI/CD - это сердце современной софтовой компании. Они доставляют код от разработчика до продакшена. В комбинации с подходами DevOps и микросервисными архитектурами CI/CD системы и процессы меняются и приобретают все большую значимость для бизнес-процессов компании:
современные подходы автоматизации тестирования, использование K8s, непрерывной доставки GitOps приводят к усложнению цепочек доставки ПО (pipeline)
развиваются практики Infrastructure as Code (IaC), Security as Code и даже Everything as Code
интеграция с внешними поставщиками, партнерами и иными третьими лицами также является часть экосистемы CI/CD.
Эти особенности позволяют быстрее, гибче и удобнее выпускать ПО, но они же приводят к росту числа атак на CI/CD. Из недавних инцидентов можно отметить следующие:
В результате компрометации системы сборки ПО SolarWinds произошло внедрение вредоносного кода в инфраструктуры 18,000 крупных заказчиков
Утечка в Codecov привела к раскрытию секретов хранящихся в переменных окружения тысяч pipelin-ов большого количества разработчиков
Инцидент PHP breach произошел в результате внедрения вредоносного кода в версию PHP.
Новые атаки типа Dependency Confusion позволили подменить зависимости используемые крупными разработчиками ПО на вредоносные.
Компрометация NPM пакетов ua-parser-js, coa и rc, с миллионами скачиваний у каждого привели к попаданию вредоносного кода в окружения сборки и на рабочие компьютеры разработчиков.
Сообщество OWASP подготовило Top 10 CI/CD Security Risk чтобы помочь вам закрыть самые популярные недостатки и уязвимости, через которые осуществляется большинство атак.
По каждому риску/угрозе приводится подробная информация:
Definition - определение источника и сути угрозы
Description - детальное описание контекста угрозы и мотивации алакующего
Impact - предположения о возможном вреде, который может быть нанесен организации в результате реализации риска
Recommendations - возможный набор практик и мер безопасности для CI/CD
References - ссылки на подобные уязвимости, утечки и инциденты
В целом документ подробный, полезный и красиво оформлен.
Рекомендую ознакомится всем работникам задействованным в управлении CI/CD, pipeline или обеспечении их безопасности
Давайте будем проводить категорирование объекта КИИ на примере организации сферы здравоохранения. Будем руководствоваться следующими НПА: · Федеральный закон от 26.07.2017 N 187-ФЗ "О безопасности критической информационной инфраструктуры Российской Федерации" · Постановление Правительства РФ от 8 февраля 2018 г. № 127 “Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений” · Приказ ФСТЭК России ОТ 06.12.2017 N 227 "Об утверждении порядка ведения реестра значимых объектов критической информационной инфраструктуры Российской Федерации" · Приказ ФСТЭК России от 22.12.2017 N 236 "Об утверждении формы направления св...
С учетом тенденции по централизации информационных систем, в региональных государственных и муниципальных органах, в региональных гос. учреждениях отсутствуют собственные ГИСы, но есть большое количество клиентских подключений к ГИС. Очевидно, что такие рабочие места необходимо защищать. Но по каким требованиям? То с чем я сталкивался – полный разброд и шатание. Одни защищают такие АРМ как собственную ИСПДн. Другие классифицируют как ГИС причем с уровнем защищенности от К1 до К3. Давайте разберемся какой порядок работы всё-таки правильный и какие сейчас есть сложности с ним. Во-первых, кто может и должен классифицировать клиентские места ГИС? В соответствии с пунктом 14 приказа ФСТЭК №17 классификацию ГИС осуществляет обладатель информации в ГИС ( заказчик ГИС –орган который создает или заказывает ГИС по гос. контракту). Учреждение с клиентским местом не создает ГИС и соответственно не может проводить классификацию. Во-вторых, может быть клиентские места ГИС вообще ...
При планировании мероприятий по обеспечению безопасности значимых объектов критической информационной инфраструктуры важно понимать какие процессы обеспечения безопасности необходимо создать/изменить, а также в каких документах они должны быть определены и описаны. Я провел полный анализ действующих НПА в области КИИ на предмет требований в которых какие-либо документы упоминаются в явном виде, либо имеются требования к мерам необходимость документирования которых очевидна и неоспорима. Для владельцев незначимых объектов КИИ получился примерно следующий перечень Для владельцев значимых объектов КИИ перечень существенно больше В хорошем качестве можно скачать PDF Получилось 18 политик, 8 порядков, 4 приказа, 3 журнала, 2 положения. Но это как минимум. Есть ещё ряд процессов обеспечения ИБ, которые требуется выполнять, но требований по документированию которых не приводится – тут документы могут разрабатываться на усмотрение субъекта КИ...
Комментарии