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)


bga68comp: (Default)

Безкоштовні американські тренінги по NIST SP 800-53

Online Introductory Courses Available for NIST SP 800-53, SP 800-53A, and SP 800-53B



Security and Privacy Controls Introductory Course

Вступний курс із засобів захисту та конфіденційності.
Курс, що базується на стандарті SP 800-53 «Security and Privacy Controls for Information Systems and Organizations/Засоби захисту та конфіденційності для інформаційних систем і організацій», знайомить із каталогом засобів захисту SP 800-53 та кожним сімейством засобів захисту.

Assessing Security and Privacy Controls Introductory Course

Вступний курс з оцінки засобів захисту та конфіденційності.
Курс, що базується на стандарті SP 800-53A «Assessing Security and Privacy Controls in Information Systems and Organizations/Оцінювання засобів захисту та конфіденційності в інформаційних системах і організаціях», охоплює методологію оцінки заходів захисту, визначених у стандарті SP 800-53. У матеріалі також пояснюється структура процедур оцінки (assessment procedures) та цілі оцінки (assessment objectives).


Control Baselines Introductory Course

Вступний курс «Базові рівні захисту».
Курс, що базується на стандарті SP 800-53B «Control Baselines for Information Systems and Organizations/Базові рівні захисту для інформаційних систем та організацій», надає огляд базових профілів засобів захисту та конфіденційності, а також рекомендації щодо їх адаптації (tailoring guidance).



Нові вступні онлайн-курси тривають від 45 до 60 хвилин і доступні безкоштовно, реєстрація не потрібна. Усі курси, включаючи вступний курс RMF, доступні за адресою
 📎https://csrc.nist.gov/Projects/risk-management/rmf-courses
 📎https://csrc.nist.gov/News/2024/online-intro-courses-for-nist-sp-800-53



bga68comp: (Default)
🔹 Zero Trust Reference Architecture (NIST SP 800-207)

Хронології Zero Trust:

  • 2009 — Джон Кіндерваг (Forrester) вводить термін Zero Trust як альтернативу класичній моделі «довіри всередині периметра».
  • 2010–2012Google запускає власну архітектуру BeyondCorp після атак Operation Aurora.
  • 2014–2019 — Вендори (Cisco, Palo Alto, Microsoft, Zscaler) починають випускати комерційні рішення на основі ZT.
  • 2020 — Виходить NIST SP 800-207, який формалізує Zero Trust Architecture (ZTA) як фреймворк.
  • 2021–2023 — В США стає обов’язковим впровадження ZTA у федеральних агентствах (указ президента Байдена, EO 14028).

Теж саме у вигляді таблиці:

🛡️ Zero Trust Architecture (ZTA)

Рік Подія
2009 Джон Кіндерваг (Forrester) вводить термін Zero Trust як противагу класичній моделі "довіри всередині периметра".
2010–2012 Google починає будувати власну Zero Trust архітектуру під назвою BeyondCorp після атак Operation Aurora.
2014–2019 Вендори (Cisco, Palo Alto, Microsoft, Zscaler) починають впроваджувати комерційні рішення на основі ZT.
2020 NIST SP 800-207 — офіційний урядовий документ, який формалізує Zero Trust Architecture (ZTA) як фреймворк.
2021–2023 В США введено обов'язкове впровадження ZTA для всіх федеральних агентств згідно з указом президента Байдена (EO 14028).

📎 https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity


bga68comp: (Default)

У Майкрософт є цікавий ресурс для тих, хто займається побудовою процесів інформаційної безпеки.
Він знаходиться за адресою:
Microsoft compliance offerings:

Пропозиції Microsoft щодо відповідності вимогам


Screenshot 2025-09-16 234034
Read more... )
Наприклад, можна офіційно і без обмежень багато інформації про ШІ отримати тут:

https://learn.microsoft.com/uk-ua/compliance/regulatory/offering-iso-42001

Огляд ISO/IEC 42001:2023


Read more... )


bga68comp: (Default)
Original:
https://www.linkedin.com/posts/the-tech-talks_cybersecurity-riskmanagement-riskassessment-activity-7373030293143748609-ef-6

26 449 отслеживающих • Все в LinkedIn и за пределами сайта
⚠️ 𝗥𝗶𝘀𝗸 𝗔𝘀𝘀𝗲𝘀𝘀𝗺𝗲𝗻𝘁: 𝗧𝗵𝗲 𝗙𝗼𝘂𝗻𝗱𝗮𝘁𝗶𝗼𝗻 𝗼𝗳 𝗖𝘆𝗯𝗲𝗿𝘀𝗲𝗰𝘂𝗿𝗶𝘁𝘆 ⚠️

Every strong cybersecurity strategy starts with one critical process: Risk Assessment. Without it, organizations are blind to where their true vulnerabilities lie.

Here’s the step-by-step process:
1️⃣ Identify Assets & Data – List hardware, software, networks, and applications that need protection.
2️⃣ Identify Threats – Brainstorm possible cyber threats targeting those assets.
3️⃣ Identify Vulnerabilities – Map out weaknesses that could be exploited.
4️⃣ Determine Likelihood – Assess the chances of an attack based on motives & attacker capabilities.
5️⃣ Determine Impact – Estimate the potential business damage if a threat is successful.
6️⃣ Determine Risk Score – Multiply likelihood × impact to calculate risk levels.
7️⃣ Compare With Risk Appetite – Decide if the risk is acceptable or requires treatment.
8️⃣ Risk Treatment – Apply security controls to mitigate unacceptable risks.
9️⃣ Document & Monitor – Continuously track, update, and refine risk assessments.

🔐 A well-executed risk assessment doesn’t just check compliance boxes—it enables smarter decision-making, prioritization, and proactive defense.

👉 How often does your organization perform risk assessments—quarterly, annually, or continuously?

🔔 Follow Tech Talks for expert tips and updates on top tech courses like Cybersecurity, BigData, DevOps, AI, ML, Development, Testing, Marketing & more!



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)

Коли описують архітектуру інформаційної системи відповідно до 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)

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

Доповнення до опису архітектури за посиланнями:
Приклад опису архітектури системи згідно 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


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


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 (реакція на інциденти)


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 Фреймворк управління / Модель управління


bga68comp: (Default)
 
COBIT 5 – это всеобъемлющая бизнес-модель по руководству и управлению ИТ на предприятии. Настоящий документ включает описание пяти принципов COBIT 5 и определяет семь факторов влияния, которые вместе формируют основу методологии.
COBIT 5 Russian
COBIT 5 Information Security Russian
COBIT 5 for Assurance Russian
Assessor Guide: Using COBIT 5 Russian
PAM Using COBIT 5 Russian


COBIT 5 представляет собой всеобъемлющую структуру общепринятых принципов, практик, аналитических инструментов и моделей, которые могут помочь любому предприятию эффективно решать важнейшие вопросы бизнеса, связанные с руководством и управлением информацией и технологиями.

1-е издание - 1996 г.
2-е издание - 1998 г.
3-е издание - 2000 г.
4-е издание - 2005 г.
5-е издание - 2012 г.

COBiT 5: История "поглощений"


COBiT 5: 5 доменов, 37 процессов

cobit-5-domains

COBiT5: Внедрение
cobit-5-implementation

Скачать на официальном сайте: http://www.isaca.org/COBIT/Pages/COBIT-5-russian.aspx

bga68comp: (Default)
 
iso27001 logo

Совершенствование процесса управления правами доступа и повышение его эффективности осуществляется за счет следующих активностей:
bga68comp: (Default)


Microsoft заявила, что правило сброса пароля по истечению срока его действия является бессмысленным с точки зрения безопасности. В связи с этим компания планирует исключить эту опцию из базовых параметров безопасности в Windows 10 (1903), Windows Server (1903) и в будущих версиях операционной системы.

«Когда люди выбирают пароль, его зачастую можно легко угадать или предсказать. Когда заставляют создавать сложные пароли или выдают уже сгенерированные варианты, которые трудно запомнить, они записывают их там, где их могут видеть другие. Когда людям приходится менять пароли, они обычно вносят небольшие и предсказуемые изменения в существующие пароли, чтобы их не забыть», – говорится в блоге Microsoft.

В компании признают, что принуждение пользователей регулярно менять пароли ставит под сомнение ценность многих давних методов обеспечения безопасности, поэтому лучше использовать более эффективные способы аутентификации. Как бы там ни было, Microsoft не первая, кто сделал такое заявление. Эксперты по безопасности годами жаловались на то, что принудительная смена пароля не решает проблему безопасности. Два года назад этот вопрос поднимала и Федеральная торговая комиссия (FTC). Но раньше всех был Национальный институт стандартов и технологий США (NIST), который раскритиковал эту практику ещё десять лет назад.

В блоге Microsoft представлен более широкий набор базовых параметров безопасности, которые софтверный гигант будет рекомендовать компаниям и организациям, использующим программное обеспечение Microsoft. Фактически, компания предлагает избегать типичных запрещённых паролей и переходить на многофакторную аутентификацию. Кроме того, по мнению Microsoft, пароль нужно менять не по расписанию, а при подозрении о возможной утечке.

Перепечатка:
26.04.2019См. также:

bga68comp: (Default)

NIST ОПУБЛИКОВАЛ ПРОЕКТ НОВОЙ ВЕРСИИ РУКОВОДСТВА ПО ЗАЩИТЕ ОТ КИБЕРУГРОЗ



image
Все федеральные агентства и операторы критической инфраструктуры США обязаны придерживаться данных рекомендаций.

Национальный институт стандартов и технологий США (NIST) опубликовал вторую редакцию руководства по усилению кибербезопасности в критической инфраструктуре NIST Cybersecurity Framework.

Первый вариант рекомендаций, опубликованный в 2014 году, был призван помочь организациям, в частности в сфере критически важной инфраструктуры, лучше защищаться от киберугроз. Руководство было разработано по приказу бывшего президента США Барака Обамы. Все федеральные агентства и операторы критической инфраструктуры США обязаны придерживаться данных рекомендаций.

Спустя четыре года с момента выхода первого варианта Cybersecurity Framework, институт взялся за разработку обновленной версии. Первая редакция была опубликована в январе 2017 года, вторая - 5 декабря 2017 года.

Согласно заявлению NIST, вторая редакция версии 1.1 фокусируется на разъяснении, уточнении и расширении руководства, облегчая его использование, а также содержит обновленную «дорожную карту», в которой подробно описываются планы по дальнейшей разработке руководства.

Комментарии и отзывы по второй редакции могут быть отправлены в NIST до 19 января 2018 года. Изначально институт собирался опубликовать окончательный вариант руководства осенью текущего года, однако отстал от графика и теперь публикация запланирована на начало 2018 года.

Национальный институт стандартов и технологий США (The National Institute of Standards and Technology, NIST) - подразделение Управления по технологиям, одного из агентств Министерства торговли США. Основной задачей института является продвижение инновационной и индустриальной конкурентоспособности США путем развития наук об измерениях, стандартизации и технологий с целью повышения экономической безопасности и улучшения качества жизни.

Подробнее: https://www.securitylab.ru/news/490200.php?R=1




По сути введено понятие инцидента кибербезопасности

Cybersecurity Incident - A cybersecurity event that has been determined to have an impact on the organization prompting the need for response and recovery.

вольный перевод:

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

Appendix B: Glossary.

Table 3: Framework Glossary

Framework for Improving Critical Infrastructure Cybersecurity
https://www.nist.gov/sites/default/files/documents/2017/12/05/draft-2_framework-v1-1_with-markup.pdf

Version 1.01 Draft 2

National Institute of Standards and Technology

February 12, 2014

Revised December 5, 2017

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 2026-01-03 20:15
Powered by Dreamwidth Studios