A Model-Based Framework for Security Policy Specification, Deployment and Testing

Tejeddine Mouelhi, Franck Fleurey, Benoit Baudry, and Yves Le Traon, MoDELS 2008

1、用model-driven的方法进行security policy测试，可行，但是扩展性有多大？可靠性又如何？值不值得深入研究？

首先在P.I（platform independent）对SP model进行验证，验证内容包括：冲突规则，访问规则等；
在此之后，自动生成PDP，实际中不需要生成完整的PDP，因为有可复用的安全框架可以被使用来生成PDP。这一步的产品是XACMAL文件；
然后是关键的一步，即根据安全描述模型将PEP整合到系统功能代码中，这一部采用AOP（aspect-oriented programing）实现，可以将整合过程产生的错误降低到一定程度；

对PDP和PEP的进一步理解：
PDP两个功能：封装用XACML表述的SP和提供访问SP的服务
PEP是部署在应用程序里（以代码段形式存在在软件代码里），包括应用程序概念（user roles, methods, resourses and contexts）和SP 概念（roles, actvities, views and contexts, or roles, permissions and constraints）的映射

本文作者设计了一个model-driven框架用于描述，部署和测试Security Policy，目标是通过自动化方法以高可信度在系统中实现Security Policy（即尽量减少SP实现与设计的不一致）。为了达到这一目标作者设计了一个完整的MDE过程用于Security Policy的描述，部署和测试。
首先，作者定义了一个Security Policy元模型，该模型独立于具体的Security Policy（如OrBAC和RBAC），领域专家依据该元模型定义具体的Security Policy模型，进而就可以为规则（rules）以该具体的模型来建模了；
然后，实现了由元模型到XACML的转换，即实现了由元模型自动生成PDP（policy decision point）。PEP（policy enforcement point）是通过AOP实现的，是为了提高PEP代码段的可靠性；
至此，就得到了具有Access Control功能的最终系统实现。

我所关注的是作者如何对部署的Security Policy进行测试。作者提出，由于定义了Security Policy元模型，使得在具体的Security Policy模型建立之初，就可以对其进行验证，验证内容包括：冲突规则，访问规则等；
文章依旧采用mutation testing方法评估测试用例的好坏，然而并未把重点集中在测试用例生成上，同时，对测试目标也没进行严格定义。

本文贡献：
1、设计了一个完整的model-driven框架用于描述，部署和测试Security Policy；
2、定义了独立于具体Security Policy的Security Policy元模型；
3、实现了一个工具，该工具可以自动从Security  Policy模型转换到XACML文件；
4、用AOP编程范型实现由Security Policy模型到PEP的转换；

本文不足：
1、假设作者提出的mutation分析方法是有效的，然而作者只实现了映射到XACML（PDP）的mutation，而实际的Security Policy错误，还包括PDP，即系统实现代码的错误，因此将不能评估PEP的测试用例；
2、既然从Security Policy到XACML转换是自动进行的，那就应当保证转换过程本身以及转换的结果是正确的，或者提出验证正确性的方法，但是作者并没有对此作出交代；
3、作者并没有严格定义对Security Policy进行测试的测试目标。目前我认为对Security Policy测试的目标至少应当有两个：一是对XACML（或其他描述性语言）正确性的测试；二是对PEP正确性的测试，即嵌入在系统实现代码中的Security Policy。

总结与思考：
本文主要贡献侧重于定义Security Policy的元模型，以及由模型到实现的转换机制，并没有基于此提出明确的测试Security Policy的方法。然而将model-driven技术用于Security Policy测试，是否可行？可扩展性有多大？可靠性又如何？值不值得深入研究？
目前，我认为对Security Policy的测试有两个问题：
1、测试目标的确定。一个具有Security Control功能的系统，至少有三个部分：PDP，PEP和业务功能。Security Policy错误可能发生在两个位置，分别是PDP和PEP。例如XACML文件错误，程序代码错误分别属于上述两种错误。因此应当针对这两类错误进行测试，测试员期望得到的是包含错误发生位置的报告。
2、测试用例的生成。如何针对测试目标生成测试用例？覆盖准则是什么？直观上看，应当保证每一条规则都至少被一个测试用例覆盖，这里又有两个问题：第一，用什么样的方法生成测试用例？针对程序语言有Symbolic Excution或者Concolic Testing，现在需要寻找一种方法，面向Security Rules生成测试用例；第二，即便得到了覆盖每一个rule的测试用例集，然而对于同一条rule，在系统中可能有多处实现，由于执行的是黑盒测试，仅仅根据输入输出还无法定位错误发生的具体位置。