24 октября 2012 г.

5 октября 2012 г.

Письма службы тех.поддержки 2.0

Лет 10 назад популярным был способ увода пароля через фейковые письма от якобы служб технической поддержки, вроде:
Добрый день, уважаемый пользователь.

В связи с атакой вируса MIR.DOS.X213-1 на сервера нашего сервиса электронной почты, часть данных об абонентах была утеряна.
Пожалуйста для актуализации информации перешлите нам следующие данные:
- адресс электронной почты;
- ФИО;
- год рождения;
- пароль доступа.

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

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

Например есть сервис А с секретными паролями для восстановления пароля и есть сервис В. Отправляем сообщение от "службы безопасности" в сервис B, в которой просим пользователя в целях повышения безопасности аккаунта ответить на несколько секретных вопросов, один из которых совпадает с вопросами сервиса А.

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

3 октября 2012 г.

Зри в корень



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

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

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

Понимание смысла требования полезно так же и при прямой его реализации. Так например известный «обход» требований стандарта PCI DSS версии 1.2, когда при формальном соблюдении требований по хранения номеров карт, допускалось совместное хранение их одновременно в маскированном и хешированном виде. Очевидно что изначальной цели – обеспечения безопасности данных, такой способ хранения не отвечал, исходные номера карт по хранимым значениям высчитать за секунды.

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

То же самое после редактуры на сайте Информзащиты