Devsecops что это такое

∞ Как и зачем изучать методики DevSecOps в 2021 году?

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

Типичный рабочий процесс DevOps и DevSecOps выглядит так:

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

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

Знания и навыки, необходимые специалисту DevSecOps

Краткий список необходимых навыков:

Краткий список необходимых знаний:

Квалификация, необходимая для начала работы инженером DevSecOps

Чтобы получить работу инженера DevSecOps, вам понадобятся четыре составляющие: образование, сертификация, опыт, обучение на курсах.

Образование

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

Сертификация

Пройти сертификацию вы можете на следующих платформах:

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

Инструменты, которые применяются для реализации подхода DevSecOps

Чтобы успешно работать с командами DevOps, инженеру DevSecOps необходимо досконально разбираться в популярных языках программирования.

Инженер DevSecOps может также использовать следующие инструменты:

Для инженеров DevSecOps важно дополнительное знакомство с популярными инструментами CI/CD:

Обязанности и карьерные перспективы специалиста DevSecOps

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

Отвечая за циклы разработки в режиме интеграции и непрерывного развертывания, инженеры DevSecOps могут выполнять следующие обязанности:

Если вы мечтаете стать инженером DevSecOps, начать карьерный путь стоит с позиции специалиста по информационной безопасности, а затем углубиться в изучение методологии DevOps.

Полезные ресурсы для самообучения

Книги

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

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

Книга «Безопасный DevOps» исследует, как методы DevOps и безопасности должны применяться вместе. В ней рассматриваются новейшие практики, используемые для защиты веб-приложений и их инфраструктуры, а также методы интеграции безопасности в программные продукты. Вы узнаете об основных концепциях DevOps, таких как непрерывная интеграция (CI), непрерывная доставка (CD) и инфраструктура как услуга (IaaS).

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

Видео

Доклад Chief Security Architect Юрия Шабалина на конференции DevOpsConf, который посвящен проблемам перехода от классической модели Application Security к процессу DevSecOps.

Юрий рассказал, как правильно подойти к встраиванию процесса безопасной разработки в процесс DevOps и как при этом ничего не сломать. Эксперт разъяснил основные этапы тестирования на безопасность, какие инструменты можно применять, чем они отличаются и как их правильно настроить. Кроме того, он раскрыл подводные камни, которые встречаются в любом процессе, и рассказал, как их избежать или хотя бы подготовиться к столкновению.

Эксперты компании «Инфосистемы Джет» Антон Гаврилов и Александр Краснов на вебинаре рассказали о том, какие технологии используются в DevSecOps, зачем они нужны и как правильно их встроить в автоматизированный конвейер разработки.

Подробно обсуждались следующие темы:

Интервью с Products Director компании Positive Technologies Денисом Кораблевым на YouTube-канале АйТиБорода.

Эксперт рассказал, как принципы кибербезопасности внедряются в процесс разработки, предотвращают атаки хакеров и помогают программистам делать действительно качественный код. Также он поделился собственным опытом использования концепций DevSecOps: SSDL, SCA, NVD, DAST, SAST, RASP.

Инженер DevSecOps и облачный архитектор с более чем тридцатилетним опытом работы в сфере ИТ и кибербезопасности поделился своими знаниями:

За год обучения вы освоите современные технологии, а опытные преподаватели ответят на все возникшие по темам вебинаров вопросы, а также дадут обратную связь. После прохождения курса вы получите электронный сертификат и сможете работать по специальностям: Application Security Engineer, пентестер, специалист по информационной безопасности, специалист по анализу защищенности. Любую из этих профессий можно рассматривать как первую ступеньку на пути к DevSecOps.

Источник

Какая разница между DevOps и DevSecOps?

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

Методология DevOps

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

Методология DevOps включает в себя:

Что из себя представляет DevOps engineer

Так как профессия появилась совсем недавно, в конце 00-х годов, какого-то точного определения для этой профессии не устоялось. Можно его сформулировать так: DevOps-engineer – это человек, который занимается внедрением методологии DevOps.

Есть несколько вещей, с которыми должен быть знаком DevOps-engineer:

Далее обсудим тот вопрос, с которого мы начали эту заметку.

DevSecOps: что это и в чем отличие от DevOps

В основе подхода DevOps плотно закрепилась автоматизация. DevSecOps тоже стремится автоматизировать все, в том числе и аудит безопасности.

Для того, чтобы стимулировать внедрение DevSecOps, компания Cloud Security Alliance выделила шесть категорий, на которые следует обратить внимание.

Практические шаги трансформации DevOps в DevSecOps

Трансформация DevOps в DevSecOps требует понимания определенных технологий и методов обеспечения безопасности программ. Остановимся на этом моменте подробнее и посмотрим, какие конкретно технологии нам тут пригодятся.

Для начала предлагаю рассмотреть возможность встраивания средств динамического тестирования безопасности приложений, DAST. Динамические анализаторы программного кода позволяют выявлять уязвимости в коде, например, SQL-инъекции, переполнение буфера и подобные, методом черного ящика. Использование динамических анализаторов при разработке позволит сделать шаг навстречу DevSecOps практикам.

RASP, самозащита приложений Runtime – одно из средств защиты, которое используется при выполнении программы. RASP анализирует поведение приложения и таким образом проводится непрерывный анализ безопасности.

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

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

Заключение

Подытожим, что же у нас в итоге получилось.

DevSecOps – это способ интегрировать задачи безопасности в методологию DevOps. Вопросы автоматизации безопасности в DevOps – это та вещь, которая требует новых подходов, технологий и инструментов. DevSecOps можно считать продолжением методологии DevOps, так как DevSecOps основан на методологии последних. Чтобы ознакомиться подробнее, предлагаю следующие ссылки:

Источник

DevSecOps

Что такое DevSecOps?

DevSecOps — сокращенно от development, security и operations — автоматизирует интеграцию задач безопасности на всех этапах жизненного цикла разработки программного обеспечения, от проектирования до интеграции, тестирования, развертывания и доставки ПО.

DevSecOps — закономерный и необходимый виток в развитии подходов к обеспечению безопасности в ходе разработки ПО. Ранее задачи безопасности «достраивались» в конце жизненного цикла разработки ПО как нечто второстепенное, при этом за обеспечение и тестирование (QA) безопасности отвечали отдельные команды специалистов.

Ситуация оставалась под контролем, пока обновления ПО выходили не чаще, чем пару раз в год. С появлением методик Agile и DevOps, направленных на сокращение длительности циклов разработки ПО до нескольких недель или даже дней, традиционная стратегия «достраивания» безопасности стала неприемлемой.

DevSecOps интегрирует задачи по обеспечению безопасности приложений и инфраструктуры в процессы и инструменты Agile и DevOps. DevSecOps позволяет решать проблемы безопасности по мере их появления, когда это можно сделать с меньшими затратами времени и средств (до развертывания функций в рабочей среде). Кроме того, DevSecOps позволяет разделить ответственность за безопасность приложений и инфраструктуры между специалистами по разработке, безопасности и эксплуатации ИТ-систем. Это позволяет реализовать девиз DevSecOps — «Разработка ПО. Безопаснее. Быстрее» — путем автоматизации доставки безопасного ПО, не замедляя цикл разработки.

Преимущества DevSecOps

Основными преимуществами DevSecOps являются скорость и безопасность. Скорость разработки, безопасность и качество кода растут, а затраты снижаются.

«Цель и смысл внедрения DevSecOps — сформировать такой образ мышления, при котором каждый участник несет ответственность за безопасность. Это обеспечивает быструю и масштабируемую передачу решений по безопасности тем, кто лучше всего владеет контекстом, без ущерба для безопасности», — считает Шэннон Лиц, соавтор «Манифеста DevSecOps».

Быстрая, экономичная доставка программного обеспечения

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

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

Улучшенные, упреждающие меры безопасности

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

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

Ускоренное исправление уязвимостей безопасности

Главное преимущество DevSecOps — скорость исправления обнаруженных уязвимостей безопасности. Поскольку DevSecOps интегрирует задачи сканирования и исправления уязвимостей в жизненный цикл выпуска, необходимость обнаруживать и исправлять общеизвестные уязвимости (CVE) вручную исчезает. Это ограничивает возможности злоумышленников по использованию уязвимостей в общедоступных производственных системах.

Автоматизация, совместимая с современными подходами к разработке

Если в организации применяется конвейер непрерывной интеграции/непрерывной доставки программного обеспечения, тестирование кибербезопасности можно интегрировать в наборы автоматических тестов.

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

Повторяющийся, адаптивный процесс

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

Рекомендации по DevSecOps

DevSecOps должен стать закономерным этапом интеграции средств обеспечения безопасности в процессы разработки, доставки и эксплуатации.

Сдвиг влево

DevSecOps реализует принцип «сдвиг влево» (Shift left): это помогает программистам переместить задачи безопасности с правой части (т. е. с конца) цикла доставки DevOps в его левую часть (т. е. в начало). В среде DevSecOps безопасность с самого начала является неотъемлемой частью процесса разработки. В организациях, следующих принципам DevSecOps, инженеры и архитекторы кибербезопасности входят в состав команды разработчиков. Их задача — убедиться в том, что каждый компонент и элемент конфигурации в стеке исправлен, настроен согласно требованиям безопасности и задокументирован.

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

Обучение в сфере безопасности

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

Все участники жизненного цикла доставки должны быть знакомы с базовыми принципами защиты приложений, списком из 10 самых опасных уязвимостей OWASP (Open Web Application Security Project), методами тестирования безопасности приложений и другими подходами к проектированию. Разработчики должны хорошо понимать модели угроз, проверки на соответствие нормативным требованиям и обладать практическими навыками оценки рисков, угроз и реализации средств контроля безопасности.

Культура: взаимодействие, люди, процессы и технологии

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

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

Отслеживаемость, контролируемость и прозрачность

Отслеживаемость, контролируемость и прозрачность в рамках стратегии DevSecOps обеспечивают углубленный анализ и повышают безопасность среды:

DevSecOps и IBM

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

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

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

Кроме того, IBM предоставляет набор оптимизированных для DevSecOps инструментов и услуг, поддерживающих конвейеры безопасной непрерывной доставки, интегрированного тестирования безопасности и облачной доставки.

Сделайте следующий шаг:

Начните работу с учетной записью IBM Cloud уже сегодня.

Источник

Страх и ненависть DevSecOps

У нас было 2 анализатора кода, 4 инструмента для динамического тестирования, свои поделки и 250 скриптов. Не то, чтобы это всё было нужно в текущем процессе, но раз начал внедрять DevSecOps, то надо иди до конца.

Источник. Авторы персонажей: Джастин Ройланд и Дэн Хармон.

Что такое SecDevOps? А DevSecOps? В чем отличия? Application Security — о чём это? Почему классический подход больше не работает? На все эти вопросы знает ответ Юрий Шабалин из Swordfish Security. Юрий подробно на всё ответит и разберет проблемы перехода от классической модели Application Security к процессу DevSecOps: как правильно подойти к встраиванию процесса безопасной разработки в процесс DevOps и ничего не сломать при этом, как пройти основные этапы тестирования на безопасность, какие инструменты можно применять, чем они отличаются и как их правильно настроить, чтобы избежать подводных камней.

О спикере: Юрий Шабалин — Chief Security Architect в компании Swordfish Security. Отвечает за внедрение SSDL, за общую интеграцию инструментов анализа приложений в единую экосистему разработки и тестирования. 7 лет опыта в информационной безопасности. Работал в Альфа-Банк, Сбербанк и в Positive Technologies, которая разрабатывает софт и предоставляет сервисы. Спикер международных конференций ZerONights, PHDays, RISSPA, OWASP.

Application Security: о чём это?

Application Security — это раздел безопасности, который отвечает за безопасность приложений. Это не относится к инфраструктуре или к сетевой безопасности, а именно к тому, что мы пишем и над чем работают разработчики — это недостатки и уязвимости самого приложения.

Направление SDL или SDLC — Security development lifecycle — разработала компания Microsoft. На схеме — каноническая модель SDLC, основная задача которой — участие безопасности на каждом этапе разработки, от требований, до релиза и выхода в продакшн. В Microsoft поняли, что в проме слишком много багов, их становится больше и с этим надо что-то делать, и предложили этот подход, который стал каноническим.

Application Security и SSDL направлены не на обнаружение уязвимостей, как принято считать, а на предотвращение их появления. Со временем канонический подход от Microsoft был улучшен, развит, в нем появилось более глубокое детальное погружение.

Канонический SDLC сильно детализирован в различных методологиях — OpenSAMM, BSIMM, OWASP. Методологии отличаются, но, в целом, похожи.

Building Security In Maturity Model

Мне больше всего по душе BSIMM — Building Security In Maturity Model. Основа методологии — разделение процесса Application Security на 4 домена: Governance, Intelligence, SSDL Touchpoints и Deployment. В каждом домене 12 практик, которые представлены в виде 112 активностей.

У каждой из 112 активностей есть 3 уровня зрелости: начальный, средний и продвинутый. Все 12 практик можно изучать по разделам, отбирать важные для вас вещи, разбираться, как их внедрять и постепенно добавлять элементы, например, статический и динамический анализ кода или code review. Расписываете план и по нему спокойно работаете в рамках внедрения выбранных активностей.

Почему DevSecOps

DevOps — это общий большой процесс, в котором нужно заботиться о безопасности.

Изначально DevOps предполагал проверки на безопасность. На практике, численность команд безопасности была намного меньше, чем сейчас, и они выступали не как участники процесса, а как контрольный и надзорный орган, который предъявляет к нему требования и проверяет качество продукта в конце релиза. Это классический подход, в котором команды безопасности находились за стеной от разработки и не принимали участия в процессе.

Основная проблема как раз в том, что ИБ стоят отдельно от разработки. Обычно это некий контур ИБ и в нём 2-3 больших и дорогих инструмента. Раз в полгода прилетает исходный код или приложение, которое нужно проверить, а раз в год производятся пентесты. Это все приводит к тому, что сроки выхода в пром откладываются, а на разработчика вываливается огромное количество уязвимостей из автоматизированных средств. Всё это невозможно разобрать и починить, потому что еще за предыдущие полгода не разобрали результаты, а тут новая партия.

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

Переход к DevSecOps

Самое важное слово в Security Development Lifecycle — это «процесс». Вы должны это понять, прежде чем думать о покупке инструментов.

Просто включить инструменты в процесс DevOps недостаточно — важно взаимодействие и понимание между участниками процесса.

Важнее люди, а не инструменты

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

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

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

Начните с того, что уже используется

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

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

— Сейчас, где-то в заметках был путь, где лежит этот документ.

В итоге мы получили документ спустя неделю.

Для требований, проверок и прочего, создайте страницу, например, на Confluence — это удобно всем.

Проще переформатировать то, что уже есть и использовать для старта.

Используйте Security Champions

Обычно, в средней компании на 100-200 разработчиков трудится один безопасник, который выполняет несколько функций, и физически не успевает все проверять. Даже если он старается изо всех сил — в одиночку не проверит весь код, который генерирует разработка. Для таких случаев разработан концепт — Security Champions.

Security Champions — это человек внутри команды разработки, который заинтересован в безопасности вашего продукта.

Security Champion — точка входа в команду разработки и евангелист безопасности в одном лице.

Обычно, когда в команду разработки приходит безопасник и указывает на ошибку в коде, то получает удивленный ответ:

— А вы кто? Я вас вижу в первый раз. У меня все хорошо — мне старший товарищ на code review поставил «apply», мы идем дальше!

Это типичная ситуация, потому что к старшим или просто коллегам по команде, с которыми разработчик постоянно взаимодействует по работе и в code review, доверия намного больше. Если вместо безопасника на ошибку и последствия укажет Security Champion, то его слово будет иметь больше веса.

Также разработчики лучше знают свой код, чем любой безопасник. Для человека, у которого минимум 5 проектов в инструменте статического анализа, обычно сложно помнить все нюансы. Security Champions знают свой продукт: что с чем взаимодействует и на что смотреть в первую очередь — они эффективнее.

Так что задумайтесь над тем, чтобы внедрить Security Champions и расширить влияние команды безопасности. Для самого чемпиона это также полезно: профессиональное развитие в новой области, расширение технического кругозора, прокачка технических, управленческих и лидерских навыков, повышение рыночной стоимости. Это некоторый элемент социальной инженерии, ваши «глаза» в команде разработки.

Этапы тестирования

Парадигма 20 на 80 гласит, что 20% усилий дают 80% результата. Эти 20% — это практики анализа приложений, которые можно и нужно автоматизировать. Примеры таких активностей — это статический анализ — SAST, динамический анализ — DAST, и контроль Open Source. Расскажу подробнее про активности, а также про инструменты, с какими особенностями мы обычно сталкиваемся при их внедрении в процесс, и как это делать правильно.

Основные проблемы инструментов

Выделю актуальные для всех инструментов проблемы, которые требуют внимания. Разберу их подробнее, чтобы не повторяться дальше.

Долгое время анализа. Если от коммита до выхода на прод уходит 30 минут на все тесты и сборку, то проверки на информационную безопасность займут сутки. Так тормозить процесс никто не будет. Учитывайте эту особенность и делайте выводы.

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

Нет интеграций с существующими инструментами. Смотрите на инструменты с точки зрения интеграций, с тем, что вы уже используете. Например, если у вас Jenkins или TeamCity — проверьте интеграцию инструментов именно с этим ПО, а не с GitLab CI, который вы не используете.

Отсутствие или чрезмерная сложность кастомизации. Если у инструмента нет API, то зачем он нужен? Всё, что можно сделать в интерфейсе должно быть доступно через API. В идеале, у инструмента должна быть возможность кастомизации проверок.

Нет Roadmap развития продукта. Разработка не стоит на месте, мы всегда используем новые фреймворки и функции, переписываем старый код на новые языки. Мы хотим быть уверенными, что инструмент, который мы купим, будет поддерживать новые фреймворки и технологии. Поэтому важно знать, что у продукта есть реальный и правильный Roadmap развития.

Особенности процесса

Кроме особенностей инструментов учитывайте и особенности процесса разработки. Например, мешать разработке — это типичная ошибка. Давайте посмотрим какие ещё особенности следует учитывать и на что обратить внимание команде безопасности.

Чтобы не срывать сроки разработки и релиза, создайте разные правила и разные show stoppers — критерии остановки процесса сборки при наличии уязвимостей — для разных сред. К примеру, мы понимаем, что текущая ветка идет на девелоперский стенд или UAT, значит мы не останавливаем и не говорим:

— У вас здесь уязвимости, вы никуда дальше не пойдете!

На этом этапе важно сказать разработчикам, что есть проблемы безопасности, на которые стоит обратить внимание.

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

— Ребята, у вас есть проблемы, пожалуйста, обратите на них внимание.

На этапе UAT опять показываем предупреждения о уязвимостях, а на этапе выхода в пром говорим:

— Ребята, мы несколько раз предупреждали, вы ничего не сделали — с этим не вас не выпустим.

Если говорить про код и динамику, то необходимо показывать и предупреждать об уязвимостях только тех фич и кода, который был написан только что в этой фиче. Если разработчик передвинул кнопочку на 3 пикселя и мы ему говорим, что у него там SQL-инъекция и поэтому нужно срочно поправить — это неправильно. Смотрите только на то, что написано сейчас, и на то изменение, которое приходит в приложение.

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

Не все проблемы качества ПО — это проблемы безопасности. Но все проблемы безопасности связаны с качеством ПО. Sherif Mansour, Expedia.

Поскольку все уязвимости — это такие же дефекты, они должны находится там же, где и все дефекты разработки. Поэтому забудьте об отчетах и страшных PDF, которые никто не читает.

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

Что делать? Подтвержденные дефекты, которые нашли, просто преобразуем в удобный для разработки вид, например, складываем в backlog в Jira. Дефекты приоритезируем и устраняем в порядке приоритета наравне с функциональными дефектами и дефектами тестов.

Статический анализ — SAST

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

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

Минусы — это отсутствие поддержки необходимых языков.

Необходимые интеграции, которые должны быть в инструментах, по моему субъективному мнению:

Важны не инструменты, а процесс, поэтому существуют Open Source решения, которые также хороши для обкатки процесса.

SAST Open Source не найдут огромное количество уязвимостей или сложные DataFlow, но при построении процесса их можно и нужно использовать. Они помогают понять, как будет построен процесс, кто будет отвечать на баги, кто репортить, кто — отчитываться. Если вы хотите провести начальный этап построения безопасности вашего кода — используйте Open Source решения.

Как это можно интегрировать, если вы в начале пути, у вас нет ничего: ни CI, ни Jenkins, ни TeamCity? Рассмотрим интеграции в процесс.

Интеграция на уровне CVS

Если у вас есть Bitbucket или GitLab, можно сделать интеграцию на уровне Concurrent Versions System.

По событию — pull request, commit. Вы сканируете код и в статусе build’а показываете, что проверка на безопасность прошла или не прошла.

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

Интеграция с системой code review

Однажды, мы ставили в ряде важных проектов дефолтным ревьюером технического пользователя AppSec. В зависимости от того, выявлены ли ошибки в новом коде или ошибок нет, на pull request ревьюер проставляет статус на «accept» или «need work» — либо все ОК, либо нужно доработать и ссылки на то, что именно доработать. На интеграцию с версией, которая идет в прод, у нас был включен запрет merge, если тест по ИБ не пройден. Мы это включали в ручное code review, и остальные участники процесса видели статусы по безопасности именно для этого конкретного процесса.

Интеграция с SonarQube

У многих есть quality gate по качеству кода. Здесь то же самое — можно сделать те же самые gates только для инструментов SAST. Будет тот же интерфейс, тот же quality gate, только называться он будет security gate. И так же, если у вас поставлен процесс с использованием SonarQube, можно спокойно все туда интегрировать.

Интеграция на уровне CI

Здесь тоже все достаточно просто:

Например, мы взяли большой проект и решили, что теперь будем сканировать его SAST’ом — ОК. Мы запихнули этот проект в SAST, он нам выдал 20 000 уязвимостей и волевым решением мы приняли, что все хорошо. 20 000 уязвимостей — это наш технический долг. Долг поместим в коробочку, будем потихонечку разгребать и заводить баги в дефект-трекеры. Наймем компанию, сделаем все сами или нам будут помогать Security Champions — и технический долг будет уменьшаться.

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

Пример security gate — аналог quality gate, по наличию и количеству уязвимостей в коде.

Интегрируем с SonarQube — плагин ставится, все очень удобно и классно.

Интеграция cо средой разработки

В нашей среде разработки Intellij IDEA просто появляется дополнительный пункт, который сообщает, что во время сканирования обнаружены такие уязвимости. Можно сразу править код, смотреть рекомендации и Flow Graph. Это все расположено на рабочем месте разработчика, что очень удобно — не надо ходить по остальным ссылкам и смотреть что-то дополнительно.

Open Source

Это моя любимая тема. Все используют Open Source библиотеки — зачем писать кучу костылей и велосипедов, когда можно взять готовую библиотеку, в которой все уже реализовано?

Конечно, это так, но библиотеки также пишутся людьми, также включают в себя определенные риски и также там присутствуют уязвимости, о которых периодически, или постоянно, сообщается. Поэтому есть следующий шаг в Application Security — это анализ Open Source компонент.

Анализ Open Source — OSA

Инструмент включает в себя три больших этапа.

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

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

Анализ компонент, которые используются в промышленной среде. Представим гипотетическую ситуацию, что мы наконец завершили разработку и выпустили в пром последний релиз нашего микросервиса. Он там замечательно живет — неделю, месяц, год. Мы его не собираем, проверки по безопасности не проводим, вроде все хорошо. Но внезапно через две недели после выпуска выходит критическая уязвимость в Open Source компоненте, которую мы используем именно в этой сборке, в пром-среде. Если мы не записываем, что и где мы используем, то эту уязвимость просто не увидим. В некоторых инструментах есть возможность мониторинга уязвимостей в библиотеках, которые сейчас используются в проме. Это очень полезно.

Единственный бесплатный из них — это Dependency-Check от OWASP. Его можно на первых этапах включить, посмотреть, как он работает и что поддерживает. В основном это все облачные продукты, либо on-premise, но за своей базой они все равно отправляются в интернет. Они отсылают не ваши библиотеки, а хэши или свои значения, которые высчитывают, и фингерпринты к себе на сервер, чтобы получить известие о наличии уязвимостей.

Интеграция в процесс

Контроль библиотек в периметре, которые скачиваются из внешних источников. У нас есть внешний и внутренний репозитории. Например, внутри Event Central стоит Nexus, и мы хотим, чтобы внутри нашего репозитория не было уязвимостей со статусом «критичный» или «высокий». Можно настроить проксирование с помощью инструмента Nexus Firewall Lifecycle так, чтобы такие уязвимости отсекались и не попадали во внутренний репозиторий.

Интеграция с артефакториями: Nexus и JFrog.

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

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

У нас есть Public Component Repositories — некие инструменты вовне, и наш внутренний репозиторий. Мы хотим, чтобы в нем были только trusted components. При проксировании запроса проверяем, что у скачиваемой библиотеки нет уязвимостей. Если она попадает под определенные политики, которые мы устанавливаем и обязательно согласовываем с разработкой, то ее не закачиваем и приходит отбивка на использование другой версии. Соответственно, если в библиотеке есть что-то реально критическое и плохое, то разработчик еще на этапе установки не получит библиотеку — пусть использует версию выше или ниже.

Динамический анализ — DAST

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

Эта же система позволяет проверять шаблонные уязвимости в Open Source. Так как DAST не знает, какой Open Source мы используем, он просто кидает «зловредные» паттерны и анализирует ответы сервера:

— Ага, тут есть проблема десериализации, а тут нет.

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

— Ребята, вы издеваетесь?! Мы вам дали учетки, а вы стенд положили!

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

Стоит учесть, что можно использовать это как аналог нагрузочного тестирования. На первом этапе можно включить динамический сканер в 10-15 потоков и посмотреть, что получится, но обычно, как показывает практика, ничего хорошего.

Несколько ресурсов, которые обычно используем.

Стоит выделить Burp Suite — это «швейцарский нож» для любого специалиста по безопасности. Его используют все, и он очень удобный. Сейчас вышла новая демо-версия enterprise edition. Если раньше это была просто stand alone утилита с плагинами, то сейчас наконец-то разработчики делают большой сервер, с которого можно будет управлять несколькими агентами. Это круто, советую попробовать.

Интеграция в процесс

Интеграция происходит достаточно хорошо и просто: запуск сканирования после успешной установки приложения на стенд и сканирование после успешного проведения интеграционного тестирования.

Если интеграции не работают или там стоят заглушки и mock-функции, это бессмысленно и бесполезно — какой бы мы паттерн не отправляли, сервер будет все равно отвечать одинаково.

Процесс

Немножко обобщенно про процесс вообще и про работу каждого инструмента, в частности. Все приложения разные — у одного лучше работает динамический анализ, у другого статический, у третьего анализ OpenSource, пентесты или вообще что-то другое, например, события с Waf.

Каждый процесс нуждается в контроле.

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

Любые данные полезны. Нужно смотреть в различных разрезах на то, где лучше применяется тот или иной инструмент, где процесс конкретно проседает. Может быть, стоит посмотреть на время отклика разработки, чтобы понять где улучшить процесс на основе времени. Чем больше данных, тем больше разрезов можно построить от верхнеуровневых до деталей каждого процесса.

Так как у всех статических и динамических анализаторов свои API, свои способы запуска, принципы, у одних есть шедулеры, у других нет — мы пишем инструмент AppSec Оркестратор, который позволяет сделать единую точку входа в весь процесс с изделия и управлять им из одной точки.

У менеджеров, разработчиков и security-инженеров одна точка входа, из которой можно посмотреть, что запущено, настроить и запустить сканирование, получить результаты сканирования, предъявить требования. Мы стараемся уходить от бумажек, переводить все в человеческий, который использует разработка — страницы на Confluence со статусом и метриками, дефекты в Jira или в различных дефект-трекерах, либо встраивание в синхронный/асинхронный процесс в CI/CD.

Key Takeaways

Инструменты не главное. Сначала продумать процесс — затем внедрять инструменты. Инструменты хороши, но дороги, поэтому можно начать с процесса и настроить взаимодействие и понимание между разработкой и безопасностью. С точки зрения безопасности — не нужно «стопить» все подряд, С точки зрения разработки — если есть что-то high mega super critical, то это нужно устранять, а не закрывать на проблему глаза.

Качество продукта — общая цель как безопасности, так и разработки. Мы делаем одно дело, стараемся, чтобы все правильно работало и не было репутационных рисков и финансовых потерь. Именно поэтому мы пропагандируем подход к DevSecOps, SecDevOps, чтобы наладить общение и сделать продукт качественнее.

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

Между дефектами ИБ и функциональными дефектами знак равенства.

Автоматизируйте всё, что двигается. Всё, что не двигается — двигайте и автоматизируйте. Если что-то делается руками, это не хороший участок процесса. Возможно, стоит его пересмотреть и тоже автоматизировать.

Если размер команды ИБ небольшой — используйте Security Champions.

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

Требования к инструментам.

Доклад Юрия выбрали одним из лучших на DevOpsConf 2018. Чтобы познакомиться с еще большим количеством интересных идей и практических кейсов приходите 27 и 28 мая в Сколково на DevOpsConf в рамках фестиваля РИТ++. А еще лучше, если вы готовы делиться своим опытом, тогда подавайте заявку на доклад до 21 апреля.

Источник