Пример за ISO 27001 внедряване в бизнес

Пример за ISO 27001 внедряване в средна компания

Да разгледаме условна българска търговска компания с 85 служители, централен офис и складова база. Тя работи с ERP система, облачна поща, CRM, онлайн магазин и външни куриери. Част от служителите работят дистанционно, а IT поддръжката се осигурява от външен партньор.

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

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

Първата стъпка е обхватът, не документацията

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

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

Ръководството определя собственик на системата за управление на информационната сигурност. Това може да е вътрешен IT мениджър, оперативен директор или друг служител с достатъчна организационна тежест. Външният IT партньор подпомага с техническата част, но не може да замести управленското решение за приемлив риск, бюджет и приоритети.

Оценката на риска показва къде са слабите места

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

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

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

Тук ISO 27001 не изисква една-единствена формула. Важното е методът да е ясен, повторяем и одобрен. Компанията трябва да може да покаже защо даден риск е оценен като висок и какво решение е взето за него: намаляване, прехвърляне, избягване или приемане.

Контролите се избират според риска

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

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

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

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

Политиките трябва да водят до действие

ISO 27001 изисква документирана система, но добрата документация не е написана само за одитора. Тя казва на хората какво да правят в реална ситуация. Политика за приемливо използване на IT ресурси, процедура за управление на достъпа, правила за работа от разстояние и план за реакция при инцидент трябва да са кратки, разбираеми и приложими.

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

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

Хората и доставчиците са част от системата

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

Компанията преглежда и отношенията си с външни доставчици. Облачният доставчик, фирмата за заплати, телекомуникационният оператор и партньорът за IT поддръжка могат да обработват или да имат достъп до информация. Договорите и работните процедури трябва да определят изискванията за сигурност, уведомяването при инцидент, отговорностите и условията за прекратяване на достъп.

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

Как изглеждат вътрешният одит и сертификацията

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

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

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

Какъв е измеримият бизнес резултат

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

За управителя най-ценният резултат е предвидимостта. Вече има конкретни отговори на въпросите кои системи са критични, какво се случва при инцидент, кога се тества възстановяването и кой докладва статуса. За вътрешния IT екип или външния технологичен партньор това превръща разпокъсаните задачи в управляван процес с приоритети.

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