10 аргументов ЗА проведение в финансовой организации тестирования на проникновение

Некоторое время назад я стал свидетелем дискуссии, в которой специалисты по информационной безопасности (ИБ) вместе с Ит-администраторами долго и, как в итоге оказалось, не зря пытались согласовать и донести до руководителей своей организации полезность практики проведения внутренних (в режиме Red Team) и внешних тестов на проникновение. Присутствующее на совещании первое лицо практически не участвовало в беседе сторон, занималось, как водится, освоением нового телефона и не уделяло особого внимания поднятой технической проблематике, но в один прекрасный момент задало ключевой для дальнейшего хода обсуждения вопрос: "а зачем оно мне надо?". 

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

Для кого статья и как читать

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

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

Причина № 1

Вопрос.
Ваша финансовая организация подключена к платежной системе SWIFT?

Да Нет

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

В 2017 г. международная платежная система SWIFT, столкнувшись с кейсами по взлому присоединенных участников, разработала и последовательно внедрила в формате набора обязательных требований методологию по обеспечению необходимого и достаточного уровня защиты информации в разрезе четырех категорий участников. Первым этапом работ по приведению инфраструктуры финансовой организаций в соответствие требованиям по безопасности SWIFT стала самооценка, реализованная путем опроса ответственных лиц организации на сайте www.swift.com. в процессе самооценки одним из маркеров, выбранных SWIFT для измерения уровня защищенности, стало подтверждение проведения в последнее (срок указан не был) время в финансовой организации внешнего независимого теста на проникновение.

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

Причина № 2

Вопрос.
Ваша финансовая организация выполняет требования по ИБ Центрального Банка РФ?

Да Нет

Регулярное проведение тестирования на проникновение в защищаемый периметр финансовой организации становится обязательным для финансовых институтов (и операторов платежных систем в частности) в соответствии с требованиями обновленного 382-П.

Указанием Банка россии от 7 мая 2018 г. № 4793-у "О внесении изменений в Положение Банка россии от 9 июня 2012 года № 382-П "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком россии контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств" внесены изменения в п. 2.5 Положения 382-П. П. 2.5.5.1. финансовым организациям отныне вменено на стадиях создания и эксплуатации объектов информационной инфраструктуры обеспечить ежегодное тестирование на проникновение и анализ уязвимостей информационной безопасности объектов информационной инфраструктуры.

Причина № 3

Вопрос.
Обрабатывает ли ваша организация внутри своей инфраструктуры данные держателей пластиковых банковских карт в открытом виде?

Да Нет

Обработка данных пластиковых банковских карт внутри финансовой организации при выполнении ряда других обязательных сопутствующих условий налагает на финансовую организацию требования международных платежных систем о соответствии стандарту безопасности данных индустрии платежных карт (PCI DSS) и регулярного, на ежегодной основе подтверждения этого соответствия.

В пп. 11.3.1. и 11.3.2. "PCI DSS. требования и процедуры оценки безопасности", версия 3.2 от апреля 2016 г., однозначно прописаны требования международных платежных систем по проведению в подконтрольных организациях внешних и внутренних тестов на проникновение с обязательным контролем качества, методики, полноты, сроков и прочих реквизитов согласно международной методологии.

Причина № 4

Вопрос.
Вы работаете в ИБ данной финансовой организации менее трех месяцев?

Да Нет

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

Причина № 5

Вопрос.
У вашей организации есть постоянно действующее представительство (сайт) в Интернете?

Да Нет

Функционирование собственного сайта банковской организации в Интернете – как красная тряпка для злоумышленников, постоянно ищущих способ обогатиться за счет технических или организационных уязвимостей процесса сопровождения интернет-представительства. В качестве целей для атак злоумышленников выступают не только сотрудники банков, но и клиенты, желающие получить информацию на сайте, поработать в личном кабинете или совершить операцию в удобном пользовательском интерфейсе подсистемы класса "Интернет-банк". Как правило, релизный цикл до выпуска обновленной версии для таких сайтов может составлять от нескольких недель до нескольких месяцев. Минимальные сроки, обозначенные бизнесом для выпуска нового функционала сайта, неминуемо приводят к снижению качества программного кода и повышению рисков ошибок/уязвимостей кода, на котором пишется интернет-представительство. В таких случаях привлечение внешней организации или выполнение тестирования на проникновение интерфейсов сайта является обязательной превентивной процедурой, не позволяющей банку нести на регулярной основе финансовые, репутационные или комплаенс-риски. Подобные подход в финансовой организации может быть применен не только для сайта, но и для любого другого клиенто-ориентированного сервиса с доступом в/из Интернета (дистанционное банковское обслуживание, портал для 3D-Secure, информационные витрины данных и пр.).

Причина № 6

Вопрос.
Планирует ли ваша организация в ближайшее время слияние/поглощение другой финансовой организации?

Да Нет

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

Причина № 7

Вопрос.
Построен ли в вашей организации ситуационный центр по ИБ?*
^*Cвой или на аутсорсинге – значения в данном случае не имеет

Да Нет

При наличии в структуре финансовой организации непрофильного для бизнеса ситуационного центра по информационной безопасности (далее – SOC, Security Operation Center) руководство всегда интересует вопрос возврата вложенных в его создание и эксплуатацию инвестиций. Если финансовая организация пока не достигла объемов операций, продуктовой линейки и масштабов внутренней инфраструктуры банков-конкурентов из топ-20, то проиллюстрировать успехи в работе SOC выдающимися результатами по противодействию атакам реальных злоумышленников возможно не всегда/не регулярно. Заключение внешней независимой компании об уровне защиты в такой финансовой организации по результатам теста на проникновение в режиме Red Team с одной стороны, и отчет SOC о мониторинге, выявленных и предотвращенных попытках реализации атак на инфраструктуру финансовой организации – с другой, вместе с аналитическими материалами SOC о реализации схожих сценариев атак в сторонних банках и потерях этих банков, выраженных в рублевом эквиваленте, позволят эффективно и понятно продемонстрировать руководству финансовой организации значимость работы подразделения по информационной безопасности и необходимость в укреплении участка оперативного мониторинга SOC.

Причина № 8

Вопрос.
Получаете/применяете ли вы рекомендации от производителя (вендора) по повышению уровня защищенности программно-аппаратных компонентов инфраструктуры?

Да Нет

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

Причина № 9

Вопрос.
Планирует ли ваша финансовая организация вывод части ИТ-функций на полный или частничный аутсорсинг* или фриланс**?
^*К примеру, мониториг или техподдержку
^**Разработка программного обеспечения, тестирование кусков кода или иные задачи

 Да Нет

Для финансовых организаций, столкнувшихся с задачей по удаленному аутстаффингу, одним из первых встает вопрос организации надежного и безопасного доступа к инфраструктуре извне. С этой целью выстраивается многоуровневая подсистема безопасности, часто применяются облачные решения, внешние хранилища, выбранная часть процессов трансформируется, данные полностью или частично выносятся из закрытых внутренних сегментов в VLAN с ограниченным доступом – в общем и целом уровень информационной безопасности, мягко выражаясь, потенциально может быть снижен. Но не будем забывать, что речь все еще идет о финансовых организациях, а это деньги, персональные данные клиентов, финансовые данные о транзакциях, банковская строгая отчетность, юридически значимые электронные документы и электронные подписи. Все перечисленное при наличии удаленного доступа из Интернета может и очень быстро становится лакомым куском для злоумышленников. Внешний нарушитель вряд ли станет взламывать многоуровневую дорогостоящую защиту, он с большим интересом воспользуется доверием или безалаберностью аутстаффера и через него, как через плацдарм, получит доступ в промежуточную систему, закрепится и совершит свое вредоносное (в прямом смысле) воздействие. Такой сценарий имел место в 2015 г. В практике работы одного немаленького банка в казахстане. Ошибочно полагать, что своевременное проведение теста на проникновение смогло бы полностью защитить такой банк от атак и внимания злоумышленников. Однако анализ и частичная реализация рекомендаций специалистов по безопасности – тестировщиков системы защиты после проверки (в режиме "серого" или "белого ящиков"), согласованных с заказчиком сценариев доступа через типовые уязвимости позволили бы снизить вероятность проведения типовых атак (в том числе через скомпрометированную машину легального пользователя) и подложить в нужные места "соломку".

Причина № 10

Вопрос. Изменилось ли в последнее время количество подозрений на инциденты ИБ для инфраструктуры?*
*В общем по банку, не только в терминах 203-й формы отчетности

Да Нет

Если вы как лицо, ответственное за обеспечение защиты информации в финансовой организации, наблюдаете подозрительно меняющуюся (не только в сторону увеличения, но и в сторону уменьшения) динамику подозрений на инциденты, это в обязательном порядке должно привести к анализу причин такого изменения данных статистики. Рост количества событий с признаками инцидентов (вне зависимости от природы и ущерба для финансовой организации и клиентов) свидетельствует о повышении интереса к объекту защиты со стороны третьих лиц. Снижение количества инцидентов может демонстрировать неэффективность выбранных ранее критериев инцидента и/или способов и инструментов для получения атомарных событий. Возможно, что обновление какой-либо системы способствовало изменению профилей защиты, а возможно, что целевая система давно взломана злоумышленниками, а подсистема журналирования перенастроена таким образом, чтобы не фиксировать и не информировать службу мониторинга о наступлении критических событий (типовой сценарий – построение ботнета и прикрепление к нему круглосуточно работающих серверов с нефильтруемым Web-доступом в Интернет). Так или иначе, проведение теста на проникновение в этой ситуации позволит развеять (или подтвердить?) все несостоятельные гипотезы и снизить общий уровень паранойи в коллективе.

Выводы

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