В прошлом году, на конференции SECR-2014 (Software Engineering Conference Russia) было 140 докладов по всем направлениям программной инженерии — от Computer Science до современного IT-менеджмента, от тонкостей верификации Linux-драйверов до бизнес-анализа и даже юридических вопросов. Была и секция докладов по информационной безопасности.
Я снимал и публиковал видео, а сейчас, в скучный летний сезон, предлагаю свой краткий обзор SECR-докладов именно по различным аспектам информационной безопасности — как от экспертов индустрии, так и от университетских исследователей. Буду рад, если замотивирую вас на просмотр и отзывы, или даже выступить на конференции в этом году.
Слайды, допматериалы, контакты для доклада «Мобильный банкинг — кража по воздуху»
Команда докладчика сконцентрировались исключительно на атаке «Man-in-the-middle», ибо в мобильном банкинге никто не будет подключать экранированный кабель в газовом канале, а подделать WiFi-точку проще простого. Чуть сложнее, но более чем реально (железо за $3000) подделать даже базовую станцию. Не говоря уже о зараженных корпоративных сетях, где перешиваются DNS-настройки и весь трафик может сливаться наружу.
Смотрели больше сотни приложений под iOS и Android (Winphone и BlackBerry отложили за малостью) и долбили в одну точку — безопасность транспортного уровня, корректность проверки SSL-сертификатов, и неиспользование SSL-Pinning. И чего только там не увидели.
И вымирающий, к счастью, набор самоделок — самопальное шифрование на XORах и т. п. И модные мультиплатформенный фреймворки (Titanium, Apache Cordova), облегчающие кроссплатформенную разработку, но из-за своей монструозности, неизбежно дырявые, на уровне «вообще не проверяет SSL-сертификат».
И надо помнить о легальных закладках в каждом броузере и телефоне — пара сотен совершенно ненужных корневых сертификатов (включая сертификаты правительств иностранных государств), которых, между прочим, в iOS принципиально нельзя выкинуть, причем элементарно социнженерией добавить «поддельные».
Геморройность разработки для банков внешними командами приводит к куче архитектурных прокладок-Mockов, лишней отладочной информации… все это конечно попадает в продакшн. В результате в приложении работают классы FakeSSLCheck, при падении вываливается гигабайтный стек с полной структурой внутренней банковской системы…
Короче — точно сломали четверть андроидных приложений, и почти каждое пятое iOSное.
Что делать? Двухуровневая идентификация — тоже не панацея, ведь часто перехватываются оба канала подтверждения. Биометрия пока еще sucks — какие-то понтовые системы команда докладчика ломала на уровне архитектуры, не доходя до алгоритмов проверки, а там, где доходили — уровень «биометрического разрешения» еще совсем никакой — так систему графологической проверки росписи вовсе сломали сделав универсальную роспись…
Смотрите доклад, в конце будут и рекомендации «что делать», чтобы не было «как страшно жить».
Слайды, допматериалы, контакты для доклада «Сквозной процесс безопасности, интегрированный в жизненный цикл разработки ПО»
Бест-практики, большая часть которых сводится к достаточно тривиальным, везде звучащим мантрам, что «Безопасность приложений это в первую очередь процесс», но детали небезинтересны.
Плотная интеграция с полным циклом разработки. Ибо тут не только предрелизный секьюрити-аудит, но даже «изменять приходится не только дизайн, но и исходные бизнес-требования» ©. Сквозной процесс начиная с бизнес-требований, ручной и полуавтоматический анализ, позиционные бои за безопасность с менеджерами-контрактниками (хотя ситуации «нечем платить за безопасность», к счастью нет).
Ибо, как в истинно британской компании, там британский только менеджмент. И разработка, и секьюрити аудит — все аутсорсинг или оффшоринг. И если в случае продуктов — это аутсорсинг («покупка продукта»), где менеджеры да, могут пытаться забивать на безопасность в пользу сроков и функциональности, то секьюрити тим — оффшоринг («покупка людей»). Ибо тут нужны долгие и плотные отношений с конкретными людьми. И с учетом, что секьюрити тип состоит пополам из российских и китайских специалистов, получается двояко. С одной стороны, это отпугивает по политическим причинам («Россия-Китай? Враги! Хакеры!»), с другой — это четкий расчет, ибо у европейцев нет прописки и всего такого, и ничто не мешает им внезапно свалить с секретами. А в странах с элементами тоталитарного контроля (паспорт-прописка) гораздо надежней выстраивать долговременные отношения с сотрудниками.
Так что в целом, все это вроде как выгодно и эффективно. Конечно, очень трудно померить эффективность нефункциональных отделов, особенно таких, где оценки рисков играют с огромными суммами и непредсказуемыми вероятностями (докладчик упомянул Санкт-Петербургский парадокс). Но если кратко — то обходится дешевле функционального тестирования, релизы не тормозит, в пакет услуг входит и отчет с рекомендациями, и обучение, и постановка процессов, OWASP-рекомендации… и в целом сделано так, что всякая сертификация получается «на сдачу» от реальной работы по проектам. А в целом, голодать не приходится, бюджет в телекомах выделают значительный, через внутренний хозрасчет все это попадает в секьюрити тим, где стоит задача добится максимума на выделенные деньги.
И в целом, позиция у секьюрити тим отличная — они не отвечают за окончательную безопасность, не блокируют релизы (даже с критическими уязвимостями релиз возможен, если на себя ответственность возьмет риск-менеджмент тим, или кто-то выше), не тушат пожары при секьюрити-факапах (там отдельные люди, и факапы есть — я вот погуглил, сразу вылезло [1]), то есть как у ленивых QA, та же мантра «мы не отвечаем за качество/безопасность, мы его только исследуем», и даже вообще вспоминается «Офис» с «как чем я занимаюсь? — я профессионал, я работаю с этими чертовыми людьми!».
Ну, конечно реальная работа есть — в команде глубоко используют HP Fortify, с кастомной базой правил и настроек, по отзываем вендора — «одно из последних мест в мире, где могут конфигурировать правила для Fortify», более того, некоторые специалисты росли и переходили в команду Fortify. И кстати, докладчик сильно предупреждал против использования облачного сервиса fortify on demand — «этим занимаются крайне некомпетентные люди на филиппинах».
В целом, позиция докладчика позитивна и убедительна — «это работает, даже если вы не верите», хотя честно признался, что у них есть разработчик, которого в момент сертификации лучше держать на больничном, чтобы он не сорвал все своим пессимизмом.
Разумеется, под конец пожаловались, что трудно искать хороших специалистов — ибо нужны реально опытные разработчики-архитекторы, внезапно почему-то решившие завязать с программированием.
Слайды, допматериалы, контакты для доклада «Технология виртуализации аппаратных модулей безопасности в контейнерах Linux»
Давайте примем гипотезу осуществовании односторонних функций о невзламываемости хост-машины, и засунем всю криптографию в отдельный контейнер, шину специальную сделаем, API максимально совместимое и все такое. PROFIT.
Сделан академический Proof-of-concept на OpenVZ контейнерах, даже померена производительность под нагрузкой — вроде даже не совсем плохая (посередине, но на логарифмической шкале). С масштабируемостью совсем не ОК. Взлетит или нет — кто знает, сама страничка проекта, увы, давно без движения.
Слайды, допматериалы, контакты для доклада «Разработка протокола с прыгающим IP адресом»
Если в двух словах — это развитие классической парадигмы «Frequency hopping», придуманной во время WWII одной актрисой эротических сцен (прим.ред). Только тут это некий супермаскарандинг с индивидуальным IP-адресом для каждого пакета каждой клиентской сессии (!).
То есть DNS перенаправляют все запросы на некий входной «сервер авторизации», который оперирует здоровым пулом IP-адресов и по хитрым правилам меняет их по времени. На клиентских машинах тоже должен быть специальный софт, который умеет играть в эти игры и синхронно все менять.
Все это реализовано пока только для TCP-протокола, дописыванием модуля ядра netfilter.
Очевидны и куча минусов этого подхода:
Слайды, допматериалы, контакты для доклада «DIY-программирование и защита от фрода»
Суть в том, что обманывающие схемы фрода быстро тиражируются, их нужно гасить и противодействовать за считанные часы — если все бизнес-процессы были бы захардкожены, то даже при самом ни на есть аджайле, к деплою в конце итерации, уже бы у всех все увели. Разумеется, нужно использовать BRE — Business Rule Engine, то есть отдельно отсаженную высокоуровневую бизнес-логику, крутящуюся поверх грамотной архитектуры с выделенной доменной моделью.
Правила надо писать на человекочитаемых высокоуровневых языках, типа Drools (WebRule, BizTalk), нужно логгировать все и накапливать бигдату знаний в специальном нереляционном хранилище для быстрого доступа.
Но в любом случае — код есть код, и снова, для этого «высокоуровневого программирования» возникают задачи рецензирования, тестирования, … и часть тестирования, как ни страшно звучит, опять проходит накошках пользователях — то есть постепенный деплой с A/B-тестированием… не думал, что даже в денежных сервисах делают так.
Цитируя докладчика — «Много, много соломок, которых нужно со всех сторон подстелить» (с).
Слайды, допматериалы, контакты для доклада «Самовосстанавливающиеся системы»
оригинальное видео «Self-healing Systems» на английском
Достаточно очевидные наблюдения, что современная хайлоад архитектура и так вся про дублирование и доступность любой ценой (примеры — Google File System, IBM MAPE-K), да и энтерпрайз тренды с микросервисной архитектурой тоже туда.
Докладчик же продвигал некий собственный спектр моделей и формализмов для адаптивного восстановления, где была и как-то тривиально понятная архитектура с отдельным контролирующим контуром и стратегией уровняPlan-Do-Check-Act Monitor-Analyze-Plan-Execute, на более детальном уровне все это распадалось на отдельные процессы управления моделью и адаптацией, исполнения стратегии, оценки архитектуры… (все вместе это называлось, Rainbow-архитектурой).
Там и специализированный предметно-ориентированный язык Stitch для задания рандомизированных стратегий адаптации, и хитрая система «спектральной локализации ошибок»… и все это тестировали даже на самсунговых системах управления производством.
Слайды, допматериалы, контакты для доклада «Умышленная безопасность»
оригинальное видео «Security by design» на английском
Софт сожрал весь мир, в безопасности ли мы? В загоне ли безопасность, на которую обращают внимание только после функциональных требований и юзабилити? Как просчитать баланс безопасности и юзабельности?
Да, вся эта область информационной безопасности полна «Черных Лебедей» с низкими вероятностями и страшными последствиями — что трудно честно посчитать. Все там контринтуитивно, фиг объяснишь и рядовым сотрудниками ценность регламентов написанных кровью, а начальству — ценность инвестиций в безопасность, особенно если менеджмент совсем эффективный, и не знает основ теорвера.
Что делать с легаси системами, в которых трудно прокачать безопасность, не меняя чуть более чем все? «цифровая безопасность… она часто бывает невидимой,этот суслик эта опасность, но она есть…©
Автор доклада про адаптивные системы продвигал свои идеи о меньшей уязвимости динамических систем, доходя правда, до весьма странных идей, что мультистековые приложения (реализованные, условно, и под Linux, и под Windows, и под… — и запущенные параллельно) — менее уязвимы. С точки зрения надежности может оно и так, но вот уязвимостей там явно будет пропоррционально больше, если не думать про «security by obscurity and insanity». Были и другие упоротые идеи, например, «атаковать вирусы».
Много обсуждалась бесконечная гонка безопасности, от «сколько стоит добавить девятку к надежности?» до, а может ну нафиг, может достаточно тратить больше, чем соседа? (в духе интернационального анекдота «мне не нужно бежать быстрее чем тигр…»).
Отзывы-комментарии приветствуется, надеюсь, вы либо найдете в докладах что-то полезное, либо, если на ваш взгляд, все это некруто, то вы явно созрели для доклада — регистрируйтесь пожалуйста.
Профессионал из индустрии, исследователь из университета, сумрачный тьюринг из подпольного датацентра — конференция ждет вас.
Да, там кончились официальные сроки, но, по моему опыту участия в Программном Комитете, если вам есть что рассказать — доклад по сильной теме успеет пройти ревью.
Я снимал и публиковал видео, а сейчас, в скучный летний сезон, предлагаю свой краткий обзор 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), но человек слаб, ошибки будут всегда.
- Аппаратные модули шифрования — правильно и круто. Но блин, как дорого. Аццки. Что у нас, что у них.
Давайте примем гипотезу о
Сделан академический 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), нужно логгировать все и накапливать бигдату знаний в специальном нереляционном хранилище для быстрого доступа.
Но в любом случае — код есть код, и снова, для этого «высокоуровневого программирования» возникают задачи рецензирования, тестирования, … и часть тестирования, как ни страшно звучит, опять проходит на
Цитируя докладчика — «Много, много соломок, которых нужно со всех сторон подстелить» (с).
«Самовосстанавливающиеся системы»
Слайды, допматериалы, контакты для доклада «Самовосстанавливающиеся системы»
оригинальное видео «Self-healing Systems» на английском
Использование вычислительных систем в каждом аспекте нашей повседневной жизни вызывает ряд проблем для программной инженерии. В частности, одним из самых важных требований для сегодняшних систем является высокая доступность, — несмотря на опасность неисправностей, атак и на изменчивое окружение. Для решения этих задач мы должны уметь строить системы, которые в большей степени контролируют собственную надежность, безопасность и полезность, автоматизировать задачи, которые в настоящее время ведут к сбоям системы и требуют внимания экспертов и администраторов. Это приводит к появлению новых разделов в области разработки ПО и проектирования, включая: Автономные компьютерные системы (Autonomic Computing), Самовосстановливающиеся системы (Self-healing Systems) или Самоадаптивные системы (Self-Adaptive Systems).Тут речь не о гонке вооружений с хакерами, а о «доступности» — часто забываемом компоненте информационной безопасности. Действительно, какая разница, упадет ли система под хакерским DDOSом или под рождественнским/хабра/реддит эффектом. Надо проектировать информационные системы, чтобы отклонения условий эксплуатации или маловероятные черные лебеди не смогли их выключить. В общем, «перестаньте думать о хакерах, думайте о ваших собственных IT-специалистах» ©.
В этом докладе я описываю последние достижения в этой области, которые позволяют нам решить ряд инженерных задач, в числе которых:
- (а) способность поддерживать самовосстановление через архитектурные модели и автоматизацию восстановления,
- (б) новые технологии диагностики неисправности во время работы приложений и создания систем управления,
- (с) возможности поддержки систем самобезопасности (self-securing systems).
Достаточно очевидные наблюдения, что современная хайлоад архитектура и так вся про дублирование и доступность любой ценой (примеры — Google File System, IBM MAPE-K), да и энтерпрайз тренды с микросервисной архитектурой тоже туда.
Докладчик же продвигал некий собственный спектр моделей и формализмов для адаптивного восстановления, где была и как-то тривиально понятная архитектура с отдельным контролирующим контуром и стратегией уровня
Там и специализированный предметно-ориентированный язык Stitch для задания рандомизированных стратегий адаптации, и хитрая система «спектральной локализации ошибок»… и все это тестировали даже на самсунговых системах управления производством.
«Умышленная безопасность»
Слайды, допматериалы, контакты для доклада «Умышленная безопасность»
оригинальное видео «Security by design» на английском
Требования и тенденции безопасности в проектировании и разработке программ, в том числе на корпоративном уровне. Как мы можем добиться безопасности и устойчивости ИТ-систем и сервисов в наших организациях.Формат «Дискуссионная панель» — немного сумбурная дискуссия четырех англоязычных докладчиков, с вопросами из зала.
Чего мы хотим:Как мы можем этого достичь:
- Точка зрения клиента и пользователя — можем ли мы создать безопасное ПО с «защитой от дурака»?
- Помогают ли современные требования и стандарты безопасности или они лишь создают новый тип уязвимостей, общий для всего ПО?
Сколько:
- Как разрабатывать безопасное ПО — принципы разработки, специальные утилиты, тестирование безопасности?
- Какие ключевые умения, связанные с безопасностью, должны требоваться от команды разработчиков?
- Что делать с наплывом «big data» в кибербезопасности — объединять и реагировать на информацию из многочисленных источников о нападениях и угрозах?
- Сколько стоит безопасность, и как сделать её стоимость доступной и контролируемой?
- Сравнение цены предотвращения с ценой исправления последствий
Софт сожрал весь мир, в безопасности ли мы? В загоне ли безопасность, на которую обращают внимание только после функциональных требований и юзабилити? Как просчитать баланс безопасности и юзабельности?
Да, вся эта область информационной безопасности полна «Черных Лебедей» с низкими вероятностями и страшными последствиями — что трудно честно посчитать. Все там контринтуитивно, фиг объяснишь и рядовым сотрудниками ценность регламентов написанных кровью, а начальству — ценность инвестиций в безопасность, особенно если менеджмент совсем эффективный, и не знает основ теорвера.
Что делать с легаси системами, в которых трудно прокачать безопасность, не меняя чуть более чем все? «цифровая безопасность… она часто бывает невидимой,
Автор доклада про адаптивные системы продвигал свои идеи о меньшей уязвимости динамических систем, доходя правда, до весьма странных идей, что мультистековые приложения (реализованные, условно, и под Linux, и под Windows, и под… — и запущенные параллельно) — менее уязвимы. С точки зрения надежности может оно и так, но вот уязвимостей там явно будет пропоррционально больше, если не думать про «security by obscurity and insanity». Были и другие упоротые идеи, например, «атаковать вирусы».
Много обсуждалась бесконечная гонка безопасности, от «сколько стоит добавить девятку к надежности?» до, а может ну нафиг, может достаточно тратить больше, чем соседа? (в духе интернационального анекдота «мне не нужно бежать быстрее чем тигр…»).
Отзывы-комментарии приветствуется, надеюсь, вы либо найдете в докладах что-то полезное, либо, если на ваш взгляд, все это некруто, то вы явно созрели для доклада — регистрируйтесь пожалуйста.
Профессионал из индустрии, исследователь из университета, сумрачный тьюринг из подпольного датацентра — конференция ждет вас.
Да, там кончились официальные сроки, но, по моему опыту участия в Программном Комитете, если вам есть что рассказать — доклад по сильной теме успеет пройти ревью.