« December 2007 | Main | May 2008 »

January 2008 Archives

January 4, 2008

Game targets

Our household received two gaming devices over the holidays that are capable of communicating with the outside world. We activated the communications of the Wii, and are merrily looking at Mii’s from across the planent.

This got me to thinking about alternate attack targets. Many folks are conditioned to think about protecting communication to and from their traditional computers (though most folks don’t do a very good job of this protection). Eventually everything will have an IP address and will be capable of communication and potentially being tricked into running undesirable code.

I did a quick nmap scan of the Wii’s currently assigned IP address and nothing showed up. That’s good. It should be initiating all communication. Then I did a ping, and it got a address not routeable message. Thought that was odd, so I looked at the network scan. Turns out the Wii wasn’t answering ARP requests. Seems like a very sensible solution if it is not expecting unrequested communication.

I’ll have to do some more sniffing downstream. Many ARP implementations seem to pick up ARP information from the cache based on the requestors information. But not all. So presumably the Wii stack also replies to ARP requests if they are seen during active communication. The EULA prohibts reverse engineering the network protocol, but I presume that observing network communication to understand its impact on my network environment is fair game.

So the good news is that the Nintendo folks seem to have thought at least a little bit about communication security. The bad news is that is this won’t likely be enough in the long run. Or maybe even now. There is lots of noise about Wii hacks on the web, but they seem to be the sort of hacks you do to yourself to improve your gaming experience and impress your friends. Once someone figures out the communication channel, you can “hack” others and then the real fun begins. Wii-bots anyone?

There are lots of flops to be had from the game hardware. The PS3 was the major platform contributing flops to Standford’s Folding@home effort.

January 10, 2008

So what is policy anyway?

I’ve been working with tools and products that nominally work with network security policy for over ten years now, and the term policy is still unclear and over-used in my mind. In his security text “Computer Security: Art and Science”, Matt Bishop describes security policy to be “a statement that partitions the states of a system into a set of secure states and a set of unsecure states”. In other words, the policy defines what is means for a system to be secure, but it doesn’t describe how the system should be made secure. The policy describes the goals or intent and the mechanism defines the how. Of course policies are used from very high level organization wide Engish documents of goals and intent down to very low level configuration details like SE Linux policies.

We first used the term policy to describe our multi-device management view of our Centri firewall. Our goal was to provide a management interface that was higher level than the per device configuration and hopefully closer to what the executives had in mind when they drafted their natural language organizational security policy. This morphed into Cisco Security Policy Manager after we were acquired by Cisco. The Centri firewall targets were dropped in favor of Cisco PIX and IOS enforcement points. This “global policy” view is also presented by the Solsoft management interface. In both management products, the “policy language” is graphical. While we did raise the abstraction level from individual devices, we didn’t nearly reach an abstraction layer that would be understandable by the executive writing the organization’s natural language policy.

Morris Sloman’s group at the Imperial College London has performed a lot of work on policy language specifications. One aspect of their work is formalizing a refinement hierarchy. The policy statements at the top of the refinement are very broad, and too ill defined to be formally analyzed, but perhaps intuitively understandable to the executive’s responsible for setting the organization’s policy. At each level of the refinement hierarchy, you formalize some aspect of the policy, potentially creating multiple versions from the previous level, e.g. refining the policy for one site vs another or refining the policy for one technology (firewall) vs another (operating system). At the lowest level of the refinement hierarchy, you have policy that could be used to directly control enforcing devices. At the higher levels of the hierarchy, you have more general policies that could be used to direct a global validation of a security implementation.

In his text, Bishop identifies three points in this refinement hierarchy. One is the English or natural language policy. The others are the high level and low level formal policies. He distinguishes between these two types of formal policies by determining whether a policy statement could be picked up and used to direct the operation of a different device or different vendor’s device. A high level policy could in theory be used to direct the operation of a different device. A low level policy statement is tied to a specific device and is really more configuration than policy. He gives the type enforcement language DTEL as an example of the high level policy. This language is the parent or the grandparent of the SE Linux type enforcement policy language. While DTEL is formal and fairly detailed it operates on general concepts of subjects (or processes) and objects (or files), so one could easily see how a specific DTEL policy could direct both firewall operation and operating system operation. He gives tripwire as an example of a low level policy. Tripwire uses a database of signatures of “good” versions of system binaries. Tripwire periodically checks the signatures against the binaries, and alerts the system administrator if there is a mismatch. One might want to build an organization wide database of good binaries and signatures and install that on all systems. However, due to how tripwire is implemented the database contains very low level information (timestamps and Inode #’s I believe) that prohibit such sharing.

This concept of policy as a system crossing configuration is consistent with how policy is used in the web services and identity management world. SAML statements are in essence policy that describe how individuals should be identified between administrative domains. Marianne Winslett’s group works on algorithms and frameworks to reason about formal policies that control trust. In these cases, the policies are like little contracts that are exchanged between entities that are trying to collaborate. Unlike the network security management case, the trust policies don’t control a single administrative domain. Rather the trust policies control how the base infrastructure evolves.

One concept that recurs in most uses of the term policy is that of conflict. In any non-trivial scenario there will be multiple, conflicting goals. An organization may want to provide a easy to use web interface to encourage new customers, but the organization must also ensure that their infrastructure has sufficient authentication and auditing to avoid fraudulent customers. These two goals are necessarily conflicting. At the implementation level, one group may require http communication with a particular server, but another group may need to prohibit all communication with that server to avoid potential conflict of interest contanimation.

The policy language could force the user to clarify all conflicts through ordered lists or policy priorities. Others try to implement more intelligent systems that deduce the correct conflict resolution. A lot of the autonomic management work involves creating greater intelligence and reasoning to save the user from the error prone work of detailed conflict resolution.

About January 2008

This page contains all entries posted to Trustworthy Thoughts in January 2008. They are listed from oldest to newest.

December 2007 is the previous archive.

May 2008 is the next archive.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.34