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

В данной статье я хочу описать основные этапы подготовки к аудиту безопасности. Чаще всего это аудит соответствия стандартам безопасности серии ISO (27***) или PCI DSS, либо выполнение требований соответствия GDPR.

Мой опыт в области информационной безопасности 12 лет. За это время мной были выполнены проекты с десятками компаний из США, Британии, Китая, России, Украины и стран Европы. Клиентами были как крупные процессинговые центры и банки, так и ИТ компании разной специализации. Результаты внедрения оценивали PWC (Hongkong), VISA (USA), Deloitte (UKR) и успешно подтвердили соответствие требованиям, о чем можно посмотреть в рекомендательных письмах на сайте и отзывах в профиле Linkedin.  

Надеюсь, что мой опыт проведения аудитов, консалтинга и курирование проектов по приведению компаний в соответствие требованиям стандарта PCI DSS, VISA & MASTERCARD  Security поможет мне простыми словами донести полезную информацию до читателей.

Накопившийся опыт и знания, наблюдения и замечания я бы хотел выразить в данной статье на примере подготовки к аудиту соответствия стандарту PCI DSS. Все высказанное в данной статье может значительно отличатся от мнений других аудиторов и консультантов, официальной позиции PCI Security Standards Council и других источников. Я не предлагаю неукоснительно следовать всему, о чем будет идти речь. Это всего лишь информация для принятия Вами собственных решений. Надеюсь, она будет полезной для читателей.

Итак, с чего же начинается и как проходит аудит?
Все начинается даже не с подписания договора на аудит или пред аудит. Все начинается с решения компании (чаще директора или менеджера) о необходимости прохождения аудита.

И тут есть два варианта развития событий: аудит необходимо пройти по требованию клиентов или платежных систем, что бывает чаще, либо аудит инициируется и отстаивается перед директором компании (главой правления, материнской компанией) начальником отдела информационной безопасности (ИБ) или менеджером - реже. В первом случае аудит спускается как «Божья кара» на сотрудников ИТ и ИБ подразделений, так как дополнительной работы добавится, в должностных инструкциях ее может и не быть, а зарплата остается на прежнем уровне. Тут все зависит от коллектива, руководителя ИБ и конкретной компании. Если коллектив удастся мотивировать, чем – это уже вопрос менеджмента и к данной статье не относится, то результат, безусловно, будет. Результат будет, даже в том случае если персонал будет не мотивирован, но применяться будет уже иной метод – метод кнута. Но вот трудностей возникнет больше.

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

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

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

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

Если есть необходимость пройти аудит, а не построить процессы (заранее говорю, что часть требований PCI DSS особенно в части документирования процессов тормозит работу самих бизнес-процессов). То лучше обратится к маленькому локальному игроку рынка. Аудиторы такой компании, как правило, более лояльны к формам реализации требований PCI DSS. Если же хочется получить не только толстый отчет, но и консалтинг в рамках его проведения то однозначной рекомендации нет. Выбирайте именно аудитора. Если же нужен красивый отчет с печатью известной компании – выбор очевиден, международная известная компания. Окончательный выбор только за Вами.

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

Если не планируется привлекать профильного специалиста или консультанта на этапе подготовки, то проводить внутренний аудит придется собственными силами. Результатом аудита должен стать не отчет, а согласованный план-график устранения несоответствий (пример таблицы аудита, разделов отчета и плана графика приведен в Приложениях 1-3). 

Приложение 1

Приложение 2

Приложение 3

И вот для того, чтобы получить данный план, необходимо провести детальный анализ инфраструктуры, документации, процессов и интервьюирование персонала. Выполнение данной задачи позволит понять уровень зрелости процессов компания и выявить самые большие прорехи.
Основные моменты, на которые стоит обратить внимание в рамках устранения несоответствий можно разделить на следующие:
1.    Подготовка либо внесение изменений в регуляторные документы.
2.    Подготовка актов, реестров, планов тестирования и иной отчетности.
3.    Модернизация и внесение изменений в конфигурацию систем и ПО.
4.    Проведение внутренних и внешних сетевых сканирований и обработка их результатов.
5.    Проведение тестов на проникновение.
6.    Проведение обучений и тестирование планов реагирования.
7.    Анализ прав доступа в логических и физических системах.

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

Думаю, не стоит говорить, что нет компании, в которой бы абсолютно все было без нарушений. На то есть разные причины: слишком большие затраты на выполнение требований, нарушение или разрушение реальных бизнес-процессов при исполнении требований, исторически сложившиеся процессы. И тут все зависит от того, что покажут аудитору или, что он увидит или найдет. Опять-таки не стоит забывать о возможности применения компенсационных мер.
В случае отсутствия возможности привлечения профильного консультанта, при подготовке к аудиту, безусловно, необходим человек компетентный в области аудита и стандартов, или тот, кто быстро может стать таковым (специалист смежной сферы). Так как аудиторам и представителям компании крайне желательно понимать друг друга, обладать высоким уровнем компетенций в сфере, подлежащей аудиту. Когда проектом по прохождению аудита соответствия руководит не мотивированный и некомпетентный в вопросах проектного менеджмента и стандартов ИБ человек, вероятность его успешного прохождения сильно уменьшается, а сроки и бюджет проекта, наоборот увеличиваются. Исключение могут составлять случаи, когда за все уплачено заранее. Но в таком случае, наверное, даже не стоит вести сам проект.

Поговорим более детально по перечисленным ранее пунктам.

1.    При разработке и редактировании документов используется очень простой принцип. Необходимо, чтобы все процессы, подлежащие документированию в рамках требований PCI DSS, были документированы.  
Из нюансов рекомендую обратить внимание, что это чревато тем, что большинство процессов так и останутся только на бумаге. Прописывая, тот или иной процесс в документах думайте, как он будет выполняться персоналом. Как это ни банально, но это действительно важно.
2.    Достаточно длинный перечень ежемесячных, ежеквартальных и прочих актов должен готовиться сотрудниками компании. Если прибавить к этому актуализацию реестров, планов, анализ и обработка результатов сканирования и обработку рисков, а также документацию по реагированию на инциденты, то стопка за год, может быть толще качественной кирпичной кладки (хотя возможно, что и в электронной форме). Нужно понимать, что лучше готовить ее на протяжении года. Хотя часто ее делают непосредственно перед аудитом. Тут уже вопрос корректности процессов. В конце концов, все направлено на повышение уровня безопасности и логичнее все делать вовремя. Ведь все равно делать придется.
3.    Системы требуют постоянных обновлений, изменения настроек и параметров конфигураций. Для этого необходимо иметь в штате компетентных специалистов, отслеживать частоту и правильность установки обновлений. Соответствие паспортам конфигураций. Это периодическая и очень затратная по времени часть работ. Кстати, это можно автоматизировать. Я писал об этом, когда рассматривал вопрос «Построение процессов управления уязвимостями и соответствием» тут.
4.    Для проведения внутренних сканирований достаточно использовать любой более-менее качественный сетевой сканер с последними обновлениями. И разворачивать целый комплекс по управлению сетевыми уязвимостями в рамках соответствия PCI DSS совсем не обязательно.  А вот что обязательно – это обработка результатов сканирования. Все уязвимости, которые не могут быть устранены должны быть проанализированы. И если уязвимость обнаружена не ошибочно, для нее должны быть разработаны и внедрены компенсационные меры.
Что же касается ежеквартального сканирования внешнего периметра (ASV) то достаточно просто купить лицензию на необходимое количество IP и проводить 4 раза в год сканирование самостоятельно. Естественно – это для тех случаев, когда у Вас нет уязвимостей в сканируемой инфраструктуре. А их не должно быть.
5.    В рамках подготовки к тесту на проникновение по приоритетности я бы выделил следующие особенности:
- Донесение до сотрудников компании, что можно, а чего делать нельзя.
- Контроль мест хранения карточных данных.
- Обновление систем.
Именно в этой последовательности, как правило, возникают проблемы в рамках теста на проникновение.
6.    Обучение сотрудников является неотъемлемой частью улучшения безопасности. Но вот если у вас не все процессы, прописанные на бумаге, работают в действительности, то это как раз возможность рассказать сотрудникам кому и как они должны отвечать на вопросы. Чтобы в рамках интервьюирования сотрудников не выяснилось, что далеко не все процессы, отраженные на бумаге, используются в действительности.
Что касается планов реагирования, то если за текущий отчетный период они применялись нужно подготовить свидетельства. В противном случае – провести тестирование планов реагирования по результатам - составить акты.
7.    Также обязательно контролировать доступ пользователей к системам. При этом если это выполняется сугубо для галочки, то так тому и быть. Но если Вы хотите наладить процессы и обеспечить реальный процесс разграничения доступа, то сначала нужно строить процесс, а потом проводить аудит. А не наоборот. Так как при неработающем процессе у Вас очень быстро все вернется на круги своя и усилия будут напрасны.

Особое внимание хотелось бы уделить планированию работ и контролю их выполнения. Думаю, что для каждого проекта актуален вопрос недостатка ресурсов. Аудит в этом плане, наверное, самый лучший пример. Так как ни для одного из привлеченных отделов (может быть за исключением отдела безопасности) проект не является приоритетным. А поскольку основные проекты для задействованных подразделений никто не планирует останавливать, то отношения ждите соответствующего. А если Вы не заручились поддержкой руководства в этом вопросе… Но не будем о грустном.
Я являюсь сторонником ведения проектов по методологии PMBok, правда, позволяя себе сократить иногда количество отчетных бумажек. Данная методология позволяет корректно вести проекты и очень много вопросов, которые будут возникать у Вас в процессе ведения проекта уже предусмотрены заранее. Вот только если Вы с ней не знакомы, то потребуется время на ознакомление с ней и ее апробацию.
Какие бы ситуации не приходилось решать в рамках тех или иных проектов, это всегда немножко творчество. И еще опыт и крупицы знаний. Которые как раз можно почерпнуть в том числе, например из статей в профильной прессе. Я, например, почерпнул идеи из методологии SCRUM, которая к информационной безопасности и аудитам не имеет никакого отношения. Но пришлась как нельзя кстати.
Что касается несоответствий, то я бы рекомендовал относиться к найденным несоответствиям спокойно, если это не базовые несоответствия в архитектуре системы, недостатке оборудования, ПО или критичных, для компании процессах, которые ни коим образом не могут быть изменены.  Во всех остальных случаях от аудитора можно получить разъяснение, а часто и совет как это исправить самым простым образом. Вот только времени и денег на это может потребоваться значительно больше, чем планировалось изначально. Потому, лучше воспользоваться услугами профильного специалиста заранее. Но тут не нужно забывать о человеческих качествах и отношениях между людьми.

Непосредственно перед проведением аудита обязательно необходимо собрать всех сотрудников, которые будут участвовать в интервьюировании и провести совещание, где уточнить основные моменты предстоящего аудита и особенно обратить внимание на нюансы. Например, что администратору запрещается покидать рабочее место, не заблокировав компьютер при посторонних. На каждом аудите находится администратор, который выбегает, куда-то оставив при этом аудитора один на один с открытыми соединениями к подлежащим аудиту критичным серверам. Данное замечание не критично, и использовано как пример, но таких мелочей может накопиться достаточно много. Кроме того, обязательно согласуйте с коллегами, какую информацию не стоит разглашать аудитору ни в коем случае – об этом выше. Так как, услышав хоть какое-то несоответствие, аудитор обязательно распутает клубок – можете не сомневаться.
Перед аудитом будьте готовы к тому, что как бы вы все не планировали, вы не успеете устранить все несоответствия и выполнить все задачи, которые хотели к запланированным срокам. Так как в компании происходят непрерывные внесения изменений в системы, процессы, случаются авралы (обязательно в самый неподходящий момент), а сотрудникам кроме подготовки к аудиту нужно выполнять свои функциональные задачи. Рекомендую обязательно при планировании в зависимости от уровня зрелости процессов, загрузки сотрудников и своей сферы влияния закладывать от 10 до 35% дополнительного времени на риски.
Да вот еще, что касается решений, которые рекомендуют компании по результатам аудита. Нужно понимать, что как правило, компании, которые проводят аудит, имеют подразделения, которые занимаются внедрением определенных решений и систем. И можете не сомневаться, что независимо от их соответствия в полной мере вашим требованиям, рекомендовать к внедрению будут именно их. Просто имейте это виду. Ничего страшного в этом нет. Если подразделение компании обладает реально выполненными успешными проектами, а данное решение и цена за услуги вас устраивает – смело соглашайтесь. Просто имейте виду, что не стоит слепо полагаться на рекомендации и внедрять дорогостоящие системы, чтобы пройти аудит и забыть о них до следующего года.
И еще. Не воспринимайте аудитора как врага. Воспринимайте его как союзника. Часто, результаты аудита могут показать руководству, что у вас действительно не хватает ресурсов, технологий или бюджета, и что это не вы сами придумали необходимость наличия бесполезных «игрушек» для ИТ или ИБ. Смело говорите об этом аудитору, пусть пишет в отчете. Но помните, такое можно говорить при предварительном аудите или экспертном аудите, но уж никак не как несоответствие, на сертификационном. Так как в противном случае сертификата соответствия, вы можете и не увидеть. А руководство вместо дополнительных ресурсов и бюджета может наградить вас выговором или и вовсе уволить, за плохую работу и провал сроков проекта.
В целом могу сказать, что подготовка компании к аудиту на предмет соответствия требованиям стандарта PCI DSS (впрочем, как и любого иного) требует четкого планирования, упорства и выдержки. А также умения балансировать между документированными требованиями стандарта и их внедрения таким образом, чтобы они минимально влияли на работающие процессы в компании, при этом повышая их реальную безопасность. 

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

Актуальную и полезную информацию по PCI DSS можно найти на сайте.

PCI DSS v4.0 Transition Timeline

Краткая информация об изменениях в стандарте PCI DSS 4.0.

GDPR - все самое полезное

Собрал все самые полезные публикации касающиеся GDPR.

1. GDPR до 18 мая 18 года.
2. Как не потерять свой бизнес из-за GDPR.
3. ICO Chat.
4. Все самое нужное по GDPR.
5. GDPR для Калифорнии или CCPA.
6. Dubai International Financial Centre (DIFC) Data Protection Law No. 5 of 2020.
7. Штрафы.

Буду рад, если данная информация окажется полезной при подготовке.

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

Криптовалюты и фиатные платежные карты

В прошлом месяце Binance подтвердила выпуск платежной карты в партнерстве с Swipe.  

Еще в начале года Coinbase получила статус VISA Principal. Что сделало возможным дальнейший выпуск Coinbase Card.  

У VISA даже есть отдельная программа Fintech Fast Track которая обеспечивает ускоренную интеграцию с блокчейн стартапами. 

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

Данные нововведения безусловно позволят значительно проще использовать криптовалюты для любых нужд с меньшим количеством ограничений. И как видно, платежные системы вовсе не собираются “воевать” с конкурентами на криптовалютном поле, а напротив успешно с ними сотрудничают. 

Но есть и альтернативная точка зрения. 

Dubai International Financial Centre (DIFC) Data Protection Law No. 5 of 2020

В 2020 году в ОАЭ планируется внедрение нового закона о защите данных, который объединит в себе требования для DIFC и лучшие международные практики - Dubai International Financial Centre (DIFC) Data Protection Law No. 5 of 2020. 

Еще одно событие, которое говорит об актуальности законодательства в данной сфере в разных регионах мира, а не только GDPR для Европы или CCPA для США.   

Штрафы.

В топе по штрафам за прошлый год известные компании - British Airways (204 млн евро), Marriott (118 млн. евро), Google (50 млн евро) и пр. 

Данные 267 млн. пользователей в сети Facebook были обнародованы уже в этом году.

Посмотрим, на каком месте по штрафам в 2020 году окажется Facebook.

Криптовалютный фонд Trident Crypto Fund тоже “потерял” 266 тыс. пользователей.
И таких инцидентов все больше и больше.
Все штрафы можно отслеживать тут.

Ну и в дополнение интересный материал - как устроен черный рынок данных. 

Карты вместо GDPR

В этот раз хотел написать о GDPR и его эволюции, в частности в странах Персидского залива, немалых штрафах за минувший год и множестве миллионных утечек, но планы изменились из-за Payoneer и Wirecard. 

Ernst & Young в рамках аудита не досчиталась 1,9 млрд у Wirecard. Как следствие к 19 июня (как крайнему сроку) компания не опубликовала отчетность, что привело к резкому падению стоимости акций компании. 

Через неделю FCA и вовсе приостановил деятельность Wirecard Card Solutions Limited. СЕО арестовали. А компания подала на банкротство. 

И вот в это время проблема докатилась и до Payoneer.

Операции по картам остановлены, а вывести средства нет возможности.

Сейчас уже есть информация, что с 6 июля можно будет выводить средства в обычном режиме.

Ну и напоследок. Все это могло длиться давно, E&Y “обманывали” десятилетиями? И только в прошлом году аудиторами KPMG были обнаружены проблемы. Не приведет ли это к тому что четверка станет тройкой, как ранее четверкой стала пятерка? 

А у вас сколько платежных провайдеров и есть ли BCP (Business continuity plan) на такой случай?

SPoC и CPoC

Давно не было новостей про PCI DSS. А это мой самый любимый стандарт. С одной стороны более сложный чем большинство других, так как более конкретный в требованиях и их проверках. С другой стороны давно знакомый, ещё c версии PCI DSS 1.1 в 2008 году.

В этом году мы уже должны увидеть PCI DSS 4.0. В предварительной версии, как я писал, не могу сказать, что он содержит уж очень много изменений.

Посмотрим по итогу. Ждать осталось не долго.

А пока есть время хочу обратить внимание, что PCI SSC уже достаточно давно опубликовал новые требования для операций, при которых покупатель вводит PIN на мобильных устройствах продавца - Software-based PIN Entry on COTS(SPoC)™. Это было (и частично остается) актуальным и своевременным решением, учитывая повсеместное использование планшетов и смартфонов. Но кардридер и софт все же придется купить. Детальнее.

И более новый стандарт, который призван обеспечить безопасность при приеме бесконтактных платежей - PCI Contactless Payments on COTS (CPoC™). В этом случае уже нет необходимости в дополнительном оборудовании.

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

Если для вас актуальный вопросы внедрения PCI DSS - больше полезной информации вы можете найти тут.

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 года.

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