Наблюдение за безопасностью и обнаружение атак

Опубликовано 16 января 2007 г.

На этой странице

Введение

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

Аннотация

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

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

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

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

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

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

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

Обзор

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

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

Трудности для среднего бизнеса

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

Решения

В этом разделе содержатся подробные сведения о разработке, внедрении, администрировании и проверке

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

Для кого предназначен этот документ

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

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

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

Определение

В этой статье в дополнение к функциям управления службами (service management functions, SMF) службы
администрирования безопасности и контроля над происшествиями MOF используется модель процессов
Microsoft Operations Framework (MOF).

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

Рис. 1. Применение MOF

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

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

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

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

Дополнительные сведения о MOF см. на веб-узле Microsoft Operations Framework по адресу

www.microsoft.com/mof (эта ссылка может указывать на содержимое полностью или частично на английском
языке). Дополнительные сведения о процессе управления безопасностью SMF доступны на веб-узле по
адресу www.microsoft.com/technet/itsolutions/cits/mo/smf/mofsmsmf.mspx (эта ссылка может указывать на
содержимое полностью или частично на английском языке).

Управление рисками — это процесс определения уровня риска, приемлемого для организации, оценки
текущих рисков, поиска способов достижения приемлемого уровня риска и устранения риска. Хотя в этой
статье описываются некоторые концепции управления рисками и некоторые действия, помогающие
осуществлять оценку рисков, подробное описание управления рисками является отдельным предметом
обсуждения и выходит за рамки этой статьи. Дополнительные сведения об анализе и оценке рисков см. в
статье «Руководство по управлению рисками, связанными с безопасностью» по адресу
http://go.microsoft.com/fwlink/?linkid=30794 (эта ссылка может указывать на содержимое полностью или
частично на английском языке).

Трудности для среднего бизнеса

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

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

Решения

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

• Определение и устранение уязвимостей компьютеров, не соответствующих политикам безопасности и

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

Разработка решения

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

Когда компании все-таки обращают внимание на проблемы безопасности и наблюдения за данными, они
обычно концентрируют усилия на защите периметра сети при помощи брандмауэров. Однако использование
такого подхода оставляет уязвимыми для атак другие места. Согласно исследованию компьютерных
преступлений за 2004 г., опубликованному Секретной службой США и координационным центром
организации CERT по адресу www.cert.org/archive/pdf/2004eCrimeWatchSummary.pdf (эта ссылка может
указывать на содержимое полностью или частично на английском языке), 29 процентов выявленных
злоумышленников действовали изнутри. Среди них были сотрудники компании, подрядчики и бывшие
сотрудники. С учетом этих сведений становится очевидна необходимость создания многоуровневого подхода
к безопасности для защиты от внутренних угроз, помимо внешних угроз, исходящих из-за пределов
организации.

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

Как уже было сказано, журналы безопасности часто используются в качестве меры реагирования в процессе
криминалистического анализа нарушения безопасности после того, как это нарушение произошло. Однако в
исследовании внутренних угроз за 2005 г., опубликованном Секретной службой США и CERT по адресу
www.cert.org/archive/pdf/insidercross051105.pdf (эта ссылка может указывать на содержимое полностью или
частично на английском языке), в процессе анализа выяснилось, что ведение журнала безопасности и
наблюдение можно использовать для упреждающего обнаружения, а не только для судебного реагирования.
Многие злоумышленники, как внутренние, так и внешние, также пытаются замести следы путем изменения
журналов; следовательно, необходимо предпринять действия для защиты системных журналов. Выясняется,
что журналы безопасности и другие методы, используемые для наблюдения и обнаружения атак, могут быть
крайне важным средством в защитном арсенале сети при условии правильного использования и защиты.

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

Реализация наблюдения за безопасностью

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

безопасностью.

Ведение журнала событий системы безопасности Windows

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

Рис. 2. Журнал безопасности средства просмотра событий

Увеличить изображение

В журнале событий безопасности (показанном на предыдущем рисунке) используется настраиваемый формат

файла для записи данных о наблюдении за безопасностью. Хотя имеется возможность чтения части этих
записей с помощью текстового редактора, для просмотра всех сведений, записанных в этих журналах,
необходимо использовать подходящую программу, например средство просмотра событий. Файл журнала
событий безопасности (SecEvent.evt) расположен в каталоге %systemroot%\System32\config. Доступ к
журналам событий всегда контролируется службой журнала событий, в которой реализованы средства
контроля доступа к каждому журналу.  Разрешения по умолчанию для журнала безопасности являются очень
строгими по сравнению с другими журналами в системе; доступ к журналу безопасности по умолчанию имеют
только администраторы.

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

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

Windows\Локальные политики», определяют, какие события могут создавать записи в журналах
безопасности. Параметры политики аудита можно настроить с помощью консоли параметров локальной
безопасности или на уровне сайта, домена или подразделения через групповую политику с помощью Active
Directory.

Интерпретация событий аудита

События аудита рассматриваются в этой статье намного подробнее, поэтому важно понимать структуру
события аудита и сведений, содержащихся в событиях аудита.
Рис. 3. Окно свойств событий

События состоят из трех основных частей: заголовок события, описание события и раздел двоичных данных.

Заголовки событий состоят из следующих полей:

Таблица 1. Заголовок события

Поле Определение

Дата Дата возникновения события

Время Локальное время возникновения события

Тип Классификация серьезности события или тип. События аудита безопасности могут иметь тип
«аудит успеха» или «аудит отказа».

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

Категория Классификация источника события. Этот параметр относится к журналам аудита

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

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

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

Компьютер Имя компьютера, на котором произошло событие.

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

События журнала событий безопасности Windows не используют раздел двоичных данных записи события.

Технические проблемы

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

• Управление большим количеством событий безопасности. Чтобы справиться с большим

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

Планирование решения

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

указанные ниже действия.

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

Дополнительные сведения о требованиях к хранению см. далее в разделе «Реализация криминалистического

анализа» данной статьи.

Просмотр текущих параметров аудита безопасности

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

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

Сведения, приведенные в Приложении Б «Реализация параметров групповой политики» в конце этой статьи,
можно использовать для определения параметров, которые необходимо записывать. Дополнительные
сведения о параметрах аудита безопасности см. в статье «Руководство по безопасности Windows Server 2003»
по адресу http://go.microsoft.com/fwlink/?LinkId=14845 (эта ссылка может указывать на содержимое
полностью или частично на английском языке).

Оценка ролей администраторов и задач обычных пользователей

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

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

Просмотр бизнес-политик и процедур

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

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

Обнаружение уязвимых систем

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

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

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

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

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

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

планированию обеспечения безопасности служб и служебных учетных записей» по адресу
http://go.microsoft.com/fwlink/?LinkId=41311 (эта ссылка может указывать на содержимое полностью или
частично на английском языке).

Создание списка особо важных активов

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

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

Определение важных и подозрительных учетных записей

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

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

Создание списка авторизованных программ

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

расположенных в сети. Ограничив перечень программ, которые можно запускать в корпоративной сети,
можно значительно снизить вероятность внешней атаки. Для создания списка авторизованных программ
необходимо выполнить аудит всех программ, авторизованных или являющимися необходимыми в сетевой
среде. Все неизвестные программы, обнаруженные в процессе подобного аудита, следует внести в число
подозрительных и немедленно проверить. Программа Microsoft Systems Management Server 2003 может быть
полезна при проведении аудита программного обеспечения, но не является необходимой.

Примечание.   Для определенных компьютеров можно сделать определенные исключения. Например, в

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

Обнаружение нарушений политики и пороговые значения

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

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

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

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

Моделирование угроз

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

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

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

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

Таким образом, имеется несколько конкретных этапов успешного процесса моделирования сетевых угроз,
основанных на изложенных ниже требованиях.
1. Определение критически важных активов. Важной частью процедуры определения наилучшего
применения ресурсов безопасности является создание списка активов, критически важных для работы
организации. Эта процедура должна охватывать владельцев бизнес-процессов, а также владельцев
технологии, поскольку у каждого из них будут важные соображения относительно опасности раскрытия
определенных активов организации.
2. Определение возможных мест атаки. Этот этап определения фактически включает два направления.
Во-первых, необходимо классифицировать типы границ, в которых могут быть расположены данные в
сети. Эти границы определяют критически важные, секретные и общие области, исходя из ущерба,
который может быть причинен, если эти данные будут раскрыты. Во-вторых, необходимо исследовать с
технической точки зрения точки атаки, направления атаки и уязвимые места, используя которые, можно
получить доступ к критически важным и секретным активам. Эти объединенные сведения позволяют
сузить область применения мер безопасности до тех точек, где можно получить доступ к критически
важным сведениям.
3. Определение фактических угроз. После определения критически важных активов и возможных точек
доступа, необходимо создать список возможных действий злоумышленников, которые могут причинить
ущерб. Этот список позволит сосредоточить усилия на конкретных угрозах.
Существуют различные методы, используемые для определения фактических угроз. Одним из таких
методов является STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of Service and
Elevation of Privilege), основанный на типах используемых атак (подмена, фальсификация, отрицание
выполнения действий, раскрытие информации, отказ в обслуживании и повышение полномочий).
Существуют также другие итеративные меры, такие как разбиение угроз по логическим уровням
(например сеть, узел и приложение). Выбор подхода зависит от организации и основывается на том, что
имеет наибольший смысл в конкретной среде.
4. Классификация и упорядочение угроз. На этом этапе используются общие принципы оценки рисков
 и управления, позволяющие упорядочить угрозы по вероятности их использования и потенциальным
последствиям этих угроз для организации. Стандартная используемая формула имеет следующий вид:
Риск = вероятность использования x потенциальные последствия для организации
Существует большое количество методов, используемых в данном процессе, а также большое количество
средств, позволяющих оценить риски, но их описание выходит за рамки этой статьи. Дополнительные
сведения об управлении рисками и этих методах см. в статье «Руководство по управлению рисками,
связанными с безопасностью» по адресу http://go.microsoft.com/fwlink/?linkid=30794 (эта ссылка может
указывать на содержимое полностью или частично на английском языке).
5. Устранение уязвимостей и повторная оценка. Результатом предыдущих этапов является список
реальных угроз, которые могут оказать влияние на организацию, упорядоченных по степени
представляемой для организации опасности. Этот список позволяет сосредоточить усилия на устранении
уязвимостей. Эти усилия также необходимо оценить по соотношению «затраты-выгода». Таким образом,
имеется несколько различных способов снизить конкретные риски и несколько способов устранения
других уязвимостей, которые делают усилия по обеспечению безопасности еще более эффективными.

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

Наведение справок и расследования

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

Соглашения о политике использования компьютеров

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

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

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

Хотя обсуждение юридических проблем и точных формулировок юридических документов, а также

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

Разделение обязанностей

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

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

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

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

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

Проверка функций наблюдения за безопасностью

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

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

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

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

Установка процессов

Чтобы отделить авторизованные события от несанкционированных событий безопасности, необходимо

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

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

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

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

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

Использование решений для автоматической подготовки пользователей и управления идентификаторами,

таких как Microsoft Identity Integration Server (MIIS) 2003, может быть полезным при автоматизации
изменений учетных записей и выполняемых при этом процессов. При использовании подобных решений
важно не забывать, что учетные записи администраторов все еще имеют возможность создавать новые
учетные записи, но им не требуется этого делать, поскольку учетные записи будут создаваться в рамках
установленных процессов. Таким образом, любые события, связанные с созданием учетных записей,
например событие 624, должны относиться только к MIIS 2003 или иной установленной учетной записи
службы, используемой для автоматической подготовки.

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

Определение ответных действий, связанных с безопасностью

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

Формирование установленного процесса реагирования на нарушения безопасности не только помогает

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

Сотрудники

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

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

Соотнесение нарушений политики безопасности с событиями аудита

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

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

EventCombMT

Программа EventCombMT (многопоточная) описывается в руководстве по безопасности Windows Server 2003,

которое можно найти по адресу http://go.microsoft.com/fwlink/?LinkId=14845 (эта ссылка может указывать на
содержимое полностью или частично на английском языке). Это средство позволяет осуществлять
синтаксический разбор и сбор событий из журналов событий на нескольких компьютерах. Оно запускается
как многопоточное приложение, позволяющее пользователю указать любое количество параметров при
сканировании журналов событий, например:

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

Рис. 4. EventCombMT
Увеличить изображение

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

•
529. Сбой при входе в систему (неправильное имя пользователя или пароль).
•
644. Учетная запись пользователя была автоматически заблокирована.
•
675. Сбой предварительной проверки подлинности в контроллере домена (неправильный пароль).
•
676. Сбой запроса билета проверки подлинности.
•
681. Сбой при входе в систему.

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

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

Примечание.   Событие 12294 отражается как событие диспетчера учетных записей безопасности (Security
Accounts Manager, SAM) в системном журнале, а не в журнале безопасности.

EventCombMT может сохранять события в таблицу базы данных Microsoft SQL Server™, что является полезным
для долгосрочного хранения и анализа. После сохранения в базу данных SQL Server сведения из журналов
событий можно оценить с помощью набора различных программ, например SQL Query Analyzer, Microsoft
Visual Studio® .NET или программ сторонних производителей.

Log Parser 2.2

Log Parser является бесплатным средством от корпорации Майкрософт, которое можно использовать для
поиска данных в журнале, загрузки журналов в базу данных SQL или CSV-файл и создания отчетов на основе
журналов событий, CSV-файлов или иных форматов файлов журнала (включая журналы служб IIS, для
которых это средство было изначально разработано).

Это средство сценариев командной строки можно использовать в качестве ресурса для помещения сведений
журналов событий в центральное местоположение, разбора событий, представляющих интерес, и даже для
создания отчетов. Однако интерфейс сценариев и командной строки требует описания, которое выходит за
рамки данной статьи. Дополнительные сведения о средстве Log Parser, его использовании, и ресурсах
сценариев можно найти на странице Log Parser 2.2 по адресу
www.microsoft.com/technet/scriptcenter/tools/logparser/default.mspx (эта ссылка может указывать на
содержимое полностью или частично на английском языке) и в статье «Описание работы средства Log Parser
2.2» по адресу www.microsoft.com/technet/community/columns/profwin/pw0505.mspx (эта ссылка может
указывать на содержимое полностью или частично на английском языке).

EventQuery.vbs

EventQuery.vbs — это средство, выпущенное вместе с Windows XP. Его можно использовать для создания
списка событий и свойств событий из одного или нескольких журналов событий. Для использования этого
сценария необходимо запустить сервер сценариев на основе команд (CScript.exe). Если сервер сценариев
Windows по умолчанию не назначен CScript, это можно сделать, выполнив следующую команду:

Cscript //h:cscript //s //nologo

Эта служебная программа сценариев командной строки является очень гибкой и может принимать множество
различных параметров для настройки фильтрации и формата выходных данных. Дополнительные сведения
об использовании этого средства и доступных параметрах см. в разделе «Управление журналами событий из
командной строки» документации по Windows XP Professional по адресу
www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/event_commandline.mspx?mfr=true
(эта ссылка может указывать на содержимое полностью или частично на английском языке).

Ведение журнала служб Internet Information Services

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

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

Необходимо тщательно отслеживать определенные действия и последовательности событий, включая

перечисленные ниже.

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

• Слишком частые неудачные попытки входа в систему с одного IP-адреса или диапазона адресов, что может
означать как попытку проведения атаки типа «отказ в обслуживании», так и попытку повышения
полномочий.
•
Неудачные попытки получения доступа или изменения файлов BAT или CMD.
•
Несанкционированные попытки загрузки файлов в папку, которая содержит исполняемые файлы.

Начиная с Windows Server 2003, новые возможности аудита встроены в службы IIS, и их можно использовать
совместно с новыми возможностями ведения журнала служб IIS, интегрированными напрямую в журнал
событий. Также можно получить к ним доступ через страницы ASP для настраиваемых решений.
Дополнительные сведения об этих возможностях и их реализации см. в документации к службам IIS.

Сервер Microsoft Internet Security and Acceleration Server

Сервер Microsoft Internet Security and Acceleration (ISA) Server является расширенным брандмауэром уровня
приложений и пакетов, предоставляющим ряд дополнительных функций, включая возможности кэширования
VPN и прокси-серверов.

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

Рис. 5. Средство просмотра журналов в режиме реального времени сервера Microsoft ISA Server
2004
Увеличить изображение

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

Помимо функций ведения журнала и оповещения об опасности имеются также встроенные средства
обнаружения вторжения, которые можно включить в сервере ISA Server. Эти простейшие службы
обнаружения вторжений (IDS) лицензированы у компании Internet Security Systems и содержат несколько
фильтров пакетов IP, фильтры приложений DNS и фильтр приложений POP. Данные службы позволяют
обнаружить множество распространенных уязвимостей.

Функция обнаружения вторжения в сервере ISA Server может записывать в журнал события и создавать
оповещения при обнаружении потенциальных атак. Она также может останавливать службы и прерывать
подозрительные подключения. Ниже перечислены некоторые обнаруживаемые этой функцией профили атак.

•
WinNuke (атаки Windows по внешним каналам).
•
Land-атаки.
•
IP-атаки полусканирования.
•
UDP-бомбы.
•
Сканирование портов.
•
Атаки, использующие переполнение длины имени узла DNS.
• Переносы зоны DNS с привилегированных портов TCP/IP или портов TCP/IP с большими
номерами.

В любом случае, при использовании сервера ISA Server или иного решения на основе брандмауэра или
системы обнаружения вторжений при разработке системы наблюдения за безопасностью и обнаружения атак
важно не забывать о периметре сети (также известном как демилитаризованная зона (DMZ) и
экранированная подсеть).

Microsoft Operations Manager 2005

Microsoft Operations Manager (MOM) осуществляет наблюдение за несколькими серверами в сети предприятия
из центрального местоположения. Агент MOM осуществляет сбор событий из журналов событий и отправляет
их на сервер управления MOM, который затем заносит эти события в базу данных MOM. MOM 2005 и более
поздние версии могут осуществлять сбор событий с компьютеров, на которых не запущен агент MOM.

MOM использует эксплуатационные правила управления для определения проблем, влияющих на

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

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

Сервер Microsoft Systems Management Server 2003

Сервер Microsoft Systems Management Server (SMS) 2003 может осуществлять наблюдение и управлять
серверами и рабочими станциями в сети из центрального местоположения. Хотя этот сервер предназначен
для выполнения задач управления, он также может выполнять в решении по наблюдению за безопасностью
крайне важные функции, связанные с безопасностью, управляя распространением обновлений системы
безопасности и сообщая о несанкционированных установках программного обеспечения.

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

Реализация криминалистического анализа

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

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

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

•
Время атаки.
•
Продолжительность атаки.
•
Атакованные системы.
•
Изменения, внесенные в процессе атаки.

Опять-таки, из-за большого количества мелких деталей, связанных с пониманием законов, управляющих
процедурой сбора вещественных доказательств, ключевыми типами данных для криминалистического
анализа, средствами, необходимыми для проведения анализа, сбором вещественных доказательств,
хранением вещественных доказательств и судебными методами, невозможно подробно рассмотреть этот
предмет в данной статье. Однако имеется несколько отличных ресурсов, например «Руководство для
специалистов групп оперативного реагирования по судебным делам, связанным с компьютерами» от CERT,
которое можно найти по адресу www.cert.org/archive/pdf/FRGCF_v1.3.pdf (эта ссылка может указывать на
содержимое полностью или частично на английском языке). Это руководство также имеется на веб-узлах,
посвященных компьютерной безопасности.

Проблемы бизнеса

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

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

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

Таблица 2. Ограничения хранилища для криминалистического анализа

Факторы хранилища Ограничения Комментарии

хранилища

Онлайновое хранилище (база 21 день Обеспечивает быстрый доступ к сведениям о

данных) событии

Автономное хранилище (резервная 180 дней Разумное архивное ограничение для большинства
копия) организаций

Регулируемая среда 7 лет Требование к архиву для предприятий,

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

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

организациям

Примечание.   В некоторых отраслях, регулируемых государством (например в организациях, имеющих дело

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

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

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

Технические проблемы

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

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

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

•
Надежное и безопасное хранилище для онлайновых данных.
• Подготовка больших объемов высокопроизводительного дискового пространства для онлайнового
хранилища.
•
Надежные системы резервного копирования для записи старых событий на архивные носители.
•
Безопасные процессы управления архивным хранилищем.
•
Проверенные процессы восстановления для извлечения сведений из резервного хранилища.

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

Требования

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

ниже требования.

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

Развертывание и управление решением

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

•
Обнаружение внутренних нарушений политики.
•
Определение атак из внешних источников.
•
Эффективный и точный криминалистический анализ.

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

Наблюдение за безопасностью и обнаружение атак

Концепция решения для наблюдения за безопасностью и обнаружения атак требует планирования

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

•
Управление учетными записями.
•
Защищенный доступ к файлам.
•
Изменения политики безопасности.
•
Доверенное создание и удаление.
•
Использование прав пользователей.
•
Перезапуски системы и изменения времени.
•
Изменения реестра.
•
Запуск неизвестных программ.

Система наблюдения за безопасностью и обнаружения атак осуществляет сбор сведений из журналов

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

Основным компонентом этого решения является возможность настройки функции Microsoft Windows 2003 с
пакетом обновления 1 (SP1) и Microsoft Windows XP с пакетом обновления 2 (SP2), называющейся
«индивидуальный аудит пользователей». Индивидуальный аудит пользователя допускает задание различных
уровней аудита для определенных учетных записей пользователей, позволяя таким образом устанавливать
более высокий уровень аудита для важных или подозрительных учетных записей.

Необходимые предпосылки решения

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

безопасностью и обнаружению атак.

• На серверах должна быть установлена ОС Windows Server 2003 с пакетом обновления 1 или более поздняя
версия, серверы должны входить в домен Active Directory.
• На клиентских компьютерах должна быть установлена ОС Windows XP с пакетом обновления 2 или более
 поздняя версия, клиентские компьютеры должны входить в домен Active Directory.

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

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

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

Нарушения политики и пороговые значения

Новые возможности, доступные в Microsoft Windows Server 2003 и Microsoft Windows XP с пакетом обновления
2 предусматривают выборочные уровни аудита для отдельных учетных записей пользователей. Например,
можно установить уровни аудита таким образом, чтобы сообщать только о входе в систему и выходе из
системы для всех пользователей, в то же время осуществляя аудит всех действий определенного
пользователя. Выборочный аудит пользователей также можно использовать для уменьшения количества
событий в журнале безопасности, исключая аудит определенных действий для некоторых учетных записей. С
помощью этих функций можно вести аудит только учетных записей пользователей; вести аудит групп
безопасности и групп рассылки таким образом не получится. Учетные записи, принадлежащие локальной
группе администраторов, нельзя исключить из аудита, используя механизм выборочного аудита
пользователей.

Служебная программа командной строки, используемая для задания политики аудита на пользователя в
Windows Server 2003 и Windows XP с пакетом обновления 2, называется Auditusr.exe. Допустимые выборочные
категории аудита:

•
системное событие;
•
вход или выход из системы;
•
доступ к объектам;
•
привилегированное использование;
•
подробное отслеживание;
•
изменение политики;
•
управление учетными записями;
•
доступ к службе каталогов;
•
Вход в систему учетной записи

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

Программа Audituser.exe используется следующим образом:

Audituser.exe /параметр учетная_запись_пользователя:«категория»

(или список категорий, разделенных запятой).

Например, для включения аудита сбоев системных событий и событий входа и выхода из системы для
учетной записи с именем ЛокальныйПользователь используется следующая запись командной строки:

Audituser /if ЛокальныйПользователь:”System Event”,”Logon/Logoff”

В командной строке можно использовать следующие параметры:

•
/is — добавляет или изменяет запись в списке успешного выполнения;
•
/if — добавляет или изменяет запись в списке выполнения с ошибками;
•
/es — добавляет или изменяет запись в списке успешного выполнения;
•
/ef — добавляет или изменяет запись в списке исключений выполнения с ошибками;
• /r — удаляет все записи индивидуального аудита пользователей для определенной учетной записи
пользователя;
• /ra — удаляет все записи индивидуального аудита пользователей для всех учетных записей
пользователей;
•
/e — экспортирует параметры в файл с указанным именем;
•
/i — импортирует параметры из файла с указанным именем.

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

Рис. 6. Пример файла импорта Auditusr.exe

Примечание.   Для успешного импорта файл импорта должен начинаться со строки Auditusr 1.0, как
показано на рисунке.

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

Audituser /i path\audit.txt

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

Нарушения политики безопасности и корреляция событий аудита

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

Из-за риска, связанного со случайным или намеренным злоупотреблением внутренних источников

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

Доступ к несанкционированным компьютерам

Административный и обслуживающий персонал все шире использует средства удаленного управления,

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

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

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

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

Таблица 3. События несанкционированного использования компьютера

Код Событие Комментарии

события

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

529 Сбой при входе в систему —
неизвестное имя пользователя
или неправильный пароль
Проверьте наличие попыток входа в систему, при которых
имя целевой учетной записи — «Администратор» или
переименованная учетная запись администратора по
умолчанию. Также проверьте наличие множества неудачных
попыток входа в систему, количество которых меньше
порогового значения блокировки.

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

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

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

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

534 Сбой при входе в систему — тип Проверьте имя целевой учетной записи, имя рабочей
Код Событие Комментарии
события

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

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

536 Сбой при входе в систему — Убедитесь в том, что служба NetLogon работает. В
компонент NetLogon не активен противном случае, это событие может стать поводом для
расследования.

540 Успешный вход в систему Это событие является сетевым эквивалентом события 528.

Троянские программы, руткиты и вредоносные программы

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

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

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

• Процессы, порождаемые учетной записью LocalSystem. Процессы, запускаемые от имени учетной

записи LocalSystem, должны присутствовать в списке утвержденных программ и могут включать такие
процессы как Services.exe.
• Процессы, порожденные в непредвиденное время. Если в наблюдаемой системе не используются
никакие запланированные пакетные процессы, выполнение некоторых действий (например резервного
копирования, запуска CGI или сценариев) должно становиться поводом для проведения расследования. В
других случаях расследование необходимо проводить, если подобные события происходят не по обычному
расписанию.

Таблица 4. Событие 592

Код Событие Комментарии

события

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

Доступ к ресурсам путем изменения разрешений на файлы

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

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

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

перечисленных ниже факторов для всех особо ценных файлов.

•
Какой объект был целью попытки получения доступа?
•
Какая учетная запись использовалась для запроса доступа?
•
Какая учетная запись санкционировала доступ?
•
Какой тип доступа пытались использовать?
•
Было ли событие успешным или безуспешным?
•
Какой компьютер использовался для запуска попытки?

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

События аудита доступа к объектам, приведенные в следующей таблице, связаны с попытками подобного
рода.

Таблица 5. События изменения разрешений для файлов

Код Событие Комментарии

события

560 Доступ предоставлен Обозначает успешно выполненный запрос на

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

567 Разрешение, связанное с Обозначает использование первого экземпляра типа доступа

использованным дескриптором к объекту и изменение разрешений, если поле «Доступ»
содержит строку WRITE_DAC. Соотнесите с событием 560,
сравнив поля «Дескриптор».

Доступ к ресурсам путем сброса паролей

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

Таблица 6. События сброса пароля

Код Событие Комментарии
события

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

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

698 Изменение пароля режима Обозначает попытку изменения пароля режима восстановления
восстановления служб служб каталогов в контроллере домена. Проверьте IP-адрес
каталогов рабочей станции и имя учетной записи. Это событие требует
немедленного расследования.

Изменение учетной записи пользователя

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

Таблица 7. События изменения учетной записи пользователя

Код Событие Комментарии

события

624 Создание учетной записи Обозначает создание сетевой учетной записи.

пользователя

630 Удаление учетной записи Обозначает удаление сетевой учетной записи.

пользователя

642 Изменение учетной записи Обозначает изменения учетной записи пользователя, связанные
пользователя с безопасностью, но не описываемые событиями 627-630.

685 Изменение имени учетной Обозначает изменение имени учетной записи пользователя.
записи пользователя

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

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

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

Изменения членства в группах

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

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

События аудита управления учетными записями, приведенные в следующей таблице, объясняют изменения
членства в группе.

Таблица 8. События изменения членства в группе

Код Событие Комментарии

события

631, 632, Изменение глобальной Проверьте поле «Имя целевой учетной записи», чтобы
633, 634 группы с включенной определить, была ли измененная группа глобальной, и имела ли
безопасностью она обширные права доступа.

635, 636, Изменение локальной Проверьте поле «Имя целевой учетной записи», чтобы
637, 638 группы с включенной определить, была ли измененная группа группой
безопасностью администраторов, операторов сервера или операторов
резервного копирования.

639, 641, Изменение группы с Обозначает изменение группы, отличное от удаления, создания
668 включенной безопасностью или изменения членства. Проверьте поле «Имя целевой учетной
записи», чтобы убедиться в том, что не была изменена группа с
высокими привилегиями.

659, 660, 661, Изменение универсальной Проверьте поле «Имя целевой учетной записи», чтобы
662 группы, связанное с убедиться в том, что не была изменена группа с высокими
безопасностью привилегиями, например группа администраторов предприятия.

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

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

Несанкционированные попытки использования учетной записи

Создание первого контроллера домена Active Directory в лесу приводит к появлению учетной записи
администратора, которая одновременно является членом групп администраторов домена и администраторов
предприятия. Эта учетная запись требует особой защиты, поскольку это единственная запись, на которую не
распространяются параметры блокировки учетной записи. Таким образом, даже при использовании политики
блокировки учетных записей, эта учетная запись остается особенно уязвимой для атак с использованием
словаря.

Эффективное наблюдение за безопасностью должно отслеживать все попытки входа в систему с этой
учетной записью администратора, даже если она была переименована. Дополнительные сведения о
повышении безопасности административных учетных записей см. в статье «Руководство по планированию
безопасности учетных записей администратора» по адресу http://go.microsoft.com/fwlink/?LinkId=41315 (эта
ссылка может указывать на содержимое полностью или частично на английском языке).

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

Таблица 9. События несанкционированного входа в систему

Код Событие Комментарии

события

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

529 Сбой при входе в систему Всегда проводите расследование, если имя целевой учетной записи
— неизвестное имя — «Администратор» или переименованная учетная запись
пользователя или пароль администратора по умолчанию. Также проводите расследование,
если количество сбоев при входе в систему чуть меньше
порогового значения блокировки. Также проверьте наличие
попыток, при которых имя целевой учетной записи —
«Администратор» или root, а имя домена неизвестно.

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

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

576 Новой учетной записи Обозначает назначение привилегий, которые могут дать новой
назначены особые учетной записи права администратора или возможность изменять
привилегии дневник аудита. Сравните поле «Идентификатор для входа в
систему» с событиями 528 или 540, чтобы с легкостью определить,
получила ли учетная запись привилегии администратора.

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

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

Примечание.   Дополнительные сведения об управлении паролями в разнородных средах см. в серии

руководств по управлению доступом и учетными данными корпорации Майкрософт по адресу
http://go.Microsoft.com/fwlink/?LinkId=14841 (эта ссылка может указывать на содержимое полностью или
частично на английском языке).

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

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

встроенных функций Active Directory. Однако для того чтобы использовать эту функцию, сеть должна
поддерживать именование NetBIOS, такое, как предоставляется, например, службой имен в Интернете для
Windows (WINS).

Интерактивный вход в систему с учетными данными учетной записи службы

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

В Windows Server 2003 и более поздних версиях некоторые учетные записи служб (например службу
оповещения) можно запустить с параметром –LocalService. Кроме того, службы, требующие подключения к
сети, могут использовать учетную запись сетевой службы NT AUTHORITY\Network Service. Все службы,
требующие использования учетных записей пользователей, необходимо проверить, чтобы убедиться в том,
что используемые учетные записи защищены надежными паролями. При наблюдение за безопасностью
необходимо следить, чтобы подобные учетные записи появлялись только при запуске связанных с ними
служб. Дополнительные сведения о повышенной безопасности для учетных записей служб см. в статье
«Руководство по планированию обеспечения безопасности служб и учетных записей служб» по адресу
http://go.Microsoft.com/fwlink/?LinkId=41311 (эта ссылка может указывать на содержимое полностью или
частично на английском языке).

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

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

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

Таблица 10. События входа в систему с учетными данными учетных записей служб

Код Событие Комментарии

события

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

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

600 Процессу был Означает, что служба использует именованную учетную запись для
назначен основной входа в систему с Windows XP или более поздней версии. Для
маркер исследования необходимо сопоставить это события со сведениями в
событиях 672, 673, 528 и 592.

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

Запуск несанкционированной программы

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

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

Таблица 11. События запуска несанкционированных программ

Код Событие Комментарии

события

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

602 Создание запланированного Проверьте поля «Целевое имя» и «Время задачи», если такое
задания событие происходит в непредвиденное время.

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

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

Доступ к запрещенным ресурсам

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

Таблица 12. События попыток доступа к запрещенным ресурсам

Код Событие Комментарии

события

560 Доступ к существующему Проверьте поле «Имя объекта», чтобы определить ресурс, к
объекту запрещен которому была предпринята попытка доступа, и сопоставьте поля
«Основное имя пользователя» и «Основной домен» или «Имя
пользователя клиента» и «Домен клиента», чтобы определить
источник.

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

Использование несанкционированных операционных систем

Использование несанкционированных операционных систем может привести к значительным проблемам,

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

•
Персональные компьютеры, подключенные к сети локально или удаленно.
•
Использование операционных систем, загружаемых с компакт-дисков.
• Переустановка операционной системы Windows.
•
Использование образов программы Virtual PC (виртуальный ПК).

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

местоположений через виртуальную частную сеть или службу удаленного доступа, включая такие требования
к подключающемуся компьютеру, как тип операционной системы, наличие обновлений и установка защитных
средств, например персональных брандмауэров и антивирусного программного обеспечения.
Дополнительные сведения о проверке того, что удаленные компьютеры соответствуют требованиям политик
безопасности предприятия, см. в статье «Внедрение служб карантина с использованием руководства
корпорации Майкрософт по планированию виртуальной частной сети» по адресу
http://go.microsoft.com/fwlink/?LinkId=41307 (эта ссылка может указывать на содержимое полностью или
частично на английском языке).

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

Примечание.   Некоторые системы с открытым исходным кодом существуют в виде загрузочного компакт-

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

Образы Virtual PC обеспечивают полную эмуляцию компьютерной среды на локальном компьютере. При такой
эмуляции в виртуальной среде запускается собственная операционная система со своим именем компьютера,
учетными записями пользователей, структурой службы каталогов и программами. Экземпляр виртуального ПК
можно запускать, выполнять и останавливать независимо от локального компьютера, и при этом на
локальном компьютере не будут создаваться события аудита. Эта возможность, наряду с возможностью
виртуального компьютера подключаться к сети, получать IP-адреса и даже использовать общие диски несет в
себе определенные риски для безопасности, начиная от использования слабых паролей и заканчивая
повышенной вероятностью использования уязвимостей, поскольку виртуальный компьютер не подчиняется
принятой в сети процедуре обновлений. Учитывая эти риски, которые представляют виртуальные ПК, важно
разрешить использование программного обеспечения для создания виртуальных ПК только уполномоченному
персоналу и выработать документированные процедуры, регулирующие создание и использование
экземпляров виртуальных ПК.

Чтобы обнаруживать использование несанкционированных операционных систем, решение по наблюдению за

безопасностью должно обнаруживать перечисленные ниже параметры.

•
Неопознанные учетные записи пользователей, имена компьютеров, рабочих групп или доменов.
•
Дублирующиеся или выходящие за установленный диапазон IP-адреса.
•
Попытки входа в систему с учетной записью администратора по умолчанию.

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

Таблица 13. События использования несанкционированных платформ

Код Событие Комментарии

события

529 Сбой при входе в систему Проверьте наличие попыток, при которых значение поля «Имя
— неизвестное имя целевой учетной записи» — «Администратор» или root либо имя
пользователя или пароль домена неизвестно.
Код Событие Комментарии
события

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

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

Создание или разрыв доверительных отношений

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

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

Таблица 14. События по изменению доверительных отношений

Код Событие Комментарии

события

610 Доверительное Эти события будут созданы на контроллере домена, который

611 отношение с другим установил доверительное отношение. Данное событие требует
620 доменом было создано, немедленного расследования, если оно не соответствует
удалено или изменено установленной процедуре запроса контроля изменений. Проверьте
поле «Имя пользователя», чтобы выявить учетную запись,
выполнившую запрос.

Несанкционированные изменения политики безопасности

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

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

Этот тип изменений политики безопасности включает перечисленные ниже элементы.

• Параметры групповой политики.

•
Политика паролей учетных записей пользователей.
•
Политика блокировки учетных записей пользователей.
•
Политика аудита.
•
Параметры журнала событий, применяемые к журналу событий безопасности.
•
Политика IPsec.
•
Политики беспроводных сетей (IEEE 802.1x).
•
Политики открытых ключей и файловой системы с шифрованием (EFS).
 •
Политики ограниченного использования программ.
• Настройки безопасности.

•
Параметры прав пользователей.
•
Политика паролей учетных записей пользователей.
•
Параметры безопасности.

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

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

Таблица 15. События изменения политик

Код события Событие Комментарии

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

613 Изменение политики IPsec Обозначает изменение политики IPsec. Эти события
614 необходимо расследовать, если они происходят не при
615 запуске системы.

618 Политика восстановления Эти события происходят при использовании политики

зашифрованных данных восстановления зашифрованных данных. Любое
возникновение этих событий вне рамок указанных политик
требует расследования.

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

политики безопасности» по адресу http://technet2.microsoft.com/WindowsServer/en/library/bcd7ea4c-f989-4cee-
969a-920f62f555111033.mspx?mfr=true (эта ссылка может указывать на содержимое полностью или частично
на английском языке).

Попытка раскрытия учетных данных

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

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

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

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

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

Код Событие Комментарии

события

529 Сбой при входе в систему Проверьте наличие попыток, при которых значение поля «Имя
— неизвестное имя целевой учетной записи» — «Администратор» или другая учетная
пользователя или пароль запись уровня администратора, которой не разрешено изменять
пароли. Проверьте наличие множества неудачных попыток входа в
систему, количество которых меньше порогового значения
блокировки. Сопоставьте данные с событиями 529 и 539, чтобы
найти непрерывные последовательности блокировок учетных
записей.

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

539 Учетная запись Обозначает попытку входа в систему с учетной записью, которая
заблокирована была заблокирована. Сопоставьте данные с событием 529, чтобы
обнаружить непрерывные последовательности блокировок.

553 Обнаружена атака с Означает, что пакет проверки подлинности, обычно Kerberos,
повторением пакетов обнаружил попытку входа в систему путем повторения пакетов с
учетными данными пользователя. Хотя это событие может быть
признаком неправильной настройки сети, оно все равно требует
немедленного расследования.

627 Попытка изменения пароля Если поле «Основное имя учетной записи» не соответствует полю
«Имя целевой учетной записи», это событие означает, что кто-то
отличный от владельца учетной записи попытался изменить
пароль.

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

644 Учетная запись Означает, что учетная запись была заблокирована, поскольку
пользователя количество последовательных неудачных попыток входа в систему
автоматически превысило предельное значение для блокировки учетной записи.
заблокирована Сопоставьте данные с событиями 529, 675, 681 и 676 (только
Windows 2000 Server). Также обратитесь к записи для события
12294 в этой таблице.

675 Сбой предварительной Обозначает возможную проблему с синхронизацией времени или

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

12294 Попытка блокировки Обозначает возможную атаку методом подбора пароля,

учетной записи направленную на учетную запись администратора по умолчанию.
Поскольку политики блокировки учетных записей не
распространяются на эту учетную запись, это записывается как
событие SAM 12294 в журнале событий системы. Любое появление
этого события необходимо расследовать, поскольку оно может
Код Событие Комментарии
события

означать использование несанкционированной операционной

системы. Проверьте поле «Имя домена» на наличие неизвестных
доменов.

Использование уязвимостей

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

Лучшей защитой от использования уязвимостей все еще является эффективная процедура управления
исправлениями, которая позволяет быстро проверить и развернуть обновления безопасности в среде. В число
службы, которые могут быть полезны в этом процессе, входят Microsoft Systems Management Server (SMS)
2003 и Windows Software Update Service (WSUS).

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

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

Таблица 17. События, связанные с использованием уязвимостей с помощью повышения

привилегий

Код Событие Комментарии

события

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

551 Пользователь инициирует Это событие может считаться эквивалентным событию 538,
выход из системы поскольку утечка маркера может привести к сбою аудита
события 538, но вызовет при этом событие 551.

576 Привилегированный вход в Обозначает вход в систему с учетной записью администратора,

систему вход в систему учетной записи с достаточными привилегиями
для подделки высоконадежной вычислительной базы (TCB) или
достаточными привилегиями для захвата компьютера с
Windows Server 2003 с пакетом обновления 1 или более
поздней версии. В более ранних версиях Windows это событие
представляет интерес только в том случае, если оно связано с
такими важными привилегиями как SeSecurityPrivilege или
SeDebugPrivelege.

Примечание.   В версиях Windows до Windows Server 2003 событие 576 будет находиться в категории
«Привилегированное использование». В Windows Server 2003 и более поздних версиях, категория «Вход в
систему» также будет содержать это событие. Таким образом, настройка параметров аудита для любой из
этих категорий приведет к появлению данного события.
Попытки обойти аудит

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

Попытки обойти решение по наблюдению за безопасностью с помощью подобных методов обнаружить

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

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

Таблица 18. События обхода аудита событий

Код Событие Комментарии

события

512 Запуск Windows Обычно происходит после события 513. Неожиданные перезагрузки
необходимо расследовать.

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

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

517 Очистка журнала событий Журналы событий безопасности никогда не должны очищаться без
безопасности авторизации. Проверьте поля «Имя пользователя клиента» и
«Домен клиента» на взаимную корреляцию с авторизованным
персоналом и утвержденными процедурой записями.

520 Изменение системного Это действие используется для введения в заблуждение

времени криминалистических расследований или для обеспечения
злоумышленникам ложного алиби. Проверьте поля «Имя
пользователя клиента» и «Домен клиента» на взаимную
корреляцию с авторизованным персоналом. Также следует
проверить имя процесса, чтобы убедиться в том, что оно выглядит
как %windir%\system32\svchost.exe.

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

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

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

612 Изменение политики Хотя это событие необязательно является признаком наличия
Код Событие Комментарии
события

аудита проблемы, злоумышленник может изменить политики аудита в

процессе атаки. Это событие необходимо отслеживать на особо
ценных компьютерах и контроллерах домена.

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

622 Доступ к системе был Это событие может сигнализировать о том, что злоумышленник
удален из системы попытался скрыть улики, включающие событие 621, или пытается
отказать в обслуживании некоторым другим учетным записям.

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

Криминалистический анализ

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

Наблюдение за безопасностью для судебного анализа требует:

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

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

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

Понимание потребностей бизнеса наряду со сведениями, предоставленными в предыдущих разделах должно

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

Аннотация

Очевидно, что в современной сетевой среде эффективное и комплексное решение по наблюдению за

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

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

можно использовать для построения эффективной системы наблюдения за безопасностью и обнаружения
атак. Встроенные функции ведения журнала аудита безопасности ОС Windows Server 2003 и других версий
операционной системы Windows составляют основу для такого решения по наблюдению за безопасностью. В
сочетании с другими компонентами, такими как Microsoft Operations Manager и EventCombMT, а также
необходимыми деловыми политиками и бизнес-процессами это дает возможность разработать комплексную
систему наблюдения за безопасностью.

Приложение A: Исключение ненужных событий

События, приведенные в следующей таблице, обычно исключаются из запросов наблюдения за

безопасностью из-за их частоты и поскольку их включение в решение по наблюдению за безопасностью
обычно бесполезно.

Таблица A1. Ненужные события

Код Событие Комментарии

события

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

562 Дескриптор объекта закрыт Всегда записывается как успешное.

571 Контекст клиента удален Появление ожидается при использовании диспетчера

диспетчером авторизации авторизации.

573 Процесс создает внесистемное Ожидаемое действие.

событие аудита с использованием
API авторизации (AuthZ API)

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

594 Дескриптор объекта был Ожидаемое действие.

продублирован

595 Получен косвенный доступ к объекту Ожидаемое действие.

596 Резервное копирование главного Ожидаемое действие. Происходит каждые 90 дней при
ключа защиты данных настройках по умолчанию.

597 Восстановление главного ключа Ожидаемое действие.

защиты данных

672 Запрос билета Kerberos AS Не содержит никаких дополнительных сведений, если

сведения об аудите для событий входа в систему 528 и
540 уже собираются. Это событие фиксирует получение
билета TGT Kerberos. Фактического доступа не
произойдет, пока не будет получен билет службы (аудит
осуществляется событием 673). Если значение параметра
PATYPE равно PKINIT, вход в систему был выполнен с
помощью смарт-карты.

680 Вход в систему учетной записи Это действие уже записано другими событиями.

697 Вызван API проверки политики Ожидаемое действие.

паролей
Код Событие Комментарии
события

768 Конфликт пространства имен леса Это событие не имеет отношения к безопасности.

769 Добавлены, удалены или изменены Ожидаемое действие. Эти события не следует путать с
770 сведения о доверенном лесе добавлением, изменением или удалением собственно
771 доверительного отношения.

832 Различные события репликации Эти события не имеют отношения к безопасности.

833 Active Directory
834
835
836
837
838
839
840
841

Примечание.   Имеется некоторый риск, связанный с исключением определенных сведений из аудита, но

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

Приложение B: Реализация параметров групповой политики

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

Таблица B1. Параметры аудита безопасности групповой политики

Путь к политике Политика Параметр политики и комментарии

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

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

Локальные Аудит доступа к В используемой по умолчанию групповой политике контроллеров

политики и службе каталогов домена этот параметр включен по умолчанию. Настройте
политика аудита параметры аудита для важных объектов каталога, используя
системные списки управления доступом (SACL) в разделе
«Пользователи и компьютеры Active Directory» или редактор
интерфейса служб Active Directory (ADSI Edit). Необходимо
запланировать реализацию SACL и протестировать SACL в
приближенной к реальности лабораторной среде перед
развертыванием их в производственной среде. Этот подход
позволяет предотвратить перегрузку журналов безопасности из-
за слишком большого объема данных.
Путь к политике Политика Параметр политики и комментарии

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

Локальные Аудит доступа к Будьте осторожны при включении этого параметра, поскольку
политики и объектам это может привести к большому объему данных аудита.
политика аудита Настройте параметры аудита только для особо ценных папок
через SACL и выполняйте аудит только определенных типов
доступа, которые представляют интерес. Если возможно,
выполняйте аудит только событий записи, а не событий доступа
на чтение.

Локальные Аудит изменения Включите аудит успехов и отказов. Соотносите все успешные
политики и политик события с авторизациями администратора.
политика аудита

Локальные Аудит использования Не включайте аудит использования привилегий, поскольку это

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

Локальные Аудит отслеживания Включите этот параметр на уязвимых компьютерах и немедленно

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

Локальные Аудит системных Включите аудит успехов и отказов.

политики и событий
политика аудита

Локальные Создание аудита Этот параметр назначается по умолчанию локальному

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

Локальные Управление журналом Используйте этот параметр, чтобы запретить администраторам

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

Локальные Аудит: Аудит доступа к Этот параметр добавляет SACL к именованным системным
политики и глобальным объектам, таким как мьютексы, семафоры и устройства MS-DOS.
параметры системным объектам В Windows Server 2003 этот параметр по умолчанию отключен.
безопасности Не включайте этот параметр, поскольку это приведет к большому
количеству событий.

Локальные Аудит: Аудит Операции резервного копирования и восстановления позволяют

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

Локальные Аудит: Немедленно Включайте этот параметр только после тщательного

политики и отключить компьютер, рассмотрения и только на особо ценных компьютерах, поскольку
Путь к политике Политика Параметр политики и комментарии

параметры если не удается злоумышленники могут использовать его для запуска атак «отказ
безопасности записать в журнал в обслуживании».
события безопасности

Журнал событий Максимальный размер Рекомендованное значение этого параметра зависит от

журнала безопасности ожидаемых объемов событий и параметров сохранения журналов
безопасности. Шаг увеличения для этого параметра может
составлять только 64 КБ, а средний размер события составляет
0,5 КБ. В активно используемых системах этот параметр можно
задать равным 250 МБ, но общий размер всех журналов событий
вместе взятых не может превышать 300 МБ.

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

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

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