Had a meeting with my hopefully to-be supervisor Barry.
I explained that I hadn't done much Msc work this week for technical and SRC reasons. He has given me until Friday to come up with a more solid project proposal.

We discussed three possible directions:

• Software Update Services - This would be for the purposes of hardening the internal network. Barry suggested client software that could enumerate all software on a machine and its version numbers. This would report to a server so that an admin could ensure all his machines are up-to-date. Windows has this for the OS (M$ SUS) but not for other programs. *Nix's don't (I haven't looked much yet) but it would be quite easy to do on FreeBSD and Gentoo with their ports systems. A modular approach could be good: plugins for an OS and plugins for certain software (doze in particular).
• SPAM - Especially with the trojans flying around the net at the moment, a method for preventing these zombies from being a problem. ASMTP is one way of doing this, but would require a CA or a web of trust. This doesn't tickle my fancy and looks like another way to make the Internet non-free. Update - Russell seems to have found this article interesting and I really enjoyed his tactic described here. I hope to soon implement a similar idea.
  
• Honey {Pot|Net}s - Neither Barry or I are sure about the staying power of this currently topical debate.
  

Some summaries of my readings and what I still need to read:

Automated Windows Patch Management Part 1 and 2
http://www.securityfocus.com/infocus/1760
Part1
The basics of M$'s SUS is explained. A local SUS server is required. This synchronises with M$ and then the local clients sychronise with it according to which updates have been approved by the local administrator. The three policies are 1) notify the user of download and install, 2) download automatically and notify user of install and 3) download and install automatically. The author also notes that applying this as a Group Policy in a large organisation might result in a DoS on the SUS server and so it should be applied at the OU (lookup?) level with staggered synch times. The author finds SUS has these problems:

• No native support for easy, useful log analysis
• No broader multiple platform coverage
• No patching for applications and server programs in addition to the operating system itself
  

Part2 - must read
http://www.securityfocus.com/infocus/1762

Software Update Services Deployment White Paper - must read
http://www.microsoft.com/windowsserversystem/sus/susdeployment.mspx

Wireless Honeypot Trickery - must read
http://www.securityfocus.com/infocus/1761

Trojans and SPAM
http://www.theregister.co.uk/content/55/35722.html

"Proof" that spammers are selling trojaned machines as relays. Research into how to deal with this apart from just blocking dial-up IP blocks should be good.

Robert X latest column - bit of a side note
http://www.pbs.org/cringely/pulpit/pulpit20040219.html

Very interesting read. Discusses how JIT, interpreted code can be easily decompiled and so needs obfuscation which conflicts with optimisation. Thus M$ has a gaping security hole as enterprise source code is not safe from copying or external audit. A company called DashO provides an obfuscator for Java and .NET but relies on renaming all variable names to "a". Another company named PreEmptive has developed Program State Code Protection which alters the program dynamically. The Author recons M$ is dependant on this security measure and Preemptive is a hot company.