Аудит кибербезопасности — это проверка на основе доказательств того, насколько правильно спроектированы средства защиты организации и как они работают на практике, оцениваемая по заданному набору критериев. Критериями могут быть стандарт, нормативный акт или договор с клиентом, и этот выбор определяет все остальное: область охвата, доказательства, аудитора и результат.
Для растущей софтверной компании разумный вопрос обычно заключается в том, какого именно аудита требует конкретное обстоятельство — например, опросник клиента, требования к обработке платежных данных или регуляторные требования к покупателю, — и какую часть работы можно выполнить собственными силами.
Что такое аудит кибербезопасности и почему он важен?
Аудит кибербезопасности — это систематическая проверка средств защиты, политик и конфигураций организации на основе доказательств в соответствии с определенным стандартом, которая завершается документированием выявленных несоответствий. В качестве стандарта может выступать NIST Cybersecurity Framework (CSF) 2.0, ISO/IEC 27001:2022 или договор с клиентом.
Аудит разделяет проектирование средств защиты и их операционную эффективность, выявляя, например, проверки доступа, которые задокументированы, но никогда не проводятся. Аудиторские доказательства — это то, что принимают покупатели и регуляторы, а выявленные проблемы ранжируются по степени риска, благодаря чему исправления направляются туда, где уровень угрозы выше.
Заказывайте внешний аудит кибербезопасности, когда клиент или регулятор запрашивает независимое подтверждение.
До этого момента внутреннего аудита кибербезопасности по тем же критериям обычно бывает достаточно.
Аудит и оценка, оценка рисков, сканирование уязвимостей и пентест
Аудит кибербезопасности проверяет средства защиты на соответствие определенному стандарту, в то время как оценка, оценка рисков, сканирование уязвимостей и тест на проникновение решают более узкие задачи. Приведенное ниже сравнение показывает, где они пересекаются.
Аудит поглощает остальные четыре направления в качестве доказательств. Отчет о сканировании подтверждает соблюдение процедур управления исправлениями, а реестр рисков показывает, осознанно ли организация выбирала средства защиты.
Тестирование на проникновение является одним из источников доказательств в рамках аудита, полезным для проверки того, выдерживают ли средства защиты попытки взлома. В статье о этапах тестирования на проникновение описывается порядок проведения пентеста.
Ранжирование найденных проблем по уровню риска — это то, в чем эти активности чаще всего путают. Оценка рисков оценивает угрозы для активов, а аудит оценивает пробелы в защите по отношению к критериям (в обоих случаях по вероятности и влиянию). Оценка серьезности уязвимости в сканере описывает саму проблему, поэтому кому-то еще предстоит перевести ее в бизнес-риск, прежде чем она станет аудиторской находкой.
Какие бывают виды аудита кибербезопасности?
Существуют следующие виды аудита кибербезопасности: внутренний, внешний, на соответствие требованиям (комплаенс) и сторонний. Именно триггер, вызвавший необходимость аудита, должен определять, какой из них проводить.
Эти четыре понятия располагаются на двух осях. Внутренний и внешний описывают, кто проводит аудит. Комплаенс определяет критерии: стандарт или нормативный акт, на соответствие которому проверяются средства защиты. Аудит на соответствие может быть внутренним или внешним. Сторонний аудит — это внешний аудит, на отчет которого полагаются другие лица, такие как клиенты или регуляторы.
Задайте три вопроса в следующем порядке:
- Требуется ли кому-то за пределами компании опираться на результаты? Если клиент, регулятор или страховщик должен доверять выводам, закажите сторонний аудит. Используйте те критерии, которые они называют. Если они ничего не называют, уточните, принимают ли они SOC 2 или ISO/IEC 27001:2022.
- Указывает ли какой-либо закон, контракт или правило платежной системы на конкретный стандарт? Проводите аудит на соответствие этому стандарту. Правило определяет, достаточно ли самооценки или требуется квалифицированный аудитор. Для PCI DSS это зависит от уровня валидации.
- Является ли причиной опросник, в котором не требуется официальное подтверждение (аттестация)? Проведите внутренний аудит на основе CIS Controls v8.1 или NIST CSF силами команды, не зависящей от владельцев средств защиты.
В таблице эти вопросы применяются к распространенным триггерам:
Повторяйте процедуру ответов на вопросы каждый раз, когда меняется триггер. Два ранних признака того, что внутренний аудит больше не подходит: опросники начинают требовать отчет или сертификат, либо клиент отклоняет результаты вашей самооценки. Любое из этих событий означает, что на первый вопрос теперь нужно ответить утвердительно.
Внутренний аудит не удовлетворит клиента, запрашивающего независимое подтверждение. Тем не менее, он обычно стоит дешевле внешнего, поэтому мы рекомендуем проводить его в первую очередь для выявления пробелов до того, как это сделает внешний аудитор.
Ограниченные аудиты сужают рамки до одной доменной зоны: сети, приложения, управления доступом и идентификацией либо облачных сред. Их можно проводить как внутри компании, так и с привлечением сторонних специалистов, и они подходят командам, которые точно знают, где кроется риск.
Аудит ваших поставщиков — это отдельная задача, отличная от прохождения аудита. Он проверяет средства защиты вендоров, которые работают с вашими данными, как правило, посредством опросников, их отчетов об аттестации и целевых запросов доказательств. Руководство по оценке безопасности вендоров описывает этот процесс.
Что включает в себя аудит кибербезопасности?
Аудит кибербезопасности охватывает двенадцать областей контроля — от управления и политик до осведомленности в вопросах безопасности — и проверяет каждую на предмет проектной и операционной эффективности в отношении выбранных критериев. Перечисленные ниже области соответствуют мерам защиты в CIS Controls v8.1 и других стандартах, рассматриваемых далее. Каждая область завершается описанием типичного упущения, которое обычно приводит к выявлению несоответствия.
- Управление и политики. Аудитор прослеживает каждую политику до конкретного ответственного лица, даты утверждения и цикла пересмотра. Типичный сбой: подписанная политика без каких-либо доказательств пересмотра в течение периода аудита.
- Инвентаризация активов. Инвентаризация сверяется со вторым источником, таким как списки приложений SSO или данные биллинга облачных провайдеров. Типичный сбой: теневое ПО (shadow SaaS) остается за пределами области охвата, поэтому аудит подтверждает неполный список систем.
- Управление доступом и идентификацией (IAM). Проверка привилегированного доступа охватывает выборку учетных записей администраторов, сервисных и экстренных учетных записей (break-glass), а также недавно уволенных сотрудников. Типичный сбой: проверки доступа одобряются массово, а заброшенные учетные затухающие записи сохраняются из цикла в цикл.
- Безопасность сети. Сегментация и правила межсетевого экрана проверяются на соответствие задокументированному проекту. Типичный сбой: временные правила, открытые для миграции или инцидента, никогда не удаляются.
- Конечные точки и управление конфигурациями. Проверка конфигураций по стандартам CIS Benchmarks сравнивает реальные настройки с базовыми показателями: Уровень 1 для обычных систем и Уровень 2 для систем с повышенным риском. Типичный сбой: базовые показатели соблюдаются при сборке, но со временем отклоняются, а для исключений отсутствуют задокументированные компенсирующие меры. Облачные активы подчиняются той же логике, а руководство по облачному аудиту охватывает проверки конкретных провайдеров.
- Защита данных и шифрование. Проверяются классификация, шифрование при передаче и в состоянии покоя, а также хранение ключей. Типичный сбой: производственные данные зашифрованы, но их копии в аналитических или тестовых средах — нет.
- Безопасность приложений и API. Аудиторы изучают процесс безопасной разработки, работу с зависимостями и проверки авторизации. Построчный анализ кода относится к софтверному аудиту. Типичный сбой: незадокументированные конечные точки API, которые никогда не попадали в область тестирования.
- Журналирование и мониторинг. Период хранения журналов сопоставляется с политикой и требованиями расследования инцидентов. Типичный сбой: срок хранения определяется настройками хранилища по умолчанию, которые короче, чем указано в политике.
- Реагирование на инциденты. Аудиторы опрашивают специалистов по реагированию, изучают план и прошлые тикеты об инцидентах. Типичный сбой: план существует, но ни одна настольная игра (учения) или реальная запись об инциденте не подтверждают его работоспособность.
- Резервное копирование и восстановление. Выборочно проверяются записи тестов восстановления. Типичный сбой: бэкапы выполняются по расписанию, но никто никогда не восстанавливался из них, поэтому средство контроля спроектировано, но его работа не подтверждена на практике.
- Управление поставщиками. Изучаются реестр поставщиков, записи о комплексной проверке (due diligence) и этапы прекращения сотрудничества. Типичный сбой: поставщиков оценивают при подключении и больше никогда.
- Повышение осведомленности в вопросах безопасности. Записи о прохождении обучения проверяются по всей совокупности сотрудников. Типичный сбой: подрядчики и новые сотрудники выпадают из охватываемой проверкой совокупности.
Как проводить кибербезопасный аудит по шагам
Аудит кибербезопасности состоит из семи этапов: определение объема и критериев, сбор свидетельств, выборка за период аудита, проверка эффективности проектирования и работы, оценка выявленных несоответствий, составление отчета и повторное тестирование.
- Определите границы области проверки и критерии. Назовите системы, сущности, местоположения и период аудита, а также укажите, что исключено из рассмотрения. Выберите критерии, по которым оцениваются средства контроля, например средства контроля CIS Controls v8.1 или Заявление о применимости (Statement of Applicability) по стандарту ISO/IEC 27001:2022. Без обоих этих элементов ни одно замечание не сможет быть воспроизведено кем-либо еще.
- Собирайте свидетельства с помощью проверки, интервью и тестирования. Стандарт NIST SP 800-53A определяет эти три оценочные процедуры. Проверка означает чтение политик, конфигураций и журналов. Интервью означает вопросы владельцам средств контроля о том, как работает средство и кто заменяет ответственного в его отсутствие. Тестирование означает практическую проверку средства контроля, например подтверждение того, что отключенная учетная запись больше не может пройти аутентификацию.
- Запросите генеральную совокупность данных, затем сделайте выборку. Выборка начинается с полной совокупности за период аудита: каждого предоставленного доступа, тикета об изменении или задания бэкапа. Выборку делает аудитор, а не вы. Размер выборки зависит от частоты использования средства контроля и уровня риска, поэтому для ежедневного контроля проверяется больше элементов, чем для ежегодного. Скриншот доказывает состояние в конкретный день, а не то, что средство контроля работало в марте.
- Оцените сначала проектное решение, а затем эффективность работы. Проектная оценка средств контроля заключается в проверке того, будет ли средство при запуске в таком виде достигать своей цели. Проверка эффективности работы определяет, функционировало ли оно стабильно на протяжении всего периода. Качественно составленный квартальный обзор доступов проходит проверку на уровне проекта, но проваливает проверку на практике, если третий квартал был пропущен. Если средство контроля дает сбой, аудитор проверяет наличие компенсирующего элемента, который все же позволяет достичь цели.
- Оценивайте каждое несоответствие по вероятности и влиянию. Оценивайте оба параметра по одной шкале (обычно три или четыре уровня) и фиксируйте критерий, свидетельства и причину. Неисправная интернет-система с известным эксплойтом получает высокие оценки по обоим параметрам. Тот же изъян на изолированном хосте в лаборатории может получить низкую оценку, поскольку уровень воздействия меняет вероятность.
- Составляйте отчет с указанием владельцев и дат. За каждым несоответствием закрепляется конкретный владелец, ответные меры руководства и целевая дата, чтобы устранение можно было отслеживать независимо от человеческой памяти.
- Проведите повторное тестирование с новыми свидетельствами. Закрытое несоответствие требует свежих выборок за период после устранения. Письменное заявление о том, что проблема решена, не закрывает ее.
Обзор безопасности компании Netguru для американского медицинского приложения, подпадающего под действие закона HIPAA, демонстрирует весь этот цикл полностью. В ходе проверки было обнаружено несколько уязвимостей высокой степени тяжести, в том числе одна, которая оставляла клиента уязвимым для взлома. Netguru немедленно сообщила об этом вместе с планом митигации, по каждому выявленному несоответствию были приняты меры, новый бэкенд был спроектирован с учетом обнаруженных угроз, а инспекция безопасности продолжалась параллельно с разработкой функционала.
По каким фреймворкам проводятся аудиты кибербезопасности?
Аудит кибербезопасности проводится по одному набору критериев, выбранному тем, кому требуется подтверждение: клиентом, регулятором, платежной системой или собственным советом директоров.
Аудита NIST в смысле сертификации не существует. NIST публикует критерии в Кибербезопасной структуре (CSF) и стандарте SP 800-53, а определяет процедуры проверки, интервью и тестирования. Эту работу выполняет внутренний или сторонний оценщик.
Фреймворки в сравнении:
Заявление о применимости имеет решающее значение при аудите ISO, поскольку аудитор проверяет только те средства контроля, которые в нем заявлены, и любое исключение требует обоснования. Отчет SOC 2 Type 2 проверяет выборку свидетельств за весь период аудита, поэтому глубина хранения логов и история тикетов влияют на результат не меньше, чем проектная архитектура средств контроля.
Мы рекомендуем сначала выбирать подход на основе внешних обязательств: данные платежных карт означают PCI DSS, медицинские данные означают HIPAA, а корпоративные заказчики обычно запрашивают SOC 2 или ISO/IEC 27001:2022.
При отсутствии внешних требований набор CIS Controls в сочетании с CIS Benchmarks является практичным решением для внутреннего аудита, а таблица соответствия (кроссволк) позволяет использовать один набор свидетельств для нескольких фреймворков. Это правило перестает работать, когда в договоре указан конкретный тип отчета, который не может заменить никакое сопоставление.
Сертификация аудита кибербезопасности: что это значит и что не значит
Сертификация аудита кибербезопасности имеет разное значение в зависимости от фреймворка: ISO/IEC 27001:2022 сертифицирует систему менеджмента, SOC 2 подтверждает средства контроля, а PCI DSS v4.0.1 проверяет соответствие требованиям.
Эти три результата доказывают разные вещи, как показано в таблице:
Наша рекомендация — уточнить у запрашивающей стороны, какой именно документ они принимают, прежде чем определять рамки проверки. Изучая чужой отчет, сначала проверьте границы области применения и охватываемый период.
Чек-лист аудита безопасности: что запросит аудитор
Чек-лист аудита безопасности связывает каждое средство контроля с артефактом, назначенным владельцем и сроком хранения, чтобы аудитор мог сформировать выборку свидетельств.
Процесс формирования выборки одинаков для всех фреймворков. Аудитор изучает ваши политики для оценки проектирования средств контроля, а затем делает выборку из совокупности (например, всех уволенных сотрудников за период аудита), чтобы проверить эффективность их работы. Если вы не можете выгрузить полную совокупность данных, аудитор не сможет сделать выборку.
В таблице ниже перечислено то, что следует подготовить заранее. Значения сроков хранения указаны в качестве наших рекомендуемых стандартов по умолчанию, если не указано иное правило.
Проверка привилегированного доступа — это артефакт, который аудиторы чаще всего находят неполным. Для него необходимы список учетных записей, имя проверяющего, дата и тикет для каждого случая удаления прав или их понижения. Скриншот группы администраторов не доказывает, что кто-либо проводил ее проверку.
Период хранения журналов — это единственный пункт, где конкретная цифра задается правилом. Требование 10.5.1 стандарта PCI DSS v4.0.1 предписывает хранить историю журналов аудита не менее 12 месяцев, причем самые свежие данные за последние три месяца должны быть доступны для немедленного анализа (PCI DSS v4.0.1, PCI Security Standards Council).
Закон HIPAA требует шести лет хранения обязательной документации по безопасности согласно разделу 45 CFR 164.316(b)(2)(i). Стандарты ISO/IEC 27001:2022 и SOC 2 не устанавливают фиксированных значений, поэтому аудитор проводит проверку на соответствие периоду, указанному в вашей собственной политике.
Загружаемый PDF-чек-лист — отличная отправная точка. Превратите его в трекер, где каждая строка ссылается на актуальную выгрузку, поскольку свидетельства, которые вы можете воссоздать по запросу, вызывают больше доверия, чем папка документов, собранная за неделю до полевого этапа проверки.
Существует ли PDF-файл или шаблон аудита кибербезопасности, который можно использовать?
Да, бесплатные PDF-файлы аудита кибербезопасности и шаблоны электронных таблиц существуют, но шаблон пригодится только в том случае, если каждая строка содержит критерий, артефакт в качестве доказательства, назначенного ответственного и период выборки.
Список тем вроде «Включена ли многофакторная аутентификация (MFA)?» не проходит эту проверку. В нем не указан стандарт для оценки, артефакт для проверки, лицо, ответственное за его предоставление, и диапазон дат для совокупности данных.
Чек-лист аудита, приведенный выше, уже связывает средства контроля с артефактами, ответственными лицами и периодами хранения. Скопируйте его в электронную таблицу, а затем добавьте столбец периода выборки и столбец статуса.
Для аудитов по стандарту ISO/IEC 27001:2022 Заявление о применимости используется в качестве столбца критериев. В нем перечислены все средства контроля Приложения А, указано, применимы ли они, почему именно и каков их статус реализации, благодаря чему аудитор проверяет то, что вы объявили находящимся в области действия.
NIST и CIS публикуют свои наборы средств контроля в виде документов, доступных для скачивания. Это критерии, а не рабочие документы, поэтому столбцы с доказательствами, ответственными лицами и периодами вы добавляете самостоятельно.
Как подготовиться к аудиту кибербезопасности?
Подготовьтесь к аудиту кибербезопасности, исправив три вещи до приезда аудитора: период хранения журналов, назначенного ответственного за каждый элемент контроля и границы области действия, включающие теневые SaaS-решения.
Выборка определяет все три аспекта. Аудитор формирует выборку из совокупности данных, охватывающей весь период аудита, поэтому доказательства должны существовать для каждого месяца этого периода, а не только для сегодняшней конфигурации.
Режимы сбоев и проверка, которую можно выполнить на раннем этапе:
Предварительный запрос — самый дешевый из трех видов проверок, и он также выявляет низкое качество доказательств: скриншоты без даты, выгрузки без показанного запроса и одобрения, хранящиеся в чате.
Одно предостережение: минимальные сроки хранения различаются в зависимости от критериев. Стандарт PCI DSS устанавливает собственные требования, охватываемые чек-листом, в то время как другие стандарты позволяют согласовать период в рамках области действия. Урегулируйте этот вопрос с аудитором в письменной форме до начала полевых работ.
Внутренний или внешний аудит: что нужно растущей софтверной компании?
Растущей софтверной компании необходим внутренний аудит, начиная с первых опросников для клиентов и далее, и внешний аудит, как только клиент, платежная система или регулятор потребуют независимого подтверждения. До появления одного из этих триггеров внешний аудит стоит денег, и никто не требует его результатов.
Триггеры и требования каждого из них:
Внутренний аудит не может обеспечить независимость. Даже самый тщательный аудит, проведенный кем-то за пределами команды, отвечающей за средства контроля, дает результат, который ни один клиент или платежная система не примут в качестве подтверждения. Тем не менее, он может проверить эффективность проектирования и функционирования по любым выбранным вами критериям, что делает его правильным инструментом для поиска упущений.
Внешний аудит не может обеспечить непрерывный охват. Аудитор делает выборку из периода аудита, пишет заключение и уходит. Он также не может подсказать, какие упущения наиболее важны для вашего продукта, поскольку его сфера деятельности определяется критериями.
Мы рекомендуем проводить внутренний аудит по тем же критериям за один квартал до начала внешних полевых работ. Это оставляет время на устранение выявленных проблем и сбор доказательств за каждый месяц периода. Сначала проверьте формулировки в договоре: некоторые клиенты принимают сертификат ISO или резюме теста на проникновение, и это может сместить триггер на более поздний срок.
Что происходит после отчета и что нужно исправить в первую очередь
Устраняйте выявленные проблемы по рейтингу риска, то есть по вероятности и воздействию, а затем пересортируйте по эксплуатируемости: устранимая уязвимость, подвергающаяся активной атаке, стоит выше более серьезной уязвимости в изолированной системе.
Оценка степени серьезности в отчете не учитывает реальную подверженность рискам, поэтому добавьте этот контекст самостоятельно. Проверьте, выходит ли система в интернет, содержится ли уязвимость в каталоге известных эксплуатируемых уязвимостей CISA и хранит ли система регулируемые данные. Наш рекомендуемый порядок:
- Открытые, эксплуатируемые уязвимости: системы, имеющие доступ к интернету, и все, что входит в каталог CISA.
- Уязвимости, затрагивающие регулируемые данные. Согласно Правилам безопасности HIPAA, стандарт управления рисками в 45 CFR 164.308(a)(1)(ii)(B) требует снижения риска до разумного и приемлемого уровня.
- Сбои в проектировании средств контроля с дешевыми исправлениями, такие как отсутствие политики MFA или неописанный процесс увольнения сотрудников.
- Сбои в эффективности функционирования, такие как пропущенные проверки доступа.
- Низкоприоритетные и информационные пункты, объединенные в обычную работу с бэклогом.
Если исправление не может быть внедрено в рамках окна устранения, задокументируйте компенсирующий элемент контроля: другую меру защиты, которая решает ту же задачу контроля, с назначенным ответственным, сроком действия и собственными доказательствами. Аудитор проверяет ее так же, как и любой другой элемент контроля, поэтому компенсирующий элемент контроля без журналов или записей о проверках не закроет найденную проблему.
Проводите повторную проверку каждого пункта по его первоначальным доказательствам. Исправления проекта можно проверить в день их выпуска. Исправления эффективности функционирования требуют нового набора данных, например, за полный квартал проверок доступа, прежде чем аудитор сможет сделать из них выборку. Проблемы, повторяющиеся в разных системах, обычно указывают на пробел в архитектуре безопасности или стратегии кибербезопасности, а не в каком-то отдельном элементе контроля.
От чего зависят стоимость и продолжительность аудита кибербезопасности?
Область аудита, количество систем, стандарт, тип аудитора и набор повторных проверок после устранения неполадок определяют стоимость и продолжительность аудита кибербезопасности. Затраты труда зависят от объема доказательств, которые аудитор должен собрать и проверить.
Каждая система внутри границ области действия добавляет совокупность данных, которую аудитор должен проверить методом выборки. Проверка эффективности функционирования за период, например, за период наблюдения SOC 2 Type 2, занимает больше времени, чем ретроспективная проверка проектирования, поскольку аудитор берет образцы доказательств за весь период.
Факторы влияния и последствия их изменения:
Наиболее дешевое сокращение затрат достигается за счет готовности доказательной базы: назначенные ответственные за каждый элемент контроля, сохраненные журналы и выгрузки, которые можно предоставить по запросу. Это сокращает полевые работы без изменения того, что проверяет аудитор.
Небезопасное сокращение затрат заключается в сужении области действия для получения более благоприятного результата. Структура гонораров аудиторов различается, поэтому запросите смету с разбивкой по этим факторам и сравнивайте их по ней.
Как часто следует проводить аудит кибербезопасности?
Проводите полный аудит кибербезопасности по крайней мере раз в год и добавляйте непрерывный мониторинг средств контроля между аудитами для тех элементов, которые смещаются быстрее всего.
Ежегодный аудит проверяет эффективность проектирования и функционирования за период. Он соответствует циклу отчетов SOC 2, инспекционных аудитов ISO/IEC 27001 и оценок PCI DSS. Пробел — это уязвимость: корзина хранения данных, открытая для публики, или пропущенная проверка доступа могут оставаться незамеченными большую часть года.
Непрерывный мониторинг средств контроля закрывает этот пробел с помощью автоматических проверок: дрейф конфигурации относительно стандартов CIS Benchmarks, охват MFA, работоспособность конвейера сбора журналов. NIST CSF 2.0 относит непрерывный мониторинг к своей функции «Обнаружение» (DE.CM), так что эти проверки имеют определенное место в рамках стандарта.
Проверки на уровне конвейера естественным образом вписываются в рабочий процесс DevSecOps. Интервью, проверка политик и оценка области действия остаются ручными, поэтому мониторинг служит источником доказательств для аудита, а не заменяет его.
Мы рекомендуем проводить внеплановый аудит, охватывающий конкретные изменения, после любого из следующих событий:
- Локализованный инцидент безопасности или подтвержденное нарушение
- Серьезное изменение архитектуры, такое как миграция в облако, новый поставщик удостоверений или новый регион
- Слияние, поглощение или появление нового регулируемого типа данных, например, данных банковских карт или медицинских данных.
- Новое договорное требование, например, дополнение по безопасности от корпоративного клиента.
- Новая третья сторона, имеющая доступ к производственным данным.
HIPAA не устанавливает фиксированного интервала. Статья 45 CFR 164.308(a)(8) требует проведения периодической оценки, а также оценки после операционных изменений, которые влияют на безопасность электронных защищенных медицинских данных. Для большинства триггеров достаточно целевого внутреннего аудита; оставьте внешнего аудитора для случаев, когда этого требует нормативная база или клиент.
Что такое аудит кибербезопасности?
Аудит кибербезопасности — это систематическая, основанная на доказательствах проверка средств контроля безопасности, политик и конфигураций организации на соответствие определенному стандарту, завершающаяся документированными выводами. Аудитор изучает документы, проводит интервью с владельцами средств контроля и тестирует конфигурации, чтобы оценить, спроектированы ли средства контроля и функционируют ли они так, как заявлено. Проверка без указания стандарта, по которому проводится тестирование, является оценкой безопасности.
Сколько стоит аудит кибербезопасности?
Стоимость аудита кибербезопасности зависит от объема, количества систем, структуры, внутренних или внешних аудиторов и того, включено ли повторное тестирование. Узкая внутренняя проверка одного приложения требует гораздо меньше усилий, чем внешний аудит по нескольким стандартам. Запрашивайте коммерческие предложения с фиксированным объемом работ, привязанные к письменным границам аудита, поскольку открытый объем — это то, как растут расходы.
Является ли аудит кибербезопасности обязательным?
Аудит кибербезопасности является обязательным только в том случае, если этого требует нормативный акт или договор. PCI DSS охватывает данные карт, Правило безопасности HIPAA требует периодической оценки (45 CFR 164.308(a)(8)), а корпоративные клиенты часто запрашивают SOC 2 или ISO/IEC 27001. В остальных случаях аудит является добровольным, но анкета клиента может превратить его в требование для совершения сделки.
Какие существуют виды аудитов кибербезопасности?
Аудиты кибербезопасности различаются по аудитору и объему: внутренние или внешние, на соответствие стандарту, или сфокусированные на сети, облаке, приложении, управлении идентификацией и доступом, или безопасности третьих сторон. Внутренние аудиты подходят для проверки готовности, в то время как внешние аудиты дают независимую гарантию клиентам и регуляторам. Выбирайте исходя из вопроса, на который вам нужно ответить, например, запрос клиента на SOC 2.
Существует ли аудит NIST?
NIST не проводит аудиты и не выдает сертификаты; организации оцениваются на соответствие NIST CSF 2.0 или SP 800-53 внутренними или сторонними оценщиками. NIST SP 800-53A определяет процедуры изучения, интервьюирования и тестирования, которые оценщики используют для проверки средств контроля (Глоссарий NIST CSRC (метод оценки)). Относитесь к заявлению о «соответствии NIST» как к утверждению об объеме и оценщике, и запрашивайте отчет.
Кто может проводить аудит на соответствие NIST CSF?
Внутренние аудиторские группы или независимые сторонние оценщики могут проводить аудит на соответствие NIST Cybersecurity Framework (CSF) 2.0, поскольку NIST не сертифицирует оценщиков. Внутренние команды подходят для работы по обеспечению готовности; третьи стороны предоставляют гарантии, которые могут изучить клиенты и регуляторы. Проверьте опыт оценщика в работе с процедурами SP 800-53A и его независимость от команды, которая создавала средства контроля.
Планируйте свой следующий аудит безопасности с четким объемом работ
Аудит кибербезопасности начинается с письменного определения объема: систем, областей контроля, структуры и периода, который он охватывает. Согласуйте эти четыре пункта перед тем, как запрашивать коммерческие предложения, чтобы каждое предложение было оценено в рамках одних и тех же границ.
