В прошлом году мы выпустили мажорную версию своего продукта Solar Dozor 7. В новую версию нашей DLP-системы вошел модуль продвинутого анализа поведения пользователей UBA. При его создании мы попробовали разные базы данных, но по совокупности критериев (о них скажем ниже) в итоге остановились на ClickHouse.

Освоить ClickHouse местами было непросто, многое стало для нас откровением, но главное преимущество этой СУБД затмевает все её недостатки. Как вы поняли из заголовка, речь о скорости. По этому параметру ClickHouse оставляет далеко позади традиционные коммерческие базы данных, которые мы в своих продуктах, в том числе в Solar Dozor, тоже используем.

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


Кадры из мультфильма «Турбо» (2013 год)

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

В этой статье я расскажу о том, какие проблемы можно выявить при аудите прав доступа в компании и как можно упростить себе жизнь с помощью современных IdM/IGA-решений (Identity Management/Identity Governance and Administration).

Эта статья — завершающая в цикле материалов о нашем опыте выстраивания процесса безопасной разработки для крупного ритейлера. Если пропустили, можете прочитать первые части: о безопасной разработке порталов и мобильных приложений, о безопасной разработке в группе приложений SAP и о встраивании в процесс разработки кассового ПО. Настало время собрать шишки, которые мы набили подвести итоги.

Все было классно. И на этом мы могли бы закончить, если бы не одно «но». При планировании мы некорректно оценили время интеграции. Спойлер: многое пошло не так, в результате внедрение усложнилось, сроки сдвинулись. Спойлер 2: учесть все факторы риска было невозможно. И вот с этого момента давайте поподробнее.

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

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

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

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

Любое ПО содержит уязвимости, причем они появляются на разных этапах его жизненного цикла. Полностью избавиться от уязвимостей в коде достаточно сложно, но можно, как минимум, сократить их количество. Для этого используются средства 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.