Pull to refresh

Мифы об ISO 27000

Довольно часто в последнее время встречаю в Интернете и, в частности на Хабре, статьи и комментарии с упоминанием серии стандартов ISO 27000. При этом частенько авторы слабо себе представляют, о чем идет речь, и вводят читателей в заблуждение. А заблуждения, как известно, имеют природу быстро распространяться и перерастать в мифы. Ниже я постараюсь развеять несколько наиболее распространённых мифов.

Миф №1 – Сертификация по ISO 27000

Это один из наиболее часто встречающихся мифов о существовании сертификации по ISO 27000 или по ISO 27k. На самом деле, требования к сертифицируемой системе управления информационной безопасностью (далее СУИБ), содержаться в одном единственном документе — ISO/IEC 27001:2005. Таким образом, существует сертификация СУИБ на соответствие требованиям ISO/IEC 27001:2005, но никак не требованиям (собственно которые и не определены) всей серии стандартов ISO 27000.

Миф №2 – Сертификат выдается на всю организацию

Область действия сертификата указана на самом сертификате и может быть (чаще всего так и есть) ограничена географической локацией, структурным подразделением, некой программно-аппаратной системой или комплексом и т.д. и т.п. Важно понимать, что выбор области сертификации целиком и полностью прерогатива самой компании. Аудиторы, безусловно, могут и должны указать на неудачно выбранную область, но окончательное решение остается за менеджментом компании. С точки зрения ISO 27001, ИБ – это прежде всего управление рисками.

Миф №3 – Внедрение ИБ завершено — сертифицируемся

Стандарт ISO 27001 описывает необходимость постоянного совершенствования системы, т.е. рассматривает внедрение СУИБ, как процесс. Мало того, в самом стандарте четко пошагово прописана структура PDCA цикла (цикл Деминга).
Off topic:
Насчет того, является ли внедрение СУИБ процессом или проектом, вопрос несколько спорный, так как для удобства управления, вполне можно организовать проект, выделить ресурсы и т.п. И в принципе, лично я, посоветовал бы именно так и поступить. Но!
1) Вы четко должны зафиксировать рамки проекта, в том числе и временные. Логично ограничить проект внедрения первым PDCA циклом, после чего использовать процессный подход. Собственно, только после завершения хотя бы одного PDCA цикла можно задумывать о сертификации.
2) Одной из основных задач аудитора является проверка работоспособности PDCA цикла СУИБ, т.е. система должна постоянно улучшаться и корректироваться. Поэтому, если аудитор обнаруживает, что руководство считает, что процесс внедрения СУИБ закончен и больше нет необходимости выделять ресурсы или лично поддерживать внедрение, или существует явное нарушение PDCA цикла описанного в стандарте, это повод внести запись в протокол о серьезном несоответствии, что влечет за собой отзыв сертификата или отказ в сертификации.

Миф №4 – У нас есть сертификат ISO 27001 – теперь мы в безопасности

Это тоже серьезное заблуждение. Как я уже писал выше, с точки зрения ISO 27001, ИБ – это прежде всего управление рисками. Как вариант, руководство может принять существование рисков, т.е. согласиться с тем, что да, риски существуют, и мы будем с ними жить дальше, даже если это явная угроза ИБ. Сертификат в данном случае, позволит говорить о том, что в организации проведен анализ угроз и рисков, и менеджментом компании приняты решения, касающиеся управления этими самыми рисками. Т.е. компания осознано и комплексно управляет ИБ!
При этом, безусловно, внедрение и последующая сертификация СУИБ позволяют существенно повысить уровень ИБ. Как правило, в команде аудиторов, присутствуют и технические специалисты, которые оценивают конкретные технологические решения в рамках обеспечения ИБ.
Tags:
Hubs:
You can’t comment this publication because its author is not yet a full member of the community. You will be able to contact the author only after he or she has been invited by someone in the community. Until then, author’s username will be hidden by an alias.