Security Logging and Monitoring...

Submittal Form CSystem Security Plan

For:Minnesota Department of Natural ResourcesFMS RFP

Version 1.0

5 Secure Configuration Controls

Table of Contents

1. SECURITY LOGGING AND MONITORING CONTROLS..................................................................................................................................................................... 2

2. IDENTITY AND ACCESS MANAGEMENT CONTROLS...................................................................................................................................................................... 6

3. CONTINGENCY PLANNING CONTROLS....................................................................................................................................................................................... 13

4. NETWORK SECURITY CONTROLS................................................................................................................................................................................................ 16

5. SECURE CONFIGURATION CONTROLS........................................................................................................................................................................................ 16

6. SECURE SYSTEMS DEVELOPMENT AND ACQUISITION CONTROLS............................................................................................................................................... 23

7. THREAT AND VULNERABILITY MANAGEMENT CONTROLS.......................................................................................................................................................... 25

InstructionsFor each requirement indicate Yes, No or NA as to whether the proposed solution meets the requirement. You must indicate Yes, No, or NA.

If Yes, please explain how the requirement is met. If No, please explain why the requirement is not met and any plans to remediate this control deficiency. If the requirement is not applicable (because the solution is not a SaaS, for example), use “NA” and explain why the requirement is not

applicable.

1. Security Logging and Monitoring Controls# Control Name Control Detail Response1 Logging Implement automated logging on all systems to

reconstruct the following events:

All actions taken by accounts with root or administrative privileges.

Access to all log data.

All log-in attempts.

Use of and changes to identification and authentication mechanisms—including but not limited to creation of new accounts and elevation of privileges—and all changes, additions or

2 document.docx


# Control Name Control Detail Response

deletions to accounts with root or administrative privileges.

Initialization, stopping or pausing of the logs.

Creation and deletion of system-level objects.2 Logging Individual

User AccessLog all individual user access to data with a data protection categorization of High.

3 Content of Log Records

Logged events must contain the following information:

User identification.

Type of event.

Timestamp.

Success or failure indication.

Origination of event.

Identity or name of affected data, system component or resource.

4 Log Processing Failure

Systems must provide alerts in the event of a log processing failure.

6 Clock Synchronization

Synchronize all system clocks to a designated internal time source that is accurate to the approved authoritative time source.

7 Protection of Logs Logs must be secured by:

Limiting viewing to those with a job-related need.

Protecting log files from unauthorized modifications.

Encrypting the logs in transit.

Requiring log configuration changes to be approved by authorized security personnel.

8 Centralized Log An authorized central log server must be in place that:

3 document.docx


# Control Name Control Detail ResponseServer Collects/receives log data from systems that store,

process or transmit data with a data protection categorization of High.

Collects/receives log data from systems/software that perform security functions including but not limited to firewalls, intrusion detection systems/intrusion prevention systems, authentication servers and anti-malware software.

Collects/receives log data in as near real time as is appropriate for the log source.

Provides log reduction and normalization.

Does not alter the original content or time ordering of the log data.

Stores logs in their raw format to support investigative evidence.

Ensures the confidentiality, integrity and availability of stored logs.

Monitors the availability of log sources.

Alerts authorized security personnel of inappropriate or unusual activities.

10 Integrity Monitoring Centrally managed integrity monitoring must be in place to detect and alert on unauthorized changes to:

Critical system files.

Critical application files.

Security log files.

Integrity monitoring events must be continuously forwarded to an authorized central log server.

4 document.docx


# Control Name Control Detail Response11 Configuration

CheckingCentrally managed configuration checking must be in place to detect and report on system compliance to security configuration baselines.

13 Host Intrusion Detection and Prevention

Host intrusion detection/prevention software must be in place on systems that store, process or transmit Federal Tax Information (FTI), where technically possible, to monitor for attack attempts and potential compromises. This software must:

Be actively running.

Prevent users from disabling or altering the software.

Generate event logs and continuously forward to an authorized central log server.

Be centrally managed.15 Anti-Malware

SoftwareAnti-malware software capable of detecting, removing and protecting against all known types of malicious software on all systems commonly affected by malicious software and at critical points throughout the network. This software must:

Be actively running.

Prevent users from disabling or altering the software.

Generate event logs and continuously forward to an authorized central log server.

Automatically check for and install updates at least daily.

Perform scans of the system at least weekly and real-time scans of files from external sources at endpoint and network entry/exit points as the files

5 document.docx



are downloaded, opened or executed.

Either block or quarantine malicious code and send an alert to the administrator in response to malicious code detection.

Be capable of addressing the receipt of false positives.

Be centrally managed.

2. Identity and Access Management Controls# Control Name Control Detail Response1 Access Control All access to systems or data, other than read only access

to data with a data protection categorization of Low, must be controlled through the use of identification and authentication mechanisms. This access control must:

Assign privileges to individuals based on the individual’s job classification and function.

Restrict privileges to the least needed for the individual or service to perform their role.

Deny all access that is not explicitly granted.

Remove all system access not explicitly required.2 Unique IDs All users must be assigned a unique ID to access systems

or data. IDs must not be reused for at least 10 years. 3 Device, Service and

Application AccountsDevice, service and application accounts must be assigned to an account owner and must not be used by individuals to access the system.

6 document.docx


# Control Name Control Detail Response4 Access Approval Requests to create or modify accounts and access

privileges must be documented and approved by authorized personnel before access can be granted. Each request for access must define access needs including:

Systems and data that each user needs to access for their job function.

Level of privilege required (for example, user, administrator, etc.) for accessing resources.

7 Revoke Access Accounts and privileges that are no longer required must be removed or disabled within:

8 hours of notification or identification of voluntary changes in access.

1 hour of notification or identification for users that have been involuntarily terminated or for accounts with credentials that may have been lost or compromised.

8 Emergency Accounts Emergency and temporary accounts must be disabled within 24 hours.

9 Privileged Accounts Privileged IDs must be: Approved by the system owner. Assigned only to users that specifically require

such privileged access. Restricted to least privileges necessary to perform

administrative responsibilities. Granted access to only the system utilities that are

needed. Authenticated using multifactor authentication

when accessing systems with data protection categorization of High.

Prohibited from changing privileges to another

7 document.docx


# Control Name Control Detail Responseuser ID either for themselves or another user without authorization.

10 Separate Administrative Account

Privileged IDs must only be used when performing authorized administrative tasks. Non-privileged accounts must be used when performing all other tasks.

11 Segregation of Duties Access privileges must allow for the appropriate segregation of duties by:

Segregating duties of individuals as necessary, to prevent malicious activity without collusion.

Ensuring that audit functions are not performed by personnel responsible for administering access control.

Maintaining a limited group of administrators (i.e. system administrators, application administrators, security administrators) with access based upon the users' roles and responsibilities.

Ensure that critical functions and system support functions are divided among separate individuals.

Ensure that system testing functions and production functions are divided among separate individuals or groups.

12 Vendor Access Accounts used by vendors to access, support or maintain system components via remote access must be:

Enabled only during the time period needed. Disabled when not in use. Monitored when in use.

13 Group Accounts Group, shared or generic IDs, passwords or other authentication methods must be restricted as follows:

Generic user IDs must be disabled or removed. Shared user IDs must not exist for system

8 document.docx


# Control Name Control Detail Responseadministration and other critical functions.

Shared and generic user IDs must not be used to administer any system components.

Passwords and other credentials for group/role accounts must be changed when someone leaves the group/role.

14 Authentication All users and administrators must be authenticated on all systems by using at least one of the following methods:

Something you know, such as a password or passphrase.

Something you have, such as a token device or smart card.

Something you are, such as a fingerprint.15 User Validation The user’s identity must be properly validated before

modifying or communicating any authentication credential—for example, performing password resets, provisioning new tokens or generating new keys.

16 First Time Passwords First-time use and reset passwords/phrases must be: Set to a unique value for each user. Changed immediately after the first use.

17 Password Encryption All authentication credentials (such as passwords/phrases) must be encrypted during transmission and storage.

18 Password Length Passwords must be at least: 8 characters long for user accounts and all

mainframe accounts. 12 characters long for privileged accounts. 14 characters long for device, service and

application accounts.19 Password Complexity Passwords must contain at least:

3 of the 4 character types below for user accounts and all mainframe accounts.

9 document.docx


# Control Name Control Detail Response 4 of the 4 character types below for privileged

accounts and device, service and application accounts.

Character Types: Lower case letters. Upper case letters. Numbers. Special characters.

20 Minimum Password Age

Passwords/passphrases must be in place for at least 1 day.Mainframe account passwords must be in place for at least 5 days.

21 Maximum Password Age

Passwords/passphrases must be changed at least: Every 90 days for user accounts. Every 60 days for privileged accounts. Every 180 days for device, service and application

accounts. Every 30 days for mainframe accounts.

22 Password History New passwords/phrases must be different from at least the previous 24 passwords/phrases used by that account.

25 Non-Password Authentication

Where authentication mechanisms other than passwords are used (for example, physical or logical security tokens, smart cards, certificates, etc.), these mechanisms must be controlled as follows:

Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts.

Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access.

A defined registration process must be established for issuing, maintaining and retrieving hardware

10 document.docx


# Control Name Control Detail Responsetokens.

When issuing a hardware token the individual receiving the token must be authorized and verified in person by a designated official.

26 Mask Password All passwords must be masked (i.e., made unreadable) when being entered to prevent unauthorized individuals from viewing the password.

27 Account Lockout User and administrator accounts must be locked out after no more than:

3 consecutive invalid logon attempts by that user during a 24 hour period for systems with a data protection categorization of High

5 consecutive invalid logon attempts by that user during a one hour period for systems with data protection categorization of Moderate

10 consecutive invalid logon attempts by that user during a one hour period for systems with data protection categorization of Low

The account must remain locked for at least 30 minutes or until unlocked by an administrator.

28 Inactivity Timeout Sessions must be automatically locked after 15 minutes of inactivity. The user must be required to re-authenticate to reactivate the session.

29 Multiple Sessions Systems must prevent multiple concurrent active sessions for individual user accounts. System and application accounts must be limited to the number of concurrent sessions needed for their purpose and as documented in the system security plan.

30 System Use Notification

A warning banner must be displayed prior to granting access to all internal networks, applications, databases, operating systems, workstations, servers and network

11 document.docx


# Control Name Control Detail Responsedevices. Users must explicitly acknowledge the warning banner before being allowed access to the system. The system warning banner must include the following information:

The user is accessing a restricted government information system.

System usage may be monitored, recorded and subject to audit.

Unauthorized use of the system is prohibited and may be subject to criminal and/or civil penalties.

Use of the system indicates consent to monitoring and recording.

For publicly accessible systems a warning banner must be displayed before allowing access. The warning banner must include:

Notification of any monitoring, recording or auditing that may occur.

Description of the authorized uses of the system.For systems containing Federal Tax Information, the warning banner must reference the civil and criminal penalty sections of Title 26 Sections 7213, 7213A and 7431

31 Remote Network Access

All remote network access originating from outside the network by personnel (including users and administrators) and all third parties, (including vendor access for support or maintenance) must:

Be authorized. Authenticate using multi-factor authentication.

At least one of the factors must be provided by a device separate from the system gaining access. The use of software tokens is allowed.

33 Database Access All access to any database containing data with a data

12 document.docx


# Control Name Control Detail Responseprotection categorization of High (including access by applications, administrators and all other users) must be restricted as follows:

All user access to, user queries of and user actions on databases are through programmatic methods.

Only database administrators have the ability to directly access or query databases.

Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes).

34 Device Identification and Authentication

The system must uniquely identify and authenticate devices before establishing a connection.

3. Contingency Planning Controls# Control Name Control Detail Response1 Contingency Plan A contingency plan must be developed and maintained

that:

Includes the following information gathered from business process owners to develop recovery strategies:

o Recovery Time Objectives (RTO), Recovery Point Objectives (RPO) and restoration priorities.

o Impacts to the business process and its customers if the system is disrupted, compromised or fails.

o System users and their primary and alternate work locations.

o Key processing times during the week,

13 document.docx



month or year when system availability is especially important.

o Essential records stored or created by the system.

Documents roles, responsibilities and assigned individuals, including their contact information.

Addresses eventual, full system restoration, without deterioration of the security measures originally planned and implemented.

Documents user-level information, system-level information and security-related documentation backup frequency.

Aligns with incident response activities.

The plan must be reviewed and approved by IT leadership in conjunction with business owners.

9 System Backup Conduct backups of user-level information, system-level information and security-related documentation consistent with the defined frequency in the contingency plan.

Protect the confidentiality, integrity and availability of backup information at storage sites.

10 Security Breach Notification

The contract vendor shall notify the State’s Authorized Representative and the State’s Chief Information Security Officer of any actual or reasonably suspected security breach with 24 hours of any security breach affecting State purchased vendor systems technology components (e.g., server, authentication processes, system architecture, software).

Vendor must pay expenses for sending notification to users affected by the breach.

14 document.docx


# Control Name Control Detail Response Normal system operation must be restored within

48 hours of security breach occurrence. Vendor Incident Response Plan must include a

Breach Notification Plan.11 Identify Past Security

IncidentsVendor must identify any software, products or services included in your proposal that were included in a security incident in the past six years. Include the following information:

1. Incident date2. Incident description3. Component(s)4. Associated security issue5. Actions taken to resolve it6. Amount of time (if any) part or all of the system

was unavailable for use

4. Network Security Controls# Control Name Control Detail Response3 Firewall and Router

Rule SetsFirewall and router rule sets must:

Restrict connections between lower trusted networks and systems in higher trusted networks.

Restrict inbound and outbound traffic to only that which is necessary and specifically deny all other traffic.

Configure these firewalls to permit only traffic necessary for business purposes between the wireless environment and any systems with a data protection categorization of High.

8 DMZ Inbound Internet traffic must be restricted to a DMZ that is physically or logically separated from internal networks. The DMZ must only contain systems that are intended and

15 document.docx


# Control Name Control Detail Responseauthorized to be publicly accessible.

12 Network Placement All systems that store process or transmit State data must be located in network zones appropriate for their function and their protection requirements. System components that store data (such as a database) must be in an internal network zone, segregated from the DMZ and other untrusted networks.

5. Secure Configuration Controls# Control Name Control Detail Response1 System Inventory An inventory of all hardware and software must be

maintained. The hardware and device inventory must include:

Data protection categorization. Business owner. Business owner contact information. Physical location. Asset tag. Serial number. Operating system version. Make and model of the device. IP address if static. MAC address. Service delivery support team owner. Service delivery support team contact information. License Number.

The software and application inventory must include: Application name. Application ID. Data protection categorization.

16 document.docx


# Control Name Control Detail Response Business owner. Business owner contact information. Service delivery support team owner. Service delivery support team contact information. License Number. Host devices.

2 Approved Software and Hardware

A list of all approved hardware and software along with any usage restrictions must be documented and maintained. All approved software must be:

Legally licensed. Approved by MN.IT. Securely configured.

3 Unapproved Hardware and Software

Users must be prohibited from using unapproved hardware or software on State systems. Systems must be monitored for unapproved software. Any unapproved software or hardware must be removed.

5 Patch Management All systems including firmware, operating systems, applications and other software must be protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install security patches according to their severity:

Severity 1: Within 5 days of discovery / notification or as directed by the State Chief Information Security Officer (CISO) or delegate.

Severity 2: Within 30 days of discovery / notification.

Severity 3: Within 90 days of discovery / notification.

Severity 4: During the next routine system maintenance, following the normal change process for the system.

17 document.docx


# Control Name Control Detail Response6 Secure Configuration

StandardsSecure configuration standards must be developed, maintained and implemented for all systems. These standards must address all known security vulnerabilities and be consistent with industry-accepted system hardening standards. These standards must be updated when new vulnerabilities are identified.

7 Least Functionality Enable only necessary services, protocols, daemons, etc., as required for the function of the system. All unnecessary functionality, such as scripts, drivers, features, subsystems, file systems and unnecessary web servers must be removed.

8 System Defaults Vendor-supplied default passwords and other authenticators must be changed and unnecessary default accounts must be removed or disabled before installing a system on the network.

9 Separate Functions Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers and DNS should be implemented on separate servers.)

10 Memory Protection Systems must be configured to protect memory from unauthorized code execution. (For example utilizing data execution prevention or address space layout randomization.)

11 Limit User Access User functionality must be separate from system management/administration functionality.

12 Information in Shared Resources

The system must prevent unauthorized or unintended information transfer via shared system resources.

13 Network Disconnect Network connections associated with a communications session must be terminated at the end of the session or after no more than 30 minutes of inactivity.

14 Remote Management

All non-console administrative access must be encrypted using strong cryptography. Technologies such as SSH, VPN

18 document.docx


# Control Name Control Detail Responseor TLS must be used for web-based management and other non-console administrative access.

15 Secure Services Additional security features must be applied for any required services, protocols or daemons that are considered to be insecure to address the weaknesses in that service, protocol or daemon (For example, use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.).

16 Virtualization Virtual environments containing Criminal Justice Information must:

Isolate the host from the virtual machine. Physically separate Internet facing Virtual

Machines (web servers, portal servers, etc.) from internal Virtual Machines.

Locate device drivers that are “critical” within a separate guest operating system.

17 Capacity Management

Systems must be configured with sufficient capacity and redundancy to meet business needs and limit any effects of security events such as denial of service attacks.

19 Personal Firewall A personal firewall must be installed and actively running on all end user devices that have a full-feature operating system (i.e. laptops, desktops or tablets with Windows or Linux/Unix operating systems). At a minimum, the personal firewall must:

23 Mask Data on Display Data with a data protection categorization of High must be masked when displayed to ensure that only personnel with a legitimate business need can see the data.

25 Encryption in Transit Strong cryptography and security protocols must be used to protect State data during transmission including the following:

Encrypt data with a data protection categorization

19 document.docx


# Control Name Control Detail Responseof High in transmission at all times.

Encrypt data with a data protection categorization of Moderate in transmission over external networks.

Only accept trusted keys and certificates. Only support secure versions or configurations of

the protocol in use. Use an encryption strength that is appropriate for

the encryption methodology in use. 26 Certificate

ManagementAll public key certificates used in State systems must be:

Authorized by a supervisor or a responsible official.

Implemented using a secure process that verifies the identity of the certificate holder.

Issued only to the intended party. 27 Encryption at Rest All data with a data protection categorization of High must

be encrypted at rest.28 FIPS Certification All encryption modules must be NIST certified FIPS 140-2

compliant.29 Disk Encryption Independent logical access controls must be used in

addition to operating system and database access controls if disk encryption is used (rather than file- or column-level database encryption). Decryption keys must not be associated with user accounts.

30 Encryption Key Security

Encryption keys must be protected against disclosure and misuse by:

Restricting access to cryptographic keys to the fewest number of individuals necessary.

Securely storing secret and private keys used to encrypt/decrypt State data in one (or more) of the following forms at all times:

20 document.docx


# Control Name Control Detail Responseo Encrypted with a key-encrypting key that

is at least as strong as the data-encrypting key and that is stored separately from the data-encrypting key.

o Within a secure cryptographic device (such as a host security module (HSM)).

o As at least two full-length key components or key shares, in accordance with an industry-accepted method.

Storing encryption keys in the fewest possible locations.

Securely distributing encryption keys.31 Encryption Key

ManagementEncryption keys must be:

Strongo At least 10 characters long.o Not a dictionary word. o At least one (1) upper case letter, one (1)

lower case letter, one (1) number and one (1) special character.

Changed at the end of their cryptoperiod, as recommended by the application vendor or key owner and based on industry best practices and guidelines.

Retired or replaced when the integrity of the key has been weakened or keys are suspected of being compromised.

Managed using split knowledge and dual control if manual clear-text encryption key-management operations are used.

21 document.docx


6. Secure Systems Development and Acquisition Controls# Control Name Control Detail Response7 Development

CredentialsAll development, test and/or custom application accounts, user IDs and passwords must be removed from the application or system prior to production deployment.

8 Developer Access to Production

Developers must not have access to production systems unless the access is:

Needed to troubleshoot a production issue.

Monitored at all times. Only granted for the timeframe needed to address

the issue.11 Test Data Development and test data must be removed prior to

production deployment.12 Address Common

Coding Vulnerabilities

Address common coding vulnerabilities in line with current industry best practices such as the Open Web Application Security Project (OWASP) Top 10 in software-development processes.

13 Code Security Testing Prior to releasing new or updated applications to production, all code must be reviewed. This review must:

Be documented.

Be performed by individuals other than the originating code author.

Identify security flaws or weaknesses in the code.

Include the use of a static and/or dynamic code analysis software.

Results must be reviewed and approved by management prior to release.

22 document.docx


# Control Name Control Detail ResponseSecurity testing must be an on-going vendor responsibility throughout the life of the contract.

14 Code Flaw Remediation

All identified security flaws and weaknesses in the code must be addressed prior to the application production deployment.

18 Commercial Software Testing

Software purchased for use with State data must be tested for security flaws and weaknesses and any identified flaws and weaknesses must be addressed prior to being used for production purposes.

19 Data Protection Categorization

Software purchased for use with State data must adhere to state and federal security standards in order to responsibly protect citizen data and prevent adverse impacts to the state economy. It must secure and protect data in accordance with the Data Practices Act, Minnesota Statutes, Chapter 13 and its accompanying rules, Minnesota Rules Chapter 1205 .

All data is categorized as one of the following: High: Data that is highly sensitive and/or protected by

law or regulation. This includes, but is not limited to:o Protected Health Information (PHI) data as

defined in the HIPAA Regulation (45 C.F.R., Sec. 160.103).

o Criminal Justice Information (CJI) data as defined in the FBI Criminal Justice Information Services (CJIS) Security Policy.

o Government issued ID Numbers (e.g., Social Security Numbers, Driver’s license numbers / State ID Card numbers, Passport Numbers)

o Federal Tax Information (FTI) data as defined in IRS Publication 1075.

o Payment Card Industry (PCI) Account Data as defined by the Payment Card Industry Data

23 document.docx


# Control Name Control Detail ResponseSecurity Standards (PCI DSS).

o Bank account numbers excluding State-owned bank account numbers.

Moderate: Data that does not meet the definition of Low or High. This includes, but is not limited to:

o System security information.o Not public names.o Not public addresses.o Not public phone numbers.o IP addresses.

Low: Data that is defined by Minnesota Statutes Chapter 13 as “public” and is intended to be available to the general public.

7. Threat and Vulnerability Management Controls# Control Name Control Detail Response2 Internal Vulnerability

ScanningPerform internal network level vulnerability, scanning on all systems:

Using privileged credentials.

At least monthly.

Prior to production deployment.

Upon any significant change.3 External Vulnerability

ScanningPerform external network level vulnerability, scanning of all external facing systems:

From authorized external IP addresses.

At least monthly.

24 document.docx




Upon any significant change.

A Payment Card Industry (PCI) Approved Scanning Vendor (ASV) must be used for PCI Data Security Standards (DSS) systems.

5 Web Application Vulnerability Scanning

Perform web application vulnerability scans on all Internet facing web applications:


At least annually.

Upon any significant change.

25 document.docx

Security Logging and Monitoring...

Documents

Transcript of Security Logging and Monitoring...