В современных условиях защита программного обеспечения на всех этапах разработки от написания кода до развёртывания — это уже не вопрос выбора, это необходимость. Число киберугроз увеличивается, они усложняются, поэтому важно иметь комплексную стратегию безопасности ПО, которая поможет организации противостоять актуальным техникам кибератак.
При всей критической важности безопасность ПО по-прежнему остаётся сложной задачей для многих компаний. Вокруг этой темы существует немало заблуждений, мешающих выстраивать эффективную защиту. В этой статье мы разберем пять типичных мифов о безопасности ПО, развенчаем их и дадим рекомендации, как сделать вашу инфраструктуру безопаснее.
В этой статье:
- Заблуждение 1: «Безопасности через сокрытие достаточно»
- Заблуждение 2: «Мой бизнес слишком мал, чтобы стать целью кибератак»
- Заблуждение 3: «Риски несут только внешние угрозы»
- Заблуждение 4: «Безопасность замедлит разработку»
- Заблуждение 5: «За безопасность отвечает только команда безопасности»
Заблуждение 1: «Безопасности через сокрытие достаточно»
«Безопасность через сокрытие» (security through obscurity) — это подход, при котором делают ставку на скрытность как на основной способ защиты. Предполагается, что злоумышленники не смогут найти уязвимости, если не знают, какую операционную систему (ОС) вы используете, на каком оборудовании она работает, на каком языке написано приложение и т. д. Однако у этого подхода есть фундаментальные ограничения: например, он мешает внедрять политики вроде “Zero Trust”.
Главная проблема такого подхода в том, что он создаёт ложное чувство защищённости. Гораздо важнее следить за актуальностью процедур безопасности и поддерживать их в состоянии, позволяющем противостоять потенциальным угрозам. Кроме того, не всех атакующих остановит недостаток информации о целевой системе. Как только «секреты» раскрываются, ставка на скрытность делает организацию уязвимой. Более надежный вариант — сохранять прозрачность и развивать сотрудничество между командами безопасности и инженерной командой: это усиливает защиту и помогает не отставать в противодействии новым угрозам.
Голландский криптограф Огюст Керкгоффс в своей книге «Военная криптография» 1883 года описал принцип, согласно которому в засекреченном виде должна быть только малая часть системы, которую сейчас мы называем ключами, токенами, секретами и паролями.
Заблуждение 2: «Мой бизнес слишком мал, чтобы стать целью кибератак»
Одно из самых опасных заблуждений — считать, что киберпреступники атакуют только крупные организации. Малый и средний бизнес тоже уязвимы: 43% кибератак направлены на малые компании, из которых лишь 14% подготовлены к кибератакам. Киберпреступники часто выбирают небольшие организации, потому что у них обычно нет продуманных мер кибербезопасности и полноценного обучения безопасности. Иногда небольшие организации рассматриваются хакерами как способ подступиться к более крупной компании.
Мораль сей басни? Малому и среднему бизнесу стоит уделять внимание безопасности ПО. Это, наряду с другими мерами, означает, в частности, разработку комплексного плана кибербезопасности, регулярное обучение сотрудников и своевременное обновление программ, приложений, браузеров и ОС.
Заблуждение 3: «Риски несут только внешние угрозы»
В сфере кибербезопасности есть распространенное мнение, что все угрозы приходят извне. Поэтому защитные меры часто строятся против внешних атак, а внутренние риски остаются без должного внимания. Однако согласно отчёту Verizon Data Breach Investigations Report за 2023 год, 74% всех утечек связаны с человеческим фактором: ошибки работников, злоупотребление привилегиями, использования украденных учётных данных или социальной инженерии. В таких условиях ключевым может стать принцип наименьших привилегий. Это, прежде всего, ограничение доступа сотрудников базовым минимумом прав. Мы призываем выстраивать защиту от внутренних угроз наряду с защитой от внешних.
Заблуждение 4: «Безопасность замедлит разработку»
Организации нередко откладывают внедрение рекомендации по безопасности из-за опасения, что это задержит выход продукта на рынок и помешает развитию технологий. Да, учёт требований безопасности увеличивает расходы, но внедрение мер защиты на ранних этапах поможет избежать дорогих исправлений потом. Итеративное развитие такого аспекта системы, как информационная безопасность продукта, также является частью жизненного цикла разработки ПО (Software Development Lifecycle, SDLC).
Здесь уместна концепция Shift Left. Организации со зрелыми процессами разработки понимают, что слабые места могут возникать на каждом этапе жизненного цикла. Shift left помогает выявлять и предотвращать проблемы с помощью автоматизации, управленческих процедур и доверия к разработчикам, что в итоге может ускорить разработку и повысить качество ПО. Своевременное внедрение проактивных мер безопасности снижает объём работ по устранению проблем и уязвимостей в авральном режиме, а также заметно уменьшает выгорание разработчиков.
Заблуждение 5: «За безопасность отвечает только команда безопасности»
Безопасность ПО — командная работа. У инженерных команд есть соблазн “забыть” про безопасность и сосредоточиться на разработке, но по мере усложнения приложения усложняются и появляются новые векторы атаки. Поэтому важно, чтобы безопасность стала общей задачей.
Среда, где безопасность — элемент культуры, помогает сократить поверхность атаки и защитить организацию. На исправления после инцидента разработчики часто тратят больше времени, чем хотелось бы. Вместо этого для достижения хороших результатов команде безопасности и команде разработчиков стоит работать сообща. Продуманный план разработки и выпуска уменьшает число проблем на внедрении и эксплуатации.
В Axiom JDK, мы понимаем, что одним из самых легкодоступных векторов атаки для злоумышленника являются известные уязвимости в неподдерживаемых версиях используемых open-source технологий. Чем дольше система использует такой код без обновлений, тем больше CVE там будет обнаружено и опубликовано. Всё хорошо, пока мейнтейнер поддерживает версию, которую вы используете, но обычно они фокусируются на так называемой upstream-ветке и старые релизы быстро перестают поддерживаться. Так же дела обстоят и со Spring. Минорные релизы поддерживаются не больше года. Если нужно дольше, то покупайте коммерческую поддержку. В России приобрести поддержку у Broadcom нельзя, зато можно у Axiom JDK. Мы поддерживаем Spring Boot LTS самых популярных версий Spring Boot — 2.7 и 3.5.
