bga68comp: (Default)
Під час перекладу Governance дуже часто передають словом «управління». І в широкому сенсі це не зовсім помилка: врядування справді є частиною загальної системи управління організацією.
Але якщо поруч з'являється Management, різниця вже стає принциповою. Перекладати і Governance, і Management одним словом «управління» — означає втратити важливу відмінність між двома рівнями діяльності.

Найпростіша аналогія звучить так:

врядування визначає напрям, а управління визначає, як цим напрямом рухатися.

І це справді працює. Але якщо трохи точніше, то врядування — це не лише напрям.

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

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

А Management бере ці рішення й перетворює їх на організовану діяльність.

Управління визначає:
  • які потрібні ресурси;
  • хто саме виконуватиме роботу;
  • які процеси треба побудувати;
  • у які строки це робити;
  • як координувати виконання;
  • як контролювати результат і виправляти відхилення.

А вже Operations — це безпосереднє виконання.

Виконання охоплює:
  • зміну та перевірку конфігурацій;
  • моніторинг подій і журналів;
  • опрацювання звернень користувачів;
  • реагування на інциденти;
  • виконання резервного копіювання та відновлення;
  • встановлення оновлень і виправлень;
  • щоденне виконання інших операційних завдань.

Тому більш точна схема виглядає так:

Governance — визначає, куди, навіщо, за якими правилами і в яких межах рухатися.

Management — визначає, як організувати цей рух.

Operationsбезпосередньо виконує роботу.

Саме тому перекладати Governance просто як «управління» незручно: тоді зникає різниця між тим, хто задає напрям і правила, і тим, хто організовує виконання.

Тепер пам'ятаємо — зовсім по-людськи, дуже грубо — саме так:
  • Врядування (Governance) — куди йдемо, навіщо, за якими правилами і хто відповідає.
  • Управління (Management) — як організувати рух у цьому напрямі: люди, ресурси, процеси, строки.
  • Виконання (Operations) — безпосередньо йти й робити конкретні кроки.

Тобто коротка формула:

Врядування = напрям і правила.
Управління = як організувати рух.
Виконання = сам рух.

А якщо зовсім по-простому, «робоча формула», коли слів уже не вистачає:

Дивись, ось тобі врядування (і рукою вказуємо напрям) — управляй звідси швиденько 😁


bga68comp: (Default)

Як пояснити слово «врядування» в українській мові

Слово «врядування» в українській мові означає систему та процеси, за допомогою яких здійснюється керівництво державою, організацією чи суспільними справами.

Це іменник, утворений від дієслова «врядувати» — керувати, розпоряджатися, організовувати діяльність.

Головні значення та сфери використання

  • Державне управління (Government / Governance): Найчастіше слово використовується в політичному та юридичному контекстах. Воно описує діяльність органів влади, принципи та систему управління країною або регіоном.
    • Приклад: Електронне врядування (e-governance) спрощує надання державних послуг.
  • Керівництво або організація управління: У ширшому сенсі — це організація процесів та впорядкування діяльності в установі, громаді чи господарстві.
    • Приклад: Добре врядування в компанії допомогло уникнути кризи.

Сучасний контекст: «Добре врядування»

Сьогодні у медіа та політиці дуже популярний термін «добре врядування» (переклад англійського Good Governance). Він означає таку модель управління, яка є:
  • прозорою;
  • відкритою для громадян;
  • ефективною та справедливою.

Близькі за значенням поняття

Залежно від контексту, поруч із поняттям «врядування» можуть використовуватися такі слова:
  • управління;
  • керівництво;
  • адміністрування;
  • правління.

Водночас ці слова не є повними синонімами: кожне з них має власну сферу застосування та відтінок значення.

далі → )


bga68comp: (Default)
NIST National Checklist Program — готові профілі безпечної конфігурації та STIG

National Checklist Program

National Checklist Program (NCP) — Checklist Repository — репозиторій уряду США з публічно доступними рекомендаціями та контрольними переліками для безпечного налаштування операційних систем, застосунків, мережевого обладнання та інших ІТ-продуктів.

Програму NCP визначено у NIST SP 800-70 — National Checklist Program for IT Products.

Простіше кажучи: якщо потрібно безпечно налаштувати Windows, Linux, Microsoft Defender, Cisco, базу даних, браузер, мобільну ОС чи інший продукт, не обов'язково самостійно вигадувати сотні параметрів hardening. Спочатку варто перевірити NCP — цілком можливо, що для цього продукту вже існує готовий і підтримуваний профіль безпечної конфігурації.

Для чого потрібен цей репозиторій

NCP допомагає перейти від загальної вимоги на кшталт «система повинна бути налаштована безпечно» до конкретних технічних параметрів.

Наприклад, за допомогою матеріалів із NCP можна:
  • визначити базову захищену конфігурацію операційної системи або застосунку;
  • перевірити поточні налаштування серверів, робочих станцій і мережевого обладнання;
  • знайти конкретні параметри, які потрібно змінити для посилення захисту;
  • порівняти фактичну конфігурацію з рекомендованою;
  • сформувати корпоративні базові вимоги до безпечної конфігурації (security baseline) на основі вже перевірених рекомендацій;
  • автоматизувати частину перевірок за допомогою SCAP-сумісних засобів;
  • використовувати готові GPO, Intune policies, XCCDF/SCAP-контент та інші матеріали, якщо вони опубліковані для відповідного продукту.

Репозиторій дозволяє шукати й фільтрувати матеріали за контрольним переліком (checklist), розробником або уповноваженим органом (Authority), цільовою системою (Target), типом вмісту (Content Type) та сумісністю із засобами перевірки (Tool Compatibility).

Пошук: https://ncp.nist.gov/repository

А що таке STIG?

У результатах пошуку NCP дуже часто трапляється абревіатура STIG.

STIG — Security Technical Implementation Guide, тобто технічний посібник із безпечного налаштування конкретної технології або продукту.

STIG розробляються та підтримуються для інформаційних систем Міністерства оборони США, зокрема Агентством інформаційних систем оборони США (Defense Information Systems Agency (DISA)).

STIG фактично переводить загальні вимоги безпеки на рівень конкретної конфігурації:

Не: «потрібно захистити операційну систему».

А: який саме параметр перевірити яким має бути його значення чому це важливо як перевірити як виправити.

Наприклад, у STIG для Windows, Microsoft Defender або мережевого обладнання окремі правила можуть визначати вимоги до:
  • автентифікації та паролів;
  • аудиту та журналювання;
  • мережевих протоколів і служб;
  • прав користувачів;
  • захисних функцій ОС;
  • Microsoft Defender і Firewall;
  • криптографічних параметрів;
  • віддаленого доступу;
  • параметрів застосунків та мережевого обладнання.

Як практично використовувати STIG

Типовий сценарій виглядає приблизно так:

  1. Знайти свій продукт. Наприклад: Windows Server, Windows 11, Microsoft Defender, Cisco IOS, RHEL тощо.
  2. Перевірити версію STIG. Вимоги прив'язані до конкретних продуктів і версій та з часом оновлюються.
  3. Отримати checklist / STIG. Це може бути звичайний документ, XCCDF, SCAP-контент, GPO, Intune policy або інший машинозчитуваний формат.
  4. Порівняти з поточною конфігурацією. Для кожної вимоги визначити: виконано / не виконано / не застосовується.
  5. Оцінити вплив змін. Не кожну рекомендацію слід бездумно вмикати на робочій системі.
  6. Перевірити налаштування у тестовому середовищі. Особливо GPO, Firewall, криптографію, автентифікацію та обмеження служб.
  7. Впровадити погоджений baseline. Бажано централізовано — наприклад через GPO, Intune, MDM або засоби керування конфігураціями.
  8. Регулярно перевіряти відповідність. Конфігурації змінюються, з'являються нові версії ПЗ і нові редакції STIG.

SCAP — навіщо він тут?

Частина checklist у NCP представлена у форматах, сумісних із
Security Content Automation Protocol (SCAP)протокол автоматизації даних безпеки, який дозволяє подавати правила перевірки конфігурації у машинозчитуваному вигляді та автоматизувати їх перевірку..

Це дозволяє перейти від ручної перевірки сотень параметрів до автоматизованої:

STIG / checklist формалізовані правила SCAP-сумісний сканер перевірка системи перелік невідповідностей виправлення повторна перевірка.

Тобто NCP може бути корисним не тільки як довідник «як правильно налаштувати», а й як джерело формалізованих вимог для контролю відповідності конфігурації (configuration compliance).

Важливо

STIG — це дуже жорсткий baseline, створений насамперед для середовища DoD США. Тому використання STIG у звичайній компанії не означає, що потрібно механічно застосувати кожну вимогу.

Правильніше використовувати його як:
  • авторитетну вихідну точку для hardening;
  • джерело конкретних технічних вимог;
  • контрольний перелік для перевірки конфігурації;
  • основу для власного корпоративного security baseline.

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

Посилання:

 © NIST National Checklist Program


bga68comp: (Default)
Терміни «ризик», «загроза» та «невизначеність» часто плутають. Однак вони позначають різні поняття.

Що таке невизначеність?


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

 
Простіше кажучи, ми не знаємо напевно:
  • чи відбудеться певна подія;
  • коли вона відбудеться;
  • якими будуть її наслідки.

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

Позитивний і негативний вплив

  • Позитивний вплив — наслідок невизначеності, який сприяє досягненню цілей.
  • Негативний вплив — наслідок невизначеності, який перешкоджає досягненню цілей або завдає шкоди.

Приклад позитивного впливу. Нову систему впровадили раніше запланованого, завдяки чому організація скоротила витрати.
 
Приклад негативного впливу. Упровадження затрималося, що призвело до додаткових витрат і зриву строків.

Позитивний вплив: ISO чи NIST?

У ISO 31000 ризик визначено як вплив невизначеності на цілі. Такий вплив може бути:
  • позитивним — створювати можливості;
  • негативним — створювати загрози;
  • одночасно позитивним і негативним.

У методиці оцінювання кіберризиків NIST SP 800-30 ризик розглядають переважно через негативний вплив — можливу шкоду організації, її системам, активам або людям.
 
Отже, поняття позитивного впливу ризику характерне насамперед для загального підходу ISO 31000. У сфері інформаційної безпеки NIST зосереджується на загрозах, шкоді та небажаних наслідках.

Чим ризик відрізняється від загрози?


Загроза — обставина або подія, яка потенційно може завдати шкоди.
Ризик — поєднання ймовірності реалізації загрози та тяжкості її можливих наслідків.

Приклад:
  • джерело загрози — зловмисник;
  • загроза — несанкціонований доступ до системи;
  • вразливість — слабкий пароль і відсутність багатофакторної автентифікації;
  • ризик — можливість того, що зловмисник використає цю вразливість, отримає доступ до системи та викраде дані.

Як запам’ятати?

  • Невизначеність — чого ми не знаємо напевно.
  • Загроза — що може завдати шкоди.
  • Вразливість — що дає змогу загрозі реалізуватися.
  • Ризик — наскільки ймовірною є шкода та наскільки тяжкими будуть її наслідки.

Джерела



bga68comp: (Default)

Як українською коректно перекласти «ticket» у Service Desk?


У робочому ІТ-сленгу слово «тікет» давно стало звичним. Але в офіційній документації, особливо якщо її можуть бачити аудитори, регулятор або зовнішні контрагенти, його краще не використовувати.

Універсального перекладу для ticket немає — він залежить від того, що саме реєструється.

  • ticket у Service Desk звернення;
  • incident ticket запис про інцидент або звернення щодо інциденту;
  • service request ticket заявка на обслуговування;
  • change ticket заявка на зміну;
  • access ticket заявка на надання або зміну доступу;
  • ticket number номер звернення або номер заявки;
  • create a ticket зареєструвати звернення або створити заявку;
  • close a ticket закрити звернення або закрити заявку.

«Звернення» чи «заявка»?


Тут є невелика, але важлива відмінність.

Заявка краще підходить для ситуацій, коли користувач або працівник просить виконати певну дію: надати доступ, встановити програму, внести зміну, виконати обслуговування.

Звернення — ширший термін. Воно може стосуватися інциденту, проблеми, запиту на обслуговування, консультації або іншої події, зареєстрованої в Service Desk.

Тому як загальний український термін для ticket у Service Desk найзручніше використовувати:
звернення

Наприклад, замість:
Створення тікета DEV-123 у Service Desk підрядника.

краще:
Реєстрація звернення DEV-123 у Service Desk підрядника.

Якщо ж ідеться про конкретний тип запиту, термін краще уточнювати:

  • реєстрація заявки на зміну;
  • реєстрація заявки на надання доступу;
  • реєстрація інциденту;
  • реєстрація запиту на обслуговування.

Отже, «тікет» можна залишити для неформального спілкування ІТ-фахівців, але в політиках, процедурах, схемах, технічних завданнях та документації для аудиту краще використовувати українські терміни «звернення», «заявка», «запис про інцидент» — залежно від контексту.


bga68comp: (Default)
45c97e31-f3f1-415d

Платіжні послуги: нормативно-правові акти, на які звертає увагу НБУ


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

Нижче наведено цей перелік із прямими посиланнями на документи в базі «Законодавство України». Частина актів повторюється в кількох розділах, оскільки НБУ відносить їх одночасно до загального та спеціального регулювання.

Примітка. На сторінці НБУ неправильно зазначено дати двох документів: постанову № 249 прийнято 26 грудня 2022 року, а постанову № 12310 жовтня 2024 року. Нижче дати наведено за офіційними картками документів.

Загальне регулювання

  1. Конституція України від 28 червня 1996 року
  2. Цивільний кодекс України № 435-IV від 16 січня 2003 року
  3. Податковий кодекс України № 2755-VI від 2 грудня 2010 року
  4. Закон України «Про фінансові послуги та фінансові компанії» № 1953-IX від 14 грудня 2021 року
  5. Закон України «Про Національний банк України» № 679-XIV від 20 травня 1999 року
  6. Закон України «Про платіжні послуги» № 1591-IX від 30 червня 2021 року
  7. Закон України «Про валюту і валютні операції» № 2473-VIII від 21 червня 2018 року
  8. Закон України «Про державну реєстрацію юридичних осіб, фізичних осіб — підприємців та громадських формувань» № 755-IV від 15 травня 2003 року
  9. Закон України «Про аудит фінансової звітності та аудиторську діяльність» № 2258-VIII від 21 грудня 2017 року
  10. Закон України «Про основні засади забезпечення кібербезпеки України» № 2163-VIII від 5 жовтня 2017 року
  11. Закон України «Про запобігання та протидію легалізації (відмиванню) доходів, одержаних злочинним шляхом, фінансуванню тероризму та фінансуванню розповсюдження зброї масового знищення» № 361-IX від 6 грудня 2019 року
  12. Закон України «Про бухгалтерський облік та фінансову звітність в Україні» № 996-XIV від 16 липня 1999 року
  13. Закон України «Про рекламу» № 270/96-ВР від 3 липня 1996 року
  14. Закон України «Про захист прав споживачів» № 1023-XII від 12 травня 1991 року
  15. Постанова Правління НБУ від 29 грудня 2023 року № 200 «Про затвердження Положення про порядок здійснення адміністративного провадження, загальні вимоги до документів і порядок їх подання до Національного банку України в межах окремих процедур та внесення змін до деяких нормативно-правових актів Національного банку України»
  16. Постанова Правління НБУ від 29 грудня 2023 року № 199 «Про затвердження Положення про авторизацію надавачів фінансових послуг та умови здійснення ними діяльності з надання фінансових послуг»
  17. Постанова Правління НБУ від 20 грудня 2023 року № 172 «Про затвердження Положення про використання електронного підпису та електронної печатки»
  18. Постанова Правління НБУ від 26 грудня 2022 року № 249 «Про встановлення вимог до надання обмежених платіжних послуг»
  19. Постанова Правління НБУ від 7 жовтня 2022 року № 217 «Про затвердження Положення про порядок здійснення авторизації діяльності надавачів фінансових платіжних послуг та обмежених платіжних послуг»
  20. Постанова Правління НБУ від 17 серпня 2022 року № 181 «Про затвердження Положення про порядок розкриття інформації небанківськими надавачами платіжних послуг»
  21. Постанова Правління НБУ від 14 липня 2022 року № 147 «Про затвердження Правил зберігання, захисту, використання та розкриття таємниці надавачами платіжних послуг»
  22. Постанова Правління НБУ від 2 серпня 2022 року № 168 «Про затвердження Положення про залучення комерційних агентів для надання фінансових платіжних послуг»
  23. Постанова Правління НБУ від 29 липня 2022 року № 164 «Про затвердження Положення про порядок емісії та еквайрингу платіжних інструментів»
  24. Постанова Правління НБУ від 26 липня 2022 року № 158 «Про запровадження номера платіжного рахунку користувача та електронного гаманця в Україні»
  25. Постанова Правління НБУ від 24 серпня 2022 року № 187 «Про затвердження Положення про порядок здійснення оверсайту платіжної інфраструктури в Україні»
  26. Постанова Правління НБУ від 28 липня 2008 року № 216 «Про затвердження Положення про порядок виконання надавачами платіжних послуг платіжних інструкцій в іноземній валюті та банківських металах»
  27. Положення про здійснення установами фінансового моніторингу, затверджене постановою Правління НБУ від 28 липня 2020 року № 107
  28. Постанова Правління НБУ від 22 вересня 2022 року № 206 «Про затвердження Положення про застосування Національним банком України заходів впливу за порушення вимог законодавства, що регулює діяльність на платіжному ринку»
  29. Постанова Правління НБУ від 3 травня 2023 року № 58 «Про затвердження Положення про автентифікацію та застосування посиленої автентифікації на платіжному ринку»
  30. Постанова Правління НБУ від 25 листопада 2022 року № 233 «Про затвердження Положення про додаткові вимоги до договорів про надання платіжних послуг, укладених небанківськими надавачами платіжних послуг зі споживачами»
  31. Постанова Правління НБУ від 25 вересня 2018 року № 103 «Про затвердження Інструкції про порядок організації касової роботи банками та проведення платіжних операцій надавачами платіжних послуг в Україні»
  32. Постанова Правління НБУ від 10 жовтня 2024 року № 123 «Про затвердження Положення про вимоги до системи управління надавача фінансових платіжних послуг»
  33. Постанова Правління НБУ від 7 березня 2025 року № 29 «Про встановлення критеріїв визначення підприємств, установ, організацій, які мають важливе значення для галузі національної економіки, у сфері діяльності на платіжному ринку»
  34. Постанова Правління НБУ від 13 червня 2025 року № 64 «Про деякі питання визначення регулятивного капіталу небанківських надавачів платіжних послуг»
  35. Постанова Правління НБУ від 2 липня 2025 року № 71 «Про затвердження Положення про порядок страхування відповідальності надавачів нефінансових платіжних послуг перед користувачами та надавачами платіжних послуг з обслуговування рахунків»
  36. Постанова Правління НБУ від 2 липня 2025 року № 73 «Про затвердження Положення про вимоги до системи управління ризиками надавача нефінансових платіжних послуг та внесення зміни до Положення про вимоги до системи управління надавача фінансових платіжних послуг»
  37. Постанова Правління НБУ від 25 липня 2025 року № 81 «Про затвердження Положення про порядок здійснення авторизації діяльності надавачів нефінансових платіжних послуг та затвердження Змін до Положення про реєстрацію платіжних систем, учасників платіжних систем та технологічних операторів платіжних послуг»

Ліцензування

  1. Закон України «Про платіжні послуги» № 1591-IX від 30 червня 2021 року
  2. Постанова Правління НБУ від 7 жовтня 2022 року № 217 «Про затвердження Положення про порядок здійснення авторизації діяльності надавачів фінансових платіжних послуг та обмежених платіжних послуг»
  3. Постанова Правління НБУ від 29 грудня 2023 року № 199 «Про затвердження Положення про авторизацію надавачів фінансових послуг та умови здійснення ними діяльності з надання фінансових послуг»
  4. Постанова Правління НБУ від 4 вересня 2024 року № 105 «Про затвердження Положення про визнання належності послуги чи операції до фінансової / обмеженої платіжної послуги та виявлення здійснення безліцензійної діяльності на ринку небанківських фінансових послуг і платіжному ринку»
  5. Постанова Правління НБУ від 25 липня 2025 року № 81 «Про затвердження Положення про порядок здійснення авторизації діяльності надавачів нефінансових платіжних послуг та затвердження Змін до Положення про реєстрацію платіжних систем, учасників платіжних систем та технологічних операторів платіжних послуг»
  6. Постанова Правління НБУ від 28 серпня 2025 року № 103 «Про окремі питання, пов’язані з визначенням ознак еквайрингу платіжних інструментів»

Нагляд та перевірки


  1. Закон України «Про платіжні послуги» № 1591-IX від 30 червня 2021 року
  2. Постанова Правління НБУ від 5 травня 2023 року № 60 «Про затвердження Положення про здійснення Національним банком України безвиїзного нагляду на платіжному ринку за небанківськими надавачами платіжних послуг, надавачами обмежених платіжних послуг»
  3. Постанова Правління НБУ від 6 квітня 2023 року № 47 «Про затвердження Положення про проведення перевірок небанківських надавачів платіжних послуг, надавачів обмежених платіжних послуг»
  4. Постанова Правління НБУ від 22 вересня 2022 року № 206 «Про затвердження Положення про застосування Національним банком України заходів впливу за порушення вимог законодавства, що регулює діяльність на платіжному ринку»
  5. Постанова Правління НБУ від 4 вересня 2024 року № 105 «Про затвердження Положення про визнання належності послуги чи операції до фінансової / обмеженої платіжної послуги та виявлення здійснення безліцензійної діяльності на ринку небанківських фінансових послуг і платіжному ринку»

Звітність

  1. Закон України «Про бухгалтерський облік та фінансову звітність в Україні» № 996-XIV від 16 липня 1999 року
  2. Закон України «Про аудит фінансової звітності та аудиторську діяльність» № 2258-VIII від 21 грудня 2017 року
  3. Порядок подання фінансової звітності, затверджений постановою Кабінету Міністрів України від 28 лютого 2000 року № 419
  4. Постанова Правління НБУ від 25 листопада 2021 року № 123 «Про затвердження Правил складання та подання звітності учасниками ринку небанківських фінансових послуг до Національного банку України»
  5. Постанова Правління НБУ від 13 листопада 2018 року № 120 «Про затвердження Правил організації статистичної звітності, що подається до Національного банку України»

Джерело:
Національний банк України — Платіжні послуги


bga68comp: (Default)
Не будемо висловивлюватися надто категорично: «керівництво» не є неправильним українським словом, але в назві нормативно-методичного документа воно менш точне.

  • Керівництво — насамперед управління кимось або чимось: керівництво організації, здійснювати керівництво роботами. Також може означати склад керівників.
  • Настанова — документ, що містить рекомендації, принципи та пояснення щодо виконання певної діяльності.
  • Посібник — переважно навчальне або практичне видання.
  • Інструкція — конкретний, часто обов’язковий порядок дій.

Англійське Guide у назві NIST означає саме методичний документ, а не «керівництво» як управління. Тому найточніше:

Guide for Conducting Risk Assessments — Настанова щодо проведення оцінювання ризиків.

Варіант «Керівництво з проведення оцінювання ризиків» зрозумілий, але відчувається вплив російського «руководство по…» і гірше відповідає українській термінології стандартів.

NIST SP 800-30 Rev. 1, опублікована у вересні 2012 року.


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


Profile

bga68comp: (Default)
bga68comp

September 2026

S M T W T F S
  12 345
67 8910 1112
13141516 171819
2021 22 23242526
27282930   

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated 2026-09-23 14:59
Powered by Dreamwidth Studios