Один из менеджеров Сбербанка, а именно начальник сектора продаж розничных продуктов Сбербанка сделал запрос в центральную БД и выгрузил данные всех клиентов Сбербанка включая (из приговора) "фамилия имя отчество, паспортные данные, дату рождения, адрес места жительства, номер мобильного телефона, полный номер карты, место работы, остаток собственных средств, учетных записях", короче говоря всю банковскую тайну всех физлиц. После этого скопировал выгрузку к себе на компьютер, переименовал, перепаковал архив и отправил его по частям себе на почту, после чего с другого ноутбука скопировал данные из почты на флешку, отнес домой, потом попытался продать данные в даркнете, опубликовав в качестве доказательств данные 5000 клиентов, за "демо"-данные он получил 25 000 рублей, но попал на контрольную закупку, арестован. Осужден на 2 года 10 месяцев (колония-поселение).

В приговоре есть ещё немало классных моментов:

1. Виновник пользовался учёткой своего руководителя, знал его логин и пароль. Объяснение "чтобы выполнять обязанности в отсутствии руководителя";

2. Данные выгружались из базы и затем копировались много часов и это ни у кого вопросов не вызвало;

3. Система не отследила перенос 5,7 Гб данных из "защищенной" части в не совсем защищенную;

4. В Сбере у пользователей есть техника, которая не имеет защиту от подключения USB-накопителей, с формулировкой "для служебной необходимости" (видать, чтобы данные воровать удобнее было);

5. В Сбере узнали об утечке данных из Банка России, который обнаружил в открытом доступе 200 из 5000 переданных данных. Если бы не инициирование проверки Банком России то не факт, что СБ Сбера вообще узнала бы о сливе всей своей клиентской базы физлиц;

6. Человек просто взял и вынес на флешке.

7. Человек, который это сделал, явно либо очень далек от ИТ, либо делал всё нагло и практически открыто.

Сперва немного отвечу комментаторам прошлых постов. Как понимаете, приговоры это то, что было выявлено, расследовано, дошло до суда и было опубликовано.

@UBM5UBM, ну что, менеджмент банков безгрешный и никакие данные никуда не сливает? Денег им на всё хватает?

@WhiteredMaH, "невозможно защитить ПД", это имел ввиду, что никто такую лавочку прикрывать не будет?

@RationalVal, ну и чего стоят глубоко разбирающиеся в теме "профессаналы" ИБ Сбербанка? Какая же у них охуенная защита ПД и реальная безопасность.

@pavelkonkov, моя больная фантазия настолько больная, что смогла заразить судей Красногорского городского суда Московской области, которые и вынесли обвинительный приговор по делу. А так же все СМИ, потому что новости о перехваченных продажах данных банков вполне себе регулярные.

А теперь моё заключение.

Я ХЗ сколько Сбер тратит денег на ИБ и сколько макулатуры на это переводит, но...

На скамье подсудимых должен был сидеть не только он. Изучение вопросов защиты информации обычно начинается с Приказ ФСБ России от 10 июля 2014 г. № 378 и постановлением Правительства Российской Федерации от 1 ноября 2012 г. № 1119, у ИБшников обычно это "азбука для самых маленьких" (с этого обычно начинают).

Так вот из фактов, изложенных в приговоре суда СОБЛЮДЕНИЯ требований данных актов я не нашел. Согласно классификации Постановления в Сбере должен обеспечиваться наивысший уровень безопасности (хранение данных более 100к физлиц).

Далее ссылки на Состав и содержание организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности (утверждены упомянутым выше приказом ФСБ) и их нарушения (не все, только основные):

1. (пп. в п. 5) Не утверждены, или "только на бумаге" или просто не соблюдаются требования по разграничениям данных и обеспечение доступа в соответствии с должностными обязанностями.

2. (пп. б п. 5) Не обеспечен учёт и порядок хранения носителей информации.

3. (пп. г п. 5) Не буду прям утверждать, но упоминаний о сертифицированных средствах защиты информации в приговоре я так же не нашел. Но использование iPad в отделениях...

4. (пп. 9) Каждый тип защищаемых данных должен быть защищен в соответствии со своим уровнем защиты. Наличие всех данных в одной БД (раз сделана выгрузка) само по себе уже нарушение.

5. (п. 17) Квалификация сотрудников ответственных за ИБ должна обеспечивать полную защиту персональных данных.

6. (пп. б п. 20) Каждый запрос на получение данных и его предоставление должны быть зафиксированы.

7. (п. 22) Все полномочия доступа должны быть прописаны в специальном электронном журнале, все изменения доступов должны фиксироваться. Не реже 1 раза в полгода должна проходить полная сверка.

Я не буду писать ссылки и цитаты на другую нормативку от ФСБ и ФСТЭК (это в 3 - 4 раза раздует пост), но почему за нарушения которой прописаны прямо в приговоре суда никто не ответил?... И к чему это привело? Через 2 года в СМИ опубликовали информацию о новой масштабной утечке по словам представителя Сбера - фейк, однако прозвон данных журналистами РБК (чтобы по формальным причинам пост не закрыли - свидетельство о регистрации СМИ ИА № ФС 77 - 63848) подтвердил, что данные настоящие.

У Сбера официально "утечки не было", но прозвон по взятым наугад номерам все данные почему-то на 100 % подтверждают, полагаю, что принято решение "если нет официальной утечки данных, то и виновных нет и оправдываться не нужно".

После начала СВО за кибератаки уже отчитываются оптом и в основном в % т.е. уже просто не публикуют сколько раз и кого слили.

Безнаказанность порождает безответственность.

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

P.S. Просто ещё раз прочувствуйте - спустя 13 лет после принятия закона 152-ФЗ "О защите персональных данных" и 29 лет после принятия закона 395-1 "О банках и банковской деятельности", где были требования по обеспечению безопасности финансовой информации из ТОП-1 крупнейших банков России всю клиентскую базу по физлицам типичный офисный планктон ПРОСТО ВЫНОСИТ НА ФЛЕШКЕ. Никаких тебе мега взломов, крутых хакеров, операций спецслужб, тайных агентов. Просто типичный (хоть и долго работающий) офисный планктон вынес всю базу на флешке...

Начать я хочу с базовой аксиомы информационной безопасности:

Единственным показателем эффективности информационной безопасности (инфобеза) ИТ-инфраструктуры является полное или почти полное отсутствие успешных атак на инфраструктуру.

Сперва здесь я сделал подборку явных нарушений инфобеза (которые видны каждому клиенту, кто в теме) в некоторых из ТОП-10 крупнейших банков, но потом удалил, чтобы не раздувать пост и сосредоточиться только на теме абсолютно безопасного хранения данных.

Итак, первый шаг - организационно-управленческий. Вопрос инфобеза должен быть № 1, полномочия ответственного за инфобез сотрудника должны быть наивысшими.

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

Второй шаг - психологический. Инфобез, это точно та же война. Только проходит она не в реальности, а в киберпространстве. Что отличает солдата от гражданского? Психология. На 1 месте слово "надо". Броник тяжелый и неудобный? Надо. Ползком неудобно? Но надо. Камуфляж не красивый, но так надо. Солдат, который забывает слово "надо" очень быстро приезжает домой в деревянном ящике. То же самое и про инфобез - расслабился, сделал что-то как захотел, а не как надо... И тебя поимели.

Третий шаг - стратегия. Инфобез строится как пирамида, только от вершины к основанию. На вершине стоят стратегические вопросы:

1. Классификация данных, определение того какие данные из всех необходимо защищать;

2. Какую цену готовы заплатить за защиту данных;

3. Какими данными можно жертвовать;

4. Какие процессы защищать;

5. Какое количество уровней защиты.

И т.д. и т.п. Последующие шаги будут делаться исходя из стратегических целей.

Для определения стратегических целей нужна полная инвентаризация данных компании (т.е. описание всей инфраструктуры), бизнес-процессов, составление матриц доступа тип данных (публичные данные, для служебного пользования, секретные, особой важности) / круг лиц имеющих доступ к данным. Главный принцип стратегии инфобеза - минимализм:

- хранимых данных должно быть минимальное количество, если что-то можно не хранить - это не должно храниться;

- доступ к каждой категории данных (кроме общедоступных) должен быть у минимально возможного числа лиц, если нет крайней необходимости, то доступа к данным быть не должно;

- объём программ и оборудования, обрабатывающих данные, должен быть минимально возможным. Всё неиспользуемое обрудование, части операционных систем, прикладное ПО которое может быть исключено - должно быть исключено;

Четвертый шаг - тактика. Каждый стратегический пункт нужно "разложить" в тактическом плане. На каждый тип данных, канал обмена данными, бизнес-процесс составляется матрица возможных угроз и меры по их предотвращению. Я предпочитаю (точнее предпочитал, до выхода из темы) делать это по матрице DCRUD (она является логической переработкой CRUD):

D - Denial of service - Отказ в обслуживании. Сервис и данные всегда должны быть доступны только пользователям у которых есть к ним доступ и недоступны всем остальным.

C - Create - Создание данных должно быть доступно только пользователям с соответствующими полномочиями.

R - Read - Чтение данных должно осуществляться только пользователям с соответствующими полномочиями.

U - Update - Обновление данных должно быть безопасно (можно восстановить всю историю обновления данных) и должно осуществляться только пользователям с соответствующими полномочиями.

D - Delete - Удаление данных недопустимо, данные могут быть помечены как не актуальные, но никогда не удаляться.

Пятый шаг - дисциплина и ответственность. Какой бы совершенной не была инфраструктура, как бы хорошо не были прописаны процессы, если требования и регламенты не будут соблюдать, то эффект на выходе - нулевой. Здесь опять же больше всего косячит именно менеджмент, они же "избранные"... Пароли на листочке на монитора, токены с ЭЦП руководителя гуляющие по всему офису... Ну вы поняли. Но главное не это - обычно, когда безопасник тыкает носом в явные нарушения правил ИБ происходит что? "Не мешай работать". Докладные, что "Вася нарушает правила ИБ, что может повлечь ... " - послушали, покивали... И на этом всё. Ну и т.д. и т.п.

Практический пример организации защищенного хранилища данных с нулевой утечкой (участвовал специалистом в разработке оного в 2015 - 2016-м году, сфера работы компании - медицина). Поскольку было давно, что-то могу помнить некорректно:

1. Провели инвентаризацию данных. Определили, что защищать нужно ПД клиентов компании (ФИО, паспортные данные), а так же услуги клиентов.

2. Сделали два хранилища - публичное и защищенное. В публичном было всё, кроме защищенных данных.

3. Защищенное хранилище физически размещалось в 2-х зданиях (для обеспечения надёжности хранения, например при пожаре в одном из зданий). Серверные в подвалах, на входе железные двери, внутри пост охраны, сами стойки за отдельной решеткой и ключей у охраны от неё нет. Доступ мог осуществляться только по приказу руководителя, который ЗАРАНЕЕ передавали охраннику, он впускал в назначенное время сотрудника, сотрудник СВОИМ ключом открывал доступ в серверную.

4. Все обмены данными (даже публичными) - зашифрованные, как минимум по 3-м ключам шифрования.

5. Сотрудникам организовали минимальный доступ к информации. Например, фамилию клиента видел только сотрудник проводящий первичную регистрацию. Дальше с клиентом работали только по имени-отчеству и ID.

6. Направления на анализы выдавались по UUID, результаты привязывались так же к UUID. Никаких фамилий и имён. Связь пациента и UUID анализа - в защищенном хранилище.

7. Сотрудники носили форму вообще без карманов, любая техника - запрещена. Из оборудования (кроме мед. приборов) разрешались только механические ручные часы. Нарушение правила - безусловное увольнение.

8. На рабочих ПК - урезанный до предела Linux, браузер в режиме киоска + самописная СКЗИ. По времени визита клиента выдавалась только минимум информации.

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

10. Никакого удаленного доступа. Вообще никакого и вообще никому.

11. Все обмены данными строго по "белым спискам" с логированием в журналах;

Защищенное хранилище технически представляло собой 5 серверов (начинка как у обычных ПК) + станция администрирования:

1. Станция администрирования - ПК с которого был доступ к серверам. Каждый сервер имел 2 сетевые карты, 1 сетевая в "общую" сеть и 1 в коммутатор к станции администрирования. Доступ к SSH только через порт 2 (только с IP и MAC станции администрирования и сервера бэкапов).

2. Сервер бэкапов. Сервер все бэкапы забирал сам мог подключаться к остальным серверам.

3. Сервер ключей шифрования. Сервер генирировал и хранил все необходимые ключи шифрования данных.

4. Сервер баз данных. База данных с полным запретом стандартных операций (SELECT, INSERT, UPDATE, DELETE). Все операции только через DDL, в каждой DDL обязательное журналирование всех операций. В таблицы допускалось только добавление строк, UPDATE, DELETE в DDL запрещены. Каждая запись, вместе с ЭЦП прошлой записи подписывается ЭЦП.

5. Сервер приложений. На данном сервере хранились микроприложения, которые работали с БД, IP-АТС и рассылки СМС. 1 задача - 1 приложение. Рассылки СМС брались напрямую из БД, на звонки динамически выделялись номера. То есть номер 0001 сейчас перенаправляется на +7 912 345 68 89, а через 5 минут на +7 912 345 89 68. Каждый сотрудник звонил только на "свой" номер. Т.е. если пациент не пришел, то "свой" номер врача указывал на номер пациента, который записан на текущий момент.

   Ни одно из приложений не было больше 1000 строк кода.

6. Сервер управления, который рулил всем вышеперечисленным.

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

Организация операций с данными от регистрации клиента до архивации:

1. Новый клиент заключает договор, его данные вносятся в форму, распечатывается подписывается. СКЗИ регистратуры шифрует каждый тип данных (фамилия отдельно, дата рождения отдельно, телефон отдельно, паспортные данные отдельно и т.д.) публичными ключами и полученные данные отправляет серверу приложений. Данные шифруются ключом рабочей станции и ключом сотрудника. Сервер приложений получает зашифрованные данные. По IP отправителя отправляет данные на расшифровку, потом по информации сервера управления отправляет данные на расшифровку ключом сотрудника, полученные данные отправляет в DDL СУБД (обращаем внимание - БЕЗ РАСШИФРОВКИ). Бумажная копия документов сразу упаковывается в конверт, опечатывается и сдается в архив. Из публичных данных остаётся только хеш номера телефона (так хранятся пароли).

2. При необходимости оказания услуги клиент называет номер телефона, его вбивают, так же шифруют ключом ПК и сотрудника, сервер приложений так же расшифровывает и возвращает по хешу телефона (из публичной части) UUID клиента зашифрованный ключами ПК и сотрудника.

3. Клиенту делается запись на время Х к врачу. Данные по записи так же шифруются и передаются в формате дата-время-UUID клиента-UUID врача.

4. По расписанию приёма сервер управления запрашивает связки UUID клиента и UUID врача. Сервер приложений получает команду на формирование пакета данных, которые будут отправлены на ПК врача - имя и отчество клиента, минимальные данные по профилю (т.е. врач видит только "свои" данные, историю посещений по своему профилю и результаты своих анализов). Данные шифруются ключом ПК врача и ключом самого врача.

5. Направление на анализы - так же по UUID. На направлении нет ни ФИО, ни возраста, ничего. UUID и список исследований.

6. Лаборатория вносит результаты так же по UUID.

Обращу внимание:

1. Все передачи данных идут строго по одной. Списки исключены полностью.

2. Все данные шифруются ПОСЛЕДОВАТЕЛЬНО ключами оборудования, сотрудников и сервисов. Расшифровка возможна ТОЛЬКО на том оборудовании куда идут данные и только сотрудником, которому данные предназначены;

3. Ключ оборудования прописан только в самом оборудовании, ключ сотрудника - на токене / флешке. Токен получается в начале рабочего дня под запись и сдаётся в конце рабочего дня так же под запись.

4. Защищаемые данные в открытом виде не хранятся НИГДЕ.

5. Все данные НИКОМУ и НИКОГДА не предоставляются.

6. Нарушение порядков обмена данными - алармы и журналы.

ОК, давайте представим, что конкуренты решили слить себе данные, что для этого нужно:

1. Украсть одну из серверных полностью. Весь комплекс работает так, что отсутствие одного из элементов делает остальные бесполезными. БД зашифрована, ключи на сервере ключей, сколько раз и какими ключами шифровалось на сервере управления, а как именно шифровалось на сервере приложений. На сервере бэкапов в принципе те же грабли (бэкапы зашифрованы).

2. Украсть все ключи запуска серверов у всех сотрудников.

3. Выкрасть всех разработчиков. Проект разрабатывало 7 человек. Каждый отвечал только за свой участок и защиту своего сектора. "В целом" работу системы понимали все, но конкретики по "чужим" участкам ни у кого не было.

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

Почему другие варианты не сработают?

1. "Засланные казачки" бесполезны. Просто потому что "точки слива" нет. Допустим решили получить данные на Х. Для этого нужно знать номер телефона, по которому он зарегистрировался, создать фиктивную запись к врачу, ОПЛАТИТЬ её и получить часть данных по его профилю. С учётом смсок с информированием о записи клиент вполне себе может и вопросы задать. А ответы в логах доступа - кто записывал, с какого рабочего места...

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

3. В регистратуре есть информация о человеке (при регистрации), больше - ничего (он ещё обследований не проходил).

4. При повторном обращении есть UUID и куда пошел человек. Больше - ничего.

5. В лаборатории есть информация, что по UUID есть такие-то результаты анализов. Больше - ничего.

P.S. У данной истории печальный финал. Система отработала несколько лет, прошла проверки в т.ч. по 152-ФЗ, а потом главврач клиники сменился. Новый систему заменил на "более продвинутую, менее сложную от одного из лидеров обеспечения безопасности персональных данных".

Для удобства переноса данных мы её быстро (за 15 минут) "ломанули" и за пару дней перетащили все данные (потребовалось участие всех разработчиков и всех админов). "Ломанули за 15 минут", это не хвастовство и не зря в кавычках - просто эта система имела уровень защиты исключительно от технически неграмотных честных людей, ибо в личных настройках ВСЕХ ПОЛЬЗОВАТЕЛЕЙ (правда довольно глубоко) был логин/пароль к центральной БД в открытом виде, БД разрешала удаленные подключения, а внутри БД разграничений доступа не было от слова совсем.

Закон, о котором речь в посте - второго типа т.е. государство не волнует как именно банки будут обеспечивать информационную безопасность, главное - результат. И в этом и есть настоящая проблема...

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

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

Самая большая проблема в том, что в банках работают люди...

Отмечал несколько раз, что при отказе в кредите (это происходит в нескольких банках), буквально в течении часа прилетает поток звонков от других банков и МФО. Иногда между отказом и первым звонком - секунды. Это значит, что слив персональных данных идёт на уровне ТОП-менеджмента этих самых банков и зашит в банковские приложения. То есть есть два варианта:

1. Есть менеджер, который продаёт данные конкурентам, есть разработчик, который этот слив написал и есть безопасник / сисадмин, который "прикрывает" канал слива данных.

2. То же самое, но без менеджера.

Сильно сомневаюсь, что такие вещи делаются бесплатно, а значит есть несколько лиц, которые зарабатывают (и полагаю не 3 копейки) на сливе данных. Очевидно, что эти люди не хотят лишаться дохода и тем более менять крутой московский офис на нары в Магадане. Естественно, такие люди на совещании не скажут - мы тут вашими данными барыжим и хотелось бы не сворачивать, поэтому палки в колёса будут ставить молча, но оптом.

Государство приняло решение о защите ПД. Тут помимо указанной выше "команды" пойдут следующие проблемы:

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

2. В нормальной структуре крупной организации руководитель ИБ (который должен запустить закон в действие) входит в высший эшелон управления (прямое подчинение гендиру / совету директоров). Если не так, то это "козёл отпущения типичный". То есть с учётом подлянке из п. 1 в штат нужно ввести "человека с улицы", причём ввести на самый верх. А "люди с улицы" имеют сразу несколько проблем для менеджмента всех уровней:

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

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

   - ИБ накладывает очень неудобные профдеформации (там много идейных), которые договариваться или не будут, или "договоряться", но при первом удобном случае сольют;

   - по должности ИБшник может нагнуть почти любого, а вот наоборот - почти нереально;

   - ИБшник имеет доступ много куда. Рано или поздно сливающие данные сотрудники будут вычислены и тогда их могут сдать гендиру, полиции или посадить на крючок и сделать расходником уже в своих планах;

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

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

4. Организационный пункт - нужно провести инвентаризацию процессов, внести изменения, обучить работать по новому, обеспечить исполнение новых регламентов. Каждый подпункт - проблема:

   - много не формализованных процессов, а из формализованных очень много "через жопу". И всё это г-но всплывёт вверх;

   - начИБ может указать точку проблемы и суть проблемы, а вот решение и как его встроить - задача руководителя, который отвечает за участок. ВНЕЗАПНО окажется, что довольно много управленцев - идиоты и не факт, что обойдётся без кадровых решений;

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

   - поскольку процессы изменились, изменяются и процессы управления. Создать или поправить процесс, это совсем не то, что по инерции поддерживать кем-то построенное ранее процесс. Это принципиально разные вещи. "Новый" банк вполне может стать неуправляемым.

   Можно сказать, что раньше менеджер ездил на Лексусе, а теперь его пересаживают на БМП-3...

5. Технический пункт. Приложение и безопасное приложение, это ОЧЕНЬ разные приложения. Кто читает компьютерную литературу, тот возможно замечал, что безопасности там внимание практически не уделяется. А про обеспечение абсолютной безопасности вопросы поднимаются реже, чем жемчужины на берегу встречаются. Более того, очень много "общепринятых правил" прямо конфликтуют с высокими уровнями ИБ.

   Грубо говоря "обычный программист" учился делать обычные мерседесы, а тут приходят и ставят задачу, что вот это вот нужно переделать так, чтобы в лоб РПГ-7 держал... Общего между А и Б примерно столько же, сколько между тем же мерседесом и Т-90, а у них - лапки.

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

6. После всего этого окажется ещё один страшный для менеджмента момент. Безопасность, это долго. До 5 - 8 раз. То есть если "как получится" 1 фишка в неделю на программиста, то при работе с защищаемыми данными (а там почти все такие) будет 1 фишка в 5 - 8 недель на программиста.

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

В банках (имеется ввиду уровень интересов сотрудников) защищать данные клиентов не интересно никому, следовательно этому процессу будут вставлять палки в колёса (кстати, то же самое происходило и с импортозамещением. На бумаге - импортозаместились, по факту ЕС и США заменили на Китай).

Почему я в этом уверен? Потому что банкиры сами это признали:

Банки предлагают отменить введение оборотных штрафов за повторную утечку персональных данных в размере до 500 млн руб. «Вызывает обоснованные сомнения тезис о том, что уплата столь значительных штрафов может заставить компании наращивать инвестиции в информационную безопасность (ИБ), поскольку все последние годы расходы на ИБ и без того растут на десятки процентов ежегодно. Напротив, при введении административной ответственности даже просто в силу самого факта утечки персональных данных при отсутствии вины компании ее средства будут уходить на уплату оборотных штрафов, а не на развитие ИБ. Крупный штраф может действовать как стимул только тогда, когда организации могут предотвратить его уплату своими добросовестными действиями», — говорится в письме НСФР.

Первоисточник

То есть представители банков в открытую говорят, что данные будут утекать и утекать многократно (возмущены частью с ПОВТОРНЫМИ утечками), вопросы ИБ рассматриваются только как финансовые (формулировка "инвестиции в ИБ", следовательно вариант замены идиотов на квалифицированных специалистов не рассматриваются), все действия делаются и будут делаться только формально (фраза "при отсутствии вины компании"), на обеспечение результата никто работать и не думает (фраза "предотвратить ... добросовестными действиями")...

И одновременно это - завуалированное предложение всё так и оставить. Мы делаем вид, что защищаем данные клиентов, вы делаете вид что данные клиентов защищены. А мошенничества с данными клиентов - это проблемы самих клиентов...

Уровень управленцев, которые это подписали неприятно поражает. Фразу выше можно переписать как: "Руководство и ТОП-менеджмент нашего банка некомпетентны в ключевых вопросах (а для банка надёжность - один из ключевых показателей), но зарплаты нам нравятся, поэтому мы хотим чтобы завтра было как вчера и ничего не менялось".

P.S. Если будет интересно, то могу коротко написать чем системы с ориентированием на безопасность отличаются от "обычных".

Теперь по пунктам, относящимся к ИБ.
1. На компах с обработкой персональных данных, согласно требованиям ФСБ, не должно быть никаких средств удаленного доступа (все эти энидески-аммиадмины). Выявили при проверке - штраф. И похер, что поддержка 1С-ок, СБИС-ов и прочей подобной херни работать по-другому просто не может.
2. На компах с обработкой персональных данных должен стоять только сертифицированный антивирь. Если приобретаете ту же самую версию, но без бумажного сертификата (она на пару тысяч дешевле из-за отсутствия коробочного комплекта) - она уже не канает. Также должна быть сертифицированная же шифровалка передаваемых данных типа випнета или криптухи (и нет, я не про Крипто-Про CSP - это софтина только для работы с ключами ЭЦП).
3. Бумажная волокита по ведению журналов и созданию правил обработки ПД.
И это только самые-самые начальные меры, которые валятся на эникея, потому что остальные на предприятии далеки от компов как от Луны, хотя подобный объем работ одну харю он просто не потянет.
Помимо, собственно, ИТ, ФСБ требует, чтобы на окнах стояли решетки, во избежание вторжения с улицы. К слову, следом приходят пожарные и требуют со своей стороны решетки убрать (в результате прикидываем, где штраф ниже - с решетками по указанию безопасников или без решеток по предписанию пожарных).
Фактически же требований и тонкостей там вагон, причем знать это все эникей в принципе не должен; для этого, мать его, специально учатся по соответствующему профилю и получают совершенно другие деньги.
Нет, можно конечно обратиться к специальным людям, но заломят эти специальные люди немалые деньги, и это будут только лишь руководства к действию.
Но во-первых, все эти руководства к действию - это тоже деньги, которые никто выделять не будет, а во-вторых, это все болото нужно уметь админить, и опять возвращаемся к эникею, который не обязан это все знать, тем более за свою зарплату, а если он умеет админить средства ИБ, то нахер ему самому занюханный МУП?
И пока у нас все происходит так, толку никакого не будет.