Статья DevSecOps. Эпизод 1. Скрытые угрозы

devsecops-image-2000-6557ba1b00.jpg


Доброго времени суток, уважаемые форумчане!

DevSecOps.Начало
DevSecOps.DevOps (ч.1)
SSDLC

Наконец-то мы добрались до последнего пункта этих статей и нашей основной цели - DevSecOps. Его внедрение без SSDLC крайне болезненное, но все же не бесполезное. Мы рассмотрим инструменты, которые помогут обеспечить безопасность DevOps.

Начнем с самых основ - настройки репозитория.

Настройка репозитория

Думаю это очевидно, но уязвимости часто возникают из-за очевидных вещей.

Сделайте веткой по умолчанию НЕ ПРОДАКШЕН ВЕТКУ! Серьезно, к тому же, для предотвращения неприятных инцидентов в дальнейшем лучше ограничить возможности участников проекта по влиянию на продакшен ветку.

1659269052997.png


1659269240270.png


Ну и конечно никаких Force push в основные ветки.

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

Безопасность контейнеров

  1. Старайтесь использовать надежный образ - из официальных образов Docker. Если вам нужно выбрать базовый дистрибутив. Рекомендуется использовать Alpine Linux. Следует ли вам использовать тег latest? Тут по вашему желанию, но стабильная версия предпочтительнее.
  2. Создавайте и запускайте свое приложение под непривилегированным пользователем (либо явно в Dockerfile, или с помощью произвольного идентификатор пользователя во время выполнения).
  3. Если вам нужно настроить доступ к хосту, используйте опции [r|w|m] для выборочного включить чтение, запись или mknod.
  4. Явно ограничивайте использование ресурсов, чтобы избежать DDoS-атаки.
  5. Ограничьте смонтированную файловую систему только на чтение.
  6. Создайте хранилище в оперативной памяти для временные файлов в директории /tmp.
  7. Настройте локальный раздел /usr/local/myapp только для чтения.
  8. Рекомендуется экспортировать логи на внешний сервис.
  9. Отключите мост по умолчанию и используйте выделенную сеть для предоставления интерфейса хоста.
И помните! Открытие сокета Docker эквивалентно предоставлению неограниченного root-доступа к вашему хосту.

Существуют множество автоматических инструментов по анализу, например Clair или Docker Bench Security.

Обучение сотрудников

Самым надежным способом защиты приложения всегда остается обучение команды разработчиков безопасной разработке. У OWASP есть документ, который содержит практики безопасного кодинга. Если разработчики с ним ознакомятся и поймут, это повысит безопасность кода, который они пишут.

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

Дальше можно проводить CTF. И это реально несет пользу, потому что у участников будет соревновательный элемент.

Если организовывать CTF нет сил и/или времени, то хорошими ресурсами для практики являются TryHackMe и HackTheBox. Обе платформы имеют хорошее комьюнити и предназначены для любого уровня.

Главное в этом пункте - системность. Например, у вас есть встречи каждую неделю, две недели вы обучаетесь по Portswigger Academy, на третьей неделе выступает спикер с докладом о какой-то найденной уязвимости, желательно с PoC, на четвертой неделе проводится CTF, который включает изученные материалы в этом месяце плюс изученные ранее.

Из под палки обучаться тоже тяжело, поэтому тут проще выделить Security Champion, которые будут ходить обязательно, а остальные по желанию. Кроме того, таким образом можно будет обеспечить заменимость Security Champion-ов в случае их отсутствия.

Обучение это конечно хорошо, но это долго. Поэтому нужно перестраховаться до момента, когда разработчики смогут самостоятельно обезопасить код. На помощь к нам приходят SAST и DAST.

SAST

SAST (Static Application Security Testing) — тестирование «белого ящика», существует уже более десяти лет. Позволяет разработчикам находить уязвимости безопасности в исходном коде приложения на ранних этапах жизненного цикла разработки ПО.

“В теории нет разницы между теорией и практикой. На практике есть”

Поэтому давайте внедрим в уже существующий проект pipeline с SAST для нашего кода.
Так как мы используем Gitlab CI, то можно использовать их встроенные функции SAST.

1659270326796.png


И получаем:

1659270264639.png


Все! Готово. Теперь у нас есть SAST =)
Важный факт, работает это только если у вас есть stage test

DAST

DAST (Dynamic Application Security Testing) — тестирование «черного ящика», может обнаруживать уязвимости и слабые места в работающем приложении, обычно веб-приложениях. Это достигается за счет использования методов внедрения ошибок в приложении, таких как передача вредоносных данных в программное обеспечение, для выявления распространенных уязвимостей безопасности, например, SQL-инъекций и межсайтовых сценариев.
С таким видом тестирования сложнее. Как правило для качественного тестирования нужны довольно дорогие приложения, например Acunetix.
Нам повезло, у Gitlab есть и встроенный DAST. Подключить его не составляет труда:
1. Добавляем stage dast
2. Подключаем встроенный DAST

1659270757932.png


3. В переменных указываем что нужно проверять инструменту

1659270739908.png


Хорошим примером DAST также является OWASP ZAP и Burp Suite, а так же Acunetix (стоит как крыло от самолета)

На этом на сегодня все.

Спасибо за внимание!
 
Последнее редактирование модератором:
  • Нравится
Реакции: kot-gor и absurd121
Мы в соцсетях: