12 марта выступаю на IDC IT Security Roadshow 2014
upd:
6 марта 2014 г.
19 февраля 2014 г.
Семинар по безопасности платежных карт RISSPA
27 февраля выступаю на семинаре по безопасности платежных карт RISSPA в Спб
Вход свободный после регистрации.
upd:
Вход свободный после регистрации.
upd:
8 ноября 2013 г.
PCI DSS 3.0
Официальный релиз https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf
Будет время распишу об изменениях.
Будет время распишу об изменениях.
15 октября 2013 г.
26 июня 2013 г.
ИБ лайфхаки
Создание сложного пароля из одной буквы в iOS:
Отфильтровка спама по ключевым словам "unsubscribe" и "отписаться"
может боян, но понравилось
Отфильтровка спама по ключевым словам "unsubscribe" и "отписаться"
может боян, но понравилось
17 февраля 2013 г.
5 февраля 2013 г.
Что такое iCVV
Как известно CVV (Card Verification Value) – это проверочное значение
использующееся для авторизации карты Visa при безпиновой транзакции. Значение CVV высчитывается
на основе номера карты, срока действия и
сервис кода. (подробности)
iCVV – это проверочное значение хранящееся на чипе, оно
эквивалентно по функциям значению CVV, но при его расчетах за величину сервис кода принимают значение
«999».
Таким образом значения CVV и iCVV различны.
Сделано это с целью противодействия мошенничеству связанному
с перехватом данных передаваемых от чипа и изготовлением на основании их поддельной
магнитной полосы.
22 января 2013 г.
Перевод Руководства по оценке рисков в рамках PCI DSS
Коллеги из бюро технических переводов «Альянс ПРО» перевели документ PCI DSS Risk Assessment Guidelines v1.0.
Текст доступен (в том числе для комментирования) по ссылке.
Документ ориентирован на процесс оценки рисков, требуемой в рамках выполнения стандарта PCI DSS и имеет рекомендательный статус.
Текст доступен (в том числе для комментирования) по ссылке.
Документ ориентирован на процесс оценки рисков, требуемой в рамках выполнения стандарта PCI DSS и имеет рекомендательный статус.
10 декабря 2012 г.
Хранение критичных данных в соответствии с PCI DSS
Периодически приходится сталкиваться со мнением, что в рамках PCI DSS запрещено к хранению только полное содержание треков магнитной полосы, но не их отдельные части, в том числе CVC, PVV, PVKI.
Это ложь. Хранение всей информации, идущей после сервис-кода запрещено:
(источник: Navigating the PCI DSS v2.0)
Что логично, т.к. CVC, PVV, PVKI - величины используемые для авторизации транзакций.
Это ложь. Хранение всей информации, идущей после сервис-кода запрещено:
(источник: Navigating the PCI DSS v2.0)
Что логично, т.к. CVC, PVV, PVKI - величины используемые для авторизации транзакций.
29 ноября 2012 г.
14 ноября 2012 г.
Skype epic fail
Утренняя радость от Skype. Что интересно в данной ситуации, что за 12 часов компания разработчик так и не придумала никаких компенсационных мер, ну хотя бы банально запретили регистрировать на один e-mail несколько аккаунтов до решения проблемы в более глобальном плане.
Что по хорошему должно происходить в такой ситуации?
В организациях, где используется Skype:
- ответственные за выявление новых уязвимостьей должны сразу при обнаружении проблемы оповестить ответственных за ИТ, и сообща:
а) протестировать проблему на работоспособность
б) разработать план временного решения (например сменить привязку на новый, случайно сгенерированный e-mail)
в) оповестить руководителей подразделений о проблеме и возможных путях решения
- сотрудники без-ти выборочно проверить, что временное решение было сотрудниками принято;
- при выходе обновлений закрывающих уязвимость, произвести его установку, проверить, что оно действительно помогает избежать обозначенные проблемы, оповестить сотрудников, что проблема решена.
В компании разработчиков:
- ответственный за отслеживание информации о продукте, в том числе уязвимостей, оповещает руководство и ответственных разработчиков.
- выбирается предварительный план решения проблемы.
- пользователи оповещаются о проблеме, пути ее временного решения и сроках устранения.
- продумывается план устранения последствий уязвимости, откат базы данных, отмена последних регистраций;
- проблема устраняется, проверяется корректность устранения и смежные возможные бреши, выпускается обновление безопасности.
- всей ситуации должен быть присвоен максимальный уровень критичности, с соответствующим включением максимального количества сотрудников для оперативного реагирования и закрытия уязвимости.
Что происходит по факту?
Доступное описание эксплуатации уязвимости позволяет практически любому пользователю ее провести, служба поддержки Skype никого не оповещает ни о методах, ни о сроках решения.
update: 14 часов потребовалось разработчикам, что бы предложить временное решение - отключить функцию восстановления паролей.
Забавно, что сейчас легитимные пользователи у которых поменяли пароль, но не поменяли почту, не смогут вернуть себе аккаунт :)
Что по хорошему должно происходить в такой ситуации?
В организациях, где используется Skype:
- ответственные за выявление новых уязвимостьей должны сразу при обнаружении проблемы оповестить ответственных за ИТ, и сообща:
а) протестировать проблему на работоспособность
б) разработать план временного решения (например сменить привязку на новый, случайно сгенерированный e-mail)
в) оповестить руководителей подразделений о проблеме и возможных путях решения
- сотрудники без-ти выборочно проверить, что временное решение было сотрудниками принято;
- при выходе обновлений закрывающих уязвимость, произвести его установку, проверить, что оно действительно помогает избежать обозначенные проблемы, оповестить сотрудников, что проблема решена.
В компании разработчиков:
- ответственный за отслеживание информации о продукте, в том числе уязвимостей, оповещает руководство и ответственных разработчиков.
- выбирается предварительный план решения проблемы.
- пользователи оповещаются о проблеме, пути ее временного решения и сроках устранения.
- продумывается план устранения последствий уязвимости, откат базы данных, отмена последних регистраций;
- проблема устраняется, проверяется корректность устранения и смежные возможные бреши, выпускается обновление безопасности.
- всей ситуации должен быть присвоен максимальный уровень критичности, с соответствующим включением максимального количества сотрудников для оперативного реагирования и закрытия уязвимости.
Что происходит по факту?
Доступное описание эксплуатации уязвимости позволяет практически любому пользователю ее провести, служба поддержки Skype никого не оповещает ни о методах, ни о сроках решения.
update: 14 часов потребовалось разработчикам, что бы предложить временное решение - отключить функцию восстановления паролей.
Забавно, что сейчас легитимные пользователи у которых поменяли пароль, но не поменяли почту, не смогут вернуть себе аккаунт :)
Подписаться на:
Сообщения (Atom)

