Цикл лекций по дисциплине «Автоматизация процессов управления информационной безопасностью»
CC BY 4.0 © Рахметов Р. для ООО «Интеллектуальная безопасность» (Security Vision), 2020
Субъект доступа – это лицо или процесс, действия которого регламентируются правилами разграничения доступа: учетная запись, пользователь или иная сущность, выполняющая какие-либо действия с объектами доступа.
Объект доступа – это единица информационного ресурса автоматизированной системы, доступ к которой регламентируется правилами разграничения доступа: файл, документ или иной объект, с которым взаимодействует субъект доступа.
Дискреционная модель управления доступом (Discretionary Access Control, DAC, от англ. Discretion – по усмотрению) – владелец объекта сам устанавливает и меняет права доступа субъектов. Минусы данной модели:
• ВПО, работающее в контексте «владельца» объекта, может получить доступ к этому объекту;
• Нет гарантий конфиденциальности информации при чтении данных из одного документа и записи в другой документ с другими правами доступа;
• Игнорирование атрибутов прав доступа при копировании файла на другое устройство (другой домен, другая ОС).
Мандатная модель управления доступом (Mandatory Access Control, MAC, от англ. Mandatory - обязательный) – использование меток/грифов конфиденциальности (англ. Classification) для объектов доступа и формы допуска (англ. Clearance) для субъектов доступа.
Основные правила (для защиты от утечек информации):
• Чтение только объектов, чей уровень безопасности не выше уровня субъекта доступа;
• Запись только в те объекты, чей уровень безопасности не ниже уровня субъекта доступа.
Ролевая модель управления доступом (Role-Based Access Control, RBAC) – предоставление прав доступа ролям (по функционалу), применяется для упрощения администрирования.
RBAC позволяет реализовать:
• Статическое разделение полномочий – невозможность одновременного присвоения субъекту нескольких ролей (например, для противодействия мошенничеству);
• Динамическое разделение полномочий – роли могут быть присвоены, но в каждый конкретный момент можно выполнять функции только одной из ролей (например, залогиниться только под кем-то одним).
Модель управления доступом на основании правил (Rule-Based Access Control, RuBAC) – предоставление доступа в соответствии с логическими правилами «если-то», задаваемыми администратором ИБ, например: размер документа не больше 5Мб, доступ только в будние дни в рабочее время и для сотрудников с формой допуска №3.
Контенто-зависимая модель управления доступом (Content-dependent Access Control) – предоставление доступа субъекту в зависимости от содержания объекта (прообраз DLP-системы предотвращения утечек данных).
Контекстно-зависимая модель управления доступом (Context-dependent Access Control) – предоставление доступа субъекту в зависимости от предыдущего запроса для невозможности агрегировать информацию (не даем субъекту больше, чем он должен знать, анализируя его предыдущие запросы).
Модель управления доступом на основании атрибутов (Attribute Based Access Control, ABAC) – предоставление доступа в зависимости от атрибутов субъекта, объекта, среды функционирования и самого действия в соответствии с логическими правилами «если-то», объединенными в политики. Является развитием модели RuBAC и одной из самых современных моделей управления доступом.
Риск-ориентированная модель управления доступом (Risk-Based/Adaptable Access Control) – предоставление доступа к объекту в зависимости от уровня риска субъекта доступа (IP-адрес, история ранее выполненных действий, скоринговый балл, иные атрибуты) и от ИБ-свойств самого объекта (атрибуты объекта, состояние защищенности, наличие инцидентов/уязвимостей на нем).
Права доступа к объекту описываются в ACL (access control list), состоящем из ACE (access control entries). Права доступа субъекта описываются в его Capability table.
Факторы аутентификации:
1. То, что субъект знает: пароли, парольные фразы, ключевые слова, контрольные вопросы.
2. То, чем субъект владеет: OTP, токены (программные, аппаратные), номер мобильного телефона, смарт-карты.
3. То, чем субъект является: биометрия (отпечатки пальцев, сетчатки глаз, радужной оболочки глаз, голос, изображение, походка).
OTP (one-time password) устройства:
1. Синхронные:
1.1. time-based synchronization (TOTP): OTP получается смешиванием (имитовставкой) секретного ключа и текущего времени, этот OTP отправляется серверу вместе с ID пользователя, сервер сравнивает то, что он сам получил (время+ключ) и то, что пришло от пользователя. Есть некая временная дельта, в пределах которой сработает OTP.
1.2. counter-based synchronization (HOTP - HMAC-based OTP): пользователь нажимает на кнопку на OTP-брелке, OTP получается смешиванием (имитовставкой) секретного ключа и значения счетчика, дальше это значение отправляется для проверки на сервер, который «знает» множество возможных значений счетчика в каждый момент времени.
2. Асинхронные:
Модель «запрос-ответ» (challenge-response): сервер отправляет запрос-challenge (или nonce, некая рандомная величина) пользователю, который вводит её в токен, токен с использованием секретного ключа формирует OTP. Далее пользователь вводит свой ID и этот OTP на странице сервера для аутентификации.
Примеры второго фактора: ruToken,RSA SecurID, FIDO U2F, Google/Microsoft Authenticator
Биометрия
FAR - false acceptance rate – уровень ложного предоставления доступа (пустили злоумышленника в помещение).
FRR - false rejection rate – уровень ложного отказа в доступе (не пускаем легитимного пользователя).
CER - crossover error rate – уровень пересечения ошибок (чем он ниже, тем более точная система, т.е. при приемлемом уровне false acceptance/rejection мы сохраняем высокий процент прохода легитимных юзеров).
На графике CER – это точка, в которой кривые false rejection rate и false acceptance rate пересекаются (т.е. когда false rejection rate = false acceptance rate).
Ошибки I рода (False Positive) (ложноположительные срабатывания) – неверно детектируем чистое письмо как спам.
Ошибки II рода (False Negative) (ложноотрицательные срабатывания) – не задетектировали спам как спам и пропустили во «Входящие».
True Positive – спам верно задетектировали как спам.
True Negative – чистое письмо верно задетектировали как чистое.
NTLM
NTLM - NT LAN Manager, протокол сетевой аутентификации в инфраструктуре Microsoft. Основан на использовании NTLM-хэша пароля пользователя в качестве секретного ключа и на знании сервером NTLM-хэша пароля пользователя для его аутентификации. Старые версии LM, NTLMv1 небезопасны, не применяются.
NTLMv2 – взаимная аутентификация клиента и сервера, использование меток времени (для исключения накопления и повторного использования устаревших данных аутентификации).
Атака Pass The Hash - возможность использования NTLM-хэша от пароля пользователя для получения доступа к ресурсам из-под его УЗ по NTLM-хэшу, без необходимости получения самого пароля.
Утилиты для атаки Pass The Hash:
• Mimikatz – получение NTLM-хэшей и их повторное использование для имперсонации учетной записи.
• Procdump (официальная утилита Microsoft) – доступ к памяти системного процесса lsass.exe, хранящего NTLM-хэши, для последующего брутфорса или повторного использования.
• Работа с hiberfil.sys (файл, хранящий данные ОЗУ во время гибернации – закрытие крышки ноутбука).
Kerberos
Kerberos - протокол сетевой аутентификации для гетерогенных сред, использует симметричное шифрование. Также основан на использовании NTLM-хэша пароля пользователя в качестве секретного ключа и на знании Керберос-сервером NTLM-хэша пароля пользователя для его аутентификации. Пароли (хэши) не передаются по сети, не требуется множественная аутентификация для работы с различными сервисами в пределах Керберос-домена, происходит взаимная аутентификация клиента и сервера.
Компоненты Керберос:
1. KDC (key distribution center) - содержит в себе все закрытые ключи (secret key) пользователей и сервисов, они доверяют KDC. KDC - единая точка отказа, должен быть всегда online.
2. AS (authentication service) - компонент KDC, принимает запросы от пользователей.
3. TGS (ticket granting service) - компонент KDC, который принимает запросы на сессионные ключи (TGS-тикеты/мандаты) и выдаёт их.
4. TGT (ticket granting ticket) - тикет/мандат, который выдаётся AS'ом в зашифрованном виде клиенту на некоторое время (Windows default setting - 10 часов), далее клиент его использует для подтверждения того, что он уже был авторизован.
Описание процесса аутентификации с использованием Керберос:
1. Клиент обращается к AS для получения TGT. Клиент пересылает данные (идентификатор клиента, метку времени и идентификатор сервера), зашифрованные NTLM-хэшем от пароля (секретным ключом) клиента. Этот пакет данных называется AS-REQ.
2. AS расшифровывает запрос клиента (связываясь с KDC для получения секретного ключа клиента); если всё ОК, то возвращает клиенту TGT, зашифрованный ключом TGS'а (т.е. NTLM-хэшем служебного пользователя KRBTGT), а также сессионный ключ связи «клиент/TGS», зашифрованный ключом клиента. Этот пакет данных называется AS-REP. Сам TGT может быть открыт и прочитан только сервисом KRBTGT.
3. Когда клиент хочет использовать сервис, то клиент шлёт в TGS свой TGT, идентификатор сервиса и свой зашифрованный сессионным ключом «клиент/TGS» аутентификатор (ID клиента, timestamp). Этот пакет данных называется TGS-REQ.
4. TGS отвечает:
а) TGS-тикетом, который зашифрован секретным ключом сервиса (т.е. NTLM-хэшем пароля сервисной УЗ) и содержит ID клиента, сетевой адрес клиента, метку времени KDC, время действия мандата, сессионный ключ «клиент/сервис»;
б) сессионным ключом «клиент/сервис», зашифрованный сессионным ключом «клиент/TGS».
Этот пакет данных называется TGS-REP.
5. Клиент отправляет сервису этот TGS-тикет и свой новый аутентификатор (тоже метка времени, ID клиента, зашифрован сессионным ключом «клиент/сервис»). Этот пакет данных называется AP-REQ.
6. Сервис расшифровывает тикет своим закрытым ключом, извлекает сессионный ключ «клиент/сервис», потом полученным сессионным ключом «клиент/сервис» расшифровывает аутентификатор клиента, и чтобы себя аутентифицировать перед клиентом отправляет ему значение «метка времени клиента+1», зашифрованное сессионным ключом «клиент/сервис». Этот пакет отправляемых данных называется AP-REP.
7. Клиент расшифровывает «метку времени+1», проверяет, если ОК - начинается обмен инфрмацией.
Схема работы Керберос:
Domain Controller = KDC+AS
Application Server = сервис, требующийся клиенту, работающему на User’s Workstation
Атаки на Kerberos:
• перебор паролей;
• подделка тикетов;
• доступ к сессионным ключам;
• доступ к секретным ключам (NTLM-хэшам от паролей пользователей и сервисов).
Старая реализация Керберос-шифрования с шифронабором «RC4_HMAC_MD5» использует «несоленый» (всегда одинаковый) NTLM-хэш от пароля атакуемого пользователя для шифрования запроса, поэтому получив этот хэш можем запросить тикет от имени атакуемой УЗ (атака Skeleton). Более новая реализация Керберос-шифрования с шифронабором «AES256_HMAC_SHA1» использует уже «соленый» NTLM-хэш (хэш каждый раз получается разным, т.к. его значение зависит не только от пароля пользователя, но и от некой переменной – «соли»).
Pass The Ticket - возможность использования пользовательского TGS или TGT-билета Керберос для получения доступа к ресурсам из-под УЗ (например, путем доступа к памяти процесса lsass.exe, в котором хранятся Керберос-тикеты).
Golden Ticket - возможность выдавать себя за любого пользователя в домене, используя NTLM-хэш учетной записи KRBTGT и выдавая любые TGT кому угодно.
Silver Ticket - возможность использования NTLM-хэша от пароля ПК или сервиса для создания TGS/TGT и получения доступа к ресурсам из-под этой УЗ.
Kerberoasting - возможность брутфорса и получения пароля сервисной УЗ в офлайне (без риска блокировки аккаунта).
Overpass The Hash - возможность подделки TGT любого пользователя при наличии NTLM-хэша от его пароля.
Защита учетных записей:
• Identity & Access Management системы
• HR-системы (актуальная информация)
• Системы токенизации (предоставление временного псевдо-пароля)
• Смарт-карты (вход не по паролю, а по сертификату)
• Программы повышения осведомленности
• Фишинговые учебные рассылки
• Работа с пользователями
Принципы:
• Минимизация полномочий
• Разделение обязанностей
• Двойной контроль
• Доступ при наличии подтвержденной служебной необходимости и при наличии согласования от руководителя
• Актуализация прав доступа (увольнение, перевод, понижение/повышение)