SOT

SOT

SOAR
Security Orchestration, Automation and Response

Автоматизация реагирования на инциденты информационной безопасности при помощи динамических плейбуков с применением СЗИ, выстраиванием цепочки атаки и объектно-ориентированным подходом

NG SOAR
Next Generation SOAR

Автоматизация реагирования на инциденты ИБ со встроенной базовой корреляцией, сбором сырых событий непосредственно с СЗИ, динамическими плейбуками, выстраиванием цепочки атаки и объектно-ориентированным подходом

AM
Asset Management

Описание ИТ-ландшафта, обнаружение новых объектов в сети, категорирование активов, инвентаризации и управления жизненным циклом оборудования и ПО на АРМ и серверах организаций

VM
Vulnerability Management

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

ГосСОПКА
Государственная Система Обнаружения Предупреждения и Ликвидации Последствий Компьютерных Атак

Двустороннее взаимодействие с Национальным координационным центром по компьютерным инцидентам (НКЦКИ), а именно передача информации об инцидентах и получение оперативных уведомлений/бюллетеней от регулятора

FinCERT
Financial Computer Emergency Response Team

Двустороннее взаимодействие с Центральным Банком (ЦБ РФ, ЦБ РБ и др.), а именно передача информации об инцидентах и получение оперативных уведомлений/бюллетеней от регулятора

Напишите нам на sales@securityvision.ru или закажите демонстрацию

GRC

GRC

КИИ
Критическая Информационная Инфраструктура

Аудит и исполнение требований ФЗ-187 «О безопасности критической информационной инфраструктуры Российской Федерации» и других нормативных документов

RM
Risks Management

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

ORM
Operational Risks Management

Учёт и фиксация событий операционных рисков (СОР), мониторинг ключевых индикаторов рисков (КИР) и проведение самооценки /контроля согласно положению №716-П ЦБ РФ

CM
Compliance Management

Аудит соответствия и комплаенса различным методологиям и стандартам (проектный)

BCP
Business Continuity Plan

Автоматизация процесса обеспечения непрерывности и восстановления деятельности (ОНиВД) после наступления чрезвычайных ситуаций

Напишите нам на sales@securityvision.ru или закажите демонстрацию

Управление доступом и учетными записями (конспект лекции)

Управление доступом и учетными записями (конспект лекции)
21.12.2020

Цикл лекций по дисциплине «Автоматизация процессов управления информационной безопасностью»
CC BY 4.0 © Рахметов Р. для ООО «Интеллектуальная безопасность» (Security Vision), 2020

 

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

 

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

 

Дискреционная модель управления доступом (Discretionary Access Control, DAC, от англ. Discretion – по усмотрению) – владелец объекта сам устанавливает и меняет права доступа субъектов. Минусы данной модели:

•       ВПО, работающее в контексте «владельца» объекта, может получить доступ к этому объекту;

•       Нет гарантий конфиденциальности информации при чтении данных из одного документа и записи в другой документ с другими правами доступа;

•       Игнорирование атрибутов прав доступа при копировании файла на другое устройство (другой домен, другая ОС).


03_01_sv.png   


Мандатная модель управления доступом (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.     То, чем субъект является: биометрия (отпечатки пальцев, сетчатки глаз, радужной оболочки глаз, голос, изображение, походка).


03_02_sv.png

 

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).

 

03_03_sv.png

 

Ошибки I рода (False Positive) (ложноположительные срабатывания) – неверно детектируем чистое письмо как спам.

Ошибки II рода (False Negative) (ложноотрицательные срабатывания) – не задетектировали спам как спам и пропустили во «Входящие».

True Positive – спам верно задетектировали как спам.

True Negative – чистое письмо верно задетектировали как чистое.


03_04_sv.png 


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

03_05_sv.png 


Атаки на 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-системы (актуальная информация)

•       Системы токенизации (предоставление временного псевдо-пароля)

•       Смарт-карты (вход не по паролю, а по сертификату)

•       Программы повышения осведомленности

•       Фишинговые учебные рассылки

•       Работа с пользователями

 

Принципы:

•       Минимизация полномочий

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

•       Двойной контроль

•       Доступ при наличии подтвержденной служебной необходимости и при наличии согласования от руководителя

•       Актуализация прав доступа (увольнение, перевод, понижение/повышение)

 

ИБ для начинающих Управление ИБ Аудит информационной безопасности Метрики ИБ

Рекомендуем

Динамический анализ исходного кода
Динамический анализ исходного кода
Комплекс документов СТО БР ИББС. Отраслевой стандарт Банка России
Комплекс документов СТО БР ИББС. Отраслевой стандарт Банка России
Принципы информационной безопасности
Принципы информационной безопасности
Нормативные документы по ИБ. Часть 11. Защита коммерческой тайны
Нормативные документы по ИБ. Часть 11. Защита коммерческой тайны
Практика ИБ. Политики аудита безопасности Windows
Практика ИБ. Политики аудита безопасности Windows
Построение системы управления информационной безопасностью. Часть 1. Инвентаризация активов
Построение системы управления информационной безопасностью. Часть 1. Инвентаризация активов
Как система защиты данных от утечек понимает, что защищать
Как система защиты данных от утечек понимает, что защищать
IoCs / Индикаторы компрометации / Indicators of Compromise
IoCs / Индикаторы компрометации / Indicators of Compromise
Динамические плейбуки IRP/SOAR 2.0 на платформе Security Vision 5
Динамические плейбуки IRP/SOAR 2.0 на платформе Security Vision 5
Нормативные документы по ИБ. Часть 1. Стандарты ГОСТ Р 57580.1-2017 и ГОСТ Р 57580.2-2018
Нормативные документы по ИБ. Часть 1. Стандарты ГОСТ Р 57580.1-2017 и ГОСТ Р 57580.2-2018
Системы и средства защиты информации (конспект лекции)
Системы и средства защиты информации (конспект лекции)
Тренды информационной безопасности. Часть 2
Тренды информационной безопасности. Часть 2

Рекомендуем

Динамический анализ исходного кода
Динамический анализ исходного кода
Комплекс документов СТО БР ИББС. Отраслевой стандарт Банка России
Комплекс документов СТО БР ИББС. Отраслевой стандарт Банка России
Принципы информационной безопасности
Принципы информационной безопасности
Нормативные документы по ИБ. Часть 11. Защита коммерческой тайны
Нормативные документы по ИБ. Часть 11. Защита коммерческой тайны
Практика ИБ. Политики аудита безопасности Windows
Практика ИБ. Политики аудита безопасности Windows
Построение системы управления информационной безопасностью. Часть 1. Инвентаризация активов
Построение системы управления информационной безопасностью. Часть 1. Инвентаризация активов
Как система защиты данных от утечек понимает, что защищать
Как система защиты данных от утечек понимает, что защищать
IoCs / Индикаторы компрометации / Indicators of Compromise
IoCs / Индикаторы компрометации / Indicators of Compromise
Динамические плейбуки IRP/SOAR 2.0 на платформе Security Vision 5
Динамические плейбуки IRP/SOAR 2.0 на платформе Security Vision 5
Нормативные документы по ИБ. Часть 1. Стандарты ГОСТ Р 57580.1-2017 и ГОСТ Р 57580.2-2018
Нормативные документы по ИБ. Часть 1. Стандарты ГОСТ Р 57580.1-2017 и ГОСТ Р 57580.2-2018
Системы и средства защиты информации (конспект лекции)
Системы и средства защиты информации (конспект лекции)
Тренды информационной безопасности. Часть 2
Тренды информационной безопасности. Часть 2

Похожие статьи

XDR - eXtended Detection and Response
XDR - eXtended Detection and Response
Нормативные документы по ИБ. Часть 9. Обзор российского законодательства в области защиты критической информационной инфраструктуры - продолжение
Нормативные документы по ИБ. Часть 9. Обзор российского законодательства в области защиты критической информационной инфраструктуры - продолжение
Каналы утечки информации. Часть 2
Каналы утечки информации. Часть 2
Модуль «Управление активами и инвентаризация» на платформе Security Vision: еще больше возможностей
Модуль «Управление активами и инвентаризация» на платформе Security Vision: еще больше возможностей
Управление рисками информационной безопасности. Часть 5. Стандарт NIST SP 800-30 (продолжение). Стандарт NIST SP 800-137
Управление рисками информационной безопасности. Часть 5. Стандарт NIST SP 800-30 (продолжение). Стандарт NIST SP 800-137
Метрики: их очарование и коварство
Метрики: их очарование и коварство
Роль киберполигона в обеспечении ИБ
Роль киберполигона в обеспечении ИБ
Нормативные документы по ИБ. Часть 10. Обзор российского законодательства в области защиты критической информационной инфраструктуры - окончание
Нормативные документы по ИБ. Часть 10. Обзор российского законодательства в области защиты критической информационной инфраструктуры - окончание
Обеспечение непрерывности деятельности и восстановление работоспособности инфраструктуры компании. Физическая безопасность (конспект лекции)
Обеспечение непрерывности деятельности и восстановление работоспособности инфраструктуры компании. Физическая безопасность (конспект лекции)

Похожие статьи

XDR - eXtended Detection and Response
XDR - eXtended Detection and Response
Нормативные документы по ИБ. Часть 9. Обзор российского законодательства в области защиты критической информационной инфраструктуры - продолжение
Нормативные документы по ИБ. Часть 9. Обзор российского законодательства в области защиты критической информационной инфраструктуры - продолжение
Каналы утечки информации. Часть 2
Каналы утечки информации. Часть 2
Модуль «Управление активами и инвентаризация» на платформе Security Vision: еще больше возможностей
Модуль «Управление активами и инвентаризация» на платформе Security Vision: еще больше возможностей
Управление рисками информационной безопасности. Часть 5. Стандарт NIST SP 800-30 (продолжение). Стандарт NIST SP 800-137
Управление рисками информационной безопасности. Часть 5. Стандарт NIST SP 800-30 (продолжение). Стандарт NIST SP 800-137
Метрики: их очарование и коварство
Метрики: их очарование и коварство
Роль киберполигона в обеспечении ИБ
Роль киберполигона в обеспечении ИБ
Нормативные документы по ИБ. Часть 10. Обзор российского законодательства в области защиты критической информационной инфраструктуры - окончание
Нормативные документы по ИБ. Часть 10. Обзор российского законодательства в области защиты критической информационной инфраструктуры - окончание
Обеспечение непрерывности деятельности и восстановление работоспособности инфраструктуры компании. Физическая безопасность (конспект лекции)
Обеспечение непрерывности деятельности и восстановление работоспособности инфраструктуры компании. Физическая безопасность (конспект лекции)