CISA требует роадмап по замещению C/C++ - Компьютерные священные войны

Американское агентство по кибербезопасности и инфраструктуре (оказывается, и такое бывает) требует явного запрета на C/C++ там, где существует "memory-safe" альтернатива. Запрет в новых продуктах, и требует роадмап на переписывание существующих продуктов.

Господа, это песец, я считаю, — но если требованием сертификата соответствия продукта станет минимизация количества нативного кода- то компаниям ничего не остаётся делать.

https://www.cisa.gov/resources-tools/resources/product-security-bad-practices

The development of new product lines for use in service of critical infrastructure or NCFs in a memory-unsafe language (e.g., C or C++) where there are readily available alternative memory-safe languages that could be used is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety.

For existing products that are written in memory-unsafe languages, not having a published memory safety roadmap by January 1, 2026 is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety. The memory safety roadmap should outline the manufacturer’s prioritized approach to eliminating memory safety vulnerabilities in priority code components (e.g., network-facing code or code that handles sensitive functions like cryptographic operations). Manufacturers should demonstrate that the memory safety roadmap will lead to a significant, prioritized reduction of memory safety vulnerabilities in the manufacturer’s products and demonstrate they are making a reasonable effort to follow the memory safety roadmap.

Аё> Американское агентство по кибербезопасности и инфраструктуре (оказывается, и такое бывает) требует явного запрета на C/C++ там, где существует "memory-safe" альтернатива.
А на использование ключевого слова unsafe потребуется разрешение парткома.

Аё>Господа, это песец, я считаю.

И?
Чем это плохо? Закончи мысль.

Здравствуйте, Артём, Вы писали:

Аё>Американское агентство по кибербезопасности и инфраструктуре (оказывается, и такое бывает) требует явного запрета на C/C++ там, где существует "memory-safe" альтернатива. Запрет в новых продуктах, и требует роадмап на переписывание существующих продуктов.

C++ еще не удобен тем, что его сложно анализировать тому же GPT, в особенности когда дело касается компил-таймовых вещей.

Т.е. это для высших кланов — как бы гвоздь в заднице, т.к. не поддается контролю.

Здравствуйте, Артём, Вы писали:

Аё>Господа, это песец, я считаю, — но если требованием сертификата соответствия продукта станет минимизация количества нативного кода- то компаниям ничего не остаётся делать.
Аё>https://www.cisa.gov/resources-tools/resources/product-security-bad-practices

Хорошо, меньше конкурентов. Это как в России борятся с утечками данных одних компаний придумывая дикие штрафы для других компаний.

Результат думаю очевиден, уничтожение владельцев сайтов внутри России. Да, на остальной мир это не повлияет. Так же как, когда уничтожали машиностроение причём при Путине остальные страны мысленно сказали молодцы.

Но это же уже старая тема, сколько ей лет. Им уже пора переходить к активным действиям. Вламываться на предприятия и отлавливать злоумышленников или хотя бы штрафовать за использование C/C++.

По аналогии с Россией штрафовать всех без разбора на 3 млн. долларов. Вот это бизнес, это по путински.

Я уже даже представил, как владельцы сайтов живущие в России шкерятся в глубоком вебе. Так и те кто программируют на C/C++ в США тоже отключат сервера от открытой сети и уйдут в подполье.

Россиянин.
— За что сидишь?
Американец.
— Разрабатывал программы на C/C++. А ты?
Россиянин.
— А я не написал политику конфиденциальности на сайте.

	Полный текст статьи
	Перейти к основному содержанию Официальный сайт правительства США Вот как вы это узнаете Меню Хлебные крошки Ресурсы и инструменты ДЕЛИТЬСЯ: ПУБЛИКАЦИЯ Неправильная практика обеспечения безопасности продукции Дата публикации 16 октября 2024 г. ПОХОЖИЕ ТЕМЫ: ЛУЧШИЕ ПРАКТИКИ КИБЕРБЕЗОПАСНОСТИ , ОРГАНИЗАЦИИ И КИБЕРБЕЗОПАСНОСТЬ , МНОГОФАКТОРНАЯ АУТЕНТИФИКАЦИЯ Запрос комментариев по Руководству по недобросовестной практике обеспечения безопасности продукта CISA ИЩЕТ ПУБЛИЧНЫЕ КОММЕНТАРИИ ДЛЯ ИНФОРМИРОВАНИЯ О РАЗРАБОТКЕ ЭТИХ ПЛОХИХ ПРАКТИК БЕЗОПАСНОСТИ ПРОДУКТОВ, КОТОРЫЕ ПЕРЕЧИСЛЯЮТ ИСКЛЮЧИТЕЛЬНО РИСКОВАННЫЕ ДЕЙСТВИЯ ПО РАЗРАБОТКЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ. ПОЖАЛУЙСТА, ПОСЕТИТЕ ФЕДЕРАЛЬНЫЙ РЕЕСТР, ЧТОБЫ ОТПРАВИТЬ КОММЕНТАРИЙ ДО 16 ДЕКАБРЯ 2024 Г. ПРОСМОТРЕТЬ ФЕДЕРАЛЬНЫЙ РЕЕСТР Обзор Как указано в инициативе CISA Secure by Design , производители программного обеспечения должны гарантировать, что безопасность является основным фактором с самого начала разработки программного обеспечения. Это добровольное руководство предоставляет обзор плохих практик безопасности продукта, которые считаются исключительно рискованными, особенно для производителей программного обеспечения, которые производят программное обеспечение, используемое для обслуживания критической инфраструктуры или национальных критических функций (NCF), и дает рекомендации производителям программного обеспечения по снижению этих рисков. Агентство по кибербезопасности и безопасности инфраструктуры США (CISA) и Федеральное бюро расследований (ФБР) (далее именуемые организациями-авторами) разработали это руководство, чтобы призвать производителей программного обеспечения снизить риск для клиентов, уделяя первостепенное внимание безопасности на протяжении всего процесса разработки продукта. Этот документ предназначен для производителей программного обеспечения, которые разрабатывают программные продукты и услуги, включая локальное программное обеспечение, облачные сервисы и программное обеспечение как услугу (SaaS), используемые для поддержки критической инфраструктуры или NCF. Организации-авторы настоятельно рекомендуют всем производителям программного обеспечения избегать этих плохих практик безопасности продуктов. Следуя рекомендациям в этом руководстве, производители будут давать понять клиентам, что они берут на себя ответственность за результаты безопасности клиентов, что является ключевым принципом Secure by Design. Руководство, содержащееся в этом документе, не является обязательным, и хотя CISA призывает организации избегать этих плохих практик, этот документ не налагает на них никаких требований делать это. Неправильные практики делятся на три категории. Свойства продукта, которые описывают наблюдаемые качества программного продукта, связанные с безопасностью. Функции безопасности, описывающие функции безопасности, поддерживаемые продуктом. Организационные процессы и политики, описывающие действия, предпринимаемые производителем программного обеспечения для обеспечения высокой прозрачности подхода к безопасности. Этот список является целенаправленным и не включает в себя все возможные нецелесообразные практики кибербезопасности. Отсутствие включения какой-либо конкретной практики кибербезопасности не означает, что CISA одобряет такую практику или считает, что такая практика представляет приемлемый уровень риска. Элементы, представленные в этом списке, были выбраны на основе ландшафта угроз как представляющие наиболее опасные и насущные плохие практики, которых производители программного обеспечения должны избегать. Свойства продукта Развитие языков, небезопасных для памяти ( CWE [1] -119 и связанные с ними недостатки) Разработка новых линеек продуктов для использования в обслуживании критической инфраструктуры или NCF на языке, небезопасном для памяти (например, C или C++), когда существуют легкодоступные альтернативные языки, безопасные для памяти, которые можно было бы использовать, является опасной и значительно повышает риск для национальной безопасности, национальной экономической безопасности, а также национального общественного здравоохранения и безопасности. Для существующих продуктов, написанных на языках, небезопасных для памяти, отсутствие опубликованной дорожной карты безопасности памяти к 1 января 2026 года является опасным и значительно повышает риск для национальной безопасности, национальной экономической безопасности и национального общественного здравоохранения и безопасности. Дорожная карта безопасности памяти должна описывать приоритетный подход производителя к устранению уязвимостей безопасности памяти в приоритетных компонентах кода (например, сетевой код или код, который обрабатывает чувствительные функции, такие как криптографические операции). Производители должны продемонстрировать, что дорожная карта безопасности памяти приведет к значительному приоритетному сокращению уязвимостей безопасности памяти в продуктах производителя, и продемонстрировать, что они прилагают разумные усилия для следования дорожной карте безопасности памяти. Это не относится к продуктам, у которых объявленная дата окончания поддержки до 1 января 2030 года. Рекомендуемые действия: Производители программного обеспечения должны создавать продукты таким образом, чтобы систематически предотвращать появление уязвимостей безопасности памяти, например, используя безопасный язык памяти или аппаратные возможности, которые предотвращают уязвимости безопасности памяти. Кроме того, производители программного обеспечения должны опубликовать дорожную карту безопасности памяти к 1 января 2026 года. Ресурсы: Аргументы в пользу планов по обеспечению безопасности памяти , Обязательство CISA по обеспечению безопасности при проектировании (сокращение классов уязвимостей), Назад к строительным блокам , NIST Secure Software Development Framework (SSDF) PW 6.1. Включение введенных пользователем данных в строки SQL-запроса ( CWE-89 ) Включение введенных пользователем данных непосредственно в необработанное содержимое строки запроса базы данных SQL в продуктах, используемых для обслуживания критически важной инфраструктуры или NCF, является опасным и значительно повышает риск для национальной безопасности, национальной экономической безопасности, а также здоровья и безопасности населения в стране. Рекомендуемые действия: Продукты должны быть созданы таким образом, чтобы систематически предотвращать появление уязвимостей SQL-инъекций, например, путем последовательного применения параметризованных запросов. Ресурсы: CISA Secure by Design Pledge (сокращение классов уязвимостей), SSDF PW.5.1, CISA SQL Injection Secure by Design Alert . Включение введенных пользователем данных в командные строки операционной системы ( CWE-78 ) Включение вводимых пользователем данных непосредственно в необработанное содержимое командной строки операционной системы в продуктах, используемых для обслуживания критически важной инфраструктуры или NCF, является опасным и значительно повышает риск для национальной безопасности, национальной экономической безопасности, а также здоровья и безопасности населения в стране. Рекомендуемые действия: Производители программного обеспечения должны создавать продукты таким образом, чтобы систематически предотвращать уязвимости, связанные с внедрением команд, например, путем последовательного обеспечения того, чтобы вводимые команды были четко отделены от содержания самой команды. Ресурсы: CISA Secure by Design Pledge (сокращение классов уязвимостей), SSDF PW.5.1. Наличие паролей по умолчанию ( CWE-1392 и CWE-1393 ) Выпуск продукта, используемого для обслуживания критически важной инфраструктуры или NCF, с паролями по умолчанию, которые CISA определяет как универсальные пароли, присутствующие по умолчанию во всем продукте, является опасным и значительно повышает риск для национальной безопасности, национальной экономической безопасности, а также здоровья и безопасности населения страны. Рекомендуемые действия: Производители программного обеспечения должны гарантировать, что в продукте отсутствуют пароли по умолчанию, например: Предоставление случайных, уникальных для каждого экземпляра начальных паролей для продукта. Требование от пользователя, устанавливающего продукт, создать надежный пароль в начале процесса установки. Предоставление ограниченных по времени паролей настройки, которые отключаются автоматически после завершения процесса настройки и требуют настройки безопасного пароля (или более безопасных подходов к аутентификации, таких как устойчивая к фишингу многофакторная аутентификация). Требуется физический доступ для первоначальной настройки и указания уникальных учетных данных экземпляра. Проведение кампаний или предложение обновлений, которые переводят существующие развертывания с паролей по умолчанию на более безопасные механизмы аутентификации. Ресурсы: CISA Secure by Design Pledge (пароли по умолчанию), SSDF PW.9.1, Оповещение CISA Default Passwords Secure by Design Alert . Наличие известных эксплуатируемых уязвимостей Выпуск продукта, используемого в обслуживании критической инфраструктуры или NCF, который на момент выпуска включает компонент, содержащий эксплуатационную уязвимость, представленную в каталоге известных эксплуатируемых уязвимостей (KEV) CISA , является опасным и значительно повышает риск для национальной безопасности, национальной экономической безопасности, а также для национального общественного здравоохранения и безопасности. Кроме того, если новый KEV, влияющий на продукт, опубликован в каталоге CISA, невыпуск исправления бесплатно для его пользователей своевременно, если KEV является эксплуатируемым в продукте, или невыполнение публичного документирования наличия уязвимости, если KEV не является эксплуатируемым в продукте, является опасным и значительно повышает риск для национальной безопасности, национальной экономической безопасности, а также для национального общественного здравоохранения и безопасности. Рекомендуемые действия: Производители программного обеспечения должны исправить все известные эксплуатируемые уязвимости в компонентах программного обеспечения до выпуска. В случае публикации нового KEV в каталоге CISA производитель должен своевременно выпустить исправление бесплатно для своих пользователей (ни при каких обстоятельствах не позднее, чем за 30 дней) и четко предупредить пользователей о связанных с этим рисках, если не установить исправление. Если производитель считает, что KEV не может быть использован в его продукте (например, потому что KEV можно использовать только через функцию, которая никогда не вызывается), производитель должен публично опубликовать письменную документацию, подтверждающую наличие KEV и объясняющую, почему его нельзя использовать в его продукте.[2] Ресурсы: CISA Secure by Design Pledge (исправления безопасности), SSDF PW.4.4, Обязательная операционная директива 22-01 . Наличие программного обеспечения с открытым исходным кодом с известными уязвимостями, которые можно использовать Выпуск продукта, используемого для обслуживания критической инфраструктуры или NCF, который на момент выпуска включает компоненты программного обеспечения с открытым исходным кодом, имеющие известные уязвимости, которые можно эксплуатировать, является опасным и значительно повышает риск для национальной безопасности, национальной экономической безопасности, а также для национального общественного здравоохранения и безопасности.[3] Кроме того, если впоследствии будут раскрыты уязвимости, которые можно эксплуатировать, во включенных компонентах с открытым исходным кодом, невыпуск исправления или другого бесплатного средства смягчения для пользователей продукта в своевременные сроки является опасным и значительно повышает риск для национальной безопасности, национальной экономической безопасности, а также для национального общественного здравоохранения и безопасности. Рекомендуемые действия: Производители программного обеспечения должны ответственно потреблять и устойчиво вносить вклад в программное обеспечение с открытым исходным кодом, от которого они зависят. Это включает в себя принятие разумных усилий для оценки и защиты зависимостей своего программного обеспечения с открытым исходным кодом, предпринимая следующие действия:[4] Ведение спецификации программного обеспечения (SBOM), описывающей все зависимости основного и стороннего программного обеспечения, как с открытым исходным кодом, так и проприетарного, и возможность предоставления ее клиентам. Наличие установленного процесса управления внедрением программного обеспечения с открытым исходным кодом, включая принятие разумных мер для: Запускать инструменты сканирования безопасности для каждого выбранного компонента программного обеспечения с открытым исходным кодом, включая его зависимости и транзитивные зависимости, а также для каждой последующей версии при ее обновлении. Выбирайте проекты программного обеспечения с открытым исходным кодом, которые хорошо поддерживаются, и — при необходимости — вносите вклад в текущую поддержку проекта для поддержания ожидаемого стандарта качества. Оцените альтернативы, чтобы определить и выбрать наиболее защищенный и обслуживаемый вариант. Загружайте артефакты проектов программного обеспечения с открытым исходным кодом из репозиториев пакетов (или других соответствующих источников), которые соответствуют лучшим практикам безопасности . Регулярно отслеживайте наличие распространенных уязвимостей и рисков (CVE) или других оповещений, связанных с безопасностью, таких как окончание жизненного цикла, во всех зависимостях программного обеспечения с открытым исходным кодом и обновляйте их по мере необходимости. Кэшируйте копии всех зависимостей с открытым исходным кодом в собственных системах сборки производителя и не обновляйте продукты или клиентские системы напрямую из непроверенных общедоступных источников. Включение стоимости обновления до новых основных версий зависимостей стороннего программного обеспечения с открытым исходным кодом в мероприятия по бизнес-планированию и обеспечение того, чтобы такие зависимости продолжали получать необходимые исправления безопасности в течение ожидаемого срока службы продукта. Ресурсы: SSDF PW.4.4, Рекомендуемые практики ESF по управлению программным обеспечением с открытым исходным кодом и спецификации программного обеспечения , Определение и руководство по программному офису с открытым исходным кодом (OSPO) группы TODO . Функции безопасности Отсутствие многофакторной аутентификации Для продуктов, используемых в обслуживании критической инфраструктуры или NCF, которые аутентифицируют пользователей, отсутствие поддержки многофакторной аутентификации (MFA) в базовой версии продукта является опасным и значительно повышает риск для национальной безопасности, национальной экономической безопасности, а также национального общественного здравоохранения и безопасности. Кроме того, продукты, которые не включают MFA по умолчанию для учетных записей администраторов после 1 января 2026 года, опасны и значительно повышают риск для национальной безопасности, национальной экономической безопасности и национального общественного здравоохранения и безопасности. Это не относится к продуктам, у которых объявленная дата окончания поддержки до 1 января 2028 года. Рекомендуемое действие: Производители программного обеспечения должны либо поддерживать MFA изначально в продукте (если продукт сам обрабатывает аутентификацию), либо поддерживать в базовой версии продукта использование внешнего поставщика удостоверений, например, через единый вход. Требовать MFA для администраторов. Ресурсы: CISA Secure by Design Pledge (многофакторная аутентификация), SSDF PW.9. Отсутствие возможности сбора доказательств вторжений Для продуктов, используемых в обслуживании критической инфраструктуры или NCF, опасно и значительно повышает риск для национальной безопасности, национальной экономической безопасности, а также здоровья и безопасности населения в стране не предоставлять клиентам артефакты и возможности в базовой версии продукта, достаточные для сбора доказательств распространенных форм вторжений, влияющих на продукт, которые как минимум включают: Изменение конфигурации или чтение параметров конфигурации; Идентификация (например, вход в систему и создание токенов) и сетевые потоки, если применимо; а также Доступ к данным или создание бизнес-значимых данных. Рекомендуемые действия: В рамках базовой версии продукта производители программного обеспечения должны предоставлять журналы в стандартном отраслевом формате, относящиеся как минимум к перечисленным выше областям. Для поставщиков облачных услуг и продуктов SaaS производители программного обеспечения должны хранить журналы в течение установленного периода времени (не менее 6 месяцев) без дополнительной платы. Ресурсы: CISA Secure by Design Pledge (доказательства вторжений). Организационные процессы и политики Несвоевременная публикация CVE с CWE Для продуктов, используемых в обслуживании критической инфраструктуры или NCF, опасно и значительно повышает риск для национальной безопасности, национальной экономической безопасности и национального общественного здравоохранения и безопасности, если производитель программного обеспечения не выпустит CVE своевременно, как минимум, для всех критических или высокоэффективных уязвимостей (обнаруженных как внутри компании, так и третьей стороной). Кроме того, опасно и значительно повышает риск для национальной безопасности, национальной экономической безопасности и национального общественного здравоохранения и безопасности, если не включить поле CWE в каждую запись CVE. Рекомендуемые действия: Производители программного обеспечения должны своевременно публиковать полные CVE, включая соответствующее поле CWE, для всех критических или имеющих высокое влияние уязвимостей. Ресурсы: CISA Secure by Design Pledge (CVEs), SSDF RV.1.3. Неопубликованная политика раскрытия информации об уязвимостях Для продуктов, используемых в обслуживании критической инфраструктуры или NCF, отсутствие опубликованной политики раскрытия уязвимостей (VDP), которая включает продукт в свою сферу применения, является опасным и значительно повышает риск для национальной безопасности, национальной экономической безопасности, а также здоровья и безопасности населения в стране. Рекомендуемые действия: Производители программного обеспечения должны опубликовать VDP, который: Разрешает проведение испытаний представителями общественности продукции, предлагаемой производителем; Обязуется не рекомендовать и не возбуждать судебные иски против любого лица, добросовестно прилагающего усилия по соблюдению Программы добровольного развития, Предоставляет четкий канал для сообщения об уязвимостях; и Позволяет публично раскрывать информацию об уязвимостях в соответствии с передовой практикой скоординированного раскрытия информации об уязвимостях (CVD) и международными стандартами. Производители программного обеспечения должны своевременно устранять все выявленные уязвимости с учетом степени риска. Ресурсы: CISA Secure by Design Pledge (Политика раскрытия уязвимостей), SSDF RV.1.3, ISO 29147. [1] Перечень распространенных слабостей. [2] В идеале документация должна быть опубликована в формате, пригодном для машинной обработки, через Vulnerability Exploitability eXchange (VEX). [3] Критические уязвимости определяются как уязвимости с оценкой Common Vulnerability Scoring System (CVSS) 9,0 или выше. [4] Организации могут принять решение о создании офиса программ с открытым исходным кодом (OSPO) для централизации этой деятельности. Ресурсные материалы Неправильная практика обеспечения безопасности продукта — 508c PDF , 755,21 КБ Английский Теги Язык : английский Темы : Безопасность и устойчивость критической инфраструктуры , Киберугрозы и рекомендации , Лучшие практики кибербезопасности , Многофакторная аутентификация , Организации и кибербезопасность , Услуги по обеспечению устойчивости , Защита сетей Связанные ресурсы 01 ОКТ. 2024 Г. ВНЕШНИЙ, ПУБЛИКАЦИЯ Принципы кибербезопасности операционных технологий 20 НОЯБРЯ 2024 Г. ПУБЛИКАЦИЯ История успеха многофакторной аутентификации (MFA), устойчивой к фишингу: внедрение USDA Fast IDentity Online (FIDO) 26 ИЮНЯ 2024 Г. Изучение безопасности памяти в критически важных проектах с открытым исходным кодом 20 ИЮНЯ 2024 Г. Препятствия к внедрению единого входа (SSO) для малого и среднего бизнеса: выявление проблем и возможностей Вернуться наверх Темы В центре внимания Ресурсы и инструменты Новости и события Карьера О Агентство по кибербезопасности и безопасности инфраструктуры Фейсбук Твиттер LinkedIn Ютуб Инстаграм RSS CISA Центральный 1-844-Сэй-CISA СкажитеCISA@cisa.dhs.gov Печать DHS CISA.gov Официальный сайт Министерства внутренней безопасности США О CISA Бюджет и производительность DHS.gov Равные возможности и доступность Запросы FOIA Закон «Нет страху» Офис Генерального инспектора политика конфиденциальности Подписаться Белый дом USA.gov Обратная связь с сайтом

Здравствуйте, Артём, Вы писали:

Аё>Господа, это песец, я считаю, — но если требованием сертификата соответствия продукта станет минимизация количества нативного кода- то компаниям ничего не остаётся делать.

Наконец-то Firefox на Rust перепишут?

Здравствуйте, Nuzhny, Вы писали:

N>Наконец-то Firefox на Rust перепишут?

Вряд ли. Может новый напишут с нуля, но потом.

Здравствуйте, Артём, Вы писали:

Аё>Американское агентство по кибербезопасности и инфраструктуре (оказывается, и такое бывает) требует явного запрета на C/C++ там, где существует "memory-safe" альтернатива. Запрет в новых продуктах, и требует роадмап на переписывание существующих продуктов.

Аё>Господа, это песец, я считаю, — но если требованием сертификата соответствия продукта станет минимизация количества нативного кода- то компаниям ничего не остаётся делать.

Давно пора. У вас были десятилетия на исправление языка или переход на другие языки. А вы чем занимались, бизнесовали? Бизнес-велью ковали куем?

Здравствуйте, Shmj, Вы писали:

N>>Наконец-то Firefox на Rust перепишут?
S>Вряд ли. Может новый напишут с нуля, но потом.

У них же servo уже полностью на rust. Может, ускорятся.

Здравствуйте, velkin, Вы писали:

V>Я уже даже представил, как владельцы сайтов живущие в России шкерятся в глубоком вебе.

V>Россиянин.
V>- А я не написал политику конфиденциальности на сайте.

А можно тут поподробнее, а то не очень понятно, о чем речь

1,5 месяца назад обсуждалось https://rsdn.org/forum/flame.comp/8848998.1

Здравствуйте, пффф, Вы писали:

V>>Россиянин.
V>>- А я не написал политику конфиденциальности на сайте.
П>А можно тут поподробнее, а то не очень понятно, о чем речь

Первая попавшаяся ссылка.
https://journal.tinkoff.ru/news/personal-data-zakon/

Появилась уголовная ответственность за незаконное использование и передачу, сбор и хранение компьютерной информации, содержащей персональные данные. Наказание — штраф в размере 300 000—400 000 р или принудительные работы на срок до четырех лет, либо лишение свободы на срок до четырех лет.

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

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

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

Ещё я писал статью на эту тему.
Электронная почта и номер телефона это дыра в безопасности сайта (17.11.2024)

Самое тупое, что под персональные данные подводят не только фио и адрес проживания, но и адрес электронной почты, то есть выдуманный логин от почты на левом сайте, или статический ip адрес пользователя, или куки, которые хранит даже не сервер.

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

Это же выгода три в одном.

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

2. Собрать штрафы на войну, причём без понимания, что у людей нет ни 30 млн. рублей, ни тем более 300 млн. рублей.

3. Вербовка в армию уголовников. Причём кто-то думает, что я тут пишу юмор, типа преувеличение и всё такое. Нет, правительство России действительно приняли такие законы.

При этом в России десятилетиями убивают учёных и бизнесменов.

Очередной "засекреченный" случай.
СМИ: в Подмосковье убили разработчика крылатых ракет

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

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

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

Здравствуйте, Shmj, Вы писали:

S>C++ еще не удобен тем, что его сложно анализировать тому же GPT, в особенности когда дело касается компил-таймовых вещей.

кто о чём, а вшивый о бане

Здравствуйте, sergii.p, Вы писали:

S>>C++ еще не удобен тем, что его сложно анализировать тому же GPT, в особенности когда дело касается компил-таймовых вещей.
SP>кто о чём, а вшивый о бане

GPT вполне сносно может переводить простые языки. А вот плюсы с компил-таймом — часто спотыкается. Теряется контроль — люди как бы становятся незаменимыми.

Это хорошо для работников, но плохо для господ.

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

S>GPT вполне сносно может переводить простые языки.

И в чем бизнес вэлью этой деятельности?

Здравствуйте, Muxa, Вы писали:

S>>GPT вполне сносно может переводить простые языки.
M>И в чем бизнес вэлью этой деятельности?

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

C++ не получится перевести автоматом и это ломает планы, теряется контроль.

Здравствуйте, Артём, Вы писали:

Аё>Американское агентство по кибербезопасности и инфраструктуре (оказывается, и такое бывает) требует явного запрета на C/C++ там, где существует "memory-safe" альтернатива. Запрет в новых продуктах, и требует роадмап на переписывание существующих продуктов.

А на каком основании оно хочет что либо требовать?

Аё>Американское агентство по кибербезопасности и инфраструктуре (оказывается, и такое бывает)
Founded: November 16, 2018
Небойсь специально его основали, чтобы С++ изгнать.

Аё>Американское агентство по кибербезопасности и инфраструктуре (оказывается, и такое бывает) требует явного запрета на C/C++ там, где существует "memory-safe" альтернатива. Запрет в новых продуктах, и требует роадмап на переписывание существующих продуктов.

Где ты там увидел запрет? Требуется roadmap на повышение безопасности.
И про этот roadmap написано в отдельном документе (который ещё в прошлом году обсужали на RSDN).
https://www.cisa.gov/sites/default/files/2023-12/The-Case-for-Memory-Safe-Roadmaps-508c.pdf

Использование memory safe languages (MSL) лишь один из путей повышения безопасности.
Там даже написано:

MSLs, whether they use a garbage collection model or not, will almost certainly need to rely on libraries written in languages such as C and C++.
Although there are efforts to re-write widely used libraries in MSLs, no such effort will be able to re-write them all anytime soon.
For the foreseeable future, most developers will need to work in a hybrid model of safe and unsafe programming languages.
Developers who start writing in an MSL will need to call C and C++ libraries that are not memory safe.

_>А на каком основании оно хочет что либо требовать?

Как регулятор. Введут в обязательный набор требований ТЗ для гос.заказа и т.п.

Здравствуйте, m2user, Вы писали:

M>Как регулятор. Введут в обязательный набор требований ТЗ для гос.заказа и т.п.

Так это автономное федеральное агентство США. К остальным какое это отношение имеет. Всем кто против санкции?
Более того помимо небезопасных языков, есть небезопасные оси и небезопасное железо, и даже не безопасные производители и не безопасные поставщики. Короче кругом враги.

От:	Артём	жж
Дата:	13.12.24 06:08
Оценка:	1 (1)

	От:	Muxa
	Дата:	13.12.24 06:16
	Оценка:	+2 -1

	От:	Shmj
	Дата:	13.12.24 07:04
	Оценка:

От:	velkin	https://kisa.biz
Дата:	13.12.24 07:21
Оценка:

От:	Nuzhny	https://github.com/Nuzhny007
Дата:	13.12.24 07:34
Оценка: