arekusux

Презентация "Антифрод на полную мощность"

noreply@blogger.com (Alexey Babenko) — Mon, 25 Jul 2016 08:34:00 +0000

Антифрод на полную мощность from Alex Babenko

SDL or SDLC or SSDLC

noreply@blogger.com (Alexey Babenko) — Fri, 25 Sep 2015 08:58:00 +0000

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

Коллеги называют это - SDLC. Но для разработчика ПО, SDLC = Systems (или Software) development life cycle.

Я ранее склонялся еще одному часто употребимому сокращению - SDL (Security development life cycle). Но это наименование четко ассоциируется с тем, что предлагает Microsoft и вносит путаницу, когда речь идет о процессах впринципе, а не о конкретном подходе.

Наиболее удачное оказывается наименование и сокращение - SSDLC (Security software development life cycle). Длинно, но однозначное и без лишних ассоциаций.

Социальная инженерия

noreply@blogger.com (Alexey Babenko) — Tue, 03 Mar 2015 11:29:00 +0000

Прокомментировал отчет Intel Security посвященной социальной инженерии на сайте BISA

Комментарии о разном

noreply@blogger.com (Alexey Babenko) — Mon, 02 Mar 2015 12:30:00 +0000

Потери мировой экономики от киберпреступлений выросли в 1,5 раза за 2013 г.

Против взлома – нет приема

Опасности IoT

Знакомьтесь: контроль кода

Когда эквайер становится сервис провайдером

noreply@blogger.com (Alexey Babenko) — Wed, 10 Sep 2014 14:06:00 +0000

Рассуждения по поводу сабжа на сайте Информзащиты

Мастер-класс «Цикл безопасной разработки»

noreply@blogger.com (Alexey Babenko) — Mon, 11 Aug 2014 07:38:00 +0000

19 августа в 10:00 проведу вэбинар. Подробности на сайте RISC

upd:

RuCTF 2014

noreply@blogger.com (Alexey Babenko) — Tue, 01 Apr 2014 08:22:00 +0000

19 апреля буду рассказывать про социальную инженерию на RuCTF 2014

Общие принципы устройства процессинга

noreply@blogger.com (Alexey Babenko) — Tue, 01 Apr 2014 08:14:00 +0000

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

продолжение - http://www.infosec.ru/news/experts/5308

IDC IT Security Roadshow 2014

noreply@blogger.com (Alexey Babenko) — Thu, 06 Mar 2014 07:05:00 +0000

12 марта выступаю на IDC IT Security Roadshow 2014

upd:

Семинар по безопасности платежных карт RISSPA

noreply@blogger.com (Alexey Babenko) — Wed, 19 Feb 2014 08:27:00 +0000

27 февраля выступаю на семинаре по безопасности платежных карт RISSPA в Спб

Вход свободный после регистрации.

upd:

Разработка ПО в рамках PCI DSS from Alex Babenko

Презентация Аудитор vs СМИ

noreply@blogger.com (Alexey Babenko) — Wed, 19 Feb 2014 08:25:00 +0000

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

PCI DSS 3.0

noreply@blogger.com (Alexey Babenko) — Fri, 08 Nov 2013 11:15:00 +0000

Официальный релиз https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf
Будет время распишу об изменениях.

Встроенное качество в процедуры ИБ

noreply@blogger.com (Alexey Babenko) — Tue, 15 Oct 2013 14:45:00 +0000

Презентация с выступления на Infobez-Expo

Все что говорил включил в описание к слайдам.

ИБ лайфхаки

noreply@blogger.com (Alexey Babenko) — Wed, 26 Jun 2013 10:02:00 +0000

Создание сложного пароля из одной буквы в iOS:

Отфильтровка спама по ключевым словам "unsubscribe" и "отписаться"

может боян, но понравилось

Презентация с Уральского форума

noreply@blogger.com (Alexey Babenko) — Sun, 17 Feb 2013 08:04:00 +0000

Хорошо забытое старое.

Что такое iCVV

noreply@blogger.com (Alexey Babenko) — Tue, 05 Feb 2013 07:21:00 +0000

Как известно CVV (Card Verification Value) – это проверочное значение использующееся для авторизации карты Visa при безпиновой транзакции. Значение CVV высчитывается на основе номера карты, срока действия и сервис кода. (подробности)

iCVV – это проверочное значение хранящееся на чипе, оно эквивалентно по функциям значению CVV, но при его расчетах за величину сервис кода принимают значение «999».

Таким образом значения CVV и iCVV различны.

Сделано это с целью противодействия мошенничеству связанному с перехватом данных передаваемых от чипа и изготовлением на основании их поддельной магнитной полосы.

Перевод Руководства по оценке рисков в рамках PCI DSS

noreply@blogger.com (Alexey Babenko) — Tue, 22 Jan 2013 09:30:00 +0000

Коллеги из бюро технических переводов «Альянс ПРО» перевели документ PCI DSS Risk Assessment Guidelines v1.0.
Текст доступен (в том числе для комментирования) по ссылке.

Документ ориентирован на процесс оценки рисков, требуемой в рамках выполнения стандарта PCI DSS и имеет рекомендательный статус.

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

noreply@blogger.com (Alexey Babenko) — Mon, 10 Dec 2012 09:21:00 +0000

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

Это ложь. Хранение всей информации, идущей после сервис-кода запрещено:

(источник: Navigating the PCI DSS v2.0)

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

О PCI P2PE в общих чертах

noreply@blogger.com (Alexey Babenko) — Thu, 29 Nov 2012 10:09:00 +0000

Skype epic fail

noreply@blogger.com (Alexey Babenko) — Wed, 14 Nov 2012 08:48:00 +0000

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

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

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

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

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

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

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

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

noreply@blogger.com (Alexey Babenko) — Tue, 13 Nov 2012 07:04:00 +0000

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

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

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

Одноразовый пароль для мобильного банкинга.

noreply@blogger.com (Alexey Babenko) — Wed, 24 Oct 2012 14:48:00 +0000

Забавно выглядит использование одноразового пароля пересланного по смс для мобильного банкинга.

Полностью автоматизированный публичный тест Тьюринга для различия компьютеров и людей

noreply@blogger.com (Alexey Babenko) — Tue, 16 Oct 2012 13:31:00 +0000

Интересная подборка различных CAPTCHA на сайте lenta.ru.

Только с большинством образцов машина как раз быстрее и лучше человека справится.

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

noreply@blogger.com (Alexey Babenko) — Fri, 05 Oct 2012 09:43:00 +0000

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

Добрый день, уважаемый пользователь.

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

С уважением, служба технической поддержки mail.ru.

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

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

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

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

Зри в корень

noreply@blogger.com (Alexey Babenko) — Wed, 03 Oct 2012 05:27:00 +0000

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

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

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

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

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

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