Накратко: ISO 27001 и TISAX засягат уеб сървърите най-вече чрез три изисквания: уязвимостите трябва да се откриват и третират, доставчиците като хостинг и агенции трябва да се управляват, а инцидентите със сигурността изискват уреден ред. Ситуация като PHP2Shell е практически тест за всеки ISMS. Който документира проследимо оценката, пача и рестарта, има добра основа за следващия одит. Сертификатът или етикетът не заменя пача.
Какво са ISO 27001 и TISAX, в два абзаца
ISO/IEC 27001 описва изискванията към система за управление на информационната сигурност, накратко ISMS. Има се предвид подреден цикъл: оценка на рисковете, определяне на мерки, изпълнение, проверка и подобрение. Актуалното издание от 2022 г. съдържа в Приложение А каталог от 93 мерки в четири теми. Кои от тях важат, решава фирмата на основата на своята оценка на риска и го записва в декларацията за приложимост.
TISAX е разпространеният в автомобилната индустрия механизъм за проверка и обмен. Управлява се от ENX Association, основа е каталогът с изисквания ISA, който ENX поддържа, а VDA публикува. Независими доставчици на услуги по проверка провеждат оценка, чийто обхват зависи от нуждата от защита и варира от проверка на документи до посещения на място. Според ENX резултатите се присъждат като етикети, важат три години и се споделят през портала на ENX само с избрани партньори.
ISO 27001 при уеб сървъра: кои изисквания действат?
Уеб сървърът рядко е самостоятелна глава в ISMS. Той се появява на няколко места и точно там възникват пропуските. Следният преглед подрежда най-важните теми общо. Той не заменя поглед в собствената Ви декларация за приложимост.
| Тема в ISMS | Какво означава при уеб сървъра | Доказателство, което помага при одит |
|---|---|---|
| Инвентар на активите | Всеки уебсайт, всеки сървър, всяка версия на PHP е отчетена | Актуален списък с оператор, версия, отговорно лице |
| Работа с технически уязвимости | Съобщения като PHP2Shell се оценяват и третират | Тикет с оценка, решение, дата на пача |
| Отношения с доставчици | Хостинг доставчикът и агенцията имат ясни задължения за сигурност | Договор, разпределение на задачите, писмено потвърждение на състоянието на пача |
| Протоколиране и наблюдение | Логовете на уеб сървъра се съхраняват и анализират | Правило за съхранение, пример за анализ |
| Управление на инциденти | Подозрението се съобщава, оценява и приключва | Протокол за инцидента, Lessons Learned |
| Управление на конфигурацията | Настройките на PHP и уеб сървъра са определени | Целева конфигурация и проверка за отклонения |
При TISAX важат съпоставими теми, защото каталогът ISA е съгласуван с други значими стандарти. Освен това някои цели на проверка, например защитата на прототипи, изискват особена грижа към системи, чрез които партньори обменят данни. Това могат да бъдат и портали на основата на PHP.
PHP2Shell като практически тест за ISMS
На 21.10.2026 г. PHP проектът публикува версиите 8.5.12, 8.4.27, 8.3.36 и 8.2.35. За PHP 8.1 и по-стари вече няма официални ъпдейти. Работещият ISMS трябва в това положение да задейства верига, която по-късно може да се докаже.
- Получаване: Кой кога е получил съобщението и къде е отчетено?
- Оценка: Кои системи са засегнати? Това предполага актуален инвентар, вижте Да знаем какво работи.
- Решение: Пач, временна мярка или временно изключване, с обосновка и името на решаващото лице.
- Изпълнение: Състояние на пакета, рестарт на всички PHP процеси, контрол. При backport-ове на дистрибуцията важи changelog-ът на пакета, а не показаният номер на версията; как се доказва това, показва Как да проверите правилно версията на PHP и състоянието на пача.
- Доставчици: Писмено потвърждение от хостинг доставчика, че е пачнато и рестартирано.
- Последващ контрол: Проверка за признаци на компрометиране от 17.10.2026 г. насам, защото пачът не отменя по-ранни прониквания.
Как от тази еднократна верига да направите траен процес, описват Управление на уязвимостите в средния бизнес и Управление на пачовете като процес.
Чести слабости в документацията
На практика доказването рядко се проваля заради техниката, а заради пропуски във веригата. Типичен е уебсайт, който отдел поддържа с агенция и който липсва в инвентара. Също толкова чести са договори с хостинг доставчици без изказване за това колко бързо се инсталират ъпдейтите за сигурност и дали клиентите се информират.
Друга класика: тикетът за пача е затворен, но никой не е рестартирал PHP процесите. Формално точката е изпълнена, технически старият код продължава да работи. Доброто доказателство затова съдържа не само „ъпдейтът е инсталиран“, но и рестарта и контрол след него.
Трудно става и при системи, които не могат да се пачнат веднага, например приложение на PHP 8.1. Тук ISMS не изисква чудеса, но изисква съзнателно решение: кои временни мерки важат, кой е приел остатъчния риск и до кога е планиран преходът? Писмено приемане на риска със срок на валидност е на одит значително по-добро от мълчаливо продължаващо да работи старо решение. Също толкова важни са логовете. След PHP2Shell специализираната преса и авторите съветваха да се съхраняват сървърните логове от 20.10.2026 г. нататък. Дали Вашето правило за съхранение позволява това и дали логовете са при хостинг доставчика или при Вас, трябва да се изясни преди следващия инцидент, а не по време на него.
Ако Вашата фирма допълнително попада под NIS2, тези изисквания се засилват. Основните положения са в NIS2 и сигурност на уеб сървърите. Това е обща информация, не е правен съвет.
Сертификатът или етикетът описва състоянието на една система за управление към момента на проверката. Той не защитава отделен сървър от нова уязвимост. Решаващо е редът в критичен момент действително да работи.
Как помага PHP SOS конкретно?
- Описваме Вашите уеб сървъри и PHP инсталации така, че да пасват в инвентара на Вашия ISMS.
- Пачваме и документираме с нашата услуга за PHP пачове: състояние на пакета, рестарт, контрол, с дата и доказателства.
- Формулираме въпросите към хостинг доставчици и агенции и оценяваме отговорите им за Вашето управление на доставчиците.
- Предоставяме на отговорните за Вашия ISMS техническите факти. Оценката в системата за управление и одитът остават у Вас и у Вашата проверяваща институция.
Извод
ISO 27001 и TISAX не изискват определен уеб сървър, но изискват проследимо отношение към него. PHP2Shell показва дали инвентарът, третирането на уязвимостите и управлението на доставчиците работят заедно. Който доказва прецизно веригата получаване, оценка, пач, рестарт и последващ контрол, има под контрол не само одита, а преди всичко сървъра.
Често задавани въпроси
Влиза ли фирменият уебсайт в обхвата на ISO 27001?
Това зависи от начина, по който Вашата фирма е определила обхвата. Ако уебсайтът обработва данни на клиенти, е свързан с вътрешни системи или се поддържа от доставчик, има много основания да се включи или поне да се отчете чрез управлението на доставчиците.
Сертификат ли е TISAX?
ENX Association говори за оценка (assessment) от независими доставчици на услуги по проверка, чиито резултати се присъждат като етикети TISAX. Според ENX етикетите важат три години и се споделят целенасочено с партньори през портала на ENX, те не са публични.
Трябва ли след PHP2Shell да информирам одитора си?
Общо задължение за това няма. Вашият ISMS обаче трябва да документира как сте оценили и третирали уязвимостта. Тези документи обикновено се разглеждат при следващия одит.
Коя версия на ISO 27001 е актуална?
Меродавно е изданието ISO/IEC 27001:2022. Приложение А към него подрежда мерките в четири теми: организационни, свързани с хората, физически и технологични.