Security Criteria for Operating Systems

1972 words (8 pages) Essay

18th May 2020 Information Technology Reference this

Disclaimer: This work has been submitted by a university student. This is not an example of the work produced by our Essay Writing Service. You can view samples of our professional work here.

Any opinions, findings, conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of UKEssays.com.

The Common Criteria is an internationally recognized standard for computer security approval. To become certified by Common Criteria a security target is laid out to meet certain functional and assurance metrics. Vendors rate their operating systems by making claims about the security attributes of their operating system. These claims are verified and evaluated in laboratories to determine if the product truly meets the security specifications laid out. If the claims are met then the operating system receives an EAL rating. It is important to note that a higher EAL does not necessarily equate to better security. It simply means that the security claims laid out have been verified more extensively with increasing level.

Get Help With Your Essay

If you need assistance with writing your essay, our professional essay writing service is here to help!

Find out more

The Evaluation Assurance Level (EAL) is a quantifier given to an operating system after it has gone through the Common Criteria security certification process. The EAL scale contains seven assurance levels. As the levels increase from one to seven,the rigorousness of the testing of the security target increases. The first level of certification is known as EAL1 and it is to functionally test a given system. This level of certification is adequate for systems that need some assurance of correct operation, but security threats are not viewed as serious. The second level, known as EAL2, is designed for structurally testing a system.  The EAL2 requires cooperation of the developer of the operating system. This is needed as the developer must provide information about design and results of testing. The EAL2 level expects that proper modern development practices were used in the development of the operating system. Due to the less rigorous requirements at this level it is expected that this level of certification be cost and time effective. This level certifies a low to medium amount of assured security. The next grade named EAL3 is given to systems after they have been methodically tested and checked. This certification is applicable to systems where users require a moderate level of assured security in the system. EAL4 is the next level on the scale and it is assigned to systems that have been methodically designed, tested, and reviewed. This level allows for a lot of assurance due to security-based engineering and the implementation of proven practices into the system. Additionally, any operating system that is designed to provide multilevel security is tested to a minimum of the EAL4 level. The EAL5 grade applies to systems that have been semi formally designed and tested. This level allows assurance to be gained from security-based engineering based on sound practices and the slight use of some specialist security engineering procedures. The second to last level, know as EAL6, is awarded to systems that have somewhat verified design and have been tested. This grade requires the system employ the application of security engineering techniques and a meticulous development environment. This level provides assurance for systems that need to protect important assets from security threats. The final level of the EAL system must meet the most rigorous set of requirements. This theoretically should give users the most assurance about a system. The EAL7 seven level requires a system to be verified and tested formally. This certification is the costliest to complete and it applies to systems that are at a high risk of security threats and important assets need to be protected. 

 The common criteria process requires that the user lay out the security claims for the operating system. These claims are then tested by a certified lab to prove that the claims are valid. So all the security aspects listed in the Target of Evaluation document  for the operating system and the execution environment are covered in the common criteria certification process. 

Discussion of the CVE-2019-7221 Linux Vulnerability and its Impacts

The vulnerability found within the Linux kernel was a Use-after-Free flaw. This flaw was discovered within the Kernel Virtual Machine (KVM) implementation of the kernel. Overall, this vulnerability has a large impact on the security and reliability of the system. There is potential for exposure of confidential information, alteration of system files, and performance change in available resources. Not only does this vulnerability have reprehensible impacts it is also relatively easy to exploit which makes it a serious issue.  The vulnerability affects many versions and products of linux which adds to the impact of the issue.

 The kernel based virtual machine is a part of the linux kernel that allows the kernel to gain the functions of a hypervisor. This allows a virtual machine to be run on top of the Linux kernel as a guest. A KVM provides device abstraction by setting up a virtual address space, feeding simulated I/O to the guest, and mapping the display of the guest to the host system.

A user after free attack is a dangerous vulnerability within a system. This vulnerability can lead to unsecure actions such as corruption of valid data or execution of random code. The unsecure actions that can be performed depend on the timing and implementation of the vulnerability. Use after free errors can be hard to identify due to the complexity of dynamic memory. Additionally, a very specific condition may have to be met for the error to occur which makes it hard to check for with autonomous testing.

 

Preventability of KVM Unbuntu 16.04 Vulnerability

 

         The security of an operating system is hard to talk about concretely as many external factors such as the purpose of the system. The EAL2 level of certification is designed to structurally test the system. However, this level is not as rigorous as levels such as EAL6 or EAL7 which formally test and verify the design of an operating system. Therefore, if your operating system is in a low risk environment where a low amount of security is needed then the EAL2 certification can give you good confidence in your system. However, if your system is designed for to be used in high risk settings the system should be certified to a greater EAL level. In a high-risk environment, you want to make sure the system has been very rigorously tested and designed using proper practices. So, since EAL2 only structurally tests the system it would not give a user great confidence in the system because the system has not been tested methodically. Additionally, this level of EAL doesn’t ensure that the best and most modern practices have been implemented. Overall, the security confidence that the EAL2 certification gives you is contextual to your system and how your system is intended to be used.

Applying updates to operating systems is a very important to keep systems secure. Just because a system is certified to degree doesn’t mean that the system is infallible. Undoubtedly, there will be some vulnerability or practice that is not sound in its design.  These flaws may not be found during the certification process and they will ultimately cause problems if they are not patched with an update. The EAL certification does not make your system infallible for all time it simply gives you a metric so that users can purchase use the system knowing that it will function most of the time. At some point it is certain that a flaw will be discovered and applying the updates will keep the system up to date with modern security practices and secure for the users.

 

Analysis of Flaw distributions in Operating systems

 

  According to the paper, An Empirical Study of Operating System Errors, most of the errors in an operating system are concentrated in code for the drivers. This result is expected due to the fact that the driver segment of the operating system contains the most code. Due to the distribution of the size of the OS it is logical that more errors would occur in that segment. However, the paper goes a step further and analyzes  the error rate relative to the rest of the kernel. Here we see the large discrepancy, because even when size is taken into account for the calculation of the error rate is still considerably higher in the driver segment of the system. The paper suggests several underlying causes to the unbalanced error distribution. The driver segment of the operating system is developed by many programmers and they programmers often have a better understanding of the device than the operating system it is being integrated into. This lack of experience can lead to improper use of interfaces built into the operating system and cause errors. Another potential cause for the skewed distribution is that drivers are not tested as thoroughly as the rest of the operating system.

 

 The clustering of bugs in an operating system has several potential causes of varying degrees. The paper presents one potential cause as simply the incompetence of of poor programmers producing multiple errors in a small segment of code. However, it is also presented that a more relevant cause is likely the ignorance of programmers about the system they are programming. This assertion is logical as the improper use of interfaces provided by the operating system would likely cause errors to arise. Additionally, one can ascertain how this would cause clustering, as a module worked on by an individual that was ignorant about the system is likely to have significantly more bugs than one written by a knowledgeable programmer.  One final cause is presented by the paper that goes hand in hand with ignorance of the system. Using cut and pasted code which is good in some scenarios may not maintain its validity in another situation due to operating system structure. If a programmer assumes that the code they are copying and pasting is valid and they paste it many times it can cause many errors if the code was actually invalid.

Citation Links

[1]https://en.wikipedia.org/wiki/Evaluation_Assurance_Level

[2]https://cwe.mitre.org/data/definitions/416.html

[3]https://blogs.cisco.com/security/talos/exploiting-use-after-free

[4]https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine

[5]https://en.wikipedia.org/wiki/Hypervisor

[6]https://en.wikipedia.org/wiki/Common_Criteria

[7]https://ubuntu.com/blog/ubuntu-eal2-certified

[8] https://www.cvedetails.com/cve/CVE-2019-7221/

[9]https://dl.acm.org/citation.cfm?id=502042.

The Common Criteria is an internationally recognized standard for computer security approval. To become certified by Common Criteria a security target is laid out to meet certain functional and assurance metrics. Vendors rate their operating systems by making claims about the security attributes of their operating system. These claims are verified and evaluated in laboratories to determine if the product truly meets the security specifications laid out. If the claims are met then the operating system receives an EAL rating. It is important to note that a higher EAL does not necessarily equate to better security. It simply means that the security claims laid out have been verified more extensively with increasing level.

The Evaluation Assurance Level (EAL) is a quantifier given to an operating system after it has gone through the Common Criteria security certification process. The EAL scale contains seven assurance levels. As the levels increase from one to seven,the rigorousness of the testing of the security target increases. The first level of certification is known as EAL1 and it is to functionally test a given system. This level of certification is adequate for systems that need some assurance of correct operation, but security threats are not viewed as serious. The second level, known as EAL2, is designed for structurally testing a system.  The EAL2 requires cooperation of the developer of the operating system. This is needed as the developer must provide information about design and results of testing. The EAL2 level expects that proper modern development practices were used in the development of the operating system. Due to the less rigorous requirements at this level it is expected that this level of certification be cost and time effective. This level certifies a low to medium amount of assured security. The next grade named EAL3 is given to systems after they have been methodically tested and checked. This certification is applicable to systems where users require a moderate level of assured security in the system. EAL4 is the next level on the scale and it is assigned to systems that have been methodically designed, tested, and reviewed. This level allows for a lot of assurance due to security-based engineering and the implementation of proven practices into the system. Additionally, any operating system that is designed to provide multilevel security is tested to a minimum of the EAL4 level. The EAL5 grade applies to systems that have been semi formally designed and tested. This level allows assurance to be gained from security-based engineering based on sound practices and the slight use of some specialist security engineering procedures. The second to last level, know as EAL6, is awarded to systems that have somewhat verified design and have been tested. This grade requires the system employ the application of security engineering techniques and a meticulous development environment. This level provides assurance for systems that need to protect important assets from security threats. The final level of the EAL system must meet the most rigorous set of requirements. This theoretically should give users the most assurance about a system. The EAL7 seven level requires a system to be verified and tested formally. This certification is the costliest to complete and it applies to systems that are at a high risk of security threats and important assets need to be protected. 

 The common criteria process requires that the user lay out the security claims for the operating system. These claims are then tested by a certified lab to prove that the claims are valid. So all the security aspects listed in the Target of Evaluation document  for the operating system and the execution environment are covered in the common criteria certification process. 

Discussion of the CVE-2019-7221 Linux Vulnerability and its Impacts

The vulnerability found within the Linux kernel was a Use-after-Free flaw. This flaw was discovered within the Kernel Virtual Machine (KVM) implementation of the kernel. Overall, this vulnerability has a large impact on the security and reliability of the system. There is potential for exposure of confidential information, alteration of system files, and performance change in available resources. Not only does this vulnerability have reprehensible impacts it is also relatively easy to exploit which makes it a serious issue.  The vulnerability affects many versions and products of linux which adds to the impact of the issue.

 The kernel based virtual machine is a part of the linux kernel that allows the kernel to gain the functions of a hypervisor. This allows a virtual machine to be run on top of the Linux kernel as a guest. A KVM provides device abstraction by setting up a virtual address space, feeding simulated I/O to the guest, and mapping the display of the guest to the host system.

A user after free attack is a dangerous vulnerability within a system. This vulnerability can lead to unsecure actions such as corruption of valid data or execution of random code. The unsecure actions that can be performed depend on the timing and implementation of the vulnerability. Use after free errors can be hard to identify due to the complexity of dynamic memory. Additionally, a very specific condition may have to be met for the error to occur which makes it hard to check for with autonomous testing.

 

Preventability of KVM Unbuntu 16.04 Vulnerability

 

         The security of an operating system is hard to talk about concretely as many external factors such as the purpose of the system. The EAL2 level of certification is designed to structurally test the system. However, this level is not as rigorous as levels such as EAL6 or EAL7 which formally test and verify the design of an operating system. Therefore, if your operating system is in a low risk environment where a low amount of security is needed then the EAL2 certification can give you good confidence in your system. However, if your system is designed for to be used in high risk settings the system should be certified to a greater EAL level. In a high-risk environment, you want to make sure the system has been very rigorously tested and designed using proper practices. So, since EAL2 only structurally tests the system it would not give a user great confidence in the system because the system has not been tested methodically. Additionally, this level of EAL doesn’t ensure that the best and most modern practices have been implemented. Overall, the security confidence that the EAL2 certification gives you is contextual to your system and how your system is intended to be used.

Applying updates to operating systems is a very important to keep systems secure. Just because a system is certified to degree doesn’t mean that the system is infallible. Undoubtedly, there will be some vulnerability or practice that is not sound in its design.  These flaws may not be found during the certification process and they will ultimately cause problems if they are not patched with an update. The EAL certification does not make your system infallible for all time it simply gives you a metric so that users can purchase use the system knowing that it will function most of the time. At some point it is certain that a flaw will be discovered and applying the updates will keep the system up to date with modern security practices and secure for the users.

 

Analysis of Flaw distributions in Operating systems

 

  According to the paper, An Empirical Study of Operating System Errors, most of the errors in an operating system are concentrated in code for the drivers. This result is expected due to the fact that the driver segment of the operating system contains the most code. Due to the distribution of the size of the OS it is logical that more errors would occur in that segment. However, the paper goes a step further and analyzes  the error rate relative to the rest of the kernel. Here we see the large discrepancy, because even when size is taken into account for the calculation of the error rate is still considerably higher in the driver segment of the system. The paper suggests several underlying causes to the unbalanced error distribution. The driver segment of the operating system is developed by many programmers and they programmers often have a better understanding of the device than the operating system it is being integrated into. This lack of experience can lead to improper use of interfaces built into the operating system and cause errors. Another potential cause for the skewed distribution is that drivers are not tested as thoroughly as the rest of the operating system.

 

 The clustering of bugs in an operating system has several potential causes of varying degrees. The paper presents one potential cause as simply the incompetence of of poor programmers producing multiple errors in a small segment of code. However, it is also presented that a more relevant cause is likely the ignorance of programmers about the system they are programming. This assertion is logical as the improper use of interfaces provided by the operating system would likely cause errors to arise. Additionally, one can ascertain how this would cause clustering, as a module worked on by an individual that was ignorant about the system is likely to have significantly more bugs than one written by a knowledgeable programmer.  One final cause is presented by the paper that goes hand in hand with ignorance of the system. Using cut and pasted code which is good in some scenarios may not maintain its validity in another situation due to operating system structure. If a programmer assumes that the code they are copying and pasting is valid and they paste it many times it can cause many errors if the code was actually invalid.

Citation Links

[1]https://en.wikipedia.org/wiki/Evaluation_Assurance_Level

[2]https://cwe.mitre.org/data/definitions/416.html

[3]https://blogs.cisco.com/security/talos/exploiting-use-after-free

[4]https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine

[5]https://en.wikipedia.org/wiki/Hypervisor

[6]https://en.wikipedia.org/wiki/Common_Criteria

[7]https://ubuntu.com/blog/ubuntu-eal2-certified

[8] https://www.cvedetails.com/cve/CVE-2019-7221/

[9]https://dl.acm.org/citation.cfm?id=502042.

Cite This Work

To export a reference to this article please select a referencing stye below:

Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.

Related Services

View all

DMCA / Removal Request

If you are the original writer of this essay and no longer wish to have your work published on the UKDiss.com website then please: