По изискване
Тестване на сигурността по ISO 27001, на което одиторът ви може да разчита
ISO/IEC 27001:2022 не изисква тест за проникване. Контролите от Приложение А обхващат управлението на техническите уязвимости, тестването на сигурността при разработка и приемане и независимия преглед на информационната сигурност. Ние провеждаме тестване, което показва, че избраните от вас контроли работят.
Какво изисква
Какво всъщност изисква ISO/IEC 27001 от тестването на сигурността
ISO/IEC 27001 е стандарт за система за управление. Клаузи 4 до 10 са задължителни, а Приложение А изброява 93 референтни контрола в четири теми: организационни, свързани с хора, физически и технологични. Вие определяте нужните ви контроли чрез третиране на риска и записвате решението в Декларация за приложимост, като обосновавате включванията и изключванията. Нищо в стандарта не казва, че трябва да възложите тест за проникване, така че твърденията, че го изисква, преувеличават. Това, което стандартът наистина изисква, е избраните от вас контроли да бъдат внедрени и резултатността на информационната сигурност и ефективността на системата за управление да бъдат наблюдавани и оценявани.
Тук се включва тестването. Контроли като 8.8 за техническите уязвимости и 8.29 за тестване на сигурността при разработка и приемане трудно се доказват без техническо тестване, а външното тестване може да подкрепи и независимия преглед по 5.35. Сертификационните одити обикновено са извадкови, а одиторите често питат откъде знаете, че даден контрол работи, така че тест с ясно определен обхват и документация с проследено отстраняване често е най-ясният отговор. Честотата, дълбочината и обхвата определяте вие, съразмерно на риска, а щом веднъж бъдат записани във вашата система за управление, можете да очаквате да бъдете одитирани спрямо тях.
Приложение А 8.8 Управление на техническите уязвимости
Очаква се да узнавате за техническите уязвимости в системите, които използвате, да преценявате колко сте изложени и да предприемате съразмерни действия. Сканирането за уязвимости и тестването за проникване показват как се идентифицира експозицията; записите за отстраняване и повторните тестове показват какво сте направили по въпроса.
Приложение А 8.29 Тестване на сигурността при разработка и приемане
Очаква се процесите по тестване на сигурността да бъдат определени и изпълнявани като част от жизнения цикъл на разработката. Тестването на приложенията преди пускане и тестването на нови или променени системи преди приемане дава пряко доказателство, че изискванията за сигурност действително са изпълнени.
Приложение А 5.35 Независим преглед на информационната сигурност
Вашият подход към управлението на информационната сигурност и начинът, по който той се прилага през хора, процеси и технологии, следва да бъде преглеждан независимо на планирани интервали или при значителни промени. Този преглед обикновено стъпва върху одит, но тестване от страна, независима от екипа, който управлява системите, може да допринесе към него.
Приложение А 5.36 Съответствие с политики, правила и стандарти
Следва редовно да проверявате дали вашите собствени политики, правила и стандарти за сигурност се спазват. Техническите проверки спрямо вашите стандарти за укрепване на защитата, достъп и конфигурация показват дали те издържат на практика, а не само на хартия.
Приложение А 8.34 Защита на информационните системи по време на одитно тестване
Одитните тестове и другите проверки на работещи системи трябва да бъдат планирани предварително и съгласувани с отговорното ръководство. Договорените правила, периоди за работа и ограничения за обработка на данни намаляват риска от смущения и документират контрола върху самата проверка.
Какво да се тества
Какво трябва да обхване един воден от риска тест по ISO 27001
Среда, достъпна от интернет
Уебсайтове, API, отдалечен достъп и облачни услуги в обхвата на вашата система за управление, приоритизирани според рисковете в регистъра ви, а не според това, което скенерът случайно открие.
Приложения в обхвата
Приложения, които изграждате или купувате и които обработват информация в обхвата на системата за управление, тествани преди пускане или приемане и след значима промяна, в подкрепа на 8.29 и вашите контроли за сигурна разработка.
Вътрешна мрежа и идентичност
Директорийни услуги, привилегирован достъп, разделяне между мрежи и облачна идентичност, тествани от позиция на предполагаем пробив, където една слабост може да подкопае много контроли от Приложение А наведнъж.
Хора и процеси
Когато оценката ви на риска го налага, социално инженерство или тестване по сценарии, което проверява дали контролите за осведоменост, сигнализиране и реакция при инциденти работят под реалистичен натиск.
Какво получавате
Какво получавате и как то подкрепя вашите одитни доказателства
Обхват, обвързан с вашата система за управление
Запис за обхвата, свързващ тестваните активи с обхвата на вашата система за управление и регистъра на рисковете, за да може одиторът да види защо точно тези системи са тествани и как е взето решението.
Доклад, съотнесен към Приложение А
Констатации със степен на критичност, доказателства и съвети за отстраняване, всяка от които препратена към съответните контроли от Приложение А, което улеснява използването на резултатите при третирането на риска и прегледа от ръководството.
Запис за повторен тест и закриване
Проверка кои констатации са отстранени и кои остават отворени, в подкрепа на 8.8 и като показател, че несъответствията и слабостите се проследяват докрай, а не се подреждат в папка.
Правила на ангажимента
Писмено разрешение, периоди за работа, контакти и правила за обработка на данни, съгласувани с ръководството преди теста. Те подкрепят контрол 8.34 и показват как е управляван рискът от самото тестване.
Чести капани
Къде тестването по ISO 27001 се обърква
Грешки, които струват време при одит, и как да ги избегнете.
Обхват, който подминава системата за управление
Тест на маркетинговия уебсайт, докато основните системи стоят нетествани, дава слаби доказателства. Одиторите обикновено търсят съответствие между обхвата на теста, обхвата на системата за управление и рисковете, които сте записали.
Политики, които не можете да изпълните
Да запишете тримесечно тестване в политиката си и после да тествате веднъж годишно означава сами да си създадете несъответствие. Определете ритъм, който рискът ви оправдава и бюджетът ви може да издържи.
Доклади без третиране
Доклад от тест с отворени критични констатации и без решения за третиране подсказва, че 8.8 не действа. Записвайте дали всяка констатация е отстранена, приета или планирана, с посочено отговорно лице.
Сканиране, представено като независим преглед
Автоматизираните сканирания са полезно доказателство за уязвимости, но 5.35 се отнася до цялостния ви подход към информационната сигурност, така че сканиранията сами по себе си не представляват такъв преглед. Бъдете ясни пред одитора си какво демонстрира всяка дейност.
Кой решава какво се приема
PXLSec е независима фирма за офанзивна сигурност, не одитор, оценител, сертифициращ орган или регулатор. Ние осигуряваме тестването и доказателствата; вашият одитор, оценител или компетентен орган решава какво приема. Тази страница е обща насока, не юридически съвет. Обобщаваме тези изисквания със свои думи въз основа на публично достъпни указания; винаги проверявайте точната формулировка спрямо официалния стандарт, преди да се позовавате на нея.
Често задавани въпроси
Често задавани въпроси
Изисква ли ISO 27001 тест за проникване?
Не. ISO/IEC 27001:2022 не изисква тестване за проникване. Изисква да третирате рисковете за информационната сигурност и да покажете, че избраните от вас контроли действат, а за контроли като 8.8 и 8.29 тестът за проникване е често срещан и практичен начин да осигурите това доказателство.
Какво ще иска да види сертификационният одитор?
Практиката се различава между сертифициращите органи, но одиторите обикновено търсят доказателство, че техническите уязвимости се идентифицират и адресират: доклади от тестове или сканирания, записи за отстраняване, решения за приемане на риск и повторни тестове. Те често търсят и съгласуваност между вашата политика, Декларацията за приложимост и това, което действително сте направили.
Колко често да тестваме за ISO 27001?
Стандартът не задава честота на тестване. Определете я според вашата оценка на риска, темпото на промяна в системите ви и евентуални очаквания от клиенти или договори, запишете я в системата си за управление и след това я спазвайте, защото одиторите обикновено проверяват спрямо това, което сте определили.
Може ли тестът за проникване да се брои за независимия преглед по 5.35?
Може да допринесе. Контрол 5.35 се отнася до цялостния подход към управлението на информационната сигурност. Външният технически тест предоставя доказателства за част от него и допълва вътрешния одит и другите независими прегледи.
Вие ли сте нашият сертифициращ орган или одитор?
Не. PXLSec не е сертифициращ орган или ISO одитор и не сертифицира, нито потвърждава съответствие с ISO/IEC 27001. Ние извършваме тестването на сигурността и го документираме, за да може вашият одитор да го оцени като част от собствената си оценка.
Това одитен или правен съвет ли е?
Не. Това е обща насока, основана на нашето разбиране за ISO/IEC 27001:2022 и контролите от Приложение А. Как стандартът се прилага за вас е въпрос на вашата собствена оценка на риска и на вашия сертифициращ орган, затова потвърдете очакванията с тях.
Услуги, които осигуряват това
Официални източници
Нека обсъдим обхвата на теста.
Кажете ни какво искате да защитите. Опитен специалист ще ви помогне да определите обхвата и следващите стъпки. Обикновено отговаряме в рамките на един работен ден.
Поверителност от първия разговор
Можем да подпишем вашето NDA, преди да споделите чувствителни детайли. За запитването ви се прилага политиката ни за поверителност.
Как защитаваме информацията ви · Политика за поверителност