Геймификация при обучении и повышении осведомлённости по ИБ (Gamification on information security awareness, education and training)

“Ready Player One” (c) Ernest Cline

Сегодня я хочу отметить важность использования научных исследований и передовых подходов для применения их в работе в области ИБ (и вообще в любых областях). В начале я приведу результаты одного такого исследования, а далее раскажу и покажу на примерах, как эти результаты удалось применить в работе. Те, кто зашёл просто посмотреть скриншоты - спускайтесь в самый низ :)


Предисловие
В Австралии в 2016 году было проведено исследование о влиянии личных качеств или личных черт личности сотрудников на результаты программы повышения осведомлённости ИБ (далее ППОИБ).
(DOI: 10.1016/j.chb.2016.11.065 "Individual differences and Information Security Awareness")

За анализируемые критерии исследователи взяли наличие самой ППОИБ, пол, возраст, 5 «больших» факторов личности (Big Five), склонность к риску.

В исследовании приняли участие 286 женщин и 219 мужчин, с возрастом от 18 до 60++, из 13 различных отраслей, имеющие различные должностные положения в организациях. Самое важное условие, это обязательное наличие программы ИБ в их организации (политики, инструкции и т.д.).

Результаты исследования:
Согласно исследованию существенное влияние на успешность ППОИБ оказывают следующие черты личности:
• Добросовестность (Big 5 - Conscientiousness) – способна повлиять положительно.
• Приятность в общении (Big 5 - Agreeableness) – способна повлиять положительно.
• Эмоциональная стабильность (Big 5 - Neuroticism) – способна повлиять отрицательно.
• Склонность к риску – способна повлиять отрицательно.

Не существенное влияние оказывают:
• Возраст
• Пол
• Открытость к новому опыту (Big 5 - Openness to experience)

Не оказывает влияния:
• Экстраверсия (Big 5 – Extraversion) – экстраверт или интраверт испытуемый.

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

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

Там же я узнал о существовании модели обучения KAB: Знания (Knowledge), Отношение (Attitudes), Поведение (Behaviour). Согласно которой, успешная ППОИБ основывается на этих 3 китах.

Например:
Если мы хотим скорректировать поведение сотрудников (к примеру меньше переходить по ссылкам в фишинговых письмах), то мы должны предоставить им соответствующие знания об угрозах\атаках\уязвимостях\ИБ политиках\инструкциях, выработать у них соответствующее отношение к этим знаниям (почему они должны им следовать) давая им корректирующие установки "как избежать проблем" или рассказывая о правилах безопасности, таким образом, выработав у них соответствующее поведение (что они должны делать).

Недостаточно это применять только в обучающих курсах. Это нужно применять в рамках ваших ИБ-процессов всегда, где предоставляется обратная связь клиенту по инциденту (сотруднику или бизнес-подразделениям).

В том же исследовании, упоминался другой аналитический материал - "The Human Aspects of Information Security Questionnaire" (HAIS-Q). Это некая модель, разработанная в 2014 году, для оценки угроз ИБ, направленных именно на сотрудников в рамках одной организации. Эта модель выделяет 7 ключевых доменов по которым необходимо проводить ППОИБ (о них я уже ранее писал):
- Безопасность паролей
- Безопасность электронной почты
- Безопасность информации
- Безопасность мобильных устройств
- Безопасность в Интернет
- Безопасность в социальных сетях
- Информирование об инцидентах


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

Получилось точно хорошо, насколько хорошо - могут оценить только эксперты и тестирование знаний сотрудников. Но могу сказать, что такая доскональная проработка деталей отсутствует даже у профессиональных сервис-провайдеров на рынке РФ, которые берутся за разработку обучающих курсов по ИБ. Но для понимания, я был лишь одним из участников команды и занимался разработкой контента. Были ещё РП, дизайнер, outsource команда разработки (для игры по ИБ), копирайтер. Конечный продукт получился при взаимодействии профессионалов и каждый участник внёс свою лепту.

Платформа обучения на которой базируются курсы и игра - СДО WebTutor. Рекомендую её как очень функциональный, удобный и гибкий продукт для дистанционного обучения и управления знаниями.

Теперь немного о получившихся продуктах:
1) Курс обучения "Безопасность паролей"
Команда: администратор WebTutor (1 чел., РП), outsource-разработчик SCORM-пакета (дизайн+копирайтинг, 1 чел.), безопасник (контент+копирайтинг+требования к дизайну, 1 чел.).

Ценности: Повышение осведомлённости, лучшие практики по безопасности паролей.

2) Игра по ИБ
Команда: Внешний сервис-провайдер (команда разработчиков -> дизайн\код\сюжет\контент\ SCORM-пакет), безопасник (контент, требования к дизайну, сториттелинг, тестирование), копирайтер (сюжет + тестирование), администратор WebTutor (РП), outstaff-разработчик WebTutor (создание рейтинга игроков).

Ценности: Геймификация программы обучения, повышение вовлечённости сотрудников и эффективное усвоение знаний и навыков по ИБ.

Игра получилась с 5 глобальными доменами повышения осведомленности (2 осталось не проработано из-за некоторых ограничений в ресурсах), 15 проблемными темами в том числе фишинг, вред. ПО, вишинг, смс-мошенничество и другие (которые приводятся у меня в блоге), рейтингом игроков (делался отдельно на WebTutor со статистикой в режиме реального времени) и поощрительными призами для первых финалистов игры (кто быстрее пройдёт, того и тапки). В игре 15 блоков на 5 доменов. Каждый блок содержит правильные и неправильные ответы\решения игрока. Так вот один блок это 6,66% к прохождению игры. Если в блоке 6 вопросов - то каждый вопрос это примерно 1% к прохождению. Попыток прохождения не ограничено (но при желании можно ограничить). Таким образом пройдя успешно все 15 блоков - игрок набирает 100%. Мы опасались, что игрок попросту не будет играть до 100% (тоесть проходя все блоки на отлично и без ошибок), поэтому в какой-то момент игра давала закончить себя на 78% (это примерно 7 блоков пройденных на отлично) и предоставляла игроку финал, поздравления, эмоции. Но так как была поощрительная часть и дух сопернечества, то ограничение сняли и игра проходилась при получении 100% баллов за правильные ответы.

Я участвовал в разработке контента, сторителлинга, требований к дизайну, роботам, игровым задачкам, тестировании, сопровождении и Бог знает чего ещё. По сюжету игрока вызывают на помощь в подразделение безопасности, дают ему очки для погружения в корпоративное киберпространство и он должен "спасти компанию" от растущего кол-ва кибератак ;)

Адаптивная многофакторная аутентификация (Adapting multifactor authentication)

(c) Ram Dass (Kali Linux)

Классические пароли имеют большое количество угроз и уязвимостей (особенно человеческого фактора) и оставлять доступ к публичным сервисам организации только по паролю – слишком рискованно для любого бизнеса. Лучшие практики для усиления безопасности это внедрение 2-ух факторной аутентификации. Но мы пойдём ещё дальше, я расскажу об адаптивной многофакторной аутентификации.


Небольшая предыстория
В начале было слово и слово это было не просто слово, а набор слов, – целое требование в ТЗ  нового разрабатываемого клиентского веб-сервиса в целях цифровизации "офлайнового" бизнес-процесса. Требование звучало так: "Реализовать механизм двухфакторной аутентификации".

На определённом этапе разработки клиентского сервиса в целях формирования и реализации потребностей клиентов  – была сформирована фокус-группа пользователей от крупных клиентов организации. Для них в определённый момент был опубликован предварительный тестовый инстанс веб-сервиса с минимально реализованным к тому времени функционалом. Доступ предоставлялся по клиентскому IP-адресу (да, не очень удобно, зато секьюрно). Также почти сразу, мы закрыли веб-приложение WAF-ом в режиме Prevent, причём без каких-либо костылей, и это было лучшим решением в плане безопасности. В таком режиме разработки и тестирования сервиса прошло примерно 10 месяцев и мы, наконец, дошли до фазы проекта – реализация требований безопасности.

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

1. Поиск и исправление всех обнаруженных уязвимостей приложения всеми доступными нам средствами (проверяли приложение на соответствие требованиям стандарта OWASP ASVS, запускали различные сканеры уязвимостей SAST\DAST и т.д.)
2. Разработка процессов системы безопасности приложения (регистрация пользователей, первый вход, 2-FA, сброс пароля, управление сессиями и т.д.)
3. Пентест приложения и исправление обнаруженных уязвимостей.

Когда поднялся вопрос о реализации 2FA я начал изучать вопрос и наткнулся вот на такую простую схему:

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

Что разъясняет эта схема?
Что веб-приложение проверяет не только 2 (или более) фактора аутентификации, но и осуществляется проверка так называемого контекста пользователя, – сверяются некие известные данные о пользователе. Например, что пользователем осуществляется вход с известного устройства, сети, браузера, определённого времени на устройстве или осуществляется проверка известного поведения пользователя, например доступ к приложению из известной геолокации, аналитика движений мыши, скорости набора текста, вход в рабочее время и т.д. Если всё ОК – второй фактор не запрашивается. Это если кратко.

Данное решение предоставляет следующие ценности:
1) Удобство (не нужно каждый раз проходить второй фактор, система "помнит" контекст клиента)
2) Повышенный риск-ориентированный уровень безопасности (система может быть настроена на проверку определённых рисков)
3) Экономический эффект (например, не нужно каждый раз отправлять платные СМС, снижается время на безопасный вход в приложение)

Никто не мешает внедрять подобное в SSO-решениях и кастомизировать под свои риски и потребности. Механизм доказывает, что можно делать безопасные решения не в ущерб функциональности и удобству:

Security Functionality Usability Triangle (c) EC-Council CEH

Рассмотрим подробнее пример реализации:
При успешном прохождении первого фактора (логин и пароль) и второго фактора (ввод кода из SMS, из Email, приложения и т.д.), веб-сервер должен запоминать контекст клиента, например связку: IP-адрес (к примеру первые 2 октета, на случай если IP-адрес клиента динамически меняется), user-agent (идентификатор браузера клиента) и далее генерировать токен аутентификации для клиентского браузера, сохраняя его в Cookies с определённым сроком жизни (зависит от контекста организации и приложения, срок жизни токена например 1 месяц). Веб-сервер под каждого успешно аутентифицированного пользователя ведёт в БД отдельную таблицу запоминаемого контекста клиента: IP-адрес, User-Agent, Token (этим не ограничено).

При следующем входе клиента – если контекст пользователя не поменялся (срок действия токена не истёк и валидный токен присутствует в Cookies браузера, IP-адрес не изменился, User-Agent тот же)  – второй фактор система не запрашивает. Если поменялось хоть что-нибудь из контекста пользователя, – инициируется запрос и проверка второго фактора (у нас это был OTP: код по SMS, email и т.д.) и выдача нового токена при успешной аутентификации. При этом ещё нужно задать ограничение на кол-во запоминаемых контекстов пользователя и при его превышении - удаление наиболее старого или сброс остальных с уведомлением. Также, например, осуществлять сброс токенов - когда при переборе паролей (атакующие сумели обойти CAPTCHA) осуществляется сброс всех токенов для данного пользователя (скажем после 100-ой попытки подбора пароля). Это для подстраховки, если атакующий изменит вектор атаки. При прохождении второго фактора и входа на сервис – отправлять пользователю email-уведомление.

Результаты
Совместно с командной разработки мы реализовали подобный механизм. Но вместо дорогого и не всегда доступного SMS-сервиса (на западе крупный бизнес давно уже от него уходит) в нашем приложении была реализована отправка кода по EMAIL. Да, не самый безопасный способ, зато самый простой и доступный в реализации (не во всех организациях разрешено на рабочем месте использовать смартфон). По сути мы перекладываем риски безопасности для второго фактора на плечи сервиса электронной почты клиента. Это не самое секьюрное решение, но в контексте нашего приложения и других механизмов безопасности – этого достаточно (по моей субъективной оценке).

Cо стороны КЛИЕНТОВ и БИЗНЕСА – к реализованному решению никаких претензий не последовало, оно показалось вполне удобным, а главное – безопасным.

Также, механизм прошёл успешный аудит безопасности командой пентестеров (топовый сервис-провайдер в РФ). По методике OWASP Testing Guide (раздел OTG-AUTHN-XXX) – уязвимостей не обнаружено.

"Я считаю это успех! Машина времени работает!" (с)

p.s. Помните, мало просто внедрить 2FA, надо убедиться, что нет других уязвимостей, например, перехвата сессии или отсутствия ограничения на кол-во одновременных сессий и т.д., чтобы всё не оказалось напрасным. Также, надо всё самому проверять, особенно логику процессов безопасности. Разработчики и тестировщики могут пропустить.


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

• https://www.slideshare.net/SecureAuth2FASSO/why-twofactor-isnt-enough
• https://www.secureauth.com/products/access-management/adaptive-authentication

Программа повышения осведомлённости и ключевые домены оповещения сотрудников (Security Awareness Program and core security awareness domains)

"A chain is only as strong as its weakest link" (с) Thomas Reid’s

Защищая активы и операционную деятельность организации мы выстраиваем различные меры и процессы безопасности. Стараемся охватить все возможные уровни абстракции на которых существуют риски, начиная с физической безопасности материальных активов, многоуровневой компьютерной, сетевой, информационной и, если хотите, кибербезопасностью и заканчивая защитой нематериальных активов. Можем использовать data-orientied и people-orientied подходы, да какие угодно подходы и лучшие практики - лишь бы они были эффективны и был результат. Главная цель, - обеспечить безопасность всего бизнеса в целом, всех его материальных и нематериальных активов (таких, например, как репутация, бренд или доверие клиентов). Это конечно идеальная картина работы системы управления информационной безопасностью (СУИБ или ISMS).

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

За примерами в реальном мире далеко ходить не надо. Довольно часто в рамках аудита безопасности, пентеста или социотехнического тестирования обнаруживаются не только известные технические уязвимости в системах, но и "всплывает" человеческий фактор: слабые\записанные\сохранённые пароли, не завершённая сессия администратора,  повышенный уровень привилегий УЗ пользователя, локальные УЗ, неподготовленность сотрудников к атакам или инцидентам ИБ и т.д.

Расмотрим конкретные угрозы: фишинг и вред. ПО. Основной канал распространения данных угроз - электронная почта. Нежелательное письмо прошло все уровни безопасности (а их по принципу Defense in Depth организовано с избытком) и доставлено в почтовый клиент на компьютер сотрудника. Сотрудник просматривает письмо: оно идёт с пометкой срочно, от незнакомого контакта, содержит убедительный текст призывающий к действиям, оформлено вполне себе прилично и содержит безобидное вложение формата Microsoft Office. Пользователь по привычке открывает документ и в этот момент на его машине выполняется скрытый вредоносный код (VBA, OLE-объект, встроенные макросы и т.д.) или эксплуатация конкретной уязвимости не пропатченного пакета MS Office. Возможно много вариаций, что будет происходить дальше, вплоть до скачивания полезной нагрузки через инкапсуляцию трафика в другие протоколы: HTTPS,  DNS, ICMP и т.д. По статистике, вредонос будет либо Ransomware (вымогатель шифровальщик), либо Backdoor (контроль ПК\ботнет клиент), либо майнер криптовалют. А может, что и похуже (вспоминаем шифровальщика с функциями сетевого червя - WannaCry). А самое главное, подготовить не детектируемую антивирусами полезную нагрузку - злоумышленникам не составляет особого труда. Для этого используются различные приёмы обфускации. Старичок "сигнатурный анализ" такое пропускает. В общем риск для бизнеса очень высокий. Вспомните последствия распространения WannaCry.

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

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

На помощь приходит комплексный подход (comprenhensive approach). Помимо технических, организационных, правовых мер безопасности, существуют также и peopleorientied меры и они зачастую предоставляют более сбалансированный по цене\качеству результат, чем другие решения.

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

По ISO/IEC 27002:2013 существует одноимённый процесс: 7.2.2 Information security awareness, education and training. Необходимо непрерывно учиться самим, быть в тренде, а также обучать сотрудников вашей организации, повышая их осведомлённость по конкретным угрозам ИБ, обобщённым их признакам и правилам реагирования и безопасности.

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

Ключевые домены информирования:

1)        Безопасность в сети Интернет

•          Актуальные угрозы ИБ в сети Интернет

•          Вредоносное ПО

•          Раздражающая и потенциально опасная реклама

•          Опасные дополнения для веб-браузера

•          Развлекательные веб-страницы

•          Социальная инженерия

•          Онлайн-покупки в Интернет

•          Кибершпионаж

•          Использование сторонних облачных сервисов

•          Поддельные антивирусы

•          Фальшивая техподдержка

•          Контрафактное\нелицензионное ПО

•          Подключение к общественной\открытой Wi-Fi сети

2)        Безопасность информации

•          Понятие конфиденциальная информация и конфиденциальность информации

•          Целостность, доступность, конфиденциальность информации

•          Источники конфиденциальной информации. Виды и формы представления конфиденциальной информации

•          Конфиденциальные сведения, подлежащие защите в организации

•          Угрозы безопасности информации

3)        Безопасность мобильных устройств

Угрозы безопасности мобильных устройств

•          Программные угрозы

•          Использование уязвимых мобильных ОС и приложений

•          Web-угрозы

•          Сетевые угрозы

•          Физические угрозы

•          Угрозы мобильных устройств для организации

•          Пользовательские угрозы

•          Угрозы со стороны поставщика услуг

4)        Использование социальных сетей

Угрозы безопасности в социальных сетях

•          Вредоносные приложения

•          Размещение приманок в социальных сетях. Вредоносные ссылки на «стене» других пользователей социальных сетей

•          Фишинговые письма от администраторов и модераторов

•          Указание личных данных и геолокации

•          Взлом вашего профиля в социальной сети

•          Публикация или отправка служебной информации в соц. сети

•          Открытие вредоносных вложенных файлов в сообщениях

•          Сбор ваших личных данных

•          Кража паролей и фишинг

•          Поддельные профили. Добавление друзей

•          Скаммер-технологии

5)         Информирование об инцидентах

Внутренние инциденты ИБ

•          Утечка конфиденциальной информации

•          Неправомерный доступ к информации

•          Удаление информации

•          Компрометация информации

•          Саботаж

•          Мошенничество работников

•          Аномальная сетевая активность

•          Аномальное поведение бизнес приложений

•          Использование активов компании в личных целях или в мошеннических операциях

•          Нарушение физических мер безопасности

•          Сбои, уязвимости и неисправности оборудования или ПО

•          Превышение полномочий. Информирование о противоправном поведении со стороны коллег

Внешние инциденты ИБ

•          Мошенничество в корпоративных системах

•          Атаки DoS/DDoS

•          Перехват и подмена трафика

•          Неправомерное использование корпоративного бренда в сети Интернет

•          Фишинг

•          Размещение конфиденциальной/провокационной информации в сети Интернет

•          Взлом, попытка взлома, сканирование портала компании

•          Сканирование сети, попытка взлома сетевых узлов

•          Вредоносное ПО

•          Компрометация учетных записей

•          Неправомерный доступ к конфиденциальной информации

•          Нежелательные письма (спам, фишинг, ВПО), анонимные письма (письма с угрозами)

Реагирование на инциденты ИБ

•          Правила корпоративной политики по реагированию на инциденты ИБ

•          Кого нужно информировать об инциденте ИБ?

•          Порядок действий при возникновении инцидента ИБ

•          Обсуждение инцидента ИБ только по телефону

•          Обеспечение сохранности доказательств возникновения инцидента ИБ

6)        Безопасность электронной почты

•          Правила работы с корпоративной электронной почтой.

•          Утечка информации, снижение продуктивности работы и ответственность за неправомочное использование корпоративных ресурсов.

•          Электронная почта как инструмент социальной инженерии.

•          Нежелательные сообщения (спам, фишинг, вред. ПО).

•          Куда обращаться в случае обнаружения нежелательного письма?

•          Пересылка информации конфиденциального характера по ошибочному адресату.

•          Использование ящиков электронной почты, созданных на внешних Интернет-ресурсах для ведения рабочей переписки.

7)        Безопасность паролей

•          Парольная политика.

•          Угрозы для паролей.

•          Как придумать простой и надёжный пароль, который легко запомнить

•          Безопасное хранение паролей. Менеджер паролей.

•          Двухфакторная аутентификация.

Спасибо за внимание. До скорых встреч!

Сертификация СУИБ по ISO 27001 новый тренд технологичных стран? (Is the certification of an ISMS according to ISO 27001 the new trend of the technologically advanced countries?)

“Information security is an economics problem” – Bruce Schneier

Недавно узнал, что в Японии существует государственное регулирование в отношении сертификации по ISO 27001 и все организации имеющие контракты с гос. органами - обязаны по умолчанию выстраивать СУИБ по ISO 27001 и подтверждать это сертификацией. Поэтому в Японии больше всего сертификаций по ISO 27001. Слайд из презентации Deloitte (2013 г.) и некоторые другие источники это подтверждают. Также нашёл данные самой ISO, которые указывают на увеличение во всём мире сертифицированных (по ISO 27001) организаций в среднем на 20% в год (стабильная тенденция начиная с 2015 г.). Тут интересно, что Китай с 2016 по 2017 г. нарастил число сертификаций в 2 раза, а США всего в 1,4 раза! Такими темпами в 2018 г. Китай сможет стать лидером по числу сертификаций в регионе и обогнать Японию. Полные данные статистики смотреть тут и тут.

Страны лидеры по кол-ву сертификаций ISO 27001 (за 2017 г.):

Но при этом в глобальном индексе кибербезопасности стран за 2017 г. - Япония дышит в спину России, а наша страна в 10-ке! Но это к слову, этот рейтинг совсем по другим критериям строится.

Всё же вернёмся к ISO 27001:

1) По секторам промышленности:

2) Ежегодные тенденции по лидерам:

3) 2013 г. - 22293 сертификаций:

4) 2015 г. - 27536 сертификаций (+23%):

5) 2016 г. - 33290 сертификаций (+21%)

6) 2017 г. - 39501 сертификаций! (+19%)

А ваша организация стремится соответствовать ISO 27001?

Хорошего дня и спасибо за внимание!

Информационное доверие (Information Assurance)

"Security is a process, not a product" (c) Bruce Schneier

Начну с того, что в своё время оказало на меня огромное влияние (см. название этого блога в заголовке).

Великобритания - родина замечательных стандартов. Например серия ISO 27000 и руководство (как оно себя величает) ITIL корнями ведут происхождение из Великобритании. Вот так и с Information Assurance, зародившейся в уже далёком 1998 году именно в Великобритании! В России оно никак не выделяется в отдельную область, а часто просто входит в ИБ. Но как писал поэт - "Русь, куда ж несешься ты? дай ответ. Не дает ответа..." (с) Гоголь Н.В.

Так вот, Information Assurance, если дословно, - это "Информационное доверие". Эта область родилась вслед за Информационной безопасностью, но ещё до Кибербезопасности:

• Компьютерная безопасность (с 1970-ых), субъект защиты: компьютеры
• Информационная безопасность (с 1980-ых), субъект защиты: информация
• Информационное доверие (конец 1990-ых начало 2000-ых), субъект защиты: информация и сети
• Кибербезопасность (с 2000-ых по настоящее время) - субъект защиты: информация и Бизнес

Области появлялись с течением времени, их история это отдельная тема. Сейчас вернёмся к Информационному доверию. Дисциплина идёт рядом с Информационной безопасностью, но в сущности охватывает более глобально и ИБ и Кибербезопасность (в западной терминологии). Субъектом защиты становится глобально Бизнес и все его активы.

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

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

Найдутся и другие примеры последствий от ущерба нематериальным активам. Кстати стандарт ISO 27005 (процесс Управление рисками информационной безопасности) требует защищать все активы Компании, - и материальные, и нематериальные, при этом предлагая учитывать не просто ущерб, но последствия для Бизнеса в целом. Тоесть, что не противоречит принципам Information Assurance.

Итак, Information Assurance - это не только ценный и критичный актив, который необходимо защищать (как и другие ценные активы Бизнеса), но и одноимённая область, занимающаяся защитой бизнеса в целом и рискоориентированным рентабельным (cost-effective) управлением ИБ в частности.

А вот и определение:
Information Assurance is a multidisciplinary area of study and pro-
fessional activity which aims to protect business by reducing risks associated
with information and information systems by means of a comprehensive and
systematic management of security countermeasures, which is driven by risk
analysis and cost-effectiveness.
IA больше относится к бизнес-уровню и управлению стратегическими рисками для информации и связанных систем, нежели к созданию и применению средств контроля безопасности.
Спасибо за внимание. До скорых встреч!

Всем привет! (Hello, World!)

"Hello, World!" (с) Brian Kernighan

Привет и добро пожаловать!

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

С некоторой периодичностью стал делать для себя открытия и решил, что пора завести блог, начать делиться, надеюсь, полезной информацией с сообществом. Возможно кому-то из уважаемых читателей мои записи будут не такими уж полезными\интересными, но как говорится "Who knows, who knows?"

До скорых встреч!