Внутреннее качество в процедурах информационной безопасностиAlex Babenko
Процедуры информационной безопасности – основные шестерни, приводящие в движение процесса обеспечения информационной безопасности. А корректное выполнение процедур является атрибутов успешности его выполнения. В докладе рассматриваются использование принципа «встроенного качества» при создании и документировании процедур информационной безопасности, построение процессов допускающих только корректное выполнение.
Более подробно - в заметках к слайдам.
Внутреннее качество в процедурах информационной безопасностиAlex Babenko
Процедуры информационной безопасности – основные шестерни, приводящие в движение процесса обеспечения информационной безопасности. А корректное выполнение процедур является атрибутов успешности его выполнения. В докладе рассматриваются использование принципа «встроенного качества» при создании и документировании процедур информационной безопасности, построение процессов допускающих только корректное выполнение.
Более подробно - в заметках к слайдам.
Выступление Валерия Боронина, посвященное внедрению безопасной разработки с точки зрения руководителя, на встрече PDUG Meetup: SSDL for Management 25 ноября 2016 года.
VII Уральский форум
Информационная безопасность банков
ТЕМАТИЧЕСКОЕ ЗАСЕДАНИЕ № 4
Обеспечение безопасности банковских приложений
на различных этапах жизненного цикла
Качалин Алексей Игоревич, заместитель генерального директора, ГК «Инфотекс»
Источник: http://ural.ib-bank.ru/materials_2015
Построение процесса безопасной разработки - Стачка 2016Valery Boronin
Безопасность - критически важный элемент любого программного решения. Элемент, который, рано или поздно, но заставит вспомнить о себе. Скупой платит дважды, а в данном случае – минимум четырежды. Безопасность и качество кода – связаны напрямую. Поэтому положение дел и с тем и с другим редко находят достаточно хорошим даже в самых успешных проектах – всегда хочется бОльшего. А где-то бывает просто необходим качественный переход и точечными мерами кардинально ситуацию уже не исправить, нужен системный подход.
Вот почему наладить процесс обеспечения и повысить уровень зрелости безопасности разработки, повысить качество кода – хотят многие руководители и разработчики. Как это сделать системно и в согласии? Какие риски для одних, какие трудозатраты для других? И стоит ли овчинка выделки? Об этом и поговорим.
2016/05/10: загружена версия для оффлайна.
Лекция по безопасной разработке приложений защиты информации в РФ. Читается на 4 курсе ФРТК МФТИ. Рассмотрен процесс создания криптографических и технических средств защиты информации.
Исследование безопасности создаваемых информационных систем и разрабатываемых приложений становится распространенной практикой. Безопасники получили наконец заслуженное признание и «включены в цикл» разработки, их вписывают в нормативку, создают базы знаний для хранения результатов исследований. Чего ждут разработчики и владельцы информационных систем от исследователей? Поговорим о задачах, которые предстоит решать, и о качестве исследований, проводимых на регулярной основе.
SSDL для руководителей: как перевести команду на безопасную разработку и не выстрелить себе в ногу.
25 ноября в Технологическом центре Microsoft состоится PDUG Meetup: SSDL for Management — встреча для руководителей R&D- и ИБ-подразделений, управляющих крупными проектами и командами разработки
https://habrahabr.ru/company/pt/blog/315840/
--
Дополнительно: www.slideshare.net/ValeryBoronin/2016-61855208
Сделать безопасно и сертифицировано — ЗАО «ПМ» на DevCon 2015Maxim Avdyunin
Сертификация приложений по требованиям федеральных и отраслевых регуляторов, требованиям компаний (если они есть) — необходимое условие разработки и поставки коробочного решения. Требования потребителей и пользователей современных технологий по функционалу и удобству развиваются значительно быстрее эволюции ограничений. В результате, исследования практической защищенности, если и рассматриваются, то вне темы сертификации, что порождает двойной объем работ и сложности в управлении проектами.
Презентация, подготовленная сотрудниками компании «Перспективный Мониторинг» для конференции DevCon 2015, содержит информацию о том, какие практики безопасной разработки позволяют удовлетворить как требования сертификации, так и потребности практической безопасности. Рассматриваются тонкие моменты на стыке этих задач, вопросы, в которых можно опереться на мировой опыт, а также планы регуляторов по развитию требований сертификации.
В докладе представлен опыт ЗАО «ПМ» по внедрению безопасной разработки в проекты создания и развития линейки средств защиты информации для сетевого оборудования, мобильных платформ и рабочих станций, подлежащих сертификации по требованиям регуляторов.
Листовка нашего продукта, подготовленная к 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
Выступление Валерия Боронина, посвященное внедрению безопасной разработки с точки зрения руководителя, на встрече PDUG Meetup: SSDL for Management 25 ноября 2016 года.
VII Уральский форум
Информационная безопасность банков
ТЕМАТИЧЕСКОЕ ЗАСЕДАНИЕ № 4
Обеспечение безопасности банковских приложений
на различных этапах жизненного цикла
Качалин Алексей Игоревич, заместитель генерального директора, ГК «Инфотекс»
Источник: http://ural.ib-bank.ru/materials_2015
Построение процесса безопасной разработки - Стачка 2016Valery Boronin
Безопасность - критически важный элемент любого программного решения. Элемент, который, рано или поздно, но заставит вспомнить о себе. Скупой платит дважды, а в данном случае – минимум четырежды. Безопасность и качество кода – связаны напрямую. Поэтому положение дел и с тем и с другим редко находят достаточно хорошим даже в самых успешных проектах – всегда хочется бОльшего. А где-то бывает просто необходим качественный переход и точечными мерами кардинально ситуацию уже не исправить, нужен системный подход.
Вот почему наладить процесс обеспечения и повысить уровень зрелости безопасности разработки, повысить качество кода – хотят многие руководители и разработчики. Как это сделать системно и в согласии? Какие риски для одних, какие трудозатраты для других? И стоит ли овчинка выделки? Об этом и поговорим.
2016/05/10: загружена версия для оффлайна.
Лекция по безопасной разработке приложений защиты информации в РФ. Читается на 4 курсе ФРТК МФТИ. Рассмотрен процесс создания криптографических и технических средств защиты информации.
Исследование безопасности создаваемых информационных систем и разрабатываемых приложений становится распространенной практикой. Безопасники получили наконец заслуженное признание и «включены в цикл» разработки, их вписывают в нормативку, создают базы знаний для хранения результатов исследований. Чего ждут разработчики и владельцы информационных систем от исследователей? Поговорим о задачах, которые предстоит решать, и о качестве исследований, проводимых на регулярной основе.
SSDL для руководителей: как перевести команду на безопасную разработку и не выстрелить себе в ногу.
25 ноября в Технологическом центре Microsoft состоится PDUG Meetup: SSDL for Management — встреча для руководителей R&D- и ИБ-подразделений, управляющих крупными проектами и командами разработки
https://habrahabr.ru/company/pt/blog/315840/
--
Дополнительно: www.slideshare.net/ValeryBoronin/2016-61855208
Сделать безопасно и сертифицировано — ЗАО «ПМ» на DevCon 2015Maxim Avdyunin
Сертификация приложений по требованиям федеральных и отраслевых регуляторов, требованиям компаний (если они есть) — необходимое условие разработки и поставки коробочного решения. Требования потребителей и пользователей современных технологий по функционалу и удобству развиваются значительно быстрее эволюции ограничений. В результате, исследования практической защищенности, если и рассматриваются, то вне темы сертификации, что порождает двойной объем работ и сложности в управлении проектами.
Презентация, подготовленная сотрудниками компании «Перспективный Мониторинг» для конференции DevCon 2015, содержит информацию о том, какие практики безопасной разработки позволяют удовлетворить как требования сертификации, так и потребности практической безопасности. Рассматриваются тонкие моменты на стыке этих задач, вопросы, в которых можно опереться на мировой опыт, а также планы регуляторов по развитию требований сертификации.
В докладе представлен опыт ЗАО «ПМ» по внедрению безопасной разработки в проекты создания и развития линейки средств защиты информации для сетевого оборудования, мобильных платформ и рабочих станций, подлежащих сертификации по требованиям регуляторов.
Листовка нашего продукта, подготовленная к 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
SIEM - мониторинг безопасности в Вашей компанииSoftline
Единая консоль, где аккумулируется информация о событиях информационной безопасности
компании, что дает возможность получить полную картину уровня ИБ защищенности, сопоставлять
события и реагировать на них максимально быстро,
поддерживать соответствие состояния информационной безопасности внутренним
регламентам и внешним стандартам,
таким как PCI DDS, SOX и т. д.
Услуги и решения Softline в области информационной безопасности. Прикладные и инфраструктурные решения. Соответствие требованиям (compliance). Сетевая безопасность. Аудит информационной безопасности.
Созданный компанией КРОК аутентификационный центр предназначен для унификации процессов аутентификации фронтальных прикладных систем дистанционного обслуживания клиентов крупного банка.
Цели и задачи проекта:
- значительное повышение защищенности операционной деятельности клиентов от мошеннических угроз и рисков, связанных с хищением их идентификационных данных;
- снижение издержек на разбор конфликтных ситуаций, связанных с операциями клиентов;
- получение конкурентных преимуществ;
- уменьшение затрат на администрирование технических средств, участвующих в процессе аутентификации клиентов банка в системах дистанционного обслуживания;
- ликвидация функциональной нагрузки на приложения банка, связанной с аутентификацией клиентов и подтверждением операционной деятельности.
1. Конференция «Разработка ПО 2011»
CEE-SECR 2011.
Центр Digital October, Москва, 31 октября – 3 ноября.
Безопасность и сертификация
банковского ПО: две стороны
одной медали
Алексей Бабенко
старший аудитор, PA-QSA, PCI QSA
3. Актуальность проблемы:
что интересует злоумышленника?
2 % 2%
3%
8%
Данные платежных карт
Служебная информация
Коммерческая тайна
Данные аутентификации
85% Персональные данные
По данным Global Security Report 2011, Trustwave
4. Актуальность проблемы:
нас это не касается?
Вырезка из Global Security Report 2011, Trustwave
13. Особенности банковских систем
Тип ПО: Клиент. Корп.
Практически неограниченный доступ к
системе из сети Интернет
Работа с платежной информацией
Большое и динамично меняющееся
количество пользователей
Ориентировка на любой уровень ИБ-
грамотности пользователя
Собственные разработки без учета
практик безопасного программирования
ТОП менеджеры, на которых не
распространяются политики безопасности
14. Риски банков
при компрометации ПО
• Прямые финансовые потери;
• Уменьшение клиентской базы,
снижение уровня доверия
клиентов;
• Отказ клиентов от
использования сервисов;
• Нарушение требований и
штрафы от регуляторов;
• Ухудшение имиджа банка.
16. Основные процессы обеспечения
безопасности ПО
• Процесс безопасного
программирования,
тестирования и анализа кода;
• Проверки с использованием
автоматизированных
средств, «ручные» проверки;
• Процесс обеспечения ИБ для
окружения приложений,
разработка необходимых
инструкций
17. Аудит безопасности ПО
Анализ уровня Формирование Устранение Контроль
безопасности плана несоответствий исправления
системы найденных
уязвимостей
— техническая документация, схемы сети
— исходные коды
— конфигурации системных компонентов
— тестовый доступ
19. PA-DSS: краткая информация
• Основная цель – поддержка реализации PCI DSS
• Дата рождения: апрель 2008
• Разработчик – PCI Security Standards Council
• Ориентирован на разработчиков платежных
приложений
• Форма подтверждения соответствия –
сертификация
• Требование к сертифицирующей компании – статус
PA-QSA
• Актуальная версия – 2.0
20. PA-DSS: что сертифицировать?
• ПО подлежит сертификации, если:
– Обрабатывает номера карт (PAN) в рамках
авторизации/расчетов;
– Разрабатывается на продажу, не является разовой заказной
разработкой.
• Основные виды сертифицируемого ПО:
– ПО процессинга (front-office, back-office (расчеты),
middleware/switching);
– ПО для банкоматов;
– ПО для POS-терминалов;
– ПО для поддержки электронной коммерции;
– ПО мобильной коммерции.
21. PA-DSS: требования стандарта
Сертифицируемое приложение Компания-разработчик
Исключение хранения Формализация процесса
критичных данных карт (TRACK, разработки с учетом вопросов
CVC2/CVV2, PIN/PIN-BLOCK); ИБ;
Безопасное хранение и Практики безопасного
передача номеров платежных программирования;
карт; Тестирование приложения;
Контроль доступа и Анализ кода;
протоколирование событий;
Мониторинг уязвимостей
платформ и тестирование
совместимости с патчами;
Возможность встраивания в PCI Руководство по выполнению
DSS Compliant инфраструктуру. требований стандарта PA-DSS.
22. PA-DSS: истории успеха
• Три программных обеспечения, сертифицированных
ЗАО НИП «Информзащита», получили статус PA-DSS
• Новые сертификации уже на подходе.