Архив метки: VMprocess

VM-ный миф № 4: можно значительно улучшить процесс Управления Уязвимостями, если найти правильные слова для руководства

VM-ный миф № 4: можно значительно улучшить процесс Управления Уязвимостями, если найти правильные слова для руководства. Довольно часто поступают вопросы в духе: "как аргументированно обосновать необходимость выстраивания полноценного процесса Vulnerability Management в организации, а не выборочного устранения отдельных находок сканера?" Когда от руководства при этом звучат возражения вроде "у нас были инциденты только через фишинг, а не через эксплуатацию уязвимостей", "построение процесса требует новой штатной единицы и бюджета", "безусловный патчинг создаст огромные трудозатраты" и т.д.

Нет, ну в целом можно посоветовать использовать методологию результативной кибербезопасности и вместе с руководителем определить, что именно "болит" в организации - какие недопустимые события (слив критичных данных, кража денег, остановка бизнес-процессов, для реального сектора вплоть до техногенных катастроф) могут реализовать злоумышленники на целевых активах. Суть в том, что затраты на выстраивание процесса будут несопоставимо меньше потенциальных потерь от инцидента, способного обрушить прибыль компании на 30-40%, вынудить сокращать штат или закрыться. На возражение "нас ломали только через фишинг, а не через уязвимости" можно объяснить, что попав внутрь через фишинг, злоумышленник продвигается к важным системам именно через уязвимости. Можно предложить пентест, чтобы оффенсив-специалисты показали реальность проблем на практике. Для компаний, подпадающих под требования регулятора, можно апеллировать к нормативке, требующей постоянного выявления и устранения уязвимостей.

Да-да, это всё можно пробовать транслировать! Но возымеет ли "цыганочка с выходом" перед руководством в исполнении простого VM-щика какой-то эффект? Не хочу обесценивать вербальную коммуникацию как таковую, но, положа руку на сердце, я бы особенно не рассчитывал, что вы "слова найдёте такие нежные", способные кардинально изменить ситуацию с VM-ом в организации. По моему глубокому убеждению, Vulnerability Management снизу в принципе не внедряется. Нигде и никогда. Устранение уязвимостей для бизнеса и IT-шников - крайне невыгодная тема и огромный объём дополнительной работы, которую они готовы выполнять исключительно из-под палки, по прямому указанию высшего руководства.

На то, что ТОП-менеджмент организации может чего-то там не понимать, я бы тоже не вёлся. 😏 Люди, добравшиеся до этого уровня - как правило, умные, циничные и с отличным кругозором. Во всяком случае CIO и CTO. А уж тем более ваш родной CISO. Всё они понимают: и про атаки, и про уязвимости, и про возможный ущерб. Поэтому если VM-ная тема в организации недофинансируется и фактически саботируется - значит, всех всё устраивает. 😉 На этом сознательно экономят, рассчитывая на то, что:

🔻 VM-щик из подручного материала соберёт что-то похожее на работающий процесс и будет носиться как белка-истеричка, поддерживая его и затыкая собой дыры; 🤪

🔻 в случае инцидента сам же VM-щик и станет крайним. F 🫡

Поэтому, ИМХО, если руководство организации принципиально не готово выделять ресурсы на VM и насаждать его сверху, углубляться в разъяснения нерационально. "Если надо объяснять, то не надо объяснять". © Не хотят ТОПы работающего VM-процесса - значит, его не будет. Хотят пройти через критичный киберинцидент прежде чем внедрять базовые ИБ-процессы - значит, будет так. Плетью обуха не перешибёшь. VM-щику в такой организации вместо отчаянного евангелизма лучше потратить время на что-то более полезное. Резюме обновить например. 😉 А если смена работы не вариант - как минимум осознавать положение вещей, границы своих возможностей и стараться самому не подставляться почём зря.

VM-ный миф № 3: специалисты по Управлению Уязвимостями должны всегда стремиться к поиску компромисса с бизнесом и IT

1 комментарий

VM-ный миф № 3: специалисты по Управлению Уязвимостями должны всегда стремиться к поиску компромисса с бизнесом и IT. Когда мы с коллегами готовили вопросы итогового тестирования для очередного потока курса "Управление Уязвимостями: от теории к практике", один из предложенных вопросов там формулировался примерно так:

Обнаружена критическая уязвимость в сервисе на периметре, который выполняет некоторую бизнес-функцию. Признаков эксплуатации нет. Вендор рекомендует срочно обновить ПО и применить защитные меры. По регламенту устранение уязвимости должно быть выполнено за 24 часа. Руководитель ИТ просит продлить срок до 72 часов, так как команда занята другим релизом. Какое решение будет наиболее правильным с точки зрения процесса VM?

🔹 Предложить внедрить компенсирующие меры в компромиссный срок.
🔹 Апеллировать к регламенту и требовать перенести релиз, эскалируя вопрос руководству.
🔹 Согласиться на 72 часа из-за отсутствия признаков эксплуатации.
🔹 Изучить возможность эксплуатации уязвимости, совместно с SOC срочно ограничить доступ к уязвимому сервису.

Какой ответ считается правильным в тесте, я не скажу. 😉 Но ситуация более чем типичная и на ней, как мне кажется, хорошо демонстрируется правильный VM-ный майндсет.

Когда говорят про VM, обычно подчеркивают необходимость искать компромиссы и выстраивать конструктивное взаимодействие с командами, чтобы вместе достигать общих целей. И это во многом действительно так. Специалистам по VM важно доносить до владельцев систем критичность выявленных проблем и объяснять связанные с ними риски. Однако на другой стороне (в IT и бизнесе) тоже работают компетентные люди, которые действуют в рамках собственных приоритетов. Устранение уязвимостей приоритетной задачей для них, как правило, не является. Поэтому переносы сроков устранения под разными предлогами или даже отказы от устранения уязвимостей - явление вполне обыденное. 🤷‍♂️

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

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

"Вы VM-щики, вы должны были разбираться с этой уязвимостью. Мы в этом не специалисты и не обязаны в этом разбираться. Мы вообще не знали, что эту уязвимость нужно было устранять."

Попробуйте мысленно перенестись еще на один шаг вперед - представьте, что вы сидите на допросе, в весьма некомфортных условиях, вам в глаза светит лампа, и вы понимаете, что в своей работе что-то делали не так. Задайте себе вопрос: "Что помогло бы мне в этой ситуации? Что нужно было сделать, чтобы лично ко мне, VM-щику, не возникло вопросов?"

🔻 Если ваши коллеги из IT и/или бизнеса должны были устранять такого рода уязвимости, значит, должен быть документ, в котором прописано, какие типы уязвимостей они устраняют и в какие сроки. Эти сроки должны быть заранее согласованы и зафиксированы. Этой бумажной частью работы кто-то должен методично заниматься.

🔻 Если вы раньше знали об этой уязвимости (детектировали её в рамках сканов), значит, нужно было донести эту информацию до ответственного за устранение так, чтобы это было неотказуемо. Что значит неотказуемо? Не устно, не через мессенджеры и даже не через почту. По этой уязвимости должна существовать задача на устранение, назначенная на конкретного исполнителя, с указанием крайнего срока. Да, этот срок может быть сложно выдержать в реальных условиях, но формально и по руководящим документам он должен быть установлен. С вашей стороны всё, что нужно, должно было вылететь. Если срок устранения не был выдержан, нужно было показать свое деятельное участие: что вы пытались эскалировать проблему. Возможно, попытки эскалации все равно были бы безуспешными, но эти попытки необходимо фиксировать.

🔻 Если вы раньше не знали об этой уязвимости (НЕ детектировали её в рамках сканов), возникает вопрос: почему? Не занимались планомерным покрытием инфраструктуры регулярными сканами? Вместо качественных средств детектирования использовали быстрые? 😉 Аргумент "мы сканировали, но сканер нам ничего не показал" будет выглядеть в рамках разбирательства весьма слабо. Оценка качества детектирования - ваша задача.

И так далее. Эти формальные меры могут повысить шансы, что в случае неприятного инцидента простого VM-щика не сделают крайним: не посадят и не уволят с волчьим билетом.

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

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

Так что склоняюсь скорее ко второму варианту. И там уж как пойдет. Получится пропушить устранение в нормативное время, отлично. 👍 Не получится пропушить, но инцидента в растянутый срок устранения не произойдет, тоже норм. 👌 Если злодеи все-таки успеют пробить периметр организации в растянутый срок устранения и это приведет к критичному инциденту - плохо. 😔 Но в этой ситуации будет что показать приехавшим разбираться людям в погонах и будет чем аргументировать, что VM-щик сделал все, что мог.

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

VM-ный миф № 2: скорость сканирования активов на наличие уязвимостей является критически важным параметром для VM-решений

2 комментария

VM-ный миф № 2: скорость сканирования активов на наличие уязвимостей является критически важным параметром для VM-решений. Частенько вижу такой аргумент в маркетинге новых VM-вендоров: что, дескать, раньше сканирование больших инфраструктур превращалось в пытку, а теперь, с появлением их нового решения, всё будет супербыстро: "вжух - и готово". 🪄

У меня, глядя на такие заявления, всегда возникает вопрос: а с чего это вы вдруг такие быстрые? 🙂 Видимо по замыслу маркетологов, подобные мессаджи должны интерпретироваться потенциальными клиентами так: зрелые VM-решения на рынке и их новое VM-решение обеспечивают одинаковое качество детектирования уязвимостей (см. предыдущий миф про качество детектирования 😏), и при этом у нового VM-решения настолько лучше архитектура и настолько более оптимизированные правила детектирования, что скорость сканирования получается значительно выше. 💪🌝

Если вы всерьёз в такое верите, то, как говорят клятые англосаксы, I have a bridge to sell you. На самом деле объяснение, как правило, гораздо прозаичнее: новое VM-решение просто умеет выполнять гораздо меньше проверок на активе. 🤷‍♂️ Меньше проверок - быстрее сканирование. А на разницу в качестве получаемых результатов просто закрывают глаза. 🙈 Используя медицинскую аналогию из разбора прошлого мифа: МРТ там не делают; трубочкой послушали, "дышите - не дышите", вроде ок - давай до свидания.

Я, конечно, НЕ утверждаю, что сканирование одного актива по 10 минут - это однозначный показатель качества. Напихать sleep-ов большого ума не надо. 😏 Но если сканирование идёт слишком быстро, то это повод посмотреть, какая логика детектирования была реализована и достаточно ли этой логики для вашей конкретной инфраструктуры.

Если посмотреть на западные тренды развития Vulnerability Management, то там всё движется не к сокращению времени сканирования, а наоборот - к более глубоким проверкам без жёстких ограничений по времени. Цель - обнаружить максимум установленного ПО, модулей и библиотек независимо от того, где и как они установлены. А затем найти максимум уязвимостей в них. Чтобы это стало возможным, нужно уходить от детектирования в рамках ограниченных по времени сканов к работающим в фоне агентам, которые передают результаты по мере готовности. Такое непрерывное глубокое сканирование идёт столько, сколько требуется для получения наиболее полных и качественных результатов детектирования уязвимостей. Потому что если результаты детектирования неполные и некачественные, какой смысл в процессе Управления Уязвимостями? Что-то где-то нашли, что-то где-то устранили - сойдёт и так? 🙃

Ну а на активах, на которые невозможно установить агента, остаётся проводить сетевое сканирование (с аутентификацией и без). Но для того чтобы оно выполнялось в адекватное время, не нужно пытаться охватить одной сканирующей нодой всю инфраструктуру. Поставьте их несколько (в соответствии с рекомендациями VM-вендора), выполняйте задачи на сканирование параллельно и всё будет ок.

VM-ный миф № 1: качество детектирования уязвимостей у всех САЗ (Средств Анализа Защищённости) одинаковое

1 комментарий

VM-ный миф № 1: качество детектирования уязвимостей у всех САЗ (Средств Анализа Защищённости) одинаковое. Хочу сделать мини-серию постов о популярных заблуждениях относительно Vulnerability Management-решений и процессов. И начну с самого вредного, на мой взгляд. Что детектирование уязвимостей - это что-то не особенно сложное, и практически любой IT/ИБ-вендор может вкатиться в область VM и быстро выпустить решения с тем же качеством детектирования уязвимостей, что и у лидеров рынка.

По моему мнению, это обусловлено самой природой средств детектирования (в широком смысле). Такое средство получает доступ к некоторым активам для анализа, делает НЕЧТО, в результате чего клиент получает отчёт с обнаруженными проблемами. Как именно это НЕЧТО реализуется, по большому счёту остаётся за кадром. Это может быть какая-то примитивная логика, дающая результаты со множеством false positive и false negative-ошибок. А может быть чрезвычайно сложная логика, на реализацию, тестирование и поддержание которой тратятся внушительные ресурсы вендора.

Приведу аналогию из области медицины. Чтобы выявлять аномалии в лёгких человека, можно прослушивать их примитивной полой трубкой ("дышите - не дышите"). Можно прослушивать их, используя более продвинутый стетоскоп. 🩺 Но для более-менее серьёзных исследований требуются установки для рентгенографии, компьютерной томографии (КТ) или магнитно-резонансной томографии (МРТ).

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

В медицине ни у кого не набирается наглости выдавать обычный стетоскоп за современный аппарат МРТ или КТ.

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

Хочется надеяться, что постепенная стандартизация процесса детектирования уязвимостей, а также развитие программ (обязательной?) сертификации средств анализа защищённости с проверкой их функциональных возможностей, сделают продажу таких "котов в мешке" невозможной. 🙏 Но пока, к сожалению, оценка качества детектирования остаётся делом самих клиентов.

О правильном понимании термина "exposure" ("экспозиция") в контексте Exposure Management (Управление Экспозициями) и Continuous Threat Exposure Management (CTEM, Непрерывное Управление Экспозициями с учётом Угроз)

Добавить комментарий

О правильном понимании термина "exposure" ("экспозиция") в контексте Exposure Management (Управление Экспозициями) и Continuous Threat Exposure Management (CTEM, Непрерывное Управление Экспозициями с учётом Угроз). Я решил вернуться к этому вопросу, более-менее подробно описать историю использования термина "exposure", а также обосновать, почему я считаю корректным определять термин "exposure" как "уязвимость в широком смысле". Сделаю я это на основе своих выступлений и дискуссий на конференциях Security Summit, Территория Безопасности и Периметр, а также семинаре компании "Киберпротект", проходивших этой весной.

Повторюсь, что у меня к термину "exposure" отношение непростое. Был период, когда он мне категорически не нравился, и я выступал против его использования. Но постепенно, как в знаменитой книге Дейла Карнеги, я перестал беспокоиться и научился с ним жить. 🙂

🎓 (НЕ)Использование в академической ИБ

Когда мы говорим об уязвимостях ("vulnerability"), мы обычно понимаем под этим ошибки программного обеспечения, "баги", которые злоумышленники могут использовать для реализации своих зловредных целей. Всё у чего есть CVE или БДУ идентификатор - это уязвимость. При этом если посмотреть формальное определение уязвимости, то оно окажется гораздо более широким. У ФСТЭК это "слабость актива или управления, эксплуатация которой приведёт к реализации одной или нескольких угроз" (ISO/IEC 27000:2014) или "Недостаток (слабость) программного (программно-технического) средства или информационной системы в целом, который (которая) может быть использована для реализации угроз безопасности информации" (ГОСТ Р 56545-2015). В глосарии NIST самое популярное определение уязвимости, используемое в 17 документах, звучит так: "слабость в информационной системе, процедурах обеспечения безопасности системы, внутренних контролях или реализации, которая может быть эксплуатирована или задействована источником угрозы".

А откуда взялось "exposure"? Это слово очень многозначное как в самом английском языке, так и при переводе на русский. В зависимости от контекста его могут переводить как подвергание, выставление, выставка, местоположение, обнажение, вид и т.д.

В академической информационной безопасности термин "exposure" практически не используется. Если термин "vulnerability", согласно глоссарию NIST встречается в 39 документах, то термин "exposure" только в двух:

🔹 В документе NIST SP 800-161r1-upd1 Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations под "exposure" понимается "степень, в которой организация и/или заинтересованная сторона подвержена риску".

🔹 В документе NISTIR 8286 Integrating Cybersecurity and Enterprise Risk Management (ERM) под "exposure" понимается "комбинация уровней вероятности и воздействия для риска".

Несмотря на низкую академическую востребованность, термин "exposure" в настоящее время активно используется индустриальной ИБ-экосистемой (Gartner, крупные вендоры, консалтинговые и платформенные игроки), но в иных смыслах.

⚙️ Эпоха Tenable

Одним из главных популяризаторов термина стала компания Tenable, которая с 2017 года начала продвигать концепт "Cyber Exposure" как "новую развивающуюся дисциплину управления и измерения современной поверхности атаки, позволяющую точно понимать и снижать киберриски" (Tenable Delivers Record Results in Q2 and the First Half of 2017). Однако при описании этого "Cyber Exposure" они используют термин "exposure", не определяя его. 🤷‍♂️ "Cyber Exposure также обеспечивает непрерывную видимость того, где активы защищены, а где они находятся в состоянии exposure и в какой степени, а также приоритизирует устранение проблем на основе критичности актива для бизнеса и степени выраженности exposure". Себя Tenable начали называть "Cyber Exposure company".

Также в 2017 году Tenable представили Cyber Exposure ecosystem - интеграционную экосистему, объединяющую инструменты безопасности и IT (ServiceNow, AWS, Splunk и другие) для сквозного управления киберриском за счёт обмена данными, автоматического обнаружения активов и ускорения приоритизации и устранения уязвимостей на всей современной поверхности атаки.

К 2019 году у Tenable "Cyber Exposure" уже используется как измеряемая модель киберриска: в Tenable Lumin они вводят Cyber Exposure Score, который объединяет вероятность эксплуатации уязвимостей и критичность активов, позволяет количественно оценивать уровень "exposure", сравнивать его во времени и между организациями и использовать это для приоритизации устранения рисков и принятия риск-ориентированных решений.

Таким образом, можно сказать, что до начала 2020-х годов термин "exposure" в рамках материалов Tenable не имел единого фиксированного самостоятельного определения и использовался как "плавающий" термин-оболочка, которому в разных контекстах придавались различные значения: от обозначения новой дисциплины управления и измерения киберриска, до общей подверженности риску, состояния уязвимости активов, степени их "открытости" атаке, агрегированного риска (с учётом вероятности и ущерба), интеграции уязвимостей и конфигураций в единую модель, а также количественного скоринга для ранжирования и приоритизации устранения проблем. 🤯

Читать далее →

Каналу @avleonovrus "Управление Уязвимостями и прочее" сегодня исполнилось 4 года

Добавить комментарий

Каналу @avleonovrus "Управление Уязвимостями и прочее" сегодня исполнилось 4 года. Я календарь переверну и снова 3 июля. 🙂 Как 3 июля 2022 года я написал первый пост про необходимость скорейшей девестернизации российского IT, так и продолжаю, помимо основной темы про уязвимости и их детектирование, гнуть свою линию. За здоровый IT-лоялизм, за признание явных успехов, за поддержку наших в беде, за повышение наступательного киберпотенциала страны. Позиция эта довольно непопулярная. Особенно в недозаблокированной соевой ТэГэшечке, где в почёте бессовестный популизм и оголтелое критиканство, направленное против любых государственных инициатив. 🫠🤷‍♂️

Однако для меня очередной год писательства прошёл весьма успешно. Посты выпускал более-менее регулярно. Количество подписчиков ТГ-канала перевалило за психологически/юридически значимую отметку в 10к и достигло уже 11 600+. ТГ-канал получил почётный статус A+ и я зарегистрировал канал @avleonovrus в национальном мессенджере MAX. Там уже больше 500 подписчиков! 🔥 Просмотры/посещения на сайте avleonov.ru также выросли за год в 3-4 раза. Спасибо большое всем тем, кто подписан, читает, лайкает, комментирует и делится постами! 🙏

Я собираюсь и дальше проживать свою лучшую жизнь и с удовольствием делиться с вами своими мыслями про Управление Уязвимостями и прочее. 😇 В первую очередь планирую писать о том, что непосредственно связано с моей работой и моими около-VMными проектами (обзоры Microsoft Patch Tuesday, Linux Patch Wednesday, трендовых уязвимостей, VM-ных продуктов и изменений регуляторики), во вторую - о том, что происходит в мире Vulnerability Management-а и кажется мне по каким-то причинам важным или любопытным, а в третью - обо всём остальном, о чём посчитаю нужным: от ситуации со смартфончиками до семейного отдыха и ХудЛита. Потому что могу! 😉

А вот всерьёз заниматься развитием своего "личного бренда", стремиться к безудержному росту количества подписчиков любыми средствами, превращаться в желтушное недо-СМИ, транслирующее 24/7 нейрослопные пересказы новостей с претенциозной популистской подачей, я как-то не планирую. 😅🤷‍♂️

Погнали в следующий год!

Руководители национальных агентств кибербезопасности альянса Five Eyes (США, Великобритания, Канада, Австралия и Новая Зеландия) призвали ускорить устранение уязвимостей, отказаться от легаси-систем и навести порядок на периметре

1 комментарий

Руководители национальных агентств кибербезопасности альянса Five Eyes (США, Великобритания, Канада, Австралия и Новая Зеландия) призвали ускорить устранение уязвимостей, отказаться от легаси-систем и навести порядок на периметре. AI радикально ускоряет и усложняет киберугрозы: атаки становятся быстрее, масштабнее и доступнее для злоумышленников, а время между обнаружением уязвимости и её эксплуатацией сокращается всё сильнее. Frontier AI (самые передовые и мощные модели искусственного интеллекта, находящиеся на границе текущих возможностей ИИ и задающие новый уровень развития) уже сейчас меняет баланс сил в киберпространстве, одновременно усиливая как возможности атакующих, так и обороняющихся. При этом киберриски перестают быть чисто технической проблемой и становятся критическим бизнес-риском, требующим внимания руководства и советов директоров.

Организации должны усиливать базовые практики кибербезопасности, повышать устойчивость ("resilience") и активно внедрять AI в защиту - для раннего выявления уязвимостей, анализа аномалий и ускорения реагирования на инциденты. Успех зависит не от количества инструментов, а от качества базовой кибердисциплины, скорости реакции и интеграции безопасности в стратегию бизнеса. Те, кто НЕ адаптируется быстро, столкнутся с растущими операционными и стратегическими рисками.

Ключевые действия для руководителей

Основные принципы:

🔻 Подход secure-by-design и secure-by-default должен стать стандартной практикой, а не просто декларируемым стремлением ("aspiration").
🔻 Устойчивость не может зависеть от одного решения или технологии. Многоуровневая защита ("defence in depth") остаётся необходимой.
🔻 По мере развития AI-систем будут появляться новые и ранее неизвестные уязвимости, включая zero-day уязвимости.
🔻 Инциденты ("breaches") будут происходить. Подготовка помогает быстро их локализовать и не допустить перерастания в серьёзные операционные и финансовые кризисы.

Практические действия

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

🔸 Сократите поверхность атаки: ограничьте ненужный доступ к системам и внешние подключения. Оценивайте, действительно ли системы должны быть доступны извне, и изолируйте те, которым это не требуется.
🔸 Ускорьте процессы установки патчей: AI сокращает время между обнаружением уязвимости и её эксплуатацией. Задержки с обновлениями увеличивают риск, особенно для производственных ("operational") систем с длинными циклами обновления. Приоритизируйте обновления безопасности соответственно.
🔸 Решайте проблему устаревших систем: неподдерживаемые системы - лёгкие цели. Это не просто технический долг, а стратегические обязательства ("liabilities").
🔸 Пересмотрите и усилите контроль идентификации и доступа: ограничьте, кто может получать доступ к критическим системам. Внедряйте строгую аутентификацию и регулярно пересматривайте права доступа.
🔸 Подготовьтесь к инцидентам заранее: тестируйте планы реагирования, обучайте команды и исходите из того, что взломы неизбежны. Фокус - на быстром сдерживании ("containment") и восстановлении.

Как видите, VM-ная тема, в связи с бурным развитием технологий ИИ, актуальна для англосаксов как никогда. 😎 И нам тоже стоит к этим призывам прислушаться. 😉