The first part of this topic discussed many of the hardware and software aspects of the computer architecture. This part will focus mainly on the security issues associated with the architecture. Some of the first few questions a security professional should ask themselves before implementing security at the terminal level are 1) What should the security mechanisms focus on? (users, operations, data) 2) What layer should they be placed at? (hardware, kernel, OS, services, program) 3) How complex should they be? It’s not possible to check all the components of a system for trustworthiness. It would require too much time and cost. Trusted components have access to more privileged services so a trusted computing base (TCP) subnet should be developed, which included hardware, software, and firmware.
The TCP operates on several conceptual constructs. The first is a security perimeter, which is an imaginary boundary that divides the trusted from the un-trusted. It forces the two areas to communicate via interfaces, as opposed to direct connections. Another concept is the reference monitor, which is the idea of forcing subjects to have proper permission before they can access an object. The security kernel, made up of hardware, software, and firmware, act as the enforcing agent of the reference monitor concept. All of this is implemented through the implementation of Rings. Rings function by layering the OS to differentiate between privileges. The layout is for the inner rings to have more privileges than the outer ones. A general example would be the following: 0 – kernel, 1 – OS, 2 – I/O, 3 – applications/user activity. The idea is that the least privilege principal is followed; give the fewest privileges possible to each process.
Many security issues can arise from the system architecture. One area where problems arise often is the memory. Memory leaks can occurs from poorly written programs that don’t indicate when they are done with a resource. This leads to a memory shortage and is the idea behind denial of service attacks. This can be fixed with better code, garbage collector programs, and the use of preemptive versus cooperative multitasking. Another issue can arise out of the use of virtual memory, which is reserved hard drive space used to extend RAM capabilities. The problem is that when the system is shut down the pointers are reset, but the information still exists in those locations. Hackers can use this to obtain information they shouldn’t have. Routines should be developed to wipe the swap space before shutdown. Another issue is maintenance hooks. This is a type of backdoor used by developers to bypass regular access controls during development. As they are hard to detect as a general user, the only countermeasures are code reviews and quality assurance testing on the part of the developer.
The next three issues are actual attacks made by hackers on the system. Time-of-clock/time-of-use attacks take advantage of the dependency on the timing of events that take place in a multitasking OS. In other words, a hacker tampers with what happens between steps in the code, so if they can insert a command in between steps 2 and 3 in a code execution, they can influence the outcome. It is a flaw resulting from poor coding. The next attack is a race condition. This is where the order the steps are executed in is changed. An example of this would be if they hacker could change the sequence of the authentication and authorization steps, they could access the system without a password. The best way to prevent this is to make sensitive processes into a single step. The final attack we will discuss is the buffer overflow. Buffers hold the information that is put on the stack. If restrictions aren’t placed on what goes into each buffer, excess information can be placed in the stack, which will overflow its boundaries and rewrite the valid code below it. This problem is fixed with bounds checking. These are just a few of the many issues hackers often attempt to exploit in the computer architecture area.
No comments:
Post a Comment