Перейти к содержанию

В Северной Корее завершена разработка национальной ОС


Евгений Малинин

Рекомендуемые сообщения

Сегодня власти Северной Кореи сообщили о завершении работы над новой версией собственной Linux-подобной операционной системой Red Star Linux. В официальном заключении сертификационной комиссии при Северокорейском институте наук и технологий говорится, что версия 1.1 этой ОС создана "чтобы защитить пользователей от внешних атак".

 

Те немногие независимые пользователи, что видели Red Star утверждают, что основная цель этой ОС - не допустить выхода немногочисленных северокорейских интернет-пользователей на пределы такого же немногочисленного северокорейского интернета. Система сделана таким образом, что выйти в интернет можно только через местный интернет-портал, называемый формально поисковым сервисом, но по факту представляющий собой онлайновую доску объявлений, аналогичную тем, что были популярны в середине 90-х.

 

Доступ информации извне здесь ограничен и пользователям остается довольствоваться только теми данными, что поставляет агентство ЦТАК (Центральное телеграфное агентство Кореи).

 

Напомним, что первая версия этой ОС была выпущена еще в начале 2000 годов. Red Star представляет собой полностью открытую ОС, которая внешне практически идентична Microsoft Windows. Здесь также есть иконка старта в левом нижнем углу, присутствуют иконки "Мой компьютер" и "Корзина", знакомые всем пользователям Windows. Однако здесь присутствует и "фирменная" разработка - браузер "Моя страна". Из названия понятно, как именно он позволяет работать с теми или иными ресурсами в сети.

 

Несмотря на то, что ОС является открытой, продаваться в стране она будет за деньги. На первом диске будет присутствовать сама система и графическая оболочка, на втором диске - офисные программы и дополнительный софт. Стоимость дисков в переводе на доллары составит 5 и 10 долларов соответственно.

 

© http://www.securitylab.ru/news/392579.php

Ссылка на комментарий
Поделиться на другие сайты

Пожалуйста, войдите, чтобы комментировать

Вы сможете оставить комментарий после входа в



Войти
  • Похожий контент

    • KL FC Bot
      От KL FC Bot
      Уже сегодня технологии на базе ИИ внедрены в каждой второй компании, а за ближайшие два года к ним присоединится еще 33% коммерческих организаций. ИИ в том или ином виде будет внедрен повсеместно. Экономический эффект, который получают компании от внедрения, варьируется от повышения удовлетворенности клиентов до прямого роста выручки. По мере того как понимание сильных и слабых сторон ИИ-систем бизнесом будет углубляться, эффективность только увеличится. Но уже сейчас очевидно, что о рисках, которые несет внедрение ИИ, нужно подумать заранее.
      Даже ранние примеры внедрения демонстрируют, что цена ошибки ИИ-системы может быть высока и может выражаться в том числе во влиянии на репутацию, отношения с клиентами, здоровье пациентов и многое другое. А если учесть еще и киберфизические системы вроде автономных автомобилей, то вопросы безопасности станут еще острее.
      Внедрять безопасность постфактум, как это было с предыдущими поколениями технологий, будет дорого и порой невозможно. Чтобы в этом убедиться, достаточно найти свежие оценки ущерба, который мировой экономике наносит киберпреступность: на 2023 год это $8 трлн. Неудивительно, что страны, претендующие на технологическое лидерство в XXI веке, торопятся внедрить регулирование ИИ (например, China’s AI Safety Governance Framework, EU AI Act, US Executive Order on AI). Но в законах редко указываются технические подробности и практические рекомендации — это не их задача. Поэтому для практического применения любых регуляторных требований формата «обеспечить надежность и этичность ИИ, а также контролируемость его решений» необходимы конкретные практические рекомендации, позволяющие достичь этого результата.
      Чтобы помочь практикам, внедряющим ИИ уже сегодня, а также сделать будущее нашего мира более безопасным, специалисты «Лаборатории Касперского» при участии Эллисон Вайлд, члена команды по функциональной совместимости Сети по вопросам политики в области искусственного интеллекта Форума ООН по управлению Интернетом; доктора Мелодены Стивенс, профессора управления инновациями и технологиями школы государственного управления имени Мохаммеда бин Рашида; и Серхио Майо Масиаса, менеджера инновационных программ из Технологического института Арагона, создали набор рекомендаций. Документ был представлен в ходе семинара «Кибербезопасность в сфере ИИ: баланс между инновациями и рисками» на 19-м ежегодном Форуме по управлению Интернетом (UN Internet Governance Forum, IGF) для обсуждения с международным сообществом формирующих политику работы с AI экспертов.
      Следование описанным в документе практикам поможет инженерам, специалистам DevOps и MLOps, которые разрабатывают и затем эксплуатируют ИИ-решения, достичь высокого уровня защищенности и безопасности ИИ-систем на всех этапах их жизненного цикла. Рекомендации документа нужно индивидуально оценивать для каждого внедрения ИИ, поскольку их применимость зависит от разновидности ИИ и модели внедрения.
      Какие риски нужно учесть
      Многообразие применений ИИ вынуждает организацию учитывать очень разнородные риски:
      Риск от неиспользования ИИ. Звучит на первый взгляд забавно, но только сравнив выигрыш и потери компании от внедрения ИИ, можно правильно оценивать все остальные риски. Риски несоответствия регулированию. Быстро развивающееся регулирование ИИ делает этот риск динамичным, его нужно часто оценивать заново. Кроме регулирования ИИ как такового, нужно учитывать сопутствующие риски, например нарушения законов по обработке персональных данных. ESG-риски, то есть социально-этические риски применения ИИ, риски раскрытия чувствительной информации и риски для экологии. Риск нецелевого использования ИИ-сервисов пользователями — от шуточных до злонамеренных сценариев. Угрозы ИИ-моделям и наборам данных, применявшимся в тренировке. Угрозы сервисам компании, возникающие при внедрении ИИ. Возникающие при этом угрозы данным, которые обрабатываются в рамках этих сервисов. При этом «под капотом» трех последних групп рисков находятся все угрозы и задачи, традиционные для ИБ в сложных облачных инфраструктурах: контроль доступа и сегментация, управление уязвимостями и обновлениями, создание систем мониторинга и реагирования, контроль цепочек поставок.
       
      View the full article
    • kmscom
      От kmscom
      Совсем недавно Дмитрий Шмойлов., руководитель отдела безопасности программного обеспечения «Лаборатории Касперского», дал интервью для AM life о безопасной разработке, а именно:
      о важности взращивания собственных лидеров безопасности (Security Champions) проблемах выявления и устранения уязвимостей плюсах и минусах открытого кода Читать интервью: https://kas.pr/9e96
    • Avito
      От Avito
      Посмотрите пожалуйста правильно ли прошла установка?
      KasperskyOS-Community-Edition_1.1.1.40_en.deb

       
      Сообщение от модератора kmscom Дубль https://forum.kaspersky.com/topic/kasperskyos-установка-sdk-разработка-36717/#comment-147861
      здесь нет профильных специалистов Закрыто  
    • KL FC Bot
      От KL FC Bot
      Современные крупные IT-системы практически всегда используют ту или иную форму виртуализации или контейнеризации. Контейнеры несут массу преимуществ как при разработке системы, так и при ее установке, сопровождении и использовании. Это приводит к ускорению разработки, экономии денег и других ресурсов. При этом к контейнерам напрямую неприменимы многие подходы, работающие при защите физических и виртуальных серверов. Какие риски нужно учесть, внедряя контейнеризацию в организации, и какими мерами защищать контейнерную инфраструктуру?
      Чем выгодна контейнеризация в разработке и эксплуатации
      Контейнер — это изолированная среда для запуска одного приложения, создаваемая средствами на уровне ядра ОС. В образ контейнера входит как приложение, так и необходимые ему настройки и вспомогательные компоненты, поэтому разработчикам крайне удобно запаковать в контейнер все необходимое, а тем, кто использует такой контейнер, гораздо проще его эксплуатировать. Ну а изоляция значительно уменьшает влияние контейнеризованных приложений друг на друга. Поэтому в контейнерной инфраструктуре меньше причин для сбоев и выше подконтрольность всего происходящего для администраторов.
      Контейнеризация является более легкой технологией, чем виртуализация: в контейнерах не эмулируется оборудование и нет нужды поставлять полное содержимое виртуальной машины, в частности гостевую ОС. Во многих случаях контейнеризованные нагрузки проще масштабировать.
      Наиболее распространенным инструментом для создания и хранения образов контейнеров, безусловно, является Docker, а оркестрацию контейнерных нагрузок чаще всего реализуют при помощи Kubernetes, Docker Swarm или Red Hat OpenShift.
      Контейнеризация стала важной составной частью современных подходов к IT-разработке. Многие приложения разрабатываются в микросервисной архитектуре: отдельные функции большого приложения выделяются в микросервисы, которые общаются с другими частями приложения по API. Примером может служить видеоплеер внутри социальной сети или процесс оплаты в интернет-магазине. Эти микросервисы зачастую поставляются в виде контейнеров, что позволяет разработчикам иметь собственный цикл разработки и доставки.
      Контейнеры прекрасно вписались в современную методологию непрерывной интеграции и развертывания (CI/CD, continuous integration, continuous delivery), помогающую выпускать обновления приложений быстрее и с меньшим числом ошибок. Этот подход предусматривает короткий цикл разработки, параллельную работу команд над одним кодом, автоматизацию рутинных действий. Применение контейнеризации в конвейере CI/CD тоже повышает эффективность этого конвейера: система CI/CD использует образы контейнеров в качестве шаблонов и доставляет сборку в виде готового к развертыванию образа. Принципиальным моментом является то, что обновление поставляется в виде нового образа, а не разворачивается внутри существующего и эксплуатируемого контейнера. В результате ускоряются подготовка и отладка релиза, снижаются требования к инфраструктуре разработчика и заказчика, повышается стабильность работы и облегчается масштабирование приложения.
      Если грамотно внедрить требования контейнерной безопасности в процесс разработки и сборки, то это существенно продвинет организацию на пути к полноценной реализации методологии DevSecOps.
       
      Посмотреть статью полностью
    • Илья_20098
      От Илья_20098
      Здравствуйте, решил полностью проверить ПК (windows 11) после проверки было обнаружено пару угроз некоторые были удалены а некоторые были помешены в карантин. Всё бы нечего но одна угроза "HackTool:Win32/Keygen"была не удалена а "Ис правление не завершено" под предлогом "СБОЙ КАРАНТИНА" прикрепил скриншот. Все процессы тоже .


×
×
  • Создать...