简介RTCA DO-326B-2024《航空系统安全过程标准》由SC-216与EUROCAE WG-72联合编制于2024年9月正式发布面向航空电子、机载信息系统、地面支持系统及空管数字化基础设施的研发与适航审定人员为应对非授权电子交互IUEI威胁提供覆盖全生命周期的安全过程框架。文档共897页详细规定威胁建模、安全需求四级划分、安全保证等级SAL确定及独立安全审计等核心要求并与DO-178C、DO-254、ED-202A等标准形成协同支撑关系。资源为单份完整PDF收录14个主章节、213项强制性要求及工具鉴定清单等内容压缩包5.4MB便于离线研读。已有144人学习浏览适合从事航空安全评估、系统安保设计与标准跟踪研究的工程师作为权威参考资料。1. RTCA DO-326B 到底是什么一份被名字耽误的适航安全标准第一次拿到 RTCA DO-326B-2024.pdf 的人十有八九会误判。有人以为它是航空无线电通信的技术规范有人以为是关于机载电子硬件的新版指导材料直到翻开目录才意识到——这是一份关于机载网络安全适航过程的标准。它不规定你用什么加密算法、不推荐具体安全产品它规定的是你的产品从概念设计到持续适航用什么流程证明自己面对恶意攻击是安全的。这件事在当前很要命。航电系统联网程度越来越高电子飞行包、无线维护口、地空数据链、驾驶舱门系统每一个都是潜在攻击面。局方在型号合格审定里越来越频繁地追问你的系统有没有做威胁分析安全需求怎么来的怎么验证的DO-326B 就是回答这些问题的依据。它的核心价值在于把网络安全从“测试时找两家公司做渗透”变成“从设计源头开始的安全过程保证”让取证材料有结构化证据链。这套标准适合三类人机载系统与航电设备开发者、负责型号适航取证的工程师、以及给飞机或无人机做网络安全方案的服务商。接下来的内容按执行顺序展开——标准体系、落地路径、材料清单、踩坑记录和验证技巧目标只有一个让你能照着把安全过程建起来。2. 先分清标准家族DO-326B 管什么、不归它管什么2.1 从 DO-326A 到 DO-326B这版改了哪些审查重点DO-326 系列最早在 2010 年前后发布A 版是 2014 年左右成型的当时把“航空器信息安全适航过程”这个概念第一次系统化。DO-326B 作为最新修订版整体框架没有推翻重来仍然围绕Airworthiness Security Process展开——从安全计划、威胁影响等级、安全开发保证、持续适航阶段的安全维护一条线串到底。A 版到 B 版之间最直观的变化在于B 版明确强化了与DO-356A的配合关系。DO-356 讲的是威胁分析的具体方法和注意事项A 版时代很多团队以为做完 DO-356 的分析就等于满足 DO-326局方后来发现这种理解有偏差——DO-326B 把话写得更死DO-356A 是方法指导DO-326B 是过程框架两者互为必要条件。另一个变化是 B 版在“安全等级”的确定上更强调与失效条件的联动要求你把安全影响评估和功能危险性评估FHA放在一起做而不是各写各的报告。还有一个容易被忽视的改动B 版加强了数据链路和载荷软件的覆盖。旧版把注意力集中在飞机系统本身B 版明确把地面站接口、维护端口、载荷数据上传通道也纳入安全过程范围这就直接影响到无人机和通航改装项目。2.2 DO-326B、DO-356A、DO-355、DO-178C 的分工与边界很多人第一次接触这个标准家族时最大的困惑是这些 DO 标准到底各管哪一段我习惯用一条产品开发时间线来划分标准定位管什么不管什么ARP4754A系统研制过程系统级需求、架构、集成验证的通用流程不区分安全与信息安全两者都要往里嵌DO-178C机载软件研制软件生命周期正确性防的是“开发错误”防不了有人通过维护接口改你的代码DO-254机载复杂电子硬件硬件设计保证防的是硬件逻辑错误不关心硬件被恶意触发后的行为DO-326B网络安全适航过程安全过程框架、安全等级、威胁分析要求、持续适航安全不指定具体技术方案和产品选型DO-356A威胁分析方法告诉你威胁分析怎么做、用什么方法识别与评估威胁不定义整体合格审定流程DO-355持续适航安全飞机交付后如何监控漏洞、发布安全通告、处理运营中安全事件不覆盖型号研制阶段DO-178C 解决的是“你的软件有没有按需求正确实现”DO-326B 解决的是“你的软件面对一个故意使坏的人还能不能保持要求的特性”。前者问“有没有 bug”后者问“有没有后门”。一条常见误用是拿 DO-178C 的 DAL 等级替代安全等级——两者逻辑起点不同DAL 来自失效后果安全等级来自威胁影响评估加安全机制有效性混用会让审查员直接质疑你的方法学。2.3 什么项目必须按 DO-326B 走适用性判断不是所有项目都需要完整按 DO-326B 执行。判断依据不是产品类型而是局方在你的型号合格审定基础里是否引用了它。目前常见情况分三类大型运输类飞机的新型号几乎必做而且局方审查员对安全过程的要求已经很成熟没有安全计划文件根本不会受理你的 PSCP 评审。通航飞机、直升机改装项目取决于审定基础是否引用。如果项目涉及加装 Wi-Fi 客舱互联、电子飞行包互联模块局方大概率会要求按 DO-326B 做安全评估但范围可以裁剪。无人机系统不同类型差异很大。大型固定翼无人机通常在审定基础里直接引用小型多旋翼目前很多还处在“局方个案评估”阶段但整机企业提前按 DO-326B 搭安全过程是划算的因为后面审定基础一旦引用你不必从零补。裁剪的常见做法是写一份Security Scope Definition明确哪些功能纳入、哪些不纳入、为什么不纳入。注意裁剪不是把工作省掉而是要在文件里论证“这个功能不涉及安全威胁”比如纯模拟信号的迎角传感器没有外部可访问接口可以不纳入。关键是有论证而不是拍脑袋。3. 把 DO-326B 落到执行从安全计划到验证活动的四步路径3.1 第一步定义安全等级与威胁环境DO-326B 的起点是安全计划文件Security Plan它规定整个项目的安全活动组织方式。但比计划文件更先要做的一件事是确定每个候选安全相关功能的威胁影响等级Threat Impact Level。这一步的常见做法是把系统功能与失效条件对比——也就是把 FHA 的结果拿过来看这些失效如果被攻击者故意触发会造成什么后果。威胁影响等级一般分四级影响从灾难性到轻微。等级定义的决策树逻辑大致是如果攻击者成功利用了某个漏洞导致飞机丧失继续安全飞行与着陆的能力这就是最高影响等级。需要注意这里评估的不是“这个漏洞在不在”而是“假如漏洞被完全利用后果有多严重”。影响等级出来后再结合系统自身具有的安全防护机制强度推导出安全等级Security Level。防护机制强等级可以适当降低没有防护等级就原样保留。威胁环境描述是这个阶段的另一项硬任务。你的飞机在什么场景下运行谁会想攻击它攻击者的能力边界在哪里常见做法是写一份Threat Environment Description内容包括运行地域、航线类型、地面人员接触机会、无线接口暴露程度等。给的提示是这条不要抄别人家飞机的描述局方会横向对比同型号项目抄来的威胁环境会和你的系统结构明显对不上反而惹来更多质疑。3.2 第二步威胁分析与安全需求生成威胁分析的执行主体普遍是系统安全工程师加网络安全工程师混编。方法上没有强制要求DO-356A 推荐了多种分析技术包括 STRIDE、攻击树分析、故障树加攻击路径分析等。常见组合拳是先用 STRIDE 把威胁类型过一遍再用攻击树细化攻击路径最后对每一条路径做可行性评估。威胁分析的输入材料包括系统架构描述、数据流图、接口清单、协议列表、上一步的威胁环境描述。输出物是一份威胁分析报告核心内容是“威胁-攻击路径-可行性-影响”的关联表。每条被判定为可实现的威胁路径都要生成对应的安全需求Security Requirement例如编号威胁描述安全需求示例T-001攻击者通过维护口未授权访问航电数据总线维护口必须具备双向身份认证且连续认证失败 5 次后锁定 30 分钟T-002攻击者向地空链路注入伪造的飞行计划数据地空数据链应使用会话级完整性校验拒绝校验失败的数据包T-003地面人员通过 USB 口加载恶意配置文件配置文件加载前必须进行签名验证验证失败禁止加载并记录日志安全需求的编写要遵循一个原则从威胁推导不凭经验硬编。如果你说不清每条安全需求对应哪条威胁路径审查员在安全需求追溯表上一查一个准。同时需求的描述要像功能需求一样可验证有对象、有动作、有条件、有响应不能用“应确保安全”这种空话。3.3 第三步安全架构落地与设计约束落实安全需求写出来后要落到系统架构和软硬件设计里。这一步是 DO-326B 落地时最容易和日常研发脱节的地方。常见做法是把安全需求分为两类一类分配给架构层例如网络分区、接口隔离、安全监控模块另一类分配给软硬件层例如实现身份认证的软件模块、加解密组件、日志记录功能。落地过程的关键动作是建立安全架构描述Security Architecture Description这个文档的画法和普通系统架构不同它要标明信任边界、数据流跨边界的位置、每个边界上的安全机制、以及这些机制如何应对威胁分析报告中的攻击路径。如果你的架构里没有明确画出“哪条数据路径是被安全机制保护的”审查员通常会直接给你开一条问题记录。设计落实阶段还需要关注一个细节把安全需求纳入常规的开发流程管理。安全需求应该进入需求管理工具和普通功能需求一起做分配、实现、验证和追溯而不是单独放一个 Excel 表里。否则后期的验证记录和追溯表会变得非常痛苦。3.4 第四步验证活动与评审关口验证策略方面DO-326B 不强制要求你必须做渗透测试——很多团队把渗透测试当成证明安全性的唯一手段这是误解。标准接受的分析方法包括设计评审、代码审查、安全测试、渗透测试、漏洞扫描等形式组合。关键原则是每条安全需求都要有对应的验证活动验证结果要形成记录并能反查到具体需求。评审关口建议参考 DO-178C 的结构性思维来组织系统安全性评审、安全需求评审、安全架构评审、验证结果评审。每个关口都要有明确的进入条件和退出条件。例如安全架构评审的退出条件是安全架构描述对每条攻击路径都有处置声明且处置机制可追溯到安全需求。提示安全验证记录中要保留原始证据不能只写“测试通过”。证据包括测试环境描述、测试步骤、输入数据、预期结果、实际结果、异常记录。这条在局方审查时是高频检查点。4. 取证材料这样准备文档清单、追溯表与四个高频审查问题4.1 一个完整项目的文档体系怎么构成按 DO-326B 搭安全过程所需的文档和传统适航文档体系可以类比但内容侧重点有明显差异。下面这个清单是基于实践经验归纳的最小可交付集合文档对应阶段核心内容常见缺失Security Plan计划阶段安全活动范围、组织、时间表、裁剪理由没有裁剪论证直接抄模板Security Scope Definition计划阶段纳入/不纳入安全评估的功能清单不纳入项没有理由说明Threat Environment Description威胁分析前置运行场景、攻击者能力假设、受保护资产假设过强或过弱与机型不匹配Threat Impact Analysis安全等级推导候选功能、失效影响、威胁影响等级、安全等级等级推导过程没有与 FHA 联动Threat Analysis Report威胁分析威胁清单、攻击路径、可行性评估、风险处置攻击树只画不分析没有结论Security Requirements需求阶段安全需求编号、来源威胁、分配对象需求没有可验证描述无法测试Security Architecture Description架构阶段信任边界、跨边界数据流、安全机制图中没有标安全机制对应哪条威胁Security Verification Results验证阶段每条需求的验证方法、结果、问题处理测试记录缺少环境描述证据链断裂Security Case / 符合性总结审定阶段整体论证为什么认为安全状态可接受只剩复述前面文档没有综合论证这套文档体系与传统功能安全文档可以共用框架但内容上绝不建议合并成一份大文档。局方审查时通常由不同领域专家分别看功能安全审查员和安全审查员的关注点不一样合并后反而两边都不满意。4.2 安全需求追溯表的写法三列而成五列更好追溯表是整个证据链里的脊梁。最基础的三列是安全需求编号 → 来源威胁编号 → 验证记录编号。但实际审查中三列往往不够我建议至少做到五列安全需求编号来源威胁编号分配对象软件/硬件/架构验证方法验证记录编号SR-001T-001软件接口认证模块测试VR-001SR-002T-002架构数据链网关设计评审VR-002SR-003T-003软件配置加载模块代码审查测试VR-003追溯表的价值在于让审查员能顺三条路径检查从威胁出发能不能找到处置措施从安全需求出发能不能找到实现对象从验证记录出发能不能反查到需求。任何一条路径断了都会被记一条问题。实践中有个技巧把追溯表放进需求管理工具里自动生成不要手工维护 Excel因为项目后期需求变更频繁手工表几乎必然失效。4.3 审查员最爱问的四个问题及应对要点问题一“你的威胁环境描述是怎么得出的凭什么认为攻击者不具备更高能力”应对要点威胁环境要与机型运营场景绑定引用公开威胁情报时可以但要说明为什么适用于本项目不能默认所有攻击者都拥有国家级能力也不能假设所有攻击者都是门外汉。问题二“这一条安全等级为什么定为 Level 2 而不是 Level 1”应对要点指出威胁影响等级来自 FHA 分析结果安全防护强度有具体设计依据两者共同推导出等级。所有防护机制的有效性要有验证手段。问题三“这条安全需求对应的威胁路径有没有可能被另一条攻击路径绕过”应对要点威胁分析时应该做过攻击路径集合的完整性论证常见的论证方式是把系统外部接口全部枚举出来说明每条接口的攻击路径都已覆盖。这条要提前准备不要现场想。问题四“交付后的安全漏洞你们怎么响应”应对要点DO-355 已经定义了持续适航阶段的安全过程你的型号要说明与运营商、维修组织的安全信息传递渠道以及漏洞评估流程。如果项目部没有 DO-355 的策划这个问题就会挂掉。5. 避坑记录DO-326B 落地时最常见的五个翻车现场5.1 把安全等级和 DAL 混用成本直接失控现象项目团队把 DO-178C 的 DAL 等级直接“平移”成安全等级DAL A 对应安全等级最高级结果所有安全相关功能都按最高等级做安全需求数量膨胀验证工作量翻了三倍项目进度严重延误。原因DAL 和威胁影响等级虽然在“失效后果严重程度”上有一点相似但 DAL 不考虑攻击者因素安全等级却要考虑防护机制的有效性。两者混用导致了一个最直接结果——原本通过安全机制可以有效降低的等级没有被降下来。解决在安全计划里明确区分两个等级体系用一张映射表说明各自的推导依据。安全等级的推导过程单独写一节明确列出“哪些安全机制参与了降级论证”并给出这些安全机制的验证方式。5.2 威胁分析报告抄上一机型局方一追问就露馅现象同一家公司做的两个机型项目威胁分析报告结构相同、内容高度相似甚至连攻击路径编号都对得上。局方审查员追问“这个项目的维护接口协议和上一机型不同为什么威胁分析完全一样”项目组当场答不上来。原因威胁分析直接套模板没有按本项目的接口清单、协议列表、系统架构重新走一遍分析流程。标准的分析对象是“你这个系统的攻击面”不是“全行业通用的攻击面”。解决做威胁分析前先整理一份当前项目的接口枚举清单列出所有外部可访问的点——无线接口、维护口、物理接触口、地面站接口、载荷接口。威胁分析报告里要能看出每条威胁路径都对应清单上的具体接口。这个清单也是后续安全架构评审的输入。5.3 安全需求只在文档里“存在”设计里没有实现现象安全需求文档写了上百条设计文档里也有对应描述但代码实现里找不到相关逻辑。审查专家做代码抽查时发现某条“连续认证失败锁定”的需求在嵌入式软件里根本没有实现。原因安全需求没有进入研发的需求管理流程只在安全文档里单独维护开发团队从未在迭代计划里接收这些需求。解决把安全需求作为第一类需求纳入产品需求基线在迭代计划里给开发团队排任务。每条安全需求在代码评审时分派给指定负责人。提醒一点如果你们公司的需求管理工具里没有安全需求的跟踪视图大概率说明安全没有进入开发流程。5.4 没有安全功能清单后期补分析补到崩溃现象项目前期没有定义哪些功能属于安全相关功能Security-Related Aircraft Functions到了验证阶段才发现某个系统功能可以被攻击者利用来改变导航数据只能倒回去补做威胁分析和安全需求设计已经定型改造成本极高。原因安全功能识别没能和 FHA 同步完成等需求冻结后才回头做安全评估发现一堆新问题。这个问题在项目里很普遍因为大多数团队把安全和功能开发分成两条线缺少并行。解决在概念设计阶段就把“是否可被外部访问”作为一个筛选条件对所有候选功能做初步筛选。哪怕结果很粗至少要得出“可能相关、不确定、确定不相关”三档清单。确定不相关的要在安全范围定义里写明理由。5.5 交付没有持续适航安全方案审定阶段被卡住现象型号审定基本完成局方开始审查交付后的安全维护安排发现项目组没有定义安全事件响应流程、没有指定安全监测责任角色、也没有和运营商约定漏洞信息通报机制。整个取证过程被拖了三个月。原因DO-326B 的覆盖范围延伸到型号交付后的持续适航安全但很多项目组把精力全部放在研制阶段的文档和测试上忽略了持续适航安全策划。这个阶段的工作量不大但没有做就会被卡。解决在安全计划阶段就加入持续适航安全章节明确监测机制、事件响应流程、组织角色、运营商沟通渠道。参考 DO-355 的框架来写不用做得特别重但要能看到实际运行机制。6. 一个具体验证技巧用安全覆盖矩阵自查你的设计完整性验证阶段有没有快速自查的设计方法有。我习惯在安全架构评审前做一张安全覆盖矩阵——行是威胁分析报告里的威胁编号列是安全机制和安全需求交叉格填“覆盖/部分覆盖/未覆盖”。这张表的价值在于把架构层面的漏洞暴露在评审之前而不是等审查员发现问题。具体做法分三步。第一步从威胁分析报告里导出所有已判定可行的威胁编号作为矩阵行。第二步从安全架构描述里提取所有已实现的安全机制作为矩阵列。第三步逐个交叉检查每条威胁路径是否被至少一个安全机制阻断或缓解。如果发现某条威胁路径和所有安全机制都没有关联这就是架构设计层面的安全漏洞必须在评审前补设计或补需求。我通常还会在这个矩阵下面加一列“验证状态”标明每条威胁路径对应的安全需求有没有通过验证。这个动作很廉价但在项目后期能帮团队省大量返工时间——审查员拿到一张完整的覆盖矩阵通常比拿到一百页描述文档更有说服力。因为它把“你做了哪些事”变成“你能证明你做完并验证了什么”。另外两个小技巧也值得一提一是用统一的编号体系把威胁T、需求SR、验证记录VR三段串起来编号里带功能代码段这样只看编号就知道属于哪个子系统追溯时不用翻遍文档二是在每个里程碑评审前做一次矩阵更新邀请系统工程师和测试工程师一起来审安全工程师一个人填出来的矩阵往往有盲区。填矩阵这件事也是排查的好工具某一行长期空着大概率就是安全活动遗漏了某个子系统提前找出来比等审查员指出要好太多。这些年我见过太多项目在安全取证上吃亏多数不是因为技术做不到而是过程证据没跟上。DO-326B 真正的门槛不在标准文本有多厚在于你能不能坚持把每条威胁、每个需求、每次验证都串成一条完整的证据链。希望帮到你。本文还有配套的精品资源点击获取