Архив рубрики: ИБ

Information Security
Информационная безопасность

BCM — термины, примеры disruptions

krestnyy-otec_6981365_orig_

 

 

 

 

 

 

 

 

Этот пост — приложение к основной статье Business Continuity Management — аццкая тема II.

Источников для терминов в области business continuity management (BCM) немало. Вот некоторые из них:

  • Серия стандартов ISO 22300:
    • ISO 22300:2012 Societal security – Terminology,
    • ISO 22301:2012 Societal security – Business continuity management systems – Requirements, —  Можно найти в нете на русском, см. например Гост ISO_22301_2014
    • ISO 22313:2012 Societal security – Business continuity management systems – Guidance,
  • Серия стандартов ISO 27001
  • Словарь терминов и аббревиатур ITIL, текущая версия аж за 2011г.

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

 

Вот что получилось:

    • Непрерывность бизнеса (Business Continuity, BC) — способность организации, в случае инцидента и нарушения ее деятельности, продолжать предоставление услуг и разработку продкутов на установленном примемлемом уровне
    • Управление непрерывностью бизнеса (Business Continuity Management, BCM) — процесс управления, предусматривающий идентификацию потенциальных угроз и их воздействия на деятель­ность организации. Данный процесс повышает устойчивость организации к инцидентам и прерываниям бизнеса, и направлен на реализацию эффективных ответных мер. Результат функционирования процесса обеспечивает защиту интересов ключевых причастных сторон, репутации организации, ее бренда и деятельности, добавляющей цен­ность.
    • План обеспечения непрерывности бизнеса, план BCP (Business Continuity Plan, BCP) — набор документированных процедур и информации, позволяющий, в случае возникновения инцидента или прерывания бизнеса, обеспечить продолжение выполнения организацией критически важных для нее видов деятельности на установленном прием­лемом уровне.
    • Анализ воздействия на бизнес (Business Impact Analysis, BIA) — процесс исследования функционирования бизнеса и последствий воздействия на него разрушающих факторов (факторов, вызывающих прерывание бизнеса).
    • Прерывание, кризисное событие (Disruption) — любой инцидент (нарушение, прерывание, кризис, катастрофа) которые угрожают персоналу, строениям, инфраструктуре или выполнению бизнес-процессов компании, и требующий специальных мер по восстановлению нормального функционирования. См. примеры прерываний бизнес процессов и возникающих при этом потерь в Приложении А (см. в конце страницы)
    • Оценка риска (Risk Assessment, RA) — процесс, охватывающий идентификацию риска, анализ риска и сравнительную оценку риска.
    • Аппетит риска, предпочтительный риск (Risk Appetite) — общая величина риска, который организация готова принять, перенести или действию которого готова подвергнуться в любой момент времени.
    • Тестирование (Exercise / Testing) — процесс проверки (репетиции) сценариев планов непрерывности бизнеса (BCP). Включает в себя обучение, проверку ролей, сценариев, времени и степени восстановления и т.п.
    • MTD (Maximum Tolerable Downtime) — максимально приемлемый период нарушения. Время, по истечении которого неблагоприятные последствия, возникшие в результате необеспечения поставок продукции/услуг или невыполнения деятельности, становятся неприемлемыми.
    • RTO (Recovery Time Objective) — время доступное для восстановления работоспособности систем и ресурсов, необходимых для выполнения критически важных видов деятельности, включая персонал и ИТ сервисы, до нормального уровня;
    • RPO (Recovery Point Objective) — относительная точка во времени (в прошлом), возврат на которую должен быть произведен в случае восстановления системы, иными словами, этот показатель определяет объём данных, представленный в виде временного интервала, утеря которого допустима в случае прерывания деятельности.

Приложение 1. Понятия RTO, RPO и MTDBCP

Приложение 2. Примеры прерываний и рисков

 

 

INTERNAL

              TECHNICAL                                                                      ECONOMIC  

 

EXTERNAL

  • Technology failure
  • IT systems breakdown
  • 􀂃Workplace accident, Fire Contamination or Water flood
  • 􀂃Virus/Malware
  • Industrial accidents
  • 􀂃Utilities / communications failure
  • Natural disasters
  • 􀂃Local/Global crisis
  • 􀂃Supplier failure
  • On site tampering or vandalism
  • Malicious acts
  • 􀂃Organisational failure
  • Epidemy
  • Sabotage
  • 􀂃Terrorism
  • 􀂃Off site product tampering
  • 􀂃Labour action; Strike demonstrations
            PEOPLE                                                                                  SOCIAL

These risks can be resulting in:  

  • Loss or damage to a primary business facilities or service utilities resulting in extended denial of access;
  • Loss of employees;
  • Loss of access to remote or co-located technology services/IT Systems;  
  • Loss of a critical 3rd party supplier/service;  
  • Loss of data/information;
  • Loss of reputation.

Business Continuity Management — аццкая тема

Business_ContinuityНе знаю почему, но BCP тема оказалось какой-то сложной.

Я внедрял ранее уже BCP, и не раз, но как оказалось, мои прошлые внедрения были специализированными, узкими.

Сейчас я изучил (т.е. продолжаю изучать) тему, поднял стандарты ISO 22301\22313, разные статьи в инете. И оказалось что BCP можно заниматься почти с такой же нагрузкой и с таким же объемом, как и ИСО 27001. Существует даже сертификация на ИСО 22301.

Сейчас сижу, копаю практическое различие между RA (Risk Assessment) и BIA (Business Impact Analysis).

PS см. результаты страданий в Business Continuity Management — аццкая тема II.

Конференция SPM Conf — 5

Побывал на конференции SPM Conf — 5, то бишь V Международная конференция в области управления проектами. Смотри тут программу конференции.2015-11-08 17.20.03

Впечатление двоякие. С одной стороны, много людей новых, в докладах проскальзывают классные мысли. С другой стороны, выглядит немного депрессивно. В частности, конференцию сократили с 2х дней до одного. Запланированные тренинги — поотменяли, по причине отсутствия интереса у аудитории.

Качество докладов — в основном средне-низкое. Я довольно резво посещал различные конференции лет 5 назад, так вот с тех пор ничего особо не изменилось. А хотелось бы надеяться, что зрелость индустрии растет, качество и количество экспертов увеличивается, соответственно все это должно отражаться на докладах. Однако, не заметно. Либо проффи просто игнорируют эти конференции (скорее всего так и есть).

Из докладов можно выделить «профессионалов-лекторов» — Орловского, Дернаковского, Безуглого. 2015-11-06 12.49.07

Однако, говорят, что доклад стратоплановца Александра Орловского уже несколько лет не меняется. Но я видел в первый раз, поэтому понравилось:)

Дмитрий Безуглый завел малопонятные беседы про анализ трендов в управлении проектов и про «систему систем». Я мало что понял, наверное не дорос еще.

У Дернаковского Михаила все как обычно — интересненько, живенько, с ролевыми играми. Тема — про коучинг. Все собирался спросить у него, что он думает про высказывания Максима Батырева, который в одной из своих татуировок утверждал, что коучинг — это зло:) Не довелось спросить, а так знатный бы троллинг случился:)

Собственно, я и сам выступал с докладом — про роль информационной безопасности в управлении проектами. Выступил субъективно не очень, сказывается отстутсвие практики в последние годы. Однако тему считаю актуальной, даже если кто и не верит в это:)

Скоро напишу более подробно, а пока — см. презентацию по ссылке.

spm5

 

 

 

 

Уведомления о конфиденциальности в электронной почте — пустая затея

confidentialEmailНедавно перевел статью одного юриста, , опубликовал на хабре — Уведомления о конфиденциальности в электронной почте: не очень хорошая идея. Статья немалая, поэтому привожу тут короткую выжимку, почему же не стоит тратить свои силы на внедрение и поддержание в своей компании так называемого confidentiality notice в подписях к электронным письмам.

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

  1. В уведомлении часто говорится, что «несанкционированному получателю» запрещается рассмотрение или распространение письма. Но получив письмо, откуда я знаю, что не являюсь санкционированным получателем, прежде не прочитав сообщение? :)
  2. И вообще, кем себя возомнил Отправитель, чтобы говорить мне, что разрешено и что запрещено? Какой властью он говорит мне, что делать с письмом, отправленным на мой адрес?
  3. Обычно в письмах с уведомлениями намешана куча мала информации, большинство из которой не является конфиденциальной. А так как подпись с уведомлением добавляется автоматически во все письма, то она просто теряет смысл. Никто не смотрит на нее.

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

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

В заключение, вопрос от одного из комментаторов: имеют ли все эти размышления какое-то отношение к российским реалиям? 
Ответ:  я разговаривал как-то с юристом (правда белорусским, не русским), он сказал, что подобные уведомления на 95% являются психологическим фактором. Однако, оставшиеся 5% потенциально могут помочь на этапах суда, для доказательства факта понимания получателем, что в письме была конфиденциальная информация.

В США в некоторых регуляциях такие уведомления обязательны. Насколько знаю, в области медицины, одно из требований HIPAA.

Итак, не стоит тратить время на внедрение confidentiality notice в письмах:)

Внедрение процессов и практик

Говорить о процессе внедрения процесса — дело не совсем благодарное. С одной стороны, процессы внедряют пачками, непрерывно, всегда это делали и будут делать. С другой стороны, мало кто осознанно это делает, и тем более по какой-либо методике.

Если у меня спрашивают о полноценном внедрении процесса, то я выставляю только один критерий — внедрение должно осуществляться как проект. Ну и как вы понимаете, в проект можно много чего напихать:)

Ниже — идеализированная схема внедрения процесса:
2015-06-16_proc_impl_full

По центру — основные активности, справа дана временная шкала, чтобы можно было сравнить со следующим вариантом. Звездами выделены ключевые вещи.
Итак, что получаем:

  • Если у нас проект, значит нужна рабочая группа, нужен план и прочие аттрибуты проекта. В плане должны быть прописаны KPI процесса, также ключевые цели, которые должны быть достигнуты в процессе внедрения процесса.
    Лет 5 назад я бы сказал, что план — очень важен. Сейчас так не думаю:) План — это заготовка, база, которая должна постоянно корректироваться.
  • Задачи из плана должны полностью замениться бэклогом задач — по результатам совещаний рабочей группы.
  • Рабочая группа — важнейший момент (все самое важное выделено красной звездой). С момента формирования группы и до закрытия проекта, рабочая группа регулярно встречается, и корректирует ход внедрения процесса. Дело в том, что каким бы смарт разработчик процесса не был, он не предскажет и половины проблем, возникающих в процессе внедрения. Для этого нам и нужны постоянные корректировки.
  • Разрабатывается документация (регламент процесса).
  • По результатам работы группы, и созданному ей бэклогу задач — выполняются мероприятия. Например, поиск и внедрение подходящего инструмента. Согласование соприкасающихся процессов и т.п. Тут могут быть целые под-проекты, и просажена куча усилий.
  • Промежуточные аудиты — в основном построены на прописанных KPI (которые кстати тоже сабжект для корректировок при необходимости).
  • Тренинги для целевой аудитории. Обычно вначале выбирается группа хомячков, все обкатывается на них. Потом тренинг проводится на всей целевой группе. В эту группу не обязательно входит вся компания, думаю это понятно.
    Хорошо, если вам нравится проводить тренинги. Ведь это выступление перед людьми:)
  • Экзамен. Лично мое убеждение — без экзамена сотрудник а) несерьезно относится б) при всем желании фигово запоминает и не проникается темой.
    Единственный минус экзаменов — большой геморрой с внедрением системы экзаменации. Это реально большая отдельная тема.
  • Закрытие проекта — с отчетом, с анализом ошибок.

Это была идеальная картинка (думаю многие смогут еще ее доидеалить, чтобы в космос полететь).

А в жизни в 95% случаях происходит все вот так:
2015-06-16_proc_impl_basic

Т.е., на основе анализа разрабатывается некий документ, который спускается на компанию. Далее, в зависимости от пожеланий бизнеса, процесс может докручиваться, возможно даже с использованием аудитов. Но частенько процесс на бумаге становится неактуальным через 15 минут после публикации, и дальше начинается параллельная жизнь бумажного и реального тигров.
Но обратите внимание на график работ — на такое вот минимальное внедрение потребуется в 3 раза меньше времени.

Какие выводы? Я понимаю, что идеальную схему внедрения нам доведется исполнить в жизни раз 6. Разве что вы работаете в NASA или атомной энергетике.
Поэтому рекомендую отталкиваться от базового варианта, с привнесением компонентов из полного варианта, по ситуации.

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

Удачи всем нам с внедрением процессов!

PS в статье я делаю допущения по поводу процессов — не углубляюсь в область управления процессом, упоминаю только про KPI процесса, не даю определения и прочее.

О создании культуры компании

2015_05_culture-is-built-not-bought-fiВначале, что такое культура компании?

Считаю что можно говорить о культуре чего-либо в компании, когда сотрудники шутят на тему этого «чего-либо» и подкалывают друг друга.

Например, культура компании в области ИБ, это когда:

  • при входе коллеги без бейджа в периметр, другой коллега искренне удивляется — «ты кто такой?».  Хотя он за соседним столом сидит, и квас вместе пьют.
  • за кофе ПМы подкалывают друг друга за разглашение информации о клиенте,  «мужик, держи изоленту» (см ниже картинку)

Вырисовалась эффективная схема по построению так называемой культуры ИБ:

  1. Прорабатывается тема, например — список сведений, составляющих коммерческую тайну компании
  2. В регулярных новостях компании (например в еженедельных письмах всем сотрудникам) делается краткий анонс об этом. Завуалировано, с интригой, типа скоро будет что-то прикольное
  3. Не тормозя, публикуется документ (в нашем случае перечень коммерческой тайны), и сопроводительное письмо к нему.
  4. В этом письме — краткий пересказ документа, без фанатизма, чтобы человек смог прочитать за 30 сек, и (! бинго) — в конце письма комикс по теме!
2015_05_isolenta

Комикс к публикации документа «Сведения, составляющие коммерческую тайну». Создано by Varvara Petrova:)

Вообще, убежден, что юмор — одна из основ для здоровой культуры компании:)

Некоторые шутки превращаются в истории, которые старожилы рассказывают новичкам. Не это ли культура компании?

2015-05_company-culture-cartoon

 

IT-Security Conference, первая в РБ

Первая конференция «Технологии защиты информации и информационная безопасность организаций»

Первая конференция «Технологии защиты информации и информационная безопасность организаций»

Посетил так называемую первую в Республике Беларусь конференцию «Технологии защиты информации и информационная безопасность организаций» («IT-Security Conference»).

Общая оценка — классно для первого раза.

Очень рад что в РБ появляются события такого порядка и такой тематики.

 

Несколько запомнившихся моментов:
  • выступление Прозорова. Тема — про законодательные движения в области ИБ в России. Не совсем релевантно для РБ, но зато интересно (по сравнению со многими и многими презентациями).
  • технари из PaloAlto, рассказали про технические решения по предотвращению кибер-атак. Было интересно, познавательно и нескучно.
  • презентация про FireEye (Ясинский А.) порадовала — много практики
  • Хайретдинов Р. из InfoWatch — рассказал про антикризисную ИБ. По сути — набор принципов из жизни безопасника. Видно что товарищ древний практик.
  • Ожегов из SearchInform — показал как можно накрыть сотрудника через прокачанную DLP. Контролируется все и вся. В конце вывел критерий успешности работы DLP — основанный на % уволенных за нарушения сотрудников. Жесть однако:-\
Организаторы обещают выложить все материалы чуть попозже, я обновлю пост когда появится ссылка.
Из плюсов  — коммуникации коммуникации. Мир посмотреть, про себя рассказать. Прекрасная площадка для знакомств.
Из минусов — не очень хорошее место для конференции — кроме главного зала, все было неудобно. С питанием было не очень. Еще специфическая черта — в основном были специалисты, не было клиентов. Но лично меня это вполне устраивает.
Напоследок — было несколько спикеров, читающих с листка. Ребята, лучше бы не позорились, это же неслушабельно и только вызывает негатив.

 

Мы с Андреем Прозоровым

Мы с Андреем Прозоровым

Однако, закончу позитивом —  для меня было очень приятно познакомиться лично с Андреем Прозоровым, специалистом по ИБ, известным блоггером (Жизнь 80 на 20).

 

В общем и целом, тема ИБ в РБ развивается, что не может не радовать:)

 

Первые шаги с ISO 27001: initial audit and risk assessment

Одни из первых вопросов, с которыми сталкиваешься при внедрении СУИБ по ISO 27001:

  1. Какие из 114 защитных мер, перечисленных в ISO 27002, требуется внедрять
  2. и в какой мере требуется внедрять каждую из выбранных защитных мер

Попробуем разобраться.

Что внедряем

В 27001, в пункте 6.1.3 b) говорится: determine all controls that are necessary to implement the information security risk treatment option(s) chosen.

И далее, d) …  and the justification for exclusions of controls from Annex A;

Таким образом, выбирать то требуется только необходимые защитные меры, но если вдруг не выбрал, изволь обосновать.

Из своей практики замечу, что иногда обосновывать исключение той или иной защитной меры сложнее, чем осуществить некое минимальное внедрение этой меры.

Ок, зная теперь, что лучше все же попытаться внедрить максимальное количество защитных мер, описанных в 27002, ответим на вопрос — в какой мере внедрять. Ведь если внедрять все рекомендации 27002 — любая компания разорится.

Как внедряем

Идея стандарта в том, чтобы на основании Risk assessmenta и Risk treatment получить Risk treatment plan (RTP), содержащий детальные инструкции по внедрению конкретных защитных мер для конкретной компании.

Я лишь хочу привнести практический аспект — проведение первоначального аудита перед Risk assessment. Цель аудита в том, чтобы дать реальное знание о ситуации с защитными мерами в компании на данный момент. Иначе придется делать Risk assessment в теоритическом вакууме.

Процесс получения желанного RTP

Процесс получения желанного RTP

 

 

Что на картинке.

Шаг 1й — аудит. Делается на основании заранее подготовленных чеклистов, по защитным мерам 27002 и основным положениям 27001. В результате получаем оценку внедренности защитных мер — см % под AS IS. Также, что очень классно, прямо в ходе аудита выясняются очевидные ляпы, которые тут же вносятся в оперативные планы ответственных команд. Таким образом, весь проект по внедрению СУИБ (ISMS) набирает ускорение.

Шаг 2й — Risk assessment. Делаем risk assessment, как правило по классике (см 27005). На выходе получаем отранжированный список рисков.

Шаг 3й Risk treatment. RA особо не отделишь от RT. Насколько знаю, большинство делают шаги 2 и 3 одновременно, доводя риски до логической развязки (treatment). Естественно, большинство рисков закрываются соответствующими защитными мерами. И вот тут то уже становится понятно, какую защитную меру нужно выводить на максимальный уровень внедренности (для критических рисков), а какие меры — лишь с минимальным внедрением (для закрытия некритических рисков).

Получаем приблизительный % «требуемого уровня внедрения» — см цифры под колонкой TO BE.

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

Все эти активности аккуратно вписываем напротив соответствующей защитной меры, и получаем Risk treatment plan.

 

Семинар Increasing Business Effectiveness of IT Companies through Risk Management and Certification Standard

Посетил семинар “Повышение эффективности ИТ компаний с помощью риск менеджмента и сертификации”, 10&11 июля, организатор — Европейский Банк Реконструкции и Развития.

Ниже — краткая сводка.
Читать далее

Информационная безопасность в Cobit 5

Вышел Cobit 5. Вообще, это мощное событие на ИТ рынке. Консультанты, специалисты по ИТ практикам, по ИБ — все должны ознакомиться с сим творением:)
Так как я являюсь членом ISACA, то базовый набор документации Cobit 5 мне достался бесплатно.
Что интересно, за отдельный гайд «COBIT 5 for Information Security» нужно платить даже члену ISACA. Ну, деньги небольшие (что-то около 35$), нужно купить.

Пока же я сделал краткий обзор по Cobit 5 — по новой структуре, принципам, содержанию процессной карты — все в разрезе ИБ.

Эту презентацию я сегодня представил на семинаре Инфопарка.
Основной аудиторией были ИТ менежмент с локальных организаций — банков, предприятий. По отклику понял, что несмотря на ‘У Cobita 5 большое будущее’ — на локальном (белорусском) рынке путь Cobit 5 будет долгим и тернистым:-)