Transportation Command
Firewall Modification Request System

Student Name

Individual Project
IS316 - Systems Analysis and Design
Professor: Erlan Burk
Park University
Fall II 2005

12 December 2005

Table of Contents

System Description 2-3 Functional Description 4-5 Data Dictionary 6-7 Context Level Diagram and Child Diagram 8-9 System Input, Output Forms, and Interfaces 10-14 Testing, Maintenance and Auditing 15-16

System Description

System Name
US Transportation Command Firewall Modification Request System (FMRS)

Type of System
FMRS is a Management Information System using a Microsoft Access Database and front end application. The system provides an avenue for customers to request firewall modifications and for the firewall maintenance team (Operation Information Security – OIS) to validate, track, and process requests in systematic fashion.

Key System Benefits * User friendly interface available to users at any time * Request tracking and history * Report generation of prior activity * Improved firewall manageability * Improved customer response time * Reduction in man hours spent duplicating and researching firewall maintenance efforts

Existing System
Currently there is no automated request or tracking system for firewall modifications and accountability. Requests are made via email to the OIS group email account and are processed from there. With the current process, the requests are subject to be accidentally deleted, read and forgotten about, or completed but with no follow up. Often there is a duplication of effort as well if there is no communication among members of the firewall team.

Interrelations/Interdependencies with other Systems
The FMRS does not contain interfaces that interact directly with the Transportation Command firewalls. All firewall modifications will be implemented manually; however the tracking of the modifications and user notification will be handled by FMRS. All FMRS users require only a workstation running Microsoft 2000 or better and will need a mapped connection to the FMRS server. The FMRS application itself requires a high-end desktop grade workstation only but needs adequate amount of space to store the database and archives. Microsoft 2000 Professional or Server software along with Microsoft Access is required as well.

System Organizational Environment
The Transportation Command is a logistics planning agency that manages air, land and sea transportation both in time of peace and in time of war. Their primary purpose is war fighter support. The IT management directorate is responsible for maintaining secure, reliable and available network and operations systems for the entire command. Firewalls are in place to protect all command resources including equipment, systems, and personnel. Proper maintenance and administration of these firewalls is paramount to the operations of the Transportation Command. The firewalls are maintained by a combination of both military and contract personnel.

Stakeholders: * Firewall Administrators * System Developers * Organizational Information System Administrators * IT Management Team * All Transportation Command personnel and war fighters abroad

Users: * Firewall Administrators (staff of 7) * Organization Information Systems Administrators (staff of 145)

Functional Description

System Functions
The Firewall Modification Request System (FMRS) will allow authorized users (system administrators) to electronically submit modification requests for the command’s firewalls. When systems, applications, or other tools are implemented or removed from the network, access control must be maintained and monitored. There are two main firewalls in the command managing multiple interfaces. The firewall administrators need a more efficient way of tracking and servicing requests from the 145+ administrators that continuously make requests for port access or access removal. FMRS will provide one point of entry for requests and also acts as a tracking system for who makes the requests, what changes were requested, and who made the firewall modifications. The system administrators will submit their requests through a locally developed Microsoft Access application. After they enter the required information and submit the request, the firewall administrators will have access to the request. Status buttons indicate where in the process the request is sitting. When a firewall administrator accesses the request, he or she will mark it as “in progress”, validate the request, make the necessary modifications in the firewalls, enter the firewall changes/rules made into the request record, and “close” the request. When a request is marked complete, an email will be automatically generated to notify the user that their request has been serviced. The firewall administrators can generate reports of requests in the system using any number of search parameters such as request=new, in progress, closed, by date, by firewall administrator, user, or information system name.

System Boundaries
The FMRS application will be hosted on an organizational application server (Microsoft 2000 Server) on a dedicated, protected drive. Access to the system will be limited to internal command personnel. Authorized users will be able to map to this drive. All other LAN users will not have permissions to see or access the application. Firewall administrators and management will have access to generate reports. Output will be through reports and automatically generated notification emails only.

System Interfaces External to the Organization
There are no interfaces with entities external to the organization.

System Interfaces Internal to the Organization
The application will be hosted on a server managed internally by command administrators. Authorized users and firewall administrators will have direct access to the system through drive mapping. Changes made to the firewall will be manually entered by firewall administrators in both the firewalls and FMRS. Interactions with FMRS will rely on LAN access and availability.

How System Relates to Organizational Mission
This system provides a reliable and structured procedure for firewall modification requests which are necessary for the smooth operations of the various logistics information systems within the command. A single point of reference for firewall maintenance reduces duplicate efforts and man hours wasted on researching validity of current rules and requests. This system will improve the commands overall mission of supporting logistics operations in time of peace and war.

How System Supports Organizational Decisions
Proper maintenance tracking provides easily accessible data on firewall operation efforts to aide in properly managing personnel, equipment, and other resource allocation. The effects of this system will allow management to be better informed when making decisions on manning and system upgrade efforts.

Information Processing Input Information * User data: name, phone, command section, email address * System data: information system needing firewall modification, port numbers, protocols, IP addresses

Process Definition * Request submission and creation * Status changes * Email generation * Report generation * Request closure and storage

Output information * Request history reports * Email notifications

CASE Tool Use for Development
Visible Analyst will be used to create the systems diagrams and to map out the processing of the system. The use of this tool will allow convenient and efficient creation of the internal system function layout and will make it easier to transfer the logic into Microsoft Access where the system will ultimately be built.

Data Dictionary and Entity Relationships

Data Dictionary

Data Element Name | Data Type | Size | Special Formatting | Definition | customer_firstname | A | 20 | none | Base element | customer_lastname | A | 30 | none | Base element | customer_userid | A | 8 | none | Base element | customer_email | AN | 50 | none | Base element | customer_officesymbol | AN | 8 | none | Base element | customer_phone | N | 14 | (###) ###-#### | Base element | requesting_system | A | 20 | none | Base element | port_number | N | 10 | none | Base element | protocol_name | A | 20 | none | Base element | source_IP_address | N | 15 | ###.###.###.### | Base element | destination_IP_address | N | 15 | ###.###.###.### | Base element | request_id | N | 8 | none | Auto-generated | rule_entered | A | 400 | none | Base element | fw_admin_userid | A | 8 | none | Base element | request_status | A | 10 | New
In Progress
Completed | (drop down menu) | date_entered | D | 7 | DDMMMYY | Auto-generated | date_closed | D | 7 | DDMMMYY | Auto-generated |

Legend:
A - alpha
AN - alpha-numeric
N - numeric
D - date
# - numbers

customer_record = customer_firstname + customer_lastname + customer_userid + customer_email + customer_phone

request_status = [new | in progress | complete]

request_record = customer_record + request_id + requesing_system + port_number + protocol_name + source_IP_address + destination_IP_address + date_entered + request_status

completed_request = request_record + customer_record + rule_entered + fw_admin_userid + request_status + date_closed

email_notification = customer_name + customer_userid + request_id + request_status + date_closed + fw_admin_userid

Data Flow Diagrams

Context Diagram

Level 0 Diagram

System Input, Output Forms, and Interfaces

Screen 1, the New Request Form, is the first user interface screen. Users enter their user identification number and select the “Submit New Request” button. The user ID used to query the customer database and pull the customers information. This information is used to populate the fields in the next screen, the Request Info screen.

Screen 2, the Request Info screen, displays the complete customer information and new request status. The fields allow the customer to make changes to their information as necessary. This form is where customers enter the information needed to make the necessary firewall modifications. The information submitted with this form is all a part of the request record and is included in the email that is generated and sent to the customer when the request is generated.

Screen 3, the Request Record, is an example of what the firewall administrators see when they log into the system. The request record contains all the information necessary to make the firewall changes. The firewall administrator uses this form to submit the rules that were added to the firewall, the name of the administrator that serviced the request, the date it was serviced, and to change the request status to “complete” or “in progress”.

Screen 4 is a sample report that management can generate for metrics purposes and to manage how efficiently the requests are being serviced.

This sample email is what the customers receive when they submit their requests into the system. The email is automatically generated and includes the information that the customer has submitted. The receipt of this email lets the customer know that their request has been submitted successfully.

Date: date_entered

Dear customer_firstname customer_lastname,

You’re firewall request has been submitted successfully and the firewall administration staff will service your request as quickly as possible. Here are the details of your request.

request_ID request_status requesting_system date_entered port_number protocol_name source_IP_address destination_IP_address

You will be notified when you’re request has been completed. If you have any questions you can contact the firewall administration staff at 555-1234.

This is an automatically generated email; please do not respond to this address.

Thank you.

The Transportation Command Firewall Administration Team

Testing, Maintenance and Auditing

Data Testing The Firewall Request Management System (FRMS) will undergo modular testing as each phase of the program is completed. The system analysts have adopted a top-down designing strategy. Documentation is maintained throughout the design and development process. Test data is used during the program testing phase to make sure the modules are working correctly. Each step of the program, from user access and input to resolution output and report generation are all tested using both valid and invalid data. Link testing is performed to ensure that the system interacts with the organization’s exchange servers correctly and that all interfaces have been properly configured.
Full system testing is performed with both test data and live data and the system users and operators are brought in to load test the system. Test plans will be created to include various scenario testing and checklists to make sure all components of the program are tested. These test plans will be performed by multiple system users and will include both valid and invalid data to help the users familiarize themselves with the system and offer avenues for suggestion and improvement. Data entry is accomplished through keyboard by users and data is also pulled from two different data stores. The information in the data store is valid because it is checked as it is entered into the system. The information entered by the users is validated against format and data constraints. Validating input data is done in the following way. First, each field is configured to accept a certain format. For example, a phone number must include the area code and be delimited by dashes. An email address must have an “@” symbol to be valid. Field length, range and reasonableness, valid data, and checking against stored data are all data checks that are performed during data entry into FRMS. When users enter data, it is automatically checked and an error message is displayed to users who have entered invalid data.

Maintenance

Minor system maintenance and upgrades are performed on a periodic or as-needed basis. Major maintenance and upgrade efforts such as modular redesigning and data structure redesigning are performed once a year. The users are polled to gather their comments, complaints, and suggestions regarding the system. This information is consolidated and analyzed to best determine how to accommodate the users’ needs. As the system grows and more users are authorized access to the system, considerations will need to be made on additional storage and processing capacity. As system modifications are made, the documentation will be upgraded accordingly to keep current. The FRMS will be housed on a low-grade Dell server with redundancy. Replication will be enabled between the primary and backup servers so that both maintain the most current data. Nightly incremental backups will be performed on the system as well as full backups each week. These backup files will be stored on magnetic tape devices in a secure location. In addition to the redundant server and backup configurations, the organization will keep various spare parts in stock to quickly accommodate any hardware failures that may occur. The goal is to minimize downtime for users and firewall administrators.

Auditing

System auditing will be performed by an internal information system auditing team. Because of the nature of the data in the system, using auditors that have the clearance to access this data is recommended for the task. The internal auditors also understand the organizational information system goals and the users’ needs as that their primary job. Spot-check auditing will be performed throughout the design process and a full audit is required when the system is complete.