Недавно в Самаре прошли международные открытые соревнования по информационной безопасности VolgaCTF. Владимир Дрюков, директор центра мониторинга и реагирования на кибератаки Solar JSOC, рассказал участникам соревнований о трех реальных атаках и спросил, как можно было их выявить. Проверьте, сможете ли вы ответить правильно.

Товарищи инженеры, уже четвертый год пошел, как я взялся преподавать в Киевском политехническом институте. За это время у меня накопилось огромное количество примеров кода и материалов, примерно на 90 лекций. Должен сказать, что за весь период своей профессиональной деятельности (а это 24 года почти ежедневного написания кода), я никогда не подымал свой уровень программирования, как за последние годы, работая со студентами. Если раньше мне казалось, что написать кратко, сложно и внушительно — это верх мастерства, то теперь я осознал, что мой код должны понимать студенты после минимальных объяснений, иначе он никуда не годится. Я пришел к выводу, что способность эту можно и нужно распространить не только на обучающий код, но и на весь рабочий код. Более того, обучающий код не должен существенно отличаться от рабочего кода, потому, что мы учим будущих инженеров делать настоящие системы, а не учебные. А после многочисленных просьб, я решил записывать все лекции в виде скринкастов, которые сразу после завершения лекции отправляются на ютюб. За этот учебный год я планирую записать 100 лекций, из которых уже опубликованы 23, готовы материалы еще для 67 лекций и новых 10 лекций еще в процессе подготовки.

Всем привет! Мы нашли время продолжить серию статей про внутреннее устройство Android. В этой статье я расскажу о процессе загрузки Android, о содержимом файловой системы, о том, как хранятся данные пользователя и приложений, о root-доступе, о переносимости сборок Android и о проблеме фрагментации.

Ethereum сейчас одна из самых популярных платформ для создания децентрализованных приложений, которая активно развивается. Одно из новшеств Zeppelin мы сегодня попробуем своими руками. А для тех кто в «танке», Zeppelin — это компания, занимающаяся разработкой и проверкой безопасности смарт-контрактов. Библиотека смарт-контрактов OpenZeppelin их самый известный продукт. 

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

Какой такой zeppelin OS?

Очередной блок наших публикаций по теме IdM будет посвящен финансам. А именно двум самым сложным и болезненным темам – оценке проекта внедрения IdM и его обоснованию перед руководством.

Полная стоимость проекта IdM складывается из затрат на оборудование, лицензии ПО, работы подрядчика и команды проекта. По опыту, основные сложности связаны с оценкой стоимости работ по внедрению системы, поэтому начнем именно с этого вопроса.

Сейчас все больше говорят о статическом анализе для поиска уязвимостей как необходимом этапе разработки. Однако многие говорят и о проблемах статического анализа. Об этом много говорили на прошлом Positive Hack Days, и по итогам этих дискуссий мы уже писали о том, как устроен статический анализатор. Если вы пробовали какой-нибудь серьезный инструмент, вас могли отпугнуть длинные отчеты с запутанными рекомендациями, сложности настройки инструмента и ложные срабатывания. Так все-таки нужен ли статический анализ?

Наш опыт подсказывает, что нужен. И многие проблемы, которые возникают при первом взгляде на инструмент, вполне можно решить. Попробую рассказать, что может делать пользователь и каким должен быть анализатор, чтобы его использование было полезным, а не вносило «еще один ненужный инструмент, который требуют безопасники».

Если вы работаете в компании, которая попадает под действие №187-ФЗ («О безопасности критической информационной инфраструктуры Российской Федерации»), то вам не нужно объяснять, что такое ГосСОПКА и зачем она нужна. Для остальных поясним: ГосСОПКА расшифровывается как Государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак. Архитектурно она представляет собой единый территориально распределенный комплекс центров различного масштаба, обменивающихся информацией о кибератаках. Такие центры обязаны создать все компании, которым принадлежат объекты критической информационной инфраструктуры (такие компании называют субъектами КИИ). Цель всей этой масштабной государственной инициативы – создать между важнейшими организациями страны систему обмена информацией о ведущихся кибератаках и тем самым обеспечить возможность превентивной защиты.

Достаточно долгое время основным документом, определяющим принципы функционирования центров ГосСОПКА и их взаимодействия с вышестоящим центром, были «Методические рекомендации по созданию и эксплуатации центров ГосСОПКА», разработанные ФСБ. Мы ранее делали обзор данного документа и отмечали, что основным фокусом его внимания было построение процессов по управлению инцидентами и контролю защищенности субъектов ГосСОПКА. Но в то же время этот подход оставлял достаточно большое поле для различного толкования того, какой объем задач должен решать центр ГосСОПКА и какие именно инструменты для этого требуются. Недавно вышли «Требования к средствам, предназначенным для обнаружения, предупреждения и ликвидации последствий компьютерных атак и реагирования на компьютерные инциденты». Попробуем разобраться, чего же ждет регулятор от компаний, строящих у себя центры ГосСОПКА, и исследовать этот вопрос.


Иерархия взаимодействия центров ГосСОПКА

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

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

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

Под катом история о том, как мы переписали основной компонент продукта с 17-летней историей (!) со Scheme на Clojure, и все сразу заработало как надо (ну, почти :)).

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



Способности, не находящие применения, превращаются в ничто.
Стен Надольный

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

Под катом – подборка самых необычных расследований, проводимых с помощью DLP.

У нас было две коммерческих APT-подписки, десять информационных обменов, около десяти бесплатных фидов и список exit-node Тора. А еще пяток сильных реверсеров, мастер powershell-скриптов, loki-scanner и платная подписка на virustotal. Не то чтобы без этого центр мониторинга не работает, но если уж привык ловить сложные атаки, то приходится идти в этом увлечении до конца. Больше всего нас волновала потенциальная автоматизация проверки на индикаторы компрометации. Нет ничего более безнравственного, чем искусственный интеллект, заменяющий человека в работе, где надо думать. Но мы понимали, что с ростом количества заказчиков мы рано или поздно в это окунемся.

Смарт-контракты Ethereum, если верить официальному сайту, выполняются «в точности так, как запрограммированы, без какой-либо возможности простоя, цензуры, мошенничества или вмешательства третьей стороны». Сегодня я попробую разобраться, так ли всё радужно на самом деле, рассмотрев некоторые проблемы, с которыми пользователи смарт-контрактов сталкиваются на практике.

В конце статьи я резюмирую свои размышления краткой инструкцией по написанию безопасных смарт-контрактов.

CSRF (Сross Site Request Forgery) в переводе на русский — это подделка межсайтовых запросов. Михаил Егоров (0ang3el) в своем докладе на Highload++ 2017 рассказал о CSRF-уязвимостях, о том, какие обычно используются механизмы защиты, а также как их все равно можно обойти. А в конце вывел ряд советов о том, как правильно защищаться от CSRF-атак. Под катом расшифровка этого выступления.


О спикере: Михаил Егоров работает в компании Ingram Micro Cloud и занимается Application security. В свободное время Михаил занимается поиском уязвимостей и Bug hunting и выступает на security-конференциях

Дисклаймер: приведенная информация является сугубо мнением автора, все совпадения случайны.


В том, что CSRF-атаки работают виноват этот Cookie-монстр. Дело в том, что многие веб-приложения используют куки (здесь и далее считаем уместным называть cookies по-русски) для управления сессией пользователя. Браузер устроен так, что, если у него есть куки пользователя для данного домена и пути, он их автоматически отправляет вместе с HTTP-запросом.

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

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

Мы уже некоторое время рассказываем о кадровых задачах и модели развития сотрудников в Solar JSOC. Наверняка вам удалось прочитать статью о том, как студенту третьего курса попасть в центр мониторинга и реагирования, или как инженеру прокачать опыт для вертикального движения в структуре Solar JSOC (из первой линии во вторую). Не за горами материалы о дальнейшем вертикальном развитии аналитиков и о том, как сервис-менеджер может превратиться в полноценного CISO. Но пока хотелось бы поговорить о другом.

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

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

Вот о нескольких таких случаях мы и попробуем рассказать.

Надеемся, что очередной выходной посреди недели вас не расслабил и вы внимательно следили за «вторником обновлений», который фактически начинается в 9-10 вечера по Москве. Если же парад Победы и поездка на дачу немного выбили вас из рабочего ритма, то добро пожаловать под кат. Вендоры выкатили несколько важных патчей, закрывающих действительно серьезные уязвимости, так что рекомендуем обратить внимание.



Само название Patch Tuesday придумали в Microsoft, поэтому с них и начнем.

В Microsoft Exchange устранены сразу 5 уязвимостей, одна из которых — CVE-2018-8154 — особенно выделяется: злоумышленнику достаточно отправить на почтовый сервер MS Exchange специальным образом созданное письмо, чтобы на сервере выполнился код с привилегиями уровня SYSTEM.

Главное в платежной системе — взять денежки, перевести записи из одной таблички в ту же самую табличку со знаком «минус». Звучит не очень сложно, пока не пришли юристы. Платежные системы во всем мире облагаются огромным количеством всевозможных отягощений и указаний. Поэтому в рамках разработки платежной системы приходится все время балансировать на грани между тяжелым enterprise и вполне нормальным масштабируемым web-приложением.

Под катом рассказ Филиппа Дельгядо (dph) на Highload++ про опыт, накопившийся за несколько лет работы над платежной системой для российского легального букмекерского бизнеса, про ошибки, но и про некоторые достижения, и про то, как грамотно смешать, но не взбалтывать, web с enterprise.

Мы продолжаем размещать доклады с семинара Geektimes, проведенного компанией RUVDS совместно с компанией TechMedia. Сегодня мы публикуем расшифровку видео с круглого стола о том, как писать в корпоративных блогах на Хабре и Geektimes.  Его участниками стали легендарные люди на Хабре: Алексей (Boomburum) Шевелёв, Данил Дехканов и Влад (vvzvlad) Зайцев.