ISO 27001, Приложение A: как да приложите 93-те контрола на практика

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

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

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

Разберете какво прави Приложение A – и какво не прави

ISO/IEC 27001:2022 съдържа 93 контрола в Приложение A, разпределени в четири теми. Точки 4–10 съдържат изискванията към системата за управление: контекст на организацията, лидерство, планиране, подпомагане, функциониране, оценяване на резултатите и подобряване. Приложение A подпомага избора на контроли; то не замества тези изисквания или вашата оценка на риска.

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

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

ISO/IEC 27002:2022 предоставя насоки за внедряване на контролите. Неговите атрибути помагат контролите да се организират по вид на контрола, свойство на информационната сигурност, концепция за киберсигурност, оперативна способност и област на сигурност. Това са полезни помощни средства за филтриране, а не допълнителни контролни списъци за сертификация. За авторитетния текст се обръщайте към лицензираните стандарти.

Използвайте четирите теми, за да намерите правилните собственици

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

Организационни контроли: свържете управлението с оперативните решения

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

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

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

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

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

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

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

Собствеността често обхваща няколко екипа. Отделът „Човешки ресурси“ може да инициира напускането, администраторите на идентичности деактивират централния акаунт, собствениците на приложения премахват локално управлявания достъп, а мениджърът потвърждава приключването. Възлагането на целия процес на сигурността скрива тези зависимости.

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

Физически контроли: документирайте вашата граница и границата на доставчика

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

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

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

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

Технологични контроли: определете обхвата, преди да изберете инструменти

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

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

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

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

Какво се промени през 2022 г. и къде да търсите пропуски

Изданието от 2013 г. имаше 114 контрола в 14 области. Изданието от 2022 г. ги реорганизира в 93 контрола в четири теми, включително 11 нови контрола. По-малкият брой не означава по-малко работа по сигурността: обединяването може да постави няколко оперативни отговорности под една препратка.

Когато актуализирате по-стар регистър, запазете съществуващите внедрявания и доказателства, вместо само да заменяте идентификаторите. Проверете дали новото групиране променя обхвата, собствеността или тестовете, необходими за подкрепа на вашия статус.

Крайният срок за преход от акредитирана сертификация по ISO/IEC 27001:2013 беше 31 октомври 2025 г. Тези сертификати вече не са валидни; самото актуализиране на регистъра на контролите не установява сертификация по изданието от 2022 г.

По-долу са практически отправни точки за 11-те нови контрола, а не възпроизвеждане на техния авторитетен текст.

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

Документирайте приложимостта и внедряването отделно

Вашата Декларация за приложимост (Statement of Applicability, SoA) трябва да посочва необходимите контроли, да обяснява защо са включени, да документира дали са внедрени и да обосновава изключванията на контроли от Приложение A. Тези изисквания са част от разпоредбите за третиране на риска в ISO/IEC 27001.

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

За всеки приложим контрол документирайте:

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

Поддържайте приложимостта независима от статуса на изпълнение. „Приложим, частично внедрен“ е честен и полезен запис. „Неприложим, защото не сме купили инструмент“ не е обосновка за приложимост.

Изключването трябва да описва фактите за обхвата, които правят контрола ненужен, и да остава съвместимо с оценката на риска. „Не разработваме софтуер“ изисква внимателна проверка, ако изпълнител разработва вашия клиентски портал. Възлагането на външни изпълнители променя пътя на внедряване и доказателства; то не премахва автоматично риска.

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

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

Тествайте твърдението зад статуса

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

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

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

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

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

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

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

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

Практически пример: направете процеса при напускане проверим

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

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

Компанията документира контрола като приложим. Отделът „Човешки ресурси“ отговаря за задействането на напускането; ИТ отговаря за действията по идентичностите и устройствата; всеки собственик на приложение отговаря за премахването на локалните акаунти. Мениджърът на служителя потвърждава необходимия момент на напускане. Собственикът по сигурността преглежда процеса и нерешените изключения.

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

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

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

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

Този пример показва защо доказателствата трябва да следват зависимостите. Четири системи, отчитащи „завършено“, не доказват приключване, ако пета система никога не е била включена.

Поддържайте контролите действащи между прегледите

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

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

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

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

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

Започнете с една услуга и пълна верига от доказателства

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

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

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

Практически въпроси

Може ли един запис да подкрепя няколко контрола?

Да. Заявката за напускане може да подкрепя няколко свързани контрола. Обяснете кое твърдение подкрепя тя за всеки от тях; споделянето на доказателства не прави контролите идентични.

Трябва ли всеки контрол да има собствена политика?

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

Откъде трябва да идва авторитетният списък с контроли?

Използвайте лицензирания стандарт ISO/IEC 27001 за текста на Приложение A и ISO/IEC 27002 за насоките за внедряване. Оперативните обобщения са полезни помощни средства за ориентиране, но не заместват стандартите.