...

вторник, 29 апреля 2014 г.

Переход к 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сылке из Вики

Буду рад, если эта заметка кому-то пригодится.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


Комментариев нет:

Отправить комментарий