Случайны выбор дневника Раскрыть/свернуть полный список возможностей
// // // // // //


Найдено 10012 сообщений
Cообщения с меткой

информационная безопасность - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Microsoft представила защитную технологию Windows Defender Application Guard для веб-браузера Edge

Среда, 28 Сентября 2016 г. 17:21 (ссылка)

Microsoft ранее уже анонсировала специальные защитные меры от вредоносного ПО и кибератак, которые основаны на механизме виртуализации Hyper-V. С выпуском Windows 10 компания представила так называемую среду Virtual Secure Mode (VSM) и две основанные на VSM защитные меры: Device Guard и Credential Guard (доступны для enterprise версий Windows 10). Основное их предназначение заключается в изоляции критических для безопасности операций в мини-ОС, которая работает в отдельной виртуальной машине с высоким уровнем доверия.







К таким критическим операциям относится проверка легитимности данных UEFI-прошивки компьютера, драйверов режима ядра (Device Guard) и выполнение процедур, которые относятся к аутентификации пользователей (Credential Guard). Новая функция безопасности под названием Windows Defender Application Guard для веб-браузера Edge выполняет аналогичную изоляцию на основе Hyper-V, но только, в этом случае, ненадежных источников контента в веб-браузере.



Ниже на рисунке представлена архитектура VSM, которая основана Hyper-V. Схожую архитектуру использует и App Guard.





Как видно выше, основная копия Windows 10 (хост) отделена от VSM изоляцией на уровне гипервизора. Схожий подход применяет и App Guard для Edge. Когда пользователь посещает недоверенный веб-сайт в браузере, он открывается не в контексте виртуальной машины хоста, а в другой, которая создана именно для таких потенциально опасных операций как просмотр контента на небезопасных веб-сайтах.



...when an employee browses to a site that is not recognized or trusted by the network administrator, Application Guard steps in to isolate the potential threat. Application Guard creates a new instance of Windows at the hardware layer, with an entirely separate copy of the kernel and the minimum Windows Platform Services required to run Microsoft Edge. The underlying hardware enforces that this separate copy of Windows has no access to the user’s normal operating environment.



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



Windows Defender Application Guard для веб-браузера Edge станет доступна пользователям копий Windows программы Insiders в ближайшие месяцы, а для пользователей релизных копий Windows 10 Enterprise в следующем году.



Windows Defender Application Guard for Microsoft Edge will become available to Windows Insiders in the coming months, and roll out more broadly next year.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/311242/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Как это было: раскрываем детали Droidcon Moscow 2016

Вторник, 27 Сентября 2016 г. 12:46 (ссылка)

22 сентября в Москве прошла третья ежегодная конференция Android-разработчиков Droidcon Moscow 2016. В Технополисе собрались более четырехсот жадных до знаний участников, Google Developer Expert’ов и представителей СМИ. Мы впервые присоединились к организации этой конференции в этом году. И вот наш отчет.







Деловая программа проходила в два потока и была разделена на четыре секции: Android, VR, IoT и Firebase. Секцию Android открыл Google Developer Expert Денис Неклюдов с докладом об адаптации приложений под новые возможности API 24 (Android 7.0 Nougat). Обсуждение жизненного цикла Activity в условиях MultiWindow перенеслось в Issue Tracker андроида, что привело к интересным результатам: оказалось, что вызов onStop не произойдет, если пользователь нажмет кнопку “Домой” во время работы с многооконными приложениями, а вот on Pause вызовется. Юрий Шмаков из Arello Mobile рассказал об их собственной библиотеке для реализации MVP. Тема жизненного цикла и проблем наследования от множества библиотечных базовых Activity вызвала бурный интерес у слушателей.







Затем Никита Слушкин, разработчик Aviasales.ru, рассказал о решении наболевшей проблемы предоставления скриншотов локализаторам – таким образом, чтобы они понимали контекст тех строк, которые переводят. Даниил Сердюков из Kaspersky Lab поделился личным опытом реализации архитектурного подхода MVVM с помощью DataBinding. Несмотря на комментарии участников о собственном негативном опыте, Даниил настоятельно рекомендовал использовать этот подход в Android. Завершил первую часть секции Android Дмитрий Школьников из компании Tapcore докладом о рынке пиратства мобильных приложений. В комментариях к выступлению слушатели активно генерировали варианты обхода пиратов, а также рассказали о личном опыте публикации бесплатной версии своей игры на пиратских ресурсах.



Каждый год конференция Droidcon Moscow собирает профессионалов в области мобильной и Android разработки. В этом году постарались в программу конференции включить как можно больше практических докладов и примеров использования технологий и решений Google в продакшне приложений.



Наталия Ефимцева, Региональный менеджер программ взаимодействия с разработчиками, Google Russia






Вторую часть секции Android открыла Наталия Кривенко, руководитель по международному развитию Apps4All, c презентацией программы, посвященной международным перспективам для разработчиков. Сначала Лютс Лайксенринг представил сообщество Jobreloaded от глобального Droidcon, которое соединяет Android-разработчиков по всему миру и помогает им построить карьеру на международном уровне. Далее Дмитрий Григорьев из Rubrain, международной freelance-платформы, рассказал о преимуществах и недостатках работы с иностранными заказчиками, а также дал несколько советов о том, как наладить процесс работы и сделать его наиболее продуктивным.



Александр Ефременков из Surf добрался до самых глубин Android и несмотря на то, что доклад был сложным, смог за 20 минут объяснить детали даже тем, кто подобными вещами ранее не увлекался. Слушатели прониклись его рассказом о sun.Misc.Unsafe и с пониманием задавали вопросы о применимости инструмента в продакшене, а также интересовались о практической полезности данного подхода. Опытный разработчик и молодой видеоблогер Александр Смирнов из Splyt рассказал о тонкостях создания хороших UI-компонентов и нюансах профилирования производительности их отрисовки в рантайме. Продолжили программу представители 1С – Петр Грибанов и Анна Лавринова, которые рассказали об интеграции мобильных приложений с их платформой. Дмитрий Провоторов из Мануфактуры в своем докладе продемонстрировал эффектные решения в рамках жестких ограничений Google Material Design. Слушатели с интересом смотрели на тщательно подобранные образцы приложений, сделанные с соблюдением стиля Material Design, но при этом воплощенного в виде UI, не просто строго по гайдлайнам, а «с душой» и креативностью. Закрыл масштабную секцию Android Александр Белов из SPB TV c докладом о существующих технологиях стриминга контента с Android-устройств, причинах выбора той или иной технологии стриминга и некоторых проблемах, с которыми сталкиваются разработчики подобных мультимедиа-приложений.



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



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



@nekdenis Денис Неклюдов, старший Android-разработчик Revolut, GDE








Секция VR стартовала с доклада «Проектирование для Google Cardboard» от Михаила Вайсмана из Trinity Digital, одного из лидеров GDG Москва. Михаил рассказал о том, как делать крутые приложения для Google Cardboard с точки зрения проектирования и применяемых технологий на примере разработанного Trinity Digital приложения Airpano Virtual Travel для Android. Затем Александр Коршак – программист и энтузиаст, лидер GDG Нижний Новгород и Android Team Lead в компании Mera, рассказал о разработке для Daydream. Докладчик поделился хаками и нюансами разработки для этой платформы. На этом Александр решил не останавливаться и поделился своим опытом в презентации «Сферическое видео — взгляд изнутри».



Секцию IoT открыл Google Developer Expert Звиад Кардава. Звиад не просто рассказал, но и продемонстрировал в режиме реального времени участникам, как с помощью двустороннего зеркала, любого планшета на Android, экрана и скотча сделать умное зеркало, которое сможет показывать время, дату, погоду, последние новости или даже вашу ленту в Twitter. Продолжил секцию невероятно харизматичный иностранный GDE Саша Вольтер из Deutsche Telekom. Он рассказал об IoT и продемонстрировал необычные примеры использования интернета вещей. Также Саша объяснил участникам, с чем связаны опасения многих относительно этой концепции и показал, что начать строить свои решения в области IoT и соединять самые разные умные вещи не так сложно. Свои слова Саша подкрепил лайв-кодингом и демонстрацией того, как можно взаимодействовать с реальными устройствами из Minecraft и наоборот.



Далее Алексей Витенко и Женя Рыжкин из AppMetrica рассказали об автоматизации тестирования SDK под Android. Первым в финальной секции Firebase выступил Тимур Ахметгареев из App in the Air и рассказал об одной из core-фич Firebase – Firebase Analytics, а также об её интеграции с Notifications Console и Remote Config. Тимур рассмотрел несколько интересных сценариев использования этой связки, а также пробежался по обновлениям компонентов, перешедших под крыло Firebase: App Indexing, App Invites, Test Lab. Программу продолжил Сергей Сметанин из Rubeacon с презентацией о том, как в его компании применяли Firebase Remote Config и Realtime Database, а также о результатах, которых достигли благодаря этому. В заключение секции и всей деловой программы выступил Алексей Милеев из App in the Air. Известно, что Firebase позиционируется в том числе и как альтернатива ушедшему в небытие Parse.com. Алексей мигрировал свой проект с Parse на Firebase и рассказал о различных подходах к миграции, а также о проблемах, связанных с ними.







That's All, Folks! Фото выложим на этой неделе в официальной встрече на Facebook, а видеозаписи докладов будут готовы примерно через две недели. Следите за новостями.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/311126/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Безопасность интернета вещей: прогресс, хайп и головная боль

Понедельник, 26 Сентября 2016 г. 19:57 (ссылка)

Интернет вещей — это такой же модный термин, как облачные технологии. Точно так же он не имеет особого смысла с технической точки зрения: это бренд, под которым спрятан миллион разных технологий и еще больше вариантов использования. Поводом для написания этого текста стали обсуждения новостей IoT в моих дайджестах: в разных случаях я получал справедливые и не очень упреки. Например, можно ли считать «вещами интернета» домашние роутеры, или распространяется ли IoT на производство и прочий индустриальный хайтек.



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



Источником информации о чудо-устройствах в этой статье является твиттер Internet of Shit — его автор уже год занимается отважной работой по разоблачению попыток разных производителей направить развитие вещей интернета в направлении полного провала. Впрочем, лучше воспринимать этот канал как современную техносатиру: пока мы ржем над 100500-м чайником с фейсбуком внутри, реальный IoT приходит к нам незаметно, и без спроса. В этом-то и заключается настоящая проблема.



В умном доме что-то пошло не так

Пожалуй главной новостью в контексте «интернета вещей» в этом году стало выключение хаба для умного дома Revolv. Разработанное одноименным стартапом, устройство поступило в продажу в 2013 году. Уже в 2014-м продажи были прекращены после того, как вендора выкупила Nest, входящая в конгломерат гуглокомпаний Alphabet. Проданные устройства поддерживались вендором, но 15 мая этого года по решению Nest буквально превратились в тыкву.







Относительно немногочисленные владельцы Revolv Smart Home Solution были в ярости, и это еще мягко сказано. Внимание СМИ привлекли как цветистые проклятия в сторону модного вендора умных решений, так и общие проблемы любых умных устройств. Дело даже не в том, что владельцы устройства лишились поддержки вендора и обновлений. Устройства просто перестали работать. Вообще. Совсем, так как выключили обязательную связь с инфраструктурой. Взамен вендор предложил полностью вернуть деньги, потраченные на устройство (300 долларов), но по сравнению с реальной ценой всей системы умного дома, в котором главное управляющее устройство вдруг перестало работать, это копейки.



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



Это выгодно отличало данную модель от конкурентов, которые работали с жестко заданным списком устройств. В идеальном мире это гарантировало возможность расширения умного дома с помощью новых устройств, даже если ранее поддерживаемые исчезали из продажи. Увы, разработчики не предусмотрели вероятность отключения собственной инфраструктуры. А зря. Это очень напоминает мне историю с отключением серверов поддержки Maemo — удачной, но не пережившей бизнес-турбулентность мобильной платформы Nokia. В том случае правда все обошлось: энтузиасты Nokia N900, более ранних и поздних устройств, собрали средства и перенесли серверы обновлений и раздачи софта на независимую площадку.



Попытки определиться с терминами

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



Это совокупность цифровых устройств, которые:

— Обмениваются данными по локальной беспроводной сети и/или через интернет.

— Работают автономно, зачастую круглосуточно, без регулярного взаимодействия с человеком (а то и вовсе без такового).



Мне кажется, дальнейшие уточнения избыточны и не нужны (ожидаю, что этот момент станет дискуссионным — что ж, велкам в комментарии). Фоторамка, зачем-то постоянная подключенная к сети через WiFi — это Internet of Things. Умный термостат и чайник — это оно. Телевизор со скайпом — да. Весы с твиттером, добавьте их в друзья. Беспроводные счетчики воды. Контроллеры солнечных батарей. Свечка с автоподжигом через смартфон.



World's first - and hopefully fucking last- smart candle pic.twitter.com/6KLqMvz95K

— Internet of Shit (@internetofshit) September 21, 2016



Серьезно, свечка!



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



Безопасность IoT

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



CONFIG_*******_ROOT_PASSWORD=«sVGhNBRNyE57»



CONFIG_*******_ROOT_PASSWORD=«GFg7n0MfELfL»


Типичная (уже закрытая) уязвимость в IP-камере.



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



INBOX: Vibrating navigation belt pic.twitter.com/sF8gSvf1i9

— James Cook (@JamesLiamCook) September 21, 2016





С практикой все интереснее. Теслу и чайники пока никто не ломает ввиду их малочисленности: пока не набрана критическая масса устройств, открывающая неминуемый интерес со стороны киберпреступников. Отслеживать и анализировать точечные атаки, даже если они происходят, крайне сложно и для обычных компьютеров, а тут подавно. Тем не менее, примеры есть, но относятся они к устройствам, которые не все согласны причислять к IoT — это роутеры, IP-веб-камеры и умные телеприставки. Повторюсь, в предложенной модели причисления устройств к IoT с точки зрения безопасности эти девайсы, доступные уже многие годы, законно занимают почетное место.



Так вот, эти знакомые и понятные устройства наглядно демонстрируют ситуацию с безопасностью в IoT в целом. Дефолтные пароли, доступные снаружи интерфейсы управления с типичными веб-уязвимостями, не говоря уж о некоторых примерах дыр, позволяющих выполнять произвольный код. Результат понятен: десятки, а то и сотни тысяч постоянно включенных в сеть и никак не управляемых владельцами устройств объединены в ботнет, использующийся для DDoS-атак и других криминальных активностей, не говоря уж о краже приватной информации. В конце прошлой недели произошла одна из крупнейших DDoS-атак (целью стал блог эксперта Брайана Кребса) — 665 гигабит в секунду. Если предварительная оценка компании Akamai (которая так и не смогла отразить атаку) подтвердится, это будет заодно и крупнейшая атака ботнетом из IoT-устройств.



Светлое Мрачное Неизбежное будущее

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



what could possibly go wrong with a face computer that records everything to snapchat pic.twitter.com/kciD5RsTWs

— Internet of Shit (@internetofshit) September 24, 2016



Казалось бы, что может пойти не так с компьютером в очках, который отправляет все в Snapchat?



Уязвимость, и, хуже того, невозможность обновления миллиардов устройств приведет к массе проблем, которые могут затронуть как ничего не подозревающих пользователей, так и повлиять на работоспособность критически важной инфраструктуры. Аргумент, что в индустриальных системах другой IoT мне не кажется надежным: во-первых рост объемов производства приведет к консьюмеризации, во-вторых — критерии автономной работы и сетевого подключения сохраняются и в этом случае, уже сейчас.



Какие подходы могут быть использованы для защиты? Пример устройства Revolv намекает на то, что рынок рано или поздно придет к двум-трем основным платформам, на которых будут строиться все IoT-системы, и хаоса станет меньше. Скорее всего так и будет, как это уже произошло с количеством платформ для смартфонов в конце нулевых или операционных систем для ПК в 90-х годах прошлого века. А если нет? Концепция безопасности вряд ли должна строиться исходя из законов рынка.



Предположу, что нынешняя концепция «в интернете никто не знает, что ты кофеварка» должна измениться. К интернету вещей должно быть иное отношение, чем к десктопу и смартфону, что сейчас не всегда выполняется. Отдельные, защищенные каналы связи, собственные надежные методы авторизации, и главное — использование технологий, максимально снижающих вероятность выполнения чужого кода. Не исключено, что это не вещи интернета придется защищать от злодеев, а проще будет защитить смартфоны и компьютеры от интернета вещей — там подходы понятнее. Наконец, так как, на 100% неуязвимых сложных систем не бывает, проблему быстрого и надежного обновления миллиардов устройств все-таки придется решить.



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



Disclaimer: Данная колонка основана на реальных событиях, но все еще отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
Original source: habrahabr.ru.

https://habrahabr.ru/post/311076/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
chooser

Власти идут на перехват

Понедельник, 26 Сентября 2016 г. 17:50 (ссылка)



Власти идут на перехват







 





Расшифровка и анализ всего





интернет-трафика россиян действительно обсуждается органами власти, подтвердила член рабочей группы при администрации президента Наталья Касперская. Вопрос лоббируют ФСБ и Роскомнадзор, чтобы решить проблему с «неподконтрольной» России частью интернета. Для российских интернет-сервисов дешифровка может обернуться репутационными рисками.




Вопрос перехвата и расшифровки интернет-трафика россиян, а затем его шифрования с помощью SSL-сертификата российского удостоверяющего центра (УЦ) поднимался органами власти, подтвердила гендиректор InfoWatch и член рабочей группы «ИТ + Суверенитет» при администрации президента Наталья Касперская.


«Тема передачи SSL-сертификата органам власти всплывала, лоббируют ее Роскомнадзор и ФСБ, которым это нужно. И это требование передачи сертификата — абсолютно правильная вещь, потому что сейчас у нас есть кусок интернета, который совершенно неподконтролен собственной стране, это неправильно», — сообщила госпожа Касперская в ходе конференции BIS Summit 2016 в ответ на вопрос «Ъ».





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




В Роскомнадзоре не прокомментировали эту информацию, в ФСБ не ответили на запрос «Ъ».




Как ранее сообщал «Ъ», сейчас ФСБ совместно с Минкомсвязью и Минпромторгом обсуждают не только вопросы снятия данных с сетей связи и их хранения согласно подписанному в июле «антитеррористическому закону» Ирины Яровой и Виктора Озерова, но и расшифровки и анализа всего интернет-трафика россиян.


Двое собеседников «Ъ» утверждают, что один из обсуждаемых вариантов дешифровки — установка на сетях операторов оборудования, способного выполнять MITM-атаку, то есть перехватывать и расшифровывать трафик от сервера, к которому обращался пользователь, и заново зашифровывать его SSL-сертификатом, выданным российским УЦ, перед отправкой пользователю.


Расшифрованный трафик намерены анализировать по ключевым словам, например «бомба», с помощью систем Deep Packet Inspection (DPI).




Роскомнадзор поднимал тему расшифровки трафика еще до «закона Яровой». Глава ведомства Александр Жаров ранее заявлял, что еще в феврале 2016 года возглавил созданную по поручению Совета безопасности РФ рабочую группу по обсуждению вопросов регулирования шифрованного трафика при Национальном антитеррористическом комитете, в состав которой вошли представители профильных министерств и силовых структур.


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


Двое собеседников «Ъ» на IT-рынке отмечают, что именно в рамках этой структуры и мог быть написан сам «закон Яровой», обязывающий владельцев интернет-площадок с возможностью переписки сдавать ключи шифрования по требованию ФСБ, а также с 1 июля 2018 года хранить все голосовые записи и интернет-трафик россиян до полугода.



Схема дешифровки трафика с помощью MITM и его анализа посредством DPI несет риски и пока сложно поддается финансовым оценкам, отмечает замдиректора по развитию бизнеса Positive Technologies в России Алексей Качалин.


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


«Крупные


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

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Безопасность Android-приложений. Лекция в Яндексе

Воскресенье, 25 Сентября 2016 г. 16:55 (ссылка)

Разработчик Дмитрий Лукьяненко, чью лекцию мы публикуем сегодня, не только является специалистом Яндекса, но и умеет проверять на прочность решения разработчиков других компаний. Это позволяет учиться на чужих ошибках — не исключая порой своих, конечно. В докладе Дмитрий поделится примерами Android-уязвимостей, в том числе найденных им собственноручно. Каждый пример сопровождается рекомендациями — как нужно и как не нужно писать приложения под Android.









Меня зовут Дмитрий, я работаю в компании Яндекс в минском офисе, занимаюсь разработкой аккаунт-менеджера. Это библиотека, которая отвечает за авторизацию пользователей. Поэтому мы поговорим о безопасности Android-приложений.



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



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



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







Этот доклад будет полезен тем, кто занимается Android-разработкой. Я бы советовал уделить внимание этим аспектам всем, кто делает приложения. Например, тестировщикам. Тестировщики, мне кажется, если посмотрят эти нюансы, смогут какие-то премии выбивать, они начнут более глубоко вникать в разработку, даже программировать можно особо не учиться. Manifest-файл просто смогут анализировать и выявлять потенциально опасные места. И всем остальным, кто интересуется такими вопросами безопасности.







Прежде чем начнем, стоит упомянуть софт, который может пригодиться. В первую очередь BytecodeViewer, очень полезная программка, позволяет одним кликом получить из apk-файла все исходники, все ресурсы, в том числе manifest-файл.







Стоит отметить удобную утилиту для Android — ManifestViewer. Она позоляет очень быстро просматривать manifest-файлы всех установленных приложений. Я её использую по работе, например, когда ко мне приходят и говорят: аккаунт-менеджер не работает, что такое? В первую очередь всегда смотрю manifest-файл, чтобы убедиться, что аккаунт-менеджер был правильно интегрирован, то есть что все его компоненты объявлены как надо.

Эта программка полезна, чтобы вы на скорую руку открыли и посмотрели точки входа, вектор атак из manifest-файла.



Если вы любите всё делать из консоли, вот вам все эти программы отдельно. apktool позволяет выдернуть все ресурсы и manifest-файл. Dex2jar и enjarify позволяют конвертировать apk-файл в jar. Dex2jar может какие-то apk не конвертнуть, выдать с каким-то исключением. Не отчаивайтесь: часто такие файлы скушает enjarify, и вы получите jar. Это две хороших утилиты.



После того, как у вас есть jar-файлы, вы можете взять Java Decompiler и сконвертировать их в более удобный вид — в вид классов. Понятно, что их нельзя будет запустить, но анализировать их гораздо проще, чем код, который там получается, и т. п.







Давайте рассмотрим самые базовые проблемы. Во-первых, сначала нам нужно проанализировать manifest-файл, потому что в нем обязательно должны быть описаны все компоненты Android-приложения. Это Activity, Service, Broadcast Receiver, ContentProvider. Все они, за исключением Broadcast Reciever, обязательно должны там находиться.



Поэтому когда мы начинаем поиск каких-то проблем, мы смотрим эти компоненты. Вот конкретный пример. Это сервис, который был объявлен в manifest-файле одного приложения, он явно экспортируется. В нем даже явно указано, что он экспортирован. Это означает, что он доступен любому другому стороннему приложению. Любое другое приложение, в свою очередь, может послать в этот сервис интент, и сервис может выполнить какие-то действия, если они там предусмотрены.



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



Ещё один момент: когда у нас какая-то компонента использует интент-фильтры, то по умолчанию она тоже становится экспортируемой. Тут, возможно, начинающие разработчики могут споткнуться. Если интент-фильтр есть, то всё, эта компонента уже публичная. Тут стоит быть внимательным.



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







Что делало это событие? Оно обрабатывалось при помощи публичного BroadcastReciever. То есть злоумышленник тоже мог послать любой бродкаст — подобрать ID письма и, допустим, удалить его. Причем необязательно, чтобы это было сообщение в панели.



Когда-то давно в Яндекс.Почте была такая уязвимость. Уже всё поправили, так что можно пользоваться, всё отлично. Спасибо Ильдару, они оперативно всё это делают.







Как это решилось? Компоненту просто сделали недоступной извне, поставили ещё permission дополнительно. Его можно было и не ставить, главное — если она не экспортируется, значит, уже никто не сможет к ней подключиться и что-то выполнить.







Следующий вид проблем — использование неявных интентов, когда в интенте не задается конкретное место, в которое он должен прийти. Это означает, что у вас нет гарантии, что этот интент придет туда, куда вы хотите. Он может прийти куда-то ещё. Поэтому тут надо быть внимательным.



Ещё нюанс, который я отнес бы к неявным интентам, — это Browsable Activity, когда у нас из браузера можно открыть Activity стороннего приложения. Это происходит, когда задана какая-то схема, хост, там кликают и у вас открывается окно. Хорошо, когда просто открылось окно и например, передалась позиция на карте. Это не страшно. А страшно — следующее. Допустим, у нас некоторые ребята предлагают использовать Slack в компании. В Slack очень интересная авторизация. Если вы авторизовались в браузере на Android, то вы можете авторизоваться и в установленном приложении Slack. Это работает по такой схеме, когда в браузере есть URL, вы по нему кликаете и его перехватывает приложение Slack.







Но здесь нет гарантии, что URL не перехватит кто-то другой, причем по нему передается токен. Схема достаточно простая: когда вы кликаете в браузере, вас сразу авторизовывают в приложении Slack. Значит, этого URL достаточно для авторизации.







Здесь отмечены кнопки, которые можно кликать в браузере и которые инициируют это открытие. Это не только «Открыть Slack», но и логотип — он всегда находится сверху, на любом экране.



Давайте посмотрим видео, которое демонстрирует использование этой проблемы. Мы авторизовались, зашли в свою директорию, нажали на логотип Slack — но приложения Slack у нас нет, у нас злоумышленник подставил интент-фильтр. Вернулись, нажали… Можно фишинг сделать — точно такой же по внешнему виду, как Slack. Написать, что авторизация не сработала и всё такое. Пользователь ничего не поймет, а токен окажется у вас. Поэтому если пользуйтесь Slack, то будьте внимательны с этой браузерной авторизацией.







Решение очень простое. Как говорил мой коллега, можно использовать явные интенты, которые открываются из браузера. Но когда я в Slack зарепортил и мой тикет получил номер 80000 с чем-то, они сказали, что это дубликат и что уже есть тикет 50000-какой-то. Если прикинуть, получится, что им это больше чем полгода назад сообщили. Исправляется вроде достаточно просто, но — не исправили. Значит, это не критичная проблема и можно тогда о ней рассказать.



Здесь есть рекомендация, что лучше всегда использовать явный интент. Если вы почитаете и вникнете более глубоко, то узнаете, что у Android была прикольная опечатка. Они в одном месте использовали неявный pending intent. Из-за этого можно было получить доступ к пользователю с правами system. Они эти ошибки исправили в Android 5. Такие ошибки у всех бывают, даже у Google.



Всегда лучше использовать явный интент или, если это невозможно, всегда задавать какой-то permission. Он позволяет ограничить доступ.



Рассмотрим другой вид уязвимостей — основанный на пользовательских данных.







У нас есть приложения, которые могут получить какие-то данные от пользователей, например отправить какой-то файл, открыть его, просмотреть. Это обычно осуществляется при помощи интентов типа view и send.



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



Можно взять getAbsolutePath() и проверить, совпадает ли директория с вашей приватной. Но это неправильно.







Вам злоумышленник может прислать не сам файл, а ссылку на него.



Как может создаваться эта ссылка? У злоумышленника создается readme.txt — он сделал ссылку на приватный файл вашего приложения. Затем он запихнул эту ссылку вам, и если вы будете использовать getAbsolutePath(), то вам вернётся путь ссылки — путь к файлу readme.txt. А вы подумаете, что всё нормально.



Чтобы это исправить, лучше использовать метод getCanonicalPath(). Он возвращает полный путь, самый настоящий. В данном случае система вернет не readme.txt, а какой-нибудь mailbox. Учитывайте эти проблемы.



Я сталкивался с ситуацией, когда подобная проблема была у одного приложения более чем с 50 млн пользователей. Говоришь: покажите мне этот файл. Они его кешируют на SD-карту и потом пытаются открыть. Так можно было все токены украсть. Они уже всё исправили, но попросили пока не разглашать. Тем не менее, такое встречается.



Следующий интересный момент: вам могут прислать ссылку на content provider, и он тоже может быть передан. Даже если он защищен через permission, даже если он не экспортируемый, то всё равно — когда ваше приложение попытается его открыть, выполнится метод query, который есть в content provider.



Тут надо быть осторожным. Вот ещё один реальный пример, уже из другого приложения. Они делали бэкап БД из метода query. Туда можно было передать action типа backup и программа сразу дублировала всю БД на SD-карту. Получается, вроде провайдер защищен, но его можно так подсунуть, чтобы получить в итоге всю БД.











Я больше нигде не встречал, чтобы кто-то делал запись в методе query, но там всегда лучше открывать что-то для чтения. А ещё — учитывать, что там может быть SQL-инъекция. Сейчас есть ряд приложений, в которых я обнаружил возможность SQL-инъекции. Однако доступы у них только для чтения, и я пока не понял, можно ли там дальше что-то сделать. Но вдруг найдется уязвимость в самой БД SQLite, которая позволит выполнить уже не настолько безобидную инъекцию? Всё-таки лучше их не допускать, даже если если при открытии есть доступ только для чтения.







Теперь давайте рассмотрим одну проблему с WebView, причем срабатывает она во всех Android до версии 5.0 и позволяет обойти SOP. Из этого мы сделаем вывод, что в WebView лучше никому не давать открывать свои файлы.







Рассмотрим этот вид атаки. Зловредное приложение может попросить ваше приложение, если оно имеет доступы к WebView: покажи мне файлик index.html. Предположим, ваше приложение открыло index.html. Содержимое файлика очень простое — JavaScript, который через 5 секунд сам файлик, самого себя, загружает в iframe, перезагружает как бы.







В этот период времени зловредное приложение указанный файлик удаляет и заменяет на символическую ссылку на приватный файл из вашего приложения. Проходит 5 секунд, оно перезагружается, но контент в нём уже становится контентом того самого приватного файла. На Android до 5.0 ещё до WebView, видимо, стоит неправильная проверка на то, что это символическая ссылка. Таким образом можно прочитать контент. Оно смотрит — имена файлов совпадают, значит SOP не нарушена, контент можно отдать и значит, JavaScript может взять контент и отправить его на сервер.







Такой вид атаки встречается не только в WebView. Он до сих пор работает в UCBrowser, у которого больше 100 млн установок. Я встречал такое и на некоторых версиях Android-браузера, до Android 5.0. Наверное, он тоже на WebView построен. Например, на телефонах Samsung у меня такое не получилось воспроизвести, а на моем телефоне Acer срабатывает.







Глянем небольшое видео о том, как это работает в UCBrowser. Речь о небольшом зловредном приложение, но оно может сработать. Вы легли спать, телефон тоже, внезапно запускается activity, страничка. Вы спите, а там запустилось — какой-то iframe, подтверждение, алерт. Если алерт прочитал контент, значит, мы точно так же могли отправить этот контент куда угодно. Это bookmark.db, тут хранятся закладки. Думаю, кому интересно — может поисследовать. Возможно, удастся найти там более приватные пользовательские данные. Можно и куки украсть. Но куки у них названы по имени сайта, поэтому надо перебирать. ВКонтакте можно взять. Уязвимость до сих пор есть, вроде пока ещё не исправили и не спешат исправлять.











Вывод: если у вас есть WebView, то не давайте никому открывать в нём свои ссылки. А если всё-таки даёте, то хотя бы запретите открытие локальных файлов. В этом плане большие молодцы компания Qiwi, я их приложение пробовал, обрадовался, что сейчас открою файлик — ан нет, они запретили открывать локальные файлы и ничего не сделаешь.



Рассмотрим следующий вид нетривиальной проблемы. Она основана на особенностях десериализации в Android. Возможно разработчикам самой Java может быть полезно.



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



Есть в Android до 5.0 такой бонус: на некоторых версиях при десериализации не проверяется, что класс действительно имплементирует интерфейс сериализации.



Это означает, что все классы, которые есть в вашем приложении, могут быть уязвимы. Да, они могут быть не сериализуемы, но если они подойдут под критерий, который будет описан дальше…







Итак, что тут опасного? Если объект был создан, он когда-нибудь будет удален. Обычно в том, что метод finalize вызовется, нет ничего опасного, ничего не реализуется. Однако когда есть нативная разработка, то обычно в методе finalize вызывают деструктор из нативной области и передают туда указатель. Я нативной разработкой не занимался, но поизучал, как туда передаются указатели. Если данный указатель сериализуется, то злоумышленник может подставить свой, а он, в свою очередь, может как вызвать ошибку выхода за границы памяти, так и указать на другую память, которая потом возьмет и выполнит какой-то код.







Этим воспользовались ребята из компании IBM. Они проанализировали весь список классов на платформе Android — проверили больше тысячи или сколько их там. И нашли всего один, который удовлетворял критериям: он был сериализуемый, и он сериализовал native-указатель. Они взяли этот класс, подставили свой указатель, он сериализовался и десериализовался. Он был новым не каждый раз. Сделали proof of concept, демонстрацию, есть видео. Эта уязвимость позволила им при помощи этого класса заслать интент в системное приложение. Оно позволило им, допустим, удалить оригинальное приложение Facebook и заменить его на фейковое. Видео длится минут 7. Там приходится повертеть — пока finalize вызовется, пока очистится память. Но вывод — никогда не надо десериализовывать нативный указатель.







Подытожим. Лучше никогда не экспортировать компоненты, которые есть в вашем приложении. Либо — ограничивать доступ по permission. Интенты всегда лучше использовать явные, либо permission задать. Никогда не доверяйте тем данным, которые придут от пользователя — это могут данные на что угодно, даже на ваши приватные области. Вы их потом можете повредить. Внимательно отнеситесь к ContentProvider, в том числе к SQL-инъекции и т. п.



Такая штука, как WebView, — она вообще не для игрушек. Если она есть в вашем приложении, закройте её и никому не давайте с ней играться.



Сериализация, а точнее, нативная разработка — это тоже как спички, будьте с ней поосторожнее. Спасибо за внимание.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/310926/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Драйвер компьютерной игры Street Fighter V отключает встроенный механизм защиты Windows

Воскресенье, 25 Сентября 2016 г. 12:26 (ссылка)

Драйверы компьютерных игр, которые используются для защиты целостности файлов игры, а также легитимности данных игроков не являются редкостью. Ранее публиковалось несколько обзоров наиболее известных подобных драйверов, например, nProtect GameGuard и Blizzard Lockdown. Такие драйверы могут использовать в своих целях перехваты API-вызовов на уровне ядра Windows, постоянное сканирование виртуального адресного пространства процессов, отслеживание доступа операций к системному реестру и др.







Несколько дней назад компания Capcom уведомила своих пользователей об обновлении anti-hack драйвера (Capcom.sys), который используется для контроля за целостностью файлов игры и предотвращает возможную компрометацию содержимого памяти процесса игры с целью предотвращения читерства. Однако, пользователей в этом обновлении ждал неприятный сюрприз в одной из функций драйвера. Она позволяет отключать защитную меру ядра SMEP и исполнять код по указателю, полученному из пользовательского режима.



SMEP (Supervisor Mode Execution Prevention) уже является довольно известной мерой, о которой было написано несколько обзоров. Она требует поддержки как со стороны микропроцессора, так и со стороны ОС (Windows 8+). SMEP используется для блокирования операции исполнения кода пользовательского режима (Ring 3) в режиме ядра (RIng 0). Как бы это не выглядело странно (код режима ядра является самым привилегированным и имеет возможность доступа ко всей памяти в системе), SMEP является хорошей мерой для блокирования активности LPE-эксплойтов, которые часто передают управление на блок кода, расположенный в пользовательской части виртуального адресного пространства.



Драйверы Windows организованы таким образом, что для взаимодействия с клиентом из Ring 3, используется специальный интерфейс под названием IOCTL. Драйвер регистрирует специальный обработчик в ядре Windows, который может быть использован из пользовательского режима известной API-функцией DeviceIoControl. Приложение при использовании этого API передает драйверу код требуемой функции, набор аргументов и указывает входной, а также выходной буферы памяти для передачи аргументов и получения результата.



Новое обновление Capcom.sys использует интерфейс IOCTL и две функции с кодами 0xAA012044, 0xAA013044. Особенность этих функций заключается в том, что они позволяют клиенту пользовательского режима исполнить код в режиме ядра по указателю, полученному оттуда, причем перед этим отключает SMEP. После исполнения функции SMEP включается обратно установкой соответствующего бита регистра CR4. Очевидно, что отключение используется для исполнения кода в режиме ядра из пользовательского режима.





Рис. Функция Capcom.sys, которая исполняет указанную в IOCTL-запросе функцию с отключенным SMEP.



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



Компания Capcom уже выпустила обновление игры, закрывающее данную уязвимость.



We are in the process of rolling back the security measures added to the PC version of Street Fighter V. After the rollback process to the PC version, all new content from the September update will still be available to players. We apologize for the inconvenience and will have an update on the time-frame for the PC rollback solution soon.

Original source: habrahabr.ru.

https://habrahabr.ru/post/310950/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

После крупнейшей кражи данных в истории на Yahoo! обрушились еще «33 несчастья»

Воскресенье, 25 Сентября 2016 г. 12:07 (ссылка)





22 сентября 2016 года компания Yahoo признала, что персональные данные ее пользователей были похищены. Речь идет о краже данных не менее 500 миллионов аккаунтов.



Это произошло еще в 2014 году, но факт был признан компанией только сейчас. Yahoo! обнаружила этот взлом после того, как в августе получила информацию о другой атаке, которая оказалась ложной.



Объем похищенных данных превышает объемы, украденные с серверов других электронных компаний – таких как MySpace.

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



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



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



В августе хакер по прозвищу Peace выставил на продажу базу с данными о 200 миллионах пользователях Yahoo со стоимостью $1,8 тысячи. Хакер утверждал, что к нему попали данные более чем со 100 миллинов страниц, пишет издание Motherboard.

Известно, что «Peace» – общий псевдоним людей, которые также занимались и продажей украденных данных MySpace и LinkedIn.
Житель Нью-Йорка Рональд Шварц подал иск против Yahoo! в федеральный суд Сан Хосе (Калифорния) от имени всех пользователей США. Возможная компенсация, которую могут назначить в случае победы Шварца, пока не определена.



Истец предполагает, что Yahoo могла предотвратить нарушения, но воспринимала необходимость защиты данных недостаточно серьезно. Еще одна претензия касается выявления факта и расследования обстоятельств взлома. На это было потрачено в 3 раза больше времени, чем необходимо по правилам.



Yahoo продемонстрировала «пренебрежение к безопасности к персональным данным своих пользователей, которые обещала защищать», говорится в исковом заявлении. Судебные иски были поданы также в суды штатов Иллинойс и Сан-Диего.



Как отметил глава департамента интернет-компании, получить доступ к закрытыми данным смог хакер, чьи действия спонсировало «правительство государства». «Онлайн-вторжения и кражи при поддержке государства становятся все более распространенным явлением в техиндустрии», — сетуют в Yahoo.



По мнению руководства компании Yahoo, ко взлому системы в 2014 году были причастны хакеры из России, рассказал источник The Wall Street Journal, знакомый с ситуацией. Предполагается, их целью были около 30 аккаунтов конкретных людей, которые ведут бизнес в России.



Ранее компания не называла страну, из которой была организована атака. В то же время собеседник издания не уверен, что действия именно этих хакеров привели к утечке данных 500 миллионов пользователей.







У Yahoo! сейчас и так непростой период: в июле она согласилась продать интернет-подразделение оператору Verizon Communications за $4,83 миллиарда. По мнению аналитика SunTrust Robinson Humphrey Роберта Пека, скорее всего, информация о взломе не заставит Verizon отказаться от сделки, но покупатель может попросить скидку на $100 миллионов, или даже $200 миллионов. Размер скидки будет зависеть от того, сколько пользователей откажутся от услуг Yahoo.



Юрист K&L Gates Стивен Капони считает, что условия сделки и принятая практика позволяют покупателю отказаться от нее, если цена актива значительно снизится, но такие случаи довольно редки.



«Если изменения будут существенными, у Verizon будет возможность начать переговоры об изменении условий сделки или вовсе от нее отказаться. Оценить изменение ценности актива можно будет по тому, какая именно информация была украдена», — сказал он.



Представители Verizon заявили, что информацию об атаке они оценят в соответствии с собственными интересами.



На сайте delfi.lv опубликовано несколько советов пользователям украденных аккаунтов.



Измените пароли и секретные вопросы



Если вы все еще пользуетесь почтой Yahoo или закачали во Flickr фото, которые не хочется потерять — измените в них пароли и секретные вопросы. Сделать это можно буквально за пять минут.


Вспомните, не использовали ли вы эти пароли и вопросы где-то еще



Если злоумышленники взломают пароли (или уже взломали) Yahoo, то они обязательно «прогонят» в автоматическом режиме пары из логина-пароля через все остальные популярные сервисы — социальные сети, Gmail, и так далее.



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


Включите двухфакторную идентификацию



С двухфакторной аутентификацией вы можете чувствовать себя спокойно даже в том случае, если у вас стоит пароль «12345» (мы, впрочем, все же рекомендуем пароль «12354» — просто чтобы потролить хакеров).



Двухфакторную идентификацию поддерживают почти все, кому не лень, включая Google, Facebook, Twitter и так далее. Найдите и включите ее везде, где только можно — и все эти гигантские утечки паролей перестанут вас волновать.

Original source: habrahabr.ru.

https://habrahabr.ru/post/310944/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Функциональная безопасность, Часть 3 из 3. МЭК 61508: Систематичная случайность или случайная систематичность?

Пятница, 23 Сентября 2016 г. 19:22 (ссылка)

Безопасности на Хабре посвящен целый хаб, и, пожалуй, никто особенно не задумывается, что именно вкладывается в понятие «безопасность», и так все ясно: информационная безопасность (security). Однако, есть еще и другая сторона безопасности, safety, связанная с рисками для здоровья и жизни людей, а также окружающей среды. Поскольку информационные технологии сами по себе опасности не представляют, то обычно говорят о функциональной составляющей, то есть о безопасности, связанной с правильным функционированием компьютерной системы. Если информационная безопасность стала критична с появлением интернета, то функциональная безопасность рассматривалась и до появления цифрового управления, ведь аварии происходили всегда.



Данная статья продолжает серию публикаций на тему функциональной безопасности.



Во вводной части 1:



— обоснована важность оценивания и обеспечения функциональной безопасности для компьютерных систем управления;

— рассмотрены архитектуры систем, для которых необходимо оценивать и обеспечивать функциональную безопасность; к таким системам относятся АСУ ТП (Industrial Control Systems) на базе программируемых логических контроллеров (ПЛК), встроенные системы (Embedded Systems) и уровень устройств (Device Layer) для интернета вещей;

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



В части 2 рассмотрена общая структура стандарта МЭК 61508 «Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью» (IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems) и используемая в нем терминология.



Описание достаточно непростой терминологической казуистики заняло целую статью, и теперь пора разобраться со структурой требований МЭК 61508.



Не рекомендуется к прочтению тем, кто не интересуется стандартизацией.



Как разобраться в структуре требований МЭК 61508?



Итак, взглянем еще раз на структуру и взаимосвязи между всеми семью частями МЭК 61508 (это повтор рисунка из части 2 публикации). Сейчас для нас важно то, что непосредственно требования содержатся в первых трех частях, а остальные четыре части носят справочный характер.





Рисунок 1. Overall framework of the IEC 61508 series (IEC 61508, Figure 1)



Давайте подумаем, на основе чего можно анализировать требования, чтобы разложить их «по полочкам»? Нужна классификация (таксономия), а где ее взять? Для начала можно взглянуть на содержание стандарта.



Действительно, части МЭК 61508-1,2,3 имеют типовое содержание, поскольку во всех трех частях:



— в разделе 5 изложены требования к документации;

— в разделе 6 приведены требования к управлению функциональной безопасностью;

— в разделе 7 описана структура жизненного цикла;

— в разделе 8 изложены требования к оцениванию функциональной безопасности.



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



1) случайные отказы аппаратных средств, для которых можно определить вероятность возникновения;

2) систематические отказы вызванные ошибками проектирования.



Для обозначения способности противостоять первым и вторым введены специальные термины: Random Capability & Systematic Capability (стойкость к случайным и систематическим отказам). По поводу Random Capability понятно, что надо защищать систему от случайных отказов (например, методами резервирования, устойчивости к помехам и другим экстремальным воздействиям и т.п.). Systematic Capability зависит, как от реализации процессов разработки, так и от механизмов защиты от отказов, и включает в себя:



— управление функциональной безопасностью (Functional Safety Management);

— реализацию жизненного цикла функциональной безопасности (Functional Safety Life Cycle);

— защиту от систематических отказов проектирования системы и аппаратных средств (Systematic Failures Avoidance);

— защиту от систематических отказов проектирования программного обеспечения (Software Failures Avoidance).



Кроме того, необходимо выполнять оценку функциональной безопасности (Functional Safety Assessment) путем определения соответствия продуктов (оборудования, программного обеспечения и документации) и процессов разработки продуктов указанным выше требованиям.



Такая вот структура требований к функциональной безопасности приведена на рисунке ниже, и именно такую структуру предлагается использовать при анализе требований отдельных частей МЭК 61508. Дальше в статье поочередно проводится краткий разбор содержания каждой из частей МЭК 61508, представленных в виде Mind Map.





Рисунок 2. Структура требований МЭК 61508



МЭК 61508-1, Общие требования



Первая часть, МЭК 61508-1, задает тон всему стандарту. Некоторая сложность для понимания состоит в том, что эта часть во многом описывает уровень объекта контроля и управления, не очень привычный для IT-специалистов. Здесь подход даже шире, чем уровень АСУ ТП, и гораздо шире, чем уровень контроллера и софта. Что с этим делать? Выбирать только те требования, которые относятся непосредственно к разрабатываемой или оцениваемой системе.





Рисунок 3. Содержание МЭК 61508-1



Здесь и далее на Mind Map разделы и приложения размечены снизу ярлыками, которые указывают на то, какой группе требований соответствует тот или иной раздел или приложение. Кроме того, на Mind Map создана ветвь Important, подчеркивающая важные таблицы и рисунки, которые без этого «теряются» в тексте стандарта.



Требования к документации (раздел 5) отнесем к группе Functional Safety Management. МЭК 61508-1 содержит еще и приложение А, относящееся к документации, но оно, на мой взгляд, не особенно полезно. Рекомендуемую структуру документации (исходя из опыта сертификации) рассмотрим в последующих публикациях. Структура документов во многом определяет и структуру жизненного цикла, а он у нас, как и для всех приложений, связанных с безопасностью – V-образный.



МЭК 61508-2, Требования к системам



Вторая часть, МЭК 61508-2, как следует из названия, относится к управляющей системе. Как было определено во вводной публикации по функциональной безопасности, мы рассматриваем три типа архитектур управляющих систем: встроенные системы (Embedded Systems), АСУ ТП на базе ПЛК (Industrial Control Systems) и Device Layer интернета вещей. Важно отметить, что, кроме системных требований, МЭК 61508-2 определяет также требования к аппаратной (hardware) составляющей систем. Разделы 5, 6 и 8 содержат лишь ссылки на МЭК 61508-1.





Рисунок 4. Содержание МЭК 61508-2



В составе МЭК 61508-2 мы найдем ряд важных приложений, которые носят нормативный, т.е. обязательный к выполнению характер:



— в приложении А предложен подход к реализации самодиагностики, а также к защите от систематических отказов;

— в приложении В меры защиты от систематических отказов дополнены требованиями к их реализации на различных этапах жизненного цикла системы;

— в приложении С показано, как рассчитывать диагностическое покрытие в целях обеспечения того или иного уровня полноты безопасности (SIL);

— в приложении D сформулированы требования к содержанию руководства по эксплуатации, которое с учетом требований к безопасности носит название Safety Manual;

— в приложение Е описаны подходы к внутрикристальному резервированию при реализации управляющих функций с использованием интегральных схем;

— приложение F формально является информативным, т.е. как бы необязательным к выполнению, но, тем не менее, де-факто его надо рассматривать, если в системах применяются заказные интегральные схемы (ASIC) или программируемые логические интегральные схемы (FPGA & CPLD).



МЭК 61508-3, Требования к программному обеспечению



Третья часть, МЭК 61508-3, определяет требования к программному обеспечению, которое может быть, как компонентом системы, так и отдельным объектом оценивания и сертификации.





Рисунок 5. Содержание МЭК 61508-3



Разделы 5, 6 и 8 традиционно ссылаются на МЭК 61508 1, но есть небольшие дополнения, учитывающие особенности программного обеспечения.



Из приложений важны А и В, содержащие требования к защите от отказов программного обеспечения. В приложении D содержатся требования к руководству по эксплуатации (Safety Manual) в части особенностей ПО.



МЭК 61508-4, Термины и определения



МЭК 61508-4 содержит структурированный перечень используемых терминов, что подробно рассмотрено в части 2 публикации.





Рисунок 6. Содержание МЭК 61508-4



МЭК 61508-5, Рекомендации по применению методов определения уровней полноты безопасности



МЭК 61508-5 приводит достаточно абстрактные примеры того, как определять уровень полноты безопасности (safety integrity level, SIL). Я бы рассматривал эту часть просто, как иллюстративный материал для изучения, тем более, что, когда мы получаем исходные данные для разработки системы или ПО, то уровень полноты безопасности (SIL), как правило, там уже задан.







Рисунок 7. Содержание МЭК 61508-5



МЭК 61508-6, Руководство по применению МЭК 61508-2 и МЭК 61508-3



МЭК 61508-6 громко заявляет о том, что он содержит руководство по применению частей 2 и 3 МЭК 61508, т.е. требований к системе, аппаратному и программному обеспечению. На самом деле, в приложении А содержится достаточно тривиальное описание этапов выполнения проекта (на уровне «разработайте требования», «спланируйте работу» и т.д.). Что действительно представляет интерес, так это подробные примеры расчета показателей надежности и безопасности (приложения B, C, D), а также пример того, как внедрять методы обеспечения полноты безопасности (safety integrity) для программного обеспечения (приложение Е). Последнее иллюстрирует применение приложений А и В из МЭК 61508-3.





Рисунок 8. Содержание МЭК 61508-6



МЭК 61508-7, Методы и средства



МЭК 61508-7 содержит перечень методов защиты от случайных отказов аппаратных средств и от систематических ошибок проектирования (как системы и аппаратных средств, так и программного обеспечения). Похоже, что авторы стандарта постарались опубликовать все, что они когда-либо слышали об этих методах. Поэтому, там много теоретических вещей, которые вряд ли могут быть эффективно применены на практике. Тем не менее, применение основных подходов в части диагностирования, тестирования, организации управления проектом и т.п. является обязательными нормативными требованиями. Таким образом, изучать МЭК 61508-7 следует на основе МЭК 61508-2 и МЭК 61508-3, где как раз и описан прагматичный подход к внедрению защиты от отказов и ошибок.





Рисунок 9. Содержание МЭК 61508-7



Выводы



Рассмотрение МЭК 61508 на основе классификации и структурирования требований позволило разложить «по полочкам» этот серьезный документ из семи частей и 700 страниц.

Классификационные признаки требований позволяют выделить аспекты функциональной безопасности, которые надо будет рассмотреть для полноты картины в планируемом цикле статей, а именно:



— оценивание вероятности случайных отказов и обеспечение защиты от таких отказов (Random Capability) через призму теории надежности и безопасности;

— управление функциональной безопасностью (Functional Safety Management) и оценивание функциональной безопасности (Functional Safety Assessment);

— реализацию жизненного цикла функциональной безопасности (Functional Safety Life Cycle), включая тестирование;

— методы защиты от систематических отказов проектирования системы и аппаратных средств (Systematic Failures Avoidance) и от систематических отказов проектирования программного обеспечения (Software Failures Avoidance).



Напомню, что в первой вводной части публикации:



— обоснована важность оценивания и обеспечения функциональной безопасности для компьютерных систем управления;

— рассмотрены архитектуры систем, для которых необходимо оценивать и обеспечивать функциональную безопасность; к таким системам относятся АСУ ТП (Industrial Control Systems) на базе программируемых логических контроллеров (ПЛК), встроенные системы (Embedded Systems) и уровень устройств (Device Layer) для интернета вещей;

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



Во второй части публикации: рассмотрена общая структура стандарта МЭК 61508 «Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью» (IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems) и используемая в нем терминология.
Original source: habrahabr.ru.

https://habrahabr.ru/post/310836/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<информационная безопасность - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda