• Purpose of the Information Security Policy

The purpose of this Information Security Policy (the “Policy”) is to document the information security policies of Ad-Unbox (“Product”).

• Scope of the Information Security Policy

This Policy applies to Product employees, contractors, consultants, and other representatives, including all individuals affiliated with third parties authorized by Product. This Policy applies to all physical and network infrastructure that are owned and operated by Product (collectively, the “Facility”). This Policy does not apply to third-party data centers that are not owned or operated by Product.

• Facility Security

• Security Areas

Public

This includes areas of the Facility that are intended for public access.
• Access Restrictions: 24 Hour Building Security

Product

This includes areas of the Facility that are used only by employees and other persons for official Product business.

• Access Restrictions: Only authorized personnel of Product and permitted invitees of such Facility.
• Additional Security Controls: Additional access controls should be used, such as keys, as well as security cameras.
• Examples: Hallways, private offices, work areas, conference rooms

Private

This includes areas that are restricted to use by certain persons within Product’s organization, such as executives and Information Technology personnel, for security or safety reasons.

• Access Restrictions: Only specifically approved personnel
• Additional Security Controls: Additional access controls must be used, such as keys or keypads, with access to these areas logged.  These areas are monitored by security cameras.
• Examples: Network room, file storage areas

1. Access Controls

Access controls are necessary to restrict entry to Product premises where Information Technology is held and security zones to only approved persons.

Keys

The use of keys is acceptable, as long as keys are marked “do not duplicate” and distribution is limited.  Keys must not be copied.  If a key is lost or stolen, it must be reported to the Facility so that the lock can be immediately rekeyed.  If an individual is terminated or resigns, that individual’s key must be returned to Product.

 

Alarm System & Security Cameras

Product mandates the use of professionally monitored alarm systems.  The system must be monitored 24×7, with Product personnel being notified if an alarm is tripped at any time.

1. Entry Security

Product’s Policy is to provide a safe workplace for personnel.  Monitoring those who enter and exit the premises is a good security practice in general, but is particularly true for minimizing risk to Product systems and data.

Use of ID Badges

Identification (ID) badges are useful to identify authorized persons on Product premises.  Product has established the following guidelines for the use of ID badges: Visitor badges are required.

Sign-in Requirements

Building security maintains a sign-in log in the lobby and visitors must be required to sign in upon arrival.  At a minimum, the register must include the following information: visitor’s name, Product name, reason for visit, name of person visiting, sign-in time, and sign-out time.

Visitor Access

Visitors should be given only the level of access to Product premises that is appropriate to the reason for their visit.  After checking in, visitors must be escorted unless they are considered “trusted” by Product.  Examples of a trusted visitor may be Product’s outside legal counsel, financial advisor, or a courier that frequents the office, and will be decided on a case-by-case basis.

• Physical Data Security

Certain physical precautions must be taken to ensure the integrity of the Product’s data.  At a minimum, the following guidelines must be followed:

• Computer screens must be positioned where information on the screens cannot be seen by outsiders. 
• Confidential information must not be displayed on a computer screen where the screen can be viewed by those not authorized to view the information.
• Personnel must log off or shut down their workstations when leaving for an extended time period or at the end of the workday.
• Network cabling must not run through unsecured areas unless the cabling is carrying only public data (i.e., extended wiring for an Internet circuit).
• Network ports that are not in use must be disabled.

1. Physical System Security

In addition to protecting the data on Product’s information technology assets, this Policy provides the guidelines below on keeping the systems themselves secure from damage or theft.

Minimizing Risk of Loss

In order to minimize the risk of data loss through loss or theft of Product property, the following guidelines must be followed:

• Unused systems: If a system is not in use for an extended period of time, it should be moved to a secure area or otherwise secured.

• Mobile devices: Special precautions must be taken by employees to prevent loss, theft of, or unauthorized access to mobile devices.  Password protection should be used on all employee mobile devices containing Product information.
• Systems that store confidential data: Special precautions must be taken to prevent loss or theft of these systems, including physically securing those systems and allowing only authorized individuals to access such systems.  

Minimizing Risk of Damage

Systems that store Product data are often sensitive electronic devices that are susceptible to being inadvertently damaged.  In order to minimize the risk of damage, the following guidelines must be followed:

• Environmental controls should keep the operating environment of Product systems within standards specified by the manufacturer.  These standards often involve, but are not limited to, temperature and humidity.
• Proper grounding procedures must be followed when opening system cases.  This may include use of a grounding wrist strap or other means to ensure that the danger from static electricity is minimized.
• Strong magnets must not be used in proximity to Product systems or media.
• Except in the case of a fire suppression system, open liquids must not be located above Product systems.  Beverages must never be placed where they can be spilled onto Product systems.
• Uninterruptible Power Supplies (UPSs) and/or surge-protectors are required for important systems and encouraged for all systems. These devices must carry a warranty that covers the value of the systems if the systems were to be damaged by a power surge.

• Data Security 

• Data Categories

Data residing on Product systems is classified into the following categories:

• Public: includes already-released marketing material, commonly known information, etc.  There are no requirements for public information.
• Operational: includes data for basic business operations, communications with customers, vendors, personnel, etc. (non-confidential).  The majority of data will fall into this category.
• Critical: any information deemed critical to business operations (often this data is both operational and confidential).  It is extremely important to identify critical data for security and backup purposes.
• Confidential: any information deemed proprietary to the business and personnel personal data, including the following: 

• Customer, employee, and partner personally identifiable information (PII)
• Medical and healthcare information
• Customer data
• Product financial data
• Sales forecasts
• Product and/or service plans and details
• Network diagrams and security configurations
• Communications about corporate legal matters
• Passwords
• Bank account information and routing numbers
• Payroll information
• Credit card information
• Any confidential data held for a third party (be sure to adhere to any confidential data agreement covering such information)

• Financial/Credit Card: any full credit card primary account number (PAN) and bank account number, encrypted or unencrypted.

• Data Storage/Retention

Operational: Operational data must be stored where the backup schedule is appropriate to the importance of the data, at the discretion of Product personnel.

Critical: Critical data must be stored on a server that gets the most frequent backups. System- or disk-level redundancy is required.

Confidential: Confidential data must be removed from desks, computer screens, and common areas unless it is currently in use.  Confidential data should be stored under lock and key, with the key secured.  Confidential data must not be stored on laptops or other mobile devices without the use of strong encryption or password-protected files.  Confidential data must never be stored on non-Product-provided machines (i.e., home computers).

 

Data is maintained indefinitely, both online and offline, unless Product is presented with a request to remove records.  If destruction of data is requested or appropriate, data will be disposed of in a secure manner pursuant to Section 4.4. 

• Data Transmission

The following guidelines apply to transmission of the different types of Product data.

Operational: No specific requirements apply to transmission of operational data, but, as a general rule, the data should not be transmitted unless necessary for business purposes.

Critical: There are no requirements on transmission of critical data, unless the data in question is also considered operational or confidential.

Confidential: Confidential data must not be (1) transmitted outside the Product network without the use of strong encryption or password-protected files; or (2) left on voicemail systems, either inside or outside of Product’s network. When faxing confidential data, personnel must use cover sheets that inform the recipient that the information is confidential.  

• Data Destruction

The following guidelines apply to the destruction of the different types of Product data.

Operational: Cross-cut shredding is required for documents.  Storage media should be appropriately sanitized and/or wiped or destroyed.

Critical: Shredding is encouraged if the data in question is considered operational or confidential; the applicable Policy statements would apply.

Confidential: Confidential data must be destroyed in a manner that makes recovery of the information impossible.  The following guidelines apply:

• Paper/documents: cross cut shredding is required or disposal in secure shred bin.
• Storage media (CDs, DVDs): physical destruction is required.
• Hard Drives/Systems/Mobile Storage Media: at a minimum, data wiping must be used.  Simply reformatting a drive does not make the data unrecoverable.  If wiping is used, Product must use the most secure commercially-available methods for data wiping.  Alternatively, Product has the option of physically destroying the storage media.

Credit Card: When disposing of physical media that has been used in a device which processes, stores, or transmits credit card data, it must be disposed of in a manner which is compliant with NIST 800-88.

• Data Security – Confidential Data

Examples of Confidential Data

The following list is not intended to be exhaustive but provides guidelines on what type of information is typically considered confidential.  Confidential data can include:

• Customer, employee and partner personally identifiable information (PII)
• Medical and healthcare information
• Customer data
• Product financial data
• 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
• Credit card information
• Any confidential data held for a third party (be sure to adhere to any confidential data agreement covering such information)

Use of Confidential Data

A successful data security Policy is dependent on Product personnel knowing and adhering to Product’s standards involving the treatment of confidential data.  The following applies to how Product personnel must interact with confidential data:

• Personnel must be advised of any confidential data to which they have been granted access.  Such data must be marked or otherwise designated “confidential.”
• Personnel may only access confidential data to perform their job functions.
• Personnel must not seek personal benefit, or assist others in seeking personal benefit, from the use of confidential information.
• Personnel must protect any confidential data to which they have been granted access and not reveal, release, share, email unencrypted, exhibit, display, distribute, or discuss the information unless necessary to do their job or the action is approved by their supervisor.
• Personnel must report any suspected misuse or unauthorized disclosure of confidential information immediately to their supervisor in accordance with Section 5 of Product’s Emergency Management Plan for Data Security Incidents.
• If confidential data is shared with third parties, such as contractors or vendors, a confidential data or non-disclosure agreement must govern the third parties’ use of confidential data.

Security Controls for Confidential Data

Confidential data requires additional security controls in order to ensure its integrity.  Product requires that the following guidelines are followed:

• Strong Encryption. Strong encryption must be used for confidential data transmitted outside of Product.  If confidential data is stored on laptops or other mobile devices, it must be stored encrypted or password protected.
• Authentication. Strong passwords must be used for access to confidential data. See Section 5.0.
• Background Checks. All personnel, new employees and anyone requiring access to or managing access of confidential data must successfully pass a background check prior to being granted the privileged access.
• Physical Security. Systems and paper that contain confidential data should always be secured.
• Printing. When printing confidential data, the user should use best efforts to ensure that the information is not viewed by others.  Printers used for confidential data must be located in secured areas.
• Faxing. When faxing confidential data, personnel must use cover sheets that inform the recipient that the information is confidential. 
• Emailing. Confidential data must not be emailed outside Product without the use of strong encryption.
• Discussion. When confidential data is discussed, it should be done in non-public places and where the discussion cannot be overheard.  If confidential data is written on a whiteboard or other physical presentation tool, the data must be erased after the meeting is concluded.
• Redaction. Confidential data must be removed from documents unless its inclusion is absolutely necessary.
• Storage. Confidential data must never be stored on non-Product-provided machines (i.e., home computers and personal mobile devices).

Expanded Security Controls for Credit Card Data

Credit card data is a special type of confidential data requiring additional security controls and specifications.  Credit card data must be protected in accordance with PCI-DSS.  Specifically, but not exclusively:

• All access to credit card data is logged via NetSuite CRM, where access log and card numbers are retained indefinitely.
• Credit card PANs must never be sent via any unsecure communication method such as email, fax, IM, or voicemail.
• Credit card data must never be written, copied, or stored on paper.
• The only acceptable method for communicating full PANs is a completed DocuSign template or a direct phone call to a Product Solutions Consultant, who will accept and enter the PANs into the NetSuite CRM.

• Password Security

• General

• All system-level passwords (for example, root, admin, application administration accounts, etc.) must be changed every 90 days.
• All Product personnel-level passwords such as workstation and e-mail passwords must be changed every 90 days  
• User accounts that have system-level privileges granted through group memberships must have a unique password from all other accounts held by that user.
• Product uses two-factor authentication for email accounts, which is valid for thirty (30) days on the same computer.  After thirty (30) days, the user must re-authenticate their account.
• All default vendor settings for wireless must be changed.  This includes but is not limited to, Simple Network Management Protocol (SNMP) strings, passwords, and if possible, user names.  
• Where SNMP is used, the community strings must be defined as something other than the standard defaults of “public,” “private” and “system” and must be different from the passwords used to log in interactively.  A keyed hash must be used where available (e.g., SNMPv2).

• Password Guidelines

All user-level and system-level passwords must conform to the guidelines described below.

• Passwords shall be allocated on an individual basis to provide accountability. Passwords must not be shared with anyone, including with IT. If IT does require knowledge of a password to troubleshoot a problem that password MUST be changed upon completion of their efforts by the employee.
• Passwords must not be transmitted in emails or other in-secure electronic communications.
• Passwords must not be written down on paper and stored or stored in any electronic document. 
• Systems will operate an account lockout policy to prevent unauthorized access to systems using brute-force or dictionary-based attacks. This means that a maximum of 5 incorrect attempts at password input will be allowed before an account is locked out. All unsuccessful logon attempts will be logged.
• Contain at least ten (10) characters. Some applications will allow eight (8) characters but the main network access must be ten (10) characters or more. 
• Passwords must begin with a letter
• Where possible, passwords history will be enforced to prevent users selecting a recently used password. Users must not choose any of their last 5 passwords.
• Passwords cannot contain 5 consecutive characters (or more) from a previous password.
• Users must choose strong, random passwords. Where possible, password complexity will be enforced by the systems. This means that users will be required to choose a password that includes:
  • Upper and lower-case alphabet characters;
  • Numeric characters; and/or special characters (e.g. #$%@*).
• Passwords must not contain commonly used words that can be found in an English or foreign language dictionary.
• Passwords must not contain other words that could be guessable or be found in common word lists, such as names, places, birthdays, etc.
• Passwords must not be the same as the user ID.
• Users will be required to change their passwords at least every 90 days.
• Users will be required to re-enter their password into systems after no more than 30 minutes of inactivity.

• Avoid characteristics of weak passwords:

• Words found in a dictionary (English or foreign) 
  • Names of family, pets, friends, co-workers, fantasy characters, etc. 
  • Computer terms and names, commands, sites, companies, hardware, software 
  • Any derivative of common Product terms 
  • Birthdays and other personal information such as addresses and phone numbers 
  • Word or number patterns like aaabbb, qwerty, zyxwvuts, 123321, etc. 
  • Any of the above spelled backwards 
  • Any of the above preceded or followed by a digit (e.g., secret1, 1secret) 

• Password Protection Standards

• Do not write down or store passwords on-line without encryption.
• Do not reveal a password in email, other electronic communication, questionnaire or security form.
• All usernames must be unique and the use of shared accounts is prohibited.
• Do not speak about a password in front of others. 
• Change system-level password every ninety (90) days. 
• Change personnel-level password every one hundred sixty (160) days.
• Do not hint at the format of a password (e.g., “my family name”). 
• If someone demands a password, refer them to this Policy and direct them to the Information Technology department. 
• Passwords are to be transmitted only after verification of end-user by either sight or confirming telephone number. 
• Consultant or vendor accounts are required to be set to expire after a period of thirty (30) days or under to ensure that the accounts are still valid and needed. 

• Network Security

• Server Security

• Ensure that Windows / Linux & MacOS Server updates are applied on a regular basis.
• Check backup jobs to ensure that they complete successfully and that the backups are valid.
• For users logging in over Remote Desktop Connection, ensure that they are logging in on a non-default port and are logging off the server to free any used resources instead of simply closing their RDC windows.
• Remote Desktop Services will always prompt a client for passwords upon connection.
• Remote Desktop Services will be configured with the client connection encryption set to the required level.
• Control access to exported files, for the protection of critical systems, monitoring file integrity.
• Delete users and groups that are no longer in use.
• Remove services and software packages that are not required for the server.
• Limit the access to services when possible.
• Scan server for viruses, rootkits, backdoors and local exploits.
• Encrypt data when needed.
• The shutdown option will not be available from the logon dialog box.
• Local volumes will be formatted using NTFS or approved format.
• The required legal notice will be configured to display before console logon.
• Anonymous enumeration of shares will be restricted.
• The system will be configured with a password-protected screen saver.
• Autoplay will be disabled for all drives.
• Network shares that can be accessed anonymously will not be allowed.
• If the time service is configured, it will use an authorized time server.

1. Firewall Security

Every firewall must have the following configuration standards prior to implementation:

• Intrusion Detection System. 
• No local accounts and the built-in admin account(s) must be renamed and password changed.  

• Any firewall rule change must be approved via Product’s Change Management Policy prior to implementation.  
• The enabled or privileged password on the firewall must be kept in a secure encrypted form and must be changed on a regular basis.
• Disallow the following:
  • IP directed broadcasts
  • Incoming packets at the sourced with invalid addresses, such as RFC1918 address
  • Transmission Control Protocol (TCP) small services
  • User Data Protocol (UDP) small services
  • All source routing
  • All web services running on firewall
  • Any unsecure protocols not specifically allowed by the firewall protocol Policy
• Idle timeout for a period of inactivity in a management console must be enabled to prevent unauthorized users from accessing the management console. 
• Access rules are to be added as business needs arise after approval through rule review process. 
• Firewall rule sets are subject to quarterly review. 
• The firewall configuration must satisfy the minimum requirement of supporting 3DES (triple-DES).  
• The Use of IPSEC VPN tunnel(s) is limited to approved users and must use the best security available. 
• Implement Internet Security Association and Key Management Protocol (ISAKMP) Policy parameters on all firewalls.  
• Secure Shell (SSH) is the preferred management protocol. Telnet is forbidden for use as the management protocol for the firewall unless there is a secure tunnel protecting the entire communication path.  HTTPS is allowed IF and ONLY if SSH is not an option, but satisfying Policy item #1 is REQUIRED for authentication. 
• Remove unused rules from the firewall rule bases when services are decommissioned.
• Organize Firewall Rules for Performance.

• Wireless Security

Security Configuration

• The Service Set Identifier (SSID) of the access point must be changed from the factory default.  
• Encryption must be used to secure wireless communications.  Stronger algorithms are preferred to weaker ones (i.e., WPA2 and Radius).  Encryption keys must be changed and redistributed quarterly.
• Administrative access to wireless access points must utilize strong passwords.
• Vendor default settings are to be changed prior to use.
• All logging features should be enabled on Product’s access points.
• Security profile is configured to protect not only access point from wireless attacks, but also SSID and clients associated to the SSID.

• Access to backend systems via mobile devices is restricted by access control lists and password security in order to limit access to data.  (Password security in this instance is defined as having unique accounts per device that are not shared on backend system which restricts area of access.)
• Enabling and configuration of Wireless Intrusion Prevention System (WIPS) (when available) is required in order to protect not only the wireless access point (WAP) but the end-user as well.  

Installation

• Software and/or firmware on the wireless access points and wireless network interface cards (NICs) must be updated prior to deployment.
• Wireless networking must not be deployed in a manner that will circumvent Product’s security controls or be easily accessible to. 
• Wireless devices must be installed only by Product’s Information Technology department.
• Channels used by wireless devices should be evaluated to ensure that they do not interfere with Product equipment.

Inactivity

• Personnel should disable their wireless capability when not using the wireless network.
• Inactive wireless access points should be disabled.  If not regularly used and maintained, inactive access points represent an unacceptable risk to the Product.

Audits

• The wireless network must be audited twice each year to ensure that this Policy is being followed.  Specific audit points should be: location of access points, signal strength, SSID, and use of strong encryption.

• Time Synchronization

• Product employs a central time server sync’d to time.nist.gov.
• All network devices, servers, and workstations must sync to the Product’s central time server.
• Any devices not able to communicate with the central time server must sync independently to time.nist.gov and must not have any devices sync their time to said device.
• Access to time settings must be restricted to administrators.
• Systems logging must include changes to time settings whenever possible.
• Central time server must be reviewed periodically to verify functionality, accessibility, and time accuracy.

• Central Log Management

Central Log Servers

The logs contained on the servers are restricted to production servers, network devices, and any system deemed critical to the day-to-day business operations at Product.

Restricted Access

Access to the central log server is restricted to senior level Product Information Technology department staff. Only authorized personnel are allowed to access the system via SSH or an encrypted form of remote access. 

Log Delivery

Product log delivery is via socket over secure network links.  Depending on the system role, the proper server will be selected to ship logs for analysis.

Notification Mechanisms

Each system is configured to alert on predefined thresholds, including but not limited to system health, disk utilization, failed logins attempts. 

Logging Configuration

Dependent on system role, each system is required to be configured to deliver the following logs for audit and retention purposes.  

• Account Log-on Events – Success and Failure
• Account Management Events – Success and Failure
• Logon Events – Success and Failure
• Network Events – ALL
• Policy Change Events – Success and Failure
• Privilege Use Events – Failure
• System Events – Success and Failure
• Directory Service Access Events – Domain Controller restricted

Log Data Review

Log data are required to be reviewed on a weekly basis. 

Log Backup

Log files are to be backed up (compressed to preserve disk space) on a 24 hour schedule.  

Log Storage

Log files are to be stored for a period of ninety (90) days.

• Anti-Virus

All Product systems must have standard, supported anti-virus software installed and scheduled to run at regular intervals. In addition, the anti-virus software and the virus pattern files must be kept up-to-date. Virus-infected computers must be removed from the network until they are verified as virus-free.  Any activities with the intention to create and/or distribute malicious programs into Product’s networks (e.g., viruses, worms, Trojan horses, e-mail bombs, etc.) are prohibited. 

All systems are required to run the standard, supported anti-virus software (“Anti-Virus”) that is installed and maintained by the Information Technology department.

Anti-Virus must be configured to perform the following actions upon detection of a potential threat

• Delete as primary action
• Quarantine as secondary action

Anti-Virus is required to:

• Send log alerts including but not limited to malware infection, root kit infection, and outbreak threat;
• Send notification alerts including but not limited to malware infection, root kit infection, and outbreak threat;
• Use heuristic technology to provide an additional layer of zero-day threat protection;
• Run scheduled scans (full) on a weekly basis;
• Update detection signatures on an hourly schedule, and if an hourly schedule is not possible or an option, anti-Virus must be configured to update detection signatures on a daily schedule; 

Personnel must be instructed to:

• Never download files from unknown or suspicious sources; 
• Never open any file or macros attached to an e-mail from an unknown or suspicious source; 
• Exercise caution when connecting to untrusted networks as risk of virus infection is high;
• Exercise caution before connecting any unknown portable storage devices (USB flash drive) to Product-owned equipment.  

• Change Management

Every change to Product business technology resources including but not limited to: operating systems, hardware, network infrastructure, and applications is subject to this Policy and must follow these procedures. A Product Change Management Committee (CMC) will review change requests to ensure that change reviews and communications are being satisfactorily performed. 

Change Management procedures include:

• A Change Review Meeting is scheduled and key Information and Technology Services stakeholders are required to attend.  The meeting occurs quarterly. 
• A formal change request must be submitted for all changes, both scheduled and unscheduled. 
• Change requests must contain all of the following:
  • Change plan
  • Backup plan
  • Backout plan
  • Test plan or validation plan
  • Progress notes and change outcome
• All scheduled change requests must be submitted so that the CMC has time to review the request, determine and review potential failures, and make the decision to allow or delay the request.
• Each scheduled change request must receive formal CMC approval before proceeding with the change. 
• The CMC may deny a scheduled or unscheduled change for reasons including, but not limited to, inadequate planning, inadequate back out plans, the timing of the change will negatively impact a key business process such as year-end accounting, or if adequate resources cannot be readily available. Adequate resources may be a problem on weekends, holidays, or during special events.
• When possible, changes must first be performed in a test environment and cannot be moved to production until validation of successful change in test is acknowledged by someone other than the person performing the change and the move is approved by IT senior management.
• When possible, the test environment must be segmented off from the production environment, with no communication permitted between the two segments.
• When moving changes into production, confidential data must not be moved from test to production.
• A Change Review must be completed for each change, whether scheduled or unscheduled, and whether successful or not. 
• A Change Management Log must be maintained for all changes. The log must contain, but is not limited to: 
  • Date of submission and date of change
  • Owner and custodian contact information
  • Nature of the change
  • Indication of success or failure

• User Provisioning

• Each user with access to the Product network or any Product application must have a unique account login.
• All account creation and modification requests must follow these guidelines and procedures
  • Accounts should only be requested for users with a business need for accessing the specific network and application in order to perform their job function.
  • Account rights will only be given in order for a user to perform their job function, following the principal of least privilege.  
• Access for third parties will remain deactivated until requested to be activated by a member of IT leadership or infrastructure team.
• Once third party has completed work, the original requestor will notify the infrastructure team so the access can be revoked.
• As a secondary control, all third party accounts expire every 30 days and are reviewed for need on a monthly basis
• The request and provisioning process is as follows for each account type.  Any non-standard requests must be supplemented by written correspondence.
  • NETWORK ACCOUNT 
    • All network account creation and modification requests are initiated by the department head responsible for the user for which the request is being made.
    • A member of Product’s infrastructure team will complete the request according to guidelines, including the password guidelines for creation, expiration, and communication.

• Remote Access

• Remote access is granted to Product users only on an as-needed basis.
• For authorized users, remote access to the Eco Material network may be made only by using the Eco Material VPN or by an authorized RDS capability.
• Two-factor authentication is required for all remote access sessions. All Eco Material remote access users will be issued a Duo Account on their mobile device.
• Remote access credentials, including usernames, passwords, and physical authentication tokens, must not be shared.
• Remote access client software and configuration files must not be copied on to unauthorized devices.
• Remote access sessions must be initiated from the approved mobile device. Knowledgeable users must not configure home routers or other networking equipment to initiate the session.
• Re-configuration of devices used for remote access to support dual-homing or split-tunnelling is not permitted.
• Remote access facilities are provided for business use only. Remote access must not be used for general Internet access or other personal use.
• The loss or theft of remote access tokens must be reported immediately to Eco Material Help Desk.
• System and Network Administrators must ensure that VPN systems are configured in accordance with the requirements of the Eco Material Network Security Standard.
• VPN sessions are automatically disconnected after one hundred eighty (180) minutes of inactivity.
• RDP server sessions are automatically disconnected after sixty (60) minutes of inactivity and the default port should be changed.

• Network Scanning and Security Assessment

Product performs the following network vulnerability and penetration testing activities: 

• Run internal and external network vulnerability scans and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).  In the event of a failed scan, remediation must take place and the scan re-run.  Remediation must be completed promptly.
• Run continuous wireless vulnerability assessments.  All vulnerabilities must be immediately addressed.
• Through third-party, perform yearly external penetration testing.  Any critical, high, or PCI-related exploited vulnerabilities are remediated promptly.

• Risk Assessment

On an annual basis or as needed basis, but no less frequent than annually, Product’s IT leadership and infrastructure teams perform a detailed, comprehensive IT security risk assessment.  The risk assessment must include the following process phases and tasks:

Discover 

• Review of most recent internal and external vulnerability scan results
• Review of most recent internal, external, and wireless pen test results
• Discuss new threats resulting from new vulnerabilities, hacking techniques, information security trends, security threats
• Discuss any upcoming relevant regulatory changes or End-of-Life (EOL) deadlines 
• Discuss any other security bulletins or advisories that have been received

Assess

• Determine any weaknesses discovered from scans and pen tests that have not already been remediated
• Determine any exposures resulting from new threats

Plan

• Categorize threats based on risk and required timeline to address/remediate
• Establish remediation plan to for each threat
• Determine course of action for any changes needed for compliance reasons
• Establish communication plan to alert others as needed of potential risks and plans

Execute

• Carry out remediation plan 
• Establish and implement compensating controls for those threats which cannot be fully addressed through remediation

Re-Assess

• Confirm all risks have been mitigated successfully
• Repeat process for all critical risks which have not been addressed

• Security Incident Response

Product has established and maintains policies and procedures regarding information security incident response. Such information security incident response procedures shall include:

Engage

• Engage legal counsel and third-party service provider.

Assess

• Immediately review all findings associated with information security incident, including vulnerabilities, techniques, and mitigation strategies.

Plan

• Establish remediation plan in coordination with legal counsel and third-party service provider.

Execute

• Carry out remediation plan 
• Communicate and/or provide notification to law enforcement, partners, and impacted individuals, as necessary.

Post-Incident Review

• Carry out remediation plan 
• Perform post-incident review of events and actions taken, including reasonably and appropriately addressing any identified gaps.

• Service Providers

For service providers that interact with credit card data or the credit card data environment, the following requirements are in place and must be adhered to:

• Selection process of new service providers must be structured and include documentation of Product’s requirements, evaluation criteria, and due diligence of the service provider. 
• Written agreement or contract between Product and each service provider.
• Service provider must agree in writing to provide their services in a PCI-compliant manner.
• Account and service review with service provider on at least an annual basis and service review to make sure services are being provided in accordance with the agreement and to establish service provider is continuing to provide in a PCI-compliant manner.
• Maintain a current matrix of service providers and the PCI-DSS requirements they are responsible for or participate in managing or maintaining.

• Security & Training

Data security is a key focus for Product, and a responsibility of all users with network and application accounts.  Security and awareness is a key tool to ensure users are equipped to fulfill their responsibilities in this space.  Product requires the following review and training:

All Personnel

All personnel with a network or application account, or that interact in any way with credit cards will receive the following training/communication regarding information and credit card security practices, trends, and threats.

• Required review of this Information Security Policy upon hire or upon being granted and account.
• Annual compliance training with detailed review of information and credit card security practices, including acknowledgement of understanding and acceptance of the training and practices by personnel, either electronic or written.
• Periodic bulletins and memos regarding key reminders, current threats, areas of observed weaknesses.

IT Leadership and Security Personnel

All personnel that work with IT security, as well as IT leadership must take the following measures to remain current with information security practices, trends, and threats.

• Subscribe to multiple security-focused or security-related newsletters.
• Have active membership in credible websites providing security bulletins.
• Attend at least one webinar, seminar, or conference annually with a strong security emphasis.
• Through above methods or via independent method, stay current with data security best practices.

• Enforcement

Product personnel found to have violated this Policy may be subject to disciplinary action, up to and including termination of employment.

• Revision History

When revisions are made to this Policy, it will be documented with a brief description below.

Revision History Revision	Date	Author	Comments