Аудит ит безопасности: его виды, стандарты и лучшие практики

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

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

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

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

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

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

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

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

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

Результаты аудита безопасности

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

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

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

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

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

Как аудит кибербезопасности помогает защите от DDoS-атак

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

Например, на сайте нет верхнего ограничения по количеству символов в пользовательском пароле. Хакер автоматически сгенерирует пароль в миллион символов, такой запрос (особенно если их несколько) может вывести сервер из строя. Атака будет сходна с DDoS по последствиям. У сайта сначала упадет производительность, а затем он полностью перестанет отвечать на запросы.

Или представим, что у злоумышленника может быть возможность заставить приложение взаимодействовать с внешней службой, такой как веб- или почтовый сервер. Он узнает реальный IP-адрес сервера в обход межсетевого экрана и защиты от DDoS и произведет успешную атаку типа отказ в обслуживании.

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

Международный стандарт ISO 27001

Иногда можно услышать о прохождении тем или иным банком аудита на соответствие требованиям международного стандарта «ISO/IEC 27001:2005» (его полный российский аналог — «ГОСТ Р ИСО/МЭК 27001-2006 — Информационная технология — Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности — Требования»). По сути, данный стандарт — это набор лучших практик по управлению информационной безопасностью в крупных организациях (небольшие организации, в том числе и банки, не всегда в состоянии выполнить требования этого стандарта в полном объеме). Как и любой стандарт в России, ISO 27001 — сугубо добровольный документ, принимать который или не принимать решает каждый банк самостоятельно. Но ISO 27001 является стандартом де-факто по всему миру, и специалисты многих стран используют этот стандарт как некий универсальный язык, которым следует руководствоваться, занимаясь информационной безопасностью.

С ISO 27001 связаны и несколько не самых очевидных и не часто упоминаемых моментов

Однако с ISO 27001 связаны и несколько не самых очевидных и не часто упоминаемых моментов. Во-первых, аудиту по данному стандарту подлежит не вся система обеспечения информационной безопасности банка, а только одна или несколько из ее составных частей. Например, система защиты ДБО, система защиты головного офиса банка или система защиты процесса управления персоналом. Иными словами, получение сертификата соответствия на один из оцениваемых в рамках аудита процессов не дает гарантии, что остальные процессы находятся в таком же близком к идеальному состоянию. Второй момент связан с тем, что ISO 27001 является стандартом универсальным, то есть применимым к любой организации, а значит, не учитывающим специфику той или иной отрасли. Это привело к тому, что в рамках международной организации по стандартизации ISO уже давно ведутся разговоры о создании стандарта ISO 27015, который является переложением ISO 27001/27002 на финансовую отрасль. В разработке этого стандарта активное участие принимает и Банк России. Однако Visa и MasterCard против проекта этого стандарта, который уже разработан. Первая считает, что проект стандарта содержит слишком мало нужной для финансовой отрасли информации (например, по платежным системам), а если ее туда добавить, то стандарт надо переносить в другой комитет ISO. MasterCard также предлагает прекратить разработку ISO 27015, но мотивация другая — мол, в финансовой отрасли и так полно регулирующих тему информационной безопасности документов

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

Интеграторы же всего лишь помогают компаниям выполнить требования стандарта, которые затем будут проверены официальными аудиторами (их еще называют регистраторами, органами по сертификации и т.д.). Пока продолжаются споры о том, внедрять банкам ISO 27001 или нет, отдельные смельчаки идут на это и проходят 3 стадии аудита соответствия:

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

Кому же нужен ISO 27001 в России? Если рассматривать этот стандарт не только как набор лучших практик, которые можно внедрять и без прохождения аудита, но и как процесс сертификации, знаменующий собой подтверждение соответствия банка международным признанным требованиям по безопасности, то ISO 27001 имеет смысл внедрять либо банкам, входящим в международные банковские группы, где ISO 27001 является стандартом, либо банкам, планирующим выход на международную арену. В остальных случаях аудит соответствия ISO 27001 и получение сертификата, на мой взгляд, не нужно. Но только для банка и только в России. А все потому, что у нас есть свои стандарты, построенные на базе ISO 27001.

Де-факто инспекционные проверки Банка России проводились до недавнего времени именно в соответствии с требованиями СТО БР ИББС

В чем заключается проверка на соответствие стандартам?

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

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

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

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

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

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

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

организационный и инструментарный;
исследование уровня защиты ИС;
определение степени соответствия ИБ стандартам и нормам.

А теперь рассмотрим данные этапы подробнее.

Проведение аудита ИТ безопасности подразумевает:

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

Результат аудита ИТ безопасности – получение полной, независимой и объективной оценки текущей ситуации в данной сфере.

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

В комплексный аудит ИБ входит:

экспертный аудит
проверка web-безопасности
тест на проникновение
аудит ИС

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

Требования

В стандарте ГОСТ Р 57580 говорится о том, что должна осуществляться полноценная защита информации в направлениях:

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

Применительно к оценке единой биометрической системы по ГОСТу 57580 исключаются направления по мобильным устройствам (ибо существующие решения не обладают соответствующим функционалом).

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

Автоматизированные рабочие места;
Сетевые устройства;
СКУД;
Аппаратные модули безопасности;
Серверные устройства;
Оборудование печати и копирования данных;
Системы хранения данных;
Общедоступные объекты (банкоматы, платежные терминалы).

Под ресурсами принято понимать:

Базы данных;
Сетевые ресурсы;
Виртуальные машины;
АС;
Почтовые сервисы;
Web-сервисы;
Ресурсы доступа к данным.

Финансовая компания во время аудита должна предоставить полноценную информацию проверяющей стороне.

Это одно из нововведений, т.к. в оценках по старым критериям, таким как СТО БР ИББС или 382-П такого положения не было. И в результате нельзя было однозначно установить был ли факт обмана со стороны аудитора или это проверяемая организация дала «неправильные» свидетельства.

Важно, что компания-аудитор самостоятельно принимает решение по поводу проверки объектов и ресурсов, выборки среди них необходимых для проведения аудита

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

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

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

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

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

Организационные угрозы законодательного, административного или процедурного типа. К примеру, это может быть отсутствие контроля и (или) неэффективно используемые меры управления такими процессами как управление конфигурациями, управление изменениями, управление обновлениями и так далее, а также атаки через привлекаемые подрядные организации.
Угрозы эксплуатационного типа, такие как, к примеру, неподдерживаемые и (или0 нелицензионные варианты операционных систем, системного программного обеспечения, программных продуктов, а также уязвимости веб-серверов и (или) применение небезопасных протоколов управления (применение SSL и TLS способно привести к перехвату транслируемой информации об аутентификации) и передачи информации. Кроме того, это наличие слабых паролей и (или) недостаточно эффективная парольная политика в организации.
Программно-технический тип угроз, то есть, архитектурные угрозы. Это может быть к примеру, возможность подключения корпоративных устройств к незащищенным сегментам гостевых беспроводных сетей компании, а также наличие неконтролируемых информационных потоков.
Другие аспекты обеспечения информационной безопасности, которые следует учитывать в процессе реализации аудита, для определения их приоритетов.

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

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

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

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

Экспертный аудит

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

Ключевые этапы экспертного аудита:

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

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

Далее ГОСТом предлагается следующая стратегия по инцидент-менеджменту:

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

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

Как подготовиться к аудиту безопасности

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

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

Этапы подготовки простые, а главный совет — предоставьте аудиторам данные от всего, с чем они будут работать. Вот примерный план подготовки:

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

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

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

Убедитесь, что все понимают важность этого процесса.

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

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

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

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

Что проверяют в ходе аудита

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

В ходе внутреннего аудита специалисты:

устанавливают права доступа сотрудников к информации;
проверяют состояние средств защиты данных;
проверяют информированность сотрудников о внутренних правилах ИБ.

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

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

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

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

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

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

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

службы каталогов (Active Directory) и/ или управления учетными данными (Identity management system);
операционной системы серверов (далее – ОС);
прикладной уровень приложений (например, электронная почта, ERP-система);
систем управления базами данных (СУБД);
ОС сетевого и прочего оборудования.

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