Тест за проникване за SOC 2: изберете тест, който информира за сигурността

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

За CTO полезният въпрос не е просто дали тестът е завършен. Въпросът е дали ангажиментът проверява контролите, които защитават клиентските данни, и дали дава констатации, които екипът може да възпроизведе, поправи и провери.

Какво изисква SOC 2 и какво не

SOC 2 е доклад за атестация, а не сертификация. Неговите критерии се основават на принципи; те не налагат едно универсално изискване за тест за проникване или годишна честота за всяка организация. Рискът, контролите, които описвате, очакванията на одитора и договорите с клиенти определят какво тестване е подходящо.

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

Увереността на клиентите е отделно съображение. Купувач може да изисква независим тест на приложението дори когато вашият подход към одита не го предписва. Установете тези очаквания рано, но не позволявайте контролен списък от отдела за покупки да замени техническото определяне на обхвата. Нито SOC 2 доклад, нито тест за проникване установяват, че една система няма уязвимости.

Определете обхвата на повърхността за атака, а не само на уебсайта

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

При SaaS продукт с множество наематели тестването само на публичната начална страница оставя важните граници на приложението непроверени. Дайте на доставчика регистър, който включва API интерфейси, фонова обработка, административни инструменти и релевантна инфраструктура, а не само списък с домейни.

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

Изберете метод, който отговаря на вашите въпроси

Автоматизираното сканиране идентифицира потенциални слабости и подкрепя редовната хигиена. Тестът за проникване добавя квалифицирано изследване на експлоатируемостта и смислените пътища за атака в рамките на разрешен обхват. Инструментите са полезни; експорт от скенер, преименуван на тест за проникване, не е равностоен на такова изследване.

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

При тестването на оторизацията в приложението акаунти в няколко роли и наематели могат да направят изследването по-ефективно. Само тестването на външната инфраструктура не може да установи дали удостоверени потребители могат да преминават границите между наемателите.

Оценете доставчика и резултатите

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

Преди да подпишете, изяснете:

• Кои системи, роли и пътища за атака са обхванати и как се разпределят усилията.
• Какво ръчно изследване допълва автоматизираните инструменти.
• Как се съобщават спешните констатации преди окончателния доклад.
• Дали констатациите включват възпроизводими доказателства, засегнати компоненти, въздействие и насоки за отстраняване.
• Дали повторното тестване е включено, в какъв срок и какво се случва, ако поправките пристигнат по-късно.
• Как докладите, идентификационните данни и уловените данни се защитават и в крайна сметка изтриват.

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

Установете правила за безопасно изпълнение

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

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

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

Практически пример: констатация за изолацията между наемателите

Разгледайте илюстративен SaaS ангажимент. Да приемем, че продуктът има два тестови наематели, обикновени потребители, администратори на наематели и роля за поддръжка. Тестът включва удостоверени API интерфейси и работни процеси за експорт; инфраструктурата за идентичност на трети страни е изключена.

Тестващ открива, че крайна точка за експорт валидира входа, но не налага последователно собствеността на наемателя. С помощта на синтетични записи той демонстрира, че потребител от наемател A може да поиска експорт, принадлежащ на наемател B.

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

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

Превърнете констатациите в инженерна работа с отговорност

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

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

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

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

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

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

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

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