Как стать автором
Обновить
86.74
Солар
Безопасность за нами
Сначала показывать

Эффективность Security Operations Center: на какие параметры смотреть?

Время на прочтение 5 мин
Количество просмотров 4.2K
Когда мы говорим о KPI и эффективности, возникает вопрос: а что вообще должен отслеживать SOC в своей повседневной деятельности? С одной стороны, тут все понятно: во-первых, соблюдение SLA, а во-вторых, возникающие события с подозрениями на инциденты. Но ведь статистику событий можно смотреть под разными углами. А еще проблемы с источниками, а еще аномалии, а еще нагрузка на SIEM и т.д. – параметров масса. Какие из них достойны дашборда аналитика – об этом поговорим ниже.


Читать дальше →
Всего голосов 13: ↑13 и ↓0 +13
Комментарии 0

Исследование атак со стороны профессиональных кибергруппировок: смотрим статистику техник и тактик

Время на прочтение 6 мин
Количество просмотров 4.8K
«Это был тяжелый год» — не только в свете коронавируса, локдауна, экологических бедствий и прочего, но и в части информационной безопасности. С переходом на удаленку многие компании выставили наружу ходы в инфраструктуру, что открыло новые возможности для мамкиных хакеров. Параллельно и профессиональные группировки, использующие гораздо более сложные инструменты, стали атаковать чаще. Мы подвели итоги за неполный год и свели в единую статистику те техники и тактики, с которыми мы чаще всего сталкивались в процессе мониторинга инфраструктур заказчиков.


Читать дальше →
Всего голосов 14: ↑14 и ↓0 +14
Комментарии 3

Строим безопасную разработку в ритейлере. Опыт интеграции с кассовым ПО GK

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

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


Читать дальше →
Всего голосов 14: ↑14 и ↓0 +14
Комментарии 1

Строим безопасную разработку в ритейлере. Часть 2, SAP-приложения

Время на прочтение 5 мин
Количество просмотров 2.8K
Недавно мы начали рассказывать вам о своём опыте выстраивания процесса безопасной разработки для крупного ритейлера. Если вы вдруг пропустили этот момент, то можете прочитать первую часть о безопасной разработке порталов и мобильных приложений здесь. А сегодня мы раскроем подробности реализации этого проекта в группе приложений семейства SAP.


Читать дальше →
Всего голосов 13: ↑12 и ↓1 +11
Комментарии 4

В погоне за «неправильными» инцидентами, или Как мы строим Threat Hunting

Время на прочтение 4 мин
Количество просмотров 3.3K
Инциденты с SLA-таймингами должны детектироваться с минимальным числом False Positive, а также иметь четкий workflow обработки. При таком устройстве SOC гарантирует, что инцидент будет обработан за определённое время – для дальнейшего своевременного реагирования… Такой подход многие годы был справедлив для любого SOC (и нашего в том числе). Но в какой-то момент пришло осознание, что мы частично теряем полноту картины происходящего. Причина – в тех самых объективных ограничениях, накладываемых на сценарии. Ведь во множестве малорелевантных сработок (которые не могут быть обработаны на линиях мониторинга разумными ресурсами и в рамках SLA) порой таится самая соль происходящего инцидента.


Читать дальше →
Всего голосов 8: ↑8 и ↓0 +8
Комментарии 0

Жизнь до и после Scrum в разработке B2B продуктов

Время на прочтение 8 мин
Количество просмотров 3.8K
Привет, Хабр! Сегодня мы хотим поговорить на тему Scrum, а точнее поделиться своим опытом внедрения новых процессов в разработке. Под катом — рассказ о том, как преодолевать проблемы B2B-разработки при внедрении agile, на примере нашего продукта Solar Dozor. Делимся откровениями о жизни до и после Scrum.


Читать дальше →
Всего голосов 16: ↑16 и ↓0 +16
Комментарии 2

Проблемы роста SOC: как учесть +100500 хотелок заказчиков и не сойти с ума

Время на прочтение 7 мин
Количество просмотров 2.8K
Когда-то деревья были большими, а Solar JSOC – маленьким. Всех его сотрудников можно было пересчитать по пальцам двух рук и ног, поэтому вопроса о единых правилах игры не стояло. При небольшом тогда числе заказчиков мы и так прекрасно учитывали их разнообразные хотелки по выявлению инцидентов и оповещению (в этой компании к инфраструктуре могут удаленно подключаться подрядчики, а в той – по ночам работает админ Вася и это легитимно; здесь ждут мгновенных сообщений о любых подозрениях на инцидент, а там готовы повременить – главное максимум аналитики и т.д. и т.п.). Но со временем клиентов заметно прибавилось, ожидания от SOC у всех были разными (а обещания сейлов о кастомизации сервиса – щедрыми). И все это наряду с ростом числа собственных специалистов с их различающимся пониманием «прекрасного». Чтобы упорядочить возникшую энтропию, можно было, конечно, продолжать плодить инструкции по каждому поводу, а всех инженеров первой линии и аналитиков отправить на курсы развития сверхпамяти, но это чревато…Поэтому мы придумали более действенную схему работы.

Читать дальше →
Всего голосов 16: ↑15 и ↓1 +14
Комментарии 0

О неравномерности нагрузки на линии SOC – как мы упорядочиваем хаос

Время на прочтение 8 мин
Количество просмотров 2.8K

Кадр из мультфильма For the Birds (Pixar)

Деятельность аналитиков центров мониторинга и реагирования на кибератаки (Security Operations Center) чем-то похожа на деятельность любой службы поддержки. Те же линии с инженерами различной экспертизы, тикеты, приоритеты, SLA и тайминги. Но то, с чем приходится сталкиваться менеджменту SOC, не приснится и в ночных кошмарах службе поддержки продукта/сервиса: экстремально короткие SLA, абсолютно непредсказуемая скважность входящего потока, отсутствие понятия «массовая проблема», возможности пообещать решение в следующем релизе и много других фишек, делающих жизнь менеджера SOC ну ооочень интересной. Про отсутствие возможности прогонять инцидент последовательно через линии мы уже писали, настало время поговорить о других особенностях организации процесса. Итак, скважность, короткий SLA и распределение критичностей.
Читать дальше →
Всего голосов 14: ↑14 и ↓0 +14
Комментарии 0

GitHub: библиотека для сбора SSL-сертификатов

Время на прочтение 2 мин
Количество просмотров 4.4K
Представляем еще одну библиотеку, написанную на Go – GoTransparencyReport предназначенную для автоматизации сбора и обработки SSL-сертификатов по API сайта transparencyreport.google.com (ранее мы уже размещали библиотеку для поиска данных о корпоративных email по домену). Суть GoTransparencyReport довольно проста: ввел домен — получил аккуратненькую JSON-табличку с сертификатами и остальными полями. Без нее пришлось бы вводить домен на сайте Google, ставить галочку на выборе субдоменов, просматривать кучу сведений, колонок и дополнительных данных, а потом неизвестно как перетаскивать их на свой источник — мы же упростили этот процесс. Ссылка на GitHub прилагается.

Читать дальше →
Всего голосов 22: ↑21 и ↓1 +20
Комментарии 2

Зачем вам чужие ошибки? Исправляем уязвимости в сторонних библиотеках

Время на прочтение 7 мин
Количество просмотров 4.7K
Любое ПО содержит уязвимости, причем они появляются на разных этапах его жизненного цикла. Полностью избавиться от уязвимостей в коде достаточно сложно, но можно, как минимум, сократить их количество. Для этого используются средства SAST, DAST и IAST – статический, динамический и интерактивный методы анализа соответственно. Эти средства можно гибко интегрировать в процесс разработки, тем самым повысив качество собственного кода. Дела обстоят сложнее со сторонним программным обеспечением, так как исправлять уязвимости в заимствованных библиотеках/фреймворках сложно и трудозатратно. Библиотеки могут быть без исходного кода, в компании может отсутствовать специалист, который готов такие исправления вносить. Да и в целом стоит задуматься о целесообразности исправлений, поскольку библиотека все-таки должна обновляться и поддерживаться командой, которая ее выпускает. Но что делать, если эта команда ленится, а использовать библиотеку надо, чтобы приложение работало? Тут пригодятся средства анализа состава программного обеспечения – SCA. Разберемся, какие SCA-инструменты существуют, как они помогают устранять уязвимости в заимствованных частях кода, и почему их имеет смысл использовать вместе с SAST.


Читать дальше →
Всего голосов 22: ↑21 и ↓1 +20
Комментарии 4

NTA здорового человека: что должны уметь системы анализа сетевого трафика (и пока что не умеют)

Время на прочтение 9 мин
Количество просмотров 10K

Кадр из м/ф «Инспектор Гаджет»

У людей, занимающихся обнаружением и расследованием компьютерных инцидентов, есть неписаная истина: «Инцидент рождается и умирает на хосте». Сегодня подавляющее большинство статей, исследований и правил детекта связаны именно с хостовыми логами (поэтому на рынке и появился EDR). Тем не менее очевидно, что события с хоста не дают полной картины происходящего и необходимо анализировать то, что происходит не только на конечных точках, но и в сети. Не так давно появился Network Traffic Analysis (NTA) – относительно молодой класс решений, который помогает обнаружить злоумышленника, «живущего в сети». Четкого понимания о функционале NTA у ИБ-сообщества пока не сформировалось, но мы со стороны центра мониторинга и реагирования на кибератаки все-таки попробуем рассказать, какой должна быть такая система и как она должна работать в идеале, чтобы полностью решать свои задачи.
Читать дальше →
Всего голосов 14: ↑14 и ↓0 +14
Комментарии 1

Постройтесь в линию: как мы набивали шишки на создании процессов выявления и реагирования на кибератаки

Время на прочтение 7 мин
Количество просмотров 2.9K
На старте сервиса по мониторингу и реагированию на киберинциденты у нас было довольно странное деление на две линии аналитики: не только и не столько по уровню экспертизы, сколько по направленности решаемых задач. Была первая линия, которая занималась мониторингом и расследованием инцидентов ИБ. И все остальные – “просто аналитики”, в чьи обязанности входило углубленное расследование инцидентов за рамками типового процесса и SLA, создание правил детектирования новых угроз, а также плотная работа с заказчиком (анализ общего уровня защищенности, проработка максимально эффективного пула сценариев для покрытия модели угроз, подключение новых источников, проработка необходимого уровня аудита, написание парсеров/коннекторов и т.д.).



Мы сознательно не строили многоуровневую линейную модель эскалации расследования инцидентов по линиям 1->2->3-> и т.д. Наверное, просто потому, что не смогли придумать, как уложить подобную парадигму расследования в экстремально короткий SLA на решение инцидентов (0,5–2 часа), причем 30 минут на разбор инцидента далеко не редкость, такие кейсы составляют значимую долю в общем потоке.
Читать дальше →
Всего голосов 12: ↑12 и ↓0 +12
Комментарии 2

Как мы внедрили вторую SIEM в центре мониторинга и реагирования на кибератаки

Время на прочтение 5 мин
Количество просмотров 4.1K
Одна голова хорошо, а две – некрасиво… Так мы думали, пока жили в чудное время, когда в нашем центре мониторинга и реагирования на кибератаки была одна-единственная SIEM-платформа. Не секрет, что это была HP ArcSight, оказавшаяся единственным финишером длительного марафона через тернии требований, хотелок и амбициозных планов построения сердца SOC.

И вроде бы ничто не предвещало беды, но в какой-то момент появились и стали все более настойчивыми мысли о необходимости работы с альтернативной платформой. И основным локомотивом тут выступило активное развитие центров ГосСОПКА. Для того чтобы стать одним из подобных центров, нам необходимо было использовать ПО, которое обеспечено «гарантийной и технической поддержкой российскими организациями, не находящимися под прямым или косвенным контролем иностранных физических лиц и (или) юридических лиц» (Приказ ФСБ от 06.05.2019 № 196, п.3.4). Как мы страдали все это пережили и что в итоге получилось, рассказываем ниже.


Кадр из мультсериала «Котопёс»
Читать дальше →
Всего голосов 15: ↑15 и ↓0 +15
Комментарии 0

Чем нас «радовали» злоумышленники последние полгода

Время на прочтение 6 мин
Количество просмотров 5.6K
Последние полгода были, мягко говоря, непростыми. Новая реальность – новые векторы кибератак, хотя и про старые, проверенные временем инструменты злоумышленники не забывали. Solar JSOC и JSOC CERT скучать не приходилось: атаки на RDP, новые оболочки известного ВПО и методы сокрытия Mimikatz… Подробности, как всегда, письмом ниже.
Читать дальше →
Всего голосов 17: ↑17 и ↓0 +17
Комментарии 1

Строим безопасную разработку в ритейлере. Опыт одного большого проекта

Время на прочтение 7 мин
Количество просмотров 4K
Некоторое время назад мы закончили строить процесс безопасной разработки на базе нашего анализатора кода приложений в одной из крупнейших российских ритейловых компаний. Не скроем, этот опыт был трудным, долгим и дал мощнейший рывок для развития как самого инструмента, так и компетенций нашей команды разработки по реализации таких проектов. Хотим поделиться с вами этим опытом в серии статей о том, как это происходило на практике, на какие грабли мы наступали, как выходили из положения, что это дало заказчику и нам на выходе. В общем, расскажем о самом мясе внедрения. Сегодня речь пойдет о безопасной разработке порталов и мобильных приложений ритейлера.


Читать дальше →
Всего голосов 15: ↑15 и ↓0 +15
Комментарии 1

Теория поколений и мотивация. Есть ли различия между X-Y-Z на самом деле?

Время на прочтение 5 мин
Количество просмотров 11K
Человеку свойственно опираться на различные теории – это придает уверенности. Когда мы ищем ответы в точных науках, очевидность теорий, подкрепленных проверками лабораторных испытаний, помогает нам не ошибиться со следующим шагом. Но можно ли перенести подобный подход на изучение человеческих сообществ?



В 1991 году двое умных парней, Штраус и Хау, предложили широкой общественности некую универсальную, на их взгляд, теорию, объясняющую различия между людьми, родившимися разных десятилетиях — в их взглядах, динамике, мотивации и пр. Любая теория, которая пытается внести хоть какую-то алгебраическую прозрачность в хаос поведенческих особенностей homo sapiens, быстро становится очень популярной. Ведь все: от руководителей, родителей и HR'ов до правительств – ищут волшебную кнопку, позволяющую управлять людьми. И voila — вот он золотой ключик — теория поколений!
Читать дальше →
Всего голосов 33: ↑28 и ↓5 +23
Комментарии 12

Реагирование на киберинциденты: 5 правил разработки плейбуков

Время на прочтение 8 мин
Количество просмотров 7.5K
Вопрос разработки и приготовления плейбуков по реагированию на инциденты сейчас очень активно обсуждается и порождает разное количество подходов, поиск баланса в которых крайне важен. Должен ли плейбук быть очень простым («выдернуть шнур, выдавить стекло») или должен давать возможность оператору подумать и принять решение на основании собственной экспертизы (хотя, как говорили в одной игре моего детства, «что тут думать – дергать надо»). За наплывом модных аббревиатур и системных рекомендаций достаточно сложно найти соль и серебряную пулю. Мы за 8 лет работы нашего центра мониторинга и реагирования на кибератаки успели наломать немало дров приобрести некоторый опыт в этом вопросе, поэтому постараемся поделиться с вами граблями и подводными камнями, которые встречались нам на этом пути, в 5 практических советах по вопросу.

Читать дальше →
Всего голосов 14: ↑13 и ↓1 +12
Комментарии 2

KPI для Security Operations Center: как мы пришли к своей системе метрик

Время на прочтение 6 мин
Количество просмотров 7.1K
Не буду тут писать длинные заумные тексты о том, «как правильно построить систему KPI для SOC». А просто расскажу, как мы боролись и искали нашли свою методику и как теперь измеряем, «насколько все плохо/хорошо/безопасно/(нужное подчеркнуть)».


Читать дальше →
Всего голосов 14: ↑14 и ↓0 +14
Комментарии 0

Уязвимости в коде. Как отличить опасную брешь от незначительной ошибки?

Время на прочтение 18 мин
Количество просмотров 13K
Как обычно выглядит проверка кода приложений на уязвимости? Специалист по безопасности инициирует процедуру, код сканируется, в приложении обнаруживаются тысячи уязвимостей. Все — и безопасник, и разработчики — в шоке. Естественная реакция разработчика: «Да наверняка половина — это ложные срабатывания, а другая — некритичные уязвимости!»

Что касается ложных срабатываний, здесь все просто: можно взять и посмотреть непосредственно те места кода, где обнаружены уязвимости с подозрением на false positive. Действительно, какая-то их часть может оказаться ложными срабатываниями, (хотя явно не половина от общего числа).

А вот о том, что критично, а что нет, хотелось бы поговорить более предметно. Если вы понимаете, почему сейчас уже нельзя использовать SHA-1 и зачем экранировать «;», возможно, эта статья не откроет вам чего-то нового. Но если по итогам сканирования от найденных уязвимостей рябит в глазах, добро пожаловать под кат – расскажем, какие «дыры» чаще всего встречаются в мобильных и веб-приложениях, как они работают, как их исправить, а главное — как понять, что перед вами — опасная брешь или незначительная ошибка в коде.


Читать дальше →
Всего голосов 25: ↑25 и ↓0 +25
Комментарии 1

Как мы построили виртуальную инфраструктуру для киберучений промышленных предприятий

Время на прочтение 7 мин
Количество просмотров 5.7K


В этом году мы начали большой проект по созданию киберполигона – площадки для киберучений компаний различных отраслей. Для этого надо создать виртуальные инфраструктуры, «идентичные натуральным» — чтобы они повторяли типовое внутреннее устройство банка, энергетической компании и т.д., причем не только в части корпоративного сегмента сети. Чуть позже расскажем о банковской и других инфраструктурах киберполигона, а сегодня – о том, как мы решали эту задачу применительно к технологическому сегменту промышленного предприятия.
Читать дальше →
Всего голосов 12: ↑10 и ↓2 +8
Комментарии 4

Информация

Сайт
rt-solar.ru
Дата регистрации
Дата основания
2015
Численность
1 001–5 000 человек
Местоположение
Россия