My 和家人一起去罗马旅行，感觉太棒了；离开办公室一周，探索这座城市，漫步于历史遗迹之间，品尝美食，以及单纯地与家人共度时光，这正是我所需要的。
一天，当我们漫步在一条凉爽的小巷里时，偶然发现了一堂意面和提拉米苏制作课。看起来很有趣，而且正如俗话所说：“入乡随俗”。在那几个小时里，我暂时把恶意软件、网络安全和关键基础设施抛诸脑后，转而专注于面粉、鸡蛋、水、时间掌控、压力把控和耐心。
随着我逐渐适应这门课，我越来越意识到，就连制作意面也是一种系统。从表面上看似乎很简单，但如果你在意成品效果，那些细微之处就至关重要。水加多了会改变面团的质地；施力过猛会影响口感；如果操之过急，成品就不会尽如人意。
无论是在食品、商业还是网络安全领域，情况都是如此。
下课时，发生了一件完全出乎意料的事：我遇到了杰夫·高布伦。
他热情、风趣、优雅，而且非常平易近人。和大多数见过他的人一样，我首先想到的是他那些标志性的电影角色、爵士钢琴，以及他那种虽声名显赫却依然平易近人的独特气质。那是在我的网络安全思维占据上风之前。
我一直在回想1996年电影《独立日》中的一幕，片中他饰演的大卫·莱文森向外星母舰植入了恶意软件。
这让我不禁思考：“恶意软件在太空中传播真的可能吗？”
当然是了。
这虽不完全符合好莱坞式的设定，但其核心理念是站得住脚的。任何运行软件、接收数据、接受指令或信任外部输入的系统都可能遭到攻击。母舰在信任人类系统方面缺乏威胁模型，这与当今的太空基础设施情况完全吻合。
太空热潮
时机在此至关重要。太空领域似乎正进入一个新的繁荣周期，其发展已不再局限于火箭、美国宇航局（NASA）以及SpaceX的上市。
从更宏观的角度来看，这是一场全球性的角逐。亚马逊的“Kuiper”计划正加入卫星宽带竞争。欧洲正在建设IRIS²卫星星座，旨在为政府通信、危机应对、关键基础设施及加密服务提供安全且具有主权的连接能力。中国正通过“千帆”和“国网”等大型卫星星座计划积极推进相关工作。印度则在扩大其航天及国防卫星领域的雄心。 日本正在加大对太空安全的投入。Viasat、OneWeb、Planet、Maxar、Intelsat、Iridium、Eutelsat、SKY Perfect JSAT等运营商正在轨道上构建通信、成像、导航、国防和数据服务。
相关讨论也已超越了“卫星作为通信基础设施”的范畴。埃隆·马斯克曾探讨过将人工智能数据中心送入轨道，他认为地球面临能源限制，而太空则拥有源源不断的阳光。 去年，Starcloud发射了一艘搭载英伟达H100芯片的航天器，并演示了在太空中运行谷歌Gemini人工智能模型的某个版本。此外，谷歌还公布了“Suncatcher项目”，旨在探索配备TPU和光纤链路的卫星集群，并计划于2027年发射原型卫星。
这是一种截然不同的太空经济。
太空领域正从运输向通信、从通信向数据、从数据向计算、再从计算向人工智能发展。太空正逐渐成为一个涉及国家、商业运营商、国防机构以及跨国供应链的全球数字基础设施层。
……而且，每一层数字基础设施最终都会成为网络攻击的目标。
网络安全……在太空
太空网络安全真的是个问题吗？是否发生过真实的事件？这些事件与其他事件有何不同？
是的，是的，还有是的。
太空领域最初属于政府和国防范畴。几十年来，大多数太空计划都由政府、军队、情报机构和国家研究组织拥有或严格控制。这一点很重要，因为这些机构并不总是会公开披露相关事件。有些失败被描述为“异常情况”，有些事件被列为机密，还有些则由相关机构、承包商或国防合作伙伴悄悄处理。
公开记录仅是该事件历史的一小部分。
尽管存在这一限制，目前已有若干组织在监测与太空相关的网络安全风险和事件，其中包括太空信息共享与分析中心（Space ISAC）、美国国家航空航天局监察长办公室（NASA OIG）以及欧洲网络与信息安全局（ENISA）。
Space ISAC 专注于太空网络威胁和事件追踪；美国宇航局监察长办公室（NASA OIG）针对美国宇航局和喷气推进实验室（JPL）的事件开展详细调查并进行根本原因分析；而欧洲网络与信息安全局（ENISA）的“太空威胁态势”则是一个汇集太空网络风险及历史案例的公开平台。
通过将他们的调查结果与公开资料进行比对，我整理出了以下事件清单，以阐明这些安全事件发生的原因及其影响：
年 | 组织 | 事件 | 数据泄露是如何发生的 | 根本原因 | 公开来源网址 |
1998年至2000年 | 美国政府 / 美国国家航空航天局 | 月光迷宫 | 一项持续时间较长的网络间谍活动窃取了美国政府、国防部门及美国国家航空航天局（NASA）的相关数据。 | 监控不力、分段不足、跨部门可见性薄弱 | https://nsarchive.gwu.edu/document/19207-national-security-archive-united-states-navy |
1999 | 美国国家航空航天局（NASA）/国防威胁降低局（DTRA） | 乔纳森·詹姆斯 | 窃取了凭证，植入了后门，拦截了电子邮件，入侵了美国宇航局（NASA）的系统。由于网络和信任区域未得到妥善隔离，事件的影响范围随之扩大。 | 扁平化网络、分段程度低、凭证强度低 | https://www.nytimes.com/2000/09/22/technology/teen-hacker-sentenced.html |
2001年至2002年 | 美国国家航空航天局（NASA）/ 美国国防部（DoD） | 加里·麦金农 | 扫描了存在安全漏洞的系统，利用了弱密码，获得了管理员权限，并安装了远程控制工具。 | 系统暴露在外、密码强度不足、未启用多因素认证 | https://www.justice.gov/archive/criminal/cybercrime/press-releases/2002/mckinnonIndict.htm |
2007年至2008年 | Landsat 7 / Terra AM 1 | 地面站干扰 | 据报告，干扰是通过地面站路径造成的，并非直接对卫星的入侵。 | 地面站暴露，指令链路分离度低 | |
2007年及以后 | Turla | 卫星链路劫持 | 滥用未加密的卫星互联网连接来隐藏指挥与控制流量。 | 未加密的卫星链路、身份验证机制薄弱 | |
2009 | 美国国家航空航天局（NASA） | Mission网络恶意软件 | 美国宇航局（NASA）的任务系统遭到了恶意软件感染，并出现了数千次未经授权的连接。 | 恶意软件、端点管控薄弱、网络分段不足 | |
2009年至2012年 | 美国国家航空航天局（NASA） | 丢失的、内含ISS数据的笔记本电脑 | 美国宇航局（NASA）丢失了笔记本电脑和便携式设备，其中部分设备未加密，且包含与国际空间站（ISS）相关的资料。 | 设备丢失、未加密、敏感数据存储在本地 | |
2011 | 美国国家航空航天局（NASA） | 47起APT攻击 | 美国宇航局（NASA）报告了47起APT攻击事件，其中13起攻击成功，包括凭证盗取。 | 网络钓鱼、凭证盗取、多因素认证（MFA）强度不足 | |
2011 | 美国宇航局喷气推进实验室 | 87 GB 被盗 | 攻击者获得了18台服务器的完全访问权限，篡改了账户信息、上传了工具、篡改了日志，并窃取了数据。 | 职责划分不明确、特权授予过多、监督不力 | |
2011 | JAXA HTV | 恶意软件感染 | 一名员工在一台未打补丁的计算机上打开了一封恶意电子邮件。恶意软件感染了该计算机，并导致登录信息泄露。 | 基于文件的攻击、恶意电子邮件、未打补丁的Office软件 | https://global.jaxa.jp/press/2012/03/20120327_security_e.html |
2012 | JAXA 埃普西隆 | Rocket数据恶意软件 | 一款恶意软件感染了筑波航天中心的计算机，可能导致Epsilon、M-V、H-IIA和H-IIB火箭的数据泄露。 | 基于文件的恶意软件，工程工作站遭入侵 | https://global.jaxa.jp/press/2012/11/20121130_security_e.html |
2012 | 美国宇航局 / 欧洲航天局 | “The Unknowns”对Web服务器的入侵 | 黑客利用了Web服务器的弱点，并披露了相关漏洞。 | Web应用漏洞、补丁修复不力 | |
2014 | NOAA | 卫星数据系统遭入侵 | 攻击者利用了面向互联网的美国国家海洋和大气管理局（NOAA）网络应用中的已知漏洞，窃取了管理员凭据，并在各系统间横向移动。 | Web应用漏洞、未打补丁的系统、凭证盗取 | |
2014 | 美国宇航局喷气推进实验室 | 公开上传恶意软件 | 普通用户可以在一台支持JPL天文任务和研究的服务器上上传和执行文件。 | 基于文件的攻击、不安全的上传、未进行数据净化 | |
2014 | 德国航空航天中心（DLR） | APT攻击 | 公开报道描述了针对航空航天系统的网络间谍活动和鱼叉式网络钓鱼攻击。 | 电子邮件攻击、凭证盗取、监控不力 | https://securityaffairs.com/24031/cyber-crime/german-aerospace-center-espionage.html |
2016 | 美国宇航局喷气推进实验室 | 网站配置错误 | 一名匿名用户获得了提升的权限，并在开发服务器上执行了代码。 | 配置错误、权限过高 | |
2017 | 美国宇航局喷气推进实验室 | 地面行动源代码服务器 | 一个未知漏洞导致源代码系统上存在远程代码执行风险。日志审查速度不够快。 | 未修补的漏洞、日志审查不力 | |
2018 | 美国宇航局喷气推进实验室 | 与深空网络相关的安全事件 | 外部用户账户遭到入侵。由于网络分段措施薄弱且资产清点不完善，攻击者得以横向移动并侵入关键业务系统。 | 划分不明确、第三方访问、库存管理不善 | |
2018 | 美国国家航空航天局（NASA） | 员工个人身份信息泄露 | 人力资源服务器遭入侵，导致员工个人数据泄露。 | 访问控制薄弱，敏感数据泄露 | https://federalnewsnetwork.com/cybersecurity/2018/12/nasa-suffers-breach-of-employee-data/ |
2019 | ISRO | DTrack 恶意软件报告 | 公开报道称，发现了DTrack恶意软件，且可能发生了域控制器遭入侵的情况。印度空间研究组织（ISRO）对此的确认信息有限。 | 可能是基于文件的恶意软件，凭证遭泄露 | https://www.cfr.org/cyber-operations/compromise-of-indian-nuclear-power-plant |
2020 | Visser Precision，SpaceX的供应商 | 勒索软件 | 供应商遭遇了勒索软件攻击，导致专有客户文件泄露。 | 供应商系统遭入侵、勒索软件、网络瘫痪 | |
2020 | SolarWinds | 影响航空航天和政府部门的供应链攻击 | 恶意软件更新使攻击者获得了进入包括美国国家航空航天局（NASA）和美国联邦航空管理局（FAA）在内的许多网络的可信访问权限 | 受信任的软件供应链遭到破坏 | https://www.cisa.gov/news-events/cybersecurity-advisories/aa20-352a |
2022 | Viasat KA 卫星 | 卫星互联网服务中断 | 攻击者利用了VPN配置错误，侵入受信任的管理网络，并下达了清除调制解调器闪存数据的命令。 | VPN 安全漏洞，网络分段管理不力 | https://www.viasat.com/perspectives/corporate/2022/ka-sat-network-cyber-attack-overview/ |
2022 | 俄罗斯联邦航天局 | 关于NB65违规的索赔 | 黑客声称入侵了俄罗斯的航天资产。此次入侵对运营造成的影响存在争议。 | 未经核实 | https://ui.adsabs.harvard.edu/abs/2024arXiv240210324T/abstract |
2023 | 波音全球服务 | LockBit 勒索软件 | LockBit对波音公司的零部件和分销业务发动了攻击。波音公司表示，飞行安全未受影响。 | 勒索软件、横向移动、分段措施薄弱 | |
2023 | Maximum Industries，SpaceX的供应商 | LockBit的声明 | LockBit声称从一家供应商处窃取了与SpaceX相关的工程图纸。此事尚未得到公开证实。 | 供应商系统遭入侵、数据被盗 | https://cyberir.mit.edu/site/lockbit-ransomware-claims-data-breach-spacex-contractor/ |
2023年至2024年 | JAXA | VPN 和 Microsoft 365 数据泄露事件 | 攻击者很可能利用了VPN中的一个漏洞，扩大了访问权限，入侵了相关账户，并访问了Microsoft 365。 | VPN 漏洞、云身份信息泄露 | |
2024 | 马克萨尔航天系统公司 | 员工数据泄露 | 攻击者入侵了一台外部DMZ主机。员工数据遭到泄露；据称业务运营未受影响。 | 面向互联网的DMZ存在安全风险，隔离措施薄弱 | |
2025 | 波兰航天局（POLSA） | 网络安全事件 | 检测到未经授权的访问。POLSA在调查期间切断了其网络连接。 | 未知，可能是网络入侵 | |
2025 | 以色列 VSAT 和卫星控制系统 | VSAT及卫星中断与控制索赔 | 太空ISAC报告称，在地缘政治冲突期间，曾出现针对以色列卫星控制段和以色列VSAT系统的攻击指控。 | 黑客行动主义、DDoS、破坏活动、地面段攻击 | https://spaceisac.org/wp-content/uploads/2025/10/Space-ISAC_Q3-2025-Public-Report_TLP-CLEAR-1-1.pdf |
2025 | 美国卫星通信服务提供商 | “Salt Typhoon”将卫星通信服务商作为攻击目标 | Space ISAC 报告称，“Salt Typhoon”组织将一家美国卫星通信服务提供商作为攻击目标，这是其更广泛的电信行动的一部分。 | 边缘设备遭入侵，电信和卫星通信系统成为攻击目标 | https://spaceisac.org/wp-content/uploads/2025/10/Space-ISAC_Q3-2025-Public-Report_TLP-CLEAR-1-1.pdf |
2025 | 俄罗斯航空航天与国防领域 | 作为“Cargo Talon行动”的一部分，针对性极强的鱼叉式网络钓鱼诱饵 | 旨在入侵各类实体并窃取敏感数据的网络间谍活动。 | 鱼叉式网络钓鱼、基于文件的攻击 | https://spaceisac.org/wp-content/uploads/2025/10/Space-ISAC_Q3-2025-Public-Report_TLP-CLEAR-1-1.pdf |
2025 | 伊朗的卫星Software 基础设施 | Lab Dookhtegan 海事 VSAT 目标定位 | 据报道，某威胁行为者将目标锁定在支持海事VSAT基础设施的卫星软件上，导致通信中断并造成文件被删除。 | 卫星通信软件支持、供应商及服务信息披露 | https://spaceisac.org/wp-content/uploads/2025/10/Space-ISAC_Q3-2025-Public-Report_TLP-CLEAR-1-1.pdf |
2025 | 欧洲电信、国防、航空航天和卫星行业 | 伊朗MINIBIKE恶意软件的攻击目标 | 据报道，伊朗APT组织UNC159针对欧洲的电信、航空航天和国防机构使用了量身定制的恶意软件。 | 恶意软件，可能通过文件传播 | https://spaceisac.org/wp-content/uploads/2025/10/Space-ISAC_Q3-2025-Public-Report_TLP-CLEAR-1-1.pdf |
2025 | 航空航天、国防和航天组织 | 通过与中国有关联的APT组织“RedNovember”实施的网络间谍活动 | 据报道，“RedNovember”利用开源、多平台的Go后门程序“Pantegana”，将全球范围内备受瞩目的政府和私营部门的航天及航空组织作为攻击目标。 | 间谍活动、网络入侵 | https://spaceisac.org/wp-content/uploads/2025/10/Space-ISAC_Q3-2025-Public-Report_TLP-CLEAR-1-1.pdf |
2025年至2026年 | 欧洲航天局 | 工程协作服务器 | 外部工程协作服务器遭到入侵。据公开报道称，代码、令牌、凭证、配置文件和任务文档均已泄露。 | 凭证盗窃、令牌盗窃、协作系统存在安全漏洞 | |
2026 | 欧洲航天局 | 大规模数据泄露报告 | 公开报道称，数百GB与欧洲航天局（ESA）相关的数据遭到泄露，其中包括登录凭证和项目文件。据报道，欧洲航天局已就此展开调查。 | 未知 / 正在调查中 |
深入剖析网络安全模式
在梳理这些事件时，我发现其他关键基础设施领域也存在同样的网络安全漏洞：不安全的文件、供应商系统遭入侵、软件更新流程薄弱、可移动存储介质风险、凭证被盗以及网络分段措施不力。
令我感到惊讶的是，航天器或卫星往往并非攻击目标。攻击路径通常始于地面。地面站、工程系统、供应商和支撑网络往往与任务本身受到不同的对待，尽管对它们进行破坏可能会导致同样的后果。
话虽如此，尽管当今大多数公开事件源于地面系统，但随着航天计划的发展以及进入轨道成本的降低和途径的普及，我们不应认为网络攻击永远都来自地球。 可以预见，未来随着国家甚至商业运营商将航天器、卫星或其他轨道资产部署到更接近目标的位置，以支持网络攻击、电子战、拦截、干扰、欺骗或情报收集行动，威胁格局将进一步扩大。
检测与预防
许多事件还暴露了主要依赖传统防火墙和基于检测的安全措施所存在的局限性。
在2018年美国宇航局喷气推进实验室（NASA JPL）的入侵事件中，攻击者攻破了一个外部账户，并通过隔离措施不完善的网络进行了横向移动。一旦建立了信任关系，外围防御就显得力不从心。在2022年Viasat KA-SAT攻击事件中，攻击者通过被攻破的VPN/防火墙路径进入了一个受信任的管理网络，并发布了合法的管理命令。
同样，问题并不单纯在于未能检测到恶意流量，而在于未能使用单向网关——这种网关本应通过设计而非策略来强制实现单向数据传输，从而从源头上阻止攻击者接触关键系统。
几起与文件相关的安全事件都揭示了类似的情况。2011年日本宇宙航空研究开发机构（JAXA）HTV恶意软件事件的起因，是有人在未打补丁的工作站上打开了一封恶意电子邮件的附件。2014年美国喷气推进实验室（JPL）上传恶意软件事件，则导致未经信任的文件进入了任务支持系统。检测工具或许能在事后识别出恶意内容，但一旦文件被打开或执行，损害可能已经造成。
由此得出的教训是：我们应将航天系统视为关键基础设施，并将支撑这些系统的网络基础设施视为任务关键型基础设施。许多此类事件并非检测失效，而是预防失效。一旦攻击者侵入受信任网络、工程环境、管理系统或任务系统，防火墙和警报往往为时已晚。
太空网络安全战略
一旦我们查明了风险以及已报告事件背后的根本原因，我们该如何应对？
太空网络安全与传统网络安全在根本原因上有很多相似之处，但它还增加了两个彻底改变局面的维度——时间和环境。
在地球上，如果出现问题，我们通常认为可以进行连接、检查、修复、恢复，或者派人前往现场处理。但在太空中，这些假设中的许多都行不通。通信速度更慢、成本更高、范围更有限，而且离地球越远，通信就越困难。
月球距离地球足够近，信号单程传播时间略超过一秒，但即便如此，往返延迟仍超过两秒。火星的单程通信时间则在4到24分钟之间，具体取决于地球和火星在各自轨道上的位置。对于深空探测任务而言，这个问题更加严峻。“旅行者”号距离地球如此遥远，单程通信几乎需要一整天的时间。
这改变了网络安全模式。
现代安全工具越来越依赖于与云端的持续交互：信誉查询、哈希校验、签名更新、AI模型更新（随着AI系统进入轨道，这种依赖性正日益增强）、沙箱提交、遥测数据上传以及集中式判定。在地球上，这种模式之所以可行，是因为网络连接速度快且可靠。但在太空中，若假设同样的模式也能奏效，则会带来风险。
在月球上，从技术上讲，其中部分功能仍然可行，但这绝非您应该依赖的方案。每次云端查询都会增加延迟；每次沙箱提交都必须往返地球；每次远程桌面会话都会变慢；每次大规模取证数据上传都会与任务带宽争夺资源。如果与地球的通信链路出现拥塞、性能下降、中断或不可用，基于云的安全防护就会变得不可靠。
如果在月球上这已经很困难，那么在火星上就会难上加难，而在深空环境中更是无法实时完成。
补丁更新也是如此。如果开展一项为期多年的太空任务，就不能指望像更新笔记本电脑、服务器或云工作负载那样对基础设施进行补丁更新。航天器可能需要使用老旧的硬件、有限的内存、抗辐射处理器、受限的带宽、有限的电力，并且通信窗口非常短暂。
如果更新有误、命令格式错误，或者软件在飞行中的表现与模拟环境中的表现不同，恢复操作可能会很困难，甚至更糟——根本无法恢复。
“旅行者号”就是一个完美的例子。美国宇航局（NASA）于1977年发射了“旅行者1号”和“旅行者2号”，近五十年后的今天，团队仍在对它们进行维护。对如此古老且距离如此遥远的航天器进行软件更新或修正，需要非凡的工程技术。但这也证明了一个事实：对航天器进行补丁更新既缓慢又充满风险，与地球上对系统进行补丁更新的情况截然不同。
伽利略号是另一个有意义的例子。发射后，伽利略号的高增益天线未能完全展开，这意味着该航天器无法使用原计划的高速通信链路。尽管如此，美国宇航局（NASA）和喷气推进实验室（JPL）仍通过数据压缩、软件修改以及周密的任务规划，获得了重要的科学发现。这证明了一个关键点：在太空中，通信限制决定了任务的成败。
网络安全的问题很简单：当你无法依赖快速通信、持续监控、基于云的响应或派遣人员现场处理时，该怎么办？我建议采取以下三种策略。
1. 将太空网络安全从“以检测为主”转变为“以预防为主”
检测仍然很有用，特别是在任务相关的地面系统、终端和企业环境中，但这假设您能够察觉到攻击，并能迅速进行分析、响应和恢复。在太空中，这一假设并不成立，因为可视范围可能受限，通信可能延迟，计算能力可能受限，而且恢复可能缓慢甚至无法实现。等到您发现问题时，任务可能已经岌岌可危。
正因如此，该策略必须 预防，而非信任。
在经过检查、验证、清理和批准之前，应将每个文件、软件更新、AI 模型、有效载荷包、命令包和可移动存储设备均视为不可信。在任何内容进入任务环境之前，应采用多重扫描、沙箱隔离、内容无害化与重建（CDR）、模式验证、签名更新、白名单、命令验证和审计日志等措施。
2. 通过设计实现细分
不要将任务控制中心视为普通的企业IT系统，也不要让工程系统随意接触运营系统。确保供应商的访问权限范围有限、临时有效、有记录且相互隔离，并严格分离地面站、指令路径、软件更新系统、测试环境和协作工具。
任何一台遭到入侵的笔记本电脑、被盗的凭证、受感染的文件、有问题的更新或供应商数据泄露，都不应被允许进入任务运营环节。
防火墙固然重要，但在最敏感的任务路径中，我不会仅依赖防火墙。防火墙由软件控制，这意味着它们可能配置错误、被绕过或遭到入侵。数据二极管或单向网关是更好的方案，因为它们通过设计而非仅靠策略来强制实现单向数据传输。
3. 将关键的安全决策与任务需求更紧密地结合起来
长期任务需要本地验证、机载完整性检查、安全模式行为、在可行情况下制定回滚方案，以及更贴近航天器的安全处理。这也意味着需要投资于坚固耐用、耐辐射的硬件，以便在本地实施安全控制。随着我们将安全决策从地球转移到任务现场，我们不能假设传统的云服务、企业级设备或软件代理始终可用、实用或与运行环境兼容。
云端可以支持从地面进行的规划、分析和协调工作，但不应作为决定某事是否安全的实时控制回路。
我们离地球越远，网络安全就越需要从“检测和响应”转向“预防、隔离和本地托管”。
引领网络安全迈向新领域
推出MetaDefender Kiosk 是我们的首次太空任务，而非一场营销噱头。对我而言Kiosk 任务体现了我所认为的太空网络安全的基础：独立计算、信任前预防、确定性文件安全，以及能在恶劣环境下持续运行的硬件。
首先，这是一个独立系统。尽管我们将它送到了极高海拔，但在任务期间它并未连接云端。它采用本地计算，并在物理隔离模式下运行。我们计划在未来的任务中加入一个单向数据网关或数据二极管。
其次，该Kiosk 在任务期间Kiosk Deep CDR™ 技术，在受控且隔离的测试环境中处理了来自USB 数千个恶意软件样本。 Deep CDR™ 技术具有确定性，这意味着它无需猜测文件是否恶意。该技术默认文件可能具有恶意，会移除高风险的动态内容，并重新生成一个干净的版本。如果对该流程进行妥善管控，则无需频繁更新签名即可防范许多未知的基于文件的威胁，因为Kiosk 信任文件之前对其Kiosk 。
最后，我们在恶劣环境下对该硬件进行了测试。Kiosk 必须应对极端温度、低气压、剧烈震动、气球爆裂、下降过程中的高过载、旋转、坠落，甚至落入河中等情况。经历这一切后，它仍能继续工作一段时间。这一点至关重要，因为太空网络安全既涉及软件问题，也涉及硬件问题。
真正的教训
太空网络安全不能建立在“地球上总有人能随时解决问题”这一假设之上。它必须具备本地化、确定性、分段化以及“预防优先”的特点。任务距离地球越远，减少任务所依赖的外部因素就越重要。
减少对系统的信任，加强验证。将安全处理流程纳入航天器内部。严格实施隔离。进入前进行检查。使用前进行数据净化。必要时采用单向数据传输。在发射前就将安全措施融入任务设计中，因为离地球越远，地球就越难拯救你。
截至今日，美国网络安全与基础设施安全局（CISA）将16个行业界定为关键基础设施：
- 化学
- 商业设施
- 通信
- 关键制造
- 水坝
- 国防Industrial
- 应急服务
- 能源
- 金融服务
- 食品与农业
- 政府设施
- 医疗保健与公共卫生
- 信息技术
- 核反应堆、材料和废料
- 运输系统
- 供水和废水系统
我认为太空应该被列为第17个领域。
当我们的其中一台网络安全设备在飞抵太空边缘后坠入河中时，我原本没料到自己会想到意大利面，但这要感谢我的家人和杰夫·高布伦给我的灵感。这也让我再次意识到，无论是意大利面团、网络安全还是深空，细节都至关重要。
我一直都很喜欢太空。和许多孩子一样，我曾经梦想成为一名宇航员。不过，我最终创办了一家网络安全公司，并作为私人飞行员驾驶飞机，但将一款网络安全产品送入太空，却让我感觉这是一种既奇妙又有意义的方式，让我得以重新与儿时的梦想建立联系。
除了海拔高度、技术和炫酷的视频之外，网络安全还必须能在人类难以触及、难以维修或难以重置的环境中正常运行。在太空中，既没有简单的现场支持，也没有快速的更换方案，更没有轻松的“第二次机会”。系统在升空之前就必须获得完全的信任。
