Безопасность прикладных систем. Разработчик, аудитор, пользователь. Сергей Гордейчик Positive Technologies. - презентация

1 Безопасность прикладных систем. Разработчик, аудитор, пользователь. Сергей Гордейчик Positive Technologies

2 Зачем заниматься безопасностью приложений? Compliance/Регулятивные требования Собственно для безопасности PR, MC & Business Just for FUN

3 Регулятивные требования PCI DSS Требования к наличию защитных механизмов (аутентификация, разграничение доступа, шифрование) Требования к качеству реализации (отсутствие уязвимостей OWASP top 10) Отдельный стандарт для платежных систем PA DSS 152 ФЗ «О персональных данных» В рамках «Четырехкнижия» выдвигаются требования к защитным механизмам Идентификация и аутентификация пользователей Управление доступом на уровне прикладных сущностей Регистрация событий на уровне прикладных сущностей Сертификация и аттестация В Риме веди себя как римлянин

4 Регулятивные требования Объем бедствия по PCI DSS Степень соответствия PCI DSS (WASC) Степень соответствия PCI DSS ASV (WASC)

5 Нужно ли мне это?... Собственно безопасность

6 «Статистика уязвимостей Web-приложений за 2008 год» - WASC

7 Пример: атака на Heartland Payment Systems «США против Гонзалеса и сообщников»

8 Сценарий Изучив компании из «Top 500», обнаружили уязвимости класса SQL Injection на Web-серверах трех из них С помощью SQL-инъекции получили контроль над несколькими серверами, установили руткиты Получили доступ к ключевым компонентам инфраструктуры, установили сниферы Арендовали Web-серверы в 6 регионах, на которые автоматически закачивались данные магнитной полосы и PIN-блоки Схема действовала с октября 2006 г. по май 2008 г. Было скомпрометировано 130,000,000 карт. Несмотря на предупреждения о возможном вроде, HPS признала утечку и оповестила клиентов только в январе 2009 Это самая масштабная утечка, по ее итогам HPS была «задним числом» признана не соответствующей PCI DSS

9 PR, MC & Business Демонстрация серьезного отношения к заказчику Удержание рынка Выход на новые рынки

10 PR, MC & Business NetCraft Market Share for Top Servers Авторитетная аналитическая компания призывает всех незамедлительно отказаться от использования веб- серверов Microsoft. В них столько ошибок, что это представляет реальную опасность 25 сентября 2001 года, 15:45 | Текст: К. Т.

11 Just for FUN Как правило, занимаются «чужой» безопасностью Исследователи, Аудиторы/пен тестеры Злобные хакеры dud3 1'm +0 HaX0r J00r s1+E!

12 Безопасное Web-приложение Что такое «Безопасное Web-приложение?»

13 Безопасное Web-приложение Все очень, очень и очень тривиально… Проектирование Разработка Поддержка

14 Проектирование Две задачи Выбор необходимых функций безопасности (защитных механизмов) Проектирование функций безопасности с учетом требований безопасности Классический пример – ГОСТ/ISO (Common Criteria) Часть 2. Функциональные требования безопасности Часть 3. Требования доверия к безопасности

15 Проектирование - Учет требований безопасности Наличие функций безопасности Нужна ли мне аутентификация… … протоколирование… …разграничение доступа… Отсутствие функций безопасности может являться уязвимостью OWASP top 10 (2004) A Insecure Storage WASC WSTCv2 Insufficient Authentication Insufficient Authorization

16 Проектирование - Источники Отраслевые/государственные и международные стандарты PCI DSS PA DSS 152 «ФЗ» - «Четырехкнижие» … Таксономии и классификации OWASP top 10 (2004) WASC WSTCv2 CWE

17 OWASP TOP 10 A1 - Cross Site Scripting (XSS) A2 - Injection Flaws A3 - Malicious File Execution A4 - Insecure Direct Object Reference A5 - Cross Site Request Forgery (CSRF) A6 - Information Leakage and Improper Error Handling A7 - Broken Authentication and Session Management A8 - Insecure Cryptographic Storage A9 - Insecure Communications A10 - Failure to Restrict URL Access Больше ориентирован на разработку

18 Web Application Security Consortium WSTCv2 Две группы: уязвимости и атаки. Наиболее полное описание проблем безопасности Web- приложений

19 Common Weakness Enumeration Исчерпывающее описание уязвимостей и атак Различные взгляды на данные – для разработчиков, исследователей…

20 Разработка – реализация требований безопасности Наиболее распространенный источник проблем Недостаточная информированность разработчиков Ошибки Недостаточное тестирование Как решать? Внедрение Secure SDLC Тестирование, тестирование, тестирование

21 Разработка – Тестирование OWASP Application Security Verification Standards (ASVS) На практике: Сканеры Черный ящик/Pentest Белый ящик

22 Тестирование – что лучше? «Статистика уязвимостей Web-приложений за 2008 год» - WASC

23 Поддержка – поддержание защищенного состояния Whitehat Security Фактическое устранение уязвимостей

24 Поддержка – уязвимости после «запуска» приложения Заказчик А что это такое? Договор на поддержку включает устранение уязвимостей? Кто вообще писал этот код? Разработчик Это не уязвимость! Что это за письмо? Шантаж?!

25 Поддержка – вовлеченные стороны Разработчик Получает информацию об уязвимостях Планирует устранение Устраняет Информирует заказчиков Исследователь Обнаруживает уязвимости Информирует разработчика/заказчика Помогает устранять Заказчик (Владелец/Пользователь) Ждет милости ? Включаем Web Application Firewall

26 Устранение уязвимостей – попытки формализации Full Disclosure Policy (RFPolicy) v2.0, Rain Forest Puppy Steven M. Christey and Chris Wysopal. Responsible Vulnerability Disclosure Process (Internet-Draft RFC). txt Organization for Internet Safety. Guidelines for Security Vulnerability Reporting and Response, Version NIAC, Vulnerability Disclosure Framework,

27 Спасибо за внимание!