Изисква ли SOC 2 тест за проникване?

Не. Нито един критерий от Trust Services Criteria не казва „организацията трябва да извърши тест за проникване“. Ако сте дошли само за този факт, вече го имате. Но „не е задължително“ и „не е необходимо“ са много различни твърдения, а смесването им е начинът, по който организациите се оказват в тежък разговор с одитора си шест седмици преди крайния срок за доклада. Ето какво в действителност казват критериите и откъде идва истинското задължение.

Краткият отговор

SOC 2 не изисква изрично тест за проникване. Trust Services Criteria на AICPA — контролните критерии, спрямо които се извършва проверката по SOC 2 — не съдържат критерий, който да назовава тестването за проникване като задължителна дейност. Няма точка, по която да се провалите за това, че нямате такъв: няма минимална честота, няма изискван метод, няма предписан обхват.

Тестването за проникване се появява в критериите точно веднъж, и то като пример — един от няколкото илюстративни типа оценка, изброени в точка за фокус под критерий CC4.1. Точките за фокус са поясняващо ръководство, не изисквания. Ще се върнем към това разграничение, защото то е най-неразбираното за SOC 2 и източникът на по-голямата част от объркването тук.

Дотук — успокоително. Ето частта, която има повече значение. SOC 2 не е стандарт-списък за отметки, а набор от ориентирани към резултата критерии, оценявани от лицензирана CPA фирма, упражняваща професионална преценка. Въпросът, който определя доклада ви, не е „извършихте ли задължителния тест за проникване?“. Той е дали можете да докажете, с доказателства, че имате контроли, подходящо проектирани и действащи, за да откриват уязвимости в системите ви, и че ръководството оценява дали тези контроли са налице и функционират. Тестът за проникване е един от най-практичните и най-четими за одитора начини да се отговори на това, а за много организации с продукт, изложен към интернет, е единственият отговор, който издържа без много компенсиращо обяснение.

На практика тогава: стандартът не ви задължава. Преценката на вашия одитор, вашата оценка на риска, собствените ви описания на контролите и въпросниците на клиентите ви много често ви задължават. Тази част покрива какво наистина казват критериите, така че когато някой ви каже, че тестът за проникване е „изискване на SOC 2“, да знаете точно колко греши и в коя посока.

Какво в действителност казват Trust Services Criteria

За да четете SOC 2 точно, трябва да знаете, че изходният документ има два слоя и само единият е обвързващ.

Критериите са еталоните: твърденията, спрямо които се оценяват контролите ви, и одиторът ви трябва да заключи по всеки приложим. За категорията сигурност — общите критерии, налични във всеки доклад по SOC 2 — те са организирани в девет групи, CC1 до CC9: контролна среда, комуникация и информация, оценка на риска, дейности по наблюдение, контролни дейности, логически и физически достъп, системни операции, управление на промените и смекчаване на риска. Първите пет са умишлено приведени в съответствие с рамката за вътрешен контрол COSO и нейните седемнадесет принципа; останалите четири разглеждат въпроси за информацията и системите, които COSO не достига.

Точките за фокус са вторият слой. Всеки критерий е придружен от кратки твърдения, илюстриращи характеристики, които контрол, отговарящ на този критерий, би могъл да има, за да помогне на организациите да проектират контроли и на практикуващите да мислят за относимите доказателства. Те изрично не са списък за отметки. Ръководството на AICPA е ясно, че оценка дали всяка точка за фокус е изпълнена не се изисква, че не всяка точка за фокус ще е относима към дадена организация и че те могат да бъдат пригаждани или пренебрегвани, когато не пасват. Критериите от 2017 г. остават в сила с преработени точки за фокус, издадени през 2022 г.: самите критерии не бяха пренаписани, само илюстративното ръководство бе опреснено. Тази история сама по себе си е знак за това кой слой носи тежест.

С тази структура наум, ето критериите, които наистина имат отношение към тестването на сигурността. Изброяваме само тези четири: твърденията, че тестването за проникване е „изисквано от“ CC9.1, CC6.x или CC8.1, почиват на извод за това как би изглеждал един разумен контрол, не на текста на критерий.

• CC4.1 — дейности по наблюдение. Критерият изисква организацията да подбира, разработва и извършва текущи и/или отделни оценки, за да установи дали компонентите на вътрешния контрол са налице и функционират. Той съответства на Принцип 16 на COSO и е мястото, където тестването за проникване е назовано — не в текста на критерия, а в точка за фокус за разглеждането на различни типове текущи и отделни оценки, която предлага тестването за проникване, независимата сертификация спрямо установени спецификации като ISO и оценките на вътрешния одит като примери. Забележете за какво наистина става дума в критерия: наблюдение. Той пита дали ръководството независимо проверява, че собствената му контролна система работи, вместо да го приема на доверие.
• CC4.2 — съобщаване на пропуски. Организацията оценява и съобщава пропуските във вътрешния контрол своевременно на отговорните за коригиращо действие, включително на висшето ръководство и борда, където е уместно. Ето защо непрочетен доклад от тест може да е по-лошо от никакъв тест: констатации, които не отидоха наникъде, са доказателство срещу вас.
• CC7.1 — откриване на уязвимости. Критерият изисква, за да постигне целите си, организацията да използва процедури за откриване и наблюдение, за да идентифицира промени в конфигурациите, въвеждащи нови уязвимости, и податливост към новооткрити уязвимости. Точките му за фокус разглеждат определени стандарти за конфигурация, механизми за откриване на промени, откриване на непознати или неоторизирани компоненти и извършване на сканирания за уязвимости периодично и след значителна промяна със своевременно отстраняване. Бъдете точни тук, защото това широко се цитира погрешно: илюстративното ръководство на CC7.1 сочи към сканиране за уязвимости, не към тестване за проникване. Двете не са взаимозаменяеми, а третирането на тримесечно удостоверено сканиране, все едно е освободило от очакване за тестване за проникване, е честа и избежима грешка.
• CC3.2 — идентифициране на риска. Организацията идентифицира рисковете за постигането на целите си и ги анализира като основа за определяне как да бъдат управлявани. Тук решение да не се тества трябва да бъде обосновано: ако оценката ви на риска назовава компрометиране на приложния слой като съществено, а наборът ви от контроли не съдържа нищо, което би го открило, одиторът ви може основателно да изследва непоследователността.

Защо стандартът е написан така

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

SOC 2 е основан на критерии, а не предписващ. Предписващ стандарт изброява контроли: направете това, с тази честота, по тази спецификация. PCI DSS работи в много по-голяма степен така, затова носи изрично изискване за тестване за проникване с посочен обхват и честота, докато SOC 2 — не. Стандарт, основан на критерии, заявява резултата, който трябва да бъде постигнат, и оставя организацията да подбере контроли, подходящи за нейния размер, сложност, технология и рисков профил. Логиката е практична: критериите трябва да работят еднакво за SaaS платформа, дружество за обработка на заплати и оператор на център за данни, а списък с контроли, достатъчно конкретен за единия, би бил абсурден за другия.

За купувача последствието е неудобно, но просто. Гъвкавостта в стандарта не означава гъвкавост на практика. Стандартът отказва да предпише контрол, затова нещо друго запълва вакуума: преценката на одитора ви за това какво представлява достатъчно подходящо доказателство, контролите, които вие самите заявихте в описанието на системата си, преобладаващата практика сред сравними фирми и очакванията на клиентите ви, изразени чрез въпросници и договори. Нищо от това не е по избор така, както е стандартът. Разменили сте ясно правило за преговори — с хора, които са видели твърде много ангажименти по SOC 2 и имат установена представа за това как изглежда нормалното.

Тип 1 и Тип 2, и защо това променя отговора

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

Type 1 разглежда описанието на системата и пригодността на дизайна на контролите към определена дата за проектираната и внедрена към този момент система. Той не дава мнение за оперативната ефективност през период. Type 2 добавя такова мнение за определен период. Нито един не трябва да се описва като гаранция за сигурност или само преглед на документи.

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

При Type 2 одиторът оценява оперативната ефективност през определения период. Доказателствата за тестване, решенията за поправки и честотата трябва да съответстват на описанието и рисковете. Отворените находки изискват оценка; самото им наличие не установява автоматично провал по конкретен критерий. Данни отпреди или след периода могат да информират оценката, но не заместват доказателствата за работа в него.

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

Защо вероятно пак ще ви поискат такъв

Отсъствието на задължение не е отсъствие на очакване. На практика повечето организации, преминаващи през проверка по SOC 2, възлагат тест за проникване, по три причини, несвързани с никакво писано правило.

Първата е преценката на одитора на услуги за доказателствата. Критериите изискват ръководството да оценява дали контролите са налице и функционират и изискват процедури за откриване, способни да идентифицират нови уязвимости, въведени от промени в конфигурацията. Как удовлетворявате това е ваш избор; контролите не са предписани. Но точките за фокус, публикувани наред с критериите, наистина назовават тестването за проникване като един вид оценка, която ръководството би могло да използва, наред с независими сертификации и работа на вътрешен одит. Това е поясняващо, а не задължително, и все пак оформя това, което опитен одитор очаква, когато попита как оценявате собствените си контроли. Ако отговорът е тримесечно автоматизирано сканиране и нищо друго, молите ги да приемат по-тясна доказателствена база от онази, която повечето от клиентите им представят. Някои ще го направят; мнозина ще възразят.

Втората е търговска и обикновено пристига преди одита. Корпоративните отдели по доставки и управление на риска от трети страни работят от стандартизирани въпросници за сигурност, а те питат за тестване за проникване пряко, обикновено с прикачена честота и обхват. Същото изискване често се появява в приложението за сигурност на рамков договор за услуги: годишен тест на продукционната среда от квалифицирана независима страна, с резюме, достъпно при поискване. Щом тази клауза е подписана, тествате, защото договорът го казва, а докладът по SOC 2 става удобно място да го докажете.

Управлението на риска е още една причина за тестове. Общите сканирания може да не познават очакваните права между организации или бизнес правилата. Човешката оценка може да установи контекста, а конфигурирани инструменти да подпомогнат проверката. Дали слабостта влияе на мнението по SOC 2 остава въпрос за оценката на съответните контроли и доказателства от одитора.

Нищо от това не прави теста задължителен. То го прави пътя на най-малкото съпротивление — практика и търговска реалност, а не правило.

Кога да тествате в рамките на одитния период

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

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

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

Тест, завършен след края на периода, добавя много малко към този доклад. Той не се е случил през периода на разглеждане, затова не може да докаже контрол, действащ по време на него. Екипите понякога очакват късен тест да бъде признат със задна дата, защото малко се е променило; одиторите обикновено не желаят, а разсъждението е здраво — тестът оценява конкретен билд в даден момент, а относимостта му спада с движението на средата. Първоначалните периоди често са кратки, три месеца е най-краткият обичайно срещан на практика, оставяйки почти никакво място.

Какво одиторът всъщност иска да види

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

• Определен обхват, обвързан с описанието на системата. Разделът за обхват на доклада трябва да назовава оценените среди, приложения, домейни и инфраструктура с термини, които читателят може да съпостави с описаната граница, с дати, тестваните удостоверени роли и всякакви изключения и причините за тях.
• Доказателство, че работата е свършена от някого подходящо независим и компетентен. Тестерът не е нужно да е външен; умел вътрешен екип, независим от онези, които са я изградили, може да е приемлив. Одиторите търсят някаква основа да вярват, че тестерите са били квалифицирани и не са оценявали собствената си работа — назована фирма, заявен метод, удостоверения или вътрешна документация за разделение и умения.
• Констатациите и степента им на сериозност. Всяка оценена по заявена схема, с достатъчно детайл, за да действа отговорник за отстраняването. Критичността има значение, защото собствената ви политика обвързва сроковете за отстраняване с нея, а тази политика е мерилото, спрямо което реакцията ви се измерва.
• Доказателство за отстраняване. Заявки, записи за промени, препратки към комити, времеви печати — показващи, че констатациите са били разпределени, обработени и затворени в сроковете, към които политиката ви се обвързва. Там, където сте избрали да не отстранявате, документирано приемане на риск с назован одобряващ и обосновка служи за същата цел.
• Потвърждение за затваряне. Повторен тест е най-чистата форма, в идеалния случай отделен датиран документ, заявяващ кои констатации са проверени като поправени и кои не. Там, където пълен повторен тест е непропорционален, целенасочено доказателство за проверка може да послужи, стига видимо да адресира конкретната констатация.

PDF без следа от отстраняване е слабо доказателство. Той показва, че сте купили тест; не показва, че процесът ви на откриване, оценка и отстраняване е работил, което е контролът, който сте описали. Най-силният пакет е доклад от тест, журнал за отстраняване, препращащ към идентификаторите на констатациите му, и писмо за повторен тест — три документа, които се четат като един непрекъснат разказ. Нашият примерен доклад показва изявлението за обхват, формата на констатациите и раздела за повторен тест.

Определяне на обхват на тест, който подкрепя доклада

Определянето на обхват на тест в подкрепа на доклад по SOC 2 не е първо технически въпрос. То е въпрос за границата, описана в този доклад — инфраструктурата, софтуера, процедурите и данните, използвани за доставяне на услугите в обхвата. Започнете от описанието на системата, избройте компонентите в границата и установете кои могат смислено да бъдат оценени от позицията на нападател.

За типична SaaS платформа това се свежда до четири области. Продукционната среда, или стейджинг среда, видимо изградена от същия код и конфигурация, тъй като констатации спрямо несходна среда казват малко за системата под разглеждане. Пътищата за удостоверяване и сесии — вход, нулиране на парола, записване и заобикаляне на многофакторно удостоверяване, SSO, обработка на токени и API данни за достъп — портата пред всичко, което докладът заявява. Границите между клиентски организации, тествани с поне два акаунта под отделни клиентски организации, така че контролът на достъпа между клиентите да бъде упражнен, а не допуснат. И поддържащата облачна инфраструктура: IAM роли и политики на доверие, изложеност на хранилища, мрежова сегментация, обработка на тайни, конфигурация на контейнери и пайплайнът за внедряване там, където достига продукционната среда.

Честото несъответствие е банално и скъпо. Организация тества публичния си уебсайт, защото той беше очевидната външна повърхност, докато докладът по SOC 2 покрива клиентската платформа зад входа. Тестът е валиден и напълно неотносим към доклада: нищо в описаната граница не е оценено. Изобилстват по-фини версии — уеб приложението, но не API-то, обслужващо същите данни, един регион, докато описанието покрива три, тестова клиентска организация без логиката на продукционната среда за оторизация. Одиторът чете раздела за обхват и вижда пропуска; решението обикновено е втори тест по свит график.

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

Грешки, които струват време при одита

Провалите по-долу надеждно създават допълнителна работа по време на одитната работа. Нито един не е технически; всички са провали в планирането.

• Представяне на сканиране за уязвимости като тест за проникване. Сканирането е ценно и трябва да върви непрекъснато, но генериран от инструмент списък с констатации има други граници: няма да упражни изолация между клиентски организации, бизнес логика или верижна ескалация на права. Одитори, които четат много такива, разпознават разликата само по заглавията на констатациите.
• Тестване извън периода. Все още най-честата грешка във времето. Тест, датиран две седмици след края на периода, не доказва нищо за този период.
• Няма повторен тест или потвърждение на затваряне. Отстраняване, което никога не е проверено, е твърдение, не доказателство — най-лесният пропуск за затваряне и онзи, най-често оставян отворен, обикновено защото повторният тест не е бил в първоначалния бюджет.
• Обхват, който не съответства на описанието на системата. Или тестът покрива по-малко от границата, или покрива нещо съседно на нея. И двете оставят одитора неспособен да свърже доказателството със системата под разглеждане.
• Констатации, оставени отворени без документирано рисково решение. Правомерно е да решите, че констатация със средна критичност няма да бъде поправена. Не е правомерно да я оставите там без запис кой е решил, на каква основа и кога позицията ще бъде преразгледана. Недокументираното бездействие изглежда идентично с нехайство.
• Допускане, че миналогодишният тест се пренася. Тест от предишния период доказва предишния период. Ако контролът ви се обвързва с годишно тестване, всеки период се нуждае от собствен тест, следа от отстраняване и проверка. Мостовите писма говорят за непрекъснатост на контрола между периодите; те не заместват тестване в рамките на настоящия.