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

Эта разница важна не только ИТ- или ИБ-специалисту. Юристу придется согласовывать договор и состав работ, руководителю — бюджет, бухгалтерии или закупкам — сравнивать предложения. А бизнесу в итоге нужен ответ на конкретный вопрос: выполняются ли требования, где есть слабые места и что исправлять в первую очередь.

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

Если руководитель спрашивает:

«Мы действительно выполняем требования и наши меры защиты работают?»

скорее всего, нужен аудит.

Если вопрос звучит так:

«Какие сценарии могут сильнее всего ударить по бизнесу и куда направить бюджет?»

то это уже задача оценки рисков.

Из-за этой разницы нельзя заранее сказать, что один формат глубже или полезнее другого. Они решают разные задачи.

Аудит начинается не с поиска «страшных» угроз, а с критериев проверки.

Аудитор выясняет, чему должна соответствовать система: требованиям законодательства, отраслевым нормам, внутренним политикам, договорным обязательствам или заданной модели защиты. Затем собирает свидетельства и сравнивает требования с реальностью.

В периметр могут входить:

• архитектура информационных систем;

• управление учетными записями и доступом;

• журналирование;

• резервное копирование;

• реагирование на инциденты;

• подрядчики;

• средства защиты;

• локальные документы и реальные процессы их исполнения.

Здесь часто обнаруживается первая неприятная вещь: наличие регламента еще ничего не доказывает.

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

Именно поэтому нормальный аудит опирается на проверяемые свидетельства, а не на уверенные ответы, что все уже настроено.

Для такой задачи Б-152 проводит технический аудит информационных систем: специалисты проводят интервью, изучают документы и архитектуру, проверяют фактическое состояние систем и фиксируют несоответствия.

Представьте, что вы отправили двум подрядчикам запрос: «Нужен аудит ИБ компании».

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

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

1. Что именно проверяем.

2. По каким критериям.

3. Насколько глубоко заходим в техническую часть.

4. Что хотим получить на выходе.

Без этого один подрядчик может продать проверку документов, другой — полноценное обследование, а в закупке они будут стоять в одной строке «аудит ИБ».

Не сравнивайте предложения на проверку только по цене

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

Определите объем проверки до запроса предложения

Специалисты Б-152 помогут определить, нужен аудит, оценка рисков или их связка и какие работы стоит включить в техническое задание.

Оценка рисков нужна, когда компания уже понимает текущее состояние, но должна решить, чем заниматься в первую очередь.

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

Например, компания переезжает из собственной инфраструктуры в облако.

Аудит может проверить, как сейчас настроены доступы, резервное копирование и журналирование.

Оценка рисков задаст другие вопросы:

• что изменится после миграции;

• какие новые зависимости появятся;

• где проходит граница ответственности между компанией и провайдером;

• кто получает административный доступ;

• что произойдет при недоступности сервиса;

• как компания заберет данные при прекращении договора.

То есть здесь мало проверить конфигурацию. Нужно оценить возможные сценарии и последствия для бизнеса.

Одна из частых ошибок — заранее объявить риск «высоким», «средним» или «низким», не договорившись о критериях.

В NIST SP 800-30 отдельно подчеркивается, что организация должна определить подход к оценке вероятности, допущения, источники информации и основания для выводов.

На практике до оценки стоит согласовать:

• шкалу вероятности;

• критерии последствий;

• допустимый уровень риска;

• подход к неопределенности;

• способ документирования оценок.

Иначе число в реестре рисков выглядит убедительно, но руководитель не понимает, почему один сценарий получил 8 баллов, а другой 4.

Аудит полезен, когда компании нужна подтвержденная картина текущего состояния.

Типовые ситуации:

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

После инцидента. Требуется выяснить, какие меры сработали, какие нет и что нужно исправить.

Перед крупными изменениями. Например, миграцией, реорганизацией инфраструктуры или сменой подрядчика.

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

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

Риск-анализ полезнее, когда исходная картина уже известна, но нужно принять решение.

Например:

• какую систему защищать в первую очередь;

• куда направить ограниченный бюджет;

• насколько опасен переход в облако;

• можно ли принять определенный риск;

• какие меры действительно снизят значимые для бизнеса последствия;

• что изменится после подключения нового подрядчика.

То есть аудит дает факты, а оценка рисков помогает расставить приоритеты вокруг этих фактов.

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

В такой ситуации последовательность логична:

сначала аудит → затем оценка рисков → затем план работ.

Например, компания считает, что резервирование настроено для всех критичных систем. Аудит показывает, что часть сервисов не входит в резервное копирование, а восстановление никогда не тестировалось.

После этого оценивать риск недоступности уже можно на фактических данных, а не на предположении «резервная копия у нас есть».

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

Пентест отвечает еще на один отдельный вопрос:

можно ли практически реализовать согласованный сценарий атаки в заданном периметре?

Поэтому пентест, аудит и оценку рисков нельзя считать разными названиями одной услуги.

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

Результаты пентеста или анализа уязвимостей при этом могут стать входными данными для аудита и риск-анализа.

Хороший результат аудита, вопреки общим представлениям, — это не список из десятков замечаний без контекста.

Компания должна понимать:

• что именно проверяли;

• на каких свидетельствах построены выводы;

• где обнаружены недостатки;

• к каким системам и процессам они относятся;

• что исправлять;

• кто может стать владельцем задачи.

После оценки рисков нужна другая картина: сценарий, затронутые активы, вероятность, последствия, существующие меры и приоритет обработки.

Рекомендация по усилению защиты бесполезна.

Формулировка «включить MFA для административного доступа в систему X, владелец — ИТ, срок — квартал» уже может попасть в план работ.

Для систем с персональными данными техническую проверку иногда стоит связать с privacy-контуром.

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

В такой ситуации техническую часть можно дополнить аудитом соответствия требованиям 152-ФЗ, а выявленные расхождения закрывать через актуализацию документов по 152-ФЗ.

Если процессов много, карту целей, систем, сроков и ответственных можно поддерживать в Privacy Box.

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

Внешняя команда полезна, если внутри не хватает времени на интервью и сбор свидетельств, инфраструктура распределена или подразделения по-разному описывают одни и те же процессы.

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

Перед выбором подрядчика спросите:

• какой периметр войдет в работу;

• какие методы проверки будут применяться;

• какие доступы понадобятся;

• кто войдет в команду;

• какие документы вы получите;

• насколько детально будут подтверждены выводы.

Эти вопросы обычно помогают понять объем работы лучше, чем название услуги в коммерческом предложении.

Нужно узнать, что реально происходит сейчас — начинайте с аудита.

Нужно понять, что может произойти и куда направить ресурсы — нужна оценка рисков.

Есть сомнения в исходных данных — сначала подтвердите их аудитом, затем стройте риск-анализ.

Нужно проверить, можно ли практически реализовать техническую атаку — рассматривайте пентест.

Главная ошибка здесь не в выборе методологии. Она возникает раньше, когда компания покупает услугу, не сформулировав вопрос, на который должен ответить результат.

Нет. Аудит подтверждает фактическое состояние защиты относительно заданных критериев, а оценка рисков рассматривает возможные сценарии, вероятность и последствия.

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

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

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

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

Периметр, критерии, свидетельства, выявленные несоответствия, их привязка к системам и процессам и практические рекомендации. Желательно сразу обозначать владельцев и приоритеты работ.

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

Реклама: ООО «Б152», ИНН 5050091524, erid: 2W5zFGjfjrH