Это те дроиды, которых вы ищете

Существует старая руководящая фантазия, которая звучит примерно так: директор по информационной безопасности (CISO) осматривает обширный технологический ландшафт, обнаруживает 11 инструментов, выполняющих работу четырех, рассчитывает экономию на лицензировании, выбирает новую стратегическую платформу и объявляет о начале консолидации. Через шесть месяцев все 11 инструментов все еще работают. Новая платформа становится уже двенадцатой.

Я видел вариации этого на протяжении всей своей карьеры, от финансовых услуг до медиа и технологических компаний. В CME Group я в конечном итоге присвоил себе неофициальный титул: директор по выводу из эксплуатации. Работа была значительно менее гламурной, чем предполагала аббревиатура. Мне приходилось находить технологии, которые пересидели свое время, определять, кто считал, что все еще владеет ими, выяснять, кто на самом деле от них зависел, и, иногда, «пристреливать» их.

Покупка технологий — это легко. Устранение технологий — это сложно. Разрастание инструментов редко является просто технологической проблемой, а скорее проблемой организационной психологии. Традиционным решением отрасли была консолидация. Покупка платформы. Стандартизация стека. Сокращение числа поставщиков и централизация закупок. Хотя все это разумные идеи, усилия по консолидации обычно застревают где-то между слайдом PowerPoint и производством.

Почему? Потому что изменение набора инструментов — это легко. А изменение мышления гораздо сложнее.

Вы не можете использовать «джедайский трюк разума» на инженерной команде

Руководителям нравится то, что называется «посылом сверху». Генеральный директор говорит, что безопасность важна. ИТ-директор заявляет, что все будут стандартизироваться. Директор по информационной безопасности объявляет о стратегической платформе. Отдел закупок пересматривает контракты. Тем временем Gartner выпускает квадрант, который успокаивает всех, что выбранный поставщик занимает правильный геометрический регион. Все хорошо в мире гольф-клубовского кумовства.

Затем наступает реальность. Разработчик говорит, что новый сканер работает на 12 минут дольше. Менеджер по маркетингу имеет устаревший API, генерирующий доход, от которого он зависит. В течение нескольких лет подавались запросы на исключения, чтобы позволить этому инструменту продолжать существовать, несмотря на то, что пакеты, поддерживающие его, устарели и не получают обновлений безопасности. Вот где важен «посыл из середины».

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

Игнорируйте средний слой организационной структуры, и ваш проект консолидации станет довольно дорогим упражнением в «shelfware» (неиспользуемое ПО). Это то, что я узнал, работая в европейских организациях, где построение консенсуса имеет больший организационный вес, чем инстинкты командования и контроля, распространенные в американских корпорациях (философия управления в стиле Nike «Просто сделай это!»). У вас может быть *авторитет* принять решение, не имея организационного *разрешения* (или контекста «реальной жизни»), необходимого для того, чтобы оно прижилось или заслуживало реализации.

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

Каждый инструмент имеет свою идентичность

Метафора из «Звездных войн» становится более полезной, когда мы перестаем думать о продуктах безопасности как о программном обеспечении. Современные инструменты безопасности имеют волю и намерение. Они имеют:

• API-ключи
• Сервисные учетные записи
• OAuth-разрешения
• Облачные разрешения
• Токены доступа GitHub
• Интеграции CI/CD
• Боты Slack
• Вебхуки
• Учетные данные базы данных
• Роли Kubernetes
• Машинные идентификаторы и,

все чаще, ИИ-агенты действуют с повсеместными и постоянными делегированными человеческими полномочиями.

Каждый раз, когда мы внедряем продукты безопасности, мы порождаем еще одну учетную запись с высокими привилегиями. Отрасль бесконечно говорит о человеческой идентичности. Кто этот человек и к чему ему разрешен доступ? Мы явно гораздо менее дисциплинированы в отношении делегированной идентичности. Что это приложение может делать от имени Майка? Что этот сканер может читать из GitHub? Какие репозитории может изменять эта интеграция? Какие учетные данные мы дали старому поставщику три года назад? И все более важный вопрос: когда действует автономный агент, чьи полномочия он на самом деле осуществляет? Это меняет экономику разрастания инструментов. Стоимость двенадцатого инструмента безопасности — это не просто еще одна годовая подписка. Это еще одни (потенциально ошибочные) доверительные отношения.

Вот почему я выступаю за вывод из эксплуатации как основную дисциплину безопасности. Технологические организации страдают от предвзятости бессмертия. Я провел «Лучшую сессию» на эту тему на RSAC весной. У нас есть сложные процессы создания вещей и удивительно примитивные процессы их исчезновения. Жизненный цикл разработки программного обеспечения обычно иллюстрируется как планирование, проектирование, разработка, тестирование и развертывание. Диаграмма часто заканчивается там, как будто каждое развернутое приложение впоследствии живет долго и счастливо. Это не так.

Консолидация без вывода из эксплуатации — это умножение

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

Представьте, что вы заменяете три инструмента одной платформой, но оставляете все три продукта технически работоспособными «временно». Сервисные учетные записи остаются. Кто-то все еще входит в них. Поздравляем! Вы консолидировали не четыре инструмента в один, а скорее три инструмента в четыре. Это различие становится важным, поскольку продукты безопасности приобретают автономные возможности. Вчерашняя забытая панель управления становится завтрашним забытым агентом с разрешением на действия. Приложение-зомби — это уже плохо, но приложение-зомби с возможностью действовать — еще хуже.

Спросите людей, которые фактически используют дроидов

Противоядие — не более сильный центральный контроль, а явное владение. Матрица RACI в помощь? Прежде чем заменять инструмент, найдите людей, которые его используют, и задайте до смешного простой вопрос: «Для чего вы на самом деле его используете?» Не спрашивайте, что говорит контракт. Не доверяйте тому, что может показать диаграмма архитектуры (*но* проверьте дату последнего изменения).

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

Вот где средний уровень организации становится вашей настоящей разведывательной сетью. Люди, наиболее близкие к системам, знают, где живут недокументированные зависимости. Относитесь к ним как к препятствиям, и они будут защищать свои инструменты. Но позвольте им стать участниками, и они помогут их демонтировать. Хорошая перспектива при планировании «убийства чьего-то ребенка» — помочь им понять, что они влюбились в контроль, который инструмент дал им над хаосом, царившим до его внедрения. И что новый инструмент может быть таким же удобным и более простым в поддержке, чем бремя ухода и обслуживания, которое требуют большинство «наследуемых» (я предпочитаю этот термин, чем «устаревших») приложений и решений.

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

CISO как директор по выводу из эксплуатации

Каждый CISO должен провести время в роли CDO. Не Chief Data Officer (директор по данным). А Chief Decommissioning Officer (директор по выводу из эксплуатации). Эта роль требует задавать неудобные вопросы, потому что почти каждый стимул в технологиях поощряет добавление. Никто не получает пресс-релиз или повышение за отключение чего-либо. Но устойчивость частично является вычитательной.

Каждый устраненный избыточный поставщик — это еще одна компания, хранящая ваши данные, и еще одна административная консоль, на которую может нацелиться и которую может взломать злоумышленник. Наша отрасль тратит миллиарды, спрашивая: «Что еще мы должны развернуть?» Зрелые организации также спрашивают: «Что мы можем безопасно устранить?» Второй вопрос становится гораздо более важным с появлением агентивного ИИ.

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

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

Не «проходите мимо»

В следующий раз, когда кто-то придет с чудесной новой платформой, обещающей устранить половину вашего стека, сопротивляйтесь желанию махнуть рукой и сказать: «Это не те дроиды, которых мы ищем». Они вполне могут быть. Но прежде чем покупать больше дроидов, выясните, кто владеет теми, которые уже бродят по вашей Звезде Смерти. Найдите их. Назовите их. Поймите, какие полномочия вы им дали. И когда их миссия будет выполнена, осмельтесь отключить их. Создайте «кладбище технологий» на своем вики, Confluence или SharePoint и празднуйте добавление выведенных из эксплуатации инструментов и технологий с еще большим рвением, чем те, которые только что появились.