Автор: Александр Колодяжный, руководитель проекта, отдел ИТ-аудита, блок внутреннего аудита, ПАО «МТС», член Ассоциации «Институт внутренних аудиторов»
В этой статье мы рассмотрим описание и оценку контролей, реализуемых в базовых процессах информационной безопасности (далее – ИБ). Обратите внимание, что перечень описанных ниже процессов не является полным, это лишь базовые процессы, с которых можно начать ИБ-аудит организации.
Расширенный список ИБ-процессов для аудита можно сформировать, например, на основании применяемых тактик и методов злоумышленников, опубликованных в базе знаний MITRE ATT&CK® https://attack.mitre.org/
К базовым процессам ИБ относятся:
-
управление доступом,
-
управление обновлениями безопасности программного обеспечения.
Процессы удобно масштабируются как на уровень ИТ-инфраструктуры, так и на уровень отдельной информационной системы (далее – ИС); контроли, описанные ниже, актуальны на всех уровнях. В статье я остановлюсь на анализе и оценке контролей в масштабе ИТ-инфраструктуры.
Процесс управления доступом
Целью процесса управления доступом (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.
В заключение
В статье я намеренно не использовал сложные технические описания и формулировки. Однако пусть вас не смущает простота изложенного материала: пренебрежение значимостью указанных процессов может привести к необратимым последствиям.
Кейсы информационной безопасности, описанные в статье, – это лишь малая часть из перечня нештатных ситуаций, которые могут возникнуть. Вероятность осуществления рисков удаления, несанкционированного изменения либо кражи данных, а также недоступности ИТ-сервисов предприятия крайне велика в случае некорректной реализации описанных в статье процессов.
