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

Кто виноват и что делать?

Архитектура Cisco Digital Network Architecture использует основные идеи SDN — разделение уровней управления и транспорта и автоматизацию задач, связанных с управлением корпоративной сетью. Однако Cisco вышли за рамки концепции SDN и реализовали сеть на основе намерения (Intent-Based Network), сделав её максимально адаптированной для потребностей современных организаций.

Атаки на браузеры являются достаточно популярным вектором для злоумышленников, которые через различные уязвимости в программах для серфинга в Интернете или через слабо защищенные плагины к ним пытаются проникать внутрь корпоративных и ведомственных сетей. Начинается это обычно на вполне легальных и даже внесенных в белые списки сайтах, которые при этом имеют уязвимости, используемые злоумышленниками. Дополнения (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, на что обратить внимание при развертывании такой схемы, и даже как это все “поднять” на отечественном оборудовании, мы и поговорим в рамках данной статьи.

Ни для кого не секрет, что в настоящий момент всем современным организациям необходима внутренняя сеть передачи данных. При этом подавляющее большинство администраторов подобных сетей считают, что качественная сеть, построенная на базе решений А-вендоров, таких как Cisco – это прерогатива средних и крупных компаний. Небольшие же организации привыкли использовать либо оборудование и программное обеспечение производителей уровня ниже, либо использовать оборудование для домашнего использования. Недостатки этого подхода очевидны: отсутствие качественной поддержки, неоднородность сетевой инфраструктуры, сложное управление и мониторинг и многое другое.

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

Убедиться в простоте и надёжности решений Cisco Small Business на практике можно в специально организованном для этого show-room в г. Санкт-Петербург 7 августа 2019 года: любой ИТ-специалист может посетить демонстрацию и ознакомиться с возможностями решений Cisco Small Business, а также проконсультироваться с экспертами по вопросам внедрения и эксплуатации. Записаться на посещение show-room-а можно по ссылке.

Сертификационная программа Cisco существует уже 26 лет (была основана в 1993 году). Многим хорошо известна инженерная линейка сертификаций CCNA, CCNP, CCIE. В этом году программа дополнилась еще и сертификациями для девелепоров, а именно DevNet Associate, DevNet Specialist, DevNet Professional, DevNet Expert.

Сама программа DevNet существует в компании более пяти лет. Детально про программу Cisco DevNet уже было написано на хабре в этой статье.

И так что мы имеем касательно новых сертификаций:

1. Как и для инженерных сертификаций, существует четыре уровня DevNet сертификаций — Associate, Specialist, Professional, Expert.
2. Инженерные сертификации дополняются модулями по направлению автоматизации/программированию.
3. В сертификациях для разработчиков есть модуль связанный с основами сетевой программируемости

Давайте рассмотрим каждую из сертификаций, в том числе контент и на кого ориентирована.

Прошлая заметка про нашу платформу поиска угроз Cisco Threat Response привела к тому, что я получил несколько вопросов о том, как интегрировать CTR с государственными сервисами ГосСОПКА и ФинЦЕРТ? И поэтому я решил написал еще одну небольшую заметку и показать, как можно выжать максимум пользы из индикаторов компрометации, отправляемых вам ФСБ и ЦБ. На самом деле ничего сверхестественного и сложного в такой интеграции нет — наши регуляторы используют машинночитаемые и стандартизованные во всем мире форматы индикаторов компрометации (я боюсь представить, что будет, если хеши для вредоносных семплов будут рассылаться по стандарту ГОСТ Р 34.11-2012, а не MD5/SHA1/SHA256), но пока не предоставляют API для автоматизации работы с ними. В любом случае их не так сложно использовать в Cisco Threat Response. Чтобы не скриншотить эту процедуру, а показать ее в динамике, я записал небольшое видео, которое демонстрирует на реальном примере с атакой на уязвимый протокол RDP как просто организовать взаимодействие ГосСОПКА с решениями Cisco по безопасности.

Примерно раз в полгода какой-нибудь американский журналист публикует конспирологическую заметку о том, что Cisco вот-вот купит Splunk и зайдет в сегмент SIEM, так как это именно то, чего нам не хватает для окончательного завоевания мирового рынка ИБ (хотя мы и так уже были названы в марте вендором №1). Однако пишущие журналисты обычно забывают о том, что Cisco уже разработала SIEM, которую назвала OpenSOC и отдала для дальнейшего развития в Apache Foundation (где OpenSOC развивается уже под именем Apache Metron). Но это шутка, а на самом деле причина иная. В мире нет вендора, который бы имел широкое продуктовое портфолио по ИБ и при этом мог поддерживать мультивендорное решение SIEM. Редкие попытки такого рода приводят либо к тому, что вендор не может сделать нормальное вендорнезависимое решение по мониторингу и оно начинает проигрывать нишевым игрокам (Splunk, IBM, Micro Focus, Elastic, LogRhytm и др.), сконцентрированным только на развитии своего флагманского продукта, либо к тому, что SIEM превращается в обычную консоль для собственных продуктов без нормальной подсистемы управления и реагирования (все силы бросаются на мониторинг). Cisco, дважды входя в реку под названием “SIEM” (первый раз с CiscoWorks SIMS, а второй — с Cisco MARS), сегодня фокусируется на немного ином решении, а именно Cisco Threat Response, которое представляет собой платформу для поиска угроз (threat hunting) и которая в перспективе должна стать связующим звеном для всех решений Cisco в области кибербезопасности.

Мы продолжаем цикл статей про Cisco Hyperflex. В этот раз мы познакомим вас с работой Cisco Hyperflex в условиях высоконагруженных СУБД Oracle и Microsoft SQL, а также сравним полученные показатели с конкурентными решениями.

Кроме того, мы продолжаем показывать возможности Hyperflex в регионах нашей страны и с радостью приглашаем вас посетить очередные демонстрации решения, которые на этот раз пройдут в городах Москва и Краснодар.

Москва – 28 мая. Запись по ссылке.
Краснодар – 5 июня. Запись по ссылке.

Гиперконвергентные решения до недавнего времени являлись не очень подходящим решением для СУБД, тем более с высокой нагрузкой. Однако, благодаря использованию в качестве аппаратной платформы для Cisco Hyperflex фабрики UCS, за 10 лет доказавшей свою надежность и производительность, уже сегодня эта ситуация изменилась.

Хотите узнать больше? Тогда добро пожаловать под кат.

Последние несколько лет Cisco активно продвигает новую архитектуру построения сети передачи данных в ЦОД — Application Centric Infrastructure (или ACI). Некоторые с ней уже знакомы. А кто-то даже успел внедрить её на своих предприятиях, в том числе и в России. Однако для большинства ИТ-специалистов и ИТ-руководителей ACI пока является либо непонятной аббревиатурой, либо всего лишь рассуждением о будущем.

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

Мы продолжаем знакомить вас с гиперконвергентной системой Cisco HyperFlex.

В апреле 2019 года компания Cisco в очередной раз проводит серию демонстраций нового гиперконвергентного решения Cisco HyperFlex в регионах России и в Казахстане. Записаться на демонстрацию можно через форму обратной связи, перейдя по ссылке. Присоединяйтесь!

• Санкт-Петербург (1-19 апреля 2019 года)
• Самара (10 апреля 2019 года)
• Алма-Ата (11 апреля 2019 года)

Ранее мы публиковали статью о нагрузочных тестах, выполненных независимой лабораторией ESG Lab в 2017-ом году. В 2018 году характеристики решения Cisco HyperFlex (версия HX 3.0) значительно улучшились. Кроме того, конкурентные решения тоже продолжают совершенствоваться. Именно поэтому мы публикуем новую, более свежую версию сравнительных нагрузочных тестов от ESG.

Летом 2018-ого года лаборатория ESG провела повторное сравнение Cisco HyperFlex с конкурентами. Учитывая современную тенденцию использования Software-defined-решений, в сравнительный анализ были также добавлены производители подобных платформ.

Тестовые конфигурации

В рамках тестирования HyperFlex сравнивался с двумя полностью программными гиперконвергентными системами, которые устанавливаются на стандартные x86 серверы, а также с одним программно-аппаратным решением. Тестирование проводилось с использованием стандартного для гиперконвергентных систем ПО – HCIBench, которое использует инструмент Oracle Vdbench и автоматизирует процесс тестирования. В частности, HCIBench автоматически создает виртуальные машины, координирует нагрузку между ними и генерирует удобные и понятные отчеты.  

Было создано 140 виртуальных машин на кластер (35 на ноду кластера). Каждая виртуальная машина использовала 4 vCPU, 4 ГБ RAM. Локальный диск ВМ был 16 ГБ и дополнительные диск 40 ГБ.

Одной из горячих тем в кибербезопасности в последнее время стали SOCи (Security Operations Center), которые не очень удачно переводят на русский язык как «центры мониторинга безопасности», умаляя тем самым одну из важных функций SOC, связанную с реагированием на инциденты ИБ. Но сегодня мне не хотелось бы вдаваться в терминологические споры, а вкратце рассказать об одном из проектов, который был реализован в нашем внутреннем SOCе — системе управления индикаторами компрометации (IoC) GOSINT. На самом деле служба ИБ Cisco не использует термин «Security Operations Center», заменяя его более приземленным CSIRT (Cisco Security Incident Response Team). Так вот GOSINT — это один из многочисленных наших проектов open source, который предназначен для сбора и унификации структурированной и неструктурированной информации об угрозах (threat intelligence). Я уже рассказывал о том, как мы мониторим безопасность нашей внутренней инфраструктуры, теперь пришел черед рассказать о том, что помогает нам это делать наиболее эффективно.