Как стать автором
Обновить

Мифы об 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, ИБ – это прежде всего управление рисками. Как вариант, руководство может принять существование рисков, т.е. согласиться с тем, что да, риски существуют, и мы будем с ними жить дальше, даже если это явная угроза ИБ. Сертификат в данном случае, позволит говорить о том, что в организации проведен анализ угроз и рисков, и менеджментом компании приняты решения, касающиеся управления этими самыми рисками. Т.е. компания осознано и комплексно управляет ИБ!
При этом, безусловно, внедрение и последующая сертификация СУИБ позволяют существенно повысить уровень ИБ. Как правило, в команде аудиторов, присутствуют и технические специалисты, которые оценивают конкретные технологические решения в рамках обеспечения ИБ.
Теги:
Хабы:
Данная статья не подлежит комментированию, поскольку её автор ещё не является полноправным участником сообщества. Вы сможете связаться с автором только после того, как он получит приглашение от кого-либо из участников сообщества. До этого момента его username будет скрыт псевдонимом.