Agency: Minnesota Department of Transportation (Mn/DOT)

Transcription

1 INFORMATION ACCESS AND PRIVACY PILOT PROJECT: CRITERIA FOR TRUSTWORTHY INFORMATION SYSTEMS Agency: Minnesota Department of Transportation (Mn/DOT) Form Completed By: Sue Dwight (Mn/DOT), Charles Engelke (InfoTech), Gary Ericksen (Mn/DOT), Bill Gordon (Mn/DOT), Lynn Klessig (Office of the Attorney General), Mike Martilla (Mn/DOT), Nancy Sannes (Mn/DOT), Gus Wagner (Mn/DOT), Joel Williams (Mn/DOT), Shawn Rounds (Recorder), Mary Klauda (Facilitator) Date: 22 July 1999 System: Electronic bidding system Expedite, Bid Express Stage of Development: Marketing and implementation of pilot project Description of System (including data models, etc.): Electronic bidding system (Expedite) will allow Mn/DOT to distribute contract bid items to contractors who can then prepare and submit bids electronically (via Bid Express and Internet) to Mn/DOT. The vendor, InfoTech, controls Expedite and Bid Express. Files transferred to Mn/Dot are brought into TRNS-PORT, a system already in place in the department. During the pilot project, Mn/DOT will still require paper bids from contractors using the electronic system. Design Date: 26 March 1999

2 CRITERIA FOR TRUSTWORTHY INFORMATION SYSTEMS Criteria What laws and/or regulations (state and federal apply to the data within your system? What are your industry s standards for system security? Data Security? Records Retention? What areas/records might lawyers target? Auditors? What data is private? / Rationale / tes Several laws in place and some to be proposed two categories. Existing ones on what information is needed (state and federal). Also laws on under what circumstances can you use a digital signature (state and federal) these are currently in flux. Mn/DOT going to ask legislature for permission to accept bids electronically. Can already accept digital signatures. Have been advised by the Attorney General s office. If the law is silent, you can t infer that you can do something just the opposite of the private industry. 16b.09 laws dictating necessity to have bids accessible at a certain time, advertising, public unsealing, alteration of bids, etc. ne. AASHTO s tried to create some standards by example, but still very general. Records retention is a yes for transportation, but based on paper system. Mn/DOT is working on security standards within department. Lawyers: proper execution of bid, valid signature, valid bid bond, correct completion of bid, proper authority signing bid. The bid document itself is what s used to verify correctness. Auditors: are we following the procedures when we accept the bid? Gary s section is audited every two years much of it based on statutes; also look for verification of proper insurance. Engineers estimate (until the award of project). Each bid is private until opening. Vendor qualification information (financial statement, work history, equipment inventory), bid escrow documents, probably some DBE material (disadvantaged business enterprises) in the future. State doesn t ask for any personal information on individual officers of businesses. Date: 22 July 1999 Page 2

3 What data is of permanent/historical value to you? To others? / All the bid information, bid prices. Rationale / tes 1. System administrators should maintain complete and current documentation of the entire system including policies, operating procedures, and audit trails of document revisions What is the system s unique identifier or name? What is the agency/department responsible for the system? For applications? What is the name and contact information of the person responsible for system administration? System security? Has a formal risk assessment of the system been completed? Date? Performed by? Methodology? Findings? Were design reviews and system test run prior to placing the system in production? Were the tests documented? Complicated because there s really two systems. Mn/DOT and the external outsourced system. Outside system documentation not available to Mn/DOT. Mn/DOT has policies and procedures that apply departmentwide, not just to this system. All Mn/DOT systems must interface with system called TRNS-PORT (AASHTO s name). Mn/DOT and InfoTech. Systems engineer. Security is the responsibility of LAN administrator if application on server, otherwise system network manager in IRM. Just an informal preliminary one. Really part of pilot project will be relying on InfoTech. This interview is the initial risk assessment. Date: 22 July 1999 Page 3

4 1. System documentation (e.g., specifications, program manuals, user guides) included in retention schedules, retained for as long as the longest retention time applicable to the records produced in accordance with the documents 1. Unique names and identifiers should remain the same over the lifetime of the units to allow tracking 1. If system installed at more than one site, each site should be running only an appropriate, documented, up-to-date version of the authorized configuration 1. Audit trails of hardware and software changes should be maintained such that earlier versions of the system can be reproduced ondemand 1. Process in place to ensure that no individual can make changes to the system without proper review and authorization 1.A.1 System Documentation: hardware procurement 1.A.1 System Documentation: hardware installation / Rationale / tes InfoTech will provide documentation on software, but not on their internal systems. Mn/DOT has retention schedules for all of their documentation. Need to retain software as well so that records can be retrieved. Have brought historical data up to date with current system will continue to migrate as move to different systems/software. TRNS-PORT started as historical tracking system, so very good about that. Will only be opening bids at one site. Contractors software will run at multiple sites, but InfoTech s software will stamp to indicate required software need to run/open (version control). InfoTech will have redundant systems located geographically separate. This system may be expanded to include State Aid -- would then have several locations for opening. Right now mainframe. Moving to client-server. t really an issue because they migrate. Database constantly being refreshed. Bid file software can be kept to access. Mn/DOT has control over TRNS-PORT system, but with this system they don t know. Will have to designate who can install updates, etc. Also network issues. Access to data very strictly controlled on mainframe. When they move into Oracle, the database administrator will control. Data on PCs encrypted with very strong encryption. t an issue on the mainframe. In process of purchasing client-server hardware and will keep record of this. t an issue on the mainframe. In process of purchasing client-server hardware and will keep record of this. Date: 22 July 1999 Page 4

5 1.A.1 System Documentation: hardware modifications 1.A.1 System Documentation: hardware maintenance 1.A.1 System Documentation: use of only agency-authorized hardware 1.A.2 System Documentation: software procurement 1.A.2 System Documentation: software installation 1.A.2 System Documentation: software modification 1.A.2 System Documentation: software maintenance 1.A.2 System Documentation: use of only agency-authorized software Is application software properly licensed for the number of copies in use? 1.A.3 System Documentation: communication networks procurement / Rationale / tes t an issue on the mainframe. In process of purchasing client-server hardware and will keep record of this. LAN administrators keep these records. agency-authorized hardware anymore. It s just purchased according to needs, although subject to approval process by state rules. Everything InfoTech delivers is heavily documented along with a revision history. Everything InfoTech delivers is heavily documented along with a revision history. Have standards like Oracle for department. InfoTech system will work with any web browser compliant with HTML 3.0 or higher. Outside of the scope of this system. Date: 22 July 1999 Page 5

6 1.A.3 System Documentation: communication networks installation 1.A.3 System Documentation: communication networks modifications 1.A.3 System Documentation: communication networks maintenance 1.A.4 System Documentation: interconnected systems (including the Internet) list 1.A.4 System Documentation: interconnected systems names and unique identifiers 1.A.4 System Documentation: interconnected systems owners 1.A.4 System Documentation: interconnected systems names and titles of authorizing personnel 1.A.4 System Documentation: interconnected systems dates of authorization 1.A.4 System Documentation: interconnected systems types of connections / Rationale / tes TRNS-PORT is the only connected system right now. Electronic Bidding will interface with this system. Once bids are received they are brought into Letting and Award system of TRNS-PORT for bid opening (will still be public). EBS is an outboard component of TRNS-PORT used for interfacing. Core TRNS-PORT system has shared central database and that s the long-term repository and location of official record. Date: 22 July 1999 Page 6

7 1.A.4 System Documentation: interconnected systems indication of system of record 1.A.4 System Documentation: interconnected systems sensitivity levels 1.A.4 System Documentation: interconnected systems security mechanisms, security concerns, personnel rules of behavior 1.B.1 System Documentation: programming conventions and procedures 1.B.2 System Documentation: development and testing procedures, including tools 1.B.2 System Documentation: development and testing procedures periodic functional tests should include anomalous as well as routine conditions and be documented such that they are repeatable 1.B.3 System Documentation: applications and associated procedures for entering and accessing data 1.B.3 System Documentation: applications and associated procedures for data modification / Probably Rationale / tes All TRNS-PORT software follows AASHTO (non-profit corporation whose members are the state DOTs) guidelines and standards. Date: 22 July 1999 Page 7

8 1.B.3 System Documentation: applications and associated procedures for data duplication 1.B.3 System Documentation: applications and associated procedures for data deletion 1.B.3 System Documentation: applications and associated procedures for indexing techniques 1.B.3 System Documentation: applications and associated procedures for outputs 1.B.4 System Documentation: identification of when records become official 1.B.5 System Documentation: record formats and codes 1.B.6 System Documentation: routine performance of system backups appropriate labels 1.B.6 System Documentation: routine performance of system backups secure, offline, off-site storage 1.B.6 System Documentation: routine performance of system backups periodic integrity tests /? Rationale / tes Also how to export, move to another machine, etc. For TRNS-PORT as a whole yes, otherwise no for EBS. EBS doesn t have the capabilities, but TRNS-PORT does. This is a state procedure. Included by reference InfoTech uses open standards. Error detecting codes in all files whenever transferred. Date: 22 July 1999 Page 8

9 1.B.7 System Documentation: routine performance of quality assurance and control checks (incl. audit trails) 1.B.7 System Documentation: routine performance of quality assurance and control checks identification devices (e.g., security cards) periodically checked to ensure proper functioning and correctness of identifying information and system privilege levels 1.B.7 System Documentation: routine performance of quality assurance and control checks storage mediums undergo regular statistical sampling following established procedures outlining sampling methods, identification of data loss and corresponding causes, and the correction of identified problems 1.B.8 System Documentation: migration of records to new systems and media as necessary, with all record components managed as a unit throughout transfer 1.B.9 System Documentation: standard training for all users and personnel with access to equipment / Rationale / tes Software-based identification scheme with encryption. Checked for correct functioning every time used. back-checking of data. Date: 22 July 1999 Page 9

10 1.B.9 System Documentation: standard training users should sign statements agreeing to terms of use Who can invoke change mechanisms for object, process, and user security levels? Who (creator, current owner, system administrator, etc.) can grant access permission to an object after the object is created? How does the system accommodate integration of records from other systems? / Rationale / tes Contractors have to sign one with InfoTech service. Important. Individuals sign agreement when join department. Bid Express is InfoTech (decides whether to invoke private-public key pair). InfoTech controls files until time of public opening, and up until then access open only to its employees. After opening, control and information passes to Mn/DOT. Expedite transfers data to and from the contractor systems. 2. System administrators should establish, document, and implement security measures 2.A.1 System Security User Authorization: user identification and access procedures should be established and documented 2.A.1 System Security User Authorization: users should be authenticated prior to being granted access 2.A.2 System Security User Authorization: unique identifier and password for each user Up until public opening InfoTech, then data passed on to Mn/DOT Two levels to browse data and to submit bid. Each subscriber has one (can be an organization). Each signer is an individual Date: 22 July 1999 Page 10

11 2.A.2 System Security User Authorization: identifiers and passwords not used more than once within a system 2.A.2 System Security User Authorization: use of access scripts with embedded passwords limited and controlled 2.A.2 System Security User Authorization: upon successful log-in, users should be notified of date and of last successful log-in, location of last log-in, and each unsuccessful log-in attempt on user identifier since last successful entry 2.A.2 System Security: where identification codes in human-readable form are too great a security liability, use of other forms such as encoded security cards or biometric-based devices 2.A.3 System Security User Authorization: password rules include minimum password length, expiration dates, and limited number of log-on attempts / Rationale / tes Many people can be logged on at same time from same organization, although multiple connections will be disallowed in the future. Mn/DOT has a digital signature to receive data for InfoTech. For contractors, their digital signatures are what allows them to send information. Digital signatures are not shared (signed agreement). For just accessing general information service, it s allowed. For submitting bid, digital signature must be applied and that s controlled by InfoTech. Bid Express tells people date of last log-in, but not location. If a submitted bid is replacing another, that information is passed on to contractor. cut-off after repeated failed attempts at access. Digital signature applied on contractors machine and transmitted to the InfoTech system in a packet. Secret key generated by InfoTech and encrypted by pass-phrase given by contractor. Usability for cards not yet available for widespread use, also hardware issues. for minimum length. Higher level access has more rules for passwords. limit to attempt. Date: 22 July 1999 Page 11

12 2.A.3 System Security User Authorization: determination of what level and frequency of log-on error constitutes a misuse problem which, in turn, would trigger notification of security personnel 2.A.4 System Security User Authorization: users to only level of access necessary to perform their job duties 2.A.5 System Security User Authorization: permission to alter disposition/retention codes, and/or to create, modify, and delete records granted only to authorized users with proper clearance 2.A.5 System Security User Authorization: modification of record identifiers prohibited 2.A.6 System Security User Authorization: Access to private keys for digital signatures limited to authorized personnel 2.A.7 System Security User Authorization: maintenance of lists of all current and past authorized users along with their privileges and responsibilities / Rationale / tes Only checks out anomalous behavior after the fact. Has been an educational issue with contractors individuals need to be physically present to apply digital signature. for Mn/DOT Core reason that Expedite was created for digital signatures (InfoTech also checks with Mn/DOT to make sure that individual is authorized to submit bids). May need to look into this at Mn/DOT (currently done on mainframe). Date: 22 July 1999 Page 12

13 2.A.7 System Security User Authorization: current list of users reviewed on a regular schedule to ensure timely removal of authorizations for former employees, and adjustment of clearances for workers with new job duties 2.A.8 System Security User Authorization: personnel duties and access restrictions arranged such that no individual with an interest in record content will be responsible for administering system security, quality controls, audits, or integrity-testing functions. 2.A.8 System Security User Authorization: individual should have the ability to singlehandedly compromise the system s security and operations 2.B.1 Internal System Security: access to system documentation controlled and monitored 2.B.2 Internal System Security: access to output and storage devices controlled and monitored 2.B.3 Internal System Security: controls in place to ensure proper security levels of data when archiving, purging, or moving from system to system / t Asked t Asked Rationale / tes Department policies for this. Contractors must have procedures for revoking privileges. Much of the InfoTech s documentation is available for free download Data between TRNS-PORT and Expedite will require security, but network-level access is controlled with policies within department. Date: 22 July 1999 Page 13

14 2.B.3 Internal System Security: controls in place for the transportation or mailing of media or printed output / Only moved digitally. Rationale / tes 2.B.4 Internal System Security: procedures for the complete sanitization and secure disposal of hardware when no longer needed. 2.B.4 Internal System Security: procedures for the complete sanitization and secure disposal of software when no longer needed 2.B.4 Internal System Security: procedures for the complete sanitization and secure disposal of storage media when no longer needed 2.B.4 Internal System Security: documentation of sanitization and secure disposal should include date, equipment identifiers, methods, personnel names t sure at Mn/DOT probably important to consider. t sure need to look at. t sure need to look at. They do have this at InfoTech reformat diskettes. t sure need to look at. 2.B.5 Internal System Security - insecuritydetection mechanisms constantly monitoring the system 2.B.5 Internal System Security: failsafes and processes to minimize the failure of primary security measures in place at all times Date: 22 July 1999 Page 14

15 2.B.6 Internal System Security: security procedures and rules reviewed on a routine basis to maintain currency 2.B.7 Internal System Security Access: measures in place to guard system s physical security 2.B.8 Internal System Security: security administration personnel undergo training to ensure full understanding of the security system s operation 2.C.1 External System Security: additional security measures employed in cases of remote access, especially through public telephone lines (e.g., input device checks, caller identification checks (phone caller identification), call backs, security cards) 2.C.2 External System Security: for records originating outside of the system, the system should be capable of verifying their origin and integrity 2.C.2 External System Security: non-system records verification of sender or source / Rationale / tes AASHTO has a fixed schedule for this. Date: 22 July 1999 Page 15

16 2.C.2 External System Security: non-system records verification of the integrity, or detection of errors in the transmission or informational content of record 2.C.2 External System Security: non-system records detection of changes in the record since the time of its creation or the application of a digital signature 2.C.2 External System Security: non-system records detection of viruses / Rationale / tes Digital signatures used. Error detection code will detect changes not made through InfoTech software. Just data files, can t hold viruses. 3. System administrators should establish audit trails that are maintained separately and independently from the operating system Who can access audit data? Who can alter audit data? Who can add audit data? Who can delete audit data? How can the audit logs be read? What mechanisms are available to designate and change activities chosen for audit? State tracks addenda to bids. InfoTech prints out receipt of each bid on two separate printers for record. Any authorized user. t alterable. t allowed. Can t do this except physically. InfoTech s responsibility human will check paper logs against digital record of transfer when transfer to Mn/DOT. Date: 22 July 1999 Page 16

17 3.A Audit Trails: if audit trails are encoded to conserve space, the decode mechanism must always accompany the data 3.A.1 Audit Trails General Characteristics: audit trail software and mechanisms subject to strict access controls 3.A.1 Audit Trails General Characteristics: audit trail software and mechanisms protected from unauthorized modification 3.A.1 Audit Trails General Characteristics: audit trails protected from circumvention 3.A.2 Audit Trails General Characteristics: audit trails backed up periodically onto removable media to ensure minimal data loss in case of system failure 3.A.3 Audit Trails General Characteristics: system automatically notifies system administrators when audit storage media nearing capacity. Response documented 3.A.3 Audit Trails General Characteristics: when storage media containing audit trail is physically removed from the system, the media should be physically secured as required by the highest sensitivity level of the data it holds / Rationale / tes Audits stored three ways at InfoTech paper, ASCI, database Printers in locked rooms. Every business day. On same tape cartridges as data. Kept in locked vault. Date: 22 July 1999 Page 17

18 3.B Audit Trails Password Usage and Changes 3.C Audit Trails Users: system in place to log and track users and their on-line actions / t asked Rationale / tes 3.C Audit Trails Users: users made aware that their use of computerized resources is traceable 3.C Audit Trails Users: users supplied with Tennessen Warning when collecting confidential or private data by any means 3.D Audit Trails: the following information, at least, logged for each record by audit trails: user identifier, record identifier, date, time, and usage (e.g., creation, capture, retrieval, modification, deletion) In terms of agreement. Just have standard web privacy warning on Bid Express site. User id, record id, date, time, usage (bid submission or withdrawal). 4. System administrators should establish a comprehensive disaster recovery plan 4.A Disaster Plan: periodically reviewed for currency and tested for efficiency InfoTech relies on backup storage. RAID is for ensuring non-stop functioning of system InfoTech s has not yet been reviewed and tested, but will be. Periodic review at Mn/DOT, but no tests run. Will need to establish this (backups) for new client-server. Some falls to Network Operations Center. Only certain offices backed-up and information has been lost in the past. Don t have good off-site storage for backups. Date: 22 July 1999 Page 18

19 5. For each record: original content and format, context, and structure preserved regardless of the system or media on which the record is retained 5. For each record: all record data, documents, proofs of authenticity (e.g., digital signatures), metadata, and other related information, regardless of form or format, accessed, displayed, and managed as a unit 5. For each record: ability, upon demand, to print or represent the record in a whole and intelligible way as it originally appeared at the time of its creation or initial receipt What are the current components of a complete or final record of the transaction? Who are the external secondary users of the record? How will the record be reproduced to meet the needs of internal and external secondary users? / Rationale / tes For seven years (after bid-letting, not completion of project) on all bids submitted (currently paper records are stored at records center). Portions of successful bids kept 20 years. All together in one file for each bid. Within Expedite: bid file (all data, metadata for rules and format, contractors information, etc.) encrypted (key not included so decryption key needs to be archived so that the old files can be accessed). InfoTech recommends changing key only for personnel issues. There may be external users, but primarily will be internal users. Contractors can request information because public data. There will be a process established for this. What is the records disposition plan? 7 years, 20 years. Who is responsible for authorizing the disposition of records? Department policy; federal and state statutes. Date: 22 July 1999 Page 19

20 Who can access metadata? / TRNS-PORT people Rationale / tes Who can alter metadata? TRNS-PORT people Who can delete metadata? TRNS-PORT people Who can add metadata? TRNS-PORT people 5.A. Record metadata: unique identifier for each bid 5.A. Record metadata: date of creation 5.A. Record metadata: time of creation 5.A. Record metadata: creator / agency / organization 5.A. Record metadata: documentation of creator s authorization 5.A. Record metadata: date of modification 5.A. Record metadata: time of modification 5.A. Record metadata: modifier / agency / organization 5.A. Record metadata: documentation of modifier s authorization Date: 22 July 1999 Page 20

21 5.A. Record metadata: indication of authoritative version 5.A. Record metadata: identification of originating system 5.A. Record metadata: date of receipt from outside system 5.A. Record metadata: time of receipt from outside system 5.A. Record metadata: addressee 5.A. Record metadata: system or mechanism used to capture record from outside system 5.A. Record metadata: protection method 5.A. Record metadata: media type / Rationale / tes in transaction file Expedite has, but not in long term database 5.A Record metadata: format 5.A Record metadata: location of record 5.A Record metadata: sensitivity classification Date: 22 July 1999 Page 21