SkillSetz Security Policies and Procedures

Sligo Software, Inc  d/b/a SkillSetz PCI Compliance Related Information  Security Policies and Procedures
Version 1.0 - October 1, 2021 (Exhibit C)


1. Introduction and Scope

1.1 Introduction

This document explains SkillSetz (SkillSetz Inc.)’s information security requirements for all employees.  SkillSetz management has committed to these security policies to protect information utilized by SkillSetz in attaining its business goals.  All employees are required to adhere to the policies described within this document.

1.2 What is Payment Card Industry (PCI) Compliance? 

The Payment Card Industry Data Security Standard (PCI DSS) Program is a mandated set of security standards that were created by the major credit card companies to offer merchants and service providers a complete, unified approach to safeguarding cardholder data for all credit card brands. 

In September of 2006, a group of five leading payment brands including American Express, Discover Financial Services, JCB, MasterCard Worldwide, and Visa International jointly announced the formation of the PCI Security Standards Council, an independent council, established to manage the ongoing evolution of the PCI standard. 

The PCI Data Security Standard requirements apply to all payment card network members, merchants, and service providers that store, process or transmit cardholder data.  The requirements apply to all methods of credit card processing, from manual to computerized; the most comprehensive and demanding of which apply to e-commerce websites, and retail POS systems that process credit cards over the Internet. This document addresses all the requirements of the Payment Card Industry Data Security Standard (PCI DSS). For more information about this standard visit the official website at:

1.3 Scope of Compliance

The PCI requirements apply to all “system components.”  System components are defined as any network component, server, or application that is included in or connected to the cardholder data environment. The cardholder data environment is defined as part of the network that possesses cardholder data or sensitive authentication data.  For example, the following types of systems would be in scope for compliance within any environment:

  • Systems storing cardholder data (e.g. databases, PC’s used by accounting for generating reports)
  • Systems processing cardholder data (e.g. web servers, application servers, etc)
  • Network devices transporting or directing cardholder traffic (e.g. border router, DMZ firewall, intranet firewall, etc.)
  • Devices that create media containing cardholder data (e.g. fax machine, printer, backup tape silo)
  • Support systems (e.g. Active Directory, Syslog server, IDS, PC’s performing support functions such as system administration, etc.)

These policies and procedures shall only apply within the PCI environment identified in the PCI Environment Description (Appendix P).

Since SkillSetz doesn’t store or transmit cardholder's data in its network, this policy is shortened to meet the appropriate scope of compliance. 


2. Policy Rules and Responsibilities

2.1 Policy Applicability

All employees, contractors, vendors and third parties that use, maintain, or handle SkillSetz information assets must follow this policy. Policy exemptions will be permitted only if approved in advance and in writing by the DevOps Team Leader.

2.2 DevOps Team Leader

The DevOps Team Leader is responsible for coordinating and overseeing SkillSetz's wide compliance with policies and procedures regarding the confidentiality, integrity, and security of its information assets.

Specific responsibilities of the DevOps Team Leader include,

  • Make high-level decisions pertaining to the information security policies and their content.  Approve, in advance, exceptions to these policies on a case-by-case basis.
  • On an annual basis, coordinate a formal risk assessment to identify new threats and vulnerabilities and identify appropriate controls to mitigate any new risks
  • Annually review the Information Security policies and procedures to maintain adequacy in light of emergent business requirements or security threats.
  • Make sure that third parties (contractors, vendors, business partners), with whom cardholder data is shared, are contractually required to adhere to the PCI DSS requirements and to acknowledge that they are responsible for the security of the cardholder data which they process.
  • Maintain updated and distribute the Response Plan and Procedures (Section 14) to all users. 
  • Complete tasks as required by the Periodic Operational Security Procedures (Appendix F).

2.3 DevOps Team 

Successfully securing SkillSetz information systems requires that the various departments and groups consistently adhere to a shared vision for security. 

The DevOps Team works with departmental system managers, administrators, and users to develop security policies, standards, and procedures to help protect the assets of SkillSetz.

The DevOps Team is dedicated to security planning, education, and awareness. Specific responsibilities of the DevOps Team include,

  • Create new information security policies and procedures when needs arise. Maintain and update existing information security policies and procedures.  Review the policy on an annual basis and assist management with the approval process.
  • Act as a central coordinating department for the implementation of the Information Security Policies. 
  • Create, maintain and distribute incident response and escalation procedures.
  • Monitor and analyze security alerts and distribute information to appropriate information security, technical and business unit management personnel. 
  • Assist the DevOps Team Leader with publishing and disseminating SkillSetz information security policies and acceptable use guidance to all relevant system users, including vendors, contractors, and business partners.
  • Verify that employees attend security awareness training upon hire and at least annually.
  • Work with the DevOps Team Leader on disseminating security awareness information to system users utilizing multiple methods of communicating awareness and educating employees (e.g. posters, letters, emails, meetings, etc).
  • Work with the DevOps Team Leader to administer sanctions and disciplinary action relative to violations of Information Security Policy. 
  • Publishing and disseminating SkillSetz information security policies and acceptable use guidance to all relevant system users, including vendors, contractors, and business partners.
  • Verify that employees attend security awareness training upon hire and at least annually.
  • Handle confidential or sensitive information disposal upon employment termination of the employee.
  • Complete tasks as required by the Periodic Operational Security Procedures (Appendix F).

2.4 DevOps Team Member

SkillSetz DevOps Team Members are the direct link between information security policies and the network, systems, and data. DevOps Team Member responsibilities include,

  • Applying SkillSetz information security policies and procedures as applicable to all information assets.
  • Administering user account and authentication management. 
  • Assisting the DevOps Team with monitoring and controlling all access to SkillSetz data. 
  • Completing tasks as required by the Periodic Operational Security Procedures (Appendix F).

2.5 Users

Each user of SkillSetz computing and information resources must realize the fundamental importance of information resources and recognize their responsibility for the safekeeping of those resources. Users must guard against abuses that disrupt or threaten the viability of all systems. The following are specific responsibilities of all SkillSetz information system users,

  • Understand what the consequences of their actions are with regard to computing security practices and act accordingly.  Embrace the “Security is everyone’s responsibility” philosophy to assist SkillSetz in meeting its business goals.
  • Maintain awareness of the contents of the information security policies. 
  • Read the SkillSetz Security Awareness and Acceptable Use Policy (Appendix A).
  • Classify confidential and sensitive information that is received unclassified. Limit the distribution of this information accordingly.


3. IT Change Control Policy

3.1 Policy Applicability

All proposed changes to SkillSetz network devices, systems, and application configurations must follow this policy.

3.2 Change Request Submittal

The responsible party that will be implementing the change must complete and submit a Change Request in the form of the Project Management System ticket to the DevOps Team.

3.3 Change Request Approval

After all planning and documentation is completed, all relevant management must sign off the Change Request by changing ticket status.

3.4 Change Testing

Prior to introduction into the production network or systems, all changes must first be tested on a QA or test environment isolated from the production environment. 


4. Data Classification and Control Policy

4.1 Policy Applicability

All data stored and accessed on SkillSetz information systems, whether managed by employees or by a third party, must follow this policy. Policy exemptions will be permitted only if approved in advance and in writing by the DevOps Team Leader.

Since SkillSetz doesn’t transmit or store cardholder's data, the only confidential or sensitive information is in terms of having access to production environments that are disclosed in the User Authentication Policy below.

4.2 User Authentication

4.2.1 Users

Each user’s access privileges shall be authorized according to business needs. All privileges must be assigned based on job classification and function. Access control systems must have a default “deny-all” setting.

The use of non-authenticated (e.g. no password) user IDs or user IDs not associated with a single identified user are prohibited. Generic, shared or group user IDs must be disabled or removed and must never be used to administer system components.

Every user must use a unique user ID and a personal secret password/passphrase for access to SkillSetz information systems and networks. 

All users must acknowledge understanding of the SkillSetz Information Security Policies by reading and signing the SkillSetz Security Awareness and Acceptable Use Policy (Appendix A) prior to being allowed to access SkillSetz information systems and networks.

Users must be provided documented guidance on the following:

  • Selecting strong authentication credentials.
  • How to protect their authentication credentials.
  • Instructions not to reuse previously used passwords.
  • Passwords must be changed if there is any suspicion the password could be compromised.

4.2.2 Systems

Access to production environment SkillSetz admin panel ensures that only authorized users can access it. The process includes:

  • Control addition, modification, and deletion of all user credentials and other identifier objects
  • Identify each User through a unique user identifier (user ID).
  • SkillSetz employee user ID will consist of the employee’s corporate email address that consists of the user's first initial, dot, and last name. Some certain specific email addresses will consist of only the first name of the user.
  • If the chosen user ID is already being used, the digit ‘1’ should be added at the end. If the resulting user ID is also being used, increment the digit until a unique user ID is found. 
  • Authenticate every user, system, and application ID with a password.
  • Require all passwords to be at least 7 characters in length.
  • Require complex passwords, consisting of both numeric and alphabetic characters.
  • Require that new passwords cannot be the same as the 4 previously used passwords.
  • Lockout accounts after not more than 6 invalid login attempts.
  • Require that once a user account is locked out it remains locked for 30 minutes or until the DevOps Team Member resets the account.
  • Require system/session idle time out of 24 hours.
  • Require passwords to be reset at least every 90 days. Note: Service level accounts (e.g. accounts that are not used interactively by users to log in) may be exempt from this requirement with management approval.  Administrative user IDs (e.g. root, system admin, database admin, etc) must comply.
  • Encrypt all passwords during transmission and storage on all system components (e.g. in scripts and databases, connection strings, inside compiled code, etc).
  • Immediately revoke access for any terminated users.
  • Remove or disable inactive users at least every 90 days. 
  • First-time passwords must be set to a unique value for each user.
  • First-time passwords must be changed after the first use.
  • Reset passwords must be set to a unique value for each user.
  • Reset passwords must be changed after the first use.

Access to the production server has key-based access only where the key is authorized and disposed of by the DevOps Team according to onboarding and offboarding processes.

Access to production admin through firewall disclosed in Firewall Security Administration (Section 7). 


4.3 Account and Access Management

4.3.1 DevOps Team Responsibilities

The DevOps Team will approve access authorization based on employees’ job classification and function as discussed in the Data Access Request Process (Section 4.3.1). 

The DevOps Team, in conjunction with business unit management, will maintain a role-based access control (RBAC) by defining the different roles and their minimum access levels. The Access Control Matrix (Appendix Q) must be used to document the RBAC.

The DevOps Team will perform a quarterly audit of computer resource authorizations to confirm that access privileges are appropriate. The audit will consist of validating access rights for sample user populations (including a sample of privileged accounts). 

4.3.2 DevOps Team Member Responsibilities

The DevOps Team Member has the following responsibilities regarding user account and access management:

  • Account creation requests must specify access either explicitly or via a “role” that has been mapped to the required access. 
  • Access must be immediately revoked for terminated or transferred users or for any user whose access is no longer required. 
  • User IDs shall be disabled after sixty (60) days of inactivity. After an additional thirty (30) days, disabled user IDs must be purged. These requirements may not apply to certain specialized accounts (e.g., admin, root, etc.). In those instances, the DevOps Team Member must provide a written waiver to the DevOps Team and document the compensating controls around access to the accounts.
  • Passwords set by DevOps Team Members must be changed by the user immediately upon the users’ next login.  DevOps Team Members must set initial passwords that are unique and compliant with the password rules.
  • Vendor accounts used for remote maintenance must only be enabled during the time that access is needed and monitored while being used.


5. Data Retention and Disposal Policy

5.1 Policy Applicability

All data deemed confidential or sensitive by the DevOps Team which is stored on SkillSetz networks and systems must follow this policy. Exemptions from this policy will be permitted only if approved in advance and in writing by the DevOps Team Leader.

Since SkillSetz doesn’t transmit or store card holders' data, the applicability of this policy is limited.

5.2 Retention Requirements

All confidential and sensitive data, regardless of storage location, will be retained only as long as required for legal, regulatory, and business requirements. The specific retention length will be established by the data creator or DevOps Team Leader.

5.3 Disposal Requirements

All confidential or sensitive electronic data, when no longer needed for legal, regulatory, or business requirements, must be securely removed from SkillSetz systems using an approved method documented in this policy. This requirement includes all data stored in systems, temporary files, or contained on storage media.

All confidential or sensitive hardcopy data, when no longer needed for legal, regulatory, or business requirements, must be disposed of by using an approved method documented in this policy. See the Paper and Electronic Media Policies (Section 6) for more details.

5.4 Disposal Process

Since confidential or sensitive data is represented by only access to the production environment, the disposal process is for manual removing of the authorized key of an employee from the production environment within one day of the offboarding process start as well as revoking Magento admin panel access in terms of firewall and login credentials.


6. Paper and Electronic Media Policies

6.1 Policy Applicability

All employees handling hardcopy or electronic media must follow this policy. Exemptions from this policy will be permitted only if approved in advance and in writing by the DevOps Team Leader.

Since SkillSetz doesn’t transmit or store cardholder data, the applicability of this policy is limited. SkillSetz doesn’t store any confidential or sensitive information on paper or electronic media.


7. Firewall Security Administration Policy

7.1 Policy Applicability

All firewalls and routers on SkillSetz networks, whether managed by employees or by third parties, must follow this policy. Exemptions from this policy will be permitted only if approved in advance and in writing by the DevOps Team Leader.

Since SkillSetz doesn’t store or handle cardholder data apart from being responsible for embedding payment gateway, no extra firewall configuration is applied to SkillSetz networks. 

However, access to the SkillSetz admin login page has a firewall restriction disclosed below.

7.2 DevOps Team  Responsibilities

  • Manage firewall access to the production environment
  • Add internal users to firewall rules according to IT Change Control Policy (Section 3)
  • Add external users only per the Client’s written request with the appropriate System Configuration Record
  • Remove access according to Data Retention and Disposal Policy (Section 5)

7.3 Configuration

At least every 6 months, the DevOps Team must thoroughly review each firewall rule set and record results of the review in the System Configuration Record (Appendix H) of the device in question. The review must include the removal, when merited, of unused or unnecessary access paths. All proposed changes identified as a result of this review must be performed as described in the IT Change Control Policy (Section 3).


8. System Configuration Policy

8.1 Policy Applicability

All servers and network devices on SkillSetz networks, whether managed by employees or by third parties, must be built and deployed in accordance with this policy. Exemptions from this policy will be permitted only if approved in advance and in writing by the DevOps Team Leader.

8.2 System Build and Deployment

8.2.1 System Purpose

All computing systems should be designated for a single primary purpose where possible (e.g., web servers, database servers, and DNS should be implemented on separate servers). 

8.2.2 System Configuration Standards

All systems, prior to deployment in the production environment must conform to the System Configuration Standards (Appendix B). Deviations require written approval by the DevOps Team Leader and must be noted on the System Configuration Record (Appendix C) for the system. 

8.2.3 System Configuration Records

System Configuration Record (Appendix C) must be completed for all deployed systems at the time of installation and kept on file for as long as the system is in service. This form must be updated with any future modifications to system configurations.

8.2.4 System Configuration Process

All-new system deployments will follow this high-level procedure:

  • Install the operating system.
  • Update all operating system software per vendor recommendations.
  • Configure operating system parameters and secure the system according to the system configuration build documentation described in the System Configuration Standards (Appendix B)
  • Install applications and software:
  • Install system-specific applications and software according to System Configuration Record (if this is a replacement for an existing system).
  • Install applications and software necessary for the system’s primary function.
  • Update all application software per vendor recommendations.
  • Configure application parameters according to the System Configuration Standards (Appendix B).
  • Complete system-specific System Configuration Record (Appendix C) and maintain it on file.
  • Ensure that all vendor-supplied defaults are changed before the system goes into production. For example, change all default passwords and simple network management protocol (SNMP) community strings, and eliminate all unnecessary accounts.
  • Verify that risky protocols, such as FTP and TELNET, are never used in the PCI environment or are encrypted using SSH or other technology.

8.2.5 Anti-virus Software

All servers, workstations, and laptops utilizing an operating system commonly affected by viruses must have anti-virus software installed as described in the Anti-virus Policy (Section 9).

8.2.6 Vulnerability Identification

Members of the DevOps Team must be informed of information security issues and vulnerabilities applicable to SkillSetz computing systems. When security issues are identified, the DevOps Team is responsible for notifying appropriate personnel, including DevOps Team Members.

The primary method for identifying new threats as they arise will be through vendor and security-specific Internet mailing lists, SkillSetz System Configuration Standards (Appendix B) must be updated to reflect measures required for protection from any newly discovered vulnerability.

SkillSetz will inform clients of new security patches available to any system installed according to SkillSetz System Configuration Standards (Appendix B).

8.2.7 Security Patch Deployment

The Information Security Department must use reputable, external sources in order to maintain awareness of and identify new vulnerabilities.

When new vulnerabilities are identified, a risk ranking must be assigned to identify “high risk” and “critical” vulnerabilities.

All critical security patches, identified by the DevOps Team or the DevOps Team Member, must be installed on applicable systems within 30 days of vendor release. 

Security patch, hot-fix, and service pack installation must be applied to devices and systems within an appropriate timeframe approved by the DevOps Team and based on a previous risk analysis. All installation of patches must follow the IT Change Control Policy (Section 3).


9. Anti-Virus Policy

9.1 Policy Applicability

All systems commonly affected by viruses such as servers, workstations, and laptops on SkillSetz networks, whether managed by employees or by third parties, must follow this policy. Exemptions from this policy will be permitted only if approved in advance and in writing by the DevOps Team Leader.

9.2 Software Configuration

All applicable systems must be configured with DevOps Team-approved anti-virus software. The anti-virus solution must be able to detect, remove and protect against all known types of malicious software such as viruses, Trojans, worms, spyware, adware, and rootkits. 

9.3 Signature Updates

All systems with anti-virus software must be configured to update virus signatures and scan engines on at least a daily basis.


10. Incident Response Plan and Procedures

10.1 Policy Applicability

All incident detections and responses, especially related to critical systems, must follow this policy. Exemptions from this policy will be permitted only if approved in advance and in writing by the DevOps Team Leader.


10.2 Incident Identification

Employees must be aware of their responsibilities in detecting security incidents to facilitate the incident response plan and procedures.  All employees have the responsibility to assist in the incident response procedures within their particular areas of responsibility.  Some examples of security incidents that an employee might recognize in their day to day activities include, but are not limited to,

  • Theft, damage, or unauthorized access (e.g., unauthorized logins, papers missing from their desk, broken locks, missing log files, alert from a security guard, video evidence of a break-in, or unscheduled/unauthorized physical entry)
  • Fraud – Inaccurate information within databases, logs, files, or paper records
  • Abnormal system behavior (e.g., unscheduled system reboot, unexpected messages, abnormal errors in system log files or on terminals)
  • Security event notifications (e.g., file integrity alerts, intrusion detection alarms, and physical security alarms)

All employees, regardless of job responsibilities, should be aware of the potential incident identifiers and who to notify in these situations.  In all cases, every employee should report incidents per the instructions under Reporting and Incident Declaration Procedures (Section 11.3), unless they are assigned other activities within the incident response plan.


10.3 Reporting and Incident Declaration Procedures

The DevOps Team should be notified immediately of any suspected or real security incidents involving SkillSetz computing assets, particularly any critical system. If it is unclear as to whether a situation should be considered a security incident, the DevOps Team should be contacted to evaluate the situation.   

With the exception of steps outlined below, it is imperative that any investigative or corrective action be taken only by DevOps Team personnel or under the oversight of DevOps Team personnel, to assure the integrity of the incident investigation and recovery process. When faced with a potential situation you should do the following, 

  • Report the security incident.
  • Contact the DevOps Team to report any suspected or actual incidents. The DevOps Team’s phone number should be well known to all employees and should page someone during non-business hours. 
  • No one should communicate with anyone outside of their supervisor(s) or the DevOps Team about any details or generalities surrounding any suspected or actual incident.  All communications with law enforcement or the public will be coordinated by the DevOps Team.
  • Document any information you know while waiting for the DevOps Team to respond to the incident. If known, this must include the date, time, and nature of the incident. Any information you can provide will aid in responding in an appropriate manner.

10.4 Incident Severity Classification

The DevOps Team will first attempt to determine if the security incident justifies a formal incident response. 

In cases where a security incident does not require an incident response the situation will be forwarded to the appropriate area of IT to ensure that all technical support services required are rendered.

The following descriptions should be used to determine what response the DevOps Team will take.

  • Level 1 - One instance of potentially unfriendly activity (e.g., finger, unauthorized telnet, port scan, corrected virus detection, unexpected performance peak, etc.).
  • Level 2 - One instance of a clear attempt to obtain unauthorized information or access (e.g., attempted download of secure password files, attempt to access restricted areas, single computer successful virus infection on a non-critical system, unauthorized vulnerability scan, etc.) or a second Level 1 attack.
  • Level 3 - Serious attempt or actual breach of security (e.g., multi-pronged attack, denial of service attempt, virus infection of a critical system or the network, successful buffer/stack overflow, successful unauthorized access to sensitive or critical data or systems, broken lock, stolen papers, etc.) or a second Level 2 attack.

Any Level 1 type incident occurring against systems storing confidential or sensitive data or originating from unauthorized internal systems is classified as a Level 2.

10.5 Incident Response

10.5.1 Typical Response

Responses can include or proceed through the following stages: identification, severity classification, containment, eradication, recovery, and root cause analysis resulting in improvement of security controls. The following actions should be taken by the DevOps Team once an incident has been identified and classified. Level 1

  •       Contain and Monitor
    • If possible, record the user, IP address, and domain of the intruder. 
    • Utilize approved technology controls to temporarily or permanently block the intruder’s access.
    • Maintain vigilance for future break-in attempts from this user or IP address. Level 32

  •       Contain, Monitor, and Warn
    • Collect and protect information associated with the intrusion. 
    • Utilize approved technology controls to temporarily or permanently block the intruder’s access.
    • Research the origin of the connection. 
    • Contact the Internet Service Provider (ISP) and ask for more information regarding the attempt and intruder is needed. 
  •       Research potential risks related to intrusion method attempted and re-evaluate for higher classification and incident containment, eradication, and recovery as described for Level 3 incident classifications. Level 3

  •       Contain, Eradicate, Recover and perform Root Cause Analysis
    • If the incident involved cardholder data systems the Acquirer and applicable card associations must be notified.  See the Credit Card Compromise – Special Response (Section 14.5.2) for more details.
    • Contain the intrusion and decide what action to take.  Consider unplugging the network cables, applying highly restrictive ACLs, deactivating or isolating the switch port, deactivating the userID, terminating the user’s session/change password etc.
  •       Collect and protect information associated with the intrusion via offline methods.  In the event that forensic investigation is required the DevOps Team will work with legal and management to identify appropriate forensic specialists.
  •       Notify management of the situation and maintain notification of progress at each following step. 
  •       Eliminate the intruder's means of access and any related vulnerabilities. 
  •       Research the origin of the connection. 
  •       Research potential risks related to or damage caused by intrusion methods used. 

10.5.2 Credit Card Compromise – Special Response

For any incidents involving potential compromises of cardholder data, the DevOps Team will use the following procedure:

  • Contain and limit the exposure. Conduct a thorough investigation of the suspected or confirmed loss or theft of account information within twenty-four (24) hours of the compromise. To facilitate the investigation: 
  • Log all actions taken (e.g., bound notebook, video camera, etc).
  • Do not access or alter compromised systems (e.g., do not log on or change passwords; do not log in as ROOT) without the approval of the DevOps Team Leader.
  • Preserve logs and electronic evidence.
  • Be on high alert and monitor all cardholder data systems.
  • Notify the client about the potential compromise as soon as possible

10.5.3 Root Cause Analysis and Lessons Learned

Not more than one month following the incident, members of the DevOps Team and all affected parties will meet to review the results of the investigation conducted under step 1, section 11.5.2 of this document to determine the root cause of the compromise and evaluate the effectiveness of the Incident Response Plan. Review other security controls to determine their appropriateness for the current risks. Any identified areas in which the plan, policy or security control can be made more effective or efficient, must be updated accordingly. This may be in response to lessons learned in response to industry developments.


10.6 Automated Security System Notifications

The automated intrusion alerts are delegated to an ESP Foregenix with their security scan tool.


Was this article helpful?

0 out of 0 found this helpful