Привет! Я — Виктория Граненко, Security Automation Engineer в NIX. Начинала как General QA, распараллеливая мануальные и автоматизированные задачи тестирования. В мои обязанности не входили задачи по безопасности. Во время тестирования приложения на прошлом проекте я обратила внимание на некоторые случаи, которые мы никогда не фиксили. Это была не наша зона ответственности. Да и специалистов, которые смогли бы оценить критичность этих находок, среди нас тоже не было. Часть багов дожидалась прихода пентестера.
Но если мы хотим создать качественный продукт, разве не должны изначально сделать его надежным? К тому же, сегодня почти все приложения попадают под закон «О защите персональных данных» в соответствии с законодательством страны, где распространяется продукт. Я считаю, проверка секьюрности не должна выноситься на финальный этап тестирования перед релизом.
Поэтому я стала глубже интересоваться безопасностью. Также мне всегда нравилась автоматизация процессов. В какой-то момент тестирование в нашем проекте начало постепенно сводиться к бесконечной регрессии. Вопрос ускорения процессов стал приоритетным. Тогда я сосредоточилась на оптимизации процессов и автоматизации рутинных задач. Позже у меня появился шанс объединить два моих интереса в другом проекте. Так к моим прямым обязанностям добавились еще и задачи по безопасности. И вот уже полгода я занимаюсь автоматизацией находок команды по безопасности.
В этой статье вы узнаете, чем занимаются специалисты по безопасности и на какие стандарты опираются, что поможет тестировщику стать чемпионом в сфере security.
Кто может стать security-чемпионом
- тестировщики;
- разработчики;
- архитекторы;
- дизайнеры;
- DevOps-инженеры;
- любой заинтересованный в безопасности специалист.
Это довольно популярная тема на Западе, когда участники процесса разработки становятся евангелистами практик и методологий по безопасности.
В мире наблюдается нехватка security-специалистов. Но есть люди, которые интересуются безопасностью параллельно со своими прямыми обязанностями. Эти специалисты — настоящие чемпионы в сфере security. Они формируют security-культуру, благодаря чему разработчикам удается создавать безопасные приложения.
Security-чемпион знает все о внутренней кухне проекта. Он пережил и бессонные ночи, и сорванные дедлайны, и не боится сбиться с пути в поисках нужного решения. Эксперт консультирует коллег, внедряет стандарты и руководства по безопасности в своей организации или в проекте заказчика, направляет фокус команды на активности, связанные с безопасностью. Он — своеобразный «мостик» между командой безопасности и командой разработки. Захотев узнать чуть больше и проявив инициативу, каждый может стать в этой сфере чемпионом.
Зачем вообще тестировщику «топить» за безопасность
Часто архитектурные решения отдаются на откуп девелоперам, а к тестированию безопасности приходят на последнем этапе подготовки к релизу. По итогам тестирования заводят множество дефектов. Но когда приложение уже в «дырах», время, затрачиваемое на улучшение продукта, увеличивается в разы. Придется перекраивать все приложение, что не гарантирует качество.
Поэтому первая мантра всех security-специалистов: безопасность — это процесс, который продолжается даже на этапе продакшена.
Важно внедрить мониторинг и логирование, а также обеспечить своевременное реагирования на инциденты. В противном случае могут быть печальные последствия.
Security champion — это, прежде всего, о личной инициативе. Узнайте требования к безопасности и ожидания заказчика, совместно разработайте включения безопасности в процесс будущей разработки. Инициатором такого разговора может быть QA, Product Owner, проектный менеджер, бизнес-аналитик, архитектор или техлид. Для существующих продуктов, которые уже разрабатывают, стоит подключить тестирование безопасности, как только это станет возможным.
Помимо официального пути, в процессе разработки абсолютно легально можно попробовать протестировать приложение на базовые уязвимости (но только не на проде!) и уже на реальном проекте увидеть, насколько актуальна информация об уязвимостях. Тестировщики тесно сотрудничают с разработчиками, поэтому всегда есть возможность провести небольшое исследование и не бояться уголовной ответственности 🙂
Как внедрить безопасность в процесс разработки
Важно ориентироваться на признанные в мире стандарты по безопасности. Среди них выделяют два типа:
- Технические или контрольные, описывающие различные аспекты реализации мер защиты (OWASP 10, CIS Control, CIS Benchmarks, NIST SP 800-XX — используется как основа для законодательной базы по информационной безопасности в США). Чаще всего на них опираются стратегии компаний, которые разрабатывают ПО.
- Процессно-ориентированные, описывающие подход к выстраиванию процессов и формированию информационной безопасности в целом (ISO/IEC 27001:2013, руководство ITIL, методология COBIT).
Наша команда, как и многие другие по всему миру, следует Agile. Эта гибкая методология определяет ценности и принципы, которыми руководствуются команды. По похожему принципу Microsoft создала каноническую модель внедрения процессов безопасности в цикл разработки ПО — Secure SDLC. От нее развились различные ответвления. Все они базируются на стратегии по безопасности, которые принимает та или иная организация. Рассмотрим все этапы подробнее.
Сравнение подходов методологии Agile и Secure SDLC
Security-тренинги
Это первый обязательный этап перед стартом разработки. Казалось бы, все понятно: перед работой специалисты должны ознакомиться со стандартами безопасности и потом ее обеспечить. Однако безопасность — это нечто быстротечное. В этой сфере тенденции стремительно меняются, ежегодно появляется что-то новое. Чтобы сотрудники были на одном уровне с мировым сообществом, нужно регулярно проводить подобные занятия. Security-тренинги включают не только стандарты того, как разрабатывать безопасное ПО, но и различные способы обеспечения секьюрности в организации (например, пропуска для входа в здание, безопасность сети).
Разработка требований к приложению
На данном этапе устанавливаются security-требования к продукту. Они касаются новейших тенденций в сфере безопасности и опираются на законодательную базу той страны, где будет внедряться и распространяться продукт. Также на этом этапе прописывается стратегия безопасности проекта/продукта и решается, какими средствами будет осуществляться проверка безопасности до деплоймента на более высокие уровни приложения (если такие планируются). Это позволяет заранее избежать уязвимостей.
Дизайн
Здесь можно провести моделирование угроз для приложения. Как это сделать:
- собирается команда по безопасности, архитектор приложения и Product Owner;
- специалист по безопасности накидывает варианты возможных угроз, а Product Owner и архитектор предлагают меры, которыми можно закрыть эти погрешности в безопасности.
Тестирование
На этом этапе оценивается эффективность закрытия выделенных поверхностей атак. Далее проходит непосредственное тестирование безопасности.
Предрелизный этап и релиз
Это стадия для Penetration Testing. Проще говоря, тестирование на проникновение — оценка безопасности системы, сетей и ПО с помощью моделирования атак злоумышленника. Специалист тестирует приложение, сеть и инфраструктуру и смотрит на продукт с точки зрения блэкбокс-тестирования. Кроме базовых знаний о веб-приложениях и операционных системах Windows и Linux, а также знания сетей Cisco, для эффективного пентестинга важно разбираться в киберинфраструктуре, повышении кроссплатформенных привилегий, атаках на сетевую инфраструктуру, в reverse engineering и анализе вредоносного ПО. Все это поможет подготовиться к сертификации по безопасности и обзавестись крутой «ачивкой» современного специалиста.
Роадмап Penetration Testing
Здесь важно отметить: Penetration Testing обязательно проводится по запросу менеджера проекта. При тестировании приложения на безопасность запускаются различные сканеры для сбора информации. Зачастую используют самые популярные программы — OWASP ZAP и Burp Suite. Они позволяют атаковать приложение на основе полученных данных. При проведении атак могут задействоваться большие ресурсы, ведь цели у злоумышленников тоже бывают разные. Поэтому важно проверять не только защиту данных, но и надежность системы под нагрузками. В таких случаях необходимо, чтобы команда разработки знала о проведении тестирования на безопасность. Иначе могут возникнуть казусы.
Отзывы
На заключительном этапе важно мониторить, атакуется ли приложение, и анализировать отчеты о безопасности.
Добавьте эти уязвимости в свой чек-лист тестирования
Существует международная некоммерческая организация, занимающаяся безопасностью веб-приложений — OWASP. Она предоставляет массу ресурсов для тестировщиков — от security-гайдов до бесплатных «песочниц», где мы можем попробовать протестировать приложение и понять ход мыслей злоумышленника, и нам за это ничего не будет 🙂
Команда OWASP раз в четыре-пять лет выпускает топ-10 наиболее распространенных уязвимостей. В 2019 году вышел OWASP API Top-10.
С развитием микросервисной архитектуры приложений проблема незащищенных API-запросов становится все актуальней. Появляется больше мест, где можно допустить ошибку.
К тому же, популярность DevOps-культуры, облачных хранилищ данных и «умных» девайсов рождает огромное количество лазеек для злоумышленников. Чтобы не упустить моменты, связанные с развитием технологий, их внесли в отдельных список OWASP API Top-10. В нем подробно рассматриваются векторы атак на API и решения, которые помогут их предотвратить.
Из списка OWASP я хочу выделить пять ключевых уязвимостей. Со стороны автоматизатора этот перечень мне ближе и понятнее, так как более тесно связан с тем, с чем я работала. Почему-то эти сценарии мы редко включаем в свой чек-лист проверки приложения, а стоило бы.
Некорректная авторизация на уровне объектов
В этой ситуации злоумышленник использует ID ресурсов, которые принадлежат другим пользователям. Если проверки авторизации не выполнены должным образом, хакер получит доступ к данным. Как это проверить? Если у нас есть юзер с определенным айдишником, например userID, залогинившись под другим пользователем, мы можем отправить запрос, подставляя в url userID параметр или указывая ID юзера в пейлоаде. Затем смотрим, что получили в итоге. В идеале должна прийти 403 ошибка, в реальности — как повезет. Случаи с нарушением прав доступа, когда юзеру разрешено все, являются самыми распространенными и критичными. Поэтому важно обращать внимание, проверяется ли токен юзера и как реализованы механизмы авторизации.
Предоставление излишних данных
Иногда API может возвращать гораздо больше данных, чем нужно клиенту, полагаясь на фильтрацию. Если злоумышленник смотрит прямо на API, он получит все данные и использует их для своих атак. Также в данных об ошибках, в хедерах и паттернах, которые используются для валидации, может содержаться много чувствительной информации. Примеры таких утечек: информация о сервере, языке программирования, фреймворке. Чем больше информации получит злоумышленник, тем более уязвимой будет система.
Сломанный функциональный уровень авторизации
Здесь клиент использует API уровня пользователя или уровня администратора — в зависимости от роли. Злоумышленники находят «скрытые» методы админских API и вызывают их напрямую. Поэтому необходимо обращать внимание, проверяются ли привилегии пользователя, какие данные доступны неавторизованному юзеру, сохраняется ли иерархическая связь пользователей.
Ошибки настроек конфигурации системы
Эти ошибки — одни из самых распространенных уязвимостей. К ним относятся открытые системные папки и файлы, данные о паролях или скрытых файлах в коде, в том числе и прямо в html-странице. Можно пойти дальше и проверить базовые настройки безопасности, в том числе security-хедеры. Они помогают контролировать данные на страницах приложения. Один из самых критичных моментов — проверка использования протоколов шифрования SSL/TSL поверх http-протокола (при этом они должны быть последней версии).
Инъекции
Это одна из самых близких уязвимостей для QA-инженера. Да и вообще один из самых простых способов познакомиться с тестированием безопасности. Основная идея — отправить код (Javascript, SQL-запрос, команду cmd) и посмотреть, выполнится он или нет. Похожий алгоритм используется и при автоматизированном тестировании: мы отправляем запросы на сервер и смотрим, что нам пришло в ответ.
Мы редко учитываем здесь негативные сценарии, а последствия могут быть довольно печальными. Например, если пользователь проводит command line injection, он может получить удаленный контроль над веб-сервером. Дальше уже все на его усмотрение — стянуть все необходимые данные или «уронить» сервер. Как этого не допустить? Внедрять экранирование спецсимволов — то есть прописывать строгие ограничения на допустимые символы и длину полей. Современные языки программирования помогают избежать большинства случаев, связанных с инъекциями, и зачастую блокируют выполнение кода, сохраняя данные на сервере. Но если мы говорим о сложных системах, никогда не предугадаешь, с какими сторонними ресурсами придется взаимодействовать.
Позаботиться о безопасности
Что хотелось бы сказать напоследок: чтобы стать security-чемпионом не обязательно обладать обширными, глубокими знаниями в сфере информационной безопасности, сетей и программирования. Стартовать можно как минимум со списка OWASP Top-10, уязвимости из которого плотно пересекаются с процессом тестирования. Попробовать что-то новое и увлекательное можно почти сходу и постепенно накапливать знания, делиться ими с коллегами.
Круто быть именно тем человеком в команде, который заботится о секьюрности проекта.
Лучше изначально вложиться в безопасность, чем накануне релиза в спешке латать «дыры». Ведь это повлияет на целостность, качество и время доставки продукта.
Хотите узнать больше о безопасности? Держите полезные ресурсы:
- Интерактивный курс по OWASP API Top-10. Можно со стороны злоумышленника посмотреть, как он пытается получить данные пользователя, и ознакомиться с терминологией по информационной безопасности.
- Статья о том, как безопасность внедряется в весь цикл разработки.
- Одна из крупнейших баз уязвимостей.
- Курс об уязвимостях с объяснением, как закрывать «дыры».
- Лекция о типах разработки программного обеспечения с внедрением секьюрности.
- Подробная карта Penetration Testing.
Этот материал – не редакционный, это – личное мнение его автора. Редакция может не разделять это мнение.
Всего просмотров Всего просмотров 
Всего просмотров Всего просмотров 
Всего просмотров Всего просмотров 
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: