Исследование безопасности создаваемых информационных систем и разрабатываемых приложений становится распространенной практикой. Безопасники получили наконец заслуженное признание и «включены в цикл» разработки, их вписывают в нормативку, создают базы знаний для хранения результатов исследований. Чего ждут разработчики и владельцы информационных систем от исследователей? Поговорим о задачах, которые предстоит решать, и о качестве исследований, проводимых на регулярной основе.
Внутреннее качество в процедурах информационной безопасностиAlex Babenko
Процедуры информационной безопасности – основные шестерни, приводящие в движение процесса обеспечения информационной безопасности. А корректное выполнение процедур является атрибутов успешности его выполнения. В докладе рассматриваются использование принципа «встроенного качества» при создании и документировании процедур информационной безопасности, построение процессов допускающих только корректное выполнение.
Более подробно - в заметках к слайдам.
Лекция по безопасной разработке приложений защиты информации в РФ. Читается на 4 курсе ФРТК МФТИ. Рассмотрен процесс создания криптографических и технических средств защиты информации.
Исследование безопасности создаваемых информационных систем и разрабатываемых приложений становится распространенной практикой. Безопасники получили наконец заслуженное признание и «включены в цикл» разработки, их вписывают в нормативку, создают базы знаний для хранения результатов исследований. Чего ждут разработчики и владельцы информационных систем от исследователей? Поговорим о задачах, которые предстоит решать, и о качестве исследований, проводимых на регулярной основе.
Внутреннее качество в процедурах информационной безопасностиAlex Babenko
Процедуры информационной безопасности – основные шестерни, приводящие в движение процесса обеспечения информационной безопасности. А корректное выполнение процедур является атрибутов успешности его выполнения. В докладе рассматриваются использование принципа «встроенного качества» при создании и документировании процедур информационной безопасности, построение процессов допускающих только корректное выполнение.
Более подробно - в заметках к слайдам.
Лекция по безопасной разработке приложений защиты информации в РФ. Читается на 4 курсе ФРТК МФТИ. Рассмотрен процесс создания криптографических и технических средств защиты информации.
VII Уральский форум
Информационная безопасность банков
ТЕМАТИЧЕСКОЕ ЗАСЕДАНИЕ № 4
Обеспечение безопасности банковских приложений
на различных этапах жизненного цикла
Качалин Алексей Игоревич, заместитель генерального директора, ГК «Инфотекс»
Источник: http://ural.ib-bank.ru/materials_2015
Внутренняя угроза: выявление и защита с помощью ObserveITBAKOTECH
Несмотря на всю сложность современных систем защиты информации, действия пользователей до сих пор являются самым слабым звеном в системе информационной безопасности компаний. Особенно если эти пользователи обладают повышенными правами доступа в ИТ-системах.
Алексей Иванов. Реализация проектов АСУ ТП электрических подстанций в соотве...Kaspersky
При создании АСУ ТП электрических подстанций заказчики пользуются годами наработанными схемами, шаблонами технических заданий, где учтено все, кроме требований современного законодательства. Вендоры АСУ ТП, в свою очередь, также часто не касаются вопросов информационной безопасности на первоначальных стадиях. Такая ситуация приводит к тому, что конкурс проводится между поставщиками, включающими в свое предложение системы информационной безопасности и поставщиками, игнорирующими данный вопрос на этапе конкурса. Тем не менее, требования всплывают на поздних этапах, когда служба ИБ эксплуатации не принимает объект. Кто виноват и что делать? В своем докладе на этот вопрос отвечает независимый эксперт Алексей Иванов.
Подробнее о конференции: https://kas.pr/kicsconf2021
Построение процесса безопасной разработки - Стачка 2016Valery Boronin
Безопасность - критически важный элемент любого программного решения. Элемент, который, рано или поздно, но заставит вспомнить о себе. Скупой платит дважды, а в данном случае – минимум четырежды. Безопасность и качество кода – связаны напрямую. Поэтому положение дел и с тем и с другим редко находят достаточно хорошим даже в самых успешных проектах – всегда хочется бОльшего. А где-то бывает просто необходим качественный переход и точечными мерами кардинально ситуацию уже не исправить, нужен системный подход.
Вот почему наладить процесс обеспечения и повысить уровень зрелости безопасности разработки, повысить качество кода – хотят многие руководители и разработчики. Как это сделать системно и в согласии? Какие риски для одних, какие трудозатраты для других? И стоит ли овчинка выделки? Об этом и поговорим.
2016/05/10: загружена версия для оффлайна.
Листовка нашего продукта, подготовленная к 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
Данная лекция посвящена исключительно метрикам информационной безопасности, которые представляют собой красивый количественный способ измерить реальную эффективность безопасности на Вашей сетевой инфраструктуре.
Подробно описаны виды метрик ИБ, приведено множество примеров и описано, зачем эти метрики нужны. Примеры практической пользы от их использования.
Подробнее читайте на моём блоге http://inforsec.ru/
DLP 007: три элемента мобильной безопасностиInfoWatch
BYOD или контролируемый периметр? Мобильность сотрудников с возможностью эффективно работать в любое время и в любом месте или защита от утечек конфиденциальных данных через смартфоны и планшеты? Непростой выбор, правда?
Но бизнес и безопасность не терпят компромиссов, а значит новая миссия агента DLP 007 – обеспечить трехстороннюю защиту корпоративных данных в концепции BYOD!
Выступление Валерия Боронина, посвященное внедрению безопасной разработки с точки зрения руководителя, на встрече PDUG Meetup: SSDL for Management 25 ноября 2016 года.
Вычисление, визуализация и анализ метрик защищенности защищенности для монито...Positive Hack Days
Вычисление, визуализация
и анализ метрик защищенности защищенности
для мониторинга мониторинга безопасности безопасности
и управления управления инцидентами инцидентами
в SIEM-системах
VII Уральский форум
Информационная безопасность банков
ТЕМАТИЧЕСКОЕ ЗАСЕДАНИЕ № 4
Обеспечение безопасности банковских приложений
на различных этапах жизненного цикла
Качалин Алексей Игоревич, заместитель генерального директора, ГК «Инфотекс»
Источник: http://ural.ib-bank.ru/materials_2015
Внутренняя угроза: выявление и защита с помощью ObserveITBAKOTECH
Несмотря на всю сложность современных систем защиты информации, действия пользователей до сих пор являются самым слабым звеном в системе информационной безопасности компаний. Особенно если эти пользователи обладают повышенными правами доступа в ИТ-системах.
Алексей Иванов. Реализация проектов АСУ ТП электрических подстанций в соотве...Kaspersky
При создании АСУ ТП электрических подстанций заказчики пользуются годами наработанными схемами, шаблонами технических заданий, где учтено все, кроме требований современного законодательства. Вендоры АСУ ТП, в свою очередь, также часто не касаются вопросов информационной безопасности на первоначальных стадиях. Такая ситуация приводит к тому, что конкурс проводится между поставщиками, включающими в свое предложение системы информационной безопасности и поставщиками, игнорирующими данный вопрос на этапе конкурса. Тем не менее, требования всплывают на поздних этапах, когда служба ИБ эксплуатации не принимает объект. Кто виноват и что делать? В своем докладе на этот вопрос отвечает независимый эксперт Алексей Иванов.
Подробнее о конференции: https://kas.pr/kicsconf2021
Построение процесса безопасной разработки - Стачка 2016Valery Boronin
Безопасность - критически важный элемент любого программного решения. Элемент, который, рано или поздно, но заставит вспомнить о себе. Скупой платит дважды, а в данном случае – минимум четырежды. Безопасность и качество кода – связаны напрямую. Поэтому положение дел и с тем и с другим редко находят достаточно хорошим даже в самых успешных проектах – всегда хочется бОльшего. А где-то бывает просто необходим качественный переход и точечными мерами кардинально ситуацию уже не исправить, нужен системный подход.
Вот почему наладить процесс обеспечения и повысить уровень зрелости безопасности разработки, повысить качество кода – хотят многие руководители и разработчики. Как это сделать системно и в согласии? Какие риски для одних, какие трудозатраты для других? И стоит ли овчинка выделки? Об этом и поговорим.
2016/05/10: загружена версия для оффлайна.
Листовка нашего продукта, подготовленная к 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
Данная лекция посвящена исключительно метрикам информационной безопасности, которые представляют собой красивый количественный способ измерить реальную эффективность безопасности на Вашей сетевой инфраструктуре.
Подробно описаны виды метрик ИБ, приведено множество примеров и описано, зачем эти метрики нужны. Примеры практической пользы от их использования.
Подробнее читайте на моём блоге http://inforsec.ru/
DLP 007: три элемента мобильной безопасностиInfoWatch
BYOD или контролируемый периметр? Мобильность сотрудников с возможностью эффективно работать в любое время и в любом месте или защита от утечек конфиденциальных данных через смартфоны и планшеты? Непростой выбор, правда?
Но бизнес и безопасность не терпят компромиссов, а значит новая миссия агента DLP 007 – обеспечить трехстороннюю защиту корпоративных данных в концепции BYOD!
Выступление Валерия Боронина, посвященное внедрению безопасной разработки с точки зрения руководителя, на встрече PDUG Meetup: SSDL for Management 25 ноября 2016 года.
Вычисление, визуализация и анализ метрик защищенности защищенности для монито...Positive Hack Days
Вычисление, визуализация
и анализ метрик защищенности защищенности
для мониторинга мониторинга безопасности безопасности
и управления управления инцидентами инцидентами
в SIEM-системах
1. ICV Kongres controllera Srbije 2013, Danijela Medić, šef finanasijske anal...Menadžment Centar Beograd
Danijela Medić, šef finansijske analize u Neoplanti, je govorila na temu: "Kako uvesti controlling u kompaniji". Navela je pitanja koja treba postaviti kada uvodite controlling: 1.Kada? 2. Ko? 3. Kako/Šta? 4. Zašto?
Uputila nas je u formulu uvođenja controllinga, navela šta se dobija od controllinga i koliko je značajan.
Many people are afraid of networking as they feel that they are 'selling' when trying to network. Remember that networking is just to develop relationships, it's not to sell to anyone. Learn how to network with confidence to find a job, manage your career and build your business. Whether you are an entrepreneur or a job seeker networking is a must! For more information visit www.janejacksoncoach.com
Павло Розенко: «Пенсійний фонд має не просто пливти за течією, а бути локом...PENSIA.ua
Відомий вислів, що «реформи розпочинаються там, де закінчуються гроші». Мабуть, як ніколи, ця теза актуальна сьогодні для України. Адже ми маємо не лише напівпорожній державний гаманець, а ще й загальну кризу в економіці та військові дії на сході нашої дер-
жави. Одне слово, весь «джентльменський набір», який не просто спонукає, а з космічним прискорен- ням штовхає нас до проведення реформ. І треба сказати, що соціальна сфера нині на шляху рефор- мування не пасе задніх. Тут не лише жваво обговорюють реформи, а й намагаються їх утілювати у життя. Здебільшого, реформи ці непрості і навіть болісні: підвищення тарифів, монетизація пільг, скасування права на vip-пенсії тощо. Зрозуміло, що такі зміни не завжди сприймають у суспільстві з розумінням. Та іншого шляху, аби поліпшити ситуацію, у нас немає. Отож, про те, чому сьогодні немає альтернативи реформам в українській соціальній сфері, «Вісник» говорив із міністром соціальної політики України Павлом РОЗЕНКОМ
В данной своей лекции я рассказываю об основе основ: базовых принципах защиты информации, которые нужно соблюдать всем, а именно принципы:
* Минимальных привиллегий.
* Прозрачности решений.
* Превентивности защиты.
* Системного подхода.
* Непрерывности защиты.
* Доказательности.
* Унификации решений.
Все описанные принципы подробно разбираются на примерах, и мы постепенно приходим к понятию оптимальной защиты. Также в презентации описываются различные уровни зрелости информационной безопасности на предприятии.
Конечно же, в конце, как и следует из названия, приведено описание так называемых метрик информационной безопасности: их виды, способы измерения и примеры.
Подробнее читайте на моём блоке inforsec.ru
Тесты на проникновение как основа реальной оценки состояния ИБ в организацииLETA IT-company
Презентация Ивушкина Андрея, заместителя руководителя направления систем менеджмента компании LETA, проведенная в рамках конференции «Грани ИБ Законодательство, процессы, технологии» 13-15 октября 2011 г. в «Атлас Парк-Отель»
Презентация с вебинара "Спроси эксперта. Все, что вы хотели узнать про «дыры» в коде, но не у кого было спросить"
Ссылка на страницу вебинара (и запись) - http://solarsecurity.ru/analytics/webinars/665/
Инструмент ChangelogBuilder для автоматической подготовки Release NotesPositive Hack Days
1. Основные понятия и определения: продукт, пакет, связи между ними.
2. Как узнать, какие изменения произошли в продукте?
3. Проблемы changelog и release note.
4. Решение: инструмент ChangelogBuilder для автоматической подготовки Release Notes
Как мы собираем проекты в выделенном окружении в Windows DockerPositive Hack Days
1. Обзор Windows Docker (кратко)
2. Как мы построили систему билда приложений в Docker (Visual Studio\Mongo\Posgresql\etc)
3. Примеры Dockerfile (выложенные на github)
4. Отличия процессов DockerWindows от DockerLinux (Долгий билд, баги, remote-регистр.)
Типовая сборка и деплой продуктов в Positive TechnologiesPositive Hack Days
1. Проблемы в построении CI процессов в компании
2. Структура типовой сборки
3. Пример реализации типовой сборки
4. Плюсы и минусы от использования типовой сборки
1. Что такое BI. Зачем он нужен.
2. Что такое Qlik View / Sense
3. Способ интеграции. Как это работает.
4. Метрики, KPI, планирование ресурсов команд, ретроспектива релиза продукта, тренды.
5. Подключение внешних источников данных (Excel, БД СКУД, переговорные комнаты).
Approof — статический анализатор кода для проверки веб-приложений на наличие уязвимых компонентов. В своей работе анализатор основывается на правилах, хранящих сигнатуры искомых компонентов. В докладе рассматривается базовая структура правила для Approof и процесс автоматизации его создания.
Задумывались ли вы когда-нибудь о том, как устроены современные механизмы защиты приложений? Какая теория стоит за реализацией WAF и SAST? Каковы пределы их возможностей? Насколько их можно подвинуть за счет более широкого взгляда на проблематику безопасности приложений?
На мастер-классе будут рассмотрены основные методы и алгоритмы двух основополагающих технологий защиты приложений — межсетевого экранирования уровня приложения и статического анализа кода. На примерах конкретных инструментов с открытым исходным кодом, разработанных специально для этого мастер-класса, будут рассмотрены проблемы, возникающие на пути у разработчиков средств защиты приложений, и возможные пути их решения, а также даны ответы на все упомянутые вопросы.
От экспериментального программирования к промышленному: путь длиной в 10 летPositive Hack Days
Разработка наукоемкого программного обеспечения отличается тем, что нет ни четкой постановки задачи, ни понимания, что получится в результате. Однако даже этом надо программировать то, что надо, и как надо. Докладчик расскажет о том, как ее команда успешно разработала и вывела в промышленную эксплуатацию несколько наукоемких продуктов, пройдя непростой путь от эксперимента, результатом которого был прототип, до промышленных версий, которые успешно продаются как на российском, так и на зарубежном рынках. Этот путь был насыщен сложностями и качественными управленческими решениями, которыми поделится докладчик
Уязвимое Android-приложение: N проверенных способов наступить на граблиPositive Hack Days
Немногие разработчики закладывают безопасность в архитектуру приложения на этапе проектирования. Часто для этого нет ни денег, ни времени. Еще меньше — понимания моделей нарушителя и моделей угроз. Защита приложения выходит на передний план, когда уязвимости начинают стоить денег. К этому времени приложение уже работает и внесение существенных изменений в код становится нелегкой задачей.
К счастью, разработчики тоже люди, и в коде разных приложений можно встретить однотипные недостатки. В докладе речь пойдет об опасных ошибках, которые чаще всего допускают разработчики Android-приложений. Затрагиваются особенности ОС Android, приводятся примеры реальных приложений и уязвимостей в них, описываются способы устранения.
Разработка любого софта так или иначе базируется на требованиях. Полный перечень составляют бизнес-цели приложения, различные ограничения и ожидания по качеству (их еще называют NFR). Требования к безопасности ПО относятся к последнему пункту. В ходе доклада будут рассматриваться появление этих требований, управление ими и выбор наиболее важных.
Отдельно будут освещены принципы построения архитектуры приложения, при наличии таких требований и без, и продемонстрировано, как современные (и хорошо известные) подходы к проектированию приложения помогают лучше строить архитектуру приложения для минимизации ландшафта угроз.
Доклад посвящен разработке корректного программного обеспечения с применением одного из видов статического анализа кода. Будут освещены вопросы применения подобных методов, их слабые стороны и ограничения, а также рассмотрены результаты, которые они могут дать. На конкретных примерах будет продемонстрировано, как выглядят разработка спецификаций для кода на языке Си и доказательство соответствия кода спецификациям.
5. Сколько можно исследовать ИБ?
0
5
10
15
20
25
30
35
2011 2012 2013 2014
ПРИМЕРНО ЛЮБОЙ ОТЧЕТ О
ПЕРИОДИЧЕСКОМ АНАЛИЗЕ ИБ
Критических уязвимостей Найдено новых Закрыто уязвимостей
8. О себе/О нас
О себе:
Занимаюсь исследованиями и
разработкой в ИБ
ЗАО «ПМ»
Аналитический и
инструментальный анализ ПО и
ИС
С 2012 года – работаем по
направлению повышения
безопасности разработки
В 2014 запустили ЦМ
Принимаем участие в работе с
регуляторами ИБ
9. О чём речь?
Наш опыт проведения работ по взлому
повышению защищённости разработки
Проблемы интеграции исследований ИБ в
цикл работ по созданию и обслуживанию
ПО/ИС
Дополнительные процессы и системы,
полезные в нашей борьбе
10. ИБ-портрет: Разработчик (СЗИ)
Компания – актуальны все угрозы для
организаций и сотрудников
Отрасль ИБ – активно вовлечен в
противоборство ИБ
Клиенты – информация о СЗИ, доступ,
доверие
Продукт – системный, инфраструктурный
компонент ИС
11. Жизненный цикл разработки ПО*: где ИБ?
03.06.2015 11
Проектирование
Требования
Разработка
Тестирование
Выпуск
Эксплуатация
Сертификация
Вывод из эксплуатации
*Аналогичная ситуация с
• Итеративными моделями разработки
• Моделью непрерывного размещения
12. Безопасная разработка продукта
Мониторинг и реагирование
Проверка и выпуск продукта
Разработка
Проектирование
Требования
Подготовка и обучение
разработчиков
Внедрение практик
разработки
13. Что «вкусного» есть в ИС разработчика?
Системы учёта ошибок и улучшений
Системы версионного хранения кода
Системы хранения жалоб потребителей
Системы подготовки обновлений
------------------------------------------------------
Идеально для инжинерии атак
14. Можно грабить караваныTM
Подключение к сетям заказчиков
Тестовые устройства на периметре
Необходимость загружать и тестировать
недоверенное ПО
Организация методов
обновления Продукта
Продукт в конце концов
15. Разработчик СЗИ – интересная мишень
Интересны для атакующих «высоких классов»,
воспринимаются как активные участники
государственной политики, представители интересов
государства
Продукт : Исходники и собранное ПО для
исследования, алгоритмы
Технологические мощности: сборочные сервера -
возможность злоумышленнику собрать свою
«подлинную» версию СЗИ, сетевые и серверные
мощности
Эксплуатация доверия - Рассылка писем/переписка
от имени доверенной организации, люди –
сотрудники, внешние контакты
База установки Продукта: Контрактная
документация, Сервисные подразделения
17. Развитие мониторинга и реагирования
Технический анализ (состояние узлов, трафик, журналы)
Обнаружить публикацию информации об уязвимости
Публикация информации об уязвимости в компоненте/продукте
Сети обмена информацией об уязвимостях
Получить и интерпретировать обращения пользователей
Сообщения о «странном поведении программы» (нет явного
подозрения на проблемы ИБ)
Попытки шантажа и ультиматумы, оскорбления и троллинг
Готовый метод компрометации ИБ (пошаговый, в виде PoCE)
Внутренние сообщение от разработчика – обратить внимание
Указания на строчку кода
Развёрнутый анализ с обоснованием неизбежности уязвимости
18. Тестирование и тестирование
Анализ ИБ – безусловно один из видов
тестирования продуктов
Свои методики и тест-планы
Автоматизация
Инструментарий
(инструкции)
Работающий вариант: разработка автотестов
для передачи в отдел тестирования
19. Ловушки для исследователя
Не читать документацию
Переписать документацию
Не согласовывать цели/прогресс с
заказчиком
Не осознать зоны ответственности
заинтересованных лиц
…
20.
21. Готовы ли разработчики?
Выбор инструментов и компонентов
Удобство среды разработки
Использование знакомых компонентов
Борьба с унаследованным кодом
«Безопасное программирование» это достаточное ИБ?
Утечки памяти, переполнение буфера, падения/повисания
Безопасные опции компилятора
Инструменты те же, а сценарии нет
Практики управления
Менеджер форсирует: бюджет, сроки, функционал
23. Безопасная разработка продукта
Мониторинг и реагирование
Проверка и выпуск продукта
Разработка
Проектирование
Требования
Подготовка и обучение
разработчиков
Внедрение практик
разработки
26. Условия внедрения безопасной разработки
Осязаемые результаты: отдача от инвестиций в безопасность
Возврат инвестиций
ПО финансовых, подверженных фроду систем – возможно
Снижение количества инцидентов и уязвимостей
Снижение «стоимости» уязвимости
Оперативность реагирования на инциденты
Встраивание в существующий процесс разработки (заказа и
эксплуатации ПО)
Существующие продукты и компоненты
Вовлечение команды (мотивация исполнителя и
легитимизация затрат) на дополнительные практики ИБ
26
28. Вот и договоритесь о приоритетах
Проекты разработки
Продукты
Клиентские проекты
29. Безопасность 2.0
Необходимая скорость реакции
Сократить окно уязвимости (Window of Vulnerability)
Локализовать и ограничить инцидент
Выявить первопричину уязвимости (ошибку)
Разработать исправление
Не позволяющее «обойти» себя
Или атаковать аналогичную уязвимость
Надежно устранить уязвимости, «не вернуть» ошибку в
будущем
30. Что блокирует внедрение исследований ИБ
Слабая прогнозируемость по срокам
Непредсказуемость по результатам
Отсутствие гарантий полноты исследований
Отсутствие сходимости исследований
Проблема повторных исследований
Потребность: непрерывный адаптируемый
процесс с управляемыми характеристиками
31. Цикл Безопасной Разработки
Свод Знаний
Домены (Разделы) практик
Мониторинг и реагирование
Проверка и выпуск продукта
Разработка
Проектирование
Требования
Сторонние компоненты
Соответствие требованиям регуляторов
Инструменты и системы разработки
Подготовка команды
32. Безопасность – командный вид спорта?
Менеджер продукта
Руководитель разработки
Аналитик
Архитектор
Программист
Тестировщик
Специалист сопровождения
Хакер
Хакер
Хакер
Хакер
Хакер
Хакер
Хакер
33. Осознать «свои» слабости
33
The CVE Identifier CVE-2014-0160 was released on April 7,
2014—the same day the Heartbleed bug was made public.
This type of weakness is described in detail by CWE-130: Improper
Handling of Length Parameter Inconsistency. The second weakness is an
out-of-bounds memory read, which is described inCWE-125: Out-of-
Bounds Read. These CWEs were first defined more than eight years ago
CAPEC-540: Overread Buffers defines the general pattern commonly
used by an attacker including how the attack is crafted, its potential
severity and consequences
35. Выстроить чтобы ломать
Исследователи и программисты
Инструменты и методика
База знаний и терминология (язык общения)
Автоматизация консистентных процессов
Процесс безопасной разработки
Средства и процесс мониторинга
36. Начать с того что имеете
Использовать доступное
Делать возможное
Качалин Алексей
Директор ЗАО «ПМ»
@kchln
Kachalin@advancedmonitoring.ru
Editor's Notes
"Ломать и строить, и снова ломать"
Исследование информационной безопасности создаваемых информационных систем и разрабатываемых приложений стало достаточно распространенной практикой. Специалисты по практической безопасности получили заслуженное признание и "включены в цикл" разработки, их "вписывают" в нормативку, создают базы знаний для хранения результатов исследований уязвимостей. Обсудим ожидания разработчиков и владельцев информационных систем от работ исследователей, задачи, которые предстоит решать, аспекты качества исследований, проводимых на регулярной основе.
Недовольны вендорами
Недоволен регулятор
Априорная безопасность не тру
Все не довольны
Пиджак/футболка – кому какое дело – была бы работа сделана
В широком смысле – т.е. по всем аспектам ИБ для п.п. выше
Модель зрелости должна быть
Подходящая этапность внедрения?
Домены
Можно суммировать и расширить
Готовые методы, инструменты, классификации
Моделирование угроз, трассировка уязвимостей для оценки ущерба
Проекты по развитию существующих продуктов
Критичность
Распространение на рынке
Критичность сценариев
Пилотные и исследовательские проекты
Новые продукты
«Агрессивность» среды
Модель угроз/нарушителя
Статистика инцидентов
Подверженность атакам на распространённые заимствованные компоненты
Проекты по развитию существующих продуктов
Критичность
Распространение в организации
Критичность сценариев
«Агрессивность» среды
Подверженность атакам на распространённые заимствованные компоненты
Возможность доступа для анализа
Компактность системы
Скорость изменения
Новые продукты
Пилотные и исследовательские проекты
Все проекты со значимыми угрозами
Cybersecurity
Security Standards Help Stop Heartbleed
May 7, 2014Software Assurance: Post by Drew Buttner
PRINT
The Heartbleed bug (CVE-2014-0160) is a critical vulnerability that first came to the attention of the public in early April and has been making headlines ever since. The vulnerability exists in certain versions of OpenSSL where it enables remote attackers to obtain sensitive information, such as passwords and encryption keys. Many popular websites have been affected or are at risk, which in turn, puts countless users and consumers at risk.
Cybersecurity experts have mounted an aggressive and multi-faceted global response to Heartbleed, and security automation standards have played an important role in this effort. These standards were created to categorize and share information about system vulnerabilities and attacks to help the security community communicate consistently. Having a common language helps in understanding these issues and determining appropriate mitigation strategies. Effective communication about bugs also helps developers prevent them from reappearing in other applications. Specifically, these three security automation standards have been particularly helpful in dealing with Heartbleed:
Common Vulnerabilities and Exposures (CVE®) provides unique identifiers for known information security vulnerabilities. CVE enables the fast, efficient, and effective correlation and sharing of information related to critical and time sensitive vulnerability.
Common Weakness Enumeration (CWE™) provides an index of different types of software code weaknesses and serves as an information repository for the types of security problems found in a software application’s architecture, design, code, and setup. CWE helps developers prevent these mistakes from being repeated.
Common Attack Pattern Enumeration and Classification (CAPEC™) is a publicly available catalogue of common attack patterns, along with a classification taxonomy that identifies relationships among attack patterns. An attack pattern is an abstraction mechanism for describing how an attack is executed. Many successful attacks are conducted in multiple, discrete, identifiable steps.
CVE and Heartbleed
The CVE Identifier CVE-2014-0160 was released on April 7, 2014—the same day the Heartbleed bug was made public. The existence of this identifier has enabled the worldwide community to converse and share information about this bug at an astonishingly rapid pace. The CVE Identifier (ID) quickly became so ubiquitous (with more than 100,000 lookups in the first few days alone) that simply entering its name into any search engine resulted in thousands of hits and a range of useful information including the official OpenSSL Security Advisory, major application vendors, details from industry experts, and guidance from security organizations. All of these search results underscores the main purpose of CVE: to allow people to correlate information.
For example, using the CVE identifier in a search engine could lead system administrators to the blog post at Fox-It with information on how to test for the Heartbleed vulnerability and what to do if it they find it. The CVE identifier could also further help system administrators ensure that they are using the appropriate security tools and vendor patches to address the issue.
Without CVE, there would likely be a surfeit of proprietary and non-standard names—such as Heartbleed, Heartbeat, and SOL15159—making it difficult to track down critical information in a timely manner. For example, the official OpenSSL Security Advisory doesn't even mention the term “Heartbleed.”
CWE and Heartbleed
The Heartbleed bug exists because of two separate mistakes in the code. The first is an inconsistency between the stated length of the message body and its actual length. This type of weakness is described in detail by CWE-130: Improper Handling of Length Parameter Inconsistency. The second weakness is an out-of-bounds memory read, which is described inCWE-125: Out-of-Bounds Read. These CWEs were first defined more than eight years ago and both provide information about the respective problem—how to detect it, why it occurs, how to fix it, and how to prevent it from happening again.
In the case of Heartbleed, developers could use CWE to quickly determine if they have the types of code analysis tools needed to ferret out these types of mistakes. Many tools can check for instances of CWE-125.
CWE also helps developers know why Heartbleed occurred and how to avoid this type of mistake in future development. Without CWE, developers would be forced to perform hours of research to understand the root of the issue and how to correct it in their code. If you don't want your software to have the same issue as Heartbleed, ask your vendors about these weaknesses and educate your developers about CWE-130 and CWE-125.
CAPEC and Heartbleed
To prevent future attacks, security professionals need to know how an attacker thinks and operates. CAPEC helps expose the attacker mindset by shedding light on how a particular vulnerability has been exploited to launch an attack. Without CAPEC, organizations are likely to be stuck in a reactionary mode, addressing known vulnerabilities, while being blind-sided when the next "Heartbleed" arrives.
Software designers, testers, and assessment teams can use CAPEC to sleuth out the next piece of software that might be similarly susceptible and eliminate it as a target. They can also look for the underlying weaknesses that make such attacks possible. CAPEC-540: Overread Buffersdefines the general pattern commonly used by an attacker including how the attack is crafted, its potential severity and consequences, as well as possible solutions and mitigating factors. CAPEC continually adds new attack patterns, such as the specific pattern used in Heartbleed, so be sure to visit the website for updates.
Future Heartbleeds
Security automation efforts such as CVE, CWE, and CAPEC can help reduce the possibility of similar severe vulnerabilities such as Heartbleed in the future. But it is incumbent upon developers and other security professionals to actively leverage resources such as these to be better prepared for the next Heartbleed.
About Drew Buttner
Drew Buttner leads a software assurance group at MITRE specializing in secure code review. He has worked on improving application security for both MITRE and its customers since joining the organization in 2001. An expert in the field of source code weaknesses, Drew is also involved in a number of research efforts related to secure software development and