Повышение уровня безопасности среды
Номер закона Десять: Технология не панацея. - 10 неизменяемых законов администрации безопасности
При создании управляемой безопасной среды для критически важных бизнес-активов фокус должен переключиться на обеспечение безопасного обслуживания. Несмотря на то, что вы получили конкретные технические средства для повышения безопасности установок AD DS, только технология не будет защищать среду, в которой ИТ-специалисты не работают в партнерстве с бизнесом для поддержания безопасной, пригодной для использования инфраструктуры. Рекомендации высокого уровня в этом разделе предназначены для использования в качестве рекомендаций, которые можно использовать для разработки не только эффективной безопасности, но и эффективного управления жизненным циклом.
В некоторых случаях ИТ-организация уже может иметь тесные рабочие отношения с бизнес-подразделениями, что упрощает реализацию этих рекомендаций. В организациях, в которых ИТ-специалисты и бизнес-подразделения не тесно связаны, может потребоваться сначала получить исполнительное спонсорство для усилий по более тесной связи между ИТ-подразделениями и подразделениями. Сводка руководителей предназначена для использования в качестве автономного документа для исполнительного обзора, и его можно распространить для лиц, принимающих решения в вашей организации.
Создание бизнес-ориентированных методов безопасности для Active Directory
В прошлом информационные технологии во многих организациях рассматривались как структура поддержки и центр затрат. ИТ-отделы часто отделы были в значительной степени разделены от бизнес-пользователей, и взаимодействие ограничивается моделью ответа на запросы, в которой бизнес-запросы ресурсов и ИТ-отделы ответили.
Поскольку технология развивалась и процветала, видение "компьютера на каждом рабочем столе" эффективно прошло для большей части мира, и даже затмение широким спектром легкодоступных технологий, доступных сегодня. Информационная технология больше не является функцией поддержки, это основная бизнес-функция. Если ваша организация не могла продолжать функционировать, если все ИТ-службы недоступны, бизнес вашей организации, по крайней мере, частично, информационные технологии.
Чтобы создать эффективные планы восстановления компрометации, ИТ-службы должны тесно сотрудничать с бизнес-подразделениями в организации, чтобы определить не только наиболее важные компоненты ИТ-ландшафта, но и критически важные функции, необходимые для бизнеса. Определив, что важно для вашей организации в целом, вы можете сосредоточиться на защите компонентов, имеющих наибольшее значение. Это не рекомендация по обеспечению безопасности систем и данных с низким уровнем ценности. Скорее, как и вы определяете уровни обслуживания для системного времени простоя, следует рассмотреть вопрос о определении уровней контроля безопасности и мониторинга на основе критичности актива.
Если вы инвестировали в создание текущей, безопасной, управляемой среды, вы можете переключить фокус на эффективное управление и обеспечить эффективное управление жизненным циклом процессов, которые не определяются только ИТ, но и бизнесом. Для этого необходимо не только сотрудничать с бизнесом, но и инвестировать бизнес в "владение" данными и системами в Active Directory.
Когда данные и системы вводятся в Active Directory без назначенных владельцев, владельцев бизнеса и ИТ-владельцев, нет четкой цепочки ответственности за подготовку, управление, мониторинг, обновление и в конечном итоге списание системы. Это приводит к инфраструктуре, в которой системы подвергаются риску организации, но не могут быть списаны, так как владение неясно. Чтобы эффективно управлять жизненным циклом пользователей, данных, приложений и систем, управляемых установкой Active Directory, следует следовать принципам, описанным в этом разделе.
Назначение владельца бизнеса данным Active Directory
Данные в Active Directory должны иметь определенного владельца бизнеса, то есть указанного отдела или пользователя, который является точкой контакта для принятия решений о жизненном цикле актива. В некоторых случаях владелец бизнеса компонента Active Directory будет ИТ-отделом или пользователем. Компоненты инфраструктуры, такие как контроллеры домена, DHCP-серверы и DNS-серверы, и Active Directory, скорее всего, будут принадлежать ИТ-службам. Для данных, добавляемых в AD DS для поддержки бизнеса (например, новых сотрудников, новых приложений и новых репозиториев информации), назначенная бизнес-единица или пользователь должна быть связана с данными.
Независимо от того, используете ли Active Directory запись владения данными в каталоге или реализуете отдельную базу данных для отслеживания ИТ-ресурсов, не следует создавать учетную запись пользователя, не следует устанавливать сервер или рабочую станцию, а приложение не должно быть развернуто без указанного владельца записи. Попытка установить владение системами после их развертывания в рабочей среде может быть сложной в лучшем случае и невозможно в некоторых случаях. Поэтому при вводе данных в Active Directory необходимо установить владение.
Реализация управления жизненным циклом на основе бизнеса
Управление жизненным циклом должно быть реализовано для всех данных в Active Directory. Например, когда новое приложение вводится в домен Active Directory, владелец бизнеса приложения должен регулярно запрашивать постоянное использование приложения. Когда будет выпущена новая версия приложения, владелец бизнеса приложения должен быть проинформирован и должен решить, будет ли реализована новая версия.
Если владелец бизнеса решит не утвердить развертывание новой версии приложения, этот владелец бизнеса также должен получать уведомления о дате, когда текущая версия больше не будет поддерживаться, и должна отвечать за определение того, будет ли приложение выведено из эксплуатации или заменено. Сохранение устаревших приложений, работающих и неподдерживаемых, не должно быть вариантом.
При создании учетных записей пользователей в Active Directory их руководители записей должны получать уведомления при создании объекта и требоваться для проверки действительности учетной записи через регулярные интервалы. Реализуя жизненный цикл, управляемый бизнесом, и регулярное аттестацию действительности данных, люди, которые лучше всего оснащены для выявления аномалий в данных, являются людьми, которые просматривают данные.
Например, злоумышленники могут создавать учетные записи пользователей, которые, как представляется, допустимыми учетными записями, после соглашений об именовании организации и размещения объектов. Чтобы обнаружить эти создания учетных записей, можно реализовать ежедневную задачу, которая возвращает все объекты пользователей без указанного владельца бизнеса, чтобы изучить учетные записи. Если злоумышленники создают учетные записи и назначают владельца бизнеса, реализуя задачу, которая сообщает о создании нового объекта назначенному владельцу бизнеса, владелец бизнеса может быстро определить, является ли учетная запись законной.
Следует реализовать аналогичные подходы к группам безопасности и распространения. Хотя некоторые группы могут быть функциональными группами, созданными ИТ, создавая каждую группу с назначенным владельцем, вы можете получить все группы, принадлежащие указанному пользователю, и требовать, чтобы пользователь мог подтвердить допустимость их членства. Аналогично подходу, принятому при создании учетной записи пользователя, можно активировать изменения группы отчетов для указанного владельца бизнеса. Чем больше подпрограмм становится для владельца бизнеса, чтобы подтвердить допустимость или недопустимость данных в Active Directory, тем больше вы можете определить аномалии, которые могут указывать на сбои процесса или фактический компромисс.
Классификация всех данных Active Directory
Помимо записи владельца бизнеса для всех данных Active Directory во время его добавления в каталог, необходимо также требовать, чтобы владельцы бизнеса предоставляли классификацию данных. Например, если приложение хранит критически важные для бизнеса данные, владелец бизнеса должен пометить приложение таким образом, в соответствии с инфраструктурой классификации вашей организации.
Некоторые организации реализуют политики классификации данных, которые помечают данные в соответствии с ущербом, который может понести, если они были украдены или разоблачены. Другие организации реализуют классификацию данных, которая метки данных по критическости, по требованиям к доступу и по хранению. Независимо от модели классификации данных, используемой в вашей организации, следует убедиться, что вы сможете применять классификацию к данным Active Directory, а не только к данным "file". Если учетная запись пользователя является виртуальной виртуальной учетной записью, ее следует определить в базе данных классификации активов (следует ли реализовать это с помощью атрибутов для объектов в AD DS или развертывать отдельные базы данных классификации активов).
В модели классификации данных следует включить классификацию для данных AD DS, таких как ниже.
Системы
Следует не только классифицировать данные, но и их популяцию серверов. Для каждого сервера необходимо знать, какая операционная система установлена, какие общие роли предоставляет сервер, какие приложения выполняются на сервере, ИТ-владелец записи и владелец бизнеса записи, где применимо. Для всех данных или приложений, работающих на сервере, требуется классификация, и сервер должен быть защищен в соответствии с требованиями к поддерживаемым рабочим нагрузкам и классификациям, применяемым к системе и данным. Вы также можете группировать серверы по классификации своих рабочих нагрузок, что позволяет быстро определить серверы, которые должны быть наиболее тщательно отслеживаются и наиболее строго настроены.
Приложения
Следует классифицировать приложения по функциям (то, что они делают), базе пользователей (которые используют приложения) и операционной системе, в которой они выполняются. Следует хранить записи, содержащие сведения о версиях, состояние исправления и любые другие соответствующие сведения. Кроме того, следует классифицировать приложения по типам обрабатываемых данных, как описано ранее.
Пользователи
Если вы называете их "VIP-адрес", критическими учетными записями или используете другую метку, учетные записи в установках Active Directory, которые, скорее всего, будут нацелены злоумышленниками, должны быть помечены и отслеживаться. В большинстве организаций просто невозможно отслеживать все действия всех пользователей. Однако если вы можете определить критически важные учетные записи в установке Active Directory, эти учетные записи можно отслеживать для изменений, как описано ранее в этом документе.
Вы также можете начать создавать базу данных "ожидаемого поведения" для этих учетных записей при аудите учетных записей. Например, если вы обнаружите, что данный исполнительный директор использует свою защищенную рабочую станцию для доступа к критически важным для бизнеса данным из своего офиса и из своего дома, но редко из других расположений, если вы видите попытки доступа к данным с помощью его учетной записи с несанкционированного компьютера или места на полпути вокруг планеты, где вы знаете, что исполнительный в настоящее время не находится, вы можете быстрее определить и исследовать это аномальное поведение.
Интеграция бизнес-информации с инфраструктурой позволяет использовать эту бизнес-информацию для выявления ложных срабатываний. Например, если исполнительные поездки записываются в календарь, который доступен ИТ-сотрудникам, ответственным за мониторинг среды, можно сопоставить попытки подключения с известными расположениями руководителей.
Предположим, исполнительный A обычно находится в Чикаго и использует защищенную рабочую станцию для доступа к критически важным для бизнеса данным из своего стола, и событие активируется неудачной попыткой получить доступ к данным из незащищенной рабочей станции, расположенной в Атланте. Если вы можете убедиться, что исполнительный директор в настоящее время находится в Атланте, вы можете решить это событие, связавшись с руководителем или помощником руководителя, чтобы определить, был ли сбой доступа результатом исполнительного директора, забыв использовать защищенную рабочую станцию для доступа к данным. Создав программу, которая использует подходы, описанные в разделе "Планирование компрометации", можно начать создавать базу данных ожидаемых действий для наиболее важных учетных записей в установке Active Directory, которые могут помочь вам быстрее обнаруживать и реагировать на атаки.