FCA EMI (Financial Conduct Authority Electronic Money and Payment Institutions)

В случае если вы планируете работать с электронными платежами, то получение лицензии FCA EMI (Financial Conduct Authority Electronic Money and Payment Institutions) в Британии позволит вам выполнять такие задачи на территории Европейского экономического пространства (с возможностью дополнительной сертификации). 

Стоимость пошлины от 1000 фунтов при годовом обороте до 3 млн. фунтов и 5000 фунтов если больше. Потребуется юридическое лицо в Британии с уставным капиталом 350 тыс евро.

Процесс получения лицензии законодательно определен и составляет 12 месяцев.

В рамках подготовки документов потребуется информация о процессах и системах безопасности, отчетности и аудита. 

По ссылкам ниже можно найти больше официальной информации: 1 и 2.

Растущие риски удаленной работы и как с этим справиться

Прошло уже больше месяца после начала карантина, а компании перевели на удаленную работу сотрудников.

За это время большинство компаний: 

1. Начали экономить и остановили часть проектов.

2. Перевели сотрудников на удаленную работу.

3. Урезали бонусы и выплаты.

4. Ограничили или отменили внешние обучения.

5. Остановили набор сотрудников, а некоторые и вовсе сократили штат. 

Как следствие

1. Периметр информационной инфраструктуры размыт.

2. Количество утечек растет.

3. Сотрудники менее лояльны.

4. Бюджеты на решения и функции безопасности сокращаются.

5. Риски увеличиваются.

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

1. Появились вирусы, рассылки и приложения посвященные COVID (1, 2, 3).

2. Zoom и TeamViewer не панацея, а угроза (1 и 2).

3. Проникновение в инфраструктуру (1).

Хотелось бы написать, что для решения актуальных вопросов безопасности нужно внедрять DLP, IDM, SSO, BYOD и прочие мудреные и дорогие системы, но в ограниченных сроках и уменьшающихся бюджетах для большинства компаний это не реально. 

Что же реально можно сделать? 

1. Пересмотреть или провести анализ рисков.

2. Проанализировать и описать новые процессы.

3. Провести обучения персонала требованиям безопасности. 

4. Уделить дополнительное внимание мониторингу инцидентов.

5. Обратить внимание как организован удаленный доступ.

6. Построить процессы передачи информации. 
7. Попросить у производителей бесплатные лицензии на ограниченный период, если они предоставляют такую возможность. Рассмотреть внедрение бесплатных или условно бесплатных решений (но не решений с взломанными или ворованными ключами). Ничего совсем бесплатно не бывает - вы просто сами таким образом установите троян в своей инфраструктуре.

8. Внедрить везде где используется удаленный доступ - 2FA. 

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

10. Привлечь специалиста по безопасности на контрактной основе с четко оговоренными KPI, что эффективнее и дешевле, чем специалист в штате.

Также будет полезно прочесть предыдущую статью по данной теме. 

Лицензия DLT для “криптокомпаний”

Около двух лет назад, с 1 января 2018 года для компаний, которые работают с технологиями блокчейн доступна лицензия DLT, которая предоставляется комиссией по финансовым услугам Гибралтара (GFSC). 

Требования содержат в себе ряд финансовых и репутационных требований, а также требований по взаимодействию с клиентами, раскрытии их данных и пр.  

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

Стоимость - 2000 фунтов для рассмотрения заявки.
Лицензирование от 10 до 30 000 тысяч фунтов.

Как правило получение такой лицензии занимает от 6 месяцев до 1 года.

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

Пока все дома. Безопасность удаленной работы.

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

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

ПК сотрудника. На ПК сотрудника, личный он или корпоративный должно ОБЯЗАТЕЛЬНО стоять антивирусное ПО. Без него время заражения ПК с подключением к глобальной сети Internet исчисляется часами. Также рекомендовано использовать персональные межсетевые экраны.

Программы удаленного доступа. Например, одна из самых популярных: TeamViewer - может быть уязвима в ряде версий. Сторонний человек может получить доступ к вашему ПК и выполнить действия для вывода денег или краже информации. Если вам нужно настраивать ПК удаленно пользуйтесь только последней официальной версией с включенным 2 FA. И вообще откажитесь от не лицензионного ПО на ПК с критичной или финансовой информацией, так как бесплатно это значит что кто-то за это платит. В лучшем случае это реклама или майнинг, в худшем троян, который ворует у вас информацию и деньги.   

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

Передача информации. Следует помнить, что вся передаваемая информация на флеш накопителях или по почте должна быть зашифрована. Можно использовать контейнеры Truecrypt, создавать запароленные архивы или использовать PGP. В любом случае это должна быть шифрованная передача информации любыми каналами - флеш накопитель, почта или мессенджеры. В противном случае не один канал не гарантирует безопасности передачи данных.

Сервисы. Если вы используете Google Docs озаботьтесь кому и на какой срок вы предоставляете доступ к документам. Если пользуетесь почтой, это должна быть именно корпоративная почта. Настоятельно рекомендую включить двухфакторную аутентификацию (2FA) для доступа ко всем важным сервисам. 

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

Непрерывность бизнеса. Если у вас не внедрены процессы BCM (процессы непрерывностью бизнеса) то сейчас самое время озаботится этим вопросом. Описать процессы и подготовить планы реагирования. А если таковые есть, то это отличная возможность их протестировать. И начать стоит, например, с проверки систем бекапирования. 

Если у вас есть вопросы или необходима консультация по вопросам безопасности - обращайтесь на почту, буду рад помочь.    

PSD(2). Что мы об этом знаем?

Еще в декабре 2015 года была опубликована директива об оказании платежных услуг Payment Services Directive (EU) 2015/2366 (PSD2). Которая в 2018 году вступила в силу. 

И хотя времени прошло немало, но тема не слишком популярна за пределами профильных кругов.

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

Внедрения требований строгой аутентификации клиентов для совершения платежа (кроме малых платежей 30-50 Евро) с сентября 2019 года. Но окончательные сроки внедрения для разных стран ЕС остаются открытыми из-за неготовности соответствующих органов и инфраструктуры. Механизм правового регулирования на территории разных стран ЕС тоже вызывает затруднения.

Часть требований коррелирует с основами GDPR о минимально необходимой достаточности сбора персональных данных и их безопасности.

В целом очень интересный нишевый документ, который может быть рассмотрен во взаимодействии с требованиями PCI DSS и GDPR. 

И несколько ссылок для более детального ознакомления - 1, 2 и 3.

Draft PCI DSS 4.0

Все мы давно ждали стандарт PCI DSS 4.0.  И вот недавно появилась предварительная версия PCI DSS 4.0. Минимум год еще потребуется для согласования и официальной публикации стандарта. Потом конечно же будет переходной период, когда можно будет делать аудит еще по PCI DSS 3.2.1. 

Что же интересного можно найти в данном документе? 

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

А что же в реальности? 

В реальности в документе целых 46 новых требований. И ряд уточнений по разделам документа PCI DSS 3.2.1. Немало, но их уровень можно описать как “побелить- покрасить”. Где-то поменяли частоту выполнения требований, где-то скоуп оценки или контроля, где-то антивирус заменили на antimalware, брандмауеры и маршрутизаторы на средства управления сетевой безопасностью. Некоторые изменения коснулись отчетности для аудиторов. 

Это все конечно важно и хорошо, уточнения это отлично. Но где новая версия стандарта? 

Эти все улучшения и уточнения, это PCI DSS 3.3, но ни как не PCI DSS 4.0.

Понятно, что требования к разработке вынесли в отдельный стандарт. Но его скоуп применимости отличается от требований PCI DSS, а разработка зачастую присутствует в обоих случаях. 

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

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

Все самое нужно по GDPR

1. Вышел обновленный перевод GDPR - тут.

2. Много полезной информации по GDPR - тут.

3. Самоопросники на сайте ICO - тут.

4. Штрафы GDPR - тут.

5. Актуальное по GDPR - тут.

Бонус.

Взломы криптовалютных бирж

Вчера я читал презентацию и в рамках доклада приводил ссылки

на информационные ресурсы по взлому криптобирж за последнее время.

Так как было много просьб опубликовать эту информацию - публикую.

Ниже вы можете найти некоторые ссылки на ресурсы и публикации по взлому криптовалютных

бирж - 1  2  3

Вот визуализация данных одной из публикаций

Или вот еще интересные данные

Вообщем читайте первоисточники, там интересно.

Длинный BIN на стандартном PAN

В данной статье хотел бы поделиться очень коротким и простым, но очень полезным по моему мнению документом.

Вопрос длинных BIN на стандартной длине номера карты (16) с точки зрения PCI DSS не так и
просто решить. PCI DSS разрешает оставлять 6 первых и 4 последних цифры номера карты и
никаких других  рекомендаций не дает. Возможно, будут рекомендации в PCI DSS 4.0 но пока их
нет. От представителей платежных систем я также не смог получить детальных рекомендаций. 

Есть рекомендации отдельно от VISA и MASTERCARD как поступать в случае более
длинных BIN (7+) на длинных номерах карт (17+). Но как поступать с длинными BIN на
стандартных 16 цифрах не всегда понятно. 

Решение очень простое и весьма логичное - оставлять суммарное количество не маскированных
цифр таким же, как того требует стандарт - 10. Но вместо 6+4 использовать, например 8+2. Да, это повышает вероятность коллизий среди пользователей одного банка, но зато сохраняет стойкость.
Кроме того, в разных процессах зачастую требуется разная информация. И там, где нужен полный
BIN возможно вовсе не нужны последние цифры карты (например, для определения через какой платежный шлюз направить транзакцию для более выгодной комиссии). А для идентификации пользователя может быть вполне достаточно классических 6+4. 

Ну и стоит помнить, что нужно принять меры для невозможности сопоставления данных одной
карты с разными маскированными элементами. 

GDPR. Штрафы

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

На официальном ресурсе ICO нашел занимательную информацию по штрафам - оригинал.

1. Используйте шифрование при хранении информации. 150 000 фунтов штрафа за утерю DVD диска с не зашифрованной информацией. 80 000 фунтов штрафа за украденную карту памяти. 150 000 фунтов за утерю носителей резервных копий с персональными данными.

2. Используйте шифрование при передаче информации. 120 000 фунтов за ошибку в адресе получателя при отправке электронной почты. Информация была не зашифрована. 75 000 фунтов за передачу персональных данных по ФАКСУ (его еще используют :-)) ошибочному получателю.  

3. Используйте шифрование при обработке информации. 150 000 фунтов за потерю двух не шифрованных ноутбуков с персональными данными. 

Если вы все еще думаете, стоит ли соответствовать требованиям GDPR, то теперь уже вывод очевиден. Однозначно стоит. Более детально тут.