VII Уральский форум
Информационная безопасность банков
ТЕМАТИЧЕСКОЕ ЗАСЕДАНИЕ № 4
Обеспечение безопасности банковских приложений
на различных этапах жизненного цикла
Качалин Алексей Игоревич, заместитель генерального директора, ГК «Инфотекс»
Источник: http://ural.ib-bank.ru/materials_2015
Внутреннее качество в процедурах информационной безопасностиAlex Babenko
Процедуры информационной безопасности – основные шестерни, приводящие в движение процесса обеспечения информационной безопасности. А корректное выполнение процедур является атрибутов успешности его выполнения. В докладе рассматриваются использование принципа «встроенного качества» при создании и документировании процедур информационной безопасности, построение процессов допускающих только корректное выполнение.
Более подробно - в заметках к слайдам.
VII Уральский форум
Информационная безопасность банков
ТЕМАТИЧЕСКОЕ ЗАСЕДАНИЕ № 4
Обеспечение безопасности банковских приложений
на различных этапах жизненного цикла
Качалин Алексей Игоревич, заместитель генерального директора, ГК «Инфотекс»
Источник: http://ural.ib-bank.ru/materials_2015
Внутреннее качество в процедурах информационной безопасностиAlex Babenko
Процедуры информационной безопасности – основные шестерни, приводящие в движение процесса обеспечения информационной безопасности. А корректное выполнение процедур является атрибутов успешности его выполнения. В докладе рассматриваются использование принципа «встроенного качества» при создании и документировании процедур информационной безопасности, построение процессов допускающих только корректное выполнение.
Более подробно - в заметках к слайдам.
Лекция по безопасной разработке приложений защиты информации в РФ. Читается на 4 курсе ФРТК МФТИ. Рассмотрен процесс создания криптографических и технических средств защиты информации.
VII Уральский форум
Информационная безопасность банков
ТЕМАТИЧЕСКОЕ ЗАСЕДАНИЕ № 1
Банковский фрод
Шумский Лев Станиславович, начальник Управления информационной безопасности, Связной Банк
Источник: http://ural.ib-bank.ru/materials_2015
Разработка любого софта так или иначе базируется на требованиях. Полный перечень составляют бизнес-цели приложения, различные ограничения и ожидания по качеству (их еще называют NFR). Требования к безопасности ПО относятся к последнему пункту. В ходе доклада будут рассматриваться появление этих требований, управление ими и выбор наиболее важных.
Отдельно будут освещены принципы построения архитектуры приложения, при наличии таких требований и без, и продемонстрировано, как современные (и хорошо известные) подходы к проектированию приложения помогают лучше строить архитектуру приложения для минимизации ландшафта угроз.
Об угрозах информационной безопасности, актуальных для разработчика СЗИSelectedPresentations
Качалин Алексей Игоревич, эксперт МОО «АЗИ»
IV Форум АЗИ
«Актуальные вопросы информационной безопасности России»
г. Москва, Конгресс-Центр МТУСИ, 14 апреля 2015 года
VII Уральский форум
Информационная безопасность банков
ТЕМАТИЧЕСКОЕ ЗАСЕДАНИЕ № 4
Обеспечение безопасности банковских приложений
на различных этапах жизненного цикла
Никитин Андрей Владимирович, заместитель директора департамента контроля информации, Банк СИАБ
Источник: http://ural.ib-bank.ru/materials_2015
Целевое управление доступом в сети. Техническое решение для финансовых органи...SelectedPresentations
VII Уральский форум
Информационная безопасность банков
ТЕМАТИЧЕСКОЕ ЗАСЕДАНИЕ № 2
Электронное взаимодействие на финансовых рынках
Кушнарев Александр Николаевич, технический консультант по решениям ИБ, Netwell
Источник: http://ural.ib-bank.ru/materials_2015
Лекция по безопасной разработке приложений защиты информации в РФ. Читается на 4 курсе ФРТК МФТИ. Рассмотрен процесс создания криптографических и технических средств защиты информации.
VII Уральский форум
Информационная безопасность банков
ТЕМАТИЧЕСКОЕ ЗАСЕДАНИЕ № 1
Банковский фрод
Шумский Лев Станиславович, начальник Управления информационной безопасности, Связной Банк
Источник: http://ural.ib-bank.ru/materials_2015
Разработка любого софта так или иначе базируется на требованиях. Полный перечень составляют бизнес-цели приложения, различные ограничения и ожидания по качеству (их еще называют NFR). Требования к безопасности ПО относятся к последнему пункту. В ходе доклада будут рассматриваться появление этих требований, управление ими и выбор наиболее важных.
Отдельно будут освещены принципы построения архитектуры приложения, при наличии таких требований и без, и продемонстрировано, как современные (и хорошо известные) подходы к проектированию приложения помогают лучше строить архитектуру приложения для минимизации ландшафта угроз.
Об угрозах информационной безопасности, актуальных для разработчика СЗИSelectedPresentations
Качалин Алексей Игоревич, эксперт МОО «АЗИ»
IV Форум АЗИ
«Актуальные вопросы информационной безопасности России»
г. Москва, Конгресс-Центр МТУСИ, 14 апреля 2015 года
VII Уральский форум
Информационная безопасность банков
ТЕМАТИЧЕСКОЕ ЗАСЕДАНИЕ № 4
Обеспечение безопасности банковских приложений
на различных этапах жизненного цикла
Никитин Андрей Владимирович, заместитель директора департамента контроля информации, Банк СИАБ
Источник: http://ural.ib-bank.ru/materials_2015
Целевое управление доступом в сети. Техническое решение для финансовых органи...SelectedPresentations
VII Уральский форум
Информационная безопасность банков
ТЕМАТИЧЕСКОЕ ЗАСЕДАНИЕ № 2
Электронное взаимодействие на финансовых рынках
Кушнарев Александр Николаевич, технический консультант по решениям ИБ, Netwell
Источник: http://ural.ib-bank.ru/materials_2015
Построение процесса безопасной разработки - Стачка 2016Valery Boronin
Безопасность - критически важный элемент любого программного решения. Элемент, который, рано или поздно, но заставит вспомнить о себе. Скупой платит дважды, а в данном случае – минимум четырежды. Безопасность и качество кода – связаны напрямую. Поэтому положение дел и с тем и с другим редко находят достаточно хорошим даже в самых успешных проектах – всегда хочется бОльшего. А где-то бывает просто необходим качественный переход и точечными мерами кардинально ситуацию уже не исправить, нужен системный подход.
Вот почему наладить процесс обеспечения и повысить уровень зрелости безопасности разработки, повысить качество кода – хотят многие руководители и разработчики. Как это сделать системно и в согласии? Какие риски для одних, какие трудозатраты для других? И стоит ли овчинка выделки? Об этом и поговорим.
2016/05/10: загружена версия для оффлайна.
Talk about how to design code that helps one to avoid some of the issues identified on OWASP top 10. Domain Driven Security is one of the main tools to achieve this.
Berezha Security was founded in 2014 and provides penetration testing services. Penetration test (pentest) - is a controlled simulation of a real hacker attack which reveals the real state of organization's information security and its ability to withstand an attack with minimal losses.
Berezha Security was established by the most experienced Ukrainian experts in the field of information security. In our work we use only reliable, proven methodologies and tools, some of which we created ourselves. Due to our own developments and vast experience we were able to significantly reduce the cost of our work and offer our customers high quality services for a perfectly balanced price, which is easy to calculate using the price calculator that is publicly available on the Berezha Security website.
Secure code review is probably the most effective technique to identify security bugs early in the system development lifecycle.
When used together with automated and manual penetration testing, code review can significantly increase the cost effectiveness of an application security verification effort. This presentation explain how can we start secure code review effectively.
Практические особенности внедрения систем класса DLPDialogueScience
В рамках вебинара "Практические особенности внедрения систем класса DLP" вы узнаете:
- цели и задачи, которые заказчик обычно ставит перед DLP, его ожидания;
- часто допускаемые ошибки;
- цели проекта по внедрению DLP;
- этапы проекта по внедрению DLP;
- описание этапов проекта;
- каких ошибок удается избежать при правильном подходе;
- преимущества и недостатки;
- ответы на вопросы.
Спикер: Роман Ванерке, руководитель отдела технических решений АО «ДиалогНаука»
На вебинаре участники ознакомились с актуальными проблемами, связанными с реализацией задач по сбору, анализу и корреляции событий информационной безопасности, регистрируемых в территориально-распределенных автоматизированных системах предприятий.
В рамках мероприятия были рассмотрены основные преимущества использования систем мониторинга, позволяющие повысить эффективность принятия решений по реагированию на инциденты безопасности
и также рассмотрена одна из возможных реализаций центра мониторинга событий безопасности (Security Operation Center, SOC) на базе программных продуктов HP ArcSight.
Мониторинг событий информационной безопасности на базе решений HP ArcSight ES...DialogueScience
Рассматриваются основные преимущества использования систем мониторинга, позволяющие повысить эффективность принятия решений по реагированию на инциденты безопасности.
Спикер:
Родион Чехарин,
Руководитель проекта технического департамента ЗАО «ДиалогНаука»
TК°Conf. Организация разработки Frontend. Виталий Слободин.TKConf
Расскажу об организации процесса разработки Frontend в единый конвейер, чтобы увеличить скорость и минимизировать затраты с рисками.
Как организовать верстку макета по фантастичному макету дизайнера при этом не вогнав в когнитивный диссонанс результатом на Bootstrap.
Каким образом объединить воинствующие стороны: Frontend, Backend и дизайнеров.
Exhibit your support to the Cyber Security community
Grow your employer brand at a high demand job market Increase user base of your professional products and services Extend your professional social network
Meet new partners and old friends
Find new business opportunities
Increase your brand visibility
Showcase your expertise
Share your experience
Help Ukraine’s Cyber Security industry grow and prosper!
Contact us to know more: sponsors@nonamecon.org
Cybersecurity Framework 021214 Final UAVlad Styran
Методика з підвищення рівня інформаційної безпеки критично важливих об'єктів інфраструктури.
Переклад NIST Framework for Improving Critical Infrastructure Cybersecurity.
Перекладено та social thanks to: Cisco Ukraine.
Fantastic Beasts and where to hide from themVlad Styran
My presentation at IT Weekend Lviv 2017. Overview of modern cyber threat agents and their modus operandi. Practical recommendations on how to be a less likely cyber threat.
2. Кто эти люди?..
• БМС Консалтинг
• Мы делаем пентесты, много и часто
• Black Box, Grey Box, социальная инженерия…
• АБС, ДБО, биллинг, инфраструктура, веб- и прочие
приложения
• “Apparently, if you can test pens, you can test
everything.” - H.D. Moore
3. Что у нас позади
• Мы видим “картинку” снаружи и она нас пугает
• Domain Admin по внешнему вектору: 1 из 5-ти
• Domain Admin по внутреннему вектору: 3 из 5-ти
• В каждом “взрослом” пентесте: root, oracle, 100+
логинов/паролей пользователей, web shells…
4. Наши впечатления
• Типы граблей (по частоте обнаружения)
• Bad/default/no credentials
• Bad/no patch management
• Passwords for candy
• Application errors
• Bad session management
• Все остальные
17%
4%
13%
9%
22%
35%
6. Какие варианты?
• Борьба за безопасность “готовой” системы - сизифов труд
• Путь “Penetrate & Patch” ведет в никуда (хотя мы, конечно же, не против)
• Пентесты покрывают чуть больше половины известных угроз
• Infinity Maxim: There are an unlimited number of security vulnerabilities for a
given security device, system, or program, most of which will never be
discovered (by the good guys or bad guys).
• Лучший способ избавиться от уязвимости - не дать ей
возникнуть
• “Идеальный” план: построение полноценного процесса
Secure Development Lifecycle
10. Этапы SDL
• Обучение
• Требования
• Дизайн
• Реализация
• Проверка
• Релиз
• Реагирование
vs. Чик-чик и в продакшн!
11. Обучение
• Разработка программы обучения
• “Внешние” условия: требования, стандарты, законодательство
• Методики и технологии разработки
• Обучение команды и оценка результатов
• Метрики/критерии обучения
• Минимальная частота тренингов (на реже N раз в год)
• Минимальный групповой порог подготовки (не мнее 80% команды)
• Актуализация программы
12. Требования
• Утверждение требований безопасности до начала проекта
• Внешние (PCI, PII, HIPPA…) и внутренние (оценка рисков)
факторы
• Требования безопасности (т.н. негативные требования)
устанавливают, документируют (и тестируют) так же, как
позитивные требования к функционалу
• Минимальные требования безопасности (в терминах
пороговых значений качества)
• Назначение аналитика по безопасности
13. Дизайн
• Определение и документирование архитектуры
безопасности и механизмов защиты
• Использование техник безопасного дизайна:
многослойность защиты, управление версиями, принцип
наименьших привилегий, оценка рисков
• Моделирование угроз в контексте дизайна проекта,
выполняемых функций, обрабатываемых данных,
размещения в инфраструктуре, уникальных особенностей
• Минимизация угроз и рисков путем сужения “поверхности
атаки”
14. Реализация
• Использование техник безопасного кодирования: проверка ввода,
экранирование символов, параметризация запросов…
• Статический анализ по мере готовности исходного кода
• Реакция на уязвимости: исправление, документирование
• Использование одобренных инструментов и параметров
редактирования, контроля версий, сборки
• Использование средств ОС: ASLR, DEP, SElinux, apparmor…
• Отказ от незащищенных и устаревших библиотек, API,
криптографических алгоритмов
• Особое внимание к онлайн-сервисам: XSS, SQLi…
15. Проверка
• Переоценка модели угроз с учетом проделанной работы
• Пересмотр дизайна с учетом новых угроз (изменение “поверхности атаки”)
• Тестирование негативных требований
• Динамический анализ по мере готовности объектного кода
• Фаззинг, брут, стресс-тесты и прочее для файлового и пользовательского
ввода, API, сетевых подключений и т.д.
• Упор на анализ защищенности кода и тестирование безопасности
• Специфические тесты для онлайн-сервисов
• Реакция на уязвимости: исправление, документирование
16. Релиз
• Создание плана реагирования на инциденты и уязвимости,
обнаруживаемые в системе
• Обеспечение возможности выпуска исправлений
безопасности
• Финальная оценка защищенности
• Принятие/отклонение релиза
• Архивирование проекта
• Обновление документации
• Сохранение исходного кода для потомков (code escrow)
18. SDL для Agile
• Вернемся в реальность: по “классическому” SDLC уже
никто не работает
• В Agile SDL практики классифицированы не по этапам
SDLC, а по частоте выполнения
• Every-sprint: самые важные, повторять для каждого
релиза
• One-time: менее критичные, выполнять одноразово
• Bucket: все остальные, выполнять по мере надобности
19. One-time
• Из требований
• Требования безопасности
• Оценка рисков
• Из дизайна
• Требования к дизайну
• Сужение поверхности атаки
• Из релиза
• Создание плана реагирования
20. Every-sprint
• Из дизайна
• Моделирование угроз
• Из реализации
• Использование одобренных инструментов
• Отказ от старого хлама (API, библиотеки и т.д.)
• Статический анализ кода
• Из релиза
• Финальная оценка защищенности, принятие и архивирование
21. Bucket
• Из требований
• Минимальные требования безопасности
• Из проверки
• Динамический анализ приложения
• Фаззинг и прочие издевательства
• Пересмотр модели угроз и “поверхности” атаки
22. Ключевые концепции
• Производство защищенного кода требует
усовершенствования процессов разработки
• Один лишь поиск багов не делает софт безопаснее
• Риски это проблема менеджера, а не разработчика
• Постоянный пересмотр процессов SDL
• Непрерывное обучение, культура безопасности
• Инструменты и автоматизация
• Поощрение и последствия
24. Подведем итог
• Угрозы двигаются на уровень приложений
• Сегмент инструментов автоматизации созрел
• SDL внедряет безопасность в процессы и
культуру разработки
• Результаты измеримы и впечатляют
• SDL Agile-у не враг