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

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

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

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

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

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

В 70-х годах для взлома телефонных сетей использовался обыкновенный свисток, в 90-х Адриан Ламо взламывал банки через интернет, используя только возможности браузера. Мир кибербезопасности не стоит на месте, постоянно усложняется и остаётся одной из самых интересных и захватывающих сфер в IT. Специально для тех, кому она интересна уже в институте, «Ростелеком» и «Ростелеком-Солар» уже второй год подряд дают возможность проверить свои силы в индивидуальных соревнованиях «Кибервызов». Итак, под катом — о том, как будут проходить эти соревнования, примеры заданий и рассказы победителей прошлого года о том, что оказалось самым сложным и как они съездили в НТУ «Сириус» на углублённый курс по информационной безопасности.

Пост, который вы сейчас читаете, – продолжение статьи о том, как правильно выстроить в крупной компании ролевую модель управления доступом пользователей к различным системам. Напомним: построение ролевой модели – это скорее процесс, чем результат, и первую часть нашей дилогии мы посвятили подготовке к «строительству». В ней мы рассказали, как создать функциональную модель каждого подразделения и должности, провести аудит ИТ-систем и расставить их по приоритетам, создать бизнес-ориентированное описание прав пользователей и о других важных подготовительных шагах. Сегодня же поговорим о способах построения ролевой модели, ролевых матрицах, чем здесь поможет внедрение автоматизированных систем управления доступом (IdM/IGA), и что вы получите на выходе.

Какое-то время назад мы начали фиксировать попытки заражения инфраструктур наших заказчиков ранее не известным вредоносным ПО. Оно доставлялось пользователям через фишинговые рассылки, иногда посвященные второй волне коронавируса, а иногда – четко «заточенные» под атакуемую организацию и связанные с ее деятельностью. Злоумышленники выдавали себя за различные существующие компании, например, «Норильский Никель», Российский союз промышленников и предпринимателей, Финаудитсервис и т.д.



Примечательными были два аспекта деятельности группировки: во-первых, высокий уровень технических навыков злоумышленников, а во-вторых – вариабельность сценария атаки. Если ты как жертва не интересен – украдут пароли и зашифруют данные, а вот если твоя машина в интересном домене и имеет потенциал для более интересного развития атаки – загрузят Remote Admin Tool (RAT), написанный на PowerShell. Мы назвали группировку TinyScouts – по именам функций из вредоносного кода. В статье мы расскажем о двух ее последних кампаниях, которые условно можно разделить по месяцам – июль и август 2020 года, и сделаем полный разбор инструментов и сценариев TinyScouts.

Жизнь сетевого инженера была счастливой и беззаботной, пока в ней не появился сертифицированный криптошлюз. Согласитесь, разбираться с решениями, предназначенными для шифрования каналов передачи данных по ГОСТу, задача не из легких. Хорошо, если это известные и понятные продукты. Вспомним ту же «С-Терра» (об их «С-Терра Шлюз» мы уже писали). Но что делать с более экзотичными решениями на базе собственных протоколов шифрования, например, «Континент» (от «Кода Безопасности») или ViPNet Coordinator HW (от «Инфотекса»)? В этой статье я постараюсь облегчить погружение в мир ViPNet (про «Континент» тоже когда-нибудь поговорим) и рассказать, с какими проблемами столкнулся сам и как их решал.

В «Ростелеком-Солар» мы разрабатываем статический анализатор кода на уязвимости и НДВ, который работает в том числе на деревьях разбора. Для их построения мы пользуемся оптимизированной версией ANTLR4 – инструмента для разработки компиляторов, интерпретаторов и трансляторов.

В репозитории можно найти грамматики множества языков программирования. Однако в нем отсутствует грамматика Ruby, которую, по всей видимости, никто так и не реализовал. Есть только грамматика похожего самодельного языка, парсящая лишь простейшие случаи. Это неудивительно, ведь грамматику Ruby сложно реализовать, так как язык обладает нетривиальным синтаксисом. Но она очень пригодилась бы тем, кто, например, захочет написать свой язык и задумается, как это сделать. Или тем, кому нужно решить технические сложности, рассмотренные в нашей статье. Ну что же – придется писать новую грамматику, чем прямо здесь и займемся.

Ни для кого не секрет, что основной опыт и экспертиза в тематике SOC в России (да в принципе и в мире) сосредоточена преимущественно на вопросах контроля и обеспечения безопасности корпоративных сетей. Это видно из релизов, докладов на конференциях, круглых столов и так далее. Но по мере развития угроз (не будем вспоминать набивший оскомину Stuxnet, но, тем не менее, не пройдем мимо Black/Gray Energy, Industroyer и Triton) и нормативных требований закона «О безопасности критической информационной инфраструктуры РФ) все чаще поднимается вопрос о необходимости охватить вниманием SOC и святая святых всех индустриальных компаний – сегменты АСУ ТП. Мы делали первый аккуратный подход к этому снаряду примерно полтора года назад (1, 2). С тех пор опыта и исследований стало чуть больше, и мы почувствовали в себе силы запустить полноценный цикл материалов, посвященных вопросам SOC OT. Начнем с того, чем отличаются технологии и процессы давно привычного нам корпоративного SOC от SOC индустриального (до кадровых вопросов дело дойдет своим чередом). Если тематика вам небезразлична — прошу под кат.

Без мониторинга конечных точек сегодня уже не получится в полной мере обеспечить безопасность и вовремя обнаруживать факты компрометации инфраструктуры. «Джентельменский» набор — сетевой мониторинг, антивирус и стандартный аудит на конечных точках — уже не позволяет противодействовать не только серьезным группировкам, но даже злоумышленникам с низким уровнем подготовки. Почему? Рассмотрим на конкретных примерах.


Кадр из мультфильма «Жил-был пес»

Опаснее всего враг, о котором не подозреваешь.
(Фернандо Рохас)

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

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


Кадр из сериала South Park

Сейчас я работаю в компании-вендоре программного обеспечения, в частности решений по управлению доступом. А мой опыт «из прошлой жизни» связан со стороной заказчика – крупной финансовой организацией. Тогда наша группа по контролю доступа в ИБ-департаменте не могла похвастаться большими компетенциями в IdM. Мы многому обучались в процессе, пришлось набить кучу шишек, чтобы выстроить в компании работающий механизм управления правами пользователей в информационных системах.

Объединив свой выстраданный в заказчике опыт с вендорскими знаниями и компетенциями, я хочу поделиться с вами по сути пошаговой инструкцией: как создать в крупной компании ролевую модель управления доступом, и что это даст на выходе. Моя инструкция состоит из двух частей: первая – готовимся строить модель, вторая – собственно строим. Перед вами часть первая, подготовительная.

Можно мало что знать о SOC, но все равно будет интуитивно понятно, что в его работе важнее всего две вещи: выявление инцидентов и реагирование на них. При этом, если не брать ситуации, когда мы имеем дело со сложным внутренним мошенничеством или признаками деятельности профессиональной группировки, реагирование, как правило, состоит из ряда очень простых технических мер (удаление вирусного тела или ПО, блокирование доступа или учетной записи) и организационных мероприятий (уточнение информации у пользователей или проверка и обогащение итогов анализа в источниках, недоступных мониторингу). Однако в силу ряда причин в последние годы процесс реагирования на стороне заказчиков начал существенно модифицироваться, и это потребовало изменений и со стороны SOC. Причем, поскольку речь идет о реагировании, где значимо «не только лишь всё» – и точность, и полнота, и скорость действий – можно с высокой вероятностью говорить, что если ваш внутренний или внешний SOC не учитывает новые требования к этому процессу, вы не сможете нормально отработать инцидент.

Как известно, лень – двигатель прогресса. А самоизоляция – двигатель DDoS'а, – добавим мы по итогу осмысления «былого» за март-май 2020 г. Пока кто-то страдал от безвыходности (в буквальном смысле) своего положения, «мамкины хакеры» страдали фигней от неотвратимости онлайн-обучения и грядущих экзаменов. «Деятельно» страдали (эту бы энергию да в мирное русло!). По количеству DDoS-атак в сфере образования наблюдалась наибольшая динамика роста. На пике – в апреле – число попыток устроить отказ в обслуживании образовательным ресурсам (электронным дневникам, сайтам с проверочными работами, площадкам для онлайн-уроков и т.д.) увеличилось в 5,5 раз по отношению к марту и в 17 раз по отношению к январю 2020 г. Всё это были маломощные (и наверняка бесплатные) атаки с использованием простых легкодоступных инструментов. Разумеется, под прицел злоумышленников (правда, уже более продвинутых) попали и другие отрасли, но тут было ожидаемо: онлайн-торговля, госсектор финансовая сфера, телеком и игровой сегмент. Подробности, как всегда, под катом.

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

Этой статьей мы завершим небольшой цикл о построении процесса безопасной разработки на основе SAST — статического анализа кода на безопасность. В первой части мы разобрали основные вопросы, возникающие при внедрении SAST в процесс разработки. Во второй части остановились на технических аспектах внедрения и разобрали несколько примеров выстраивания SSDLC на практике. В последней части расскажем об организационных моментах.

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

Можно внедрять у себя в компании ПО последнего поколения для защиты от «злобного хацкера», но какой в этом толк, если твои сотрудники продолжают ходить по фишинговым ссылкам… Мы регулярно проводим социотехнические исследования в различных компаниях и представляем себе масштаб трагедии проблемы. Цель таких исследований – не просто понять, насколько легко обмануть персонал и на какие крючки его легче всего зацепить, но и сделать правильные выводы о том, какие методики обучения киберграмотности использовать и как часто стоит проводить проверку. За 2019 год и начало 2020-го мы разослали более 9 тысяч «фишинговых» писем на корпоративные почтовые ящики. Что из этого вышло – читайте ниже.

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



Тем не менее потребность в собственном центре реагирования определяется зрелостью заказчика… или внезапно предъявленными требованиями регулятора, которые сразу же делают каждого очень зрелым. Чтобы оперативно отслеживать инциденты ИБ и реагировать на них, необходима определенная инфраструктура, включающая в себя готовые решения, процессы, людей, вычислительные мощности. И если принципиальное решение уже принято, остается только определиться: создавать ли SOC на базе своих ресурсов или получать весь спектр услуг в виде сервиса.