3 июля 2013 в 04:41

Итак, вы решили создать security отдел…

Данная статья отвечает на вопрос, чем он и как должен заниматься, со всеми интимными подробностями. Подразумевается, что есть проект (стартап) с веб-частью, который работал некоторое время без тестирования безопасности, но по каким-либо причинам решили его внедрить. Последние 2 года я работал security в стартапе с очень крупными клиентами (стартап один из лидеров в мире в своей области), и я уверен, мне есть что сказать по этой теме (естественно, вся информация ниже — лишь мои идеи, подходы и размышления, а не гайд howto и ни шагу в сторону). Статья посвящается заинтересованному начальству, PM'ам, а также человеку, который будет именоваться как Security Testing Team Lead и создавать подобный отдел с нуля.


Итак, вы решили создать security отдел…

Мои поздравления, даже если вы просто над этим задумались (и совсем круто, если при приеме на работу новых сотрудников у вас этот момент как-то учитывается, писал об этом). Ломают всё и везде, и всё чаще и чаще. В наше время бизнес действительно может пошатнуться от утечек информации (в т.ч. пользовательской). За прошлый год получен полный доступ к LinkedIN, Stratfor, Gamigo, NVidia, Adobe, eHarmony, Blizzard и многим другим. А вот например вчера взломали Ubi, слышали? Хотя, малоудивительно, пишут, что у них уязвимости прямо на странице смены пароля


Ну да ладно, давайте перейдем к делу. И так, в компании появляется человек-security. Из себя он представляет специалиста, который, в первую очередь, сам владеет навыками пентеста и может выполнять эту работу. Так же некоторые навыки управления командой, знание CI систем, а так же редмайны или похожие вещи (зависит от специфики проекта, но в целом везде схожие подходы). Что ему делать?

Месяц первый — второй


Начать тестировать все самому, при чем в режиме blackbox. Получаем список проектов (их домены). Возможно, список IP адресов всех серверов, которые задействованы в проекте (сократит время на разведку). И начинаем тестировать.
Сначала сетевые сервисы. Сканим порты, вооружаемся msf+armitage, проверяем все эксплойты, конфигурацию dns-сервера (axfr, dns replay attack), веб-сервера. Тестируем «слабые» аккаунты, не забывая использовать пары startupname:startupname и подобные. В общем по полной пытаемся пробиться через сеть, веб не трогаем (если только в перерывах). Попутно записываем к себе всё используемое ПО (nginx/apache/pgsql). Задействуем эту инфу позже. У меня это просто текстовый файл с айпишниками и результатами nmap'a.

image
Будни

Как только закончили, отрепортили, с админом все поправили перешли к вебу. И так, нужен беглый, но более-менее качественный обход. Пускаем в ход различные сканеры, которые позволят протестировать ресурс «в лоб», а может даже что-то и найти. Вооружаемся burp-suite и идем исследовать функционал. Везде бесконечно отправляем универсальный xss вектор (штука старая, но зато какая):
Скрытый текст
javascript:/*-->
">[img=1]<img -/style=-=expression(/*’/-/*',/**/eval(name)//);width:100%;height:100%;position:absolute;behavior:url(#default#VML);-o-link:javascript:eval(title);-o-link-source:current name=alert(1) onerror=eval(name) src=1 autofocus onfocus=eval(name) onclick=eval(name) onmouseover=eval(name) background=javascript:eval(name)//>"

Смотрим на различные параметры, которые бы можно легко подменить или перебрать (enumerate), в общем ищем какой-нибудь очевидный parameter tampering. Там же особое внимание уделяем заливке файлов. Пробуем ведомые-неведомые файлы (например в случае php скрипты с mime типом jpg или png (idat chunks)). Кавычки везде подряд. В общем, не мне тут об этом рассказывать, у всех свои техники. Рассчитываем, кстати (в зависимости от масштаба проекта) какое время мы потратим на эдакий перебор «на удачу», например — 10 рабочих дней.

Собираем все вместе, возможно что-то найдете такое, что надо будет «крутить». В общем тратим это время на атаки «в лоб» и исправляем все то, что нашел бы атакующий, не имеющий никакого отношения к компании (как факт, почти ничего о ней не знающий). С бОльшей вероятностью именно в этот период найдутся и исправятся самые критичные баги.

Месяц третий-шестой


За месяц-два мы можем изучить проект, понять его логику и работу. И начинаем внедряться в разработку… Whitebox во всей красе.
Многое зависит от workflow в проекте. Основная идея внедрения состоит в том, чтобы внедрить security code review и/или security тестирование фич, которые готовятся к следующему релизу. New -> in progress -> done -> in testing -> tested -> security in testing -> security tested. Момент в том, что одному человеку просто напросто не справиться с тестированием безопасности всех фич (оно и очевидно), так что пока (если мы никого к себе еще не брали) тестируем только критично важные вещи (оцениваем их субъективно).
Здесь же перед каждым релизом можно делать полный diff с продакшн сервером и смотреть весь новый написанный код. Очень полезно.
И здесь же начинаем уже не в «безумном» режиме, а более спокойно и размеренно, разделив функционал по частям его тестировать. Каждый параметр, каждый ajax запрос и особенно всякие забытые вещи, кто никто не использует и которые были написаны разработчиком, который уволился года 2 назад (обычно в начале разработки допускается довольно много ошибок, так как надо всё «срочно срочно, скоро релиз!»). На данном этапе руководству над security team lead не стоит ожидать таких же «бумов» как в первые 2 месяца работы.

Месяц шестой + или мы взяли кого-то ещё


На моменте, когда мы решаем, что у нас появляется свободное время (проект в целом тестами покрыт, уже получен исходный код и проведен его анализ, в базе где нужно добавлена соль, везде «выпилили» md5 и т.п.) начинаем пытаться автоматизировать свою работу и внедряем security авто-тесты, которые мы можем создать на базе различных сканеров (например nmap — сохранили все в базу, если при очередном запуске state порта поменялся — сообщаем в отчете). Привинчиваем webui к w3af от Яндекса (кстати, сам не юзал). В общем начинаем писать код и это нормально (хоть должность и не программиста).

Если есть еще человек (а может и не один) и если люди творческие — обсуждаем, чтобы еще проверить на проекте. А так — делегируем им часть (или всю) работу месяцев 3-6 (не забывая порой проверять что да как), расширяя набор автотестов и не только.

Ну и офис, сотрудники. Читаем, применяем. По возможности делаем массовую рассылку о том, что нужно обновить какой-то плагин/браузер, если требуется.

На протяжении всего времени


Проводим обучение персонала (в основном разработчиков, указываем им на их ошибки, расширяем кругозор и др.), мониторим эксплойты (помните, мы записывали все ПО на первых двух месяцах работы?), смотрим отчеты сканеров, внедренных в CI разработку, постоянно, постоянно (!) читаем новые новости и твиттер различных security персон и компаний (или просто разные агрегаторы новостей), посещаем/выступаем на конференциях (PHDays/ZN как минимум, если брать РФ), играем в CTF. Возможно, период некоторой «халявы», но чаще всего находится (или придумывается самим) какая-то новая техника, которую надо срочно проверить на проекте. Поддерживаем безопасность со всех сторон и назначаем периоды «полного обхода». Когда со свежей головой, как будто в первый раз, снова обходится весь проект (см. месяца 1-2).

В целом


Многие моменты зависят от проекта, но по моим личным ощущениям, что если организовать работу, как я описал выше, получится эффективно (и не будет о нем подобных отзывов). Эффективность выражается в понижении рисков нарушения безопасности ресурса и его пользователей. В денежном эквиваленте безопасность выражается довольно сложно (хотя есть методы).


И на правах небольшой рекламы, если вы знаете какой-нибудь интересный стартап/проект/компанию в Санкт-Петербурге (или distance), куда (возможно) нужен такой человек, или QA с такими «наклонностями», или ресерчер, готовый учиться и развиваться, то сообщите мне (буду благодарен), ищу работу и различные варианты. Или просто если есть что сказать по теме поиска работы, то тоже пишите :-)
Стартапов с dev-офисами и достойными зп, готовых брать на работу граждан не РФ в Питере почти не знаю (желательно работающих на заграницу, не хочу бросать постоянное общение на английском).

Спасибо за внимание и прочтение, буду рад обсуждению статьи и расширению своих взглядов на организацию подобного процесса.
Sergey Belov @BeLove
карма
239,7
рейтинг 0,0
Пользователь
Самое читаемое Разработка

Комментарии (6)

  • +2
    интересный формат резюме :)
  • +15
    На второй день, ты уже устроился, но еще не купил кружку соответствующую статусу.
    Открываешь в браузере проект, в первом же месте меняешь в запросе ?id=14, на ?id=TEST и вуаля — на экране появляется ошибка с текстом SQL запроса. Далее бежишь доказывать, что это не правильно, успешно, тебе обещают поправить.
    Для более качественного анализа получаешь исходный код. Через 5 минут становиться понятным, что это систематическая ошибка.
    Еще через полчаса понимаешь, что проверки в принципе никто не делает. Пишешь скриптик для анализа масштаба проблемы и тот находит 3000 мест, где осуществляется передача параметров запроса без проверок. Более того, однотипные модули были реализованы под copy-paste, что говорит о низкой культуре кода и тяжкой перспективе что-то объяснить.
    Возвращаешься к разработчикам, тебя сходу уверяют, что над твоим первым пришествием они долго думали и поправят ошибку, как только освободится ответственный за тот код программист, где-то через неделю. Умножаешь неделю на 3000, пытаешься представить сколько это. Запутавшись в вычислениях приобретаешь спокойствие — с этим надо как-то жить дальше. Вываливаешь разработчикам свои 3000 засеченных косячка, отмечаешь copy-paste, тщательно подбирая цензурные выражения. Оказываются, что разработчики слышали про атаки на WEB, но все как-то времени нет это все систематизировать, описать, донести и внедрить. Иными словами это твоя работа! Тут же узнаешь, что проект старый, сложный, писанный кому не лень было. Действующая команда вынуждена продолжать традиции, да еще постоянная нехватка сил на необходимое развитие.
    Возвращение на рабочее место и поиск ответа на «Что делать ?». mod_security одним махом прикроет множество проблем! Находишь тестовый сервер, просишь развернуть проект, поднимаешь mod_security. Тестируешь сайт. Он работает лишь частично. mod_security тебе рассказывает, что в запросах обнаруживается нечто, сильно похожее на SQL: «select id,username .....». Изучаешь код страницы и обнаруживаешь симпатичный самописный фреймворк, которой на javascript генерит SQL запросы на основании действия пользователя.

    Идешь покупать кружку.
    • 0
      Соль жизни…
      (и ладно если все еще так обстоит :) )
  • +3
    И так создавал дед security отдел, и эдак — а почему-то получался хомяк на Ucoz-е.
  • 0
    Скажите, зачем выпиливать md5?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.