Переход к 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сылке из Вики
    Буду рад, если эта заметка кому-то пригодится.
    Метки:
    • +6
    • 12,6k
    • 2
    Поделиться публикацией
    Комментарии 2
    • 0
      А нет объяснений почему исключили ежегодный пересмотр СМИБ?
      • 0
        К сожалению, нет.

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