bga68comp: (Default)


АНБ разом із CISA та Канадським центром кібербезпеки опублікувала звіт «Звіт про аналіз шкідливого програмного забезпечення: бекдор BRICKSTORM», у якому детально описано кіберкампанію, що спонсорується державою Китаю та використовує BRICKSTORM для довготривалого збереження скомпрометованих систем. Шкідливе програмне забезпечення BRICKSTORM — це складний бекдор, який дозволяє кіберзлочинцям підтримувати постійний, прихований доступ, надаючи можливості безпечного управління та контролю, віддаленого керування системою та збереження шкідливого програмного забезпечення. Організаціям рекомендується використовувати індикатори компрометації (IOC) та сигнатури виявлення, описані в ньому, для ідентифікації зразків шкідливого програмного забезпечення BRICKSTORM, повідомлення про будь-які компрометації та впровадження відповідних заходів щодо пом'якшення наслідків.

 © https://www.linkedin.com/posts/the-cyber-security-hub_malware-analysis-report-brickstorm-backdoor-ugcPost-7402396757097074688-BvOb/


bga68comp: (Default)

Кабінет Міністрів України
Постанова від 26 листопада 2025 р. № 1516

Про затвердження Порядку призначення керівника з кіберзахисту на посаду в органі державної влади

https://www.kmu.gov.ua/npas/pro-zatverdzhennia-poriadku-pryznachennia-kerivn-derzhavnoi-vlady-i-1516

https://www.kmu.gov.ua/storage/app/uploads/public/692/820/5a9/6928205a9d0dc940485839.pdf


bga68comp: (Default)

© linkedin.com

Information Security NetworkAyesha Abid • 3-й и выше • Все в LinkedIn и за пределами сайта
Отримайте повний набір шаблонів і документів з кібербезпеки за адресою: https://lnkd.in/dqACKdzc

🏆 Оптимізуйте свій робочий процес без зусиль!
🎢 Аналізуйте дані з легкістю!
🎡 Приймайте рішення впевнено!

Скоротіть завдання навпіл за допомогою готових шаблонів і документів.



Cybersecurity Templates & Documents

Шаблони та документи з кібербезпекиRead more... )


bga68comp: (Default)

Структура можливостей безпеки SaaS (SSCF)
Для кого це:
  • Команди з управління ризиками третіх сторін
  • Постачальники SaaS
  • Команди інженерів безпеки SaaS

Структура можливостей безпеки SaaS (SSCF)

Дата виходу: 23.09.2025

Структура можливостей безпеки SaaS (SSCF) – це нова технічна структура, яка визначає налаштовувані, споживані та орієнтовані на клієнта засоби контролю безпеки, що надаються постачальниками SaaS своїм клієнтам.
SSCF являє собою комплексний підхід до управління безпекою в хмарних програмних рішеннях, розроблений для подолання розриву між можливостями безпеки постачальників та специфічними вимогами замовника. SSCF було розроблено у співпраці з робочою групою SaaS CSA та іншими провідними галузевими експертами.
SSCF надає ключові переваги широкому колу користувачів:
  • Для команд TPRM це слугує базовою точкою можливостей безпеки під час оцінки постачальників SaaS, спрощуючи оцінку ризиків та процеси закупівель.
  • Для постачальників SaaS це стандартизує відповіді на оцінювання, слугуючи узгодженою основою, зменшуючи кількість спеціалізованих анкет та накладні витрати на оцінювання.
  • Для команд інженерів безпеки SaaS це надає базовий контрольний список впровадження, оптимізуючи та пришвидшуючи їхню програму безпеки SaaS.
Встановлюючи стандартизовані функції безпеки, які мають бути доступні на всіх SaaS-платформах, SSCF дозволяє власникам додатків приймати обґрунтовані рішення та підтримувати послідовний рівень безпеки.
Що входить до цього завантаження:
  • Документ випуску SSCF версії 1.0: Описує новий стандарт, його контекст, область застосування та домени контролю.
  • Список елементів керування SSCF версії 1.0: Містить елементи керування SSCF, узгоджені з доменами CCM.
  • Слайди SSCF версії 1.0: Ознайомлення з передумовою, постановкою проблеми та перевагами SSCF.

Джерело:
https://cloudsecurityalliance.org/artifacts/saas-security-capability-framework-sscf


bga68comp: (Default)


Керівні принципи (рамки) впровадження та аудиту AICM

Керівні принципи (рамки) впровадження та аудиту AICM

Дата виходу: 22.10.2025

Комплект інструкцій щодо впровадження та аудиту Матриці елементів керування штучним інтелектом (AICM) Альянсу безпеки хмарних технологій (Cloud Security Alliance, CSA) надає вичерпні вказівки щодо впровадження та оцінки 243 елементів керування Матриці елементів керування штучним інтелектом.
Що входить до цього завантаження:
  • Керівні принципи впровадження: Визначає практичні рекомендації на основі ролей щодо застосування елементів керування AICM до систем штучного інтелекту, що працюють у хмарних середовищах. Кожен елемент керування містить детальні інструкції з впровадження, адаптовані до основних учасників екосистеми штучного інтелекту: постачальників моделей (MP), постачальників додатків (AP), постачальників оркестрованих послуг (OSP), клієнтів штучного інтелекту (AIC) та постачальників хмарних послуг (CSP).
  • Керівні принципи аудиту: Надає структуровані кроки аудиту для внутрішніх або зовнішніх аудиторів, які оцінюють організації, що впроваджують AICM. Підкреслює відповідальність за конкретні ролі в усьому ланцюжку постачання штучного інтелекту, забезпечуючи послідовну оцінку, чіткі очікування та відстеження в усіх видах діяльності з впровадження та забезпечення якості.
Ці рамки є орієнтиром для практиків, впроваджувачів та аудиторів, які прагнуть впровадити, оцінити та посилити програми управління, управління ризиками та відповідності для систем штучного інтелекту в хмарних середовищах.
Завантажте повну Матрицю контролю штучного інтелекту (AICM) тут .

Джерело:
https://cloudsecurityalliance.org/artifacts/aicm-implementation-auditing-guidelines-frameworks


bga68comp: (Default)

Кібербезпека та життєвий цикл даних
Для кого це:
  • Фахівці з ІТ та кібербезпеки
  • Команди з дотримання вимог
  • Бізнес-лідери та керівники
  • Постачальники технологій та рішень

Кібербезпека та життєвий цикл даних

Дата випуску: 02/10/2025

Життєвий цикл даних стосується комплексного процесу, який проходять дані, від їх створення до остаточного видалення. Розуміння та захист кожної фази цього життєвого циклу є важливим для захисту конфіденційності, цілісності та доступності даних (також відомої як Тріада CIA).
Захист життєвого циклу даних є постійним викликом для більшості організацій. Ситуацію погіршує те, що дані стають дедалі ціннішими та схильними до незаконного використання. Зусилля з кібербезпеки повинні узгоджуватися з етапами життєвого циклу даних, щоб захистити конфіденційну інформацію від загроз, що постійно змінюються.
У цій публікації окреслено унікальні проблеми безпеки та практичні рекомендації щодо захисту даних вашої організації на кожному етапі. Завдяки проактивному підходу до кожного етапу життєвого циклу, організації можуть забезпечити надійний захист даних .
Ключові висновки:
  • Основні принципи безпеки даних: конфіденційність даних, цілісність даних та доступність даних
  • Фази життєвого циклу даних
  • Як кожна фаза життєвого циклу відповідає різним вимогам до відповідності
  • Рекомендації щодо посилення безпеки даних, такі як впровадження інструментів запобігання втраті даних
  • Ключові проблеми та рішення для кожного етапу життєвого циклу

Джерело:
https://cloudsecurityalliance.org/artifacts/cybersecurity-and-the-data-lifecycle


bga68comp: (Default)

Стан хмарних технологій та безпеки штучного інтелекту у 2025 році
Для кого це:
  • Керівники інформаційної безпеки (CISO)
  • Архітектори хмарної безпеки
  • Менеджери з ІТ та безпеки
  • Фахівці з IAM
  • Спеціалісти з управління ризиками та дотримання вимог

Стан хмарних технологій та безпеки штучного інтелекту у 2025 році

Дата виходу: 09/09/2025

Цей глобальний звіт про дослідження, розроблений у партнерстві з Tenable, досліджує, як організації адаптують стратегії безпеки для гібридних , багатохмарних та середовищ на основі штучного інтелекту . Спираючись на думки понад 1000 фахівців, він підкреслює зростаючий розрив між швидким впровадженням та готовністю до безпеки.
Сьогодні більшість організацій працюють у гібридних середовищах та використовують кількох хмарних провайдерів. Водночас робочі навантаження на основі штучного інтелекту швидко переходять у виробництво. Понад половина організацій впроваджують штучний інтелект, а 34% вже повідомляють про порушення, пов'язані зі штучним інтелектом. Незважаючи на це, програми безпеки залишаються реактивними, зосереджуючись на інцидентах, а не на запобіганні, та покладаючись на базові засоби контролю ідентифікації.
Цей звіт показує, що ідентифікація є найбільшим ризиком для хмарних технологій. У ньому також висвітлюється зростаючий дефіцит кваліфікованих кадрів та численні способи, якими організації залишають системи штучного інтелекту незахищеними. Він пропонує практичні рекомендації щодо переосмислення стратегій безпеки навколо єдиної видимості, управління ідентифікацією та проактивного управління ризиками.
Ключові висновки:
  • Понад половина організацій (63%) повідомляють, що використовують більше одного хмарного провайдера. Ще більше (82%) підтримують певний вид гібридної інфраструктури.
  • Багато організацій (59%) визначили незахищені ідентифікаційні дані та ризиковані дозволи як головний ризик безпеки для своєї хмарної інфраструктури. Однак багатьом із цих самих організацій бракує структури або робочих процесів для вирішення цих проблем у великих масштабах.
  • Брак досвіду є головною проблемою для забезпечення безпеки хмарної інфраструктури.
  • Найчастіше відстежуваним KPI хмарної безпеки є частота та серйозність інцидентів безпеки. В IAM головним показником є ​​рівень впровадження MFA/SSO. Організації, як і раніше, зосереджені на поверхневих показниках, а не на перспективних показниках ефективності.
  • Більше третини організацій із робочими навантаженнями, пов’язаними зі штучним інтелектом (34%), вже зіткнулися з порушенням, пов’язаним зі штучним інтелектом.
  • Лише 20% організацій надають пріоритет єдиній оцінці ризиків, і лише 13% зосереджуються на консолідації інструментів.

Джерело:
https://cloudsecurityalliance.org/artifacts/the-state-of-cloud-and-ai-security-2025


bga68comp: (Default)

DoD 5220.22-M — це стандарт Міністерства оборони США (Department of Defense), який визначає метод безпечного знищення (перезапису) даних на цифрових носіях, щоб запобігти їх відновленню.
Повна назва документа:
"National Industrial Security Program Operating Manual (NISPOM)" — DoD 5220.22-M

🔹 Що описує стандарт

У цьому документі наведено вимоги до того, як безпечно видаляти дані з носіїв (жорстких дисків, SSD, стрічок, тощо), щоб їх неможливо було відновити навіть спеціальними засобами.

🔹 Класичний метод DoD 5220.22-M (3-pass wipe)

Згідно з ним, дані мають бути перезаписані кілька разів:
  1. Перший прохід: записує випадкові або фіксовані символи (наприклад, 00000000);
  2. Другий прохід: записує протилежні біти (наприклад, 11111111);
  3. Третій прохід: записує випадкові символи та верифікує, що дані знищено.
Іноді використовують 7-pass або 35-pass (Gutmann) варіанти, але класичний 3-pass DoD 5220.22-M вважається достатнім для більшості випадків.

🔹 Навіщо це потрібно в політиках ІБ

У політиках PCI DSS, ISO 27001 або внутрішніх політиках ІБ цей стандарт згадується як приклад безпечного способу видалення даних, зокрема PAN або резервних копій, щоб унеможливити їх відновлення після закінчення терміну зберігання.

🔹 Приклад формулювання

“Видалення даних держателів платіжних карток здійснюється із застосуванням методів безпечного знищення, що відповідають вимогам стандарту DoD 5220.22-M або еквівалентним сучасним методам (наприклад, NIST SP 800-88 Rev.2 ‘Guidelines for Media Sanitization’).”
NIST SP 800-88 Rev. 2 Guidelines for Media Sanitization
NISP Operating Manual (DoD 5220.22-M)


ORM

2025-09-03 02:26
bga68comp: (Default)

ORM (Object-Relational Mapping / Об’єктно-реляційне відображення) — це програмна технологія, яка дозволяє працювати з базою даних не напряму через SQL-запити, а через об’єкти мови програмування.

Простими словами:

  • Без ORM: ви пишете SELECT * FROM users WHERE id=1;
  • З ORM: ви пишете User.find(1) і отримуєте об’єкт User, з яким можна працювати у коді.

Де застосовується

  • ORM є проміжним шаром (layer) між додатком і БД.
  • Він транслює методи й властивості об’єктів у SQL-запити і назад.
  • Це робить код простішим, зручнішим у підтримці та менш залежним від конкретної СУБД.

Приклади ORM

  • Java: Hibernate, EclipseLink
  • .NET: Entity Framework
  • Python: SQLAlchemy, Django ORM
  • Ruby: ActiveRecord
  • PHP: Doctrine, Eloquent (Laravel)


bga68comp: (Default)

У ISO/IEC/IEEE 42010 (Systems and Software Engineering — Architecture Description) є два близькі, але різні поняття:

Viewpoint (точка зору)

  • Визначення: це "шаблон" або правило, яке пояснює як і для кого треба створювати архітектурне подання.
  • Він відповідає на питання: які інтереси стейкхолдера ми показуємо, яку інформацію включаємо, якими засобами (діаграми, таблиці, текст) описуємо.
  • Простими словами: viewpoint — це інструкція або рецепт для створення подання.

View (подання)

  • Визначення: це конкретний результат застосування viewpoint до вашої системи.
  • Тобто це вже готова діаграма, таблиця чи текст, що показує систему під певним кутом зору.
  • Простими словами: view — це фото системи, зроблене за тим рецептом.

Приклад

Уявімо, що будуємо архітектуру для хмарної платформи:
  1. Stakeholder (зацікавлена сторона)
    • CIO (Chief Information Officer, директор з ІТ)
    • Його concern (потреба): чи масштабована система і як забезпечено інтеграцію між додатками?
  2. Viewpoint (точка зору на інтеграцію додатків)
    • Назва: Application Communication Viewpoint
    • Призначення: показати, як взаємодіють модулі та сервіси
    • Мова: UML Component Diagram або ArchiMate Application Collaboration
    • Яку інформацію включати: сервіси, API, протоколи, залежності
  3. View (конкретне подання)
    • Діаграма з Azure AD, веб-додатком на Ubuntu, RDS MySQL, інтеграцією з O365.
    • Тут видно, що користувачі логіняться через Entra ID, доступ йде через API-шлюз, БД інтегрується через ORM-шар.
    • Це вже готова картинка, яку CIO може подивитися.

🔹 Отже:
  • Viewpoint = каже: "покажи архітектуру додатків через компоненти і протоколи"
  • View = конкретна діаграма з вашим Entra ID, API Gateway і MySQL


bga68comp: (Default)

В чому незручність, коли використовують тільки одну методологію для опису архітектурних рівнів?

  • TOGAF дає методологію (ADM-фази, артефакти, каталоги, матриці), але іноді в ньому бракує гнучкості у формальному представленні результатів.
  • ISO/IEC/IEEE 42010 дає рамку опису архітектури: хто стейкхолдери, які їхні потреби (concerns), через які viewpoints ці потреби відображати, і у вигляді яких views це презентувати.
  • Якщо користуватися лише TOGAF — є ризик, що опис буде “каталог + текст”, але не зовсім зрозумілий різним групам зацікавлених сторін.
  • Якщо користуватися лише ISO 42010 — буде гарна структура “хто/що/для чого”, але без готових методичних кроків і артефактів (каталогів, матриць).

Комбінація TOGAF і ISO/IEC/IEEE 42010 методично сильніша, ніж використання кожного окремо: TOGAF забезпечує процес і набір артефактів, а ISO 42010 — формалізований спосіб представлення архітектури через стейкхолдерів, concerns і viewpoints. Разом вони дозволяють зробити опис не лише повним, а й зрозумілим для різних аудиторій.

Критерій TOGAF ISO/IEC/IEEE 42010 Разом (TOGAF + ISO 42010)
Призначення Методологія розробки архітектури (ADM, фази, артефакти) Рамка для опису архітектури (stakeholders, concerns, viewpoints, views) Повний цикл: розробка + формалізований опис
Сильна сторона Дає покроковий процес (ADM) і набір артефактів (каталоги, матриці) Дає чітку структуру для комунікації з різними стейкхолдерами Виходить і методика роботи, і методика подачі результатів
Слабка сторона Може вийти занадто “всередину ІТ”, важко донести до нефахівців Немає власної методики створення артефактів, лише правила їх опису Компенсують слабкі сторони один одного
Фокус Що і як робити (Data, Application, Technology, Business Architectures) Як показати і пояснити (concerns, viewpoints, views) І процес, і представлення зрозумілі й прозорі
Приклад результату Каталоги даних, матриці застосунків, моделі потоків Logical Data View, Security View, паспорти viewpoints Каталоги + матриці (TOGAF), оформлені у views для різних стейкхолдерів (ISO 42010)


Таким чином, можна сказати так — разом вони дають повну картину:
  • TOGAF = як і що робити (ADM, каталоги, матриці).
  • ISO 42010 = як правильно це описати й донести (stakeholders, concerns, viewpoints, views).

Див. також:
⋄ Приклад опису архітектури системи згідно TOGAF https://bga68comp.dreamwidth.org/787432.html


bga68comp: (Default)

Американська ІБ-фірма Hunted Labs провела дослідження і з'ясувала, що найпопулярніша Node.js-утиліта fast-glob підтримується лише однією людиною. І, судячи з його профілів у мережі, це розробник з Яндекса на ім'я Денис Малиночкін, який проживає в РФ.

photo_2025-08-27_22-35-15

Здавалося б, типова історія для Open Source. Але є нюанс. fast-glob скачали десятки мільйонів разів, вона є залежністю у 5000+ публічних проектах, а найцікавіше, що вона використовується як мінімум у 30 проектах Міністерства оборони США (DoD). Більше того, вона включена до Iron Bank, а це довірений репозиторій ПЗ, який Пентагон використовує для своїх систем 🎩

Дослідники уточнюють, що fast-glob не має відомих уразливостей (CVE), а до самого розробника немає жодних претензій. А проблема у самій моделі загроз. Найпопулярніший пакет із глибоким доступом до файлової системи, який є частиною критичної інфраструктури СЩА, підтримується одним Денисом із підмосков'я без будь-якого зовнішнього контролю 😗

Хлопці з Hunted Labs повідомили про свої знахідки до Пентагону ще три тижні тому. Особливо іронічно це виглядає на тлі нещодавньої директиви міністра оборони США, яка забороняє закуповувати програмне забезпечення, схильне до іноземного впливу.

Відчуваєте, що скрізь все одно? 🤔 Ідеальний приклад того, як насправді влаштований сучасний ланцюжок поставок ПЗ.

© Типичный 🥸 Сисадмин (https://t.me/+ksMnj1y9FaAyMGJi)


bga68comp: (Default)
© https://www.linkedin.com ... 7366376703905968128
    •  
    • Все в LinkedIn и за пределами сайта
    𝗖𝗼𝗺𝗽𝗧𝗜𝗔 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆+ is a foundational, vendor-neutral certification for IT security professionals, focusing on practical skills for real-world cybersecurity. The 𝗦𝗬𝟬-𝟳𝟬𝟭 𝘃𝗲𝗿𝘀𝗶𝗼𝗻 updates content to include automation, zero trust, and IoT security.
    🟢 𝗖𝗼𝗿𝗲 𝗘𝗹𝗲𝗺𝗲𝗻𝘁𝘀 𝗼𝗳 𝗖𝗼𝗺𝗽𝗧𝗜𝗔 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆+ (𝗦𝗬𝟬-𝟳𝟬𝟭 𝗘𝘅𝗮𝗺 𝗗𝗼𝗺𝗮𝗶𝗻𝘀):
    1️⃣ 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗙𝘂𝗻𝗱𝗮𝗺𝗲𝗻𝘁𝗮𝗹𝘀 & 𝗖𝗼𝗻𝘁𝗿𝗼𝗹𝘀:
    Understanding core security principles (CIA triad, Zero Trust) and applying various security controls (technical, physical, managerial) and cryptographic solutions.
    2️⃣ 𝗧𝗵𝗿𝗲𝗮𝘁𝘀, 𝗩𝘂𝗹𝗻𝗲𝗿𝗮𝗯𝗶𝗹𝗶𝘁𝗶𝗲𝘀 & 𝗠𝗶𝘁𝗶𝗴𝗮𝘁𝗶𝗼𝗻:
    Identifying diverse cyber threats, common attack vectors, system vulnerabilities, and implementing techniques to reduce risk.
    3️⃣ 𝗦𝗲𝗰𝘂𝗿𝗲 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲:
    Designing and securing enterprise infrastructure across various models like cloud, IoT, and on-premises, with a focus on data protection and system resilience.
    4️⃣ 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗢𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝘀:
    Executing day-to-day security tasks, including asset management, vulnerability management, monitoring, incident response, and applying secure operational techniques.
    5️⃣ 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗣𝗿𝗼𝗴𝗿𝗮𝗺 𝗠𝗮𝗻𝗮𝗴𝗲𝗺𝗲𝗻𝘁:
    Managing security governance, risk assessment, compliance, third-party risks, and fostering security awareness within an organization.

    𝗖𝗼𝗺𝗽𝗧𝗜𝗔 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆+ aims to equip IT professionals with the essential knowledge and skills to assess security postures, implement solutions, monitor environments, and manage security programs effectively in today's dynamic cybersecurity landscape.

    ✨ Follow NOMAN RAHEEM for more insightful content on Cybersecurity 🛡️, GRC ⚙️ and emerging technologies

bga68comp: (Default)

Перелік офіційних джерел, з яких можемо брати формулювання термінів інформаційної безпеки:

1. ISO OBP (Online Browsing Platform) — офіційна база ISO

📎 https://www.iso.org/obp/ui/

  • Це єдине офіційне джерело текстів і термінів міжнародних стандартів ISO (у межах відкритих частин).
  • Тут можна безкоштовно переглядати визначення термінів, структуру стандарту, іноді — окремі розділи.
  • Приклад: зручний централізований пошук термінів Новий ISO DIS 27000:2024 на Online Browsing Platform (OBP)

2. IEC (International Electrotechnical Commission) — міжнародна електротехнічна комісія

📎 https://www.iec.ch/
📎 Сторінка термінів IEC: https://www.electropedia.org/

  • IEC відповідає за стандарти в галузі електротехніки, електроніки та суміжних сфер.
  • «Electropedia» — офіційний словник IEC з понад 20 000 термінів кількома мовами.

3. ITU (International Telecommunication Union) — міжнародний союз електрозв’язку

📎 https://www.itu.int/
📎 ITU-T Resources: https://www.itu.int/en/ITU-T/info/Pages/resources.aspx
📎 ITU Search: https://www.itu.int/search
📎 ITUSearch Deep search for documents: https://www.itu.int/net4/ITU-T/search
📎 Фокус-група з управління ідентифікацією (FG IdM). Технічне завдання:
  https://www.itu.int/ITU-T/studygroups/com17/fgidm/tor.html

  • ITU розробляє стандарти в галузі телекомунікацій та ІКТ (серії рекомендацій ITU-T).
  • Офіційна база термінів ITU дозволяє шукати визначення англійською, французькою, іспанською.

4. ETSI (European Telecommunications Standards Institute) — європейський інститут телекомунікаційних стандартів

📎 https://www.etsi.org/
📎 Пошук стандартів: https://www.etsi.org/standards/search

  • ETSI розробляє стандарти для мобільного зв’язку, мереж 5G, кібербезпеки, IoT.
  • Часто в їхніх специфікаціях є власні глосарії термінів, доступні у PDF.


bga68comp: (Default)

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

NIST (National Institute of Standards and Technology) — Glossary

📎 https://csrc.nist.gov/glossary
чи
📎 https://csrc.nist.gov/publications

Цитата:
Цей глосарій є сукупністю термінів і визначень, зазначених у стандартах кібербезпеки та конфіденційності NIST, інструкціях та інших технічних публікаціях, а також у CNSSI 4009. Їх не слід розглядати як «офіційні» або «бажані» визначення для певної предметної області, сектора або галузі, за винятком того, що деякі визначення цитуються безпосередньо із законів США, Кодексу федеральних правил, президентських директив тощо.

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

  • Посилайтеся на джерело публікації, а не на цей сайт. У міру публікації та відкликання наших документів термінологія на цих веб-сторінках змінюватиметься. При цитуванні термінів та визначень ми заохочуємо вас посилатися на джерело публікації для отримання авторитетної термінології та розуміти її в належному контексті. Багато термінів на цьому веб-сайті мають різні визначення, отримані в багатьох публікаціях.
  • Публічний внесок. Ми запрошуємо громадськість висловлювати свої зауваження, включно з пропозиціями щодо термінології, до наших чернеток публікацій і вітаємо ваш внесок.
  • Термінологія штучного інтелекту (ШІ). Термінологію, орієнтовану на штучний інтелект, можна знайти в глосарії, доступному в Ресурсному центрі NIST Trustworthy & Responsible AI.


bga68comp: (Default)

Hackers разные важны, hackers разные нужны.
Purple Team


bga68comp: (Default)

Коли описують архітектуру інформаційної системи відповідно до TOGAF (The Open Group Architecture Framework) або ISO/IEC/IEEE 42010 (Системна та програмна інженерія — Архітектурний опис), використовують набір структурованих діаграм, які відображають різні аспекти системи.

Ці діаграми не є строго фіксованими, але часто стандартизуються в межах архітектурних поглядів (views) та представлень (viewpoints).

🔸 Основні категорії діаграм (за TOGAF + ISO 42010)

Категорія діаграм Назва погляду (view) Назва типових діаграм Призначення
Бізнес-архітектура Business Architecture View ▫️ Business Process Diagram (BPD)
▫️ Organizational Chart
▫️ Actor-Role diagrams
Моделює бізнес-функції, процеси, ролі та організаційну структуру
Інформаційна/дані Data Architecture View ▫️ Data Entity Relationship Diagram (ERD)
▫️ Class Diagram (UML)
▫️ Data Flow Diagram (DFD)
Відображає структуру даних, об’єкти, зв’язки, потоки даних
Системна/аплікаційна Application Architecture View ▫️ Application Communication Diagram
▫️ Component Diagram
▫️ Application Interaction Matrix
Відображає аплікації, сервіси, їх взаємодію, залежності
Технологічна/інфраструктурна Technology Architecture View ▫️ Network Diagram
▫️ Infrastructure Landscape
▫️ Deployment Diagram
▫️ Platform Diagram
Показує хостинг, сервери, мережеву структуру, розгортання
Безпекова архітектура Security Architecture View ▫️ Trust Boundary Diagram
▫️ Security Zones
▫️ Access Control Model ▫️ Threat Modeling Diagram
Відображає зони довіри, політики доступу, загрози, контролі
Архітектура рішень Solution Architecture View ▫️ Solution Overview Diagram
▫️ Use Case Diagram
▫️ Sequence Diagram
Описує рішення, інтеграції, сценарії використання
Мотиваційна Motivation View ▫️ Goal Diagram
▫️ Requirements Diagram (SysML)
▫️ Stakeholder Map
Визначає цілі, мотивацію, потреби та вимоги зацікавлених сторін
Операційна Operational View ▫️ Workflow Diagrams
▫️ Activity Diagram
▫️ Event-Driven Process Chains
Моделює робочі потоки, сценарії, автоматизацію
Архітектура безперервності / відновлення Continuity / Disaster View ▫️ DR/BCP Architecture Diagram
▫️ Backup & Failover Plan
Відображає резервування, відновлення, відмовостійкість


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



bga68comp: (Default)


🔐 18 Критично важливих заходів захисту CIS
CIS Critical Security Controls (CIS Controls) — це приписуваний, пріоритетний і спрощений набір найкращих практик, який ви можете використовувати для зміцнення вашої кібербезпеки.

Остання версія, CIS Controls v8.1, включає оновлене узгодження з новими стандартами та галузевими фреймворками, переглянуті класи активів і описи заходів безпеки (Safeguards), а також нову функцію «Управління» (Governance) у сфері безпеки.

CIS Controls List

🔹 CIS Control 1: Інвентаризація та контроль активів підприємства
Активне управління (облік, відстеження, коригування) всіма активами підприємства (пристрої кінцевих користувачів, включаючи портативні й мобільні; мережеві пристрої; непроцесорні/IoT-пристрої; сервери), підключеними до інфраструктури фізично, віртуально, віддалено або у хмарі, для повного розуміння обсягу активів, які потрібно контролювати й захищати. Це також допомагає виявляти несанкціоновані або неуправлювані активи.

🔹 CIS Control 2: Інвентаризація та контроль програмних активів
Активне управління (облік, відстеження, коригування) всім програмним забезпеченням (ОС і застосунки) у мережі, щоб дозволити лише авторизоване ПЗ та запобігти встановленню чи виконанню несанкціонованого ПЗ.

🔹 CIS Control 3: Захист даних
Розробка процесів і технічних заходів для ідентифікації, класифікації, безпечного оброблення, зберігання та знищення даних.
Read more... )
Джерело:
 📎 https://www.cisecurity.org/controls/cis-controls-list


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


Profile

bga68comp: (Default)
bga68comp

December 2025

S M T W T F S
  12 3 456
7891011 1213
14151617181920
21222324252627
28293031   

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated 2025-12-25 13:37
Powered by Dreamwidth Studios