С другой стороны, дни безопасности как нахлебника ИТ подходят к концу, по крайней мере, в больших организациях,
считает Кевин Кейси, автор статей на ресурсе Red Hat для ИТ-директоров.

В отчете Red Hat Global Tech Outlook 2021 безопасность названа приоритетом номер один при финансировании ИТ, 45% респондентов указали на нее как на главное направление финансирования.

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

Кевин Кейси называет четыре проблемы, о которых следует помнить в 2022 году.

1. Базовые модели

Если бы у информационной безопасности был альбом лучших хитов, элементарная гигиена ИБ стала бы первой дорожкой. Из года в год главную причину многих инцидентов безопасности можно проследить до самых основ. Широкий спектр угроз, от программ-вымогателей до взлома облачных учетных записей и утечки данных, во многом обязан своей эффективностью удивительно простым ошибкам: от неправильных настроек (или даже настроек по умолчанию, оставленных без изменений) до чрезмерных привилегий пользователя и непропатченного ПО.

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

Аладдин Элстон, считает, что базовыми являются управление обновлениями, безопасная конфигурация, моделирование угроз, сканирование DAST и SAST, сканирование внутренних и внешних уязвимостей, тестирование на проникновение, защита от фишинговых атак, сторонняя оценка уязвимостей, резервное копирование и аварийное восстановление.

Есть много хороших инструментов и технологий безопасности и они как никогда необходимы, особенно те, которые позволяют автоматизировать безопасность. Однако мышление «у нас есть все инструменты» может привести к тому, что люди будут игнорировать основные потребности в безопасности или просто предполагать, что о них кто-то позаботится.

2. Вы не можете приоритезировать всё

Рассмотрите возможность (повторного) проведения анализа пробелов в вашей организации как части программы возврата к базовым вещам, особенно если вы не завершили ее ранее. Элстон указывает на множество внешних фреймворков, которые вы можете использовать. В соответствующих случаях применяются нормативные правила (например, HIPAA или PCI).

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

Люди и организации иногда теряются в ландшафте угроз. Список рисков и уязвимостей, которые вы обнаруживаете в своей компании, особенно если копаться во внешних фреймворках или других ресурсах, охватывающих известные угрозы и CVE, может показаться бесконечным. Вам нужно уменьшить этот список до нужного размера. Если вы попытаетесь решить все проблемы, вы рискуете ничего не защитить, особенно с учетом того, что потенциальные угрозы растут из года в год. Элстон рекомендует начать с того, чтобы определить первых 20% в этом списке.

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

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

Элстон также подчеркивает важность создания внутреннего канала, в котором разные люди и команды могут общаться и сотрудничать по вопросам безопасности. Это то, что вы можете (и должны) сделать, если не используете подход DevSecOps. «К счастью, с помощью программ ответственного раскрытия (responsible disclosure) информации, краудсорсинга и тестирования на проникновения многие уязвимости могут быть обнаружены на ранней стадии и быстро исправлены», – говорит Элстон.

3. Цепочки поставок

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

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

«Большая часть программного обеспечения, которое пишут организации, зависит от софта, полученного из других источников, в том числе загруженного из Интернета», – говорит технологический евангелист Red Hat Гордон Хафф. «Большая часть кода не является вредоносным, но, как и все программное обеспечение, он может содержать ошибки или быть просто старой версией».

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

Хафф отмечает, что отраслевые группы, такие как Open Source Security Foundation (OpenSSF), уже решают проблемы цепочки поставок в глобальном масштабе. Но ИТ-специалистам нужно будет донести это до своих собственных организаций.

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

Кирстен Ньюкомер, директор по облачным технологиям и стратегии DevSecOps Red Hat видит еще одну проблему производства и цепочки поставок, возникающую в ИТ: спецификацию программного обеспечения(software bill of materials – SBOM).

«Предлагаемые стандарты SBOM существуют уже довольно давно, но из-за проблем, связанных с безопасностью цепочки поставок, мы достигли точки, когда всем организациям нужно будет выяснить, как предоставить спецификацию», – говорит Ньюкомер, добавляя, что в отрасли будут проводиться обсуждения и дебаты по поводу статических и динамических спецификаций. Последняя будет включать данные об уязвимостях: сам программный пакет не меняется, но меняются известные уязвимости, связанные с этим пакетом.

4. Всё о данных

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

По словам Гала Дискина, технического директора и соучредителя Authomize, организациям следует уделять приоритетное внимание инструментам и стратегиям, таким как контроль доступа на основе ролей и нулевое доверие, иначе они сильно рискуют. Дискин рекомендует постоянно оптимизировать все, что связано с идентификацией и управлением доступом. Применяйте образ мышления «предположим, что вас взломали»: предположите, что ваши облачные учетные записи, от инфраструктуры до SaaS и не только, в какой-то момент будут взломаны.

«Вы должны ожидать, что корпоративные учетные записи будут скомпрометированы, и соответствующим образом спланировать свою стратегию безопасности, – говорит Дискин, – Защищайтесь глубоко и используйте инструменты, которые могут помочь ограничить «радиус взрыва» при взломе учетных записей. Убедитесь, что вы постоянно проверяете доступ не только на уровне простой аутентификации, но и на уровне детальной авторизации».

Мелинда Уоттс, глава отдела глобальных услуг в ZL Technologies ожидает, что группы безопасности, которые в прошлом были сосредоточены на инфраструктуре, в будущем году будут уделять больше внимания данным, которые хранятся в этой инфраструктуре или проходят через нее.

В частности, Уоттс прогнозирует, что организации будут уделять больше внимания своим скрытым данным с точки зрения безопасности. «DevSecOps уже давно придерживается нисходящего подхода к безопасности, обеспечивая безопасность инфраструктуры хранения – облачной или локальной, – говорит Уоттс, – Однако в 2022 году мы увидим, что эта работа будет дополнена восходящим подходом, при котором предприятия вновь сосредоточатся на безопасности данных, хранящихся в этих системах».

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

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