Показаны сообщения с ярлыком информационная безопасность. Показать все сообщения
Показаны сообщения с ярлыком информационная безопасность. Показать все сообщения

суббота, 3 мая 2014 г.

Шпионаж и ИТ-саботаж: сходства и различия

Несмотря на то, что саботаж и шпионаж на первый взгляд кажутся совершенно разными типами инсайдерских правонарушений, между ними много общего.

Психология шпиона и саботажника во многом совпадает.

Мы привыкли при слове "шпион" представлять себе агента 007, хладнокровного, спокойного, обаятельного.

В действительности же, согласно отчету центра безопасности персонала PERSEREC Министерства обороны США, среднестатистический шпион - конфликтный сотрудник с вредными привычками и психическими проблемами, плохо уживающийся в коллективе.

В отчете PERSEREC Espionage and Other Compromises of National Security. Case Summaries from 1975 to 2008 детально рассмотрены реальные случаи шпионажа в гос.структурах США с 1975 по 2008 (141 случай).

На базе этой статистики можно смело провести анализ поведения шпиона и получить портрет среднестатистического шпионящего инсайдера.


Что и было сделано специалистами PERSEREC и CERT при помощи профессиональных клинических психологов контрразведки в отчете CERT. Comparing Insider IT Sabotage and Espionage: A Model-Based Analysis.

В отчете было проведено отдельное системно-динамическое моделирование ИТ-саботажника и шпиона, причем для ИТ-саботажа использованы результаты предыдущего исследования CERT по ИТ-саботажу, обработанные совместно с психологами при анализе CERT Insider Threat Database.

Затем исследователи сравнили модель шпионажа и ИТ-саботажа и пришли к выводу, что в моделях есть схожие черты. Авторы отчета смогли сформулировать 6 ключевых наблюдений о сходствах и различиях между шпионом и саботажником, а также сформировать общую модель поведения, единую для этих двух типов инсайдеров.

На мой взгляд, можно найти сходства и между другими типами инсайдеров: мошенниками, инсайдерами, осуществляющими кражу интеллектуальной собственности, саботажниками и шпионами.
Скорее всего в корне отличаться будет только поведенческая модель немотивированного инсайдера.
Поэтому в итоге, я надеюсь, мои исследования (да и исследования CERT) придут к общей модели, единой для всех типов инсайда, которая позволит выработать меры защиты для комплексного противодействия инсайду.

Наблюдение 1. Большинство саботажников и шпионов имели персональные предпосылки, которые увеличили риск совершения правонарушения.

Персональные предпосылки - это, как правило, неадекватная реакция на стресс, финансовые и прочие персональные нужды, которая ведет к конфликтам и нарушению правил, хроническому недовольству, сильной реакции на организационные санкции, утаиванию фактов нарушения правил и склонности к обострению рабочих конфликтов.

Наблюдение 2. В большинстве случаев шпионажу и ИТ-саботажу способствовали стрессовые события, в том числе организационные санкции.

Причем самым стрессовым событием для инсайдера является увольнение или отстранение от выполнения своих обязанностей. Большинство инсайдеров из CERT Insider Threat Database и PERSEREC Database атаковали именно после таких событий.

Наблюдение 3. Чаще всего подозрительное поведения можно было обнаружить до или во время проведения саботажа и шпионажа.

К подозрительному поведению относится:
Опоздания, прогулы
Конфликты с коллегами
Плохая производительность труда
Нарушения ИБ
Подготовка к атаке.

Наблюдение 4. Технические индикаторы могли бы предупредить организацию о планируемом или производимом нарушении.

Это наблюдение авторы формулируют как "ловушка доверия".
Чем больше организация доверяет инсайдеру, тем меньше у нее желание производить аудит и мониторинг его активности. А это уменьшает шанс того, что подозрительная активность данного сотрудника вообще будет обнаружена. Тем самым, опять же, растет доверие к инсайдеру.

Наблюдение 5. Во многих случаях организация проигнорировала или проглядела нарушение правил.

В некоторых случаях организации замечали нарушения правил, но игнорировали этот факт. Это поведение неверно. Необходимо, чтобы инсайдер понимал, что организация в курсе его деятельности.
В крайнем случае можно не информировать сотрудника, но установить более детальный мониторинг его действий.

Наблюдение 6. Недостаток физического и электронного контроля доступа влияет как на ИТ-саботаж, так и на шпионаж.

Как правило, инсайдер имеет доступ к активам, которые не являются необходимыми для выполнения его производственных функций.

Ролевое разграничение доступа - отличное решение.



Необходимо отметить, что несмотря на сходства, между шпионом и саботажником много отличий.

Саботаж - явление единичное. 
Шпионаж - процесс длительный.

Поэтому, как правило, социальные и технические индикаторы шпионажа проявляются гораздо раньше, чем аналогичные индикаторы саботажа.

Да и сами индикаторы у них отличаются.

Также важно, что, как правило, шпионаж не является настолько технически сложным, как саботаж. Поэтому шпион - это не обязательно привилегированный технический персонал.
Шпион обычно действует в рамках предоставленных прав и полномочий.



 Общая модель


Модель ИТ-саботажа





Модель шпионажа


Хочется отметить, что с точки зрения моделирования CERT и PERSEREC продвинулись вперед: они уже определяют типы обратных связей в системно-динамической диаграмме и типы зависимостей между элементами схемы :)

Но, безусловно, неприятно, что исследования до сих пор стоят на уровне диаграммы. Компьютерное моделирование проводить с использованием полученных моделей пока не представляется возможным.



Еще на тему защиты от инсайдеров читайте:

Лучшие практики защиты от инсайдеров от CERT

Управление риском ИТ-саботажа от CERT

Архитектура борьбы с инсайдом от CERT

среда, 16 апреля 2014 г.

Топ 10 рисков Web-приложений от OWASP 2013

На волне ажиотажа с атакой Heartbleed  стоит еще раз поднять тему безопасности Web-приложений.

Одним из самых популярных, интересных и доступных материалов на эту тему является ежегодных отчет проекта по безопасности Web-приложений OWASP - OWASP TOP-10 2013 
О нем и пойдет речь в обзоре.

Документ является классикой для специалистов по Web-безопасности, но рассказать о нем лишним никогда не будет :)





В документе использован интересный подход к классификации бед, связанных с Web-технологиями: рассматриваются не уязвимости, не атаки, а именно риски ИБ, которые определяются как совокупность:

1. Атакующего
2. Вектора атаки
3. Уязвимости (у которой есть характеристики распространенности и простоты обнаружения)
4. Мер защиты
5. Влияния реализованной атаки на технику
6. Влияния реализованной атаки на бизнес

И каждый риск описан в таком ключе.

Каждому риску посвящена всего 1 страничка, на которой кратко доступным языком даются его характеристики, то, как определить, подвержены ли вы этому риску, пример атаки, то, как от этого риска защититься и ссылки на другие материалы (среди других материалов стоит отметить отдельно знаменитый стандарт по оценке Web-безопасности того же самого проекта OWASP ASVS)

Итак, рейтинг ключевых рисков Web-приложений согласно OWASP:

1. Инъекции (SQL, LDAP, Xpath, NoSQL и т.д) - Injection
2. Угон сессий из-за уязвимостей в аутентификации и управлении сессиями - Hijacking (Broken Authentication and Session Management)
3. Межсайтовый скриптинг - XSS
4. Небезопасные прямые ссылки на внутренние объекты - Insecure Direct Object References
5. Ошибки конфигураций безопасности - Security Misconfiguration
6. Слабая криптография (и защита важной информации в целом) - Sensitive Data Exposure
7. Отсутсвие контроля доступа к функционалу
8. Подделка межсайтовых запросов - CSRF
9. Использование компонентов с известными уязвимостями - Using Components with Known Vulnerabilities
10. Непроверяемые переадресации между сайтами и внутри одного сайта - Unvalidated Redirects and Forwards

Стоит также отметить, что проверить приложение на предмет рисков из OWASP Top 10 требуется согласно стандартам PCI DSS 3.0 и PA DSS 3.0

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

Впечатления от VII CISO Forum 2014 (Форум директоров по ИБ)

Подошел к концу седьмой межотраслевой форум директоров по информационной безопасности (VII CISO Forum)

Расскажу о впечатлениях.

Мероприятие прошло на достаточно высоком уровне. Выступлений в стиле "покупайте наших слонов" практически не было. Даже если вендор и пытался продать свой продукт, делал он это с умом и интересно :)





Среди выступающих хотел бы отметить:

Константина Коротнева (Эльдорадо) с докладом о стратегическом управлении ИБ

Андрея Конусова (Avantpost) с его зажигательным докладом про собственный IDM

Алексея Волкова (Северсталь-Инфоком) с докладом про внедрение электронных подписей на Северстали

Андрея Дроздова (ISACA) с его анализом стандартов по ISMS и связкой их с COBIT

Андрея Ерина (CARCADE-лизинг) с его трогательной историей про внедрение ИБ в 
корпоративную культуру при помощи шоколадок :)

Евгения Царева (Swivel) с его ненавязчивой рекламой своего продукта под видом анализа развития средств аутентификации

Никиту Кислицина (Group-IB) с анализом мобильных ботнетов

и, конечно, Евгения Климова (KPMG) c докладом про форензику

Прошу не обижаться докладчиков, которых я не упомянул, мероприятие было слишком интенсивное, все в голове перемешалось.

Я сам выступил с докладом "Современные методы противодействия инсайду" и рассказал о том, как проанализировать поведение инсайдеров при помощи системной динамики и выбрать стратегию противодействия.

Стоит отметить хорошую атмосферу форума, располагающую к общению, что, безусловно, является главным в мероприятии подобного уровня.

суббота, 12 апреля 2014 г.

Обзор PA-DSS 3.0

В ноябре 2013 г. вышла версия 3.0 стандарта безопасности данных платежных приложений индустрии платежных карт (PA-DSS).

Данные требования применяются к поставщикам платежных приложений.

Семейство стандартов и требований PCI (индустрии платежных карт) состоит из трех документов:


1. PCI PIN Transaction Security (PTS) Point of Interaction (POI) v. 4.0
- требования к POI-устройству по безопасности транзакций с использованием PIN-кода (требования к аппаратным терминалам)

2. PA-DSS v. 3.0  - требования к приложениям, обрабатывающим платежную информацию.

3. PCI DSS v. 3.0  - требования к среде, обрабатывающей информацию платежных карт.
Обзор стандарта PCI DSS v. 3.0


Стандарт PA-DSS применяется для платежных приложений, которые распространяются на рынке. То есть в случае, если приложение разрабатывается для использования в личных целях или для использования одним заказчиком, то можно добиваться соответствия сразу PCI DSS.

Сертификат PA-DSS гарантирует то, что приложение, установленное правильным образом в среду, удовлетворяющую требованиям PCI DSS не нарушит безопасность этой среды. Это гарантия того, что среда сохранит соответствие PCI DSS.

Именно поэтому вместе с самим сертифицированным приложением в комплект поставки должен входить документ "Руководство по внедрению стандарта PA-DSS", который говорит о том, как правильным образом устанавливать и эксплуатировать приложение.

Причем не обязательно выполнять все требования стандарта PA-DSS. Если приложение планируется использовать на конкретном POI-устройстве, прошедшем сертификацию по PCI PTS, то требования можно закрыть с использованием функционала POI.
Тогда в перечне приложений, сертифицированных по PA-DSS, наше приложение будет идти с пометкой, что его необходимо использовать только в связке с конкретным POI-устройством.

Аудит приложения производится сертифицированным аудитором платежных приложений (PA-QSA) в лаборатории, требования к которой приведены в приложении В к стандарту.
Причем по возможности PA-QSA должен использовать свою лабораторию.
Если в лаборатории PA-QSA отсутствует необходимое железо, то необходимо запросить железо у разработчика ПО либо, если это сделать невозможно, проводить аудит в лаборатории разработчика.
По результатам аудита оформляется отчет о проверке PA-DSS (называемый ROV) и направляется в PCI SSC.



PA-DSS состоит из 14 требований:

1. Не хранить полные данные магнитной дорожки, код или значение проверки подлинности карты (CAV2, CID, CVC2, CVV2), или данные PIN-блока
2. Обеспечить безопасное хранение данных держателей карт
3. Предоставление функций безопасной аутентификации
4. Следует вести журнал активности платежного приложения
5. Необходимо разработать безопасные платежные приложений
6. Защита беспроводной передачи данных 
7. Необходимо тестировать платежные приложения с целью устранения уязвимостей и регулярного обновления приложений
8. Необходимо обеспечить возможность внедрения в безопасные сетевые среды
9. Данные держателей карт ни в коем случае не должны храниться на сервере, подключенном к Интернету
10. Необходимо обеспечить безопасный удаленный доступ к платежному приложению
11. Необходимо шифровать конфиденциальный трафик в общедоступных сетях
12. Необходимо шифровать неконсольный административный доступ
13. Необходимо составить Руководство по внедрению стандарта PA-DSS для клиентов, реселлеров и интеграторов
14. Необходимо назначить сотрудникам обязанности по стандарту PA-DSS и обеспечить программы обучения сотрудников, реселлеров и интеграторов.



Требования стандарта PA-DSS во многом пересекаются с требованиями его большого брата PCI DSS.
Из нового можно отметить требования к управлению версиями (5.4) и требование к разработке сопроводительного документа "Руководство по внедрению стандарта PA-DSS". О необходимости составления такого документа говорится практически в каждом требовании, также ему посвящено требование 13, кроме того существует Приложение А, которое еще раз говорит о том, что должно быть в документе.

Любопытно то, что согласно PA-DSS ответственность за обучение и предоставление информации реселлерам и интеграторам, которые будут внедрять ПО, ложится на разработчика ПО (требование 14).


Стандарт, безусловно, будет полезен разработчикам платежных приложений, даже если они не собираются сертифицировать свои продукты. Он детален, охватывает все аспекты безопасности приложений и хорошо структурирует подход к разработке и внедрению безопасного ПО.

воскресенье, 6 апреля 2014 г.

Обзор PCI DSS 3.0

Представляю вашему вниманию краткий обзор стандарта безопасности данных индустрии платежных карт PCI DSS 3.0 (Payment Card Industry Data Security Standard).







В начале необходимо рассказать, какие именно данные призван защищать данный стандарт.

Данные платежный карт (Account Data), согласно PCI DSS, делятся на данные держателя карты и критичные аутентификационные данные.


К данным держателя карты относятся:

1. Основной номер держателя карты (Primary Account Number, PAN) - 16 цифр, эмбоссированных или выгравированных на лицевой стороны пластиковой карты.

PAN идентифицирует платежную систему банк-эмитент (банк, который выпустил данную пластиковую карту) и держателя (владельца) карты.

2. Имя держателя карты. Указывается, как правило, в нижней части лицевой стороны пластиковой карты.

3. Данные истечения срока действия карты. Указывается непосредственно под основным номером держателя карты.

4. Сервисный код. Информация о возможностях карты (является ли она международной, встроены ли дополнительные технологии, такие как чип, а также для каких операций предназначена карта и для каких операций запрашивать PIN-код). 

Данная информация находится на магнитной полосе и в чипе (при его наличии).

К критичным аутентификационным данным относятся:

1. Полные данные дорожки магнитной полосы или ее эквивалент на чипе.

2. CAV2/CVC2/CVV2/CID.


CVC2 - трехзначный код подтверждения подлинности карты Visa, расположенный под магнитной полосой с оборотной стороны пластиковой карты и используемый для проведения операций "Card not present" (покупка через интернет/телефон).

CVV2 - аналогичный код для MasterCard.

CAV2 - аналогичный код для японской платежной системы JCB Cards.

CID - аналогичный код для платежных систем American Express и Discover.

3. PIN/PIN-блоки. PIN - код (как правило, 4 цифры), аутентифицирующий владельца карты. PIN-блок - то, во что он преобразуется после ввода на пин-паде (зашифрованное значение).


Эту информацию и призван защищать стандарт PCI DSS.



Теперь расскажу более подробно о самом стандарте.

PCI DSS разработан организацией PCI SSC (Security Standards Council), учрежденной платежными системами Visa, MasterCard, JCB Cards, American Express и Discover.

Стандарт является обязательным для организаций, обрабатывающих данные платежных карт этих платежных систем.

Все организации делятся на торгово-сервисные предприятия (ТСП, merchants) и поставщиков услуг (service providers). К торгово-сервисным предприятиям относятся те организации, которые принимают оплату своих товаров или услуг посредством платежных карт (магазины, кафе, автозаправки и т.д.). К поставщикам услуг относятся организации, которые обеспечивают процесс осуществления платежа (банки-эмитенты, банки-эквайреры, процессинговые центры, сами платежные системы, хостинг-провайдеры и т.д.).

Для сертификации на соответствие PCI DSS существует три вида проверок:

1. Самое простое - самооценка с заполнением листа самооценки (Self-Assesment Questionnaire - SAQ). Причем бывает 4 вида листов самооценки (в зависимости от числа проверок)

2. ASV-сканирование - сканирование проверенными вендорами (Approved Scanning Vendors). Список компаний ASV

3. QSA-аудит - полноценный аудит на соответствие PCI DSS, проведенный организацией со статусом Qualified Security Assessor. Список компаний QSA

В зависимости от того, является организация ТСП или поставщиком услуг, а также от числа обрабатываемых транзакций, необходимо проходить те или иные проверки.



В самом стандарте 12 требований, разбитых по 6 доменам безопасности:

домен "Построение и обслуживание защищенной сети и систем"
1. Установить и обеспечить функционирование межсетевых экранов для защиты данных держателей карт.
2. Не использовать пароли и другие системные параметры, заданные производителем по умолчанию.

домен "Защита данных держателей карт"
3. Обеспечить безопасное хранение данных держателей карт.
4. Обеспечить шифрование данных держателей карт при их передаче через сети общего пользования.

домен "Программа управления уязвимостями"
5. Использовать и регулярно обновлять антивирусное программное обеспечение.
6. Разрабатывать и поддерживать безопасные системы и приложения.

домен "Внедрение строгих мер контроля доступа"
7. Ограничить доступ к данным держателей карт в соответствии со служебной необходимостью.
8. Определять и подтверждать доступ к системным компонентам.
9. Ограничить физический доступ к данным держателей карт.

домен "Регулярный мониторинг и тестирование сети"
10. Контролировать и отслеживать любой доступ к сетевым ресурсам и данным держателей карт.
11. Регулярно выполнять тестирование систем и процессов обеспечения безопасности.

домен "Поддержание политики информационной безопасности"
12. Разработать и поддерживать политику информационной безопасности для всего персонала организации.


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

Для хостинг-провайдеров выдвигаются дополнительные требования.

Если организация не может выполнить какое-либо требование по объективным ограничениям, то после проведения оценки рисков она может внедрить компенсационные меры, с помощью которых достигнут цели изначального требования другим способом.



Необходимо отметить, что стандарт очень полно покрывает все аспекты обеспечения информационной безопасности. Требования детальны, понятны. Возможно, даже чересчур детальны и понятны :)

Вместо того, чтобы давать более гибкий и системный подход к обеспечению информационной безопасности, как это делают его коллеги ISO 27001 или ISM3, PCI DSS выставляет жесткие четкие требования, и их надо выполнить. Возможно, в сфере платежей с использованием пластиковых карт это оправдано.

Также необходимо отметить, что существует родственный стандарт PA DSS (Payment Application Data Security Standard), посвященный безопасности платежных приложений.

понедельник, 31 марта 2014 г.

Архитектура борьбы с инсайдом от CERT

Прочитал очередной документ по управлению инсайдерской угрозой ИБ о CERT.

Insider Threat Security Reference Architecture (2012)


Документ является логичным продолжением исследований Common Sense Guide to Mitigating Insider Threats и Management and Education of the Risk of Insider Threat: System Dynamics Modeling of Computer System Sabotage, которые я также рассматривал на своем блоге.

Итак, Insider Threat Security Reference Architecture от CERT.


По документу ясно, что авторы решили упорядочить свои знания по противодействию инсайду в более четкую методологию, по образу и подобию методологий и стандартов управления ИТ и ИБ.

В работе выделены 4 основных уровня безопасности:
1. Уровень бизнеса
2. Уровень информации
3. Уровень данных
4. Уровень приложений
 

Подобное деление, правда с другими уровнями, можно встретить в CobiT 5 или даже в старой статье Алексея Лукацкого.

Вот как CERT определяет данные уровни:

Уровень бизнеса: высокоуровневые требования бизнеса, такие как миссия организация, политики и процедуры.


Уровень информации: сеть и компоненты сети, железо и софт (другими словами, ИТ-инфраструктура).


Уровень данных: информационные активы организации.


Уровень приложений: приложения, поддерживающие бизнес, наподобие ERP или CRM.

Причем авторы документа утверждают, что невозможно полноценно защититься от той или иной угрозы ИБ, не внедрив меры защиты на всех четырех уровнях.

С данным постулатом я согласен, но уровни я бы расположил в другой последовательности (с учетом того, как эти уровни понимает CERT):

1. Уровень бизнеса
2. Уровень данных
3. Уровень приложений
4. Уровень информации (онной инфраструктуры).

Вообще, в этом отношении мне импонирует модель ИТ-инфраструктуры из СТО БР ИББС. Ее можно красиво объединить с моделью из CobiT и получить более точную и взвешенную архитектуру. Авторы явно взяли модель из NIST и зачем-то поменяли уровни местами. Но не об этом речь.

Для каждого уровня авторы приводят примеры рекомендуемых к применению стандартов и методологий ИБ.

Для уровня бизнеса: SABSA, NIST 800-37, Six Sigma (Как сюда ложится Six Sigma я не понимаю).

Для уровня информации: Open Security Architecture, Cisco Safe, NIST 800-53.

Для уровня данных: CDSA, Oracle Database Security.

Для уровня приложений: разумеется OWASP, CERT Security Coding Standards, Microsoft Appication Security.


С точки зрения управления инсайдерской угрозой авторы выделяют три основные типа деятельности:
1. Предотвращение (возможных в будущем инцидентов)
2. Обнаружение (инсайдерской деятельности)
3. Противодействие (обнаруженной инсайдерской деятельности)

Индикаторы инсайдерской деятельности бывают техническими и социальными. Ключевой момент в грамотном управлении инсайдерской угрозе - корреляция как раз технических и социальных данных.


CERT в своей работе выделяют также три фундаментальных принципа защищенности организации от инсайдерской угрозы:
1. Принцип авторизованного доступа.
2. Принцип допустимого использования.
3. Принцип непрерывного мониторинга.

На базе данных принципов и деления безопасности на 4 уровня, авторы разработали таблицу ключевых мер защиты, которые необходимо внедрить для минимизации рисков инсайдерской угрозы ИБ (они назвали ее ITSRA Matrix):





Табличка мне нравится, данный подход к структуризации мер защиты видится мне весьма гармоничным, даже более гармоничным, чем подход, приведенный в стандарте ISO 27001. Но с тем, что приведенные в табличке меры защиты полностью охватывают все аспекты борьбы с инсайдом, можно поспорить. Поэтому авторы статьи скромно заявляют, что данная матрица приведена для примера.





Статья заканчивается демонстрацией того, как правильно защититься от конкретной угрозы ИБ с использованием предложенной архитектуры.


Документ, несмотря на некоторые недостатки, мне понравился. Он очень логично дополняет предыдущие исследования CERT и является шагом к построению полноценной методологии борьбы с инсайдерской угрозой ИБ.




Еще на тему защиты от инсайдеров читайте:

Лучшие практики защиты от инсайдеров от CERT

Управление риском ИТ-саботажа от CERT


Шпионаж и ИТ-саботаж: сходства и различия

суббота, 29 марта 2014 г.

Обзор ISO 27001:2013

В сентябре 2013 года вышла новая версия самого известного стандарта по управлению информационной безопасностью - ISO/IEC 27001 Information technology - Security techniques - Information security management systems - Requirements

Наконец-то нашел время ознакомиться с новой версией документа и написать короткий обзор!



Документ состоит из повествовательной части, в которой описываются требования к построению системы управления информационной безопасностью, и приложения А, в котором содержатся основные цели информационной безопасности и меры, которые необходимо применять, чтобы этих целей достигнуть.

Более подробно цели и меры ИБ описаны в стандарте ISO 27002, который также обновился в сентябре 2013 года.

В качестве основы для СУИБ ISO 27001 предлагает использовать процесс управления рисками ИБ. Причем в версии 2013 года процесс управления рисками ИБ приведен в соответствии с серией стандартов по управлению рисками ISO 31000.

В новой версии стандарта построение СУИБ начинается с определения того, как ИБ может повлиять на достижения бизнес-целей организации, понимания потребностей заинтересованных сторон и внешних обязательств.

Появление подобной главы не может не радовать, но необходимо отметить, что в других стандартах и методологиях процесс целеполагания рассмотрен гораздо более подробно и гармонично (взять, к примеру, CobiT 5 или O-ISM3)

В качестве основной движущей силы СУИБ стандарт позиционирует лидерство (то, что ранее называлось приверженность руководства). Необходимость инициативы и приверженности высшего руководства организации обозначена более четко в новой версии стандарта. Причем высшее руководство должно разработать политику информационной безопасности и организационную структуру для СУИБ.

В главе, посвященной планированию, описан процесс управления рисками ИБ, состоящий из следующий стадий:
1. Оценка рисков ИБ:
1.1 Установление критериев принятия рисков и критериев для проведения оценки рисков ИБ.
1.2 Определение рисков и владельцев рисков.
1.3 Анализ рисков:
1.3.1 Определение последствий возникновения рисков
1.3.2 Определение вероятности возникновения рисков
1.3.3 Определение уровня рисков
1.4 Непосредственно оценить риски: сравнить с критериями и произвести приоритезацию
2. Обработка рисков ИБ:
2.1 Выбрать вариант по обработке риска.
2.2 Определить меры, которые необходимо использовать для реализации варианта обработки
2.3 Сравнить с каталогом целей и мер в Приложении А.
2.4 Разработать положение о применимости мер ИБ с обоснованием.
3.5 Разработать план по обработки рисков.
3.6 Согласовать с владельцами рисков план и получить согласие на принятие остаточных рисков.

Согласно стандарту, на стадии планирования организации также необходимо определить цели ИБ и меры для их достижения.

Основными факторами, необходимыми для поддержки СУИБ, согласно ISO 27001:2013, являются:
1. Ресурсы
2. Компетенция
3. Осведомленность
4. Коммуникации
5. Документирование

Причем документирование рассмотрено в стандарте более подробно.

Процесс оценки и обработки рисков должен производится регулярно в течение эксплуатации СУИБ, наряду с оперативным планированием и контролем.

В качестве основных способов для оценки результативности СУИБ являются:
1. Мониторинг, измерение, анализ и оценка.
2. Внутренний аудит.
3. Анализ со стороны руководства, базирующийся в том числе на результатах мониторинга и внутреннего аудита.

В конце повествовательной части даны требования по улучшению СУИБ при выявлении несоответствий, в том числе постулирована необходимость постоянного улучшения.

Каталог целей ИБ и мер по их достижению состоит из следующих доменов:

А.5 Политики ИБ
А.6 Организация ИБ
А.7 Безопасность, связанная с персоналом
А.8 Управление активами
А.9 Управление доступом
А.10 Криптография
А.11 Физическая безопасность и защита от окружающей среды
А.12 Безопасность при обработке информации
А.13 Безопасность связи
А.14 Приобретение, разработка и поддержка систем
А.15 Взаимоотношения с поставщиками
А.16 Управление инцидентами ИБ
А.17 ИБ при управлении непрерывностью бизнеса
А.18 Соответствие требованиям

Мне особенно понравились домены А.7 и А.15. Но, безусловно, необходимо отметить, что они более подробно рассмотрены в том же CobiT или лучших практиках CERT 

На мой взгляд, про управление инцидентами ИБ необходимо было упомянуть и в основной части стандарта, т.к. этот процесс наряду с управлением рисками ИБ является основным в СУИБ.

Новая версия стандарта мне понравилась, видно развитие, хотя не такое сильное как в других методологиях, стандартах и лучших практиках.