Продолжение поста «Банки выступили против нового закона о штрафах за утечки данных»

В связи с моей болезнью заранее прошу прощения, что мои посты могут быть немного более неточными, чем обычно.

В своем последнем посте я написал:

Если вам интересно, я кратко напишу о том, чем системы, ориентированные на безопасность, отличаются от «обычных» систем".

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

- невозможно полностью защитить персональные данные;

- Возможна полная безопасность персональных данных.

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

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

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

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

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

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

второй шаг – психологический. Господин Инфовез, это точно такая же война. Однако это происходит в киберпространстве, а не в реальной жизни. Чем отличается солдат от гражданского?Психология. Номер один — слово «должен». Броня тяжелая и неудобная? нуждаться. Ползать неприятно? Но это необходимо сделать. Камуфляж — это некрасиво, но так и должно быть. Солдата, который легко забывает слово «надо», отправляют домой в деревянном ящике. То же самое касается и информационной безопасности. Я расслабился и сделал то, что хотел, а не то, что мне нужно было сделать. И тогда я потерпел неудачу.

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

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

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

  3. Данные, которые можно пожертвовать;

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

  5. Каков уровень защиты.

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

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

- Должен храниться минимальный объем данных, а то, что не может быть сохранено, не должно храниться;

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

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

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

D — Отказ в обслуживании — Отказ в обслуживании. Услуги и данные всегда должны быть доступны только тем пользователям, которые имеют к ним права доступа, и должны быть недоступны для других.

C — Создание. Создание данных должно выполняться только пользователями с соответствующими привилегиями.

R — Чтение — Данные могут быть прочитаны только пользователями с соответствующими разрешениями.

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

D – Удаление – Удаление данных не допускается. Данные можно пометить как нерелевантные, но они никогда не будут удалены.

Пятый шаг – дисциплина и ответственность. Независимо от того, насколько совершенна инфраструктура или насколько хорошо написаны процессы, если не соблюдать требования и правила, результаты будут нулевыми. Опять же больше всех не справляются менеджеры, они же "избранные"... Пароли пишутся на бумаге на мониторах, а жетоны с цифровой подписью менеджера бродят по офису. Это... Ну вы поняли идея. Но дело не в этом. Что обычно происходит, когда охранник указывает на явное нарушение правил информационной безопасности? «Пожалуйста, не беспокойте меня на работе». «Вася нарушил правила информационной безопасности, в том числе...» - они выслушали, кивнули.. и вот и все и т д.

Практический пример построения безопасного хранилища данных с нулевой утечкой (участвовал в разработке в качестве эксперта с 2015 по 2016 год. Специализация компании — медицинское обслуживание). Это было очень давно, возможно, я неправильно помню:

  1. Мы провели инвентаризацию данных. Мы определили, что необходимо защищать персональные данные клиентов нашей компании (имена, паспортные данные) и службы поддержки.

  2. Я создал два репозитория: общедоступный и защищенный. Все данные, кроме защищенных, были общедоступными.

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

  4. Все обмены данными (в том числе публичные) шифруются с использованием как минимум трех ключей шифрования.

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

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

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

  8. Рабочий ПК — урезанный Linux, браузер в режиме киоска + доморощенный CIPF. О времени посещения клиентов была предоставлена ​​лишь минимальная информация.

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

  10. Никакого удаленного доступа. Ни за что, ни от кого.

  11. Весь обмен данными осуществляется строго в соответствии с «белым списком», в который входят журналы входа;

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

  1. Станция управления — ПК, с которого вы получаете доступ к серверу.

    Обратите внимание: Как банки проверяют кредитную историю.

    Каждый сервер имел две сетевые карты: одна была подключена к «общедоступной» сети, а другая — к коммутатору станции управления. Доступ к SSH осуществляется только через порт 2 (только со станций управления IP и MAC и резервных серверов).

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

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

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

  5. Сервер приложений. На этом сервере находились микроприложения, которые работали с базой данных, IP-АТС и отправкой SMS. 1 задание – 1 заявка. Электронные SMS-сообщения извлекались непосредственно из базы данных, а номера телефонов присваивались динамически. То есть номер 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. «Пропавшие казаки» бесполезны. Просто потому, что нет «точки слива». Предположим, вы решили получить данные для X. Для этого вам необходимо узнать зарегистрированный X номер телефона, записаться на фиктивную встречу с врачом, оплатить сбор и получить некоторые данные из его профиля. Учитывая СМС-информирование о записи, клиент может задаться вопросом: И ответ по журналу доступа - кто его записывал и с какого рабочего места...

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

  3. Реестр содержит информацию о человеке (на момент регистрации) и никакой дополнительной информации (еще не проверено).

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

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

PS У этой истории печальный конец. Данная система находится в эксплуатации уже несколько лет и прошла следующие испытания: По данным 152-ФЗ, в клинике с тех пор сменился лечащий врач. Новая система была заменена «более продвинутой и менее сложной системой от одного из лидеров в области безопасности персональных данных".

Для облегчения передачи данных мы сразу «разбили» данные (в течение 15 минут) и перетащили все данные за несколько дней (требовалось участие всех разработчиков и всех администраторов). «Они победили за 15 минут», это не хвастовство, не просто так в кавычках. Эта система имела лишь определенный уровень защиты от технически неграмотных и честных людей. Это был открытый текст логина и пароля для центральной базы данных, база данных допускала удаленные подключения, и не было никаких ограничений доступа внутри базы данных.

[my]Утечка данных счета-фактуры Банк ЦБ РФTextMatОтвет на сообщениеДлинный пост 14

Больше интересных статей здесь: Банки.

Источник статьи: Продолжение поста «Банки выступили против нового закона о штрафах за утечки данных».