bga68comp | Entries tagged with информационная безопасность

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

🪟 На стартову сторінку

Питання:
— 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 ночі з іншої країни"

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

Події (events) →
Журнали (logs) →
Обробка (normalization) →
Кореляція (correlation rules) →
Створення alert-ів (за певними умовами)

🔎 Приклад:

Подія: "10 невдалих логінів поспіль".
Подія: "Потім один успішний логін з іншого регіону".
Alert: "Можливе brute-force проникнення → реагувати!"

🔧 Підсумок:

Подія — це факт.
Alert — це висновок SIEM, що цей факт (або комбінація фактів) може свідчити про інцидент.

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

🪟 На стартову сторінку

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

🪟 На стартову сторінку

Фінтех та ISO 27001: стандарти безпеки для захисту даних і репутації

Volodymyr Tkachenko
https://youtu.be/9bAWTnkpW2U?t=18511

Director/CEO at Active audit agency, LLCDirector/CEO at Active audit agency, LLC
• 8 квітня 2025 • CEO Audit3A

Watch on YouTube

CEO Audit3A Volodymyr Tkachenko:

🔐 Кібербезпека — це не про страх, а про довіру.
8 квітня 2025 року я мав честь виступити на Digital Banking & Fintech Forum 2025, де ми говорили про найважливіше: як захистити дані, зберегти репутацію та не загубитися в морі регуляторних вимог.
📣 Моя тема — «Фінтех та ISO 27001: стандарти безпеки для захисту даних і репутації».
Ми занурилися у практику:
— Як впровадження ISO 27001 допомагає компаніям системно керувати ризиками.
— Чому кібербезпека стала конкурентною перевагою №1 у фінансовій сфері.
— Які виклики постають перед фінтех-компаніями у 2025 році — і як їх подолати.
💬 Вдячний організаторам за можливість бути частиною цієї події, а колегам — за діалог, питання і щире зацікавлення.
✅ Якщо ви — fintech, банк або регульований бізнес і хочете дізнатися, з чого почати свій шлях до ISO 27001 або покращити чинну систему інформаційної безпеки — запрошую на консультацію:
🌐 audit3a.com
🌐 pecb.com — міжнародний сертифікаційний орган, з яким ми активно співпрацюємо.
Кібербезпека — це не розкіш, а відповідальність.
Радо допоможемо зробити її зрозумілою, ефективною та результативною.

🪟 На стартову сторінку

60 сценаріїв викрадення інформації або несанкціонованого доступу (НСД) під час використання:

особистих пристроїв (ноутбук, телефон),
корпоративного VPN,
доступу через RDP over SSL/TLS,
корпоративного ноутбука за периметром мережі,
використання хмарних сервісів (OneDrive, SharePoint, Teams, Dropbox тощо).

🔒 1. Через особисті пристрої (BYOD)

1.1. Встановлений шкідливий додаток на телефоні отримує доступ до робочих файлів.
1.2. Ненадійне підключення Wi-Fi перехоплює трафік до корпоративних сервісів.
1.3. Витік VPN-трафіку через DNS-leak або WebRTC-leak.
1.4. Залишений без нагляду телефон з активним VPN.
1.5. Root/jailbreak дозволяє шкідливому ПЗ доступ до системних API.
1.6. Перехоплення clipboard на пристрої (копіювання пароля/токена).
1.7. Зламаний браузер на телефоні краде cookie до корпоративного порталу.
1.8. Витік з месенджера з доступом до корпоративних чатів.
1.9. Несанкціоноване створення резервних копій у сторонні хмари (Google Drive, iCloud).
1.10. Автоматична синхронізація робочих документів на особистий обліковий запис MS Office.

🖥 2. Через RDP over SSL/TLS (дистанційний робочий стіл)

2.1. Витік облікових даних через фішинговий RDP-клієнт.
2.2. Недостатній контроль сесії — сеанс не завершується автоматично.
2.3. Перехоплення трафіку через MITM на зараженому Wi-Fi.
2.4. Сесія записується зловмисником на зараженому хості.
2.5. Вбудовані в буфер обміну дані (clipboard injection).
2.6. Завантаження шкідливих файлів через відкритий mapped диск.
2.7. Доступ до внутрішньої мережі компанії без MFA.
2.8. Вразливість у протоколі RDP або TLS-налаштуваннях.
2.9. Крадіжка знімків екрану через шпигунське ПЗ.
2.10. Несанкціоноване збереження файлів із корпоративного середовища на локальний диск.

🧳 3. З корпоративного ноутбука за периметром мережі компанії

3.1. Підключення до відкритого Wi-Fi без VPN.
3.2. Автоматичне підключення до підробленої мережі (Evil Twin).
3.3. Підключення до зараженого USB (маус, флешка, зарядка).
3.4. Несанкціоноване встановлення стороннього ПЗ.
3.5. Встановлення браузерного розширення-шпигуна.
3.6. Недостатній захист BitLocker або FileVault (відсутність PIN).
3.7. Неоновлена ОС дозволяє експлуатацію CVE-уразливостей.
3.8. Вивантаження робочих документів на особистий Gmail/Dropbox.
3.9. Крадіжка ноутбука в транспорті — диск не зашифрований.
3.10. Використання одного пароля до корпоративного і особистого облікового запису.

☁ 4. Через хмарні сервіси (OneDrive, SharePoint, Teams, Dropbox тощо)

4.1. Ненавмисне надання загального доступу до файлу (public link).
4.2. Запрошення сторонніх користувачів у Teams-канал.
4.3. Використання особистого Dropbox замість корпоративного.
4.4. Неконтрольоване завантаження файлів у OneDrive.
4.5. Шкідливе вкладення в чаті Teams, що запускає скрипт.
4.6. Витік токенів OAuth у логах браузера.
4.7. Використання ботів або розширень до Teams із доступом до даних.
4.8. Неавторизований співробітник має доступ до конфіденційних папок SharePoint.
4.9. Зміна налаштувань спільного доступу без затвердження адміністратором.
4.10. Фішинг через підроблений інтерфейс входу Microsoft 365.

🔓 5. Помилки користувача та фішинг

5.1. Натискання на фішингове посилання у робочій пошті.
5.2. Відправка конфіденційного документа через Telegram замість Outlook.
5.3. Поширення скріншоту робочого екрана з відкритими даними.
5.4. Копіювання пароля у відкритий блокнот.
5.5. Використання публічних комп’ютерів для доступу до OneDrive.
5.6. Автозаповнення браузера вставляє корпоративний пароль у фішингову форму.
5.7. Зберігання токенів VPN/Teams у текстовому файлі.
5.8. Перенесення файлу з корпоративного облікового запису в особистий Google Docs.
5.9. Використання загального сімейного пристрою для входу у корпоративний обліковий запис.
5.10. Примусове оновлення пароля за фішинговим листом від "адміністратора".

💼 6. Інсайдерські загрози і людський фактор

6.1. Звільнений співробітник не позбавлений доступу до Teams.
6.2. Співробітник навмисно завантажує дані в особисту хмару.
6.3. Обхід політик DLP через зашифровані ZIP-архіви.
6.4. Встановлення TeamViewer або AnyDesk без дозволу.
6.5. Використання Telegram Bot API для автоматичного витоку.
6.6. Зйомка робочого екрану на телефон і пересилка у месенджері.
6.7. Вивантаження бази даних через SQL-запит у Excel і збереження в OneDrive.
6.8. Завантаження PowerShell-скриптів на корпоративний хост із зовнішнього ресурсу.
6.9. Співробітник використовує чат GPT або подібне ПЗ для обробки службової інформації.
6.10. Співробітник відкриває файли з вірусами "щоб подивитись що буде".

🪟 На стартову сторінку

Коли ти ще робиш каву з ранку, хакер вже перейменував твій сервер у “Дмитро”

8 квітня у Великій Британії вийшов новий гайд для керівників — не страшний, не технічний, а про те, як "не вляпатись" в новини як "та компанія, яку зламали".

Його назва:
Кодекс кіберуправління для директорів

Навіщо це вам?

Кібербезпека — це не технічне питання, а частина управління бізнесом.
Керівники мають бути в темі, хоча б на рівні “знати, куди дивитися”.

Що ж рекомендують британці:

– Мати план на випадок кібератаки.
– Слідкувати, щоб усе критичне оновлювалося.
– Не давати фішингу шансу (бо він любить Excel).

Де глянути?

Безкоштовно, офіційно, англійською:

📄 Cyber Governance Code of Practice – gov.uk (PDF)

Для тих, хто дуже зайнятий — нижче коротка листівка. Роздрукуйте її.
Хоч лісів і мало — але хай муляє очі, щоб не клікали куди не треба.

🪟 На стартову сторінку

Кодекс практики з кіберуправління (Cyber Governance Code of Practice) — це новий документ, опублікований урядом Великої Британії 8 квітня 2025 року. Він надає керівництву компаній та директорам рекомендації щодо ефективного управління кіберризиками та захисту своїх організацій від кібератак.

Кодекс кіберуправління — коротко

A: Управління ризиками

Дія 1	Отримайте впевненість, що технології, процеси, інформація та сервіси, критично важливі для досягнення цілей організації, ідентифіковані, пріоритетизовані та погоджені.
Дія 2	Узгодьте відповідального за кіберризики на рівні керівництва та впевніться, що вони інтегровані в загальне управління ризиками та внутрішній контроль.
Дія 3	Визначте та чітко донесіть рівень прийнятного кіберризику, а також переконайтесь, що існує план дій для дотримання цих меж.
Дія 4	Отримайте впевненість, що інформація про постачальників регулярно оцінюється відповідно до рівня ризику, і що організація стійка до ризиків у ланцюгу постачання.
Дія 5	Переконайтесь, що оцінки ризиків проводяться регулярно та враховують зміни в технологіях, регуляторних вимогах та загрозах.

B: Стратегія

Дія 1	Переконайтесь, що в організації розроблено кіберстратегію, яка узгоджена з загальною стратегією компанії.
Дія 2	Переконайтесь, що кіберстратегія відповідає визначеному рівню прийнятного ризику, регуляторним вимогам і змінам у середовищі (див. A3, A5).
Дія 3	Переконайтесь, що ресурси розподілені ефективно для управління кіберризиками.
Дія 4	Переконайтесь, що кіберстратегія впроваджується ефективно і досягає очікуваних результатів.

C: Люди

Дія 1	Сприяйте формуванню культури кібербезпеки з позитивними поведінковими моделями та відповідальністю — на всіх рівнях.
Дія 2	Переконайтесь, що існують чіткі політики, які підтримують цю культуру.
Дія 3	Пройдіть навчання для підвищення власної обізнаності та візьміть відповідальність за безпеку своїх цифрових активів.
Дія 4	Перевірте наявність ефективної програми навчання та обізнаності, заснованої на відповідних метриках.

D: Планування інцидентів, реагування і відновлення

Дія 1	Переконайтесь, що організація має план реагування та відновлення у разі кіберінциденту, що зачіпає критичні сервіси.
Дія 2	Щонайменше раз на рік проводьте тестування цього плану з залученням ключових внутрішніх і зовнішніх сторін.
Дія 3	У разі інциденту — виконуйте власні обов’язки щодо звітності та беріть участь у прийнятті рішень.
Дія 4	Переконайтесь, що існує процес аналізу інцидентів із врахуванням уроків для подальших оцінок ризиків та оновлення планів.

E: Контроль і нагляд

Дія 1	Створіть структуру кіберуправління, інтегровану у загальну структуру управління компанії, з чітким розподілом ролей та відповідальності.
Дія 2	Встановіть формальну звітність (не рідше ніж щоквартально), чіткі метрики та допустимі межі ризику.
Дія 3	Підтримуйте постійний двосторонній діалог із ключовими керівниками, включно з CISO (або аналогічною особою).
Дія 4	Переконайтесь, що кібербезпека інтегрована з внутрішнім/зовнішнім аудитом та системами контролю.
Дія 5	Забезпечте обізнаність керівників щодо нормативних вимог та кращих практик.

Де його завантажити?
Безкоштовно, офіційно:
gov.uk/cyber-governance

🔞 На стартову сторінку

Information Security Network •
Sofiyan Rizawi •

• Information Security Network

🪟 На стартову сторінку

Акронім AAA:

Використовується для позначення автентифікації, авторизації та обліку різноманітних сервісів (англ. authentication, authorization, accounting, AAA)

Див. також:

🪟 На стартову сторінку

"A Survey of Security Tools for the Industrial Control System Environment" — це звіт, підготовлений Національною лабораторією Айдахо (INL), який детально описує результати опитування щодо існуючих інструментів, які можуть бути використані для запобігання, виявлення, пом'якшення або розслідування кібератак у середовищі промислових систем управління (ICS). У звіті зібрано перелік потенційно застосовних інструментів та показано їх охоплення в архітектурі ICS.

Промислові системи управління включають такі конфігурації, як системи SCADA, розподілені системи управління (DCS) та інші, які часто використовуються в промислових секторах та критично важливій інфраструктурі, таких як електростанції, водоочисні споруди, виробництво та системи розподілу. З розвитком технологій та інтеграцією ICS з інформаційними технологіями (ІТ), такими як хмарні обчислення, ці системи стали більш вразливими до кібератак. Звіт INL допомагає зрозуміти, які інструменти доступні для забезпечення безпеки ICS та як вони можуть бути інтегровані в існуючі архітектури для підвищення захисту від потенційних загроз.

Джерело:

A Survey of Security Tools for the Industrial Control System Environment

ACRONYMS

BOM	bill of materials
CERT	computer emergency response team
CVE	common vulnerabilities and exposures
GPL	general public license
GUI	graphical user interface
HIDS	host-based intrusion detection system
HMI	human machine interface
ICS	industrial control system
IDS	intrusion detection system
IED	intelligent electronic device
INL I/O IOC	Idaho National Laboratoryinput/outputindicator of compromise
IP	internet protocol
IPS	intrusion prevention system
IT	information technology
LAN	local area network
LR	log review
NIDS	network-based intrusion detection system
NSM	network security monitoring
NTAD	network traffic anomaly detection
OA	outlier analysis
OT	operational technology
OS	operating system
OSI	open system interconnection
PLC	programmable logic controller
RE	reverse engineering
RTU	remote terminal unit
SAR	system artifact review
SCADA	supervisory control and data acquisition
SIEM	security information and event management
SME	subject matter expert

Акроніми

BOM – специфікація матеріалів (bill of materials)
CERT – команда реагування на комп’ютерні надзвичайні ситуації (computer emergency response team)
CVE – загальні вразливості та експлойти (common vulnerabilities and exposures)
GPL – загальна публічна ліцензія (general public license)
GUI – графічний інтерфейс користувача (graphical user interface)
HIDS – система виявлення вторгнень на рівні хоста (host-based intrusion detection system)
HMI – людино-машинний інтерфейс (human machine interface)
ICS – система управління виробництвом (industrial control system)
IDS – система виявлення вторгнень (intrusion detection system)
IED – інтелектуальний електронний пристрій (intelligent electronic device)
INL I/O IOC – Національна лабораторія Айдахо / вхід-вихід / індикатор компрометації (Idaho National Laboratory input/output indicator of compromise)
IP – інтернет-протокол (internet protocol)
IPS – система запобігання вторгненням (intrusion prevention system)
IT – інформаційні технології (information technology)
LAN – локальна обчислювальна мережа (local area network)
LR – перегляд журналів (log review)
NIDS – мережева система виявлення вторгнень (network-based intrusion detection system)
NSM – моніторинг безпеки мережі (network security monitoring)
NTAD – виявлення аномального мережевого трафіку (network traffic anomaly detection)
OA – аналіз аномальних даних (outlier analysis)
OT – операційні технології (operational technology)
OS – операційна система (operating system)
OSI – модель взаємозв’язку відкритих систем (open system interconnection)
PLC – програмований логічний контролер (programmable logic controller)
RE – зворотна інженерія (reverse engineering)
RTU – віддалений термінальний пристрій (remote terminal unit)
SAR – аналіз артефактів системи (system artifact review)
SCADA – система диспетчерського управління і збору даних (supervisory control and data acquisition)
SIEM – управління інформацією та подіями безпеки (security information and event management)
SME – експерт з конкретної галузі (subject matter expert)

Архітектура системи управління виробництвом (Industrial Control System, ICS)

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

Основні компоненти ICS

ICS складається з декількох ключових елементів:

Контролери промислової автоматики (PLC, DCS, RTU) – програмовані логічні контролери (PLC), розподілені системи управління (DCS) та віддалені термінальні пристрої (RTU) виконують основні функції збору даних і управління.
Людино-машинний інтерфейс (HMI) – надає операторам зручний спосіб взаємодії з системою.
SCADA-системи (Supervisory Control and Data Acquisition) – системи централізованого моніторингу та управління.
Промислові мережі – спеціалізовані протоколи для обміну даними, такі як Modbus, DNP3, Ethernet/IP, PROFINET.
Сервери управління та бази даних – використовуються для збереження та аналізу інформації.
Пристрої кінцевого рівня (датчики, виконавчі механізми) – безпосередньо взаємодіють із фізичними процесами.

Основні рівні архітектури ICS

Рівень фізичних пристроїв – включає датчики, реле, електродвигуни, клапани тощо.
Рівень контролерів (PLC, RTU) – забезпечує збір і обробку даних від датчиків, передає команди на пристрої.
Рівень SCADA та DCS – здійснює контроль за всією системою.
Рівень управління підприємством (MES, ERP) – системи управління виробництвом та бізнес-процесами.
Рівень корпоративних ІТ-систем – взаємодія ICS із загальною інформаційною інфраструктурою компанії.

Виклики безпеки ICS

ICS піддаються численним кіберзагрозам, зокрема:

Використання застарілого обладнання та програмного забезпечення.
Відсутність механізмів автентифікації та шифрування в промислових мережах.
Вплив шкідливих програм (наприклад, Stuxnet).
Фізичний доступ до критичних елементів системи.

Способи підвищення безпеки ICS

Сегментація мережі (розділення IT- та OT-систем).
Впровадження контролю доступу.
Використання механізмів аномального моніторингу.
Регулярні оновлення та патчі для ПЗ.

Джерело:

Cisco Hybrid Cloud Industrial DMZ White Paper :

Промислова демілітаризована зона (iDMZ) є критично важливим рівнем у комплексній стратегії наскрізної безпеки для середовища промислових операцій.

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

1. Корпоративна зона описує завод або середовища, керовані IT, включаючи корпоративні центри обробки даних, локальну мережу, глобальну мережу та хостинг бізнес-додатків.

2. Промислова демілітаризована зона (IDMZ) є буфером між критичними середовищами або системами виробничих цехів і мережею підприємства. Всі спільні послуги між промисловою зоною і зоною підприємства будуть розташовані на ІДМЗ.

3. Зона промислової безпеки є домом для критично важливих операційних систем, включаючи зону стільникового/зонального зв'язку, де зв'язок відбувається часто та з низькою затримкою або в режимі реального часу. Оскільки цей документ в основному стосується IDMZ, ми пропустимо детальне покриття зони cell/area.

🪟 На стартову сторінку

Компанія Fortinet надає можливість потицяти у демо-режимі свою SIEM-систему. Для цього треба тільки зареєструватися. Демо-режим означає, що система працює у режимі читання і тільки. Цього для першого знайомства достатньо.

164538

Посилання:
→ https://www.fortinet.com/demo-center/fortisiem-demo

p.s. Але якщо треба щось більше ніж просто подивитись на інтерфейс системи, то можливо заказати лабораторні роботи і пройти декілька стандартних сценаріїв у FortiSIEM.

Для цього вже треба звернутися до Fortinet і знайти людину, яка відповідає за вашу країну

→

👩‍💻

🪟 На стартову сторінку

CyberArk – інтелектуальний захист користувачів та їх пристроїв

Watch on YouTube

У ПРОГРАМІ ВОРКШОПУ:
Як CyberArk допомагає запобігти компрометації облікових записів та доступів в умовах складних кібератак.
Як платформи CyberArk забезпечують інтелектуальний захист кінцевих пристроїв та користувачів, аналізуючи їхню поведінку в реальному часі.
Практичні приклади впровадження та успішного використання рішень CyberArk для захисту користувачів та бізнесу від кіберзагроз.

🪟 На стартову сторінку

Вимоги, що підсилюють захист DMZ у разі використання хмарних рішень, зокрема при роботі з персональними даними та інфраструктурою як послугою (IaaS).

Вимога	Опис	Посилання на стандарт або нормативний акт
1. Сегментація мережі	Мережеві сегменти повинні бути чітко відокремлені, з обмеженим доступом між внутрішньою мережею, DMZ-зоною та Інтернетом.	ISO 27001:2022, A.13.1.3; PCI DSS v4.0, п. 1.2.1; НБУ Постанова №75
2. Контроль доступу до ресурсів	Впровадження суворих правил контролю доступу до серверів у DMZ на основі ролей, мінімізації прав доступу.	ISO 27002:2022, 9.4.3; PCI DSS v4.0, п. 7.2; Закон України "Про захист персональних даних"
3. Аутентифікація та авторизація	Використання двофакторної аутентифікації для адміністраторів та всіх, хто має доступ до критичних ресурсів у DMZ.	ISO 27002:2022, 9.4.2; PCI DSS v4.0, п. 8.3; НБУ Постанова №43
4. Логування і моніторинг	Всі події у DMZ повинні бути автоматично записані в журнали, зберігатися і періодично перевірятися.	ISO 27001:2022, A.12.4.1; PCI DSS v4.0, п. 10.1; НБУ Постанова №217
5. Оцінка ризиків	Проводити регулярну оцінку ризиків для визначення загроз у DMZ, включаючи вразливості нових технологій.	ISO 27005:2022, п. 5.4; ISO 31000:2018, п. 6.3; COBIT 2019, EDM03
6. Захист від шкідливого ПЗ	Установити системи захисту від шкідливого ПЗ на всіх серверах і мережевих пристроях у DMZ.	ISO 27001:2022, A.12.2.1; PCI DSS v4.0, п. 5.1; НБУ Постанова №95
7. Регулярні оновлення і патчі	Оновлення програмного забезпечення та систем безпеки в DMZ повинні проводитися регулярно для захисту від нових загроз.	ISO 27002:2022, 12.5.1; PCI DSS v4.0, п. 6.2; Кращі практики Cisco, Microsoft
8. Процедури аварійного відновлення	Впровадження та тестування планів аварійного відновлення для серверів і пристроїв у DMZ.	ISO 27001:2022, A.17.1.2; PCI DSS v4.0, п. 11.1; НБУ Постанова №243
9. Оцінка ефективності заходів безпеки	Регулярно проводити аудит безпеки та тестування заходів захисту DMZ для забезпечення їх ефективності.	ISO 27001:2022, A.18.2.3; PCI DSS v4.0, п. 12.11; ТОGAF 10, ADM
10. Виявлення і реагування на інциденти	Необхідно впровадити системи для автоматичного виявлення і швидкого реагування на інциденти безпеки в DMZ.	ISO 27002:2022, 16.1.1; PCI DSS v4.0, п. 12.5; НБУ Постанова №65
11. Безпека в хмарних середовищах	При розгортанні DMZ у хмарі необхідно враховувати відповідальність між хмарним провайдером та клієнтом за захист інфраструктури. Важливо чітко розмежувати зони відповідальності.	ISO/IEC 27017:2015, п. 5.1
12. Контроль доступу до хмарних ресурсів	Всі адміністратори і користувачі з доступом до хмарних ресурсів, пов'язаних з DMZ, повинні мати відповідні ролі і права, з акцентом на мінімізацію прав доступу.	ISO/IEC 27017:2015, п. 9.4
13. Захист персональних даних у хмарі	Якщо DMZ обробляє персональні дані, необхідно застосовувати додаткові заходи для захисту таких даних, зокрема шифрування та контроль доступу.	ISO/IEC 27018:2019, п. 4.1; Закон України "Про захист персональних даних"
14. Шифрування даних у хмарі	Всі дані, які передаються через DMZ в хмарних середовищах, повинні бути зашифровані на рівні мережевих передач та зберігання.	ISO/IEC 27018:2019, п. 5.2.1
15. Виявлення та реагування на інциденти у хмарі	Необхідно забезпечити наявність інструментів для виявлення інцидентів безпеки в хмарному середовищі, зокрема в зоні DMZ, та швидке реагування на них.	ISO/IEC 27017:2015, п. 16.1
16. Моніторинг та аудит хмарних середовищ	Регулярний моніторинг подій у DMZ та хмарі має проводитися для оцінки ефективності заходів безпеки, зокрема в межах процесу аудиту.	ISO/IEC 27017:2015, п. 12.4
17. Інформування про інциденти з персональними даними	У разі виявлення інцидентів, пов'язаних з персональними даними у DMZ, необхідно мати механізми для швидкого інформування про це відповідальних осіб.	ISO/IEC 27018:2019, п. 9.1

Примітки:

ISO/IEC 27017:2015 надає додаткові рекомендації щодо безпеки в хмарних середовищах, зокрема для забезпечення безпеки DMZ в хмарі.
ISO/IEC 27018:2019 фокусується на захисті персональних даних, що є критичним при обробці таких даних у хмарних інфраструктурах.

Примітки:

Посилання на конкретні пункти стандартів та нормативних актів надають рекомендації для впровадження вимог.
Кращі практики Cisco, Fortinet, Microsoft враховують методи захисту мережевого периметру, управління доступом та хмарних інфраструктур.

Кращі практики Cisco:

Cisco Safe Architecture:
- Розподіл мережевих зон: Рекомендується чітко відокремлювати критичні ресурси (внутрішня мережа) від зовнішніх (Інтернет) за допомогою DMZ. Роль DMZ — забезпечити захищений шлюз для публічно доступних ресурсів.
  - Джерело: Cisco SAFE Design Guide.
Cisco Next-Generation Firewalls (NGFW):
- Додаткові механізми захисту: Використання систем глибокого аналізу трафіку, виявлення вторгнень (IDS/IPS) та фільтрації шкідливого ПЗ у трафіку через DMZ.
  - Джерело: Cisco Firepower NGFW Best Practices.
Сегментація за допомогою ACL (Access Control Lists):
- Контроль доступу між зонами: Використання ACL для точного контролю доступу між різними мережевими зонами, такими як внутрішня мережа, DMZ та Інтернет.
  - Джерело: Cisco ASA Firewall Configuration Guide.

Кращі практики Fortinet:

Fortinet Security Fabric:
- Інтегрований моніторинг та видимість: Використання платформи для централізованого управління та моніторингу мережевих пристроїв у різних зонах, включаючи DMZ, для швидкого виявлення та реагування на загрози.
  - Джерело: Fortinet Security Fabric Best Practices.
FortiGate Firewall:
- Застосування політик безпеки: Використання гнучких політик безпеки для контролю трафіку в DMZ з акцентом на мінімізацію доступу до внутрішньої мережі та використання зон захисту для різних рівнів сегментації.
  - Джерело: FortiGate NGFW Best Practices.
Захист від DDoS-атак:
- Фільтрація та захист DMZ від DDoS-атак: Використання технологій Fortinet для виявлення та блокування атак на рівні DMZ, щоб запобігти перевантаженню серверів і доступних з Інтернету ресурсів.
  - Джерело: Fortinet DDoS Protection Best Practices.

Кращі практики Microsoft:

Azure Security Center:
- Моніторинг та реагування в хмарних середовищах: У разі розгортання ресурсів у хмарі Microsoft рекомендує інтеграцію DMZ з Azure Security Center для проактивного виявлення загроз та управління вразливостями.
  - Джерело: Microsoft Azure Security Center Best Practices.
Active Directory (AD) та Azure AD:
- Управління доступом через AD: Використання ролей та груп доступу для чіткого контролю, хто має права на доступ до ресурсів у DMZ. Рекомендується використовувати двофакторну аутентифікацію (MFA) для додаткового захисту.
  - Джерело: Microsoft AD Security Best Practices.
Windows Defender Advanced Threat Protection (ATP):
- Виявлення загроз і захист від шкідливого ПЗ: Впровадження Windows Defender ATP на серверах у DMZ для виявлення та блокування потенційних загроз на основі поведінкових аналізів і захисту в реальному часі.
  - Джерело: Microsoft Windows Defender ATP Best Practices.

🪟 На стартову сторінку

Щоб впроваджувати безпечні, надійні та ефективні хмарні сервіси, а також управляти ними відповідно до міжнародних вимог та кращих практик, нижче наведений перелік основних стандартів ISO/IEC:

1. ISO/IEC 17788:2014 — Інформаційні технології – Хмарні обчислення – Огляд та словник

Цей стандарт надає визначення ключових понять хмарних обчислень, таких як моделі надання послуг (SaaS, PaaS, IaaS) та моделі розгортання (публічна, приватна, гібридна хмара). Він забезпечує єдину термінологію для розробників і користувачів хмарних рішень.

2. ISO/IEC 17789:2014 — Архітектура хмарних обчислень

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

3. ISO/IEC 27017:2015 — Інформаційні технології – Методи забезпечення безпеки – Керівництво з безпеки для хмарних обчислень

Цей стандарт надає рекомендації щодо захисту інформації у хмарних середовищах, зокрема щодо конфіденційності, доступу до даних та управління ризиками.

4. ISO/IEC 27018:2019 — Захист персональних даних у хмарних обчисленнях

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

5. ISO/IEC 19086 — Угоди про рівень надання послуг (SLA) для хмарних обчислень

Частина 1: Загальні концепції та структура — визначає загальні принципи створення та управління SLA.
Частина 2: Метрики рівня обслуговування — надає інструкції щодо метрик, які використовуються для оцінки якості хмарних сервісів.
Частина 3: Основні вимоги до SLA — описує основні вимоги, яким повинні відповідати SLA.
Частина 4: Метрики безпеки — описує метрики, що пов'язані із забезпеченням безпеки в угодах SLA.

6. ISO/IEC 27001 — Система управління інформаційною безпекою (ISMS)

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

7. ISO/IEC 38500 — Корпоративне управління ІТ

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

🪟 На стартову сторінку

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

MITRE ATT&CK та MITRE D3FEND — це два різні, але взаємопов'язані фреймворки, створені для аналізу кіберзагроз і захисту від них. Вони мають різні цілі, і їхні ключові відмінності можна описати так:

1. MITRE ATT&CK

Мета: Описує дії зловмисників. ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) — це таксономія тактик і технік, які використовують атакуючі на різних етапах кібератак.
Зміст: ATT&CK містить тактики (наприклад, початок атаки, підтримання доступу, ексфільтрація даних) та техніки (конкретні методи, такі як фішинг або використання шкідливого ПЗ), що допомагають досягати цих тактик.
Структура: ATT&CK представлений у вигляді матриці, де стовпці — це тактики, а рядки — техніки атак.
Застосування: ATT&CK використовується для моделювання атак і аналізу вже здійснених атак, щоб зрозуміти, які тактики і техніки були використані. Це допомагає організаціям передбачити наступні кроки атакуючих і посилити захисні заходи.

2. MITRE D3FEND

Мета: Описує захисні контрзаходи. D3FEND — це фреймворк, який зосереджений на методах захисту від атак, що протистоять технікам, описаним у ATT&CK.
Зміст: D3FEND класифікує методи захисту (наприклад, моніторинг мережі, аналіз поведінки, контроль доступу) і прив'язує їх до конкретних технік атак із ATT&CK.
Структура: D3FEND також має структуру таксономії захисних дій, згрупованих за категоріями (виявлення, запобігання, блокування) і пов'язаних з конкретними техніками атак.
Застосування: D3FEND використовується для розробки і аналізу захисних заходів в організації, допомагаючи визначити, які техніки можуть допомогти запобігти або пом'якшити дії зловмисників, описані в ATT&CK.

Основні відмінності

Фокус: ATT&CK описує дії атакуючих, тоді як D3FEND зосереджується на захисних заходах.
Структура: ATT&CK — це матриця технік атак, а D3FEND — карта захисних дій.
Застосування: ATT&CK корисний для моделювання і аналізу загроз, а D3FEND — для розробки тактик захисту і їх зіставлення з техніками атак.

Примітка

D3FEND — це ініціатива, розроблена Агентством національної безпеки США (NSA) у співпраці з MITRE для покращення захисту кіберпростору. Назва є комбінацією слова "defend" (захищати) та цифри "3", яка символізує фокус на тристоронню взаємодію між технологіями, методами захисту та архітектурними рішеннями в кібербезпеці.

D3FEND слугує таксономією та базою знань для методів захисту від кібератак. Вона підтримує MITRE ATT&CK, надаючи оборонні методи, які відповідають конкретним технікам атак.

D3FEND зазвичай вимовляється як "дефенд" (англійське слово defend, що означає "захищати"). Цифра "3" використовується для стилізації назви, але на вимову вона не впливає.

На стартову сторінку

Приклад

Концепція інформаційної безпеки фінансової установи

1. Загальні положення

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

Посилання на кращі практики

Концепція інформаційної безпеки фінансової установи

1. Загальні положення

Ця концепція визначає підходи до забезпечення інформаційної безпеки у фінансовій установі з метою захисту інформаційних активів від можливих загроз і ризиків. Вона враховує специфіку фінансового сектору та міжнародні стандарти, зокрема ISO/IEC 27001:2022, PCI DSS, а також нормативні вимоги регуляторних органів, таких як Національний банк України (НБУ) та інші закони України.
( Read more... )

💻 На стартову сторінку

Приклад

Концепція інформаційної безпеки (ІБ) для фінансової установи — це стратегічний документ, що визначає принципи, підходи, і засоби забезпечення захисту інформаційних активів організації. Цей документ має відповідати міжнародним стандартам, таким як ISO 27001:2022, TOGAF 10, а також враховувати чинне законодавство України, зокрема Закон України "Про захист інформації в інформаційно-телекомунікаційних системах", "Про електронні довірчі послуги" та інші нормативно-правові акти.

1. Вступ

1.1. Мета документа
1.2. Сфера застосування
1.3. Визначення термінів та скорочень

2. Загальні положення

2.1. Нормативно-правове регулювання
2.2. Основні принципи інформаційної безпеки
2.3. Основні загрози інформаційній безпеці
2.4. Визначення відповідальності за забезпечення ІБ

3. Мета та завдання інформаційної безпеки

3.1. Захист конфіденційності, цілісності та доступності інформаційних активів
3.2. Вимоги до управління ризиками інформаційної безпеки
3.3. Дотримання нормативних вимог і стандартів

4. Архітектура інформаційної безпеки

4.1. Інтеграція з TOGAF 10 - Використання TOGAF 10 для формування архітектури інформаційної безпеки. - Визначення доменів безпеки в рамках архітектурного підходу.
4.2. Використання ISO 27001:2022 для структурування політик ІБ - Основні етапи впровадження системи управління інформаційною безпекою (СУІБ) за стандартом ISO 27001:2022. - Впровадження контролів, визначених у додатку A стандарту.
4.3. Оцінка ефективності СУІБ (розділ 9.1 ISO 27001:2022) - Процедури моніторингу, вимірювання, аналізу та оцінки ефективності СУІБ.
4.4. Управління фізичними та технічними ресурсами (розділ 8.1 ISO 27001:2022) - Вимоги до захисту приміщень, технічних засобів та засобів комунікації.

5. Захист інформаційних активів

5.1. Визначення та класифікація інформаційних активів
5.2. Розробка та впровадження політик і процедур захисту - Політики захисту даних, управління доступом, шифрування, аудит.
5.3. Управління інцидентами інформаційної безпеки - Вимоги до процесів виявлення, реєстрації та реагування на інциденти.
5.4. Вимоги до забезпечення безперервності бізнесу

6. Організаційна структура управління інформаційною безпекою

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

7. Контроль та аудит інформаційної безпеки

7.1. Внутрішні аудити
7.2. Зовнішні перевірки та сертифікація
7.3. Документування та звітність

8. Заключні положення

8.1. Порядок перегляду та оновлення Концепції
8.2. Вимоги до звітності та контролю виконання

Посилання на нормативні документи:

ISO 27001:2022 — Стандарт інформаційної безпеки, що визначає вимоги до СУІБ.
TOGAF 10 — Стандарт архітектурного фреймворку, що визначає підходи до побудови архітектури підприємства, включаючи інформаційну безпеку.
Закон України "Про захист інформації в інформаційно-телекомунікаційних системах" — регулює захист інформації в Україні.
Закон України "Про електронні довірчі послуги" — регулює порядок надання електронних довірчих послуг та захисту даних у цифровому середовищі.

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

💻 На стартову сторінку

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

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

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

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

Актив (Asset): Ресурс або інформація, що має цінність для організації.
Загроза (Threat): Потенційне джерело небезпеки для активу, яке може спричинити порушення інформаційної безпеки.
Уразливість (Vulnerability): Слабке місце або недолік, яке може бути використане для реалізації загрози.
Інцидент інформаційної безпеки (Information security incident): Подія або серія подій, які можуть призвести до порушення конфіденційності, цілісності або доступності активів.
Ризик інформаційної безпеки (Information security risk): Поєднання ймовірності реалізації загрози та її наслідків для організації.
Контроль (Control): Міра або механізм, що застосовується для зменшення ризиків або досягнення цілей інформаційної безпеки.
Система управління інформаційною безпекою (СУІБ) (Information Security Management System, ISMS): Частина загальної системи управління, яка включає політики, процеси, процедури, рекомендації та ресурси, що використовуються для досягнення та підтримання інформаційної безпеки.
Політика інформаційної безпеки (Information security policy): Документ, що визначає зобов’язання організації щодо інформаційної безпеки, її цілі та підходи до управління інформаційними активами.
Актор загрози (Threat actor): Особа або організація, яка може здійснити загрозу, наприклад, зловмисник або природний фактор.
Ризик (Risk): Вплив невизначеності на цілі, що може мати як позитивні, так і негативні наслідки.
Захист даних (Data protection): Засоби та заходи, які організація застосовує для захисту інформаційних активів від несанкціонованого доступу, використання, розголошення, зміни або знищення.
Конфіденційність (Confidentiality): Властивість забезпечення доступу до інформації лише тим особам, які мають на це право.
Цілісність (Integrity): Властивість забезпечення точності, повноти та достовірності інформації.
Доступність (Availability): Властивість інформаційних активів бути доступними для використання авторизованими особами у потрібний момент.
Інформаційний актив (Information asset): Будь-яка інформація або ресурс, що має цінність для організації, включаючи електронні та паперові дані, програмне забезпечення, бази даних, системи та мережі.
Оцінка ризиків (Risk assessment): Процес виявлення, аналізу і оцінки ризиків для інформаційних активів.
Управління ризиками (Risk management): Процес визначення та застосування заходів для мінімізації, контролю або перенесення ризиків інформаційної безпеки.
Залишковий ризик (Residual risk): Ризик, який залишається після застосування заходів контролю.
Стороння організація (External party): Організація або особа, що не входить до структури компанії, але може взаємодіяти з її інформаційними активами.
Аудит інформаційної безпеки (Information security audit): Незалежна перевірка та оцінка відповідності процесів і заходів інформаційної безпеки вимогам стандарту.
Інформаційна безпека (Information security): Захист інформаційних активів від загроз, спрямованих на порушення їхньої конфіденційності, цілісності або доступності.
Інформаційна система (Information system): Сукупність взаємозалежних компонентів, що використовуються для збору, обробки, зберігання та поширення інформації.
Безперервність бізнесу (Business continuity): Здатність організації забезпечувати продовження критично важливих бізнес-функцій під час інцидентів.
Шифрування (Encryption): Процес перетворення інформації у форму, недоступну для несанкціонованих користувачів.
Управління доступом (Access control): Процедури і технології, які забезпечують доступ до інформаційних активів лише авторизованим користувачам.

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

💻 На стартову сторінку

Яку інформацію треба зібрати під час інвентаризації інформаційних активів (ІА) згідно з рекомендаціями стандарту ISO 27001:2022

Під час підготовки листа опитування завжди постає питання: що треба відобразити у листі опитування для визначення переліку інформаційних активів?

Для визначення переліку інформаційних активів за допомогою опитування, варто включити такі питання, щоб отримати повну інформацію про активи, які є в розпорядженні підрозділів або окремих співробітників:

Основні дані про актив
- Назва активу: Яке найменування чи ідентифікатор використовується для цього активу?
- Тип активу: До якого типу належить актив (апаратне забезпечення, програмне забезпечення, дані, документи, люди, мережеві ресурси тощо)?
- Короткий опис активу: Яка основна функція або призначення цього активу?
- Місцезнаходження активу: Де фізично або віртуально розташований цей актив?
Власність та відповідальність
- Власник активу: Хто відповідальний за управління цим активом?
- Користувачі активу: Хто має доступ або використовує цей актив?
Цінність та критичність
- Важливість активу: Наскільки критичним є цей актив для виконання бізнес-процесів або підтримки операцій організації?
- Інформаційна класифікація: До якої категорії конфіденційності або важливості належить інформація, що міститься в цьому активі (конфіденційна, внутрішня, публічна)?
Безпека та захист
- Існуючі заходи захисту: Які заходи безпеки використовуються для захисту цього активу?
- Потенційні загрози: Які основні ризики чи загрози можуть вплинути на безпеку цього активу?
Життєвий цикл активу
- Дата придбання чи створення: Коли було придбано або створено цей актив?
- Строк служби: Який очікуваний період використання цього активу?
Законодавчі та регуляторні вимоги
- Вимоги до зберігання та обробки: Чи підлягає цей актив спеціальним законодавчим або регуляторним вимогам?
Вартість та витрати
- Оцінка вартості активу: Яка приблизна вартість цього активу?
- Витрати на утримання: Які основні витрати пов'язані з підтримкою чи експлуатацією цього активу?
Залежності
- Залежності від інших активів: Чи залежить цей актив від інших активів для функціонування?

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

Таблиця з питаннями для листа опитування з метою визначення переліку інформаційних активів

№	Категорія	№	Питання
1	Основні дані про актив	1.1	Назва активу: Яке найменування чи ідентифікатор використовується для цього активу?
		1.2	Тип активу: До якого типу належить актив (апаратне забезпечення, програмне забезпечення тощо)?
		1.3	Короткий опис активу: Яка основна функція або призначення цього активу?
		1.4	Місцезнаходження активу: Де фізично або віртуально розташований цей актив?
2	Власність та відповідальність	2.1	Власник активу: Хто відповідальний за управління цим активом?
		2.2	Користувачі активу: Хто має доступ або використовує цей актив?
3	Цінність та критичність	3.1	Важливість активу: Наскільки критичним є цей актив для бізнес-процесів або операцій?
		3.2	Інформаційна класифікація: До якої категорії конфіденційності або важливості належить інформація?
4	Безпека та захист	4.1	Існуючі заходи захисту: Які заходи безпеки використовуються для захисту цього активу?
		4.2	Потенційні загрози: Які основні ризики чи загрози можуть вплинути на безпеку цього активу?
5	Життєвий цикл активу	5.1	Дата придбання чи створення: Коли було придбано або створено цей актив?
		5.2	Строк служби: Який очікуваний період використання цього активу?
6	Законодавчі та регуляторні вимоги	6.1	Вимоги до зберігання та обробки: Чи підлягає цей актив спеціальним законодавчим або регуляторним вимогам?
7	Вартість та витрати	7.1	Оцінка вартості активу: Яка приблизна вартість цього активу?
		7.2	Витрати на утримання: Які основні витрати пов'язані з підтримкою чи експлуатацією цього активу?
8	Залежності	8.1	Залежності від інших активів: Чи залежить цей актив від інших активів для функціонування?