23.08.2013

Что такое business capability map в контексте ИБ?

О том чего не хватает образованию я уже писал не раз. Одним из серьезных недостатков является отсутствие бизнес-привязки в деятельности или образовании ИБ. Мы все время говорим о классических аксиомах - триаде КДЦ, ААА, криптографии и т.п. Все это важно, но мы часто забываем, что всему свое время и место и в разных бизнесах могут быть совершенно разные потребности и приоритеты в ИБ. Всех одним аршином не измерить, а мы пытаемся.

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

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

M2M... Межмашинное взаимодействие. Еще одна тенденция последних месяцев, которая приходит и в Россию. И датчики в индустриальных системах, кардиостимуляторы с дистанционным мониторингом, банкоматные сети, это только один из возможных примеров. А автомобили, берующие информацию о заторах на дорогах от самой дороги? Правда не российской дороги, а "умной" дороги, проекты которых сейчас появляются в разных странах мира. Тахографы, передающие информацию о маршруте движения транспорта и о состоянии водителя через спутниковые каналы или GSM. Климатические датчики, датчики состояния трубопроводов, датчики контроля парогенератора атомного реактора... Примеров много, а вот с их безопасностью пока не так все хорошо. Традиционные защитные подходы не срабатывают - миниатюрные размеры, автономное энергоснабжение, длительные сроки работы... Все это не позволяет взять и поставить у каждого (или на каждом) датчика защитный комплекс. И тяжеловесную криптографию, требующую больших вычислительных ресурсов, тоже не реализуешь. Опять затык с традиционными подходами, к которым мы так привыкли и которым нас учат (учили в ВУЗах). А зачастую появляются и вовсе совершенно новые задачи, о которых мы раньше и не думали. Например, защита GPS-передатчиков. В них очень важно обеспечить защиту от блокирования сигнала. Представьте, что вы следите за перемещением инкассаторской машины с GPS-датчиком или осужденного под домашним арестом с браслетом за контролем перемещений. Вы уверены, что контролируемые объекты находятся там, где они должны находиться, а на самом деле это не так и они уже давно тю-тю - инкассаторский броневик разгружается преступниками, а домашний арестант по бутикам шатается.

Индустриальные системы (или как их часто называют АСУ ТП). Модная тема. Мне в течение последнего месяца пришлось столкнуться с тремя проектами по ИБ в области атомной энергетики. Проекты все разноплановые, но объединяет их всех одно - попытка идти в них с традиционным ИБшным опытом и взглядами, без учета специфики атомной отрасли, а она есть. Например, полное отсутствие учета требований нормативной базы Росатома к выбираемым средствам защиты. Требований не ИБшных, а, например, по наработке на отказ, по климатике, по происхождению. Или попытка прописать обычное для традиционных ИТ-проектов требование по управлию патчами - регулярное и автоматическое обновление ПО. Но в индустриальных системах, где установка патча может нарушить работоспособность контролируемой или управляемой системы, традиционные подходы к патч-менеджменту не работают. Как и традиционные VPN-шлюзы с их задержками и временем отклика. Представьте, что из-за такого шифратора или системы аутентификации по 802.1x система контроля реактора не получила вовремя сигнал от какого-либо датчика и запустила процесс аварийного отключения реактора?..

Поднимемся на уровень выше, туда где обрабатывается информация. Допустим мы все-таки реализовали технический комплекс защитных средств и он в состоянии обеспечить необходимый уровень защиты. Но защиты чего? Мы традиционно защищаем все. IP-шифратор шифрует все в канале, локальная СКЗИ шифрует либо весь диск, либо каталог, либо файл (что требует определенного порядка и системы управления файлами). А надо ли? Может и нет? Может не тратить ресурсы на то, что вовсе не требует защиты? Есть ли у нас не просто список сведений конфиденциального характера, а реальное понимание, где эта информация хранится, где обрабатывается, как и кому передается? Знаем ли мы владельцев этой информации? А ее стоимость? А влияние на бизнес? Может мы защищаем то, что вовсе не требует защиты, а то, что требует, мы не защищаем или просто не знаем как? Например, тривиальная задача - контроль утечек по протоколу ActiveSync во время синхронизации ПК с мобильным устройством. Мы контролируем то, что умеем или то, что надо? Или контроль и защита информации о переговорах о покупке актива, проводимые по Telepresence, или на худой конец видеоконференц-связи? Защищаем?

А что делать? Как учитывать потребности бизнеса? Начну с того, что все, что написано выше - это еще не совсем потребности бизнеса, это скорее технологии, ориентированные на бизнес-потребности, с понимания которых и надо начинать. Обычно они формулируются и помещаются в так называемые business capability map. Для тех, кто долгое время работает в той или иной отрасли проблемы составить такую карту труда не представляет. Для тех, кто присматривается к новому месту работы или приложения своих сил потребуется время на их составление. Обычно на это уходит около недели. Можно поступить проще и погуглить уже готовые карты (иногда их можно найти в открытом доступе). Хорошим подспорьем являются подобия таких карт, выложенные на сайте компании Perimetrix. У меня в какой-то из презентаций на блоге были приведены некоторые из таких карт (правда, не помню в какой). Третий вариант - купить или заказать разработку. Например, у Forrester такие карты есть по разным отраслям - банки (для разных видов банковской деятельности - разные), нефтянка, страхование и т.д.

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

3 коммент.:

Евгений Родыгин комментирует...

+++

ZZubra комментирует...

По существу самих карт - очень они похожи на BPMN, о котором я уже говорил. Кстати следующим шагом за business capability map, наверное, идут идеи Деминга и карты Шухарта (как пример их вырождения - бережливое производство). Это ж клондайк для бизнеса - японцы вон на этих средствах передовыми в мире стали.

Карты такие (business capability map)- это очень хорошо (даже у самого такая есть по организации, правда во free mind отрисованная - большая, народ пугается видя ее в первый раз, но когда начинают разбираться сразу рвутся добавлять что-нибудь). А что дальше за картами? По той же больнице - ну принесу я супер карту главврачу, он же даже выгоды своей не увидит - окружение и среда его работы не подразумевает отклонения от системы. Потому главную проблему я вижу в руководителях, которых устраивает существующее положение дел. Они может и не виноваты - все и всегда вокруг них так было. Но именно они на своем уровне блокируют применение таких классных инструментов (кстати в Японии именно эта проблема была главной). А ниже уровнем их применять бессмысленно. Та же защита персданных - больше мода для начальников, а не понимание угроз и рисков, мол чего-то вокруг коллеги-начальники много стали говорить о них, надо хоть цену узнать. Это я про операционную деятельность выразил свое мнение )))

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

Алексей Лукацкий комментирует...

Как раз ИБ в атомной энергетике прописана очень и очень недурно