Abstract
Although security plays a major role in the design of software systems, security requirements and policies are usually added to an already existing system, not created in conjunction with the product. As a result, there are often numerous problems with the overall design. In this paper, we discuss the relationship between software engineering, security engineering, and policy engineering and present a security policy life-cycle; an engineering methodology to policy development in high assurance computer systems. The model provides system security managers with a procedural engineering process to develop security policies. We also present an executable Prolog-based model as a formal specification and knowledge representation method using a theorem prover to verify system correctness with respect to security policies in their life-cycle stages.
Highlights
High assurance computer systems are those that require convincing evidence that the system adequately addresses critical properties such as security, safety, and survivability[13]
We use the following terms: entity to refer to any source or destination through which information can flow; security enclave to refer to a logical boundary for a group of entities that have the same security level (e.g., CS faculty, ER physicians, C-130 pilots); and message to refer to any data that has been encoded for transmission to or received from an entity
Our research focuses on the Multiple Independent Levels of Security (MILS) architecture, a high assurance computer system design for security and safety-critical multi-enclave systems
Summary
High assurance computer systems are those that require convincing evidence that the system adequately addresses critical properties such as security, safety, and survivability[13]. Security engineering focuses on the tools and methods needed to design, implement, and test dependable systems and must be integrated in every stage of the software development process. POLICY LIFE-CYCLE policies, algorithms are designed, and the following are identified: modules, interfaces, High-level policies are statements that define objectives or entity relationships They are not specific to the deployed technology (e.g., which communication ports, protocols, and devices are used). The following are examples of high-level policies: “Allow only detectives to access the evidence room”, “A faculty member can view university records only for students threats, and risks During this stage, a policy design document is generated that specifies what the system does. Users can have queries about the system’s entities, enclaves, roles, and operations
Sign-in/Register to view highlights & summary Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callDisclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
