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

Помните, мы рассказывали, что наши команды центра мониторинга и реагирования на кибератаки сидят в разных городах, объясняли причины такого решения и расписывали плюсы? Все это так — у территориальной распределённости, несомненно, есть серьезные преимущества, но почему же тогда так мало компаний решаются на создание удаленных офисов? Или сажают на регион одинокого волка от продаж и дерут с него три шкуры, ибо работа его удалена и из Центра временами не видна? Все потому, что дьявол, как известно, в деталях. Для руководства компании вынос офисов из «нерезиновой» — это экономический плюс, но как сделать так, чтобы команды не разваливались, оставались активными и эффективными?

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

Очередной блок наших публикаций по теме IdM будет посвящен финансам. А именно двум самым сложным и болезненным темам – оценке проекта внедрения IdM и его обоснованию перед руководством.

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

Если вы работаете в компании, которая попадает под действие №187-ФЗ («О безопасности критической информационной инфраструктуры Российской Федерации»), то вам не нужно объяснять, что такое ГосСОПКА и зачем она нужна. Для остальных поясним: ГосСОПКА расшифровывается как Государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак. Архитектурно она представляет собой единый территориально распределенный комплекс центров различного масштаба, обменивающихся информацией о кибератаках. Такие центры обязаны создать все компании, которым принадлежат объекты критической информационной инфраструктуры (такие компании называют субъектами КИИ). Цель всей этой масштабной государственной инициативы – создать между важнейшими организациями страны систему обмена информацией о ведущихся кибератаках и тем самым обеспечить возможность превентивной защиты.

Достаточно долгое время основным документом, определяющим принципы функционирования центров ГосСОПКА и их взаимодействия с вышестоящим центром, были «Методические рекомендации по созданию и эксплуатации центров ГосСОПКА», разработанные ФСБ. Мы ранее делали обзор данного документа и отмечали, что основным фокусом его внимания было построение процессов по управлению инцидентами и контролю защищенности субъектов ГосСОПКА. Но в то же время этот подход оставлял достаточно большое поле для различного толкования того, какой объем задач должен решать центр ГосСОПКА и какие именно инструменты для этого требуются. Недавно вышли «Требования к средствам, предназначенным для обнаружения, предупреждения и ликвидации последствий компьютерных атак и реагирования на компьютерные инциденты». Попробуем разобраться, чего же ждет регулятор от компаний, строящих у себя центры ГосСОПКА, и исследовать этот вопрос.


Иерархия взаимодействия центров ГосСОПКА

Сегодня даже беглый поиск по hh.ru выдает около 90 разных по задачам и функционалу вакансий с магическим словом «аналитик» и довольно приличными условиями оплаты. Перед глазами многих кандидатов сразу проплывают большие данные и машинное обучение, зарплата начинает плясать сильно выше рынка и заигрывать нулями. Так кто же такие аналитики центра мониторинга, «отвечающие за то, чтобы заказчика не взломали»? Чем они занимаются и что нужно знать и уметь, чтобы попасть на эту позицию?

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

Под катом история о том, как мы переписали основной компонент продукта с 17-летней историей (!) со Scheme на Clojure, и все сразу заработало как надо (ну, почти :)).

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

Под катом – подборка самых необычных расследований, проводимых с помощью DLP.

Мы уже некоторое время рассказываем о кадровых задачах и модели развития сотрудников в Solar JSOC. Наверняка вам удалось прочитать статью о том, как студенту третьего курса попасть в центр мониторинга и реагирования, или как инженеру прокачать опыт для вертикального движения в структуре Solar JSOC (из первой линии во вторую). Не за горами материалы о дальнейшем вертикальном развитии аналитиков и о том, как сервис-менеджер может превратиться в полноценного CISO. Но пока хотелось бы поговорить о другом.

Рыба всегда ищет, где глубже, а человек — где лучше. Это расхожее утверждение довольно четко отражает стремления сотрудников и кандидатов. Только слово «лучше» для каждого из них имеет свое значение. Отнюдь не всегда оно связано с финансовыми условиями, грейдами/малиновыми штанами или временем в пути от дома до офиса.

Часто бывает, что сотрудник просто устал от текущих задач и стремится не столько «прокачать» опыт, т.е. заниматься тем же, но глубже, сколько найти для себя новые вызовы в смежных направлениях. В таких случаях мы всячески стараемся помочь ему обрести новое призвание и получить не «вертикальное», а «горизонтальное» развитие внутри Solar JSOC. Сложность лишь в том, чтобы не упустить этот момент, а также дать человеку все необходимое «снаряжение» для покорения новых вершин.

Вот о нескольких таких случаях мы и попробуем рассказать.

И снова всем привет. Цикл «SOC for …» продолжает свое движение и развитие. Первый слой внутренней кухни центров мониторинга и реагирования на инциденты мы уже успели осветить в предыдущих статьях, поэтому попробуем понемногу пойти вглубь, к техническим подробностям и более тонким проблемам.

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

Коллеги, вчера началась и до сих пор продолжается мощная ботнет-атака. Все 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 в сутки. Каждый шестой инцидент – критичный. При этом для наших клиентов, в числе которых «Тинькофф Банк», «СТС Медиа» или «Почта Банк», вопрос оперативности информирования об атаке и получения рекомендаций по противодействию стоит очень остро.

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