Безпека архітектури ІТ-системи. Заходи захисту ISO/IEC 27001:2013 → 2022

2025-06-29 17:57
bga68comp: (Default)

Щодо шаблонів рівнів архітектури ІТ-систем.

Доповнення до опису архітектури за посиланнями:
• Приклад опису архітектури системи згідно TOGAF
• Побудова віртуальної інфраструктури на базі Microsoft Azure
• Інформаційна архітектура ІТ-системи компанії. Приклад
• Безпека архітектури ІТ-системи на базі Microsoft Azure. Мапінг компонентів на NIST SP 800-53 Rev. 5
• Основні категорії діаграм (за TOGAF + ISO 42010)

Відповідність заходів захисту ISO/IEC 27001:2013 → 2022

№ Компонент архітектури прикладу Заходи захисту ISO/IEC 27001:2013 Заходи захисту ISO/IEC 27001:2022
1 Віртуальна мережа (VNet) A.13.1, A.9.1 A.8.20, A.8.21, A.8.22, A.5.15, A.5.18
2 Шлюз за замовчуванням A.13.1 A.8.20, A.8.21, A.8.22
3 DNS-сервер A.12.1, A.14.1 A.8.6, A.8.9, A.8.25, A.8.27
4 Контролер домену (DC1, DC2) A.9.2 A.5.16, A.5.17
5 Файловий сервер (FS1) A.8.2, A.9.1 A.5.9, A.5.10, A.5.15, A.5.18
6 Термінальний сервер (DevS1/RDS) A.13.1, A.9.4 A.8.20, A.8.21, A.8.22, A.5.4
7 Веб-сервер (WS1 – внутрішній) A.14.2, A.13.1 A.8.26, A.8.28, A.8.20, A.8.21, A.8.22
8 Веб-сервер (WS2 – зовнішній) A.14.1, A.13.1 A.8.25, A.8.27, A.8.20, A.8.21, A.8.22
9 Групи безпеки (NSG) A.13.1, A.12.4 A.8.20, A.8.21, A.8.22, A.8.15, A.8.16
10 Azure Backup A.12.3 A.8.13
11 Моніторинг і логування (Azure Monitor, Log Analytics) A.12.4 A.8.15, A.8.16
12 Балансування навантаження (Azure Load Balancer, App Gateway) A.13.1, A.14.1 A.8.20, A.8.21, A.8.22, A.8.25, A.8.27

Пояснення ключових нових заходів захисту ISO/IEC 27001:2022:

  • A.8.20–A.8.22 – Безпека мереж, сервісів і сегментація
  • A.8.25–A.8.28 – Безпека життєвого циклу розробки, архітектура і кодування
  • A.5.15–A.5.18 – Контроль доступу, управління ідентичностями
  • A.8.6 / A.8.9 – Потужність систем і конфігурації
  • A.8.13 – Резервне копіювання
  • A.8.15 / A.8.16 – Журналювання та моніторинг
  • A.5.4 – Контроль доступу до ІТ-систем


Звісно, кожен архітектор безпеки може сказати, що використовував би трохи інші заходи захисту. Для цього можна посилатися на Annex B (informative) Correspondence of ISO/IEC 27002:2022 with ISO/IEC 27002:2013.
  Table B.1 — Correspondence between controls in ISO/IEC 27002:2022 and controls in ISO/IEC 27002:2013
  Table B.2 — Correspondence between controls in ISO/IEC 27002:2013 and controls in ISO/IEC 27002:2022


Tags:
  • Add Memory
  • Share This Entry

Безпека архітектури ІТ-системи на базі Microsoft Azure

2025-06-29 16:30
bga68comp: (Default)

Щодо шаблонів рівнів архітектури ІТ-систем.

Доповнення до опису архітектури за посиланнями:
• Приклад опису архітектури системи згідно TOGAF
• Побудова віртуальної інфраструктури на базі Microsoft Azure
• Інформаційна архітектура ІТ-системи компанії. Приклад

Відповідність між компонентами, заходами захисту ISO/IEC 27001:2022 та відповідними родинами заходів захисту NIST SP 800-53 Rev. 5.

Мапінг компонентів на NIST SP 800-53 Rev. 5


№КомпонентISO/IEC 27001:2022NIST SP 800-53 Rev. 5
1Віртуальна мережа (VNet)A.8.20, A.8.21, A.8.22, A.5.15, A.5.18AC-4 (Information Flow Enforcement), SC-7 (Boundary Protection), AC-2 (Account Management), AC-6 (Least Privilege)
2Шлюз за замовчуваннямA.8.20, A.8.21, A.8.22SC-7, SC-5 (Denial-of-Service Protection)
3DNS-серверA.8.6, A.8.9, A.8.25, A.8.27CM-2 (Baseline Config), SI-2 (Flaw Remediation), SA-3 (System Development Process), SA-8 (Security Engineering)
4Контролер домену (DC1, DC2)A.5.16, A.5.17IA-2 (User Identification & Authentication), IA-5 (Authenticator Management)
5Файловий сервер (FS1)A.5.9, A.5.10, A.5.15, A.5.18AC-3 (Access Enforcement), MP-5 (Media Transport Protection), CM-8 (Information System Component Inventory)
6Термінальний сервер (DevS1/RDS)A.8.20, A.8.21, A.8.22, A.5.4AC-17 (Remote Access), AC-19 (Access Control for Mobile Devices), SC-12 (Cryptographic Key Establishment)
7Веб-сервер (WS1 – внутрішній)A.8.26, A.8.28, A.8.20, A.8.21, A.8.22SA-11 (Developer Security Testing), RA-5 (Vulnerability Scanning), SC-7, SI-10 (Information Input Validation)
8Веб-сервер (WS2 – зовнішній)A.8.25, A.8.27, A.8.20, A.8.21, A.8.22SA-3, SA-8, CA-3 (System Interconnection), SI-10, SC-26 (Public Key Infrastructure Certificates)
9Групи безпеки (NSG)A.8.20, A.8.21, A.8.22, A.8.15, A.8.16AC-4, SC-7, AU-6 (Audit Review), AU-12 (Audit Generation)
10Azure BackupA.8.13CP-9 (Information System Backup), CP-10 (Recovery and Reconstitution)
11Моніторинг і логування (Azure Monitor, Log Analytics)A.8.15, A.8.16AU-2 (Audit Events), AU-6, AU-12, IR-5 (Incident Monitoring)
12Балансування навантаження (Azure Load Balancer, App Gateway)A.8.20, A.8.21, A.8.22, A.8.25, A.8.27SC-5, SC-7, SA-8, AC-17, CA-3

Додатково:
Коментарі до основних родин заходів захисту NIST
 → https://bga68comp.dreamwidth.org/804396.html


Tags:
  • Add Memory
  • Share This Entry

Коментарі до основних родин заходів захисту NIST

2025-06-29 16:01
bga68comp: (Default)

Коментарі до основних родин заходів захисту NIST:

  • AC-: Access Control (управління доступом)
  • IA-: Identification and Authentication (ідентифікація і автентифікація)
  • SC-: System and Communications Protection (захист мереж і систем)
  • AU-: Audit and Accountability (журналювання і аудит)
  • SA-: System and Services Acquisition (розробка та закупівля)
  • SI-: System and Information Integrity (цілісність систем)
  • CM-: Configuration Management (конфігурація)
  • CP-: Contingency Planning (резервне копіювання)
  • IR-: Incident Response (реакція на інциденти)


Tags:
  • Add Memory
  • Share This Entry

Інформаційна архітектура ІТ-системи компанії. Приклад

2025-06-26 20:58
bga68comp: (Default)

Продовжуємо розбирати шаблони рівнів архітектури ІТ-систем. Це доповнення до опису архітектури за посиланнями:
• Приклад опису архітектури системи згідно TOGAF
• Побудова віртуальної інфраструктури на базі Microsoft Azure



✅ Опис інформаційної архітектури компанії
🖼️ Згідно з наданою схемою (RDS, Files, IIS Web Front/Back, AD DC1/DC2, VPN)

🧾 Інформаційна архітектура ІТ-системи компанії

🔹 1. Методологія

  • TOGAF 9.2, ADM, фаза C (Data Architecture): побудова інформаційного рівня архітектури.
  • ISO/IEC/IEEE 42010:2011: опис архітектури через зацікавлені сторони, погляди (views), моделі та відповідності.

🔹 2. Архітектурний контекст

  • Усі серверні ресурси компанії розміщені в тенанті Azure.
  • Користувачі підключаються до корпоративної мережі через захищені канали (VPN або Azure Bastion).
  • Робоче середовище реалізоване через RDS-сервер (DevSRV).
  • Веб-додатки розділені на фронт- (IIS Web Front) та бекенд (IIS Web Back).
  • Ідентифікація та авторизація забезпечуються двома доменними контролерами (AD DC1, DC2).

🔹 3. Архітектурні погляди (Views)

3.1 📡 Deployment View

  • DevSRV – RDS сервер для користувачів.
  • Files – файловий сервер зі спільними каталогами.
  • IIS Web Srv Front / Back – розподілення логіки веб-додатку.
  • AD DC1 / DC2 – розподілена автентифікація, DNS, GPO.
  • Всі ресурси ізольовані через NSG, Firewall, розміщені у VNet з Subnet-сегментацією.
  • Користувачі підключаються через захищений шлюз (VPN/Bastion).

3.2 🧩 Data Architecture View

Сутність даних Опис
User Profile Профілі користувачів, зберігаються в AD та RDS
File Object Файли користувача на файловому сервері
DNS-записи Зони та записи, керуються AD DC1/DC2
Web Session Дані сесій на IIS Front
GPO Configuration Групові політики, що застосовуються через AD
RDP Logs Логи входів і дій у RDS

3.3 🔐 Access & Security View

  • RBAC на основі груп у AD.
  • GPO-політики: заборона USB, блокування локального диска, перенаправлення папок.
  • Шифрування: RDP over TLS, SMB over TLS.
  • Аудит: централізоване логування входів, дій на RDS.
  • Двофакторна автентифікація (MFA) через Azure AD / Conditional Access.
  • Firewall + NSG: розмежування Frontend, Backend, Infra.

3.4 🔄 Information Flow View

Звідки → Куди Протокол Захист
Користувач → RDS RDP over TLS VPN / MFA / GPO
RDS → Files SMB 3.0 ACL + GPO + TLS
RDS → AD LDAP/Kerberos Шифрування, автентифікація
RDS → IIS Front/Back HTTP/HTTPS ACL, WAF, сегментація
RDS → DNS DNS ACL-захист зони

🔹 4. Зацікавлені сторони (Stakeholders)

Сторона Інтерес
Користувачі Стабільний і безпечний доступ до робочого середовища
Системні адміністратори Централізоване управління політиками та файлами
Відділ ІБ Впровадження GPO, аудит, захист інформації
Бізнес Доступність сервісів, віддалена робота

🔹 5. Цільова модель та вдосконалення

Компонент Поточна реалізація Рекомендоване покращення
RDS DevSRV на VM Перехід до RDS Farm + Load Balancer
Files Windows FS Azure Files + Private Endpoint
MFA Часткове Універсальне MFA через Azure AD
AD DC1 + DC2 Гібрид із Azure AD DS
IIS Front/Back На VM Azure App Service або контейнеризація

🔹 6. Узгодженість із ISO/IEC/IEEE 42010

Компонент Відповідність
Stakeholders Визначено
Architectural Views Згруповано (Deployment, Security, Data)
Вимоги Ураховані: доступність, безпека, контроль
Traceability Показано зв’язок між цілями й рішеннями

✅ На останок:

Інформаційна архітектура побудована згідно з TOGAF ADM (фаза C) та структурована за стандартом ISO 42010.
Враховано як функціональні, так і нефункціональні вимоги: доступність, безпека, масштабованість.
Усі основні компоненти (RDS, Files, AD, IIS) інтегровані через захищені канали й управляються централізовано.


Annex:
🟠 Фази ADM (Architecture Development Method)

  1. Preliminary Phase
  2. Phase A: Architecture Vision
  3. Phase B: Business Architecture
  4. Phase C: Information Systems Architectures
  5. Phase D: Technology Architecture
  6. Phase E: Opportunities and Solutions
  7. Phase F: Migration Planning
  8. Phase G: Implementation Governance
  9. Phase H: Architecture Change Management
  10. Requirements Management


Tags:
  • Add Memory
  • Share This Entry

Зависає вікно "Збереження файлу"

2025-06-09 19:00
bga68comp: (Default)

Проблема:
Вікно "Збереження файлу" (Save As) періодично зависає у Windows 11.

Можливе рішення:

🔹 Вимкнути апаратне прискорення

  • У браузерах (Chrome/Edge):
    Налаштування → Система → Вимкнути "Use hardware acceleration when available" → Перезапусти браузер.

  • У Word / Excel:
    Файл     → Параметри → Додатково → Відключити апаратне прискорення графіки.


Але пам'ятаємо, що для того, щоб використовувати різні фони під час спілкування у Google Meet, треба у Chrome вмикати апаратне прискорення графіки.

Тому вмикайте-вимикайте апаратне прискорення графіки 😜 Хтось вирішив з нас познущатися 👻


Tags:
  • Add Memory
  • Share This Entry

SIEM, SIEM TOOLS, ARCHITECTURE

2025-06-04 21:01
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


Tags:
  • Add Memory
  • Share This Entry

Термін — Alert

2025-05-22 18:44
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 — Застереження (Найкращий баланс між "сповіщенням" і "тривогою")


Tags:
  • Add Memory
  • Share This Entry

SIEM. Denny Roger

2025-05-22 18:31
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... )


Tags:
  • Add Memory
  • Share This Entry

Insecure Port Vs Secure Port

2025-05-22 14:37
bga68comp: (Default)
Insecure Port Vs Secure Port | Credits:

e-Learn Cyber Security

Insecure Ports vs Secure Ports

Insecure Port Protocol Description Secure Port Protocol Description
21 FTP Sends username and password in plaintext. 22 SFTP Encrypts user credentials and data packets.
23 Telnet Sends all info in plaintext; vulnerable to interception. 22 SSH Encrypts terminal traffic; protects from sniffing.
25 SMTP Sends emails without encryption; vulnerable to sniffing. 587 SMTP (TLS) Encrypts emails between client and server.
37 TIME Legacy protocol, mostly replaced. 123 NTP Better error handling and accuracy.
53 DNS Widely used but unencrypted. 853 DoT Encrypts DNS with TLS, protects in transit.
80 HTTP Unencrypted web traffic; vulnerable to sniffing. 443 HTTPS Uses TLS to protect browser-server communication.
143 IMAP Retrieves email without encryption. 993 IMAP (SSL/TLS) Encrypts email retrieval traffic.
445 SMB Unencrypted file sharing on Windows networks. 2049 NFS Can be encrypted, but often blocked by firewalls.
389 LDAP Unencrypted directory queries; vulnerable to attacks. 636 LDAPS Adds SSL/TLS to secure directory access.

🇺🇦 Незахищені порти порівняно із захищеними

Незахищений порт Протокол Опис Захищений порт Протокол Опис
21 FTP Передає ім’я користувача і пароль у відкритому вигляді. 22 SFTP Шифрує облікові дані користувача і передані дані.
23 Telnet Уся інформація передається у відкритому вигляді; вразлива до перехоплення. 22 SSH Шифрує термінальний трафік; захищає від перехоплення.
25 SMTP Відправляє електронну пошту без шифрування; вразлива до перехоплення. 587 SMTP (TLS) Шифрує пошту між клієнтом і сервером.
37 TIME Застарілий протокол, майже не використовується. 123 NTP Краще обробляє помилки, підвищує точність.
53 DNS Широко використовується, але не шифрується. 853 DoT Шифрує DNS через TLS, захищає під час передавання.
80 HTTP Нешифрований вебтрафік; вразливий до перехоплення. 443 HTTPS Використовує TLS для захисту з’єднання браузера з сервером.
143 IMAP Отримання пошти без шифрування. 993 IMAP (SSL/TLS) Шифрує трафік отримання електронної пошти.
445 SMB Нешифроване спільне використання файлів у Windows-мережах. 2049 NFS Може шифруватися, але зазвичай блокується фаєрволами.
389 LDAP Нешифровані запити до каталогу; вразливі до атак. 636 LDAPS Додає SSL/TLS для захисту доступу до каталогу.


Tags:
  • Add Memory
  • Share This Entry

Скільки середовищ має бути в життєвому циклі ІТ

2025-05-09 12:46
bga68comp: (Default)

Скільки середовищ має бути в життєвому циклі ІТ-системи?

У життєвому циклі ІТ-системи зазвичай виділяють від 3 до 6 середовищ, залежно від рівня зрілості процесів та вимог до безпеки. Найбільш поширена структура включає:

1. Development (DEV)

Середовище розробки
  • Використовується розробниками для написання та первинного тестування коду.
  • Низький рівень обмежень, можливі нестабільності.

2. Testing (TEST) або QA

Середовище тестування функціональності / контролю якості
  • Перевіряються основні сценарії, автоматизовані тести.
  • Конфігурація наближена до продуктивного середовища, але з меншим обсягом даних.

3. Staging (STG) або Pre-Production

Передпродуктивне середовище
  • Майже повна копія продуктивного середовища: ті ж версії ПЗ, архітектура, налаштування.
  • Використовується для перевірки релізів перед впровадженням у продакшн.

4. Production (PROD)

Продуктивне (робоче) середовище
  • Обробляє реальні користувацькі дані.
  • Високі вимоги до доступу, стабільності, безпеки.

Додатково можуть використовуватись:

5. UAT (User Acceptance Testing)

Середовище приймального тестування
  • Замовники або бізнес-користувачі перевіряють, чи відповідає рішення їхнім очікуванням.

6. Sandbox

Середовище-пісочниця для експериментів, навчання та демонстрацій
  • Безпечне середовище для тестування ідей або навчання без ризику для основної системи.

Підсумкова таблиця:


№ Назва середовища Призначення
1 DEV (Розробка) Розробка та початкове тестування
2 TEST або QA Функціональне та автоматизоване тестування
3 STG (Передпродакшн) Перевірка перед виходом у продакшн
4 PROD (Продуктивне) Робота з реальними даними
5 UAT Приймальне тестування замовником
6 Sandbox (Пісочниця) Експерименти, PoC, навчання


Tags:
  • Add Memory
  • Share This Entry

Active audit agency: Фінтех та ISO 27001

2025-04-24 15:23
bga68comp: (Default)
Фінтех та 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

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


Tags:
  • Add Memory
  • Share This Entry

Тріада інформаційної безпеки

2025-04-23 13:18
bga68comp: (Default)



ISO/IEC 27000
Fifth edition
2018-02
Information technology — Security techniques — Information security management systems — Overview and vocabulary
Technologies de l'information — Techniques de sécurité — Systèmes de management de la sécurité de l'information — Vue d'ensemble et vocabulaire

Reference number
ISO/IEC 27000:2018(E)
© ISO/IEC 2018

3.28
information security
preservation of confidentiality (3.10), integrity (3.36) and availability (3.7) of information

Note 1 to entry: In addition, other properties, such as authenticity (3.6), accountability, non-repudiation (3.48), and reliability (3.55) can also be involved.

Section 3.28: Information Security

Definition: Information security is defined as the preservation of confidentiality, integrity, and availability of information.

Key Properties:

  1. Confidentiality: This property ensures that information is not disclosed to unauthorized individuals, entities, or processes. It is essential for protecting sensitive data from unauthorized access.
  2. Integrity: Integrity refers to the accuracy and completeness of information. It ensures that information is not altered or tampered with by unauthorized individuals, maintaining its reliability and trustworthiness.
  3. Availability: This property ensures that information is accessible and usable on demand by authorized entities. It is crucial for ensuring that information systems and data are operational and can be accessed when needed.

Additional Considerations: The definition also mentions other properties that can be involved in the broader context of information security, such as:

  • Authenticity: Ensuring that an entity is what it claims to be.
  • Accountability: The ability to trace actions to the responsible entity.
  • Non-repudiation: Ensuring that a party cannot deny the authenticity of their signature on a document or the sending of a message.
  • Reliability: The assurance that information is consistently accurate and trustworthy.

These three core principles—confidentiality, integrity, and availability—are commonly referred to as the CIA triad and serve as a fundamental framework in the practice of information security management.

Джерело :
1 ISO 27000:2018
Переклад тексту українською:

Розділ 3.28: Інформаційна безпека

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

Ключові властивості:

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

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

  • Автентичність: Забезпечення того, що суб'єкт є тим, за кого себе видає.
  • Відповідальність: Можливість відстежувати дії до відповідального суб'єкта.
  • Невідмовність: Забезпечення того, що сторона не може заперечувати автентичність свого підпису на документі або відправлення повідомлення.
  • Надійність: Гарантія того, що інформація постійно є точною та надійною.

Три основні принципи — конфіденційність, цілісність та доступність — зазвичай називаються тріадою CIA і слугують фундаментальною основою в практиці управління інформаційною безпекою.


Tags:
  • Add Memory
  • Share This Entry

Натхненка! ChatGPT Free Online українською

2025-04-21 02:32
bga68comp: (Default)


ChatGPT Free Online: розкрийте силу розмов зі штучним інтелектом
Спілкуйтеся, перекладайте та навчайтеся з ChatGPT - Все безкоштовно

 https://gptonline.ai/uk/


Tags:
  • Add Memory
  • Share This Entry

Visualize your work with easy-to-make diagrams

2025-04-14 19:26
bga68comp: (Default)
Коли архітектура — мистецтво

Бувало таке: треба швиденько накидати архітектуру в AWS — типу “ось тут база, ось тут бекенд, а тут якийсь сервіс, який іноді працює” — ти відкриваєш Microsoft Visio або Draw.io, а воно тобі у відповідь: «Ну… я старався…». І ти дивишся на цю схему і думаєш: "Показувати "оце це" замовнику? Може, краще ні?.."

Але вихід завжди є!😎

 👉 https://aws.amazon.com/architecture/icons


Що всередині:

AWS підготував офіційні піктограми, шаблони і навіть рекомендації, щоб діаграми виглядали як у людей. Красиво. Зрозуміло. І без сорому.
Тут ви знайдете набір офіційних піктограм Amazon Web Services, які можна використовувати у своїх проектах:

– піктограми для кожного сервісу AWS (навіть для тих, які ще не встиг придумати архітектор),
– шаблони для Visio, PowerPoint, Lucidchart,
– приклади схем, щоб надихнутись.

З цим набором схема архітектури більше не виглядатиме як план втечі з Excel — вона буде, як мінімум, претендувати на “AWS Diagram of the Year 2025”❤️

Це не реклама, бо я не працюю в AWS 😉


Tags:
  • Add Memory
  • Share This Entry

Сценарії викрадення інформації або НСД

2025-04-11 20:38
bga68comp: (Default)

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. Співробітник відкриває файли з вірусами "щоб подивитись що буде".



Tags:
  • Add Memory
  • Share This Entry

Термін framework

2025-04-11 19:40
bga68comp: (Default)

У контексті інформаційної безпеки (ІБ) слово "framework" українською найчастіше перекладається як:

🔹 Фреймворк — транслітерований варіант, часто вживається у професійному ІТ-середовищі (наприклад, NIST Cybersecurity Framework — Фреймворк кібербезпеки NIST).
🔸 Рамкова модель або рамкова структура — офіційно вживаний переклад у нормативних документах (наприклад, рамкова структура управління ризиками).
🔹 Концептуальна модель — якщо йдеться про абстрактну, методологічну основу.
🔸 Методологія — коли фреймворк описує процеси та принципи роботи.
🔹 Система (управління/захисту/оцінки) — у вільному перекладі, щоб зробити текст доступнішим.

Приклади перекладу:


Англійський термін Український переклад
NIST Cybersecurity Framework Фреймворк кібербезпеки NIST
Risk Management Framework (RMF) Рамкова модель управління ризиками
ISO/IEC 27001 Framework Фреймворк ISO/IEC 27001
Cloud Security Framework Хмарний фреймворк безпеки / Рамкова модель хмарної ІБ
Governance Framework Фреймворк управління / Модель управління


Tags:
  • Add Memory
  • Share This Entry

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

2025-04-11 16:24
bga68comp: (Default)
10хв-white_v3Коли ти ще робиш каву з ранку, хакер вже перейменував твій сервер у “Дмитро”

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

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

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

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

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

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

Де глянути?

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

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

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

10хв-white_v3


Tags:
  • Add Memory
  • Share This Entry

The next chapter: Moving from Skype to Microsoft Teams 

2025-04-10 14:51
bga68comp: (Default)

У травні 2025 року Microsoft припиняє роботу Skype, щоб зосередитися на Microsoft Teams, їх сучасному центрі комунікацій і співпраці. 



Що чекає на користувачів Skype 
Skype — всьо...

Протягом перехідного періоду до 5 травня 2025 року користувачі мають вибір:

1. Перейти на Microsoft Teams безкоштовно. Найближчими днями Microsoft розгорне можливість для користувачів Skype входити в Teams (безкоштовно) на будь-якому підтримуваному пристрої за допомогою своїх облікових даних Skype, починаючи з сьогоднішнього дня — Прим.: опубліковано 28 лютого 2025 р — для тих, хто бере участь як у програмах Teams, так і в програмі Skype Insider. Увійшовши в Teams за допомогою облікового запису Skype, чати та контакти автоматично з’являться в програмі, тож ви зможете швидко продовжити з того місця, де зупинилися.

Протягом перехідного періоду користувачі Teams можуть телефонувати та спілкуватися з користувачами Skype, а користувачі Skype можуть робити те саме з користувачами Teams. Це допоможе вам залишатися на зв’язку з усіма, незалежно від платформи, яку ви використовуєте під час переходу.

2. Експортувати дані Skype. Якщо ви не бажаєте переходити до Teams, ви можете натомість експортувати свої дані, зокрема чати, контакти та історію викликів.

Skype залишатиметься доступним до 5 травня 2025 року, що дасть користувачам час вивчити Teams і вибрати варіант, який їм найкраще підходить.

Microsoft каже:

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

За допомогою Teams користувачі мають доступ до багатьох тих же основних функцій, що й у Skype, як-от дзвінки один на один і групові дзвінки, обмін повідомленнями та спільний доступ до файлів. Крім того, Teams пропонує розширені функції, як-от проведення зустрічей, керування календарями, створення спільнот і приєднання до них безкоштовно.

Сотні мільйонів людей уже використовують Teams як центр для командної роботи, допомагаючи їм залишатися на зв’язку та бути залученими на роботі, у школі та вдома. За останні два роки кількість хвилин, проведених користувачами Teams на зустрічах, зросла в 4 рази, що відображає цінність Teams для повсякденного спілкування та співпраці. 

Коли ми робимо наступний крок із Teams, ми в захваті від нових можливостей. Ми з нетерпінням чекаємо й надалі підтримувати повсякденні зв’язки людей, починаючи з полегшення входу в Teams за допомогою їхнього облікового запису Skype.



Хто ж у цьому всьому безладі винен?

Jeff Teper, President, Collaborative Apps and Platforms | Джефф Тепер
Президент, програми та платформи для спільної роботи

Original:
 • The next chapter: Moving from Skype to Microsoft Teams 


Tags:
  • Add Memory
  • Share This Entry

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

2025-04-10 02:23
bga68comp: (Default)
​image_2025-04-10_02-43-53Кодекс практики з кіберуправління (Cyber Governance Code of Practice) — це новий документ, опублікований урядом Великої Британії 8 квітня 2025 року. Він надає керівництву компаній та директорам рекомендації щодо ефективного управління кіберризиками та захисту своїх організацій від кібератак.

​image_2025-04-10_02-43-53

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

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


Tags:
  • Add Memory
  • Share This Entry

30 заповідей офіцера кібербезпеки у п’ятнию

2025-04-04 22:04
bga68comp: (Default)

30 заповідей офіцера кібербезпеки:

  1. Я – твій SOC-аналітик, і хай не буде в тебе інших алертів, окрім тих, що я благословив.
  2. Не зроби собі кумира з ChatGPT – навіть якщо він щойно згенерував шикарну політику безпеки.
  3. Пам’ятай день пентесту, щоб святити його.
  4. Шануй лог і SIEM – бо без них немає слідства і немає прощення.
  5. Не клацай suspicious лінки – бо можеш побачити світ із вікна SOC-а.
  6. Не встановлюй .exe з невідомого джерела – навіть якщо обіцяють піца-код.
  7. Не кради чужий пароль – навіть якщо це пароль адміністратора.
  8. Не свідчи хибно перед аудитом – лог все одно тебе видасть.
  9. Не зазіхай на політику інформаційної безпеки сусіда свого – пиши свою.
  10. Не жадай чужого Nmap – склади свій список портів.
  11. Бо як тільки хтось каже “ми нецікаві хакерам” – хакери прокидаються.
  12. Не пиши “123456” – бо навіть Бог втомився про це говорити.
  13. Проксі – не перешкода, а благословення.
  14. MFA – не знущання, а спасіння.
  15. VPN – твій щит, і навіть коли здається, що він ламається.
  16. Тримай свою політику безпеки в порядку – як зуби перед візитом до ISO-аудитора.
  17. З шифруванням, як з борщем – краще трохи більше, ніж трохи менше.
  18. І нехай твій пароль буде довгий і незрозумілий, як звіт з Nessus.
  19. І нехай твій бек-ап буде тричі перевірений і один раз протестований.
  20. І не введи себе у спокусу дешевого антивірусу.
  21. Бо якщо щось працює – ще не значить, що воно безпечно.
  22. І якщо щось безпечно – ще не значить, що воно працює.
  23. Якщо щось не логгується – вважай, що цього не існує.
  24. Не оновив? Готуйся оновити своє резюме.
  25. Не вір .xls з пошти – навіть якщо це звіт з бухгалтерії.
  26. Адмін без обмежень – як меч без піхов. Небезпечно.
  27. Сегментація мережі – як двері в будинку. Без неї тебе обкрадуть, поки ти спиш.
  28. IDS бачить усе, але пробачає мало.
  29. Якщо щось здається занадто хорошим – це, ймовірно, фішинг.
  30. І наостанок – пам’ятай, офіцере: ніхто не дякує за інцидент, який не стався. Але ти все одно молодець.



Tags:
  • Add Memory
  • Share This Entry

Profile

bga68comp: (Default)
bga68comp

January 2026

S M T W T F S
    123
45678 910
11121314151617
18192021222324
25262728293031

Syndicate

RSS Atom

Most Popular Tags

Page Summary

Style Credit

Expand Cut Tags

No cut tags
Page generated 2026-01-11 06:16
Powered by Dreamwidth Studios