Новая политика конфиденциальности Google

С 1 марта Google вводит в действие новую политику конфиденциальности, информация и рассылка о которой уже прошла по Интернет.

Google может собирать достаточный комплект ПДн:
-    ФИО
-    e-mail
-    название оператора и номер мобильного телефона
-    фотографию
-    реквизиты кредитной карты!
Сведения об устройстве:
-    модель
-    тип и  версия ОС
-    уникальный идентификатор
Геоданные собираются при помощи:
-    GPS
-    Wi-Fi
-    вышек сотовой связи
Всё используется для:
-    контентной рекламы
-    развития
Каким третьим лицам передаются ПДн (априори используется трансграничная передача ПДн):
-    дочерним компаниям
-    доверенным лицам
-    партнерам
-    государственным и правоохранительным органам
Методы защиты информации:
-    SSL-шифрование
-    двухфакторная аутентификация (одноразовые пароли)
-    безопасный просмотр в Chrome
-    собственные организационные меры

Итак, общий вывод в том, что использование облачных сервисов Google не гарантирует:
-    конфиденциальность данных, т.к. не смотря на SSL-шифрование неизвестно, что делается в ИС Google, а также в каком виде хранятся ПДн
-    целостность данных, т.к. при обработке (хранении) ПДн не исключаются никакие «сюрпризы»
-    доступность данных, т.к. канал связи до Google может быть недоступен, например,  по вине ISP

Как в таком случае можно повлиять на безопасность ПДн? Только заключениям между сторонами SLA, что маловероятно, или не пользоваться сервисами Google. Впрочем, контакты российского представительства успешно гугляться.
ООО «Гугл» (Россия)
Москва, ул. Балчуг, 7
+7 (495) 644-14-00
Кстати глагол “to google” определен в Oxford English Dictionary и означает «Search for information about (someone or something) on the Internet, typically using the search engine Google»).

Метрики процесса защиты ПДн

Решил написать юмористический пост про метрики, которыми можно измерять «эффективность» процесса защиты ПДн по-русски.

ТОП-10 метрик ИБ для процесса защиты ПДн :-)

1. Количество и % от их общего количества защищенных ПДн.
2. Количество и % от их общего количества защищенных сертифицированными средствами ПДн.
3. Количество и % от их общего количества ПДн, которые утекли из организации за отчетный период.
4. Ущерб, который нанесли утечки ПДн за отчетный период.
5. Стоимость утечки одной ПДн (рассчитывается как отношение Пункта 4 и Пункта 3).
6. Количество предотвращенных утечек ПДн за отчетный период.
7. Количество ПДн, утечки которых предотвращены.
8. Стоимость предотвращения утечки одной ПДн (рассчитывается как произведение стоимости часа зарплаты офицера безопасности на время, потраченное на выявление утечки и деленное на количество ПДн).
9. КПД офицера безопасности по теме ПДн (рассчитывается как отношение времени, затраченного на выявление утечки ПДн и общего времени работы по теме ПДн умноженное на 100%).
10. Эффективность защитных мер (рассчитывается как отношение Пункт 5 и Пункт 8).

Проверяем всё на примере. Допустим, есть организация, в которой обрабатывается 1 000 000 ПДн.

1. Всего защищено 500 000 ПДн, т.е. 50%.
2. Защищено сертифицированными средствами 100 000 ПДн, т.е. 10%.
3. За год утекло 1 000 ПДн, т.е. 0,1%.
4. Был судебный иск, по которому выплачено 100 000 руб.
5. Цена утечки 1 ПДн равна 100 руб.
6. За год предотвращена 1 попытка утечки ПДн.
7. За год предотвращено утечек в количестве 500 ПДн
8. Стоимость предотвращения утечки одной ПДн равна 2 руб. 50 коп. (допустим зарплата офицера ИБ равна 100 000 руб., значит час его рабочего времени стоит 625 руб., а потратил он на расследование 2 часа).
9.  КПД офицера безопасности по теме ПДн равен 0,8% (офицер безопасности ежедневно тратит 1 час по тематике ПДн, а в 2011 году было 248 рабочих дней).
10. Эффективность защитных мер равна 40 попугаев (или удавов).

Представим, что в 2010 году, т.е. до внедрения защитных мер, был такой же судебный иск на сумму 100 000 руб. А значит уже можно рисовать график «эффективности» процесса защиты ПДн. :-)

Обновлять или не обновлять серверы

Обновлять или не обновлять серверы

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

 ИТ

-  на это нужно много ресурсов, которых нет

-  это может вызвать сбои или отказы

-  и так всё работает (или основное правило админа - не трожь, пока работает)

ИБ

-  уменьшается количество уязвимостей

-  улучшается сопротивляемость  атакам

-  возрастает надежность

Бизнес

-  бизнес-процессы не должны прерываться

Аудитор

-  всё должно обновляться

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

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

-  все серверы из DMZ

-  все серверы, имеющие интерфейсы или port mapping во вне

-  все серверы, по которым есть жесткие compliance требования

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

Также хочу обратить внимание на компенсирующие меры для этого процесса. К таким мерам относятся:

-  работа с минимальными привилегиями

-  постоянно запущенный и обновляемый антивирус

-  контроль доступа как физического, так и на всех уровнях модели OSI

-  логирование событий

Мое IMHO заключается в том, что таким образом должны остаться целыми волки и сытыми овцы. :-)

Важность контроля учетных записей

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

А теперь немного юмора. Так бы я сделал, работая сисадмином в Кремле :-)

Производители устройств, создающих доверенную платежную среду

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

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

Пока мною замечены 4 реализации:

Agses. Австрийская разработка, на территории России есть ресселер – питерская компания. Название продукта качественно обыгрывает слово Access (доступ). Уже есть несколько качественных промо-сайтов, на которых присутствует много хорошо переведенных как маркетинговых, так и технических материалов и презентаций. Технологически очень интересная задумка с биометрией. Заявленная цена кусается на отметке 6000 р.

Cronto. Английская разработка, в контактах значится Кембридж. Присутствуют как программная, так и программно-аппаратная реализация. Программная реализация, по сути, является приложением (Java?) для любого современного мобильного телефона. Цена программной реализации не заявлена, но, видимо, она должна стремиться к нулю, т.к. очевидно позиционирование устройства для физиков.  Здесь я уже размещал свои мысли по созданию аналогичной среды.

PINPad. Российская разработка. Известный производитель, в багаже которого помимо опыта присутствуют тысячи проданных устройств. Может использоваться как в конфигурации с внешним, так и с внутренним защищенным токеном. Хорошего качества сенсорный экран, поддерживается скролинг. Заявленная цена 3000 р.

SafeTouch. Российская разработка. Удачное с точки зрения эргономики устройство, поддерживающее смарт-карты. Есть мнения, что тренд смещается в сторону карт, но есть и противоположное мнение. Заявленная цена 1600 р. Однако, имеются большие вопросы в части доверия к производителю: новая компания, пока не имеющая реализованных проектов, де-факто иностранное производство.

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

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