Сегодня у нас не совсем обычная статья. Как следует из заголовка, она посвящена проблемам непрерывной защиты веб-приложений и разбита на две части, отражающие два взгляда на проблему: с позиции разработчиков WAF (Андрей Петухов, SolidLab) и с точки зрения центра мониторинга и противодействия кибератакам, который использует WAF для оказания сервиса клиентам (@avpavlov, Solar JSOC).

Начнем мы с разработчиков, а через неделю дадим слово эксплуатантам WAF.

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

Выставка и конференция Cloud Expo Asia Hong Kong объединяет в себе четыре направления – облака, облачная безопасность, интернет вещей и центры обработки данных. У Азии всегда находится свой особенный путь решения для любой задачи, и соблазн взглянуть на китайскую «дорогу в облака» был настолько велик, что даже десять часов перелета прошли в приятном предвкушении знакомства с дивным новым миром.

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

В этом году перед «Противостоянием» мы в очередной раз собрали сборную «солянку» частично из сотрудников Solar Security, частично из неравнодушных друзей и SOCостроителей России. В статье попробуем описать весь процесс участия в «Противостоянии» — какие были «пасхалки» от организаторов, какие шли атаки, как мы защищались, какие инструменты отработали и т.д.

Скоро состоится очередной Positive Hack Days, в рамках которого традиционно пройдет «Противостояние» – многочасовая кибербитва между Защитниками и Атакующими и, пожалуй, самая напряженная часть всего мероприятия.


Мы участвовали в «Противостоянии» в прошлом году. Было тяжело, но, без сомнения, очень круто. В этом году мы продолжим традицию, но правила «Противостояния» серьезно поменялись, и в этой заметке хотелось бы рассказать, в чем состоят эти изменения, насколько новые условия игры похожи/не похожи на реальную жизнь и как они повлияют на ход борьбы.

Название этой статьи частично позаимствовано из одного популярного спектакля и кинофильма. «Дальше не придумали, импровизируй» – после этой фразы в фильме звучит нецензурная реакция человека, который понял, что импровизировать придется именно ему. В этой ситуации когда-нибудь оказывался или окажется каждый профессионал, работающий в сфере информационной безопасности. Это тот самый момент, когда ты встал у руля ИБ в организации нового для тебя профиля, когда в структуре компании происходят изменения уровня слияний и поглощений, или когда внезапно в 8 вечера пятницы начинают раздаваться звонки с сообщениями о неработающих банкоматах… Именно тогда в голове начинает звучать этот голос, дающий единственно верное направление дальнейших действий.

Аналитики Solar JSOC и Solar Dozor в своих статьях часто говорят о том, что даже все многообразие средств защиты, существующих на рынке, не защитит компанию от атаки, если она рассматривает данные каждой системы в отдельности. Чаще всего атаку, если она не совсем примитивная, можно выявить только сведя воедино данные с различных источников.

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

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

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