Как стать автором
Обновить

Как Карл данные у Клары крал. Реконструкция ИБ-инцидента на 100+ млн. рублей

Уровень сложностиПростой
Время на прочтение8 мин
Количество просмотров5.7K
Всего голосов 6: ↑5 и ↓1+5
Комментарии26

Комментарии 26

После слов "Карл знал пароль от ящика Клары и читал ее почту по её же просьбе" далее можно не читать. Хотя .. в жизни далеко не редкость. Начальник, который часто отсутствует на работе (дачу чинит к примеру) часто просит кого-то из подчиненных его "заместить без уведомления старших" .. встречал и не раз. В части безопасников, кмк, прокол такого плана: "сотрудника нет в отделе (не отбит на входе системой), но письма ходят".. это как? Не панацея против фантазеров, но на первом этапе помогало.

Да это типичный прокол инфосеков в расслабленных конторах, полагающихся только на техметоды.

А если бы пересылки не было? Например, сотрудник снимал на камеру и потом отправлял извне.

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

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

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

И анальный досмотр

А что, Apple, между прочем, недавно так и сделала и вычислила инсайдера благодаря такому способу. Каждому сказала разные даты и одна из дат просочилась в сеть. Ну и всё.
https://forums.macrumors.com/threads/farewell-message.2389187/

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

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

Совместная работа с почтой делается так:

  1. Отбойник, что пока в отпуске обращайтесь на такой-то адрес рассылки по такой-то теме, на другой адрес рассылки по другой теме;

  2. Адрес рассылки рассылает письма на нужных подчиненных Клары, включая Карла при необходимости;

  3. Никто не видит все письма Клары, те кто и видит, видит только те, что отправлены на ящик рассылки;

  4. Никто никаким образом не имеет право доступа в чужой ящик даже по заявке (исключением как всегда является CEO, но это уже другая история с «охотой на китов»).

Да, я про это и говорю

Не, см. мой 4й пункт. Он никакой инструмент не предлагает, PAM, DLP и т.п. Пункт 4, ну и все пункты вместе предлагают методику не разрешающую:

разрешить совместную работу с почтой через специальный инструмент

Чем больше хешей снято с одного документа, тем лучше (вроде бы). Но возникает проблема: операция хеширования требует ресурсов для вычисления хешей. Чем больше хешей надо «снять», тем дольше будет обрабатываться один документ. Разработчикам приходится искать «золотую середину».

В том виде, как описано, непонятно, отчего [значительное] увеличение ресурсов. Что мы все абзацы текста обработаем и сольем их в один хеш, что для каждого абзаца посчитаем хеш индивидуально, количество операций не сильно изменится (оверхед только на начальные/конечные операции алгоритма хеширования, коих не может быть много)

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

То есть, если бы злоумышленник переводил все в txt формат, менял кодировку текста и вставлял в него "лишние" кустки текста, то его бы фиг поймали?

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

Почему нельзя было powershell-oм вытянуть настройки безопасности всех ящиков и получившейся базе посмотреть аномалии?

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

Я так понял, что Карл зайдя в ящик Клары, разрешил Карлу читать содержимое ящика. Написано "настроил к нему доступ в своем почтовом клиенте". Это право юзеров поумолчанию раздавать права на принадлежащие им объекты. Естественно эта аномалия будет видна. Кстати, смена пароля доступ не выключит. :)

В этом "выдуманном" деле чуть по-другому вышло: Карл просто знал логин\пароль Клары и на своей машине в Outlook добавил ещё одну учётную запись.

Извините, увидев Outlook и AD, я было подумал что речь идет о сервере exchange, в котором есть много способов, при верной настройке,выявления и пресечения подобного поведения Карла. Однако я не учел что он работает на Российском предприятии где предпочитают сэконмить вначале, чтобы в дальнейшем тратиться на ваш упоротый упорный, "выдуманный" труд ;)

Из описания обоих инцидентов можно предположить, что если бы не случайное стечение обстоятельств, то ИБ ни там ни там бы никакой утечки не обнаружила? Те никакие превентивные меры не сработали?

Я больше склоняюсь к мысли, что эти инциденты подтверждают высказывание, что нельзя быть на 100% защищённым. Думаю, что отдел ИБ нормальную работу проделал и лёгкие\средние дыры позакрывал. В итоге осталось что-то уникально, что сложно было предугадать. Например, человеческую безалаберность Клары.

Если в истории про банк ещё можно говорить о службе ИБ (как отдельном структурном подразделении), то в данной истории — не факт.


Более того, есть такая поговорка: "знает соседка, узнает и наседка." Клара — начальник, и в её отделе все знали учётки друг друга. Мне слабо верится, что в подобных условиях безопасники пребывали в неведении. ИМХО, их либо не было, либо они мало на что могли повлиять. Плюс, Вы же сами написали: безопасность VS бизнес. Думаю, это был вполне осознанный "компромисс."


А в случае с банком мне непонятно ещё кое-что. Во-первых, я-то думал, что сотрудников с особым допуском должны ещё при приёме на такую должность проверять по полной программе. Во-вторых, неужели человеку, имеющему доступ к столь значимой информации, а тем более начальнику, нельзя платить достаточно для того, чтобы он не решился на преступление? Понимаю, что мысли о "лёгком заработке" могут возникать у многих, но перейти от мыслей к делу… Тут, в моём понимании, потенциальная выгода должна значительно превышать потенциальные потери.

Я работал в паре банков и везде были какие-то возможности, которые бы мог использовать недобросовестный сотрудник, если бы он там был.

Возможно, я сейчас огребу от безопасников, но мне кажется, что при построении системы безопасности главное — не обеспечить "идеальность" системы, а сделать максимально дорогой попытку успешно её обойти: как в плане прилагаемых усилий, так и с точки зрения возможных последствий. Разумеется, максимально дорогой для злоумышленника, а для себя — максимально дешёвой. Понятно, что невозможно помешать злоумышленнику запомнить какую-то информацию, но сколько он так "вынесет", не вызвав подозрений?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий