Данная статья отвечает на вопрос, чем он и как должен заниматься, со всеми интимными подробностями. Подразумевается, что есть проект (стартап) с веб-частью, который работал некоторое время без тестирования безопасности, но по каким-либо причинам решили его внедрить. Последние 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.
Будни
Как только закончили, отрепортили, с админом все поправили перешли к вебу. И так, нужен беглый, но более-менее качественный обход. Пускаем в ход различные сканеры, которые позволят протестировать ресурс «в лоб», а может даже что-то и найти. Вооружаемся burp-suite и идем исследовать функционал. Везде бесконечно отправляем универсальный xss вектор (штука старая, но зато какая):
javascript:/*--></marquee></script></title></textarea></noscript></style></xmp>">[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 рабочих дней.
Собираем все вместе, возможно что-то найдете такое, что надо будет «крутить». В общем тратим это время на атаки «в лоб» и исправляем все то, что нашел бы атакующий, не имеющий никакого отношения к компании (как факт, почти ничего о ней не знающий). С бОльшей вероятностью именно в этот период найдутся и исправятся самые критичные баги.
Месяц третий-шестой
За месяц-два мы можем изучить проект, понять его логику и работу. И начинаем внедряться в разработку…
Многое зависит от 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-офисами и достойными зп, готовых брать на работу граждан не РФ в Питере почти не знаю (желательно работающих на заграницу, не хочу бросать постоянное общение на английском).
Спасибо за внимание и прочтение, буду рад обсуждению статьи и расширению своих взглядов на организацию подобного процесса.
Автор: BeLove
