При TDS важно представлять безопасность как отдельную функциональность продукта. Для этого меры безопасности реализуются непосредственно в коде или системе продукта. Работа команд по безопасности, выстраивающих защиту вне самого приложения и инфраструктуры, вызывает меньше доверия, поэтому лучше воздерживаться от такого подхода.
Верный подход к управлению рисками должен преследовать три цели.
• Оценивать риски следует в пределах небольших итераций, часто и быстро. Программы и инфраструктура постоянно меняются, и организация должна быть способна обсуждать риски сразу, а не с недельной задержкой.
В операционной системе Linux подсистема отслеживания в ядре может журналировать системные вызовы. Атакующие зачастую не учитывают этот тип журналирования при проникновении в системы, и отправка событий отслеживания в конвейер журналирования может помочь обнаружить вторжение.
Вторгаясь в инфраструктуру, атакующие обычно выполняют четыре шага.
1. Отправляют полезную нагрузку на целевые серверы. Полезная нагрузка — это некий небольшой бэкдорный скрипт или вредоносный код, который может быть загружен и выполнен, не привлекая внимания.
DevOps учит нас: для успешной стратегии необходимы сближение стороны эксплуатации со стороной разработки, а также разрушение коммуникационного барьера между различными разработчиками и специалистами по эксплуатации. Безопасность в DevOps должна начинаться с близкого взаимодействия команд по безопасности и их коллег-инженеров. Безопасность должна служить клиенту, выступая в качестве функции сервиса, а внутренние цели команд по безопасности и DevOps-команды должны быть связаны.
DevOps — процесс непрерывного совершенствования программных продуктов посредством ускорения циклов релизов, глобальной автоматизации интеграционных и разверточных конвейеров и тесного взаимодействия между командами. Целью DevOps является сокращение времени и стоимости воплощения идеи в продукте, которым пользуются клиенты. DevOps применяет много автоматизированных процессов для ускорения разработки и развертывания.
