5.1.4. Журнал событий безопасности. Журнал событий безопасности

Журнал регистрации событий безопасности | Информационная безопасность

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

(Ключевые моменты)

 NIST Special Publication 800-92. Guide to Computer Security Log Management.

 

1. Введение.

2. Введение в управление журналами регистрации событий компьютерной безопасности.

2.1. Основы журналирования событий безопасности.

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

• журналы специального ПО (СЗИ), обеспечивающего безопасность (раздел 2.1.1).
• журналы операционных систем (раздел 2.1.2) и приложений (раздел 2.1.3).

 

2.1.1. Системы защиты информации (СЗИ).

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

• Системы защиты от вредоносного ПО. Наиболее распространенной формой является антивирусное ПО, которое, как правило, записывает все события связанные с обнаружением вредоносных программ, попыток «дезинфекции» файлов и систем, передачи файлов на карантин. Антивирусное ПО может также регистрировать события, связанные с проведением сканирование на наличие вредоносных программ, обновлением сигнатур.
• Системы обнаружения и предотвращения вторжений. Журналы событий систем обнаружения и предотвращения вторжений содержат подробную информацию о подозрительном поведении и обнаруженных атаках, а также о действиях, предпринятых, чтобы остановить вредоносную активность. Некоторые задачи системы обнаружения вторжений, такие как проверка целостности файлов и ПО могут запускаться на периодической основе, создавая отдельные пакеты записей в журнале.
• ПО для создания безопасного удаленного доступа. Удаленный доступ часто предоставляется и защищается с использованием виртуальных частных сетей (VPN). Системы VPN обычно предоставляют возможность регистрировать успешные и неудачные попытки входа, а также дату и время подключения и отключения пользователей, объем данных, переданных и принятых в каждой сессии пользователя. Системы VPN, которые поддерживают гибкий контроль доступа, такие как Secure Sockets Layer (SSL) VPN, могут также регистрировать подробную информацию об использовании ресурсов.
• Прокси-сервер. Прокси-сервер являются промежуточным звеном (посредником) между пользователем и интернет сайтом. Прокси делает запросы веб-страниц от имени пользователей, кэширует копии полученных веб-страниц, чтобы сделать последующий доступ к этим страницам более эффективным. Прокси также может быть использован для ограничения доступа в Интернет и создания дополнительного слоя защиты между веб-клиентами и веб-сервером. Веб-прокси регистрирует информацию о посещаемых ресурсах Интернет (кто, когда и что посещал).
• Системы управления уязвимостями. Системы управления уязвимостями, обычно регистрируют историю обнаружения и устранения уязвимостей (установки патчей) каждого хоста. Также такие системы могут записывать дополнительную информацию о конфигурации хостов. Как правило, сканирование с использованием таких систем запускается на периодической, а не постоянной основе.
• Серверы аутентификации. Серверы аутентификации, как правило, регистрируют каждую попытку аутентификации, в том числе ее происхождение, имя пользователя, успех или неудача, а также дату и время.
• Маршрутизаторы. Маршрутизаторы могут быть сконфигурированы, чтобы разрешить или блокировать определенные типы сетевого трафика на основе созданных политик. Маршрутизаторы, которые блокируют трафик, как правило, настроены на регистрацию только самых базовых характеристик заблокированной деятельности.
• Межсетевые экраны. Как и маршрутизаторы, межсетевые экраны разрешают или блокируют трафик, на основании сконфигурированных политик. Однако, межсетевые экраны используют намного более сложные методы исследования трафика, они могут отслеживать состояние соединений и выполнять контентный анализ. Межсетевые экраны, как правило, имеют более сложные политики и генерируют более подробные журналы.
• Серверы карантина. Некоторые организации проверяют уровень безопасности каждого удаленного хоста, прежде чем разрешить ему присоединиться к сети. Часто это делается через установку агентов на каждом хосте и с использованием сервера карантина. Хосты, которые не отвечают на проверки сервера или которые проходят проверку будут помещены на карантин в отдельную виртуальную сеть (VLAN). Серверы карантина регистрируют информацию о состоянии проверок, в том числе, какие хосты были помещены в карантин, и по каким причинам.

На рисунке ниже представлены примеры журналов регистрации событий СЗИ.

2.1.2. Операционные системы.

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

• Системные события. Системные события — операционные действия, выполняемые компонентами ОС, такие как выключение системы или запуск сервиса. По умолчанию регистрируются события завершенные неудачей, а также наиболее значимые успешные события, но, как правило, многие ОС позволяют администраторам определять, какие типы событий будут регистрироваться. Детали, регистрируемые для каждого события, также отличаются друг от друга; каждое событие, как правило, датировано, и содержит вспомогательную информацию, такую как, коды ошибок; имя службы, имя системной или пользовательской учетной записи, связанной с событием.
• Записи аудита. Записи аудита содержат информацию о событиях безопасности, такую как удачные и неудачные попытки аутентификации, доступ к файлам, изменения в политике безопасности, изменения учетных записей (например, создание и удаление учетных записей, назначение привилегий), использование привилегий. ОС обычно позволяют системным администраторам указать, какие типы событий следует регистрировать.

Пример журнала регистрации событий ОС представлен на рисунке ниже:

2.1.3. Приложения

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

• Запросы клиента и ответы сервера, могут быть очень полезны в восстановлении последовательности событий и определении их результата. Если приложение записывает успешные аутентификации пользователей, как правило, можно определить, какой пользователь сделал каждый запрос. Некоторые приложения могут выполнять весьма подробное протоколирование, например серверы электронной почты, могут регистрировать отправителя, получателей, тему и имена вложений для каждого сообщения электронной почты. Веб-серверы регистрируют каждый запрос URL и тип ответа, предоставляемый сервером. Бизнес-приложений, например, могут регистрировать информацию о том, какие финансовые отчеты были просмотрены пользователем. Эта информация может быть использована для идентификации или расследования инцидентов и помогать контролировать использование приложений.
• Информация об учетных записях, например, успешные и неудачные попытки аутентификации, изменения (например, создание и удаление учетных записей, назначение и отзыв привилегий), а также использование привилегий. По такой информации можно идентифицировать попытки подбора паролей и эскалации привилегий, и контролировать использование приложений (когда, какой пользователь и какое приложение использовал).
• Информация об использовании, например, количество транзаций, происходящих в течение определенного периода (минута, час, и т.д.) и величина транзакций (размер сообщения электронной почты, размер передаваемых файлов, и т.п.). Такая информация может быть полезной, например десятикратное увеличение почтового трафика от определенного пользователя, может сигнализировать о заражении его системы вредоносным ПО или о нарушении политики допустимого использования системы.
• Значительные операционные события, такие как запуск и закрытие приложения, сбои приложений, и серьезные изменений конфигурации, могут быть использованы для идентификации нарушений безопасности и отказов обслуживания.

На рисунке ниже, представлен пример журнала событий веб-сервера.

2.3. Проблемы в управления журналами событий.

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

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

 

2.3.1. Генерация и хранение журналов.

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

• Большое количество источников журналов. При этом каждый источник может также регистрировать большое количество различных типов событий.
• Противоречивое содержание журналов. Каждый источник записывает определенную информацию в свои журналы (например, адрес хоста и имя пользователя). Для эффективности, источники журналов часто записывать только те части информации, которые они считают наиболее важными. Это может затруднить задачу связи (корреляции) событий, записанных различными источниками журналов (например, источник 1 записывает IP-адрес хоста, но не имя пользователя, и источник 2 записывает имя пользователя, но не IP-адрес хоста). Каждый тип источника журнала также может представлять значения отличающемся от других формате; эти различия могут быть небольшими (например, одна дата, в формате ММДДГГГГ а другая в формате ДД-ММ-ГГГГ), или более сложными (например, использование протокола передачи файлов (FTP) в одном журнале выявляются по имени («FTP») а в другом журнале по номеру порта (21)). Все это еще больше усложняет процесс связывания событий, записанных различными источниками журнала.
• Непоследовательные метки времени. Каждый хост, который создает журналы, обычно ссылается свои внутренние часы при установке метки для каждой записи журнала. Если на хосте установлено не точное время, временные метки в журналах также будут неточными. Это может усложнить анализ журналов, особенно когда анализируются журналы из нескольких источников. Например, временные метки могут показывать, что событие А произошло за 45 секунд до события В, когда на самом деле событие А произошло на две минуты позже события B.
• Противоречивый формат журналов. Многие из типов источников журнала используют различные форматы для своих журналов, таких как, разделенные запятыми или др символами текстовые файлы, бинарные файлы, syslog, Simple Network Management Protocol (SNMP), Extensible Markup Language (XML). Некоторые форматы журналов предназначены для чтения человеком, в то время как другие должны проходить предварительную обработку. Некоторые журналы используют стандартные форматы, в то время как другие используют собственные форматы. Некоторые журналы создаются для передачи в другие системы, а не для локального хранения в файле. Некоторые форматы, в частности, текстовые файлы, отличаются последовательностью значений в каждой записи журнала и разделителями между значениями (например, значения, разделенных запятыми, пробелами, XML).

 

2.3.2. Обеспечение безопасности журналов.

• В связи с тем, что журналы содержат записи систем безопасности, они должны быть защищены от нарушения их конфиденциальности и целостности. Например, в журналах может намеренно или случайно регистрироваться конфиденциальная информация, такая как, пароли пользователей и содержание электронной почты. Журналы, также могут быть подвержены преднамеренному и непреднамеренному изменению и уничтожению. Это может привести к тому, что вредоносная деятельность останется незамеченной и недоказуемой. Например, многие руткиты изменяют журналы для удаления каких-либо доказательств своей установки или функционирования.
• Организации также должны защитить доступность своих журналов. Многие журналы имеют пороговые значения для их хранения (например, хранение 10000 последних событий, или хранение 100 мегабайт данных журнала). При достижении предельного размера, журнал может переписать старые данные — новыми, или прекратить регистрацию событий. Для удовлетворения требований к хранению данных, организации может потребоваться хранить копии файлов журналов в течение более длительного периода времени, чем поддерживают источники журналов, что требует внедрение процесса архивирования журналов. Ввиду большого объема, было бы целесообразно в некоторых случаях, отфильтровывать записи журнала, которые не должны быть попадать в архив, для уменьшения объема. Конфиденциальность и целостность архивных журналов также должны быть обеспечены.

 

2.3.3. Анализ журналов.

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

 

2.3. Решение проблем управления журналами.

Несмотря на многие проблемы, с которыми сталкиваются организации, есть несколько ключевых практик, следование которым поможет решить рассмотренные выше проблемы, и даже предотвратить их появление:

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

 

3. Инфраструктура управления журналами.

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

• Системы централизованного сбора и хранения журналов, основанные на протоколе syslog.
• Системы управления событиями информационной безопасности.

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

 

3.1. Архитектура.

Инфраструктура управления журналами обычно включает в себя следующие три уровня:

• Генерация журналов. К первому уровню относятся хосты, оборудование (источники журналов), которые генерируют данные. Некоторые хосты хранят журналы локально, другие передают их (или их копии) для последующего хранения и обработки на сервер, который относится ко второму уровню архитектуры.
• Анализ журналов и их хранение. Ко второму уровню относятся один или несколько серверов, которые получают журналы или копии данных с первого уровня архитектуры. Данные передаются на серверы в реальном (или близком к реальному) масштабе времени, либо на основании графика передачи журналов, либо, случайным образом. Серверы, которые получают данные журналов из нескольких источников, иногда называют коллекторами или агрегаторами. Данные журналов могут затем храниться как на самих серверах, так и на отдельных серверах баз данных.
• Мониторинг журналов. К третьему уровню относятся различные консоли, которые могут использоваться как для ручного, так и автоматического контроля и анализа данных журналов. Консоли мониторинга также можно использовать для создания отчетов. В некоторых случаях, консоли также могут быть использованы для управления серверами и клиентами инфраструктуры.

 

3.2. Функции.

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

Общие:

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

Хранение:

• Ротация журналов – закрытие одного и открытие нового файла журналов, когда первый файл считается полным. Ротация обычно выполняется в соответствии с графиком (например, ежечасно, ежедневно, еженедельно), или когда файл журнала достигает определенного размера. Основные преимущества ротации журналов — сохранение записей журналов, сохраняя при этом управляемым размер файлов журнала.
• Архивирование журналов — сохранение журналов в течение длительного периода времени, как правило, на съемных носителях, в сети хранения данных (SAN), или специализированном устройстве или сервере. Журналы часто нуждаются в хранении для удовлетворения юридических или нормативных требований. Есть два типа хранения журналов: сохранение и консервация. Сохранение (Log retention) — выполняет архивирование журналов на регулярной основе в рамках стандартных операционных мероприятий. Консервация (Log preservation) — архивация журналов, содержащих интересующие организацию записи, которые в обычных условиях отбрасываются системой фильтрации. Консервация обычно выполняется в интересах проведения дальнейших расследований инцидентов.
• Сжатие журналов — хранение файлов журналов таким образом, чтобы уменьшить место, необходимое для хранения файла, не изменяя смысл содержания журнала. Сжатие часто выполняется, при ротации и архивировании журналов.
• Сокращение журналов — удаляет ненужные записи из журнала, чтобы создать новый журнал меньшего объема. Сокращение часто выполняются в сочетании с архивированием, чтобы на длительное хранение помещались только записи журналов, представляющие интерес для организации.
• Преобразование журналов – обработка журнала в одном формате и хранение в другом. Например, преобразование может импортировать данные из журнала в базе данных и сохранять его в XML-формате в текстовом файле. Многие генераторы журнала могут конвертировать свои собственные журналы в другой формат. Доступны также сторонние утилиты для преобразования.
• Нормализация журналов, каждое поле данных журнала преобразуется в частный формат представления. Наиболее распространенный пример нормализации — хранение дат и времени в едином формате. Нормализация может быть очень ресурсоемкой, особенно для сложных записей журнала (например, журналы систем обнаружения вторжений).
• Проверка целостности журналов – вычисление контрольной суммы каждого файла журналов и надежное хранение значений контрольных сумм сообщения, чтобы  гарантировать, что изменения архивных журналов будут обнаружены.

Анализ:

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

Утилизация:

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

 

3.3. Системы централизованного сбора и хранения журналов, основанные на протоколе syslog.

В инфраструктурах на основе протокола syslog, каждый генератор журнала использует одинаковый формат для своих журналов и базовой механизм передачи своих записей журнала на сервер, запущенный на другом хосте. Syslog предоставляет основу для генерации, хранения и передачи записей журналов, которые могут использоваться различными ОС, СЗИ, или приложениями, поддерживающими данный формат. Подробнее о протоколе Syslog можно почитать здесь: http://ru.wikipedia.org/wiki/Syslog.

 

3.3.1. Формат Syslog.

Syslog назначает приоритет каждому сообщению на основе важности следующих двух атрибутов:

• Тип сообщения, известный как facility. Примеры включают сообщения ядра, сообщения системы электронной почты, сообщения авторизации, сообщения принтера и сообщения аудита.
• Серьезность. Каждому сообщению журнала присваивается уровень серьезности, от 0 (чрезвычайный) до 7 (отладка).

Пример сообщения Syslog представлен на рисунке ниже:

3.3.2. Безопасность Syslog.

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

В настоящее время в протоколе syslog уделяется больше внимания безопасности журналов. Реализация протокола на основе RFC 3195 может поддерживать конфиденциальность, целостность и доступность журналов.

 

3.4. Системы управления событиями информационной безопасности (SIEM -системы).

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

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

 

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

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

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

 

3.5. Дополнительные типы ПО управления журналами событий.

Другие типы программного обеспечения, которые также могут быть полезны в управлении журналами:

• Системы обнаружения вторжений уровня хоста (Нost-based IDS). Хост-IDS контролирует (в поисках подозрительной активности) характеристики и события в пределах одного хоста. Многие IDS уровня хоста могут контролировать журналы ОС и приложений, для обеспечения безопасности.
• Инструменты визуализации. Инструмент визуализации представляет данные о событиях безопасности в графическом формате. Например, инструмент может отображать данные, сгруппированные или упорядоченные по значениям различных характеристик событий (например, таких как адрес источника). Многие SIEM решения имеют встроенные средства визуализации.
• Утилиты для ротации журналов. Администраторы могут использовать специализированные утилиты сторонних производителей для ротации журналов. Это может быть полезно для улучшения управления журналами при отсутствии встроенных возможностей ротации журналов.
• Утилиты тля преобразования журналов. Многие производители программного обеспечения предлагают утилиты, которые можно использовать, чтобы преобразовать журналы в стандартные форматы. Эти утилиты являются полезными, например, когда SIEM решение не поддерживает определенный формат журнала.

 

4. Планирование управления журналами.

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

 

4.1. Определение ролей и сфер ответственности.

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

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

 

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

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

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

 

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

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

 

4.2. Определение и внедрение политик журналирования.

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

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

Генерация журналов:

• Какие типы хостов должны или могут выполнить регистрацию.
• Какие компоненты хоста должны или могут выполнять регистрацию (например, ОС, службы, приложение).
• Какие типы событий каждый компонент должен или может регистрировать (например, события безопасности, сетевые соединения, попытки аутентификации).
• Какие характеристики данных должны или могут регистрироваться для каждого типа события (например, имя пользователя и IP-адрес источника для попыток аутентификации).
• Как часто каждый тип события должен или может регистрироваться (например, каждое событие, один раз для всех экземпляров в течение N-минут, каждый раз после N событий).

Передача журналов:

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

Хранение и удаление журналов:

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

Анализ журналов:

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

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

4.3. Убедитесь в выполнимости политик.

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

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

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

 

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

 

Организации при разработке политики необходимо также рассмотреть среду в которой функционируют системы,. NIST SP 800-70, Security Configuration Checklists Program for IT Products—Guidance for Checklists Users and Developers, определяетнесколькообщихтиповсредыфункционирования. Ниже приведено описание этих сред с пояснениями, как характеристики каждой среды могут повлиять на политики протоколирования. Организации могут рассмотреть отдельные положения политик управления журналами для систем в каждой среде.

• Малый офис / домашний офис (SmallOffice/HomeOffice, SOHO) охватывает небольшие инсталляции, которые используются для дома или в коммерческих целях. SOHO охватывает разнообразные мелкие среды и устройства, такие как, ноутбуки, мобильные устройства или домашние компьютеры, системы дистанционной работы, для малого бизнеса и небольших филиалов компании. Многие SOHO имеют соединения с низкой пропускной способностью с первичной сетью организации, которые могут существенно повлиять на интеграцию с инфраструктурой управления журналами. Необходимо разрабатывать инфраструктуру управления журналами таким образом, чтобы свести к минимуму передачу данных от систем SOHO к инфраструктуре.
• Корпоративные (Enterprise) среды обычно состоят из большого количества организационных систем с определенными аппаратными и программными конфигурациями, как правило, состоящие из центрально-управляемых рабочих станций и серверов, защищенных от Интернета с помощью межсетевых экранов и других устройств сетевой безопасности. Из всех сред, корпоративная среда предприятия, как правило, самая простая, для организации управления журналами.
• Нестандартные (Custom) среды содержат системы, в которые не вписываются (например, из-за ограничений функциональности) в другие среды. В стандарте приводится два типа таких сред:

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

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

 

4.4. Разработка инфраструктуры управления журналами.

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

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

• Типичный и пиковый объем данных отчетов, которые будут обработаны в течение часа/дня. Для большинства источников журнала, типичный объем данных журнала имеет тенденцию увеличиваться. Пиковый объем должен определяться с учетом обработки экстремальных ситуаций, таких как случаи масштабного распространения вредоносных программ, сканирования уязвимостей и тестирования на проникновение, приводящих к возникновению большого количества записей в журнале, которые будут созданы в течение короткого периода времени. Такое увеличение объема данных может привести к отказу в обслуживании.
• Типичное и пиковое использование пропускной способности сети.
• Типичное и пиковое использование ресурсов хранения данных (например, архивирование) — должно включать в себя анализ времени и ресурсов, необходимых для выполнения резервного копирования (и архивирования) данных журнала, а также утилизации данных, как только они больше не нужны.
• Потребности безопасности для данных журнала. Например, если необходимо шифровать данные журнала при передаче между системами, может потребоваться задействовать больше системных ресурсов, а также пропускной способности сети.
• Время и ресурсы, необходимые сотрудникам для анализа журналов.

 

5. Операционные аспекты управления журналами.

Администраторы ИТ — инфраструктуры должны следовать стандартным процессам управления журналами, за выполнение которых они несут ответственность. В этом разделе описываются основные операционные виды деятельности процесса управления журналами:

• Настройка источников журналов, в том числе создание, хранение и обеспечение безопасности журналов.
• Анализ данных журналов.
• Инициация соответствующих ответов на определенные события.
• Управление долгосрочным хранением данных журналов.

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

 

5.1. Настройка источников журналов:

5.1.1. Генерация журналов.

5.1.2. Хранение и удаление журналов.

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

• Отсутствие необходимости хранения.
• Хранение только на локальном уровне (уровне хоста).
• Хранение только на уровне инфраструктуры управления журналами.
• Хранение, как на уровне хоста, так и на уровне инфраструктуры.

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

• Остановить регистрацию событий.
• Перезаписать старые данные журналов.
• Остановить генерацию журналов.

5.1.3. Безопасность журналов.

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

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

 

5.2. Анализ данных журналов:

5.2.1. Понимание информации содержащейся в журналах.

Ключ к проведению анализа журналов — понимание типичной активности каждой системы. Хотя некоторые записи в журнале очень легко понять, многие из них не являются таковыми. Основные причины этого следующие:

• Необходимость учета контекста.
• Неясность сообщений.

5.2.2. Приоритезация данных журналов.

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

• Тип записи (например, код сообщения 103, класс сообщения критический).
• Новизна (то есть, появлялся ли такой тип данных в журналах раньше?).
• Источник журнала.
• IP-адрес источника или назначения (например, адрес источника из черного списка, адрес назначения — критическая система)/
• Время суток или день недели (например, запись может быть приемлемой или неприемлемой в определенное время)
• Частота событий (например, N раз за Mсекунд).

5.2.3. Сравнительный анализ на уровне хоста/системы.

 

5.3. Реагирование на идентифицированные события.

5.4. Управление долгосрочным хранением данных журналов.

• Выберите формат журналов для проведения архивирования.
• Архивируйте данные журналов.
• Проверяйте целостность передаваемых журналов.
• Обеспечивайте безопасность мест/средств хранения журналов.

 

5.5. Обеспечение дополнительной операционной поддержки.

Необходимо регулярно выполнять следующие виды работ:

• Мониторинг состояния систем журналирования всех источников, чтобы гарантировать, что каждый источник включен, настроен должным образом, и работает, как ожидается.
• Мониторинг процессов ротации и архивирования журналов, чтобы убедиться, что журналы архивируются, и старые журналы будут уничтожены, как только они больше не нужны. Мониторинг ротации журналов должен также включать регулярные проверки наличия свободного пространства доступного для записи и хранения журналов.
• Проверка обновлений и патчей ПО управления журналами: приобретение, тестирования и развертывания обновлений.
• Проверка того, что часы каждой системы синхронизируется с источником общего времени.
• Перенастройка компонентов инфраструктуры управления журналами по мере необходимости на основе таких факторов, как: изменения в политике, результаты аудита, изменения в технологиях и удовлетворение новых потребностей в области безопасности.
• Документирование аномалий, обнаруженных в настройках журналов, конфигураций компонентов инфраструктуры управления журналами и процессах. Такие аномалии могут указывать вредоносную активность, отклонения от политики и процедур, а также недостатки в механизмах регистрации событий. Администраторы систем должны сообщать о таких аномалиях администраторам инфраструктуры управления журналами.

 

5.6. Выполнение тестирования и валидации.

Наиболее распространенные методы проверки и валидации системы управления журналами:

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

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

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

itsec.by

Практика ИБ \ Аудит событий безопасности

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

1. Определите, какие источники журналов и какие автоматизированные средства вы можете использовать в процессе анализа
2. Организуйте копирование всех записей журналов в одно место, где вы сможете их анализировать
3. Минимизируйте "шум", исключив из анализа обычные, повторяющиеся записи (предварительно убедившись, что они не представляют угрозы)
4. Убедитесь, что вы можете положиться на отметки о времени событий в журналах, примите во внимание возможные различия во временных зонах
5. Сосредоточьтесь на необычных для вашей среды событиях - последних изменениях, ошибках, изменениях состояния, событиях доступа, выполнении административных функций и т.п.
6. Возвращайтесь назад во времени для реконструкции действий до и после произошедшего инцидента
7. Совмещайте (коррелируйте) действия, зафиксированные в различных журналах, для получения полной картины произошедшего
8. Создайте для себя предположение о произошедшем, а затем исследуйте журналы, чтобы подтвердить или опровергнуть это предположение

Потенциальные источники журналов событий безопасности

• Журналы регистрации событий операционных систем серверов и рабочих станций
• Журналы регистрации событий приложений (например, веб-серверов, серверов баз данных)
• Журналы регистрации событий средств безопасности (например, антивирусных программ, средств контроля изменений, систем выявления/предотвращения вторжений)
• Журналы регистрации событий внешнего прокси-сервера
• Журналы регистрации событий приложений конечного пользователя
• Не забудьте принять во внимание иные (не журнальные) источники событий безопасности

Типичное размещение журналов регистрации событий

• ОС Linux и основные приложения: /var/logs
• ОС Windows и основные приложения: Журнал регистрации событий Windows (Безопасность, Система, Приложение)
• Сетевые устройства: обычно журналируются посредством Syslog; некоторые используют собственные местоположения и форматы

Что отслеживать в Linux

• Успешный вход пользователя
• “Accepted password” (пароль принят)
• “Accepted publickey” (открытый ключ принят)
• "session opened” (открыт сеанс)
• Неудачный вход пользователя
• “authentication failure” (неудачная аутентификация)
• “failed password” (неверный пароль)
• Выход пользователя
• “session closed” (сеанс закрыт)
• Изменение или удаление пользовательской учетной записи
• “password changed” (изменен пароль)
• “new user” (создан новый пользователь)
• “delete user” (удален пользователь)
• Использование sudo
• “sudo: … COMMAND=…”(использование sudo)
• “FAILED su” (неудачная попытка использования su)
• Сбои сервисов
• “failed” или “failure”

Что отслеживать в Windows

• Указанные ниже идентификаторы событий соответствуют Windows 2000/XP/2003. Для Vista/7 нужно добавлять к приведенному здесь номеру 4096 для получения правильного идентификатора события
• Большинство приведенных ниже событий записывается в журнал "Безопасность"; многие из событий журналируются только на контроллере домена
• События входа/выхода пользователей
• Успешный вход - 528, 540; неудачный вход - 529-537, 539; выход - 538, 551 и т.д.
• Изменения пользовательских учетных записей
• Создание - 624; разблокирование - 626; изменение - 642; блокирование - 629; удаление - 630
• Изменения пароля
• Для своей учетной записи - 628; для другой учетной записи - 627
• Запуск и остановка сервисов
• Отказ в доступе к объекту (если включен соответствующий аудит)

Что отслеживать на сетевых устройствах

• Контролировать следует как внутреннюю, так и внешнюю активность
• Приведенные ниже примеры относятся к журналам Cisco ASA, однако для других устройств все аналогично
• Разрешенный на межсетевом экраноме трафик
• “Built … connection” (установлено соединение)
• “access-list … permitted” (разрешен сетевой пакет в соответствии с ACL при включенной для правила опции LOG)
• Заблокированный на межсетевом экране трафик
• “access-list … denied” (блокирован сетевой пакет в соответствии с ACL при включенной для правила опции LOG)
• “deny inbound” (блокировано входящее соединение)
• “Deny … by” (блокирован сетевой пакет в соответствии с ACL; журналируется даже при выключенной опции LOG)
• Объемы переданных данных (для выявления передачи больших объемов данных)
• “Teardown TCP connection … duration … bytes …” (завершено ТСР-соединение, длительность, передано байт)
• Использование полосы пропускания и ресурсов
• “limit … exceeded” (превышен лимит)
• “CPU utilization” (использование процессора)
• Выявленные атаки
• “attack from” (атака от)
• Изменения пользовательских учетных записей
• “user added” (пользователь добавлен)
• “user deleted” (пользователь удален)
• “User priv level changed” (изменены привилегии пользователя)
• Административный доступ
• “AAA user …” (доступ пользователя)
• “User … locked out” (пользователь заблокирован)
• “login failed” (неудачная попытка входа)

Что отслеживать на веб-серверах

• Большое число попыток доступа к несуществующим файлам
• Что-то похожее на код (SQL, HTML) в URL-запросах
• Попытки доступа к отсутствующим у вас расширениям
• Сообщения об остановке/запуске/сбое веб-сервиса
• Доступ к рискованным страницам, которые принимают пользовательский ввод
• Просмотр журналов регистрации событий на всех серверах пула
• Код ошибки 200 на отсутствующих у вас файлах
• Неудачная аутентификация пользователя
• Коды ошибки 401, 403
• Неверный запрос
• Внутренняя ошибка сервера

Ссылки на дополнительные ресурсы:

dorlov.blogspot.ru

НОУ ИНТУИТ | Лекция | Аудит и журналы безопасности

Аннотация: После укрепления системы и настройки безопасности веб-сайта Microsoft IIS необходимо отслеживать попытки нарушения защиты сайта и определять признаки атак или вторжений на сервер.

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

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

Отслеживание событий сайта

События, происходящие на веб-сервере Windows 2000/IIS, отслеживаются при помощи просмотра и анализа журнала, в который отправляются сообщения от других служб, приложений или операционной системы. Эти сообщения учитывают события, происходящие в системе: выключение, запуск, создание новой учетной записи и т.д. IIS дополнительно отслеживает события собственного набора служб, например, запросы от посетителей сайта, отправленные на сервер для осуществления анонимного входа.

В Windows 2000 имеются журналы шести различных типов. Если вы имеете опыт системного администрирования Windows 2000, то уже знакомы с некоторыми из них. IIS ведет свой собственный отдельный журнал. Ниже приведен полный перечень журналов, работающих на сервере.

• Системный журнал. Фиксирует события компонентов: остановку и запуск службы или возникновение ошибки.
• Журнал безопасности. Записывает события, связанные с безопасностью: вход пользователей и использование ресурсов, например, создание, открытие и удаление файлов.
• Журналы приложений. Фиксируют события, связанные с приложениями, выполняемыми на сервере.
• Журнал службы каталогов. Фиксирует информацию о работе службы Active Directory, например, проблемы с подключением к глобальному каталогу.
• Журнал сервера DNS. Записывает события, связанные с работой службы Windows 2000 DNS в Active Directory.
• Журнал службы репликации файлов. Фиксирует значимые события, происходящие при попытке контроллера домена обновить другие контроллеры домена.
• Журнал IIS. Фиксирует события, происходящие при работе служб IIS (WWW, FTP и т.д.).

Для веб-сервера IIS не требуется работа всех без исключения журналов, например, не нужны журналы сервера DNS и службы репликации файлов. Журнал службы каталогов включается, если сервер является частью домена Windows Active Directory, причем ведется он на другом сервере. Веб-сервер работает с системным журналом, журналом приложений, журналом безопасности и журналом IIS.

Системный журнал Windows 2000 и журнал приложений активируются по умолчанию при установке IIS для автоматического фиксирования системных событий и событий приложений. Остальные журналы запускаются только после их непосредственной настройки и/или запуска. При выполнении IIS Lockdown автоматически активируется журнал безопасности Windows 2000 и IIS.

Информация журналов событий

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

Системный журнал Windows 2000 по умолчанию хранится в специальном формате в файлах с расширением .evt. Программа Event Viewer (Просмотр событий) Windows 2000, доступная в консоли MMC в папке Administration Tools (Администрирование), позволяет просматривать сообщения в журналах Windows 2000 и упорядочивать их по дате, времени, источнику, степени значимости и по другим переменным. Event Viewer используется также для преобразования файлов журнала в текстовый формат для просмотра в другой программе. На рисунке показана консоль программы Event Viewer.

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

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

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

На рисунке 5.1 приведен пример сообщения об ошибке в системном журнале Windows 2000, зафиксировавшего неожиданное отключение сервера. Это событие выходит за рамки нормальной работы и его необходимо исследовать. По идентификационному номеру ID события его можно найти в базе данных Microsoft Knowledge Base, если не понятно, что оно означает.

Рис. 5.1. Сообщение системного журнала Windows 2000, информирующее о неожиданном отключении

Аудит

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

Windows 2000 предоставляет три типа возможностей по аудиту объектов и ресурсов, свои функции имеются и в IIS (см. табл. 5.1).

Таблица 5.1. Типы аудита в Windows 2000 и IIS Тип аудита Системы, в которых применяется аудит

Система и реестр	Windows 2000 и IIS.
Файловая система	Windows 2000 и IIS.
Учетная запись пользователя	Windows 2000 и IIS.
Посетители домашней страницы	Только IIS.
Авторство	Только IIS.

При аудите отслеживаются события согласно правилам аудита, определенным в локальной политике безопасности сервера и/или параметрах веб-сайта. Осуществляется аудит событий, входящих в следующие девять категорий.

• События системы. События, связанные с безопасностью, такие как отключение системы и ее перезапуск; события, влияющие на журнал безопасности.
• Отслеживание процесса. Детализированное отслеживание вызова процесса, дубликатов процессов, непрямого доступа к объектам и уничтожения процесса.
• Изменение политики. Изменение политики безопасности, включая присвоение привилегий, модификацию политики аудита и параметров доверия.
• Использование привилегий. Использование привилегий, присвоение специальных привилегий.
• Управление учетной записью. Создание, изменение, удаление пользователей и групп; изменение паролей.
• Доступ к службе каталогов. Отслеживание доступа к Active Directory. Включается для разрешения аудита определенных объектов каталога, работает только на контроллерах домена.
• События входа в учетную запись. Аутентификация на локальном компьютере в консоли или через сеть.
• События входа. Интерактивный вход или сетевые подключения к локальному компьютеру; генерируются в том месте, где происходит вход.
• Доступ к объектам. Попытки доступа к определенным объектам: файлам, каталогам, учетным записям пользователей и параметрам реестра.

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

www.intuit.ru

Локальная политика безопасности. Часть 5: Журнал событий

 

Введение

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

Политики журналов событий

Задать настройки журналов событий вы можете при помощи четырех политик безопасности, предназначенных для трех основных журналов – журнала безопасности, журнала приложений, а также системного журнала. Ниже вы узнаете обо всех локальных политиках безопасности, используя которые вы можете управлять журналами событий ваших пользователей. Для того чтобы перейти к настройке политик журналов событий, в редакторе управления групповыми политиками откройте узел Конфигурация компьютера/Конфигурация Windows/Параметры безопасности/Локальные политики/Журнал событий. Политики журналов событий вы можете увидеть на следующей иллюстрации:

Рис. 1. Узел «Журнал событий»

Рассмотрим подробно каждую политику данного узла:

Запретить доступ для локальной группы гостей к журналу безопасности. Данная политика безопасности может быть применена только к операционным системам, которые предшествуют Windows Vista. Применяется данная политика с целью ограничения локальной группы гостей, использующих анонимный вход в систему для журнала безопасности в операционных системах Windows XP и Windows 2000. По умолчанию, для клиентов, использующих операционную систему Windows 2000, данная политика отключена, а для пользователей Windows XP – включена.

Запретить доступ для локальной группы гостей к журналу приложений. Действия этой политики безопасности аналогичны политике «Запретить доступ для локальной группы гостей к журналу безопасности». Эта политика отличается от предыдущей только тем, что используя параметры текущей политики, вы можете ограничить гостевых пользователей в доступе к журналу «Приложения». По умолчанию, для клиентов, использующих операционную систему Windows 2000, данная политика отключена, а для пользователей Windows XP – включена.

Запретить доступ для локальной группы гостей к системному журналу. Текущая политика безопасности также как и две предыдущих политики, позволяет пользователям операционных систем Windows XP и Windows 2000 запрещать локальным гостям с анонимным входом в систему иметь доступ к журналу «Система». По умолчанию, для клиентов, использующих операционную систему Windows 2000, данная политика отключена, а для пользователей Windows XP – включена.

Максимальный размер журнала безопасности. В одной из статей посвященных управлению журналами событий я рассказывал о том, как вы можете изменить максимальный размер различных журналов при помощи графического интерфейса или командной строки. Если вам нужно указать максимальный размер определенного журнала для целой группы пользователей, то вы можете упростить себе эту задачу и воспользоваться текущей политикой безопасности. Эта политика безопасности позволяет указывать максимальный размер журнала «Безопасность». Максимальный размер журнала может достигать 4 Гб, но обычно указывают максимальный размер не более 500 Мб. Ограничение размера журнала безопасности может привести к затиранию важных событий, так как по достижению порогового объема, у вас будут удаляться самые старые события, и вместо них будут записываться новые. Размеры файлов журнала должны быть кратны 64 КБ. Если введено значение, не кратное 64 КБ, средство просмотра событий установит размер файла журнала, кратный 64 КБ. Обычно, есть смысл увеличивать размер журнала событий только в том случае, если есть необходимость в тщательной обработке событий безопасности и сохранении журнала на протяжении длительного периода времени. По умолчанию в операционной системе Windows 7 и Windows Vista размер журнала безопасности составляет 20 Мб, в Windows Server 2008 и Windows Server 2008 R2 – 128 Мб, для операционных систем Windows Server 2003 – 16 Мб, а Windows XP – 8 Мб.

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

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

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

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

Метод сохранения событий в системном журнале. Эта политика безопасности предназначена для настройки сохранения событий в журнале «Система».

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

Сохранять события в журнале приложений. Эта политика безопасности предназначена для определения количества дней, на протяжении которых в журнале «Приложения» будут сохраняться события.

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

Примеры использования политик журналов событий

Разберемся с настройками политик безопасности журналов событий на живом примере. В этом примере мы определим настройки журналов событий «Приложения», «Безопасность» и «Система» для группы «Бухгалтерия» организации. Предположим, что в вашем отделе бухгалтерии все компьютеры оснащены операционными системами Windows Vista и Windows 7, в связи с чем, параметры политики «Запретить доступ для локальной группы гостей к журналу …» не будут задействованы. Выполните следующие действия:

1. На контроллере домена создайте группу безопасности «Бухгалтерия» и поместите ее в подразделение «Группы»;
2. Откройте консоль «Управление групповой политикой», где выберите контейнер «Объекты групповой политики» и нажмите на этом контейнере правой кнопкой мыши для отображения контекстного меню;
3. В контекстном меню выберите команду «Создать» и в отобразившемся диалоговом окне «Новый объект групповой политики» введите «Политики журналов событий для отдела бухгалтерии», после чего нажмите кнопку «ОК»;
4. Выберите данный объект групповой политики и из контекстного меню выберите команду «Изменить», как показано на следующей иллюстрации: 

   Рис. 2. Изменение «Политики журналов событий для отдела бухгалтерии»

5. В появившемся окне «Редактор управления групповыми политиками» разверните узел Конфигурация компьютера/Политика/Конфигурация Windows/Параметры безопасности/Журнал событий и выберите политику «Максимальный размер журнала безопасности»;
6. В диалоговом окне «Свойства: Максимальный размер журнала безопасности» установите флажок «Определить следующий параметр политики» и в соответствующем текстовом поле установите значение в 30 МБ, что равняется 30720 КБ, как показано ниже: 

   Рис. 3. Настройка максимального размера журнала безопасности

7. Предположим, что в отделе безопасности установлены надежные пароли, назначены все необходимые права для пользователей этой группы и у вас нет необходимости в аудите журналов безопасности этого отдела. Откройте свойства политики «Метод сохранения событий в журнале безопасности». В диалоговом окне свойств политики установите флажок «Определить следующий параметр политики» и выберите значение «Затирать старые события по необходимости». Теперь, по достижении 30 Мб самые старые события в журналах безопасности отдела бухгалтерии будут перезаписываться новыми; 

   Рис. 4. Настройка метода сохранения событий в журнале безопасности

8. Для журналов приложений группы бухгалтерии регистрируется не очень много событий, поэтому в настройках политики «Максимальный размер журнала приложений» укажем значение 25600 КБ, что равняется 25 МБ;
9. Вы не хотите, чтобы журнал «Приложения» для отдела бухгалтерии вашей организации перезаписывался, но не ведете его архивацию. Допустим, вы периодически его просматриваете и очищаете вручную. Для этого в политике «Метод сохранения событий в журнале приложений» установите значение «Не затирать события (чистка журнала вручную)». Но вам необходимо учесть, что если вы не будете самостоятельно чистить данный журнал, то, в конечном счете, новые события не будут фиксироваться в журналах приложений отдела бухгалтерии;
10. Последний журнал, который вам предстоит настроить – это журнал «Система». В политике «Максимальный размер системного журнала» установите размер 20 МБ, что является 20480 КБ;
11. По требованиям безопасности вашей организации вам необходимо создавать архивные копии системных журналов для всех групп безопасности. Поэтому в политике «Метод сохранения событий в системном журнале» выберите значение «Затирать старые события по дням». По нажатию на кнопку «ОК» перед вами будет отображен диалог «Предлагаемые изменения значений», в котором указывается, что для политики «Сохранять события в системном журнале» будет установлено значение 7 дней. Это значение как раз соответствует требованиям по архивации системного значения и по нажатию закрытия данного диалога не будет необходимости в редактировании этой политики безопасности; 

    Рис. 5. Предлагаемые изменения значений политики «Сохранять события в системном журнале»

12. По окончанию настроек политик журналов событий, содержимое оснастки «Редактор управления групповыми политиками» будет выглядеть следующим образом: 

    Рис. 6. Настроенные политики журналов событий

    Закройте данную оснастку.

13. После закрытия оснастки «Редактор управления групповыми политиками» вам нужно привязать отредактированный объект групповой политики к группе безопасности «Бухгалтерия». Для этого в оснастке «Управление групповой политикой» выберите контейнер «Группы», нажмите на нем правой кнопкой мыши и из контекстного меню выберите команду «Связать существующий объект групповой политики…». В диалоговом окне «Выбор объекта групповой политики» выберите объект «Политики журналов событий для отдела бухгалтерии» и нажмите на кнопку «ОК»; 

    Рис. 7. Выбор привязываемого объекта групповой политики

14. Разверните подразделение «Группы», выберите объект «Политики журналов событий для отдела бухгалтерии» и на вкладке «Область», и в области «Фильтры безопасности» удалите фильтр «Прошедшие проверку». После этого нажмите на кнопку «Добавить» и выберите группу «Бухгалтерия», которая заранее была создана;
15. Перейдите на клиентские машины и обновите групповые политики, используя команду Gpupdate;

Заключение

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

dimanb.wordpress.com

5.1.4. Журнал событий безопасности

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

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

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

Таблица 5.2

Категории событий для ревизии.

Категория	События
Начало и конец сеанса Доступ к файлам и объектам	Попытки начала сеанса, попытки конца сеанса; создание и завершение сетевых соединений к серверу Доступы к каталогу или файлу, которые устанавливаются для ревизии в диспетчере файлов; использование принтера, управление компьютером
Использование прав пользователя Управление пользователями и группами Изменения полиса безопасности Перезапуск, выключение и система Трассировка процесса	Успешное использование прав пользователя и неудачные попытки использовать права, не назначенные пользователям Создание, удаление и модификация учетных карточек пользователя и групп Предоставление или отменена прав пользователя пользователям и группам, установка и разрыв связи доверия с другими доменами Остановка и перезапуск компьютера, заполнение контрольного журнала и отвержение данных проверки если контрольный журнал уже полон Начало и остановка процессов в компьютере

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

Таблица 5.3

Типы доступа к каталогам и файлам.

Доступ к каталогу	Доступ к файлу
	Отображение имен файлов в каталоге Отображение атрибутов каталога Изменение атрибутов каталога	Отображение данных, хранимых в файле Отображение атрибутов файла Отображение владельца файла и разрешений
	Создание подкаталогов и файлов Переход в подкаталогах каталога Отображение владельца каталога и разрешений Удаление каталога Изменение разрешений каталога Изменение владельца каталога	Изменение файла Изменение атрибутов файла Запуск файла Удаление файла Изменение файловых разрешений Изменение владельца файла

5.1.5. Права пользователя

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

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

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

studfiles.net

---

Смотрите также

• 
  Военное образование журнал
• 
  Научный журнал поиск
• 
  Форма журнал 60
• 
  Создание электронного журнала
• 
  Журналы для общежития
• 
  История ссср журнал
• 
  Черно белые журналы
• 
  Гражданский процесс журнал
• 
  Журнал защити меня
• 
  Журналы мафия 3
• 
  Электронная техника журнал