CSI Digital Banking Security Whitepaper

Digital Banking provides Internet Banking and Mobile Banking channel access for delivery of information to your customers. These channels must have controls in place to limit exposure to unauthorized access of account information. CSI has developed a secure infrastructure to minimize exposure to unauthorized access of account information.

Controls to limit exposure and unauthorized access to account information can be identified in three primary areas: Access, Network, and Processing.

Access Controls

Cookies are small text files placed on the user’s computer by a website. CSI Digital Banking, like many other commercial websites, uses a technology called "cookies" to provide tailored information from the website. There are two types of cookies: persistent cookies and temporary or session cookies.

CSI Digital Banking sites use session cookies to assist in securing activities and to enhance the performance of our websites. Session cookies are used for authentication purposes. Once a user logs in to a website, the browser receives a session cookie that has a time stamp on it. As the end user moves around a website, the browser submits the session cookie whenever the browser requires a private web page. This is how the site knows that the person who logged in is the same person requesting the private pages.

CSI Digital Banking persistent cookies contain an encryption key in the cookie that must match the encryption key on the database at the web host location in order to skip the security questions previously entered when creating the password.

Bank Administrators can choose from four options that will control how the "Remember this device" feature functions. These options are Disabled, Cookie, IP-Based Cookie, and Device Fingerprint.

• "Disabled" will simply remove the ability for any user to use the "Remember this device" feature. This will require the user to input a security question or OOBA each time they log into the digital banking system.

• "Cookie" will store a cookie on the user’s computer but will not tie this cookie to an IP address on the internet. This method is not recommended due to the ability to copy this cookie from one computer to another

• "IP-Based Cookie" is a far better approach than the standard "Cookie" option because the internet banking server keeps a record of what IP address is associated with that cookie and will not allow it to be passed to another computer.

• "Device Fingerprint" is the most advanced method available because it does not require the use of a persistent cookie. The fingerprint is a proprietary hash created from various hardware and software components that can uniquely identify that device for digital banking services creating a known device. This allows the device to move from one IP to another and still function properly. This option allows for the highest level of security and usability.

Regardless of which method is used, the end user’s computer expires based on the setting within the Admin console. The financial institution can set the Days Until Security Cookie Expiration (1- 365). The numeric value is the number of days the security cookie is valid. After that time, the computer is required to be registered again. Valid entries are 1-365 (the number of days). The default value is 30.

In addition to the authentication in place for Digital Banking, the Digital Banking app offers specific validation options.

• "PIN" allows a user to create a 4-digit code for login on a known app device.

• "Auto Login" allows a user to access a subset of features in a read-only mode on a known device.

• "Biometrics" permits fingerprint access in place of credentials on a known device.

SMS/text banking is also available for client access. This service authenticates based on phone number and returns select information upon request.

Enrollment

First-Time User SetupFirst-Time User Setup

General Login ProcessGeneral Login Process

If password is forgottenIf password is forgotten

If username is forgottenIf username is forgotten

Multi-Factor Authentication

Secure TokensSecure Tokens

OOBA (Out of Band Authentication)OOBA (Out of Band Authentication)

BiometricsBiometrics

IP Tracking (Geolocation) and Access

Geo-locationGeo-location

Internet Protocol Address/Geo-location Block ListsInternet Protocol Address/Geo-location Block Lists

Internet Protocol Address/Geo-location Allow ListsInternet Protocol Address/Geo-location Allow Lists

IP Address Tracking and ReportingIP Address Tracking and Reporting

Physical and Environmental Controls

Physical access to the Paducah and Valparaiso facilities is controlled by a card key system that requires proximity badges and a four-digit PIN. The card key system is administered by Paducah Host Operations and access levels are reviewed annually for appropriateness. Within each facility, the server rooms are protected by two layers of security. First, the computer room area requires entry by utilizing the proximity badge with PIN. Only authorized employees are assigned access privileges through the card key system to the computer room. Once inside the computer room area, the server room itself is further protected with a biometric fingerprint scanner and only authorized employees are entered into the biometric system for access approval.

Uninterrupted Power Supply (UPS) units, which contain power-conditioning units, have been installed at the Host sites to provide battery back-up power to critical processing equipment in the event of a short power outage. The UPS units can provide up to an hour of back-up power for the host system. To reduce the risk associated with an interruption of electrical service in the Paducah location, the facility is served by two separate power grids which are automatically switched over should power be lost. At both the Paducah and Valparaiso Host sites, a diesel generator has been installed to power the facility in the event of a long-term power outage. The generators and power supplies are tested monthly.

The Paducah Server room has climate controls implemented to maintain optimal operating temperature. There are additional environmental controls, which include fire detection, sprinkler system, and raised floors. These environmental controls are also present in the Valparaiso Server room.

Logical Access Controls

Logical access controls are implemented for servers. Authorized users are assigned access privilege to servers through a group policy that requires a unique username and password for authentication. Passwords are required to be a minimum of 8 alphanumeric characters and expire every 90 days for non-administrative users. Administrative passwords are required to expire every 45 days. After five failed login attempts, users are locked out for a duration of 15 minutes or greater. Furthermore, the minimum age for passwords is 7 days with a password history of 8. There are instances where generic user accounts are utilized but these accounts are presented to the Information Security Committee for evaluation and an exception must be granted.

All servers and workstations are required to have an approved anti-virus system that is configured to be updated at least daily. Additionally, all workstations must have an approved firewall configured to block all unauthorized access attempts. Furthermore, all servers and workstations must have an Intrusion Detection System implemented to alert users when unauthorized access is attempted. Any mobile device must have full disk encryption implemented and any server or workstation deemed sensitive or containing cardholder data must utilize full disk encryption. CSI Digital Banking does not contain any cardholder data.

Software Engineers generally do not have remote access to any of the web application servers. There are rare instances where the SEG Leader or SEG Manager may request remote access to the production servers to assist in troubleshooting performance issues. In these instances, a TMT ticket requesting remote access is sent to the System Operations or email approval is obtained. Once the performance issues have been corrected, the remote access to the web application servers is rescinded.

 

Network Controls

Vulnerability Management

Network penetration tests are conducted on an annual basis through arrangements with an independent outside consultant. External vulnerability scans are conducted on a quarterly basis. CSI also maintains a robust vulnerability management program that conducts vulnerability scans on at least a monthly basis.

These penetration tests and vulnerability scans not only evaluate the network infrastructure but web-based applications with Internet access. Vulnerabilities are prioritized by criticality with mandated remediation dates by corporate policy.

CSI monitors several areas of the infrastructure 24/7 as indicated in the high-level diagramhigh-level diagram.

Behavioral and Anomaly-based Intrusion Prevention Systems (IPS):

• IPS are deployed between CSI public-facing systems and the Internet as well as in strategic locations throughout the CSI infrastructure.

• Systems receive frequent updates to protect against zero-day attacks.

• Feeds from industry-leading financial and governmental agencies are applied to enhance threat intelligence.

• Indicators of compromise are correlated to protect against sophisticated attacks.

Distributed Denial of Service (DDoS) Protection:

• CSI maintains agreements with our upstream Tier-1 providers to provide real-time, active monitoring, detection, and mitigation of DDoS activity.

• DDoS services are tested on a scheduled basis for reliability.

• DDoS protection levels are maintained at a level greater than CSI’s connection bandwidth to ensure adequate mitigation capabilities.

Network Controls between the End User and CSI

• TLS Protocol: All Digital Banking activity uses the Transport Layer Security (TLS) protocol. TLS is a set of formal rules describing how to transmit data to provide encrypted communications over the Internet. TLS protocol utilizes public-key cryptography to ensure privacy for the data moving between the browser and CSI Digital Banking servers. This protocol allows for the transfer of digitally signed certificates for authentication procedures and provides message integrity ensuring the data cannot be altered in route. By convention, the URLs for the web pages that require a TLS connection start with https, instead of http.

• Certificate: The CSI Digital Banking websites have a certificate that is 2048-bit SHA-2 and only accepts TLS1.2 connections and dynamic, session-based Elliptic-Curve (ECD) ciphers.

• Public-Key Cryptography: Public-key cryptography is used for encryption and server authentication. Encrypted messages provide protection against anyone eavesdropping; even if the information is intercepted, it is unreadable. Authentication identifies the origin of the information and that it has not been altered. Authentication also provides an extremely valuable tool in network security: verification of the identity of an individual. When an account holder wants to initiate a transaction, the browser is used to send a secure message via TLS to the web server. This method assures account holders they are communicating with the webserver and not a third party who is attempting to intercept the transaction request.

• Secure Network: All Digital Banking traffic must pass through a firewall, and filtering/screening routers. Traffic through the firewall is processed to a special proxy system, which operates similarly to a filtering/screen router and verifies the format, source, and destination of each information packet. The proxy then changes the IP address of the packet and delivers it to the appropriate site. This protects inside addresses from outside access and makes the structure of CSI's perimeter networks invisible to outside observers.

  To understand the importance of this structure, think of Digital Banking as having a front door and a backdoor: The Firewall provides security at the front door and the Filtering/Screening Router provides security at the back door.

• Web Application Firewall: CSI employs an industry-leading web application firewall to block common web-based threats such as those in the OWASP Top 10 for web applications and services. These web application firewalls are configured to inspect unencrypted and encrypted web application/web service traffic. The system receives real-time threat intelligence to aid in the prevention of known and zero-day web application attacks.

Network Controls between 3rd Party Vendors and CSI

API Access - Geezeo, Ensenta, iPay

Third-party applications such as Geezeo, Personal Financial Management (PFM), Ensenta Mobile Remote Deposit Capture (mRDC), and iPay, integrated bill pay, are controlled by a Single Sign-On from the Digital Banking product. The third party then calls an API opened by CSI Digital Banking to retrieve information for each customer as they log into Digital Banking. The SSO from CSI Digital Banking to these vendors use an x509 certificate to post a predefined SAML formatted message from CSI to a public vendor service via SSL. PartnerID must be valid based off the certificate and SAML organization that was used. A valid User ID must also be provided. An API call from the vendor uses SSL to encrypt data. The vendor sends a request and sends a response, generating a similar signature for the response. Vendors and CSI keep a private key that will be used in a multi-step process to generate and validate signatures sent in both directions. Any signature that does not match will not be processed.

Bill Pay Vendors

CheckFree

FiServ utilizes transport-based security disciplines to protect the production channel between the partner and Fiserv. Confidentiality and integrity are provided by using the standard SSL (Secure Sockets Layer) security framework over the internet, with certificates as the primary authentication technique.

The CheckFree interface utilizes an enrollment step as well as the Single Single Sign-On (SSO). For CheckFree, we have SSL certificates on our SSO server to authenticate, as well as the use of an initialization vector and three production keys that are sent with each message.

Direct iPay

The Single Sign-On process contains two primary steps: the User Authorization Token request and the Subscriber Login attempt. When this request is received, a unique one-time-use Session ID will be created. A response will then be returned that will contain the unique Session ID to use in the subsequent Subscriber login attempt. Once the user is authenticated or after a predetermined amount of time, the Session ID will be marked invalid and can never be used again.

The BillPay application website security uses SSL encryption to ensure all communications between systems are secure. BillPay cryptography will support 3DES encryption algorithms. Initialization Vectors will be passed with encrypted data.

Integrated iPay uses the API process described earlier in this document.

 

Processing Controls

Processing controls are in place to manage the end user's ability to acquire information stored with the Core Provider.

The security obligations of internal users and employees responsible for these web applications are communicated at least annually. All employees are required to review and acknowledge their review of Corporate Information Security policies annually. This acceptance is tracked by the Information Security Coordinator. Furthermore, all employees must receive Information Security training, which includes GLBA, Social Engineering, Contingency Plans, and Pandemic Plans annually. All training is presented through web-based instructions and some modules require the employee to demonstrate understanding of the material through a test that the employee must achieve at least an 80 percent score to pass.

Coordinator administers, monitors, and tracks success of the annual Information Security training. As part of the GLBA training, employees are informed on the Incident Response policies and procedures in the event of security breaches. The training provides insight into the employee’s responsibility for recognizing and reporting such instances.

Changes that might affect the security and availability of web applications are monitored through daily meetings. There are two daily meeting times at 10:00 and 3:00.

External Organization Participation

• Financial Services – Information Sharing and Analysis Center (FS-ISAC)

• InfraGard

Reporting

There are several reports that monitor activity and security within CSI Digital Banking, some of which are:

• Cash Management Batch Approval/Unapproval Report

• Cash Management Company Maintenance

• Customer Access Change Report, shows Security alert changes, dual authorization changes

• Transaction Reports from CSI Digital Banking match back to Transaction Report from Meridian.

• Fraud Anomaly Detection (FAD) monitoring and reporting module

Additional detailed information on the reporting available can be obtained from the Online User Manual.

 

Disaster Recovery

Server Failure

In the event of an ESX hardware failure, the virtual servers will automatically move to a different ESX host. In the event the SQL hardware was to fail, there is a second SQL cluster node at Paducah that will failover to take over. If both SQL nodes in Paducah fail or become unavailable, it would failover to Valpo.

Network Device Failure

In the event that CSI Digital Banking becomes unavailable, the GSS will automatically shift the traffic to the Valpo servers. The Valpo front end servers are always up and have the correct configuration; there is nothing further that needs to be done. If the Database needs to be failed to Valpo, currently that is a manual process.

Full Site Failure

In the event that Paducah becomes offline, all failovers will be automatic. The GSS will shift all web traffic up to Valpo. The Configuration on the webservers in Valpo will send all data to the Valpo SSO and application servers. The SQL cluster will also fail to Valpo; currently, this is a manual process

Disaster Recovery Testing

Disaster Recovery Testing methods mentioned above are tested at least annually as part of our Business Continuity Planning.

 

Digital Banking Safeguards to Mitigate Risk (OWASP Top 10)

AppE.5.b(ii) Mobile-Enabled Web Site Risk Mitigation Financial institution management should consider several controls to mitigate risks associated with mobile-enabled Web sites, including the following:

• Provide specific training and security awareness materials for users and customers accessing the institution’s sites to teach them how to identify compromised sites.

  RESPONSE: CSI requires all Software Engineering staff to go through a security training module each year. This training includes coding best practices and OWASP Top 10 Security threats.

• Require Web site developers to follow a secure development life cycle to increase the security of the Web sites designed for the financial institution.

  RESPONSE: CSI has a very strict Software Development Lifecycle (SDLC). All code changes are tracked against approved change request. The changes must go through testing by a developer, code review by a peer, and final approval from an outside quality control group. There are various procedures that must also be followed for getting change sets applied to production environments. CSI goes through both internal and external audit of this SDLC.

• Require developers to build a secure Web site especially for mobile devices and encourage them to follow the guidelines provided from the Open Web Application Security Project (OWASP) 25 Top 10 for Web application and OWASP Top 10 for mobile.

  RESPONSE: CSI uses the latest technology to test code against possible vulnerabilities. There are procedures in place where tools such as HP Fortify and Microsoft Secure Code Analyzer scans our code base and report any possible areas for improvement.

  Procedures are in place to review and correct any findings. These reports are monitored and reviewed but are not made available publicly. They are made available to internal audit and CSI Security Officer.

  CSI has the latest hardware-based Web Application Firewalls in place to monitor and alert security threats.

• Make available a baseline set of controls, and educate customers on the use of those controls to protect their device and information (e.g., device passwords with complexity, application passwords, and an auto-wipe feature after excessive password failures).

  RESPONSE: CSI Provides the functionality in our web applications that allows customers to define an appropriate risk tolerance for password complexity, and wipe and disable devices.

• Determine whether mobile browsers have available safeguards implemented, such as anti-XSS modules or additional monitoring of browsers for those that are no longer supported, and deny access to devices with mobile browsers not meeting minimum standards.

  RESPONSE: CSI has varying levels of browser support.

• Determine whether mobile-enabled Websites are designed with the following mitigating controls to help minimize the potential for exploitation of "redirect and forward" vulnerabilities:

  • Avoid using redirects and forwards

  • Explicitly hardcode the URL to prevent manipulation by an attacker.

  • Apply additional validation or control checks to verify the user trying to access the URL, validate the URL, check the appropriateness of the URL request, and prevent a malicious user from redirecting site users to a phishing, malicious, or non-affiliated site.

  • Create a whitelist of trusted URLs

  • Force all redirects to go through a page that notifies a user that they are leaving the page and require user confirmation.

  • Perform frequent vulnerability scans.

    RESPONSE: CSI uses industry-standard security hardening guides to configure web-based applications.

    Notification or "bump page" to let the user know they are leaving the financial institution is available on all high-risk web-based applications. Vulnerability scans are conducted by our internal security teams.