Слепая безопасность
Вы заметили, что сегодня встретились два противоположных тренда? Рост расходов на информационную безопасность и рост ущерба от инцидентов информационной безопасности.
Первый тренд – опережающий рост рынка информационной безопасности. Увеличиваются продажи рынка в целом и особенно некоторых ниш, постоянно появляются новые продукты и целые классы продуктов. Внедряются передовые технологии, редкий инструмент не щеголяет терминами «искусственный интеллект», «большие данные», «квантовое шифрование», «распределенный реестр» и другими. Растет число и занятых в области корпоративной информационной безопасности, появляются SOCи, CERTы и другие службы. Правительства принимают доктрины и концепции, регуляторы закручивают гайки, вводят все новые требования и ограничения.
Второй, встречный, тренд – постоянный рост потерь от инцидентов информационной безопасности, исчисляемый как в миллионах записей персональных данных и другой чувствительной информации, так и в миллиардах рублей и долларов. Что это? Не в коня корм? Компании тратят на информационную безопасность все больше, причем как абсолютно, так и относительно, в процентах от расходов на ИТ и цифровизацию. При этом чем выше траты, тем ощутимее потери, а атаки все чувствительнее и приносящие больший ущерб. Можно подумать, что чем больше у нас безопасности, тем у нас меньше безопасности.
Как и любая глобальная проблема, такая корреляция вызвана несколькими причинами. Тут и повысившийся объем оцифрованных данных, и количество систем, в которых они хранятся и обрабатываются. И рост квалификации хакеров, на чьей стороне теперь часто играют правительственные службы, – никто не запрещал всем им использовать все современные технологии нам во вред. И еще несколько базовых причин. Но в этой статье мы поговорим о другом.
Нацеленность на атаку
Даже в названии некоторых продуктовых ниш присутствует слово «анти»: антивирус, antiDDoS, antiAPT, антиспам, антифрод, антифишинг и т. д. В других наименованиях такое «анти» явно не звучит, но подразумевается: предотвращение утечек, предотвращение несанкционированного доступа, межсетевой экран и т. п. Сегодня мы строим безопасность от угроз и видов атак – для каждой угрозы и каждого типа атаки подбираем свой продукт. Таксономия продуктов безопасности насчитывает почти сто видов вариантов от тысяч способов атак. Может быть, проблема в том, что мы так увлечены атаками, что забыли про то, что защищаем?
Знаем ли мы объект защиты?
Летом я проводил семинар по защите процессов и удивился, насколько мало студенты, а среди них были специалисты и даже начальники безопасности российских банков, знают о процессах, которые они защищают. Они на отлично знали требования по безопасности Банка России, ФСТЭК и PCI Council. Они хорошо понимают application security. Иногда могут объяснить, как работает их автоматизированная банковская система (АБС). Но при рассмотрении примера из банковского бизнеса никто не смог объяснить, как именно в их банке происходит процесс изменения кредитного лимита у физического лица. В общих чертах этапы такого процесса и их очередность они объяснить еще могли: заявка, оценка, принятие решения, уведомление клиента и согласование с ним, выпуск юридически значимых документов, само изменение. Но какие именно события в каких информационных системах происходят при реализации такого процесса, мы предполагали уже вместе – точно не знал никто. Но если ты не знаешь, какие события где происходят и как они связаны между собой, то как ты найдешь среди тысяч изменений кредитных лимитов, вручную проводимых администратором АБС, ту, которая не согласована с кредитным комитетом? У тебя дорогущие IDM и PAM, но какой в этом прок, если ты не можешь отличить легитимную операцию в АБС от нелегитимной? Как ты отличишь обращение оператора к данным для обработки от обращения к таким же точным данным, но для фотографирования и выкладки на продажу? У тебя DLP и снимки экрана каждые десять секунд, но какой в них толк, если ты не можешь отличить обращение к данным по просьбе клиента от самовольного?
Мы начали мозговой штурм и «нагенерили» десяток работающих систем и сотню событий в них. Например, заявки на повышение кредитного лимита на уже имеющуюся кредитную карту могут поступить: через личный кабинет, по электронной почте, в мессенджере на смартфоне, с телефона, с личным визитом в офис. Предложение увеличить кредитный лимит может также поступить от инфоробота, который заметит, что старым лимитом клиент пользуется достаточно давно и не нарушает условий погашения. Инициативу может проявить и клиентский менеджер. И это только первый этап – заявка. Представляете, сколько событий и их сочетаний в информационной системе порождает всего один этап процесса. И это только сильные, однозначные сигналы. На них накладывается море слабых, сопутствующих – уточняющих коммуникаций по всем каналам, внутренних согласований, циклов обсуждений и т. п.
Простой пример
Давайте еще проще: следующему кейсу больше пятнадцати лет, но из его решений я видел только остроумные «костыли», не более. DLP система перехватывает письмо, содержащее детализацию операций по счету, предположим, Иванова Ивана Ивановича, отправляемое, скажем, на адрес iii@email.ai. Пропускать или нет? Правильный ответ «не знаю, не хватает данных». Какие данные нам нужны? Да много нам различных данных надо.
Есть ли в банке такой клиент? А если есть, да еще не один, то какой из них? Заказывал и оплатил ли он такой сервис? Пользовался ли им раньше? Его ли данные в письме? Указан ли именно этот почтовый адрес в его заявке на рассылку? Какое отношение к обслуживанию этого клиента имеет отправитель? Если письмо отправляет почтовый робот, то кто и на основании чего внес данные Иванова И. И. в список рассылки?
Теперь вы понимаете, что такое «контекстно зависимое событие». Его легитимность или нелегитимность зависит от такого количества информации, которой никак не может обладать не только DLP-система, но и сам безопасник, ее настраивающий. Нет никакой технической возможности прописывать все правила для каждого контекста каждого события, поэтому в реальной жизни банковская DLP-система, чтобы не дай бог, не нарушить легитимный процесс, пропустит это письмо и сохранит лог события, пометив его как потенциальный инцидент, связанный с рассылкой финансовой информации. Буква Р в аббревиатуре DLP означает prevention, но кто же это сегодня вспоминает – большая часть угроз, против которых работает DLP, контекстно зависима, поэтому многие из них работают в режиме мониторинга, если не архива.
Причины пассивности
Без понимания контекста безопасность стала пассивной – другого выбора у нее просто нет. Пропустить атаку для безопасника менее рискованно, чем заблокировать легитимный процесс. Чего там говорить о DLP, если прикладные межсетевые экраны (WAF) и средства обнаружения вторжений работают в красиво названном «режиме форензики», это означает, что они не только не могут, но даже и не собираются блокировать атаки.
Пока не будет разомкнут порочный круг: не понимаем контекст события – боимся ложно-положительных срабатываний – переходим в режим наблюдения и расследований, защиты цифровых процессов не обеспечить. Найти виновных – найдем, причины установим, накажем злоумышленников, если, конечно, найдем. Но не защитим. Мы забыли, что социальный договор между бизнесом и безопасностью состоял в том, что в ответ на финансирование службы безопасности бизнес будет избавлен от угроз информационной безопасности. Но безопасники первым его нарушили, уйдя в мониторинг и расследования, а потому не удивительно, что бизнес не видит результатов от деятельности безопасников и вскоре это бессмысленное финансирование прекратит.
Разорвать столь ущербную логическую цепочку можно только с самого начала, с понимания объекта защиты. Настала пора смотреть не только на то, откуда идут возможные атаки, но и на то, к чему они приводят или могут привести – к нарушению функций цифровых систем. Без понимания этого безопасникам в цифровой экономике придется несладко.
Можно возразить: есть же решения, блокирующие атаки, например, антивирусы или NGFW. Конечно, совсем позиции безопасности не сданы, но все атаки, которые блокируют средства безопасности, направлены на инфраструктуру. Да, мы умеем зашифровать канал, заблокировать аномальную активность или отбить DDoS-атаку. Но не можем отличить легитимные действия в конкретном процессе от нелегитимных – не можем обнаружить платеж, сгенерированный трояном или мошенником, среди тысячи ежедневных платежей. При проведении расследования мы, конечно, найдем признаки атаки или мошенничества, но обычно денег это уже не вернет.
Разграничение ответственности
Можно было бы сказать: это не дело информационной безопасности, пусть им занимается антифрод, внутренний контроль или экономическая безопасность. Но в цифровых системах разделить роли данных подразделений уже очень непросто – все выявляют аномальную активность, ищут признаки нарушений в миллиардах событий в цифровых системах, которые в цифровой экономике и есть бизнес. Уязвимости и заказные вирусы используются при мошенничестве, ошибки операторов и сбои ведут к потерям – как вы проведете линию «это за пределами зоны моей ответственности»? Сегодняшние безопасники поделили свои обязанности так: мы помним про триаду «целостность-доступность-конфиденциальность», но пусть доступностью занимаются айтишники, а целостностью – антифрод, мы занимаемся только конфиденциальностью. Возможно, подобная позиция и помогает отбиваться от упреков, но не гарантирует выживания: во многих компаниях безопасников, которых так долго всем миром выводили из-под ИТ-служб, снова загоняют в ИТ-отделы, защитой инфраструктуры удобнее заниматься там. А безопасности, если она вообще сохраняется, достается согласование требований к цифровым системам с требованиями законодательства. Ни интересных задач, ни бюджетов, ни карьеры.
От информационной безопасности к цифровой
Чем больше бизнес-системы становятся цифровыми, тем меньше времени остается на реакцию на инцидент, тем быстрее наступает время безотзывности транзакции, тем больше возможный ущерб. Тем скорее бизнес станет задавать неудобные вопросы типа «а за что я вам плачу деньги?». Но время перестроиться еще есть. Хорошим девизом защитников «цифры» мог бы стать лозунг «мы знаем, что защищаем».
Смотреть все статьи по теме "Информационная безопасность"
Опубликовано 01.11.2019
