Какво е ISMS? Свържете работата по сигурността с бизнес решенията

Работата по сигурността може да изглежда натоварена, без да е координирана. Инженерите прилагат корекции по системите, отделът „Човешки ресурси“ обработва напусканията, снабдяването преглежда доставчиците, а ръководството одобрява изключения. Системата за управление на информационната сигурност (ISMS) свързва тези дейности с общи цели и с изричен процес на вземане на решения.

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

Какво всъщност управлява ISMS

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

Нейната цел е да защитава три свойства на информацията:

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

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

ISO/IEC 27001 съдържа признати изисквания към ISMS с определен обхват. Точки 4–10 обхващат контекста на организацията, лидерството, планирането, подпомагането, функционирането, оценяването на резултатите и подобряването. Организацията може да разработи и да експлоатира ISMS, преди да се стреми към сертификация.

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

Защо ръководството се нуждае от тези връзки

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

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

Връзките трябва да отговарят на практически въпроси:

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

Определете обхват, който отразява бизнеса

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

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

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

Напишете декларация за обхвата и я подложете на проверка с три въпроса:

• Би ли могъл клиентът да разбере какво е обхванато и какво не?
• Включили ли сме зависимостите, необходими за защита на обхванатата услуга?
• Могат ли посочени собственици да поддържат системата в тази граница?

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

Възлагайте решения, а не само задачи

Висшето ръководство трябва да осигурява насоки и подкрепа за ISMS по ISO 27001. Делегирането на координацията на ръководител по сигурността не прехвърля отговорността на ръководството за приоритетите, ресурсите и приемливия риск.

Разделете отговорностите, които често се обединяват в длъжността на един човек:

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

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

Превърнете оценката на риска в процес на приоритизиране

Оценката на риска трябва да описва правдоподобни сценарии, а не само да назовава активи или да изброява слабости. „База данни с клиенти“ е актив. „Компрометиран администраторски акаунт позволява масово извличане на записи за клиенти“ е сценарий на риска с причина и последица.

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

За всеки съществен сценарий документирайте:

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

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

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

Регистърът на оперативните рискове трябва да остане запис на решенията: какво се е променило, защо е избрано дадено третиране и кога оценката трябва да бъде преразгледана.

Изберете контроли и обяснете тяхната приложимост

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

Приложение A към ISO/IEC 27001:2022 съдържа 93 референтни контрола: 37 организационни, 8 свързани с хората, 14 физически и 34 технологични. Изборът се основава на риска; организацията не внедрява автоматично всеки контрол. ISO/IEC 27002 предоставя насоки за внедряване, а не отделно изискване за сертификация на ISMS.

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

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

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

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

Вградете доказателствата в нормалните операции

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

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

Практичният набор от доказателства за ISMS включва:

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

Практически пример: платформа за поддръжка на клиенти

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

Обхватът на ISMS обхваща операциите по поддръжка на клиенти и техните зависимости: идентичностите на служителите, доставчика на SaaS, достъпа от крайни устройства, експортите, съхранението и уговорките за възстановяване. Мениджърът на поддръжката е собственик на услугата; ИТ експлоатира контролите на достъпа; снабдяването координира прегледа на доставчика; ръководството одобрява рисковете извън делегираните правомощия.

Първоначалната оценка идентифицира три сценария:

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

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

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

Ръководството получава нерешените въпроси: дали да финансира по-силен резервен вариант, да намали информацията, събирана в прикачените файлове, или да приеме определена оставаща експозиция. Това е ISMS, която свързва оперативните констатации с бизнес изборите.

Поддържайте ритъм, който може да открива промени

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

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

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

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

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

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

Разграничавайте ISMS, сертификацията и правните задължения

ISMS е системата, която организацията експлоатира. ISO 27001 е стандарт, спрямо който тази система може да бъде оценена. Сертификацията се издава от независим сертифициращ орган, а не от ISO или Secani, и се отнася за посочения обхват.

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

Правната приложимост изисква отделен анализ. Член 32 от ОРЗД изисква подходящи технически и организационни мерки за сигурност въз основа на релевантните рискове. NIS2 урежда надзора от ръководството, мерките за управление на риска и докладването на инциденти за субектите в обхвата чрез националното транспониране.

ISMS може да организира доказателствата и отговорностите, подкрепящи такива задължения, но сертификацията не установява съответствие с ОРЗД или NIS2. Не е точно и да се твърди, че ISMS никога не може да бъде законово изискуема: приложимите национални или секторни правила трябва да бъдат проверени.

Избягвайте три предвидими провала при внедряването

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

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

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

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

Направете първото решение на ръководството конкретно

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

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

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