Model-Based Tests for Access Control Policies

本文探讨了基于角色、权限、上下文等元素的RBAC模型来生成安全策略测试用例的方法,包括独立于策略和依据策略两种生成方式。通过评估发现,依据策略生成的测试用例在有效性上优于独立生成的测试。研究贡献了自动生成安全策略测试的技术,并强调了将安全策略考虑在内的必要性。
Alexander Pretschner, Tejeddine Mouelhi, Yves Le Traon, ICST.2008

本文工作:
提出两个安全策略测试生成的方法:独立于policy和依据policy。
作者采用RBAC模型描述Security Policy,并且对其进行了扩展,加入了context元素。首先作者定义了Security Policy元模型:

一个RBAC Security Policy由至少一个规则构成,每一个规则包含四个元素:role,permission,context,priority,规则形如prohibition(borrower, borrowbook,holiday,5)
RBAC支持元素的层次结构,例如,对于一个具体的role,people,其下层可具体为teacher,student,具体的role适用于其父节点的规则。

作者使用两种方法生成测试,分别是独立于policy的随机生成法和依据policy生成测试。
独立于policy的方法:
不考虑规则,随机地从role(permission,context)集合中选取实例构成测试。

依据policy的方法:
针对每一条规则,依据role,permission,context这三个元素生成测试,选取某个具体的role(permission,context)以及继承它的所有role(permission,context);
考虑到规则分为permission和prohibition,因此有必要对没有在规则中规定的方面进行测试,可以生成role(permission,context)和其子role(permission,context)之外的实例构成的测试;

作者用mutation测试方法评估生成的测试,测试数据表明,随机生成的测试用例的mutation score要低于依据policy生成的测试用例。依次作者得出结论:在生成安全策略测试用例时,将安全策略考虑进来(即依据安全策略)是极有必要的

本文贡献:
1、提出了两种自动生成安全策略测试的方法和技术:独立于安全策略和依据安全策略;
2、对生成的测试进行了有效性分析,得出重要结论:在生成安全策略测试用例时,将安全策略考虑进来(即依据安全策略)是极有必要的。

这个生成测试用例的方法和我想的差不多,只是Mouelhi没有借助数据结构(比如decision tree)

本文不足:
1、没有提供可用的工具

Application

NO. of rules

NO. of roles

NO. of permissions

NO. of contexts

library management system

41

7

10

4

access control policy of hospital

37

10

15

3

auction system of eBay

130

8

23

4

meeting management

system

106

8

18

3




<think>嗯,用户现在想了解不同软件集成测试环境的区别,特别是Model-in-the-loop (MIL)、Software-in-the-loop (SIL)、Processor-in-the-loop (PIL)和Hardware-in-the-loop (HIL)。这个问题其实和之前讨论的ISO 26262软件架构设计有密切联系,因为测试环境的选择直接影响功能安全验证的有效性。 从用户引用的资料看,ta应该是在工业自动化或汽车电子领域工作,可能正在设计基于NI平台的视觉或运动控制系统。用户特意提到LabVIEW和NI Vision,说明实际应用场景可能涉及图像处理或运动控制算法的测试验证。不过用户强调"引用仅供参考",说明更关注测试方法论本身而非具体工具。 关于测试环境的区别,需要从四个维度展开:测试对象抽象层级、执行环境、测试目的和适用阶段。比如MIL是在纯模型层面验证算法逻辑,完全脱离硬件;而HIL则是把真实控制器接入虚拟环境测试。有趣的是,PIL作为过渡阶段经常被忽略,但它对嵌入式编译器优化的验证很关键。 用户之前研究过ISO 26262的动态设计要素,所以回答时要呼应功能链和时序约束的验证需求。比如HIL测试能有效验证逻辑序列的时序约束,而MIL更适合早期检查功能链完整性。可以举例说明:在AEB系统中,MIL验证碰撞决策算法功能链,HIL则验证从图像采集到制动执行的端到端延迟是否满足100ms要求。 注意到用户是技术型专业人士,回答需要突出工程实践细节。比如解释SIL测试时,要说明为什么需要关闭编译器优化;讨论HIL时要强调IO接口的实时性要求。最后生成的延伸问题应该引导用户思考如何将这些测试环境融入安全生命周期,比如ISO 26262要求的测试覆盖率指标如何分配在不同测试阶段。</think>以下是不同软件集成测试环境的对比分析,重点关注其区别与应用场景: --- ### **测试环境核心区别** | **测试类型** | **测试对象** | **执行环境** | **验证目标** | **适用阶段** | |----------------------|--------------------|----------------------|---------------------------------------|---------------------| | **Model-in-the-Loop (MIL)** | 算法模型 | PC仿真环境 | 功能逻辑正确性、需求符合性 | 早期设计阶段 | | **Software-in-the-Loop (SIL)** | 生成代码 | PC环境(脱离目标硬件)| 代码功能等效性、数值精度 | 代码生成后 | | **Processor-in-the-Loop (PIL)** | 编译后的可执行文件 | 目标处理器(如MCU) | 编译器优化影响、处理器兼容性 | 硬件集成前 | | **Hardware-in-the-Loop (HIL)** | 完整嵌入式系统 | 实时仿真器+物理硬件 | 实时性、硬件交互、故障注入 | 系统集成阶段 | --- ### **关键差异详解** 1. **抽象层级** - **MIL**: 验证数学模型(如Simulink/Stateflow模型) $$ \text{需求} \rightarrow \text{模型行为} \quad \text{(例:NI Vision算法模型[^1])} $$ - **SIL/PIL**: 验证代码实现(如C/C++代码) $$ \text{模型} \xrightarrow{\text{代码生成}} \text{可执行逻辑} $$ - **HIL**: 验证物理系统(如ECU+传感器/执行器) $$ \text{硬件} + \text{实时环境} \quad \text{(例:NI SoftMotion控制[^2])} $$ 2. **实时性要求** - **MIL/SIL**: 非实时(关注功能正确性) - **PIL/HIL**: 强实时(需满足毫秒级时序约束) > PIL验证任务调度最坏执行时间(WCET),HIL验证电子制动响应≤5ms[^2] 3. **测试输入/输出** | **测试类型** | **输入源** | **输出监测** | |--------------|------------------|----------------------| | MIL | 仿真信号 | 模型输出变量 | | HIL | 传感器模拟信号 | 执行器物理响应 | --- ### **工程应用场景** 1. **MIL** - 验证图像处理链功能(如NI Vision缺陷检测算法[^1]) - 例:摄像头模型→目标识别模型→决策模型的功能链验证 2. **SIL/PIL** - 测试运动控制代码(如NI SoftMotion轨迹规划算法[^2]) ```c // 电子凸轮代码SIL测试 void updateCamProfile(float position) { // 验证代码逻辑 vs 模型输出 } ``` 3. **HIL** - 硬件故障注入测试(如模拟摄像头信号丢失) - 实时闭环验证(例:电机控制+视觉反馈的协同系统[^3]) --- ### **测试环境选择策略** ```mermaid graph LR A[需求分析] --> B{是否涉及硬件?} B -->|否| C[MIL/SIL测试] B -->|是| D{是否需实时验证?} D -->|否| E[PIL测试] D -->|是| F[HIL测试] ``` --- ### **ISO 26262 关联要求** 1. **MIL**:满足Part 6
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值