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

Я думаю, что отчасти это связано с трениями между разработчиками и специалистами по безопасности. Я думаю, что корень этих трений, вероятно, кроется в несовпадении целей между функциями безопасности и развития в организации. Это создало действительно болезненную ситуацию для многих групп разработки и безопасности. Иногда это проявляется в командах, у которых «нет времени» заниматься безопасностью.

Мой подход к решению этой проблемы с годами изменился. Раньше я думал, что этого достаточно, чтобы сформулировать риск для организации и сообщить об этом «вверх по цепочке». Со временем я понял, что, хотя я видел мир только с точки зрения обеспечения безопасности, у руководителей программ, разработчиков и владельцев продуктов были приоритеты, которые, по их мнению, были самыми важными. Редко когда менеджера по предложениям оценивают по чему-то столь же нематериальному, как безопасность, гораздо проще (и чаще) измерять его по предоставленным функциям.

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

Безопасность как особенность

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

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

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

Обеспечьте путь наименьшего сопротивления

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

Возьмем управление сертификатами в качестве наглядного примера: я никогда не работал там, где либо самоподписанные сертификаты, либо сертификаты с истекшим сроком действия не вызывали каких-либо болезненных сбоев или нарушений безопасности в какой-то момент. Для решения этой проблемы в HP мы создали систему под названием Anchor и представили клиентские инструменты, которые упростили получение сертификата, который был распознан и действителен для среды, в которой вы работаете.

Мы создали инструменты, которые упростили получение действительного сертификата, чем использование Google, чтобы узнать, как вырезать самоподписанный сертификат с помощью OpenSSL.

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

Используйте «комплаенс»

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

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

Это понадобится вам для соответствия требованиям. Для X, Y, Z и Z требуется 6-месячное окно доказательств - вместо того, чтобы делать это вручную, давайте разберемся, как превратить его в функцию, которая добавляет ценность сейчас и дает вам соответствие бесплатно. через полгода…

Хорошая безопасность должна иметь результаты помимо «нас не взломали». Обратите внимание на свою дорожную карту соответствия при рассмотрении функций, которые вы можете встроить в свою дорожную карту, или автоматизации, которые могут облегчить безопасность разработчиков. Какие артефакты должна выдавать эта функция, какие доказательства должна генерировать моя автоматизация, что еще мы можем сделать, чтобы облегчить соблюдение требований для всех в долгосрочной перспективе?

Я обнаружил, что призрак соблюдения нормативных требований может быть фантастическим способом взаимодействия с руководителями проектов. Сертификаты соответствия - это конкретные результаты, которые часто определяются требованиями продаж. Опытный архитектор безопасности найдет способы удовлетворить эти требования соответствия; путем развертывания технических средств управления безопасностью, которые приносят пользу более широкому продукту.

Мы, наверное, все знаем, что Compliance! = Безопасность, я предлагаю вам использовать Compliance для повышения безопасности, сделав всех (разработчиков, безопасность, менеджеров проектов, продаж, клиентов) немного более довольными продуктом.