5 проблем управления информационной безопасностью на основе оценки рисков

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

1. Это удивительно, но до недавнего времени ведущие практики, и исо27тыщ не исключение, предлагали разбирать всю область на т.н. активы, для каждого выявлять уязвимости и оценивать последствия/вероятности их использования – это, типа, и есть риски. Фигурально говоря, берем автомобиль и давай его декомпозировать на партнамберы: вот шпилька ступицы, есть опасность сломать, шансы самопроизвольного выпадения небольшие, перегореть не может, подмена неизвестным злоумышленником на неоригинальную маловероятна, а вот шина, вероятность прокола большая, и сверхнормативного износа тоже большая, и еще кражи тоже, но хоть коррозии нулевая; а вот бензонасос... и так до конца каталога. Очевидная проблема: вся эта огромная матрица принимать реальные решения (обгонять / не обгонять, страховать / не страховать, дополнительная противоугонка / сойдет заводская, ТО у официала / да ну его) не помогает потом совершенно. Ну, может, не совершенно, но обычная обывательская рассуждалка дает результаты точно не хуже.
Так что вот такая вот засада: системный подход работает, но "низенько-низенько" (хотите – убеждайтесь сами, года два-три на это уходит), а бессистемный – шаманство. Есть там всякие хинты (какие-то риски можно найти, определив цели и анализируя причины, влияющие на их недостижение, какие-то спрогнозировать из ожидаемой модели поведения нарушителей, какие-то взять с потолка ужасно мозговым штурмом и т.п.), но все же свободное творчество, сильно зависящее от мастерства и интуиции.

2. Ментальная ловушка безопасника – определить защищаемую информацию (или даже рассортировать каким-то образом) и назвать нарушения ее свойств рисками. А это не риски! Смотрите, события обычно собираются в цепочку: «Не стоят последние патчи» - «И что?» - «Может произойти ознакомление с персданными к ним не допущенных» - «Оно у нас каждый час происходит в той или иной форме, и что?» - «А субъект, если узнает, может нажаловаться» - «И что?» - «И придет проверка» - «И что?» - «И найдет нарушения» - «И что?» - «И мы не сможем их устранить в ходе проверки» - «И что?» - «И нам выпишут предписание» - «И что?» - «И мы его почему-то не выполним» - «Странно, и что?» - «И нам присудят штраф». Вот где здесь рисковое событие для организации? Его здесь вообще нет, пожалуй, оно на следующем шаге («И нам не хватит денег заплатить аренду»). А разглашение персданных – это не риск, а возможная причина причины причины причины возникновения, да вдобавок только одна из.
Цепочка может ветвиться. Например, от предписания может отходить ветка «и опубликует на сайте, что мы нарушаем», упирающаяся в падение имиджа и отток клиентов. Или, например, от проверки ответвляется «и заметит использование радиодиапазона без разрешительных документов». Или нарушение может сразу пойти в прокуратуру для принятия мер реагирования. В таких случаях тут несколько рисков напрашивается, но все равно не заключающихся в разглашении персданных, а связанных с.

3. Смысл всей возни с рисками – в их оценивании, оно нужно для принятия решений: этот слишком мал, чтобы вкладываться в противодействие, а этот так велик, что заберем деньги из договора на проведение работ по охране труда. Это только в легенде безопасности много не бывает, реальная организация всегда вынуждена делать какой-то выбор. Чтобы сравнивать риски, нужно, чтобы они были посчитаны (в одинаковых единицах), и считаются они произведением ущерба на вероятность наступления. С ущербом все не так плохо: чаще всего просто есть вариативность (коньяк vs штраф, потеря единичных клиентов vs массовая и пр.), и это всего лишь надо рассматривать как разные рисковые сценарии, а сами-то последствия вообразимы.
С вероятностью хуже. Даже если у вас или у соседа есть статистика подобных событий в прошлом (каковая далеко не по всем рискам есть), ее обычно нельзя взять «в лоб». Скажем, в мире отмечено 100 прецедентов Stuxnet, но это не в год, а всего, и чтобы прикинуть на следующий год, это уже надо что-то вычесть и разделить, и это что-то в доступных источниках отсутствует. Опять же, это не равномерно по миру, а тяготеет к одному региону, и для «в среднем» надо какой-то поправочный коэффициент взять – какой? Но учетом последней антироссийской волны Россия – тоже не средняя, и это еще один поправочный коэффициент надо как-то экспертным путем… А сколько событий вообще прежде не происходило! Представьте, что какой-то год назад Вас бы просили оценить вероятность введения вайфая по паспортам – прикидываете разброс в оценках? Беда в том, что приблизительно оцененный риск будет сравниваться – с другими вашими рисками, с рисками, поданными другими подразделениями, и погрешность принятых на основе этого решений «мама дорогая».

4. Но предстоит оценивать еще и остаточный риск – риск после принятия контрмеры (направленной на какую-то из причин или причин причин). Часто это происходит уже и при первичной оценке, чтобы сказать, достаточно ли такой контрмеры, как предложена, а при периодической переоценке всегда. И тут недостоверность возрастает еще больше.
Знаете, на сколько (цифра!) упадет вероятность НСД от разработки правил и процедур ограничения программной среды или от сбора и хранения информации о событиях безопасности в течение установленного времени хранения? Точно знаете? Попробуйте только сказать, что не знаете, и ни в жизнь не пропихнете меру, не обоснованную с точки зрения оценки рисков. Можно отмазаться и заявить, что это не совсем мера, а условие работы другой меры (например, обнаружение инцидентов и принятие мер по предотвращению повторного возникновения), но тогда ее влияние на вероятность будущих НСД оцените-ка.

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

А так остальное легко. Я, правда, иной раз задумываюсь, а есть ли остальное-то, но как посмотришь очередную презентацию – до фига.

"Англия сдалась!"

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

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

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

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

Дальше надо было примерить к каждому элементу каждую возможную угрозу и назвать величину наступающего в этом случае ущерба (желательно в деньгах), а также шансы того, что он произойдет. В этом виделась потрясающая наукообразность. Детали-то ведь все разные, и это правильно учитывать, что подшипник передней ступицы вряд-ли снимут гайцы, но он способен треснуть, а тосол склонен вытекать или выкипать, а шильдики могут пионерить. Итого, когда на двести, скажем, элементов пяти, например, классов ценности наложить триста угроз от семи типов источников с четырьмя показателями легкости реализации, и для каждой не лишенной смысла комбинации (ибо такие несуразицы как короткое замыкание в шине надо вычеркивать) назвать ущерб и вероятность – это же ого-го! «Ну, а теперь со всей этой красотой мы попробуем взлететь».

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

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

Победа разума? Вряд-ли. Потому что одновременно сделаны необязательными «контроли» из Аннекс А (т.е. 27002, он же 17799, он же 7799-1), и контрмеры можно теперь брать откуда угодно – скажем, из Базеля. Складывая это с либерализацией в оценке рисков, резонно заключить, что ИСО теряет рынок и хочет найти клиентов среди придерживающихся прежде бывших несовместимыми методик.

«Какие стандарты нам нужны и зачем?»

Ходил на оный диспут в рамках INFOBEZ. Велик был соблазн воспользоваться чуть не 20-летним опытом по эту сторону рынка и просто констатировать, что хорошо тут без них ныне и присно, но все же соорудил некую объяснялку.

Когда юриста спрашивают, как поступить в таком-то деле, он уточняет: "Если я на стороне кого?". Вот и поднимая тему, какие стандарты нам нужны, прежде всего нужно определить, мы – кто?

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

А вот физику, потребителю сами по себе стандарты безопасности не нужны – ему нужны гарантии безопасности, ее подтверждения, свидетельства. Когда продукт или услуга, которую он покупает (или получает бесплатно, это ведь может быть и государственная услуга), соответствует какому-то стандарту, то это, конечно, некие дополнительные очки в ее пользу, дополнительный повод на то решиться или выбрать Х, а не Y. Но это очень слабые очки! Примерно на уровне медалек, которые на этикетках рисуют. Любые предубеждения их перебивают, любые сообщения об инцидентах, слухи, советы друзей. Если человек будет покупать автомобиль, то ГОСТа "№ какой-то там" не будет в десятке – в десятке будут характеристики, результаты независимых тестов, сравнения в журналах, имидж бренда, опыт соседей и т.д. – вот чему он доверится за свои кровные. Причины можно искать, но факт: сейчас репутация товара/услуги или их производителя в исчезающе малой степени обеспечивается соответствием стандарту.

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

Я когда слышу, что кто-то нахваливает стандарт, всегда очень интересно понять, в качестве чего. Ибо ситуация, знаете, примерно какая: "Джинсы - такая замечательная одежда: я из них классные прихваточки шью!". А причем тут одежда, это мог быть рулон ткани с таким же успехом.
Когда кому-то не хватает знаний, то для него стандарт шпаргалка какая-то, источник терминологии непротиворечивой, свод мудрых советов, многие из которых полезны. Но тут, по-моему, если стандарты восполняют собой нехватку нормальных учебников, то нужно больше учебников, а не больше стандартов. (Кстати, надо сказать, бывает, что это сами стандарты такие – когда по сути это методология, а для продвижения выдает себя за стандарт, маскируется. Там попросту нечего выполнять: вода и квадратики красивые со стрелочками.)

А вот в корпоративном секторе распространенный вариант – это стандарт в роли входного билета. Некий набор обязательных действий, чтобы войти в какой-то клуб. Как в примере с платежными системами. Но это же не выбор организации, она бы с удовольствием не покупала этот билет, если бы можно было не покупать. Потому что в нем нет конкурентного преимущества, когда это у всех, кто продает однотипные с тобой продукты или услуги.
Или встречается стандарт как недостающее обоснование, когда ИБ не смогло убедить руководство через риски, и поэтому аппелирует к какому-то стандарту – но это же подмена целей стандарта опять-таки.
Стандарт, по сути своей – это механизм преодоления проблемы разнообразия: "под одну гребенку", "как инкубаторские" и т.п. Кому это нужно, разве кто-то любит быть одинаковым? Вот он и нужен не тому, в отношении кого его применяют, а тому, кто применяет. Не когда оно на тебя сверху, а когда ты его вниз. Это очень удобно управлять однотипным. Поэтому в организации пишем стандарт (или заимствуем готовый) и по нему строим в шеренги то, что под нами - маршрутизаторы, домены, филиалы.
Плюс легче взаимодействовать с партнерами, когда общая система терминов, форматы обмена (инцидентами, например). Но есть загвоздка: стандартов-то слишком много. Если один придерживается 53647, а другой 34-ой серии ГОСТ, поговорить им будет нечем – там только буквы алфавита совпадают.

И, конечно, вузовский стандарт на подготовку по специальности – есть такая тема. Но там большой подводный камень: сначала нужно решить, потребность в образованных или в обученных. Узкие знания сейчас устаревают очень быстро – может и не должны в ВУЗах давать, что на работе за месяц дадут.

В общем, сколько я перебирал – нашел добровольное применение только внутренним стандартам и на взаимодействие. А принудить нас сами принудят.

И бонус для тех, кто все это слышал – чуть другой вариант ответа про 27001.
Пришел молодой адепт к гуру: "Можешь научить меня воспламенять бумагу одним взглядом?". "Могу, но это довольно сложная практика: там 5 лет в позе лотоса, 60000 повторений мантры и все такое". "Я готов, учитель, начинай же скорее!". "Ну, хорошо. Но дурак ты - спички же существуют".
27001 – настолько хороший стандарт, что достоинств больше, чем недостатков. Но эффекты, которые наступят, можно получить и без него.

Не все то золото, что стандарт

Стандарты у западопоклонников в особой чести: если нечто скреплено магическими буквами и цифрами, оно заведомо хорошо всем и вчетверо превосходит отечественные потуги, что уверенно округляется до двух порядков. ФирмА, че уж там! Хвалить их принято в режиме реального времени – одновременно с чтением. То есть не так чтобы изучил, дал улечься и выразил, а тырнул фразу через буфер и прямо на ходу ей восхитился, а за ней сразу другую тоже. Акын-стайл.

Приключилось тут опять воспользоваться ISO 27005 – ну капец ведь.

2700х – это система, комплекс. Нестройный, но славный 27001 отправляет выбирать меры из 27002 на основе анализа рисков (для краткости не буду перечислять идентификацию, анализ, измерение, оценку – здесь и далее просто анализ), а тот находится в 27005 как раз. Т.е. в пятерке мы имеем дело не с анализом риском вообще, а с типичным анализом рисков на предмет. Ну, отлично – заглядываем в его собрата по исо27тыщ, чем же нам в конечном итоге предлагается защищаться.

И вот тут жесть. Потому что анализ рисков, он ведь у них устроен как: переписываем свои активы типа софт, железо, помещения, материальные носители, etc. и оцениваем их критичность с точки зрения последствий, потом пересекаем с угрозами, для которых определяем вероятность возникновения и легкость реализации (степень неуязвимости каждого актива к каждой угрозе, если так понятнее), и наконец все перемножаем к чертям собачьим.

Так вот это пересечение уже предопределило, что риски получатся вида «повреждение водой дела №21-01-8К», «программный сбой межсетевого экрана» и «недоступность серверной для обслуживающего персонала». Оно-то хорошо, но Вы как потом из этого получите, что в организации должны быть вовлеченность руководства, обработка инцидентов или обучение по проблемам информбезопасности? Или даже интереснее - что чего-то из них не должно быть. Правильно, притягиванием. Нет ничего невозможного для человека с интеллектом.

Да только длина логической цепочки такова, что оценка теряет смысл. «Мы не можем мириться с риском ошибки оператора 22, поэтому [бла-бла-бла-бла-бла] с помощью внутреннего форума по информационной безопасности, который в силу [бла-бла-бла-бла-бла] снизит наш риск до 19». А почему бы тогда не до 17 или не с помощью тестирования аварийных процедур? Что толку, что Вы героическими усилиями 22 насчитали, если потом все равно вот этот бубен «бла-бла-бла-бла-бла 11,63»?

Как бы это на пальцах… Что-то вроде: «возьмите буковую разделочную доску, измерьте площадь рабочей поверхности половника (не ошибитесь!) и сварите борщ». Инструментарий Вам дают один, а результат хотят другой, почти не связанный.

Есть, конечно, «контроли» и с совсем четкой цепочкой риск – контрмера – остаточный риск (среди ста с хреном штук еще бы им не быть!), да сам механизм длинными уже дискредитирован. Что толку, что вот конкретно здесь Вы совершенно точно намерили 9, если рядом так посмотришь – вроде 3, а так – все 42.

Или вот тоже смешно. Какие-то защитные меры в организации могут быть уже внедрены – так пятерка советует их предварительно идентифицировать, чтобы потом не предложить в качестве меры по управлению риском то, что и так есть. Это знаете для кого рекомендация? Для консалтера, который первый и последний раз эту СМИБ видит. От консалтера, который так их и видел.

В жизни 27005 тут сработает по-другому: имеющаяся контрмера «просадит» соответствующие угрозы – Вы когда будете опрашивать экспертов, Вам их дадут за вычетом. Скажем, все привыкли, что система усиленной аутентификации усиленно аутентифицирует, и по НСД оценки будут спокойные. А потом придет аудитор исошный и спросит: «А вот у вас система усиленной аутентификации – она как из анализа рисков следует?». А она и не следует. А по исо27тыщ меры должны быть оправданы – надо выключать. Выключили – на следующий год вылез риск – включили – исчез риск – выключили – на следующий год вылез риск... Замечательная мигалка DIY, можете попробовать, главное буквально следовать.

И ведь 70 страниц на это накручено. И ведь кто-то с душой переводит.

"Р" значит ...?

Прочитал радость Алексея Лукацкого по поводу разработки ГОСТ Р 5311х и адаптации ГОСТ Р ИСО/МЭК 2700х и вспомнил, как последний раз заглядывал в русский 27005 по казенной надобности. Было страшно.

Ну-ка, профи, попробуйте догадаться, что это:
1. преступное использование аппаратных средств;
2. владение, например, штат организации;
3. недостаточное осознание безопасности;
4. компрометирующие сигналы помех;
и только потом посмотреть в оригинал или в первый камент.

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

Стоит ли после этого удивляться, что в России так странно мало сертифицированных на тот же 27001?

Годные литераторы из НИИ "СОКБ"

За чаем взялся почитать проект ГОСТ Р ИСО/МЭК 27003, ссылка на который мелькнула в твиттере Алексея Лукацкого.

Цели внедрения СМИБ можно определить, ответив на следующие вопросы:

• как может СМИБ улучшить управление рисками информационной безопасности?
• как может СМИБ улучшить управление информационной безопасностью?
• как может СМИБ создать конкурентные преимущества для организации?

Чтобы ответить на эти вопросы, необходимо рассмотреть приоритеты и требования организации на основе следующих факторов:

• ...
• законы, делающие обаятельным принятие мер информационной безопасности

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

Десять ключей к сертификации по ISO 27001

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

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

2. Не перегружайте себя информацией - достаточно самих 27тыщ, это и так нехилый объем (и к ним потом 19011, и еще пару раз отправят подглядеть в 18044 и 13335). Чем больше будет вроде бы родственных источников, тем больше все будет только запутываться.

3. Если многократное перечитывание пункта не дает понимания, поищите параллель в 9тыщах (например, инциденты - несоответствующая продукция), они хорошо проработаны. Да, это помогает только с управленческими вопросами, но с техническими Вы и так разберетесь.

4. Не думайте, что при ограниченности в деньгах, времени, иных ресурсах, можно сертифицировать не всю организацию, а любую ее часть. Можно, но не любую.
Чтобы смочь обосновать выбор области сертификации, продемонстрировать связь с бизнесом, отстоять свою оценку рисков и т.п., нужно ИБшить то, что для организации является одним из источников дохода - производство продукта или сервиса (группы продуктов или сервисов). В отсутствие коммерческой деятельности, сгодится безвозмездная услуга, а в отсутствие внешних клиентов - внутренняя, но все равно нечто с потребителями, и чем оно для организации важнее, тем лучше.
В область действия придется взять всех, кто принимает участие в ИБ этой услуги - если обучением занимается работник кадровой службы, скажем, то его тоже. Поэтому когда говорят, что некто сертифицировал сервис-деск, знайте: речь не о подразделении с таким названием, а об услуге сервис-деска.
Очерченные границы будут проверяться и должны быть материальными - либо толстая воздушная прослойка (между питерским офисом, в котором находится часть процессов, и идущим на сертификацию пермским датацентром / казанским отделением / уфимским филиалом), либо заглушка в виде договора ("А это другая услуга, мы получаем ее от телефонистов - вот регламент и внутренний SLA").
Наибольшая экономия ресурсов будет на количестве людей, подготавливаемых к встрече с аудиторами, небольшая на стоимости услуг аудиторов, на документировании незначительная.

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

6. Те же документальные следы четырех фаз, что и для СМИБа в целом, нужны для каждого "контрола": установление правил и порядка (в политиках и процедурах), свидетельства функционирования (журналы), свидетельства проверки (отчеты внутреннего аудита), свидетельства устранения несоответствий между регламентацией и реализацией (карточки внесения изменений или превентивных/корректирующих мер), далее по кругу.

7. В первую очередь запускайте главное колесо: политика ИБ организации и заявление руководства (в эту политику обычно и включают упоминание области действия СМИБ, отвечающей 27 тыщам), положение об управляющем органе СМИБа и все остальные параграфы из бывшей второй части, которая теперь 27001. Ибо пробелы в реализации 27001 - это "мейджоры", т.е. недостатки, несовместимые с сертификацией, а пробелы в реализации 27002 и других 2700х (кроме пунктов, совпадающих с 27001) - это просто несоответствия, которые, если их не бешеные десятки, будете устранять уже после благополучного получения сертификата.

8. Все потребные аудиторам документы, кроме почему-то Положения о применимости, упомянуты в 27001 и 27002 - просто обращайте внимания на слова documented, established, written и formal (и это еще один аргумент в пользу оригинала, т.к. в русском варианте на этом месте может стоять что угодно - от "актировка" до "самовар").

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

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

з.ы. Ну и да, стандарт где-нибудь раздобудьте ;)

Лечился по справочнику – умер от опечатки

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

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

Так их прямо и учат: все будет хорошо, если политика понятная и до всех доведена, а если нет, то ховайся – ничего в этой конторе не выйдет.
Многие верят и очень на эту тему усираются.

Вы ведь правда не прочли "понятна & доведена" как "все будут знать & выполнять"?
Об этом я обычно и сообщаю.
Следуют напряженная работа памяти и "Не-е-ет, это она все-таки непонятно написана! А надлежащим образом ведь не доведена, а должна же быть доведена же!".
Потому что так в книге.

Ребята, в книгах иной раз пропущено то, что дети в саду знают.
Цифры от балды, исследований мне таких не заказывали, у кого внутреннее ощущение иное, пишет альтернативные на бумажке. Минусуем:
- 8 % блатных и/или неуловимых, за которых закорючку кто-то поставил;
- 12 %, которые ничего не поняли, несмотря на доступность ежу, в т.ч. 9 % сделавших вид, что поняли;
- 14 % сделавших вид, что читают;
- 23 %, которые усвоили, но соблюдать не будут из лени;
- 7 %, которые усвоили, но соблюдать не будут злонамеренно;
- 16%, которые все поняли, глубоко согласны, но тут же забыли;
и остаются 20%, которые забывать будут плавно, но уверенно.

Вот и выходит, что даже у самой лучшей-прелучшей политики (ежовая понятность и поголовное доведение) пиковый КПД хуже паровой машины.

Что с этим делать? Для начала – жить дальше.
Если в используемой книжке помимо политики есть и другие "контролы", их реализация эти минусовые группы подтянет: кто-то что-то доберет через демонстрацию приверженности руководства, кто-то при обучении, кто-то при внутреннем аудите, кто-то при санкциях за нарушения и т.п.
В принципе, все это должно дать какой-то приемлемый уровень знания, дальше уже каждый процент в каждой группе за отдельные деньги, если хочется.
И в одиночку ни одна из мер не панацея – ее можно точно так же по минусам расписать. Приверженность руководства? А злодеев никто не отменял. Экзамен? Я вон в пятницу очередную охрану труда сдал, к субботе уже ничего не помнил.

В-общем, не воспринимайте книжки слишком серьезно - отдаляет от реальности.

з.ы. Можно ли пруфлинк про детский сад? Можно.

Паралогизм ЗИшника

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

Диалог:
- Т.е. соответствие какому-нибудь стандарту, тому же исо27тыщ, например, не гарантирует отсутствия незапатченного сервера или роутера с дефолтным паролем?
- Ну, во-первых, аудиторы могут что-то и проморгать, особенно если инфраструктура большая. А во-вторых, обнаружения подобной уязвимости действительно недостаточно, чтобы не выдать или не продлить сертификат - major'ным (несовместимым с сертификацией) несоответствие будет только если патч- или пассворд-менеджмент вообще не регулируется, не выполняется или не контролируется. Так что, теоретически, да - не гарантирует.
- Тогда никакой разницы, кому свою тайну доверить - что у тех утечет, что у этих - от сертификата польза чисто маркетинговая.

Или такой вариант:
- AWS сертифицирован по исо27тыщ, а инцидент тем не менее произошел - где же эффект от соответствия стандарту? А просто оно снижает вероятность инцидентов и, поэтому, демонстрируемые в отчетах риски, но не более.

В чем логическая ошибка? В подмене предмета. В переносе фокуса с субъекта или обладателя информации (или иного заинтересованного лица) на собственно информацию, оценке события для нее, а не для него, порождающей ЗИшное умозаключение вместо ИБшного.

Между тем, пробой защищенности информации не означает равного снижения защищенности оунера/стейкхолдера.
Если организация сертифицировалась по исо27тыщ, то у нее есть коллегия по ИБ, налажен процесс отработки инцидентов, коммуникации с партнерами и органами, извлечения и внедрения уроков, отслеживания выполнения, наказания нарушителей, восстановления работы и т.п.
Поэтому даже при одинаковом нарушении КДЦ информации, последствия для пострадавшего могут отличаться по размеру или долговременности.

Вот для информации действительно все равно - она не живая (грубый отсыл к посту "Есть ли у информации интересы?").

з.ы. Следующий пост будет коротким, ибо нефиг.

ИБ и НБ: это зависит

Если на расхожий вопрос нет расхожего ответа, то ответом является "это зависит" (а до меня этого никто не говорил?).

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

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

Максимум, подразделение ИБ может строить и сопровождать систему управления непрерывностью. В этом есть смысл, если ИБ использует систему менеджмента, родственную той, на которой будет делаться НБ - например, если НБ строится по стандарту Банка России, т.е. переведенному с русского на русский (за немаленькие деньги?) ГОСТ 53647−2009, а ИБ исо27тыщ-базированная, то это два симметричных побега ISO 9001.
Если в организации есть несколько родственников будущей СУНБ (скажем, есть еще сама 9001 в отделе качества, 14001 в охране труда и т.п.), то пальма должна достаться более развитому и влиятельному.
При этом переквалифицировавшиеся в непрерывники все равно столкнутся с новыми для себя проблемами - элементами, отсутствующими в их родной системе, и справятся ли они - это вопрос упорства и таланта. В случае ИБ сложным окажется BIA (не знаю устоявшейся русской аббревиатуры) - и в силу ментальной привычки к вероятностной оценке, и из-за необходимости понять устройство основного бизнеса. Больших усилий, чем прежде, потребует и анализ рисков.

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

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

Если вопрос НБ наполнен для Вас практическим смыслом, то начинать надо не с размышления, куда бы устроить подразделение ИБ, а с поиска наилучшего кандидата на разработку BIA. Потом RA. Потом само видно будет.

Тонкая работа (Перманентный ремонт - 4)

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

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

То, чего хочет исо27тыщ, говоря о непрерывном улучшении, это рацухи. Встретился с парой инцидентов, вероятность которых считал низкой - поправь оценочку соответствующего риска (и если вышел за порог приемлемости, то допиши в план обработки контрмеру), не смог наказать внутреннего нарушителя из-за изъяна в формулировке запрета – уточни эту формулировку и т.п.
Плюсы понятны (особенно если читал про патч-менеджмент в стилях вестерн и ориент): необходимые улучшения не откладываются до второго квартала следующего года, когда мы может быть соберемся пересоздавать такой-то процесс и там учтем все накопившиеся пожелания, а инициируются сразу.

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

Если говорить о примере с документацией, то тем и плоха российская традиция писать все в один большой документ и вводить через приказ (чтобы ни одна сволочь не посмела даже на секунду усомниться). Как оперативно удастся поменять пункты в списке 3 приложения 7, если понадобится? А если через неделю опять понадобится?
Вот и пишутся маленькие документы, сегментированные по уровню принятия и целевой аудитории, когда руководство возглашает свою политику в такой-то области и уполномочивает внедренца, тот создает регламент для вовлеченных подразделений, а уж те пишут инструкции своим работникам.

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

Как метафора - анекдот про мерседес и пепельницу.

Соответствие изменчивого или перманентный ремонт - 3

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

В первом варианте проверяется результат, продукт. До этого человечество додумалось давно и даже удовлетворялось одно время. Подход примерно такой: врезались в батарею отопления, замерили напор и температуру, выдали справку.
Ясно, что состояние в момент проверки – это состояние в момент проверки, и обычное состояние или состояние по прошествии какого-то времени могут от него отличаться, поэтому вариант хорош в коматозных системах (со штампованной продукцией) и плох в живых. Достоверность можно чуть приподнять увеличением выборки и/или повторным тестом, но дальше все равно упираешься в ограничения самого метода.

Когда все меняется чаще, чем проверяется, нужен какой-то выход. Хорош постоянный мониторинг, но чаще всего неподъемно затратен.
Выход простой: надо проверять не то, что производится, а как производится. Пойти к истопнику и посмотреть, что у него есть руки, лопата, уголь, приборы, инструкция, и он ними управляется. А еще посмотреть реакцию на изменения: что будет делать, если давление упало или уголь сыроват пришел.
О той воде, которая в момент проверки по батареям идет, это скажет меньше замеров, а о той, которая всегда или завтра? Вам, вообще, которая из них интересна-то?

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

Вот так и родилась сертификация систем управления (качеством чего-то). Второй подход - это она и есть, если кто не понял.
А по первой схеме работают, например, техосмотр автотранспорта, сертификация СЗИ и проверка защищенности.

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

Перманентный ремонт - 2

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

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

Не переплачивайте консалтерам по внедрению - они делают самую легкую часть работы. Есть такой легендарный анекдот, оканчивающийся на "после сборки обработать напильником". С первого захода защитная мера реализуется в первом приближении, делается то, что лежит на поверхности. Консалтеры различны по добросовестности поиска наиболее подходящей чужой практики и/или адаптации ее к особенностям заказчика, но даже у лучших из них попаданий с первого круга будет сильно меньше половины - слишком недолго изучали ваши заморочки и не изнутря. Когда окажется, что созданные процессы толком не работают, работают только под давлением или обходятся в несуразные трудозатраты, они уже умотали к следующему (ибо как и плохие репетиторы, любят работать с начинающими, ведь насовать чего-то с нуля легче, чем разобраться и выправить), а напильничек полностью ваш.

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

Будет еще текст в эту тему, но не в следующий раз.

Инцидент - фигня или капец?

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

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

Очевидно, что обработка фигнь – это тривиальные действия: эникейщик должен взять со склада новый картридж и установить взамен выработанного, приемщик должен подтвердить гарантийный случай и оттаранить стиральную машину в мастерскую, офицер безопасности должен помочь работнику заполнить стандартную форму об утере смарт-карты и выдаче новой.
Капцы – это ощутимо другой уровень происшествия: затоплена половина цехов, скомпрометирован УЦ, гипс снимают / клиент уезжает.
Где та граница, за которой уже не одно, а другое – это нужно внимательно присматриваться к определениям соответствующей системы. Многие предлагают каждой организации провести ее для себя самостоятельно.

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

Перманентный ремонт – 1

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

Никогда не замечали удивительную популярность QM-базированных стандартов в странах с дхармическими религиями? А всё просто – у их мира тот же колесный привод, неспроста Деминг именно там до PDCA допер на радость всяким Шухартам.
В это трудно поверить, но секрет соответствия системы управления информационной безопасностью исо27тыщам в том, что вся она должна быть ввергнута в состояние непрекращающегося ремонта. В каждом своем элементе.
Европейцу это странно - круговорот воспринимается им как нечто негативное, с чем можно мириться, но никак не стремиться создавать. Европеец привык созидать стабильное, а если переменчива среда существования, то все равно созидать стабильное, но периодически. У него проектное мышление, не процессное.

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

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

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

Эффективный подход к оценке эффективности

Усвоив, что кесарю кесарево, спасение утопающих – дело рук самих утопающих, а "мы бодры" надо говорить бодрее, человечество почему-то до сих пор пребывает в странной неопределенности относительно того, как оценивать эффективность ИБ.
Протягиваю руку помощи: оценка эффективности должна быть эффективной. Если подразделение ИБ подает отчеты на двухстах страницах, о его эффективности можно судить, не заглядывая в цифры.

Чтобы сразу не отпугнуть поклонников NISTовской, SANSовской, ISM3шной и прочей нужной макулатуры про метрики, честно начинаем с подсчета стейкхолдеров, т.е. ключевых потребителей результата:
1) вышестоящее руководство. Выход процесса "измерение эффективности" попадает на вход процесса "менеджмент-ревю", говоря мелодичным языком исо27тыщ и его забавных родственников по девятитысячной линии. Руководство определило курс. Руководство давало ресурсы и полномочия. Руководство хочет знать, что получилось, и что-то наверняка скорректировать. У него тоже цикл PDCA, видите ли, даже если и неосознанный.
Но и всё. Такие потребители как акционеры, клиенты, кадровики, айтишники, юзеры, регуляторы, партнеры, конкуренты и т.п. – это от лукавого, "кто девушку ужинает, тот ее и танцует", а эти Вам не платят, их интересы и чаяния к Вам через руководство приезжают, оно же и в противную сторону интерфейс – само по ситуации разберется, если что. Совершенно не призываю совсем никаких дел не иметь с этими достойными людьми, но лишь осознать, перед кем вы реально отчитываетесь, а с кем чай пьете. Поверьте, ставить на одну доску строгих и регулярных потребителей с опосредованными и эпизодическими чревато нелепой трагедией, а что гоняться за восемью зайцами бесполезно – это еще Фибоначчи с сожалением выяснил. Попытка сконструировать такие метрики, которые и нашим / и вашим, и для того / и для этого, да еще и не выбалтывая лишнего непосвященным, обернется тем, что они утратят полезность для главного – для менеджмент-ревю.
Когда-нибудь, когда возраст вашего процесса оценки эффективности перевалит за 10 лет, а в CMM кончатся уровни, можете попробовать добавить к руководству кого-нибудь из непрямых, но раньше не надо.
Поищите-ка у кого-нибудь из мировых авторитетов квартальные отчеты о состоянии их (а не чужой) информационной безопасности в публичном доступе. А ведь Вы как покупатель (клиент) всяко должны были б в стейкхолдерах быть по идее.

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

Сколько? Для этого нужно понять, что будет делать с этой информацией руководство – оно будет принимать решения, и здесь очень простая вилка: слишком мало показателей загрубляют картину, слишком много зашумляют. Если начальники – люди, то штук семь им самое оно, скорее всего.
Но один точно нельзя, а то есть сейчас такая смешная теория – натурально шаг назад по сравнению со средней температурой по больнице, т.к. незадачливые эскулапы не просто суммировали, но еще и на количество больных делили, а эти только суммируют. Первая засада в том, что эффективность – это уже два параметра – эффект и затраты, и по одному ее не оценишь. А вторая в том, что жизнь идет, и при попытке добавлять/убавлять слагаемые теряется ценность накопленных ранее измерений. Кому что даст информация, что безопасность изменилась с 1786 на 1844 или 1562, если сам состав метрики на добрую четверть поменялся вслед за целями.

з.ы. Ах, да! Если Вы – консалтер, то к Вам это не относится: для Вас эффективным является как раз таки копипейст "лучших практик", ибо большой выход продукта при минимуме затрат, но это уже другая эффективность – не ИБ.

Исо27тыщ как защита от дурака

очень недурен.

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

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

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

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

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

27001ые риски - решение задачи

Обещал рассказать прикол с анализом рисков для ISO 27001 - рассказываю.

Был у меня такой учитель физики, который, зачитав условие задачи, вопрошал:
- Ну, и с чего начинаем решать? С какой стороны подступимся? Есть идеи?
Появлялись какие-то версии из зала:
- Вспомним формулу, связывающую температуру с давлением! Положим систему абсолютно упругой! Найдем центр масс первого тела!
Ответом чаще всего было:
- Неверно. Решение начинаем с того, что пристально всматриваемся в вопрос задачи.
Для солидности можно было бы нагуглить что-нибудь созвучное у более древнего мыслителя и процитировать на языке оригинала, но легендарно ленив, да и охота воздать хорошему дядьке, раз вспомнился.

Итак, хрестоматийный подход к анализу рисков таков: пишем активы, уязвимости, источники угроз и способы реализации, вычеркиваем абсурдные комбинации (пожар не может разгласить сетевой коммутатор), к остальным как-то прикручиваем ущербы с вероятностями, которые потом перемножаем, дальше критерии принятия и стратегии обработки.
Если Вы не консалтер, которому надо наваять повнушительнее, то имеет смысл как можно раньше задаться тем самым вопросом - а что от нас хотят в результате-то?
А хотят от нас, чтобы мы определили, какие из перечисленных в стандарте (сейчас в 27002, прежде в 17799, еще раньше в 7799-1) защитных мер aka "контролей" надо / не надо применять, и смогли убедить в этом внешнего аудитора, буде тот усомнится.
Читаем эти контроли: "политика ИБ организации", "классификация информации", "управление инцидентами"... и понимаем, что та наша многомерная матрица путем к ответу никак не является.
Вот от чего зависит, иметь ли политику ИБ организации - от наличия или отсутствия организации, разве что? А классификацию - от наличия защищаемой информации (иначе зачем вообще мы ИБ городим)? А управление инцидентами согласно бывшей второй части, которая теперь 27001, вообще must, а не на выбор по результатам анализа рисков. И т.п.

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

Как правильно делать анализ рисков ИБ

Смотря какой. "Анализ рисков ИБ" без дополнения "на предмет ..." - это ни о чем. Это все равно что инженеру про расчет изделия сказать. А какой расчет-то - на изгиб с кручением, на гомогенную конденсацию или на болотную проходимость? Это разные задачи, а не одна. Задача "Расчет вообще" не решаема, бессмысленна, недостаточнно информации для решения, только время терять.
Выбор применимых контролей из 27002 - это один анализ рисков (довольно смешной, кстати, но это отдельная тема), выбор между СЗИ А и Б - другой, прием стремного работника на генератора ключей - третий и т.п. А поскольку нет общего знаменателя, то нет и универсального инструмента.

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

Думаешь, если мышка маленькая, то у нее смерть ненастоящая?

Месяц назад написал я эту фразу в блоге у Алексея Лукацкого, отвечая, зачем малому бизнесу ИБ по ISO. Просто там тема в очередной раз касалась ISO, а говорил-то я про ИБ/НБ вообще. И даже еще более вообще.
Афоризм понравился, врать не буду. Даже погуглил потом на всякий случай - вроде нигде не стырено. Перекликается, конечно, с анекдотом про канарейку и историей про часы Маршака, но и только. Если все ж таки стырил, тогда дайте знать. Подозрительно ловко звучит.