1Security + Microsoft Sentinel

Sentinel каже, що сталося. 1Security каже йому, хто до чого міг дотягнутися.

Sentinel - робоче місце вашого SOC: кожне джерело нормалізоване, сповіщення згруповані в інциденти, плейбуки ведуть реагування. 1Security підключається до вашого клієнта Microsoft 365 лише на читання й додає те, чого не несе сира подія аудиту - який користувач, з якого пристрою, з якого міста, якого файлу торкнувся і скільки ще файлів міг відкрити цей обліковий запис. Інцидент відкривається на рядку, який уже відповідає на перші три запитання.

Що робить Sentinel

Головний SIEM, вбудований у хмару, якою ви вже користуєтеся.

Одна поверхня запитів для виявлення, розслідування, полювання на загрози й реагування - у масштабі всього, що ви в нього надішлете.

  • Кожне джерело, одна поверхня

    Конектори даних постачаються у складі рішень: джерела Microsoft передають дані в реальному часі, а Syslog, CEF і REST API приносять решту вашого середовища. Нормалізація ASIM перетворює все це на одну модель, до якої справді можна писати запити.

  • Сповіщення стають інцидентами

    Правила аналітики об'єднують сповіщення низької достовірності про різні сутності в інциденти високої достовірності, зіставлені з MITRE ATT&CK і збагачені аналітикою загроз. Аналітик починає зі справи, а не зі стогу сіна.

  • Реагування як робочий процес

    Правила автоматизації централізовано координують обробку інцидентів, а плейбуки на Azure Logic Apps несуть реагування в ServiceNow, Jira та решту вашого стека. Запити полювання на загрози та блокноти сягають далі, ніж передбачило будь-яке правило.

Запитання, на яке відповідає ця зв'язка

Рядок журналу каже, що сталося. Він не каже, до чого можна було дотягнутися.

Інцидент у Sentinel називає обліковий запис о 02:14. Наступні три запитання завжди ті самі: хто це, що він може відкрити і чи нормальна для нього ця ніч? Цих відповідей немає в жодній події, бо постійні дозволи в Microsoft 365 - це стан, а не активність. Посилання спільного доступу, створене 2023 року, цієї ночі нічого не пише. Вкладена група розширює охоплення до сайту, якого не згадує жоден рядок журналу. У типовому клієнті Microsoft 365 звичайний обліковий запис може відкрити понад 200 000 файлів, і ніщо в потоці аудиту про це не каже.

Тож аналітик виходить з інциденту з'ясовувати - діалоги дозволів, членства в групах, скрипт на кожен сайт - і повертається за годину з оцінкою. Ця година - вся ціна сповіщення, і її платять і за хибні спрацювання.

1Security тримає цю відповідь напоготові. Він обчислює, до чого може дотягнутися кожен користувач, гість, застосунок і ШІ-агент через прямі надання, посилання спільного доступу, групи та успадкування, зберігає до трьох років атрибутованої активності й передає Sentinel події, які вже несуть контекст. Інцидент і далі відкривається в Sentinel. Година зникає.

Що додає 1Security

Чотири речі, які Sentinel отримує з клієнта і яких раніше не мав.

1Security підключається до Microsoft 365 лише на читання, будує граф дозволів та історію активності й віддає те й інше Sentinel через REST API лише для читання.

  1. 01

    Охоплення в кожній події

    Кожна подія Microsoft 365, яку віддає 1Security, прив'язана до користувача, файлу чи поштової скриньки, застосунку, пристрою та розташування, а обліковий запис за нею приходить з тим, що він може відкрити: сайти, файли, поштові скриньки, обчислені через вкладеність, посилання та успадкування. Питання про радіус ураження, яке забирало пів дня, - це поле в рядку.

  2. 02

    Норма для кожного облікового запису

    Кожен користувач, застосунок і ШІ-агент оцінюється відносно власної попередньої активності. «340 завантажень сьогодні» приходить уже порівняним зі звичними 12, з епізодом аномалії, за яким Sentinel може корелювати. За цим стоїть до трьох років історії на стандартних ліцензіях Microsoft 365.

  3. 03

    Пристрої та розташування, а не лише IP-адреси

    Кожна подія несе пристрій (керований, некерований або той, що ніколи не реєструвався) і розташування як країну, місто й тип мережі - хостинг, VPN, офіс. Вердикт про неможливу подорож - це значення в рядку, а не запит KQL, який ви пишете.

  4. 04

    Виправлення, яке чекає на людину

    Коли Sentinel ескалує, виправлення відбувається в 1Security за вікном перевірки - завершити строк дії посилань, забрати доступ, відкликати сеанси - підготовлене за кожним ресурсом, за замовчуванням 72 години, із записом, хто затвердив. Ніщо незворотне не виконується на самій лише автоматизації.

Як вони поєднуються

Sentinel тримає запис і робочий процес. 1Security тримає контекст.

Sentinel залишається головним SIEM: робоча область, правила аналітики, інциденти, плейбуки. 1Security підключається до вашого клієнта Microsoft 365 зі згодою лише на читання - без агентів, на стандартних ліцензіях, перші знахідки того самого дня - і підтримує те, чого не може потік журналів: обчислений граф дозволів, норми за кожним обліковим записом і три роки атрибутованої історії. Sentinel за розкладом забирає з REST API лише для читання журнали аудиту 1Security, сповіщення моніторингу та сповіщення безпеки, і кожен рядок приходить з уже прикріпленими «хто», пристроєм, розташуванням і охопленням. Сповіщення Sentinel і Defender також з'являються всередині 1Security, пов'язані з обліковим записом, групою, поштовою скринькою чи застосунком, яких вони стосуються, тож перехід працює в обидва боки. Коли аналітику потрібна повна картина, одне клацання відкриває обліковий запис у 1Security.

  • 1 день
    від згоди лише на читання до перших знахідок
  • 10 хв
    до відповіді про радіус ураження, яка раніше забирала пів дня
  • 3 роки
    атрибутованої активності за кожним інцидентом

Разом на практиці

DORA хоче оцінку впливу до строку. Обсяг має бути пошуком у даних, а не проєктом.

DORA вимагає від фінансових організацій класифікувати інциденти у сфері ІКТ і повідомляти про серйозні у фіксовані строки - первинне повідомлення, проміжний звіт, підсумковий звіт - з обґрунтованою оцінкою впливу. Годинник запускається раніше, ніж закінчується розслідування.

Sentinel встановлює ланцюжок подій: коли почалося, які системи були задіяні, що зробили правила аналітики та плейбуки. 1Security встановлює обсяг: кожен файл, сайт і поштову скриньку, до яких міг дотягнутися зачеплений обліковий запис, обчислені за хвилини, і чого він насправді торкнувся, виміряне відносно трьох років його власної історії. І те і те - в рядку, який Sentinel уже тримає.

Первинне повідомлення виходить зі справжніми цифрами. Проміжний звіт називає 214 000 досяжних файлів і 3 100 з персональними даними, а не «потенційно зачеплені». А подальше усунення підготовлене, перевірене й записане, тож до підсумкового звіту можна додати хронологію виправлень.

Інтеграція

На запит, лише читання, за вашим розкладом.

Sentinel забирає з REST API 1Security лише для читання під /api/v1: нормалізовані журнали аудиту Microsoft 365, збагачені користувачем, файлом, пристроєм, розташуванням і охопленням; сповіщення моніторингу від ваших політик; і сповіщення безпеки з тим самим контекстом. Ключі видаються на клієнта, з обмеженою областю й лише на читання, тож колектор може читати дані й нічого не змінює ні в 1Security, ні в Microsoft 365. Сповіщення Sentinel і Defender течуть і у зворотний бік і потрапляють в 1Security пов'язаними із сутностями, яких вони стосуються. Вихідна доставка вебхуками запланована; доки її немає, підтримуваний шаблон - опитування за розкладом.

Дайте інцидентам у Sentinel «хто», охоплення та історію.

Підключіть 1Security лише на читання і спрямуйте Sentinel на API. Ваш наступний інцидент Microsoft 365 відкриється з обліковим записом, його охопленням і його нормою вже в рядку.

Або й далі залишайте аналітику перші три запитання для відповіді вручну.