Должна ли безопасность ухудшиться, прежде чем она станет лучше?

Во вступительном докладе 2022 г. Black Hat конференция по безопасности, Крис Кребс, бывший директор по кибербезопасности Министерства внутренних дел, заявил, что безопасность будет ухудшаться, прежде чем станет лучше. Почему? Кребс сказал, что «программное обеспечение остается уязвимым, потому что преимущества небезопасных продуктов намного перевешивают недостатки». Вместо обеспечения безопасности основное внимание в жизненном цикле разработки программного обеспечения (SDLC) уделяется победе над конкуренцией на рынке. На самом деле, инновации часто противоречат безопасности — первая считается быстро развивающейся и продуктивной, а вторая — препятствием, сдерживающим быструю разработку приложений. Эта точка зрения оказывается устаревшей в текущей ситуации с угрозами.

В связи с ростом числа кибератак цепочка поставок программного обеспечения становится популярной мишенью для киберпреступников, которые осознают огромный ущерб, который они вызывают при заражении небезопасного кода. Например, ныне печально известный Журнал4Shell Уязвимость представляет такой риск, потому что Log4j с открытым исходным кодом так широко используется в программных приложениях и онлайн-сервисах по всему миру, а использование этой уязвимости требует очень небольшого опыта. Совсем недавно, 25,000 XNUMX вредоносных плагинов найденные на сайтах WordPress, подчеркивают риск кибербезопасности, с которым сталкиваются многие компании, несмотря на то, что они считают, что используют безопасные приложения и программы на своих веб-сайтах.

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

Дилемма AppSec

Несмотря на возросшие инвестиции в разработку приложений, безопасности уделяется меньше внимания. В такой конкурентной среде первопроходцы, как правило, получают вознаграждение. Те, кто выходит на рынок со своим «первым жизнеспособным продуктом», скорее всего, смотрят на то, как этот продукт может обслуживать клиентов, а не на то, как его можно безопасно использовать. Из-за этих высоких ожиданий требования к коду для разработчиков возросли. 100 раз за последние 10 лет, при этом 92% чувствуют необходимость писать код быстрее. Соедините это с тем, что 53% не имеют профессиональной подготовки по безопасному кодированию, а количество новых уязвимостей в NIST Национальная база данных уязвимостей увеличилась более чем на 200% за последние несколько лет, и, похоже, мы столкнулись с чем-то вроде дилеммы безопасности приложений.

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

Создание такого мышления, ориентированного на безопасность, имеет решающее значение — не только для команды разработчиков, но и для всех, кто играет роль в SDLC. Менеджеры по продуктам и проектам, DevOps, дизайнеры пользовательского опыта (UX) и специалисты по обеспечению качества (QA) будут влиять на конечный результат и, следовательно, должны осознавать текущую дилемму безопасности приложений и способы решения этой проблемы.

Правильное интегрированное образование

Если команды не понимают зачем мышление, ориентированное на безопасность, настолько важно при разработке приложений, что они никогда не купятся на КАК это может быть достигнуто. Поэтому комплексное и непрерывное обучение безопасности приложений для всей организации-разработчика как никогда важно. Для тех, кто создает код, важно провести базовое обучение перед практическими упражнениями, непосредственно касающимися проблем, с которыми они сталкиваются ежедневно. Это специальное обучение для разработчиков должно проводиться параллельно с базовыми и расширенными программами обучения безопасности приложений для тех, кто играет роли в SDLC, которым может не обязательно требоваться практический опыт. Подобные инициативы позволят всей команде мыслить по-новому, принимать более обоснованные решения и интегрировать безопасность во все аспекты разработки.

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

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

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