Comments 80
А чем банку опасна утечка базы? Регуляторы могут наказать руководство за утечку персональных данных или вопрос лишь в теоретической потере клиентов и их денег ?
В данном случае, как я понял, выгрузили не только ФИО, но и номера кредиток, счетов, пароли, а может и ещё чего полезного.
Известны случаи, когда угоняли деньги с карт, имея на руках только её номер, ФИО владельца, да ещё пару перс. данных, вроде даты рождения (Далее, методами соц. инженерии хакер представлялся владельцем карты и получал доступ к деньгам на ней)
Пароли? Они их там в открытом виде хранили?
номера кредиток, счетов, пароли
Попахивает нарушениями PCI DSS
Тоже первое, что пришло в голову, что по PCI DSS не должны хранится полные номера карт. Но с другой стороны, я видел массу промышленных систем в банках, где номера карт хранились целиком.
И то, и то. Притом штраф за утечку ПД может быть умножен на количество утекших учёток, так что там могут на круг очень приличные суммы набежать.
Плюс есть ещё вопрос - а чьи именно данные утекли? Если я плюну на этот банк и перейду в другой, убыток невелик. Если владелец нескольких компаний перетащит ещё и их обслуживание - это уже будет неприятно.
Обычно проблема в высоком % ложных срабатываний.
Ну и еще - безопасники мешают работать людям
Допустим, Вы запретили записывать запороленные архивы на флешки. А если сотруднику надо (именно надо) передать кому-то запороленный архив. И не дело безопасников сувать туда нос (поэтому и заполоролен, в целях безопасности)
Или на каждый чих вызывать СБ-иста, чтобы он лично присутствовал?
Обычно проблема в высоком % ложных срабатываний.
Это факт, но в целом аномалии со временем искать получается неплохо.
Ну и еще - безопасники мешают работать людям
Ну во первых это финтех и аудиторы с PCIDSS не дремлют. Во вторых - с позиций удобства согласен, с позиции бизнеса - это необходимое зло (или не зло).
Допустим, Вы запретили записывать запороленные архивы на флешки. А если сотруднику надо (именно надо) передать кому-то запороленный архив. И не дело безопасников сувать туда нос (поэтому и заполоролен, в целях безопасности)
Обычно есть регламентированные пути передачи чувствительных данных, не архивчики. Но да, ситуаций где кому-то будет неудобно из-за очередной инновационной DLP можно придумать (и не придумать) массу.
В бытность моей работы, я скидывал архив одного проекта на свой личный яндекс-диск. С точки зрения СБ - утечка. А с точки зрения нач. отдела - бекапы в разных местах
Каким образом предлагаете передавать даннные (в которые запрещено сувать нос сотрудникам, за пределами узкого круга. В том чисел СБ-истом тоже нельзя) кроме как архивом? Экселевские запороленные файлы взламываются проще, насколько я знаю
При этом эти данные бывает надо передать своим же коллегам. Или не своим, а каким-то консалтерам
В бытность моей работы, я скидывал архив одного проекта на свой личный яндекс-диск. С точки зрения СБ - утечка. А с точки зрения нач. отдела - бекапы в разных местах
Ну тут без комментариев, в больших компаниях бэкапить что-то сколь либо чувствительное "во вне" нельзя, совсем.
Каким образом предлагаете передавать даннные (в которые запрещено сувать нос сотрудникам, за пределами узкого круга. В том чисел СБ-истом тоже нельзя) кроме как архивом? Экселевские запороленные файлы взламываются проще, насколько я знаю
Вариантов больше чем кажется. Мне вот приходилось записывать cd-r и передавать под роспись результаты работы одной запатентовоной деньгоприносящей штуки (понятно что и там все запаролено, пароль передавался отдельно).
При этом эти данные бывает надо передать своим же коллегам. Или не своим, а каким-то консалтерам
У коллег либо есть легитимный доступ к данным, либо нет. Третьего не дано.
p.s. Если что я не ИБшник, но наверное слишком давно в финтехе.
Оно нельзя, когда для плохих целей. Вон тот Денисович попался не потому, что базу слил, а потому что использовал ее в плохих целях. А если бы он эту базу использовал для хороших целей (губеру бы отнес, хз зачем, ситуация выдуманная), то никаких проблем бы у него не было. Еще бы и премию получил
CD-r. А откуда у Вас на компе есть CD-r и будет ли читалка на той стороне? да и чем это безопасней то? Денисочу было бы гораздо проще, будь у него писалка дисков. А так пришлось с почтой извращаться
У коллег есть право. Но доступа нет. например это холдинг. Вы работаете в УК. Формально у Вас есть право смотреть их доки (ну, финотчеты например). Но нет доступа в их компы. Опять таки в целях безопасности. Вам могут только передать эту инфу (таким образом передающий сотрудник несет ответственность за передачу)
Вы рассуждаете с точки зрения идельного мира. А фактические ситуации они шире. А на каждый чих прописывать правила в айти-системе и в инструкциях - невозможно
(в некоторых организациях народ обменивается уже через вотсап всякими данными, которые очевидно не должны "утекать" буржуям и вообще за пределами компании), но жизнь она такая. В случае реальной утечки конечно вздрючат виноватого. Но пока нет проблем - нет проблем.
Оно нельзя, когда для плохих целей. Вон тот Денисович попался не потому, что базу слил, а потому что использовал ее в плохих целях. А если бы он эту базу использовал для хороших целей (губеру бы отнес, хз зачем, ситуация выдуманная), то никаких проблем бы у него не было. Еще бы и премию получил
Есть данные которые нельзя предоставлять третьим лицам, совсем. И персоданные тут на первом месте (вспомните как в один момент все начали подкидываться с GDPR).
CD-r. А откуда у Вас на компе есть CD-r и будет ли читалка на той стороне? да и чем это безопасней то? Денисочу было бы гораздо проще, будь у него писалка дисков. А так пришлось с почтой извращаться
а) Иммутабельность б) После отчуждения ответственностьза сохранность фактически на конкретном лице (я б на его месте мухлевать не стал).
Таковы были условия передачи с принимающей стороны согласованные с ИБ компании в которой я на тот момент работал. Ивану Денисовичу было бы +- одинаково)
У коллег есть право. Но доступа нет. например это холдинг. Вы работаете в УК. Формально у Вас есть право смотреть их доки (ну, финотчеты например). Но нет доступа в их компы. Опять таки в целях безопасности. Вам могут только передать эту инфу (таким образом передающий сотрудник несет ответственность за передачу)
Ну так вот надо сначала согласовать подход к передаче данных и как гарантировать их безопасноть, а не прыгать с завязанными глазами по граблям. Давайте перефразирую, если в ходе вашего придуманного на коленке процесса передачи часть чувствительных данных попадут не в те руки, при этом кто передавал понятно и последствия для вас не радужные (менее чем у Ивана Денисовича, но все таки) - что делать и кому плакаться?
Вы рассуждаете с точки зрения идельного мира. А фактические ситуации они шире. А на каждый чих прописывать правила в айти-системе и в инструкциях - невозможно
Я рассуждаю с точки зрения процессов которые в том или ном виде работают последние несколько десятков лет в финтехе, поскольку и статья про финтех. Как передавать сверхсекретный шаблон сайта на ucoz'e для команды в контре - да как удобнее в принципе)
>Есть данные которые нельзя предоставлять третьим лицам, совсем
Я не про перс. данные. Я про фин. документы, например
ИБ компании просто нужно было, чтобы была физическая передача. Чтоб акт составить. Вот ценный диск. Вот мы его передали. Дальше не наша ответственность. А интернет -черный ящик.
Сложно сказать, архив запоролен. Попадет не в те руки.. Типа шел, шел, потерял флешку. Ну такое конечно мей би, но вероятность низкая. Ну и нашедший флешку с запороленным архивом будет довольно долго его взламывать (если вообще будет)
Ну да, оно в теории верно, что сначала надо согласовать. Согласовывать будете недели 2, а работать надо "вчера". Какой-нить Сбер может себе позволить простой работника в месяц. А другие организации - не очень
Я не про перс. данные. Я про фин. документы, например
Ну фин. документы, какие-то инсайды и прочее такое тоже могут повлиять как минимум на репутацию компании и финансовые показатели, как максимум на целые рынки. Тут просто надо смотреть глобальнее и тогда такие меры начинают казаться оправданными.
ИБ компании просто нужно было, чтобы была физическая передача. Чтоб акт составить. Вот ценный диск. Вот мы его передали. Дальше не наша ответственность. А интернет -черный ящик.
Ну это достаточно обоснованное мнение и как бы не хотел я во многом с ним согласен.
Сложно сказать, архив запоролен. Попадет не в те руки.. Типа шел, шел, потерял флешку. Ну такое конечно мей би, но вероятность низкая. Ну и нашедший флешку с запороленным архивом будет довольно долго его взламывать (если вообще будет)
К чему приводили забытые(?) в баре прототипы айфонов или какие-нибудь важные ноутбуки интернет помнит)
Ну да, оно в теории верно, что сначала надо согласовать. Согласовывать будете недели 2, а работать надо "вчера". Какой-нить Сбер может себе позволить простой работника в месяц. А другие организации - не очень
А чтобы было не 2 недели - нужны процессы способные ускорить и облегчить эту процедуру. Как раз сбер со своими ~300к сотрудников я думаю в этом на внутренней кухне достаточно приуспел, иначе бы оно вообще не смогло шевелиться.
Оно нельзя, когда для плохих целей.
Если защита информации строится понятиях сотрудников о том, что есть хорошо, а что плохо — то у компании большие проблемы.
Когда-то натыкался на случай: к работнику оператора сотовой связи пришёл знакомый, сказал, что хочет проверить свою девушку на измену и для этого нужна детализация звонков. С точки зрения человека это была не плохая цель. Вот только это был номер вовсе не девушки, то бишь — обычный пробив.
Экселевские запороленные файлы взламываются проще, насколько я знаю
ЕМНИП после переезда на xmlzip-формат взломать офисные документы сдало достаточно сложно (AES128 как минимум), вот до того ломалось в самом деле легко.
свой личный яндекс-диск
ЭЭЭЭ.... Вам в этой фразе ничего глаз не режет? В самом деле?
PGP контейнер с подписью ответственного человека за передачу таких данных?
Да можно даже при помощи ссл сделать
безопасники мешают работать людям
Работа у них такая. «Безопасность не должна быть удобной» (с)
на каждый чих вызывать СБ-иста, чтобы он лично присутствовал
да, согласование действий, проверка спеца от ИБ, вплоть до «скиньте файлы мне в папку, придёте за флэшкой после проверки и согласования».
Обычно на таких армах разрешено только определенное ПО из доверенного списка. Powershell, python инерпритотор и подобные штуки явно не присутствуют. Как Вы планируете делать стеганографию в таком случае?
Как вариант можно данные выгружать не как есть, а по-xor-ит с чем то. И тогда в выгрузке не будет осмысленных данных.
Для, этого хватит просто возможностей sql, если данные слили из БД.
Сможет ли анализатор содержимого файлов такое детектировать.?
Я не знаю что может чей-то анализатор сожержимого файлов.
Но я думаю что директор по продажам, руками не писал кастомные запросы в базу данных по выгрузке клиентов. Скорее всего там обвязка в виде приложения,crm системы или еще како-то банковского клиента, и оставлять возможность что-то xor'ить в запросе из такой обвязки как минимум странно.
Опять же это только мои предположения исходя из опыта в offensive security, как и что там устроено мы не узнаем :)
Ни разу в жизни не видел заблокированного powershell. Работал в госбанках. Так что не думаю, что какая-то проблема в этом есть.
Как по мне, подозрение должен вызывать уже сам факт наличие на арме какого-то "видео".
>Как по мне, подозрение должен вызывать уже сам факт наличие на арме какого-то "видео".
Запрос в техподдержку написал, приложил видео воспроизведения проблемы.
И самое главное — почему техподдержка в другом сетевом сегменте? То есть, ну сняли, ладно — но зачем пересылает? Понятно что можно выдумать разную правдоподобную фигню, но реально оправдать такое действие было бы практически невозможно.
подозрения должен вызывать уже сам факт наличие на арме какого-то «видео».
Само собой, не надо называть видео «Выпускной Дуси», или как оно там называлось на АРМе.
Это как бы не персональный арм то был, а по сути толстый клиент для работы с бд клиентов, несколько я понимаю.
Так а что в итоге по Ивану Денисовичу? Карамельку дали?
В начале статьи описали ложные чувства, но не развенчали их.
да там ссылка есть на "дело"
приговорил:
признать ФИО2 виновным в совершении преступления, предусмотренного ст. 183 ч. 3 УК РФ и назначить наказание в виде 2 (два) лет 10 (десять) месяцев лишения свободы, с отбыванием наказания в колонии-поселении.
Меру пресечения в отношении ФИО2 в виде домашнего ареста – оставить без изменения до вступления приговора в законную силу, сохранив ранее установленные запреты и ограничения. По вступлении приговора в законную силу указанную меру пресечения - отменить.
Возложить на ФИО2 обязанность следовать по месту отбывания наказания в колонию-поселение за счет государства самостоятельно; явиться в территориальный орган уголовно-исполнительной ФИО1 для получения, в соответствии со ст. 75.1 УИК РФ, предписания о направлении к месту отбывания наказания и обеспечения его направления в колонию-поселение;
Плюс еще и бабла
Гражданский иск ПАО Сбербанк к Зеленину ФИО33 о взыскании в счет возмещения вреда, причиненного деловой репутации ПАО «Сбербанк» в размере 25 856 157 рублей 00 копеек – удовлетворить.
Взыскать с Зеленина ФИО34 в пользу ПАО Сбербанк в счет возмещения вреда, причиненного деловой репутации ПАО «Сбербанк» денежные средства в размере 25 856 157 (двадцать пять миллионов восемьсот пятьдесят шесть тысяч сто пятьдесят семь) рублей 00 копеек.
В начале статьи есть ссылка http://судебныерешения.рф/53900773
Ивану Денисовичу-то ничего не было. Он выдуман. А реальному человеку из дела, помимо того, что уже написано выше, ещё и штраф дали:
Взыскать с ФИО34 в пользу ПАО ...банк в счет возмещения вреда, причиненного деловой репутации ПАО ...банк денежные средства в размере 25 856 157 (двадцать пять миллионов восемьсот пятьдесят шесть тысяч сто пятьдесят семь) рублей 00 копеек.
Эвристика по записи на флешку запароленного архива бесполезна если пользователь это сразу заметит. Ничто не мешает домешивать данные в конец настоящего видеофайла. Или перегонять кусочки в base64 и утекать через обычные файлы. Стеганографию опять же никто не отменял, подмешивать данные в биты пнг. Код для всей этой магии можно отлично писать на VBA.
Всякие security best practices хоть и не советуют передавать почтой sensitive информацию, всё же настойчиво советуют её передавать запароленной ( и пароль отдельно и по другому каналу), поэтому в какой-то момент огораживание пользователей может выйти боком.
Сбер такой сбер. А Иван Денисович тоже мамкин хацкер. Не мог тузом в базу залогиниться штоле? Откуда ваще в альфе мог взяться выпускной.mp4 😂 Ещё раз убеждаюсь, что все начальники дураки
Итого, Иван Денисовичу достаточно было воспользоваться file-erase утилитамиКоторых на АРМе нет, как и возможности их туда вкорячить. Если только не городить из говна и палок через fsutil.
Как вариант - делать выгрузки такого же размера примерно каждый день, чтобы а) создать впечатление, что это нормальный рабочий процесс, а не разовая аномалия, б) затереть следы утекшей выгрузки, в) убедиться, что не привлёк внимания СБ. А базу продавать через год, когда следов уже не найти. В идеале - после списания АРМ2 с регламентным уничтожением HDD, но это можно и не дождаться.
Я бы сказал, что очевидное слабое звено не тут — а на пересылке из защищенного сегмента сети во внешний. Потому что появление во внутренней сети какого-то там видеоролика — уже вызывает явные вопросы: а как он вообще туда попал? А нахрена его пересылать наружу? И так далее.
Более того, вызывает вопрос сама необходимость для какого-то там «начальника отдела продаж» иметь доступ к "«корпоративному файловому перекладчику». Для пересылки каких-таких данных на постоянной основе изнутри наружу ему это нужно? И если бы ему эту пересылку нужно было согласовать — у любого человека со стороны озвученные выше вопросы возникли бы.
В остальном согласен, ситуация поражает. Самый очевидный вектор атаки с наградой в «миллионы или даже десятки миллионов рублей» вообще никак не контролируется. Ладно б в IT резервную копию выкрали и расшифровали, а тут простой пользователь может а) выгрузить базу, б) передать её через шлюз, вся суть которого в том, чтобы предотвратить передачу базы!
Да, конечно. Тут речь скорее была о том, что объемы — они разные для ролей. Начальнику отдела продаж вообще непонятно, нафига выгрузка такого размера. То что он начальник — ничего тут не значит. У него есть свой круг задач, в него явно не входит анализ миллионов записей с номерами карт.
Я вам больше скажу — в нашей конкретной системе нет полей с картами. Но мы работаем с остальными полями «оттуда». Так нам даже это стоило кучу мороки — доказать тот факт, что мы поля не берем, оказалось мало. Пришлось проделать еще много чего, чтобы мы даже случайно их не взяли. Например, в результате какой-то SQL иньекции.
>никто аж целому Сберу слова ни сказал.
Ну это не факт. Не знаю, кому чего сказали, но нам доступ туда усложнился. То есть, реакция была. Насколько широкая — сказать тут трудно.
Тут речь скорее была о том, что объемы — они разные для ролей.
Я рискну чрезмерно обобщить, но, по моему мнению, за исключением редчайших случаев, на которые можно хоть комиссию из 10 надзирающих за процессом собирать, никому и никогда не нужна ручная выгрузка значимых для PCI DSS размеров. Там, где машины между собой общаются, там могут быть объёмы. Человеку же нужен единичный доступ. Это — основа защиты данных кредитных карт. Этой функции там вообще не должно было быть.
Я вам больше скажу — в нашей конкретной системе нет полей с картами. Но мы работаем с остальными полями «оттуда». Так нам даже это стоило кучу мороки — доказать тот факт, что мы поля не берем, оказалось мало. Пришлось проделать еще много чего, чтобы мы даже случайно их не взяли. Например, в результате какой-то SQL иньекции.
Ну да, это базовые требования PCI DSS — ограничение доступа ко всей cardholder data, а не только к PAN. Я не знаю деталей вашей системы, но в норме должно быть разделение на разработчиков и Operations, и доступ разработчикам к cardholder data должен быть закрыт «с той стороны».
>никто аж целому Сберу слова ни сказал.
Ну это не факт. Не знаю, кому чего сказали, но нам доступ туда усложнился. То есть, реакция была. Насколько широкая — сказать тут трудно.
Я имел в виду, что заранее на наличие у пользователей функции выгрузки закрыл глаза их аудитор. Весь 7-й раздел PCI DSS о том, что такого не должно быть.
То, что вам доступ «усложнили», показывает лишь то, что до этого было нарушение PCI DSS, а тут их припугнули и они стали что-то где-то выполнять. Есть надежда, что теперь стали относится серьёзно. Удивляет то, что это произошло в 2020+ году. В Северной Америке с большего прогресс был виден уже 5+ лет назад, тоже после громких скандалов. Есть, конечно, и исключения, к сожалению, но, мне хочется надеяться, не размера Сбер-а.
Да не, даже если тут обобщение — то идея все равно выглядит верной. В моей работе такое есть — но я никогда не забираю эти объемы через тот же интерфейс, через который их получает обычный пользователь. Ну т.е. если вы инженер или аналитик больших данных, или там обучаете модели — вам могут быть нужны объемы, но тогда у вас скорее всего — другие каналы их получения, чем у начальника отдела продаж.
По большому счёту, вообще любая аналитика внутри CDE — сомнительное удовольствие. Мой совет — автоматически фильтровать, выводить за пределы scope (а ещё лучше никогда не вводить туда) данные, по которым нужна аналитика.
Полагаю, что выбранный в выпадающем списке Метод валидации=Номер карты это и делает
Создаём правило, которое поможет находить и помечать информацию, содержащую ПДн. В условиях прописываем регулярное выражение для «номера карты» и устанавливаем порог входа (50 цепочек).
вот тут явно регулярка. И алгоритм Луна на регулярках по-моему написать нельзя.
Тоесть, если бы он не сразу понес базу продавать, а выждал бы пару месяцев, то хрен бы доказали ? Остатки файлов на винчестере за это время были бы перезаписаны, корзины очищены, искать в логах неизвестно что на неизвестно какую глубину -та еще задача.
проверять файлы только указанных расширений это конечно оптимизирует поиск.
но как тогда проверится jpeg в 6 гб, который будет вполне открываться как картинка а в метаданных у него будет искомый архив.
более того, можно разбить 6 гб, на фоточки по 8 мб, в которых 4 будет фотка, 4 зашифрованные данные.
и всё это вообще спокойно можно передавать. или такие кейсы анализатор файлов поймает?
был ещё сервис darkjpeg вроде, тот в шум сжатия данные сохранял
Он мог просто пересобрать архив на компьютере №2, не говоря уже о всяких стеганоизвращениях.
Как отреагирует упомянутая система, если не ограничиться переименованием *.rar в *.mp4, а еще и поменять при этом пару первых байт в файле?
Два дня из жизни «Ивана Денисовича»: как инсайдер вынес базу за периметр компании