Як спланувати тестування стійкості DORA за допомогою ШІ

Огляд

Ви дізнаєтесь, як спроектувати та впровадити програму тестування цифрової операційної стійкості, яка відповідає статтям 24-27 DORA, використовуючи ШІ. Цей посібник охоплює загальну програму тестування (оцінка вразливостей, тестування на проникнення, сценарне тестування), вимоги до поглибленого тестування на основі загроз (Threat-Led Penetration Testing, TLPT), обсяг і частоту тестування, звітування результатів керівному органу та інтеграцію тестування з вашою системою управління ІКТ-ризиками, з конкретними запитами для ISMS Copilot для генерації кожного компонента.

Для кого цей посібник

Цей посібник призначений для:

• CISO та менеджерів з безпеки, відповідальних за проектування та нагляд за програмами тестування стійкості
• Менеджерів ІТ-ризиків, які інтегрують результати тестування в оцінку ІКТ-ризиків
• Координаторів тестування на проникнення, які керують внутрішніми та зовнішніми тестуваннями
• Спеціалістів з комплаєнсу, які забезпечують відповідність програм тестування регуляторним вимогам
• Консультантів, які допомагають фінансовим установам підготуватися до TLPT або загального тестування стійкості

Перш ніж розпочати

Вам знадобиться:

• Обліковий запис ISMS Copilot (доступна безкоштовна пробна версія)
• Ваша система управління ІКТ-ризиками та інвентаризація ІКТ-активів з матеріалу How to build a DORA ICT risk management framework using AI
• Ваші процедури класифікації та реагування на інциденти з матеріалу How to implement DORA incident reporting using AI
• Розуміння ваших поточних заходів з тестування (сканування вразливостей, тести на проникнення, тести аварійного відновлення)
• Знання про те, чи була ваша установа визначена для TLPT вашим компетентним органом
• Бюджетне схвалення на послуги зовнішнього тестування (особливо для TLPT)

Розуміння вимог DORA до тестування стійкості

Розбір статей

Розділ IV DORA (статті 24-27) встановлює структурований підхід до тестування цифрової операційної стійкості:

Article

Title

Key requirements

Applicability

Art 24

General requirements for digital operational resilience testing

Створення програми тестування як частини управління ІКТ-ризиками, підхід на основі ризиків

Усі фінансові установи (пропорційно)

Art 25

Testing of ICT tools and systems

Конкретні види тестування: оцінка вразливостей, тестування на проникнення, сценарне тестування, тестування сумісності, тестування продуктивності, перевірка вихідного коду

Усі фінансові установи (пропорційно)

Art 26

Advanced testing through TLPT

Тестування на проникнення на основі загроз за рамками TIBER-EU, кожні 3 роки

Лише визначені установи

Art 27

Requirements for testers

Кваліфікація, незалежність та стандарти для тестувальників (внутрішніх та зовнішніх)

Усі установи, що проводять тестування

Загальне тестування vs. TLPT

Розуміння відмінностей між загальним тестуванням та TLPT є критично важливим для визначення обсягу вашої програми:

Aspect

General testing (Art 24-25)

TLPT (Art 26-27)

Key difference

Хто

Усі фінансові установи

Лише визначені установи

Компетентний орган визначає установи для TLPT

Частота

На основі ризиків; критичні системи принаймні раз на рік

Принаймні кожні 3 роки

TLPT проводиться рідше, але є набагато інтенсивнішим

Обсяг

Усі ІКТ-системи (пропорційно)

Критичні та важливі функції, робочі виробничі системи

TLPT тестує робочі системи, а не лише тестові середовища

Методологія

Різноманітні (сканування вразливостей, тести на проникнення, сценарні тести)

Рамки TIBER-EU, на основі розвідки загроз

TLPT імітує тактику реальних супротивників

Тестувальники

Внутрішні або зовнішні (з вимогами незалежності)

Зовнішні тестувальники обов'язкові (з обмеженими винятками)

TLPT вимагає сертифікованої зовнішньої червоної команди

Звітування

Внутрішнє (керівному органу, функції ІКТ-ризиків)

Компетентному органу, з підтвердженням

Результати TLPT передаються регулятору

Крок 1: Розробка загальної програми тестування (статті 24-25)

Структура програми тестування

Стаття 24 вимагає програму тестування, яка є невід'ємною частиною вашої системи управління ІКТ-ризиками, дотримується підходу на основі ризиків та є пропорційною до розміру та профілю ризиків вашої установи.

1. Відкрийте ваш робочий простір DORA у ISMS Copilot

2. Згенеруйте документ програми тестування:

   "Create a Digital Operational Resilience Testing Program for a [entity type] satisfying DORA Articles 24-25. Include: program purpose and objectives, governance (management body oversight, program owner, roles and responsibilities), risk-based approach to test planning (how risks determine what is tested and how often), testing scope (mapped to ICT asset inventory and critical/important functions), testing types to be conducted (vulnerability assessments, network security testing, penetration testing, scenario-based testing, compatibility testing, performance testing, source code reviews, open source software testing, end-to-end testing), testing frequency by asset criticality and test type, internal vs external tester requirements, independence requirements per Article 27, results reporting and management body communication, remediation tracking process, integration with ICT risk management framework updates, annual testing calendar template, and budget and resource planning. Apply proportionality for a [entity size] organization."

3. Визначте методологію тестування на основі ризиків:

   "Create a risk-based testing methodology for DORA resilience testing. Define how we determine: which systems and functions to test (based on ICT asset criticality, business impact, threat landscape, previous incidents), what type of testing to apply (vulnerability scan vs penetration test vs scenario-based test), testing depth and intensity (basic, standard, advanced), testing frequency (quarterly, semi-annual, annual), and testing priority when resources are constrained. Provide a testing priority matrix that maps asset criticality and threat level to testing type and frequency. Include examples for a [entity type]."

Види тестування та їх застосування

Стаття 25 визначає кілька видів тестування. Використовуйте ISMS Copilot для розробки детальних планів для кожного з них:

1. Програма оцінки вразливостей:

   "Create a vulnerability assessment program for DORA Article 25 compliance. Include: scanning scope (all ICT assets by criticality tier), scanning tools and methodology, scanning frequency (at least quarterly for critical assets, monthly recommended), vulnerability classification aligned with CVSS scoring, remediation timelines by severity (critical: 48 hours, high: 7 days, medium: 30 days, low: 90 days), exception management process for vulnerabilities that cannot be immediately remediated, reporting format (technical report and management summary), trend analysis methodology, and integration with patch management procedures. Provide a vulnerability management workflow."

2. Програма тестування на проникнення:

   "Create a penetration testing program for DORA Article 25 compliance. Include: testing scope (external perimeter, internal network, web applications, mobile applications, API security, social engineering), testing frequency (at least annual for critical systems, more frequent for high-risk areas), testing methodology (OWASP, PTES, or equivalent), rules of engagement template (scope, timing, escalation, prohibited actions), tester qualification requirements per DORA Article 27 (independence, competence, insurance), pre-test procedures (authorization, scope confirmation, communication), reporting requirements (executive summary, technical findings, risk ratings, remediation recommendations), post-test procedures (remediation verification, re-testing), and management body reporting format. Provide a sample rules of engagement template."

3. Програма сценарного тестування:

   "Design a scenario-based resilience testing program for DORA Article 25. Create test scenarios covering: ransomware attack on core banking/payment systems, major cloud provider outage affecting critical services, DDoS attack during peak transaction periods, insider threat compromising sensitive data, supply chain attack through a critical third-party ICT provider, simultaneous failure of primary and backup systems, loss of key ICT personnel during an incident, regulatory data breach requiring client notification. For each scenario, define: test objectives, scope and systems involved, scenario narrative and inject timeline, success criteria, participants and roles, test execution procedures, expected outcomes, evaluation criteria, and reporting template. Include both tabletop and simulated exercise formats."

Крок 2: Встановлення вимог до тестувальників (стаття 27)

Незалежність та кваліфікація тестувальників

Стаття 27 встановлює вимоги до тестувальників, які проводять тестування стійкості. Вони застосовуються як до внутрішніх, так і до зовнішніх тестувальників:

"Create a tester requirements and qualification policy for DORA Article 27. Address: internal testers (independence from the areas being tested, relevant certifications such as OSCP/CREST/GPEN, maintained competence, rotation requirements), external testers (professional certifications and accreditations, relevant experience in financial sector testing, professional indemnity insurance, independence verification, reference checking), conflict of interest management, tester vetting and security clearance procedures, non-disclosure and confidentiality requirements, and tester performance evaluation criteria. Provide a tester qualification checklist for both internal and external testers, and a sample statement of work for external testing engagements."

Крок 3: Планування TLPT (статті 26-27)

Розуміння вимог TLPT

Тестування на проникнення на основі загроз (TLPT) згідно з DORA базується на рамках TIBER-EU і є найінтенсивнішою вимогою до тестування. Навіть якщо вас не визначили для TLPT, розуміння вимог буде корисним для підготовки.

1. Оцінка застосовності TLPT:

   "Assess whether our [entity type] with [size, systemic importance, ICT risk profile] is likely to be designated for DORA TLPT under Article 26. Consider: our systemic importance in the financial sector, criticality of services we provide, our ICT risk profile and complexity, competent authority designation criteria from published guidance. If likely designated, provide a TLPT readiness assessment and preparation timeline. If unlikely, recommend preparatory measures we should take regardless."

2. Генерація рамок TLPT:

   "Create a TLPT preparation and execution framework for DORA Article 26, aligned with the TIBER-EU methodology. Include: Phase 1 - Preparation: scope definition (critical and important functions to test on live production systems), competent authority engagement and notification, threat intelligence provider selection, red team provider selection, white team formation (internal team aware of the test), internal governance approvals. Phase 2 - Threat Intelligence: threat intelligence report (targeted threat landscape analysis), threat scenarios based on current threat actors and techniques, attack surface analysis, and competent authority review of threat scenarios. Phase 3 - Red Team Testing: red team engagement (simulated attacks on live production systems), test execution over [typical duration: 8-12 weeks], controlled testing with safety mechanisms, purple team activities (if agreed), and findings documentation. Phase 4 - Closure: red team report with findings and evidence, blue team response assessment, remediation plan development, management body briefing, competent authority attestation process. Provide timeline estimates and resource requirements for each phase."

Вибір постачальників TLPT

TLPT вимагає як постачальника розвідки загроз, так і постачальника червоної команди. Використовуйте ISMS Copilot для розробки критеріїв відбору:

"Create a TLPT provider selection framework for DORA Article 26-27. For the Threat Intelligence Provider: required qualifications (sector-specific financial threat expertise, recognized certifications), evaluation criteria (quality of previous threat reports, understanding of EU financial sector threats, data sources and collection capabilities), and selection checklist. For the Red Team Provider: required qualifications (CREST, CBEST, or equivalent accreditation, experience with TIBER-EU testing, financial sector experience), evaluation criteria (technical capabilities, methodology, team composition, safety track record), independence verification (no current advisory relationship with entity), insurance requirements, and selection checklist. Provide an RFP template for both provider types."

Визначення обсягу TLPT

Правильне визначення обсягу є критично важливим для успішного TLPT. Використовуйте ISMS Copilot для визначення обсягу тестування:

"Help us define the scope for our DORA TLPT exercise. Our critical and important functions include: [list functions]. For each critical function, identify: the supporting ICT systems and infrastructure that should be in scope, data flows and integrations that could be attack paths, third-party ICT providers that support the function (and whether they should be included in testing per Article 26(3)), potential attack surfaces (external, internal, physical, social engineering), and systems that should be explicitly excluded for safety reasons. Produce a TLPT scope document suitable for competent authority review."

Крок 4: Звітування результатів та відстеження усунення недоліків

Звітування результатів тестування керівництву

DORA вимагає, щоб результати тестування були повідомлені керівному органу та використані для оновлення системи управління ІКТ-ризиками:

1. Генерація шаблонів звітів про результати тестування:

   "Create a resilience testing results report template for management body reporting under DORA Article 24. Include: executive summary (overall resilience posture, key findings, trend comparison), testing program execution summary (tests conducted, scope, timing), findings by severity (critical, high, medium, low) with business impact context, comparison with previous testing cycles (improvement or degradation), remediation status for previously identified vulnerabilities, new remediation recommendations with risk-based prioritization, testing program effectiveness assessment, budget and resource utilization, and recommendations for testing program adjustments. The report should be suitable for non-technical board members while maintaining sufficient detail for risk oversight."

2. Створення документації для підтвердження TLPT:

   "Create a TLPT attestation documentation package for submission to our competent authority under DORA Article 26(6). Include: TLPT summary report (scope, methodology, timeline), anonymized red team findings (critical and high-severity), remediation plan with timeline and status, management body acknowledgment and approval, organizational lessons learned, and any requests for mutual recognition with other competent authorities. Follow the format guidance from [competent authority] and TIBER-EU framework."

Відстеження усунення недоліків

Тестування має цінність лише тоді, коли результати ведуть до покращень. Встановіть надійне відстеження усунення недоліків:

"Create a resilience testing remediation tracking procedure for DORA compliance. Include: how findings are translated into remediation actions, prioritization methodology (critical: remediate within 30 days, high: 60 days, medium: 90 days, low: next testing cycle), remediation owner assignment and accountability, progress tracking and escalation for overdue remediations, verification testing (confirming fixes are effective), exception process for findings that cannot be remediated (compensating controls, risk acceptance with management body approval), integration with the ICT risk register (updating risk assessments based on test findings), and reporting cadence to management body. Provide a remediation tracking register template."

Крок 5: Інтеграція тестування з вашою системою управління ІКТ-ризиками

Включення результатів у управління ризиками

DORA вимагає, щоб результати тестування інформували та оновлювали вашу систему управління ІКТ-ризиками. Використовуйте ISMS Copilot для формалізації цієї інтеграції:

"Define how resilience testing results integrate with our DORA ICT risk management framework. Include: how testing findings update the ICT risk register (new risks identified, risk ratings adjusted, control effectiveness reassessed), how testing results inform the annual ICT risk management framework review under Article 6(5), how TLPT results influence our ICT risk strategy and risk appetite, how scenario-based testing results update our business continuity and disaster recovery plans, how vulnerability assessment trends inform our protection and prevention measures under Article 9, and how incident simulation results validate or challenge our incident classification and reporting procedures. Provide a process flow showing the feedback loop between testing and risk management."

Безперервне покращення тестування

Ваша програма тестування сама по собі має розвиватися на основі результатів та змінюваних загроз:

"Create an annual testing program review process for DORA compliance. The review should assess: testing coverage (did we test all critical systems and functions as planned?), testing effectiveness (did tests identify real vulnerabilities? how do findings compare to actual incidents?), testing efficiency (are we using resources effectively? are there overlapping or redundant tests?), threat landscape changes (do our test scenarios reflect current threats?), new systems or services added since last review (are they included in the testing scope?), regulatory feedback or guidance on testing expectations, and recommended program adjustments for the next cycle. Produce an annual testing program review report template for management body approval."

Крок 6: Управління логістикою та керівництвом тестування

Календар тестування та координація

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

"Create an annual resilience testing calendar for our [entity type]. Map all required testing activities across the year: vulnerability scans (quarterly for critical, monthly for internet-facing), penetration tests (annual external, annual internal, annual application), scenario-based exercises (semi-annual tabletop, annual simulation), business continuity tests (annual failover, annual backup restoration), and TLPT preparation activities (if applicable). Include: resource requirements for each activity, coordination requirements (change freeze windows, business unit involvement), dependencies between testing activities, budget allocation by quarter, and management body reporting milestones. Format as a calendar view with Gantt-chart structure."

Тестування сторонніх ІКТ-провайдерів

Стаття 26(3) стосується тестування, що включає сторонніх ІКТ-провайдерів. Узгоджуйте вимоги до тестування з вашими постачальниками:

"Create procedures for coordinating resilience testing with ICT third-party providers under DORA. Include: contractual requirements for provider participation in testing (link to Article 28 contract clauses), provider notification and coordination procedures, shared responsibility testing (what we test vs what the provider tests), handling provider refusal to participate in testing, alternative testing approaches when direct provider testing is not possible (synthetic testing, provider-supplied test reports), TLPT involving third-party provider systems (Article 26(3) pooled testing arrangements), and evidence collection from provider testing activities. Address scenarios for cloud providers, managed service providers, and critical infrastructure providers."

Наступні кроки

Тепер у вас є комплексна програма тестування цифрової операційної стійкості:

• Структура програми тестування з методологією на основі ризиків
• Детальні плани оцінки вразливостей, тестування на проникнення та сценарного тестування
• Вимоги до кваліфікації та незалежності тестувальників
• Структура підготовки до TLPT (якщо вас визначили або ймовірно визначать)
• Шаблони звітування результатів для керівного органу та компетентного органу
• Процедури відстеження усунення недоліків
• Інтеграція з системою управління ІКТ-ризиками

Продовжуйте з останнім посібником у цій серії DORA:

• How to manage DORA third-party ICT risk using AI -- Переконайтеся, що ваші сторонні провайдери включені до вашої програми тестування та що контракти підтримують ваші зобов'язання щодо тестування

Для базової настройки див. How to get started with DORA implementation using AI. Для системи управління ІКТ-ризиками див. How to build a DORA ICT risk management framework using AI. Для інтеграції звітування про інциденти див. How to implement DORA incident reporting using AI.

Для готових до використання запитів див. DORA Compliance Prompt Library. Для повного огляду регуляторних вимог зверніться до DORA Compliance Guide for Financial Entities.

Отримання допомоги

Для додаткової підтримки у плануванні вашої програми тестування стійкості:

• Запитайте ISMS Copilot: Використовуйте свій робочий простір DORA для генерації сценаріїв тестування, специфічних для типу вашої установи та ІКТ-середовища
• Завантажте існуючі звіти про тестування: Отримайте аналіз прогалин, завантаживши попередні звіти про тестування на проникнення або оцінку вразливостей для порівняння з вимогами DORA
• Підготовка до TLPT: Використовуйте ISMS Copilot для розробки документації щодо обсягу TLPT та критеріїв вибору постачальників перед зверненням до вашого компетентного органу
• Валідація вихідних даних: Перегляньте всі плани тестування на відповідність статтям 24-27 DORA, відповідним RTS та рамкам TIBER-EU перед затвердженням керівним органом