«Сбербанк», ВТБ, «ЮниКредит» и «Открытие» запретили сотрудникам фотографировать экраны компьютеров Статьи редакции
При этом сам факт съемки доказать очень тяжело, считают эксперты.
«Сбербанк», ВТБ, «ЮниКредит» и «ФК Открытие» запретили сотрудникам снимать экраны компьютеров с личных мобильных устройств. Об этом пишет РБК.
Замруководителя лаборатории компьютерной криминалистики Group-IB Сергей Никитин считает, что такой запрет — способ борьбы с «пробивом» данных о клиентах. Злоумышленники размещают объявление в даркнете, чтобы выяснить баланс карты жертвы, паспортные данные и другое. Фотографии с такими данными стоят от 800 до 8 тысяч рублей, и их делают сообщники мошенников — инсайдеры в разных банках.
Также Никитин пояснил, что распространенность фотографирования экранов можно объяснить новыми системами защиты банков от внутренних угроз и утечек. В результате сотрудникам легче сфотографировать экран. Кроме того, добавляет Никитин, сам факт съемки доказать очень тяжело.
Директор департамента информационной безопасности «ФК Открытие» Владимир Журавлев считает, что на основе фотографий клиентских данных можно изготовить поддельные документы. Их могут использовать для снятия денег с чужого счета и участия в мошеннических схемах.
Зампред «Сбербанка» Станислав Кузнецов рассказал, что системы банка, как правило, не позволяют передавать служебные данные в третьи руки.
Если им удалось по какой-то причине передать это преступникам, мошенникам либо третьим лицам, мы передаем материалы в правоохранительные органы.
Почему бы с правами и логированием не поиграться? Изучать обоснованность и цель доступа сотрудника к данным, например.
на масштабах сотен тысяч запросов этих данных в день, будет трудно изучать логи и обоснованность
имхо, логи смотреть легко. Систему логирования только надо качественно спроектировать. и вопрос будет решаться 2-3 SQL запросами (условно)
логи чего посмотреть легко? что кто-то открыл конкретный счет? да
а чтобы подтвердить легитимность, надо выяснить почему это произошло - личный визит клиента в офис, звонок в кол центр, запрос от другого сотрудника и тп. это не автоматизировать в разумных пределах
достаточно логировать запрос на выдачу данных клиента. например сотрудник номер XXX посмотрел данные клиента YYY. Смотрел 2 минуты, нажал на кнопку "операции" и баланс (условно). Этого достаточно для выяснения инсайдеров
это всё и так логируется по умолчанию.
ну вот у тебя 100 тысяч таких запросов в день, что ты дальше с ними будешь делать?
1. 100к запросов на угон данных - перебор
2. Обрабатывать в порядке очереди
3. для чего существуют службы безопасности?
4. опять же легко автоматизировать. клиента переадресуют в СБ, СБ видит сразу карточку клиента в вебморде, в карточке будет кнопка "кто смотрел". все профит
1. 100k легитимных запросов
2. каждый день
4. опять же легко автоматизировать. клиента переадресуют в СБ, СБ видит сразу карточку клиента в вебморде, в карточке будет кнопка "кто смотрел".
в какой момент и зачем переадресовавать клиента в сб? тебе сначала из сотен тысяч запросов данных в день (п.1) надо вычленить подозрительные, а потом уже с ними работать. из этих сотен тысяч, существенная часть будет результатом звонка в кол центр, которая сольется с существенной частью запросов инсайдеров
мои предложение строится по сценарии: "Инсайдеры угнали данные, передали мошенникам, они клиенту позвонили по соц инженерии, клиент заподозрил что то неладное, позвонил в коллцентр сбера, там его выслушали, переадресовали на СБ, СБ выявила инсайдера и применила к нему санкции."
надо глубже смотреть специфику. но оно все реализуется без больших вопросов
полагаю, что тут задача не расследовать инциденты, а выявлять инсайдеров и предотвращать слив инфы в первую очередь.
с инцидентами всё гораздо проще, потому что по конкретному клиенту модно сразу посмотреть все логи и поработать со всеми причастными сотрудниками
можно еще документально в трудовом договоре прописать штраф за слив данных в 20 окладов. Инсайдер 20 раз подумает перед сливом
То что вы предлагаете это решение вопроса пост фактум. Получается для повышения безопасности на паркинге вы порекомендуете повесить камеры, дескать когда вам проломят черепушку мы с лёгкостью найдём грабителя!
да, мое предложение на решение вопроса пост-фактум. Но это банк, транзакцию подозрительную можно откатить и вернуть деньги клиенту.
Если грабитель увидит камеру, то лишний раз подумает. Не просто так ведь часто можно встретить то, что много где муляжи расставлены. И это работает!
Ну так и отлично, значит мы 90% этой существенной части сможем отфильтровать как не подозрительные операции.
Кстати, 100 К запросов - это очень мало. Даже если не запускать нейросеть обычными ифами за несколько месяцев можно написать обработку большинства запросов. Ну и как ниже говорили - то, что секретное слово находится в открытом доступе - это основная дыра, которую нужно решать.
оно не находится в открытом доступе и это не пароль, чтобы его никто не знал кроме обладателя.
даже если сотрудники банка его бы не знали, и могли только ввести сказанное секретное кодовое слово в форму, которая бы сматчила с базой по хешу. в этот момент слово бы перестало быть секретным.
это как пароль спрашивать по телефону.
Как это не находится, если его видят любые операторы?
в этот момент слово бы перестало быть секретным.Однако это бы предотвратило запрос ПД оператором, без обращения клиента.
Да и в любом случае, любое введение функций, ограничивающих доступ к моим (вашим) данным от посторонних людей - это благо. Я бы еще и шифрование ПД на основе кодового слова ввел. То, что код нужно сообщать посторонним лицам - это, конечно, очень плохо. Нужно разрабатывать такие законы и процессы, чтобы максимально нивелировать влияние людей.
эти любые операторы аутентифицируются в своих системах где имеют этот доступ для выполнения служебных обязанностей. технически там может быть, а может и не быть шифрования на уровне БД. сами поля с кодовым словом в клир тексте, естественно.
> Однако это бы предотвратило запрос ПД оператором, без обращения клиента.это, возможно, подняло бы стоимость запросов, и существенно снизило юзабили при прямом обращении в колл центр. при этом не закрыв ни какие существенные риски
> любое введение функций, ограничивающих доступ к моим (вашим) данным от посторонних людей - это благонет, вся безопасность строится на разумности, клиентам такие меры не интересны. аутентификация вообще мало кому интересна. зачем тратить 15 минут на ФИО+паспорт+дата рождения+кодовое слово по буквам, чтобы узнать почему у тебя транзакция задублировалась или остаток по счету?
клиенты хотят набрать номер и получить помощь, а не дополнительные проблемы.
даже работая в безопасности я не считаю уровень безопасности банка где я обслуживаюсь существенным критерием выбора
Так. И? Сейчас они могут без знания кодового слова получить доступ к ПД? Видимо, да, раз банки начали беспокоиться по этому поводу.
и существенно снизило юзабили при прямом обращении в колл центрЭто бы увеличило время на ввод кодового слова.
зачем тратить 15 минут на ФИО+паспорт+дата рождения+кодовое слово по буквам, чтобы узнать почему у тебя транзакция задублировалась или остаток по счету?А в чем разница? Сейчас и так нужно называть ФИО и кодовое слово, чтобы узнать любую информацию по счету.
да, кодовое слово вообще не является определяющим в вопросе внутренней обработки ПД, закон и здравый смысл такого не требуют. кодовое слово существует только для того чтобы банк понял что к ним _скорее всего_ именно ты обратился и что тебе можно предоставить базовые сервисы (без переводов денег). оно не для того чтобы ты аутентифицировал банк или чтобы ты авторизовал банк на доступ к твоим данным.
Видимо, да, раз банки начали беспокоиться по этому поводу.нет никакой особой обеспокоенности на самом деле и никаких особых изменений во внутренних документах крупных банков, это пустые слова стасяна кузнецова, который бороздит просторы биг даты, простая некомпетентность.
Это бы увеличило время на ввод кодового слова.да, и не принесло бы никакой пользы никому в данном кейсе
А в чем разница? Сейчас и так нужно называть ФИО и кодовое слово, чтобы узнать любую информацию по счету.сотруднику не надо вводить большую часть этого, он только проверяет что клиент их правильно назвал. а кодовое слово надо будет вводить побуквенно.