What's an IT Security person's "perfect" setup?

Recently, I've been thinking about what would be an ideal "setup" for my position as an IT security person. I deal with a lot of sensitive information, both regarding people that I work with and about the systems that I'm responsible for securing.

What I mean when I say setup, is the equipment that I use to do my job. For example, I have to print out patch level reports for the rest of the team so that they can "go forth and patch". Problem is that the traffic between my scanning machine and the printer is unencrypted. If someone were already into our system, they could potentially grab a nice concise list of our vulnerabilities off the wire as my print job passes by. NOT GOOD. Stuff like that.

So here's an off the top of my head start:

- Multiple OS Desktop(s)
There are numerous ways to accomplish this, starting with 1 physical machine for each needed OS, up to a Virtual Machine for each OS. Typically, the general consensus is that you'll need a MS Windows instance and some UNIX or UNIX-like OS (Linux, *BSD, or Mac OS X) instance, to get good coverage for the various tools of the trade.

- Backups
Since this desktop machine will contain sensitive material, the backups should be performed encrypted, and ideally, separate from the standard backup system.

- Decent network printer
This is a tricky one because most IT budgets don't have room for a nice (for n values of nice) printer dedicated to one person, they are typically a shared resource. Most folks won't need color, so you can save by going with a black and white printer, however, it needs to be reasonably quick (say, 30 ppm), duplex capable (try not to kill a tree a day), reasonable cost per page, and durable.

- Office space
A security persons work space should ideally be a single occupant office, with a restricted (ideally documented and access logged) set of people that have access to the office. You can really get picky and require that janitorial staff are escorted by authorized individuals.

- Shredder, burn bin, or documentation destruction
Some form of documentation destruction should be employed, dictated in some sense by the sensitivity of information printed.

- Management Network
Ideally, this would be physically separate from your production network, and not only involve dedicated network security devices (IDS sensors and servers, firewalls), but also network infrastructure devices (routers, switches, bridges). Budgets and designs restrictions may limit one's ability truly achieve this, but the closer you can get, the better.

Issues to consider:
- Internet access for the desktop
You generally wouldn't want to allow internet access out from the management network, but the security person will need Internet access to do research pertinent to his or her job.

I'll update this post as I think of more. Please post any ideas you might have in the comments, or email me at rfifarek at gmail.com.

Enjoy.

Sguil Yum Repository

As some of you (may) know, I've been working on creating a Sguil YUM repository, currently aimed at CentOS 4.X (which should work with RHEL 4.X). The end goal is to have a repository that you could point YUM at, and then execute:

yum install sguil-server

or

yum install sguil-sensor

where sguil-server and sguil-sensor are meta packages that pull down all the necessary binary packages needed to install a Sguil server or sensor. These package lists and versions are taken from InstantNSM.

It's not finished yet, but Real Soon Now (tm). I'll post updates as they come.

Solaris 10/11 Telnet Exploit

I'm not going to repeat what others have already said regarding the telnet+login vulnerability, other than:

If you are running telnet, and it's internet facing, then you have much more fundamental network security problems to workout.

Solaris 10 - First Try

I've been trying to install Solaris 10 yesterday and today, and have run into a nasty endless loop.

At work, we have a fairly large installation of Solaris 8. Our plans were to slowly replace our Solaris 8 SPARC machines with RedHat Linux Intel machines, with a target date of Oct. 2010. However, as time progresses these Solaris 8 machines are becoming more and more difficult to support software wise with regard to network integration. So, we're evaluating Solaris 10 as a stop gap upgrade.

Solaris 8 has given us problems in the past with package (and subsequent patch) dependencies, and our solution has been to "install everything", for better or worse. So, I did the same for Solaris 10, including the Solaris Validation packages. The initial install (from DVD) went smoothly, and rebooted off the hard drive just fine. It then brought up a secondary install step, where it asked for Solaris 10 software 5 CD/DVD. I popped the DVD in, hit Ok, and it promptly spit it out. Ok, given that it was the Validation software, which I likely didn't need, I told it to skip the software install. It continued forward, and asked me to Reboot the machine. I clicked on Reboot Now, and then ... nothing. Clicked again, nothing. Ok, I opened up a Terminal window, and typed reboot at the prompt, which worked. The machine rebooted, and launched the software installer again. Wash, rinse, repeat.

So, my next step was to download the ISO for CD 5 (wasn't that supposed to be part of the DVD????), and burn that. Well, this time it accepted the CD 5, and installed the software, so I figured I was in the clear. Reboot Now button still didn't work. Rebooted via the command line, and was promptly asked to install the software I had just installed. Lovely. Tried various tricks, but to no avail. So, this morning, I gave up, and started from scratch, however, this time I didn't select the Validation Packages. This will inevitably come back to bite me at the most inopportune time somewhere in the future when I've forgotten about Validation Packages and endless install+reboot loops (what is this, Windows?).

Long story short, removing the extra Validation packages from the install list solved this problem, and the machine booted properly.

It's interesting that they call the GNOME desktop environment, the Java Desktop.

Enjoy.

To Encrypt or Not to Encrypt

Most computer folks would agree, encryption is a good thing, and for the most part, so would I. However, the point where it becomes harder to justify is when there is an IDS in the mix. There are things that you can do to "get around" the problem, but no matter how you look at it, encryption makes IDS harder to do.

As I mentioned in a previous post, one of the things I use my IDS for is to monitor software that reports it's version number over the network in some fashion. All I do is look for a particular combination of destination port, and a string within that packet, and I can pick out what version of software a machine is reporting. Very effective in catching out of date software that was missed in the last round of upgrades.

Once you add encryption to this, it becomes significantly more difficult to do this type of monitoring, along with numerous others. What happens when a Trojan bot connects to IRC using SSL? I can no longer see the commands that were issued to the bot, but seeing encrypted IRC traffic still tells me that something. Same thing with HTTPS, however, HTTPS traffic isn't likely to be considered unusual.

Food for thought.

Enjoy.

Dual Boot FreeBSD 6.2 and Linux (CentOS 4.4)

I've been building some machines for testing various network foo, and found that this would a good opportunity to try FreeBSD again. I've been heavily into Linux lately, mainly due to job requirements, but I don't want my *BSD skills to horribly stagnate (shocking coming from a gov't employee, I know), and this seemed like a good time. Since I can't get completely away from Linux, I wanted this machine to be dual boot.

The first obstacle was installation. FreeBSD still uses, by default, an ncurses-based menu driven install, although I understand there is a GUI install system being developed. No problem, as I'm just as comfortable on the command line as I am with a graphical interface. Installing CentOS 4.4 has the option of a text menu install, but it defaults to a graphical install (my biggest annoyance with RH/Fedora/CentOS install (anaconda?) is that it picks the strangest hard disk layouts if you don't specify exactly what you want, and sometimes it even screws that up). The difference in install methods speaks to how Linux is trying to be everything to everybody, whereas FreeBSD is comfortable sticking to it's roots. Personally, I'm on the fence as to whether either camp has it "right." Both installs went smooth.

I installed FreeBSD first, giving it the first half of the hard drive (1 partition, with 5 slices within that partition), and CentOS the last half of the disk with 3 partitions. Given the maturity and open source nature of both of these operating systems, I was surprised that CentOS didn't recognize that FreeBSD was installed, and offer to add it to the GRUB boot menu like it would have done if it detected MS Windows something or other. Silly. Reminds me of Mom yelling at us as a kid, "Now children, stop fighting and play nice."

Anyway, the fix to that was (thankfully) fairly simple because GRUB is such a well designed boot loader. After installing CentOS, it left itself as the only option, so I boot into that, and edit /etc/grub.conf (symlink to /boot/grub/grub.conf), and add the following (YMMV, primarily with regard to partition numbers, etc.):

title FreeBSD 6.2
root (hd0,0,a)
kernel /boot/loader

and upon the next boot, FreeBSD 6.2 will be a boot option. Selecting it from the list allowed it to boot normally.

Enjoy.