Управление на разширенията за браузър за NIS2, DORA и GDPR
Maria, CISO на бързо растяща финтех компания, смяташе, че предварителната оценка по DORA върви добре. Екипът ѝ беше подготвил регистъра на ИКТ трети страни, договорите за критични SaaS платформи, записите от надлежната проверка на доставчиците, решенията за приемане на риска и пакета за докладване към ръководния орган.
Тогава одиторът зададе въпрос, за който никой не беше подготвен.
“Можете ли да ни покажете процеса си за управление на разширенията за браузър?”
Въпросът възникна по време на преглед на крайна точка с финансов анализатор. При споделяне на екрана одиторът забеляза разширение за продуктивност от трета страна в браузъра на анализатора. На пръв поглед изглеждаше безобидно, но бърза проверка показа, че разработчикът е претърпял компрометиране на веригата за доставки три месеца по-рано. Компрометираното разширение е било използвано за източване на сесийни токени за големи SaaS платформи.
Финтех компанията имаше строги политики срещу неоторизиран софтуер. Имаше EDR, MFA, CASB, SaaS журнали и ISMS, съгласувана с ISO/IEC 27001. Но никой не беше третирал браузъра като управлявана софтуерна платформа. Никой не беше инвентаризирал разширенията. Никой не беше одобрявал разрешенията им. Никой не беше проверил дали разработчиците на разширения са доставчици. Никой не беше съпоставил дейността на разширенията с доказателствата по DORA, NIS2 или GDPR.
Едно-единствено разширение за браузър беше превърнало привидно съответстваща крайна точка във възможна задна врата към финансови системи, клиентски данни и регулирани работни процеси.
Това е проблемът с управлението на разширенията за браузър през 2026 г. Браузърът вече не е просто прозорец към интернет. В него служителите се автентикират, одобряват плащания, достъпват записи в CRM, обработват лични данни, управляват облачна инфраструктура и взаимодействат с критични SaaS платформи. Разширенията вече не са козметични добавки. Те са код от трети страни, който работи в най-чувствителния слой на съвременната работа.
За CISO, мениджъри по съответствието, DPO и собственици на ИКТ риск неуправляваните разширения се намират на пресечната точка между сигурността на крайните точки, неуправляваните ИТ, риска от доставчици, управлението на промените, управлението на уязвимостите и отчетността при защитата на данните. ISO/IEC 27001:2022 дава на организациите структурата за управление на този риск. NIS2, DORA и GDPR създават регулаторния натиск това управление да бъде доказано.
Разширенията за браузър са софтуер, доставчици и обработващи данни
Повечето организации вече са се научили да управляват лаптопи, мобилни устройства, сървъри, SaaS приложения, облачна инфраструктура и привилегировани акаунти. Разширенията за браузър често остават извън тези програми.
Екипите по сигурността ги разглеждат като настройка на браузъра. Отделът по закупуване не ги вижда, защото не се подписва договор. Правният отдел не ги вижда, защото не се открива заявка за въвеждане на доставчик. Екипите по защита на данните не ги виждат, защото разширението се инсталира от потребител, а не се внедрява като официално приложение. Въпреки това разширението може да поиска разрешение да чете и променя данни във всички уебсайтове, да достъпва съдържанието на клипборда, да улавя метаданни на страниците, да управлява изтегляния, да инжектира скриптове или да комуникира с външен бекенд.
Това означава, че едно разширение за браузър може едновременно да бъде всичко изброено по-долу:
| Управленска перспектива | Защо е важно | Типичен режим на отказ |
|---|---|---|
| Софтуер | Променя поведението на крайната точка и може да изпълнява код в потребителски сесии | Потребителите инсталират разширения извън одобрените работни процеси за софтуер |
| Доставчик | Разработчикът контролира актуализациите, инфраструктурата и поддръжката | Не се извършва надлежна проверка на доставчика |
| Облачна услуга | Много разширения се свързват с хоствани API или SaaS платформи | Бекенд компонентите на разширенията не се преглеждат като облачни услуги |
| Риск от обработващ данни | Разширенията може да виждат клиентски, служителски или финансови данни | Екипите по защита на данните не оценяват достъпа до данни или правното основание |
| Експозиция на уязвимости | Разширенията могат да бъдат компрометирани, изоставени или злонамерени | Липсва преглед на корекциите, репутацията или известни компрометирания |
| Източник на инцидент | Дейността на разширение може да създаде неоторизиран достъп или извличане на данни | Липсват журнали, което затруднява разследването и уведомяването |
[ZB] Zenith Blueprint: 30-стъпкова пътна карта за одитора улавя същността на проблема в указанията си по ISO/IEC 27002:2022 за контрола 8.19. В него се предупреждава, че “дори добросъвестни служители може да инсталират инструменти, за да „свършат работата по-бързо“ — разширение за браузър, библиотека с код, приложение за прехвърляне на файлове — без да осъзнават, че току-що са въвели задна врата, некоригирана зависимост или вектор за извличане на данни.”
Това изречение следва да се третира като изявление за риск на ниво ръководен орган. Служителите, които инсталират рискови разширения, обикновено не се опитват да заобиколят сигурността. Те се опитват да подобрят продуктивността си. Управленският отказ възниква, когато организацията не осигурява безопасен процес за заявяване, одобрение, внедряване и мониторинг.
Защо NIS2, DORA и GDPR правят сляпото петно спешно
Рискът от разширения за браузър съществува от години, но регулаторният контекст се промени. През 2026 г. от организациите се очаква да доказват не само че контролите съществуват, а че са основани на риска, интегрирани, наблюдавани и подкрепени с доказателства.
NIS2 повишава очакванията за киберхигиена и сигурност на веригата за доставки. DORA изисква финансовите субекти да управляват ИКТ риска във вътрешните зависимости и зависимостите от трети страни. GDPR изисква администраторите и обработващите да доказват сигурност на обработването, отчетност и защита на данните на етапа на проектиране. Неуправляваните разширения могат да подкопаят и трите режима.
| Регулация | Значение на разширенията за браузър | Доказателства, очаквани от регулатори и одитори |
|---|---|---|
| NIS2 Article 21 | Разширенията влияят върху киберхигиената, управлението на уязвимостите, контрола на достъпа, сигурността на софтуера и риска по веригата за доставки | Инвентар на разширенията, одобрен списък, записи от оценка на риска, журнали за блокирани инсталации, доказателства за обработване на инциденти |
| NIS2 Article 23 | Компрометирано разширение може да създаде значим инцидент, изискващ ранно предупреждение и уведомяване | Журнали за откриване, записи от триаж, оценка на въздействието, доказателства за решението за уведомяване |
| DORA Article 5 | Ръководните органи остават отговорни за управлението на ИКТ риска | Политики, решения относно апетита към риск, докладване, одобрения на изключения |
| DORA Article 6 | Разширенията могат да влияят върху рамката за управление на ИКТ риска | Идентифициране на активи, защитни контроли, мониторинг, тестване на устойчивостта, записи за отстраняване |
| DORA Article 28 | Разработчиците на разширения и свързаните услуги може да бъдат ИКТ зависимости от трети страни | Надлежна проверка, рискова класификация, записи в регистри, договорна оценка, когато е приложимо |
| GDPR Article 5(2) | Организациите трябва да доказват отчетност при обработването на лични данни | Документирани оценки, решения за одобрение, собственост, периодичност на прегледите |
| GDPR Article 25 | Защитата на данните на етапа на проектиране и по подразбиране се прилага към избора на инструменти | Минимизиране на разрешенията, преглед за защита на данните, конфигурация със забрана по подразбиране |
| GDPR Article 32 | Сигурността на обработването изисква подходящи технически и организационни мерки | Контроли за крайните точки, ограничения на достъпа, журнализиране, мониторинг, управление на уязвимостите |
| GDPR Article 33 | Готовността за уведомяване при нарушение зависи от своевременно откриване и доказателства | Журнали за инциденти, анализ на въздействието върху личните данни, доказателства за сроковете за уведомяване |
Изводът е прост. Разширението за браузър не е твърде малко, за да има значение. Ако може да достигне регулирани данни, автентикирани сесии, финансови работни процеси или критични SaaS услуги, то трябва да бъде управлявано.
Използвайте ISO/IEC 27001:2022 като оперативен модел
ISO/IEC 27001:2022 е ефективен за управление на разширенията за браузър, защото не изисква отделен силоз за съответствие. Той позволява на организациите да разширят съществуващите процеси на ISMS към слоя на браузъра.
Практичният модел на контрол се изгражда около осем контроли от Annex A на ISO/IEC 27001:2022:
| Контрол по ISO/IEC 27001:2022 | Наименование на контрола | Приложение към разширенията за браузър |
|---|---|---|
| 5.10 | Допустима употреба на информация и други свързани активи | Определяне какво потребителите могат да инсталират, използват, заявяват и съхраняват в браузъри |
| 5.19 | Информационна сигурност във взаимоотношенията с доставчици | Третиране на разработчиците на разширения и свързаните услуги като рискове от доставчици, когато е приложимо |
| 5.23 | Информационна сигурност при използване на облачни услуги | Преглед на разширенията, които се свързват с външни SaaS API или облачни бекенд компоненти |
| 8.1 | Устройства на крайни потребители | Управление на конфигурацията на браузъра като част от защитата на крайните точки |
| 8.8 | Управление на техническите уязвимости | Проследяване на уязвими, изоставени, компрометирани или високорискови разширения |
| 8.15 | Журнализиране | Улавяне на инсталации, премахвания, блокирани опити, промени в политиките и административни действия |
| 8.16 | Дейности по мониторинг | Генериране на предупреждения за аномална дейност на разширения и нарушения на политики |
| 8.19 | Инсталиране на софтуер върху работни системи | Изискване за одобрение преди инсталиране на разширения върху работни системи |
[ZC] Zenith Controls: Ръководство за междурегулаторно съответствие е особено полезно, защото обяснява как се одитират контролите по ISO/IEC 27001 и как те подпомагат доказателства между различни рамки. За контрола 8.19 Zenith Controls: Ръководство за междурегулаторно съответствие обяснява, че одиторите ще “проследят работния поток: от заявката, през теста и одобрението, до внедряването.” Именно така трябва да бъде проектирано управлението на разширенията.
Ако одитор открие разширение, което не е в одобрения списък, не е документирано в записите за промени и не е оценено за риск, проблемът вече не е просто настройка на браузъра. Той се превръща в доказателство за слаб контрол върху инсталирането на софтуер, слабо управление на крайните точки и възможен отказ в управлението на риска от доставчици.
Стъпка 1: открийте средата от разширения
Първият отказ на контрола във финтех компанията на Maria беше липсата на видимост. Екипът ѝ не знаеше кои разширения са инсталирани, кой ги е инсталирал, какви разрешения са поискали или дали се свързват с външни услуги.
Откриването трябва да обхваща всички управлявани браузъри, профили, потребители, устройства и операционни системи. То трябва да идентифицира име на разширението, уникален идентификатор, версия, издател, източник на инсталация, набор от разрешения, дата на инсталиране, статус на актуализация, брой потребители, бизнес собственик и дали разширението е принудително инсталирано, инсталирано от потребител, инсталирано странично или блокирано.
Контролът 8.1, Устройства на крайни потребители, е основата. Указанията на Zenith Blueprint: 30-стъпкова пътна карта за одитора за контрола 8.1 посочват, че крайните потребителски устройства “трябва да бъдат укрепени, наблюдавани и контролирани.” Това изискване естествено включва браузъра, защото браузърът вече е основният интерфейс на потребителската крайна точка за SaaS и работа в облака.
Контролът 5.23 също се прилага, когато разширенията се свързват с облачни услуги. Zenith Blueprint: 30-стъпкова пътна карта за одитора рамкира този контрол като отговор на неуправляваните ИТ, при които потребителите приемат несанкционирани услуги без управление. Разширение за браузър, което изпраща съдържание към неизвестен хостван бекенд, представлява събитие на приемане на облачна услуга, дори ако никой в отдела по закупуване не го е одобрил.
Зрелият резултат от откриването трябва да класифицира всяко разширение в едно от пет състояния:
| Състояние на разширението | Значение | Необходимо действие |
|---|---|---|
| Одобрено | Прегледано, обосновано и разрешено за определени потребители | Наблюдава се и се преглежда периодично |
| Условно | Разрешено с ограничения, например конкретни групи, сайтове или разрешения | Условията се прилагат и прегледът се извършва по-често |
| Очаква преглед | Открито или заявено, но все още неоценено | Блокира се или се поставя под карантина до одобрение |
| Блокирано | Известно рисково, ненужно, несъответстващо или забранено | Предотвратява се инсталирането и се премахват съществуващите инстанции |
| Изключение | Временно разрешено поради служебна необходимост и приет риск | Записват се собственик, дата на изтичане, компенсиращи контроли и одобряващ |
Откриването не трябва да бъде еднократен проект. Разширенията се актуализират често, издателите сменят собственост, разрешенията се разширяват, а магазините премахват злонамерени пакети, след като потребителите вече са ги инсталирали. Инвентарът трябва да стане непрекъснат или поне достатъчно периодичен, за да поддържа управление на уязвимостите и одитни доказателства.
Стъпка 2: направете допустимата употреба изрична
След като разширенията станат видими, очакванията към потребителите трябва да бъдат ясни. Много организации вече имат формулировки в политиките, които могат да поддържат управлението на разширенията, но те трябва изрично да се приложат към браузъра.
[P-EPM] Политика за защита на крайните точки от зловреден софтуер - SME посочва, че потребителите “не трябва да инсталират неоторизиран софтуер или плъгини, които могат да въведат риск.” Това едно изречение дава на екипите по сигурността стабилна политическа основа да третират разширенията за браузър като контролиран софтуер.
[P03-AUP] P03 Политика за допустима употреба, наричана също корпоративната Политика за допустима употреба, забранява “Неодобрени инструменти: инсталиране или използване на неоторизиран софтуер, хардуер, облачни услуги или устройства”. Това е основата, насочена към потребителя. Тя превръща управлението на разширенията за браузър от техническо предпочитание в приложимо поведенческо изискване и изискване за съответствие.
Силната политика за разширения за браузър трябва да отговаря на шест практически въпроса:
| Въпрос на политиката | Управленски отговор |
|---|---|
| Могат ли потребителите свободно да инсталират разширения? | Не, разширенията изискват одобрение, освен ако не са предварително одобрени по роля или група |
| Считат ли се разширенията за браузър за софтуер? | Да, те са софтуер, инсталиран върху операционни системи |
| Считат ли се бекенд компонентите на разширенията за облачни услуги? | Да, когато обработват, предават, съхраняват или обогатяват данни на организацията |
| Кой одобрява разширенията? | Сигурност, ИТ, защита на данните и бизнес собственици одобряват въз основа на риска |
| Какво се случва с неодобрените разширения? | Те се блокират, премахват или поставят под карантина до преглед |
| Как се обработват изключенията? | Изключенията изискват документирано приемане на риска, срок на валидност и компенсиращи контроли |
Целта не е да се забрани всяко полезно разширение. Целта е преминаване от неявно доверие към изрично одобрение. Някои разширения може да са безопасни, необходими и да повишават продуктивността. Други може да са ненужни, с прекомерни привилегии, изоставени или враждебни. Програмата за управление трябва да прави разлика между тях.
Стъпка 3: прилагайте забрана по подразбиране със списък с разрешени по изключение
Контролът 8.19, Инсталиране на софтуер върху работни системи, е контролът, който превръща политиката в практика. Разширенията за браузър не трябва да се третират различно от друг софтуер само защото потребителите ги инсталират чрез магазин на браузъра.
Zenith Blueprint: 30-стъпкова пътна карта за одитора е директен по този въпрос: “никакъв софтуер не се инсталира, освен ако не е обоснован, оторизиран и защитен.” За разширенията за браузър това означава използване на корпоративно управление на браузъри, управление на крайни точки или инструменти за конфигуриране на устройства за прилагане на правилата за инсталиране.
Най-защитимият модел е забрана по подразбиране със списък с разрешени по изключение:
- Блокирайте всички разширения по подразбиране за управлявани браузъри.
- Принудително инсталирайте само съществени, одобрени корпоративни разширения.
- Поддържайте списък с разрешени разширения по потребителска група, отдел или роля.
- Блокирайте странично инсталирани разширения и недоверени източници на инсталация.
- Предотвратете заобикалянето на политиките чрез смяна на профили или неуправлявани браузъри.
- Премахнете вече инсталираните разширения, които не са одобрени.
- Преглеждайте разрешенията на разширенията и риска на издателя преди одобрение.
- Журнализирайте разрешени, блокирани, премахнати и променени разширения.
Някои организации започват с по-мек модел поради оперативна сложност. Те може първо да инвентаризират, да блокират известни злонамерени разширения и след това поетапно да въведат списъци с разрешени за високорискови групи като финанси, инженеринг, привилегировани администратори, правен отдел, човешки ресурси и обслужване на клиенти. Това е приемливо, ако има документирана пътна карта. Постоянното толериране на неизвестен риск от разширения не е защитимо.
Стъпка 4: оценявайте риска от разширенията като при доставчици и софтуер
Прегледът на риска от разширение за браузър трябва да бъде достатъчно лек за приемане от бизнеса, но достатъчно силен, за да издържи одит. Прегледът трябва да комбинира софтуерен риск, риск от доставчици, облачен риск, защита на данните и управление на уязвимостите.
[P-TP] Политика за сигурност на трети страни и доставчици изисква “всички нови доставчици да преминат документирана оценка на сигурността преди сключване на договор.” Не всеки разработчик на разширение ще изисква пълен корпоративен процес за въвеждане на доставчици, но принципът за риск от доставчици остава приложим. Ако разработчик може да изпраща актуализации на код в браузърите на служителите или да обработва данни на организацията чрез бекенд услуга, организацията има зависимост от трета страна.
[P-ASR] Политика за изискванията за сигурност на приложенията - SME засилва същото изискване от софтуерна гледна точка: “всеки инструмент, плъгин или външна библиотека с код от трета страна, използвани в приложение, трябва да бъдат записани и преглеждани ежегодно за въздействие върху сигурността и статус на корекциите.”
Използвайте следния модел на риска за стандартизиране на решенията:
| Рисков фактор | Нисък риск | Среден риск | Висок риск |
|---|---|---|---|
| Разрешения | Няма достъп до данни на страници | Достъп до активен раздел или ограничени сайтове | Достъп за четене и запис до всички сайтове |
| Издател | Проверен издател със силна история | Известна компания с политика за защита на данните | Неизвестно физическо лице, неясна собственост, липса на политика за защита на данните |
| Достъп до данни | Работи локално без чувствителни данни | Вижда ограничени служебни данни | Достъпва лични данни, финансови данни, тайни или съдържание на сесии |
| Свързаност | Няма външен бекенд | Свързва се с известна услуга | Свързва се с неизвестен или непрозрачен бекенд на трета страна |
| Модел на актуализация | Официален магазин, редовни актуализации | Редки актуализации, ограничен журнал на промените | Странично инсталирано, изоставено или с неясен източник на актуализации |
| Служебна необходимост | Необходимо за одобрен работен процес | Полезно, но заменимо | Само удобство с високи разрешения |
| История на уязвимости | Няма неблагоприятни констатации | Минали проблеми са отстранени | Известно компрометиране, злонамерено поведение или нерешена уязвимост |
| Позиция по защита на данните | Ясно уведомление за защита на данните и ограничено събиране | Широка политика, но приемливи контроли | Липса на ясна политика или прекомерно събиране |
Високорисково разширение не трябва да се одобрява, освен ако има критична служебна необходимост, документирани компенсиращи контроли и приемане на риска от висшето ръководство. Примери за компенсиращи контроли включват ограничаване на използването до укрепен профил на браузър, ограничаване до конкретни URL адреси, блокиране на въвеждане на данни в чувствителни приложения, докато разширението е активно, използване на DLP мониторинг или изискване на договор с доставчика и приложение за защита на данните.
Стъпка 5: интегрирайте прегледа за защита на данните и GDPR
Управлението на разширенията за браузър често се проваля, защото прегледът за защита на данните е откъснат от инструментите за крайни точки. Въпреки това много разширения могат да виждат лични данни, показвани в SaaS приложения, HR системи, билети за поддръжка, CRM записи, електронна поща, аналитични платформи и инструменти за сътрудничество.
Съгласно GDPR Article 5(2) организацията трябва да докаже отчетност. Съгласно Article 25 тя трябва да внедри защита на данните на етапа на проектиране и по подразбиране. Съгласно Article 32 тя трябва да прилага подходящи технически и организационни мерки за сигурност на обработването. Ако разширение извлича лични данни, събитието може да се превърне в нарушение на сигурността на личните данни по Article 4(12), което задейства оценка и евентуално задължения за уведомяване по Article 33.
Прегледът на разширенията с фокус върху защитата на данните трябва да задава следните въпроси:
| Област на преглед по GDPR | Въпрос при преглед на разширението | Доказателства за съхранение |
|---|---|---|
| Категории данни | Може ли разширението да достъпва лични данни, специални категории данни или финансови данни? | Оценка на достъпа до данни |
| Ограничаване на целите | Необходимо ли е разширението за определена бизнес цел? | Бизнес обосновка |
| Минимизиране на данните | Ограничени ли са заявените разрешения до необходимия минимум? | Преглед на разрешенията |
| Отношение с обработващ | Обработва ли доставчикът на разширението данни от името на организацията? | Оценка на доставчика и защитата на данните |
| Международни трансфери | Напускат ли данните юрисдикцията или одобрения регион за хостинг? | Оценка на трансфера |
| Съхранение | Съхранява ли доставчикът данни, журнали, промптове, екранни снимки или метаданни? | Преглед на уведомлението за защита на данните и съхранението |
| Сигурност | Адекватни ли са криптирането, контролите на достъпа и практиките за уязвимости? | Надлежна проверка на сигурността |
| Реагиране при нарушение | Може ли доставчикът да уведомява организацията за инциденти? | Договорни или документирани доказателства за реагиране |
Не всяко разширение изисква пълна DPIA. Въпреки това разширения с широк достъп до страници, AI обработване, заснемане на екрана, достъп до електронна поща, достъп до CRM, достъп до данни на човешки ресурси, данни от обслужване на клиенти или регулирани финансови данни трябва да задействат структурирана оценка за защита на данните.
Стъпка 6: журнализирайте и наблюдавайте за одит и реагиране при инциденти
Програма за управление на разширенията без журнали не може да бъде одитирана. Тя също отслабва реагирането при инциденти, защото организацията не може да установи кога е инсталирано разширение, кой го е използвал, коя версия е била налична, кога са се променили разрешенията или дали е възникнал опит за блокирана инсталация.
[P-LM] Политика за журнализиране и мониторинг - SME определя журналите за “софтуерни инсталации” като ключово управленско изискване. Инсталирането на разширение за браузър е събитие по инсталиране на софтуер и следва да се улавя по съответния начин.
Като минимум журналите трябва да включват:
| Събитие в журнал | Защо е важно |
|---|---|
| Инсталирано разширение | Потвърждава внедряването и поддържа доказателства за промяна |
| Блокирано разширение | Показва действието на превантивен контрол |
| Премахнато разширение | Потвърждава отстраняването |
| Актуализирано разширение | Поддържа прегледа на уязвимостите и промените |
| Променено разрешение | Открива повишаване на риска след одобрение |
| Променена политика | Показва административен контрол и отчетност |
| Опит за странично инсталиране | Показва поведение за заобикаляне или риск от зловреден софтуер |
| Променен източник на магазин | Открива недоверен път за инсталиране |
| Открито високорисково разширение | Задейства триаж и премахване |
| Предоставено потребителско изключение | Поддържа доказателства за приемане на риска |
Тези журнали трябва да се подават към процесите за мониторинг по контролите 8.15 и 8.16. В зависимост от риска те може също да се изпращат към SIEM, платформа за крайни точки или хранилище за доказателства за съответствие. Предупреждения трябва да се конфигурират за блокирани високорискови разширения, внезапни пикове в заявките за разширения, промени в разрешенията на одобрени разширения, опити за инсталиране от неофициални източници и опити за инсталиране от привилегировани потребители.
Мониторингът също е предимство по NIS2 и DORA. Докладването на инциденти по NIS2 Article 23 зависи от ранно откриване и оценка на въздействието. DORA изисква устойчиво обработване на ИКТ инциденти и доказателства за устойчивост. Оценката на нарушение по GDPR зависи от знанието какво се е случило, кога и кои данни може да са били засегнати.
Какво иска да види одиторът
Одиторът рядко се удовлетворява от твърдение като “блокираме рискови разширения.” Той иска доказателства за управление. Доказателствата трябва да свързват политика, оценка на риска, техническо прилагане, мониторинг и отчетност на ръководството.
| Одиторски въпрос | Силен отговор | Доказателствен артефакт |
|---|---|---|
| Разширенията за браузър в обхвата ли са? | Да, те се третират като софтуер върху крайни потребителски устройства | Обхват на ISMS, регистър на активите, стандарт за крайни точки |
| Забранено ли е на потребителите да инсталират неодобрени разширения? | Да, политиките за допустима употреба и крайни точки определят правилото | Политика за защита на крайните точки от зловреден софтуер - SME, P03 Политика за допустима употреба |
| Има ли одобрен списък с разширения? | Да, одобрените разширения са документирани по бизнес собственик и потребителска група | Експорт на списък с разрешени, регистър на одобренията |
| Оценяват ли се новите разширения за риск? | Да, заявките задействат проверки за софтуер, доставчик, уязвимости и защита на данните | Запис от оценка на риска |
| Третират ли се разработчиците на разширения като доставчици, когато е приложимо? | Да, високорисковите доставчици преминават надлежна проверка | Оценка на доставчика |
| Преглеждат ли се разширенията, свързани с облака? | Да, външните бекенд компоненти се оценяват по управлението на облачните услуги | Преглед на облачна услуга |
| Прилагат ли се инсталациите технически? | Да, забрана по подразбиране и списъци с разрешени по групи се прилагат в управлението на браузъри | Експорт на конфигурация |
| Журнализират ли се промените? | Да, инсталиране, блокиране, премахване, актуализация и административни промени се журнализират | Журнали от SIEM или административна конзола |
| Контролират ли се изключенията? | Да, изключенията изискват собственик, срок на валидност, одобряващ и компенсиращи контроли | Регистър на изключенията |
| Повтарят ли се прегледите? | Да, разширенията се преглеждат периодично и след съществени промени | График за преглед и доказателства |
Тук Zenith Controls: Ръководство за междурегулаторно съответствие става ценно. То помага на организациите да покажат как една контролна дейност поддържа множество очаквания за съответствие. Един работен поток за одобрение на разширение за браузър може да поддържа ISO/IEC 27001 контрола 8.19, киберхигиена по NIS2, управление на ИКТ риска по DORA и отчетност по GDPR, ако доказателствата се съхраняват и съпоставят ясно.
Съпоставка: ISO/IEC 27001:2022 към NIS2, DORA и GDPR
Практичната съпоставка помага на CISO да обяснят защо управлението на разширенията за браузър не е нишов технически контрол. То е контрол за съответствие с широка регулаторна стойност.
| Контрол по ISO/IEC 27001:2022 | Съответствие с NIS2 | Съответствие с DORA | Съответствие с GDPR | Доказателства за разширения за браузър |
|---|---|---|---|---|
| 5.10 Допустима употреба на информация и други свързани активи | Article 21 киберхигиена и потребителски практики | Article 5 управленски очаквания | Article 5(2) отчетност | Правила за допустима употреба, осведоменост на потребителите, потвърждения за запознаване с политиката |
| 5.19 Информационна сигурност във взаимоотношенията с доставчици | Article 21 сигурност на веригата за доставки | Article 28 управление на ИКТ риск от трети страни | Articles 28 and 32, когато се прилага обработване | Преглед на доставчик, оценка на доставчика, договорен анализ |
| 5.23 Информационна сигурност при използване на облачни услуги | Article 21 ИКТ и мрежова сигурност | Articles 6 and 28 ИКТ риск и зависимости от трети страни | Articles 25 and 32 защита на данните на етапа на проектиране и сигурност | Преглед на облачен бекенд, одобрение на SaaS интеграция |
| 8.1 Устройства на крайни потребители | Article 21 сигурност на крайните точки и контрол на достъпа | Article 6 рамка за управление на ИКТ риска | Article 32 сигурност на обработването | Конфигурация на браузъра, управлявани профили, инвентар на крайните точки |
| 8.8 Управление на техническите уязвимости | Article 21 управление на уязвимостите | Article 6 защита и превенция | Article 32 технически мерки | Проследяване на уязвими разширения, записи за отстраняване |
| 8.15 Журнализиране | Article 23 доказателства за инцидент | Обработване на ИКТ инциденти и доказателства за устойчивост | Articles 5(2), 32 and 33 отчетност и доказателства за нарушение | Журнали за инсталации, блокирани опити, промени в политики |
| 8.16 Дейности по мониторинг | Article 21 откриване и Article 23 докладване | ИКТ мониторинг и откриване на инциденти | Articles 32 and 33 откриване на нарушения | Предупреждения, събития в SIEM, доклади за аномалии |
| 8.19 Инсталиране на софтуер върху работни системи | Article 21 сигурна конфигурация и контрол на софтуера | Очаквания за контрол на ИКТ промените, включително COBIT BAI06 Managed IT Changes като одиторска перспектива | Articles 25 and 32 контролирана среда за обработване | Заявка, одобрение, тестване, внедряване, доказателства за списък с разрешени |
Съпоставката с DORA заслужава специално внимание. Някои одитори и оценители ще използват терминология в стил COBIT при преглед на управлението на ИКТ промените. COBIT BAI06 обичайно се разбира като Managed IT Changes. Ако разширенията за браузър са софтуер и тяхното инсталиране променя потребителската изчислителна среда, тогава инсталирането на разширения принадлежи към същата управлявана логика за промени. Zenith Controls: Ръководство за междурегулаторно съответствие подкрепя тази одиторска перспектива, като показва как доказателствата за контроли по ISO/IEC 27001 могат да се използват повторно за очакванията за съответствие.
90-дневен план за внедряване на управление на разширенията за браузър
Организациите не трябва да решават всичко в рамките на една седмица. Практична програма може да бъде изградена по фази, особено ако прекъсването на бизнеса трябва да се управлява внимателно.
| Срок | Цел | Действия | Резултати |
|---|---|---|---|
| Дни 1 до 15 | Установяване на обхват и собственост | Определяне на собственици от ИТ, сигурност, защита на данните, закупуване и бизнес звена; потвърждаване на управляваните браузъри и потребителски групи | Списък на управленските собственици, обхват на браузърите, първоначално изявление за риска |
| Дни 16 до 30 | Откриване на текущото състояние | Инвентаризиране на инсталирани разширения, разрешения, издатели, версии, потребители и източници на инсталация | Инвентар на разширенията, високорискови констатации, първоначално резюме за ръководството |
| Дни 31 до 45 | Дефиниране на политика и правила за решения | Актуализиране на процедурите за допустима употреба, крайни точки, облак и доставчици, така че да включват разширения | Актуализации на политики, критерии за одобрение, процес за изключения |
| Дни 46 до 60 | Изграждане на работен поток за оценка на риска | Създаване на формуляр за заявка, модел за точкова оценка, въпроси за защита на данните, триаж на доставчици и записи за одобрение | Работен поток за заявка на разширение, матрица на риска, шаблони за доказателства |
| Дни 61 до 75 | Прилагане на технически контроли | Конфигуриране на забрана по подразбиране или поетапно въвеждане на списъци с разрешени, блокиране на странично инсталиране, премахване на известни рискови разширения | Конфигурация за управление на браузъри, списък с разрешени, списък за блокиране |
| Дни 76 до 90 | Мониторинг и доказателства | Изпращане на журнали към инструменти за мониторинг, създаване на предупреждения, тестване на одитни доказателства, докладване към ръководството | Табло за журнализиране, правила за предупреждения, одиторски пакет, доклад за ръководството |
За високорискови организации, особено финансови субекти по DORA или съществени и важни субекти по NIS2, първата фаза на прилагане трябва да приоритизира потребители с достъп до критични системи, регулирани данни, привилегировани административни конзоли, финансови платформи, инструменти за обслужване на клиенти и развойни среди.
Посланието към ръководния орган
Управлението на разширенията за браузър не трябва да се представя на изпълнителните ръководители като проект за укрепване на браузъра. То трябва да се представя като контрол върху непроверен код от трети страни в регулирани работни процеси.
Съветът и ръководният орган трябва да разберат четири точки:
- Браузърът вече е основна бизнес платформа.
- Разширенията могат да достъпват чувствителни SaaS данни и автентикирани сесии.
- Неуправляваните разширения създават рискове, свързани с доставчици, защита на данните, инциденти и устойчивост.
- ISO/IEC 27001:2022 предоставя защитим контролен модел, който поддържа доказателства по NIS2, DORA и GDPR.
Тази рамка измества разговора от техническо предпочитание към оперативна устойчивост. Тя също подкрепя финансиране за корпоративно управление на браузъри, интеграция с крайни точки, мониторинг, преглед за защита на данните, триаж на доставчици и автоматизация на одитни доказателства.
От сляпо петно към стратегически контрол
Одиторският проблем на Maria не беше причинен от това, че един анализатор е инсталирал един инструмент за продуктивност. Причината беше неуправляван клас риск. Организацията беше изградила силна програма за съответствие около видими активи, видими доставчици, видими SaaS платформи и видими крайни точки, но слоят на разширенията за браузър беше останал невидим.
Този пропуск вече е твърде важен, за да бъде пренебрегван.
Решението не е сложно, но трябва да бъде целенасочено. Третирайте браузъра като част от крайната точка. Третирайте разширенията като софтуер. Третирайте разработчиците на разширения и бекенд компонентите като доставчици, когато е приложимо. Третирайте разрешенията като достъп до данни. Третирайте инсталирането като промяна. Третирайте журналите като доказателства за съответствие.
Защитима програма започва с четири действия:
- Открийте всяко разширение във всички управлявани браузъри и крайни точки.
- Дефинирайте правила за допустима употреба и забрана по подразбиране чрез Политика за защита на крайните точки от зловреден софтуер - SME, P03 Политика за допустима употреба и корпоративната Политика за допустима употреба.
- Оценявайте заявките за разширения чрез критерии за доставчици, облак, уязвимости и защита на данните от Политика за сигурност на трети страни и доставчици и Политика за изискванията за сигурност на приложенията - SME.
- Прилагайте и наблюдавайте дейността по инсталиране чрез управление на браузъри, журнализиране и практики за доказателства, съгласувани с Политика за журнализиране и мониторинг - SME.
За CISO, които се подготвят за одити по NIS2, DORA, GDPR или ISO/IEC 27001:2022, управлението на разширенията за браузър е подобрение на контролите с висока стойност, защото затваря реален път за атака и едновременно създава доказателства за многократна употреба в различни рамки.
За да ускорите работата, изтеглете Zenith Blueprint: 30-стъпкова пътна карта за одитора и съпоставете доказателствата си със Zenith Controls: Ръководство за междурегулаторно съответствие. Ако искате да превърнете хаоса с разширенията за браузър в програма за управление, готова за одит, насрочете оценка или демонстрация с Clarysec и започнете с практичен инвентар, карта на риска и 90-дневен план за контрол.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
