Security Enhanced Linux to Enforce Mandatory Access Control in Health Information Systems Luis Franco, Tony Sahama, Peter Croll Faculty of Information Technology Queensland University of Technology GPO Box 2434, Brisbane, QLD 4001, Australia
[email protected]
Abstract This paper introduces Security Enhanced Linux (SELinux) as the required Operating System (OS) to enforce Mandatory Access Control (MAC) mechanisms to protect Health Information. Health Information Systems (HIS) require an OS which can enforce MAC rules so that access to the resources does not rely on the discretion of the users, thus minimizing the damage when users’ applications are compromised. SELinux provides a flexible and fine-grained MAC architecture implementing a combination of Type Enforcement (TE) and Role-Based Access Control (RBAC). SELinux however, is considered to be difficult to implement because of the complexity of SELinux policies required by the fine-grained access controls. To reduce the complexity to manage SELinux policies different tools and methods have been developed increasing the feasibility to use SELinux to create trusted systems. Keywords: HIS, Access Control, Health Information Privacy, SELinux, MAC, RBAC, SELinux Policy Tools.
1
Introduction
The use of Information and Communication Technologies (ICT) to hold large amounts of patients' information and to allow access to this information from different sources is becoming more common to improve the quality, safety and efficiency of healthcare services. Initiatives in the adoption of technologies to store and access Health Information using networked Health Information Systems (HIS) have been demonstrated in past years, for example, initiatives from the National Health Services (NHS) in the UK, the Nationwide Health Information Network (NHIN) in the United States and the Integrated Health Record and Information System (IHRIS) in Australia. As the use of ICT to collect, manage and share Health Information to support the delivery of healthcare and promote health become more widespread, the privacy of patient’s information is becoming an important issue. As recognized by the Australian Privacy Foundation (Brewin, 2005), the use of Electronic Health Records
Copyright © 2007, Australian Computer Society, Inc. This paper appeared at the Australasian Workshop on Health Data and Knowledge Management (HDKM 2008), Wollongong, NSW, Australia. Conferences in Research and Practice in Information Technology, Vol. 80. James R. Warren, Ping Yu, and John Yearwood, Ed. Reproduction for academic, not-for profit purposes permitted provided this text is included.
(EHR) has raised concerns in relation with the trustworthiness of the systems by which patients can access their own records. Main privacy issues related with systems that manage EHR are those in which the access to Health Information can be compromised. Authentication and authorization are key security goals in HIS while authorizing access to the resources only to those individuals with the need-to-know rights to the information, and granting the least number of privileges required to commit the intended tasks. Systems with poor security mechanisms can be faulted through unauthorized access to the information that can be obtained by posing as the patient or hacking into the database/system. Privacy can be also compromised when authorized users have access to more information than they require and using it for purposes for which they were not authorized. For a system to be considered usable and legally compliant, privacy and security issues must be adequately addressed. HIS are constructed with the awareness that security is required to assure individuals that their Health Information will remain confidential. However, systems are built based on the flawed idea that security can adequately be provided by the applications used to access the information (Loscocco et al., 1998). The Operating System (OS) is responsible for the overall protection and dependable operation of the application-space mechanisms. Therefore, constructing trustworthy HIS requires a secure OS that enforces the security requirements in Healthcare environments (Liu et al., 2007).
2
Paper Overview
This paper is dedicated to demonstrate that Security Enhanced Linux (SELinux) is the appropriate Operating System (OS) to use in Health Information Systems (HIS). The paper’s main concern is the management of SELinux policies, which is considered to be the main factor limiting the adoption of SELinux. The first part of this paper introduces the concepts of Access Control giving some types of Access Control Models that can be used in HIS, selecting Role-Based Access Control (RBAC) as the most suitable option. The second part is dedicated to explain the importance of the Operating Systems Mandatory Access Control and introduces available options in the market. The last part explains how the SELinux policy management complexity can be reduced using existing tools.
3
Access Control and Healthcare
In Health Information Systems (HIS) disclosure of health information shall be done only with the patients’ consent or in a situation of extreme emergency. Unauthorized disclosure of Health Information has serious consequences including refusal of employment, difficulties with insurance contracts, personal embarrassment and exclusion from family or social groups. Nevertheless, there are special circumstances in which Health Information has to be disclosed without the authorization of the patient, for example, during an emergency or after the patients’ death. These create constraints that must be addressed in order to ensure a proper management of Health Information without exposing sensitive Health Information to unauthorized usage.
discretion of the system administrator. If a flawed application can run with the system administrator privileges, it will get access to all the resources in the system. The access decision based on the discretion of the creator of information makes DAC not the most suitable access control model to protect sensitive Health Information.
The use of security mechanisms to protect Health Information is not something new. The use of encryption, data signing, certificate exchange and audits has been used to protect confidentiality, integrity, authentication, and accountability of the information while transmitted. However, these mechanisms are not enough to protect Health Information. Access to Health Information has to be restricted so that the owner of the information has the assurance that the information is always accessed in a controlled and secured manner. Access to Health Information is an important issue which becomes more complicated once this information is shared in interconnected HIS. As more systems are interconnected more people could have access to the information, and this heightens the risk of losing access control over that information. The main problem while protecting Health Information is not that the information is accessed, but the basis in which that information is accessed. Access to the information must be restricted to a need-to-know basis, restricting individual users to the minimum amount of information needed to complete a specific task. Access Control Mechanisms are used in computer systems to ensure that only authorized users have access to the resources. The most common type of access control mechanisms used to protect information from unauthorized access is Discretionary Access Control (DAC) in which the access to the information is on discretion of the creator of the information. Most of the contemporary Operating Systems (OS) make use of this type of access control to restrict the access to the information granting the owner of the information the ability to pass permissions over their owned resources to other users or programs. This is the main vulnerability of DAC systems, in which an application running on behalf of an authorized user will acquire the same privileges to the resources to which the user is authorized to access. If the application is flawed, the application can be committing actions over the user’s resources that the user is not aware of. Furthermore, OS that implement DAC mechanisms make use of two types of users: the system administrator and the unprivileged user. The system administrator has ownership over every resource in the system thus every resource is under the
Figure 1: Discretionary Access Control The weaknesses identified in a DAC can be addressed using Mandatory Access Control (MAC) in which the access to the information is restricted by the system and not at the discretion of the system administrator. MAC takes access decisions based in labels containing securityrelevant information assigned to subjects and objects in the system. Access decisions are not in the discretion of the creator. Those who create, access, and maintain information shall follow rules set by the policy and administered by the organisation. The enforcement of access control rules by the system according to organisational policies makes MAC highly suitable for protecting Health Information. The most common implementation of MAC is the Multilevel Security (MLS) which is based on assigning hierarchical clearances and classification to subjects and objects respectively and non hierarchical categories for both. MLS is based on a formal model called the BellLaPadulla model which makes use of three security properties to ensure the secure state of the system: simple security, star property and discretionary security property. In MLS subjects can only read objects that are in the same sensitivity level or lower levels and write objects in the same sensitivity level or higher. MLS systems are designed to protect the confidentiality of the information only in a very strict and inflexible manner, which is suitable in a highly hierarchical environment such as military organisations, but very inflexible for Healthcare Organisations.
privilege principle. Nevertheless, there are several limitations when applying RBAC in a healthcare context which impacts on the adoption of this model. An example of this as identified by Bennett, Rigby and Budgen (2006) is the use of specialized role functions and the adoption of privileges in cases of absence. These limitations are addressed in different approaches based on RBAC, but remains unclear which are the most suitable for healthcare organisations. The National Institute of Standards and Technology (NIST) for example, have made different researches on how to implement RBAC in HIS. One of these initiatives is the Dynamic Authorisation Framework for Multiple Authorisation Types (DAFMAT) which combines RBAC and a type of Type Enforcement (TE) called Dynamic Type Enforcement (DTE) to address the multiple types of authorisations required in HIS (Chandramouli, 2001).
Figure 2: Multilevel Security In current organisations access has to be based on the need-to-know principle, the concept of competency, enforcement of conflict-of-interest rules, and a strict concept of least privilege (Ferraiolo, Kuhn, & Chandramouli, 2003). Therefore, access to the resources has to be based on a user function or organisational role. Role-Based Access Control (RBAC) is a policy independent model that can be configured as MAC and/or DAC. Nevertheless, RBAC is considered a form of nondiscretionary access control since users do not have discretionary access to enterprise objects. In a functional perspective, roles are associated with operations and users are members of one or more roles. The actions represented by operations that users can commit over an object depend on the role to which the user belongs. Access decisions are based on the roles to which the individual are a member of. In a hospital context, roles can be Doctor, Nurse, Researcher, or Clinician. Users are assigned to one or more of those roles depending on their functions in the hospital (Ferraiolo, Cugini, & Kuhn, 1999). Members of the roles are constrained by the operations assigned to those roles. For example, a Doctor can prescribe medications while a Researcher can be limited to gather anonymous clinical information. RBAC has security principles which are useful to protect healthcare information such as enforcement of least privilege principle and enforcement of conflict of interest rules. In an administrative point of view, RBAC simplifies the understanding and management of privileges and increases the level of abstraction making use of roles, role hierarchies, relationships and constraints. RBAC is a suitable access control model to protect Health Information due to restrictions based on the individuals’ job functions and enforcement of least
Figure 3: Role-Based Access Control
4
Operating Control
System
Mandatory
Access
Mandatory Access Control (MAC) integrated in the Operating System (OS) can improve the systems’ security and address vulnerabilities at the application layer (Loscocco et al., 1998). Secure applications have to be constructed based in a trusted OS to ensure that access control rules are not bypassed. Applications are considered to be the principal point of failure in a system, for example, a flawed application can be used to get system administrator privileges in a specific host and consequently getting access to unauthorized resources. MAC mechanisms can help an OS to create sandboxes in which the application can run and limit their activities to specific resources (Hericksen, Caelli, & Croll, 2007). As mentioned in the previous section, MAC is required to protect Health Information thus is important to use an OS which implements MAC mechanisms.
5
Operating System Control Options
Mandatory
Access
Mandatory Access Control (MAC) integrated in the Operating System (OS) has been used for several years in military environments, but only in recent years its use has been widely available for organisations in general. Currently there are some OS which employ nondiscretionary access control methods such as Windows 2003, HP-LX, Linux and Solaris. From which Solaris Trusted Extensions and Security Enhanced Linux (SELinux) have been certified at the Common Criteria EAL4+ against the CAPP, LSPP, and RBACPP (Common Criteria, 2007). In this paper SELinux is introduced as the most suitable Operating System Mandatory Access Control solution from those previously introduced. SELinux has several security features which are of main interest for those keen to protect their sensitive information when creating trusted systems. Systems like Solaris Trusted Extensions however, provide similar security features plus features that could make its use more user-friendly. Then, what makes SELinux a more suitable solution for Health Information Systems (HIS)? SELinux was initially developed by the U.S. National Security Agency (NSA) as part of a research in highassurance OS security. In December 2000, the NSA made it available to the open source community to get support and viability for its usage. In August 2003, the NSA with support from the open source community merged it in the mainline Linux 2.6 kernel. SELinux is freely available to anyone for purposes from research studies to enterprise implementation. Access to this type of OS before SELinux was difficult because most of them were classified or very expensive. This makes SELinux a more suitable solution not only because of its features, but also for the increasing interest from the open source community and researches all around the world. As a consequence of the increasing interest, SELinux features are strengthen, its functionality is improved, more tools are developed, and more documentation is available. SELinux implements a type of MAC called Type Enforcement (TE) which is a variation of the traditional TE due to the use of object classes along with types for objects and domain for subjects. SELinux also provides a form of Role-Based Access Control (RBAC) built upon TE in which roles are used to group domain types and relate these domains with users, but decisions are based on TE rules instead of RBAC permission assignments (Mayer, MacMillan, & Caplan, 2007). SELinux manages orthogonal user’s identifiers between the SELinux identifiers and Linux UIDs. This improves the level of accountability of users’ activities in the system. A correct implementation of SELinux provides important security advantages to HIS with features such as finegrained access controls, orthogonal user identities, and flexible policy configuration. Also, by configuring a RBAC security policy in SELinux the system can restrict users to the domain types specified to their roles and allow inheritance of privileges using role hierarchies simplifying the task of access assignment.
Even though SELinux’s highly flexible and fine-grained architecture can help to meet security objectives in HIS, writing customised SELinux policies is very complicated. To create fine-grained SELinux policies an administrator needs to know and understand every access that a new application requires to operate properly. Adding a new SELinux policy module in the current SELinux policy requires the administrator to know every type, attribute, alias, role, and object class already defined. In addition, to avoid policy or constraint conflicts the administrator need to know all the existing access vector rules, constraint rules, and type enforcement assertions. A typical Linux environment has hundreds of resources and applications that need to be protected, making thousands of lines in a SELinux policy. The perceived difficulty of writing SELinux policies is one of the major factors preventing the widespread adoption of SELinux.
6
SELinux Policy Management Tools
In recent years there has been an increasing interest to minimise the burden of managing Security Enhanced Linux (SELinux) policies by the open source community and other institutions. As a result of this effort different SELinux policy management tools for different purposes have been developed. These tools can be subdivided according to four SELinux policy management stages: planning, creating, testing and maintaining. Also, policy development is constituted by: SELinux policy tools, SELinux policy language and SELinux policy architecture.
Figure 4: SELinux Policy Management Stages and Tools
6.1
Planning Stage Tools
The definition stage is composed by those tools that enable to get the access history required by an application to operate properly while applying the least privilege principle. For an administrator to create a well-formed SELinux policy it is necessary to understands all the resources that the application access at run time. If the administrator fails in this task, although the policy may be syntactically correct, it could restrict access to authorized resources or allow access to unauthorized resources. Currently, there are no specific tools which can help only on this specific task, but there are tools and methods that can be used to get the application’s access history. The approach described by Harada, Horie and Tanaka (2003) is the most approximated solution for this task. They made modifications in the “vanilla” Linux kernel so that the system would keep the process execution history and dump this value into a log. This log contains the detailed description of accesses made by the targeted application.
There are other tools from which the access history can be extracted such as Polgen (Sniffen, Harris, & Ramsdell, 2006) and Setroubleshoot (Dennis, 2007). Polgen is a tool that can be used not only by System Administrators but also by application authors for automated SELinux policy generation. Polgen make use of other tools that can be subdivided into pattern decision, information flow and guided automation. Polgen uses a modified “strace” tool to identify dynamic behaviour of a targeted application. The modified “strace” displays the security context of the executing process and the resources accessed. Setroubleshoot is a tool that exposes Access Vector Cache (AVC) denials in real time and interacts with the user presenting the current denial and presenting possible solutions. This tool can be used to determine accesses that were missing or that are required by a newly introduced application in the system. Because of their easier usage and low expertise required to use them, both tools, Setroubleshoot and Polgen, can be used to help system administrators who need to create or modify policies for new applications in HIS.
There are some utilities provided with any distribution of Linux that can be used for this purpose. The SETools Suite includes libraries and tools that can be used for analysing and debugging SELinux policies. One of the included tools is Apol which is very useful while analysing SELinux policies. Apol is a SELinux analysis tool which can work with either example policies or reference policies. This tool allows analysing modules in search of allowed permissions, existing roles, constraints, and also Multi Level Security (MLS) rules. Other useful tool of the SETools Suite is the seaudit tool which can be used to browse and analyse Access Vector Cache (AVC) Messages. The messages provided in this tool can be used to identify any missing permission and make any corrections in the SELinux policy if required. Along with seaudit we can use the already mentioned Setroubleshoot for the analysis of AVC Messages. The advantage of using this tool is that it provides a proposed solution to the problem and an understandable explanation of it.
6.4 6.2
Creating Stage Tools
The generation stage is composed by those tools that help to generate SELinux policies in a more understandable and user-friendly way. There are many development tools that can help to minimize the complexity of generating policies, but here the focus will be on those that can be used in the Reference Policy for reasons described further in this paper. For those who like to develop in a text mode exist a file which adds colour features to the vim text-editor. This will add colour to different components and areas in a SELinux policies, but do not provide any addition features or functionality. Tresys Technology created a plug-in called SLIDE that can be used in Eclipse Development Toolkit to create, edit, and test SELinux policies. This tool is comprised by a graphical interface which makes the development of SELinux policies easier and user-friendly. The system administrator can manage SELinux policies and receive valuable feedback when SELinux policies are tested. The plug-in also provides templates that can be used to simplify the addition of new modules in a SELinux policy when a new application is installed in the system. Also, from Tresys Technology, Tresys Brickwall Security Suite (TBSS) helps to reduce the gap between a low-level SELinux access control language and a high-level abstraction language. The abstraction used in TBSS helps to change the perception that SELinux is too complex to be implemented. Also, its use can reduce time and effort spent by a system administrator when adding a new application to the system.
6.3
Testing Stage Tools
The testing stage is composed by those tools that help to verify if the SELinux policy is working properly and meeting security goals.
Maintaining Stage Tools
The maintenance stage is composed by those tools that enable the modification of SELinux policies without the need to recompile or rebuild the whole SELinux policy. Also, this stage includes tools that allow an immediate change between SELinux policies if specific changes in the environment are detected (which is helpful in emergency situations). As described above, Setroubleshoot can be used to easily identify modifications required in the SELinux policy if an application has an access problem to an authorized resource. Without a tool like Setroubleshoot the scan of log files for Access Vector Cache (AVC) denials require a high level of expertise because of the unfriendly presentation and complexity of its content. Even if the message in the log is understandable, following that message into a complete understanding of the problem and finding the solution is very complex. In order to create a system that is able to react to specific changes in the environment there are tools that are created for self-defending systems which make use of SELinux Conditional Policies. Self-defending systems are those systems which can be configured to act on behalf of internal and/or external attacks to ensure their own security, without the presence of the system administrator (Butler, Pollet, & Hale, 2006). In a Healthcare organisation changes to the environment could be defined as those in which an emergency situation arises and changes in the policy have to be made without the presence of the system administrator. SELinux conditional policies can be used along with a Dynamic Policy Enforcement Agent (DPEA) to create selfdefending systems (Butler, Pollet, & Hale, 2006). The DPEA will check for local or remote logs to make decisions and enable or disable specific sets of rules in the SELinux policy.
6.5
SELinux Policy Development Architecture
Currently there are two methods for building SELinux policies: the Example Policy and the Reference Policy. The Example Policy has demonstrated to be difficult to understand, develop and maintain. The Reference Policy is rigorously structured, making SELinux policies easier to maintain, modify and use. The Reference Policy project is an effort to restructure the National Security Agency (NSA) Example Policy. The main reason to restructure the Example Policy is that it is difficult to understand, develop and maintain (PeBenito, Mayer, & MacMillan, 2006). The aims of the Reference Policy are to use software engineering techniques to make the policy more maintainable, verifiable, and useable. The Reference Policy makes use of concepts such as layers, modules, encapsulation rules, and abstractions. As part of the encapsulation, the Reference Policy makes use of three Macros, namely: interface, template, and support. The use of macros means that the person who is modifying/creating the policy does not need to understand everything in the existing policy to implement a new module. This is a great advantage, firstly because there are not global types and attributes, and secondly because the creation of a new module does not require the understanding of the content of all of the other modules. The Reference Policy is recommended to be implemented in any Health Information System (HIS) which decides to use SELinux. This will create the bases for simplified SELinux policy management.
6.6
SELinux Policy Development Languages
In addition, there is a great interest to create high level languages that are based on the SELinux policy language adding a level of abstraction making it simpler to understand for application developers. These languages are still in its early stages but can represent a significant improvement in the future. The SELinux policy language can be considered complicated because the application developers are accustomed to other type of languages in which the abstraction level allow the developer to make use of data types, functions or object classes. Therefore, is important to provide the application developers with programming languages with which they are more familiar. SENG (Kuliniewicz, 2006) is a new language that is built based on the existing SELinux policy language but adding a higher-level of abstraction. This level of abstraction goes far beyond the use of macros which can be considered a problem for analysis tools, i.e., macros can have difficulty in verifying the access vector rules, in particular, the type transition rules. SENG creates custom types, grouping types, permission and type enforcement rules belonging to the same group of objects or to the same process. For example, SENG groups all the required type enforcement rules required in a type transition, creating a custom type transition which allows the policy writer to specify rules that should be evaluated along with a type transition.
7
Conclusions
Security Enhanced Linux (SELinux) is an Operating System (OS) that can be used in Health Information Systems (HIS) to enforce Mandatory Access Control (MAC) mechanisms. MAC is required to protect unauthorised access to Health Information which could have serious consequences. The nature of HIS requires an access control model which allows a high level of flexibility while enforcing access control policies. RoleBased Access Control (RBAC) can demonstrate to be suitable for HIS, but research is being undertaken to add features to strength its implementation. SELinux provides a flexible and fine-grained MAC using Type Enforcement (TE) and RBAC. The freely availability of SELinux along with the increasing research on it, makes it an outstanding option for HIS. However, its configuration can be a tedious task, requiring a high level of expertise not commonly available in HIS. The adoption of SELinux to provide MAC mechanisms to protect against unauthorized access to the information is more feasible once the SELinux policy management is not perceived as a burden. Currently, there are an increasing number of tools which can help to minimize the expertise required to manage SELinux policies. SELinux is not the complete solution to protect Health Information but is the base to construct HIS that can assure the correct use by authorised users of sensitive Health Information.
8
References
Athey, J., Ashworth, C., Miner, D., & Mayer, F. (2007). Towards intuitive tools for managing SELinux: Hiding the details but retaining the power. 2007 Security Enhanced Linux Symposium. Baltimore, Maryland, USA. Bennett, K., Rigby, M., & Budgen, D. (2006). Role Based Access Control – a Solution with Its Own Challenges. IEE Proceedings - Software, 153(1), 1-3. Brewin, B. (2005). Australia health IT faces privacy fears. GovernmentHealthIT. Retrieved September 18, 2007, from: http://govhealthit.com/article89294-0617-05-Web Butler, M., Pollet, B., & Hale, J. (2006). Dynamic Policy Enforcement in a Network Environment. 2006 Security Enhanced Linux Symposium. Baltimore, Maryland, USA. Chandramouli, R. (2001). A framework for multiple authorization types in a healthcare application system. 17th Annual Computer Security Applications Conference. New Orleans, Louisiana. Common Criteria. (2007). List of evaluated products page. Retrieved 18 Sept., 2007, from http://www.commoncriteriaportal.org/public/developer /index.php
Dennis, J. (2007). Setroubleshoot: A user friendly tool to diagnose AVC denials. 2007 Security Enhanced Linux Symposium. Baltimore, Maryland, USA. Ferraiolo, D. F., Cugini, J. A., & Kuhn, D. R. (1999). Role-Based Access Control (RBAC): Features and Motivations. Gaithersburg: National Institute of Standards and Technology. Ferraiolo, D. F., Kuhn, D. R., & Chandramouli, R. (2003). Role-Based Access Control. Norwood : Artech House. Harada, T., Horie, T., & Tanaka, K. (2003). Access policy generation system based on process execution history. JNSA '03: Network Security Forum 2003. Tokyo, Japan. Henricksen, M., Caelli, W., & Croll, P. (2007). Securing grid data using Mandatory Access Controls. Proceedings of the fifth Australasian Symposium on ACSW frontiers. Ballarat, Australia. Jaeger, T., Sailer, R., & Zhang, X. (2004). Resolving constraint conflicts. SACMAT '04: Proceedings of the 9th ACM Symposium on Access Control Models and Technologies. Yorktown Heights, New York, USA. Jaeger, T., Zhang, X., & Edwards, A. (2003). Policy Management Using Access Control Spaces. ACM Transactions on Information and System Security, 6(3), 327-364. Kuliniewicz, P. (2006). SENG: An enhanced policy language for SELinux. 2006 Security Enhanced Linux Symposium. Baltimore, Maryland, USA. Liu, V., Caelli, W., May, L., Croll, P., & Henricksen, M. (2007). Current approaches to secure health information systems are not sustainable: an analysis. MEDINFO 2007. Brisbane, Australia. Loscocco, P. A., Smalley, S. D., Muckelbauer, P. A., Taylor, R. C., Turner, S. J., & Farrel, J. F. (1998). The inevitability of failure: The flawed assumption of security in modern computing environments. Proceedings of the 21st National Information Systems Security Conference. (pp. 303-314). Mayer, F., MacMillan, K., & Caplan, D. (2007). SELinux by example: using security enhanced Linux. Upper Saddle River, NJ: Prentice Hall. PeBenito, C. J., Mayer, F., & MacMillan, K. (2006). Reference Policy for security enhanced Linux. 2006 Security Enhanced Linux Symposium. Baltimore, Maryland, USA. Reid, J., Cheong, I., Henricksen, M., & Smith, J. (2003). A novel use of RBAC to protect privacy in distributed health care information systems. 8th Australasian Conference on Information Security and Privacy. Wollongong, Australia. Sniffen, B. T., Harris, D. R., & Ramsdell, J. D. (2006). Guided Policy Generation for Application Authors. McLean, Virginia, USA: MITRE
