INFORMATION ACCESS AND PRIVACY PILOT PROJECT: CRITERIA FOR TRUSTWORTHY INFORMATION SYSTEMS

Transcription

1 INFORMATION ACCESS AND PRIVACY PILOT PROJECT: CRITERIA FOR TRUSTWORTHY INFORMATION SYSTEMS Form Completed By: HRIS team (Sandra Allshouse, Caroline Bachun, Marsha Haagenson, Shirley Janssen, Merry Keefe, Mary Pedersen, Myron Rademacher, Carol Rogers, Bert Sletten, Craig Steiner, Linda Webster), Shawn Rounds (Recorder), Mary Klauda (Facilitator) Date: 12 March 1999 (sections 1 though 2.C); 26 March 1999 Stage of Development: Moving to PeopleSoft Description of System (including data models, etc.): 28 January 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? Rationale / tes Data privacy, data practices, IRS regulations, COBRA, GAAP, civil service rules, state statutes, city charter, laws applying to veterans rights, labor contracts, Federal communications (FCC), new privacy laws just coming down now. PeopleSoft modified to address some of these. Data privacy (legal). Records retention guidelines based on state and federal guidelines and statutes. Regarding destruction of private information. PeopleSoft reflects best practice for HR only changed to comply with specific laws, etc. so the standard would be maintained. Bid Spec and Implementation plan would document this. Date: 12 March 1999; 26 March 1999 Page 2

3 What areas/records might lawyers target? Auditors? What data is private? What data is of permanent/historical value to you? To others? Rationale / tes COBRA, disciplinary records (big), training, medical, selection, testing and hiring. ADA and disability, gender issues. Deductions, enrollments, benefits, etc. did the employee actually authorize it, is it a court order for child support, etc.? Have never really been audited in terms of their procedures. >> also recruitment and applications Personnel files: they have identified all paper types in file and identified of those which are private -- was reviewed by Caroline Bachun. Very broad definitions. Some portions of forms have public as well as private information. Have general guideline that also applies to HRIS. Potentially anything in personnel file could go into HRIS. Could use this to determine data needs for data warehouses what not to send or what to mark for additional security. See retention schedules Date: 12 March 1999; 26 March 1999 Page 3

4 1(1). System administrators should maintain complete and current documentation of the entire system including policies, operating procedures, and audit trails of document revisions Rationale / tes 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? HRIS HR Finance officer and head of HR Date: 12 March 1999; 26 March 1999 Page 4

5 1(2). 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 Rationale / tes 1(3). Unique names and identifiers should remain the same over the lifetime of the units to allow tracking Couldn t track versions 1(4). If system installed at more than one site, each site should be running only an appropriate, documented, up-todate version of the authorized configuration 1(5). Audit trails of hardware and software changes should be maintained such that earlier versions of the system can be reproduced on-demand It s an enterprise system that can add users, but only one system Only keep information at high level (like procurement) 1(6). Process in place to ensure that no individual can make changes to the system without proper review and authorization 1.A.1(1) System Documentation: hardware procurement 1.A.1(2) System Documentation: hardware installation Written procedures who has access. Oracle security, network security, etc. t concerned. t concerned. Date: 12 March 1999; 26 March 1999 Page 5

6 1.A.1(3) System Documentation: hardware modifications Rationale / tes t concerned. 1.A.1(4) System Documentation: hardware maintenance t concerned. 1.A.1(5) System Documentation: use of only agency-authorized hardware 1.A.2(1) System Documentation: software procurement 1.A.2 (2) System Documentation: software installation 1.A.2 (3) System Documentation: software modification Important 1.A.2 (4) System Documentation: software maintenance 1.A.2 (5) System Documentation: use of only agency-authorized software Is application software properly licensed for the number of copies in use? 1.A.3(1) System Documentation: communication networks procurement Important to know about lines -- who has access 1.A.3(2) System Documentation: communication networks installation Date: 12 March 1999; 26 March 1999 Page 6

7 1.A.3(3) System Documentation: communication networks modifications Rationale / tes 1.A.3(4) System Documentation: communication networks maintenance 1.A.4.a System Documentation: interconnected systems (including the Internet) list 1.A.4.b System Documentation: interconnected systems names and unique identifiers 1.A.4.c System Documentation: interconnected systems owners 1.A.4.d System Documentation: interconnected systems names and titles of authorizing personnel Have to keep track of history of everything that comes in. PRS is an authentication issue of the other system. Also things go out to other systems pension, deferred comp, quarterly unemployment, child support validation, etc. Using web to send info to Medica, etc. (Is outbound really important? Need to track private data.) Tax information coming in from PeopleSoft, but reference material. Benefits staff doesn t get any information from other departments, but would like to have enrollment capabilities over web. Direct deposit. Date: 12 March 1999; 26 March 1999 Page 7

8 1.A.4.e System Documentation: interconnected systems dates of authorization Rationale / tes 1.A.4.f System Documentation: interconnected systems types of connections 1.A.4.g System Documentation: interconnected systems indication of system of record 1.A.4.h System Documentation: interconnected systems sensitivity levels 1.A.4.i System Documentation: interconnected systems security mechanisms, security concerns, personnel rules of behavior If connected to external systems lacking commensurate security measures, what mitigation procedures are in place? Date: 12 March 1999; 26 March 1999 Page 8

9 1.B.1 System Documentation: programming conventions and procedures 1.B.2(1) System Documentation: development and testing procedures, including tools PeopleSoft conventions Rationale / tes Important to know what changes were made, regardless of whether they were right or wrong. Off-the shelf packages, with some modifications by outside contractor based on HR requirements and requests. Can tell what modifications were made for Minneapolis. General design, detail design, etc. documented, reviewed and signed-off on. Documented testing cycles. 1.B.2(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, for routine Impossible to re-create anomalous conditions by themselves 1.B.3(1) System Documentation: applications and associated procedures for entering and accessing data 1.B.3(2) System Documentation: applications and associated procedures for data modification 1.B.3(3) System Documentation: applications and associated procedures for data duplication Date: 12 March 1999; 26 March 1999 Page 9

10 1.B.3(4) System Documentation: applications and associated procedures for data deletion Rationale / tes 1.B.3(5) System Documentation: applications and associated procedures for indexing techniques What are indexing techniques in this case? 1.B.3(6) 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 By effective dates and entry dates. In payroll they check information and keying, but once it enters system then it s official. Once paycalc is run time sheet can t be updated. 1.B.6(1) System Documentation: routine performance of system backups appropriate labels 1.B.6(2) System Documentation: routine performance of system backups secure, off-line, off-site storage 1.B.6(3) System Documentation: routine performance of system backups periodic integrity tests Date: 12 March 1999; 26 March 1999 Page 10

11 1.B.7(1) System Documentation: routine performance of quality assurance and control checks (incl. audit trails) Rationale / tes 1.B.7(2) 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 for hardware, for software Don t power-down machines as often as they should probably. Don t know how they could do software checks. Don t use identification devices 1.B.7(3) 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 Should do this. 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 Should did old system to new. Prepared crosswalks for old to new codes record components requirement not applicable in this case What other systems might records be migrated to? Date: 12 March 1999; 26 March 1999 Page 11

12 1.B.9(1) System Documentation: standard training for all users and personnel with access to equipment Rationale / tes 1.B.9(2) System Documentation: standard training users should sign statements agreeing to terms of use, for Should consider? Maybe -- important for privacy data, etc. Who can invoke change mechanisms for object, process, and user security levels? System administrator by request is in place and is important Who (creator, current owner, system administrator, etc.) can grant access permission to an object after the object is created? Depends on what the object is different levels of security How does the system accommodate integration of records from other systems? 2. System administrators should establish, document, and implement security measures 2.A.1(1) System Security User Authorization: user identification and access procedures should be established and documented Date: 12 March 1999; 26 March 1999 Page 12

13 2.A.1(2) System Security User Authorization: users should be authenticated prior to being granted access Rationale / tes 2.A.2(1) System Security User Authorization: unique identifier and password for each user 2.A.2(2) System Security User Authorization: identifiers and passwords not used more than once within a system and Administrators can log on to multiple terminals at once. Passwords can t be used by the same individual more than once 2.A.2(3) System Security User Authorization: use of access scripts with embedded passwords limited and controlled Don t allow and shouldn t 2.A.2(4) 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(5) 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 Date: 12 March 1999; 26 March 1999 Page 13

14 2.A.3(1) System Security User Authorization: password rules include minimum password length, expiration dates, and limited number of log-on attempts Rationale / tes 2.A.3(2) 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 Is there a help desk or group that offers advice and can respond to security incidents in a timely manner? 2.A.4 System Security User Authorization: users to only level of access necessary to perform their job duties 2.A.5(1) 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(2) System Security User Authorization: modification of record identifiers prohibited Needs further group discussion Employee id #s would be example for HRIS certain people can delete erroneous ids such action documented by audit trail. Date: 12 March 1999; 26 March 1999 Page 14

15 2.A.6 System Security User Authorization: Access to private keys for digital signatures limited to authorized personnel 2.A.7(1) System Security User Authorization: maintenance of lists of all current and past authorized users along with their privileges and responsibilities Rationale / tes Maybe Future issue. 2.A.7(2) 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 List internal and external user groups and the types of data created and accessed Have all positions been reviewed for security level? As changes occur review whole list at that time HRIS has categories of users. Disable person who leaves usually their replacement is added with same security profile. Date: 12 March 1999; 26 March 1999 Page 15

16 2.A.8(1) 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. Rationale / tes In the sense that everyone gets a paycheck, no. But have separation of duties. one can do anything to their own record. But what about creating fake employees and getting fake checks? 2.A.8(2) System Security User Authorization: individual should have the ability to single-handedly 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 What are the procedures for the destruction of controlled-access hardcopies? 2.B.3(1) Internal System Security: controls in place to ensure proper security levels of data when archiving, purging, or moving from system to system, some The office areas are behind locked doors, but documentation within area not controlled. Date: 12 March 1999; 26 March 1999 Page 16

17 How is information purged from the system? Rationale / tes 2.B.3(2) Internal System Security: controls in place for the transportation or mailing of media or printed output 2.B.4(1) Internal System Security: procedures for the complete sanitization and secure disposal of hardware when no longer needed. PCs must be wiped in some departments. Required by city. 2.B.4(2) Internal System Security: procedures for the complete sanitization and secure disposal of software when no longer needed 2.B.4(3) Internal System Security: procedures for the complete sanitization and secure disposal of storage media when no longer needed 2.B.4(4) Internal System Security: documentation of sanitization and secure disposal should include date, equipment identifiers, methods, personnel names How is reuse prevented?? control over floppies, but important for private data. Want to control leaving building?? Need to have a policy. Separate from issue of whether data is trustworthy in legal world? Date: 12 March 1999; 26 March 1999 Page 17

18 2.B.5(1) Internal System Security - insecurity-detection mechanisms constantly monitoring the system 2.B.5(2) Internal System Security: failsafes and processes to minimize the failure of primary security measures in place at all times, in terms of limited password attempts Rationale / tes 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 In terms of room access, structure, fire safety 2.B.8 Internal System Security: security administration personnel undergo training to ensure full understanding of the security system s operation HRIS would be security administrator 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) Date: 12 March 1999; 26 March 1999 Page 18

19 2.C.2 External System Security: for records originating outside of the system, the system should be capable of verifying their origin and integrity Rationale / tes PRS would be outside. Different levels of controls depending on outside system. 2.C.2.a External System Security: non-system records verification of sender or source At a minimum need to know source system. 2.C.2.b 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.c 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 Hard to do. 2.C.2.d External System Security: non-system records detection of viruses Date: 12 March 1999; 26 March 1999 Page 19

20 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? Rationale / tes What is tracked? What is important? Benefits has independent paper audit trails in enrollment forms. In other areas built into system so not separate. can run employee history reports. HR -- Database files/audit reports checked periodically -- Separate audit trails in paper for things requiring authorization/signing run queries occasionally to check inputs. Payroll has hard-copy register reflecting what s on-line and kept for 50 years also runs queries all the time to check on accuracy of inputs. HRIS team members, system administrators ne Who can add audit data? Who can delete audit data? Data entry people cause audit trail entries. Can add comments as part of record and those can be changed. ne Date: 12 March 1999; 26 March 1999 Page 20

21 How can the audit logs be read? Who can read audit data? Rationale / tes Day-to-day changes (selected items) are kept on the system and dumped every 3 months onto paper and then audit database purged. Audits are on paper. All job data. By data set and then by date and then by alphabetical order by login ID of input operator. Can only see online what date a document was changed have to go to hard-copy to get to operator identifications, etc. Need retention schedule for these? HRIS team What tools are available to output audit information? What are the formats? Computer print-outs Who can output audit information? HRIS team What mechanisms are available to designate and change activities chosen for audit? Who is able to designate and change activities chosen for audit? HRIS team 3.A Audit Trails: if audit trails are encoded to conserve space, the decode mechanism must always accompany the data Dumped off to conserve space, but not compressed. Date: 12 March 1999; 26 March 1999 Page 21

22 3.A.1(1) Audit Trails General Characteristics: audit trail software and mechanisms subject to strict access controls Rationale / tes 3.A.1(2) Audit Trails General Characteristics: audit trail software and mechanisms protected from unauthorized modification 3.A.1(3) Audit Trails General Characteristics: audit trails protected from circumvention How are audit trails protected? 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 System set up to record information automatically. Dumped onto paper. If system crashes, most they would lose is a day s worth of work daily backups. 3.A.3(1) Audit Trails General Characteristics: system automatically notifies system administrators when audit storage media nearing capacity. Response documented Indirect notification performance slows down. Document dump to paper and purge (every three months or so). Date: 12 March 1999; 26 March 1999 Page 22

23 3.A.3(2) 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 One paper copy in locked room, one in Linda s office (in a secure area) for reference. Very coded, but not highly sensitive material. Perhaps can and should store offsite. 3.B Audit Trails Password Usage and Changes 3.C(1) Audit Trails Users: system in place to log and track users and their on-line actions Tracked in system, but not in audit report. Different security levels for different areas tracked in online security tree. Can track security levels for individuals and dates. 3.C(2) Audit Trails Users: users made aware that their use of computerized resources is traceable 3.C(3) Audit Trails Users: users supplied with Tennessen Warning when collecting confidential and private data by any means for paper Should be on HRIS documents, but not always there. Only necessary when asking for information about the individual themselves. Will be put on hire forms, applications, personal data updates. Need to keep listed purposes updated. Carol will look into this further about when it s required. Date: 12 March 1999; 26 March 1999 Page 23

24 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) Track all Rationale / tes 4. System administrators should establish a comprehensive disaster recovery plan 4.A Disaster Plan: periodically reviewed for currency and tested for efficiency Have nightly backups. Where are the backup tapes held? Off-site? Are the backup tapes tested for recovery at periodic intervals? See above. 5(1). For each record: original content and format, context, and structure preserved regardless of the system or media on which the record is retained You can display the information, but not in original form. Carol says she s read somewhere that it s desirable. 5(2). 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 Must keep links together. Date: 12 March 1999; 26 March 1999 Page 24

25 5(3). 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 Rationale / tes What are the current components of a complete or final record of the transaction? What are the minimal components necessary to provide evidence of the transaction? (if you went to court, what would be the minimum information you would need?) Are there any laws, regulations, or professional best practices that specify the structure (including medium, format, relationships) of the record of the transaction or any of its components? What information is necessary to interpret the contents of the record? During which agency business processes might you have to access this record? Who are the external secondary users of the record? Date: 12 March 1999; 26 March 1999 Page 25

26 What are the rules, laws, and regulations that restrict or open access to these records to external users? Rationale / tes How will the record be reproduced to meet the needs of internal and external secondary users? Is there a mechanism in place to indicate sensitivity level on hardcopies? Who can enable/disable this function? What is the records disposition plan? Who is responsible for authorizing the disposition of records? Who is responsible for changes to the records disposition plan? Who can access metadata? Who can alter metadata? Who can delete metadata? Who can add metadata? 5.A. 1 Record metadata: unique identifier Date: 12 March 1999; 26 March 1999 Page 26

27 5.A. 2 Record metadata: date of creation 5.A. 3 Record metadata: time of creation 5.A. 4 Record metadata: creator / agency / organization 5.A. 5 Record metadata: documentation of creator s authorization 5.A. 6 Record metadata: date of modification 5.A.7 Record metadata: time of modification 5.A. 8 Record metadata: modifier / agency / organization 5.A. 9 Record metadata: documentation of modifier s authorization Rationale / tes Carol says legal requirement need to know the original date when form filled out as well date inputed. Date form filled out not currently captured on computer but should be (do keep paper copies). 5.A. 10 Record metadata: indication of authoritative version NA Multiple versions in Payroll, but new overwrites old dated/timed, but no version indication. Date: 12 March 1999; 26 March 1999 Page 27

28 5.A..11 Record metadata: identification of originating system Rationale / tes Just know by file type 5.A.12 Record metadata: date of receipt from outside system Recorded elsewhere 5.A.13 Record metadata: time of receipt from outside system Recorded elsewhere 5.A.14 Record metadata: addressee 5.A.15 Record metadata: system or mechanism used to capture record from outside system Recorded elsewhere 5.A.16 Record metadata: protection method? Will look into this 5.A.17 Record metadata: media type? Will look into this 5.A.18 Record metadata: format? Will look into this 5.A.19 Record metadata: location of record 5.A.20 Record metadata: sensitivity classification? Will look into this? Will look into this Date: 12 March 1999; 26 March 1999 Page 28