вторник, 24 апреля 2012 г.

Размышления об оценке рисков

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

С одной стороны необходимость проведения такой оценки предписывается практически всеми стандартами/международными практиками.  Возьмем самые основные:

ISO 27001: 
Организация должна создать, внедрить, эксплуатировать, осуществлять мониторинг, анализировать, сопровождать и совершенствовать документированную СУИБ в контексте общих бизнес активностей и рисков организации.

Организация должна делать следующее:
c) Определить подход организации к оценке рисков.
d) Идентифицировать риски.
e) Проанализировать и оценить риски.
f) Идентифицировать и оценить возможности по обработке рисков.

PCI DSS:
12.1 Должна быть разработана, опубликована, утверждена и доведена до сотрудников политика информационной безопасности, которая включает описание ежегодного процесса идентификации угроз и уязвимостей, завершающегося формализованной оценкой рисков

СТО БР ИББС-1.0:
8.4.1. В организации БС РФ должна быть принята/корректироваться методика оценки рисков нарушения ИБ / подход к оценке рисков нарушения ИБ.
8.4.2. В организации БС РФ должны быть определены критерии принятия рисков нарушения ИБ и уровень допустимого риска нарушения ИБ.
8.4.4. Оценка рисков нарушения ИБ проводится для свойств ИБ всех информационных активов (типов информационных активов) области действия СОИБ.

Cobit 5.0:
Процесс APO12 Manage Risk
1. Collect data.
2. Analyse risk.
3. Maintain a risk profile.
4. Articulate risk.
5. Define a risk management action portfolio.
6. Respond to risk.

и многие, многие другие..... 

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

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

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

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

1. Вы определили основные активы (то за что, вам могут дать по голове в случае чего) 
2. Вы обнаружили проблемы (они же уязвимости)
3. Вы определили к чему эти проблемы могут привести (определили угрозы)
4. Представили свои соображения руководству, получили денег, к примеру, на половину из предложенного и расставили приоритеты по проведению мероприятий по ИБ (это и есть оценка и ранжирование рисков ИБ и закрытие их на приоритетной основе).

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

И вот что еще важно отметить. Есть принципиальное отличие в подходах к риск-менеджменту в существующих стандартах по ИБ.

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

А если мы возьмем стандарт PCI DSS (который, кстати, многие хвалят) или СТО БР ИББС-1.0, то там оценка рисков - это всего лишь один из элементов безопасности наряду с массой других, определенных в стандарте.  Именно это и приводит к тому, что многие специалисты по ИБ задают вопрос, а зачем вообще проводить оценку рисков.  Мы же уже реализовали огромное количество требований, написанных в стандарте, т.е. мы практически все риски перекрыли, зачем теперь еще и оценку проводить ?  Ответ прост - стандарт определяет набор базовых требований и поэтому оценку рисков ИБ следует проводить для того, чтобы определить необходимость реализации дополнительных защитных мер для конкретных активов, защита которых не обеспечивается выполнением базовых требований, определенных в стандарте.

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

воскресенье, 22 апреля 2012 г.

Законотворческий процесс в действии

Коллеги, еще 13 февраля я писал о появлении проекта постановления правительства "Об утверждении Положения о защите информации в национальной платежной системе".  Проект был опубликован на сайте ФСТЭК, а также передан на оценку регулирующего воздействия в МЭР  и оценку коррупционгенности в Минюст. Об этих оценках я уже писал ранее.

Кстати, интересно было почитать заключение МЭР на этот законопроект. Оно опубликовано здесь. Приведу ключевую для меня выдержку:

2. В соответствии с абзацем 2 пункта 14 проекта Положения предусматривается, что «контроль (оценка) проводятся субъектом платежной системы самостоятельно и (или) с привлечением на договорной основе организаций, имеющих лицензию на деятельность по технической защите конфиденциальной информации». Исходя из указанной формулировки проекта Положения, полагаем, могут возникнуть необоснованные основания в дублировании контроля (оценки), в случае его проведения субъектом платежной системы самостоятельно и с привлечением на договорной основе организаций, имеющих лицензию на деятельность по технической защите конфиденциальной информации. В связи с этим считаем необходимым уточнить редакцию абзаца 2 пункта 14 проекта Положения.
Также представляется целесообразным в проекте Положения конкретизировать случаи привлечения на договорной основе организаций, имеющих лицензию на деятельность по технической защите конфиденциальной информации, для осуществления контроля (оценки).
Кроме того, полагаем, что положения абзацев 4 и 5 пункта 14 проекта Положения не позволяют однозначно определить периодичность проведения контроля (оценки). Так, с одной стороны в проекте Положения предусматривается установить периодичность осуществления контроля (оценки) требований к защите информации в платежной системе «не реже раза в два года» (абзац 4 пункта 14 проекта Положения). С другой стороны, предполагается установить, что «контроль (оценка) выполнения требований к защите информации в платежной системе может осуществляться в ходе аудита субъекта платежной системы, проводимого в соответствии с законодательством Российской Федерации об аудиторской деятельности» (абзац 5 пункта 14 проекта Положения). Отмечаем, что в соответствии с пунктом 2 статьи 5 Федерального закона от 30 декабря 2008 г. № 307-ФЗ «Об аудиторской деятельности», в частности, обязательный аудит проводится ежегодно. Одновременно, в абзаце 5 пункта 14 проекта Положения представляются неясными случаи, в которых «обеспечение защиты информации включено в перечень сопутствующих аудиту услуг, устанавливаемому федеральными стандартами аудиторской деятельности и (или) стандартами аудиторской деятельности саморегулируемых организаций аудиторов».
Таким образом, полагаем, что пункт 14 проекта Положения требует существенной доработки.

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

Кстати, на днях проект этого документа появился на сайте АРБ (ссылка). Текст оригинальный и замечания МЭР не учитывает. Интересно, это АРБ запаздывает с публикацией документов на пару месяцев или все же это сигнал, что документ скоро примут в его изначальной редакции ?

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

вторник, 17 апреля 2012 г.

По итогам форума директоров ИБ

Сегодня завершился второй, заключительный день Форума директоров ИБ. Несколько наиболее ярких моментов, которые я лично для себя выделил:

1) Представитель ФСБ рассказал, что проект нового Постановления Правительства под 152-ФЗ про уровни защищенности должен быть опубликован в ближайшее время. Если я правильно понял, то переход к уровню защищенности будет через какую-то комбинацию класса системы (по схеме классификации типовых систем) и модели нарушителя. 

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

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

3) Еще я отметил, что в риторике представителей ФСТЭК и ФСБ все чаще звучит то, что их назначили ответственными за контроль государственных информационных систем, а то, как будет организован контроль коммерческих организаций их не особо интересует. Это не их задача. 

4) И в заключение на основании доклада Алексея Волкова я отмечаю, что действительно все разговоры в кулуарах конференций не значат ничего и точку в большинстве вопросов может поставить только СУД.  Готовьте свои аргументы, коллеги !

воскресенье, 15 апреля 2012 г.

Проблематика защиты мобильных устройств (часть 3) - утечка данных

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

1) Применение криптографии

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

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

2) Усиленный контроль доступа

Т.е. использование на устройствах пароля доступа (passcode). И тут конечно же важно не просто его наличие, но и требования к сложности пароля. Чтобы не получилось вот это:


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

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

3) Использование DLP-систем для мобильных устройств 

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

4) Исключение хранения информации на мобильном устройстве

Конечно же это не всегда возможно в силу того, что у нас пока еще не везде можно обеспечить уверенный прием 3G/WiMax сигнала, который позволит работать с удаленным сервисом без хранения информации на устройстве.

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

1) Использование специальных клиентов для доступа к прикладным системам, которые исключают хранение информации на устройстве.

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

2) Использование веб-приложений, позволяющих просматривать информацию в браузере без возможности сохранения документа.

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

3) Терминальный доступ с мобильного устройства к корпоративному серверу, на котором хранится необходимая информация/приложения

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

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

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

вторник, 10 апреля 2012 г.

Межбанковская конференция "Вопросы обеспечения безопасности НПС"

Для информации, коллеги, 7 июня 2012 года состоится Межбанковская конференция "Вопросы обеспечения безопасности Национальной платежной системы и дистанционного банковского обслуживания». Место проведения: Москва, Конгресс-центр МТУСИ. 

Обсуждаемые вопросы:
  • Регулятивная функция Банка России в свете выполнения закона "О национальной платежной системе"
  • О документах Банка России по информационной безопасности в рамках закона "О национальной платежной системе"
  • Обеспечение бесперебойности функционирования платежной системы: роль и место вопросов информационной безопасности
  • Механизмы саморегулирования субъектов предпринимательской и профессиональной деятельности в кредитно-финансовых и других организациях – участниках национальной платежной системы Российской Федерации
  • Нормативные и технические вопросы обеспечения безопасности систем ДБО
  • Практический опыт совершенствования систем ДБО
  • Взаимодействие банковского сообщества по решению проблем обеспечения безопасности систем ДБО
Подробнее -  http://www.ib-bank.ru/dbo/

вторник, 3 апреля 2012 г.

Open source в инфобезопасности

Помню на волне кризиса, который начался в 2008 году, шло немало разговоров (в т.ч. на уровне государства) о возможном переходе на СПО (свободно распространяемое программное обеспечение, open source).  Я даже в свое время размещал список open source решений, которые могут быть полезны для безопасника.  Сейчас эти разговоры поутихли, да и активное развитие облачных и мобильных технологий серьезно повлияло на рынок ПО.  В связи с этим у меня возник вопрос к читателям этого блога. А вы используете open source решения для обеспечения информационной безопасности ? Если да, то какие ?  Напишите в комментариях. 

воскресенье, 1 апреля 2012 г.

Всех с днем смеха !

В прошлом году я в этот день устроил небольшой розыгрыш на тему принятия поправок в 152-ФЗ. В этом году не буду, т.к. к сожалению мой розыгрыш начинает сбываться.... :) 

Поэтому в этот раз просто хочу с вами поделиться одним забавным наблюдением. Дело в том, что в панели управления блогом на сервисе Blogger можно отслеживать статистику посещения блога, а также источники приходящего трафика. И есть там в том числе возможность видеть поисковые фразы, которые вбивали в поисковик Google пользователи, которые переходили на мой блог. Итак:

1) truecrypt vs. фсб

Лейдз..ээээнд джентлменс... ин зе ред корнер......да, я хотел бы на это посмотреть :).  Кстати, а как вы думаете кто кого ? 

2) iБондаренко блог

Нет, все таки эпломания захватила всех, теперь даже к фамилии i прибавляют.  или это мой iКлон ?

3) александр лукацкий блог

Гы, интересно, как выглядит этот человек ?  Прямо так и захотелось в фотошопе поэкспериментировать :)

4) регулятор давления ак 11 б нового образца

Вот скажите мне как можно было по такой поисковой фразе зайти на мой блог ?   Кстати,  а что это вообще такое ? :)

5) ребята вот email и пароль на сайт мой мир

спасибо конечно