середу, 21 вересня 2011 р.

Укращение строптивых


Недавно, приводя к эталонному размеру стопку «очень нужных» документов, в руки попала папочка цвета «хаки» со строгой и простой надписью Xylogics, Inc. , хранившая переписку, которую сегодня уже не прочесть, почему тогда о столь замечательном свойстве факсовой термобумаги я не задумывался…

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

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

Как укротить этих «железных коней», превратив их из потенциальных «врагов»  в «друзей и помощников»? Некоторые ответы можно подсмотреть в исследовании Gartner-a «Critical Capabilities for Mobile Device Management»

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

Так, например, назвав критическими, Gartner рекомендует анализировать 10 свойств продуктов управления:

  1. Device Diversity: возможности работы с различными ОС и различными устройствами
  2. Policy Enforcement: возможности настроек и управлением политиками безопасности (доступа, роуминга, фильтрации, приложений и т.д. и т.п)
  3. Security and Compliance: наличие средств защиты корпоративных данных хранимых на устройстве (аутентификация, блокровка, шифрование и т.д. и т.п)
  4. Containerization: возможности разделения сорпоративных данных от личных
  5. Inventory Management: набор механизмов для предоставления, контроля и отслеживания устройства, подключенные к корпоративным приложениям и данным (и снова замечательный перечень для чеклиста)
  6. Software Distribution: возможности по распространения приложений и обновлений программного обеспечения для мобильных пользователей (поддержка OTA …) 
  7. Administration and Reporting: администрирование и отчетность (интерфейсы, группы, интеграция и т.д.)
  8. IT Service Management: доступные уровни обслуживания (интеграция с Help desk, self-service, аlerting и т.п.)
  9. Network Service Management: возможности для контроля и оптимизации расходов
  10. Delivery Model: модель использования (например: on-premises, hosted, cloud) 


Документ, так же может быть полезен, в процессе разработки политик, процедур, контролей… Приятного прочтения ;-)

вівторок, 20 вересня 2011 р.

Эволюция безопасности: от трагедии к фарсу


Гегель когда-то написал, что история повторяются дважды: первый раз как трагедия, а второй — как фарс.

Столкнувшись с проблемой, что  человеческий дух слаб и не редко, люди поставленные охранять, сами же, превращаются в воров, древние римляне обозначили серьезную проблему, возникающую перед каждым, кто пытается построить систему безопасности, подарив изречение ставшее крылатым «Quis custodiet ipsos custodes?».

На фоне недавних проблем у COMODO, HBGary, RSA, сегодня, прочтя сообщение от Vasco, подумалось: учение римлян устарело, пришло время менять парадигму. Ура, Гегелю!!!

пʼятницю, 26 серпня 2011 р.

Незнание не освобождает

"Незнание угроз не освобождает нас от риска"

Сегодня, просматривая новости, наткнулся, что жителя Чебоксар оштрафовали за взлом учетной записи супруги. А это, как не говори, уже не далекая Америка…

Особо и комментировать вроде нечего, но лишний раз для себя отметил:

  1. Хочешь иметь тайну - позаботься о ее защите
  2. Первейший нарушитель - инсайдер
  3. Изменение контекста изменяет ландшафт угроз
  4. Мы часто переоцениваем себя и недооцениваем оппонента
  5. Киберпространство - виртуально по форме, но реально по сути

пʼятницю, 5 серпня 2011 р.

Атака прошла успешно! Кто виноват?

Сегодня, все пользователи ИТ, в той или иной степени подвергаются опасности сами или подвергают опасности других. Умиляют настойчивые попытки в формировании мнения, что они (пользователи) чаще всего сами и виновны, если происходят неприятности.

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

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

Призвать к ответу «разработчика А» ! Потому как он:
  • разрешает использовать слабые пароли;
  • разрешает запускать свое приложение без активного антивируса с актуальными базами данных; 
  • в конфигурации «по-умолчанию» вместо широко используемого подхода «all deny» использует «all permit»;
  • разрешает при первом запуске приложения просто прочесть перечень опасностей подстерегающих пользователя, и даже не пытается проверить, насколько хорошо пользователь усвоил прочитанное.
А ведь Разработчик мог достаточно просто реализовать и даже обновлять как  инструкцию, так и опросник по безопасности.

Почему производители бездействуют? – Даже на копеешной лазерной указке пишут об опасности.

Многие из нас находятся в рабстве иллюзий, разделяя мир на «материальный» и «виртуальный».

Грань стерта, граница размыта!

Потери денег, изуродованная психика – это уже сегодня.
А что завтра?  Атаки на SCADA атомных электростанций, самолетов, систем очистки воды?
Что здесь виртуального?

Атака прошла успешно! Кто виноват? Пользователь?

пʼятницю, 8 липня 2011 р.

Утечки и Конституция

Весь мир борется с утечками информации, по вине инсайдеров, внедряя очень и очень не дешевые, но очень умные DLP-системы, а у нас, понимаешь ли, «руки связаны»: Конституция запрещает! (см. Статью 31 Конституции Украины  или Статью 23 Конституции Российской Федерации).

Это ошибка законодателя или свидетельство высшего проявления демократии? И как же быть? Что делать? Как изменить  Конституцию?

На самом-то деле менять нужно не Конституцию, а свое отношение к проблеме.

А что есть "тайна переписки"? А если из процесса мониторинга и принятия решения по результатам мониторинга исключить человека?

Давайте сделаем так, что бы наши DLP-системы анализировали информационные потоки без регистрации автора. Системы могут/должны обладать функциями блокировки и даже возможностью предупреждения нарушителя о неправомерных действиях, типа «Отправка вашего сообщения заблокировано. Сообщение уничтожено по причине нарушения пункта №6.1.1 Политики допустимого использования (Acceptable use policy )  в соответствии пункта №3 Политики безопасности».

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

А что дальше? Если действия повлекшие инцидент случайны, сотрудник сам инициирует для себя «ликбез» в этом вопросе и его личность будет установлена, если же действия умышленны, то…

Что мы делаем, если обнаруживаем, что кто-то пытался залезть к нам в гараж и украсть машину? Правильно – обращаемся в компетентные органы! А они, руководствуясь законом и характером нарушения, определяют  средства и методы для поимки нарушителя…

Почему так? Потому как времена и нравы Дикого Запада канули в лету и самосуд стал преступлением.

вівторок, 12 квітня 2011 р.

RA: В поисках "цифры"

Будучи скептиком в вопросе возможности количественной оценки рисков информационной безопасности, не смог пройти мимо факта, лишний раз иллюстрирующего природу моего "неверия".

Вспомним один из последних громких инцидентов: успешную атаку на RSA. Воспользуемся  кратким описанием "анатомии" атаки и небольшим исследованием ее последствий.

Возможно ли было заранее "просчитать" этот риск и получить цифру "694 млн. долларов"?

Сторонники количественных оценок, для расчета Риска рекомендуют различные формулы и подходы, которые опираются на "классику":

Риск = Вероятность * Воздействие

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

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

На самом-то деле, проблем для такой оценки никаких нет, для этого нужно знать ответ на три простых вопроса:
1.       Когда (дата) произойдет инцидент?
2.       Какая будет стоимость акций компании на указанную дату?
3.       Как отреагирует "биржа"  на сообщение о инциденте?  (т. е. на сколько "упадут" акции в цене: на 1%, или на 10%, а может на 5%).


Неужели кто-то не смог определить, что данное безобразие инцидент будет оценен падением на 1.25% в тот момент когда капитализация компании достигнет 55.55 млрд?