Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.
Методические отличия при анализе кода
внутренних и внешних приложений
CISO Forum 2013
Петухов Андрей
Thursday, July 18,
• Основополагающий принцип при построении
системы защиты
• Подходы к реализации:
➡ наименьшие привилегии и разграничение д...
• Для управления угрозами, исходящими от обычных
пользователей отлично годятся все три подхода
• Как насчет пользователей ...
• SDLC нет и не предвидится
➡ дорого и/или долго и/или нецелесообразно
➡ вся основная разработка давно завершилась
➡ почти...
• Есть приложения, основанные на веб-технологиях,
которые почти не отличаются от открытых в WWW
• Есть и другие,“особенные...
• Высокая критичность => сканирование запрещено
• Много связей с другими системами => развернуть в лаборатории для
динамич...
• Доступ к приложению: onsite vsVPN
➡ VPN может быть запрещен политиками; но onsite будет дороже
• Какие уязвимости можно ...
• Доступ к коду: onsite vs передача
➡ передача может быть запрещена политиками; но onsite будет дороже
• Автоматический ан...
• Внутренние веб-приложения приемлемо анализировать методом черного
ящика на начальном этапе (см. быстро и дешево найти “т...
• Контакты
➡ Twitter: @p3tand
➡ Mob: +7 916 360-52-49
➡ Email: petand@seclab.cs.msu.su
➡ Blog: http://andrepetukhov.wordpr...
Próxima SlideShare
Cargando en…5
×

Методические отличия при анализе кода внутренних и внешних приложений

958 visualizaciones

Publicado el

Презентация с CISO Forum 2013

Publicado en: Tecnología
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Методические отличия при анализе кода внутренних и внешних приложений

  1. 1. Методические отличия при анализе кода внутренних и внешних приложений CISO Forum 2013 Петухов Андрей Thursday, July 18,
  2. 2. • Основополагающий принцип при построении системы защиты • Подходы к реализации: ➡ наименьшие привилегии и разграничение доступа ➡ резервирование и архивное копирование ➡ реализация системы мониторинга и реагирования • Подходы реализуются на различных уровнях ИС ➡ сетевой, системный (узловой), прикладной, физический и т.п. Принцип ограниченности ущерба Thursday, July 18,
  3. 3. • Для управления угрозами, исходящими от обычных пользователей отлично годятся все три подхода • Как насчет пользователей с высоким уровнем технического допуска? ➡ “How to Grant Administrator Authority without Losing Control over System?” (с) ➡ “How to Grant Developer Authority without Losing Trust into System?” (с) • Начнем с администраторов; в целом, все известно: ➡ Least privilege & monitoring [& ITSM] • Продолжим про разработчиков ➡ Secure SDLC способно побороться с преднамеренным и непреднамеренным внесением недостатков ➡ А если SDLC нет и не предвидится? “For whom how” (c) Thursday, July 18,
  4. 4. • SDLC нет и не предвидится ➡ дорого и/или долго и/или нецелесообразно ➡ вся основная разработка давно завершилась ➡ почти вся разработка - это расширение существующих функций в уже внедренных приложениях, добавление новых и исправление ошибок ➡ принимается приложение, разработанное на стороне, при заказе которого не предъявлялись требования к безопасности • Как методически решать задачу организации мониторинга за действиями разработчиков? • По идее, комплекс мониторинга должен включать: ➡ анализ исходного состояния приложения ➡ фиксирование и анализ изменений ➡ мониторинг взаимодействия пользователей с приложением ➡ протоколирование работы приложения Проблематика Thursday, July 18,
  5. 5. • Есть приложения, основанные на веб-технологиях, которые почти не отличаются от открытых в WWW • Есть и другие,“особенные”: ➡ толстые клиенты вместо веб-интерфейса, возможно свой протокол обмена данными ➡ используются DSL (LotusScript) и прочие нетипичные сейчас языки (Cobol) ➡ могут быть расширениями огромной платформы (1С, SAP, Lotus и т.п.) • Особенности ➡ высокая критичность ➡ большое количество связей в другими системами Специфика внутренних приложений Thursday, July 18,
  6. 6. • Высокая критичность => сканирование запрещено • Много связей с другими системами => развернуть в лаборатории для динамического анализа нереально • Что остается из методов? ➡ ручной black-box анализ ➡ статический анализ (ручной или автоматический) • Толстые клиенты => XSS нерелевантно • DSL-языки => SQLi и прочие “классические” атаки могут быть неосуществимы • Что остается из релевантных недостатков? ➡ application specific недостатки: уязвимости авторизации, уязвимости логики ➡ бекдоры, закладки, логические бомбы ➡ некорректная конфигурация платформы, сервера и приложения Выводы из свойств Thursday, July 18,
  7. 7. • Доступ к приложению: onsite vsVPN ➡ VPN может быть запрещен политиками; но onsite будет дороже • Какие уязвимости можно найти ➡ если внутренне приложение - веб-приложение: все типичные уязвимости веб- приложений, позволяющие проводить Injection-атаки (XSS, SQLi, и т.п.) ➡ если внутреннее приложение “особенное”: некоторые классы уязвимостей авторизации и логики, уязвимости конфигрурирования ➡ важно: для полноценного black-box анализа потребуется доступ от имени пользователей различных ролей, в т.ч. привилегированных (!), что не всегда возможно (см. политики организации) Ручной black-box анализ Thursday, July 18,
  8. 8. • Доступ к коду: onsite vs передача ➡ передача может быть запрещена политиками; но onsite будет дороже • Автоматический анализ способен найти только типичные недостатки (SQLi/XSS и т.п.) • Для DSL и других нераспространненых языков не всегда найдется анализатор • App specific недостатки можно найти с приемлемой полнотой только вручную • Для “особенных” приложений самыми актуальными являются следующие классы недостатков: ➡ уязвимости авторизации ➡ некорректное использование API платформы ➡ контуры для удаленной отладки и мониторинга Статический анализ Thursday, July 18,
  9. 9. • Внутренние веб-приложения приемлемо анализировать методом черного ящика на начальном этапе (см. быстро и дешево найти “тупые” уязвимости) ➡ этот подход не так хорошо работает для “особенных” приложений (DSL/толстые клиенты) • Недостатки некоторых классов можно найти только статически и только вручную ➡ это решит задачу анализа исходного состояния, как построить систему мониторинга (см. еженедельные обновления в коде)? • Статический анализ по сигнатурам, написанным в результате ручного анализа, сможет обеспечить мониторинг изменений в коде • Offtopic: Injection-атаки во внутренней сети очень шумные => мониторинг! Выводы Thursday, July 18,
  10. 10. • Контакты ➡ Twitter: @p3tand ➡ Mob: +7 916 360-52-49 ➡ Email: petand@seclab.cs.msu.su ➡ Blog: http://andrepetukhov.wordpress.com/ Ответы на вопросы Thursday, July 18,

×