Пользователь
0,0
рейтинг
29 апреля 2014 в 15:52

Разработка → Переход к ISO/IEC 27001:2013. Тонкости перевода и не только

Привет, Хабр!
25 сентября 2013 года был опубликован обновленный стандарт ISO/IEC 27001:2013 «Системы Менеджмента Информационной Безопасности. Требования» (Information security management systems — Requirements), пришедший на смену аналогичному стандарту 2005-го года. Мне в руки попал Transition Guide, и, дабы систематизировать свои знания и поделиться ими с теми, кому это будет интересно, я решил организовать эту короткую заметку.

Под спойлером: для чего вообще нужен сей стандарт
Цитата из wiki:
ISO/IEC 27001 — международный стандарт по информационной безопасности. Cодержит требования в области информационной безопасности для создания, развития и поддержания Системы менеджмента информационной безопасности (СМИБ).
В стандарте ISO/IEC 27001 (ISO 27001) собраны описания лучших мировых практик в области управления информационной безопасностью. ISO 27001 устанавливает требования к системе менеджмента информационной безопасности для демонстрации способности организации защищать свои информационные ресурсы. Настоящий стандарт подготовлен в качестве модели для разработки, внедрения, функционирования, мониторинга, анализа, поддержки и улучшения Системы Менеджмента Информационной Безопасности (СМИБ).


А нам-то что?


Само по себе прохождение аудита на соответствие 27001 не дает для бизнеса ничего, кроме гордости за свое ИБ-подразделение (поправьте меня, если я не прав). Однако может существенно облегчить прохождение таких важных аудитов, как, например, PCI DSS.
Однако, как мне кажется, любая крупная компания с международным бизнесом стремится получить заветную корочку.

Изменения в терминах


Стандарт 27001:2013 опирается на группу 31000 (оценка рисков).
В этой версии исчезает термин «Актив». Вместо него используются более широкие понятия «информация» и «сервис».
Кто-то скажет: «Как же так?!». Но постойте, ведь это логично: далеко не всякая информация, которую нужно защищать, является активом компании (в том смысле, в котором его употребляет, например, Роберт Кийосаки).

Добавлен термин «opportunities» (п.6.1.1) как потенциальная область для улучшений – широкий термин, который может включать в себя целый набор мер по устранению различных рисков.
Например, возможности по улучшению программного обеспечения включают в себя фикс конкретных багов, изменение архитектуры и даже, возможно, какие-то меры воздействия на вендора, предоставляющего это ПО, на уровне соглашений.

«Action» превратился в «Objective» — это текущая цель, конкретная и измеримая, в отличие от глобальной цели («Goal»).

В остальном, все также. Information Security — это обеспечение конфиденциальности, целостности и доступности, а риск-менеджмент осуществляется по методу Plan-Do-Check-Act.

По пунктам


Некоторые пункты совершенно новые, в некоторых добавились подпункты. Приведу (а, заодно, и переведу) основные из них.

п. 6.1.1:
Во время планирования СМИБ, организация должна определить риски и возможности (opportunities), что должно быть направлено на:
a) подтверждение того, что СМИБ способна достичь ожидаемых от нее результатов;
b) предотвращение или сокращение нежелательных эффектов; и
c) достижение непрерывного совершенствования.

п. 6.1.2 сводится к тому, что в организации должна быть формализована методология оценки рисков. При этом, при идентификации рисков за каждым из них обязательно должен закрепляться владелец – это новое требование [6.1.2 с) 2)].

п. 6.2:
Возможности (opportunities) ИБ должны:
b) быть измеримыми (если применимо);
с) брать во внимание применимые требования ИБ и результаты оценки и обработки рисков.
Во время планирования достижения возможностей ИБ организация должна определить:
f) что должно быть сделано;
g) какие ресурсы требуются;
h) кто будет ответственным;
i) когда нужно закончить; и
j) как будут оцениваться результаты.

п. 7.4 Взаимодействие – новый пункт.
Организация должна определить необходимость внутренних и внешних взаимодействий, относящихся к СМИБ, включая:
a) О чем;
b) когда;
c) с кем;
d) кто;
e) с помощью каких средств.
Аудитору можно продемонстрировать, например, записи в календаре outlook. Обычно, в них есть весь требуемый перечень.

п. 9.1 Мониторинг, измерение, анализ и оценка
Организация должна определить:
c) когда и
b) кто будет осуществлять мониторинг и измерения;
f) кто будет проводить анализ и оценку результатов.

Из п. 9.3 (Management review) исключено требование о ежегодном пересмотре СМИБ со стороны руководства.

п.10.1 Несоответствия и корректирующие действия
Когда обнаруживается несоответствие, организация должна:
a) отреагировать на несоответствие, и, если применимо:
1) принять меры по его контролю и корректировке; и
2) работать с последствиями;
e) если необходимо, внести изменения в СМИБ.
Организация должна сохранить задокументированную информацию как доказательство:
f) природы несоответствий и последующих принятых мер, и
g) результатов корректирующих действий.

Afterword


Более общую информацию о стандарте можно найти по cсылке из Вики
Буду рад, если эта заметка кому-то пригодится.
Владимир @valodik
карма
18,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (2)

  • 0
    А нет объяснений почему исключили ежегодный пересмотр СМИБ?
    • 0
      К сожалению, нет.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Интересные публикации