Средняя
- Теги: История кибербезопасности, Modula, C, KSOS, Secure UNIX
В современном мире IT кажется, что все инновации рождаются здесь и сейчас. Мы смотрим на новые языки программирования, восхищаемся микроядрами и верим, что концепция «безопасности по умолчанию» — это исключительно заслуга последних пяти-десяти лет. Особенно много шума в последние годы вокруг языка Rust, который сделал строгую типизацию и безопасность памяти «модными» и буквально обязательными для серьёзных проектов.
Но что, если я скажу вам, что задолго до того, как Rust стал мейнстримом, а концепция формальной верификации ядер ОС начала обсуждаться на каждом углу, Министерство обороны США уже создавало операционные системы, которые реализовывали эти принципы? Более того, эти системы не были просто пыльными академическими экспериментами — они стояли на страже государственной кибер безопасности и использовались в реальных боевых и разведывательных операциях.
Недавно в архивах The Unix Heritage Society (TUHS) был рассекречен и выложен в открытый доступ исходный код KSOS (Kernelized Secure Operating System). Это событие — не просто повод для ностальгии по ретро-вычислениям. Это важнейший исторический артефакт, который показывает, как эволюционировала сетевая безопасность, как менялись подходы к мониторингу сети и управлению рисками, и почему идеи, заложенные в 1970-х годах, до сих пор актуальны для современных архитекторов систем защиты.
В этой статье мы подробно разберём историю KSOS, погрузимся в технические детали использования языка Modula вместо C, обсудим магию формальной верификации и, наконец, проведём параллель между военными ОС сорокалетней давности и современными системами мониторинга сети.
Содержание
- Часть 1. Призрак из прошлого: что такое KSOS и зачем он был нужен?
- Часть 2. Modula против C: битва за строгую типизацию, которая длилась десятилетиями
- Часть 3. Формальная верификация: доказательство безопасности вместо надежды на авось
- Часть 4. От изолированных узлов к глобальной паутине: эволюция угроз
- Часть 5. Мониторинг сети и управление рисками: глаза и уши современной кибербезопасности
- Часть 6. Архивы TUHS: почему важно помнить прошлое, чтобы строить будущее?
- Часть 7. Практические выводы: как использовать уроки истории в современной архитектуре?
- Заключение: цикличность истории и будущее сетевой безопасности
Часть 1. Призрак из прошлого: что такое KSOS и зачем он был нужен?
Чтобы понять феномен KSOS, нужно перенестись в конец 1970-х годов. Холодная война в разгаре, гонка вооружений включает не только создание новых ракет, но и разработку систем управления ими. Компьютеры перестают быть просто «электронными вычислительными машинами» для расчёта баллистических таблиц и становятся критической инфраструктурой для обработки секретных данных.
Именно в этот период перед Министерством обороны (DoD) США встала сложнейшая задача: как обрабатывать данные разного уровня секретности на одном и том же оборудовании, не допуская утечек? Стандартный Unix, который в то время набирал популярность, был хорош для всего, но не для безопасности. Его архитектура предполагала, что пользователь, получивший доступ к системе, имеет определённые привилегии, но не была спроектирована для жёсткого разделения потоков данных с разным грифом секретности.
Рождение Secure UNIX
Проект, который позже станет известен как KSOS, стартовал в 1978 году в недрах Ford Aerospace (да, того самого Ford, который делал автомобили). Команда разработчиков столкнулась с необходимостью создать операционную систему, которая была бы совместима с Unix (чтобы использовать существующую экосистему утилит), но при этом обладала бы математически доказуемым уровнем безопасности.
Изначально система называлась Secure UNIX, но позже была переименована в KSOS — Kernelized Secure Operating System (Ядерная безопасная операционная система). Как позже описывал основатель TUHS Уоррен Туми (Warren Toomey), KSOS была предназначена для обеспечения «доказуемо безопасной операционной системы для больших миникомпьютеров».
В команде работали выдающиеся инженеры. Например, Питер Нойман (Peter Neumann), который позже стал легендарным благодаря созданию рассылки RISKS Digest, документирующей риски в компьютерных системах. Другим ключевым фигурантом был Том Перрин (Tom Perrine), который в 2002 году написал для журнала USENIX отличную статью о KSOS, а в 2012 году выступил с докладом о ней на главной хакерской конференции мира — DEF CON 20.
От академии к реальному бою
Важно понимать: KSOS не был «игрушкой». Это была полноценная, производственная система. Изначально созданная для архитектуры PDP-11, а позже портированная на VAX (в версии KSOS-32), она использовалась в так называемых «системах понижения доверия» (Trusted Downgrade System).
Эти системы были частью многоступенчатых разведывательных комплексов «all-source» (анализ всех источников данных), которые компания Logicon создавала для различных ведомств США. Системы с кодовыми названиями ACCAT-GUARD и USAFE-GUARD обрабатывали секретнейшие данные, и KSOS выступал в роли надёжного фундамента, гарантирующего, что информация с грифом «Совершенно секретно» никогда не просочится в каналы, предназначенные для данных с грифом «Для служебного пользования».
KSOS имел супервизорный режим, совместимый с системными вызовами UNIX, а также пользовательскую библиотеку, которая эмулировала эти вызовы. При этом, что критически важно, в нем не было ни строчки общего кода с оригинальным ядром UNIX. Это была полностью переписанная, безопасная с нуля реализация.
Часть 2. Modula против C: битва за строгую типизацию, которая длилась десятилетиями
Одной из самых интригующих особенностей KSOS является выбор языка программирования. В то время как весь мир Unix развивался на языке C, создатели KSOS сделали радикальный выбор в пользу языка Modula, созданного никлаусом Виртом (Niklaus Wirth).
Почему не C? Проблема, которую мы решаем до сих пор
Язык C, созданный в начале 1970-х, был шедевром прагматизма. Он давал программисту доступ к «железу», позволял манипулировать памятью напрямую и работал невероятно быстро. Но у этой медали была обратная сторона: C не обеспечивал безопасность памяти и строгую типизацию. Указатели можно было приводить к любым типам, выход за границы массива не проверялся, а переполнение буфера было не багом, а «особенностью».
Именно эти «особенности» языка C стали причиной подавляющего большинства уязвимостей в кибер безопасности за последние 40 лет. Переполнение буфера, использование освобожденной памяти (use-after-free), утечки указателей — все это порождения философии C, которая гласит: «Программист всегда прав, даже когда он не прав».
Modula: Строгость как основа безопасности
Никлаус Вирт, создав язык Pascal, а затем его более мощного наследника Modula (и позже Modula-2), пошел другим путем. Философия Вирта заключалась в том, что язык должен защищать программиста от его же ошибок. Modula предлагал строгую типизацию, модульность и, что самое важное для KSOS, механизмы, позволяющие изолировать части системы друг от друга на уровне самого языка.
Использование Modula для написания ядра ОС было беспрецедентным шагом. Это позволяло реализовать концепцию type safety (безопасности типов) задолго до того, как это стало мейнстримом. В контексте KSOS это означало, что ядро могло математически гарантировать, что модуль, обрабатывающий секретные данные, физически не сможет передать их модулю, работающему с несекретными данными, потому что типы данных и права доступа были жестко заданы на этапе компиляции.
Наследие Modula в современном Rust
Когда мы сегодня читаем восторженные статьи о языке Rust и его «borrow checker», который предотвращает утечки памяти и гонки данных (data races) на этапе компиляции, мы по сути читаем современную интерпретацию идей, заложенных в Modula полвека назад.
Rust сделал безопасность памяти модной и коммерчески успешной. Проекты вроде Asterinas (новый микроядерный проект на Rust) или интеграция Rust в ядро Linux доказывают, что индустрия наконец созрела для отказа от небезопасного C. Но KSOS доказывает, что эта идея витала в воздухе еще в 1978 году. Разница лишь в том, что тогда экосистема и «железо» (PDP-11) были достаточно нишевыми, чтобы позволить себе такую роскошь, как строгий компилятор, а сегодня, когда сетевая безопасность является вопросом выживания корпораций, строгая типизация становится стандартом де-факто.
Часть 3. Формальная верификация: доказательство безопасности вместо надежды на авось
Вторым, и, пожалуй, самым важным концептуальным прорывом KSOS была ориентация на формальную верификацию. Что это значит и почему это перевернуло представление о том, как должна создаваться кибербезопасность?
Тестирование против Доказательства
Традиционный подход к разработке ПО (и ОС в частности) выглядит так: мы пишем код, затем пишем тесты, прогоняем их и, если тесты проходят, считаем систему безопасной. Но тесты могут доказать лишь наличие багов, но не их отсутствие. Вы можете протестировать миллион сценариев, но хакеру достаточно найти один, неочевидный, чтобы взломать систему.
Формальная верификация — это другой уровень. Это использование математических методов для доказательства того, что исходный код системы точно соответствует ее формальной спецификации. Проще говоря, вы математически доказываете, что в системе не может быть определенных классов уязвимостей.
KSOS была спроектирована именно для такой верификации. Это было невероятно сложно. В конце 1970-х вычислительные мощности для математических доказательств были на порядки меньше современных, но сам концептуальный задел был сделан.
Современные наследники идеи KSOS
Сегодня очень мало операционных системных ядер проходят полную формальную верификацию, потому что это требует колоссальных ресурсов. Но те, что проходят, считаются «золотым стандартом» надежности.
Самый известный современный пример — микроядро seL4. Оно используется в системе Ironclad (о которой мы писали ранее) и в новых RTOS для архитектуры RISC-V, таких как QSOE. SeL4 математически доказуемо изолирует компоненты системы. Если один компонент скомпрометирован, он физически не может повлиять на другие, потому что микроядро не предоставляет ему таких механизмов.
Когда мы говорим о современных проектах, таких как упомянутый Asterinas или еще более новый проект Maestro, мы видим ту же самую философию, что и в KSOS: отказ от «безопасности через неясность» (security through obscurity) в пользу прозрачности, строгой типизации и математического доказательства корректности.
Кстати, на конференции FOSDEM в прошлом году в докладе «Недавнее прошлое, настоящее и долгое будущее конфиденциальных вычислений» (Confidential Computing’s Recent Past, Emerging Present, and Long-Lasting Future) KSOS был упомянут именно в этом контексте. На слайде 8 говорится, что KSOS была «одной из первых ядер, ориентированных на безопасность, с упором на формальную верификацию», и что «исходный код был общедоступным, отвергая ‘безопасность через неясность’».
Часть 4. От изолированных узлов к глобальной паутине: эволюция угроз
История KSOS прекрасна, но возникает резонный вопрос: как операционная система для PDP-11 или VAX, созданная 40 лет назад, связана с современными реалиями? Ведь сегодня мы живём в мире облаков, микросервисов и распределённых сетей.
Ответ кроется в понимании того, как менялась парадигма угроз. В 1970-х и 1980-х годах компьютеры были в основном изолированными или соединены в примитивные локальные сети. Угроза исходила от инсайдеров или от физического доступа к терминалу. Поэтому кибер безопасность того времени фокусировалась на защите самого узла (узла сети), на разграничении прав пользователей внутри одной ОС. KSOS решал именно эту задачу.
Но с развитием интернета и глобальных сетей (в первую очередь, ARPANET, а затем и современного Интернета) периметр защиты исчез. Узел больше не был крепостью; он стал лишь одной из миллионов песчинок в глобальной сети. Угрозы стали сетевыми. Хакеру больше не нужно было физически садиться за терминал VAX — он мог отправить специально сформированный пакет данных через тысячи километров.
Именно здесь на сцену выходит сетевая безопасность. Если KSOS защищал «внутренности» одного компьютера, то современные системы должны защищать коммуникации между миллионами компьютеров, предотвращать несанкционированный доступ по сети и отслеживать аномалии в трафике.
Сетевая безопасность как новый периметр
Сетевая безопасность (Network Security) сегодня — это комплекс мер, направленных на защиту инфраструктуры, данных и ресурсов от несанкционированного доступа, атак и повреждений, происходящих именно по сетевым каналам. Если формальная верификация ядра (как в KSOS или seL4) гарантирует, что мы не можем быть взломаны через уязвимость в самом коде ОС, то сетевая безопасность гарантирует, что даже если злоумышленник найдёт уязвимость в приложении, работающем поверх этой ОС, мы сможем это обнаружить и заблокировать на уровне сети.
Современная сетевая безопасность опирается на несколько столпов:
- Защита периметра (Firewalls, WAF): Фильтрация нежелательного трафика.
- Шифрование (TLS/SSL, VPN): Защита данных от перехвата.
- Сегментация сетей: Разделение сети на изолированные зоны (привет, идеи KSOS о разделении уровней секретности, но применительно к микросегментации в Zero Trust архитектурах!).
- Сетевой мониторинг и анализ угроз: Обнаружение аномалий в реальном времени.
И вот здесь мы подходим к самому важному аспекту современной защиты — непрерывному наблюдению за тем, что происходит в каналах передачи данных.
Часть 5. Мониторинг сети и управление рисками: глаза и уши современной кибербезопасности
Если ядро ОС — это «мозг» и «иммунная система» отдельного компьютера, то мониторинг сети — это центральная нервная система всей корпоративной инфраструктуры. Без понимания того, какие данные, куда и с какой интенсивностью перемещаются, говорить о безопасности бессмысленно.
Что такое мониторинг сети в 2026 году?
Мониторинг сети (Network Monitoring) — это непрерывный процесс сбора, анализа и визуализации данных о состоянии сетевой инфраструктуры и проходящем через неё трафике. Но если в 1990-х годах это был просто подсчёт пакетов и проверка доступности хостов (ping), то сегодня это высокотехнологичная дисциплина.
Современный мониторинг сети включает в себя:
- Глубокий анализ пакетов (Deep Packet Inspection — DPI): Изучение не только заголовков, но и полезной нагрузки пакетов для поиска сигнатур известных атак или аномалий.
- Анализ потоков (NetFlow, sFlow, IPFIX): Сбор статистики о том, кто с кем общается, какие порты используются, каковы объёмы трафика. Это позволяет видеть «карту» сети и выявлять скрытые каналы связи (например, C2-серверы ботнетов).
- Сетевое обнаружение и реагирование (NDR — Network Detection and Response): Использование машинного обучения и поведенческого анализа для выявления угроз, которые обошли традиционные средства защиты. NDR ищет аномалии: например, почему бухгалтер из Москвы вдруг начал скачивать гигабайты данных с сервера разработки в Калифорнии в 3 часа ночи?
- Мониторинг зашифрованного трафика: Поскольку большая часть трафика сегодня зашифрована (TLS 1.3), современные системы учатся анализировать метаданные зашифрованных соединений (JA3/JA4 хеши, время между пакетами, размер пакетов), чтобы выявлять вредоносную активность, не вскрывая само шифрование.
Связь мониторинга и управления рисками
Сам по себе мониторинг сети — это лишь сбор данных. Вы можете иметь петабайты логов и тысячи алертов в день, но если вы не понимаете, как они влияют на бизнес, вы не защищены. Здесь на сцену выходит связка мониторинг сети и управление рисками.
Управление рисками (Risk Management) — это процесс выявления, оценки и приоритизации рисков с последующим применением ресурсов для минимизации, мониторинга и контроля вероятности или воздействия этих рисков.
Как мониторинг сети и управление рисками работают вместе в едином цикле?
- Идентификация активов и угроз (Управление рисками): Мы понимаем, что наш сервер баз данных — это критический актив. Угроза — это утечка данных через SQL-инъекцию или инсайдер.
- Настройка мониторинга (Мониторинг сети): Мы настраиваем NDR и SIEM (Security Information and Event Management) системы на отслеживание специфических паттернов трафика, ведущих к этому серверу, и аномальных объёмов исходящих данных.
- Оценка вероятности и воздействия (Управление рисками): На основе данных мониторинга сети мы оцениваем реальный риск. Если мы видим, что сервер не патчился полгода и к нему открыт доступ из интернета, риск возрастает до критического.
- Митигация и реагирование: Мы принимаем меры: закрываем порт на фаерволе, патчим сервер, или, если атака уже идёт, изолируем сегмент сети.
- Непрерывный мониторинг: Цикл повторяется. Мониторинг сети и управление рисками — это не линейный процесс, а бесконечная спираль адаптации к меняющейся обстановке.
Уроки KSOS для современных систем мониторинга
Что мы можем взять из истории KSOS для современных систем, обеспечивающих мониторинг сети и управление рисками?
- Во‑первых, принцип минимальных привилегий и микросегментации. KSOS жёстко разделял потоки данных. В современных сетях мы используем Zero Trust архитектуру, где каждый микросервис, каждый контейнер должен доказывать своё право на общение с другим. Мониторинг сети в таких архитектурах усложняется, но становится невероятно точным: любое отклонение от разрешённой «белой» схемы трафика является инцидентом.
- Во‑вторых, отказ от безопасности через неясность. KSOS был открыт для анализа (насколько это было возможно в те годы), и его безопасность базировалась на математике, а не на секретности алгоритмов. Современные системы мониторинга сети должны предполагать, что злоумышленник знает нашу инфраструктуру. Поэтому мы используем открытые стандарты (например, OpenTelemetry для сбора телеметрии) и фокусируемся на качестве данных и скорости реакции, а не на том, чтобы «спрятать» свои логи.
- В‑третьих, важность доверенной базы (Trusted Base). KSOS был «доверенной» ОС. В современном мониторинге сети критически важно, чтобы сами агенты мониторинга, сенсоры NDR и коллекторы логов работали на доказуемо безопасных, верифицированных системах. Если хакер скомпрометирует саму ОС, на которой работает SIEM, он сможет скрыть любые следы своего присутствия в сетевом трафике. Поэтому возвращение к идеям формальной верификации (как в seL4) для критической инфраструктуры безопасности — это не просто дань истории, а насущная необходимость.
Часть 6. Архивы TUHS: почему важно помнить прошлое, чтобы строить будущее?
История возвращения KSOS из небытия сама по себе является захватывающим триллером, который показывает важность сохранения цифрового наследия.
The Unix Heritage Society Inc. (TUHSI) — это некоммерческая ассоциация, зарегистрированная в Виктории, Австралия. Их миссия может показаться узкоспециализированной, но она критически важна для всей индустрии: сохранение и поддержка исторических артефактов UNIX, а также предоставление площадки для обсуждения истории Unix и его влияния на современный мир.
Волонтёры TUHS делают титаническую работу. Они восстанавливают повреждённые магнитные ленты, декодируют древние форматы файлов и оцифровывают документацию. Недавно основатель TUHS, Уоррен Туми, объявил о добавлении KSOS в коллекцию архива.
Как KSOS вернулся из небытия?
Этим мы обязаны Тому Перрину (тому самому, который работал над KSOS в Logicon). Спустя 38 лет после того, как проект был закрыт и забыт, Перрин нашёл старый tarball (архив) с исходным кодом. С помощью Джона О Гойо (John O Goyo) и Талии Арчибальд (Thalia Archibald) этот код был восстановлен, проверен и передан в архив TUHS.
Теперь перед историками и разработчиками стоит новая задача: найти оригинальный компилятор Modula, который использовался для сборки KSOS. Интересная деталь: KSOS не был самодостаточным (self-hosting); он компилировался под обычным UNIX. Это означает, что для его сборки требовалась «хостовая» система, что добавляет ещё один слой сложности для энтузиастов, желающих запустить этот код сегодня.
Почему это важно для кибербезопасности сегодня?
Может показаться, что копание в коде сорокалетней давности для PDP-11 — это удел хоббитов. Но для профессионалов в области кибербезопасности и сетевой безопасности эти архивы — бесценный источник знаний.
- Понимание корней уязвимостей. Многие современные проблемы (например, управление памятью, разграничение доступа) были осмыслены и решены (или не решены) десятилетия назад. Изучая KSOS, мы видим, как умные инженеры пытались обойти ограничения C и почему в итоге индустрия пришла к тем или иным стандартам.
- Борьба с синдромом «изобретения велосипеда». В статье USENIX 2002 года Том Перрин с горечью отмечал, что даже через 24 года после создания KSOS проекты в области безопасности снова и снова наступали на те же грабли, пытаясь изобрести решения, которые в KSOS уже работали. Сегодня, в эпоху хайпа вокруг ИИ и блокчейна, мы снова видим, как стартапы пытаются создать «безопасные ОС с нуля», игнорируя уроки KSOS, seL4 и других проектов.
- Культура Open Source и прозрачности. KSOS, будучи военным проектом, в итоге стал частью открытого архива. Это доказывает, что долгосрочная кибер безопасность выигрывает от открытости. Закрытые, проприетарные системы, безопасность которых держится на секрете их устройства, неизбежно проигрывают системам, прошедшим через горнило публичного аудита (как это происходит с Linux, OpenBSD или архивами TUHS).
Часть 7. Практические выводы: как использовать уроки истории в современной архитектуре?
Итак, мы прошли путь от военных миникомпьютеров 1970-х до современных облачных кластеров. Как практические специалисты, занимающиеся сетевой безопасностью и мониторингом сети и управлением рисками, мы можем извлечь из истории KSOS несколько конкретных уроков для построения современных систем.
Урок 1: Безопасность должна быть заложена на уровне архитектуры (Security by Design)
KSOS не был «обычным Unix, к которому прикрутили фаервол». Он был переписан с нуля с использованием языка, обеспечивающего строгую типизацию (Modula).
Современное применение: При проектировании новых микросервисов или IoT-устройств не пытайтесь «прикрутить» безопасность к готовому коду на C/C++. Используйте языки с гарантированной безопасностью памяти (Rust, Go с его строгой типизацией и сборщиком мусора). Если вы пишете ядро драйвера или критический сетевой прокси, рассмотрите возможность использования формально верифицированных библиотек или микроядер.
Урок 2: Сегментация — ваш лучший друг
KSOS обеспечивал многоступенчатую безопасность, жёстко разделяя потоки данных.
Современное применение: В эпоху Zero Trust мониторинг сети должен базироваться на микросегментации. Не надейтесь на один большой периметровый фаервол. Разделяйте сеть на зоны, ограничивайте восток-западное (east-west) движение трафика между контейнерами. Любой мониторинг сети будет намного эффективнее, если «белый» трафик составляет 99%, а аномалии видны сразу.
Урок 3: Математика надёжнее интуиции
KSOS стремился к формальной верификации.
Современное применение: В управлении рисками уходите от интуитивных оценок (“нам кажется, что этот риск высокий“). Используйте количественные модели, такие как FAIR (Factor Analysis of Information Risk). Переводите риски в финансовые показатели. Настраивайте мониторинг сети так, чтобы он предоставлял метрики, которые можно напрямую-feedить в модели управления рисками (например, MTTR — Mean Time To Respond, MTTD–Mean Time To Detect).
Урок 4: Не изобретайте велосипед, изучайте историю
Команда KSOS решила проблемы многоуровневой безопасности, которые до сих пор актуальны.
Современное применение: Прежде чем начинать разработку собственной системы SIEM, SOAR или NDR, изучите существующие open-source решения (Wazuh, Suricata, Zeek, Security Onion). Поймите, как они решают проблемы, которые вы хотите решить. Участвуйте в сообществах, таких как TUHS, OASIS, OWASP. Кибер безопасность — это командный спорт, и опыт предыдущих поколений бесценен.
Заключение: цикличность истории и будущее сетевой безопасности
История KSOS — это напоминание о том, что в IT нет абсолютно новых идей. Есть идеи, которые опережают своё время, и идеи, которые становятся востребованными, когда «железо» и экосистема догоняют концепцию.
В 1978 году Никлаус Вирт и команда Ford Aerospace создали безопасную, строго типизированную, формально верифицируемую ОС. Мир сказал: «Это слишком медленно и сложно, нам нужен быстрый и гибкий C».
В 2026 году мир, уставший от бесконечных уязвимостей переполнения буфера и атак на цепочки поставок, говорит: «Нам нужна строгая типизация, безопасность памяти и формальная верификация. Да здравствует Rust и seL4!».
Круг замкнулся. Но он замкнулся не просто так. Он замкнулся на новом витке.
Сегодня кибербезопасность и сетевая безопасность — это не просто защита отдельного узла. Это комплексная дисциплина, охватывающая глобальные сети, облачные архитектуры и распределённые системы. Но фундамент остаётся прежним: безопасный код, строгое разграничение прав и непрерывное наблюдение за тем, что происходит в системе.
Мониторинг сети и управление рисками эволюционируют от простого сбора логов к предиктивной аналитике на базе ИИ, но их цель неизменна: обеспечить непрерывность бизнеса и защиту данных. И в этом контексте уроки, извлечённые из пыльных архивов The Unix Heritage Society, звучат на удивление современно.
Исходный код KSOS, доступный сегодня в архивах TUHS, — это не просто музейный экспонат. Это манифест, написанный на языке Modula, который доказывает: безопасность не может быть запоздалой мыслью. Она должна быть вшита в саму ДНК системы, в каждый тип данных, в каждую строчку кода, в каждый пакет, проходящий через вашу сеть.
И пока мы ждём, пока энтузиасты найдут оригинальный компилятор Modula для запуска KSOS, нам есть над чем подумать. Возможно, следующий прорыв в кибербезопасности произойдёт не благодаря созданию чего‑то совершенно нового, а благодаря переосмыслению гениальных идей, которые были заложены полвека назад людьми, которые понимали, что безопасность — это не продукт, а процесс, требующий математической строгости и инженерной дисциплины.
Будьте бдительны, проверяйте типы, верифицируйте свои ядра и не забывайте мониторить свою сеть. Ведь, как показали парни из Ford Aerospace в 1978 году, фундаментальные законы безопасности не меняются, меняются лишь инструменты.
Адрес:
121205, г. Москва, муниципальный округ Можайский, территория инновационного центра «Сколково», б-р Большой, д. 42, стр. 1, этаж 2, помещение № 162/№ 4
Телефон:
+7 (495) 255-35-82
Почта:
info@netopia.pro
Деятельность осуществляется компанией ООО «Нетопия» при грантовой поддержке Фонда «Сколково»
© Netopia.pro
