Some random thoughts

Still waiting for RedHat 6.0 to be released: The new program secstate looks very interesting. It is being published from Tresys which has a CLIP project in place. This is a version of RedHat which has been locked down based on the CIS benchmark or in this case the new FDCC / USGBC standard. The important thing is the use of puppet in both cases to manage the secure configuration.

I also like how they (Tresys) have mapped some of the CLIP security controls back to FISMA controls; So, with some sort of reporting on the status of the system, it is possible to automate reporting of how the system is doing in terms of FISMA.

EMET from Microsoft

Busy day for Posting: Another thing I have come across is the EMET tool from Microsoft. It basically wraps security around other programs and runs on Windows XP SP3 and later. It does solve the security problems in these programs, but provides protection until a patch can be applied. For example, (not picking on Adobe), but if a malicous pdf is run inside Adobe Reader, EMET will step in and crash Reader to prevent the bad codes from running, thus protecting the system from infection.

So far I have tested it with firefox, Internet Explorer, java and Adobe reader. Also I have wrapped the svchost program which connects the system to the Internet. In addition, I have wrapped lssas which is the local security authentication server. I know the best method is to always know the source of the files you download and scan them with an Antivirus tool; but any extra protection is always welcome.

Ultimate Goal for a Secure system

I have been looking into ways to make my systems the most secure as possible, but making sure my users are able to do their work. One the things I have been following is the use of micro-kernels; this reduces your "Attack Surface" since there is less of the kernel to attack. Also there is a micro-kernel (SEL4) which has been verified by means of Formal Methods to be a very secure kernel. However it is not available for use as a Linux kernel replacement. Its cousin L4 can be used as a Linux kernel replacement very certain functions which I may be looking into.

Another method of securing the system is to look into Trusted Computing. They are generated a trusted system by starting at the boot level. There is code available to verify if the BIOS boot-loader can be trusted. Then the next step is to see if the GRUB or LILO loader can be trusted and finally testing to see if the OS that is loaded can be trusted. Unfortunately there has been problems; Trusted Computing has been advertised as a means to make sure that copyrighted material is not copied and are being controlled by the copyright owner. There has been many cases like Sony and others where the copyright control has gone to far. Another problem is that the chain of trust starts at the BIOS level and it has been shown that a rogue BIOS can be planted on one of the peripheral devices and use to bypass the chain of trust of the main BIOS on the motherboard. These issues might explain why there has not been much work on Trusted Computing since 2008.

Attack Surface

I learned a new term for protecting systems. The Attack surface; so deleting unused services, packages and accounts you reduce the "Attack Surface" of the system and make it more secure. There are tools in development which will be able to test a system a generate a score for the "Attack Surface" of the system. This will not make the systems more secure but provide a means to see which systems need more attention and unfortunately or fortunately provide a metric for management about the current security state of the systems.

Delete unused Service Accounts

Not sure how much of a problem these unused accounts are especially with SElinux watching the show, but to be safe remove them anyway.

/sbin/userdel adm
/sbin/groupdel adm
/sbin/userdel lp
/sbin/groupdel lp
/sbin/userdel shutdown
/sbin/groupdel shutdown
/sbin/userdel halt
/sbin/groupdel halt
/sbin/userdel news
/sbin/groupdel news
/sbin/userdel uucp
/sbin/groupdel uucp
/sbin/userdel operator
/sbin/groupdel operator
/sbin/userdel games
/sbin/groupdel games
/sbin/userdel gopher
/sbin/groupdel gopher
/sbin/userdel ftp
/sbin/groupdel ftp
/sbin/userdel mail
/sbin/groupdel mail
/sbin/userdel xfs
/sbin/groupdel xfs
/sbin/userdel mailnull
/sbin/groupdel mailnull

Vulnerability in OpenSSH CBC Ciphers

I just stumbled upon  this advisory about CBC mode ciphers have a vulnerability.
http://www.openssh.org/txt/cbc.adv

I have looked into this and discovered that some old versions of Putty and WinSCP will need to be updated, but this looks like a good idea to reduce the list of ciphers until a fix is found.