bga68comp: (Default)

  • Зіставлення та переходи між 800-53 Rev. 5 та іншими моделями/структурами управління та стандартами ( NIST Cybersecurity Framework та NIST Privacy Framework ; ISO/IEC 27001:2022 ).
    Зіставлення та переходи надають загальне уявлення про охоплення контролем SP 800-53 стосовно інших рамок та стандартів. Використовуючи ці зв'язки, враховуйте обсяг та цільове використання кожної публікації. Не припускайте еквівалентності виключно на основі таблиць зв'язків; зіставлення та переходи не завжди є взаємно однозначними, а аналіз зв'язків може бути суб'єктивним.
  • Mappings and crosswalks between 800-53 Rev. 5 and other frameworks and standards (NIST Cybersecurity Framework and NIST Privacy FrameworkISO/IEC 27001:2022)
    Mappings and crosswalks provide a general indication of SP 800-53 control coverage with respect to other frameworks and standards. When leveraging these relationships, consider the scope and intended use of each publication. Do not assume equivalency based solely on relationship tables; mappings and crosswalks are not always one-to-one and relationship analysis can be subjective.

 


bga68comp: (Default)

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


bga68comp: (Default)

Пояснення CERT-UA. Як відновити роботу компанії після кібератаки: покрокова інструкція


27.08.2025 13:30


Під час реагування та відновлення компанії після атаки пропонуємо використовувати стандартизовані кроки реагування за кращими практиками та підходами щодо реагування на основі моделі реагування від SANS Institute (американська компанія, що спеціалізується на навчанні та сертифікації фахівців з кібербезпеки), яка має назву PICERL.

Етап 1: Підготовка (Preparation)

Цей етап виконується до інциденту. Його мета – бути готовим до атаки, а не реагувати хаотично:
• розробіть та затвердьте план реагування на кіберінциденти;
• сформуйте команду, чітко визначте ролі та зони відповідальності кожного її учасника;
• підготуйте необхідні інструменти (резервні копії, «чисті» образи систем, засоби аналізу) та канали екстреного зв’язку.

Етап 2: Ідентифікація (Identification)

Після виявлення аномалії необхідно точно встановити факт інциденту, його джерело та масштаби. Спершу необхідно розібратись, чи справді це інцидент, а не технічний збій Зберіть первинні дані із систем моніторингу (SIEM, EDR), антивірусів, журналів подій.
Далі потрібно провести аналіз і дати відповіді на низку питань: як зловмисники потрапили до системи (фішинг, вразливість, злам облікового запису), коли відбулася початкова компрометація, а також які системи, облікові записи та дані було скомпрометовано

Етап 3: Стримування (Containment)

Головне завдання – негайно зупинити поширення загрози та обмежити збитки:
• негайно ізолюйте уражені системи від мережі. Це можна зробити фізичним від’єднанням кабелю або програмним блокуванням на рівні мережевого обладнання;
• змініть паролі для всіх скомпрометованих облікових записів, а також для всіх адміністративних та сервісних акаунтів;
• не перезавантажуйте уражені системи без крайньої потреби. Створіть образи дисків та копії оперативної пам’яті для подальшого розслідування (форензики).

Етап 4: Усунення загрози (Eradication)

На цьому етапі відбувається повне видалення всіх компонентів загрози та усунення першопричини атаки. Це не просто видалення вірусу. Ми радимо оновити програмне забезпечення до актуальних версій, з метою усунення вразливостей. Також рекомендуємо заблокувати скомпрометовані облікові записи та перегляyти мережеву інфраструктуру — від принципів сегментації до переліку сервісів, відкритих для зовнішнього доступу.
Повністю видаліть усі файли, процеси та записи в реєстрі, пов’язані зі шкідливим програмним забезпеченням.

Етап 5: Відновлення (Recovery)

Мета — безпечне та контрольоване повернення систем до повноцінної роботи.
• використовуйте для відновлення лише перевірені та надійні резервні копії, створені до моменту інциденту. Переконайтесь, що бекапи не містять шкідливого коду;
• перед повним поверненням в експлуатацію ретельно протестуйте відновлені системи в ізольованому середовищі. Встановіть посилений моніторинг їхньої активності;
• поетапно повертайте системи до робочого середовища, постійно відстежуючи їх стан.

Етап 6: Аналіз та висновки (Lessons Learned)

Кібератака – це не лише криза, а й можливість зробити висновки та посилити захист. Для цього:
• складіть звіт, задокументуйте весь життєвий цикл інциденту, від виявлення до повного відновлення. Опишіть причини, наслідки та вжиті заходи;
• оновіть план реагування. На основі отриманого досвіду внесіть зміни до вашого плану, політик безпеки та технічних засобів захисту;
• проведіть навчання, поділіться результатами аналізу з персоналом, щоб запобігти повторенню подібних інцидентів у майбутньому.


© https://cip.gov.ua/ua/news/poyasnennya-cert-ua-yak-vidnoviti-robotu-kompaniyi-pislya-kiberataki-pokrokova-instrukciya


bga68comp: (Default)

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

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/


bga68comp: (Default)

Державна служба спеціального зв'язку та захисту інформації виклала переклад The NIST Cybersecurity Framework (CSF) 2.0 українською:

2026-01-19 192547

 © https://cip.gov.ua › api › attachment › https://cip.gov.ua/services/cm/api/attachment/download?id=62934




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См. также:

Profile

bga68comp: (Default)
bga68comp

July 2026

S M T W T F S
   1234
567 8 91011
12 1314 15161718
19 20 2122232425
262728 293031 

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated 2026-08-01 12:46
Powered by Dreamwidth Studios