Что такое аудит безопасности компьютерной системы

Обновлено: 15.01.2025

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

Составляющие внутреннего аудита

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

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

Перечень потенциально уязвимых мест, которые будут проверяться. Сетевые правила доступа, настройки операционных систем, используемые средства защиты информации, защищенность помещений с оборудованием и другое.
Методы проверки. Среди них могут быть тестирование на проникновение, оценка осведомленности сотрудников в вопросах ИБ и другое. Что касается конкретных действий при аудите, то они во многом перекликаются с действиями потенциального злоумышленника, только без причинения реального вреда. Это сканирование портов, поиск уязвимостей в сетевых службах и старых версиях ПО, социальная инженерия и многое другое.
Содержание итоговых отчетов. Отдельно нужно прописать требование, чтобы в отчетах подробно описывались все недостатки и тонкие места ИТ-инфраструктуры. Среди обязательных элементов отчета должны быть: подробное документирование состояния ИТ-инфраструктуры на момент аудита, анализ развития нагрузки на сеть и предложения по оптимизации оборудования, ПО и сервисов.
Расписание с точными датами. Внутренний аудит информационной безопасности должен быть важной частью постоянной работы. Для этого нужно составить точное расписание всех действий (включая подготовку отчетов) как минимум, на год вперед.

Аудит Wi-Fi-сети

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

подключены ли к сети несанкционированные устройства?
соответствуют ли роутеры стандартам ИБ? Не используются ли в них методы защиты, для которых существуют документированные способы обхода?
нет ли ошибок в конфигурации устройств, которые подключены к сети?
достаточно ли осведомлены сотрудники о культуре информационной безопасности при подключении к беспроводным сетям?

Пентест

Атаки бывают разными. Один из возможных методов проверки уровня защищенности инфраструктуры — тест на проникновение. Для него можно как использовать традиционные для пентеста модели White box и Grey box (имитирующие разные типы атак) или же модифицировать их под себя, предполагая, что у хакера имеется или не имеется информация об устройстве корпоративной сети.

Итоговые документы

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

Топология сети и используемое оборудование с разбивкой по помещениям. Следует описать назначение и функцию каждого устройства. Здесь же фиксируется состояние компонентов, а также способы подключения к интернету.
Серверы. Описываются их физическое расположение и характеристики, используемая система защиты информации, сетевое оборудование, источники бесперебойного питания.
Пользовательские места. Сколько помещений, где и как они расположены, сколько в них рабочих мест, сколько человек имеет к ним доступ, имеют ли к ним доступ сотрудники других компаний? Если имеют, то насколько эти компании имеют к вам отношение? Ответы на эти вопросы помогут понять, насколько защищена ваша инфраструктура.
Рекомендации по улучшению ситуации. Самый важный пункт, который состоит из конкретных советов — где, что и как можно улучшить, чтобы обезопасить себя от проблем. Причем заполнять его нужно без установки «на это точно не дадут денег».

Адаптация

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

Общая культура ИБ

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

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

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

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

Различия внутреннего и внешнего аудита

Внутренний аудит выполняют сотрудники отдела ИБ компании. Перед этим создаётся документ, в котором есть следующие пункты:

поиск уязвимостей;
выбор метода проверки;
структура итогового отчёта;
расписание с датами проведения.

Цель внутреннего аудита добиться соответствия ИТ-инфраструктуры определённым требованиям.

Для проведения внешнего аудита привлекают сторонних специалистов. Компании, которые могут выполнить такую работу, обязаны иметь лицензию регулятора (ФСТЭК, ТЗКИ, ФСБ, сертификат ISO 27001). В отличие от внутреннего внешний разноплановый, требует привлечения разных специалистов, части из которых иногда в штате компании-заказчика нет.

Цель внешнего аудита – выявить проблемы, определить точки роста, получить авторитетное мнение стороннего специалиста, подтвердить правильность подходов, соответствие нормативным требованиям.

В процессе ИТ аудита проверяют:

состояние ИТ-инфраструктуры;
если необходимо, квалификацию специалистов информационного отдела;
состояние системы информационной безопасности и процессов в компании.

Вообще же, направления могут быть самыми разными. Например, компания может провести проверку Wi-Fi-сети, чтобы выявить подключения несанкционированных устройств, соответствие роутеров стандартам безопасности. Иногда ИБ проверяют «в бою» – организуют фишинговые атаки, чтобы проверить правильность действий сотрудников.

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

Плюсы и минусы

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

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

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

Когда и кому нужно проводить аудит ИБ

Чаще всего компании обращаются для проведения it аудита в таких случаях:

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

Кроме выявления и устранения потенциально уязвимых мест аудит помогает руководству компании повысить контроль над работой информационного отдела и улучшить бизнес-процессы.

Этапы аудита информационной безопасности

Аудит проходит в несколько этапов:

Составляют план. После этого заказчик согласовывает его с клиентом.
Аудитор изучает документацию. Её должен предоставить заказчик.
Собственно проверка на месте. Подрядчик приезжает в компанию (если это не внутренний аудит) и на месте оценивает состояние ИТ-инфраструктуры и/или отдельных её элементов.
Дополнительные мероприятия. Это может быть анкетирование сотрудников, исследование программного обеспечения, тестирование на проникновение.

Ещё какое-то время будет затрачено на составление отчёта. Его аудитор передаёт заказчику.

Этапы аудита ИБ

Результаты аудита

Результатами проверки становятся итоговые отчёты, структуру которых прописывают заранее:

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

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

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

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

выросла компания, увеличилось количество сервисов и участников сети;
произошла утечка конфиденциальной информации и необходимо устранить «дыры» в информационной безопасности;
в штате организации нет сотрудников, ответственных за информационную безопасность.

Эффективный способ аудита – тестирование на проникновение, в ходе которого моделируется реальная атака злоумышленников. Такой подход позволяет объективно оценить уровень защищенности корпоративной инфраструктуры и понять, могут ли противостоять атакам применяемые в компании средства защиты.

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

На основе аудита наши сотрудники предоставят:

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

Закажите услугу по аудиту информационной безопасности, просто оставив заявку!

В рамках теста на проникновение специалисты «Калуга Астрал» выполняют анализ вашей IT-инфраструктуры, подготавливают список доступных ресурсов, портов, служб, используемых серверов. Таким же образом проводят анализ правил файерволов и систем предотвращения атак.

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

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

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

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

К базовым процессам ИБ относятся:

управление обновлениями безопасности программного обеспечения.

Процессы удобно масштабируются как на уровень ИТ-инфраструктуры, так и на уровень отдельной информационной системы (далее – ИС); контроли, описанные ниже, актуальны на всех уровнях. В статье я остановлюсь на анализе и оценке контролей в масштабе ИТ-инфраструктуры.

Процесс управления доступом

Целью процесса управления доступом (access management) является исключение следующих рисков:

недоступность сервисов и информационных систем предприятия в результате эксплуатации учетных записей (далее – УЗ) неавторизованных пользователей либо УЗ пользователей с избыточными правами доступа;

компрометация данных предприятия (утечка данных / внесение несанкционированных изменений в информационные системы предприятия) в результате эксплуатации УЗ неавторизованных пользователей, либо УЗ пользователей с избыточными правами доступа.

Рассмотрим контроли, внедрение которых необходимо для минимизации данных рисков:

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

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

Контроль доступа к ресурсам неавторизованных пользователей

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

Показателем некачественно реализованного процесса является обнаружение хотя бы одной активной УЗ неавторизированного пользователя. Примером таких УЗ могут быть: УЗ уволенных сотрудников; УЗ, эксплуатирующиеся без соответствующей заявки на создание, и т.д. Агрессивность метрики показателя качества контроля (т.е. обнаружение хотя бы одной такой УЗ) обусловлена спецификой направления ИБ. Под активными УЗ уволенных сотрудников могут вноситься несанкционированные изменения в ИС предприятия (например, корректировка финансовой отчетности).

Оценить качество реализации процесса можно на основании анализа списка учетных записей инфраструктуры предприятия. Перечень УЗ, эксплуатируемых в инфраструктуре предприятия, необходимо сравнить с мастер-списком (актуальный список сотрудников можно получить в отделе кадров). Если были обнаружены УЗ, не состоящие в указанном списке, администратору (владельцу) ресурса отправляется запрос с просьбой предоставить комментарии по обнаруженным УЗ. Как правило, администратор (владелец) ресурса сразу блокирует порядка 90% УЗ, по которым был сформирован запрос. Для оставшихся 10% предоставляется аргументированное обоснование необходимости в эксплуатации УЗ.

Контроль избыточных прав доступа у пользователей предприятия

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

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

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

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

Оценить качество реализации процесса можно на основании анализа списка УЗ с указанием статуса. На примере систем управления базами данных (далее – СУБД) контроль прав доступа пользователей осуществляется посредством анализа результата исполнения специально сформированного SQL-запроса. Указанный запрос возвращает список активных УЗ и роль для каждой УЗ. Предположим, что в анализируемой СУБД присутствует около 10 УЗ с максимальными правами. Лучшие практики не рекомендуют эксплуатировать более двух УЗ с максимальными правами в СУБД (одна – для выполнения задач администратора СУБД, вторая, локальная, – на случай нештатных ситуаций). Администратору СУБД отправляется запрос с просьбой обосновать избыточное количество УЗ с привилегированными правами. Как и в предыдущем примере, администратор предоставляет аргументированную причину необходимости эксплуатации УЗ с привилегированными правами либо изымает права у УЗ.

Личный опыт и подводные камни

Инструменты аналитики. Хорошим решением, представляющим множество инструментов для сравнения списков большого объема (до 20 млн строк) с различными сложными условиями, является структурированный язык запросов SQL. Business intelligence-решения для аналитики такие как Qlik Sense, Tableau, Microsoft Power BI и другие также помогут выполнять аналитику по большим объемам данных.

Подводные камни. Самой большой проблемой при анализе УЗ является качество предоставляемых данных. Почти всегда списки из отдела кадров «не бьются» со списками УЗ без дополнительных «манипуляций». В таких случаях приходится искать «прослойку» в виде дополнительных источников данных. Например, кадры выгружают текущий список сотрудников в формате: ФИО (Сергей Петрович Иванов), статус сотрудника (действующий сотрудник / уволен). Необходимо осуществить анализ УЗ СУБД Oracle в формате: имя УЗ (spivanov), статус УЗ (OPEN / LOCKED). Прямое сравнение указанных списков корректно выполнить невозможно. Решением в данном случае может быть использование списков службы каталогов Active Directory в качестве «прослойки» (в списках службы каталогов присутствуют поля с ФИО сотрудника и наименованием УЗ сотрудника; указанные поля можно использовать как ключевые). Ниже схематично показано применение данных из службы каталогов в качестве «прослойки»:

На схеме видно, что одна из активных УЗ СУБД принадлежит уволенному сотруднику (обозначена красным цветом), вторая УЗ принадлежит действующему сотруднику (обозначена зеленым цветом).

Также необходимо понимать принцип организации доступа к ресурсам ИТ-инфраструктуры. Все УЗ организации можно категорировать по уровням эксплуатации:

службы каталогов (Active Directory) и/ или управления учетными данными (Identity management system);

операционной системы серверов (далее – ОС);

прикладной уровень приложений (например, электронная почта, ERP-система);

систем управления базами данных (СУБД);

ОС сетевого и прочего оборудования.

Это деление довольно условное, и существует немало примеров, когда сотрудник использует одну УЗ при входе в ОС сервера и при подключении к СУБД; но без понимания принципа многоуровневого доступа к ресурсам организации крайне сложно правильно определить периметр и полноту работ по анализу УЗ. Как правило, контроль доступа осуществляется на уровне службы каталогов и на уровне прикладных приложений, остальные УЗ остаются без внимания.

Процесс управления обновлениями безопасности программного обеспечения

Целью процесса управления обновлениями безопасности программного обеспечения (далее – ПО) является исключение следующих рисков:

недоступность сервисов и информационных систем предприятия в результате эксплуатации уязвимости в ПО с устаревшими обновлениями безопасности;

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

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

Показателем качественно реализованного процесса является отсутствие на предприятии ПО с устаревшими обновлениями безопасности.

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

И снова: агрессивность метрики показателя качества контроля (обнаружение хотя бы одного экземпляра такого ПО) обусловлена спецификой направления ИБ. Вектором атаки вируса-шифровальщика может стать сервер или рабочее место сотрудника с неактуальными обновлениями безопасности операционной системы.

Оценить качество реализации процесса можно на основании анализа статуса установленных обновлений безопасности для ПО (актуальное/ неактуальное). В качестве контрольной даты для определения статуса используется дата, соответствующая дате выпуска обновлений вендором + период тестирования обновления (процесс тестирования вновь вышедших обновлений с указанием времени проведения тестовых работ должен быть описан в нормативной документации предприятия; предположим, что он равен 25 дням) + период установки обновлений (предположим, что он равен 7 дням). Процесс определения статуса установленного обновления безопасности отображен на схеме 2:

В приведенном примере для обновлений, выпущенных 01.02.2021, контрольной датой является 05.03.2021. В случае, если дата установки обновления меньше, чем контрольная дата, статус обновления для ПО – актуальное. Если обновление не установлено до контрольной даты, статус обновления для ПО – неактуальное.

Личный опыт и подводные камни:

Одной из распространенных ошибок, допускаемых при оценке качества реализации процесса, является поверхностный анализ реализации процесса из-за непонимания принципов эксплуатации ПО. На примере СУБД MSSQL, реализованной на сервере с ОС Windows Server, как правило, проверяется актуальность установленных обновлений для ОС Windows Server. В случае, если для ОС Windows Server установлены актуальные обновления, сервер считается обновленным и не попадает в зону риска, но по факту это не так, и на обновленной ОС Windows Server может быть реализована СУБД MSSQL с устаревшими обновлениями и со всеми вытекающими рисками ИБ. Ниже на схеме приведены примеры поверхностного и полного анализов качества реализации процесса:

На схеме 3 серверу 1 присвоен статус обновления для ПО – «актуальный», указанная оценка для сервера будет некорректной, т.к. СУБД MSSQL не обновлена. Корректная оценка актуальности ПО приведена на схеме 4 серверу 2.

В заключение

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

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

Читайте также: