Type a search term to find related articles by LIMS subject matter experts gathered from the most trusted and dynamic collaboration tools in the laboratory informatics industry.
In computer sciences, the separation of protection and security is an application of the separation of mechanism and policy principle.[1] The protection mechanism is supposed to be a component that implements the security policy. However, many frameworks consider both as security controls of varying types. For example, protection mechanisms would be considered technical controls, while a policy would be considered an administrative control.
The adoption of this distinction in a computer architecture probably means that protection is provided as a fault tolerance mechanism by hardware/firmware and kernel, whereas the operating system and applications implement their security policies. In this design, security policies rely therefore on the protection mechanisms and on additional cryptography techniques.
Examples of models with protection and security separation include access matrix, UCLA Data Secure Unix, take-grant and filter. Such separation is not found in models like high-water mark, Bell–LaPadula (original and revisited), information flow, strong dependency and constraints.[2]
The line between 'separation of mechanism and policy' and 'separation of protection and security' isn't necessarily clear. The terms 'protection' and 'security' aren't widely considered distinct. For example, 'computer security' is commonly defined as 'the protection of computer systems'. Indeed, the major hardware approach[3] of hierarchical protection domains considers its use to be both for security and protection. A prominent example of this approach is the ring architecture with "supervisor mode" and "user mode".[4] Such an approach adopts a policy already at the lower levels (hardware/firmware/kernel), restricting the rest of the system to rely on it. Therefore, the choice to distinguish between protection and security in the overall architecture design implies rejection of the hierarchical approach in favour of another one, the capability-based addressing.[1][5]
LIMS forum content by LIMS forum members is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. Based on a work at www.limsforum.com.
