Maximum PC

The main security efforts have been placed at the network borders (firewalls, IDS/IPS, etc between the internal network and the internet) for quite sometime, but that is no longer sufficient, if it ever really was. Now, security is starting to secure the internal network, such as with host-based security solutions. My question is, what do you think is the smallest, securable, component of a computer system, while still maintaining some functionality? I think it would be useful to discuss this both based on current systems and based on theoretical systems. Also, this obviously, partially, depends on the purpose of the computer system, but how much?

For those who would like an analogy, think about the human body as the computer system. In the past we were just protecting the body at the skin, but that wasn't enough. Now we are starting to protect the body on the inside as well. In addition, we can lose a leg or an arm and still remain functional. However, if we lose our heart or brain, it is game over. So, what is the heart and brain of computer systems?

The brains would be the modem. You can't exactly have an internet without connection to the outside world.

Wouldn't a CPU seem like a better choice for a brain?

Easier comparisons...
brain -> cpu, primary memory, secondary memory (a combination of long-term memory plus reference material)
nervous system -> motherboard
mic -> hearing
cam -> visual
speakers -> mouth / localized human communication

Harder comparisons...
NIC -> mouth / external computer communication
BIOS -> ???
video card ->

From there I suppose you could define relationships like family, extended family, etc.

I would say the BIOS is the smallest defensible component in a computer system. If an attacker is able to compromise your BIOS, they can literally prevent your computer from completing a boot up sequence. In a more advanced attack, they might be able to store/transmit hardware information prior to booting the actual operating system. However, aside from an attack destroying your BIOS, it probably isn't as potentially debilitating (from a personal level) as an attack on the operating system. One of the professors at USC was doing research on operating system security that involved using hardware to ensure that critical components of the OS weren't modified. You might want to look into his research. I can't think of his name offhand, but he was the creator of Kerberos.

When I was originally forming my question, I was thinking more of in the software only realm. For some reason, I wasn't even thinking about hardware/firmware/BIOS, but you are absolutely correct that if the hardware/firmware/BIOS is owned, software has no chance.

The reason I started down this line of thinking is thinking about what is required to be able to fight through a computer attack and then be able to recover from the attack? I'm thinking that one way would be to have each layer, from hardware to the highest software layer, detect when a higher layer has been compromised, take that layer offline, and then restart that layer from a known good point. This way, the greatest functionality can be maintained, while maintaining the integrity of the system. A further refinement of this would be to take only the compromised portion of a layer offline rather than the whole layer, such as a process rather than all user-level software. Once this in put into place, the next step would be to secure each layer as well as you can.

I realize my ideas aren't fully thought out; I'm basically thinking out loud.


Are you thinking of Clifford Neuman? Are you thinking of the Trusted Computing Model?

Interesting idea. IIRC, there is a (very) high-security operating called Rings that is conceptually similar to what you have in mind.


Aside from marketing, I'm not sure if the "layers" concept actually provides any additional functionality, but I'm not sure either. It seems like you should start with a finer grained program/process model then resort to a courser 'layers' model if you must. Lets suppose that app z, depends on libraries x and y, x in turn depends on systems calls r and s, while y depends on s and t. App z also make a system call directly to q. Clearly, we construct a directed graph for all apps, libs and syscalls. However, I'm not completely sure that the graph will be acyclic due to callbacks. Anyways, it seems like you should be able to create a dependency graph to shut down the compromised portions of the system, but how do you determine if a process is compromised?

I know that the DOD was funding research into an operating system that would display information at the application level depending on the user's security clearances. For example, imagine that a B-1 bomber was on a mission. A secret clearance might show the aircraft's location, but not the speed or fuel consumption, if that information wasn't appropriate for someone w/ a secret clearance. That is another interesting idea, but I think it would require substantial changes to many aspects of our current software development.


Yes and yes. I attended a dinner for PhD and MS students to become more familiar with faculty research. Most of the faculty gave a ten to fifteen minute presentation on their research, sometimes an overview other times a single subject, but in depth, followed by questions and answers from those in attendance. He spoke about some of the advantages of the Trusted Computing Model, but I don't remember much in the way of details.

I'm having trouble googling for it, could you provide some more information on it, or a link? Who knew ring was such a common term?


Layers aren't really a new concept. By layers I was meaning hardware, firmware, ring 0, ring 1, etc.


I don't think it's important which system calls each process depends on, more so it's the resources (shared memory, files, possibly messages, etc.) each process accesses. These are different ways to look at the same thing (what does each program effect), but I think it's an important distinction, because I think it's easier to think in terms of the end effect of each system call. Based on this, you'd pretty much consider any program that has been written to by a compromised program also compromised.

One way to determine if a process, or any layer, is compromised, is behavioral analysis. It may be good enough to ensure the computer is in a safe state when it's turned on, like the Trusted Computing Model attempts to do, and then work to ensure it doesn't get to a bad state.


Is this different than SELinux?


You went to USC? Cool. How did you like it there?

The concept reminded me of Qubes OS, but it's more about isolating things into VMs that have different trust levels rather than detecting compromises: http://qubes-os.org/Home.html

LOL... I bet. I'll need to dig an old security book at out of my storage bookshelf in the garage. I'll get to it tomorrow or Monday.


I'm not following the distinction. Let's pretend that I've tampered with the syscall for writing a file so that it occasionally writes the contents to the wrong location thus corrupting the file. What is the difference?


What do you mean by "written to" in this context? In terms of shared memory?


Is this a statistical analysis method? Typically these methods require a large data set for establishing normative behavior which I think would be pretty difficult in this context. It's an interesting idea though -- it seems like statistical computing / machine learning is being applied to everything lately.


SELinux has been around quite a bit longer, and I believe that it is more of a hardened OS implementation. This was centered more around creating a system for developing applications with different access policies. I'm not sure if they were thinking along the line of a framework for developing the apps, perhaps a VM for enforcing the policies on a system, or who knows what else. Just another example of the DOD having too much money.


USC was great; I finished the MS degree in '09. The university and CS dept are very impressive. There is a lot of interesting research and researchers. The professors are excellent. Several of the undergrads that I met in a "Implementation of Algorithms" course have done extremely well: One went on to work at Google, another HP, and a third at MS. I was working at Boeing at the time and fortunate enough to have all of the tuition and books paid for under the LTP program. Unfortunately, the campus, which is pristine, is located in one of the worst areas of Los Angeles. Overall, I think it is a great program.

Let's take two programs operating in ring3 and syscalls operating in ring0. Let's assume ring0 has not been compromised (if it has been, we have bigger problems than ring3 programs operating correctly); however one program can use a system call to corrupt another program, such as by writing bad data to a shared resource, such as a file or memory. To illustrate the difference, let's look at two scenarios.

Scenario 1: Both programs only use syscalls to affect resources that are exclusive to them (Ex: write to their own memory space or their own files).

Scenario 2: One program uses the same syscalls to affect resources that they both share (Ex: write to shared memory or shared files).

In Scenario 1, each program can't affect each other, but in Scenario 2 they can, even though they use the same syscalls. In Scenario 2, if one program is compromised so that it writes bad data, it can lead to the other program being compromised, while in Scenario 1, it can't.


By "written to", I mean one program writing to a resource (file, memory, etc.) that another program accesses. So if programs A and B share memory, then program B is written to by program A when program A writes data to the shared memory, and the reverse also holds.


Hopefully each layer, and portions of each layer, will be small enough that it will be easier to determine what is normal. There's got to be some way to determine if a portion of the system is compromised, behavioral analysis is the only way I could think of to do this semi-reliably.

Gotcha. I meant when the syscall had been compromised. In a DAG, if X is corrupt and shares memory with Y, then you'd have an edge from X to Y.

Based on what? There doesn't have to be a way until you prove that it can be done (or can't be done in some cases). I currently have Chrome, Emacs, Notepad and a file folder open on my computer (plus the dozens of additional processes that the OS and application services). Each of these programs behaves very differently, so analysis between different types of applications doesn't seem like it will work. You could try looking for changes in behavior within an application, but this is going to lead to a number of false positives (eg I was reading all day in Chrome then decided to play an online game which spikes the CPU and network activity; I run some cpu intensive code in Emacs or write a script that spiders several websites). How would you baseline an application? Are you going to log the history of all the processes on a system? That's process is going to be turned off really quickly!

I was basically meaning that compromises of a layer, or portion of a layer, should be able to be detected; otherwise, the attacker can use that portion to their hearts content. For example, if they compromise your browser, they can do whatever they want with your browser without you knowing about it, if they do it properly. Therefore, it'd be advantageous for the lower levels to detect that your browser has been compromised.

The name of the "rings" operating system is STOP or XTS ... I'm not sure.
http://en.wikipedia.org/wiki/XTS-400

The book also mentioned the Bell–LaPadula security model.

Other operating systems mentioned were Trusted Xenix and Trusted Solaris.

In terms of mathematics (ie proving that you can), the difference between should and can is huge. However, let's assume that you can detect a security threat at a higher level, what do you plan on doing? This can get pretty complicated when you're dealing with large networks and distributed storage systems.

Also, how would a security detection application running at the same or lower ring than say the operating system? I guess what I'm getting at here is how would you implement the security system for an operating system that runs applications in one of two modes based on the hardware.

I'd say, either restart the compromised portion or take it offline entirely. You'd have to be careful and proactive in repairing the vulnerability that allowed the original compromise if you simply restart the compromised portion. Also, the system can be ensured to always be in a consistent state by using transactions and you wouldn't have to worry about dependencies, since everything that depended on the portion where the compromise was detected would be restarted too.


I think what you're asking is how this mechanism would work when it came to the lowest level? Such as the hardware or the OS kernel. The short answer is it won't. That is the genesis of this thread - what is that level? At that level, pretty much the only thing you can do is do everything you can to prevent any vulnerabilities in it, such as intensive code reviews, code analysis, etc.

A transaction as used in databases (in that sense)?


I think what you're asking is how this mechanism would work when it came to the lowest level? Such as the hardware or the OS kernel. The short answer is it won't. That is the genesis of this thread - what is that level? At that level, pretty much the only thing you can do is do everything you can to prevent any vulnerabilities in it, such as intensive code reviews, code analysis, etc.[/quote]
I was kind of suggesting that there may be a chicken and egg problem. I need to run... was there anything interesting in the links I posted?

Yes. As in all of the actions in the group happen successfully or none of them do.


As I imagine it, there'd be more than two levels, and each lower level would provide the functionality the next higher level needs and possibly verify that it is working properly. For example, in a system with four levels (x86 hardware has 4 rings), the highest level (ring 3) would be user space, next (ring 2) would be the various drivers, next (ring 1) would be the core OS functionality (process scheduling, memory management, etc), and the lowest level (ring 0) would be a verifier for the core OS (verify the data structures are consistent, etc). This is a rough example, but I think it may help to clarify my thinking. Each lower layer would be more restrictive as to who can modify them.

I haven't read the articles yet, but I intend to. They look interesting.