American Institute of Certified Public Accountants (AICPA) совместно с Canadian Institute of Chartered Accountants (CICA) опубликовали для комментирования черновик модели зрелости для процессов защиты персональных данных (Privacy Maturity Model). Модель базируется на Generally Accepted Privacy Principles (GAPP).
Свои комментарии и пожелания можно выразить до первого октября. Инструкции как это сделать тут.
четверг, 16 сентября 2010 г.
вторник, 14 сентября 2010 г.
В ДТП под Харьковом погибли представители "Бакотек" и McAfee
Сегодня новость грустная. Точнее сказать печальная.
Ночью на трассе под Харьковом в результате ДТП погибли коллеги из McAfee и БАКОТЕК.
Среди погибших:
Елена Утвенко, менеджер по развитию бизнеса McAfee, Оксана Лучко менеджер по маркетингу БАКОТЕК, Максим Козуб - переводчик - находятся в больнице. Елена и Оксана в тяжелом состоянии.
Искренние соболезнования
Тут находится документ с деталями, а также контактами людей, через которых можно оказать помощь и выразить соболезнования
Ночью на трассе под Харьковом в результате ДТП погибли коллеги из McAfee и БАКОТЕК.
Среди погибших:
- Доминик Сумовски (Dominik Sumowski) - менеджер по работе с партнерами McAfee в Восточной Европе
- Константин Здыбель - начальник отдела технической поддержки проектов БАКОТЕК
- Витольд Мазанек (Witold Mazanek) - технический эксперт компании McAfee
- Ольга Журавлева - руководитель отдела по работе с корпоративными клиентами БАКОТЕК
Елена Утвенко, менеджер по развитию бизнеса McAfee, Оксана Лучко менеджер по маркетингу БАКОТЕК, Максим Козуб - переводчик - находятся в больнице. Елена и Оксана в тяжелом состоянии.
Искренние соболезнования
Тут находится документ с деталями, а также контактами людей, через которых можно оказать помощь и выразить соболезнования
среда, 8 сентября 2010 г.
О темной стороне криптографии
Сисадмин спросил Инь Фу Во:В сети продолжается святая война между разработчиками криптографических алгоритмов и теми, кто их вскрывает. Форумы пестрят бесконечными спорами, какой алгоритм надежнее, и достаточно ли делать криптоконтейнер в криптоконтейнере, который сам в криптоконтейнере и разделять ключ на 10 человек или нет. Сломали WPA2, "вскрыли" систему квантовой криптографии, придумали невскрываемый алгоритм (неужели изобрели одноразовый блокнот?). Даже в фольклере (как, например, в эпиграфе) рассматривается только "система из четырёх".
– Правда ли, что любой шифр можно сломать?
Учитель ответил:
– Можно. Но не "шифр", а систему из четырёх: алгоритм, реализация, окружение и оператор.
Сисадмин ещё спросил:
– А что из этих четырёх самое непрочное?
– Стыки между ними, – ответил Учитель.
И почему-то нигде (в русскоязычных источниках) не рассматривается экономическая сторона использования шифрования.
Истории из жизни:
- После очередной утечки информации руководство принимает решение об обязательном шифровании. Вопрос выбора системы простой - спросили у безопасника. Тот почесал затылок и сказал: "ну, давайте использовать PGP - она надежная". Прописали в политику - всем все шифровать с использованием PGP - и почту и диски. А процедуры прописать забыли. Послушные сотрудники все зашифровали. Через какое-то время уходит один сотрудник из компании, потом другой. Обычная текучка - ничего сверхъестественного. А процесса отбирания ресурсов у увольняющихся сотрудников тоже нет. Через время этих сотрудников уже не найти, зато понадобились документы с их рабочих станций. А документы надежно защищены (PGP- диском). Пароля не знает никто - это же конфиденциальная информация. В финале, утеря информации в результате ее шифрования нанесла больше ущерб, чем утечки.
- Решила другая компания защищать свои ресурсы от утечек (что поделать, время такое). Разослали приказ - все все шифровать. Но централизованно ничего не внедряли - приказ дан, исполняйте, чего не понятного? Начинает каждое подразделение что-то свое покупать и внедрять. В результате обмен ключами и паролями занимает треть всего документооборота, затраты на покупку всех систем для компании и на поддержание работы этого зоопарка вызывают приступы у финансов. Да, я говорил, что классификации информации никто не проводил? Поэтому зашифровали все - так надежнее. И не ясно - на сколько сократили потенциальные риски, но явно увеличили расходы на безопасность.
понедельник, 6 сентября 2010 г.
Облака, белогривые лошадки...
ISACA провела web-based семинар, посвященный информационной безопасности и безопасности персональных данных при использовании облачных вычислений.
Материалы в основном базировались на ноябрьской публикации ENISA (Eropean Network and Information Security Agency), посвященной вопросам безопасности при использовании облачных вычислений.
В документе приводятся выгоды (для безопасности) от использования облачных вычислений, основные риски (для нее же) и рекомендации что с эти всем делать.
Основные риски, приведенные в публикации:
Какой же выход из данной ситуации?Как говорит народная мудрость: "даже если тебя съели, у тебя остается еще два выхода" Выходов как минимум два:
счастье безопасность - потребителям.
Материалы в основном базировались на ноябрьской публикации ENISA (Eropean Network and Information Security Agency), посвященной вопросам безопасности при использовании облачных вычислений.
В документе приводятся выгоды (для безопасности) от использования облачных вычислений, основные риски (для нее же) и рекомендации что с эти всем делать.
Основные риски, приведенные в публикации:
- Утрата конроля. При использовании облачных вычислений, клиенты неизбежно передают контроль за средой провайдеру услуги. Разумеется это - большой риск для безопасности, ибо провайдер может и не организовать у себя все необходимые меры защиты.
- Закрытость систем. На текущий момент мигрировать с одного провайдера на другого или перевести данные назад в собственную систему - задача не тривиальная, часто не реализуемая. Причем тут безопасность? - Вопросы доступности информации.
- Нарушение изоляции (isolation failure). Мда, на русском не звучит. В общем, это класс рисков связанных с нарушением механизма изоляции хранения, памяти, маршрутизации и даже репутации между различными владельцами (так называемая guest-hoping атака). Если на пальцах, то зловредные действия у одного владельца в облаке наносят ущерб репутации другому. В результате риски утечки информации, ущерба репутации или нарушения сервиса для сервис-провайдера и его клиентов.
- Комплайенс-риски. Опять по-русски нормально не переводится, но все уже к слову комплайенс привыкли. В общем, кто не привык - это риски не соответствия каким-либо требованиям. Например, проинвестировала компания в получение сертификата по информационной безопасности, например
ISO 27001... мда, редкое явлениеPCI DSS. А потомс какого-то перепугуперенесла часть данных в облако.
- Компрометация административного интерфейса. Интерфейс, с помощью которого "облачный провайдер" управляет своими ресурсами, доступен через интернет. И получить через него доступ можно к огромному количеству данных от самых разных компаний. А постоянно появляющиеся уязвимости браузеров только усугубляют риск.
- Защита данных.
Вот уж неожиданный риск.Честно говоря, не представляю, что авторов сподвигло выделить этот риск как отдельный класс, но к нему можно свести все остальные. Ибо проблема защиты возникает как при передаче данных в облако, так и при хранении, так и при уничтожении и т.д.
- Небезопасное / неполное уничтожение данных. Обеспечить полное уничтожение данных без возможности их восстановить - достаточно хлопотное мероприятие для информационной безопасности. Например, в Нацбанке использование электро-магнитного импульса (вроде того, что создает "Лавина") для уничтожения данных на жестких дисках первый отдел не считает безопасным. Приходится брать старую добрую дрель и делать из дисков дуршлаг... В облаке же, где трудно понять вообще где что физически хранится, организация безопасного и полного уничтожения данных по запросу клиента кажется сизифовым трудом.
- Внутренний злоумышленник. Ну, тут все просто - та же проблема, как и везде, только возможностей у него не в пример больше, т.к. доступ есть к данным сразу многих компаний.
Какой же выход из данной ситуации?
- можно использовать традиционный метод кнута - вводим
очереднуюобязательную сертификацию, какой-нибудь CPSS (Cloud Provider Security Standard) и понеслась.... - Можно конечно и пряничный метод - провайдеры сами заказывают аудит по ISAE 3402 Assurance Reports on Controls at a Service Organization. Добровольно прошли, опубликовали отчет, показали что безопасность есть, завлекаем этим клиентов.
Подписаться на:
Сообщения (Atom)