Александра Сватикова работает экспертом по информационной безопасности в Одноклассниках. Более 8 лет назад она перешла от разработки на Java к тестированию безопасности приложений.

Мы взяли у неё интервью, где обсудили:

• сложно ли перейти разработчику в аналитику приложений;
• различия в работе пентестера, ресерчера и аналитика;
• security development lifecycle или SDLC;
• роль человека в поиске уязвимостей;
• как обстоят дела с аналитикой безопасности в других компаниях.

В этой статье не будет хардкора — за ним можно съездить на Heisenbug 2019 Moscow, где Александра расскажет о статическом тестировании безопасности. Подробнее к её докладу перейдём в конце поста, а пока добро пожаловать под кат.

Войти в application security не так сложно, как кажется

— На кого ты училась? Почему ты стала заниматься безопасностью приложений?

— Я, наверное, не пример для подражания (смеётся). Я училась на программиста, и в дипломе написано что-то вроде «software engineering». Работала сначала мобильным разработчиком, затем перешла в веб-разработку на Java. После поиска очередной работы Java-программистом я попала в команду, которая занимается application security — поддержанием связанной с безопасностью части разработки. Там был хорошо организованный сформулированный процесс, и им были нужны люди, которые занимались бы ревью кода и статическими анализаторами. Соответственно, они искали Java-программиста и были готовы научить его безопасности. Мне это показалось интересным, так я и осталась.

— Как ты думаешь, в этой области ты останешься надолго, или за этим этапом дальше что-то последует?

— Думаю, что навсегда останусь, ведь я с 2011 года application security аналитик. Опыта разработки у меня уже меньше, получается. Программист должен не бояться рутинных задач, фиксить баги, а у специалиста по безопасности другая специфика, она меня больше привлекает.

— Какие дополнительные области по сравнению с обычной разработкой тебе пришлось освоить?

— На заре карьеры я занималась тестированием. Оно хорошо настраивает тебе мозги: ты видишь систему в виде не кучи кода, а организма, на который можно влиять разными путями. Так что у тестировщиков и разработчиков разница в мышлении.

Например, 10−15 лет назад считалось, что тестировщики должны сломать систему и найти баг любым способом. У специалистов по безопасности иногда должна быть подобная точка зрения. Значит, нужно понимать, как система работает в целом.

Некоторые разработчики зацикливаются на деталях: они знают, как работает часть системы, но плохо понимают, как это все взаимодействует. Например, он знает, как выполняется JS в браузере, но как этот браузер работает дальше и общается с сервером, почему это устроено так, разработчик не в курсе. Тестировщик же должен смотреть с высоты птичьего полета, чтобы оценить взаимосвязи компонентов, слабые изменения или какие-нибудь уязвимости.

— А что-то инженерное, например, сетевые стеки, тебе пришлось изучать с нуля? Например, как работает JS, фронт, бэк?

— В принципе, я уже была фуллстек-разработчиком, поэтому понимаю, как работает бэкенд и фронтенд. Нужно иметь определённый кругозор, но углубление в детали уже зависит от того, чем ты занимаешься. Те же разработчики и тестировщики в зависимости от проекта больше знают какие-то системные вещи (например, сетевые протоколы), либо больше знают про фронтенд. Это зависит от обстоятельств.

— Насколько тебе кажется реальным, что абстрактный фулстек-разработчик или фулстек-тестировщик, который занимается программированием, автоматизацией и тестированием, перейдёт в анализ приложений, то есть то, чем ты занимаешься?

— Тестировщику вообще всё просто. Обязательно надо обладать какими-то навыками программирования и понимать, как система устроена изнутри. Но хороший тестировщик без этого уже не существует. Если это есть, то дальше идёт вопрос специализации: ему надо почитать про безопасность и определённые технологии (например, Android или бэк), то есть то, в чём он пытается найти уязвимости.

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

Пентестер, ресерчер и application security-аналитик: в чём различие

— Как я понимаю, твоя специализация связана с пентестерами. Насколько соотносятся пентестеры и исследователи уязвимостей нулевого дня, или всё это смешано в один флакон и разобраться, кто есть кто, очень трудно?

— Нет чёткого деления на должности. Но расскажу, какими терминами оперирует тусовка.

Есть ресерчеры, которые исследуют продукт, технологию, протокол, сервер в попытке найти интересную проблему. Под интересной понимается проблема, которую раньше не находили, или выявили в неожиданном месте, либо это сложная комбинация ранее известных проблем. Могу сказать, что как правило, всякие 0day-уязвимости находят ресерчеры.

Пентест — это услуга. У тебя есть система, и ты хочешь найти уязвимые места. Задача пентестеров — проникнуть в систему. Они не смогут найти все потенциальные проблемы. Например, какая-то уязвимость может быть нивелирована другими механизмами безопасности на разных уровнях. Пентестер будет искать то, что реально эксплуатируется, а после выдаст отчёт и уйдет, поскольку у него нет задачи повышать безопасность системы или настраивать процессы разработки.

Есть также application security или product security-аналитики. Они, наоборот, смотрят на систему изнутри. Их задача – сделать систему безопасной. Это значит, что у них есть информация о системе, и она для них не «чёрный ящик». С другой стороны, они по-другому ранжируют проблемы. Аналитики рассматривают даже те уязвимости, которые в настоящий момент не могут быть эксплуатированы. Например, в админке критическая дыра, и понятно, что она доступна только из внутренней сети, и поэтому не очень страшно. Но человек изнутри понимает, что при определённых обстоятельствах может случиться страшное.

Аналитики больше заточены на поддержание процесса. Если пентестеры найдут 20 багов и уйдут, и разработчики в процессе фикса багов сделают еще столько же, то пентестеры тут уже не помогут. Поэтому понимание количества уязвимостей в системе будет актуально только в том моменте.

— Тогда application security-аналитик занимается этим в процессе, day-by-day?

— Да, и при этом деятельность направлена в две стороны. С одной стороны, нужно заниматься поиском существующих уязвимостей и борьбой с ними. С другой стороны, есть задача сделать систему безопаснее.

К этому можно подходить по-разному. Например, так построить процесс разработки, чтобы было меньше ошибок либо они быстро обнаруживались. Или внедрять механизмы, которые будут снижать риск того, что уязвимость попадёт в продакшн. Путей для обеспечения безопасности системы несколько.

— Получается, работа application security-аналитика тесно связана с командами и процессом разработки именно внутрь?

— Да, application security-аналитик должен поднять вопрос о процессе разработки. SDLC (Secure Development LifeCycle) — это первый buzzword, который встретится, если читать про application security. Если вкратце, цель этих действий в том, чтобы на каждом этапе разработки были учтены соображения безопасности системы. Не всегда при этом выполнением конкретных задач занимается именно специалист по безопасности, иногда можно делегировать другим членам команды. Ведь чем раньше ты найдёшь проблему, тем дешевле ее исправлять.

Человеческий разум всё ещё незаменим в поиске уязвимостей

— Проблемы с продуктом можно находить на уровне спецификации, её обсуждения, прототипа, скетча, когда ещё нет ни одной строчки кода. А вот проблемы безопасности на каком этапе становится можно найти? И можно ли их найти ещё до написания кода?

— Конечно, ведь есть проблемы, связанные непосредственно с тем, как формулируются требования. Приведу дикий пример. Ты делаешь форму логина, и тебе дизайнер говорит: «а давайте нашим пользователям скажем, что они не просто ввели неправильный пароль, а ошиблись в последней букве своего пароля». То есть формулировка требования может быть изначально небезопасной.

Также ещё на этапе ТЗ можно предположить, что система будет подвержена определённым уязвимостям, и придётся внедрять некоторые механизмы защиты. Если взять ту же форму на сайте, то обязательно нужно сделать капчу, чтобы запретить перебор пароля. Поэтому такие моменты должны быть упомянуты в разработке архитектуры.

— Насколько часто тестирование безопасности встраивается в CI/CD-процессы, и сложно ли это? То есть чтобы можно было «напедалить» какой-либо пайплайн в Jenkins или TeamCity, и там был отдельный этап, где запускаются тесты на безопасность. Насколько это реально?

— Есть гайдлайны по тому же SDLC, есть требования регуляторов. Соответственно, компании, которые имеют зрелый процесс разработки, их реализуют. Инструменты для автоматизации части процесса есть, но соотношение потраченных усилий и результата зависит от природы проекта и от того, на каком этапе разработки начали внедрять эти техники.

Если приложение пишется с нуля, то ты можешь предложить использовать статический анализатор, чтобы не допускать сомнительных инструкций в коде. А если до тебя 10 лет писали код, и ты пришёл туда со своим инструментом за безумные деньги, то, конечно, там немного найдешь.

У всех автоматических инструментов проблема в том, что они из коробки не знают, как устроена система. Если отдельный компонент системы можно изолировать, тогда его можно протестировать готовыми инструментами. Но в системе с множеством зависимостей автоматизированные сканеры могут потерять ценную информацию.

Аналитика безопасности в других компаниях

— Какая компания или какой отдельный проект, по твоему мнению, является флагманом в application security-аналитике, исходя из выступлений компаний и докладов на конференциях?

— Microsoft придумала имплементацию SDLC, которая стала каноном. Но вот как все устроено у них на самом низком уровне, какие инструменты используются, я не знаю.

Facebook много пишет про то, как все у них устроено в техническом плане: как они сканируют код, находят уязвимости в работающих системах и т.д. Некоторые инструменты Facebook даже являются open source-проектами, поэтому можно поковыряться в их «кишочках».

Если взять российские компании, то Сбербанк интересно рассказывал про то, как они формализовывали SDLC, документировали процесс. Хотя application security-команда у них немаленькая, её не хватает на множество разработчиков. Поэтому они воспитывают security-чемпионов в командах, вкладывают им в голову какие-то знания о безопасности, и в случае чего чемпионы могут поднять красный флаг.

Яндекс рассказывает на конференциях про крутые штуки вроде «как взломать браузер».

— Реально ли, что тестировщик после конференции, где услышал доклад про угрозы и инструменты, получит значимый эффект после их внедрения? Например, компания купит за условные 10 тысяч долларов сканер, который в пайплайне Jenkins ищет «дыры». Или же важнее знание механик эксплуатации уязвимостей, чтобы внедрить какие-то вещи?

— За 10 тыс. долларов ты сканер не купишь (смеётся). Если говорить про поиск уязвимостей, то всё сводится к тестированию конкретных сценариев. Сценарии берутся из сборников общих знаний.

Например, OWASP (Open Web Application Security Project) публикует гайды, как проводить тестирование безопасности, ревью кода и т.д. Например, в OWASP Application Security Verification Standard написано обо всем, что нужно тестировать. Для чтения документа специальных знаний не требуется, достаточно знать о веб-приложениях, поэтому любой тестировщик справится.

Стандарта и шпаргалок хватит для запуска ручных тестов. Там написано, какие виды уязвимостей существуют и как их искать. Некоторые тесты не могут быть выполнены стандартными сканерами по определению: например, те, что связаны с проверкой бизнес-логики.

С другой стороны, если нужно найти XSS, то в каждый изменяемый параметр надо вписать кавычку, скобку и т. п. А если в системе 100 миллионов параметров, то задача уже нереализуема. Зато с ней как раз хорошо справятся автоматизированные инструменты.

Но когда ты запускаешь сканер, может быть три варианта развития событий:

1. Инструмент выдал отчет, где много хороших воспроизводимых багов и немного false positive (идеально, но маловероятно).
2. В отчете 20 тыс. находок, из которых истинных около 1%. Поэтому придётся посидеть и определить, настоящие ли проблемы.
3. Инструмент не смог что-то понять в системе, поэтому выдал отчёт, в котором всё хорошо, но это не так. Например, не смог скомпилировать код, потому что не нашёл библиотеку. Или это сканер уязвимостей, который сделал 10 запросов, нарвался на антифлуд, и на оставшийся миллион запросов не получил от сервера ответа.

Поэтому, думаю, важно всё же понимать, что у сканера «под капотом», чтобы выбирать соответствующий решаемой задаче инструмент и адекватно оценивать полученный результат.

Тему правильного выбора и настройки инструментов Александра разовьёт в своём докладе на Heisenbug. Там она расскажет о применении и кастомизации SAST-решений SonarQube и Find Security Bugs для поиска уязвимостей в своём проекте. Какие возможности эти инструменты предоставляют «из коробки»? А как самостоятельно расширить их функциональность? В качестве примера спикер рассмотрит уязвимости XSS и IDOR.

Конференция пройдёт 5-6 декабря в Москве.