Коллеги, вчера началась и до сих пор продолжается мощная ботнет-атака. Все IP-адреса сканируются на предмет наличия свежей уязвимости в программном обеспечении Cisco IOS (CVE-2018-0171, CVSS=9,8), позволяющей удаленно выполнять команды на устройствах Cisco. Бот заходит на устройство и удаляет конфигурацию, записывая вместо нее свои файлы. Мы фиксируем попытки эксплуатации уязвимости с более ста разных адресов, из разных стран, и их пул продолжает расширяться.

Разработчики Cisco уже выпустили патчи для обнаруженной уязвимости.

Мы рекомендуем установить патчи как можно скорее. Под катом — уведомление, которое Solar JSOC рассылает клиентам, с деталями уязвимости и рекомендациями по противодействию.

Мы в Solar JSOC на постоянной основе собираем данные о событиях и инцидентах информационной безопасности в инфраструктурах заказчиков. На базе этой информации мы раз в полгода делаем аналитику, которая демонстрирует, как меняются атаки на российские организации. Сегодня мы собрали для вас самые интересные тренды второго полугодия 2017 г.

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

Если спросить, какие требования мы предъявляем к кандидатам, ответ может показаться очень банальным: определенные технические компетенции, аналитический склад ума, внимательность… Однако как проверить эти качества, на что опираться, чтобы свести к нулю влияние субъективной оценки? Рассказываем, на что мы обращаем внимание и какие задания даем кандидатам.

Говорят, в 70-х годах Геннадий Зайцев, первый президент легендарного Ленинградского рок-клуба, так сформулировал принцип отбора музыкантов: «Беглость пальцев — дело наживное. Был бы человек хороший».

Возможно, если бы мы с Геннадием Борисовичем решили за рюмкой чего-нибудь горячительного пожаловаться друг другу на сложности в подборе кадров, то обнаружили бы много общих моментов. Когда мы собирали первую команду Solar JSOC, рынка сервисов мониторинга и противодействия кибератакам фактически еще не существовало, следовательно, не было ни готовых специалистов под эти задачи, ни даже четких критериев поиска. Нам предстояло собрать команду уникумов, но до этого — много раз пробовать новое, ошибаться и снова пробовать. Именно про команду сегодня и поговорим: как это было в самом начале и к чему мы пришли в результате.

Где-то благодаря самостоятельной инициативе организации, где-то – вследствие активных действий государства в части регулирования вопросов защиты АСУ ТП и в целом критических инфраструктур РФ, в большинстве компаний на текущий момент запущен, по крайней мере, один из процессов:

• Анализ текущего среза состояния ИБ в АСУ ТП (аудит).
• Проектирование и построение соответствующих систем защиты АСУ ТП.
• Либо в дополнение к этому – построение или модернизация непосредственно самих АСУ ТП с учетом соответствующих требований безопасности.

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

Больша́я часть наших заказчиков — это промышленные и производственные компании. Каким бы крупным и значимым ни был фронт-офис и корпоративная сеть подобных компаний, основной их бизнес — непосредственно производство, а также связанные с ним задачи и процессы. И зачастую, решая с заказчиками задачи мониторинга и реагирования на кибератаки, мы начинаем с корпоративной сети и периметра, а в итоге приходим к закрытым сетям и сегментам производственных и технологических сетей.

Мы решили собрать наш опыт защиты АСУ ТП и рассказать о самых частых проблемах и популярных мифах о безопасности в данной области.

Составили для вас подборку книг, которые помогут прокачать полезные для работы скиллы и узнать что-то новое, не делая над собой титанических усилий.

В последнее время (и тематический SOC-форум не стал исключением) все чаще можно слышать заявления, что люди в процессах SOC вторичны и технологии в состоянии заменить большинство из них — «Смерть Tier-1 аналитиков», «Искусственный интеллект, победивший самого умного пианиста/филолога/кандидата естественных наук», «Автоматические обучаемые правила» и вот это все. Наш же опыт подсказывает, что до власти SkyNet еще далеко, и недооценивать роль человека даже в базовых процессах SOC пока не стоит.

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

Мы уже рассказывали о том, почему секционирование баз данных очень важно для производительности DLP-системы и как мы реализовывали его в PostgreSQL. В этой статье речь пойдет об Oracle.

Специфика использования СУБД в DLP-решениях состоит в том, что объем данных прирастает очень быстро. Их невозможно держать в оперативном архиве, и долговременное хранение – это необходимость в компании численностью свыше хотя бы 50 человек. При этом оперативный архив наполняется так быстро, что отдавать информацию в долгосрочный архив приходится раз в 2 недели или чаще. Использование только встроенных средств СУБД требует знаний и опыта. Это главная сложность, и она, в общем-то, очевидна «на берегу».

Кроме того, возникают проблемы, не очевидные сразу. Как вернуть из долгосрочного архива партицию с данными более старой версии приложения и прицепить к более свежей? Что делать, если у них разных формат хранения данных? Что делать, если подключение секции было прервано, и она «зависла» между долговременным и оперативным архивом?

Продолжаем цикл наших статей «SOC for beginners». В прошлый раз мы говорили о том, как внедрить в компании Threat Intelligence и не пожалеть. Сегодня хотелось бы поговорить о том, как организовать процессы, чтобы обеспечить непрерывный мониторинг инцидентов и оперативное реагирование на атаки.

В первом полугодии 2017 г. совокупный среднесуточный поток событий ИБ, обрабатываемых SIEM-системами и используемых Solar JSOC для оказания сервиса, составлял 6,156 миллиардов. Событий с подозрением на инцидент – в среднем около 960 в сутки. Каждый шестой инцидент – критичный. При этом для наших клиентов, в числе которых «Тинькофф Банк», «СТС Медиа» или «Почта Банк», вопрос оперативности информирования об атаке и получения рекомендаций по противодействию стоит очень остро.

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

Статью «Один квартал из жизни SOC. Три инцидента без купюр» весьма активно плюсовали, так что мы решили рассказать о еще одной интересной атаке, расследованием которой мы недавно занимались.

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

Некоторое время назад крупная компания с развитой инфраструктурой обратилась к нам за помощью. Проблема заключалась в странных событиях в инфраструктуре компании:

1. Рабочие станции и серверы внезапно уходили на перезагрузку и выводились из домена.
2. Пользователи обнаруживали, что их учетная запись заблокирована.
3. Компьютеры некоторых сотрудников стали «тормозить» без видимой причины.

В предыдущих статьях «SOC for beginners» мы рассказали, как устроен и как организовать базовый мониторинг инцидентов и контроль защищенности инфраструктуры. Сегодня речь пойдет о Threat Intelligence — использовании внешних источников данных об угрозах.

При всей кажущейся простоте, запуск работы с Threat Intelligence — чуть ли не самый длительный и болезненный процесс. Исключение, наверное, составляют только те случаи, когда у вас на рабочих станциях эталонные образы ОС с включенным Application Control, пользователи — без прав администратора, а доступ в интернет — исключительно по белым спискам. К сожалению, мы за все время работы таких компаний пока не встречали. В связи с этим все интересующиеся темой Threat Intelligence – добро пожаловать под кат.

Привет, Хабр!

Мы тут часто пишем о том, что работа центра мониторинга и противодействия кибератакам невозможна без определенных процессов (мониторинг, реагирование, расследование инцидентов и т.д.) и, конечно, без систем защиты (AV, WAF, IPS и т.д.).

То же самое мы объясняем заказчикам, но они, быстро пересчитывая деньги в кармане, иногда в ответ спрашивают: "А можно нам SOC в базовой комплектации?"

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

Внимание! Среди вариантов возможны honeypots.

Продолжаем цикл наших статей о центрах мониторинга кибератак для начинающих. В прошлой статье мы говорили о Security Monitoring, инструментах SIEM и Use Case.

Термин Security Operations Center у многих ассоциируется исключительно с мониторингом инцидентов. Многим сервис-провайдерам это, в принципе, на руку, поэтому мало кто говорит о том, что мониторинг имеет ряд серьезных ограничения в плане защиты от кибератак.

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

В ходе работы DLP-система ежедневно перехватывает огромные массивы информации – это и письма сотрудников, и информация о действиях пользователей на рабочих станциях, и сведения о хранящихся в сети организации файловых ресурсах, и оповещения о несанкционированном выводе данных за пределы организации. Но полезной эта информация будет только в случае, если в DLP реализован качественный механизм поиска по всему массиву перехваченных коммуникаций. С тех пор, как в 2000 году увидела свет первая версия нашего DLP-решения, мы несколько раз меняли механизм поиска по архиву. Сегодня мы хотим рассказать о том, какие технологии мы использовали, какие видели в них преимущества и недостатки, и почему мы от них в итоге отказывались. Возможно, кому-то наш опыт окажется полезен.

Мы продолжаем рассказывать о буднях Security Operations Center – о реагировании на массовые кибератаки, любопытных кейсах у заказчиков и правилах корреляции событий, позволяющих нам детектировать атаки на заказчиков и пр.

Сегодня мы хотим открыть новый цикл статей, задача которого – продемонстрировать, с какими задачами и трудностями сталкиваются все начинающие (и не очень) SOCостроители, и главное – поделиться нашим опытом по их решению.

…Всё началось с отдела маркетинга. Эти милые люди подумали и решили, что нам (специалистам пресейла и сервисов) следует написать некоторое количество статей «на разные интересные темы». Темы они, как водится, придумали сами, исходя из видящихся им «потребностей рынка». (При этом, если взглянуть на них с нашего ракурса, темы были, мягко говоря, «не очень»…)

Нашей команде, отвечающей за развитие системы управления доступом и учётными записями пользователей Solar inRights, пришла в голову идея миссионерства (как бы громко это ни звучало): если уж писать обращение «к граду и миру», то пусть оно будет полезным инструментом для принятия взвешенных решений. Поэтому решено составить целостный цикл материалов, который поможет чётко осознать, какие действия и процедуры сопровождают внедрение IdM-решения.

Центр мониторинга и реагирования на киберугрозы Solar JSOC опубликовал исследование киберугроз за первое полугодие 2017 г., подготовленное на базе обезличенной статистики по инцидентам ИБ у заказчиков. Полученная аналитика отвечает на вопросы о том, кто, как, в какое время и с использованием каких векторов и каналов атакует крупнейшие российские компании. Отчет предназначен для информирования служб ИТ и информационной безопасности о текущем ландшафте угроз и основных трендах.

В первой половине 2017 года средний поток событий ИБ составлял 6,156 миллиардов в сутки, из них около 950 в сутки – события с подозрением на инцидент (172 477 за полгода). Это примерно на 28% больше, чем в первом полугодии 2016 года. Доля критичных инцидентов составила 17,2%. Таким образом, если в 2016 году критичным был каждый 9-й инцидент, то теперь – уже каждый 6-й. Предполагается, что такая динамика связана с общим повышением интенсивности массовых и целенаправленных атак на организации.

С каждым годом парк информационных систем компаний все больше разрастается, вместе с ним пропорционально усложняются задачи управления, контроля и разграничения прав доступа сотрудников к информационным ресурсам. Наличие на рынке решений, частично перекрывающих функционал друг друга, дает плодотворную почву для новых и новых дебатов. Как должна быть реализована система управления доступом – через интеграцию с ITSM или внедрение отдельного IGA-решения?

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