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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мир IT разнообразен донельзя. Кто каких только технологий и решений не создает, что только не разрабатывает! Компании творят продукты каждая по-своему, но многие процессы схожи, а потому могут оказаться полезным опытом для заимствования. Вот мы и подумали: а почему бы не рассказать вам о том, как мы создаем наш флагманский продукт Solar Dozor? Команда у нас очень опытная и энергичная. Каждый день нам приходится решать нетривиальные задачи, искать киллер фичи и увязывать пожелания заказчиков с собственным роудмапом. Вдруг наш опыт кому-то пригодится?

В общем, решили – запускаем серию статей о том, как, где и при каких обстоятельствах рождается наша DLP-система. Все откровенно, по-честному, с фото и, может, даже видеопруфами. А сегодня вы узнаете, с чего начинается создание нашего продукта. Знакомьтесь – discovery-лаборатория Dozor Research Lab.

Старый, добрый DDoS… Мы каждый год анализируем, как меняется этот сегмент киберпреступности, и по итогам прошлого и начала этого года видим, что количество таких атак выросло более чем в 1,5 раза. За это время злоумышленники значительно нарастили мощность атак и сменили тактику. А кроме того, DDoS стал еще доступнее: судя по тому, как резко в последнее время увеличилось число атак на образовательные ресурсы и различные «электронные дневники», мир DDoS все активнее открывают для себя «хакеры» школьного возраста. В этом посте мы расскажем о DDoS-атаках, которые мы фиксировали в 2019-м и в начале 2020 года, и о том, как изменился DDoS за последнее время.

Продолжаем серию занятий по разбору CTF-задач для тех, кто начинает карьеру в ИТ и ИБ.
Ближайший вебинар стартует в четверг 23 апреля в 18:00 и будет посвящен поиску вредоносного ПО в IoT. Будем разбирать протокол общения вредоносного ПО с C&C-серверами на примере ботнет-агента для OpenWRT на архитектуре MIPS, искать способы детектирования и перехвата управления. Все детали и ссылка на регистрацию — под катом.

Мы активно поддерживаем CTF-движение – наши ребята из подразделений форензики, пентеста, защиты АСУ ТП и Security Awareness помогают в разработке заданий и оценке работ участников CTF.Moscow, VolgaCTF, FarEastCTF, BlackMirror и других подобных мероприятий. И, конечно, каждый год мы проводим олимпиаду «Кибервызов» – тоже в формате CTF.

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

За последние пару недель разве что ленивый не посоветовал окружающим, как правильно и без потерь перейти на удалёнку. Мы не будем вам ничего советовать. А просто расскажем, как мы наладили удаленную разработку нашего ключевого продукта и к 3-му апреля уже завершили первый, полностью удаленный, двухнедельный спринт команд разработки Dozor Core (центрального модуля системы).



Кому интересно, изучайте наш опыт, включайтесь в обсуждение, делитесь своим в комментах. Ну что, поехали!