Логотип Зефирнет

Минимально эффективное соблюдение требований: о чем следует заботиться и почему

Дата:

В сфере ИТ-безопасности мы должны заботиться обо всем. Любая проблема, даже самая маленькая, может стать средством удаленного выполнения кода или, по крайней мере, точкой приземления для злоумышленников, которые смогут жить за счет земли и направить наши собственные инструменты против нас. Неудивительно, что сотрудники ИТ-безопасности сталкиваются с выгоранием и стрессом. В соответствии с исследование Enterprise Strategy Group и ISSA, около половины специалистов по ИТ-безопасности думают, что оставят свою нынешнюю работу в ближайшие 12 месяцев.

Команды безопасности несут профессиональную ответственность, и теперь директора по информационной безопасности (CISO) личная ответственность — для безопасности своих организаций. Однако в других областях ИТ и технологий существует совершенно иное мышление. Из мантры Марка Цукерберга «двигаться быстро и ломать вещи» вплоть до Эрика Райса Lean Startup и модели минимального жизнеспособного продукта (MVP), идея в этих областях заключается в том, чтобы двигаться быстро, но при этом предоставлять ровно столько, чтобы организация могла двигаться вперед и совершенствоваться.

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

Что будет включать в себя MVC?

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

Для управления активами в идеале вам необходимо знать все установленные вами активы. Без такого уровня надзора как вы можете считать себя в безопасности? Для подхода MVC вам понадобится 100% понимание того, что у вас есть?

На самом деле проекты управления активами, такие как базы данных управления конфигурациями (CMDB), направлены на предоставление полная видимость ИТ-активов, но они никогда не бывают на 100% точными. В прошлом точность активов колебалась в пределах от 70% до 80%, и даже самые лучшие сегодняшние развертывания не могут обеспечить полную прозрачность и поддерживать ее на этом уровне. Итак, стоит ли нам тратить бюджет MVC на эту область? Да, но не совсем так, как мы традиционно думаем.

Один заместитель директора по информационной безопасности сказал мне, что он понимает идеал полного освещения, но это невозможно; вместо этого он заботится о полной и постоянной прозрачности критически важной инфраструктуры организации (около 2.5% от общего объема активов), в то время как другие рабочие нагрузки отслеживаются как можно чаще. Таким образом, хотя прозрачность по-прежнему является необходимым элементом программ ИТ-безопасности, усилия должны быть направлены в первую очередь на защиту активов с самым высоким риском. Однако это краткосрочная цель, поскольку всего одно раскрытие уязвимости отделяет вас от того, чтобы актив с низким уровнем риска стал активом с высоким риском. Проходя этот процесс, не путайте соблюдение требований с безопасностью — это не одно и то же. Соответствующий требованиям бизнес может оказаться небезопасным.

Планирование регулирования

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

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

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

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

Spot_img

Последняя разведка

Spot_img