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

Сегодня мы хотели бы затронуть очень важную для DLP-решений тему – выбор СУБД для хранения данных. Так исторически сложилось, что большинство российских DLP используют для этих целей Oracle Database. На заказчиков это накладывает определенные финансовые ограничения: стоимость лицензий Oracle закладывается в стоимость DLP-системы. Это создает определенный фильтр, сокращающий аудиторию пользователей продукта: СУБД Oracle могут позволить себе не все – как в техническом, так и в финансовом плане.

Теперь, когда импортозамещение шагает по стране, госсектор (и не только) формирует спрос на DLP, поддерживающие свободные СУБД. Это очень ощутимый импульс, но, метнувшись в сторону свободных СУБД, важно сохранить удобство, производительность и функциональные возможности продукта. В этой статье речь пойдет о том, как мы решали эту задачу, реализуя поддержку PostgreSQL и разрабатывая схему секционирования в Solar Dozor.

На хабре есть много статей о том, как работает рантайм Swift/Objective-C, но для еще более полного понимания того, что происходит под капотом, полезно залезть на самый низкий уровень и посмотреть, как код iOS приложений укладывается в бинарные файлы. Кроме того, безусловно, под капот приходится залезать при решении реверс-инжиниринговых задач. В этой статье мы обсудим самые простые конструкции Objective-C, а о Swift и более сложных примерах поговорим в последующих статьях.

В первых двух секциях я постарался максимально подробно осветить практические подробности, чтобы читателю, желающему пройти этот тьюториал, не нужно было каждые две минуты гуглить вещи в стиле "где найти бинарный файл приложения в Xcode". Дальше все максимально информативно.

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

Итак, куда же, по мнению Gartner, движется отрасль?

Добрый день, коллеги. Вот и подошел черед третьей статьи, посвященной Security Operations Center.

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

Привет, Хабр!

Эта статья станет вступительной в моем небольшом цикле заметок, посвященном такой технике анализа программ, как pointer analysis. Алгоритмы pointer analysis позволяют с заданной точностью определить на какие участки памяти переменная или некоторое выражение может указывать. Без знания информации об указателях анализ программ, активно использующих указатели (то есть программ на любом современном языке программирования — C, C++, C#, Java, Python и других), практически невозможен. Поэтому в любом мало-мальски оптимизируещем компиляторе или серьезном статическом анализаторе кода применяются техники pointer analysis для достижения точных результатов.

В данном цикле статей мы сосредоточимся на написании эффективного межпроцедурного алгоритма pointer analysis, рассмотрим основные современные подходы к задаче, ну и, конечно же, напишем свой очень серьезный алгоритм pointer analysis для замечательного языка внутреннего представления программ LLVM. Всех интересующихся прошу под кат, будем анализировать программы и многое другое!

Сегодня мы расскажем об одной из ключевых фишек нашей DLP-системы — уровне доверия. Это показатель, который присваивается каждому человеку в компании и отражает вероятность того, что данный сотрудник окажется нарушителем.

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

Solar inCode умеет обнаруживать уязвимости в байткоде Java. Но показать инструкцию байткода, которая содержит уязвимость, мало. Как показать уязвимость в исходном коде, которого нет?

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

Мы продолжаем серию материалов, посвященных Security Operations Center, и представляем вашему вниманию второй выпуск.

Сегодняшняя статья посвящена «магическим девяткам» доступности и готовности сервисов. Мы расскажем, из чего складываются сервисные показатели облачного SOC с точки зрения «железа» и ПО, какими средствами они контролируются в Solar JSOC.

Эта статья открывает цикл публикаций, посвященных функционированию центра по мониторингу и реагированию на инциденты информационной безопасности – Security Operations Center (SOC). В них мы будем рассказывать о том, что надо учитывать при создании SOC, о процессе подготовки инженеров мониторинга, регистрации инцидентов и практических кейсах, с которыми сталкивается Solar JSOC.

Цель данных статей не самореклама, а описание практических аспектов в реализации сервисной модели оказания услуг в области информационной безопасности. Первая статья будет иметь вводный характер, но она необходима для погружения в тему, которая все еще является достаточно новой для российского рынка информационной безопасности.

Зачем нужен SOC

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

В качестве вводной информации стоит упомянуть статистику по данным исследований, проведенных ФРИИ, а также компаниями Group-IB и Microsoft:

• Потери экономики РФ от киберпреступности за 2015 год оцениваются в 123,5 млрд рублей.
• 60% российских компаний отметили рост числа киберинцидентов на 75%, а размера ущерба — в два раза.

Также хотелось бы упомянуть статистику по нашим клиентам, которая отражается в ежеквартальных отчетах JSOC Security Flash Report:

• Двукратный рост количества инцидентов информационной безопасности в первом квартале 2016 года по отношению к аналогичному периоду 2015 года.
• Значительный рост инцидентов, связанных с утечками конфиденциальной информации.
• Увеличение критичных инцидентов с 26% до 32% по отношению к общему скоупу.
• Рост числа различных кибергруппировок, работающих по известным схемам мошенничества.

Пробки начинаются на перекрестках, когда транспортные потоки вступают в конфликт. Пока один поток движется, другой вынужден ждать. Что-то похожее происходит при выпуске очередного релиза программного продукта: чтобы выпустить продукт достойного качества, приходится останавливать разработку.

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