BRIGHT PATTERN SECURITY

NETWORK DEVICE AUTHENTICATION

To protect against compromised passwords on network devices, Bright Pattern uses multi-factor authentication for network devices. If the system is not compatible with multi-factor authentication or multi-factor authentication is not practical, a strong password must be selected and used according to strict guidelines on password construction. We require implementation of technology that enforces password policy construction, changes, reuse, lockout, and so forth.

LOGGING

The logging of certain events is an important component of good network management practices. We require that logging on network-level devices must be enabled to the fullest degree possible. Logs are reviewed daily on critical and high-security devices of all security events, system components that handle cardholder data or authentication data, and servers and system components that perform security functions. Additionally, we require log retention of one year.

AUDIT TRAILS

Audit trails must be kept for at least one year, with a minimum of three months available for immediate analysis.

We require an audit trail process for linking all access to system components back to individual users, implementation that allows for the reconstruction of all events, audit trails to be secured against unauthorized modifications, and recorded entries for all system components for each event.

FIREWALLS

Internet connections and other unsecured networks are separated from the Bright Pattern network through the use of a firewall. We ensure that firewall rules are as restrictive as possible while still providing the necessary access required for business operations, and we require firewall rule sets to be documented and audited every six months.

NETWORKING HARDWARE

Networking hardware, such as routers, switches, bridges, and access points, are implemented in a consistent manner to provide secure administrative access through the use of strong encryption.

NETWORK SERVERS

Servers typically accept connections from a number of sources, both internal and external; the more sources that connect to a system, the more risk that is associated with that system. We require recent versions of TLS, SSH, SFTP, or Ipsec VPN to be used to secure insecure technologies such as SSL, NetBIOS, file sharing, telnet, FTP, and so forth. Our systems are configured to restrict the disclosure of internal IP addresses and routing information and prevent misuse.

INTRUSION DETECTION/INTRUSION PREVENTION

We require the use of either an Intrusion Detection System (IDS) or Intrusion Prevention System (IPS) on critical, high-risk, or high-security network segments, where an IDS provides alerts for suspicious activity, and an IPS blocks the activity.

FILE INTEGRITY MONITORING

Bright Pattern requires the use of an effective change detection mechanism, such as File Integrity Monitoring (FIM) technology, that will provide alerts for changes, additions, and deletions to critical system files, configuration files, or content files.

FIM can be useful in notifying the IT staff to malicious activity or other significant network events that may otherwise go unnoticed. The software must be configured to perform critical file comparisons at least weekly.

SECURITY CONTROL MONITORING

Bright Pattern acts in the capacity of a service provider, as defined by the Payment Card Industry Security Standards Council (PCI SSC) and proactively monitors its security infrastructure in order to detect failures to its critical security control systems. We monitor systems including firewalls, Intrusion Detection/Intrusion Prevention Systems (IDS/IPS), File Integrity Monitoring (FIM) applications, antivirus/antimalware systems, logical access controls, audit logging mechanisms, and segmentation controls (if in use).

SECURITY TESTING

Network security is maintained and tested by qualified IT personnel and by third-parties recognized as Approved Scanning Vendors (ASV) by the PCI SSC.

We require evaluation of the network for all wireless access devices; internal vulnerability assessments using internal scans performed by qualified personnel or a third party recognized as an ASV by PCI SSC; external vulnerability (e.g., from the public Internet)  assessments, using scans performed by a third-party ASV; rescanning of high-risk vulnerabilities (i.e., any rated higher than 4.0 by the Common Vulnerability Scoring System (CVSS)) until there are no such remaining; and penetration testing at least annually, with a testing method implemented according to an industry-accepted penetration testing approach (e.g., NIST SP 800-115).

DISPOSAL OF INFORMATION TECHNOLOGY ASSETS

IT assets, such as network servers and routers, may contain sensitive data about network communications. When these assets are decommissioned, we require identifying tags and stickers to be removed, configuration information to be removed by deletion or reset to factory settings, and data wiping (not reformatting) using the most secure commercially available methods.

SOFTWARE/APPLICATION DEVELOPMENT

Bright Pattern develops software in a secure manner and in accordance with industry best practices for secure application coding.

We include security in all phases of application development by training developers in secure coding techniques at least annually, and reviewing custom application code for security weaknesses prior to being put into production, with reviews performed by qualified company personnel or a third party knowledgeable about code-review techniques and secure coding practices, who is independent of the software developer.

NETWORK DOCUMENTATION

Network documentation, specifically as it relates to security, is important for efficient and successful network management. We require network documentation be updated on a quarterly basis, and a formal network documentation process.

We ensure that security policies and operational procedures are documented, in use, and known to all affected parties. These procedures include managing firewalls, vendor defaults and other security parameters, protecting stored cardholder data, restricting access to cardholder data, encrypting transmissions of cardholder data, protecting systems against malware, developing and maintaining secure systems and applications, identification and authentication, restricting physical access to cardholder data, monitoring all access to network resources and cardholder data, and security monitoring and testing.

ANTIVIRUS / ANTIMALWARE / FIREWALL

Computer viruses and malware are pressing concerns in today’s threat landscape. If a system or network is not properly protected, a virus outbreak can have devastating effects on the system, the network, and the entire company. We require all company-provided user workstations and servers to have antivirus/antimalware/firewall software installed, and for personal firewall software or the equivalent functionality for all portable computing devices that connect to the Internet (e.g., laptops used by employees), which are also used to access the cardholder data environment (CDE). We prohibit the use of personal portable computing devices to connect to the CDE.

An Internet firewall restricts access between a protected network and the Internet to block unwanted or dangerous traffic and provides a single control point for access. Incoming connection attempts are blocked by default, except to services that can be offered safely. Outgoing connections are permitted by default.

SOFTWARE USE

Software applications can create risk in a number of ways. For the use of software applications, we require:

• Only legally licensed software to be used
• Licenses to be stored in a secure location
• Open source and/or public domain software to be used only with the permission of the Information Security Manager
• Software to be kept reasonably up to date by installing new patches and releases from the manufacturer
• Vulnerability alerts to be monitored for all software products used by Bright Pattern
• Assignment of a risk ranking based on industry best practices to each vulnerability discovered, such as “high,” “medium,” or “low”
• Critical patches to be installed as soon as possible but no more than one month after the patch release date

SOFTWARE/APPLICATION DEVELOPMENT

Bright Pattern develops software in a secure manner and in accordance with industry best practices for secure application coding.

We include security in all phases of application development by training developers in secure coding techniques at least annually, and reviewing custom application code for security weaknesses prior to being put into production, with reviews performed by qualified company personnel or a third party knowledgeable about code-review techniques and secure coding practices, who is independent of the software developer.

MAINTENANCE WINDOWS AND SCHEDULED DOWNTIME

Certain tasks require that network devices be taken offline either for a simple reboot, an upgrade, or other maintenance. When this occurs, Bright Pattern performs the tasks during a scheduled weekly or monthly maintenance window. Tasks that are deemed “emergency support,” or tasks required to close discovered vulnerabilities are done with one hour’s notice to users or immediately if the situation dictates

CHANGE MANAGEMENT

Documenting changes to network devices is a good management practice and can help speed resolution in the event of an incident. Bright Pattern documents hardware and/or configuration changes to network devices in a change log.

SUSPECTED SECURITY INCIDENTS

When a security incident is suspected that may impact a network device, Bright Pattern refers to its Incident Response policy for guidance.

REDUNDANCY

Redundancy can be implemented on many levels, from redundancy of individual components to full site redundancy. We determine the appropriate level of redundancy for critical systems and network devices, implementing redundancy where needed, including some or all of the following: hard drive redundancy, server level redundancy (e.g., clustering or high availability), component level redundancy (e.g., redundant power supplies or redundant NICs), and keeping hot or cold spares onsite.

MANUFACTURER SUPPORT CONTRACTS

Outdated products can result in a serious security breach. When purchasing critical hardware or software, Bright Pattern purchases a maintenance plan, support agreement, or software subscription that allows us to receive updates to the software and/or firmware for a specified period of time.

SECURITY POLICY MANAGEMENT

Effective PCI security management is performed by our Information Security Manager, who is responsible for compliance with Bright Pattern’s security policy and any applicable security regulations; Executive Manager assigned with overall accountability for maintaining Payment Card Industry Data Security Standard (PCI DSS compliance); and System Administrator, who is responsible for systems across the enterprise, which include CDE systems, connected-to and security-impacting systems, as well as out-of-scope systems.

We require at least annual review of security policies, with evaluation of regulations for changes that would affect compliance, whether deployed security controls are still capable of performing their intended functions, technology or other changes may affect Bright Pattern’s security strategy, and if any changes need to be made to accommodate future IT security needs.

When or if Bright Pattern acts in the capacity of a service provider, as defined by PCI SSC, Bright Pattern’s compliance with its security policies and required security procedures is audited at least quarterly.

SECURITY AWARENESS TRAINING

Bright Pattern implements a security awareness program for all users and/or employees upon hiring and at least annually, which includes security awareness training and the appropriate handling of confidential data, including cardholder data.

SYSTEM CONFIGURATION STANDARDS

We require vendor-supplied defaults to be changed before installing a system, and unnecessary default accounts to be removed or disabled before installing a system. These system configuration standards apply to all default passwords within the CDE, including but not limited to those used by operating systems, software that provides security services, application and system accounts, payment applications, Simple Network Management Protocol (SNMP) community strings, and so forth.

INCIDENT RESPONSE PLAN

Our plan includes procedures for preparation, identification, containment, eradication, recovery, lessons learned, and the people responsible for incident responses.

REMOTE ACCESS CLIENT SOFTWARE

It is often necessary to provide access to corporate information resources to employees or others working outside Bright Pattern’s network. To prevent vulnerabilities, Bright Pattern provides a framework for secure remote access implementation, defining standards for accessing corporate IT resources for any reason from outside the network, including from the employee’s home, remote working locations, while traveling, and so forth.

REMOTE NETWORK ACCESS

Remote network access can be provided for a variety of reasons to a variety of different types of users. Rather than take a “one size fits all” approach, Bright Pattern requires that remote access be offered according to the level of access required by each user type (i.e., employees, administrators, and third parties/vendors).

We limit remote users’ access privileges to only those information assets that are reasonable and necessary to perform their function when working remotely (e.g., email), and require multi-factor authentication (e.g., smart cards, tokens, or biometrics in combination with a password).

Any non-console administrative access, such as remote management or web-based access, is secured with strong encryption to prevent misuse. Insecure management protocols, such as telnet, are disabled or prohibited in favor of more secure methods, such as Secure Shell (SSH), or encrypted via a virtual private network (VPN) or Transport Layer Security (TLS). We do not use Secure Sockets Layer (SSL) due to significant and fundamental vulnerabilities within that protocol.

When non-employees are provided access to the network, such as vendors or service providers, their remote access account is disabled when not in use. Accounts used for remote vendor access are monitored when in use.

IDLE CONNECTIONS

Due to the security risks associated with remote network access, remote connections to Bright Pattern’s network are timed out after 15 minutes of inactivity.

PROHIBITED ACTIONS

We prohibit installation of an access point, router, or other remote access device on a company system without the approval; remotely accessing corporate systems with a remote desktop tool (e.g., VNC, Citrix, or GoToMyPC) without the written approval; use of non-company-provided remote access software; split tunneling; and copying data to and storing data on remote computers unless explicitly authorized to do so for a defined business need and done in a manner that meets requirements for data confidentiality. If the data contains cardholder data, Bright Pattern is compliant with any applicable PCI DSS requirements.

USE OF NON-COMPANY-PROVIDED SYSTEMS

Accessing the corporate network through home or public systems presents a security risk, as Bright Pattern cannot completely control the security of the system accessing the network. No non-company-provided computers are allowed to access the corporate network for any reason, unless the access is provided by Bright Pattern in a public manner, such as web-based email.

CONSTRUCTION

The best security against a password incident is to follow a sound password construction strategy. We recommend that passwords include at least seven characters, be a mix of letters and numbers and special characters, include a mix of uppercase and lowercase characters, not consist of words found in a dictionary or obvious keyboard sequences, and not include guessable data. We recommend using pass phrases.

CONFIDENTIALITY

Passwords are considered confidential data and are treated with the same discretion as any of Bright Pattern’s proprietary information.

Compliance with our Password Policy means never sharing passwords, writing them down, checking the “save password” box when authenticating to applications, using the same password for different systems or accounts, sending passwords electronically, or reusing passwords.

INCIDENT REPORTING

Because the compromise of a single password can have a catastrophic impact on network security, it is the user’s responsibility to immediately report any suspicious activity involving his or her passwords and immediately change the password in question.

CHANGE FREQUENCY

Bright Pattern requires users to change their passwords at least once every 90 days.

REASONS FOR DATA RETENTION

It is neither practical nor cost-effective to keep all data. Some data, however, must be retained in order to protect Bright Pattern’s interests, preserve evidence, and generally conform to good business practices.

Some reasons for data retention include litigation, accident investigation, security incident investigation, regulatory requirements, and intellectual property preservation.

DATA DUPLICATION

As data storage increases in size and decreases in cost, companies often err on the side of storing data in several places on the network. A common example of this is where a single file may be stored on a local user’s system, on a central file server, and again on a backup system. 

For this reason, Bright Pattern applies its Retention Policy to all stored data, including duplicate information.

RETENTION REQUIREMENTS

Retention requirements vary for the different types of company data. We require that users’ personal data (e.g., emails, documents) be deleted or destroyed when it is no longer needed, so there are no retention requirements for personal data.

Operational data (e.g., data for basic business operations, communications with vendors, employees, device logs if nonconfidential, etc.) must be retained for five years.

Confidential data (e.g., any information deemed proprietary to the business, including cardholder information) must be retained for seven years unless otherwise required for legal, regulatory, or business reasons.

RETENTION OF ENCRYPTED DATA

If any information is stored in an encrypted format, we require encryption keys to be securely stored for as long as the data that the keys decrypt is retained.

DATA DESTRUCTION

On a quarterly basis, Bright Pattern seeks out and securely deletes any cardholder data that exceeds retention requirements defined in our Retention policy. We direct users not to destroy data in violation of our Retention Policy. Particularly forbidden is destroying data that a user may feel is harmful to himself or herself or destroying data in an attempt to cover up a violation of law or company policy. Further, any data that may be subject to a subpoena or discovery request must not be destroyed.

DATA CLASSIFICATION

We require data to be classified according to its importance to company operations and the confidentiality of its contents. This helps us to determine its value and ensure that data is treated appropriately.

Of particular concern is confidential data or cardholder data, which we require to be identified and inventoried in all its forms—electronic, printed, or stored on digital media—and segregated from the non-confidential data so that access to it can be more tightly controlled and tracked. Any media that contains cardholder data must be catalogued and secured.

TREATMENT OF CONFIDENTIAL DATA

Confidential data (e.g., cardholder data) and backups of this data can be stored only when absolutely necessary. If stored, it must be stored under lock and key (or keycard/keypad), in encrypted form, using strong encryption.

When handling cardholder data, Bright Pattern never stores the full contents of any track from a credit card magnetic stripe, the card verification code, PIN, or encrypted PIN block after authorization.

If there is a business need to do so and they are appropriately secured, we can retain cardholder name, PAN, expiration date, and service code in an unreadable format via strong cryptography, one-way hashes based on strong cryptography, or index tokens/pads and truncation.

When credit card authentication data is received, we require the data to be securely deleted following authorization. Confidential data must never be stored on non-company-provided systems (i.e., home computers).

We require strong encryption to be used when transmitting confidential data (e.g., credit card data) when such transmission takes place outside of our network. Confidential data must not be recorded. In addition, we only accept trusted keys and certificates.

If data transmission occurs as part of a web application, we require “https” to be displayed in the browser URL bar whenever confidential information. We use TLS or another secure protocol to be used to secure these connections, and never insecure encryption protocols, such as SSL.

Media containing confidential data must be destroyed in a manner that makes it impossible to recover the information.

EXAMPLES OF CONFIDENTIAL DATA

Confidential data generally includes:

• Credit card information/cardholder data
• Credit card Primary Account Numbers (PANs)
• Employee or customer Social Security numbers, or other personal information
• Medical and healthcare information
• Electronic Protected Health Information (EPHI)
• Customer data, including customer lists and customer contact information
• Company financial data that has not been released publicly
• Sales forecasts
• Product and/or service plans, details, and schematics
• Network diagrams and security configurations
• Communications about corporate legal matters
• Passwords
• Bank account information and routing numbers
• Payroll information
• Any confidential data held for a third party

USE OF CONFIDENTIAL DATA

We require our users to be aware of what to do when or if they must interact with confidential data. Users must be aware of which data they’ve been granted access, and they must only access it when necessary to perform their job. Moreover, we require users to protect any confidential information they have been granted access to and not reveal, release, share, email unencrypted, exhibit, display, distribute, or discuss the information unless necessary to do or their supervisor has approved it.

SHARING CONFIDENTIAL DATA WITH THIRD PARTIES

If confidential data, including cardholder data, is shared with third parties, such as service providers, we require a written agreement to govern the provider’s use of the confidential information.

RECEIVING CONFIDENTIAL DATA FROM THIRD PARTIES

If we receive or in any way handle confidential data for customers or partners, we treat this data as if it were its own confidential data, and we take all necessary steps to secure any data that we possess, store, process, or transmit on behalf of customers or partners that may affect the security of the cardholder data environment.

THIRD-PARTY COMPLIANCE

Enterprise-grade contact center software requires high levels of security and compliance to protect all customer data. As an enterprise provider, Bright Pattern upholds the highest level of Payment Card Industry (PCI) compliance.

Our cloud contact center software infrastructure and practice have been third-party certified by CompliancePoint for compliance with the Payment Card Industry Data Security Standard (PCI DSS 3.2).

We monitor compliance with the PCI SSC and other industry standard programs through third-party evaluators on a yearly basis.

SECURITY CONTROLS FOR CONFIDENTIAL DATA

Confidential data requires additional security controls in order to ensure its integrity. We utilize strong encryption for transmission of confidential data and require confidential data to be kept separate from the rest of the network using firewalls, access control lists, or other security controls. We require physical confidential data to be kept or transmitted securely when applicable when it appears in hardcopy form or is printed. We prohibit confidential data to be transmitted via email, SMS, and messengers.

Numerical confidential data (e.g., Social Security numbers, cardholder data, etc.) must be removed if at all possible or masked.

EMERGENCY ACCESS TO DATA

We require procedures for accessing confidential data that has critical business or health implications (i.e., healthcare information) during an emergency.

IDENTIFICATION OF CRITICAL DATA

We classify all data and identify critical data so that it can be given the highest priority during the backup process. Any data deemed confidential is identified so that backups of this data are treated and secured accordingly.

DATA TO BE BACKED UP

We ensure that backups are done for:

• All data determined to be critical to company operation and/or employee job function
• All information stored on the corporate file server(s) and email server(s). It is the user’s responsibility to ensure any data of importance is moved to the file server.
• All information stored on network servers, which may include web servers, database servers, domain controllers, firewalls, and remote access servers, and so forth.
• Logs and configuration information from network devices such as switches, routers, IDS/IPS systems, and so forth.

BACKUP FREQUENCY

Backup frequency is critical to successful data recovery. To allow for sufficient data recovery in the event of an incident, while avoiding an undue burden on the users, network, and backup administrator, we perform incremental backups every three days and a full backup every week.

OFF-SITE ROTATION

To protect from fire, flood, or other regional or large-scale catastrophes, we keep backups in separate geographic locations. Off-site storage is balanced with the time required to recover the data, in accordance with our uptime requirements. Backup media is rotated off-site at least once per week.

BACKUP STORAGE

Storage of backups is a serious issue and one that requires careful consideration. Since backups contain critical, and often confidential, company data, we take precautions with storing data onsite and off. 

When stored onsite, backup media is stored in a fireproof container in an access-controlled area. When taken off-site, we use a hardened facility that uses accepted methods of environmental controls, including fire suppression, and security processes to ensure the integrity of the backup media. Online backups are allowed only if the service meets our criteria for security. Confidential data must be encrypted using industry-standard, strong encryption to protect against data loss. The security of backup locations, particularly when a third party is involved, is reviewed at least annually.

BACKUP RETENTION

To effectively mitigate risk while preserving required data, incremental backups are saved for one month, and full backups are saved for six months.

RESTORATION PROCEDURES AND DOCUMENTATION

We require data restoration procedures to be tested and documented. Documentation must include exactly who is responsible for the restore, how it is performed, under what circumstances it is to be performed, and how long the process should take from request to restoration.

RESTORATION TESTING

Since a backup policy does no good if the restoration process fails, we periodically test the restore procedures to eliminate potential problems. Backup restores are tested when any change is made that may affect the backup system, as well as once every month.

EXPIRATION OF BACKUP MEDIA

Certain types of backup media, such as magnetic tapes, have a limited functional lifespan. After a certain time in service the media can no longer be considered dependable. When backup media is put into service the date is recorded on the media or a master list. The media is then retired from service after its time in use exceeds manufacturer specifications.

ACCOUNT SETUP

Good IT security starts with good user security. We require that potential personnel be screened prior to hire. Examples of acceptable screening methods include checking employment history, criminal records, credit history, and reference checks.

During initial account setup, we require that certain checks be performed, such as assigning a unique user ID before being granted access to network resources; restricting the ability to add, delete, and change user IDs, user credentials, user privileges, and other account-related activities; performing identity verification for any user-requested account changes; and required passwords to be changed immediately after the first use.

ACCOUNT ACCESS LEVELS

It is our policy to follow the principle of least privilege, where employees will be provided the least amount of access required to perform their job functions. This is particularly important as it relates to high-security zones, such as the cardholder data environment. Any user account with access to these zones (i.e., privileged users) must be given the minimum amount of access possible to perform job functions.

ACCOUNT USE

Network accounts are implemented in a standard fashion and utilized consistently for our systems. To ensure consistency, we require account user IDs to be created using a standard format (e.g., first name.last name); protection of all non-consumer accounts using a password, token, or biometric control; individual use of the accounts (no account sharing or group accounts); and no administrator or “root” access for users.

ACCOUNT TERMINATION

In the event of a staffing change, which includes employment termination, employment suspension, or a change of job function (e.g., promotion, demotion, suspension, etc.), user access can be disabled or revoked. We enable our customers to audit user accounts to verify that any inactive accounts over 90 days old are removed or disabled.

NETWORK AUTHENTICATION REQUESTS

We require user systems to be configured to request authentication against a central network authentication manager, such as a domain, at startup. If this authentication mechanism is not available or authentication for some reason cannot occur, then the system is not allowed to access the network. Any session that has been idle for more than 15 minutes is terminated, requiring the user to reauthenticate in order to activate the session again.

DATABASE AUTHENTICATION REQUESTS

Any access to a database containing confidential or cardholder data requires authentication, whether the access is by applications, administrators, or users. We restrict direct database access to only database administrators, and we only allow user access to, user queries of, and user actions on databases through programmatic methods, such as stored procedures, rather than direct access.

USE OF PASSWORDS

When accessing the network locally, username and password can be used for authentication, as long as usernames and passwords conform to our policies. We implement password management technology that requires users to change their passwords every 90 days and to not allow the reuse of any of the user’s last four passwords.

SCREENSAVER PASSWORDS

Screensaver passwords offer an easy way to strengthen security by removing the opportunity for a malicious user, curious employee, or intruder to access network resources through an idle computer. We require that users lock their computers when stepping away and configure screensaver passwords to activate after five minutes of inactivity.

MINIMUM CONFIGURATION FOR ACCESS

Any system connecting to the network can have a serious impact on the security of the entire network. A vulnerability, virus, or other malware may be inadvertently introduced in this manner. For this reason, users must strictly adhere to corporate standards with regard to antivirus software and patch levels on their systems. Users must not be permitted to access the network if these standards are not met.

ENCRYPTION OF LOGIN CREDENTIALS

Industry best practices state that username and password combinations must never be sent as plain text. If this information were intercepted, it could result in a serious security incident. Therefore, authentication credentials must be encrypted during transmission across any network, whether the transmission occurs internally to our network or across a public network such as the Internet.

FAILED LOGIN ATTEMPTS

Repeated login failures can indicate an attempt to “crack” a password and surreptitiously access a network account. In order to guard against password-guessing and brute-force attempts, we  lock a user’s account after a maximum of six unsuccessful logins.

ALTERNATE AUTHENTICATION MECHANISMS

Where passwords are specified, we have the option to enforce controls such as tokens or biometrics, which are as secure or more secure than passwords.

TYPES OF INCIDENTS

A security incident can be electronic (e.g., attacker, user accessing the network for malicious purposes, virus, etc.), physical (e.g., loss or theft of a laptop or other asset that contains company information), or a hybrid of the two. We protect against such incidents using alerts generated from intrusion detection, intrusion prevention, and file integrity monitoring systems.

PREPARATION

Work done prior to a security incident is arguably more important than work done after an incident is discovered. The most important preparation work is maintaining good security controls that will prevent or limit damage in the event of an incident. This includes technical tools such as firewalls, intrusion detection systems, authentication, and encryption; and nontechnical tools such as good physical security for laptops, mobile devices, and printed data.

CONFIDENTIALITY

All information related to an electronic, physical, or hybrid security incident is treated as confidential information until the incident is fully contained and investigated.

ELECTRONIC INCIDENTS

When an electronic incident is suspected, our goal is to recover as quickly as possible, limit the damage done, secure the network, and preserve evidence of the incident.

PHYSICAL INCIDENTS

Physical security incidents are challenging, because often the only actions that can be taken to mitigate the incident must be done in advance. This makes preparation critical. One of the ways we prepare for an incident is to mandate the use of strong encryption to secure confidential data when stored on company systems, mobile or otherwise.

HYBRID INCIDENTS

For hybrid incidents, we establish the severity of the incident by determining the type of data stored on the missing device. This can often be done by referring to a recent backup of the device. If the type of data cannot be determined, and there is a likely possibility that confidential data was involved, then we assume that confidential data was lost, and we respond accordingly.

NOTIFICATION

If an electronic, physical, or hybrid security incident is suspected to have resulted in the loss of third-party or customer data, we follow applicable regulations and/or industry breach disclosure laws; append the applicable section(s) of the regulations to our policy; and notify impacted parties, including credit card/merchant fraud control departments, if such notification is needed.

BUSINESS RECOVERY AND CONTINUITY PLANNING

The purpose of recovery and continuity planning is to enable recovery of critical IT systems, operations, and data after an incident by developing coordinated plans, procedures and other technical measures in advance of such a disruptive event. We establish policies and procedures for responding to an emergency or other event that damages or negatively impacts access to systems required for business operations.

REVIEW, TESTING, AND MAINTENANCE

We review our contingency plan on an annual basis, ensuring that the plan is appropriate to restore critical processes after security incidents or under different types of emergencies.

APPLICABILITY OF ENCRYPTION

Encryption plays a versatile role in Bright Pattern’s data security. We require the following to be secured with strong encryption: remote access, mobile devices, email, messaging, backups, authentication, site-to-site VPNs, confidential data, firewalls, and network hardware.

ENCRYPTION KEY MANAGEMENT

Key management is critical to the success of an implementation of encryption technology. For our encryption keys and key management, we ensure that data is available for decryption when needed, including the retention of keys necessary to decrypt encrypted backups. As confidential data, we require keys to be locked up, never be transmitted in clear text, never shared, never stored on the same media as the encrypted information, and stored in the fewest locations possible.

We require keys to be stored in one or more of the following forms at all times: encrypted with a key-encrypting key that is at least as strong as the data-encrypting key and stored separately from the data-encrypting key, within a secure cryptographic device, and as at least two full-length key components or key shares.

ACCEPTABLE ENCRYPTION ALGORITHMS

Only the strongest types of generally accepted, nonproprietary encryption algorithms are allowed, as dictated by industry best practices on encryption. Use of proprietary encryption is specifically forbidden since it has not been subjected to public inspection and its security cannot be assured.

The length of encryption should meet industry best practices for security. Refer to trusted sources such as NIST SP 800-52 (current revision), NIST SP 800-175B, NIST SP 800-57, OWASP, and so forth.

LEGAL USE

Some governments have regulations applying to the use and import/export of encryption technology. Bright Pattern conforms with encryption regulations of the local or applicable government, and we forbid the use of encryption to hide illegal, immoral, or unethical acts.

SITE LOCATION

Sites for IT operations should be secure and free of unnecessary environmental challenges, especially when selecting a data center or a site for centralized IT operations.

Bright Pattern ensures physical security for our locations by choosing site(s) that are not particularly susceptible to fire, flood, earthquake, or other natural disasters, are not located in an area where the crime rate and/or risk of theft is higher than average, and have the fewest number of entry points possible.

SECURITY ZONES

At a minimum, we maintain standard security controls, such as locks on exterior doors and/or an alarm system. In addition, we provide security in layers by designating different security zones within the building for public, company, and private use.

ACCESS CONTROLS

We restrict entry to Bright Pattern’s premises and security zones to only approved persons.

PHYSICAL DATA SECURITY

To ensure the integrity of our data by taking common sense precautions, such as positioning computer screens where information cannot be seen by outsiders, not allowing the display of confidential information to those not authorized to view the information, requiring users to log off or shut down workstations when leaving for an extended time period, running network cabling only through secure areas, and requiring any media containing confidential data or cardholder information to be stored in a high-security/private zone.

PHYSICAL SYSTEM SECURITY

In addition to protecting the data on our information technology assets, we also take precautions to minimize the risk of loss, theft, damage, or tampering of our systems.

FIRE PREVENTION

It’s our policy to provide a safe workplace that minimizes the risk of fire.

ENTRY SECURITY

We provide a safe workplace for employees and our information assets. Monitoring those who enter and exit the premises is a good security practice in general, but is particularly true for minimizing risk to company systems and data.