Взлом Equifax: разбор полетов

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

Сам по себе взлом не представлял собой ничего необычного. В марте 2017-го года неизвестные злоумышленники использовали известную уязвимость на публичном Web-сайте для доступа к внутренним системам Equifax. В мае того же года злоумышленники стали красть данные из внутренних баз данных, пока 29 июля Equifax не обнаружила взлом и не блокировала действия злоумышленников.

Есть несколько интересных моментов, на которые я бы хотел обратить внимание в этой истории:

• Злоумышленники использовали известную к моменту первичной атаки уязвимость в Apache Struts Server, которая была идентифицирована US CERT двумя днями ранее. Это в очередной раз поднимает вопрос о том, как должен быть выстроен процесс устранения уязвимостей? Надо ли их устранять сразу по факту публикации бюллетеня по ним? А может надо ждать публикации сведений об экслойтах для уязвимости? Или опираться на рейтинг CVSS? Вопросов много, но однозначных ответов пока нет. В любом случае, это лишний раз напоминает нам, что злоумышленники далеко не всегда используют 0Day для своих атак.
• В процессе расследования выяснилось, что Equifax знал об уязвимости, так как получил от US CERT соответствующий бюллетень, который был распространен среди системных администраторов. Но... оказалось, что список этих лиц был устаревшим и в него не входили те администраторы, которые отвечали за установку патчей на уязвимом Web-портале. Наблюдается либо определенный пофигизм к поддержанию такой информации в актуальном состоянии, либо конфликт между ИТ и ИБ, что бывает очень часто.
• Интересно, что Equifax также заявил, что через неделю после получения бюллетеня от US CERT, они сканировали свою сеть, включая и уязвимый web-портал, но используемый сканер ничего не показал, что в очередной раз поднимает вопрос о том, надо ли целиком доверять используемым техническим решениям одного вендора и не надо ли их дублировать (не обязательно тратя на это еще деньги и используя решения open source).
• Equifax заявляет, что злоумышленники так долго могли скрывать свою деятельность, потому что использовали шифрование своей активности. Я уже неоднократно писал о том, что шифрование - это палка о двух концах и оно активно используется злоумышленниками для скрытия своих действий, существенно усложняя жизнь специалистам по ИБ. И им не нужно получать никаких лицензий ФСБ для этого. Так как это происходит все чаще, то необходимо иметь определенную стратегию для борьбы с зашифрованным трафиком.
• Самое интересное, что в процессе проведения регламентных работ в инфраструктуре Equifax выяснилось, что одно из решений по мониторингу и инспекции сетевого трафика не видело вредоносной активности в зашифрованном трафике из-за ошибок конфигурации этого устройства. Если быть точнее, то на данном устройстве был просроченный более чем 10 месяцев (!) цифровой сертификат. На мой взгляд это чистой воды халатность администраторов, которые почти год вообще не мониторили внутренний сетевой трафик. Это же показывает, что помимо защиты периметра необходимо иметь решения и для мониторинга аномалий во внутренней инфраструктуре. Без этого сегодня никуда.
• В другом источнике было написано, что используемое для инспекции сетевого трафика оборудование не соответствовали заявленным вендором цифрам по производительности, что часто приводило к задержкам в обработке трафика. В итоге настройки оборудования были изменены так (в сторону ухудшения ИБ), чтобы производительность устройства не снижалась.
• Никакой сегментации в инфраструктуре Equifax не было, что привело к неконтролируемому доступу к множеству различных баз данных, а не только к тем, которые были связаны с уязвимым Web-сервером. А ведь сегментация - это то, что дает чуть ли не 50% успеха в сетевой безопасности и при этом не требует особых затрат, так как задействует встроенные возможности сетевого оборудования.
• Интересный факт - позже выяснилось, что Equifax использовал оборудование компании FireEye для мониторинга угроз во внутренней сети, но FireEye на следующий день после известия о взломе Equifax удалил со своего сайта историю успеха о внедрении в кредитном бюро своих решений. Предположу, что это результат эмоционального решения руководства ИБ-вендора, который не хотел связывать себя с взломом, но мы все прекрасно понимаем, что кеш поисковых систем сохраняет все, в том числе и удаленные материалы. А на репутации такой факт сказывается гораздо больше, чем если бы мир знал, что Equifax защищался с помощью FireEye. Если верить отчету Счетной палаты США, то вина лежала целиком на администраторах Equifax, которые почти год не обновляли цифровой сертификат на средстве инспекции сетевого трафика. 

Выводы из этого кейса вполне очевидны и я бы назвал несколько рекомендаций, которые позволили бы предотвратить его. Необходимо:

1. выстроить процесс управления уязвимостями и четко понимать, как и когда устранять обнаруженные уязвимости.
2. тесно контактировать с ИТ-командой, отвечающей за процесс управления патчами и иметь актуальный список лиц, которые занимаются устранением дыр.
3. мониторить внутренний трафик с помощью решений класса NTA (NBAD), которые позволяют обнаруживать аномалии и угрозы, проникшие из-за периметра или инициированные изнутри.
4. поддерживать актуальную конфигурацию как сетевого оборудования, так и средств защиты.
5. сегментировать сеть для предотвращения несанкционированного доступа. 
6. понимать риски использования злоумышленниками шифрования для скрытия своей активности и использования решений, которые борются с этим (EDR на оконечных устройствах, устройства для SSL Offload, инспекция DNS-трафика для обнаружения взаимодействия с инфраструктурой злоумышленников, использование технологий машинного обучения для обнаружения вредоносной активности внутри зашифрованного трафика без его расшифрования).

PS. Примечательно, но во взломе Equifax русских хакеров не обвиняли :-)