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

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

	Введение
	Определение
	Трудности для среднего бизнеса
	Решения
	Аннотация
	Приложение a: Исключение ненужных событий
	Приложение B: Реализация параметров групповой политики

Введение

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

Аннотация

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

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

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

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

Средства ведения журнала безопасности, имеющиеся в 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. Заголовок события

Поле описания события содержит разнообразные сведения, которые могут меняться от события к событию. Например, в событии 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. Ограничения хранилища для криминалистического анализа

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

Один из возможных вариантов заключается в использовании онлайновых баз данных для хранения данных для криминалистического анализа и последующем архивировании старых событий в лучше поддающийся сжатию формат, например разделенный запятыми текст (также известный как значения, разделенные запятой, или 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. События несанкционированного использования компьютера

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В Windows server 2003 и более поздних версиях некоторые учетные записи служб (например службу оповещения) можно запустить с параметром –LocalService. Кроме того, службы, требующие подключения к сети, могут использовать учетную запись сетевой службы NT aUTHORITY\Network service. Все службы, требующие использования учетных записей пользователей, необходимо проверить, чтобы убедиться в том, что используемые учетные записи защищены надежными паролями. При наблюдение за безопасностью необходимо следить, ч