SlideShare a Scribd company logo
Безопасность прикладных систем. Разработчик, аудитор, пользователь. Сергей Гордейчик Positive  Technologies
Зачем заниматься безопасностью приложений? Compliance/ Регулятивные требования Собственно для безопасности PR, MC & Business Just for FUN
Регулятивные требования PCI DSS Требования к наличию защитных механизмов (аутентификация, разграничение доступа, шифрование) Требования к качеству реализации (отсутствие уязвимостей  OWASP top 10) Отдельный стандарт для платежных систем  PA DSS 152  ФЗ «О персональных данных» В рамках «Четырехкнижия» выдвигаются требования к защитным механизмам Идентификация и аутентификация пользователей Управление доступом на уровне прикладных сущностей Регистрация событий на уровне прикладных сущностей Сертификация и аттестация В Риме веди себя как римлянин
Регулятивные требования Объем бедствия по  PCI DSS Степень соответствия  PCI DSS (WASC) Степень соответствия  PCI DSS ASV (WASC)
Нужно ли мне это?... Собственно безопасность
Собственно безопасность «Статистика уязвимостей Web-приложений за 2008 год»  -  WASC
Пример :  атака на  Heartland Payment Systems «США против  Гонзалеса и сообщников»
Сценарий Изучив компании из « Top 500 », обнаружили уязвимости класса  SQL Injection  на  Web- серверах трех из них С помощью  SQL- инъекции получили контроль над несколькими серверами, установили руткиты Получили доступ к ключевым компонентам инфраструктуры, установили сниферы Арендовали  Web- серверы в 6 регионах, на которые автоматически закачивались данные магнитной полосы и  PIN- блоки Схема действовала с октября 2006 г. по май 2008 г.  Было скомпрометировано 130,000,000 карт. Несмотря на предупреждения о возможном фроде,  HPS  признала утечку   и оповестила клиентов только в январе 2009 Это самая масштабная утечка, по ее итогам  HPS  была «задним числом» признана не соответствующей  PCI DSS
PR, MC & Business Демонстрация серьезного отношения к заказчику Удержание рынка   Выход на новые рынки
PR, MC & Business NetCraft Market Share for Top Servers  Авторитетная аналитическая компания призывает всех незамедлительно отказаться от использования веб-серверов Microsoft. В них столько ошибок, что это представляет реальную опасность 25 сентября 2001 года, 15:45 | Текст: К. Т.
Just for FUN Как правило, занимаются «чужой» безопасностью Исследователи,  Аудиторы / пентестеры Злобные хакеры dud3 1'm g0nn@ +0 HaX0r J00r s1+E! MuH@Ha!
Безопасное  Web- приложение Что такое  «Безопасное  Web- приложение?»
Безопасное  Web- приложение Все очень, очень и очень тривиально… Проектирование Разработка Поддержка
Проектирование Две задачи Выбор необходимых функций безопасности (защитных механизмов) Проектирование функций безопасности с учетом требований безопасности Классический пример – ГОСТ /ISO 15408 (Common Criteria) Часть 2. Функциональные требования безопасности Часть 3. Требования доверия к безопасности
Проектирование -  Учет требований безопасности Наличие функций безопасности  Нужна ли мне аутентификация… …  протоколирование… … разграничение доступа… Отсутствие функций безопасности может являться уязвимостью OWASP top 10  (2004)  A8 2004 Insecure Storage   WASC WSTCv2  Insufficient Authentication Insufficient Authorization
Проектирование -  Источники Отраслевые / государственные и международные стандарты PCI DSS PA DSS 152  «ФЗ» - «Четырехкнижие» … … Таксономии и классификации OWASP top 10  (2004)  WASC WSTCv2  CWE
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   http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project Больше ориентирован на разработку
Web Application Security Consortium WSTCv2 http://projects.webappsec.org/Threat-Classification-Working http://www.webappsec.org/projects/threat/ Две группы: уязвимости и атаки. Наиболее полное описание проблем безопасности  Web- приложений
Common Weakness Enumeration http://cwe.mitre.org/ Исчерпывающее описание уязвимостей и атак Различные взгляды на данные – для разработчиков, исследователей…
Разработка –  реализация требований безопасности Наиболее распространенный источник проблем Недостаточная информированность разработчиков Ошибки  Недостаточное тестирование Как решать? Внедрение  Secure SDLC Тестирование, тестирование, тестирование
Разработка –  Тестирование OWASP   Application Security Verification Standards (ASVS) http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project   На практике: Сканеры Черный ящик /Pentest Белый ящик
Тестирование – что лучше? «Статистика уязвимостей Web-приложений за 2008 год»  -  WASC
Поддержка –  поддержание защищенного состояния Whitehat Security Фактическое устранение уязвимостей
Поддержка –  уязвимости после «запуска» приложения Заказчик А что это такое? Договор на поддержку включает устранение уязвимостей? Кто вообще писал этот код? Разработчик Это не уязвимость! Что это за письмо? Шантаж?!
Поддержка – вовлеченные стороны Разработчик Получает информацию об уязвимостях Планирует устранение Устраняет Информирует заказчиков Исследователь Обнаруживает уязвимости Информирует разработчика / заказчика Помогает устранять Заказчик (Владелец / Пользователь) Ждет милости   ? Включаем  Web Application Firewall
Устранение уязвимостей – попытки формализации “ Full Disclosure Policy (RFPolicy) v2.0”, Rain Forest Puppy http://www.wiretrip.net/rfp/policy.html   Steven M. Christey and Chris Wysopal.  “Responsible Vulnerability Disclosure Process (Internet-Draft RFC).”  http://www.vulnwatch.org/papers/draft-christey-wysopal-vuln-disclosure-00.txt   Organization for Internet Safety.  “Guidelines for Security Vulnerability Reporting and Response, Version 2.0.”  http://www.oisafety.com/guidelines/secresp.html   NIAC, “Vulnerability Disclosure Framework”,  http://www.dhs.gov/interweb/assetlibrary/vdwgreport.pdf
Спасибо за внимание! [email_address] http://www.ptsecurity.ru/   http://sgordey.blogspot.com/

More Related Content

Sergey Gordeychik, Application Security in real word

  • 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 g0nn@ +0 HaX0r J00r s1+E! MuH@Ha!
  • 12. Безопасное Web- приложение Что такое «Безопасное Web- приложение?»
  • 13. Безопасное Web- приложение Все очень, очень и очень тривиально… Проектирование Разработка Поддержка
  • 14. Проектирование Две задачи Выбор необходимых функций безопасности (защитных механизмов) Проектирование функций безопасности с учетом требований безопасности Классический пример – ГОСТ /ISO 15408 (Common Criteria) Часть 2. Функциональные требования безопасности Часть 3. Требования доверия к безопасности
  • 15. Проектирование - Учет требований безопасности Наличие функций безопасности Нужна ли мне аутентификация… … протоколирование… … разграничение доступа… Отсутствие функций безопасности может являться уязвимостью OWASP top 10 (2004) A8 2004 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 http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project Больше ориентирован на разработку
  • 18. Web Application Security Consortium WSTCv2 http://projects.webappsec.org/Threat-Classification-Working http://www.webappsec.org/projects/threat/ Две группы: уязвимости и атаки. Наиболее полное описание проблем безопасности Web- приложений
  • 19. Common Weakness Enumeration http://cwe.mitre.org/ Исчерпывающее описание уязвимостей и атак Различные взгляды на данные – для разработчиков, исследователей…
  • 20. Разработка – реализация требований безопасности Наиболее распространенный источник проблем Недостаточная информированность разработчиков Ошибки Недостаточное тестирование Как решать? Внедрение Secure SDLC Тестирование, тестирование, тестирование
  • 21. Разработка – Тестирование OWASP Application Security Verification Standards (ASVS) http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project На практике: Сканеры Черный ящик /Pentest Белый ящик
  • 22. Тестирование – что лучше? «Статистика уязвимостей Web-приложений за 2008 год» - WASC
  • 23. Поддержка – поддержание защищенного состояния Whitehat Security Фактическое устранение уязвимостей
  • 24. Поддержка – уязвимости после «запуска» приложения Заказчик А что это такое? Договор на поддержку включает устранение уязвимостей? Кто вообще писал этот код? Разработчик Это не уязвимость! Что это за письмо? Шантаж?!
  • 25. Поддержка – вовлеченные стороны Разработчик Получает информацию об уязвимостях Планирует устранение Устраняет Информирует заказчиков Исследователь Обнаруживает уязвимости Информирует разработчика / заказчика Помогает устранять Заказчик (Владелец / Пользователь) Ждет милости  ? Включаем Web Application Firewall
  • 26. Устранение уязвимостей – попытки формализации “ Full Disclosure Policy (RFPolicy) v2.0”, Rain Forest Puppy http://www.wiretrip.net/rfp/policy.html Steven M. Christey and Chris Wysopal. “Responsible Vulnerability Disclosure Process (Internet-Draft RFC).” http://www.vulnwatch.org/papers/draft-christey-wysopal-vuln-disclosure-00.txt Organization for Internet Safety. “Guidelines for Security Vulnerability Reporting and Response, Version 2.0.” http://www.oisafety.com/guidelines/secresp.html NIAC, “Vulnerability Disclosure Framework”, http://www.dhs.gov/interweb/assetlibrary/vdwgreport.pdf
  • 27. Спасибо за внимание! [email_address] http://www.ptsecurity.ru/ http://sgordey.blogspot.com/