FAQ по стандартам «Системы с разделением доменов»/2
Являются ли системы с разделением доменов конструктивно безопасными (secure by design)?
Подход с разделением доменов является методом создания архитектуры, который может применяться при создании конструктивно безопасных систем. В отрыве от других методов, он может не дать нужный результат, однако в комплексе мероприятий действительно эффективен.
Насколько новым является подход, есть ли соответствующий мировой опыт?
Впервые понятие ядра разделения (separation kernel) и соответствующей архитектуры системы описано в статье J.Rushby в 1981 году. Практический подход к созданию систем с разделением доменов активно исследуется и реализуется примерно с начала двухтысячных годов (подробнее я рассказывала здесь и здесь) и носит название MILS.
Почему стандарты разрабатывались для Интернета вещей, можно ли их применять еще где-то?
Идея разработки стандартов в контексте киберфизических систем и Интернета вещей связана с универсальностью подхода в отношении безопасности. Он способствует как информационной безопасности, так и функциональной, а это особенно важно для систем, которые «выходят в физический мир». Тем не менее, в чистом «информационном» окружении архитектура с разделением доменов для проектирования, реализации и сертификации безопасных систем работает не хуже.
Являются ли системы с разделением доменов конструктивно безопасными (secure by design)?
Подход с разделением доменов является методом создания архитектуры, который может применяться при создании конструктивно безопасных систем. В отрыве от других методов, он может не дать нужный результат, однако в комплексе мероприятий действительно эффективен.
Насколько новым является подход, есть ли соответствующий мировой опыт?
Впервые понятие ядра разделения (separation kernel) и соответствующей архитектуры системы описано в статье J.Rushby в 1981 году. Практический подход к созданию систем с разделением доменов активно исследуется и реализуется примерно с начала двухтысячных годов (подробнее я рассказывала здесь и здесь) и носит название MILS.
Почему стандарты разрабатывались для Интернета вещей, можно ли их применять еще где-то?
Идея разработки стандартов в контексте киберфизических систем и Интернета вещей связана с универсальностью подхода в отношении безопасности. Он способствует как информационной безопасности, так и функциональной, а это особенно важно для систем, которые «выходят в физический мир». Тем не менее, в чистом «информационном» окружении архитектура с разделением доменов для проектирования, реализации и сертификации безопасных систем работает не хуже.
FAQ по стандартам «Системы с разделением доменов»/3
Почему документы носят статус ПНСТ (предварительный национальный стандарт), а не ГОСТ?
Так как несколько человек уже спросили, расскажу, что значит «предварительный стандарт».
Согласно статье 2 162-ФЗ «О стандартизации», предварительный национальный стандарт (ПНСТ) - документ по стандартизации, который разработан участником или участниками работ по стандартизации, по результатам экспертизы в техническом комитете по стандартизации или проектном техническом комитете по стандартизации утвержден федеральным органом исполнительной власти в сфере стандартизации и в котором для всеобщего применения устанавливаются общие характеристики объекта стандартизации, а также правила и общие принципы в отношении объекта стандартизации на ограниченный срок в целях накопления опыта в процессе применения предварительного национального стандарта для возможной последующей разработки на его основе национального стандарта.
Так как большая часть понятий, терминов и определений, вводимых в наших документах, является новой для отечественной практики, накопление опыта действительно необходимо. Работу над документами мы не прекращаем, и надеемся на активное участие сообщества в ней.
При этом условия применения ПНСТ точно такие же, как у ГОСТ (статья 26 упомянутого ФЗ) – «Документы национальной системы стандартизации (ГОСТ, ПНСТ, правила стандартизации, рекомендации по стандартизации, информационно-технические справочники) применяются на добровольной основе одинаковым образом и в равной мере независимо от страны и (или) места происхождения продукции (товаров, работ, услуг), если иное не установлено законодательством Российской Федерации».
Так что это просто статус, обозначение того, что стандартизация не стоит на месте.
Жду еще вопросы в комментариях!
Почему документы носят статус ПНСТ (предварительный национальный стандарт), а не ГОСТ?
Так как несколько человек уже спросили, расскажу, что значит «предварительный стандарт».
Согласно статье 2 162-ФЗ «О стандартизации», предварительный национальный стандарт (ПНСТ) - документ по стандартизации, который разработан участником или участниками работ по стандартизации, по результатам экспертизы в техническом комитете по стандартизации или проектном техническом комитете по стандартизации утвержден федеральным органом исполнительной власти в сфере стандартизации и в котором для всеобщего применения устанавливаются общие характеристики объекта стандартизации, а также правила и общие принципы в отношении объекта стандартизации на ограниченный срок в целях накопления опыта в процессе применения предварительного национального стандарта для возможной последующей разработки на его основе национального стандарта.
Так как большая часть понятий, терминов и определений, вводимых в наших документах, является новой для отечественной практики, накопление опыта действительно необходимо. Работу над документами мы не прекращаем, и надеемся на активное участие сообщества в ней.
При этом условия применения ПНСТ точно такие же, как у ГОСТ (статья 26 упомянутого ФЗ) – «Документы национальной системы стандартизации (ГОСТ, ПНСТ, правила стандартизации, рекомендации по стандартизации, информационно-технические справочники) применяются на добровольной основе одинаковым образом и в равной мере независимо от страны и (или) места происхождения продукции (товаров, работ, услуг), если иное не установлено законодательством Российской Федерации».
Так что это просто статус, обозначение того, что стандартизация не стоит на месте.
Жду еще вопросы в комментариях!
🔥5
В некоторых отраслях системы с разделением доменов существовали примерно всегда. Например, в автомобильной. Вмешательство в бортовую сеть, объединяющую электронные блоки управления, из инфотейнмент окружения всегда было затруднительно. Если помните - в исследовании Миллера и Валасека 2014 года основная техническая трудность отправки джипа чероки в кювет удаленно заключалась как раз в обходе этой изоляции.
Однако все меняется, и к сожалению, не всегда в лучшую сторону. Электроника автомобилей становится сложнее и все уязвимее к намеренным атакам.
Вебинар, который я советую не пропускать: мои коллеги по ICS CERT Сергей Ануфриенко и Александр Козлов расскажут о киберугрозах современным автомобилям
Сама пойду)
Однако все меняется, и к сожалению, не всегда в лучшую сторону. Электроника автомобилей становится сложнее и все уязвимее к намеренным атакам.
Вебинар, который я советую не пропускать: мои коллеги по ICS CERT Сергей Ануфриенко и Александр Козлов расскажут о киберугрозах современным автомобилям
Сама пойду)
BrightTALK
Cyberthreats to modern automotive industry
Modern cars are no longer just a means of transportation. Their built-in services can manage everything for drivers and passengers alike from seat heating, to using voice-controlled GPS to find a coffee, or make theater ticket reservations. Along with the…
🔥7👍5
Не хочу учиться_Екатерина Рудина.pdf
4.4 MB
Во вторник состоялась первая конференция открытого сообщества RuScadaSec, на которой я присутствовала как давний участник этого сообщества и рассказывала разные смешные (и не очень) истории в духе "каких уязвимостей и инцидентов могло не быть, если бы люди лучше знали теорию информационной безопасности".
Меня очень просили выложить слайды и подстрочник к ним (например, для использования на лекциях для студентов), что я и делаю.
При подготовке использованы исследования и публикации Kaspersky ICS CERT
Меня очень просили выложить слайды и подстрочник к ним (например, для использования на лекциях для студентов), что я и делаю.
При подготовке использованы исследования и публикации Kaspersky ICS CERT
🔥8
Истории будет 4 и рассказывать буду понемногу, по мере подготовки подстрочника
История первая, о криптографии. Как строить, строить и наконец ничего не построить
В начале 2021 года была официально опубликована информация об уязвимостях различной степени критичности (от 3.1 до 7.1) в ПЛК Modicon M100/M200/M221 производства Schneider Electric. Уязвимости связаны с недостатками реализации криптографических функций защиты данных.
Эти и подобные контроллеры используются для базовой машинной автоматизации в автоматизации упаковки, погрузочно-разгрузочных работах, в том числе в логистических системах (доставке), переработке материалов, в промышленной роботизации. Конкретно контроллеры этих линеек работают на базе изначально небезопасного протокола Modbus over TCP. Аутентификация инженера и дальнейший обмен данными, к примеру, при переконфигурации контроллера требуют защиты. Если нарушитель получил доступ к промышленной сети, то его несанкционированный доступ к контроллеру или MitM атака c подделкой данных может привести к непредсказуемым последствиям, в том числе физическому ущербу.
Так ли уж защищает от подобных атак спроектированная инженерами Schneider Electric криптография?
На самом деле нет: при реализации защиты были сделаны детские ошибки.
Во-первых, собственный алгоритм для генерации общего «секрета» (ключа), несколько похожий на алгоритм Диффи-Хеллмана, но отличающийся в деталях (замечу, что этот алгоритм генерации секрета не является устойчивым к MitM атаке)
Во-вторых, длина того самого секрета – всего 4 байта! Пространство перебора очень небольшое, да и сложность задачи дискретного логарифмирования в таких порядках невысока
В-третьих, для генерации случайных данных использовалось текущее время, а это абсолютно плохая практика, так как числа получаются предсказуемыми.
В-четвертых, в трафике смешивались шифрованные и нешифрованные данные, это всегда облегчает криптоанализ.
Ну, и в-пятых, никакой криптоанализ и не требовался, точнее, требовался в минимальном объеме. Дело в том, что для шифрования передаваемых данных на общем «секрете» использовалось «исключающее или» (XOR) с этим ключом. Для Modbus трафика с предсказуемыми, часто нулевыми заполнениями, это позволяет в некоторых участках дампа трафика попросту наблюдать ключ в открытом виде (XOR нулевых байтов и ключа даст сам ключ).
Давайте вспомним, что разработка каких-то новых функций в ПО известного оборудования – довольно дорогостоящая история. Кто-то обосновал и спроектировал эту «защиту», описал требования, был проведен цикл разработки, включая контроль качества, успешно прошел релиз. Эффект для безопасности – околонулевой. Издержки на выпуск обновления, коммуникацию, поддержку репутации.
А стоило всего лишь привлечь кого-то, кто не пропускал лекции по основам криптографии в универе
Ссылки на оригинальные источники в блоге Kaspersky ICS CERT
В начале 2021 года была официально опубликована информация об уязвимостях различной степени критичности (от 3.1 до 7.1) в ПЛК Modicon M100/M200/M221 производства Schneider Electric. Уязвимости связаны с недостатками реализации криптографических функций защиты данных.
Эти и подобные контроллеры используются для базовой машинной автоматизации в автоматизации упаковки, погрузочно-разгрузочных работах, в том числе в логистических системах (доставке), переработке материалов, в промышленной роботизации. Конкретно контроллеры этих линеек работают на базе изначально небезопасного протокола Modbus over TCP. Аутентификация инженера и дальнейший обмен данными, к примеру, при переконфигурации контроллера требуют защиты. Если нарушитель получил доступ к промышленной сети, то его несанкционированный доступ к контроллеру или MitM атака c подделкой данных может привести к непредсказуемым последствиям, в том числе физическому ущербу.
Так ли уж защищает от подобных атак спроектированная инженерами Schneider Electric криптография?
На самом деле нет: при реализации защиты были сделаны детские ошибки.
Во-первых, собственный алгоритм для генерации общего «секрета» (ключа), несколько похожий на алгоритм Диффи-Хеллмана, но отличающийся в деталях (замечу, что этот алгоритм генерации секрета не является устойчивым к MitM атаке)
Во-вторых, длина того самого секрета – всего 4 байта! Пространство перебора очень небольшое, да и сложность задачи дискретного логарифмирования в таких порядках невысока
В-третьих, для генерации случайных данных использовалось текущее время, а это абсолютно плохая практика, так как числа получаются предсказуемыми.
В-четвертых, в трафике смешивались шифрованные и нешифрованные данные, это всегда облегчает криптоанализ.
Ну, и в-пятых, никакой криптоанализ и не требовался, точнее, требовался в минимальном объеме. Дело в том, что для шифрования передаваемых данных на общем «секрете» использовалось «исключающее или» (XOR) с этим ключом. Для Modbus трафика с предсказуемыми, часто нулевыми заполнениями, это позволяет в некоторых участках дампа трафика попросту наблюдать ключ в открытом виде (XOR нулевых байтов и ключа даст сам ключ).
Давайте вспомним, что разработка каких-то новых функций в ПО известного оборудования – довольно дорогостоящая история. Кто-то обосновал и спроектировал эту «защиту», описал требования, был проведен цикл разработки, включая контроль качества, успешно прошел релиз. Эффект для безопасности – околонулевой. Издержки на выпуск обновления, коммуникацию, поддержку репутации.
А стоило всего лишь привлечь кого-то, кто не пропускал лекции по основам криптографии в универе
Ссылки на оригинальные источники в блоге Kaspersky ICS CERT
🔥8👍1
История вторая, о доверии технологиям. Двое из ИБ-ларца
Что такое технология? Совокупность идей и их технического воплощения для достижения определенной цели. В ИБ отрасли техническое воплощение идеи само по себе должно быть безупречно с точки зрения безопасности, с двух точек зрения.
Первая точка зрения – отсутствие уязвимостей. Атака на защитный механизм делает этот механизм бесполезным.
Вторая точка зрения – отсутствие скрытых возможностей. Потому что у того, кто вас защищает, есть все возможности обратить свою силу против вас же. А значит, защитному механизму нужно доверять.
Давайте еще вспомним, что уязвимости, при определенной степен паранойи, можно рассматривать ка скрытые возможности ПО.
А теперь с этих точек зрения посмотрим на историю с возможностями/уязвимостями ПО, которое устанавливается при использовании USB-токенов ИБ-гиганта Gemalto. Заметим, что подключаемое устройство не хранит в себе ни вредоносного, ни уязвимого легитимного кода, и его подключение служит лишь триггером для установки полнофункционального легитимного бэкдора из более чем легитимного источника.
Исследуемый продукт – это комплекс, включающий USB-носитель и набор драйверов и прикладного ПО, устанавливаемого на компьютер для работы с лицензионными ключами. USB-токен надо подключать к персональному компьютеру или серверу, на котором ПО требуется лицензия. В этом менеджере лицензий исследователи Kaspersky ICS CERT обнаружили порядка 20 уязвимостей, и кроме классических уязвимостей – очень странную функциональность, которая позволяла провести эффективную атаку на целевую систему. Подробно можно почитать тут.
А вкратце дело обстоит так: функционал ПО позволял атакующему скрытно получать удаленный доступ, выполнять произвольный код, а также скрывать свое присутствие. Всё, что было нужно для получения доступа к компьютеру, – подключить USB-токен одной из моделей, указанных в таблице выше, подождать пару минут – и отключить токен.
Если на атакованной машине есть доступ в Интернет, происходит автоматическая установка драйвера через Windows Update и службы, автоматически запускается процесс hasplms.exe с правами SYSTEM, открывается порт 1947. Если доступа в Интернет нет, то нужно заставить пользователя установить ПО Gemalto с сайта или в составе ПО третьей стороны. Порт 1947 при этом добавляется в исключения межсетевого экрана Windows. После открытия порта 1947 атакующий по сети мог воспользоваться «плохо документированной API функцией», которая позволяла включать и выключать доступность web интерфейса. Через этот интерфейс можно менять различные настройки программной части решения. В том числе, открывалась возможность менять настройки внутреннего proxy-сервера для обновления языковых пакетов.
Интересный факт: классические защитные механизмы от бинарных уязвимостей (ASLR, Stack Cookie, Stack Canary и т.д.) были отключены разработчиками. И бинарные уязвимости в этих языковых пакетах давали злоумышленникам возможность удаленного выполнения произвольного кода с правами SYSTEM – без особых усилий.
После изменения прокси-сервера, используя внутреннюю логику сервиса, можно получить NTLM-хеш пользователя, из-под которого запущен процесс hasplms.exe (SYSTEM).
Как уже было сказано, компьютер при этом даже может находиться в заблокированном режиме. Перед нами – легитимный функционал, имеющий все признаки бекдора.
Вывод? Доверяй, но проверяй. Желательно, с участием опытных специалистов, понимающих особенности реализации технологий операционных систем и защитного ПО.
Что такое технология? Совокупность идей и их технического воплощения для достижения определенной цели. В ИБ отрасли техническое воплощение идеи само по себе должно быть безупречно с точки зрения безопасности, с двух точек зрения.
Первая точка зрения – отсутствие уязвимостей. Атака на защитный механизм делает этот механизм бесполезным.
Вторая точка зрения – отсутствие скрытых возможностей. Потому что у того, кто вас защищает, есть все возможности обратить свою силу против вас же. А значит, защитному механизму нужно доверять.
Давайте еще вспомним, что уязвимости, при определенной степен паранойи, можно рассматривать ка скрытые возможности ПО.
А теперь с этих точек зрения посмотрим на историю с возможностями/уязвимостями ПО, которое устанавливается при использовании USB-токенов ИБ-гиганта Gemalto. Заметим, что подключаемое устройство не хранит в себе ни вредоносного, ни уязвимого легитимного кода, и его подключение служит лишь триггером для установки полнофункционального легитимного бэкдора из более чем легитимного источника.
Исследуемый продукт – это комплекс, включающий USB-носитель и набор драйверов и прикладного ПО, устанавливаемого на компьютер для работы с лицензионными ключами. USB-токен надо подключать к персональному компьютеру или серверу, на котором ПО требуется лицензия. В этом менеджере лицензий исследователи Kaspersky ICS CERT обнаружили порядка 20 уязвимостей, и кроме классических уязвимостей – очень странную функциональность, которая позволяла провести эффективную атаку на целевую систему. Подробно можно почитать тут.
А вкратце дело обстоит так: функционал ПО позволял атакующему скрытно получать удаленный доступ, выполнять произвольный код, а также скрывать свое присутствие. Всё, что было нужно для получения доступа к компьютеру, – подключить USB-токен одной из моделей, указанных в таблице выше, подождать пару минут – и отключить токен.
Если на атакованной машине есть доступ в Интернет, происходит автоматическая установка драйвера через Windows Update и службы, автоматически запускается процесс hasplms.exe с правами SYSTEM, открывается порт 1947. Если доступа в Интернет нет, то нужно заставить пользователя установить ПО Gemalto с сайта или в составе ПО третьей стороны. Порт 1947 при этом добавляется в исключения межсетевого экрана Windows. После открытия порта 1947 атакующий по сети мог воспользоваться «плохо документированной API функцией», которая позволяла включать и выключать доступность web интерфейса. Через этот интерфейс можно менять различные настройки программной части решения. В том числе, открывалась возможность менять настройки внутреннего proxy-сервера для обновления языковых пакетов.
Интересный факт: классические защитные механизмы от бинарных уязвимостей (ASLR, Stack Cookie, Stack Canary и т.д.) были отключены разработчиками. И бинарные уязвимости в этих языковых пакетах давали злоумышленникам возможность удаленного выполнения произвольного кода с правами SYSTEM – без особых усилий.
После изменения прокси-сервера, используя внутреннюю логику сервиса, можно получить NTLM-хеш пользователя, из-под которого запущен процесс hasplms.exe (SYSTEM).
Как уже было сказано, компьютер при этом даже может находиться в заблокированном режиме. Перед нами – легитимный функционал, имеющий все признаки бекдора.
Вывод? Доверяй, но проверяй. Желательно, с участием опытных специалистов, понимающих особенности реализации технологий операционных систем и защитного ПО.
👍2🔥2
История третья, о моделях ИБ. Спасибо, что деньгами
Модели безопасности и, в частности, модели контроля доступа – одна из самых нелюбимых и непонятных тем для студентов. Правила доступа, сформулированные вне привычных концепций файлов и пользователей, кажутся то непонятными, то самоочевидными, а теоремы безопасности забываются после экзамена почти мгновенно.
Однако принципы ограничения потоков данных в соответствии с обязательными правилами нормативного контроля применяются не только для защиты данных, но и для защиты критических инфраструктур, к примеру, вычислительных сетей на объектах атомной промышленности.
Официально цифровизация атомных электростанций началась не слишком давно: в нулевые начиналась в России, а первая полностью цифровая АЭС в США заработала только в 2011 году (источник). Тем не менее, тут и там встречались энтузиасты, дорабатывавшие системы контроля и управления, к примеру, для целей удаленной диагностики. В офисной сети АЭС Хэтч (Hatch) в штате Джорджия, США, использовалось специализированное ПО для наблюдения за химическими и диагностическими данными, получаемыми от основной системы управления. При этом происходила синхронизация хранимых в нем данных с данными в системе управления, расположенной в сегменте сети, изолированном от офисного сегмента.
Оператор знал о важности обновлений безопасности и проводил обновление ПО в офисном сегменте. Однако он не учел, что при перезапуске системы после обновления ПО произойдет удаление всех данных, и синхронизация вызовет удаление данных в связанной системе управления. В свою очередь, система безопасности интерпретировала отсутствие данных в системе управления как потерю охлаждающей воды и в результате инициировала аварийный останов реактора.
Останов реактора в нормальном режиме не был опасен для людей или окружающей среды, однако перезапуск реактора – долгая операция. К тому же, на втором реакторе происходила перегрузка топлива, а значит, АЭС была неспособна поставлять электроэнергию в течение двух суток. По оценкам экспертов, финансовые потери из-за недопоставок составили от 2 до 5 миллионов долларов.
Почему я тут говорю о моделях безопасности? Дело в том, что согласно современным стандартам, на АЭС применяется мандатная модель ограничений доступа. Непредвиденная синхронизация данных в системе управления с офисным компьютером не произошла бы, если бы не прошел сигнал из офисной сети в сеть контроля и управления – а он должен был быть запрещен и отфильтрован на МЭ или при помощи диода данных. Разумеется, ни о каком «собственноручно модифицированном» ПО на АЭС не может быть и речи, однако организационные правила не всегда срабатывают, а хорошо реализованная архитектура безопасности на моделях доступа помогает предотвратить ущерб от ошибок.
Модели безопасности и, в частности, модели контроля доступа – одна из самых нелюбимых и непонятных тем для студентов. Правила доступа, сформулированные вне привычных концепций файлов и пользователей, кажутся то непонятными, то самоочевидными, а теоремы безопасности забываются после экзамена почти мгновенно.
Однако принципы ограничения потоков данных в соответствии с обязательными правилами нормативного контроля применяются не только для защиты данных, но и для защиты критических инфраструктур, к примеру, вычислительных сетей на объектах атомной промышленности.
Официально цифровизация атомных электростанций началась не слишком давно: в нулевые начиналась в России, а первая полностью цифровая АЭС в США заработала только в 2011 году (источник). Тем не менее, тут и там встречались энтузиасты, дорабатывавшие системы контроля и управления, к примеру, для целей удаленной диагностики. В офисной сети АЭС Хэтч (Hatch) в штате Джорджия, США, использовалось специализированное ПО для наблюдения за химическими и диагностическими данными, получаемыми от основной системы управления. При этом происходила синхронизация хранимых в нем данных с данными в системе управления, расположенной в сегменте сети, изолированном от офисного сегмента.
Оператор знал о важности обновлений безопасности и проводил обновление ПО в офисном сегменте. Однако он не учел, что при перезапуске системы после обновления ПО произойдет удаление всех данных, и синхронизация вызовет удаление данных в связанной системе управления. В свою очередь, система безопасности интерпретировала отсутствие данных в системе управления как потерю охлаждающей воды и в результате инициировала аварийный останов реактора.
Останов реактора в нормальном режиме не был опасен для людей или окружающей среды, однако перезапуск реактора – долгая операция. К тому же, на втором реакторе происходила перегрузка топлива, а значит, АЭС была неспособна поставлять электроэнергию в течение двух суток. По оценкам экспертов, финансовые потери из-за недопоставок составили от 2 до 5 миллионов долларов.
Почему я тут говорю о моделях безопасности? Дело в том, что согласно современным стандартам, на АЭС применяется мандатная модель ограничений доступа. Непредвиденная синхронизация данных в системе управления с офисным компьютером не произошла бы, если бы не прошел сигнал из офисной сети в сеть контроля и управления – а он должен был быть запрещен и отфильтрован на МЭ или при помощи диода данных. Разумеется, ни о каком «собственноручно модифицированном» ПО на АЭС не может быть и речи, однако организационные правила не всегда срабатывают, а хорошо реализованная архитектура безопасности на моделях доступа помогает предотвратить ущерб от ошибок.
🔥3👏3👍1
Историю четвертую, про 13 портовых друзей Оушена, я просто рекомендую почитать в блоге тут, потому что вряд ли расскажу ее лучше Володи Дащенко
Но позволю себе заметить, что в случае настолько целеустремленных нарушителей нельзя предложить какое-то готовое техническое решение, а работать нужно с фантазией, огоньком и «catch me if you can» в крови. Это плохо стыкуется с той скукотой, которую студенты получают на лекциях по «Организационным и техническим методам защиты информации». И даже с той работой, которую большинство взрослых специалистов делает для организации СУИБ по ISO 27001.
Потому что убрать бумажную безопасность из бумажной безопасности – самое сложное.
Но позволю себе заметить, что в случае настолько целеустремленных нарушителей нельзя предложить какое-то готовое техническое решение, а работать нужно с фантазией, огоньком и «catch me if you can» в крови. Это плохо стыкуется с той скукотой, которую студенты получают на лекциях по «Организационным и техническим методам защиты информации». И даже с той работой, которую большинство взрослых специалистов делает для организации СУИБ по ISO 27001.
Потому что убрать бумажную безопасность из бумажной безопасности – самое сложное.
Kaspersky ICS CERT | Центр реагирования на инциденты информационной безопасности промышленных инфраструктур «Лаборатории Касперского»
Нестандартные методы проникновения в практике Red Team команд и в тактике злоумышленников | Kaspersky ICS CERT
Я хотел бы рассказать о нескольких трюках и некоторых приёмах получения первоначального доступа к удаленной системе, которые меня заинтересовали с точки зрения неожиданности и нестандартности подхода.
👍4
Информационная безопасность VS кибербезопасность
Время от времени в профильных сообществах возникает вопрос об употреблении терминов "информационная безопасность" и "кибербезопасность". Я вспомнила, что уже разбиралась и объясняла - выложила для всех.
Время от времени в профильных сообществах возникает вопрос об употреблении терминов "информационная безопасность" и "кибербезопасность". Я вспомнила, что уже разбиралась и объясняла - выложила для всех.
👍11
Forwarded from SafeCode — конференция по безопасности приложений
#подкаст
Новый выпуск подкаста [SafeCode Live] — Secure by design
Разбираемся в подходе Secure by design (SBD), или конструктивной безопасности в разработке продукта.
Участники обсуждают:
— что такое Secure by design и нужен ли он в каждом продукте;
— чем SBD отличается от безопасной разработки;
— что делать, если «уже сделано небезопасно»;
— может ли SBD-продукт стать небезопасным;
— как стать компетентным в SBD;
— существуют ли общие концепции и стандарты SBD.
Гости:
— Сергей Рогачев, руководитель отдела разработки безопасной платформы в Лаборатории Касперского.
— Екатерина Рудина, аналитик в Лаборатории Касперского. Работает в департаменте перспективных технологий в области исследования угроз, моделирования и оценки рисков.
— Александр Поломодов, руководитель управления разработки цифровых экосистем в Тинькофф.
Ведущий:
Алексей Федулаев, руководитель направления автоматизации безопасной разработки в Wildberries.
Новый выпуск и предыдущие доступны на:
— YouTube
— Apple Podcasts
— Яндекс Музыке
Подписывайтесь на удобные платформы, чтобы не пропустить новые выпуски!
Новый выпуск подкаста [SafeCode Live] — Secure by design
Разбираемся в подходе Secure by design (SBD), или конструктивной безопасности в разработке продукта.
Участники обсуждают:
— что такое Secure by design и нужен ли он в каждом продукте;
— чем SBD отличается от безопасной разработки;
— что делать, если «уже сделано небезопасно»;
— может ли SBD-продукт стать небезопасным;
— как стать компетентным в SBD;
— существуют ли общие концепции и стандарты SBD.
Гости:
— Сергей Рогачев, руководитель отдела разработки безопасной платформы в Лаборатории Касперского.
— Екатерина Рудина, аналитик в Лаборатории Касперского. Работает в департаменте перспективных технологий в области исследования угроз, моделирования и оценки рисков.
— Александр Поломодов, руководитель управления разработки цифровых экосистем в Тинькофф.
Ведущий:
Алексей Федулаев, руководитель направления автоматизации безопасной разработки в Wildberries.
Новый выпуск и предыдущие доступны на:
— YouTube
— Apple Podcasts
— Яндекс Музыке
Подписывайтесь на удобные платформы, чтобы не пропустить новые выпуски!
👍4🔥2
TGIF!
Записали подкаст в хорошей компании. Нескучно и полезно поговорили о Security by Design, в чем сходство и различие с безопасной разработкой, с какой стороны заходить в этот самый SbD и кому он может быть нужен.
Записали подкаст в хорошей компании. Нескучно и полезно поговорили о Security by Design, в чем сходство и различие с безопасной разработкой, с какой стороны заходить в этот самый SbD и кому он может быть нужен.
YouTube
[SafeCode Live] Secure by design
Ближайшая конференция: SafeCode 2025, даты будут анонсированы позднее. Подробности: https://jrg.su/hbNqzs
— —
В этом выпуске разбираемся в подходе Secure by design (SBD), или конструктивной безопасности в разработке продукта.
Участники обсуждают:
— что…
— —
В этом выпуске разбираемся в подходе Secure by design (SBD), или конструктивной безопасности в разработке продукта.
Участники обсуждают:
— что…
👍6
Расскажу еще про дружественный хакатон, где можно попробовать на практике создавать secure by design решения при поддержке технологии Лаборатории Касперского. Однажды я его анонсировала, и вот версия 2.0 - улучшенный, доработанный сценарий, новые знания, хороший призовой фонд.
На хакатон приглашаются разработчики, аналитики, QA-специалисты, архитекторы ПО, специалисты, эксперты по ИБ и студенты соответствующих направлений. Участвовать можно индивидуально или в команде до 5 человек. Специфических знаний не требуется - все расскажут и объяснят.
Регистрация открыта до 13:00 по МСК 24 ноября. Все подробности: https://cnrlink.com/cyberimmunehack2
На хакатон приглашаются разработчики, аналитики, QA-специалисты, архитекторы ПО, специалисты, эксперты по ИБ и студенты соответствующих направлений. Участвовать можно индивидуально или в команде до 5 человек. Специфических знаний не требуется - все расскажут и объяснят.
Регистрация открыта до 13:00 по МСК 24 ноября. Все подробности: https://cnrlink.com/cyberimmunehack2
👍9🔥1
Forwarded from KasperskyOS. Разработка
В "Школе фундаментальных технологи" МГТУ им. Н.Э. Баумана в период с марта по май состоится уникальный цикл лекций от российских IT компаний — лидеров своих направлений, посвященный фундаментальным информационным технологиям, их развитию в России и в мире.
👉 https://secure-software.bmstu.ru
В первом же блоке курса "Системное программное обеспечение. Фундаментальные технологии сквозь призму безопасной разработки" с докладом «Микроядерные операционные системы. Summa Technologiae» выступит Сергей Рогачев, руководителя отдела разработки безопасной платформы "Лаборатории Касперского".
📅 6 марта
🕚 уточняется. Следите за нашими анонсами.
🧑🏻💻 Участие в курсе бесплатное. Но требуется предварительная регистрация
👉 https://secure-software.bmstu.ru
В первом же блоке курса "Системное программное обеспечение. Фундаментальные технологии сквозь призму безопасной разработки" с докладом «Микроядерные операционные системы. Summa Technologiae» выступит Сергей Рогачев, руководителя отдела разработки безопасной платформы "Лаборатории Касперского".
📅 6 марта
🕚 уточняется. Следите за нашими анонсами.
🧑🏻💻 Участие в курсе бесплатное. Но требуется предварительная регистрация
🔥8👍1
Запись первого блока курса Школы фундаментальных технологий РБПО в МГТУ им. Н.Э. Баумана выложили на канале Школы в Rutube
Приятного просмотра!
Приятного просмотра!
RUTUBE
Школа фундаментальных технологий РБПО — полная коллекция видео на RUTUBE
На базе МГТУ им. Н.Э. Баумана по инициативе кафедры ИУ10 "Защита информации" в период с марта по май состоится уникальный цикл лекций от российских IT компаний - лидеров своих направлений, посвященный фундаментальным информационным технологиям, их развитию…
🔥7👍2
Завтра слушаю вебинар Kaspersky ICS CERT о промышленной кибербезопасности - что происходит прямо сейчас и, вероятно, будет происходить в недалёком будущем. Один из самых достоверных источников, один из самых честных и квалифицированных экспертов.
Язык трансляции английский.
Язык трансляции английский.
BrightTALK
Industrial cybersecurity in 2024: trends and forecasts
As the industrial landscape evolves, so do the threats that accompany it. While many industrial threats may be developing slowly from year to year, subtle changes are reaching a critical mass, poised to reshape the cybersecurity landscape in the near future.…
👍7
Даниэль Канеман, мыслитель, лауреат Нобелевской премии, один из авторов теории быстрого и медленного мышления, изменившей наше понимание того как работает общество, экономика, и не в последнюю очередь - безопасность, сегодня умер.
Светлая память.
Его книга заменяет добрую половину современной нонфикшн литературы о памяти и мышлении, о достоверности информации, о рисках, об отношении к рискам и прогнозировании, об эффективном управлении своим и чужим поведением. Если не читали - самое время.
Светлая память.
Его книга заменяет добрую половину современной нонфикшн литературы о памяти и мышлении, о достоверности информации, о рисках, об отношении к рискам и прогнозировании, об эффективном управлении своим и чужим поведением. Если не читали - самое время.
😱11😢2