![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Принципово важливо, що вибір заходів захисту в логіці NIST не є довільним. Він базується на встановлених базових лініях заходів і подальшому їх адаптуванні до конкретної системи. Це означає, що організація свідомо обирає, які заходи є необхідними, які — надлишковими, а які потребують посилення з урахуванням реального контексту використання системи, а не формальних вимог.
Принципово важливо, що вибір заходів захисту в логіці NIST не є довільним. Він базується на встановлених базових лініях заходів і подальшому їх адаптуванні до конкретної системи. Це означає, що організація свідомо обирає, які заходи є необхідними, які — надлишковими, а які потребують посилення з урахуванням реального контексту використання системи, а не формальних вимог.
NIST українською
2026-01-24 15:23Державна служба спеціального зв'язку та захисту інформації виклала переклад українською:
NIST Special Publication 800-181 Rev. 1 Загальні принципи управління персоналом у сфері кібербезпеки (Загальні принципи NICE)!
Джерело:
https://lnkd.in/dNeW7ZFK
Також цікавим буде документ "Порівняльний аналіз професійних кваліфікацій (ПК) за «Класифікатором професій» ДК 003:2010 стандартом NIST 800-181 USA, рамкою компетентностей ECSF"
Джерело:
https://lnkd.in/dFfmMJBP
Дякую!
LinkedIn:
https://www.linkedin.com/posts/g-b-56429176_державна-служба-спеціального-звязку-та-захисту-activity-7420817951009849344-f31i/
Державна служба спеціального зв'язку та захисту інформації виклала переклад The NIST Cybersecurity Framework (CSF) 2.0 українською:
© https://cip.gov.ua › api › attachment › https://cip.gov.ua/services/cm/api/attachment/download?id=62934
DoD 5220.22-M
2025-10-29 21:20DoD 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)
Згідно з ним, дані мають бути перезаписані кілька разів:- Перший прохід: записує випадкові або фіксовані символи (наприклад,
00000000); - Другий прохід: записує протилежні біти (наприклад,
11111111); - Третій прохід: записує випадкові символи та верифікує, що дані знищено.
🔹 Навіщо це потрібно в політиках ІБ
У політиках 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)
Безкоштовні американські тренінги по 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
🔹 Zero Trust Reference Architecture (NIST SP 800-207)
Хронології Zero Trust:
Теж саме у вигляді таблиці:
🛡️ Zero Trust Architecture (ZTA)
📎 https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity
Хронології Zero Trust:
- 2009 — Джон Кіндерваг (Forrester) вводить термін Zero Trust як альтернативу класичній моделі «довіри всередині периметра».
- 2010–2012 — Google запускає власну архітектуру 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
У Майкрософт є цікавий ресурс для тих, хто займається побудовою процесів інформаційної безпеки.
Він знаходиться за адресою:
Microsoft compliance offerings:
Пропозиції Microsoft щодо відповідності вимогам
( Read more... )
Наприклад, можна офіційно і без обмежень багато інформації про ШІ отримати тут:
https://learn.microsoft.com/uk-ua/compliance/regulatory/offering-iso-42001
Огляд ISO/IEC 42001:2023
( Read more... )
Якщо шукаємо терміни інформаційної безпеки у 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.
Коли описують архітектуру інформаційної системи відповідно до 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
Щодо шаблонів рівнів архітектури ІТ-систем.
Доповнення до опису архітектури за посиланнями:
• Приклад опису архітектури системи згідно 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
Щодо шаблонів рівнів архітектури ІТ-систем.
Доповнення до опису архітектури за посиланнями:
• Приклад опису архітектури системи згідно TOGAF
• Побудова віртуальної інфраструктури на базі Microsoft Azure
• Інформаційна архітектура ІТ-системи компанії. Приклад
Відповідність між компонентами, заходами захисту ISO/IEC 27001:2022 та відповідними родинами заходів захисту NIST SP 800-53 Rev. 5.
Мапінг компонентів на NIST SP 800-53 Rev. 5
| № | Компонент | ISO/IEC 27001:2022 | NIST SP 800-53 Rev. 5 |
|---|---|---|---|
| 1 | Віртуальна мережа (VNet) | A.8.20, A.8.21, A.8.22, A.5.15, A.5.18 | AC-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.22 | SC-7, SC-5 (Denial-of-Service Protection) |
| 3 | DNS-сервер | A.8.6, A.8.9, A.8.25, A.8.27 | CM-2 (Baseline Config), SI-2 (Flaw Remediation), SA-3 (System Development Process), SA-8 (Security Engineering) |
| 4 | Контролер домену (DC1, DC2) | A.5.16, A.5.17 | IA-2 (User Identification & Authentication), IA-5 (Authenticator Management) |
| 5 | Файловий сервер (FS1) | A.5.9, A.5.10, A.5.15, A.5.18 | AC-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.4 | AC-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.22 | SA-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.22 | SA-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.16 | AC-4, SC-7, AU-6 (Audit Review), AU-12 (Audit Generation) |
| 10 | Azure Backup | A.8.13 | CP-9 (Information System Backup), CP-10 (Recovery and Reconstitution) |
| 11 | Моніторинг і логування (Azure Monitor, Log Analytics) | A.8.15, A.8.16 | AU-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.27 | SC-5, SC-7, SA-8, AC-17, CA-3 |
Додатково:
Коментарі до основних родин заходів захисту NIST
→ https://bga68comp.dreamwidth.org/804396.html
Коментарі до основних родин заходів захисту 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 (реакція на інциденти)
Термін framework
2025-04-11 19:40У контексті інформаційної безпеки (ІБ) слово "framework" українською найчастіше перекладається як:
🔹 Фреймворк — транслітерований варіант, часто вживається у професійному ІТ-середовищі (наприклад, NIST Cybersecurity Framework — Фреймворк кібербезпеки NIST).
🔸 Рамкова модель або рамкова структура — офіційно вживаний переклад у нормативних документах (наприклад, рамкова структура управління ризиками).
🔹 Концептуальна модель — якщо йдеться про абстрактну, методологічну основу.
🔸 Методологія — коли фреймворк описує процеси та принципи роботи.
🔹 Система (управління/захисту/оцінки) — у вільному перекладі, щоб зробити текст доступнішим.
Приклади перекладу:
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 процессов
COBiT5: Внедрение
Скачать на официальном сайте: http://www.isaca.org/COBIT/Pages/COBIT-5-russian.aspx
Совершенствование процесса управления правами доступа и повышение его эффективности осуществляется за счет следующих активностей:
- Анализа мирового опыта и ведущих мировых практик, которые включают, но не ограничиваются:
- ISO 27002 (А 11)
- COBIT5 Enabling Processes (см.процесс DSS 05)
- ITIL (см. Service operation: Access management)
- NIST SP 800-53 (Security control: «Access Control»)
ISO/IEC 27000 glossary standard - https://bga68.livejournal.com/553511.html
Overview of Information Security Management Standard - https://bga68.livejournal.com/541166.html
COBiT - https://bga68.livejournal.com/599641.html
NIST - https://bga68.livejournal.com/tag/nist
ITIL - https://bga68.livejournal.com/tag/itil
Microsoft заявила, что правило сброса пароля по истечению срока его действия является бессмысленным с точки зрения безопасности. В связи с этим компания планирует исключить эту опцию из базовых параметров безопасности в Windows 10 (1903), Windows Server (1903) и в будущих версиях операционной системы.
| ” | «Когда люди выбирают пароль, его зачастую можно легко угадать или предсказать. Когда заставляют создавать сложные пароли или выдают уже сгенерированные варианты, которые трудно запомнить, они записывают их там, где их могут видеть другие. Когда людям приходится менять пароли, они обычно вносят небольшие и предсказуемые изменения в существующие пароли, чтобы их не забыть», – говорится в блоге Microsoft. |
В компании признают, что принуждение пользователей регулярно менять пароли ставит под сомнение ценность многих давних методов обеспечения безопасности, поэтому лучше использовать более эффективные способы аутентификации. Как бы там ни было, Microsoft не первая, кто сделал такое заявление. Эксперты по безопасности годами жаловались на то, что принудительная смена пароля не решает проблему безопасности. Два года назад этот вопрос поднимала и Федеральная торговая комиссия (FTC). Но раньше всех был Национальный институт стандартов и технологий США (NIST), который раскритиковал эту практику ещё десять лет назад.
В блоге Microsoft представлен более широкий набор базовых параметров безопасности, которые софтверный гигант будет рекомендовать компаниям и организациям, использующим программное обеспечение Microsoft. Фактически, компания предлагает избегать типичных запрещённых паролей и переходить на многофакторную аутентификацию. Кроме того, по мнению Microsoft, пароль нужно менять не по расписанию, а при подозрении о возможной утечке.
Перепечатка:
26.04.2019См. также:
В блоге Microsoft представлен более широкий набор базовых параметров безопасности, которые софтверный гигант будет рекомендовать компаниям и организациям, использующим программное обеспечение Microsoft. Фактически, компания предлагает избегать типичных запрещённых паролей и переходить на многофакторную аутентификацию. Кроме того, по мнению Microsoft, пароль нужно менять не по расписанию, а при подозрении о возможной утечке.
Перепечатка:
26.04.2019См. также:
- Базовые параметры безопасности Windows - https://docs.microsoft.com/ru-ru/windows/security/threat-protection...
- Набор средств обеспечения соответствия требованиям безопасности (SCT) - https://docs.microsoft.com/ru-ru/windows/security/threat-protection...
- Windows 10. Windows Server. Базовая безопасность - https://bga68.livejournal.com/522156.html
NIST Cyber Security Framework
© The Cyber Security Hub
Перейти на начальную страницу https://bga68.livejournal.com
© The Cyber Security Hub
Перейти на начальную страницу https://bga68.livejournal.com
09:46 / 11 Декабря, 2017
NIST ОПУБЛИКОВАЛ ПРОЕКТ НОВОЙ ВЕРСИИ РУКОВОДСТВА ПО ЗАЩИТЕ ОТ КИБЕРУГРОЗ
Все федеральные агентства и операторы критической инфраструктуры США обязаны придерживаться данных рекомендаций.
Национальный институт стандартов и технологий США (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
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!