В мае этого года прошла конференция Positive Hack Days 8, на которой мы вновь поучаствовали в роли SOC в уже традиционном Противостоянии (The Standoff).
В этом году организаторы учли прошлые ошибки и Противостояние началось в срок. Атакующие — молодцы! Нападали практически непрерывно все 30 часов, поэтому нашей ночной смене не удалось даже вздремнуть.
Сегодня даже беглый поиск по hh.ru выдает около 90 разных по задачам и функционалу вакансий с магическим словом «аналитик» и довольно приличными условиями оплаты. Перед глазами многих кандидатов сразу проплывают большие данные и машинное обучение, зарплата начинать плясать сильно выше рынка и заигрывать нулями. Так кто же такие аналитики центра мониторинга, «отвечающие за то, чтобы заказчика не взломали»? Чем они занимаются и что нужно знать и уметь, чтобы попасть на эту позицию?
В предыдущей статье речь шла о поиске и обучении инженеров для первой линии центра мониторинга и реагирования на кибератаки. Сегодня мы поговорим о поиске и подготовке кадров для второй линии — аналитиков, которые занимаются расследованием нетиповых инцидентов и работой с контентом SIEM-системы, а также инженеров эксплуатации СЗИ, отвечающих за настройку средств защиты, анализ атак и разработку кастомных сигнатур.
Если спросить, какие требования мы предъявляем к кандидатам, ответ может показаться очень банальным: определенные технические компетенции, аналитический склад ума, внимательность… Однако как проверить эти качества, на что опираться, чтобы свести к нулю влияние субъективной оценки? Рассказываем, на что мы обращаем внимание и какие задания даем кандидатам.
Говорят, в 70-х годах Геннадий Зайцев, первый президент легендарного Ленинградского рок-клуба, так сформулировал принцип отбора музыкантов: «Беглость пальцев — дело наживное. Был бы человек хороший».
Возможно, если бы мы с Геннадием Борисовичем решили за рюмкой чего-нибудь горячительного пожаловаться друг другу на сложности в подборе кадров, то обнаружили бы много общих моментов. Когда мы собирали первую команду Solar JSOC, рынка сервисов мониторинга и противодействия кибератакам фактически еще не существовало, следовательно, не было ни готовых специалистов под эти задачи, ни даже четких критериев поиска. Нам предстояло собрать команду уникумов, но до этого — много раз пробовать новое, ошибаться и снова пробовать. Именно про команду сегодня и поговорим: как это было в самом начале и к чему мы пришли в результате.
Продолжаем цикл наших статей «SOC for beginners». В прошлый раз мы говорили о том, как внедрить в компании Threat Intelligence и не пожалеть. Сегодня хотелось бы поговорить о том, как организовать процессы, чтобы обеспечить непрерывный мониторинг инцидентов и оперативное реагирование на атаки.
В первом полугодии 2017 г. совокупный среднесуточный поток событий ИБ, обрабатываемых SIEM-системами и используемых Solar JSOC для оказания сервиса, составлял 6,156 миллиардов. Событий с подозрением на инцидент – в среднем около 960 в сутки. Каждый шестой инцидент – критичный. При этом для наших клиентов, в числе которых «Тинькофф Банк», «СТС Медиа» или «Почта Банк», вопрос оперативности информирования об атаке и получения рекомендаций по противодействию стоит очень остро.
Мы решили рассказать, как мы решали эту задачу, с какими проблемами столкнулись, и какой метод организации работы в итоге используем.
В предыдущих статьях «SOC for beginners» мы рассказали, как устроен и как организовать базовый мониторинг инцидентов и контроль защищенности инфраструктуры. Сегодня речь пойдет о Threat Intelligence — использовании внешних источников данных об угрозах.
При всей кажущейся простоте, запуск работы с Threat Intelligence — чуть ли не самый длительный и болезненный процесс. Исключение, наверное, составляют только те случаи, когда у вас на рабочих станциях эталонные образы ОС с включенным Application Control, пользователи — без прав администратора, а доступ в интернет — исключительно по белым спискам. К сожалению, мы за все время работы таких компаний пока не встречали. В связи с этим все интересующиеся темой Threat Intelligence – добро пожаловать под кат.
Продолжаем цикл наших статей о центрах мониторинга кибератак для начинающих. В прошлой статье мы говорили о Security Monitoring, инструментах SIEM и Use Case.
Термин Security Operations Center у многих ассоциируется исключительно с мониторингом инцидентов. Многим сервис-провайдерам это, в принципе, на руку, поэтому мало кто говорит о том, что мониторинг имеет ряд серьезных ограничения в плане защиты от кибератак.
В этой статье мы на примерах продемонстрируем слабые места мониторинга инцидентов ИБ, расскажем, что с этим делать, и в конце, как обычно, дадим несколько практических рекомендаций на тему того, как провести аудит защищенности инфраструктуры своими силами.
