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

Один аналитик SOC, когда его решили перевести на работу из дома, задал сакраментальный вопрос: «Я живу в однушке со своей девушкой и ее кошкой, на которую (кошку, а не девушку) у меня аллергия. При этом у нас всего один стол, за которым мы едим, а во внетрапезное время, моя девушка на нем раскладывает чертежи, она модельер-конструктор одежды. И где мне прикажете разместить 3 монитора, которые мне разрешили временно забрать с работы?» Ну а поскольку это только один из множества вопросов, которые возникают при переводе работников SOC (Security Operations Center) на удаленку, я решил поделиться нашим опытом; особенно учитывая, что именно сейчас для одного из заказчиков мы как раз проектируем центр мониторинга кибербезопасности (SOC) с нуля и он решил на ходу переобуться и попросил учесть в проекте возможность работы его аналитиков и специалистов по расследованию инцидентов из дома.

Вот уже около 20 лет Cisco живет без привычного периметра, а ее сотрудники пользуются всеми преимуществами удаленной работы. Помню, когда я пришел в 2004-м году в Cisco, я получил на руки корпоративный ноутбук с установленным Cisco VPN Client и получил право работать из… да откуда угодно. За это время я работал из дома и гостиницы, из электрички и такси, из самолета на высоте 10000 метров и в метро. По сути у нас реализован принцип «работа там, где я», а не «я там, где работа». Как нам удалось это сделать? Как мы реализовали концепцию «доверенного предприятия», которая вот уже много лет помогает нам не замечать неприятных событий, заставляющих многих из нас безвылазно сидеть по домам (разумеется, есть ряд процессов, которые требуют физического присутствия, например, производство оборудования)?

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

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

Я уже не раз рассказывал о бесплатном решении Cisco Threat Response (CTR), которое позволяет существенно снизить время на расследование инцидентов, характеризующихся множеством разнотипных индикаторов компрометации — хэшей файлов, IP-адресов, имен доменов, адресов e-mail и т.п. Но прошлые заметки были посвящены либо примерам использования CTR с отдельными решениями Cisco, либо его интеграции с ГосСОПКОЙ и ФинЦЕРТом. Сегодня я хотел бы описать, как можно применить CTR для расследования отдельных хакерских кампаний, которые могут использовать множество векторов против множества различных целей внутри компании. В качестве примера возьмем уже упомянутую мной в одной из предыдущих статей кампанию DNSpionage.

Тема удаленного доступа сейчас на подъеме, но обычно при ее описанию речь идет либо о решениях, устанавливаемых на устройствах сотрудников (например, описанный вчера Cisco AnyConnect), либо о решениях, устанавливаемых на периметре. Такое впечатление, что именно эти два набора защитных средств позволяют полностью исключить угрозы со стороны удаленных пользователей, подключающихся к корпоративной или ведомственной инфраструктуре. В этой заметке я хотел бы рассмотреть применение средств класса NTA (Network Traffic Analysis) для мониторинга удаленного доступа.

На прошлой неделе вышла у меня дискуссия на тему удаленного доступа и различных VPN-клиентов, которые можно поставить на рабочее место сотрудника, отправляемого работать домой. Один коллега отстаивал «патриотическую» позицию, что надо использовать «абонентские пункты» к отечественным шифраторам. Другой настаивал на применении клиентов от зарубежных VPN-решений. Я же придерживался третьей позиции, которая заключается в том, что такое решение не должно быть придатком периметрового шифратора и даже не клиентской частью VPN-шлюза. Даже на производительном компьютере не совсем правильно ставить несколько защитных клиентов, которые будут решать разные задачи — VPN, идентификация/аутентификация, защищенный доступ, оценка соответствия и т.п. Идеально, когда все эти функции, а также иные, объединены в рамках единого клиента, что снижает нагрузку на систему, а также вероятность несовместимости между различным защитным ПО. Одним из таких клиентов является Cisco AnyConnect, о возможностях которого я бы и хотел вкратце рассказать.

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

Чтобы помочь нашим заказчикам, как текущим, так и потенциальным, организовать защищенную работу возросшего количества удаленных пользователей, мы предлагаем бесплатные пробные лицензии с увеличенным сроком действия новым заказчикам и возможность превышения количества пользователей свыше приобретенного ранее пакета без дополнительной платы текущим заказчикам, которые используют уже эти решения, по трем основным линейкам продуктов:

Атаки на браузеры являются достаточно популярным вектором для злоумышленников, которые через различные уязвимости в программах для серфинга в Интернете или через слабо защищенные плагины к ним пытаются проникать внутрь корпоративных и ведомственных сетей. Начинается это обычно на вполне легальных и даже внесенных в белые списки сайтах, которые при этом имеют уязвимости, используемые злоумышленниками. Дополнения (add-on), расширения (extensions), плагины (plugin), будучи однажды установленными даже в благих целях, начинают мониторить пользовательскую активность, “сливать” разработчикам историю посещенных сайтов, внедрять в посещаемые страницы назойливую рекламу, иногда вредоносную. Пользователи часто даже не понимают, что рекламный банер, который они видят на странице сайта, добавлен ими же установленным плагином, а не является изначально внедренным на странице. А иногда такие плагины и расширения и вовсе служат входной дверью для злоумышленников на компьютеры пользователей, с которых начинается победное шествие по внутренней сети предприятия. Именно через такие расширения злоумышленники могут устанавливать вредоносный код, отслеживать данных или красть их. При этом не всегда мы в состоянии заставить всех пользователей правильно настраивать свои браузеры и следить за их конфигурацией. Что же делать в такой ситуации, когда всего один пользователь может стать самым слабым звеном и открыть “ворота в ад”? Решения по мониторингу сетевого трафика могут помочь и в данном кейсе.

Продолжаем рассмотрение кейсов для систем анализа сетевого трафика (NTA) применительно к целям кибербезопасности. Сегодня мы посмотрим, как такие решения можно применить для обнаружения очень непростых, целенаправленных и очень эффективных кампаний под названием DNSpionage и Sea Turtle.

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

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

На одном из мероприятий завязалась у меня интересная дискуссия на тему полезности решений класса NTA (Network Traffic Analysis), которые по полученной с сетевой инфраструктуры телеметрии Netflow (или иных flow-протоколов) позволяет выявлять широкий спектр атак. Мои оппоненты утверждали, что при анализе заголовков и сопутствующей информации (а NTA не занимается анализом тела данных пакетов в отличие от классических систем обнаружения атак, IDS) нельзя увидеть многое. В данной статьей я попробую опровергнуть это мнение и чтобы разговор был более предметным, приведу несколько реальных примеров, когда NTA действительно помогает выявлять различные аномалии и угрозы, пропущенные на периметре или вообще минувшие периметр. А начну я с угрозы, которая вышла на первые места в рейтинге угроз прошлого года и, думаю, останется таковой в этом году. Речь пойдет об утечках информации и возможности их обнаруживать по сетевой телеметрии.

Продолжаю рассказ о развитии системы Cisco Threat Response, которая постепенно превращается в полноценную систему управления инцидентами, объединяющую вместе все решения Cisco по информационной безопасности; и при том бесплатную. В прошлый раз я рассказывал о том, как CTR может быть интегрирован с Cisco Email Security для помощи в расследовании инцидентов, источником которых является электронная почта. Сегодня поговорим о том, как CTR интегрируется с системой обнаружения сетевых аномалий Cisco Stealthwarch Enterprise. Это новая интеграция и про нее еще не все знают.

В последнее время мы стараемся на наших мероприятиях не просто рассказывать о наших решениях в области кибербезопасности, а добавляем в них интересную интеллектуальную фишку, которая позволяет слушателям не только узнать что-то новое о Cisco, но и проверить свои знания в игровой форме. На Cisco Connect мы проводили «Свою игру» по теме сетевой безопасности и разыгрывали среди участников различные призы. На прошедшем в ноябре SOC Forum мы также не обошли вниманием тему интеллектуальных игр по ИБ и предложили всем участникам попробовать себя в роли аналитиков центров мониторинга кибербезопасности (Security Operations Center, SOC).

У Cisco достаточно агрессивная стратегия поглощения компаний на рынке, которая не только приносит нам доходы по ключевым направлениям нашей деятельности, но и создает то, что иностранцы любят называть словом challenge, которое на русский часто переводят как “вызов”. Возможно когда-то это и было вызовом для нашей службы информационной безопасности, но сейчас мы успешно решили эту задачу и ее решением я бы и хотел поделиться в этой заметке. Суть же первоначальной проблемы была простой — после анонса факта поглощения какой-либо из компаний в среднем уходит около одного года на ее полную интеграцию — как с точки зрения бизнеса, так и с точки зрения ИТ-инфраструктуры. Но год — это достаточно большой срок, в течение которого мы должны не только обеспечить доступ новым членам нашей команды доступ к корпоративным ресурсам, но и обеспечить мониторинг поглощенной компании с точки зрения информационной безопасности. О том как мы решали эту задачу я и хочу поговорить.

Итак, я продолжу статью, посвященную мониторингу безопасности облачных провайдеров. В первой части я рассказывал об опыте Cisco в работе с внешними облачными сервисами, а также о наблюдениях Cisco, с которым мы столкнулись при построении или аудите SOCов наших заказчиков. Взяв в первой части в качестве примера три самых популярных решения от компаний Amazon, Microsoft и Google, которые являются IaaS/PaaS-платформами, сегодня наступила пора поговорить о мониторинге SaaS-платформ — Dropbox, Salesforce.com, Slack и Apple Business Manager, а также о том, какие SIEM сегодня лучше всего подходят для мониторинга облачных платформ.

Пример: Мониторинг ИБ в SaaS на базе Dropbox

Если на базе AWS, Azure или GCP вы можете создать почти полный аналог своей корпоративной инфраструктуры, только в облаке, то есть облачные сервисы, которые выполняют одну конкретную задачу, например, файловое хранилище, как это делает Dropbox. Этот сервис давно вышел за рамки обычной пользовательской хранилки, предоставляя своим корпоративным пользователям целый набор защитных механизмов:

• идентификацию и аутентификацию пользователей
• контроль доступа к файлам
• удаленное удаление данных
• управление доверенными устройствами
• интеграцию с внешними решениями по ИБ (DLP, SSO, DRM, eDiscovery, SIEM и т.п.)
• регистрация событий безопасности.

Перенос данных и приложений в облака представляет собой новую проблему для корпоративных SOCов, которые не всегда готовы к мониторингу чужой инфраструктуры. По данным Netoskope среднее предприятие (видимо все-таки в США) использует 1246 различных облачных сервиса, что на 22% больше, чем год назад. 1246 облачных сервисов!!! 175 из них касаются HR-сервисов, 170 связано с маркетингом, 110 — в области коммуникаций и 76 в финансах и CRM. В Cisco используется “всего” 700 внешних облачных сервисов. Поэтому меня немного смущают эти цифры. Но в любом случае проблема не в них, а в том, что облака достаточно активно начинают применяться все большим числом компаний, которые хотели бы иметь те же возможности по мониторингу облачной инфраструктуры, как и в собственной сети. И эта тенденция нарастает — по данным американской счетной палаты к 2023 г. в США собираются закрыть 1200 ЦОДов (6250 уже закрылись). Но переход к облаку — это не просто “а давайте перенесем наши сервера к внешнему провайдеру». Новая ИТ-архитектура, новое программное обеспечение, новые процессы, новые ограничения… Все это вносит существенные изменения в работу не только ИТ, но и ИБ. И если с обеспечением безопасности самого облака провайдеры научились как-то справляться (благо рекомендаций достаточно много), то с облачным мониторингом ИБ, особенно на SaaS-платформах, есть существенные сложности, о которых мы и поговорим.

Начну с некоторых цифр:

• 80% успешных атак начинается с фишинга (а кто-то считает, что и вовсе 95%)
• 10% сигналов тревоги в большинстве SOC связано с фишинговыми атаками
• Рейтинг успешных кликов на фишинговые ссылки — 21%
• Рейтинг загрузки/запуска вредоносных вложений – 11%

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

Когда речь заходит о мониторинге безопасности внутренней корпоративной или ведомственной сети, то у многих возникает ассоциация с контролем утечек информации и внедрением DLP-решений. А если попробовать уточнить вопрос и спросить, как вы обнаруживаете атаки во внутренней сети, то ответом будет, как правило, упоминание систем обнаружения атак (intrusion detection systems, IDS). И то, что было единственным вариантом еще лет 10-20 назад, то сегодня становится анахронизмом. Существует более эффективный, а местами и единственно возможный вариант мониторинга внутренней сети — использовать flow-протоколов, изначально предназначенных для поиска сетевых проблем (troubleshooting), но со временем трансформировавшихся в очень интересный инструмент безопасности. Вот о том, какие flow-протоколы бывают и какие из них лучше помогают обнаруживать сетевые атаки, где лучше всего внедрять мониторинг flow, на что обратить внимание при развертывании такой схемы, и даже как это все “поднять” на отечественном оборудовании, мы и поговорим в рамках данной статьи.