В каждой компании есть правила защиты информации. В них указано, кому можно входить в системы, как выдавать и закрывать доступ, что записывать в журналах и как делать резервные копии. Сотрудники работают по этим правилам, а системы выполняют их автоматически там, где это возможно. Но утечки и взломы все равно случаются, а значит, правила несовершенны.
Чтобы их проверять и корректировать, нужно периодически проводить аудит информационной безопасности. Как он устроен, из каких этапов состоит и какие результаты дает — рассказываем в статье.
Что такое аудит информационной безопасности
Аудит информационной безопасности — это процесс проверки систем защиты информации в конкретной компании. Аудитор читает документы с правилами, смотрит настройки, сверяет заявки и журналы, разговаривает с сотрудниками. Затем он систематизирует собранные данные, находит слабые места системы: какие данные защищены недостаточно, что может произойти и какие действия снизят риск утечки или взлома.
Перед проверкой компания и аудитор договариваются о том, какие системы и процессы попадут в проверку и по каким правилам оценят результат. На языке аудиторов это называется границами и критериями.
Границы показывают область проверки. Это может быть весь бизнес, один сайт, облако, база данных, офисная сеть или выдача прав администраторам.
Критерии показывают, как все должно работать. Их берут из законов, стандартов, договоров и внутренних правил компании.
Возьмем доступ уволенных сотрудников. В границы входят корпоративная система и учетные записи. Внутреннее правило требует закрыть доступ в день увольнения. Аудитор берет список уволенных, сверяет его с аккаунтами и смотрит время блокировки. Если бывший сотрудник все еще может войти, команда выясняет причину и закрывает доступ.
Какие бывают виды аудита ИБ
Защиту может проверить сотрудник компании или приглашенный специалист. В обоих случаях проверяют документы, рабочие процессы, технические настройки или все сразу.
Внутренний и внешний аудит
Внутренний аудит информационной безопасности проводит сотрудник компании. Проверять собственную работу трудно. Поэтому аудитор никогда не бывает тем же сотрудником, который сам настраивал систему информационной безопасности.
Внешний аудит проводит приглашенный специалист или внешняя команда.
Документальный, процессный и технический аудит
При документальном аудите специалист читает политики, регламенты, приказы, модели угроз, договоры и журналы. Он проверяет, описаны ли важные ситуации и не противоречат ли документы друг другу.
Процессный аудит показывает, что сотрудники делают в реальности. Кто согласовал доступ? Как разобрали инцидент? Ответы сверяют с заявками, записями в системах и другими доказательствами.
Технический аудит касается настроек. Специалист изучает сеть, серверы, компьютеры сотрудников, облако, приложения, API, базы данных, резервные копии и защитные программы.
На что обращает внимание аудитор информационной безопасности
- Доступ к данным и системам. Какие сотрудники и сервисы могут читать, изменять или удалять данные, соответствуют ли права должностям, есть ли лишние, неиспользуемые и общие учетные записи.
- Выдача и отзыв прав. Как сотрудник получает доступ, кто согласует заявку, что происходит при переводе и увольнении, как быстро закрывают права и где сохраняется подтверждение каждого изменения.
- События и журналы. Какие входы, действия администраторов, изменения настроек и обращения к важным данным фиксируют системы. Затем проверяют полноту записей, срок хранения, доступ к журналам и возможность восстановить ход события.
- Реакция на предупреждения. Выясняют, кто получает уведомление, по каким признакам оценивает событие, когда подключает ответственного специалиста, какие действия выполняет и где записывает результат разбора.
- Резервное копирование и восстановление. Проверяют расписание копирования, состав данных, защиту копий от изменения и доступ к ним, отчеты об ошибках и результаты пробного восстановления.
- Выполнение правил на практике. Сопоставляют политики и регламенты с заявками, настройками, журналами и рассказами сотрудников. Так можно увидеть, где процесс работает полностью, где зависит от ручных действий и какие шаги требуют исправления.
Зачем компании нужен аудит ИБ
У компаний встречаются две причины заказать аудит: они сами хотят понять и исправить свои уязвимости, или этого требуют их партнеры, заказчики или регуляторы.
Когда аудит требуют извне
Партнер или крупный заказчик оценивает риск, который появится после подключения к сервису. Если поставщик получает доступ к персональным данным, платежной информации или внутренней сети заказчика, тот может запросить анкету безопасности, отчет об аудите. Заказчик хочет понять, где лежат его данные, кто к ним получает доступ, как компания замечает инциденты и сколько времени занимает реакция. Риск для заказчика: подрядчик может допустить утечку данных или предоставить к ним доступ посторонним, а ответственность и репутационные потери затронут обе компании. Конкретный комплект зависит от договора, отрасли и глубины доступа поставщика.
Регулятор включает аудит или оценку защиты в отраслевые требования, условия лицензии, проверку значимой системы или разбор инцидента. Например, Роскомнадзор проверяет компанию после утечки персональных данных. Аудит помогает оценить, кто имел доступ к данным, как настроены права пользователей, ведутся ли журналы событий и соблюдаются ли требования к защите информации. В этом случае аудитор сопоставляет требования с документами, настройками, журналами, заявками и результатами тестов. Состав проверки зависит от отрасли, типа данных, статуса системы и нормы, на которую ссылается регулятор.
Покупатель или инвестор проводит проверку кибербезопасности перед сделкой — security due diligence. Ему важно понять, какие системы и данные перейдут к новому владельцу, какие обязательства уже возникли перед клиентами и регуляторами, сколько стоит исправление проблем и остались ли внутри инфраструктуры незакрытые инциденты. Поэтому проверяют границы сертификатов, сроки их действия, исключения, открытые замечания, результаты прошлых пентестов, доступы подрядчиков, резервные копии и план исправлений.
Когда компания сама заказывает аудит
Перед запуском продукта или большой перестройкой инфраструктуры. Команда добавляет личный кабинет, переносит базы в облако, открывает API — интерфейс, через который другие программы обращаются к сервису, — или объединяет несколько систем. Вместе с этим меняются доступы, сетевые соединения, резервное копирование и журналы событий. Аудитор проверяет новую схему до запуска: кто сможет войти, какие данные увидит, куда попадет запрос и что произойдет при сбое.
После инцидента или сбоя. Компания увидела подозрительный вход, утечку, остановку сервиса или ошибочную выдачу прав. Первое исправление закрывает острую проблему, а аудит помогает разобраться глубже: когда все началось, какие данные затронуты, кто получил доступ, какая настройка или действие привели к событию и где еще может повториться та же ошибка. Для этого аудитор изучает журналы, настройки, заявки и действия сотрудников. В итоге у команды появляется проверяемая картина случившегося и план мер с ответственными.
Перед сертификацией или важной проверкой. Компания может заранее пригласить аудитора, чтобы подготовиться к внешней оценке. Например, она собирается сертифицировать систему по ISO/IEC 27001 или ожидает отчет SOC 2 — проверку защитных мер сервисной компании. Предварительный аудит показывает, где расходятся требования и реальная работа: какой документ устарел, у какого администратора лишние права, где отсутствуют записи и какие доказательства придется собрать.
Перед передачей данных подрядчику или подключением нового поставщика. До подписания договора компания проверяет, где будут храниться данные, кто получит административный доступ, как поставщик сообщает об инциденте и что происходит с учетными записями после окончания работ. Если ответы остаются только в презентации поставщика, решение получается на доверии. Аудит помогает проверить процессы и закрепить в договоре конкретные обязанности, сроки и доказательства.
Что проверяют во время аудита информационной безопасности
Сеть, серверы и облако
Сначала собирают карту внешних точек: домены, IP-адреса, балансировщики, почтовые шлюзы, API и облачные сервисы. Затем сравнивают ее со списком активов компании. Если находится неизвестный сервис, это отдельный вопрос: кто его запустил, какие данные он видит и кто отвечает за обновления.
Для каждого сервиса, доступного из интернета, проверяют назначение, порт и протокол, шифрование соединения, способ входа, ограничения по источникам и дату последнего обновления. Отдельно смотрят, можно ли из пользовательской сети попасть к базам данных, панелям управления и резервным копиям. В нормально разделенной сети рабочая станция, тестовая среда и производственная база имеют разные маршруты и права.
При проверке сервера смотрят операционную систему и ее версию, просроченные обновления, открытые порты, локальные учетные записи, права администраторов, защиту конечной точки, синхронизацию времени, резервные копии и журналы. Если сервер обновляют вручную, аудитор ищет заявки на изменения и подтверждение того, что после обновления сервисы проверили.
В облаке дополнительно проверяют роли IAM, MFA для корневых и административных аккаунтов, публичный доступ к хранилищам и снимкам дисков, срок жизни ключей, правила групп безопасности и включенный аудит действий.
Приложения и API
В веб-приложении сначала описывают роли и путь данных: где пользователь входит, какие запросы принимает API, где приложение хранит данные и какие действия меняют их. Затем проверяют аутентификацию, восстановление пароля, срок действия сессии, ограничение частоты запросов и авторизацию.
Для API оценивают область действия и срок жизни токенов, обработку ошибок и защиту от повторной отправки запроса. Например, специалист меняет идентификатор записи в тестовом запросе и смотрит, не отдаст ли сервер чужой документ. Такой тест проводят только в разрешенной среде и с тестовыми данными.
Проверяют также валидацию входных данных, загрузку файлов, секреты в репозитории и настройках, версии сторонних библиотек, настройки CORS, журналы запросов и отсутствие чувствительных данных в сообщениях об ошибках.
Учетные записи и доступы
Здесь аудитор проверяет, соответствуют ли права пользователя в системе его реальной должности. Например, бухгалтеру можно читать счета и менять реквизиты платежа, но нельзя создавать новых пользователей. Затем аудитор выбирает несколько реальных сотрудников и сверяет их должность, заявку на доступ, назначенную группу в каталоге и запись о входе.
Также аудитор проверяет, как меняются права пользователя, если изменился его статус при приеме на работу, смене должности и увольнении. Если сотрудник перешел из отдела продаж в бухгалтерию, старые права должны отменить и завести новые. Если человек уволился, в системе ищут время блокировки аккаунта и события после него.
Отдельно проверяют административные и сервисные аккаунты, общие пароли и многофакторную аутентификацию, или MFA. У каждого сервисного аккаунта должны быть владелец и назначение, ограниченный набор прав, срок действия ключа и журнал использования. Для аварийной учетной записи проверяют, кто может ее открыть, где хранится пароль и как компания узнает о таком входе. Доказательства ищут в заявках на доступ, списках ролей, настройках каталога и журналах изменений.
Внутренние документы и рабочие процессы
Документы или регламенты говорят, как рабочий процесс должен идти: кто согласует доступ, в какой срок отключают аккаунт, как часто делают резервные копии. Но важно проверять, как в компании работают на самом деле.
Например, аудитор проверяет выдачу доступа сотруднику:
- сотрудник отправил заявку и указал, к каким данным ему нужен доступ;
- руководитель подтвердил, что доступ нужен для работы;
- администратор выдал права в системе;
- в журнале появилась запись об изменении;
- ответственный сотрудник проверил, что права соответствуют заявке.
Резервное копирование проверяют по той же логике. Если внутреннее правило требует делать копию каждый день, аудитор проверяет:
- запускается ли задание по расписанию;
- какие данные попадают в копию;
- где система записывает ошибки;
- зашифрована ли копия, чтобы посторонний не прочитал ее;
- кто может удалить или заменить копию;
- защищена ли она от случайного изменения.
Затем аудитор выбирает одну копию и пробует восстановить из нее файл, базу или тестовый сервис. В отчете указывают, сколько времени заняло восстановление и сколько данных удалось вернуть. Эти значения сравнивают с целями компании: сколько данных она готова потерять после сбоя и сколько времени может работать с остановленным сервисом.
Уязвимость — слабое место в программе, настройке или процессе, через которое можно нарушить работу системы или получить доступ к данным. Аудитор выясняет:
- кто и где регистрирует найденную уязвимость;
- как оценивают ее срочность и возможный ущерб;
- кому назначают исправление;
- что делают, если быстро исправить проблему нельзя;
- кто разрешает временное исключение и до какой даты оно действует;
- как проводят повторную проверку после исправления.
Для подрядчика проверяют отдельную цепочку. До заключения договора компания оценивает, как поставщик защищает данные. В договоре фиксируют, к каким системам и данным подрядчик получает доступ, кому он сообщает об инциденте и в какой срок. После окончания работ компания закрывает учетные записи и просит подтверждение удаления данных из систем и копий подрядчика. Каждое звено должно подтверждаться своим фактом: заявкой, настройкой, записью в журнале, пунктом договора или результатом теста.
Журналы событий
Журнал событий — это список записей, которые система автоматически создает, когда в ней что-то происходит. Событие — одно зафиксированное действие или результат: пользователь вошел, пароль отклонен, права изменились, файл открыли. По журналу можно восстановить порядок действий и понять, кто и что сделал.
Обычно в журнале сохраняются:
- попытки входа — успешные и отклоненные системой;
- выдача и отзыв прав — кому разрешили доступ, к каким данным и когда его закрыли;
- действия администраторов — вход в панель управления, изменение настроек, создание или удаление учетной записи;
- обращения к чувствительным данным — например, открытие карточки клиента или выгрузка платежной информации;
- изменения важных настроек — правил доступа, сетевых соединений, резервного копирования или защитных систем;
- запуск и остановка служб — фоновых компонентов, которые обеспечивают работу приложения, базы данных или другого сервиса;
- предупреждения защитных систем — сообщения о подозрительном входе, вредоносном файле или попытке отправить данные через запрещенный канал;
- очистка журнала и ошибки записи — события, которые показывают, что записи удаляли или система не смогла их сохранить.
Хорошая запись отвечает как минимум на четыре вопроса: когда произошло событие, кто или какая программа действовали, что именно изменилось и чем все закончилось. Иногда нужны дополнительные данные: с какого устройства пришел запрос, к какому объекту обращались и какое правило сработало.
Аудитор проверяет, как долго компания хранит журналы, кто может их читать и удалять, защищены ли записи от изменения и разбирают ли сотрудники предупреждения. Важно сохранить саму запись и понятный порядок работы с ней. Если система присылает тревогу, должно быть видно, кто ее получил, что проверил и какое решение принял.
Здесь аудитор тоже обычно рассматривает конкретные случаи. Например, после изменения прав администратора он ищет заявку на доступ, подтверждение руководителя, запись в системе учетных записей, изменение в целевой системе и уведомление в SIEM.
Заодно проверяют синхронизацию времени: часы на разных системах должны показывать одно и то же время, иначе порядок действий окажется искажен. Смотрят и на полноту записей о неудачных входах, и на защиту журнала от удаления администратором, чьи действия в нем зафиксированы. Если в цепочке пропущен участник или результат, расследование инцидента придется строить на догадках.
Персональные данные
Проверяют путь данных от первого сбора до удаления: какие поля получает форма или API, зачем они нужны, где хранятся, в какие системы передаются, кто их видит и как удаляют основной массив и резервные копии. Отдельно смотрят тестовые среды: настоящие персональные данные там маскируют или заменяют тестовыми.
В настройках проверяют шифрование при передаче и хранении, управление ключами, права операторов, выгрузки и журналы обращений к данным. В процессе — согласие или другое основание обработки, сроки хранения, ответы на запросы субъектов и порядок действий при утечке. Точный список требований зависит от отрасли, типа данных и статуса системы. Его сверяют с юристом и специалистом по ИБ.
Какие инструменты защищают данные и системы
Защитные системы — это программы и сетевые устройства, которые помогают компании отслеживать путь данных и действия пользователей. Одни проверяют вход и права, другие фильтруют запросы и соединения, третьи следят за компьютерами и серверами, четвертые ищут признаки утечки и собирают записи для расследования. Перечислим основные инструменты:
- WAF (Web Application Firewall, межсетевой экран для веб-приложений). WAF проверяет входящие запросы и может заблокировать попытку встроить команду базы данных в поле формы. Аудитор смотрит, защищены ли все нужные страницы и точки API, включена ли блокировка, кто выдает исключения и сохраняются ли записи о сработавших правилах.
- NGFW (Next-Generation Firewall, межсетевой экран нового поколения). Управляет соединениями между сетевыми зонами — отдельными частями сети с разными правилами доступа. Например, он решает, может ли рабочий компьютер обратиться к серверу базы данных, а сервер — к облачному хранилищу. Аудитор проверяет сами разрешения, изменения сетевых правил, ограничения для администраторов и записи о разрешенных и запрещенных соединениях.
- IAM (Identity and Access Management, управление учетными записями и доступом). Хранит сведения о пользователях, проверяет вход и выдает права по ролям. Аудитор проверяет MFA — многофакторную аутентификацию, при которой одного пароля недостаточно и нужен дополнительный код или подтверждение, — а также права администраторов, сроки действия доступов и сервисные аккаунты, которыми пользуются приложения. Отдельно смотрит, что происходит с доступом после приема сотрудника, перевода на другую должность и увольнения.
- EDR (Endpoint Detection and Response, защита рабочих станций и серверов). На компьютере или сервере работает агент — небольшая программа, которая наблюдает за процессами и подозрительными действиями. При угрозе EDR может закрыть устройству сетевые соединения и передать информацию специалисту. Аудитор проверяет, установлен ли агент на всех нужных устройствах, получает ли обновления, кто меняет правила и действительно ли устройство изолируется при разрешенной проверке.
- DLP (Data Loss Prevention, защита от утечек). Следит, как чувствительные данные покидают компанию: через почту, облачное хранилище, веб-загрузку или USB-накопитель. К таким данным относятся персональные данные клиентов, платежная информация и ключи доступа. Аудитор выясняет, какие данные DLP умеет распознавать, какие каналы контролирует и что происходит при нарушении: передача блокируется или сотрудник получает предупреждение. Еще один вопрос — кто разбирает такие события и где фиксирует результат.
- SIEM (Security Information and Event Management, сбор и анализ событий). Это платформа, куда поступают журналы приложений, серверов, IAM, EDR, WAF и других систем. Правило корреляции связывает несколько событий в одну подозрительную цепочку — например, серию неудачных входов, успешную авторизацию и попытку выгрузить данные. Аудитор проверяет, подключены ли нужные источники, синхронизировано ли время на системах, работают ли правила, кто получает предупреждение и за какой срок должен его разобрать.
Как проводится аудит информационной безопасности
1. Компания формулирует запрос
Сначала компания формулирует вопрос так, чтобы на него можно было ответить с доказательствами. Обычно это звучит примерно так: «Могут ли администраторы войти в production без MFA?» или «Восстанавливается ли база из резервной копии за четыре часа?».
Затем компания и аудитор перечисляют системы, процессы, офисы и данные для проверки и называют владельца каждого объекта. Для технических тестов заранее записывают ограничения: время запуска, допустимую нагрузку, тестовые аккаунты, запрещенные действия и контакт сотрудника, которому нужно звонить при сбое.
2. Компания и аудитор выбирают правила
Бывают внутренние правила, обычно они отвечают на несколько вопросов:
- какие данные и системы нужно защищать;
- кому можно входить и что разрешено делать;
- какие события записывать в журнал;
- что делать при сбое или инциденте;
- какими доказательствами подтвердить, что правило работает.
У одной компании обычно бывает несколько наборов требований. Например, веб-сервис хранит данные клиентов, принимает платежи и подключается к системам крупного заказчика. На него одновременно могут распространяться закон о персональных данных, требования платежной системы, пункты договора с заказчиком и внутренние правила самой компании. Эти документы отвечают на разные вопросы, поэтому аудитор собирает их в одну рабочую карту.
А еще бывают законы и требования регуляторов, их тоже учитывают при аудите.
Российские законы
В России есть несколько законов, которые регулируют правила информационной безопасности.
149-ФЗ «Об информации, информационных технологиях и о защите информации». Закон говорит о правовых, организационных и технических мерах защиты информации: ограничении доступа, предотвращении уничтожения и изменения данных, контроле уровня защищенности. Это общий фон для работы с информацией и информационными системами.
152-ФЗ «О персональных данных» применяется, когда компания обрабатывает сведения о людях: имя, телефон, адрес, данные клиента, сведения о сотруднике и другие данные, по которым человека можно определить. Закон регулирует цели и основания обработки, права человека, обязанности оператора и защиту данных.
Для информационных систем персональных данных к закону добавляются специальные требования. Постановление Правительства №1119 связывает защиту с уровнем защищенности системы и особенностями обрабатываемых данных. Приказ ФСТЭК России №21 описывает состав организационных и технических мер: управление доступом, регистрацию событий, защиту от вредоносных программ, резервирование и другие меры. В отдельных случаях нужны требования ФСБ к применению средств криптографической защиты информации — программ и устройств, которые шифруют данные и проверяют их подлинность.
Государственные информационные системы живут по отдельному набору требований. Для них действует приказ ФСТЭК России №117 от 11 апреля 2025 года. Он предназначен для государственных органов, государственных унитарных предприятий, учреждений и указанных в документе информационных систем. Частная компания обращается к этому приказу, когда ее система связана с таким заказчиком или договор прямо включает эти требования.
Критическая информационная инфраструктура — еще один отдельный случай. К ней относятся информационные системы и сети в значимых для государства и экономики сферах, например в энергетике, здравоохранении, транспорте, связи, финансовом секторе и промышленности. Сначала организацию и ее объекты проверяют на принадлежность к КИИ и определяют категорию значимости. Затем применяют требования безопасности.
Основной закон здесь — 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации». Правила категорирования объектов установлены постановлением Правительства №127, а требования к защите значимых объектов — приказом ФСТЭК №239. Для обычной серверной или веб-сервиса этот набор требований появляется при подтвержденном статусе значимого объекта КИИ либо по договору с организацией, которая уже работает по этим требованиям.
Для финансовых организаций добавляются нормативные документы и стандарты Банка России. Например, в банковской сфере используют ГОСТ Р 57580.1-2017 и документы Банка России по управлению риском информационной безопасности. Они учитывают особенности платежей, банковских систем, операционной надежности и финансовых инцидентов.
Есть и российская версия международного стандарта: ГОСТ Р ИСО/МЭК 27001-2021. Он устанавливает требования к системе менеджмента информационной безопасности и оценке рисков. ГОСТ становится обязательным для компании, когда на него ссылается закон, договор, тендер или требование регулятора. Компания также может сама включить его в свою систему управления и проверять соответствие по собственной инициативе.
Какие правила используют в мире
ISO/IEC 27001:2022 — стандарт для системы менеджмента информационной безопасности. ISO/IEC 27001 подходит компаниям любого размера и отрасли. По нему можно пройти сертификацию, если партнеру нужен внешний документ о том, что заявленная область компании управляет рисками по требованиям стандарта. Область важна: сертификат может относиться к конкретному сервису, офису или процессу, а не автоматически ко всей компании.
ISO/IEC 27002:2022 помогает выбрать меры защиты и объясняет, как работать с доступами, криптографией, персоналом, поставщиками и инцидентами. Это практическое руководство по контролям. Для аудита по ISO/IEC 27001 оно помогает понять, какие меры проверять и какие доказательства запросить.
ISO 19011:2026 посвящен самому аудиту систем менеджмента. В нем описаны принципы аудита, программа проверок, методы сбора доказательств и требования к компетенциям аудиторов. Этот документ помогает организовать проверку, а требования к защите данных берут из подходящего стандарта, закона или договора.
NIST Cybersecurity Framework 2.0 — фреймворк для управления киберрисками. Он описывает шесть связанных направлений:
- Govern — управлять: определить правила, роли, допустимый уровень риска и требования к поставщикам.
- Identify — выявлять: понять, какие есть системы, данные, процессы и уязвимости.
- Protect — защищать: настроить доступы, обучение, защиту данных и платформ.
- Detect — обнаруживать: замечать подозрительные события и признаки атаки.
- Respond — реагировать: локализовать инцидент, разобраться в причинах и сообщить нужным людям.
- Recover — восстанавливать: вернуть системы в работу и учесть выводы после инцидента.
NIST CSF 2.0 описывает желаемые результаты и оставляет компании выбор конкретных средств. Например, он требует управлять доступом, а компания сама решает, будет ли использовать конкретный IAM, аппаратные ключи или другой способ. Заказчику показывают профиль текущего состояния — описание того, как защита устроена сейчас, — целевой профиль с желаемым уровнем защиты и доказательства выполнения выбранных мер.
CIS Critical Security Controls v8.1 — приоритизированный набор технических и организационных мер против распространенных атак. В нем есть инвентаризация устройств и программ, управление аккаунтами, настройка систем, работа с уязвимостями, журналы, резервные копии, реагирование на инциденты и пентесты. Для разного уровня зрелости предусмотрены Implementation Groups: IG1 содержит базовую «кибергигиену», IG2 добавляет более сложные меры, IG3 включает полный набор. CIS Controls удобны, когда компании нужен список конкретных действий для команды. Это ориентир и набор практик, а обязательность появляется из договора, внутреннего решения или ссылки на него в требованиях заказчика.
В международных проектах отдельно учитывают законы тех стран, где компания работает и предлагает услуги. Например, GDPR — европейский закон о защите персональных данных. Он может применяться к компании за пределами ЕС, если она предлагает товары или услуги людям в Евросоюзе либо отслеживает их поведение. GDPR задает требования к законности обработки, правам людей, безопасности и ответственности организации. ISO, NIST и CIS помогают построить защиту, а GDPR определяет юридические обязанности компании перед людьми и надзорными органами.
3. Компания готовит материалы
Компания собирает для проверки схему инфраструктуры, список систем, регламенты, данные об учетных записях, старые отчеты, записи об инцидентах, настройки и журналы. К этому добавляют матрицу ролей, список подрядчиков, перечень исключений, отчеты о резервном копировании, результаты сканирований и открытые задачи по уязвимостям.
Ответственный сотрудник проверяет даты на документах, владельцев систем и период, за который выгружены журналы. Доступ аудитора ограничивают: для чтения дают отдельные учетные записи, секреты передают через согласованный канал, а активные тесты проводят на тестовых данных или в оговоренное время. Старая схема пригодится для истории, но сегодняшнюю сеть по ней уже не разберешь.
4. Изучают документы, людей и системы
Аудитор обычно движется от общего к частному. Сначала читает правило и схему, затем разговаривает с владельцем процесса, после этого берет выборку заявок и открывает настройки системы. В конце сверяет результат с журналами или проводит разрешенный технический тест.
5. Аудитор описывает проблему
Хорошее описание отвечает на вопросы:
- Что обнаружили?
- Какими данными это подтверждается?
- Какое правило нарушено?
- Какой системе или процессу грозит проблема?
- Что может случиться?
- Как снизить риск?
Если находкам присваивают уровни риска, нужно объяснить шкалу. Обычно отдельно оценивают вероятность события, доступность уязвимого объекта, ценность данных и тяжесть последствий. Сотрудникам важно понимать цвет или балл, причину оценки и решение: проблему исправляют сегодня, включают в план или принимают как остаточный риск.
6. Ответственные сотрудники проверяют факты
Перед выпуском отчета владельцы систем сверяют названия, настройки и обстоятельства. Владелец может принести новые данные или указать на ошибку. После этого описание проблемы уточняют, если это нужно.
Здесь владелец системы может принести новые данные, уточнить границы находки или согласовать временное исключение. Одного объяснения мало: если сотрудник говорит, что MFA включена, аудитор просит показать настройку или событие успешного входа.
Руководителю нужны главные риски, возможные потери и решения. Техническим специалистам нужны точный объект, доказательство, причина и способ проверить исправление.
7. Исправляют проблему
Для каждой задачи назначают ответственного, срок, зависимые работы и способ проверки. Исправление должно устранять причину. Например, для лишнего доступа закрывают текущую роль и обновляют процесс пересмотра прав.
После исправления снова открывают настройку, журнал или результат теста. Для сложной проблемы проводят повторную выборку, а для технической уязвимости повторяют согласованный тест. Если риск снизился, но полностью не исчез, в отчете оставляют остаточный риск.
Как проверяют цепочку от события до реакции
Аудитор берет заранее согласованную тестовую ситуацию и проходит ее от первого действия до записи результата. Допустим, нужно проверить защиту от подбора пароля. В тестовой среде несколько раз вводят неверный пароль тестовой учетной записи. IAM записывает попытки входа, SIEM получает эти записи, связывает их правилом корреляции и отправляет предупреждение ответственному сотруднику. Сотрудник разбирает уведомление и фиксирует результат в заявке или журнале инцидента. Если проверяют изоляцию устройства, EDR должен закрыть тестовому компьютеру сетевой доступ, а аудитор — увидеть это в журнале и подтвердить результат.
Для каждого шага заранее определяют ожидаемый результат: какая запись должна появиться, куда она должна попасть, кто получит уведомление и какое действие выполнит. Активную проверку проводят с письменного разрешения, в тестовой среде или на тестовых данных. Так аудитор проверяет полный путь события — от действия пользователя до реакции команды. Панель может показывать зеленые индикаторы, а передача сигнала, запись в журнале или изоляция устройства все равно требуют отдельной проверки.
Что должно быть в отчете по итогам аудита
Отчет помогает руководству решить, какие риски принять и на что выделить деньги. Специалисты по информационной безопасности получают из него задачи.
Обычно в отчет входят:
- краткое резюме для руководства;
- цель и границы аудита;
- правила и методы проверки;
- список найденных проблем;
- доказательства и затронутые системы;
- риски и возможные последствия;
- рекомендации и приоритеты;
- ответственные, сроки и способ повторной проверки.
Для внешнего аудита заранее готовят программу работ, договор и правила доступа, список нужных материалов, итоговый отчет и план исправлений. Для пентеста или другого активного теста отдельно записывают, что можно проверять, в какое время и как остановить работу при сбое.
Если нужен сертификат или официальное заключение, заранее уточняют список документов по выбранной процедуре.
Что делают после аудита информационной безопасности
После аудита команда разбирает рекомендации по риску и срочности. На решение влияют важность системы, возможный ущерб, сложность исправления и связь с другими задачами.
Большую рекомендацию разбивают на несколько задач. Например, для MFA нужно найти все административные учетные записи, выбрать способ входа, включить второй фактор, обновить правила выдачи прав и проверить исключения.
Каждое исправление подтверждают настройкой, записью журнала или новым тестом. Следующий аудит должен учитывать новую схему и выводы прошлой проверки.
