Обзор и видео докладов по информационной безопасности с конференции SECR-2014

    В прошлом году, на конференции SECR-2014 (Software Engineering Conference Russia) было 140 докладов по всем направлениям программной инженерии — от Computer Science до современного IT-менеджмента, от тонкостей верификации Linux-драйверов до бизнес-анализа и даже юридических вопросов. Была и секция докладов по информационной безопасности.

    Я снимал и публиковал видео, а сейчас, в скучный летний сезон, предлагаю свой краткий обзор SECR-докладов именно по различным аспектам информационной безопасности — как от экспертов индустрии, так и от университетских исследователей. Буду рад, если замотивирую вас на просмотр и отзывы, или даже выступить на конференции в этом году.






    «Мобильный банкинг — кража по воздуху»


    Слайды, допматериалы, контакты для доклада «Мобильный банкинг — кража по воздуху»
    Будет представлено новое независимое исследование безопасности мобильных приложений для мобильного банкинга для 2 платформ (iOS, Android), около 120 приложений, от более 70 банков.

    В фокусе исследования — уязвимость, использование которой может привести к реализации атаки MiTM (Man-in-The-Middle) и краже финансовых средств со счетов клиентов.
    Времена, когда через мобильники шли только неважные микроплатежи прошел — теперь в мобильном банкинге полно денег, уязвимость может привести и к потере счета клиентом и репутации банка, а с точки зрения ЦБ — банк-клиент от мобильника с приложением вообще одно и то же.

    Команда докладчика сконцентрировались исключительно на атаке «Man-in-the-middle», ибо в мобильном банкинге никто не будет подключать экранированный кабель в газовом канале, а подделать WiFi-точку проще простого. Чуть сложнее, но более чем реально (железо за $3000) подделать даже базовую станцию. Не говоря уже о зараженных корпоративных сетях, где перешиваются DNS-настройки и весь трафик может сливаться наружу.

    Смотрели больше сотни приложений под iOS и Android (Winphone и BlackBerry отложили за малостью) и долбили в одну точку — безопасность транспортного уровня, корректность проверки SSL-сертификатов, и неиспользование SSL-Pinning. И чего только там не увидели.

    И вымирающий, к счастью, набор самоделок — самопальное шифрование на XORах и т. п. И модные мультиплатформенный фреймворки (Titanium, Apache Cordova), облегчающие кроссплатформенную разработку, но из-за своей монструозности, неизбежно дырявые, на уровне «вообще не проверяет SSL-сертификат».

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

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

    Короче — точно сломали четверть андроидных приложений, и почти каждое пятое iOSное.

    Что делать? Двухуровневая идентификация — тоже не панацея, ведь часто перехватываются оба канала подтверждения. Биометрия пока еще sucks — какие-то понтовые системы команда докладчика ломала на уровне архитектуры, не доходя до алгоритмов проверки, а там, где доходили — уровень «биометрического разрешения» еще совсем никакой — так систему графологической проверки росписи вовсе сломали сделав универсальную роспись…

    Смотрите доклад, в конце будут и рекомендации «что делать», чтобы не было «как страшно жить».

    «Сквозной процесс безопасности, интегрированный в жизненный цикл разработки ПО»


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

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

    Обсуждаются компромиссы, позволяющие снизить затраты на осуществление такого процесса до приемлемого уровня.
    Секьюрити отдел, который занимается не только наведением лоска в телеком продуктах перед PCI DSS-аудитом, но и по отзывам аудиторов, наиболее удачный и полезный из подобных отделов в Европе. Все это в крупном телекоме EE, плоде недавней интеграции более известных T-Mobile и Orange.

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

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

    Ибо, как в истинно британской компании, там британский только менеджмент. И разработка, и секьюрити аудит — все аутсорсинг или оффшоринг. И если в случае продуктов — это аутсорсинг («покупка продукта»), где менеджеры да, могут пытаться забивать на безопасность в пользу сроков и функциональности, то секьюрити тим — оффшоринг («покупка людей»). Ибо тут нужны долгие и плотные отношений с конкретными людьми. И с учетом, что секьюрити тип состоит пополам из российских и китайских специалистов, получается двояко. С одной стороны, это отпугивает по политическим причинам («Россия-Китай? Враги! Хакеры!»), с другой — это четкий расчет, ибо у европейцев нет прописки и всего такого, и ничто не мешает им внезапно свалить с секретами. А в странах с элементами тоталитарного контроля (паспорт-прописка) гораздо надежней выстраивать долговременные отношения с сотрудниками.

    Так что в целом, все это вроде как выгодно и эффективно. Конечно, очень трудно померить эффективность нефункциональных отделов, особенно таких, где оценки рисков играют с огромными суммами и непредсказуемыми вероятностями (докладчик упомянул Санкт-Петербургский парадокс). Но если кратко — то обходится дешевле функционального тестирования, релизы не тормозит, в пакет услуг входит и отчет с рекомендациями, и обучение, и постановка процессов, OWASP-рекомендации… и в целом сделано так, что всякая сертификация получается «на сдачу» от реальной работы по проектам. А в целом, голодать не приходится, бюджет в телекомах выделают значительный, через внутренний хозрасчет все это попадает в секьюрити тим, где стоит задача добится максимума на выделенные деньги.

    И в целом, позиция у секьюрити тим отличная — они не отвечают за окончательную безопасность, не блокируют релизы (даже с критическими уязвимостями релиз возможен, если на себя ответственность возьмет риск-менеджмент тим, или кто-то выше), не тушат пожары при секьюрити-факапах (там отдельные люди, и факапы есть — я вот погуглил, сразу вылезло [1]), то есть как у ленивых QA, та же мантра «мы не отвечаем за качество/безопасность, мы его только исследуем», и даже вообще вспоминается «Офис» с «как чем я занимаюсь? — я профессионал, я работаю с этими чертовыми людьми!».

    Ну, конечно реальная работа есть — в команде глубоко используют HP Fortify, с кастомной базой правил и настроек, по отзываем вендора — «одно из последних мест в мире, где могут конфигурировать правила для Fortify», более того, некоторые специалисты росли и переходили в команду Fortify. И кстати, докладчик сильно предупреждал против использования облачного сервиса fortify on demand — «этим занимаются крайне некомпетентные люди на филиппинах».

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

    Разумеется, под конец пожаловались, что трудно искать хороших специалистов — ибо нужны реально опытные разработчики-архитекторы, внезапно почему-то решившие завязать с программированием.




    «Технология виртуализации аппаратных модулей безопасности в контейнерах Linux»


    Слайды, допматериалы, контакты для доклада «Технология виртуализации аппаратных модулей безопасности в контейнерах Linux»
    В докладе описана технология построения виртуального модуля безопасности, опирающаяся на использование контейнеров в Linux. Данное решение может быть интересно тем, кто планирует или уже использует облачные сервисы для построения ИТ-инфраструктуры.
    Опустив стандартные слова про важность безопасности и пугалки взломами и утечками, тезисно идея выглядит так:
    • OpenSSL — cтандартная библиотека безопасности, количество портов OpenSSL превышает в 10 раз количество систем, на которых можно запустить Linux. И она уже не раз показала классные дыры, которых не могли найти годами. Да, сейчас делают форки (BoringSSL/LibreSSL), но человек слаб, ошибки будут всегда.
    • Аппаратные модули шифрования — правильно и круто. Но блин, как дорого. Аццки. Что у нас, что у них.
    А тут у нас тренд виртуализации, все будет жить в контейнерах и все такое.

    Давайте примем гипотезу осуществовании односторонних функций о невзламываемости хост-машины, и засунем всю криптографию в отдельный контейнер, шину специальную сделаем, API максимально совместимое и все такое. PROFIT.

    Сделан академический Proof-of-concept на OpenVZ контейнерах, даже померена производительность под нагрузкой — вроде даже не совсем плохая (посередине, но на логарифмической шкале). С масштабируемостью совсем не ОК. Взлетит или нет — кто знает, сама страничка проекта, увы, давно без движения.

    «Разработка протокола с прыгающим IP адресом»


    Слайды, допматериалы, контакты для доклада «Разработка протокола с прыгающим IP адресом»
    DDoS атаки остаются одной из главных угроз для Интернет-северов. В докладе предлагается программное решение повышающее устойчивость серверов к DDoS атакам и перехвату трафика, основанное на псевдослучайном изменении реального IP адреса защищаемого сервера на адреса из большого набора IP адресов.
    Старая добрая проблема DDOS атак, к которой, по мнению автора, почему-то равнодушны магистральные провайдеры, и предлагается ее решать не фильтрующими супержелезками, типа Tilera, а чисто софтверным методом.

    Если в двух словах — это развитие классической парадигмы «Frequency hopping», придуманной во время WWII одной актрисой эротических сцен (прим.ред). Только тут это некий супермаскарандинг с индивидуальным IP-адресом для каждого пакета каждой клиентской сессии (!).

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

    Все это реализовано пока только для TCP-протокола, дописыванием модуля ядра netfilter.

    Очевидны и куча минусов этого подхода:
    • Сервер авторизации становится Single Point of Failure и новой точкой для атаки и его надо отдельно защищать.
    • Публичные IP-адреса ресурс дико редкий, как IPv4, так кстати, небесплатно достаются и IPv6-адреса.
    • Все это не подойдет для публичных сервисов (нужен спецклиент), только для корпоративной работы, а в этом случае, непонятно, почему не использовать добротный VPN-шлюз.
    Возможно конечно, вы найдете и другие аргументы за или против.

    «DIY-программирование и защита от фрода»


    Слайды, допматериалы, контакты для доклада «DIY-программирование и защита от фрода»
    В рассказе пойдет речь о нашем опыте использования систем BRE (business rules engine) — способе дать не-разработчикам писать код и, при необходимости, быстро менять логику работы приложения.

    На примере одного из компонентов системы фрод-мониторинга рассмотрим особенности разработки, преимущества такого подхода, проблемы, с которыми пришлось столкнуться, и важные моменты, которые необходимо предусмотреть при реализации.
    Хотя название доклада хакерское — тут и Do It Youself, и антифрод… но на самом деле, тут скорее про архитектуру и процессы в ЯндексДеньгах.

    Суть в том, что обманывающие схемы фрода быстро тиражируются, их нужно гасить и противодействовать за считанные часы — если все бизнес-процессы были бы захардкожены, то даже при самом ни на есть аджайле, к деплою в конце итерации, уже бы у всех все увели. Разумеется, нужно использовать BRE — Business Rule Engine, то есть отдельно отсаженную высокоуровневую бизнес-логику, крутящуюся поверх грамотной архитектуры с выделенной доменной моделью.

    Правила надо писать на человекочитаемых высокоуровневых языках, типа Drools (WebRule, BizTalk), нужно логгировать все и накапливать бигдату знаний в специальном нереляционном хранилище для быстрого доступа.

    Но в любом случае — код есть код, и снова, для этого «высокоуровневого программирования» возникают задачи рецензирования, тестирования, … и часть тестирования, как ни страшно звучит, опять проходит на кошках пользователях — то есть постепенный деплой с A/B-тестированием… не думал, что даже в денежных сервисах делают так.

    Цитируя докладчика — «Много, много соломок, которых нужно со всех сторон подстелить» (с).

    «Самовосстанавливающиеся системы»


    Слайды, допматериалы, контакты для доклада «Самовосстанавливающиеся системы»
    оригинальное видео «Self-healing Systems» на английском


    Использование вычислительных систем в каждом аспекте нашей повседневной жизни вызывает ряд проблем для программной инженерии. В частности, одним из самых важных требований для сегодняшних систем является высокая доступность, — несмотря на опасность неисправностей, атак и на изменчивое окружение. Для решения этих задач мы должны уметь строить системы, которые в большей степени контролируют собственную надежность, безопасность и полезность, автоматизировать задачи, которые в настоящее время ведут к сбоям системы и требуют внимания экспертов и администраторов. Это приводит к появлению новых разделов в области разработки ПО и проектирования, включая: Автономные компьютерные системы (Autonomic Computing), Самовосстановливающиеся системы (Self-healing Systems) или Самоадаптивные системы (Self-Adaptive Systems).

    В этом докладе я описываю последние достижения в этой области, которые позволяют нам решить ряд инженерных задач, в числе которых:
    • (а) способность поддерживать самовосстановление через архитектурные модели и автоматизацию восстановления,
    • (б) новые технологии диагностики неисправности во время работы приложений и создания систем управления,
    • (с) возможности поддержки систем самобезопасности (self-securing systems).
    Тут речь не о гонке вооружений с хакерами, а о «доступности» — часто забываемом компоненте информационной безопасности. Действительно, какая разница, упадет ли система под хакерским DDOSом или под рождественнским/хабра/реддит эффектом. Надо проектировать информационные системы, чтобы отклонения условий эксплуатации или маловероятные черные лебеди не смогли их выключить. В общем, «перестаньте думать о хакерах, думайте о ваших собственных IT-специалистах» .

    Достаточно очевидные наблюдения, что современная хайлоад архитектура и так вся про дублирование и доступность любой ценой (примеры — Google File System, IBM MAPE-K), да и энтерпрайз тренды с микросервисной архитектурой тоже туда.

    Докладчик же продвигал некий собственный спектр моделей и формализмов для адаптивного восстановления, где была и как-то тривиально понятная архитектура с отдельным контролирующим контуром и стратегией уровня Plan-Do-Check-Act Monitor-Analyze-Plan-Execute, на более детальном уровне все это распадалось на отдельные процессы управления моделью и адаптацией, исполнения стратегии, оценки архитектуры… (все вместе это называлось, Rainbow-архитектурой).

    Там и специализированный предметно-ориентированный язык Stitch для задания рандомизированных стратегий адаптации, и хитрая система «спектральной локализации ошибок»… и все это тестировали даже на самсунговых системах управления производством.




    «Умышленная безопасность»


    Слайды, допматериалы, контакты для доклада «Умышленная безопасность»
    оригинальное видео «Security by design» на английском


    Требования и тенденции безопасности в проектировании и разработке программ, в том числе на корпоративном уровне. Как мы можем добиться безопасности и устойчивости ИТ-систем и сервисов в наших организациях.

    Чего мы хотим:
    • Точка зрения клиента и пользователя — можем ли мы создать безопасное ПО с «защитой от дурака»?
    • Помогают ли современные требования и стандарты безопасности или они лишь создают новый тип уязвимостей, общий для всего ПО?
    Как мы можем этого достичь:
    • Как разрабатывать безопасное ПО — принципы разработки, специальные утилиты, тестирование безопасности?
    • Какие ключевые умения, связанные с безопасностью, должны требоваться от команды разработчиков?
    • Что делать с наплывом «big data» в кибербезопасности — объединять и реагировать на информацию из многочисленных источников о нападениях и угрозах?
    Сколько:
    • Сколько стоит безопасность, и как сделать её стоимость доступной и контролируемой?
    • Сравнение цены предотвращения с ценой исправления последствий
    Формат «Дискуссионная панель» — немного сумбурная дискуссия четырех англоязычных докладчиков, с вопросами из зала.

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

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

    Что делать с легаси системами, в которых трудно прокачать безопасность, не меняя чуть более чем все? «цифровая безопасность… она часто бывает невидимой, этот суслик эта опасность, но она есть…

    Автор доклада про адаптивные системы продвигал свои идеи о меньшей уязвимости динамических систем, доходя правда, до весьма странных идей, что мультистековые приложения (реализованные, условно, и под Linux, и под Windows, и под… — и запущенные параллельно) — менее уязвимы. С точки зрения надежности может оно и так, но вот уязвимостей там явно будет пропоррционально больше, если не думать про «security by obscurity and insanity». Были и другие упоротые идеи, например, «атаковать вирусы».

    Много обсуждалась бесконечная гонка безопасности, от «сколько стоит добавить девятку к надежности?» до, а может ну нафиг, может достаточно тратить больше, чем соседа? (в духе интернационального анекдота «мне не нужно бежать быстрее чем тигр…»).
    Отзывы-комментарии приветствуется, надеюсь, вы либо найдете в докладах что-то полезное, либо, если на ваш взгляд, все это некруто, то вы явно созрели для доклада — регистрируйтесь пожалуйста.

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

    Да, там кончились официальные сроки, но, по моему опыту участия в Программном Комитете, если вам есть что рассказать — доклад по сильной теме успеет пройти ревью.
    Поделиться публикацией

    Комментарии 0

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое