bga68comp: (Default)

SIEM, SIEM TOOLS, ARCHITECTURE
Джерело:
https://www.linkedin.com/posts/priombiswas-cybersec_siem-tools-architecture-ugcPost-7335827891684823040-ZyaH




Priom Biswas

IT🌐|☁️Cloud/SysOps/Cybersecurity Strategy🚀| OS-WS/Linux👨💻| F5 | SIEM | AWS | Oracle OCI | WAF | VA | XDR🛡️| DFIR🕵| Malware🐞| Wireshark | Threat Intelligence🔰| Phishing Analysis 📧| PKI🔑| Dohatec-CA & NOC-Team


 🛡️Mastering SIEM: The Brain of Modern Cyber Defense 🚀
💥 Security Information & Event Management – Explained Simply By Kumar Raja Reddy T

In today’s threat landscape, visibility is everything. 🔍
Over the past few weeks, I’ve crafted a detailed guide covering SIEM fundamentals, tools, architectures, and real-world use cases—designed to help learners, SOC analysts, and security professionals truly understand how SIEM powers proactive defense.
📘 What’s Inside:
  1️⃣ What is SIEM? Why it matters in modern cybersecurity
  2️⃣ How SIEM collects, parses, correlates & analyzes logs
  3️⃣ Top SIEM tools: Splunk, QRadar, Sentinel, ArcSight & more
  4️⃣ Real-world examples of threat detection & incident response
  5️⃣ Incident Management & Response Lifecycles
  6️⃣ Next-Gen SIEM: AI, UEBA, XDR & SOAR integrations
  7️⃣ SIEM Architecture deep-dives (ArcSight, Splunk)
  8️⃣ Dashboards, alerting, compliance reporting & threat hunting

 🎯 Goal: To turn complex SIEM concepts into clear, actionable knowledge that can be applied in the SOC, classroom, or certification prep.
Whether you’re starting out in cybersecurity or upskilling for the next step in your career, this guide is your launchpad. 🚀
 🧠 You can’t stop what you can’t see.
With SIEM, we see more—and act faster.
 📥 New Guide Released: SIEM & SIEM Tools
A Practical Breakdown for Cybersecurity Professionals & Learners
https://lnkd.in/gmfDEAkU


bga68comp: (Default)

Питання:
— Alerts — це події?

Ні, alerts (тривоги, сигнали, оповіщення) — це не події (events), а реакція SIEM на події.

Ось чітке розмежування:

Термін Українською Що це таке Приклад
Event Подія Будь-який факт, зафіксований системою: логін, відкриття порту, запуск процесу тощо. Успішний логін користувача до AD
Log Журнал (запис) Текстовий запис події з технічними деталями (час, IP, користувач тощо). 2025-05-22 18:03:12 user:admin login success from 192.168.1.10
Alert Тривога / сигнал Автоматично або вручну створене повідомлення, яке вказує на потенційно шкідливу або аномальну активність, на основі подій. "Підозрілий логін о 3:00 ночі з іншої країни"

🔁 Взаємозв’язок:

  1. Події (events)
  2. Журнали (logs)
  3. Обробка (normalization)
  4. Кореляція (correlation rules)
  5. Створення alert-ів (за певними умовами)
🔎 Приклад:
  • Подія: "10 невдалих логінів поспіль".
  • Подія: "Потім один успішний логін з іншого регіону".
  • Alert: "Можливе brute-force проникнення реагувати!"
🔧 Підсумок:
  • Подія — це факт.
  • Alert — це висновок SIEM, що цей факт (або комбінація фактів) може свідчити про інцидент.

Тому AlertЗастереження (Найкращий баланс між "сповіщенням" і "тривогою")


bga68comp: (Default)

Denny Roger
https://www.linkedin.com/in/dennyroger/
LinkedIn Top Voice | SOC Builder | Cybersecurity Startup Builder | 23 anos de consultoria estratégica em cibersegurança | Master Coach | Triatleta
Сан-Паулу, Бразилия



SIEM (Security Information and Event Management):

Думаєш, що SIEM — це просто миготливі алерти? Тоді присядь, я покажу, як все працює насправді.
Справжній SIEM — це цикл. Живий механізм. І якщо хоч одна шестерня в цій машині вийде з ладу — все, прогавиш атаку і дізнаєшся про неї з новин. Тож розберімо цю систему по пунктах:

1. Збір журналів (Log Collection)

Усе починається тут. Немає логів — немає безпеки. SIEM бачить тільки те, що збирає. Жодних логів з фаєрволів, AD, кінцевих точок чи Microsoft 365? Це як намагатися скласти пазл без головних частин.

2. Обробка журналів (Log Processing)

Зібрав логи? Тепер їх треба привести до ладу. Фільтрація, нормалізація, уніфікація — усе має бути готове до аналізу. Інакше отримаєш цифрове звалище, в якому не розбереться ніхто.

3. Зберігання (Storage)

Де ти це все зберігаєш? І скільки часу? Тут в гру вступають Retention (строк зберігання або політика зберігання), Compliance (відповідність вимогам або дотримання нормативів) і політики зберігання. Бачив компанії, які отримували штрафи, бо видаляли логи через 15 днів. Без стратегії зберігання — болючі проблеми гарантовані.

4. Запити (Querying)

Дані є — а запитати вмієш? Тут вирішується, аналітик ти чи просто пасажир. Уміння ставити правильні запитання до логів — це те, що відрізняє ефективний SOC від загублених у логах людей.

5. Кореляція (Correlation)

А ось і магія. SIEM зв’язує події: підозрілий логін + нетиповий аплоад + нічний трафік = інцидент. Правильна кореляція — це коли бачиш загрозу до того, як вона стане проблемою.

6. Дашборди (Dashboards)

Все добре, але CISO хоче бачити цифри. Дашборд має розповідати історію, а не просто бути красивою картинкою. Якщо з нього не можна приймати рішень — це просто декорація для презентації.

7. Застереження (Alerts)

SIEM починає кричати. Але чому саме? Якісне застереження має контекст, пріоритет і план дій. Погане застереження — просто шум, який виснажує команду SOC.

8. Управління інцидентами (Incident Management)

Дійшли до інциденту? Тепер важливо діяти: створити тікет, слідувати плейбуку, правильно повідомити й швидко вирішити. Цикл завершується — і починається знову, з урахуванням набутого досвіду.

Підсумок?

SIEM — це не просто інструмент. Це спосіб мислення. Це мозок добре організованого SOC.
А якщо ти не поєднав усі компоненти — у тебе просто дорогий інтерфейс з маленькою користю.

Хочеш робити все правильно? Інтегруй усе. Розумій цикл. І пам’ятай: дані без мети — це просто витрати.


Оригінал:
https://www.linkedin.com/posts/dennyroger_t%C3%A1-achando-que-siem-%C3%A9-s%C3%B3-alerta-piscando-activity-7330840895459667970-OHWR
Read more... )


bga68comp: (Default)
Щоб перевірити надійність вашого паролю, скористайтеся сайтами:



bga68comp: (Default)


Philippe Caturegli
• Chief Hacking Officer at Seralys

Впродовж останніх 4,5+ років MasterCard мала помилку в записах DNS, коли в одному з її піддоменів був запис NS, що вказує на a22-65.akam.ne, а не на a22-65.akam.net (Akamai Technologies).
На щастя, ми виявили цю проблему під час нашого нещодавнього дослідження безпеки DNS та управління доменами та «оборонно» зареєстрували домен, щоб запобігти зловживанням. Але цікаво, що, як зазначив Brian Krebs, «хтось у Росії зареєстрував цей домен з друкарською помилкою ще в 2016 році і протягом декількох років час від часу дозволяв його IP-адресу в Німеччині (185.53.177.31)». 😱

Будь ласка, перевірте ще раз свої записи DNS...
Одна помилка може відкрити двері для атак типу «людина посередині», фішингу, перехоплення даних і багато іншого. Якщо ви не контролюєте домен, на який вказують ваші сервери імен, зловмисники можуть це зробити.



Джерело:
https://www.linkedin.com/posts/caturegli_for-the-past-45-years-mastercard-had-a-activity...


bga68comp: (Default)

Якщо ви підозрюєте, що ваш обліковий запис в Telegram зламали, виконайте такі кроки:
 
  1. Негайно завершіть сесії на всіх пристроях
  • Зайдіть в Установки Пристрої.
  • Натисніть кнопку Завершити всі інші сеанси.
Це викине зловмисника з вашого облікового запису.

  1. Змініть пароль для двофакторної автентифікації
  • У Налаштуваннях виберіть Конфіденційність та безпека Двоетапна автентифікація.
  • Встановіть новий пароль та додайте резервний e-mail.

  1. Перевірте активні чати та групи
  • Переконайтеся, що зловмисник не додав вас до підозрілих груп або чатів.
  • Видаліть будь-які підозрілі повідомлення, які були надіслані від вашого імені.

  1. Змініть пароль на пошті
Якщо ви використовуєте електронну пошту для відновлення Telegram, змініть пароль на поштовому обліковому записі.
 
  1. Оновіть PIN-код SIM-картки
Це захистить вас від можливого клонування SIM-картки, якщо злом стався через мобільний номер.
 
  1. Оновіть Telegram до останньої версії
Якщо зловмисник використовував уразливість, вона могла бути усунена у новій версії програми.
 
  1. Зверніться до Telegram
Якщо ви втратили доступ до облікового запису, напишіть на підтримку через спеціальну форму Telegram або на e-mail login@telegram.org.

 

Як уникнути злому у майбутньому?
 
  • Встановіть двофакторну аутентифікацію.
  • Не використовуйте прості паролі.
  • Не переходьте за підозрілими посиланнями.
  • Увімкніть оповіщення про входи до облікового запису.
 

Офіційний сайт Telegram: https://telegram.org
 
На цьому сайті ви можете:
 
  • Завантажити програму для різних платформ.
  • Дізнатися більше про функції Telegram.
  • Перейти до розділу Support для зв'язку із підтримкою.
  • Ознайомитися з політиками конфіденційності та безпеки.

Якщо потрібно вирішити проблему, зв'язатися з підтримкою або знайти інструкції, використовуйте цей ресурс.
 
Telegram пропонує форму підтримки

для відновлення доступу або вирішення проблем з обліковим записом. Ось як її знайти:
 
  1. Через додаток Telegram:
  • Зайдіть в Налаштування Задати питання.
  • Це відкриє чат із роботом підтримки Telegram.
 
  1. Через веб-сайт Telegram:
  • Перейдіть на офіційний сайт Telegram.
  • Виберіть Login and SMS issues або іншу категорію, пов'язану з проблемою.
  • Заповніть форму із зазначенням вашої проблеми, телефону та деталей.
 
  1. Безпосередньо по e-mail:
Якщо форма недоступна, можна написати лист на login@telegram.org, вказавши:
 
  • Ваш номер телефону (з кодом країни).
  • Опис проблеми.
  • Усі додаткові відомості, які допоможуть підтвердити вашу особу (наприклад, дату створення облікового запису).
 
Підтримка Telegram відповідає швидше, якщо ви надасте коректно всю інформацію.

Щоб перевірити надійність вашого паролю, скористайтеся сайтами:



bga68comp: (Default)
Терміни і визначення, які використовуються у ISO 27001:2022

У стандарті ISO/IEC 27001:2022 використовується низка термінів і визначень, які є ключовими для розуміння і впровадження системи управління інформаційною безпекою (СУІБ).

Стандарт ISO/IEC 27001:2022 містить детальний перелік термінів і визначень, які є критично важливими для розуміння вимог і ефективного впровадження системи управління інформаційною безпекою (СУІБ). Нижче наведено основні терміни та визначення, що використовуються у цьому стандарті:

Основні терміни та визначення в ISO/IEC 27001:2022:


  1. Актив (Asset): Ресурс або інформація, що має цінність для організації.
  2. Загроза (Threat): Потенційне джерело небезпеки для активу, яке може спричинити порушення інформаційної безпеки.
  3. Уразливість (Vulnerability): Слабке місце або недолік, яке може бути використане для реалізації загрози.
  4. Інцидент інформаційної безпеки (Information security incident): Подія або серія подій, які можуть призвести до порушення конфіденційності, цілісності або доступності активів.
  5. Ризик інформаційної безпеки (Information security risk): Поєднання ймовірності реалізації загрози та її наслідків для організації.
  6. Контроль (Control): Міра або механізм, що застосовується для зменшення ризиків або досягнення цілей інформаційної безпеки.
  7. Система управління інформаційною безпекою (СУІБ) (Information Security Management System, ISMS): Частина загальної системи управління, яка включає політики, процеси, процедури, рекомендації та ресурси, що використовуються для досягнення та підтримання інформаційної безпеки.
  8. Політика інформаційної безпеки (Information security policy): Документ, що визначає зобов’язання організації щодо інформаційної безпеки, її цілі та підходи до управління інформаційними активами.
  9. Актор загрози (Threat actor): Особа або організація, яка може здійснити загрозу, наприклад, зловмисник або природний фактор.
  10. Ризик (Risk): Вплив невизначеності на цілі, що може мати як позитивні, так і негативні наслідки.
  11. Захист даних (Data protection): Засоби та заходи, які організація застосовує для захисту інформаційних активів від несанкціонованого доступу, використання, розголошення, зміни або знищення.
  12. Конфіденційність (Confidentiality): Властивість забезпечення доступу до інформації лише тим особам, які мають на це право.
  13. Цілісність (Integrity): Властивість забезпечення точності, повноти та достовірності інформації.
  14. Доступність (Availability): Властивість інформаційних активів бути доступними для використання авторизованими особами у потрібний момент.
  15. Інформаційний актив (Information asset): Будь-яка інформація або ресурс, що має цінність для організації, включаючи електронні та паперові дані, програмне забезпечення, бази даних, системи та мережі.
  16. Оцінка ризиків (Risk assessment): Процес виявлення, аналізу і оцінки ризиків для інформаційних активів.
  17. Управління ризиками (Risk management): Процес визначення та застосування заходів для мінімізації, контролю або перенесення ризиків інформаційної безпеки.
  18. Залишковий ризик (Residual risk): Ризик, який залишається після застосування заходів контролю.
  19. Стороння організація (External party): Організація або особа, що не входить до структури компанії, але може взаємодіяти з її інформаційними активами.
  20. Аудит інформаційної безпеки (Information security audit): Незалежна перевірка та оцінка відповідності процесів і заходів інформаційної безпеки вимогам стандарту.
  21. Інформаційна безпека (Information security): Захист інформаційних активів від загроз, спрямованих на порушення їхньої конфіденційності, цілісності або доступності.
  22. Інформаційна система (Information system): Сукупність взаємозалежних компонентів, що використовуються для збору, обробки, зберігання та поширення інформації.
  23. Безперервність бізнесу (Business continuity): Здатність організації забезпечувати продовження критично важливих бізнес-функцій під час інцидентів.
  24. Шифрування (Encryption): Процес перетворення інформації у форму, недоступну для несанкціонованих користувачів.
  25. Управління доступом (Access control): Процедури і технології, які забезпечують доступ до інформаційних активів лише авторизованим користувачам.

Ці терміни є фундаментальними для розуміння підходів до управління інформаційною безпекою та забезпечення відповідності вимогам стандарту ISO/IEC 27001:2022.


bga68comp: (Default)

Приклад

Політика моніторингу та реагування на події інформаційної безпеки

1. Вступ

Ця політика визначає підходи до моніторингу інформаційної безпеки (ІБ) та реагування на події, пов'язані з безпекою, які можуть впливати на конфіденційність, цілісність та доступність інформаційних активів організації. Метою є забезпечення своєчасного виявлення, оцінки та реагування на потенційні загрози та інциденти.

2. Сфера дії

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

3. Визначення

  • Інцидент інформаційної безпеки - будь-яка подія, яка має або може мати негативний вплив на інформаційну безпеку організації.
  • Моніторинг інформаційної безпеки - процес безперервного спостереження за інформаційними системами та активами для виявлення ознак потенційних інцидентів.

4. Процедури моніторингу

4.1 Засоби моніторингу
Організація впроваджує та використовує засоби моніторингу для виявлення аномалій, загроз та інцидентів у реальному часі. До них відносяться:

  • Системи виявлення вторгнень (IDS/IPS);
  • Антивірусне програмне забезпечення;
  • Фаєрволи та системи контролю доступу;
  • Логування та аналіз журналів подій;
  • Моніторинг мережевого трафіку.

4.2 Оповіщення та сповіщення
В разі виявлення інциденту або аномалії, система моніторингу повинна автоматично генерувати оповіщення, які будуть негайно передані відповідальним особам для подальшого розгляду.

5. Процедури реагування

5.1 Класифікація інцидентів
Інциденти повинні бути класифіковані за рівнем критичності та впливу на бізнес-процеси. Класифікація визначає пріоритетність та порядок реагування.

5.2 Етапи реагування
  • Ідентифікація: Збір та аналіз інформації про інцидент.
  • Контейнування: Вжиття заходів для обмеження поширення інциденту.
  • Усунення: Відновлення нормальної роботи системи та усунення загроз.
  • Відновлення: Відновлення функціоналу систем після інциденту.
  • Аналіз: Оцінка інциденту та розробка рекомендацій для попередження подібних подій у майбутньому.

5.3 Звітність та документування
Усі інциденти повинні бути документовані. Включно з деталями про час, тип інциденту, дії, які були вжиті, та результати реагування. Розслідування та звітність повинні бути завершені якомога швидше після завершення реагування.

6. Ролі та відповідальність

6.1 Відповідальні особи
Кожен інцидент ІБ повинен мати призначеного відповідального, який забезпечує координацію дій та комунікацію з усіма зацікавленими сторонами.

6.2 Зовнішні партнери
У разі необхідності, організація може залучати зовнішніх фахівців для розслідування або реагування на інциденти.

7. Оцінка та вдосконалення

7.1 Періодичний огляд
Ця політика підлягає регулярному перегляду та вдосконаленню з урахуванням нових загроз та змін в ІТ-інфраструктурі.

7.2 Навчання та підготовка
Всі співробітники, відповідальні за реагування на інциденти, повинні проходити регулярне навчання та підготовку з питань ІБ.

8. Дотримання політики

Невиконання положень цієї політики може призвести до дисциплінарних заходів, включаючи звільнення.



bga68comp: (Default)
Оригинал: http://ko.com.ua/v_deloitte_vzlomana_vsya_korporativnaya_e-mail...

В Deloitte взломана вся корпоративная e-mail и аккаунты администраторов

 
В Deloitte взломана вся корпоративная e-mail и аккаунты администраторов

Компания Deloitte (Deloitte Touche Tohmatsu Limited), входящая в «большую четвёрку» крупнейших в мире фирм, оказывающих бухгалтерские и консалтинговые услуги, подтвердила информацию о взломе её внутренней электронной почты. При этом было заявлено, что от данного инцидента пострадало «совсем немного» клиентов.

Британская Guardian оспорила это утверждение Deloitte в своей вчерашней публикации. По сведениям из кругов, близких к ведущемуся расследованию, проблемы с безопасностью электронной корреспонденции Deloitte восходят ещё к осени прошлого года. Причём, речь идёт о взломе всех администраторских учётных записей и внутренней системы e-mail целиком, получении хакерами паролей, имён и персональных данных важнейших клиентов компании.

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

Ситуацию осложняет отсутствие полной уверенности, что внутренняя сеть Deloitte стала полностью безопасной.

Не вызывает сомнений, что Deloitte уже какое-то время подозревала о существовании проблемы. Все её сотрудники в США 13 октября 2016 г. получили письмо с распоряжением произвести обязательный сброс пароля в 5-дневный срок с заменой его на более сложный.

Однако клиенты консультационных и кибер-аналитических сервисов Deloitte, включая такие организации, как CSAA Insurance, FedEx, Invesco и St. Joseph’s Healthcare System, по утверждению источника, до последнего времени и не были поставлены в известность о возможных рисках. Хотя сама Deloitte сообщает, что уведомила шесть пострадавших клиентов, она отказывается комментировать когда это было сделано.

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


bga68comp: (Default)




Большая советская энциклопедия.
Инцидент (от лат. incidens, родительный падеж incidentis — случающийся) случай, происшествие (обычно неприятное), недоразумение, столкновение. Большая советская энциклопедия. — М.: Советская энциклопедия. 1969—1978.

ISO/IEC TR 18044:2004
инцидент информационной безопасности (information security incident): одно или серия нежелательных или неожиданных событий информационной безопасности, которые имеют значительную вероятность компрометации бизнес-операции и угрожают информационной безопасности.


bga68comp: (Default)
Реагирование на инциденты информационной безопасности

July 25, 2014 Vladimir Bezmaly IT-Security

https://www.it-community.in.ua/2014/07/reagirovanie-na-intsidenty-informatsionnoj-bezopasnosti.html/

Сегодня большой популярностью пользуется тема реагирования на инциденты информационной безопасности (ИБ). С одной стороны – тема весьма популярна, с другой – она покрыта завесой тайны, ведь именно во время расследования проявляются конкретные уязвимости системы, обнаруживаются следы атак, проверяется квалификация сотрудников ИБ, качество построения системы ИБ.

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

Попробуем кратко перечислить, что же требуется от специалиста подобного рода:
  1. понимание принципов безопасности;
  2. знания о слабостях и уязвимостях информационных объектов;
  3. представление об устройстве Интернет;
  4. навыки анализа информационных рисков;
  5. знание сетевых протоколов;
  6. знание сетевых приложений и сервисов;
  7. владение вопросами сетевой безопасности;
  8. владение вопросами безопасности узла или системы; 
  9. знание о вредоносных программах (вирусы, черви, трояны); 
  10. навыки программирования.

На Украине существует целый ряд серьезнейших проблем в этой области:
  1. нет единого центра регистрации инцидентов;
  2. отсутствует статистика инцидентов;
  3. отстает законодательство;
  4. нет открытых методик и стандартов организации процесса реагирования и расследования инцидентов ИБ;
  5. неясно, как можно подготовиться к такого рода событиям;
  6. не определено, какие превентивные меры стоит предпринять;
  7. отстает подготовка сотрудников правоохранительных органов.

За рубежом, в свою очередь, существуют стандарты, которые описывают процесс реагирования на компьютерные инциденты. В первую очередь это стандарт NIST Special Publication 800-61 “Computer security incident handling guide”. К слову, новая версия ISO 17799:2005 требует наличия процесса реагирования на инциденты (раздел 13 – “Information security incident management”).

Попробуем коротко рассмотреть основные составляющие процесса реагирования на инцидент.

Что такое инцидент ИБ?

Инцидент, согласно требований IT Infrastructure Library (ITIL), – любое событие, не являющееся частью нормальной работы услуги и ведущее или способное привести к остановке или потере уровня качества этой услуги.

Согласно ISO/IEC TR 18044:2004 инцидент информационной безопасности (information security incident): одно или серия нежелательных или неожиданных событий информационной безопасности, которые имеют значительную вероятность компрометации бизнес-операции и угрожают информационной безопасности.
Read more... )

Profile

bga68comp: (Default)
bga68comp

June 2025

S M T W T F S
123 4567
8 91011121314
15161718192021
22232425262728
2930     

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated 2025-06-25 03:30
Powered by Dreamwidth Studios