Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

946 views

Published on

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

Published in: Technology
  • Be the first to comment

  • Be the first to like this

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

  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,

×