Валерий Боронин (Россия), Positive Technologies. SSDL для руководителей: как исправить безопасность в legacy-проекте

Kaz’Hack’Stan2017ptsecurity.com
Валерий Боронин
Как исправить безопасность в
legacy-проекте

• В PT отвечаю за направление безопасной разработки
• Работал CTO небольшой компании (30+ человек)
• Директором по исследованиям большой
(Лаборатория Касперского, 2500+ человек, 2009-2014)
• В R&D 20+ лет, помню Windows 3.1
• В безопасности с прошлого тысячелетия ;-)
• В AppSec c 2015
• ESMT Европейская школа менеджмента и технологий
Менеджмент технологий и инноваций,
Берлин-Роттердам, 2010–2011
• 15+ публикаций в специализированных изданиях.
• 3 патента в США и ЕС (в соавторстве).
Валерий Боронин, linkedin.com/in/boronin
27 октября, KazHackStan-2017, Алматы Как исправить безопасность в Legacy проекте, Боронин Валерий 2

1. 26 октября Владимир Путин провел расширенное
заседание Совета безопасности, посвященное
проблеме безопасности в инфосфере.
2. Главная цель, …обеспечить бесперебойную работу
отечественных средств связи, коммуникаций и
информсистем. А кроме того, как можно скорее
перейти на отечественное оборудование и ПО.
3. «Обеспечение безопасности информационной
инфраструктуры имеет стратегическое значение,
прежде всего с точки зрения обороноспособности»
4. Сплошь и рядом кибератаки формируются и «как
средство подавления конкурентов или фактора
мягкой силы», отметил глава государства,
5. «а это значит, что мы должны четко представлять
себе все новые тренды, угрозы и вызовы и
своевременно реагировать на них».
МОЛНИЯ! 26.10 Путин Совбез по ИБ
Путин и вирусы: на Совбезе в закрытом
режиме обсудили хакеров

ptsecurity.com
Тренды, угрозы и вызовы
Взрывной рост угроз и отлавливаемых проблем в коде

1. Производство ПО – очень молодая индустрия
2. Большинство ПО плохо написано, ненадежно и небезопасно
• этому не учат
• качественный код не поощряется
• в отличие от дешевого и быстрого
• потребители не требуют
безопасного кода
3. Угрозы растут быстрее, чем
можем представить, даже сами
эксперты © Шнейер, RSA’17 keynote
Угрозы растут быстрее, чем думаем
Атака роутеров
21.10.2016 – ботнет Mirai

1. Интернет возник без безопасности by design, мы сейчас также
наверстываем
2. Криптография, сетевая безопасность, общая ИБ – все это из
специализированной предметной области выплескивается в
реальный мир и затрагивает всех и вся
3. Экономическая, физическая безопасности – уже невозможно
обеспечить без ИБ
4. Компьютерная безопасность -> Безопасность всего
5. С одним критически важным исключением – угрозы становятся
больше!
6. IoT-робот размером в целый мир от Шнейера, RSA’17 keynote
Угрозы становятся больше

1. Атака сильнее защиты, в основе – сложность
2. Сложность умножается на подключенность «всего ко всему»
• Соединение всего со всем создает новые уязвимости
• Каскадные атаки
• Трансграничность
• Нет одного ответственного
• Небезопасное взаимодействие 2х безопасных систем
3. Каждый противодействует лучшему атакующему в мире
4. Одно из наиболее мощных свойств Интернета – позволяет
вещам (и угрозам!) масштабироваться
Почему код столь небезопасен?

• DECEMBER 4, 2013 AMAZON DEPLOYS TO
PRODUCTION EVERY 11.6 SECONDS
• 2016: см картинку è
Если не выкатываем ежедневноежечасно
• Выбываем из игры
• Инновации затруднительны
• Конкуренты уходят в отрыв
Но придерживаясь тренда на DevOps,
CI/CD – мы создаем среду, в которой
уязвимости выкатываются в производство через дни, часы, или …мгновенно!
Лавина кода выкатывается мгновенно
https://www.slideshare.net/flamboy
ant4u/devops-101-64274725/40

1. Наши ПК и смартфоны относительно
безопасны потому что гиганты
вкладываются
2. Для встроенных систем это не так.
Производители и сборщики не
обладают экспертизой. Патчинг через
выброс и устройств и заменой новым.
3. Экономика не способствует и Рынок не
поможет: Покупателей все устраивает,
Продавцов все устраивает
4. Externalities – Невидимое загрязнение
Невидимое загрязнение

• Качество – не то, что можно
поправить в конце
• Безопасность – это как
качество, ключевая его
характеристика, интегральная
• В коде – только ~35% проблем
Жизненный цикл разработки ПО SDL

1. В коде – загрязнение тоже, и это гораздо более
точная аналогия, чем технический долг, который
платят только разработчики
2. Здесь имею ввиду не только создаваемый
исходный код, но и весь используемый и
покупной
3. В результате сложность и стоимость разработки
ПО растет взрывным темпом
4. Но еще быстрее растут риски и падает качество
5. Имеем взрывной рост угроз и отлавливаемых
проблем в коде
Рост угроз и проблем в коде

ptsecurity.com
AppSec на подъеме
А где же этот ваш AppSec?

InfoSec (ИБ) защищает организацию
и операции
InfoSec (ИБ) это про:
• Networks, Firewalls, Server security,
Anti-virus, IDS, Logging, NOC,
Policies, end-user security, mobile
devices, AD/Ldap management, user
provisioning, DevOps, ….
AppSec – защищает весь создаваемый,
используемый и покупной исходный код
AppSec это про:
• code, apps, CI, secure coding standards, threat
models, frameworks, code dependencies, QA,
testing, fuzzing, dev environments, DevOps, ….
• Если ваш ИБ человек не может писать код (не
будет нанят разработчиками), то это НЕ AppSec
• AppSec ~= Non-Functional requirements
• AppSec – про понимать и контролировать
непреднамеренное поведение приложения
AppSec vs InfoSec
Оба одинаково важны, но ИБ
гораздо более зрелая, имеет
большие бюджеты и лучше
понимается бизнесом

• Облака улучшили сетевую безопасность и ИБ. Сущ. Инфраструктура
безопасности и обнаружения сосредоточена на сетях (не Приложениях)
• Конечно, нужно заниматься этими и другими функциями безопасности,
это все важно, но все активы доступны на уровне приложений
• Большинство атак в наши дни происходят на уровне приложений
• Новый код лавинообразно пишется каждый день
• Технологии развиваются и устаревший legacy код на них уже не заточен
• Если не писатьпокупать защищенный код, ваши активы будут
уязвимы
• Улучшение понимания безопасности уже делает ее чуть лучше
• Корень прошлых проблем с безопасностью все еще здесь (в коде)
Сетевая безопасность и ИБ впереди

ptsecurity.com
Exec Summary
В чем проблема конкретно и какие ваши предложения?

• Даже если ваша компания не нанимает разработчиков, вы уже являетесь
«софтверной компанией»
• Вероятно, вы не рассматриваете разработку ПО как основную компетенцию и
не контролируете ПО / Приложения, которые управляют вашей компанией (что
является риском высокого уровня само по себе)
• Если ваша операционная деятельность, продажи или обслуживание
клиентов, контролируются тем ПО, что вы делаете заказываете – вы уже
software компания (отрасль неважна)
• Вопрос в том, насколько ваша команда и команда разработчиков осознают
это, и насколько приоритет и внимание уделяется (безопасной) разработке ПО
• Код контролирует вашу компанию
• Вопрос в том, насколько вы
контролируете свой код?
Вы уже software компания
Talk is cheap. Show me the code.
- Linus Torvalds

1. Совет директоров, CTO, CISO и владельцы бизнеса ставят свои карьеры на:
• Безопасность существующих приложений и
• их способность успешно обнаруживать, содержать и реагировать на злонамеренные атаки и код
2. Сегодня по-прежнему существует большое количество рисков безопасности
высокого уровня, которые не фиксируются
• пользователи подвергаются высокому риску эксплуатации
3. Недавно был обнаружен ряд рисков высокого уровня
• и нет НИКАКИХ ГАРАНТИЙ, что они единственные
4. В настоящее время нет оправданий (на рынке) для тех проблем и
уязвимостей, которые существуют в настоящее время в производстве:
• это было бы нормально, если бы они были в прошлом,
• но сейчас (2016), и поскольку они хорошо всем понятны
5. НЕ фиксируя их, показывается неполное служебное соответствие и
недостаточная забота о данных пользователей и акционерах
Скрытая ставка на свою карьеру

Если вы не делаете у вас нет:
1. Команды AppSec и озадаченных безопасностью людей в dev командах
2. Инспекций, еженедельных код и security review
3. Моделирования угроз
4. Статанализа и тестирования на безопасность, автоматических!
5. Планов реагирования на инциденты и восстановления в случае отказов
• ...и многих других мер AppSec и SDL (Secure Dev Life Cycle)
В приложениях, которые вы используете, будут значительные уязвимости
• Потому что откуда возьмется безопасность?
Без этих действий:
• Ваша модель безопасности основана на квалификации и бизнес-модели атакующих
• ... и ...«волшебная защитная пыль» (которая работает до тех пор, пока вас не атакуют)
Волшебная защитная пыль ;-)

• Если нет AppSec команды и др (см пред. слайд)
• Неизвестно, сколько уязвимостей безопасности уже известно (и
успешно эксплуатируется) существующими злоумышленниками
• Отсутствие журнала, видимости в существующей инфраструктуре
атак на приложения
• Старые части кодовой базы НЕ должны рассматриваться как
legacy устаревшие, поскольку они все еще несут ответственность
за значительный процент веб-трафика и прибыли
• При нынешнем положении дел заявлять что у вас безопасная,
надежная, устойчивая и современная платформа нельзя (рынку,
акционерам и пользователям)
Кейс – сайт НЕбезопасен = опасен

Нет формального процесса принятия
риска
• Риски в неофициальных средах
(Письма, лично, на встречах, вики)
• Реальный риск принятых решений
неизвестен и не понятен
• Решения не основаны на данных
Решение, повышаем accountability:
• Владельцы бизнеса и технический
директор должны «принять риск»
• Использовать Risk Workflow (на
базе Jira или GitHub, будет далее)
Для чего требуется:
• Балансировать аппетит к бизнес-
рискам с реальностью (используя
предложенный рабочий процесс
управления рисками для
распределения ответственности на
правильном уровне)
• Измерять загрязнение кода с
помощью Risk Workflow
• Политики должны поддерживать
то, что лежит в основе принятых
решений на основе принятых
рисков
Нет четкого процесса принятия
риска

• Legacy код по-прежнему будет жить в ближайшие 3-5 лет
• Опасная стратегия Идея:
• «Заменить сложную систему, которую трудно изменить (и понять) ...
• ... отдельной, полностью новой сложной системой, построенной на новой технологии
• очень редко работает
• Лучшая модель - это «инкрементальные изменения, с совместимыми
новыми функциями»
• Создаем Legacy Development Plan с командой
• Подходящее имя для команды Legacy-SecDevOps
• Эта команда будет сосредоточена на:
• устранении проблем безопасности, рефакторинге, тестировании, развертывании
• Не добавляем новых фич и функций первые 6 месяцев работы
Legacy-SecDevOps

Как минимум:
• Готовим несколько планов аварийного восстановления и реагирования на инциденты
• Выполняем регулярные учения для проверки и отладки тонкой настройки этих планов
• Киберстраховка (будет дороже, чем предлагаемое здесь решение, вариант для Запада)
Официально принять (в Risk Workflow, в трэкере) риски:
1. Приложение не является безопасной платформой
2. Приложение не было тщательно изучено на предмет рисков безопасности AppSec
3. Масштабы количества проблем AppSec неизвестны
4. Существует ряд открытых рисков AppSec высокого уровня, без планов их исправлять
5. Невозможно обнаружить зондирование и эксплуатацию злоумышленниками
6. Невозможно выборочно удалять отключать уязвимые функции
7. Риск безопасности и эксплойты приложения будут влиять на все приложения,
совместно размещенные в одном домене
Если желающих нет

ptsecurity.com
Legacy-SecDevOps
Концепция, что делать, выгоды, кто оплатит, оргструктура

SecDevOps (Securing DevOps)
24
Development
Security
QA
IT Ops
Secured
DevOps
27 октября, KazHackStan-2017, Алматы Как исправить безопасность в Legacy проекте, Боронин Валерий
https://www.slideshare.net/ValeryBoronin/2016-61855208

• Запускаем проект на 6 мес (начиная с 10 января 2018) с
обязательным ревью через полгода (измеряем эфф-ть)
• Это нужно для финанасирования и запуска AppSec команды в 2018
• Тестирование, управление зависимостями и визуализация
web-сервисов – особое внимание
• Берем одну известную уязвимость и рефакторим весь код
в отдельный модуль (aka микросервис) по схеме от
лучших собаководов из OWASP на след слайде
Главная идея

От лучших собаководов из OWASP
берем 1 известную уязвимость и рефакторим весь код в отдельный модуль (микросервис)
▸ включалкивыключалки фич, чтобы можно было использовать на живых системах
▸ полностью независимый стек для разработки, тестирования и продакшна
▸ контейнеры для разработки, тестирования и продакшна
▸ добавить активностей связанных с безопасностью (SDL)
▸ Моделирование угроз
▸ Ревью на безопасность и соблюдение стандартов защищенного кодирования
▸ Автотесты на безопасность в QA (от юнит до интеграционных), 100% покрытие
▸ Автоматическое отображение (mapping) поверхности атаки и документирование
▸ помощь независимых экспертов по ИБ снаружи
▸ Мониторинг и визуализация происходящего в продакшне
▸ Готовиться к инцидентам и отражению атак надо заранее
26
Source: Dinis Cruz
Изучай оффлайн

SecDevOps рекомендуют
▸ Автоматизируйте CI и CD
▸ Быстро разворачивайте и восстанавливайте
▸ Отслеживайте и визуализируйте все
▸ Используйте контейнеры в продакшне
▸ Ежедневные множественные деплои
▸ Kanban workflow
▸ Low WIP (work-in-progress) count и андоны
▸ Улучшайте покрытие тестирования и качество тестовых API
▸ Реалтаймовые юнит тесты и покрытие в IDE
▸ SecDevOps Pipeline
▸ определяйте изменения sensitive кода (trigger secure code review)
▸ автоматическое развертывание of air-gapped QA sites
(with surrogate dependencies for external components)
▸ автоматический запуск статического анализа и динамического анализа
27
Source: Dinis Cruz

• Процессы, передовые методы, технологии и полученные знания будут
распространяться на другие команды
• Используем проект Legacy-SecDevOps как стратегическую
возможность управлять изменениями в организации и поднять планку
разработки, тестирования и QA
• Отличная возможность научиться внедрять методы, процессы и
технологии безопасности в процесс жизненного цикла разработки и CI
• Участники вернутся в свои команды прокачанными, со знаниями
• SOC получит новые инструменты и видимость
Позитивное влияние инвестиций

Кто заплатит за это:
• Операционный бюджет (из прибыли старого приложения)
• R&D бюджет
• Команды, которые выделяют ресурсы (на 6 месяцев)
• Бюджет страхования AppSec (страховки от киберинцидентов уже есть)
Data breach или атака будут стоить больше, чем устранение проблем:
• Существующий закон о data breach в Великобритании позволяет до 500 000
фунтов (https://ico.org.uk/about-the-ico/what-we-do/taking-action-data-protection/)
• новое регулирование ВВП (в Великобритании к 2018 году) позволит штрафы
до 4% от оборота всей компании (см. https://ico.org.uk/for-organisations/data-
protection-reform/overview-of-the-gdpr)
Рассматриваем проект Legacy-SecDevOps в качестве страховки
Legacy-SecDevOps бюджет

• Создаем команду для проекта (Legacy-SecDevOps) с использованием
внутренних ресурсов (где и если это возможно) в составе
• Старший архитектор безопасности
• Старший инженер AppSec
• 3x Senior Dev / QA
• 3x Стажера Dev / QA
• 1x DevOps
• 1x ПМ
• 30 дней внешних пентестов
• Все будут обучены в качестве Security Champions с ожиданием, что они затем
перенесут знания и рабочие процессы в свои оригинальные команды
• Это шаблон для избранных целевых групп разработчиков, которые могут быть
выборочно использованы для управления стратегическими технологическими
изменениями
Legacy-SecDevOps команда
Source: Dinis Cruz

ptsecurity.com
7+1 активностей
Которые никому не будут лишними
Если нас много? И даже если мало?
Но мы в тельняшках! ;-)

Пример неплохой структуры
Ключевые области:
• SecOps
• SOC
• RISK
• AppSec
• Testing
Также важно:
• Security   Champions
• Knowledge
• RND
1. Central AppSec Team
https://www.slideshare.net/DinisCruz/sc-
conference-building-appsec-teams-v08

Предоставляет сервисы командам
• External Pen-Tests
• Code Reviews (internal and external)
• Threat Modeling
• Static and Dynamic scanning of code
• AppSec Training
• AppSec Advisory Surgery
Активности:
• Support Security Champions Network
• Manage AppSec Risk Workflow
• Maintain AppSec knowledge base (Confluence based)
• Own AppSec Policy
• Own Secure Coding Standards (based on JIRA Risk
issues and OWASP ASVS)
• Own SDL (Secure Development Lifecycle) programme
• Manage Internal and External Bug-Bounty mgmt
• Provide App Registry and Attack Surface mapping
• Create Visualisations of existing architecture / code
and Business reporting of existing risks
Ex: Security Function Budget and Team

• Security as Code
• Self-Service Testing
• Red Team/Blue Team
• Inline Enforcement
• Analytics & Insights
• Detect & Contain
• Incident Response
• Investigations
• Forensics
DevSecOps by Amazon
https://www.slideshare.net/AmazonWebServices/sec320-
leveraging-the-power-of-aws-to-automate-security-
compliance

А без AppSec могу? Security Adviser
35
https://www.slideshare.net/ValeryBoronin/sdlssdl-69670799

Являются ключевым элементом команды AppSec
• поскольку они создают кросс-
функциональную группу, ориентированную
на безопасность приложений
• Кто они такие, чем будут заниматься?
• На что уйдет >20% времени под их дела?
• Почему следует стать SC, в чем выгода?
• Кто квалифицируется? Как обучается?
• Проводят хакатоны по безопасности
• Участие в проектах, управляемых AppSec
Чтобы настроить под свою культуру и рабочие
процессы – см справа, + вариант от MSFT дальше
2. Security Champions (SC)
http://blog.diniscruz.com/2015/10/w
hat-are-security-champions-and-
what-do.html

• Accountability – The key is to make
the business accept the risk (i.e the
debt) – make sure it is your boss who
gets fired (all the way to the board)
• Отдельный проект, отдельный
бэклог
• Объем и наполнение рисками.
Проблема когда их 5.
Должно быть 350+
• Детали справа, фактически весь
рабочий процесс уже на картинке
3. Risk Workflow
https://www.slideshare.net/DinisCr
uz/secdevops-risk-workflow-v06

• Dataflow Diagrams (DFD) + STRIDE = Threat Model
• Делаются по уровням, фичам, …
• связанные / привязанные к
соответствующим типам угроз
• Модели отображаются на риски
• Пентесты подтверждают модели угроз
• Начните на бумаге
• Подробнее в докладе с классическим SDL, там же список литературы
4. Моделирование Угроз

Моделирование Угроз
http://blog.diniscruz.com/search/label/Threat%20Modeling

5. Инспекции и secure code
standards
• Стандарты кодирования, классификации багов,
критериев и метрик для триажа, использования
инструментария и т.п., см материалы в конце
• Чеклист для ТЗ (ЧТО и ЗАЧЕМ)
• Чеклист для SAD / Design (КАК)
• Точка синхронизации понимания всеми в
команде
• Исходный материал к ревью и фиксация
принятых решений
• Форма (документ, вики…) не важна, важна суть

Внедрение автоматизации безопасности в вашем SDL-конвейере
• SecDevOps – см справа
Команда AppSec
• Интеграция инструментов
безопасности в SDL
• Оценить и развернуть инструменты
для выполнения статических (SAST) и
динамических (DAST) сканирований
существующих приложений и кода
• Настройка правил для создания
высоконадежных данных
• Работа с SC по исправлению проблем
6. Статанализ и др инструменты
https://www.slideshare.net/ValeryBoronin/2016-61855208

7. Планы реагирования и учения

• Резать нельзя лечить
• Security Push и другие
изменения
продуктового цикла,
которые помогут – в
докладе про
классический SDL
• Учиться, учиться, учиться
– повышать людям
мотивацию на
качественный и
защищенный код через
тренинги и обучение
7 + 1 Что-то еще?

ptsecurity.com
В завершение

• Выгоды для разработчиков, для
руководителей, для первых лиц
• Бюджеты, расписание,
требуемые умения и навыки,
изменение в продуктовом
цикле, … – подробнее в è
• DISCLAIMER: Материал(ы) выше
не догма, а исходник-шаблон
для творческой переработки
под себя, прикидок бюджетов и
планов, формулы нет
Больше информации и DISCLAIMER
https://www.slideshare.net/ValeryBoronin/sdlssdl-69670799

High Quality is free (book of 1979)

А кто не будет меняться….
…. тому отключим газ!
Век светлого высокотехнологичного будущего не видать J

ptsecurity.com
Спасибо!
Стройте AppSec, внедряйте SSDL
и с его помощью SecDevOps!
Валерий Боронин

Что такое SDL / безопасная разработка?
15 апреля 2017, Стачка, Ульяновск SecDevOps, Боронин Валерий 49
https://www.slideshare.net/ValeryBoronin/sdlssdl-69670799https://www.slideshare.net/ValeryBoronin/2016-61855208

Валерий Боронин (Россия), Positive Technologies. SSDL для руководителей: как исправить безопасность в legacy-проекте

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Валерий Боронин (Россия), Positive Technologies. SSDL для руководителей: как исправить безопасность в legacy-проекте

Ähnlich wie Валерий Боронин (Россия), Positive Technologies. SSDL для руководителей: как исправить безопасность в legacy-проекте (20)

Mehr von KazHackStan

Mehr von KazHackStan (20)

Валерий Боронин (Россия), Positive Technologies. SSDL для руководителей: как исправить безопасность в legacy-проекте