10 декабря 2012 г.

Хранение критичных данных в соответствии с PCI DSS

Периодически приходится сталкиваться со мнением, что в рамках PCI DSS запрещено к хранению только полное содержание треков магнитной полосы, но не их отдельные части, в том числе CVC, PVV, PVKI.

Это ложь. Хранение всей информации, идущей после сервис-кода запрещено:
(источник: Navigating the PCI DSS v2.0)

Что логично, т.к. CVC, PVV, PVKI - величины используемые для авторизации транзакций.

14 ноября 2012 г.

Skype epic fail

Утренняя радость от Skype. Что интересно в данной ситуации, что за 12 часов компания разработчик так и не придумала никаких компенсационных мер, ну хотя бы банально запретили регистрировать на один e-mail несколько аккаунтов до решения проблемы в более глобальном плане.

Что по хорошему должно происходить в такой ситуации?

В организациях, где используется Skype:
- ответственные за выявление новых уязвимостьей должны сразу при обнаружении проблемы оповестить ответственных за ИТ, и сообща:
 а) протестировать проблему на работоспособность
 б) разработать план временного решения (например сменить привязку на новый, случайно сгенерированный e-mail)
 в) оповестить руководителей подразделений о проблеме и возможных путях решения
- сотрудники без-ти выборочно проверить, что временное решение было сотрудниками принято;
- при выходе обновлений закрывающих уязвимость, произвести его установку, проверить, что оно действительно помогает избежать обозначенные проблемы, оповестить сотрудников, что проблема решена.

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


Что происходит по факту?

Доступное описание эксплуатации уязвимости позволяет практически любому пользователю ее провести, служба поддержки Skype никого не оповещает ни о методах, ни о сроках решения.

update: 14 часов потребовалось разработчикам, что бы предложить временное решение - отключить функцию восстановления паролей.
Забавно, что сейчас легитимные пользователи у которых поменяли пароль, но не поменяли почту, не смогут вернуть себе аккаунт :)

13 ноября 2012 г.

Аудит безопасности: как не начать мерить среднюю температуру по больнице

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

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

Читать далее на bankir.ru

24 октября 2012 г.

5 октября 2012 г.

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

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

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

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

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

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

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

3 октября 2012 г.

Зри в корень



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

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

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

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

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

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

20 сентября 2012 г.

Стандарты информационной безопасности

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

Очередная статья на банкир.ру

6 сентября 2012 г.

Defсon 20

Ждал, пока товарищи из ddtek выложат результаты CTF, после чего хотел написать о том как все прошло, но видимо бесполезно.

А к этому времени отличную обзорную статью написал BeLove на Хабре.

Upd: финальные результаты:
1.
2.PPP
3.European NopSled Team
4.Routards
5.OccupyEIP
6.0ldEur0pe
7.Hates Irony
8.Leet More Smoked Chicken
9.Shellphish
10.TwoSixNine
11.ACME Pharm
12.SiBears
13.Hackerdom
14.our name sucks
15.WOWHACKER-PLUS
16.We_0wn_You
17.KAIST GoN
18.V&
19.sutegoma2
20.Team Hillarious

3 июля 2012 г.

Defcon CTF 2012

Подсмотрел у Марата.

Все российские команды вышедшие в прошлом году в составе IV в финал Defcon CTF, в этом году попали туда независимо:
More Smoked Leet Chicken [PhDays (and more)],
SiBears [HitB Amsterdam],
HackerDom [Nuit du Hack].

(Хакеры, ГосДеп, Навальный, Собчак, Потупчик, Чуров. Спонсоры, не спите!)

16 апреля 2012 г.

Черный ход в корпоративную крепость

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

Читать далее на bankir.ru

3 апреля 2012 г.

30 марта 2012 г.

V Форум ИТ-безопасность для финансового сектора

Выступал с презентацией про анализ защищенности банковских систем.

Впервые решил попробовать сделать презентацию в Prezi для публичного выступления.

18 марта 2012 г.

RuCTF quals


Закончились отборочные RuCTF, предварительные результаты тут.

К слову, в субботу вечером на blackbox началась DDoS атака, борьба с которой привела к часовой недоступности ресурса. С одной стороны это популярность, с другой непонятно кому надо было ддосить соревнования CTF. Желающим показать свой крутой нрав можно было сделать это уделав всех участников, а тупой ддос больше похож на беспомощные потуги доказать свою значимость.

p.s.: прелесть BlackBox в том, что почти все задания на нем можно продолжать решать даже после окончания соревнований, но уже в личный рейтинг.

16 марта 2012 г.

Семинар «Особенности обеспечения информационной безопасности банков»

Вчера рассказывал об анализе ДБО, показывал не очевидные ошибки и их последствия. Презентацию выкладывать смысла нет, суть была не в ней.

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

5 марта 2012 г.

Безопасность систем дистанционного банковского обслуживания

За последние годы система дистанционного банковского обслуживания превратилась из дополнительного в основной инструмент предоставления услуг. К такому результату привели несколько процессов. Это и общее распространение онлайн технологий, предоставляющих пользователям максимальную мобильность и удобство. И перевод всех доступных операций «в сеть», что позволяет существенно снизить затраты на оказание услуг в отделениях банка. Положительный как для клиента, так и для банка сценарий закономерно привел к тому, что дистанционное обслуживание (ДБО) сегодня у банков в приоритете.

Читать дальше на bankir.ru

28 февраля 2012 г.

CTF news

LeetChicken заняли первое место в отборочных CODEGATE 2012. Круто.

* * *

Отборочные RuCTF 2012 пройдут 16-18 марта на базе blackbox

* * *

Defcon CTF в этом году будет юбилейным (20 лет) и более масштабным, по мимо 11 команд прошедших отбор и команды победителя прошлого года, к участию приглашаются 8 команд, занявших первые места в прочих CTF (что забавно, в том числе PHD CTF).

К слову PHD CTF 2012 пройдет в мае и будет крайне интернациональным

27 февраля 2012 г.

3-D Secure inside

Первый подход к снаряду, для общего представления о технологии.

17 января 2012 г.

Уязвимость в системе FrequentLine

FrequentLine — система повышения лояльности клиентов авиакомпаний.

Аутентификация пользователей производится на основании пары: номер карты + пин-код.

Номера карты размером в 13 цифр генерируются по алгоритму Луна, с большой долей вероятности последовательно.

Уязвимость заключается в реализации системы восстановления пароля. Если к номеру привязан адрес электронной почты (что истинно скорее для 90% номеров), то восстановление осуществляется при введении номера карты, путем отправки нового пароля. Пароль одинаковый для всех пользователей.

Страница пользователя содержит — персональные данные (в том числе паспортные), информацию о перелетах.

Все естественно лишь догадки автора, публикуется для информации.