CyberSim – Dec03-06Final Report

Client: Information Assurance CenterFaculty Advisor: Doug JacobsonTeam Members: Ryan Applegate

Saddam KhattakDan NguyenAdam Straw

11/18/03

Table of ContentsTable of Contents..............................................................................................................i

1 Frontal Materials.........................................................................................................vi1.1 List of Figures.....................................................................................................vi1.2 List of Tables.....................................................................................................vii1.3 List of Definitions............................................................................................viii

2 Introductory Materials.................................................................................................12.1 Executive Summary.............................................................................................1

2.1.1 Need for the Project.....................................................................................12.1.1.1 Project Activities.....................................................................................12.1.1.2 Researched Technical Approach.............................................................12.1.1.3 Infrastructure............................................................................................12.1.1.4 Game Development Research..................................................................22.1.1.5 Network Security Research.....................................................................22.1.1.6 Documentation.........................................................................................2

2.1.2 Final Results................................................................................................22.1.3 Recommendations for Follow-on Work......................................................3

2.2 Acknowledgement...............................................................................................32.3 Problem Statement...............................................................................................3

2.3.1 General Problem Statement.........................................................................32.3.2 General Solution-Approach Statement........................................................3

2.4 Operating Environment.......................................................................................42.5 Intended User(s) and Use(s)................................................................................4

2.5.1 Intended Users.............................................................................................42.5.2 Intended Uses...............................................................................................4

2.6 Assumptions and Limitations..............................................................................42.6.1 Assumptions................................................................................................42.6.2 Limitations...................................................................................................4

2.7 Expected End Product and Other Deliverables...................................................53 Project Approach and Results......................................................................................6

3.1 End Product Functional Requirements................................................................63.1.1 Requirements of Documents........................................................................63.1.2 Requirements of Implemented Game (in the future)...................................6

3.2 Resultant Design Constraints...............................................................................73.3 Approaches Considered and One Used...............................................................7

3.3.1 Technical Approach Considerations and Results........................................73.3.2 Technologies Considered.............................................................................73.3.3 Advantages and Disadvantages of Each Technology..................................73.3.4 Selected Technology....................................................................................83.3.5 Reasons for Selection..................................................................................8

3.4 Detailed Design...................................................................................................83.4.1 Introduction..................................................................................................8

3.4.1.1 Game Overview.......................................................................................93.4.1.2 Purpose of the Game................................................................................9

3.4.2 Detailed Gameplay Description...................................................................9

i

3.4.2.1 Detailed Walkthrough of the Game.......................................................103.4.3 User Interface and Controls.......................................................................11

3.4.3.1 Description of User Interface.................................................................113.4.3.2 Game Screens........................................................................................12

3.4.3.2.1 Introduction/Splash Screen..............................................................123.4.3.2.2 Menu Screen....................................................................................123.4.3.2.3 Start New Game Screen...................................................................123.4.3.2.4 Load Game Screen...........................................................................123.4.3.2.5 Options Screen.................................................................................123.4.3.2.6 Network Topology Screen...............................................................133.4.3.2.7 Office View Screen..........................................................................133.4.3.2.8 Properties Screen.............................................................................143.4.3.2.9 Email Client Screen.........................................................................143.4.3.2.10 Company Status Screen.................................................................143.4.3.2.11 Purchasing Screen..........................................................................153.4.3.2.12 History Screen...............................................................................15

3.4.4 Game Data.................................................................................................153.4.4.1 Statistics and Variables..........................................................................15

3.4.4.1.1 Game Variables...............................................................................153.4.4.1.1.1 Player Name..............................................................................153.4.4.1.1.2 Difficulty Level........................................................................163.4.4.1.1.3 Game Speed..............................................................................163.4.4.1.1.4 Sound Volume..........................................................................163.4.4.1.1.5 Music Volume..........................................................................16

3.4.4.1.2 Company Variables, Uncontrollable...............................................163.4.4.1.2.1 Income......................................................................................163.4.4.1.2.2 Size...........................................................................................173.4.4.1.2.3 Morale.......................................................................................173.4.4.1.2.4 Productivity...............................................................................173.4.4.1.2.5 Prestige/Stock Price..................................................................173.4.4.1.2.6 User Expertise...........................................................................183.4.4.1.2.7 Systems Status..........................................................................18

3.4.4.1.3 Company Variables, Controllable...................................................193.4.4.1.3.1 User Training............................................................................193.4.4.1.3.2 Systems Maintenance...............................................................20

3.4.5 Higher Level Design..................................................................................203.4.5.1 Game Engine Structure..........................................................................20

3.4.5.1.1 Engine Composition........................................................................203.4.5.1.2 The Game Cycle..............................................................................20

3.4.5.2 How Attacks Work................................................................................213.4.5.2.1 Attack Class.....................................................................................213.4.5.2.2 The Life of an Attack.......................................................................22

3.4.5.2.2.1 Attack Prevention Stage...........................................................223.4.5.2.2.2 Attack Detection Stage.............................................................223.4.5.2.2.3 Attack Damage Stage...............................................................223.4.5.2.2.4 Relation Between Attacks and Defenses..................................22

ii

3.4.5.2.3 Included Attacks..............................................................................233.4.5.2.3.1 Virus.........................................................................................233.4.5.2.3.2 Worm........................................................................................233.4.5.2.3.3 Social Engineering....................................................................233.4.5.2.3.4 Physical Access........................................................................243.4.5.2.3.5 Eavesdropping..........................................................................243.4.5.2.3.6 Password Access.......................................................................243.4.5.2.3.7 Denial of Service......................................................................24

3.4.5.3 Defenses.................................................................................................253.4.5.3.1 The Defense Class...........................................................................253.4.5.3.2 Included Defenses............................................................................25

3.4.5.3.2.1 Antivirus...................................................................................253.4.5.3.2.2 Firewall.....................................................................................253.4.5.3.2.3 Access Control..........................................................................253.4.5.3.2.4 Biometrics/Guards....................................................................263.4.5.3.2.5 Cryptography............................................................................263.4.5.3.2.6 User Expertise...........................................................................263.4.5.3.2.7 Backups.....................................................................................263.4.5.3.2.8 Redundant Systems...................................................................26

3.4.5.3.3 How Defenses Defend.....................................................................263.4.5.4 The Network..........................................................................................26

3.4.5.4.1 The Computer..................................................................................273.4.5.4.2 Upgrading the Network...................................................................27

3.4.5.5 Economic Model....................................................................................273.4.6 Multimedia.................................................................................................27

3.4.6.1 Graphics.................................................................................................283.4.6.1.1 Graphical User Interface..................................................................28

3.4.6.1.1.1 GUI Look-And-Feel.................................................................283.4.6.1.1.2 GUI Implementation.................................................................28

3.4.6.1.2 Graphical Perspective of Network Topology Screen......................283.4.6.1.2.1 Network Topology Screen Look-And-Feel..............................293.4.6.1.2.2 Network Topology Screen Graphical Implementation.............30

3.4.6.1.3 Graphical Perspective of Office Screen...........................................303.4.6.1.3.1 Office Screen Look-and-Feel...................................................303.4.6.1.3.2 Graphical Implementation of Office Screen.............................31

3.4.6.2 Music and Sound...................................................................................323.4.6.2.1 Music...............................................................................................323.4.6.2.2 Sound...............................................................................................32

3.5 Implementation Process Description.................................................................333.5.1 Implementing the Back End......................................................................333.5.2 Implementing the GUI...............................................................................333.5.3 Integrating Back End and GUI..................................................................333.5.4 Improvements to Implementation Process.................................................33

3.6 End-Product Testing Description......................................................................333.6.1.1 How and where will the testing be performed?.....................................343.6.1.2 Exactly what will be tested?..................................................................34

iii

3.6.1.3 How will testing accuracy be determined?............................................343.6.1.4 What information is required on the forms that will be used to record the test results?.......................................................................................................353.6.1.5 Who will do the testing and how will it be verified?.............................35

3.7 Project End Results............................................................................................353.7.1 Detailed Design Document........................................................................353.7.2 Research Paper on Network Security........................................................353.7.3 Code and Documentation for Resource File Manager..............................353.7.4 Infrastructure..............................................................................................36

4 Resources and Schedule............................................................................................374.1 Resource Requirements.....................................................................................37

4.1.1 Personnel Effort.........................................................................................374.1.2 Other Resource Requirements...................................................................384.1.3 Estimated Project Costs.............................................................................39

4.2 Schedules...........................................................................................................414.2.1 Tasks versus Project Calendar Chart.........................................................414.2.2 Project Deliverables Chart.........................................................................45

5 Closure Materials.......................................................................................................475.1 Project Evaluation..............................................................................................475.2 Commercialization.............................................................................................475.3 Recommendation for Additional Work.............................................................485.4 Lessons Learned................................................................................................48

5.4.1 Successes...................................................................................................485.4.2 Failures......................................................................................................485.4.3 Technical Knowledge Gained....................................................................495.4.4 Non-technical Knowledge Gained.............................................................495.4.5 Different Approaches.................................................................................49

5.5 Risk and Risk Management...............................................................................495.5.1 Anticipated Potential Risks and Planned Management Thereof...............495.5.2 Anticipated Risks Encountered and Success in Management Thereof.....495.5.3 Unanticipated Risks Encountered and Success in Management Thereof..505.5.4 Resultant Changes in Risk Management Made Because of Encountered Unanticipated Risks...................................................................................................50

5.6 Project Team Management................................................................................505.6.1 Client Contact Information........................................................................505.6.2 Faculty Advisor Contact Information........................................................505.6.3 Team Members Contact Information.........................................................51

5.7 Closing Summary..............................................................................................525.8 References..........................................................................................................53

5.8.1 Programming References...........................................................................535.8.1.1 Code Documentation.............................................................................535.8.1.2 OpenGL Walkthroughs..........................................................................53

5.8.2 Network Systems References....................................................................535.8.2.1 Network Guides and Information..........................................................535.8.2.2 Network Security Information...............................................................535.8.2.3 Network Security Issues and Current Events........................................54

iv

5.8.2.4 Gaming Theory and Issues....................................................................545.9 Appendices..........................................................................................................A

5.9.1 APPENDIX A – Sample DirectX Code for GUI........................................A

v

1 Frontal MaterialsThis section contains information about the document including a list of figures, list of tables, and a list of definitions.

1.1 List of FiguresThe following contains a list of figures for the document.

Figure 3.4.4.1.2.7 Relationship between company variables......................................19 Fig 3.4.6.1.2.1 A sample topology screen from CyberProtect™...........................29 Figure 3.4.6.1.3.1 Sample screen from The SimsTM....................................................30 Figure 3.4.6.1.3.2 Texture mapped cube.....................................................................31

vi

1.2 List of TablesThe following contains a list of tables for the document.

Table 3.3.3a Advantages/Disadvantages of C / OpenGL.....................................7 Table 3.3.3b Advantages/Disadvantages of Java / Java3D...................................8 Table 3.3.3c Advantages/Disadvantages of Macromedia Director....................37 Table 4.1.1a Original Personnel Effort Requirements........................................37 Table 4.1.1b Revised Personnel Effort Requirements........................................38 Table 4.1.1c Actual Personnel Effort Requirements..........................................38 Table 4.1.2a Original Other Resource Requirements.........................................38 Table 4.1.2b Revised Other Resource Requirements.........................................39 Table 4.1.2c Actual Other Resource Requirements............................................39 Table 4.1.3a Original Estimated Project Costs...................................................40 Table 4.1.3b Revised Estimated Project Costs...................................................40 Table 4.1.3c Actual Project Costs.......................................................................40 Table 5.6.1 Client Contact Information............................................................50 Table 5.6.2 Faculty Advisor Contact Information............................................51 Table 5.6.3a Team Leader Contact Information.................................................51 Table 5.6.3b Communication Coordinator Contact Information........................51 Table 5.6.3c Team Member Contact Information..............................................51 Table 5.6.3d Team Member Contact Information..............................................51

vii

1.3 List of DefinitionsThe following is a list of definitions used in the document.

Buffer overflow – Technique for crashing or gaining control of a computer by loading it with data sent to the buffer in a computer’s memory.

Crackers – Hackers on hire who break into computer systems to steal valuable information for their own financial gain.

Cyber squatting – Buying domain names like www.mcdonalds .com or www.coke .com , and then selling them for a big profit (just like a personalized number plate).

Denial of service – Intentionally flooding a website with too many requests for information, an attacker can effectively clog the system, slowing performance or even crashing the site.

Dumpster diving – Sifting through a company’s garbage to find information to help break into their computers.

Eavesdropping – An intruder reroutes all traffic through his/her machine Hacker – A person who explores programming systems in detail and who seeks to

extend his knowledge in this field. The term represents persons illegally introduced into computer systems. White-hat hackers are the good guys who are excited by the intellectual challenge of tearing apart computer systems to improve computer security. Black-hat hackers are desperadoes on the Net out to crash systems, stealing passwords, and generally wreaking as much havoc as possible.

Insiders – Disgruntled employees working solo or in concert with outsiders to compromise corporate systems.

Logic bombs – An instruction in a computer program that triggers a malicious act. Malicious applets – Tiny programs, sometimes written in Java, which misuse a

computer’s resources to modify files on the hard disk, send fake e-mail, or steal passwords.

Password crackers – Those who possess software that can guess passwords. Phreaking – An act of pirating telephone networks. Since they spend long hours

trying to get access to phone lines the majority of the hackers are also phreakers. Moreover, since the modern telephone exchanges are computerized, it becomes possible for phreakers to control the network as easily as an employee of the telephone company.

Scans – Widespread probes of the Internet to determine types of computers, services, and connections. This way one can take advantage of the weaknesses in a particular make of computer or software program.

Script bunnies – Amateur hackers with little technical savvy who download program-scripts that automate the job of breaking into computers.

Sniffer – A program that covertly searches individual packets of data as they pass through the Internet, capturing passwords of the entire contents.

Spoofing – Faking an e-mail address or a web page to trick users into passing along critical information like passwords or credit-card numbers.

Trojan horses – Software programs that hides another program. For example, if in addition to being a word-processing program, its programmer decides to make it

viii

search for the valid applications and erase all other word processing software, it is a Trojan horse. It is also possible to use a Trojan horse to introduce a virus on a computer.

Viruses – Programs that can reproduce in a computer and infect other programs. It is transmitted from one computer to another, on copying an infected program. The viruses can be programmed to be harmful, for example, by erasing all of the machine’s data on a precise date.

War dialing – Programs that automatically dial thousands of telephone numbers in search of a way in through a modem connection.

Worms – A worm differs from a virus in that it transfers itself from one computer to the other through a network.

Version control system – A system to keep track of multiple versions of software and configurations allowing multiple programmers to work simultaneously on the same software.

Integrated development environment – A developing environment integrated in the software used by programmers to aid in their software development. Provides options and features for the programmer to be productive and efficient.

Resource File Manager – Software used to manage the resource files needed for the project. Provides options for the programmer to load, save, and delete files from the resource files as needed for the implementation of the project.

ix

2 Introductory MaterialsThis section contains basic information about the project including the executive summary, acknowledgement, problem statement, operating environment, intended users and uses, assumptions and limitations, and the expected end product and deliverables.

2.1 Executive SummaryThis section contains a summary of the project including the need for the project, project activities, final results and recommendations for follow-on work.

2.1.1 Need for the ProjectCyberSim is an intriguing and challenging project. Its design and implementation will be a beneficial learning tool for the engineers in charge of its creation, and the final product will provide a fun and effective way to learn about network security.

With the society’s use of the Internet continually growing, so grows the need for network security and persons educated in the subject matter. There are currently very few games that are about network security, and even fewer that have any educational value. CYBER Sim would be one of the first of its kind.

2.1.1.1 Project ActivitiesCyberSim is a large project, not something that can be completed in one term. The activities in this first term centered on laying a foundation for future teams to build on. The pieces of this foundation are outlined in the following sections.

2.1.1.2 Researched Technical ApproachMuch work was put into the research of the technical approach used for the project. In summary, C or C++ and OpenGL will be used for languages in the Microsoft Visual Studio.net integrated development environment. Microsoft Visual SourceSafe will be used as the version control system. Any necessary database will be done with text files.

2.1.1.3 InfrastructureThe groundwork has been placed for development. A version control system, Microsoft Visual SourceSafe, was set up on a server on one of Dr. Jacobson’s machines. It can be accessed by any future team. Two means for communication were set up: email and a discussion group. The email address, cybersim@iastate.edu, can be used to communicate with past and present team members. A discussion group was established at http://groups.msn.com/cybersim/ that can be used for posting ideas and group communication. The integrated development environment, Microsoft Visual Studio .NET, was integrated with Microsoft Visual SourceSafe. Microsoft Visual Studio .NET can be used to develop the code for the project. A document was created explaining the different pieces of infrastructure and how to access and use each piece.

1

2.1.1.4 Game Development ResearchMuch research went into game development. Most of this research is included in the design. Research was also done on a resource file manager. This research is not included in the design. The resource file manager is code, licensed from gamedev.net, checked into the version control system. There is a document, also on the version control system, which explains the details of the resource file manager and how to implement it.

2.1.1.5 Network Security ResearchResearch on the topic of network security was done to provide the game with educational context. This research is in the form of a document on the version control system, and also included in the design.

2.1.1.6 DocumentationDocumentation includes the documents required: project plan, project poster, design report, and this, the final report. Each of these documents was continuously improved throughout the semester. This final report which contains information from the project plan and the design report can be considered the final draft of both the project plan and design report.

The daily activities this term centered on discussion and documentation. From time to time the team would try to implement parts of the project, but would inevitably come to realize that the design was not fully complete and thus more discussion and documentation was needed.

2.1.2 Final ResultsThe final results are a list of deliverables as follows:

- Detailed design document: a high-level description of the design of CYBER Sim that serves as a walk-through for implementing the game.

- Research paper on network security: A document describing the theory of network security and how it has informed the design of CYBER Sim. The content of this document will be incorporated into the game (for example, the descriptions of each network security component.) to educate the players.

- Code and documentation for Resource File Manager: The RFM is a mechanism that allows a game to access library and graphic files. The group has produced compiled code and documentation on how to use it.

- Infrastructure: A version control system, mailing list, and discussion group has been formed for a CYBER Sim team to utilize.

2

2.1.3 Recommendations for Follow-on WorkThe following are the recommendations for follow-on work:

1. Reviewing and revising the document – A future group should review the document for comprehension and revise it as necessary to the needs of their group.

2. Implementing the game – From the information and instructions given in the documents, a future group can implement CYBER Sim.

3. Create graphics – A future group can create the art necessary to make CYBER Sim have a professional look-and-feel.

4. Testing – After the game has been programmed, the future group should rigorously test the program for bugs.

2.2 AcknowledgementInformation Assurance Center Dr. Doug Jacobson, Associate ProfessorIowa State University

2.3 Problem StatementThis section defines the problem and the solution in general terms.

2.3.1 General Problem StatementThe main problem was how to educate the general population about a concept that is both obscure and technical. Given the abstract nature of computer network security and its implementation, the task was to create an interactive game that would be both educational and entertaining for the user, such that he/she shall have a concrete understanding of the principles behind network security, as well as gain an interest in pursuing the subject in further depth.

2.3.2 General Solution-Approach StatementThe solution was to model CYBER Sim after the popular Sim games. The Sim games have brought normally difficult and abstract topics—such as the building of a city or the genesis of life—and brought it down to a level that is easy to grasp and captivating for the player. The goal of CYBER Sim was to do the same with computer network security.

In the product CYBER Sim, the features that have made the Sim games so well-received were attempted to be implemented, including:

Functional graphical interface Strategic elements to the game play Easy learning curve and intuitive controls Compelling presentation of the theory and conceptual ideas

3

2.4 Operating EnvironmentCYBER Sim was planned to be distributed by compact disc (CD), which is subject to wear. It was to be created to run on all versions of the Windows operating system since and including Windows 95. Each of these operating systems has a different level of stability and different functionality that would be needed to be taken into account.

CYBER Sim was to be used on a wide range of computer systems including relatively low-end computer systems. A low-end computer system could have one or more of: low memory, slow CPU speed, low hard disc space, or poor sound or video capabilities.

2.5 Intended User(s) and Use(s)This section identifies the intended users and uses of the project.

2.5.1 Intended UsersThe intended users of CYBER Sim were those who are interested in computer security and who like to play games. This ranged from middle school students to engineers and professors in the computer industry. CYBER Sim’s user friendly and self-explanatory gameplay was planned to be easy for young adults to navigate, yet its strategic virus attacks shall make it challenging for older adults.

2.5.2 Intended UsesCYBER Sim was planned to be a marketable product and would be distributed by Iowa State University to high schools and other environments where it may be utilized as an educational tool.

2.6 Assumptions and LimitationsThis section gives the assumptions and limitations for the project.

2.6.1 Assumptions Users would possess basic knowledge of and have experience with computers Users would have a CD-ROM drive User would have sufficient computing power

o Computer would have at least a 300 MHz processor, o Computer would have at least 30 MB of disk space, o Computer would have at least 64 MB of memory

Users would be interested in computer security Game would be played by only one player at a time Users would have access to a Windows based PC

2.6.2 Limitations Quality art and music for the game was be limited by time The project must fit on a single CD-ROM (less than 700MB)

4

2.7 Expected End Product and Other Deliverables Project plan Project poster Design report Infrastructure Research Game Final report

The infrastructure will provide the groundwork for development. Infrastructure includes means of group communication, a version control system and an integrated development environment.

Research conducted on the topics of network security and game development will be delivered to the client. The network security research will be included in the game so that the user can learn about network security by playing the game. The game development research can be used by the developers in creating the game.

The game, CYBER Sim, will be distributed by Iowa State University when it is implemented. The program was designed in such a way that it will provide a framework that will be easy to build on by future attempts to expand the game.

5

3 Project Approach and ResultsThis section gives a detailed description of the approach and results for the project including end product functional requirements, resultant design constraints, approaches considered and one used, detailed design, implementation process description end-product testing description, and project end results.

3.1 End Product Functional RequirementsThis section contains the end product functional requirements for the project. Since the goals of this project changed midterm, this section will be in two parts: the requirements of the design documents that were produced for a future group’s reference, and the requirements of the game when it is implemented by a future group. The former section will be in past tense and the latter will be in the future tense.

3.1.1 Requirements of DocumentsThese are the requirements for the documents that were produced.

Documents are thorough and completeIt was required that the documents are as complete as possible so that implementation can be done without a future group needing to spend time fixing the design.

Documents are readableIt was required the documents be as intuitive and readable as possible so that a future group does not misunderstand our work.

3.1.2 Requirements of Implemented Game (in the future)These are the requirements for the game to be implemented in the future.

Allow purchase of computer equipment to prevent against network attacks

The user shall create a network and then attempt to protect it by buying computer equipment. The goal of the user is to prevent against network attacks simulated by the game.

Simulate network attacks

The game shall simulate network attacks such as viruses, worms, etc. against the network that the user is attempting to protect.

Provide descriptions computer equipment and software, and attacks

In order to help the user learn about computer security the game shall provide information about the computer equipment available for purchase and the network attacks that may be simulated.

6

3.2 Resultant Design ConstraintsThis section contains the resultant design constraints for the project.

Cost-effective design Flexible for future expansion

3.3 Approaches Considered and One Used

3.3.1 Technical Approach Considerations and ResultsThis section details the process taken to select the technology for the project including technologies considered, advantages and disadvantages of each technology, the selected technology, and the reasons for selection.

3.3.2 Technologies ConsideredThe following are the technologies considered for the project:

C / OpenGL Java / Java3D Macromedia

3.3.3 Advantages and Disadvantages of Each TechnologyThis section gives the advantages and disadvantages of each technology that was considered for the project

Table 3.3.3a Advantages/Disadvantages of C and Open GLAdvantages DisadvantagesExcellent tutorials Complexities of the language may be

difficult to masterWidely used Low level language – more prone to errorSmall learning curveGood development environmentCompatible with Microsoft Visual SourceSafeLow level language – fastEntire group has experience

7

Table 3.3.3b Advantages/Disadvantages of Java and Java3DAdvantages DisadvantagesSmall learning curve Slow at run-timeWidely used Poor development environmentExtremely fast for a Java 3D engine Code reuse could be risky (latest version

still had some bugs and was not fully testedUses raycasting and texture mapping May not interface well with other codeExisting engine with source code availableFirst person look and feelTypical advantages of code reuse (accelerated development, reduce process risk, and increased reliability

Table 3.3.3.c Advantages/Disadvantages of Macromedia DirectorAdvantages DisadvantagesGood for creating movies Poor for dame development, but can be

used for movies with a gameSimple to use once learned Large learning curveGood tutorials No built in 3D engine, possible problems

with interfacing another languageCan incorporate 3D graphics

3.3.4 Selected TechnologyThe selected technology was C / OpenGL. The development environment will be Microsoft Visual Studio .NET

3.3.5 Reasons for SelectionAlthough each technology met the project’s needs, C and OpenGL had the most advantages. The group as a whole was already familiar with it. The development suites for it are excellent. And more importantly, the language is very flexible and powerful.

3.4 Detailed DesignThis section is a high-level description of Cyber SIM. Although no programming details are included, it does provide a comprehensive schematic of what the vision is for Cyber SIM.

3.4.1 IntroductionThis sub-section describes the general idea behind the game play of Cyber SIM as well as the intentions behind this game—for example, what is intended for the user to learn.

This description is intended for both the programmers and client of this project, as well as the interested customer.

8

3.4.1.1 Game OverviewCyber SIM places the player in the role of a system administrator of an up and coming business. The player is in charge of keeping the company’s networks secure from attacks and system failures, whether it is viruses accidentally downloaded from the Internet or hackers with malicious intent.

At the player’s disposal are a variety of defenses and countermeasures to place on the network. The player will also be responsible for deciding security policies and the maintenance of the network. If the player succeeds, the company will flourish and the budget will increase, giving the player greater purchasing power. If the player does poorly, the company and its budget will be stagnant or even shrink.

Cyber SIM is a persistent and open-ended simulation. In other words, there is no easy or clear solution. As the company grows larger, the network will become a more frequent target for increasingly sophisticated attacks, and the costs of maintaining security measures will increase. Also, too strict of security policies and countermeasures can frustrate the company employees and even reduce productivity.

So each action the player takes will affect numerous variables, and the player will have to be diligent in finding the right balance between a secure network and the costs to maintain it. Cyber SIM is meant to be a game that can take many hours for the player to reach a satisfactory solution.

3.4.1.2 Purpose of the GameAs stated in Section 2.3.2 – General Solution/Approach, Cyber SIM is intended to be an educational game that players who are unfamiliar with the concepts and terminology behind network security. The game will place an emphasis in providing information, both in game feedback and in textual descriptions, which will educate the player.

Of course, as a game, Cyber SIM is meant to be entertaining, even to a player not interested in or already familiar with network security. Like any other Sim game, the player will be challenged to make intelligent decisions and responses, and the player will be rewarded by receiving feedback from the robust simulation.

3.4.2 Detailed Gameplay DescriptionThis section consists of an informal walkthrough to give a concrete idea of the options and challenges for the player to consider.

9

3.4.2.1 Detailed Walkthrough of the GameAt the start of a new game, the player finds himself as the system administrator of a startup company. There is a small server and LAN and just a few employees to take care of. The player has a small budget to work with, in accordance to the company having a small income. The player’s first step after getting a look at the simple network is to go to the purchase screen and buy some basic security measures. At this point, the player can only afford the cheapest kinds of protection, such as basic anti-viral software and firewalls. That’s OK, though. Because the company is relatively small, it will not be a big target for hackers at this point. Also, it is assumed since these initial employees are experienced enough to start their own company, their user expertise—a statistic that describes how skilled the employees are at avoiding human error—is pretty high. As long as the player installs some basic measures, the network should be safe. Every quarter-year in game time will bring in more income to buy more measures.

The game runs in real-time. Every few seconds will be approximately equal to a day in game time (this is adjustable). Every game day, the network will come under attack. Most of the time, these attacks will be low-level and will be immediately stopped by the counter-measures, such as a virus being detected by a routine virus scan.

However, some attacks will be strong enough that blocking them will not be trivial. For this, the game will determine if an attack can breach the network by considering the types and strengths of the defenses (anti-virus software and firewalls both combine to block out viruses), global factors affecting the company (how well the network software has been maintained, for example) and the strength of the attack.If the attack succeeds, then the network has been breached. The player will not always be notified of this. In the case of a virus, the virus will have time to spread from computer to computer and it may take several days or weeks for the virus to “announce” itself, by which time, it may have already caused significant damage. However, along with the defenses needed to prevent attacks, the player can purchase certain hardware and software that will reduce the damage of attacks if they are successful. For example, a robust backup system can easily replace files corrupted by a virus.

Obviously, the player will want to detect the presence of an intruder as soon as possible. To this end, there are several ways that the player can keep up to tabs with the performance of the network. The simplest and most menial of the methods is to individually check each machine and see if there is any strange behavior, such as lackluster performance. Another way to get feedback is to pay attention to the in-game email. When employees notice problems, they will email the system administrator to complain. Maybe an employee “just forgot” her password. Or maybe that password was hacked by an eavesdropper…

10

If the player has been doing an adequate job of keeping the company’s network secure, after awhile, the company will grow. The player will receive an (in-game) e-mail informing him that a new server was installed along with more computers. And of course, more employees were hired. This will affect the player’s job in several ways. The most obvious is that the bigger the company, the more money that will be brought in and therefore the more money for the player’s budget. However, this will be offset by the fact that the player now has a larger network to secure. The basic anti-viral software that was initially purchased, for example, will cost more to install this time around because there are more computers to install it on. Also, the user expertise level will drop. This is primarily for game balance issues, but it can be thought of as a reflection of the company hiring quantity over quality as it gets larger. And finally, the growth of the company makes it a fatter target. Expect more frequent and sophisticated attacks as the company grows. What happens if a poor job is done securing the network? Then the network becomes vulnerable to a variety of problems, including slow performance, crashing, data corruption, and stolen secrets. It basically all adds up to reduced productivity, which results in reduced income and therefore, a reduced budget. Furthermore, the company’s prestige will take a hit. Being at the mercy of viruses and hackers does not make the company attractive to investors, and so the company’s growth will slow down and even shrink if the player’s performance is poor.When implementing security measures and policies, one thing to be aware of is how they will affect the performance of the network and employees. It is trivial to make a safe network—just unplug the Internet connection. Then the network would be completely safe from outside hackers and viruses. Of course, then the company’s Internet business has just been completely cut off. Likewise, with implementing security, there is a tradeoff between freedom and safety. For example, a player can configure a firewall to block all peer-to-peer sharing programs to eliminate the possibility of employees catching a computer virus from downloading pirated software. This is a pretty reasonable countermeasure to take. But if the player wants to eliminate the transfer of files by FTP and email attachments—this would certainly reduce the chances of employees getting a virus, but it would not make them very happy to be denied these services and may in fact, become a hassle for them to the point where Productivity will fall. So there is no actual perfect victory in Cyber SIM. The game is meant to be a persistent simulation where the player can find his own kind of balance between security, income, and performance.

3.4.3 User Interface and ControlsThis section describes how the game will be navigated by the player, in particular, the theory behind the graphic interface and the specific screens that the player will encounter.

3.4.3.1 Description of User InterfaceCyber SIM will be, as most GUI-based applications are, heavily driven by the mouse. The interface will rely heavily on buttons and icons so that the user can navigate through the entire game with just the mouse.

11

3.4.3.2 Game ScreensThis section describes the details of each screen included in the game.

3.4.3.2.1 Introduction/Splash ScreenThis screen displays the logo of Cyber SIM, as well as credits, version number, and copyright information.

3.4.3.2.2 Menu ScreenThis screen provides the player the following options, each with their own screen

Start new game – Begin a new game from scratch Load game – Load a previously saved game Options – Configure playability options Exit game – Exit the program

3.4.3.2.3 Start New Game ScreenThis screen allows the player to provide a name for him/herself and a name for the company that he/she will works in, to give each game a custom, personalized flavor. Also, the player can select a difficulty level—the harder the level, the more frequent and damaging the attacks.

3.4.3.2.4 Load Game ScreenThis screen allows the player to choose from a gamesave file from which to continue the game.

3.4.3.2.5 Options ScreenThis screen allows the player to configure how the game is presented. The following variables can be adjusted

Sound on/off Sound volume Music on/off Music volume Gamma/brightness

12

3.4.3.2.6 Network Topology ScreenThis screen is where the player can view the entire network at the architectural level. It diagrams how the company’s servers, host computers, routers and hubs are physically connected to each other and to the outside world.

Here is also where the player will place the countermeasures and defenses that he/she has purchased from the purchase screen (3.2.3.2.11).

From this screen, the player can click on each machine or device and open the properties screen (3.2.3.2.8) to view its information, statistics, and properties.

The topology view will be a two-dimensional representation of the network

3.4.3.2.7 Office View ScreenThis screen is where the player can view the company at the “human” level. Employees will be seen in this screen, and certain hardware features (such as the computers, obviously) will be represented.

The purpose of this screen is to provide another layer of feedback to the player. For example, the player can see that security policies are too tight or network performance too slow when employees display frustration, represented by thought balloons or physical actions (such as punching a computer’s monitor!).

This screen’s main function is to provide an interesting, entertaining and dynamic representation of the network.

The screen is planned to be rendered in a three-dimensional, isometric view.

13

3.4.3.2.8 Properties ScreenWhen a player selects a device or machine on the network topology screen, he/she can access its properties. This is the screen that will pop-up if he/she chooses to view the properties of the device or machine.

This screen serves to provide basic information and data about the individual machine or device. Here is what the player will find:

Name – the machine/device’s specific name (assigned by the game, in the format: DEVICETYPE-000)

Type – what the device/machine is (i.e. “firewall”, “hub”, etc) Status – the performance of the device in terms of a percentage Effectiveness – if this is a countermeasure, the estimated effectiveness against

stopping attacks Installed countermeasures – if this is a machine, this is a list of the countermeasures

installed on it (such as anti-virus software) Cost: if this was a purchased countermeasure, how much it cost (and what it can be

sold for) Description – a paragraph description of what the device/machine actually is. This is

intended for players who are not familiar with the terminology.

3.4.3.2.9 Email Client ScreenJust like a real system administrator, the player receives (in-game) emails from the employees who will provide feedback on how the network’s performance. This is also where the player learns of announcements, such as the expansion of the company.

This screen will be modeled in appearance after a simple email client. There will be a list containing all received messages with the author, subject, and date. The player can click on each message in order to read it. Also, the player can delete messages.

The player will not be able to send out email.

3.4.3.2.10 Company Status Screen This screen allows the player to have an overview of the company’s status in terms of size (i.e. number of employees and size of network), finance, and overall network security effectiveness. This screen is meant to provide simple, statistical feedback of the player’s performance.

14

3.4.3.2.11 Purchasing ScreenThis screen is where the player will purchase countermeasures which he/she will place in the network topology screen (3.2.3.2.6). The screen will be divided in two sections. The left half will be a list menu of all available countermeasures for purchase. The player can click on each item, and on the right side of the screen, the following information will be displayed:

Name – the name of the countermeasure (“Norton3000 Anti-Virus Software”) Type – the type of countermeasure (“Anti-viral software”) Price – the cost of the countermeasure, both in terms of initial purchase price and

maintenance cost Effectiveness – from a scale of 1 to 100, how effective the countermeasure is at

preventing/containing attacks Hindrance – from a scale of 1 to 100, a rating of how the countermeasure can

negatively affect productivity. This number reflects the fact that higher security often results in higher amounts of hassle.

Description – A paragraph description of the countermeasure for players unfamiliar with the terminology

3.4.3.2.12 History ScreenThis screen allows the player to view the global statistics of the company (such as income, number of attacks, company size) over time, plotted as a line graph. Here, the player can see how well he/she has been performing as well as see how the countermeasures and security policies he/she implemented are affecting the company.

3.4.4 Game DataThis section contains high-level descriptions of the details, numbers, and formulae that will drive Cyber SIM’s simulation.

3.4.4.1 Statistics and VariablesThis sub-section describes the variables that the game will use to calculate events and provide feedback to the player.

3.4.4.1.1 Game VariablesThese are the variables relating to the gameplay

3.4.4.1.1.1 Player NameThe player’s name. This affects how he/she is addressed by the game. Assigned at the new game screen.

15

3.4.4.1.1.2 Difficulty LevelThis number is a multiplier that increases several variables in the game in order to provide the appropriate challenge level for the player. These are the possible values:

Easy: 0.75 Normal: 1.0 Difficult: 1.25

The variables that these numbers are multiplied against are:

Attack frequency – higher difficulty means more attacks Attack strength – higher difficulty means stronger attacks Attack damage – higher difficulty means more damaging attacks Countermeasure cost – higher difficulty means higher costs per countermeasure

The difficulty is selected in the new game screen

3.4.4.1.1.3 Game SpeedThis number reflects how many real-time seconds it takes for a day in game-time to pass. This number can range from 1 to 5 seconds per game-time day. The game can also be paused.

The speed can be adjusted in-game in the options screen.

3.4.4.1.1.4 Sound VolumeThis number ranges from 1-100 and affects how loud the game sounds are. Can be adjusted in-game in the options screen.

3.4.4.1.1.5 Music VolumeThis number ranges from 1-100 and affects how loud the background music is. Can be adjusted in-game in the Options Screen

3.4.4.1.2 Company Variables, UncontrollableThese are the variables that describe the player’s company profile and performance. These are feedback numbers—they cannot be directly controlled by the player. Also included is how each variable affects and is affected by other variables.

3.4.4.1.2.1 IncomeThis number describes, in a monetary value, how much money the player will be given at the start of each quarter-year. It is an indicator of performance—a well-protected network means that the company doesn’t have to spend money repairing the damage caused by attacks. The bigger the company, the more money that will be brought in.

Affects: Purchasing abilityAffected by: Productivity, size (network), attacks

16

3.4.4.1.2.2 SizeThis number describes how many computers exist on the network. Essentially, the number of computers is a discrete factor in calculating the income. Each computer brings in a set value of income. Also, this number is a factor in the cost of installing countermeasures. More computers require more copies of anti-viral software, for instance. The network grows according to how successful the company is.

Affects: Income, cost of countermeasuresAffected by: Prestige

3.4.4.1.2.3 MoraleThis number describes, from a scale of 1-100, how happy the company employees are. It is a direct reflection of how stringent the security policies are. The less freedom employees have, the less they will enjoy working for the company. This number has a very small effect on productivity.

Affects: ProductivityAffected by: Hindrance of countermeasures

3.4.4.1.2.4 ProductivityThis number describes, from a scale of 1-100, the efficiency in terms of work output of the employees. The higher the productivity, the higher the amount of money brought in. Overly strict security policies can adversely affect productivity. On the other hand, successful attacks will definitely reduce productivity (server crashes, for instance). This number, if abnormally low, can serve as an indication that the network is under attack.

Affects: IncomeAffected by: Hindrance of countermeasures, attacks

3.4.4.1.2.5 Prestige/Stock PricePrestige is a number from 1-100 describing how attractive the company is financially. For game purposes, the company is attractive if it isn’t vulnerable to attacks. Prestige influences how quickly the company will grow, and it increases as the company is able to stay attack-free over time. No one wants to invest in a company that is constantly beset by viruses and hackers.

The prestige number will not be seen by players—it is used solely by the game to calculate how fast the company will grow. The player will see the prestige number in the form of a stock price, a dollar amount that is a function of the prestige and the current Income. It is only for display purposes and emphasizes that the safer the company’s network, the more willing people are to invest in it.

Affects: Size (the rate of change)Affected by: Number of successful attacks

17

3.4.4.1.2.6 User ExpertiseThis is a number from 1-100 that reflects the technical expertise of the player’s employees. It is a number that will play in almost all calculations of how successful attacks are against the network. Having employees who know, for example, not to open an email attachment from a suspicious source, will reduce the exposure of the network to malicious viruses. Poorly trained employees can undermine even the best network protection.

This number is obviously affected by how much money the player invests in user training (3.2.4.1.3.1), but is also slightly affected by size, reflecting the more “personal” assistance technical staff can give in a smaller company. In a small company, there is one system administrator for a few employees. In a larger company, the system admin is not quite able to personally help and supervise every employee in their network habits, or to remind them of their training.

Affects: Number of successful attacksAffected by: User training, size

3.4.4.1.2.7 Systems StatusThis is a number from 1-100 that reflects the network’s readiness. This number encompasses, for example, the frequency that software is upgraded or that faulty hardware is replaced.

This number plays a part in the calculation of how successful attacks are. At 100 percent, the countermeasures will be working at their advertised strength. Otherwise, they will operate at a fraction of their effectiveness.

Affects: Number of successful attacksAffected by: Systems maintenance

18

Figure 3.4.4.1.2.7 Relationship between company variables

The arrows go in the direction of the first variable affecting the second. For example, productivity is affected by morale and hindrance of security, but affects income.

3.4.4.1.3 Company Variables, ControllableThese are the numbers that the player can directly control that affect the company globally.

3.4.4.1.3.1 User TrainingThis is a number in the form of dollars spent that reflects how much the player has invested in educating the company’s employees. Obviously, it is the prime factor in deciding the user expertise.

Size

Systems Status

PrestigeUser Expertise

Productivity

Morale

Income

Hindrance of Security

Frequency of Attacks

Costs

19

3.4.4.1.3.2 Systems Maintenance This is a number in the form of dollars spent that reflects how much the player has invested in maintaining the network. The larger the network and the higher the number of countermeasures, the more it will cost to maintain. This is the prime factor in deciding the Systems Status.

3.4.5 Higher Level DesignThis section describes the high-level design of the game including classes and variables.

3.4.5.1 Game Engine StructureThis section describes how the game’s backend engine works and its components.

3.4.5.1.1 Engine CompositionThe engine, right now, is composed of the BackEnd class. The reason for differentiating between the two is that the engine would encompass the graphical side of the game (such as updating onscreen graphics) and the BackEnd takes care of all the number crunching.

The BackEnd class member variables and functions:

Company company: this is the company that is currently in play.

Timer timer: The game clock used to calculate intervals between events.

int attacksID: each time an attack is generated, this number is assigned to it and incremented.

void GameCycle (float deltaTime): All the normal events, such as updating graphics, checking input, and calculating the money the company makes, is done in this function. The game’s main function will run in an infinite while loop, with each iteration calling GameCycle. The variable that is passed in, deltaTime, will tell GameCycle how much time has passed so that it can perform calculations accordingly.

3.4.5.1.2 The Game CycleAlthough the GameCycle seems to be similar in function to what one might expect from a main function, the choice was made to write it as its own function to be called by main so that event-handling and message-passing can be done outside the gamecycle.

The GameCycle runs every interval. In this interval:

An attack is maybe generated The list of attacks is iterated through, and each attack executes. The money generated by the company’s network is calculated any other updates or calculations are done

20

3.4.5.2 How Attacks WorkThis section describes how attacks work.

3.4.5.2.1 Attack ClassAttack is a class derived from the base class, Object.

These are the member variables:int attackClass: the seven or so attacks are divided into classes…for example, viruses and worms are in class 0.

int attackStrength: this is the strength of the attack, from 1-100, used in the calculating if the attack is effective.

int attackStage: attacks happen in stages. The first stage is Prevention, before the attack actually hits the network. The second stage is Detection. The attack is in the network but still has the ability to be detected and deleted. If the attack doesn’t die in this stage, it causes damage and remains in the detection stage for the next gamecycle (in which the listOfAttacks is executed again).

int damageCausedSoFar: the amount of damage, in monetary values (i.e. $500), that the attack is causing upon the network, or an individual computer. In the income calculation stage, the amount of damage caused by successful attacks is subtracted from the amount of money that the computer/network is supposed to have generated.

int attackID: A number to identify this particular attack with.

string attackType: “VIRUS”, “WORM” “SOCIALENGINEERING” etc.

string attackName: Just some name randomly generated by the game, like “Killer Virus 2.6” or “Nimda v.602301”

Company* company – the company that the virus is attacking. Obviously, there is only one company in the game—this just points to the company to be able to access its variables.

Computer* computer – The computer that is being attacked.

virtual int PerformAttack() { }- This is the function that calculates if an attack is successful or not. It is virtual because it is implemented different for each particular attack. The int that it returns indicates if it was successful or not (0 = no, 1 = yes. -1 indicates an error)

21

3.4.5.2.2 The Life of an AttackFirst an attack is generated by the random generator—which happens at a random interval of time. Upon generation, the following member variables are set: attackClass, attackStrength, attackStage, attackID, attackType, attackName, and company.

When the gamecycle runs, the listOfAttacks associated with the network is executed. All the attacks are in a linked list (since they are based of the Object class), and this list is iterated through.

3.4.5.2.2.1 Attack Prevention StageWhen an attack is first generated, it is in attackStage = 1, which is the Prevention stage. So the attack goes against the preventive devices of the network. If it succeeds the roll, then its attackStage is changed to 2, the detection stage. It remains in the attack list for the next gamecycle. If it dies at stage 1, then it is just deleted from the game and not recorded.

3.4.5.2.2.2 Attack Detection StageIf a stage is in attackStage = 2, then when it is executed, it goes up against the detective devices of the network. If it dies, then the attack is logged and deleted from the game. If it succeeds the roll, then it causes some damage. A random number of computers or servers are damaged, hindering their money producing ability. The attack will still remain in the Detection stage, where the next gamecycle it has a chance of being detected or causing more damage.

3.4.5.2.2.3 Attack Damage StageAt this point, there are different things that can happen. Maybe the attack will terminate after a set number of turns in the system. Maybe the attack, like Social Engineering, will spawn another attack, like a Password Cracking attack. This is why each specific attack is derived from the Attack class. There is also the chance that the game will give the player a subtle notice that his network is damaged. For example, the user will be told that people are experiencing slowdown, and the user will have to install better virus detectors to actually find what’s causing the damage.

3.4.5.2.2.4 Relation Between Attacks and DefensesAs is shown in the “Included Attacks” section, the success of each attack at each particular stage is determined by what defenses the computer is equipped with. The strengths of these defenses are weighted—for example, the computer’s prevention rating against Social Engineering might be made up of 80% Expertise and 20% Access Control. Where are the relevant defenses and their weights determined? They are hardcoded in each attack’s performAttack function. The defenses and their weights that an attack has to consider will be constant throughout the game (i.e. a Virus will ALWAYS have to deal with antiviral software at the detection stage).

22

3.4.5.2.3 Included AttacksThe following is a description of the attacks that will be included in the project implementation.

3.4.5.2.3.1 VirusA virus is simply a malicious piece of code that can be introduced into a system by an unauthorized user or program.

Prevention Stage:Expertise, Antivirus, Firewall, Access ControlDetection State:Antivirus

3.4.5.2.3.2 WormSimilar to a virus, a worm seeks to replicate itself as much as possible and causes system slowdown.

Prevention Stage:Expertise, Firewall, AntivirusDetection Stage:Antivirus

3.4.5.2.3.3 Social EngineeringThe least technical attack yet the most common, social engineering attempts to win passwords and access by human contact (such as an unauthorized person pretending to be an admin who needs an employee’s password)

Prevention Stage:Expertise, Access ControlDetection Stage:NoneOther notes:Don’t know if this will cause damage in itself. But it may spawn other attacks, like Password Access.

23

3.4.5.2.3.4 Physical AccessSomeone with physical access to the company’s systems can cause all sorts of damage, whether it be installing physical surveillance devices on machines, or just putting a cap through the hard drive.

Prevention Stage:User expertise, biometrics, guardsDetection Stage:User expertiseOther Notes:May cause damage in a one-time manner, or may spawn other attacks, like Eavesdropping and Password access.

3.4.5.2.3.5 EavesdroppingEavesdropping occurs when an unauthorized person intercepts network traffic and deciphers the contents.

Prevention Stage:CryptographyDetection Stage:User Expertise(?)Other Notes:May cause damage in a one-time manner, or may spawn Password Access attacks.

3.4.5.2.3.6 Password AccessWhen an unauthorized person steals an employee’s password, all kinds of havoc can be wreaked on a system.

Prevention Stage:User Expertise, Strong password policiesDetection Stage:User Expertise

3.4.5.2.3.7 Denial of Service An attacker can clog the company’s Internet availability by launching a large number of accesses, such that the server crashes.

Prevention Stage:Detection Stage:Pretty obvious to detect.

24

3.4.5.3 DefensesThis section discusses how the defenses work.

Defenses have a similar class structure to attacks. One of the main differences is that whereas each attack is attached to a computer, some defenses are global, such as cryptography and user expertise.

3.4.5.3.1 The Defense ClassDefense is derived from the class Object. Each entity in the network has a list of defenses.

Member variables of defenses:

int defenseID: A number to identify this defense mechanism.

int cost: How much this defense costs to purchase

int level: The level the strength of this defense.

string defenseType: “FIREWALL”, etc.

string defenseName: The brand name of the defense, “Horton Antivirus 6.0”

Company company: The company that owns this defense.

Computer computer: The computer that this defense is attached to.

3.4.5.3.2 Included DefensesThis section describes the defenses that are included in the game.

3.4.5.3.2.1 AntivirusThis is software that both prevents and detects virus behavior in software. It can be installed on servers and workstations.

3.4.5.3.2.2 FirewallFirewalls serve as filters to control incoming and outgoing traffic, thereby limiting the possibility for attacks and malicious programs to enter the network and compromise integrity.

3.4.5.3.2.3 Access ControlThis is a set of controls that the server uses to determine access privileges of users and groups based on their authorization.

25

3.4.5.3.2.4 Biometrics/GuardsA network can be compromised by physical access to the actual workstations. Guards and biometrics help prevent unauthorized persons from entering the company and tinkering around with unattended workstations.

3.4.5.3.2.5 CryptographyCryptography obfuscates raw data so that it cannot be read in transfer. Also provides such services as digital signatures and non-repudiation to ensure integrity of transactions. Cryptography is a global defense.

3.4.5.3.2.6 User ExpertiseThis is a term to represent all the training, knowledge, and discipline the average employee in the company has. Most vulnerabilities of a network are due to human error, such as writing a password on a visible Post-it note or not knowing how to turn on a program’s security features. User expertise is the first line in preventing attacks.

3.4.5.3.2.7 BackupsWhen data loss or corruption occurs, backups help reduce the total damage done to the company by allowing the administrator to recover the relevant information.

3.4.5.3.2.8 Redundant SystemsThese are systems in parallel to the main systems in the network that can defend against system failure caused by attacks or other disasters.

3.4.5.3.3 How Defenses DefendThe defenses installed on a computer give it a rating in a respective category. As mentioned previously, the attack process is done by each attack’s PerformAttack member function. When this function executes, it compares the defenses against the attack’s strength and determines the winner.

3.4.5.4 The NetworkThe network is composed of a list of Servers, Computers, and Routers, which are derived from the Object class. The reason for differentiating between servers and computers are that both handle attacks differently.

26

3.4.5.4.1 The ComputerThe member variables are:

int compID: - the ID of the computer

Attack* listofAttacks – the list of attacks that the computer is under attack by.

Company* company – the company that the computer belongs to.

int currentMoneyMakingRate – How much money this computer currently brings in per cycle. Note that this is just another way of saying how well the computer performs. The more its performance is negatively affected by attacks, the less money it brings in.

int maxMoneyMakingRate – How much money this computer would make if it weren’t under attack.

3.4.5.4.2 Upgrading the NetworkThe network will grow on its own depending on how well the player is doing. The player will not be able to increase the size of the network manually, to reflect the fact that the player is in the role of network administrator and not business manager.

3.4.5.5 Economic ModelMoney is made when a network is running successfully.

Every gamecycle, the game (this is still under discussion) runs through a list of all the computers on the network. Each computer has a maximum number of dollars it earns per gamecycle. If a computer is affected by an attack, its performance will drop, and this is reflected by a reduced number of dollars it will earn per gamecycle. The total number of dollars earned per gamecycle will be what all the computers earned in that gamecycle.

The player earns money at some set interval. For example, quarterly or bi-annually (in game years).

3.4.6 MultimediaThis section discusses the style and implementation of graphics and sound into CYBER Sim

27

3.4.6.1 GraphicsThis sub-section discusses the approach was taken in developing the visual presentation of CYBER Sim.

Due to the team’s limited artistic skills, inexperience in graphical programming, and the time limitations inherent in the project, the goal is to find a graphical solution that is, in order of priority:

1. Easy to learn2. Easy to implement3. Attractive

The solutions presented in this section are both meant to be realistic and idealistic. CYBER Sim’s graphical style and complexity will be adjusted according to the time and resources available at the time that the graphics are being developed.

3.4.6.1.1 Graphical User InterfaceThis sub-section discusses how the goals in creating the GUI for CYBER Sim.

3.4.6.1.1.1 GUI Look-And-FeelSince CYBER Sim is a Windows application, the most obvious solution was to furnish CYBER Sim’s menus and screens with the Windows flavor of fonts, lines, and boxes.

3.4.6.1.1.2 GUI ImplementationTo implement the GUI, the DirectX API was planned to be used.

The DirectX API is the standard in programming the graphics for Microsoft Windows applications. The DirectX Software Development Kit (SDK) is based on Microsoft’s graphical object-oriented development environment and allows developers to use prepackaged routines that are part of Microsoft Foundation Class Library, a collection of classes written in C++ that include GUI elements such as windows, scroll bars, and menus. An example of code used to create a Window class is given in the Appendix

3.4.6.1.2 Graphical Perspective of Network Topology Screen This section discusses how the network topology screen (3.2.3.2.6) was planned to be created.

To remind the reader, the network topology screen allows the player to view the layout of his/her network in a 2D schematic view.

28

3.4.6.1.2.1 Network Topology Screen Look-And-FeelThe look-and-feel of this screen was planned to be of the similar color scheme and style of the GUI (3.4.6.1.1).

The icons used to represent the various system components shall be attractive, organic to the look-and-feel, and intuitive (i.e. a firewall looks like a firewall).

Fig 3.4.6.1.2.1 A sample topology screen from CyberProtect ™

The above screen represents a possible implementation of the Network Topology look-and-feel.

29

3.4.6.1.2.2 Network Topology Screen Graphical ImplementationTo implement the network topology screen, the DirectX API will be used.

The implementation of this screen will follow closely to the implementation of the GUI (3.2.7.1.3.2), since both are meant to meld seamlessly into each other.

3.4.6.1.3 Graphical Perspective of Office ScreenThis subsection discusses how the office screen (3.2.3.2.7) will be created.

To remind the reader, the office screen allows the player to view the network at the “human” level.

3.4.6.1.3.1 Office Screen Look-and-FeelThe office screen was planned to have a decidedly different look from the rest of CYBER Sim. Although it will be anchored in the GUI, the office screen would be rendered in an isometric 3D perspective.

Fig 3.4.6.1.3.1 – Sample screen from The Sims™

The above screen from the Sims™ is similar in spirit to what the office screen was planned resemble. As mentioned in the preface to the graphics subsection, complexity of graphics would have to be traded off in favor of ease of implementation.

30

3.4.6.1.3.2 Graphical Implementation of Office ScreenOpenGL shall be used to implement the office screen.

The programming for the office screen would be non-trivial. Although some features of modern 3D engines will not be necessary, such as a physics model, the artistic design of human characters and furniture as well as their animation would be difficult.

The features of OpenGL that will be necessary to implement in order to make the Office View attractive and useful were:

Texture Mapping – 3D shapes are relatively easy to create using OpenGL. But to make them look realistic, they must be given texture. For example a sphere can have an image of a face mapped onto it to make it look like a realistic head.

Fig 3.4.6.1.3.2 Texture mapped cube. On the left is a normal cube. On the right is a cube with a wooden crate image mapped onto it. Image courtesy of NeHe OpenGL Tutorial

Picking – The Office View will allow the user to click on objects to query for information. This requires special OpenGL programming to detect the cursor collision with the 3D objects, i.e. deciding which 3D object the user wants to select

Perspective Rotation – Since the view is isometric, objects will be inadvertently hidden from sight. The option to allow the user to rotate his/her perspective will be necessary.

31

3.4.6.2 Music and SoundThis sub-section discusses the approach that was planned for developing the audio presentation of CYBER Sim.

Due to the team’s limited musical skills and the time limitations inherent in the project, the goal was to find an audio solution that is, in order of priority:

1. Easy to implement and create2. Aurally attractive

The solutions presented in this section are both meant to be realistic and idealistic. CYBER Sim’s audio style and complexity will be adjusted according to the time and resources available at the time that the audio is being developed.

3.4.6.2.1 MusicSince the team’s time and resources to compose music was limited, the best choice was to let the player choose his/her own background music.

This would be done by using the DirectX API to play a player-selected MP3 file. The player would have the option to change the MP3 file in-game.

3.4.6.2.2 SoundThe sounds in CYBER Sim would serve two main purposes:

Audio feedback to player actions – A “click” sound will play when the player clicks a button example.

Alerts – this includes alarms and beeps to notify the player of game events.

The sound would be composed of short clips of no more than two-seconds each.

Sounds for CYBER Sim will be selected from free sound libraries and be implemented through the DirectX API.

32

3.5 Implementation Process DescriptionThis section describes the implementation process and the materials used, as well as how the implementation process could be improved.

3.5.1 Implementing the Back EndIt was planned to implement the backend first, which would include all the logic and numbers behind the simulation of the game. This phase would not be completed until the simulation was balanced and bug-free.

3.5.2 Implementing the GUITo implement the GUI, a graphical engine would have been created which would define how the graphical elements are displayed, updated, and maintained. Then the graphical elements would have been created in a modeling program like MilkShape 3D.

3.5.3 Integrating Back End and GUIWith the GUI and backend both implemented, the final step would be to write code that would relate the simulation output to the graphical elements displayed on screen.

3.5.4 Improvements to Implementation ProcessIt is difficult to know how the implementation process could have been improved since the group did not go much further than the design process. The parts that were implemented in the backend, such as the resource file manager, could have been done with a more top-down perspective in mind.

3.6 End-Product Testing DescriptionThis section details the approach for testing the project including how and where the testing will be performed, what will be tested, how testing accuracy will be determined, what information is required on the forms that will be used to record the test results, and who will do the testing and how the testing will be verified.

Since this semester the group did not have a completed game to test, this section is written in the future tense to reflect what process a future group should follow to test the game.

33

3.6.1.1 How and where will the testing be performed?Anyone who wishes to test the game will have access through a website to one or more files that will install the game on a computer of their choice.  They may then test the game, write down their results, and remove it from their computer.

3.6.1.2 Exactly what will be tested?The following issues will be tested:

Able to install Inputs and outputs function properly Cosmetics Accuracy and usefulness of documentation User friendliness of GUI Functionality of all GUI components

3.6.1.3 How will testing accuracy be determined?The accuracy of testing will be determined by a number of things:

The number of tests run

The more tests that are run the more likely any errors made during development will be caught and fixed. These errors can include such things as memory leaks or run-time crashes that are not immediately evident while coding.

Similarity between comments

If different people give similar comments during testing then the testing process is likely more accurate than if different people give opposing comments.

Results of automated testing

The game will be tested extensively through automated scripts. These scripts will be designed to test every line of code to see if given inputs produce the desired output.

34

3.6.1.4 What information is required on the forms that will be used to record the test results?

The following information is required on the forms that will be used to record the test results:

Who performed the test Date and time of the test Results of the test Any pertinent comments

The results of the test will consist of comments on the items in the “Exactly what will be tested?” section.

3.6.1.5 Who will do the testing and how will it be verified?The following are the groups that should do the testing and how the testing should be verified:

Group Members – Make sure basic functionality works, check program against a basic set of requirements such as: installs properly, simple input and output work, no viruses, uninstalls properly, documentation is up to date, etc.

Outsiders to the Group – will try to “break” the game, and report their “success” Faculty Advisor – Will be able to function as a group member or an outsider to the

group because of only slight involvement with the development of the project. Automated Testing – Scripts will be written to test every line of code to see if given

inputs produce the desired output.

3.7 Project End ResultsThis section describes the final status of each major component of the main product here, as well as any significant accomplishments or research activities not described elsewhere.

3.7.1 Detailed Design DocumentThis document describes all the main classes and member variables, the logic, and the design principles behind Cyber SIM. It is complete although may need revision during the implementation process, if unforeseeable problems arise.

3.7.2 Research Paper on Network SecurityThis document is a reference for the educational material that will be included in the CYBER Sim game. It is a complete and thorough examination of the basic network security theory and terminology.

3.7.3 Code and Documentation for Resource File Manager The RFM and documentation is complete and should be easily integrated into the implemented game

35

3.7.4 InfrastructureThe version control system, mailing list, and discussion group are fully set-up and ready for use.

36

4 Resources and ScheduleThere are three parts to each of the following components. These consist of the original estimate, the revised estimate, and the final results. Also, in each case, the original estimate, the revised estimate, and final values shall be compared and the reason(s) for the difference shall be explained.

4.1 Resource RequirementsThree separate components make up the estimated resource requirements; these include: personnel effort requirements (Table 4.1.1a-c), other resource requirements (Table 4.1.2a-c), and financial requirements (Table 4.1.3a-c).

4.1.1 Personnel EffortThis section indicates the personnel effort estimated by each member of the group. This effort is based on the number of hours a member spends on the planning and programming of the project. These estimates are based on the projected effort required to perform the task correctly. Table 4.1.1a shows the original individual efforts in hours.

Table 4.1.1a – Original Personnel Effort Requirements in hoursPersonnel Name Project

PlanProject Poster

Design Report

Research Progra-mming

Totals

Straw, Adam 4 6 5 5 90 110Applegate, Ryan 4 5 5 5 90 109Khattak, Saddam 5 5 6 5 90 111Nguyen, Dan 4 5 6 5 90 111

Table 4.1.1b shows the revised personnel effort requirement. The design and research was revised and the hours increased to give more time than originally estimated. The poster hours were also reduced, because it was expected the total time needed was originally overestimated.

Table 4.1.1b – Revised Personnel Effort Requirements in hoursPersonnel Name Project

PlanProject Poster

Design Report

Research Progra-mming

Totals

Straw, Adam 5 2 10 10 83 110Applegate, Ryan 4 2 10 10 83 109Khattak, Saddam 5 2 10 10 84 111Nguyen, Dan 4 2 10 10 85 111

Table 4.1.1c shows the actual personnel effort requirement. The hours for design were closely estimated, however the hours for research were severely underestimated. There had to be additional research done before the programming could be started to give us direction with the implementation. The poster hours were underestimated in the original revision, because there were formatting issues when creating the PowerPoint slide.

37

Table 4.1.1c – Actual Personnel Effort Requirements in hoursPersonnel Name Project

PlanProject Poster

Design Report

Research Progra-mming

Totals

Straw, Adam 5 7 10 51 5 78Applegate, Ryan 4 8 9 38 18 77Khattak, Saddam 5 9 3 14 31 62Nguyen, Dan 4 7 10 52 5 78

4.1.2 Other Resource RequirementsThis component identifies the other resources aside from financial, such as materials and other important parts/categories that are required to conduct the project. Table 4.1.2a shows the number of hours the whole team used to complete the task and also the cost of each of the items purchased.

Table 4.1.2a – Original Other Resource RequirementsItem Team Hours Cost

Printing of project poster 21 $45Development Software 0 $2003D Engine 4 UndeterminedInstallation Software 4 $20Totals 29 $265+

Table 4.1.2b shows the revised version of the resource requirements. The development software finally decided upon was acquired for free, reducing the cost originally estimated. Also, there was more time allotted for the team hours on the 3D engine and the development software.

Table 4.1.2b – Revised Other Resource RequirementsItem Team Hours Cost

Printing of project poster 21 $48Development Software 50 $03D Engine 30 UndeterminedInstallation Software 4 $20Totals 105 $68+

Table 4.1.2c shows the actual resource requirements that were needed for the project. The development software hours were lower than the revised resource requirements because there was less time spent coding than expected. There was more time spent actually designing how to implement the project. Also, it was decided that a 3D engine would not be purchased so there would be no cost applied towards it.

38

Table 4.1.2c – Actual Other Resource RequirementsItem Team Hours Cost

Printing of project poster 21 $48Development Software 30 $03D Engine 20 $0Installation Software 0 $0Totals 71 $48

4.1.3 Estimated Project CostsThe third component involves the financial resources required to conduct the project. . The plan includes a cost estimate for the project. The labor costs are included to estimate the costs in case the group members are getting paid for the number of hours they spend on the project. Table 4.1.3a shows the original estimated project costs.

Table 4.1.3a – Original Estimated Project CostsItem W/O Labor With LaborDevelopment Material $40 $40Subtotal $40 $40Development Software Macromedia Studio $200 $200Subtotal $200 $200Labor at $10.00 per hour Straw, Adam $0 $450 Applegate, Ryan $0 $490 Khattak, Saddam $0 $490 Nguyen, Dan $0 $450Subtotal $0 $1880Total $240 $2120

Table 4.1.3b shows the revised estimated project costs. The development software and material was acquired at not cost. Therefore, the revised table shows a two hundred and forty dollar decrease in the total cost for the project.

39

Table 4.1.3b – Revised Estimated Project CostsItem W/O Labor With LaborDevelopment Material $0 $0Subtotal $0 $0Development Software Macromedia Studio $0 $0Subtotal $0 $0Labor at $10.00 per hour Straw, Adam $0 $450 Applegate, Ryan $0 $490 Khattak, Saddam $0 $490 Nguyen, Dan $0 $450Subtotal $0 $1880Total $0 $1880

Table 4.1.3c shows the actual project costs. The number of hours each member spent on the project was more than originally expected. Thus, the actual table reflects this increase in hours by the amount of labor charged for each member. This increases the revised project cost total by two hundred and forty dollars.

Table 4.1.3c – Actual Project CostsItem W/O Labor With LaborDevelopment Material $0 $0Subtotal $0 $0Development Software Macromedia Studio $0 $0Subtotal $0 $0Labor at $10.00 per hour Straw, Adam $0 $780 Applegate, Ryan $0 $770 Khattak, Saddam $0 $620 Nguyen, Dan $0 $780Subtotal $0 $1880Total $240 $2120

40

4.2 SchedulesThe following contains the schedule for the project including tasks versus project calendar chart and the project deliverables chart.

4.2.1 Tasks Versus Project Calendar ChartThis schedule shows the tasks and subtasks versus the project calendar. The schedule has been revised to accommodate the changes in the project deliverables. This chart contains two lines: one for the revised schedule and one for the actual schedule that occurred.

The revised schedule has some additions in relation to the deliverables. Some more subtasks have been added in each task in order to improve the effectiveness of the project. Some major changes devised in the schedule and deliverables are:

Additional game design subtaskso Develop functional specificationso Develop high-level game designo Review functional specificationso Incorporate feedback into functional specifications

Inclusion of unit testing and integration testingo Review modular codeo Test component modules to product specificationso Identify anomalies to product specificationso Modify codeo Re-test modified codeo Unit testing completeo Test module integrationo Identify anomalies to specificationso Modify codeo Re-test modified codeo Integration testing complete

Inclusion of additional documentation subtaskso Develop design guidelineso Develop help systemo Develop research documentationo Incorporate research documentationo Review all developer documentationo Documentation complete

41

Addition of Pilot for testingo Identify test groupo Develop software delivery mechanismo Install/deploy softwareo Obtain user feedbacko Evaluate testing informationo Pilot complete

Addition of deployment phaseo Determine final deployment strategyo Develop deployment methodologyo Secure deployment resourceso Train support staffo Deploy softwareo Deployment complete

Addition of post-implementation review phaseo Document lessons learnedo Distribute to team memberso Create software maintenance teamo Post implementation review complete

This schedule covers all the processes of the project creation and implementation. Starting from the problem definition through the technology selection and building game design. Other than the above-mentioned tasks, it also includes the development process and testing requirement schedules.

The difference between the revised schedule and the actual schedule is not very significant. The project is on schedule and the initial phases of the project have been completed, including problem definition and technology selection. Currently, the project code has been implemented and tested by the programmers.

42

Insert chart here

43

Insert chart here

44

4.2.2 Project Deliverables ChartThis chart includes the schedules and the deadlines for the project deliverables for previous and current semester only. The future deliverables that are required to complete the whole project has not been included due to possible change in development team and eventually project deliverables according to the new team.

This chart provides scheduling information about the project plan, design report, user-documentation and final report. It also covers the code and documentation deliverables accomplishing the goals for this semester. The additional deliverables include:

Infrastructure implementation guideline for the whole project Infrastructure documentation Detailed design and high-level project design Resource file manager implementation Resource file manager documentation Network security research documentation

45

Insert chart here

46

5 Closure MaterialsThe following contains the closure materials including a project evaluation, commercialization, recommendation for additional work, lessons learned, risk and risk management, project team management, closing summary, references, and appendices sections.

5.1 Project EvaluationIn the original project and design plan, the final deliverable would be a completed game. However, those goals in retrospect were too ambitious. Throughout the year while planning out the design of CYBER Sim, it became apparent that it would be infeasible to research the background behind the game, conceptualize a full design, and then implement that design into a professional game. The first two steps would be a project in of themselves, so in the second semester the decision was made to change the project goals to delivering design documents for CYBER Sim that could later be implemented by programmers in the future.

So, with respect to the original goals and milestones, the group failed to meet them.

However, the revised goals are also non-trivial and worthwhile goals to meet. The documents that have been written are as complete as possible and shall be essential to a future group interested in implementing the project.

5.2 CommercializationThe commercialization of the delivered design documents for CYBER Sim is neither feasible nor desirable.

It is not feasible because there is no precedent for selling a design document as one would a screenplay. The market simply does not exist.

It is not desirable because the primary intention is for CYBER Sim to become a full-fledged game. Few programmers at the college level would be willing to pay to be able to implement someone else’s creative work. More likely, they would want to devote their time and resources into designing their own game rather than pay a fee. This would drain important time and resources from implementation work, thus delaying the implementation of CYBER Sim.

The commercialization of the game itself is possible, depending on the quality and professionalism of graphics produced. Since it was meant as an educational game, commercialization of CYBER Sim is not a priority.

47

5.3 Recommendation for Additional WorkFrom the documents that have been created, the next steps should be:

1. Reviewing and revising the document – The documents that have been created are a comprehensive starting point, but before attempting to implement these plans, a future group should review the document for comprehension and revise it as necessary to the needs of their group.

2. Implementing the engine and class structures – The design documents provide all the high-level information needed to code the backend of the game.

3. Create graphics – Although the design documents provide resources on how to implement graphics and how graphics should be incorporated into the game, how the graphics will be composed and their exact appearance should wholly be a creative decision by the future group.

4. Testing – After the game has been programmed, the future group should rigorously test the program for bugs.

5. Distribution and commercialization – Since this game is meant to be an educational tool, the future group, after the program has been finalized, should then distribute the product to its intended users.

5.4 Lessons LearnedThis section describes the lessons the group has learned in the senior design process.

5.4.1 SuccessesThe main accomplishment of this project is creating a strong foundation from which a game about network security can be started. This is a worthy accomplishment considering there are almost no playable games with this topical matter.

This foundation includes a:

- Detailed design document: a high-level description of the design of CYBER Sim that serves as a walk-through for implementing the game.

- Research paper on network security: A document describing the theory of network security and how it has informed the design of CYBER Sim. Since CYBER Sim was meant to be an educational game, the content of this document will be incorporated into the game (for example, the descriptions of each network security component.)

- Code and documentation for Resource File Manager - The RFM is a mechanism that allows a game to access library and graphic files. The group has produced compiled code and documentation on how to use it.

5.4.2 FailuresThe main failure of this project is not having an implemented game or much working code. There were also failures in not planning enough time and resources for creating the design of the game.

48

5.4.3 Technical Knowledge GainedThe group learned about the programming and code specific to a game-type program, issues in security as well as technology in information assurance, graphical programming.

5.4.4 Non-technical Knowledge GainedTime and group management – The group already knows what it means to manage personal time and schedules, but it has gained more experience in how to allocate time and resources in a large project such as CYBER Sim.

5.4.5 Different ApproachesIn retrospect, the project could have considered these different approaches:

Spending less time on the technical aspects of the project and instead put more of a group effort in the design of the game.

Taking more of a top-down than bottom-up in programming.

Spending more time consulting with programmers who were experienced in game programming.

5.5 Risk and Risk ManagementThis section discusses the risks that were anticipated, the risks that were actually faced, how these risks were managed, and how risk management was changed.

5.5.1 Anticipated Potential Risks and Planned Management Thereof Loss of member – If a group member had to unexpectedly quit the group, it would require revising expectations and goals for the end-product.

Excessive difficulty in coding components – If a section of the code was particularly difficult to complete and was causing a bottleneck, time and attention would be focused on another part of the project and the problem would be later returned to.

5.5.2 Anticipated Risks Encountered and Success in Management Thereof

Excessive difficulty in coding components – There was particular trouble with coding the resource management system. The group allocated two members and three weeks to finish it but the attempt was not completely successful.

49

5.5.3 Unanticipated Risks Encountered and Success in Management Thereof

Difficulty in deciding design – Deciding how to structure the game was surprisingly difficult and created a bottleneck since it was difficult to code before a high level design was completed. In retrospect, more meetings could have been devoted to fleshing out the design.

Difficulty in learning Visual .NET compiler – There were problems with getting code that was originally designed for Visual C++ 6.0 to compile in .NET. The group consulted with online forums on how to fix specific bugs and had limited success, due to the reluctance or lack of knowledge from online users.

5.5.4 Resultant Changes in Risk Management Made Because of Encountered Unanticipated Risks

There was an increased awareness in the importance of group communication so that risks would be recognized sooner and could be dealt with in a timely manner.

5.6 Project Team ManagementThis component has three distinct elements: (1) client information, (2) faculty advisor information, and (3) student team information.

5.6.1 Client Contact InformationThis section contains contact information for the client.

Table 5.6.1 Client Contact InformationClient Name ISU Information Assurance Center Contact Name Dr. Doug JacobsonMailing Address 2419 Coover Hall

Ames, IA 5001-3060Telephone 515-294-8307Fax 515-294-8432Email dougj@iastate.edu

5.6.2 Faculty Advisor Contact InformationThis section contains contact information for the faculty advisor.

50

Table 5.6.2 Faculty Advisor Contact InformationName Dr. Doug JacobsonOffice/Mailing Address 2419 Coover Hall

Ames, IA 5001-3060Telephone 515-294-8307Fax 515-294-8432Email dougj@iastate.edu

5.6.3 Team Members Contact InformationThis section contains the team’s contact information.

Table 5.6.3a Team Leader Contact InformationName Adam Straw (team leader)Major Computer EngineeringMailing Address 729 NE 5th St. #105

Ankeny, IA 50021Telephone 515-971-6713Email astraw@iastate.edu

Table 5.6.3b Communication Coordinator Contact InformationName Ryan Applegate (communication coordinator)Major Computer EngineeringMailing Address 6325 Fredericksen Ct.

Ames, IA 50010Telephone 515-572-7853Email rapple@iastate.edu

Table 5.6.3c Team Member Contact InformationName Saddam KhattakMajor Computer EngineeringMailing Address 246 N Hyland Ave #2

Ames, IA 50014Telephone 515-292-3701Email saddam@iastate.edu

Table 5.6.3d Team Member Contact InformationName Dan NguyenMajor Computer Engineering, JournalismMailing Address 3218A Roberts Fairchild

Ames, IA 50013Telephone 515-572-5839Email dnguyen@iastate.edu

51

5.7 Closing SummaryThe group believes, after two semesters of working on it, that CYBER Sim is a worthwhile project and it is the group’s desire to see it implemented.

The group did not accomplish its original goal, which was to have a fully realized and implemented game. This is of course a disappointment, as all of the group’s members are accustomed to being in group projects in which the result is an implemented program.

On the other hand, this is the most difficult and largest software project that any of the group members have ever attempted. Not only was the group inexperienced with a project of this scope, but the subject matter of this game—network security—was difficult to adapt into a game setting, which is why there are very few games dealing with this subject matter. This resulted in the group spending a longer time than anticipated in the planning and designing stages.

So the disappointment of not completing the original goals is mitigated by the realization that it would’ve been nearly impossible to do what the group originally planed to do with the time and resources available. Everything would have had to go correctly, and as the case is in virtually every project, everything did not go correctly.

With the revised and limited goals, though, the final product—design documentation—that has been produced is vital to the completion of this project, especially in the context of a university setting where programmers will not have the time to do research, design, and implementation within a reasonable period in their academic schedule.

With the documents that have been created, a programming group will have a foundation from which to implement a successful game. The group is proud of that and it hopes that a future group will be able to build on what the group has done.

52

5.8 ReferencesLinks to references used in this document.

5.8.1 Programming ReferencesLinks for programming or coding references used in this document.

5.8.1.1 Code DocumentationC++ Library Referencehttp://www.cplusplus.com/ref/#language

5.8.1.2 OpenGL WalkthroughsNeHe’s OpenGL Tutorialshttp://nehe.gamedev.net

5.8.2 Network Systems ReferencesLinks to network security references used in this document.

5.8.2.1 Network Guides and InformationParallel Technologies Basic Network Guidehttp://www.lpt.com/windowsnetworking/regusers/basics.htm

Whatis.com’s IT Glossaryhttp://whatis.techtarget.com/

About.com’s Guide to Computer Networkinghttp://compnetworking.about.com/index.htm?terms=network

5.8.2.2 Network Security InformationITPRC’s Network Security Linkshttp://www.itprc.com/security.htm

SecurityDogs.com – Info and Productshttp://www.securitydogs.com/

About.com’s Guide to Network Securityhttp://netsecurity.about.com/index.htm?terms=network

Windows NT Network Security: A Manager’s Guidehttp://www.ciac.org/ciac/documents/CIAC-2317_Windows_NT_Managers_Guide.pdf

53

5.8.2.3 Network Security Issues and Current EventsCybercrimes.nethttp://cybercrimes.net/

“CyberTerrorism – From Virtual Darkness”http://www.nici.org/Research/Pubs/98-5.htm

Position Papers for Workshop on Countering Cyber-Terrorismhttp://www.isi.edu/gost/cctws/positions.html

“Are Companies Prepared for CyberTerrorism?”http://www.cfo.com/article/1,5309,5988,00.html?f=related

5.8.2.4 Gaming Theory and IssuesGeneral Game Design Articles on GameDev.nethttp://www.gamedev.net/reference/list.asp?categoryid=23#40

Will Wright’s lecture to Terry Winnograd’s user interface class at Stanfordhttp://www.art.net/~hopkins/Don/simcity/WillWright.html

“Seductions of Sim: Policy as a Simulation Game” – The American Prospecthttp://www.prospect.org/print/V5/17/starr-p.html

“Making Sense of Software: Computer Games and Interactive Textuality” by Ted Friedmanhttp://www.duke.edu/~tlove/simcity.htm

“Creating a Great Design Document” – Game Developershttp://www.geocities.com/SiliconValley/Bay/2535/design_doc.html

“Techniques for Achieving Play Balance” – GameDev.nethttp://www.gamedev.net/reference/design/features/balance/

“Evolutionary Design” – GameDev.nethttp://www.gamedev.net/reference/design/features/evolution/default.asp

“Cyber Crime” – http://rrtd.nic.in/cyber_crime.htm

54

5.9 AppendicesThis section contains reference documents and figures pertinent to CYBER Sim.

5.9.1 APPENDIX A – Sample DirectX Code for GUI

// Developing a GUI Using C++ and DirectX// Source Listing 1// Window Class//Courtesy of Gamedev.net

class gui_window{public: gui_window(); // boring ~gui_window(); // boring virtual void init(void); // boring gui_window *getparent(void) { return(m_pParent); }

///////////// // section I: window management controls /////////////

int addwindow(gui_window *w); int removewindow(gui_window *w);

void show(void) { m_bIsShown = true; } void hide(void) { m_bIsShown = false; } bool isshown(void) { return(m_bIsShown); } void bringtotop(void); bool isactive(void); ///////////// // Section II: coordinates /////////////

void setpos(coord x1, coord y1); // boring void setsize(coord width, coord height); // boring

void screentoclient(coord &x, coord &y);

int virtxtopixels(coord virtx); // convert GUI units to actual pixels int virtytopixels(coord virty); // ditto

virtual gui_window *findchildatcoord(coord x, coord y, int flags = 0);

///////////// // Section III: Drawing Code /////////////

// renders this window + all children recursively int renderall(coord x, coord y, int drawme = 1);

A

gui_wincolor &getcurrentcolorset(void) { return(isactive() ? m_activecolors : m_inactivecolors); }

///////////// // Messaging stuff to be discussed in later Parts /////////////

int calcall(void);

virtual int wm_paint(coord x, coord y); virtual int wm_rendermouse(coord x, coord y); virtual int wm_lbuttondown(coord x, coord y); virtual int wm_lbuttonup(coord x, coord y); virtual int wm_ldrag(coord x, coord y); virtual int wm_lclick(coord x, coord y); virtual int wm_keydown(int key); virtual int wm_command(gui_window *win, int cmd, int param) { return(0); }; virtual int wm_cansize(coord x, coord y); virtual int wm_size(coord x, coord y, int cansize); virtual int wm_sizechanged(void) { return(0); } virtual int wm_update(int msdelta) { return(0); }

protected: virtual void copy(gui_window &r); // deep copies one window to another

gui_window *m_pParent; uti_pointerarray m_subwins; uti_rectangle m_position; // active and inactive colorsets gui_wincolor m_activecolor; gui_wincolor m_inactivecolor;

// window caption uti_string m_caption;};

B