Тестове за възстановяване, готови за одит, за ISO 27001, NIS2 и DORA

Понеделник сутрин е, 07:40, и Sarah, CISO на бързо развиваща се финтех компания, наблюдава как кризата се развива в реално време. Финансовият директор (CFO) не може да отвори платформата за одобрение на плащания. Service desk смята, че проблемът е в съхранението. Екипът по инфраструктура подозира ransomware, защото няколко споделени папки вече показват криптирани имена на файлове. Изпълнителният директор (CEO) иска да знае дали изплащането на заплатите е защитено. Правният отдел пита дали трябва да бъдат уведомени регулаторите.

Sarah отваря таблото за резервни копия. То е пълно със зелени отметки.

Това би трябвало да успокоява, но не успокоява. Успешна задача за резервно копиране не е доказателство за успешно възстановяване. Това е като да видите пожарогасител на стената, без да знаете дали е зареден, достъпен и използваем под натиск.

Компанията на Sarah попада в обхвата на ISO 27001:2022, третира се като важен субект по NIS2 и подлежи на DORA като финансова организация. Въпросът вече не е дали организацията прави резервни копия. Въпросът е дали може да възстанови правилните системи, към правилния момент във времето, в рамките на одобрените целево време за възстановяване (RTO) и целева точка на възстановяване (RPO), с доказателства, достатъчно надеждни за одитор, регулатор, клиент, застраховател и управителен орган.

Точно тук много програми за резервно копиране се провалят. Те имат задачи за резервно копиране. Имат табла за наблюдение. Имат моментни снимки на състоянието. Може дори да имат облачно хранилище. Но когато настъпи натискът, не могат да докажат, че критичните системи са възстановими, че са проведени тестове за възстановяване, че неуспешните тестове са задействали коригиращо действие и че доказателствата се съпоставят ясно с очакванията на ISO 27001:2022, NIS2, DORA, NIST и COBIT 2019.

Тестването на резервни копия и възстановяване вече е въпрос на оперативна устойчивост на ниво управителен орган. NIS2 повишава очакванията към управлението на риска за киберсигурността и непрекъснатостта на дейността. DORA превръща цифровата оперативна устойчивост на ИКТ в основно задължение за финансовите организации и техните критични доставчици на ИКТ услуги. ISO 27001:2022 предоставя структурата на системата за управление за обхват, риск, избор на контроли, доказателства, одит и непрекъснато подобрение.

Практическото предизвикателство е техническият тест за възстановяване да бъде превърнат в доказателства, готови за одит.

Резервното копие не е доказателство, докато възстановяването не бъде доказано

Успешно завършена задача за резервно копиране е само частичен сигнал. Тя показва, че данните са копирани някъде. Не доказва, че данните могат да бъдат възстановени, че зависимостите на приложението са запазени, че ключовете за криптиране са налични, че услугите за идентичност продължават да работят или че възстановената система поддържа реални бизнес операции.

Одиторите знаят това. Регулаторите знаят това. Нападателите знаят това.

Технически зрелият одитор няма да спре до екранна снимка, показваща 97 процента успешни задачи за резервно копиране. Той ще попита:

• Кои системи са критични или с високо въздействие?
• Какви RTO и RPO се прилагат за всяка система?
• Кога е проведен последният тест за възстановяване?
• Тестът беше ли пълен, частичен, на ниво приложение, на ниво база данни или на ниво файл?
• Кой валидира бизнес процеса след възстановяването?
• Записани ли са отказите като несъответствия или действия за подобрение?
• Колко дълго се съхраняват журналите и записите от тестове за възстановяване?
• Сегрегирани ли са резервните копия между различни местоположения?
• Как доказателствата се съпоставят с регистъра на риска и Декларацията за приложимост?

Затова езикът на политиките на Clarysec е целенасочено директен. Политика за резервно копиране и възстановяване за МСП [BRP-SME], раздел „Изисквания за управление“, клауза 5.3.3 на политиката, изисква:

Тестовете за възстановяване се провеждат най-малко на тримесечна база, а резултатите се документират за проверка на възстановимостта

Това едно изречение променя разговора при одит. То премества организацията от „имаме резервни копия“ към „проверяваме възстановимостта с определена периодичност и съхраняваме резултатите“.

Същата Политика за резервно копиране и възстановяване за МСП, раздел „Прилагане и съответствие“, клауза 8.2.2 на политиката, засилва задължението за доказателства:

Журналите и записите от тестове за възстановяване се съхраняват за целите на одита

Тази клауза не допуска тестването на възстановяването да остане недокументирана институционална памет. Ако инженер по инфраструктурата каже „тествахме това през март“, но няма запис, това не е доказателство, готово за одит.

Същата политика разглежда и устойчивостта чрез разнообразие на местата за съхранение. В раздел „Изисквания за внедряване на политиката“, клауза 6.3.1.1 на политиката, резервните копия трябва да бъдат:

Съхранявани най-малко на две местоположения (локално и в облак)

Това е практичен базов минимум. Той не замества оценката на риска, но намалява вероятността един физически или логически домейн на отказ да унищожи едновременно продукционните и резервните данни.

Веригата от доказателства по ISO 27001:2022 започва преди теста

Организациите често третират съответствието при резервното копиране като тема на ИТ операциите. От гледна точка на ISO 27001:2022 това е твърде ограничено. Тестването на резервни копия и възстановяване трябва да бъде вградено в системата за управление на информационната сигурност, свързано с обхвата, риска, избора на контроли, мониторинга, вътрешния одит и непрекъснатото подобрение.

Zenith Blueprint: 30-стъпкова пътна карта за одитори [ZB] на Clarysec започва тази верига от доказателства още преди да бъде извършен какъвто и да е тест за възстановяване.

Във фазата „Основа и лидерство на ISMS“, стъпка 2, „Потребности на заинтересованите страни и обхват на ISMS“, Zenith Blueprint инструктира организациите да определят какво попада в ISMS:

Действие 4.3: Изгответе декларация за обхвата на ISMS. Избройте какво е включено (бизнес звена, местоположения, системи) и всички изключения. Споделете този проект с висшето ръководство за становище – то трябва да се съгласи кои части от бизнеса ще бъдат предмет на ISMS. Разумно е също да проверите този обхват спрямо по-ранния списък с изисквания на заинтересованите страни: покрива ли вашият обхват всички области, необходими за изпълнение на тези изисквания?

За тестването на възстановяването обхватът определя вселената на възстановяване. Ако платформата за одобрение на плащания, доставчикът на идентичност, ERP базата данни, сървърът за управление на крайни точки и облачното обектно хранилище са в обхвата, доказателствата за възстановяване трябва да ги включват или да обосноват защо не ги включват. Ако система е изключена, изключението трябва да бъде защитимо спрямо изискванията на заинтересованите страни, договорните задължения, регулаторните задължения и нуждите за непрекъснатост на дейността.

Следващата връзка е рискът. Във фазата „Управление на риска“, стъпка 11, „Изграждане и документиране на регистъра на риска“, Zenith Blueprint описва регистъра на риска като основния запис на рискове, активи, заплахи, уязвимости, текущи контроли, собственици и решения за третиране.

Запис за риск, свързан с резервни копия, трябва да изглежда практично, а не теоретично.

Тук резервното копиране става подлежащо на одит. Вече не е „имаме резервни копия“. То е „идентифицирахме бизнес риск, избрахме контроли, възложихме собственост, тествахме контрола и съхранихме доказателства“.

Zenith Blueprint, фаза „Управление на риска“, стъпка 13, „Планиране на третиране на риска и Декларация за приложимост“, затваря цикъла на проследимост:

Съпоставете контролите с рисковете и клаузите (проследимост)

След като вече имате както План за третиране на риска, така и SoA:

✓ Съпоставете контролите с рисковете: В плана за третиране във вашия Регистър на риска сте посочили определени контроли за всеки риск. Можете да добавите колона „Annex A Control Reference“ към всеки риск и да посочите номерата на контролите.

За резервното копиране и тестването на възстановяване Декларацията за приложимост трябва да свързва сценария на риска с контролите от Приложение A на ISO/IEC 27001:2022, особено 8.13 Information backup, 5.30 ICT readiness for business continuity, 8.14 Redundancy of information processing facilities и 5.29 Information security during disruption.

SoA не трябва просто да маркира тези контроли като приложими. Тя трябва да обяснява защо са приложими, какви доказателства за внедряване съществуват, кой е собственикът на контрола и как се обработват изключенията.

Картата на контролите, която одиторите очакват да видят

Zenith Controls: Ръководство за кръстосано съответствие [ZC] на Clarysec не създава отделни или собственически контроли. То организира официални стандарти и рамки в практичен изглед за кръстосано съответствие, така че организациите да разбират как една оперативна практика, например тестването на възстановяване, подпомага множество задължения.

За ISO/IEC 27002:2022 control 8.13 Information backup Zenith Controls класифицира контрола като Corrective, свързан с Integrity и Availability, съгласуван с концепцията за киберсигурност Recover, подпомагащ оперативната способност Continuity и позициониран в домейна за сигурност Protection. Този профил преосмисля резервните копия като способност за възстановяване, а не просто като процес по съхранение.

За ISO/IEC 27002:2022 control 5.30 ICT readiness for business continuity Zenith Controls класифицира контрола като Corrective, фокусиран върху Availability, съгласуван с Respond, подпомагащ Continuity и позициониран в домейна за сигурност Resilience. Тук тестването на възстановяване се свързва пряко с оперативната устойчивост.

За ISO/IEC 27002:2022 control 8.14 Redundancy of information processing facilities Zenith Controls идентифицира Preventive control, фокусиран върху Availability, съгласуван с Protect, подпомагащ Continuity и управление на активите, и свързан с домейните Protection и Resilience. Резервираността и резервните копия не са едно и също. Резервираността помага да се предотврати прекъсване. Резервните копия позволяват възстановяване след загуба, повреда или атака.

За ISO/IEC 27002:2022 control 5.29 Information security during disruption Zenith Controls показва по-широк профил: Preventive и Corrective, обхващащ Confidentiality, Integrity и Availability, съгласуван с Protect и Respond, подпомагащ Continuity и свързан с Protection и Resilience. Това е важно при възстановяване след ransomware, защото възстановяването не трябва да създава нови откази на сигурността, като възстановяване на уязвими образи, заобикаляне на журналирането или повторно активиране на прекомерни привилегии.

Практическият извод е прост. Тестът за възстановяване не е един изолиран контрол. Той е доказателство по цяла верига на устойчивост.

Скритата одитна празнина: RTO и RPO без доказване

Една от най-честите одитни констатации при непрекъснатостта на дейността е разликата между документираните RTO/RPO и реалната способност за възстановяване.

Планът за непрекъснатост на дейността може да посочва, че клиентският портал има RTO от четири часа и RPO от един час. Платформата за резервни копия може да се изпълнява на всеки час. Но по време на първото реалистично упражнение за възстановяване екипът установява, че възстановяването на базата данни отнема три часа, промените в DNS изискват още един час, сертификатът на приложението е изтекъл, а интеграцията с идентичността никога не е била включена в инструкцията за възстановяване. Реалното време за възстановяване е осем часа.

Документираният RTO е бил фикция.

Политика за непрекъснатост на дейността и аварийно възстановяване за МСП [BCDR-SME] на Clarysec, раздел „Изисквания за управление“, клауза 5.2.1.4 на политиката, прави изискването за непрекъснатост изрично:

Целеви стойности за време за възстановяване (RTO) и целеви точки за възстановяване (RPO) за всяка система

Това е важно, защото „бързо възстановяване на критични услуги“ не е измеримо. „Възстановяване на базата данни за одобрение на плащания в рамките на четири часа с не повече от един час загуба на данни“ е измеримо.

Същата Политика за непрекъснатост на дейността и аварийно възстановяване за МСП, раздел „Изисквания за внедряване на политиката“, клауза 6.4.2, превръща тестването в подобрение:

Всички резултати от тестове трябва да бъдат документирани, а научените уроци трябва да бъдат записани и използвани за актуализиране на BCP.

Неуспешното възстановяване не е автоматично одитна катастрофа. Неуспешно възстановяване без документиран урок, собственик, корекция и повторен тест е.

За корпоративни среди Политика за резервно копиране и възстановяване [BRP] на Clarysec предоставя по-формално управление. В раздел „Изисквания за управление“, клауза 5.1 на политиката, се посочва:

Поддържа се главен график за резервно копиране, който се преглежда ежегодно. Той трябва да определя:

Това начално изискване установява основния управленски артефакт. Главният график за резервно копиране трябва да идентифицира системи, набори от данни, честота на резервно копиране, период на съхранение, местоположение, собственост, класификация, зависимости и периодичност на тестване.

Същата Политика за резервно копиране и възстановяване, раздел „Изисквания за управление“, клауза 5.2, свързва очакванията за резервно копиране с въздействието върху бизнеса:

Всички системи и приложения, класифицирани като Critical или High impact в анализа на въздействието върху бизнеса (BIA), трябва:

Тук BIA и управлението на резервните копия се свързват. Критичните системи и системите с високо въздействие изискват по-силно уверение за възстановяване, по-често тестване, по-добро картографиране на зависимостите и по-дисциплинирани доказателства.

Един модел на доказателства за ISO 27001:2022, NIS2, DORA, NIST и COBIT 2019

Екипите по съответствие често срещат трудности с дублирането между рамките. ISO 27001:2022 изисква избор на контроли и доказателства, основани на риска. NIS2 очаква мерки за управление на риска за киберсигурността, включително непрекъснатост на дейността. DORA очаква цифрова оперативна устойчивост на ИКТ, реагиране и възстановяване, процедури за резервно копиране и възстановяване и тестване на цифровата оперативна устойчивост. NIST и COBIT 2019 използват различен език.

Решението не е да се изграждат отделни програми за резервно копиране за всяка рамка. Решението е да се изгради един модел на доказателства, който може да бъде разглеждан през различни одитни перспективи.

За NIS2 най-пряката препратка е Article 21 относно мерките за управление на риска за киберсигурността. Article 21(2)(c) изрично включва непрекъснатост на дейността, като управление на резервни копия, аварийно възстановяване и управление на кризи. Article 21(2)(f) също е важен, защото разглежда политики и процедури за оценка на ефективността на мерките за управление на риска за киберсигурността. Тестовете за възстановяване са точно това: доказателство, че мярката работи.

За DORA най-силните връзки са Article 11 относно реагирането и възстановяването, Article 12 относно политиките и процедурите за резервно копиране, процедурите и методите за възстановяване, и Article 24 относно общите изисквания за тестване на цифровата оперативна устойчивост. За финансови организации само тест за възстановяване на база данни може да бъде недостатъчен, ако бизнес услугата зависи от облачна идентичност, свързаност с платежен шлюз, външно възложен хостинг или управляван мониторинг. Доказателствата в стила на DORA трябва да бъдат на ниво услуга, а не само на ниво сървър.

Това е ефективността на единната стратегия за съответствие. Тримесечен тест за възстановяване на платежна система може да подпомогне доказателствата по Приложение A на ISO 27001:2022, очакванията за непрекъснатост по NIS2, изискванията на DORA за възстановяване на ИКТ, резултатите Recover по NIST CSF и докладването по управление на COBIT 2019, ако доказателствата са структурирани правилно.

Практически тест за възстановяване, който става доказателство, готово за одит

Да се върнем към понеделнишкия сценарий на Sarah, но да си представим, че организацията ѝ е подготвена с инструментариума на Clarysec.

Платформата за одобрение на плащания е класифицирана като Critical в BIA. Одобреният RTO е четири часа. Одобреният RPO е един час. Платформата зависи от клъстер от бази данни, доставчик на идентичност, хранилище за тайни, поток за журналиране, DNS, сертификати и изходящ имейл relay.

Екипът на Sarah изгражда тримесечен тест за възстановяване около шест стъпки.

Стъпка 1: Потвърдете обхвата и зависимостите

Използвайки Zenith Blueprint стъпка 2, Sarah потвърждава, че платежната платформа, базата данни, интеграцията с идентичността, инфраструктурата за резервни копия и средата за възстановяване са в обхвата на ISMS. Правният отдел потвърждава регулаторната релевантност. Финансите потвърждават въздействието върху бизнеса. ИТ потвърждава зависимостите.

Това избягва класическата грешка да се възстанови само базата данни, като се игнорира услугата за автентикация, необходима за достъп до приложението.

Стъпка 2: Свържете теста с регистъра на риска

Използвайки Zenith Blueprint стъпка 11, регистърът на риска включва сценария: „Загуба или криптиране на данни от платформата за одобрение на плащания възпрепятства платежните операции и създава регулаторна експозиция.“

Текущите контроли включват ежедневни резервни копия, неизменяемо облачно хранилище, резервни копия на множество местоположения, тримесечно тестване на възстановяването и документирани инструкции за възстановяване. Собственикът на риска е ръководителят „Инфраструктура“. Собственикът от страна на бизнеса е „Финансови операции“. Решението за третиране е смекчаване.

Стъпка 3: Съпоставете третирането със SoA

Използвайки Zenith Blueprint стъпка 13, SoA съпоставя риска с контролите от Приложение A на ISO/IEC 27001:2022 8.13, 5.30, 8.14 и 5.29. SoA обяснява, че тестването на резервните копия осигурява коригираща способност за възстановяване, процедурите за непрекъснатост на ИКТ подпомагат непрекъснатостта на дейността, резервираността намалява вероятността от прекъсване, а сигурността по време на прекъсване предотвратява несигурни преки пътища при възстановяване.

Стъпка 4: Използвайте клаузите на политиките като критерии за теста

Екипът използва клауза 5.3.3 от Политика за резервно копиране и възстановяване за МСП за тримесечно тестване на възстановяването, клауза 8.2.2 за съхранение на доказателства и клауза 6.3.1.1 за съхранение на множество местоположения. Той използва клауза 5.2.1.4 от Политика за непрекъснатост на дейността и аварийно възстановяване за МСП за целевите стойности RTO/RPO и клауза 6.4.2 за научените уроци и актуализациите на BCP.

Стъпка 5: Изпълнете възстановяването и запишете фактите

Възстановяването се извършва в изолирана среда за възстановяване. Екипът записва времеви маркери, идентификатори на набора от резервни копия, стъпки за възстановяване, грешки, резултати от валидиране и одобрения.

Силен запис от тест за възстановяване трябва да включва:

По време на теста екипът открива един проблем. Възстановеното приложение не може да изпраща имейли за уведомяване, защото списъкът с разрешени адреси за имейл relay не включва подмрежата за възстановяване. Основното одобрение на плащания работи, но работният поток е деградирал.

Стъпка 6: Запишете научените уроци и коригиращото действие

Тук много организации спират твърде рано. Подходът на Clarysec насочва проблема към системата за подобрение.

Във фазата „Одит, преглед и подобрение“, стъпка 29, „Непрекъснато подобрение“, Zenith Blueprint използва CAPA журнал за проследяване на описание на проблема, анализ на първопричината, коригиращо действие, собственик, целева дата и статус.

Този единичен тест за възстановяване вече създава верига от доказателства, готова за одит: изискване на политиката, потвърждение на обхвата, съпоставяне с риска, съпоставяне със SoA, план за тест, запис от изпълнение, бизнес валидиране, валидиране на сигурността, запис на проблем, коригиращо действие и актуализация на BCP.

Как различните одитори проверяват едни и същи доказателства

Силен пакет от доказателства предвижда перспективата на одитора.

Одитор по ISO 27001:2022 обикновено започва със системата за управление. Той ще попита дали изискванията за резервно копиране и възстановяване са обхванати, основани на риска, внедрени, наблюдавани, вътрешно одитирани и подобрявани. Ще очаква проследимост от регистъра на риска към SoA и към оперативните записи. Може също да свърже неуспешните тестове и коригиращите действия с ISO/IEC 27001:2022 clause 10.2 относно несъответствие и коригиращо действие.

Проверяващ по DORA ще се фокусира върху цифровата оперативна устойчивост на ИКТ за критични или важни функции. Той ще иска да види възстановяване на ниво услуга, зависимости от ИКТ трети страни, сценарийно тестване, надзор от управителния орган и доказателства, че процедурите за възстановяване са ефективни.

Надзорната перспектива по NIS2 ще търси подходящи и пропорционални мерки за управление на риска за киберсигурността. Доказателствата за резервно копиране и аварийно възстановяване трябва да показват, че съществените или важни услуги могат да поддържат или възстановяват операции след инциденти, като ръководството е запознато с остатъчния риск.

Оценител, ориентиран към NIST, ще се фокусира върху резултатите в киберсигурността през Identify, Protect, Detect, Respond и Recover. Той може да попита за неизменяеми резервни копия, привилегирован достъп до хранилища за резервни копия, възстановяване в чисти среди, комуникации и научени уроци.

Одитор по COBIT 2019 или в стил ISACA ще акцентира върху управлението, собствеността върху процесите, показателите, докладването към ръководството и проследяването на проблеми. Той ще бъде по-малко впечатлен от технически елегантно възстановяване, ако собствеността и докладването са неясни.

Едни и същи доказателства могат да удовлетворят всички тези перспективи, но само ако са пълни.

Чести провали при тестването на възстановяване, които създават одитни констатации

Clarysec многократно вижда едни и същи предотвратими пропуски в доказателствата.

Целта не е бюрокрация. Целта е надеждно възстановяване под натиск и защитими доказателства при одит.

Изградете пакет от доказателства за възстановяване на ниво управителен орган

Висшите ръководители не се нуждаят от сурови журнали за резервни копия. Те се нуждаят от увереност, че критичните услуги са възстановими, изключенията са известни и действията за подобрение напредват.

За всяка критична услуга докладвайте:

• Име на услугата и собственик от страна на бизнеса
• Критичност от BIA
• Одобрени RTO и RPO
• Дата на последния тест за възстановяване
• Постигнати RTO и RPO
• Резултат от теста
• Отворени коригиращи действия
• Зависимости от трети страни, засягащи възстановяването
• Декларация за остатъчен риск
• Следващ планиран тест

Този стил на докладване създава мост между техническите екипи, одиторите и ръководството. Той също така подпомага прегледа от ръководството на ISMS и надзора върху устойчивостта по NIS2 и DORA.

Практически одитен контролен списък за следващите 30 до 90 дни

Ако одитът ви наближава, започнете с доказателствата, които вече имате, и първо затворете пропуските с най-висок риск.

• Идентифицирайте всички Critical и High impact системи от BIA.
• Потвърдете RTO и RPO за всяка критична система.
• Проверете дали всяка критична система присъства в главния график за резервно копиране.
• Потвърдете местоположенията на резервните копия, включително локални, облачни, неизменяеми или сегрегирани хранилища.
• Изберете поне един скорошен тест за възстановяване за всяка критична услуга или планирайте тест незабавно.
• Уверете се, че записите от тестове за възстановяване показват обхват, времеви маркери, набор от резервни копия, резултат, постигнати RTO/RPO и валидиране.
• Получете потвърждение от собственик на бизнеса за възстановяване на ниво приложение.
• Валидирайте сигурността след възстановяване, включително контрол на достъпа, журналиране, мониторинг, тайни, сертификати и експозиция на уязвимости.
• Съпоставете доказателствата с регистъра на риска и SoA.
• Запишете проблемите в CAPA, възложете собственици и проследете повторния тест.
• Обобщете резултатите за преглед от ръководството.
• Подгответе изглед за кръстосано съответствие за одитни разговори по ISO 27001:2022, NIS2, DORA, NIST CSF и COBIT 2019.

Ако не можете да изпълните всеки елемент преди одита, бъдете прозрачни. Одиторите обикновено реагират по-добре на документиран пропуск с план за коригиращи действия, отколкото на неясни твърдения за зрялост.

Превърнете тестването на възстановяване в най-силното си доказателство за устойчивост

Тестването на резервни копия и възстановяване е един от най-ясните начини да се докаже оперативна устойчивост. То е конкретно, измеримо, релевантно за бизнеса и пряко свързано с ISO 27001:2022, NIS2, DORA, NIST, COBIT 2019, докладването към управителния орган, клиентските искания за потвърждение на контролите и очакванията на застрахователите.

Но само ако е документирано правилно.

Clarysec помага на организациите да превърнат операциите по резервно копиране в доказателства, готови за одит, чрез Политика за резервно копиране и възстановяване, Политика за резервно копиране и възстановяване за МСП, Политика за непрекъснатост на дейността и аварийно възстановяване за МСП, Zenith Blueprint и Zenith Controls.

Следващото практическо действие е просто. Изберете една критична услуга тази седмица. Изпълнете тест за възстановяване спрямо одобрените ѝ RTO и RPO. Документирайте резултата. Съпоставете го с регистъра на риска и SoA. Запишете всеки научен урок.

Ако искате този процес да бъде повторяем в ISO 27001:2022, NIS2, DORA, NIST и COBIT 2019, инструментариумът на Clarysec ви дава структурата да докажете възстановяване, без да изграждате лабиринт за съответствие от нулата.