Решение задачи распознавания изображений (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 г.

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

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

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

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

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

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


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

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

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

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

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

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