Standard: System Security Authorization AgreementStandard Number: S-PM-035
Phase: Concept &Phases: Concept and Technology Development,System Development and Demonstration; or alternatelyDemonstration (or Engineering and
and Manufacturing Development(II) if system already received Milestone II approval), Production and
Deployment (System Acquisition), (System Maintenance)
Activities: Information Assurance/Security
Tasks: DITSCAP Phase 1, Definition; DITSCAP Phase 2, Verification; DITSCAP Phase 3, Validation
For additional guidance see: DoD DITSCAP Application Manual (DoD 8510.1-M) Conduct DITSCAP Phase 1, Definition, Conduct DITSCAP Phase 2, Verification,
Conduct DITSCAP Phase 3, Validation, Conduct DITSCAP Phase 4, Security Operations and
Compliance Validation
Reference: DoD DITSCAP Application Manual
Effective Date: May 17, 2002
DEFENSE FINANCE AND ACCOUNTING SERVICE
SYSTEM SECURITY AUTHORIZATION AGREEMENT
System Security Authorization Agreement
For
E-voting System
SSAA 2.0
UCCS-Ditscap Team
Version Draft (DITSCAP Phase 1)
Wednesday,May 09,2007
Issuing organization: UCCS
TABLE OF CONTENTS FOR E-voting system SSAA
1.0 MISSION DESCRIPTION AND SYSTEM IDENTIFICATION......
1.1 System name and identification......
1.2 System description......
1.3 Functional description......
1.3.1 System Capabilities......
1.3.2 System criticality......
1.3.3 Classification/sensitivity of data processed......
1.3.4 System user description and clearance levels......
1.3.5 Life Cycle of the System......
1.4 System CONOPS Summary......
2.0 ENVIRONMENT DESCRIPTION......
2.1 Operating environment......
2.1.1 Facility Description......
2.1.2 Physical Security......
2.1.3 Administrative Issues......
2.1.4 Personnel......
2.1.5 COMSEC......
2.1.6 TEMPEST......
2.1.7 Maintenance Procedures......
2.1.8 Training Plans......
2.2 Software development and maintenance environment......
2.3 Threat description......
3.0 SYSTEM ARCHITECTURAL DESCRIPTION......
3.1 System Architecture Description......
3.2 System Interfaces and External Connections......
3.3 Data flow (including data flow diagrams)......
3.4 Accreditation boundary......
4.0 SYSTEM SECURITY REQUIREMENTS
4.1 National and DOD security requirements......
4.2 Governing security requisites......
4.3 Data Security Requirements......
4.3.1 Confidentiality......
4.3.2 Integrity......
4.3.3 Availability......
4.3.4 Classification Guidelines......
4.4 Security CONOPS......
4.5 Network Connection Rules......
4.6 Configuration Management Requirements......
4.7 Reaccreditation requirements......
5.0 ORGANIZATIONS AND RESOURCES
5.1 Organizations......
5.2 Resources......
5.3 Training......
5.4 Other Supporting Organizations......
6.0 DITSCAP PLAN......
6.1 Tailoring Factors......
6.1.1 Programmatic considerations......
6.1.2 Security Environment......
6.1.3 IS Characteristics......
6.1.4 Reuse of previously approved solutions......
6.2 Tasks and milestones......
6.3 Schedule summary......
6.4 Level of effort......
6.5 Roles and Responsibilities......
6.5.1 Designated Approving Authority......
6.5.2 Certification Authority......
6.5.3 Certifying Agent Representative......
6.5.4 Program Manager......
6.5.5 User Representative......
6.5.6 System Administrator......
RECORD OF CHANGES
Version No. / Date of Change / Date Entered / Entered byDraft / May 09. 2007 / Apr 25. 2007 / DITSCAP team
1.0 / May 10,2007 / May 09 2007 / DITSCAP team
2.0 / May 11 2007 / DITSCAP team
[E-voting system]
[SSAA 2.0]
SYSTEM SECURITY AUTHORIZATION AGREEMENT
(SSAA)
Designated Approving Authority (DAA):
______
[Mr. Ismael Rodriguez, BOEING] Date
Program Manager:
______
[Dr. Edward Chow,UCCS] Date
11. Mission Description and System Identification
Identification. .
1.1 1.1. System Name and Identification
Identification.
System Name : E-Voting System by Brett Wilson
OrganizationName : University Of Colorado at Colorado Springs(UCCS).
Location : Colorado Springs, CO-80918
User : Boeing
1.2 System Description
1.2. System Description.
The E-Voting system described in this document is based upon the Paillier Threshold Cryptosystem from the Graduate work of Wilson et al. [1]. The systemwill allow only single-choice ballot issues for an election consisting of potentially more than one ballot. The election administrator creates the ballots and other election parameters then requests the Paillier threshold encryption parameters from the PTC Web Service during the initial election set-up. The administrator then submits the election parameters to a VotingService web service, and saves the election parameters (including the cryptosystem parameters) to an XML file. Next, Voters load the election parameters by opening the XML file. They then make their selection(s) and cast their encrypted vote(s) to the VotingService web service. During the tally phase, the votes are multiplied together, and, due to the homomorphic properties of the Paillier cryptosystem, the product of the votes can be decrypted to reveal the sum total of all the votes cast.
1.3The Paillier encryption scheme itself is homomorphic, self-blinding, and probabilistic.Functional Description
These properties are useful for implementing a secure E-Voting System. The homomorphic property helps secure a voter’s privacy as well as greatly reducing the number of decryption operations required in the system. The self binding property is applied in a mix-net scheme to protect voter anonymity. And finally, the probabilistic property is important for protecting voter privacy since no two votes, even if they are identical, will produce an identical cipher text.
The E-Voting System Software has the following components:
The Paillier Threshold Cryptosystem consists of two main software components.
- PaillierThresholdCryptoServiceProvider (PTCSP) – contains all of the algorithms and data handling methods required to fully implement the Paillier Threshold scheme.
- Paillier Threshold Cryptography Web Service (PTC Web Service) – uses the PTCSP to generate the requested system parameters, properly secure them, and return them to the requestor.
The PTCSP holds two main blocks of data. The first block is the cryptosystem parameters of type PaillierThresholdParameters holds both the public and private keys, the secret key shares, and the system parameters specifying the number of shares and the threshold value.
The second block is the DecryptionShares list exposed as a public property of generic type List(Of ThresholdDecryptionShares). This list can either be populated by importing decryption shares obtained from participants in the system, or generated from a given ciphertext and the secret key shares present in the parameters data structure.
The E-Voting System hardware architecture will consist of an E-Voting server which will house all of the software component functionality of the E-Voting system, a Linux firewall server which will limit access to the E-Voting system, and one E-Voting access terminal. All systems other than the E-Voting access terminal will be running on a VMWare virtual network configuration.
Figure 1: E-Voting System Hardware Architecture
1.4Functional Description
This section provides1.3. Functional Description.
The external players for e-voting system are election administrator, the candidates that own the key share and general voter. During the setup phase of election, the administrator creates the secret key shares to be owned by the candidates. For security reason, the secret key shares need to be encrypted by public X.509 certificate of the key share owners.
1.3.1.1. System Capabilities
1.3.2.1.3.1.System Capabilities
The E-Voting system will provide the capability for individuals to vote in local, state, and national elections securely from any pre-determined voting site. In addition, election administrators will be able to use the system to create election ballots, administer the election process and tally election results in a collaborative manner from any pre-determined election administration sites.
The security level of the information contained within the E-Voting System application should be considered Top Secret, meaning access should be restricted to only those individuals who require it. The Principle of Least Privilege should be employed to determine all access levels for the system. In addition, the separation of the voter identification information from the ballot cast is essential to maintain any legally required anonymity of the voters.
Figure 2: E-Voting System Functional Diagram
1.4.1 System Criticality
1.3.2. System Criticality.
DoD Instruction 5000.2 mandates that systems be categorized as mission critical, mission essential or neither. E-voting is
Mission Essential - (system is essential for the completion of an organizational function)
1.4.2 1.3.3. Classification and Sensitivity of Data Processed
Processed.
The e-voting system is designed upon the Paillier Threshold Cryptography(PTC) scheme. PTC inherently protects secrecy of individual vote, still making vote counting possible through mathematical properties. Thus, exposure of data is not critical threat to any of the election being carried out, as in order to make any sense out of the stored data requires consent and availability of all the secret share owners. The system do need to be protected against data loss due to natural calamity as well as human errors.
1.4.3 1.3.4. System User Description and Clearance Levels
Levels.
E-voting users are government personnel and government contractors. Because of the data classification level, a special clearance is not required. However, if a clearance is required it will be set by each facility.
Access requests are approved by :E-voting Administrators
1.4.4 1.3.5. Life Cycle of the System
System.
E-voting is in phase __3__ of the DITSCAP: (check one)
1 – Definition
2 – Verification
3 – Validation
4 – Post-Accreditation
1.5 1.4. System CONOPS Summary
Summary.
The system is to be used on Remote Desktop Connection. The evoting server is protected with a firewall.A voter thru his desktop or laptop has to first gain access to the firewall which in turn would grant him access to the evoting server.The code of evoting is to be configured thru proper configuration management procedures.
22. Environment Description.
Description.
2.1 2.1. Operating Environment
Environment.
E-voting servers are located in the controlled spaces at UCCS Room EN-149.
2.1.1 2.1.1. Facility Description
Description.
Office Space
Strong Room
Vault
Facility secured for open storage (N/A for unclassified systems)
The current E-Voting System hardware resides in the EngineeringBuilding, Room 149 at the University of Colorado, Colorado Springs. The environment in this facility is that of a typical business office. However, it is envisaged the production system will be located in an enterprise class computer facility with redundant power, air conditioning, dry fire control system, physical security, and raised flooring similar to that shown in Figure 3.
2.1.2 2.1.2. Physical Security
Security.
The physical security of the building is constantly monitored.there is security personeel in charge of the building on 24X7 basis.Only authorized persons are allowed to enter the e-voting server room. Auhorization is in the form of card swipes.There are cameras monitoring the e-voting server to reduce possibilities of tampering and/or removal of critical information pieces..
2.1.3 2.1.3. Administrative Issues
Issues.
The security personned are assigned duties on a rotational basis This is to ensure proper controls can be provided to eliminate fraud,abuse or espionage or at the least difficult. The security personnel are screened for background check before they are hired.
2.1.42.1.4 PersonnelPersonnel
There are 5 security personnel assigned for the physical securities of the server room.No sitors are allowed entry in the server room..Only authorized personnel for maintenance of the evoting system are allowed entry with the proper authorization of swipe cards.
2.1.5COMSEC
Not Applicable
2.1.5TEMPEST
2.1.6. TEMPEST.
Not Applicable
2.1.62.1.7. Maintenance Procedures
Procedures
The following is a firewall tune-up procedure a recommend you to do so you can have a "health chart" of your system:
- Monitor your firewall for a month and store all the lof results. AS many logs you have more accurate and complete will be results of your firewall "physical" exam!
By doing this you will have a first hand idea of the load going through your firewall, regardless if it is a packet or application level firewall. If the firewall is an application level firewall, this should be a breeze, as these firewall already provide you a lot of reports about the system by default. Now, if it is a packet-level firewall, like a router for example, then you will have to develop some kind of log-reduction, by using tools such as tcpdump, or NNstat.
- Sort the logs by the time of day, per hour.
- Tabulate the batch of logs by services, yielding values like:
Number of web hits during that interval
Average size of retrieved web objects during that interval
Average time between web accesses during that interval
Number of FTP retrieves during that interval
Average size of FTP objects retrieved during that interval
Average time between FTP retrievals during that interval
Number of TELNET sessions during that interval
Maximum concurrent TELNET sessions during that interval
Amount of NNTP traffic in during that interval
Amount of NNTP traffic out during that interval
Average time between NNTP sessions during that interval
Watch for new patch releases for your firewall of operating system, and when they come out, apply them. Be careful with false patches, as every now and then you will find someone creating a Trojan horse patch and trying to pass it off as the real thing.
The following is a list of steps and procedures you should follow in order to keep your firewall working properly, which includes both preventive and curative measures:
- Back up all firewall components, not only the bastion host(s), loaded with firewall software, but also the routers.
- Make sure when adding new management accounts on a firewall, as it’s very important to maintain your firewall system secure at all times. New accounts must be added correctly, as well as old accounts removed, and make sure to change passwords after deleting an user account. My recommendation is that you should limit the number of user accounts on the firewall, only allowing administrators to access it.
- Watch the log reports of traffic passing through the firewall. Data always expands to fill all available space, even on machines that have almost no users. Unfortunately, there is no automatic way to find junk on the disk. Auditing programs, like Tripwire, will alert on new files that appear in supposedly static areas. The main disk space problem will be firewall logs. These can and should be rotated automatically with old logs being stored for a minimum of one year.
- Monitors your system. By creating a habit of monitoring your system you will be able to determine several things:
Has the firewall been under any form of attack?
If so, what kinds of attacks are being tried against the firewall?
Is the firewall holding up to this attacks, in working correctly?
Is the firewall able to provide the service users need?
Monitor attempts to use the services you disable.
Configure your system so that any activities related to security is recorded on a log report.
If your firewall doesn’t provide an auditing software, install one, such as Tripwire or L5, run it regularly to spot unexpected changes to your system.
Log your most critical events to hardcopy if at all possible, and check your logs frequently!
Be on alert for abnormal conditions of your firewall. Develop a security checklist, watching for:
All packets that were dropped
Denied connections, as well as rejected attempts.
Data such as time, protocol, and user name of all successful connection to or through the firewall.
All error messages from your routers, firewalls and any proxying programs.
Exceptions based on your normal firewall activity. Figure 12.01 outlines a basic access policy.
2.1.72.1.8.Training Plans
Plans.
The training plan for System Administrators include :
- OS Hardening
- Security domains
- Adding networks and hosts
- Importing vulnerability data
- Locating a hacker in a smoke screen
- Conserving threat data while away
- Removing a host from top threats view
- Filters
- Using rules
- Auditing
- Firewall
- IDS
Maintenance procedure of security personnel :
- Yearly Training requirements
- Scheduld Penetration testing
- Software update Procedures
- Response to IDS
- Response to suspicious Audit Activity
2.2 2.2. Software Development and Maintenance Environment
Environment.
E-voting system will be maintained by UCCS-DITSCAP team. A routine integrity check of networks, firewalls and routers are to be maintained.A snort IDS is the be installed on the evoting server as a mechanism for intrusion detections. Snorts rules are to updated periodically to be in control of uncovered vulnerabilities.Honeypot measures are to be used for prevention of false positives.
2.3 Threat Description
2.3. Threat Description.
The system is also subject to a range of generic threats that are similar to those applicable to most government information systems. Potential threats exist in the areas of:
Protection and distribution control of Controlled Unclassified Information (CUI) that is processed, stored, and transmitted.
Integrity of CUI processed, stored, and transmitted.
Potential threats to the system originate from natural and man-made sources. Natural threats include fire, flooding, water, wind, and electrical disturbances. Natural threats may be induced by man-made activity. Man-made threats are from those who specifically target the system for espionage, criminal activity, unlawful use, denial of service, or malicious harm. External or internal threat agents include espionage services, terrorists, hackers, and vandals. Analysis of recent computer-related incidents, however, indicates that the greatest threat to the system is from a trusted agent who has access to the system.In the case of evoting system there is a residual risk of the trustworthiness of the key share owners who own public and private keys.
The most likely threat scenario involves an authorized user who accidentally or inadvertently commits or omits some action that damages or compromises the system, one of its components, or information processed, stored, or transmitted. A malicious hacker could gain entry into the system for spoofing of votes, repudiation of votes,escalation of priveleges therby distorting thr election scenario.These circumstances also include the threat posed by users who negligently or inadvertently fail to follow security requirements for proper handling and labeling of system output or media, or the rules against the introduction of unauthorized software or data into the system.
There is a related threat scenario that results from the failure of authorized users to employ proper procedure for entry or manipulation of system data because of a lack of proper or adequate training in the use and operation of the system.
There is a threat scenario that involves an authorized user who, for personal gain or vengeful reason, takes deliberate action to damage the system, one of its components, or information processed, stored or transmitted. .
There is a threat scenario posed by disgruntled employees, especially those who are to be terminated for cause.
Insider threats, whether intentional or unintentional, can be manifested in the following ways: