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

Современный рынок ИБ наполнен всевозможными продвинутыми решениями с приставками в названии Next generation, Unified, AntiAPT ну или хотя бы 2.0. Производители обещают новый уровень автоматизации, автореспонса, распознования зеродея и прочие чудеса. Любой безопасник знает: нужно усиленно защищать периметр, вовремя ставить патчи, внедрять хостовые и поточные антивирусы, DLP, UEBA и прочие средства. Можно и даже нужно организовать ситуационный центр (SOC) и выстроить процессы выявления и реагирования на инциденты, проводить сложный Threat Intelligence, обмениваться фидами. В общем-то этим и заполнена жизнь обычного ИБэшника, чуть более чем на 100%…

Но все это бесполезно! Потому что внутри любой компании находится Homo vulnerable (в простонародье — сотрудник), иногда много. Его далекие предки Homo sapiens sapiens, проходя этапы дарвиновской эволюции, отлично освоили работу с браузером, почтовым клиентом и офисным пакетом, и теперь мы наблюдаем Homo vulnerable. От Homo sapiens sapiens он отличается наличием смартфона, кучей аккаунтов в соцсетях и атрофированным умением изобретать орудия труда из палок и камней. Он еще он что-то слышал про хакеров, но это где-то там, потому что даже если он с ними и сталкивается, то ему не больно и не страшно: максимум чем он рискует — это некое количество денежных единиц.

— Ребята, вы круты! Так нас еще никто не опускал!
— Мы старались.

Да, жизнь охотников за уязвимостями полна специфических комплиментов от заказчиков и не менее специфических ситуаций. За прошедший год мы выполнили более пятидесяти тестов на проникновение в разные компании и, надо сказать, повидали всякое. Один пароль ко всем учеткам и системам, открытое хранение паролей в базе данных, остатки отладочного функционала в боевой среде… Поэтому, когда наши коллеги из JSOC CERT поведали несколько историй по расследованию киберинцидентов, мы в отделе пентеста решили не отставать и показать другую сторону «баррикад»: инфраструктуру заказчика глазами хакера. Сегодня расскажем о наиболее интересных за последнее время внешних пентестах, когда мы должны были проникнуть во внутренний периметр заказчика, имея только список его внешних IP-адресов и доменных имен.

Ещё не успела отшуметь уязвимость BlueKeep (CVE-2019-0708) для старых версий ОС Windows, нацеленная на реализацию протокола RDP, как снова пора ставить патчи. Теперь в зону поражения попали все новые версии Windows. Если оценивать потенциальную угрозу от эксплуатации уязвимостей путем прямой атаки из интернета по методу WannaCry, то она актуальна для нескольких сотен тысяч хостов в мире и нескольких десятков тысяч хостов в России.



Подробности и рекомендации по защите под катом.

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

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

Как говаривал Генри Форд, все можно сделать лучше, чем делалось до сих пор. Вот и мы так подумали, когда приступили к работе над версией 3.1 нашего анализатора защищенности приложений. Нам ОООЧЕНЬ хотелось сделать наш продукт не только самым крутым по функциональности: например, реализовать поддержку максимального количества языков программирования. Но и наиболее эргономичным, удобным, эстетически привлекательным… – ну чтобы прям глаз не оторвать! И так мы увлеклись своей задумкой, что даже название продукту поменяли. В общем, выложились по полной. А результатами своих усилий решили поделиться с вами в этом обзоре.

Мы в JSOC CERT расследуем инциденты. Вообще все 170 человек в JSOC занимаются расследованиями, но в руки экспертов CERT попадают наиболее технологически сложные случаи. Как, к примеру, обнаружить следы вредоноса, если злоумышленник прибрал за собой? Каким образом найти «волшебника», удалившего важные бизнес-документы с файлового сервера, на котором толком не настроено логирование? Ну и на сладкое: как может злоумышленник без проникновения в сеть получить пароли от десятков не связанных между собой доменных учеток? Подробности, как всегда, под катом.

Большинство успешных атак организации реализуется через уязвимости и закладки в софте. К счастью, сканер уязвимостей ПО уже рассматривается компаниями не как что-то экзотическое, а как необходимый элемент инфраструктуры защиты. Если при небольших объемах разработки можно использовать сканер as is, то когда объемы большие, приходится автоматизировать процесс. Но кто должен им управлять? Решать, как часто проверять релизы? Заниматься верификацией уязвимостей? Принимать решение, наложить ли вето на релиз и отправить код на устранение уязвимостей? И отвечать на многие другие вопросы. Вот тут на авансцену выходит Application Security Manager — менеджер по безопасной разработке ПО.



Но где сыскать такую редкую птицу или как вырастить самим? Артем Бычков, менеджер по безопасности приложений АО «Райффайзенбанк», и Даниил Чернов, руководитель направления Solar appScreener компании «Ростелеком-Солар», рассказывают, какие требования к Application Security Manager диктует практика разработки в российских компаниях.

«Мир. Труд. Май» — это не только про приятную работу на даче, но и про установку обновлений, тем более что в этом месяце производители офисного программного обеспечения потрудились на славу и закрыли в сумме 162 уязвимости, из которых 90 позволяют выполнить произвольный код в системе.

Стало известно о критичной RCE-уязвимости в Службах Удаленных рабочих столов RDS (на более ранних ОС – Служба Терминалов TS ) в ОС Windows (CVE-2019-0708), которая при успешной эксплуатации позволяет злоумышленнику, не прошедшему проверку подлинности, осуществить удаленное выполнение произвольного кода на атакуемой системе.



Cогласно информации, предоставленной компанией Microsoft, для успешной эксплуатации необходимо лишь иметь сетевой доступ к хосту или серверу с уязвимой версией операционной системы Windows. Таким образом, в случае если системная служба опубликована на периметре, уязвимость можно проэксплуатировать непосредственно из сети интернет, без дополнительного способа доставки. Рекомендации по мерам защиты под катом.

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

11 февраля 2014 года ФСТЭК России утвердила методический документ «Меры защиты информации в государственных информационных системах». Этот документ применяется для «выбора и реализации в отношении информации, не относящейся к гостайне и содержащейся в государственных информационных системах (ГИС), мер защиты, направленных на обеспечение конфиденциальности, целостности и доступности информации». Регулятор рекомендует применять данный документ для защиты информации как в ГИС, так и в негосударственных информационных системах, в том числе для обеспечения безопасности ПДн.

В документе указаны рекомендуемые меры защиты информации с отсылкой к определенным классам систем, например, таким как средства аутентификации, антивирусы, IDS/IPS и др. При этом регулятор напрямую не указывает на необходимость применения систем защиты конфиденциальных данных от утечек (DLP). Однако эти системы позволяют выполнить такие требования, как обеспечение конфиденциальности, целостности информации, передаваемой из информационной системы, регистрация событий безопасности и др.



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

«Ростелеком» провел исследование DDoS-атак, осуществлявшихся на российский сегмент интернета в 2018 году. Как свидетельствует отчет, в 2018 году произошел резкий рост не только количества DDoS-атак, но и их мощности. В фокусе внимания злоумышленников чаще всего оказывались игровые серверы.

Авторы: к.ф.-м.н. Чернов А.В. (monsieur_cher) и к.ф.-м.н. Трошина К.Н.

Как с помощью самых общих предположений, основанных на знании современных процессорных архитектур, можно восстановить структуру программы из бинарного образа неизвестной архитектуры, и дальше восстановить алгоритмы и многое другое?

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

Практически повсеместное использование в массовых устройствах программируемых микроконтроллеров (концепции интернета вещей IOT или умного дома SmartHome) требует обратить внимание на бинарный анализ встраиваемого кода, или, другими словами, бинарный анализ прошивок устройств.

Бинарный анализ прошивок устройств может иметь следующие цели:

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

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

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

В течение всего прошедшего года в гонке кибервооружений между атакующими и защитниками все большую популярность набирала тема киберразведки или Threat Intelligence. Очевидно, что превентивное получение информации о киберугрозах — очень полезная штука, однако само по себе оно инфраструктуру не обезопасит. Необходимо выстроить процесс, который поможет грамотно распоряжаться как информацией о способе возможной атаки, так и имеющимся временем для подготовки к ней. И ключевым условием для формирования такого процесса является полнота информации о киберугрозе.



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

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

Дисклеймеры

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

1. Supply Chain Management

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

— Надо бы корову купить…
— Надо бы, да где денег взять?
«Трое из Простоквашино»




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

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