USC Data Security Requirements (Standards) Guidelines for Compliance Revised 05-Jan-2015

Transcription

1 USC Data Security Requirements (Standards) Guidelines for Compliance Revised 05-Jan-2015 The purpose of these Guidelines is to assist in the interpretation of USC Data Security Requirements, and in the implementation of compliant controls and practices. The standards are shown in black. Guidelines for compliance are in blue. Section 1 System Management 1.1 Define ownership and appropriate use Awareness of your inventory of assets is a critical first step in assessing your information security risk. Without a clear understanding of the assets which are at risk there can be no clear understanding of the amount of risk [i]7.1.1 Assets documented: application software used for University data [i]7.1.1 Assets documented: university data identified by sensitivity and authoritative Data Steward [i]7.1.1 Assets documented: computer equipment The purpose of asset documentation is to ensure that knowledge is shared by more than one person. In the event of staff absence or turnover, this knowledge must still be available. Any method of documentation that accomplishes this purpose is acceptable [i]7.1.2 Ownership and responsibility for assets are documented and periodically reviewed [p] Personnel with access to assets are documented Ownership, responsibility, and access should in most cases be documented by employee role or other classification, rather than by individual name. e.g. Owner: department IT manager or End-user access granted to all employees with HR-related job duties [p] Devices are labeled to indicate owner, contact info, and purpose The purpose of labeling is to facilitate identification of devices for those who do not routinely use them. Any method which achieves this result is acceptable [i]7.1.1 Assets documented: computing and communication services Computing and communication services refers to data and communication service providers and related equipment Mechanism to assist in the tracking of and discovery of sensitive data on system are implemented See UISO Data Loss Prevention Procedure. Page 1 of 13

2 1.2 Information backup [i] Backup copies of information and software are made Backups are important primarily to business continuity. As such, absence of backups should not be assessed as a risk to data exposure, and therefore of LOW risk in regard to granting of data access [i] Backup copies of sensitive data are securely encrypted Where backups are made, encryption is critical for backups containing sensitive data (Limited Access or Restricted data elements; see Data Access Requirements document in the Information Security Program website). Unencrypted backups of sensitive data should be assessed as HIGH risk in regard to granting data access [i] Backup plan includes: define level of backup information, keep accurate records of backups made, plan granularity (full/differential, frequency), keep backup media off site, protect backup media, test backup media, test restore procedures [p]9.5 Observe offsite storage facility to verify security and confirm annual review 1.3 Logging System time is accurately synchronized (e.g. with NTP) Security relevant events are logged: user activity, critical system changes, critical data changes Daily review of logs by manual or automated means Keep logs for at least 3 months Logs with accurate timestamps are important for investigation of security incidents. A lack of accurate logs may lead to a liability for notification in cases where the extent of information disclosure (breach) cannot be determined. For most Linux systems, security-relevant events are logged by default. In most Windows platforms security event logging must be enabled by an administrative user Keep logs for at least 12 months Real-time log review Free tools such as OSSEC are available for automated real-time log review [p]10.1 Establish process to link access to user id [p] Establish audit trail for all actions of admin users [p] Log creation and deletion of system objects [p]10.3 Record these data for each event logged (where relevant): user id, event type, data and time, success/failure, origination, identify affected items [p]10.7 Retain audit trails for at least 12 months For through , ideally any security-relevant action taken at the OS, service, or application level should be logged with enough information to trace the action back to the user and/or location (IP address or console) from which it was performed. Page 2 of 13

3 1.4 Password Management [i] Passwords must be stored encrypted or hashed [i] Vendor default passwords are changed as soon as practical [i] User identity is verified prior to processing password set/reset [i] Users sign statement of password confidentiality [i] Users required to follow good security practices in selecting and using passwords [i] Any passwords provided to users must be complex and unique, must be communicated to user securely, and must be changed by user on first login Safekeeping of user password data is critical because loss of credentials is one of the most frequent causes of information security incidents. Managing accounts using USC enterprise identity management services will satisfy these requirements [p]2.1 Change vendor default identifiers, such as SNMP community string, SSID, encryption keys 1.5 OS Secure Authentication This section of standards refers to administrator logins [i] OS login process includes: no display of password during entry, no cleartext transmission of password [p] Logging of OS authentication success/failure [p]8.5.13,14 Lock out account after at most 6 consecutive unsuccessful login attempts. lock out for at least 30 minutes For 1.5.3, logins performed using USC enterprise authentication services will satisfy this requirement [i] OS login process includes: no display of system/application identifiers until logon successful, displays a warning about unauthorized access, no help messages during logon, validate credentials only after all inputs are received, display previous logon upon successful logon [i] Inactive session timeout Page 3 of 13

4 1.6 System Security OS and application security patches installed as soon as practical Applications and services must be patched promptly, because unpatched application vulnerabilities are the most common avenue of system compromise [p]6.3.1 Development stage data and accounts removed before production stage [p]2.2.3 Configure system security parameters to prevent misuse OS services and policies must be configured in consultation with authoritative standards, such as those published by the Center for Internet Security (cisecurity.org) [i] Software installation controls include: updates performed only by trained administrators with management authorization, rollback strategy, audit log of code changes [i] Software installation controls include: OS limited to approved services, applications thoroughly tested, configuration control system, retain previous versions of applications for all archived data versions Limit scope of trust relationships between systems [i] Test data is selected carefully, protected, and controlled; avoid use of production data [p]2.2.4 Remove unnecessary services 1.7 Vulnerability Management [i]12.6 Vulnerability management: establish resources to identify vulnerabilities, identify risks to organization for discovered vulnerabilities, address vulnerabilities according to plan [i]12.6 Vulnerability management: establish roles for vulnerability management, establish timeline to respond to vulnerabilities, evaluate impact of vulnerability remediation before implementing, test remediation method before installing in production [p]11.2 Scan for vulnerabilities quarterly and after significant changes Applications and services must be patched promptly, because unpatched application vulnerabilities are the most common avenue of system compromise [p]11.3 Perform penetration testing yearly and after significant changes Page 4 of 13

5 1.8 Malicious Code Protections [i] Malicious code protections: policy prohibiting use of unauthorized software, periodic review of installed software, installation of anti malware software, establish procedure for responding to malware detection Software should not be installed without approval of appropriate IT staff. If malware is detected on systems that contain or process Restricted Data (see Data Access Requirements document in the Information Security Program website), contact the University Information Security Office before taking any countermeasures [i] Malicious code protections: policy restricting software sources, establish contingency plans for losses due to malware infection, maintain awareness of malware threats [p]5.2 Monitor correct function of anti malware software, and log its activity 1.9 Data Validation This section of standards applies only to software development and testing [i] input data validation: evaluate inputs for value range, valid characters, completeness, data length/volume limits [p]6.5 Design/test applications: avoid injection flaws, buffer overflow, directory traversal [p]6.5 Design/test applications: avoid insecure cryptographic storage, insecure communications, data leakage via error messages, cross site scripting and forgery, unsecured URL access [i] input data validation: establish procedures for responding to validation errors, establish procedures to test plausibility of input data, define responsibilities of personnel involved in data entry, log all data entry [i] output data validation: reconciliation controls, provide sufficient data to allow reader to verify accuracy [i] input data validation: periodic review of data, inspecting hardcopy for unauthorized changes [i] output data validation: includes test plausibility of output data values, establish procedures for responding to validation errors, define responsibilities of personnel involved in data output, log data output validation Page 5 of 13

6 1.10 Encryption [p]8.4 Passwords are encrypted during transmission or storage Safekeeping of user password data is critical because loss of credentials is one of the most frequent causes of information security incidents. Managing accounts using USC enterprise identity management services will satisfy these requirements [p]2.3 Encrypt all administrative access Administrative access must only be conducted across an encrypted connection (e.g. HTTPS, SSH, encrypted RDP) [p]4.1 Data are encrypted over public networks Public networks refers to any networks beyond university control [i] Data is encrypted in motion In motion refers to any network connection Mechanism to render unsecured sensitive information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals This refers to encryption of data at rest and in transit Production Controls [i]6.2.2 prior to customer access, these controls are addressed: asset protection, product or service is well described, requirements and benefits for customers, access control policy, procedures for reporting and investigation of inaccuracies and breaches, descriptions of all services, target level of service, disclose right to monitor, disclose liabilities of organization and customer, disclose legal responsibilities, disclose intellectual property rights Production controls are important primarily to business continuity. As such, absence of these controls (except those that are also mentioned elsewhere in this document) would not be assessed as a risk to data exposure, and therefore of LOW weight in regards to granting of data access Security Incident Reporting [p]12.9 Establish incident response plan including roles, response procedures, recovery/contingency procedures, data backup/recovery processes, document legal reporting requirements [i] Security incidents reported through appropriate command channels, including suitable feedback mechanisms to satisfy those reporting incidents and incident reporting form to ensure uniform and complete collection of details [p] Document incident response procedures The university s incident response procedure is documented on the Information Security Program website. Each business unit must understand its role in the procedure in case of its involvement in a security incident. Page 6 of 13

7 Section 2 Policy and Documentation 2.1 Third Party Access 3P access (third party access) refers to any access to university data by a external contractor or other entity, either accessing data contained in a university system, or by receiving a copy of university data [i]6.2.1 Evaluate 3P access requirements: enumerate types of access and assess the sensitivity of data to be accessed [i]6.2.3 Terms included in 3P agreements: controls for asset protection, responsibilities regarding hardware and software, access controls, incident reporting process, establish process for problem resolution [i]6.2.3 Terms included in 3P agreements: information security policy, training in security issues, awareness of information security responsibilities, provision for transfer of personnel, clear reporting structure and reporting formats, clear process of change management, description of product or service to be provided, target level of service, definition of performance criteria, disclose right to monitor, disclose right to audit, service continuity requirements, liabilities of parties, legal responsibilities, intellectual property rights, involvement with subcontractors, conditions of renegotiation or termination [i]6.2.1 Evaluate 3P access requirements: enumerate facilities a 3P is required to access, enumerate 3P personnel, document controls for secure storage and exchange of data with 3P [i]6.2.1 Evaluate 3P access requirements: document controls to limit access, document how 3P personnel identity can be verified, assess impact of loss of access by 3P, establish procedures for incident response involving 3P, document legal requirements regarding 3P, document impact to stakeholders for use of 3P 2.2 Operational Procedure [i] Document operating procedures: processing and handling of information, backup, scheduling and interdependency, handling of errors and exceptions, support contracts, special output and media handling, restart and recovery procedures, management of audit trail and logging [p]12.2 Document daily operational security procedures For and 2.2.2, these controls are important primarily to business continuity. As such, absence of these controls (except those that are also mentioned elsewhere in this document) would not be assessed as a risk to data exposure, and therefore of LOW weight in regards to granting of data access. Page 7 of 13

8 2.3 Access Control Policy [i] Access control policy: enumerate all data and risks [p]8.2 In addition to unique id, require at least one factor of authentication, e.g. password, hardware token, biometric Use of username and password for authentication satisfies item 2.3.2, as does username plus key-pair authentication [p]8.5.1 Control and audit creation, modification, and deletion of user credentials [p] Require passwords to contain at least 7 characters [p] Require passwords to contain alphabetic and numeric characters Complex passwords are important to reduce the risk of password guessing or cracking. Complexity requirements should be enforced through automated means. Requiring punctuation as an alternative to one of the character types described in is acceptable. Managing accounts using USC enterprise identity management services will satisfy these requirements [i] Access control policy: security requirements of individual applications, data classifications and policies for dissemination consistent across all systems, document legal requirements for data, document user profiles by role, document management of access rights, segregate access control roles, require formal authorization of access requests, periodic review of access controls, proper and timely removal of access rights [p]7.1 limit access rights to least necessary [p]7.2 establish access controls for system components Multifactor authentication mechanism to substantiate the claimed identity of a user Multifactor authentication requires a 2 step verification process prior to granting access. 2.4 Regulatory Compliance [i] Identify requirements of all applicable laws, contracts, and other regulation e.g. FERPA, HIPAA, GLBA, PCI DSS [i] Managers ensure compliance with all applicable security policies Managers must ensure that all employees are aware of security policies, and agree to follow them. 2.5 User Registration and Deregistration [i] User registration: unique user id, verify access authorization with system owner, give user written statement of access rights, immediate removal or blocking of access when job duties no longer require it, periodic audit of user ids and access rights [p]7.1.3 Formal documented approval of user access and level of privileges by appropriate system manager [i] User registration: level of access matches business needs, user signs statement of access conditions, ensure authorization process is complete before access is granted, formal record of all registered users Page 8 of 13

9 Access to university systems must be approved by Data Stewards, either individually (e.g. user John Smith) or by blanket authorization (e.g. all students, all supervisors, all employees in department X, etc.) Page 9 of 13

10 2.6 Support Processes [i] change control procedures: record of agreed change authorization levels, ensure changes are submitted by authorized users, identify all components that require change, maintain version control for software updates, ensure change timing has minimal impact on business [i] change control procedures: review controls to ensure integrity is not compromised by change, obtain formal approval before change is made, ensure authorized users accept change prior to implementation, ensure system documentation is updated, audit trail of all change requests [i] technical review for system changes: review application integrity controls, ensure timing of change will allow for testing [i] technical review for system changes: verify vendor support plans will continue, ensure business continuity plans are updated [p]6.4 change control includes: separate development/test and production environments, separation of duties for dev/test and production, production data not used for dev/test, test data removed before production For through 2.6.5, these controls are important primarily to business continuity. As such, absence of these controls (except those that are also mentioned elsewhere in this document) would not be assessed as a risk to data exposure, and therefore of LOW risk in regard to granting of data access. 2.7 Information Exchange [p]9.7.2 For physical shipment of data, courier has established tracking methods [i] information exchange policies: procedures designed to prevent interception, copying, modification, misrouting, or destruction; procedures for detection and protection from malicious code; policy outlining acceptable use; procedures outlining secure usage of wireless technology; retention and disposal guidelines for correspondence [i] information exchange policies: procedures for protecting sensitive data attachments; statement of employee/contractor responsibilities; encryption where appropriate; prompt retrieval of sensitive data from shared printers; restrictions on forwarding of ; caution personnel about protection from eavesdropping; caution personnel about leaving voice messages with sensitive information; cautions about usage of fax; cautions about giving demographic data to vendors [i] Establish exchange agreements with external parties, to include responsibilities for coordinating exchange, procedures for exchange notification, procedures to ensure auditability, minimum standards for packaging and transmission, escrow agreements, courier identification, responsibilities and liabilities in case of incidents, agreed labeling for sensitive/critical data, responsibilities for data protection, copyright, and licensing, standards for recording/reading software, special controls for sensitive data [i] Physical media in transit includes reliable courier, list of authorized couriers, procedure to check courier id, packaging to physically protect contents, protection of sensitive data Page 10 of 13

11 Section 3 Unauthorized Access Prevention 3.1 Physical Controls [i]9.1.1 Locked cabinet or room To qualify for control 3.1.1, the guidelines in the Physical Security Guidelines document in the Information Security Program must be followed cc Alternative for requirement 3.1.1: If data are encrypted at rest, and decryption keys are securely managed, these provisions may serve as a compensating control for lack of compliance with requirement To qualify for compensating control 3.1.1cc, the guidelines in the Whole Disk Encryption Guidelines document in the Information Security Program must be followed [p]9.1.2 Restrict physical access to network jacks [p]9.1.3 Restrict physical access to wireless hardware [p]9.1.1 Video camera or other auditable access record 3.2 Sanitization of Equipment [i]9.2.6 Storage media securely erased or destroyed prior to disposal Secure erasure must accomplish at least one full pass of overwriting with zero or random data [p] Shred or incinerate hardcopy of data Shredding must be crosscut. If shredding service is contracted, it must be through a certified contractor, using locked shred bins. 3.3 Protection of Media [i] Management of removable media: prior to disposal, removable media are securely erased or destroyed [p]9.6 Physically secure hardcopy of data Hardcopy of sensitive data must never be placed where it is visible to those who are not authorized to see it [i] Management of removable media includes removable media are securely erased or destroyed, authorization required for removal of media from premises, media stored in physically secured location, consider expected lifetime of media when designing retention plan, maintain records of removable media, removable media drives only enabled if needed [p]9.9.1 Conduct annual physical audit of removable media Page 11 of 13

12 3.4 Mobile Security [i] Establish formal policy for information security as regards mobile computing Employees must understand their responsibilities for data security when accessing university systems or data via mobile devices [i] Establish formal policy for working from remote locations, including physical security of remote site, communications security requirements, consider risk of unauthorized physical access, establish policy on use of privately owned equipment, require anti malware and firewall Employees must understand their responsibilities for data security when accessing university systems or data from remote locations. Section 4 Networking 4.1 Network Management Controls [i] Require authentication for remote access Authentication by VPN qualifies for control 4.1.1, as will authenticated connections via HTTPS, SSH, or encrypted RDP [i] Segregate network segments by services, users, or system function Ideally network segments should be separated using VLANS or router ACLs. 4.2 Restriction of Network Access [i] Restrict access to network segments based on business need A system containing sensitive data must not be placed on a subnet that permits connection of non-employee devices, unless that system is protected by firewall or other method that blocks all but the necessary inbound connections. Page 12 of 13

13 4.3 Isolation of Services and Data [i] Sensitive systems use isolated resources [p]2.2.1 Servers are dedicated to single services (e.g. web server, db server) For and the most important issue is that any server handling sensitive data must not be used for high risk services such as public information websites (or content management systems), file shares, , FTP, or similar. The isolation requirement may be satisfied by using separate physical or virtual servers University data stored, received, or processed by this system is not shared with any other system unless that system also undergoes a security assessment and receives Data Steward approval. Data Stewards grant permission only for a specific usage of university data on a specific system. If a different usage of the data is desired, that new usage must be requested. If that usage involves a different computer, that computer must undergo a separate security assessment. 4.4 Network Security [p]11.4 Use intrusion detection/prevention systems Systems located on the Columbia campus are in most cases monitored by the UISO s network intrusion detection system, which meets requirement Qualifying host-based protection may be available with some free products such as OSSEC [i] Network management: establish controls to secure sensitive data traffic, log activity as necessary to record security relevant events For systems on the Columbia campus, UISO s network logging facilities meet this requirement In other locations, firewall logs and network flow logs may be used to meet this requirement [i] Network management: network management responsibilities separated from computer management, establish responsibilities for management of remote equipment, ensure network is configured to perform optimally and consistently Network administrators must understand network security issues and be able to effectively implement measures to reduce the risk of such threats as rogue routers, open wireless, and malicious ARP and DHCP activity. Any network management plan that addresses these needs will meet requirement [p]1.1.6 Review firewall and router rule sets every 6 months [p]6.6 Review public facing web interfaces at least annually, to find vulnerabilities Page 13 of 13