The first step in preparing any kind of security plan would be line up your assets. These can either be physical machines or simply data stored on them. In our fictitious department, we don't have any formal inventory system detailing what we have exactly, so this takes a bit of time. We stroll around into every room and simply jot down informally to get an idea of what we're up against. It took us a day or two to do. It isn't incredibly complete, but does show us where the low-hanging-fruit may be.

• 35 PCs running a variety of Windows: Most of these are running WindowsXP, although a few are running Vista. A few lab machines were spied running Windows 95

• 5 PCs running Linux: These were mostly found on professor's desktops. At least two different kinds of linux were identified; it's really hard to tell.

• 4 MacBooks: Hard to miss! The folks with these machines were actually eager to show them to us.

• 6 Windows laptops: While one or two looked like they had not been moved in at least a year, the others look like they travel around.

• 4 Windows file servers: Two of these help support the department itself and are in the main office. The other two belong to PIs doing their own research. They all run XP.

• Physical exams: Large piles of exam material are often seen in the front office near the copier.

• Professor's private documentation in offices: I'm sure there is a lot of documentation in those offices which could be regarded as sensitive.

• Linux mail server, Linux DNS server, Linux web server: The sysadmin for the department runs these (potentially the same individual performing this survey).

• 4 Wireless access points: Couldn't exactly find them, but a quick kismet install on a laptop discovered these somewhere nearby.

• Student information stored as rosters: Although the university stopped using SSNs on class rosters, many professors still have rosters laying around in both paper and electronic form for old classes before the change. They also have a lot of the new rosters, which aren't as sensitive.

• Email, web pages: Given the servers we run, it can be safely assumed that these assets exist. They might even be used.

• Wireless information in the air: This deserves to be pointed out. While the switches supporting our department are owned and managed by TD, the wireless routers folks have set up circumvent that control and is something we'll have to account for.

• Research material: Hard to underestimate this one. The department has 3 grants which are particularly large and help fund a large amount of the operations. A loss of data to one of these could be devastating.

• Financial and operational information: The systems in the main office have a lot of information pertaining to the financial operation of the department. A lot of unidentified data is housed there.

Given what our assets are, we now have to identify what we absolutely have to do with regards to the law and university security standards. These pages help review what we're dealing with:

Respecting any of these documents means we have to identify our sensitive data. In our case, this means identifying machines and/or files with SSN data. Additionally, for the purposes of their importance to the department, research what data is integral to important funding sources should also be considered to be sensitive. In the case of SSNs, there are a variety of programs which can be used to identify if any files on a machine are in fact using SSNs. SENF is put out by the University of Texas, and find_SSNs is produced by the University of Virginia. Both are cross-platform (python and java), and both seem to be fairly effective and quite usable. As we discover, a few professor's machines do indeed have SSNs. Rather than be faced with tighter controls on their computers, they volunteer to remove the identified data from their machines. A few do this by merely deleting the columns with the SSNs, while others volunteer to just ask for the data from the register on an as-needed basis and delete what they have on hand. This inherently shifts the responsibility of the data over to the registrar.

Beyond SSNs, we do not have to consider any of our current data to be restricted -- just sensitive. This means we still have to implement patching and anti-virus on all of our machines in order to be compliant. Thankfully, the university provides software and a service to make this simple to manage. You can download Trend-Micro's virus scanning software from software.rutgers.edu.

Looking at patching, we have a few issues. Right off, those few lab machines running Win95 are going to have to be updated to be WindowsXP. Thankfully, XP is free via software.rutgers.edu. Whether or not the machines can handle the update is another issue entirely. It should also bear mentioning that they can likely remain as Win95, but only if they are completely restricted from participating on any network. This leaves us with about 41 other windows machines which have supported operating systems and which need patching regularly. It would take about 10 hours for someone to walk around and patch all those machines in the most ideal of situations. Alternatively, software like Patchlink costs approximately $15 a seat per year and would cost approximately 25 man-hours per year to operate. The math says Patchlink is more efficient for us and we decide to spring for it. Our linux machines also need patching. The kinds of actions which are required in order to do this for all of our versions of linux make it much more expensive in terms of time to patch regularly. In addition to this, a linux machine may require patching on an irregular schedule. After a bit of research, we discover that Patchlink will also patch Linux machines! We plan to implement this for the main service machines and the other linux machines.

Now that we have a plan for being compliant with those regulations which affect us, we can actually look at those things which are important to us as an organization and decide if they are worth protecting. In the event of a total catastrophe, it would be nice to know that our data is recoverable. Disaster recovery should be given a good deal of thought. We should try and evaluate the odds of a catastrophe against the actual cost to the department. This laid against how much it should actually cost to offer disaster recovery for a resource should answer the "should we back this up" question rather easily. The technologies and methods employed in disaster recovery schemes are surely beyond this document, but are still fairly relevant to security. It could be as simple as just backing up one shared system, or as complex as a distributed system of tapes and NAS architectures to ensure various windows of rolling incremental and full backups.

The general protections we're implementing thus far are almost satisfactory for almost all of our information resources. Implementing a few host-based firewalls and making sure we have robust login procedures should round it all out. A lot of the department depends on the success and stability of those 3 grant projects. It is very difficult to put a quantifiable value on the information and infrastructure there, so it can be difficult to ascertain how much should be spent protecting them. We decide that it would be a good idea to invest $20,000 worth of resources a year into protecting just those grant projects. For the first year, we'd likely only cover the one group which in fact does get attacked a lot due to the controversial research they do. Based upon the abilities we're bringing to the table, we may decide on firewalls, an IDS, or even more robust backups.

The wireless access points should be addressed in some way. After a simple google search for "wireless AP best practices", the first link is a fairly informative guide from Microsoft. We decide to track down the individuals running the access points, and ask them to secure the points via MAC addresses and encryption.

Physically, we have no idea what is going on. Keys to offices are floating around everywhere, and we're not even sure who at the university has access to master keys which could open any of our doors. This is a large problem due to the terrific expense involved. It's also one which we might not have to pay the upfront cost for completely. We quickly find the main key shop page and a list of individuals responsible for various locations and buildings. This turns into a project all its own; but the upper management in the department decides that if needed, in the near term they will help fund securing a few important rooms which contain many resources. We also set up routine procedures to make sure copies of exams are closely monitored and always stored in a secure room at all times.

Monitoring, as was indicated earlier, is essential to this entire process. At the moment, we have no centralized monitoring whatsoever. The easiest and most clear cut way to set this up is to have one of our unix machines set up as a syslog server and have all our other machines send data to it. We don't need client data at this point, just our servers. We also point our new patching software at it, so we have an idea of how well that new purchase is progressing. A few perl scripts later to parse all of this, and a simple cronjob to mail out what the scripts find daily, and we have a passable monitoring solution. It's not quite enough, however. In order to make sure that we don't get blindsided by a few machines we missed, we decide it would be a good idea to scan our networks once a month for new machines and new vulnerabilities that crop up. Both the SCANME service or our own independent service are options at this point. We're not sure which. In either solution, we'll have to make sure the scanner can access the networks without any restrictions. This more than anything else will likely determine whether we go with the university service or our own nessus process. In the end, running our own nessus server seems to be superior.

Ok! We're doing pretty good. We've grabbed almost all the log hanging fruit without having to set up or make complicated design decisions about our current infrastructure. Of course, this is made easier by only being a fictitious case study, but hey, it would be nearly impossible to anticipate all of the various problems on campus in one document (or even a book). At this point we'll review the checklist on this site to see if we can find anything to remind us of things we've missed. Lo' and behold, we do. They mostly comprise of things like informing folks about what makes a good password, implementing more host-based-firewalls, and getting more individuals in on the loop.

We do have one issue left. There is a proposal for selling T-shirts, baseball caps, and other related items with departmental logos and pictures of professors on them. Ideally, we could set up our own ecommerce site on one of our servers and go from there. As it turns out, processing credit cards means that we as a group will have to adhere to PCI compliance standards. While it would certainly ensure that our own processes and systems are secure, this would push the cost of such a project way over the roof. This is easy to demonstrate given the university web-page describing PCI compliance. Instead, we suggest using a service such as Cafepress. There are lots of examples of universities successfully doing just this! And because the remote vendor is used, liability for the entire process and even site development is pushed off.

After all this, here is our short plan:

• Survey all machines for SSN data using SENF

• Remove SSN data from machines found with them

• Install Trend-Micro virus scanning on all applicable operating systems

• Retire all machines running unsupported operating systems

• Research "Patchlink" service and implement for the department on all applicable operating systems

• Review, develop, and test disaster recovery plans (research how appropriate current implementations are)

• Purchase and deploy IDS/firewall for high-profile grant lab.

• Contact key shop personnel and evaluate current status of door locks.

• Potentially replace locks on highly sensitive doors due to unknown status of campus and building masters.

• Create syslog server and scripts to monitor and mail out daily reports from syslog

• Create local nessus scanner, provide it access to machines, and perform scans quarterly of all network space.

• Recommend e-commerce liability to an external site.

Of course, the process will not be this straightforward and simple. While most of this exercise was qualitative, often a quantitative approach will have to be taken in order to make the right decision. It may involve getting many individuals involved, and perhaps even require obtaining help from outside the department. IPS would be more than willing to help you make these decisions or even point you at other resources at campus to help you create your own security plan!