25 июля 2016 г.
25 сентября 2015 г.
SDL or SDLC or SSDLC
С терминологией в ИБ все плохо. Маркетинг, невежество, журналисты делают свое дело. Встал вопрос об именовании процессов обеспечения ИБ при создании ПО.
Коллеги называют это - SDLC. Но для разработчика ПО, SDLC = Systems (или Software) development life cycle.
Я ранее склонялся еще одному часто употребимому сокращению - SDL (Security development life cycle). Но это наименование четко ассоциируется с тем, что предлагает Microsoft и вносит путаницу, когда речь идет о процессах впринципе, а не о конкретном подходе.
Наиболее удачное оказывается наименование и сокращение - SSDLC (Security software development life cycle). Длинно, но однозначное и без лишних ассоциаций.
Коллеги называют это - SDLC. Но для разработчика ПО, SDLC = Systems (или Software) development life cycle.
Я ранее склонялся еще одному часто употребимому сокращению - SDL (Security development life cycle). Но это наименование четко ассоциируется с тем, что предлагает Microsoft и вносит путаницу, когда речь идет о процессах впринципе, а не о конкретном подходе.
Наиболее удачное оказывается наименование и сокращение - SSDLC (Security software development life cycle). Длинно, но однозначное и без лишних ассоциаций.
3 марта 2015 г.
Социальная инженерия
Прокомментировал отчет Intel Security посвященной социальной инженерии на сайте BISA
2 марта 2015 г.
10 сентября 2014 г.
11 августа 2014 г.
1 апреля 2014 г.
Общие принципы устройства процессинга
На прошлой неделе, по сообщениям средств массовой информации,
международные платежные системы Visa и MasterCard прекратили
обслуживание платежных карт, выпущенных рядом российских банков. Событие
вызвало большой резонанс среди пользователей платежных карт и повлекло
за собой массовое снятие наличных средств.
Такие последствия возникли, однако, не от реальной угрозы, а в результате недостаточной информированности клиентов об организации платежных систем и принципах обработки безналичных платежей. Ниже я постараюсь в общих чертах дать представление о том, как устроен процесс обслуживания карт, и от чего он зависит.
продолжение - http://www.infosec.ru/news/experts/5308
Такие последствия возникли, однако, не от реальной угрозы, а в результате недостаточной информированности клиентов об организации платежных систем и принципах обработки безналичных платежей. Ниже я постараюсь в общих чертах дать представление о том, как устроен процесс обслуживания карт, и от чего он зависит.
продолжение - http://www.infosec.ru/news/experts/5308
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 - величины используемые для авторизации транзакций.
Это ложь. Хранение всей информации, идущей после сервис-кода запрещено:
Что логично, т.к. 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)