Пример программы аудита иб

Типовая программа проведения проверки филиала

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

№
п / п
Мероприятие
Описание
Регламентирующие документы
Срок исполнения
Ответственный за выполнение сотрудник
I этап. Начало проверки
Представление должностных лиц Банка, проводящих проверку, руководству проверяемого филиала
-Служебное удостоверение;
-Приказ или распоряжение о проведении проверки филиала.
__ . __ .2015

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

Заверенная копия приказа или распоряжения о проведении проверки филиала.
__ . __ .2015

II этап. Проведение проверки соответствия уровня информационной безопасности филиала
нормативным правовым актам

Проверка соблюдения требований, установленных законодательством Российской Федерации, в области информационной безопасности банковской сферы, а также при обработке персональных данных работников и клиентов филиала

Открытый урок. Аудит ИБ на практике

Документы, подтверждающие принятие мер:
1) Кадровая политика филиала;

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

3) Положение о подразделении, осуществляющем функции по организации защиты персональных данных;

4) Приказы/распоряжения о назначении ответственных лиц филиала за информационные ресурсы и системы филиала.

-Федеральный закон от 27.07.2006 №152-ФЗ “О персональных данных”;
-Постановление Правительства РФ от 01.11.2012г. № 1119;

-Письмо ЦБ РФ от 14 марта 2014г. №42-Т “Об усилении контроля за рисками, возникающими у кредитных организаций при использовании информации, содержащей персональные данные граждан”;

-Приказ ФСБ от 10 июля 2014 №378 “Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности ПДн при их обработке в ИСПДн с использованием средств защиты информации, необходимых для выполнения установленных правительством РФ требований к защите ПДн для каждого из уровней защищенности”.

-Политика Банка в области обработки и защиты ПДн (общедоступная, размещаемая на сайте Банка)
-Положение о работе с персональными данными работников Банка;
-Приказы о назначении администраторов информационных систем Банка (АБС, ДБО и др.).
__ . __ .2015
Мониторинг программного обеспечения на рабочих станциях и серверах филиала

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

-Политика информационной безопасности Банка.
__ . __ .2015- __ . __ .2015

Проверка состояния антивирусной защиты в филиале (включая защиту серверов, рабочих станций, интернет-шлюза)

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

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

Анализ журналов систем антивирусной защиты.
Выявление рабочих станций и серверов, не снабженных средствами антивирусной защиты.

-Письмо ЦБ РФ от 24 марта 2014г. №49-Т “О рекомендациях по организации применения средств защиты от вредоносного кода при осуществлении банковской деятельности”.

__ . __ .2015- __ . __ .2015
Аудит групп локальных администраторов на рабочих станциях и серверах филиала

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

-Политика информационной безопасности Банка;

-другие документы Банка, регламентирующие правила контроля идентификации и предоставления прав доступа.

__ . __ .2015- __ . __ .2015
Аудит учетных записей пользователей в каталоге Active Directory

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

-Политика информационной безопасности Банка;

-другие документы Банка, регламентирующие правила контроля идентификации и предоставления прав доступа.

__ . __ .2015- __ . __ .2015
Аудит парольной политики в корпоративной сети филиала

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

-Стандарт Банка России: “Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Общие положения” (СТО БР ИББС-1.0-2014);

__ . __ .2015- __ . __ .2015
Аудит доступа к съемным носителям информации
Аудит политик контроля доступа к съемным носителям и внешним портам на рабочих станциях филиала.
-Политика информационной безопасности Банка;

-другие документы Банка, регламентирующие правила контроля идентификации и предоставления прав доступа.

__ . __ .2015- __ . __ .2015
Аудит сетевой инфраструктуры на наличие уязвимостей

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

__ . __ .2015- __ . __ .2015
Аудит прав доступов сотрудников к сетевым ресурсам и АБС

Аудит на соответствие прав доступа сотрудников Заявкам на предоставление доступа к ресурсам БИС и АБС.

-Политика информационной безопасности Банка;

-другие документы Банка, регламентирующие правила контроля идентификации и предоставления прав доступа.

__ . __ .2015- __ . __ .2015

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

Соблюдение требований, изложенных в эксплуатационной документации к НСД и СКЗИ. Проверка журналов поэкзем-плярного учета СКЗИ.

-Постановление Правительства РФ от 16.04.2012 № 313 «Об утверждении Положения о лицензировании деятельности по разработке, производству, распространению шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств, выполнению работ, оказанию услуг в области шифрования информации, техническому обслуживанию шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств (за исключением случая, если техническое обслуживание шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств, осуществляется для обеспечения собственных нужд юридического лица или индивидуального предпринимателя)»;

-Инструкция об организации и обеспечении безопасности хранения, обработки и передачи по каналам связи с использованием средств криптографической зашиты информации с ограниченным доступом, не содержащей сведений, составляющих государственную тайну, утвержденной Приказом ФАПСИ от 13.06.2001 № 152.

Источник: www.securitylab.ru

ИТ-аудит: анализ базовых процессов информационной безопасности

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

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

Целью процесса управления доступом (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.

В заключение

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

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

Источник: www.audit-it.ru

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

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

Необходимо провести аудит ИБ?

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

Музалевский Федор Александрович

Ведущий эксперт компьютерно-технического направления

Опыт: Экспертная работа с 2010 года. Педагогический стаж с 2012 года. Кандидат физико-математических наук. Доцент кафедры ВМ и ИТ ФГБОУ ВО “ВГУИТ”

Задать вопрос эксперту: Музалевский Федор Александрович Задать вопрос эксперту Все эксперты

Царев Евгений Олегович

Эксперт в сфере информационной безопасности

Опыт: Экспертная работа с 2011 года. Педагогический стаж с 2008 года

Задать вопрос эксперту: Царев Евгений Олегович Задать вопрос эксперту Все эксперты

Гончаров Андрей Михайлович

Юрист в области информационной безопасности

Опыт: Профессиональный опыт в области IT-права с 2015 года

Задать вопрос эксперту: Гончаров Андрей Михайлович Задать вопрос эксперту Все эксперты

Перминов Геннадий Вадимович

Эксперт в сфере информационной безопасности

Опыт: Экспертная работа и педагогический стаж с 2008 года

Задать вопрос эксперту: Перминов Геннадий Вадимович Задать вопрос эксперту Все эксперты

Аудит информационной безопасности – один из ключевых инструментов, который позволяет оценить реальную защищенность активов (в том числе ИТ-активов) компании. Результаты аудита позволяют создать/улучшить существующую систему ИБ.

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

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

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

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

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

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

К задачам аудита ИБ можно отнести:

• Подтверждение соответствия требованиям (стандартов, регуляторов и пр.)
• Выявление уязвимостей ИТ-инфраструктуры
• Выявление уязвимостей в процессах (в том числе в процессе самого обеспечения ИБ)
• Получение рекомендаций по улучшению/изменению

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

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

В качестве свидетельств выступают:

• скриншоты и фотографии
• интервью и записи сотрудников проверяемой организации
• внутренние документы и документы контрагентов проверяемой организации
• наблюдения эксперта

После получения достаточного набора свидетельств, аудитор получает оценку соответствия (количественная, например, 0.84 или качественная – “соответствует”, в зависимости от критерия).

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

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

Принято разделять аудиты ИБ на экспертные аудиты и аудита по стандартам (compliance).

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

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

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

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

Наиболее популярные стандарты/критерии/РД информационной безопасности в России, которыми пользуются аудиторы, являются:

1. ISO 27001
2. NIST SP 800-й серии
3. ГОСТ Р ИСО/МЭК 18045
4. Серия положений Банка России по информационной безопасности
5. ГОСТ 57580.х
6. ГОСТ Р ИСО/МЭК 27007
7. Серии документов ФСТЭК России по персональным данным и защите критической информационной инфраструктуры

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

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

По типу исполнителя аудиты ИБ можно разделять на:

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

Исходя из определения, для проведения конкретного аудита ИБ можно выбрать разные:

• Критерии аудита
• Проверяемые элементы ИТ-инфраструктуры (для аудита информационных систем)
• Проверяемые процессы
• Варианты получения оценок (качественных или количественных)
• Варианты собираемых свидетельств аудита
• Варианты процессов сбора свидетельств

Наиболее частыми критериями для аудита являются законы, стандарты или требования регулирующих органов. Основными регуляторами в области информационной безопасности являются ФСТЭК России, ФСБ России и Банк России. Помимо этого, применяется так называемый экспертный аудит, проводимый по неформализованному критерию обобщения лучших практик.

• Аудит по 802-П
• Аудит элементов единой биометрической системы по ГОСТ Р 57580.1-2017
• Аудит по 683-П для банка
• Аудит по 757-П для НФО
• Аудит по 719-П
• Аудит (оценка соответствия) по ГОСТ Р 57580
• Аудит на соответствие 152-ФЗ «О персональных данных»
• Аудит на соответствие стандартам серии ISO 27001

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

• Тест на проникновение (пентест)
• Аудит программного кода
• Аудит безопасности сайта или web-сервиса
• Аудит безопасности сайта

Большинство аудитов носят смешанный характер (оценивается как техническая реализация, так и документальное обеспечения деятельности). К данной категории можно отнести:

• Аудит программного обеспечения по ОУД4 и ГОСТ 15408-3
• Оценка соответствия по ОУД4
• Аудит безопасности сети на соответствие требованиям
• Аудит ИБ удаленной работы сотрудников
• Технико-правовой аудит безопасности интернет-банка
• Аудит системы мониторинга информационных систем
• Аудит системы инвентаризации оборудования
• Аудит безопасности процесса разработки программного обеспечения
• Аудит инфраструктуры на соответствие требованиям информационной безопасности
• Аудит непрерывности бизнеса с точки зрения информационной безопасности
• Аудит систем обеспечения физической безопасности
• Аудит безопасности внутренних процессов
• Аудит состояния информационной безопасности за определенный период времени
• Аудит состояния ИБ на соответствие требованиям клиентов и/или стандартов
• Аудит ИБ в рамках отдельных бизнес-процессов

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

• Экспертиза по оценке защищенности программного обеспечения или IT-системы
• Экспертиза соответствия регулированию в области криптографии
• Экспертиза продукта, сервиса или оборудования по ИБ
• Досудебная экспертиза по вопросам IT и информационной безопасности
• Экспертиза документов в области информационной безопасности
• Экспертиза инцидента информационной безопасности
• Экспертиза проектов 1С
• Экспертиза базы данных
• Экспертиза электронной подписи (ЭЦП)
• Экспертиза электронной переписки (email, смс, WhatsApp, Telegram, Viber и пр.)
• Экспертиза разработанного программного обеспечения (ПО)
• Экспертиза в спорах по IT-контрактам
• Экспертизы в спорах по хищению денежных средств через ДБО (Интернет-банк)
• Экспертиза продукта, сервиса или оборудования по ИБ
• Экспертиза документов в области информационной безопасности
• Предварительная экспертиза инцидента информационной безопасности
• Нормативно-техническая экспертиза в области ИБ
• Цифровая криминалистика (форензика)

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

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

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

1. Инициация аудита (как правило, включает в себя разработку и подписание договора и ТЗ, в случае аудита по стандартам ссылку на конкретный стандарт)
2. Сбор информации (проведение интервью, сбор технических данных, сбор документации по информационной безопасности и пр.)
3. Обработка и анализ информации (этап на котором полученная информация интерпретируется аудитором для достижения цели аудита)
4. Разработка отчета по результатам аудита (формат отчета зависит от технического задания или стандарта ИБ)

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

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

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

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

1. Информация о Заказчике и Исполнителе аудита
2. Сведения об аудиторской группе
3. Цели аудита
4. Сроки аудита
5. Информация о ходе аудита
6. Информация о результатах аудита
7. Рекомендации по результатам аудита

Преимущества RTM Group?

• Эксперты обладают богатым опытом независимого аудита, судебных экспертиз и представительства в судах, преподавательским опытом.
• RTM Group – экспертная компания, не является интегратором и не предоставляет аутсорсинговых услуг – поэтому наш аудит не сводится к “продаже” дополнительных услуг.
• Мы – полностью независимая компания, не аффилированная ни с одним брендом или вендором.
• Мы обладаем лицензиями:

• Лицензия ФСТЭК России на деятельность по технической защите конфиденциальной информации
• Лицензия ФСТЭК России на деятельность по разработке и производству средств защиты конфиденциальной информации
• Лицензия ФСБ России на работу со средствами криптозащиты

Заказать аудит или экспертизу в сфере ИБ

Для уточнения стоимости и сроков звоните или пишите нам:

Источник: rtmtech.ru