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




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

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

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

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

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



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

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

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

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

Для любителей подробностей – короткая справка по новым уязвимостям под катом.

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

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

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

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