Статья SSDLC

Доброго времени суток.
Это продолжение статей про DevSecOps.

1 статья
2 статья

SSDLC - Secure Software Development LyfeCycle. Как было написано ранее, SSDLC это методика по обеспечению безопасности на каждом этапе разработки ПО.
Вспомним каждый этап:

1. Планирование
2. Анализ требований
3. Проектирование и дизайн
4. Разработка ПО
5. Тестирование
6. Поддержка и сопровождение

Большинство компаний не может себе позволить безопасность раньше этапа Разработки ПО. А большинство не задумывается об этом раньше этапа тестирования.
Давайте посмотрим почему же SSDLC не может быть внедрено всеми компаниями.

1. Планирование - добавляется оценка угроз и анализ рисков. Это сложно, и дорого, так как качественную анализ рисков и угроз может делать лишь высококвалифицированный специалист.
2. Анализ требований - оценка рисков, анализ поверхности атаки, требования по безопасности. Тут уже попроще, как минимум требования по безопасности могут составить рядовые безопасники, которые регулярно тестируют приложение. Но оценка рисков задача не для новичков, даже мидлам будет нелегко.
3. Проектирование и дизайн - безопасная архитектура, безопасное взаимодействие сервисов, модель угроз. Нужны мидлы безопасники. Особо одаренные новички, конечно тоже смогут, но их еще нужно найти.
4. Разработка - безопасное программирование, статический анализ, тесты. Здесь от безопасников зависит не многое. Хорошей практикой можно считать внедрение Security Champion, это разработчик, который отвечает за безопасный код. Он знает
   Ссылка скрыта от гостей
   ,
   Ссылка скрыта от гостей
   и, самое важное, имеет вес в принятии решений среди разработчиков. Задачу безопасной разработки можно решить обучением всех разработчиков, демонстрация уязвимого кода и как его исправить до безопасного.
5. Тестирование - проведение пентестов и проверка требований безопасности. Если в компании есть безопасники, то они подключаются здесь, как правило.
6. Поддержка и сопровождение - анализ уязвимостей, выпуск патчей, реагирование на инциденты. Если у приложения есть поддержка, то этот пункт тоже есть в компаниях с безопасниками.

Как видите людей требуется на целый отдел из более чем 4 человек. В этом кроется основная трудность, либо маленькому количеству людей давать много задач в ущерб качеству, либо лучшее качество, но больше людей, а следовательно - дороже.

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

1. Анализ угроз безопасности информации. Он включает:

• Выявление источников угроз безопасности и оценку возможностей внешних и внутренних нарушителей;
• Анализ возможных уязвимостей программных, программно-аппаратных средств ИС;
• Определение возможных сценариев возникновения угроз безопасности информации;
• Оценку возможных последствий от возникновения угроз безопасности информации.

Для этого нам помогут Матрица MITRE ATT&CK (про то как ей пользоваться тут) и

Ссылка скрыта от гостей

. Чтобы нормально оперировать этими данными нужно обладать изрядным опытом, либо терпением, чтобы ваши сотрудники сначала ознакомились со всеми угрозами (их там больше 400 в каждом ресурсе), а потом научились их в нужном месте применять.

1. Анализ поверхности атак, требования по безопасности к системе. Поверхность атак означает уязвимые места, т.е. место в котором можно провести атаку. Сложно советовать что-то конкретное, системы бывают разными.

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

1. Модель угроз - это описание угроз, насколько они реалистичны, каковы шансы, что они воплотятся в жизнь, каковы последствия. Можно без большого личного опыта, достаточно посмотреть какие угрозы были в похожих системах у других. То же самое касается и безопасного взаимодействия сервисов. Тот самый случай, когда лучше воспользоваться чужими успехами, особенно, если они построены на неудачном опыте.
2. Безопасное программирование. Как писалось выше, здесь от безопасников зависит немногое, но, все же кое-что есть. Как показывает практика, в ВУЗах и техникумах разработчиков не обучают даже простейшим уязвимостям, таким как SQLi и/или XSS. Поэтому эта задача ляжет на безопасников. Можно проводить инструктажи, или CTF, вести свой блог внутри компании по уязвимостям и их патчингу. Известный факт, что групповые занятия менее эффективны, чем индивидуальные, поэтому можно обучать не всех разработчиков, а лишь одного - Security Champion. Он в свою очередь будет отвечать за безопасность кода и общаться с отделом безопасности. Это считается Best Practice, т.к. разработчики без энтузиазма воспринимают критику своего кода от специалистов по безопасности и тем более от SAST/DAST систем.
3. Тестирование. Читаем Codeby, учимся проводить тестирование на проникновение, профит)
4. Поддержка и сопровождение. Так называемый Vulnerability Patching. Из-за развития технологий, вам нужно будет обновлять критические системы, чтобы в них не плодились известные уязвимости. Почему я акцентирую внимание на критических системах? Дело в том, что не всегда можно безболезненно перенести систему на новый стек. Например, система хорошо работает на JQuery, но ведь мы все знаем, что это крайне уязвимая технология. Однако заменить ее нет возможности, т.к. для этого нужно выделить команду, которой нужно будет переписать весь функционал. Придется идти на компромисс между безопасностью и ресурсами на разработку. Благо существует такое понятие - Virtual Vulnerability Patching. То есть мы не код исправляем, а, например, создаем правило на WAF, которое блокирует эксплуатацию этой уязвимости. Главное не забыть об этом и все же, когда-нибудь переписать функционал.

На этом все, спасибо за внимание, пошел готовить следующую статью.