Информационная безопасность: новые вызовы, новые решения

Введение

Эволюция угроз корпоративным данным вызвала соответствующие изменения в подходах к обеспечению информационной безопасности (ИБ) корпоративной ИТ-инфраструктуры. Множественные инциденты с данными, вызванные неправомерным использованием полномочий, повлекли создание в США отраслевых и государственных стандартов обеспечения безопасности, таких как Sarbanes — Oxley, HIPAA, COBIT и др. Из российских документов можно назвать появившийся недавно стандарт ЦБ РФ “Обеспечение ИБ организаций банковской системы РФ”. В данной статье мы предлагаем рассмотреть развитие концепции информационной безопасности с учетом новых требований к контролю доступа и хранению данных.

Управление полномочиями

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

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

Контроль доступа

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

1. Недостаточность построения периметра. Современные технологии мобильной связи позволяют обходить стандартные программные и технические ограничения на доступ в интернет с рабочего места. Запрет на электронные устройства, способные передавать и хранить информацию, может снизить производительность труда сотрудников или вообще противоречить организации бизнеса.
2. Инсайдеры. Возможность утечки данных на основании неправомерного использования предоставленных сотрудникам прав доступа вызвало появление целого сегмента рынка — DLP-систем, но проблема продолжает существовать. Отдельная категория угроз — уничтожение данных с соответствующей правкой системных журналов.
3. Недостатки стандартных средств. Практически все ОС, базы данных и приложения имеют собственные журналы аудита и средства их просмотра. Работа с ними требует определенной квалификации и часто весьма трудоемка, создание удобочитаемых отчетов может потребовать часов и даже дней. Кроме того:
   • стандартные средства обычно не рассчитаны на обработку крупных объемов данных и требуют больших ресурсов продуктивных серверов;
   • сотрудник, создающий отчет, может случайно или сознательно пропустить важное событие, а неправильная фильтрация и сортировка способны исказить результаты в отчете. Поручите создание отчета об использовании интернет-каналов администратору — 99%, что он не будет в списке “лидеров”;
   • большое количество разнородных журналов затрудняет общую корреляцию событий. Например, в журнал Microsoft SQL Server заносятся действия пользователя, но данные о его входе/выходе нужно собирать из журналов безопасности ОС и домен-контроллеров. Сопоставление данных многих разных журналов в одну временную цепочку событий — задача нетривиальная и практически невыполнимая при отсутствии специальных инструментов.
4. Большие объемы данных. Стандартный журнал аудита домен-контроллера при включенном полном аудите AD может достигать 2 Гб в сутки (!).

Виды аудита

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

Оперативный аудит

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

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

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

Сбор, долговременное хранение, проведение расследований

Отраслевые и государственные стандарты безопасности требуют длительного хранения десятков терабайтов данных о доступе персонала к ИТ-ресурсам организации (например, SOX — 5 лет). Для реализации этих требований система должна решать следующие задачи: 

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

Область применения

Рассмотрим варианты внедрения средств сбора и обработки событий безопасности.

Small:   небольшая компания — до 200 пользователей, несколько серверов. Зачастую под “производственными” системами понимается совместное использование документов на общем файловом ресурсе. Контроль над инфраструктурными серверами (например, AD) легко выполняется стандартными средствами.

Medium:   средняя компания (от 200 до 1000 пользователей, парк серверов, нередко на разных площадках). Обычно есть общие платформы ИС, содержащие серверы БД и серверы приложений. Необходим жесткий контроль полномочий в применяемых информационных системах. Контроль над инфраструктурными серверами требует отдельного внимания, так как необходимо собирать журналы с многих (часто — удаленных) серверов, а анализ полученной информации стандартными средствами затруднен.

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

Для каждой организации можно выбрать соответствующие средства аудита. Например, для небольшой компании нет необходимости собирать журналы аудита Active Directory — стандартный журнал AD security вполне достаточен для анализа и быстрого создания отчета по нему. С другой стороны, несколько домен-контроллеров могут записать в свои журналы действия одного пользователя, при этом эти записи не коррелируются в одно представление стандартными механизмами, поэтому для компаний Medium и Enterprise необходима система сбора и анализа данных журналов. Конечно, на практике нет четких границ между типами компаний, а значит, нет четких ограничений на используемый в ИТ-инфраструктуре инструментарий контроля безопасности.

Методы построения аудита ИС

На рынке ПО существует множество систем, обеспечивающих безопасность ИТ-инфраструктуры. При выборе системы под конкретную инфраструктуру необходимо обратить на некоторые технические аспекты. Выделим наиболее значимые.

Список поддерживаемых операционных систем и приложений

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

Сбор журналов

Существуют два метода сбора журналов.

1. С помощью стандартных механизмов. Журналы Windows-систем могут быть перенаправлены или получены через интерфейсы WMI и WinRM. Для *nix-систем можно применять syslog server. Основное достоинство этого пути — стандартный для ОС целевого сервера метод. Из недостатков можно отметить отсутствие кэширования, шифрования и сжатия при передаче в централизованное хранилище.
2. С помощью специализированных агентов. Применение агентов и коллекторов позволяет избежать недостатков, присущих встроенным механизмам: агенты могут быть настроены в соответствии с определяемыми политиками. При этом можно создавать сложные расписания для передачи журналов, использовать шифрование и сжатие. Агенты могут контролировать состояние журналов, например на предмет злоумышленной очистки. Но применение агентов имеет недостаток — дополнительную нагрузку на производственные серверы.

Централизованное хранение

Большинство представленных на ранке систем используют в качестве центрального хранилища журналов базу данных (обычно Oracle или MS SQL). Такой подход позволяет оперативно просматривать происходящие в инфраструктуре события и строить отчеты “на лету”, но имеет два существенных недостатка:

1. хранение журналов в БД не уменьшает, а даже увеличивает (за счет накладных расходов самой базы данных) размер используемого дискового пространства;
2. запись событий в базу ведет к очень интенсивному вводу-выводу, ведь каждое событие в журнале — фактически операция записи на диск. Так, при сборе журналов безопасности от десятка домен-контролеров в часы пик количество событий может достигать тысячи в секунду, что вызовет 1000 операций ввода-вывода в дисковой подсистеме.

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

Система отчетности

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

Заключение

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

Автор статьи — технический эксперт компании Allware Business Solutions.