A Summer Internship with the Critical
Infrastructure Protection Plan
By Jonathan Bird
Introduction
During
the spring and summer of 2003 and continuing into this year and the next I am
employed as a student programmer on the CIPP project, which was being conducted
out of the ISAT facility of
.
Me - my name is Jon Bird and I'm really glad I could be a part of this. Not only did I learn a lot of valuable software development and coding techniques, but I had a good time in the process. Thank you to everyone who let me be a part of the team
Jae - Jae is a rising senior at JMU and a lot of fun to be around. She's probably got the most experience at software design and development among the four students because she's taken a few more classes in those areas here at JMU.
Lavie - Lavie is also a rising senior at JMU. He is a solid coder and is always very willing to help you out when you hit a bump in your code. Lavie is also a great debugger.
Demitrius - We call Demitrius our "unit tester" because he had about 2 weeks solid of testing code that we had all written. Demitrius brought a lot of humor to the group.
Phil - great person to work for and an incredible programmer, Phil is doing work on the "engine" part of our project.
Dan – This picture describes Dan to a T. In July and August, Dan became our primary leader, helping to direct our efforts on the project because Phil was so busy. Dan actually worked in the high confidence software lab doing work for Dr. Redwine, but his efforts got redirected to our project. Dan is an amazing software developer (a big reason he's in the high confidence lab), and was another person that I found it easy to work for.
Kevin - Kevin is a grad student here at JMU and is a recent addition to the CIPP team who does most of his work with Phil.
Subir - Subir was hired to fill the vacant CIPP programmer position that Kathy left in March. Subir got his masters degree from George Mason 2 years ago and worked at a small company that did network solutions last year. Subir is probably the hardest worker on the team, and was always willing to help you out, no matter how lost you were.
(1) (2) (3)
1,2
– Examples of our workstations
3 – A view of the entire room
The Project
I first heard about this job from the CS department's mailing list in mid November. The description was pretty vague, but said something like "student programmers needed for Critical Infrastructure Protection Plan". This sounded like it was right up my alley so I applied immediately via email, and met with Kathy Shipp in the ISAT building for an interview in December. My resume was the same one that I had made for TSC 210, which is a technical writing course CS majors have to take (that class was fantastic for resumes). During the interview with Kathy I found out what the CIPP project was all about. The federal government had allocated a large amount of money after 9/11 to strengthening the infrastructure of the United States. This includes both technological infrastructures like computer networks as well as utility infrastructures like the electrical grid. The government wanted to be able to assess the vulnerability of its networks so it commissioned an enormous project to meet this end. JMU was contracted by George Mason University, who had a hand in the government sponsored project. George Mason gave JMU the responsibility of writing a program that could assess vulnerabilities in infrastructures by running "scenarios" on them. A scenario in this sense is a sequence of events that occur which affect the network in some way. Furthermore, not only should the program be able to run scenarios, but they wanted it to be able to run Monte Carlo sets. A Monte Carlo set is a group of runs of scenarios. The reasoning here is that something unusual could happen in a run of a scenario and give you bad data, so averaging it out over thousands of runs of the same scenario would give you better data. An example of a scenario could be someone breaking into a building that housed a router and smashing it with a hammer, or a cracker from outside of the network maliciously attacks the router electronically and brings it down. Since these are two different types of scenarios, the leaders of the team here at JMU decided to split the work into two programs. Any physical attack scenarios would be handled by a piece of software that George Baker (a professor at ISAT) had helped develop, called LabView. This software would not be as comprehensive in features as the software that would handle electronic or logical attacks on a network. That program fell under the responsibility of Dr. Redwine and our team. During the summer I worked 9-5 Monday through Friday, and during the school year I work 10 hours a week, which I take at different times depending on the week.
PSP – The Personal
Software Process
The first goal of our team was to learn a software development process. Software development processes are steps that the developers use to ensure they write well organized, correct code in a timely fashion. The chosen method of the CIPP team was the Personal Software Process, or PSP. The Personal Software Process is a method for designing and writing software, regardless of the programming language.
Each week beginning in January, Phil, Kathy, and the students would meet and go through a lecture on PSP basics. They would explain things like how to go through each phase of software development, how to fill out certain postmortem sheets, and why it was important to keep track of your performance in writing code. It was a bit like having another class because there were PowerPoint slides and homework. The homework was always an easy program because the real point of doing this was to get used to going through the PSP each time we wrote code.
The basic layout looks something like this:
1. Plan - this phase is where you decide when you are going to be doing your work, and how much time you think you will need to get it done
2. Design - in this step you are actually thinking up how your code will work and perhaps writing it down somewhere in words. Most of the details should be worked out at this point so you know exactly what you're going to code before you start.
3. Code - writing the code that conforms to the design
4. Compile - this involves mostly getting rid of syntax errors in your code and getting a running version up for debugging.
5. Test - testing is probably the toughest part of software design. Finding the bugs in your code can be a bigger pain then fixing them.
6. Postmortem - the write up portion of PSP, where you fill out all your paperwork. This is done so that a record of your performance is kept and you have some historical data to look at. With this you can plan better, determine where you make most of your errors in code, and be more organized.
PSP also has five "versions", which basically boil down to levels of detail. Each version has sheets where you must record data about the program (how much time you spent on certain things, etc). The thoroughness of the sheets increased with each new version of PSP
JDBC and an Overview of the Design
When I first began my work on the project full time Phil was still working hard on a prototype that we would demo to GMU in mid July, so there was a lot of room for creativity and ideas about version one of our program. Initially, our design looked like this:
The design evolved over time, especially after we gave the prototype demonstration, but it stayed close to the above diagram.
The GUI Interface entry has an obvious purpose; to interact with the user and provide input and output functionality in a graphical environment. The Controller is a pipeline between the GUI Interface and the Engine, which are the classes that do all the actual work. The Data Manager would be the interface between the engine and the database. The Database would be the repository for all information regarding the network that the program was assessing. Information about the network would be stored in the database, which would in turn be used by the engine to create a "model". A model in the scope of our project meant a representation of a network, and this is what the engine ran scenarios on. Results from the scenarios would also be written to the database, so the data manager was an important liaison.
So it turned out that Phil had me begin work on writing the data manager early after I started in May. Since we did not want to force the user of the program to have a specific kind of database, we needed a "bridge" between our code and the relational database. There were two methods in which we could bridge the database and our code. The first was COM, an antiquated Windows component that dealt with databases. The second option was to use a driver. A driver is a chunk of code written to allow programs to interact with certain components of a system, and in this case that component was a database. Phil wanted to know the pros and cons of using either option, so he told me to research drivers and Demitrius to research COM. I began to research the pros and cons of drivers, and eventually found that the most exceptional and moderately priced option was JDBC. JDBC was a set of drivers written specifically for JAVA applications. There were 4 types of JDBC drivers, depending on the specifics of your JAVA code. After a week or so of research on drivers and databases, Demitrius, Phil, and I all met to discuss our work. Drivers were attractive because I discovered that they were platform independent. Therefore we could distribute the drivers with the program and it would work on any operating system. COM however was a Microsoft Windows invention, and if we programmed our interaction using COM objects, there would be no way to access databases on Linux or UNIX systems. The unfortunate part about drivers, and JDBC in particular, was that it cost money to use. A license and fee had to be paid in order to distribute the drivers for commercial use. After the meeting Phil decided to put off the issue of the data manager and concentrate on the prototype demonstration that was rapidly approaching.
The Prototype
and Network Attacks
Phil was designing the prototype but needed a scenario to run it on. Eventually our program would be able to simulate many different scenarios, and even allow the user to create their own scenario, but at this point we would have to hard code a scenario into the prototype. The early prototype was a model of the JMU network because the network team at JMU obviously had a vested interest in our progress. Therefore we decided that an acceptable network to model for the prototype would be the JMU network. That left two tasks in addition to the coding that still needed to be done. Phil gave me and Jae the job of formatting a map of the JMU network into something that the prototype could use. This turned out to be XML. XML stands for eXtended Markup Language, and is a sort of interpretive language. What I mean by this is that XML isn’t a programming language; it’s more of a way to sculpt orders and information without hard syntactical rules. It’s very good for data entry, and we had an XML parser written into the program. The Networking Department sent us a large map of the topology of the JMU network, which we converted to XML format over the course of a week or so. The XML parser read the file which we had stored information about the network in and converted it into data for the engine. The engine then created the model and visually displayed it for the user. Our prototype looked something like this:
___________________________________________________________
| | |
|Router 1 | |
| | __ |
| (graph of | |__|-------/_\ ------------() |
| activity) | |
| | |
| | |
| | |
| | |
|___________ |______________________________________________ |
(Key: Circle would be a router, square a switch, triangle a workstation)
This is obviously a crude picture, but I hope the reader understands the gist of this layout. Basically the large rectangle on the right is a pictorial view using shapes and images to represent the model of the network, and the left hand side is a status screen. Clicking on one of the elements would display its historical data on the left side. The status screen had graphs as well as a few number fields. The scenario that I researched and suggested to the team was one that I found to be very interesting. The cyber attack I chose is called a DDoS attack, which stands for Distributed Denial of Service. What this boils down to is one cracker having a large amount of “zombie” computers, or computers that he or she has already got control of. These zombie computers are then used to exploit a flaw in the BGP (Border Gateway Protocol) that certain routers use to direct a stream of packets from these routers at a target computer. Since these routers have a high bandwidth they can flood the target with millions of packets and shut down their bandwidth effectively. Our prototype demonstrated that a DDoS attack like this would successfully bog down Wilson Core and the A2 core routers such that almost no traffic would get out of JMU’s network. In mid July, around the 22nd, we unveiled our prototype as well as LabView to the heads of CIPP at George Mason University. A good deal of positive discussion came of the meeting, and the representatives from George Mason seemed genuinely pleased. After that we moved onto developing version one of the program.
Version One – Design, JGO, and Menus
With the prototype demonstration out of our way, we got to work on version one. One important thing I learned was that the prototype in software design can either be of the throwaway variety, or it can be a base for further development. In our case it was somewhere in the middle, since we abandoned our GUI design but kept the engine components. Phil decided to give the student team the opportunity to design the entire GUI interface on our own! This was both exciting and unnerving, because none of us had undertaken anything this big before.
We spent about two weeks in the design phase of the GUI interface development. During those two weeks we met with Dan often, who didn’t really tell us what to do, but guided us in certain directions and gave a few suggestions. Those two weeks were a ton of fun for all of us, because we got to interact with each other and bounce ideas off of each other in a totally creative process that was all our own. We had no real restrictions in what we could do. There were some heated arguments, and a lot of changes to our proposed design, but eventually we met with Dan for two days in a row, locked ourselves in a room, and hammered out the design documents for review by Dr. Redwine.
Eventually Dr. Redwine met with us and approved our design, a few minor changes not withstanding. Our idea for the GUI interface was broken up into 6 major components, which are as follows.
1. Property View – displays a list of
properties for any selected item in the model view. These properties are things
like name, type, etc.
2. Tree View – displays an “explorer” type
view of the hierarchy of the network. This view is very similar to file
hierarchy views found in Windows.
3. Model View- displays a visual
representation of the network. Supports editing abilities to the various elements
in the network. Elements can be anything, from a router to a power switch.
4. Message View – outputs textual system
messages about events that occur while a scenario is running on the model.
5. Toolbar – a floating toolbar with
various operations that can be performed on the model.
6. Menu Bar- a simple menu bar that
provides functionality like new file, open file, save, etc.
_________________________________
| | |
| | |
| 2. | 3. |
| | |
| | |
| | |
|________|________________________|
| | |
| 1. | 4. |
|________|________________________|
A crude drawing of the interface. The toolbar would float over any portion of the screen while the menu bar sits at the top above the tree view and model view.
We split up the components among members of the team. Lavie was given the property view, Subir and Demitrius the tree view, Jae the model view, Dan the message view, and I took the menu bar. In addition, my more pressing task was to work with Jae to integrate her previous work with the new classes everyone was writing, as well as to add menu functionality to the model view. What this means is that when you right click with a mouse on the model view portion of the screen, you would get a right click menu similar to ones you find in other software programs. This took around two weeks altogether, and was the last thing I worked on before the school year began.
An example of a typical day at work
Today Jae, Lavie, Demitrius, and I met with
Dan in 243 to discuss our design and prepare the documents for Dr. Redwine. We were in there all day, but we took a break for
lunch. It got pretty tough to concentrate towards the end because we’d been
going over the technical details for so long. Dan helped us draw up a
priorities list for the features of the gui
so that we know what should be done first and what we can worry about a little
later. We settled on which parts everyone is going to do and planned out how
long it should take. I think 2 weeks is enough time, but we planned 3.
Conclusion and Internship Value
My job this summer lead me to do a lot of things, many of which I had never done before and had to learn how to do. The most important skills I carried with me from my classes at JMU were JAVA programming and software development. The classes that taught these skills were CS139/239 and CS345, but I wish that I had more training in software development and gui development. I can’t stress enough how much this internship helped me, because it let me see how a real software product is developed and allowed me to take a part in the process, which is invaluable because I learn more quickly when I can do things instead of just reading about them. The additional JAVA experience was also great. I experienced a team work environment for the first time and learned a lot about how to manage that. I was very used to doing things on my own and not relying on other people to get work done, so when I was forced into that situation I realized how effective a team can be. I’m very grateful for the opportunity to work with the entire team and can’t say enough about how much I have learned this year.
-Jonathan Bird