С начала сегодняшнего дня и по настоящее время эксперты JSOC CERT фиксируют массовую вредоносную рассылку вируса-шифровальщика Troldesh. Его функциональность шире, чем просто у шифровальщика: помимо модуля шифрования в нем есть возможность удаленного управления рабочей станцией и дозагрузки дополнительных модулей. В марте этого года мы уже информировали об эпидемии Troldesh — тогда вирус маскировал свою доставку с помощью IoT-устройств. Теперь же для этого используются уязвимые версии WordPress и интерфейса cgi-bin.

Эта статья пригодится тем, кто работает в компании, признанной субъектом критической информационной инфраструктуры (КИИ), а значит — обязанной выполнить требования №187-ФЗ и построить центр ГосСОПКА (Государственной системы обнаружения, предупреждения и ликвидации последствий компьютерных атак), соответствующий требованиям ФСБ России.

В прошлой статье мы затронули самые основы этой темы и рассказали о требованиях ФСБ к техническим средствам, которые должны использоваться в центре ГосСОПКА. Однако эти требования (едва ли не впервые) распространяются не только на технические средства защиты, но и на реализацию конкретных процессов мониторинга, реагирования и расследования инцидентов ИБ. Поэтому сегодня мы расскажем о том, какие кадровые ресурсы вам понадобятся, чтобы все эти процессы обеспечить.

Многие центры безопасности смыслом своей работы, а то и жизни делают борьбу с хакерами и атаками. Дело действительно важное и интеллектуально очень емкое. Исследуем данные Threat Intelligence, собираем атрибуцию на группировки и её TTP (tactics, techniques and procedures), разрабатываем отдельные сценарии и правила выявления инцидентов, внедряем мощные технологические решения. Это огромный и важный кусок работы любой команды по безопасности, а уж тем более любого зрелого SOC.



Но периодически все классические подходы к безопасности через мониторинг просто умножаются на ноль, когда в жизнь приходит большая и неприятная массовая атака. Та самая, о которой узнаёт даже ваша бабушка. Условно назовем такую атаку медиакиберпандемией, чтобы не путать с регулярными рассылками Cobalt или хитрыми инструментами Silence (для бывалых они уже стали чем-то вроде белого шума). Речь о Heartbleed, Shellshock, WannaСry, уязвимости в оборудовании Cisco и прочих. Что их отличает от прочих кибердиверсий? Как в этом случае стоит (или не стоит) вести себя SOC и просто ИБ-службе компании? Давайте разбираться под катом.

В конце прошлого года, после сделки с «Ростелекомом», мы получили в свое распоряжение облачную SD-WAN/SDN-платформу для предоставления заказчикам ИБ-сервисов. Мы подключили к проекту вендоров, поставляющих свои решения в виртуализованном виде, и получилась огромная махина, которую мы назвали Единой платформой сервисов кибербезопасности, или ЕПСК. Ее ключевая особенность — поставка из облака технологий защиты с возможностью централизованного управления: развертывание и изменение отдельной сетевой функции или глобальная трансформация во всех обслуживаемых офисах занимают считанные минуты. Сегодня расскажем подробнее о ее архитектуре и «начинке».

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

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

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

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



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

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

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

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

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



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

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



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

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

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

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



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

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

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



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

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




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

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



В первой статье мы сравним сходства и различия в тех рекомендациях российских и зарубежных регуляторов по защите информации, к которым в той или иной степени могут быть применимы системы защиты от утечек. Во второй – расскажем о применимости ключевых DLP-систем по составляющим модулям к мерам защиты ГИС, рекомендуемым ФСТЭК РФ. В третьей рассмотрим тот же перечень систем защиты от утечек на предмет корреляций с рекомендациями американского стандарта NIST US.

Итак, что же нам рекомендуют ФСТЭК РФ и NIST US применительно к защите информации, для обеспечения которой могут быть использованы DLP-системы? Ответ на этот вопрос – под катом.

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

Мы в Solar JSOC на постоянной основе собираем данные о событиях и инцидентах информационной безопасности в инфраструктурах заказчиков. На базе этой информации мы раз в полгода делаем аналитику, которая демонстрирует, как меняются атаки на российские организации. Сегодня мы собрали для вас самые интересные тренды первого полугодия 2018 г.