Внутреннее качество в процедурах информационной безопасностиAlex Babenko
Процедуры информационной безопасности – основные шестерни, приводящие в движение процесса обеспечения информационной безопасности. А корректное выполнение процедур является атрибутов успешности его выполнения. В докладе рассматриваются использование принципа «встроенного качества» при создании и документировании процедур информационной безопасности, построение процессов допускающих только корректное выполнение.
Более подробно - в заметках к слайдам.
Внутреннее качество в процедурах информационной безопасностиAlex Babenko
Процедуры информационной безопасности – основные шестерни, приводящие в движение процесса обеспечения информационной безопасности. А корректное выполнение процедур является атрибутов успешности его выполнения. В докладе рассматриваются использование принципа «встроенного качества» при создании и документировании процедур информационной безопасности, построение процессов допускающих только корректное выполнение.
Более подробно - в заметках к слайдам.
Выступление Валерия Боронина, посвященное внедрению безопасной разработки с точки зрения руководителя, на встрече PDUG Meetup: SSDL for Management 25 ноября 2016 года.
Построение процесса безопасной разработки - Стачка 2016Valery Boronin
Безопасность - критически важный элемент любого программного решения. Элемент, который, рано или поздно, но заставит вспомнить о себе. Скупой платит дважды, а в данном случае – минимум четырежды. Безопасность и качество кода – связаны напрямую. Поэтому положение дел и с тем и с другим редко находят достаточно хорошим даже в самых успешных проектах – всегда хочется бОльшего. А где-то бывает просто необходим качественный переход и точечными мерами кардинально ситуацию уже не исправить, нужен системный подход.
Вот почему наладить процесс обеспечения и повысить уровень зрелости безопасности разработки, повысить качество кода – хотят многие руководители и разработчики. Как это сделать системно и в согласии? Какие риски для одних, какие трудозатраты для других? И стоит ли овчинка выделки? Об этом и поговорим.
2016/05/10: загружена версия для оффлайна.
Исследование безопасности создаваемых информационных систем и разрабатываемых приложений становится распространенной практикой. Безопасники получили наконец заслуженное признание и «включены в цикл» разработки, их вписывают в нормативку, создают базы знаний для хранения результатов исследований. Чего ждут разработчики и владельцы информационных систем от исследователей? Поговорим о задачах, которые предстоит решать, и о качестве исследований, проводимых на регулярной основе.
SSDL для руководителей: как перевести команду на безопасную разработку и не выстрелить себе в ногу.
25 ноября в Технологическом центре Microsoft состоится PDUG Meetup: SSDL for Management — встреча для руководителей R&D- и ИБ-подразделений, управляющих крупными проектами и командами разработки
https://habrahabr.ru/company/pt/blog/315840/
--
Дополнительно: www.slideshare.net/ValeryBoronin/2016-61855208
Лекция по безопасной разработке приложений защиты информации в РФ. Читается на 4 курсе ФРТК МФТИ. Рассмотрен процесс создания криптографических и технических средств защиты информации.
Листовка нашего продукта, подготовленная к PHD 2016. Подробнее по ссылке http://www.slideshare.net/ValeryBoronin/application-inspector-ssdl-edition-product
English version:
www.slideshare.net/ValeryBoronin/pt-application-inspector-ssdl-edition-leaflet-67085824
PT AI Desktop edition product brief:
www.slideshare.net/ValeryBoronin/pt-application-inspector-desktop-edition-product-brief
Хакеры, скандальные утечки данных, целые отделы, занимающиеся вопросами ИБ в компании - все это больше из области теле-новостей про фирмы-гиганты. Но, "плачут не только богатые". У обычных небольших организаций, и у обычных людей - вопросы ИБ занимают все более важное место.
В докладе будут даны рекомендации по ИБ для самых обычных организаций - небольших фирм от 10 сотрудников. Как хоть немного защититься в этом сложном информационном мире. Поговорим об ИБ - без фанатизма, без сертификации ИСО 27001 и без консультантов от "большой четверки".
O documento resume a regionalização da América, dividindo-a em América Anglo-Saxônica e América Latina de acordo com a língua e religião dos colonizadores. Também discute as diferentes formas de colonização na América - exploração e povoamento - e suas consequências econômicas e sociais. Por fim, analisa o subdesenvolvimento na América Latina em comparação à América do Norte desenvolvida.
Выступление Валерия Боронина, посвященное внедрению безопасной разработки с точки зрения руководителя, на встрече PDUG Meetup: SSDL for Management 25 ноября 2016 года.
Построение процесса безопасной разработки - Стачка 2016Valery Boronin
Безопасность - критически важный элемент любого программного решения. Элемент, который, рано или поздно, но заставит вспомнить о себе. Скупой платит дважды, а в данном случае – минимум четырежды. Безопасность и качество кода – связаны напрямую. Поэтому положение дел и с тем и с другим редко находят достаточно хорошим даже в самых успешных проектах – всегда хочется бОльшего. А где-то бывает просто необходим качественный переход и точечными мерами кардинально ситуацию уже не исправить, нужен системный подход.
Вот почему наладить процесс обеспечения и повысить уровень зрелости безопасности разработки, повысить качество кода – хотят многие руководители и разработчики. Как это сделать системно и в согласии? Какие риски для одних, какие трудозатраты для других? И стоит ли овчинка выделки? Об этом и поговорим.
2016/05/10: загружена версия для оффлайна.
Исследование безопасности создаваемых информационных систем и разрабатываемых приложений становится распространенной практикой. Безопасники получили наконец заслуженное признание и «включены в цикл» разработки, их вписывают в нормативку, создают базы знаний для хранения результатов исследований. Чего ждут разработчики и владельцы информационных систем от исследователей? Поговорим о задачах, которые предстоит решать, и о качестве исследований, проводимых на регулярной основе.
SSDL для руководителей: как перевести команду на безопасную разработку и не выстрелить себе в ногу.
25 ноября в Технологическом центре Microsoft состоится PDUG Meetup: SSDL for Management — встреча для руководителей R&D- и ИБ-подразделений, управляющих крупными проектами и командами разработки
https://habrahabr.ru/company/pt/blog/315840/
--
Дополнительно: www.slideshare.net/ValeryBoronin/2016-61855208
Лекция по безопасной разработке приложений защиты информации в РФ. Читается на 4 курсе ФРТК МФТИ. Рассмотрен процесс создания криптографических и технических средств защиты информации.
Листовка нашего продукта, подготовленная к PHD 2016. Подробнее по ссылке http://www.slideshare.net/ValeryBoronin/application-inspector-ssdl-edition-product
English version:
www.slideshare.net/ValeryBoronin/pt-application-inspector-ssdl-edition-leaflet-67085824
PT AI Desktop edition product brief:
www.slideshare.net/ValeryBoronin/pt-application-inspector-desktop-edition-product-brief
Хакеры, скандальные утечки данных, целые отделы, занимающиеся вопросами ИБ в компании - все это больше из области теле-новостей про фирмы-гиганты. Но, "плачут не только богатые". У обычных небольших организаций, и у обычных людей - вопросы ИБ занимают все более важное место.
В докладе будут даны рекомендации по ИБ для самых обычных организаций - небольших фирм от 10 сотрудников. Как хоть немного защититься в этом сложном информационном мире. Поговорим об ИБ - без фанатизма, без сертификации ИСО 27001 и без консультантов от "большой четверки".
O documento resume a regionalização da América, dividindo-a em América Anglo-Saxônica e América Latina de acordo com a língua e religião dos colonizadores. Também discute as diferentes formas de colonização na América - exploração e povoamento - e suas consequências econômicas e sociais. Por fim, analisa o subdesenvolvimento na América Latina em comparação à América do Norte desenvolvida.
O artigo resume:
1) O ministro da Geologia e Minas de Angola apresentou as oportunidades de investimento no setor mineiro de Angola em uma conferência na Cidade do Cabo;
2) Isso despertou o interesse de mais de 200 participantes, incluindo representantes governamentais e empresas de mineração;
3) O ministro destacou o potencial de Angola em diversos minerais além de diamantes, como ferro, cobre e ouro.
O Renascimento marcou a transição dos valores medievais para um mundo moderno influenciado pela burguesia. O período foi caracterizado pela redescoberta da cultura clássica da Grécia e Roma. O Renascimento surgiu na região da Toscana na Itália e se espalhou pela Europa Ocidental, promovendo avanços nas artes e ciências.
Este documento apresenta um resumo de um teste sobre o uso do algicida sulfato de cobre em tanques de criação de camarões. O teste avaliou a resistência dos camarões a diferentes concentrações de íons de cobre em aquários. O documento também contém questões sobre química geral e reações químicas relacionadas a poluentes atmosféricos.
Este documento presenta una serie de prácticas para estudiantes del curso de Artista Gráfico Comercial utilizando el programa Paint de Windows. La primera práctica instruye a los estudiantes a dibujar una fruta, figuras geométricas, y una casa con un slogan, guardando los archivos en una carpeta específica. La segunda práctica enseña a cambiar el tamaño del lienzo y dibujar un círculo con detalles e imágenes. La tercera práctica guía a los estudiantes a dibujar un j
На вебинаре участники ознакомились с актуальными проблемами, связанными с реализацией задач по сбору, анализу и корреляции событий информационной безопасности, регистрируемых в территориально-распределенных автоматизированных системах предприятий.
В рамках мероприятия были рассмотрены основные преимущества использования систем мониторинга, позволяющие повысить эффективность принятия решений по реагированию на инциденты безопасности
и также рассмотрена одна из возможных реализаций центра мониторинга событий безопасности (Security Operation Center, SOC) на базе программных продуктов HP ArcSight.
Мониторинг событий информационной безопасности на базе решений HP ArcSight ES...DialogueScience
Рассматриваются основные преимущества использования систем мониторинга, позволяющие повысить эффективность принятия решений по реагированию на инциденты безопасности.
Спикер:
Родион Чехарин,
Руководитель проекта технического департамента ЗАО «ДиалогНаука»
Практические особенности внедрения систем класса DLPDialogueScience
В рамках вебинара "Практические особенности внедрения систем класса DLP" вы узнаете:
- цели и задачи, которые заказчик обычно ставит перед DLP, его ожидания;
- часто допускаемые ошибки;
- цели проекта по внедрению DLP;
- этапы проекта по внедрению DLP;
- описание этапов проекта;
- каких ошибок удается избежать при правильном подходе;
- преимущества и недостатки;
- ответы на вопросы.
Спикер: Роман Ванерке, руководитель отдела технических решений АО «ДиалогНаука»
Презентация с вебинара "Спроси эксперта. Все, что вы хотели узнать про «дыры» в коде, но не у кого было спросить"
Ссылка на страницу вебинара (и запись) - http://solarsecurity.ru/analytics/webinars/665/
This document summarizes the key offerings and services from Positive Technologies, a leading cybersecurity firm. It highlights Positive Technologies' expertise in incident response, penetration testing, application security, and security management solutions. The document also discusses Positive Technologies' approach to addressing different threat levels, from mass threats to more advanced targeted attacks. It provides an overview of Positive Technologies' security workflow and products to help organizations predict, prevent, respond to, and detect security issues.
Сервисы ИБ как ответ на новые угрозы ИБ (PHDays 2016)
2015 02 пм качалин sdl
1. «Опасная разработка. Дорожная карта
движения к катастрофе»
Практика внедрения в организациях цикла безопасной
разработки программного обеспечения
Качалин Алексей
Зам. Генерального директора
ЗАО «Перспективный мониторинг»
2. О наших работах по теме
• Инструментальный анализ ПО и ИС
• С 2012 года – работаем по направлению
повышения безопасности разработки
• Принимаем участие в работе ГК с
регуляторами
– ФСТЭК: требования к СЗИ и ИБ платформ, база
угроз, безопасная разработка
– ФСБ: СОПКА
3. Безопасная разработка:
этапы осознания проблем
Мониторинг и реагирование
Проверка и выпуск продукта
Разработка
Проектирование
Требования
Подготовка команды
Внедрение цикла безопасной разработки
4. Шаг 1. Такая безопасность не нужна
2010 год. Эксперт по ИБ/соответствию требованиям:
«… работы по инструментальному анализу не будут
востребованы, нет таких требований у регуляторов»
• ФСТЭК: о безопасной разработке
• «Банки будут стремиться оптимизировать
расходы, а самый оптимальный способ –
вывести операции в Интернет»
• «Анализ безопасности ПО - одно из
немного за что в кризис банки
будут готовы платить»
Февраль 2015. Конференция ИБ Банков
5. Безопасность разработки - требование рынка
• Уязвимости и инциденты ИБ
– Репутация невозможно контролировать
раскрытие информации
– Раскрытие информации об уязвимостях
используемых компонентов
– Обращения к регулятору с вопросами от
пользователей
• Необходимость реакции
– Взаимодействие с «атакующим»
сообществом
• Требования НПА и регуляторов
• Требования 3-их лиц по гарантиям ИБ
6. Шаг 2. Соответствие как самоцель
«При выполнении работ должны применяться практики
безопасной разработки программного обеспечения»
Из ТЗ
7. Разработка
Подтверждение соответствия ПО
Как устроена разработка
• Водопад – не модно?
• Итеративные и гибкие методики
В худшем случае – после разработки
• Внутренние требования организации
• Требования регуляторов отрасли (БР, PCI DSS)
• Требования гос.регуляторов
• …Разработка
Проект
Проект
Безопасная
разработка
Проект
Проект
Безопасная
разработка
8. Шаг 3. ИБ будет протестировано
«… в случае возникновения проблем у
внедряемого сервиса мы обратимся за анализом
уязвимостей»
Руководитель службы эксплуатации сервиса в
первом проекте
«…мы хотим сделать новый
сервис, представляющий
следующие возможности:…,
насколько это безопасно?»
Он же, несколько проектов спустя
9. Эволюция требует повторений
Мониторинг и реагирование
Проверка и выпуск продукта
Разработка
Проектирование
Требования
Подготовка команды
Внедрение цикла безопасной
разработки
1
10. Эффект от внедрения безопасной
разработки
• Осязаемые результаты: отдача от инвестиций
– Возврат инвестиций
• ПО финансовых, подверженных фроду систем – возможно
– Снижение количества инцидентов
– Оперативность реагирования на инциденты
• Встраивание в существующий процесс разработки
(заказа и эксплуатации ПО)
• Часто применение к имеющимся продуктам или
компонентам
– Вам продают «задел по теме», свой или чужой
• Вовлечение команды (мотивация исполнителя и
легитимизация затрат) на дополнительные практики ИБ
10
11. Шаг 4. Какая-то безопасность разработки
«Мы себя проверили – у нас многое есть.
Программисты что-то такое делают. Не надо
ничего менять»
В ответ на предложение развивать практики
Отказ от изменений
Самообман
Непонимание
12. Не так уж и сложно соответствовать SDL
Basic Standardized
(Activities are
expert led)
Advanced
(Activities are led
by central security
team)
Dynamic
(Activities are co-
led by product
teams and central
security team)
Training, Policy
Organizational
Capabilities
+ Setting baseline and goals
for SDL
+ Executive support: Tacit
+ Enterprise coverage: Few
SDL pilot project
+/- Training: Basic concepts
+/- Basic security bug tracking
- Executive support: Explicit
- Enterprise coverage: New,
high risk project
- Training: Common baseline
- Central security team exists
- Executive support: SDL
mandated and enforced
- Enterprise coverage: All
project with meaningful risk
+/- Training: Custom training
- SDL is adopted to the
development methodology
Requirements
Design
Undefined or inconsistent - Risk assessment
+/- Threat models: Piloted to
high-risk modules
- Functional requirements for
security and privacy
- Standard security solutions
+/- Threat models: Created
with expert assistance
- Threat models:
Independently created by
product group
Implementation Undefined or inconsistent + Compiler defense
- Banned functions
- Cross-site scripting and SQL
injection defenses
+/- Static analysis tools - In-house, product-specific
security tools development
and customization
Verification Undefined or inconsistent - File fuzzing
- Basic Web application
scanning
+ Penetration testing by third
party as appropriate
+/- Comprehensive fuzzing
and Web application scanning
- Threat model validated
- In-house development and
customization tools to:
+ Detect vulnerabilities
- Audit compliance with SDL
Release
Response
Undefined or inconsistent - Final Security Review: Verify
internal and external
compliance
+ Project archiving
+ Response: Basic
+ Response plan in place,
incident tracking
- Basic root-cause analysis
- Real-time incident tracking
- Advanced root-cause analysis
and formal feedback into
policy
13. Ловушки инструментов и практик “as is”
• Выбор инструментов и компонентов
– Удобство среды разработки
– Использование знакомых компонентов
– Борьба с унаследованным кодом
• «Безопасное программирование» == ИБ?
– Утечки памяти, переполнение буфера, падения/повисания
– Безопасные опции компилятора
• Инструменты безопасности при разработке
– Анализаторы кода
– Генераторы нагрузки без тонкой настройки
– Системы автоматизированного тестирования
• Практики управления
– Менеджер форсирует: бюджет, сроки, функционал
– Унаследованный долг: было 500 предупреждений, будет 507 – ок?
14. Кстати о говоря – о границах понимания
• «Уязвимость» – все говорят, скоро зафиксируют в НПА
• Различные этапы проявления уязвимостей
– Уязвимости эксплуатации
– Уязвимости, вносимые на этапе
формирования требований
• CVE vs CWE - Уязвимость vs Слабость
– Необходимость логичной замкнутой системы
определений и понятий
• Корректность «атакующей» терминологии
– «Василий провёл с своего компьютера DDoS»
– Пользователи устроили DDoS сервиса
– В вашем ПО – эксплоит
15. Шаг 5. Строим
безопасную разработку по учебнику
«Я не читаю курсы по SDL»
Алексей Лукацкий, кладезь по ИБ
16. Что можно почерпнуть из практик MSDL, CSDL, …
• Модель зрелости должна быть
– Подходящая этапность внедрения?
• Домены
– Можно суммировать и расширить
• Готовые методы, инструменты,
классификации
– Моделирование угроз, трассировка
уязвимостей для оценки ущерба
19. Пример одного анализа
• Продуктовый менеджмент
– Интенсивность разработки
• Бизнес: база внедрений,
перспективы продаж
• Разработка:
технологические тренды,
тех.долг и архитектура
• Установка и
сопровождение
– «Агрессивность среды»
– Инциденты
20. Шаг 6. Если решать - то все проблемы
«Если нельзя полностью гарантировать
доверие начиная от аппаратной базы, … - то
нет смысла вообще заниматься вопросами
безопасности»
Анализ
21. Решить проблему нельзя принять риски
• «Крупноузловая» сборка
– Фреймворки и библиотеки
• Инструменты разработчика
– Инструменты проектирования
– Инструменты разработки
– Инструменты хранения и сборки
• Инфраструктура ПО
– Магазины мобильных
приложений и хранения данных
22. Внедрение безопасной разработки даёт
ценную информацию к размышлению
Мониторинг и реагирование
Проверка и выпуск продукта
Разработка
Проектирование
Требования
Подготовка команды
Внедрение цикла безопасной
разработки
23. Развитие мониторинга и реагирования
• Обнаружить публикацию информации об уязвимости
– Публикация уязвимости в используемом компоненте
– Публикация информации об уязвимости в Интернет
– Сети обмена информацией об уязвимостях
– Технический анализ (состояние узлов, трафик, журналы)
• Интерпретировать обращения пользователей
– Сообщения о «странном поведении программы» (нет явного
подозрения на проблемы ИБ)
– Попытки шантажа и ультиматумы, оскорбления и троллинг
– Готовый метод компрометации ИБ (пошаговый, в виде PoCE)
…
• Внутренние сообщение от разработчика – обратить внимание
– Указания на строчку кода
– Развёрнутый анализ с обоснованием неизбежности уязвимости
24. Итого
• Разрозненные практики ИБ часто расходы на иллюзию
безопасности – должна быть поставлена цель
– Синергия безопасной разработки и соответствия требованиям
– Стратегический план реалистичный по ресурсам и времени
• Очень многое зависит от автоматизации и инструментов – но
они не панацея
– Инструменты определяют отдельные сценарии – целостность?
– Риск автоматизации хаоса
• Реагирование дороже предотвращения
24
• «Бесплатно» получится плохо
– Корректировка бюджетов и границ
проектов
– Безопасность – в «системе ценностей»
менеджмента
– Внутренняя команда внедрения
25. худшая из угроз - Неведение
Инструментальный анализ
ПО и ИС
Внедрение практик
безопасной разработки
Мониторинг ИБ
Качалин Алексей
kachalin@advancedmonitoring.ru
Editor's Notes
«Опасная разработка. Дорожная карта движения к катастрофе»
Начнём с цитаты: «… при реализации первой версии нашего продукта мы не занимались вопросами информационной безопасности, мы планируем заняться ими после запуска пилотной версии сервиса.»
Общение с разработчиком программного обеспечения об уязвимостях продукта начинается, как правило, на этапе эксплуатации. На этом этапе все активности, связанные с реагированием и устранением проблем максимально дороги как для разработчика, так и для всех участников «цепочки поставки». Сложившаяся практика делегирования ответственности приводит к тому, что ответственным назначается компания-разработчик, который в свою очередь, в полном соответствии с лицензионным соглашением, имеет право поставлять изделие «как есть» и по факту не несёт обязательств (кроме моральных) по устранению выявленных проблем.
Может ли быть изменена установившаяся тупиковая практика, приводящая к отсутствию у участников процесса позитивных стимулов обратить внимание на безопасность итогового решения? Если абсолютная безопасность не может быть достигнута, то какие приёмы на этапах формирования требований и проектирования могут принести пользу и какова допустимая цена этих мер? Как могут повлиять на разработчика заказчики, поставщики, исследователи и пользователи решений? Готового ответа на эти вопросы, пригодного на все случаи жизни очевидно нет, но даже внесение этих вопросов в обсуждение может стать существенным шагом вперёд.
Ключевые слова: вопросы безопасной разработки, практика проверки продуктов на уязвимости, разработка программного обеспечения, сопровождение разработки заказчиком, регулирование разработки программного обеспечения
1. Данный документ является одним из первых нормативных документов по данной тематике, в котором установлены конкретные требования к процессу разработки, а не к продукту.
2. При разработке данного ГОСТа были учтены лучшие мировые практики по безопасной разработке.
3. В ГОСТе предусмотрен контроль (мониторинг) системы управления безопасной разработкой программного обеспечения, который проводится через внутренние аудиты системы управления безопасностью разработки ПО, что позволяет контролировать качество выполнения требований на всех этапах разработки.
4. Определена необходимость периодического обучения сотрудников организации-разработчика ПО с целью повышения их осведомленности в области безопасной разработки ПО.
5. В госте определены какие документированные свидетельства необходимы для реализации мер по обеспечению безопасности разработки ПО.
Проекты по развитию существующих продуктов
Критичность
Распространение на рынке
Критичность сценариев
Пилотные и исследовательские проекты
Новые продукты
«Агрессивность» среды
Модель угроз/нарушителя
Статистика инцидентов
Подверженность атакам на распространённые заимствованные компоненты
Проекты по развитию существующих продуктов
Критичность
Распространение на рынке
Критичность сценариев
Пилотные и исследовательские проекты
Новые продукты
«Агрессивность» среды
Модель угроз/нарушителя
Статистика инцидентов
Подверженность атакам на распространённые заимствованные компоненты