Document Information and Change Log

Document Information

Document history

Gender And Entity Neutrality

The masculine form is used solely for the sake of better readability. It always refers to persons of any gender identity (m/f/diverse). This document uses the abbreviation “Give” for all legal entities and subsidiaries.

Table of Contents

Introduction        6

About Security Events and Incident Response        6

Access Control        6

Web Application Access Control        6

User Identification and Authentication        6

Network Access Control        10

User Identification and Authentication        10

Authorization and Access Management        10

Network Security Policies and References        11

Network Security        12

System Hardening        12

Purpose        12

Scope        12

Vendor Default Account Management        12

Primary Functions Security Management        12

Management of Services, Protocols, and Functions        14

Operating System Hardening        14

User Account Management Hardening        14

Security Patch Management Hardening        14

Network Security Hardening        15

System Acquisition        15

Purpose        15

Vendor Selection and Evaluation        15

Due Diligence and Risk Assessment        15

Contractual Agreements        15

Integration and Compatibility        16

Data Privacy and Protection        16

Project Management and Oversight        16

Testing and Quality Assurance        16

Training and User Adoption        16

Regulatory Compliance        16

Continuous Monitoring and Auditing        16

Documentation and Records Management        16

Disposal and Decommissioning        16

Compliance        17

Web Application Security        17

Secure Communication        17

User Access Control Policy        17

Input Validation        17

Output Encoding        17

Error Handling        17

Security Testing        17

Network Segmentation        17

VPC (Virtual Private Cloud)        17

Subnets        18

NLB (Network Load Balancer)        18

Kubernetes        18

Firewalls        18

Network Firewall        18

WAF (Web Application Firewall)        18

Firewall Safeguards        18

Public Encryption Ciphers        18

Accepted Cipher Suites        18

Monitoring Cipher Suites        19

Static Encryption Keys        19

Key Management        19

Key Rotation        19

Key Custodians        19

Cryptographic Key Generation        19

Cryptographic Key Distribution        20

Key Distribution        20

Key Storage        20

Compromised Keys        20

Retired Custodians        20

Retired Keys        21

Key Rotation, Revocation, and Destruction        21

Key Rotation        21

Key Revocation and Destruction        21

Key Substitution        21

Anti-Virus        21

Anti-virus Software Policy        21

Anti-virus Software Selection        22

Anti-virus Software Update Procedures        22

Anti-virus Software Scanning Procedures        22

Anti-virus Software Incident Response Procedures        22

Systems with Exclusion to Anti-Virus Policy        22

IDS (Intrusion Detection System) / IPS (Intrusion Prevention System)        23

Identify Network Assets        23

Develop Rules        23

Deploy Sensors        23

Configure Systems        23

Monitor and Review IDS / IPS Systems        23

Network Access Control (NAC)        24

Endpoint Security        24

Non-Compliant Resources        24

Guest Access        24

Network Monitoring        24

Monitoring and Alerting        24

Security Information and Event Management (SIEM)        24

Monitor Access        25

Test the System        25

Data Protection        25

Transmission Restrictions        26

Backup and Restore Testing        26

Bring Your Own Device (BYOD) Policy        26

Purpose        26

Scope        27

Guidelines        27

Device Responsibility        27

Security Protocols        27

Removable Media Security        27

Data Storage and Management        28

Network Access        28

Reporting Lost or Stolen Devices        28

Application Use        28

Separation of Work and Personal Data        28

Device End of Life (EOL)        28

Compliance        28

Review        28

Incident Response        29

Incident Response Policy        29

Incident Response Procedure        29

Incident Response Team        29

Incident Types        29

Communication Protocols        29

Investigate Incidents        29

Contain the Incident        29

Recovery        29

Incident Response Procedure        30

Purpose        30

Scope        30

Roles and Responsibilities        30

Incident Response Team (IRT)        30

Incident Response Coordinator (IRC)        30

Network Team        30

Web Application Security Team        31

Compliance Manager        31

Operations Manager        31

Detection and Reporting        31

Alerts        31

Triage        32

Investigation        32

Containment and Eradication        32

Recovery        32

Reporting        32

Communication        33

Plan Review and Maintenance        33

Inappropriate Stored Cardholder Data        33

Investigation        33

Containment and Eradication        33

Recovery        33

Reporting        33

Communication        34

Plan Review and Maintenance        34

Change Requests        34

Change Request Template        34

Retrospective and Improvements        34

Training        35

IT Risk Management Reviews        35

IT Security Role        36

Introduction

The Information Security Program (ISP) serves as a set of guidelines and procedures for managing the security risk and ensuring the confidentiality, integrity, availability of information assets and securing sensitive information like cardholder data.

The ISP will cover several key areas, including authentication, access control, network security, data protection, incident response, and compliance.

The ISP is a general outline of the key areas mentioned above and some key areas may have separate policies or procedures which will be indicated by a reference to the corresponding document.

Some key areas are split between how someone interacts with the system, consider a user entering through the Web Application vs accessing the Network directly; each will have its own Access Control and Security policies but share common policies like strong password and (“Two-factor authentication”) 2FA. A public accessible web application will need to allow a wide range of IPs whereas direct access to the network should restrict to allow only white listed IPs.

About Security Events and Incident Response

Throughout the ISP references to identifying Security Events and using the Incident Response Procedure will be referenced. Please review the sections for each to see more details.

Access Control

Web Application Access Control

User Identification and Authentication

Unique User IDs

Each user is provided a unique user ID that is not shared with any other user. Authenticated sessions are linked to each user ID so the user activity can accurately be tracked and attributed to each specific user.

New Users

New users either sign up themselves or are invited by an existing user to become a member or owner of an account. When a new user signs up or is invited they receive an email where they must click a confirmation link to validate their email address. The new user is then taken to a set password screen. After login authentication the user must connect a 2FA typically using a mobile phone number. In some instances email 2FA is allowed.

Strong Password Policy

All users must adhere to the strong password policy.

• Minimum of 12 characters
• Must contain at least 1 uppercase letter
• Must contain at least 1 number
• Must contain at least 1 unique symbol
• Passwords cannot match previously used 5 passwords

Exception: In cases where technical limitations prevent enforcing the required 12-character minimum, systems must enforce a minimum password length of 8 characters, while still adhering to all other requirements of the strong password policy (e.g., uppercase letters, numbers, unique symbols, and restrictions on reusing the last 5 passwords).

Exception Applicable Systems:

• OpenVPN

Change Password Policy

In the event that a password has not been compromised but needs to be updated for security purposes (e.g., routine maintenance, system requirements, or user request), the password must be changed at the next login attempt. Users will be notified when a password change is required.

Compromised Passwords

A compromised password is any password that may have been exposed, guessed, or otherwise at risk of unauthorized use. This can occur through phishing attacks, data breaches, or even suspicion of unusual activity. Protecting user accounts from compromised passwords is critical to maintaining the security and integrity of our systems.

If a password is suspected or known to be compromised, the following steps must be taken immediately:

• Send an email to the Incident Response Team (IRT) at irt@givecorporation.com detailing the nature of the compromise or suspicion.
• The password reset request must be approved by the Production Systems Network Administrator before a reset can proceed.
• Until a new password is established and verified, access using the compromised account will be restricted.

User Guidance to Protect Authentication Factors

When setting or changing passwords, users should be given the following guidance on how to protect their authentication factors:

• How to choose a strong password
• Instructions to not use previously used passwords
• How to report suspicion or knowledge of a compromised password

Multi-Factor Authentication (MFA)

All users must use MFA to access the web application, VPN and production network.

MFA Standards and Controls

The following methods are accepted for MFA.

1. TOTP Applications (e.g. Google Authenticator)

Encryption Standards

Secret Key Encryption

The shared secret key, used to generate the TOTP codes, is encrypted by strong algorithms like AES 256-bit encryption.

Data Transmission

The TOTP codes are valid for a short period of time (30 seconds) and the transmission of these codes are secured using TLS 1.2 or higher.

Controls

Secure Key Exchange

During initial setup, the secret key is securely transferred to the user’s device displayed as a QR code and scanned by the user’s TOTP application.

Secure Storage

The TOTP application stores the secret key in a secure manner leveraging the device’s secure storage capabilities.

Code Generation Security

Algorithms used for generating the TOTP (like HMAC-SHA1) are designed to be resistant to tampering and prediction.

2. SMS/Email Passcodes

Encryption Standards

Transmission Security

Passcodes sent via email are encrypted using TLS 1.2 or higher. Due to the insecurity of the SMS protocol additional security measures are required where only after primary authentication is successful does the system prompt to initiate the MFA process. The token is time-sensitive and can only be used in combination with the authenticated user session.

Data Storage Encryption

Stored data is encrypted at rest using AES-256 bit encryption.

Controls

Rate Limiting

Rate limit is enabled to limit the sending of SMS messages to prevent abuse such as brute force attacks or flooding.

Time-limited and One-Time Use tokens

Passcodes are valid only for a short-period of time to reduce the window of opportunity for attackers.

Tokens are invalidated after one use to prevent replay attacks.

User Notifications

Users are notified of the MFA process initiation and if the request was not triggered by them to alert them of potential unauthorized login attempts.

Session Management

Session management will be used to control user access to the web application and access to specific resources within the application.

Session Revocation

Sessions should be able to be revoked which disallow any further access to the previous session.

Session Timeouts

Session timeouts should occur after 30 minutes of inactivity. A warning message should be displayed prior to automatically ending their session to allow them the opportunity to extend their session. After timeout the user must re-authenticate their session.

Monitor and Review Session Logs

Regular monitoring and reviewing of session logs to detect and respond to suspicious activity. Identify Security Events and use Incident Response Procedure.

Risk Profile

Each IP address that accesses the web application will be given a risk profile. Any activity that occurs under that IP address will be linked to its associated risk profile. Tracked activity includes but is not limited to; transactions, authenticated user sessions, etc..

Network Access Control

Control user access to AWS resources and data. Access granted on a need-to-know basis. Use Request for Access Form to add new users.

User Identification and Authentication

Strong Password Policy

All users with access to Cardholder Data must adhere to the strong password policy.

• Minimum of 12 characters
• Must contain at least 1 uppercase letter
• Must contain at least 1 number
• Must contain at least 1 unique symbol

Two Factor Authentication (2FA)

All users must use 2FA to access the network.

Authorization and Access Management

Authorized Access

Only authorized personnel should be granted access on a need-to-know basis.

Limit Access

Users should be provided access only to systems, resources and data that is required to perform their job.

Secure Connection

Users must connect through a secure white listed IP.

VPN Connection

SSH key pair is required for authentication and password-based SSH login is disallowed. VPN must use minimum TLS v1.3.

Use a Corporate VPN gateway to access the production environment.

Access Control Policy

Access Control or Security Groups should be implemented to any applicable resource including but not limited to the following; VPC, Subnets, DBs, EKS etc..

Review and Audit

Review and audit access controls and user access regularly every 6 months and identify unauthorized access and appropriate access control. If unauthorized access is identified, use the Incident Response Procedure.

Termination of Access

Access should be terminated immediately for any personnel who are no longer authorized or who are no longer employed.

Network Security Policies and References

To ensure secure and controlled access to our network resources, we implement robust network access control measures as outlined in the following AWS documentation:

1. AWS Client VPN Administrator Guide: This guide provides comprehensive instructions on configuring and managing our VPN setup, ensuring secure remote access for authorized users. Refer to the guide here.
2. AWS Management Console Guide: This guide details the procedures for accessing and managing our AWS resources through the Management Console, including user roles, permissions, and MFA requirements. Refer to the guide here.
3. Amazon Elastic Compute Cloud (EC2) User Guide for Linux Instances: This guide offers extensive information on setting up and securing EC2 instances, including network configurations and security group settings. Refer to the guide here.

These documents provide the necessary guidelines and best practices to maintain secure network access and protect our infrastructure from unauthorized access and potential threats.

Network Security

This document includes an overview of our network security. Reference the Network Security Policy for implementation detail.

System Hardening

Purpose

The purpose of this System Hardening Policy is to establish clear guidelines and procedures for enhancing the security of the Give’s computer systems by minimizing vulnerabilities, reducing the attack surface, and strengthening defenses.

Scope

This policy applies to all information technology systems and infrastructure within the organization.

Vendor Default Account Management

All vendor default accounts are managed to ensure security within the environment. This policy outlines the process for handling vendor default accounts in compliance with PCI DSS Requirement 2.2.2.

1. Management of Vendor Default Accounts:

• If a vendor default account is required, the default password must be changed in accordance with PCI DSS Requirement 8.3.6.
• If a vendor default account is not required, the account must be removed or disabled.

2. Application to AWS Environments:

• The AWS Management Console does not permit vendor default passwords for access.
• For EC2 instances and other AWS resources, default passwords are disabled, and appropriate hardening measures are applied in all production environments to ensure security compliance.

Primary Functions Security Management

To ensure the security and integrity of the cardholder data environment (CDE), all primary functions that require different security levels are managed in compliance with PCI DSS Requirement 2.2.3. This policy defines the approach to managing system components with primary functions that may have differing security levels.

Policy Requirements:

1. Single Primary Function Requirement:

• Each system component within the CDE is configured to perform only one primary function, ensuring no differing security levels exist within a single component.

2. Handling Multiple Primary Functions:

• If multiple primary functions with differing security levels are required on the same system component, the functions must be isolated from each other to prevent security conflicts.
• Alternatively, if isolation is not possible, all functions within the same component must adhere to the highest security requirement among them to maintain robust security.

3. Application in AWS Environments:

• For Amazon Web Services (AWS) environments, SaaS platforms are leveraged in such a way that they operate only one function at a time.

  ---

Management of Services, Protocols, and Functions

To secure the environment per PCI DSS Requirement 2.2.4, only necessary services, protocols, daemons, and functions are enabled on system components. All unnecessary features must be disabled or removed.

1. Enable Only Necessary Features:

• Only essential services, protocols, and functions required for system operations are enabled.

2. Disable Unnecessary Features:

• Any non-essential service, protocol, or function must be disabled or removed to minimize security risks.

3. CIS-Hardened Implementation:

• System components are deployed using CIS Benchmark level 2 to ensure compliance with high security standards.

Operating System Hardening

• Configure operating systems based on recognized security benchmarks, such as the Center for Internet Security (CIS) or National Institute of Standards and Technology (NIST) guidelines.
• Disable unnecessary services and features, reducing the attack surface.
• Apply security patches promptly upon release to address known vulnerabilities.
• Implement host-based firewalls or intrusion detection systems (IDS) to monitor and control network traffic at the OS level.
• Enforce strict file system permissions to restrict unauthorized access to critical system files and directories.
• Use full disk encryption where applicable to protect sensitive data at rest.
• Regularly audit and review system logs to detect and investigate security incidents.

User Account Management Hardening

• Enforce strong password policies, including complexity requirements and regular password changes.
• Implement multi-factor authentication (MFA) for user accounts, especially for privileged access.
• Utilize centralized identity and access management systems to centralize user provisioning, deprovisioning, and access control.
• Regularly review and remove inactive or unused user accounts to reduce the attack surface.
• Monitor and log all user account activities for auditing and anomaly detection.

Security Patch Management Hardening

• Establish a well-defined patch management process to identify, test, and deploy security patches and updates.
• Maintain a vulnerability management program to assess and prioritize patching based on risk.
• Use automated tools for patch deployment to ensure timely and consistent updates.
• Conduct vulnerability scanning and penetration testing to identify and validate the effectiveness of patching efforts.
• Establish rollback procedures in case a patch causes unforeseen issues.

Network Security Hardening

• Implement network segmentation to isolate critical systems and limit lateral movement in the event of a breach.
• Employ firewalls to control inbound and outbound network traffic.
• Use intrusion detection/prevention systems (IDS/IPS) to detect and block malicious network activity.
• Regularly review firewall rules and access control lists to ensure they align with security policies.
• Employ network access controls, such as Network Access Control (NAC), to enforce security policies for endpoint devices.

System Acquisition

Purpose

The purpose of this System Acquisition Policy is to outline the procedures, principles, and standards governing the acquisition of new information systems and technologies by Give. It ensures that system acquisitions align with business objectives, meet security and compliance requirements, and are effectively integrated into the organization's infrastructure.

Vendor Selection and Evaluation

The payments provider will employ a rigorous vendor selection process that assesses vendor reputation, financial stability, past performance, and the alignment of their solutions with business needs.

Due Diligence and Risk Assessment

Comprehensive due diligence procedures will be conducted to assess potential risks associated with system acquisition, including cybersecurity risks, regulatory compliance, and operational impacts.

Contractual Agreements

Clear and legally sound contractual agreements will be established with vendors. Contracts will include provisions related to service level agreements (SLAs), data ownership, security responsibilities, and dispute resolution.

Integration and Compatibility

The provider will assess the compatibility of newly acquired systems with existing infrastructure and applications. Plans for data migration, testing, and integration will be developed.

Data Privacy and Protection

The payments provider will ensure that system acquisition processes comply with data privacy regulations. Sensitive customer data will be protected in accordance with applicable laws.

Project Management and Oversight

Well-defined project management methodologies will be employed, including timelines, milestones, resource allocation, and change management strategies. Oversight and reporting mechanisms will be established to monitor project progress.

Testing and Quality Assurance

Robust testing and quality assurance procedures will be implemented to verify that new systems meet performance, security, and functionality requirements before deployment.

Training and User Adoption

The provider will plan for employee training and user adoption strategies to facilitate a smooth transition and maximize the benefits of newly acquired systems.

Regulatory Compliance

System acquisition processes will adhere to relevant payments industry regulations and standards, ensuring compliance with cybersecurity, data protection, and financial stability requirements.

Continuous Monitoring and Auditing

Ongoing monitoring and auditing mechanisms will be established to evaluate the performance and security of newly acquired systems over time. This includes regular cybersecurity assessments and audits.

Documentation and Records Management

Comprehensive records of all system acquisitions, evaluations, contracts, and compliance assessments will be maintained for transparency and audit purposes.

Disposal and Decommissioning

Procedures for the secure disposal or decommissioning of legacy systems and technologies will be established to minimize security risks.

Compliance

Non-compliance with this policy may result in corrective actions, including the reassessment of system acquisitions, contract renegotiations, or termination of vendor relationships, as necessary.

Web Application Security

Secure Communication

Always use HTTPS and HSTS (HTTP Strict Transport Security) and automatic HTTPS Rewrites. Minimum TLS Version of TLS v1.3.

User Access Control Policy

Allow administrators to set user specific access control policies to restrict access to resources and sensitive information on a need-to-know basis.

Input Validation

Validate input from users and other sources to prevent injection attacks (SQL Injection and cross-site scripting (XSS). Validate input data types, formats, lengths etc. Encode input data such as HTML, URLs and Javascript to ensure malicious code or scripts are not being injected.

Output Encoding

Use output encoding to protect against XSS attacks. Use HTML entity encoding, URL encoding, Javascript encoding, and any other encoding where output data will be displayed in the web application.

Error Handling

Handle errors and exceptions gracefully as not to reveal sensitive data or system details that could be used for malicious purposes.

Security Testing

Perform regular security testing, including penetration testing, code reviews, and vulnerability scanning, to identify and remediate security vulnerabilities in the web application.

Network Segmentation

VPC (Virtual Private Cloud)

Use VPCs to isolate in-scope from out-of-scope environments, and to separate backup and failover systems.

Subnets

Use private subnets for all resources that do not need to be accessed publicly in the VPC, including EKS and EKS nodes.

NLB (Network Load Balancer)

Use a public subnet for the NLB to enable public traffic to access services.

Kubernetes

Use kubernetes to control network traffic, scale resources and distribute traffic across services.

Firewalls

This document includes an overview of our network security firewalls. Reference the Firewall and Router Configuration Standards document for in-depth detail.

Network Firewall

Network based firewall should be used to secure all inbound and outbound traffic to the VPC and private subnets from the load balancer. The network firewall should deny all and only allow white listed IPs.

WAF (Web Application Firewall)

The WAF should be in front of the NLB to protect against a wide range of web application attacks coming from the public traffic accessing services.

Firewall Safeguards

Safeguards protect against intrusion during firewall changes. The safeguards are preventative and involve measures taken prior to the actual change. During the firewall change preventative measures protect vulnerable points from being accessed.

Public Encryption Ciphers

Use strong encryption protocols such as AES 256 (Advanced Encryption Standard) for stored and in transit data. Use SSL/TLS to encrypt traffic between clients and servers. Minimum TLS Version of TLS v1.2..

Accepted Cipher Suites

TLS 1.3

• TLS_AES_128_GCM_SHA256 (0x1301)
• TLS_AES_256_GCM_SHA384 (0x1302)
• TLS_CHACHA20_POLY1305_SHA256 (0x1303)

TLS 1.2

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)

Monitoring Cipher Suites

Perform an SSL Labs analysis to identify any weak or deprecated ciphers in use. Additionally, consult ciphersuite.io for the most up-to-date information on the current status of cipher suites.

Static Encryption Keys

Key Management

Use KMS (Key Management Service) to create and protect encryption keys and log key usage to monitor and track key activity.

Key Rotation

Keys should be rotated once per year and database migrated to decrypt and re-encrypt column specific data.

Key Custodians

Give Corporation shall appoint key custodians responsible for:

• Generating and distributing cryptographic keys following PCI DSS requirements.
• Protecting keys using strong encryption, access controls, and monitoring.
• Keeping accurate records of key details such as type, purpose, creation, and expiration dates.
• Destroying or revoking keys that are no longer needed or have been compromised.
• Reporting breaches or incidents involving cryptographic keys according to the Incident Response Procedure.
• Completing all required training on key management and demonstrating understanding of PCI DSS requirements.

Cryptographic Key Generation

Keys must be generated using secure algorithms and key lengths, such as AES-256, following documented and reviewed procedures. Key generation is performed using AWS KMS, ensuring confidentiality, integrity, and availability.

Cryptographic Key Distribution

Key Distribution

Keys are distributed only to authorized personnel on a need-to-know basis. Stored within AWS KMS, key access is controlled via AWS IAM, with distribution procedures reviewed periodically for compliance with PCI DSS guidelines.

Key Storage

Keys must be securely stored with encryption, access controls, monitoring, and backup/recovery measures. These storage procedures are regularly reviewed to ensure compliance.

Compromised Keys

1. Reporting a Compromised Key
In the event of a suspected compromised cryptographic key, the issue must be reported immediately using the following procedure:

• Notify the network administrators via Slack.
• The suspected compromise will be escalated to the Incident Response Team (IRT), which will handle further investigations and actions related to the compromised key.

2. Compromised Key Procedure
Once a compromised key is reported, the following steps will be taken:

• The compromised key will be retired following the organization's key management lifecycle.
• A replacement key will be generated and distributed securely to ensure continued operation.

Retired Custodians

When a custodian retires, their access to cryptographic keys must be revoked. The Compliance Manager is responsible for completing the Remove User from Group Request Form. Network administrators will then remove the custodian from all access groups and systems that manage cryptographic keys.

Additionally, cryptographic keys must be rotated whenever a custodian retires to maintain security.

Retired Keys

If a key needs to be retired, it can be done manually. For imported keys, AWS KMS allows the key material to be deleted on demand while retaining the key's metadata for future re-importation. This ensures flexibility while keeping the retired key unusable until it is reactivated.

Deleting AWS KMS keys - AWS Key Management Service 

When a key is scheduled for deletion, it enters a “pending deletion” state for a waiting period of 7 to 30 days, after which it is permanently deleted. This process can be monitored using CloudWatch and CloudTrail for auditing and compliance purposes.

Key Rotation, Revocation, and Destruction

Key Rotation

Keys should be rotated at least annually. Database content will be decrypted and re-encrypted as needed during this process.

Key Revocation and Destruction

Compromised or no-longer-needed keys must be securely revoked or destroyed. AWS KMS supports deleting imported key material on demand, and deletion can be monitored using CloudWatch and CloudTrail for compliance.

Key Substitution

For customer-managed keys, AWS KMS supports both automatic and manual key rotation for symmetric keys. New cryptographic material is generated without altering the key's ID or ARN, ensuring uninterrupted functionality for services using the key.

Rotating AWS KMS keys - AWS Key Management Service 

Anti-Virus

Anti-virus Software Policy

All systems that store, process, or transmit payment card data must have anti-virus software installed and enabled, except for those systems inherently protected against viruses, such as Linux and macOS. The IT Department is responsible for the enforcement of this policy and subject to distribution, enforcement, and maintenance therein of the anti-virus policy. The software must be configured to perform real-time scanning of all file and network activity, and to automatically update virus definitions on a regular basis.

Anti-virus Software Selection

All selected software must be approved by the IT Security team before installation. The approved software must have the following capabilities:

• First connection of all file, media, and network activity
• Ability to identify and remove any known malicious attack
• Regular updates of virus definitions
• Quarantine capabilities for infected files
• Reporting and notification capabilities
• Logging compliance: software is capable of storing logs for a minimum of 1 year, 3 months available
• Anti-phishing mechanisms must be built into the antivirus solution
• Solution may not be tampered or modified by end-users

Anti-virus Software Update Procedures

All anti-virus software must be configured to automatically update virus definitions on a regular basis. In addition, regular manual updates must be performed to ensure that the software is up to date with the latest security patches and updates. Manual updates must be performed on a regular basis, at least once a month.

Anti-virus Software Scanning Procedures

All systems that store, process, or transmit payment card data must be scanned for viruses and malware on a regular basis. Scans must be performed at least once a week, and more frequently if required by the IT Security team. Scans must be performed during non-business hours to minimize the impact on system performance.

Anti-virus Software Incident Response Procedures

If a virus or malware infection is detected, the affected system must be isolated from the network immediately. Use the Incident Response Procedure, and the system must be scanned and disinfected before it can be connected back to the network.

Systems with Exclusion to Anti-Virus Policy

For any systems deemed to be not commonly affected by malware, periodic evaluations shall be performed to help identify and assess any evolving malware threats in order to confirm whether these systems do/do not require anti-virus software. Evaluations must be in congruence with the targeted risk analysis and explicitly noted within the registry. Platforms exempt from the anti-virus policy include:

• Linux based operating systems
• Appliance based systems without OS access

Periodic evaluation of these exceptions shall be performed to determine if systems are still exempt from the anti-virus policy.

IDS (Intrusion Detection System) / IPS (Intrusion Prevention System)

Monitor network traffic for signs of suspicious activity and if found use the Incident Response Procedure.

Identify Network Assets

Identify all network assets that require IDS/ IPS protection to determine the scope of the IDS / IPS deployment.

Develop Rules

Develop rules based on identified network assets and potential threads. Should include settings for known attacks, zero-day attacks, and unusual network activity.

Deploy Sensors

Deploy sensors in strategic locations within the network to monitor traffic and detect potential threats.

Configure Systems

Configure the systems to take appropriate action when threats are detected. This should include identifying Security Events to send alerts, blocking traffic or taking other actions which may include using the Incident Response Procedure.

Monitor and Review IDS / IPS Systems

The IDS / IPS system should be monitored regularly to detect and respond to potential threats. This includes reviewing logs, analyzing alerts, and responding to incidents.

Network Access Control (NAC)

Network Access Control should be implemented between all subnets and connected services to ensure only authorized devices, services, users are allowed to connect to the network and their access is limited to only the resources they need.

Endpoint Security

Endpoints should be checked for compliance with security policies, such as up-to-date anti-virus software, latest OS and software updates, and strong passwords.

Non-Compliant Resources

Resources that are found non-compliant with security policies should be denied network access or given limited access until they are brought into compliance. Use Incident Response Procedure when a non-compliant resource is identified.

Guest Access

Any guest access to the network should have limited privileges and be time-limited and closely monitored to ensure that guests are not accessing unauthorized resources.

Network Monitoring

VPC flow logs should be enabled to capture information about IP traffic. Security events should be identified to detect any unusual or malicious activity.

NLB Health Checks to ensure that only healthy nodes receive traffic to ensure service availability and responsiveness.

Monitoring and Alerting

Security Information and Event Management (SIEM)

Collect and analyze logs from AWS resources, servers, network devices, applications etc.

Security Events

Security events should be identified and configured to generate alerts that are prioritized based on the severity of the event.

Security events include but are not limited to; too many failed login attempts, changes to critical system files or resources, unusual network traffic patterns, etc. If a security event is identified, use the Incident Response Procedure.

Monitor Access

Log all access, including successful and unsuccessful attempts. Monitor privileged user access and changes to user access privileges. If suspicious activity is detected use the Incident Response Procedure.

Test the System

The SIEM should be regularly tested to ensure that it is functioning as expected. New security events should be identified and added. A retrospective of alert prioritization should be conducted on a regular basis.

Data Protection

It is critical to protect sensitive data. Most of the data protection policy is addressed in the previous sections which cover access control, strong authentication, encryption, monitoring and alerts etc.

In addition to what was covered thus far, Data protection also must include a policy for retention and disposal. Please reference Data Retention and Disposal Policy.

Give Corporation shall retain credit card data only for the period necessary to fulfill business, legal, and regulatory requirements, and shall securely dispose of such data after the retention period has expired.

The retention periods for credit card data shall be determined as follows:

• Primary Account Numbers (PANs) in plaintext shall not be stored after authorization.
• Card Verification Value (CVV) shall not be stored after authorization.
• Magnetic Stripe Data shall not be stored after authorization.
• Tokenized PANs associated with the risk profile, future payment, recurring payment or subscription service may be stored for the duration of the service or as required by law or specific business need.
• Cardholder data that is associated with the risk profile, future payment, recurring payment or subscription service may be stored for the duration of the service, or as required by law or specific business need.
• Security-related data (such as logs, audit trails, and security incident reports) shall be retained for a minimum of 1 year.
• Only authorized administrators can copy or export PAN data. Any other user with access to PAN data must have revoked privileges to export or copy tables with PAN data.
• Data will be inventoried and reviewed at least annually by key custodians for relevance and retention requirements.

Transmission Restrictions

The transmission of credit card data via Slack or any other instant messaging or end-user messaging service is strictly prohibited. This ensures that sensitive data is not shared over insecure or non-compliant channels.

Backup and Restore Testing

Database Backup and Restore

Frequency: A daily automatic backup will be performed on all databases.

Retention: Each backup will be retained for 7 days. After this period, older backups will be automatically purged to manage storage resources.

Recovery: The database backup process must ensure that recovery is possible for any day within the last 7-day retention period.

Database Restoration: Full restoration testing of the database backups is scheduled annually.

Server(s) Backup and Restore

Server Backup: Server backups are conducted on an as-needed (ad hoc) basis.

Server Restoration: Annual restoration testing is performed to verify the accuracy and reliability of server backup processes.

A. Instance Backup

• Instance Backups: A backup will be maintained for each instance, especially before any major update or change.
• AMI Updates: An updated Amazon Machine Image (AMI) must be created following each upgrade or configuration change to ensure consistency and allow rapid restoration.
• Retention: Previous AMIs will be retained based on storage policies and space requirements, with the goal of maintaining at least one stable, pre-update AMI for each instance.

B. EKS Cluster

• Launch Template and Auto-Scaling: Since the EKS cluster is configured with launch templates and auto-scaling groups, explicit backup of individual nodes or worker instances is not required.

Bring Your Own Device (BYOD) Policy

Purpose  

This policy outlines the guidelines and practices for remote employees of Give and any of its subsidiaries using their personal devices for work related activities.

Scope  

This policy applies to all remote employees of Give and any of its subsidiaries who use their personal devices to access company data, networks, and systems.

Guidelines

Device Responsibility  

Employees are responsible for the maintenance and updated software of their devices. Devices should have the latest security patches installed.

Security Protocols  

All devices used for work purposes must have updated antivirus software and an active firewall. Personal devices must have reputable antivirus software installed and kept up-to-date. Exceptions to this antivirus requirement include:

• Linux-based operating systems (e.g., Ubuntu), where SELinux/AppArmor or equivalent is enabled in place of antivirus software.
• Appliance-based systems without OS access.

The IT Department is responsible for enforcing the antivirus policy, ensuring distribution, enforcement, and maintenance.

Devices should be password protected, preferably with strong, unique passwords or biometric authentication.

Removable Media Security

In compliance with PCI Requirement 5.3.3, any removable electronic media used with personal devices to access, store, or transmit company data must adhere to the following security measures:

• Automatic Scanning: The device must automatically scan removable media for malware upon insertion, connection, or logical mounting, OR
• Continuous Monitoring: The device must continuously monitor systems or processes for suspicious behavior when removable media is connected.

Verification and Compliance:

• Configuration Check: The anti-malware software on personal devices must be configured to either automatically scan removable media or perform continuous behavioral analysis as per PCI Requirement 5.3.3.
• Logging: All anti-malware activities, including scans and detections related to removable media, must be logged and retained according to the relevant PCI logging requirements.

Data Storage and Management  

Sensitive company data should not be stored permanently on personal devices. Use cloud storage or company provided platforms for data storage.

Avoid transferring company data to unsecured or public cloud storage solutions.

Network Access  

When accessing production networks the company VPN (vpn.givesync.com) must be used to connect.

Reporting Lost or Stolen Devices  

Employees must report any lost or stolen device that has accessed company resources immediately to the IT department at it_support@givecorporation.com.

Application Use  

Only use company approved software and applications for work related tasks.

Avoid downloading suspicious or unverified applications that might compromise the device's security.

Separation of Work and Personal Data  

Where feasible, use separate user profiles or partitions to segregate work related data and activities from personal ones.

Device End of Life (EOL)

Before discarding, selling, or giving away a device, employees should ensure that all company data is securely deleted.

Compliance  

Failure to comply with this BYOD policy may result in disciplinary action and revocation of access to company resources.

Review  

This policy will be reviewed annually and may be updated based on technological advancements and company needs.

Incident Response

Incident Response Policy

Incident Response Procedure

Use an Incident Response Procedure for handling security breaches. Reference the Incident Response Procedure document for details.

Incident Response Team

Maintain an incident response team consisting of individuals from different departments who will be responsible for responding to security incidents. The team should have clear roles and responsibilities and be available 24/7.

Incident Types

Incident types include and are not limited to the following; unauthorized access, malware infection, data breaches. New types should be added when identified by new incidents, audits, reviews, and monitoring.

Communication Protocols

Establish clear communication protocols for notifying internal and external stakeholders of security incidents. Define the information that needs to be communicated and establish escalation procedures.

Investigate Incidents

Investigate incidents to determine the root cause and the scope of the impact. This includes analyzing logs and system data, interviewing witnesses, and conducting forensic analysis.

Contain the Incident

Contain the incident by isolating affected resources or systems, restricting access and shutting down affected systems as necessary.

Recovery

Restore affected systems and data from backups, update security controls, and test systems to ensure they are secure after recovery.

Incident Response Procedure

Purpose

The purpose of this document is to establish a process to detect, analyze, contain and recover from security incidents that may impact the confidentiality, integrity, and availability of Give Corporations networks and data.

Scope

This procedure applies to all employees, contractors, vendors, and other parties who use the Give Corporation’s network and data resources. There will be resources available 24/7 to respond to security incidents where they may be reached by electronic communication or telephone. Incident response plan shall be tested at least annually by appropriate IRP team members.

Roles and Responsibilities

The following roles and responsibilities have been established to ensure an effective incident response process:

Incident Response Team (IRT)

The IRT is responsible for investigating and responding to security incidents.

As soon as an incident is alerted, discovered, or suspected an email should immediately be sent to the IRT team at irt@givecorporation.com.

The IRT is composed of the following individuals or teams:

Incident Response Coordinator (IRC)

aaron@givecorporation.com

• The IRC is responsible for coordinating the response to a security incident,
• The IRC will be the primary contact for all incident related communication.

Network Team

marian@givecorporation.com

youcef@givecorporation.com

hosni@givecorporation.com

• The Network Team is responsible for overseeing all network-related aspects of the incident response process.
• The Network Team will ensure that network devices are properly configured and that all network traffic is monitored and analyzed for potential security incidents.
• The Network Team will provide recommendations for containment, eradication, and recovery effort in regards to the network, security, backups, AWS resources, database.

Web Application Security Team

marian@givecorporation.com

hosni@givecorporation.com

youcef@givecorporation.com

• The Web Application Security Team is responsible for conducting technical analysis of security incidents having to do with the Web Application.
• The Web Application Security Team will provide recommendations for containment, eradication, and recovery effort in regards to the web application and database.

Compliance Manager

kateryna@givecorporation.com

• The Compliance Manager will provide guidance on compliance-related matters throughout the incident response process.
• The Compliance Manager will provide status updates to key stakeholders and communicate important information throughout the incident response process.

Operations Manager

kateryna@givecorporation.com

• The Operations Manager is responsible for coordinating operational activities during a security incident.
• The Operations Manager will ensure that all necessary resources are available to support the incident response process and as necessary implement system wide security measures such as User password changes and 2FA re-authentications.

Detection and Reporting

Security incidents may be detected by automated systems, monitoring, reports from users or customers, or other means. Anyone who suspects a security incident should report it to the IRC immediately.

Automated systems should send alert notifications to irt@givecorporation.com as follows:

Alerts

Any security event that triggers an alert having to do with the network or AWS resources should be sent to the IRT and logged in CloudWatch and/or CloudTrail.

Alerts may include but not limited to the following:

• Changes to operating system time configuration, files and NTP
• Change detection to critical files
• AWS GuardDuty High Severity Findings
• AWS VPC Flow Logs detecting DDoS, IP Spoofing, frequent failed attempts to access resources
• Amazon Inspector Critical and High Vulnerabilities
• IAM unusual login locations, failed login attempts, privilege escalation, creation of new IAM users, disabling of MFA
• WAF Block and Alert Events for DDoS, SQL injection and XSS attempts

Triage

The IRC, Network Team and Web Application Security Team will perform an initial assessment of the reported incident to determine its severity and scope.  This sub-team of the IRC will collectively be called the IAT (Initial Assessment Team).

The IAT will classify incidents based on its impact and level of severity. Depending on the impact and level of severity the IRC will determine if the entire IRT needs to be involved.

Investigation

• The IAT will conduct a detailed analysis of the incident, following the guidelines outlined in the Incident Response Playbook.
• The IAT will gather evidence and perform forensics as necessary.
• The IRC may request additional information and review all evidence gathered.

Containment and Eradication

• The IRT will work to contain the incident and prevent further damage.
• The IAT will recommend actions to eradicate the incident.
• If necessary, the Operations Manager will coordinate all necessary activities outside the engineering team to contain the incident.

Recovery

• The IRT will work to restore systems and data to their pre-incident state.
• The IAT will recommend actions to prevent future incidents.
• If necessary, the Operations Lead will coordinate all necessary activities to support the recovery effort.

Reporting

• The IRT will document the incident and all actions taken to respond to it.
• The Compliance Manager will report the incident to appropriate stakeholders, as necessary.

Communication

• The IRC will determine if an incident needs to be communicated to stakeholders.
• The Compliance Manager will be responsible for all incident-related communications.

Plan Review and Maintenance

• The Incident Response Procedure will be reviewed and updated annually.
• Any changes to the plan will be communicated to all relevant stakeholders.
• Lessons learned will append the incident response plan if necessary to adapt to new industry threats.

Inappropriate Stored Cardholder Data

In the event that cardholder data is found outside of the appropriate provisioned areas, the following process will be performed to eradicate the inappropriately stored data and prevent the issue from occurring again.

Investigation

• The IAT will conduct a detailed analysis of the potential leak of cardholder data.
• The IAT will gather evidence and perform forensics as necessary.
• The IRC may request additional information and review all evidence gathered.

Containment and Eradication

• The IRT will work to contain the incident and prevent further inappropriate storage
• The IAT will recommend actions to eradicate the incident. This includes a secure delete operation and appropriate safety measures to prevent propagation of cardholder data.
• If necessary, the Operations Manager will coordinate all necessary activities outside the engineering team to contain the incident.

Recovery

• The IRT will work to restore systems and data to appropriate order.
• The IAT will recommend actions to prevent future incidents.
• If necessary, the Operations Manager will coordinate all necessary activities to support the recovery effort.

Reporting

• The IRT will document the incident and all actions taken to respond to it. The team will document incidents in the Incident Tracker.
• The Compliance Manager will report the incident to appropriate stakeholders, as necessary.

Communication

• The IRC will determine if an incident needs to be communicated to stakeholders.
• The Compliance Manager will be responsible for all incident-related communications.

Plan Review and Maintenance

• The Incident Response Procedure will be reviewed and updated annually.
• Any changes to the plan will be communicated to all relevant stakeholders.
• Lessons learned will append the incident response plan if necessary to adapt to new industry threats.

Change Requests

A change request formally notifies that changes or enhancements are necessary. The types of necessary changes  and the reasons for the change are included in the change requests for approval and tracking, Follow up testing is conducted at the completion of the changes to validate the effectiveness of the changes. Each submitted change request must follow the relevant procedures for transparency. The scope and reasons for the updates must be clearly communicated prior to being given approval.

Change Request Template

A Change Request form is completed for the change requested. The following are to completed unless otherwise stated:

• Description of Change Request - Clearly state the description of the change(s) requested.
• Reason for Change (Could be optional) - Explain the reasons for the change(s).
• Scope of Change (Could be optional) - State the applications, systems and processes affected.
• Impact / Systems Affected by Change -  Describe the impact of the change(s) and the impact on the affected applications/systems. Use “Production Systems” for general or non specific impact.
• Testing Validation - Describe how the changes will be validated for effectiveness. Use “QA Regression Tests” or general or non specific validation.
• Breakout Procedure - Comment on the breakout procedure which will be used for each PR which is “Revert to the last known approved and stable branch or version”. Specific scenarios may require more details of what is needed to roll it back.

Retrospective and Improvements

Do retrospectives of past incidents to improve incident response procedures based on lessons learned. Update the procedures to address any gaps in the security controls or response processes.

Training

Part of mitigating information security risk is employee training.Developers and employees with various responsibilities will be training on information security. Each employee will understand that everyone plays an important role in safeguarding sensitive information.Applying the guidelines in this Information Security Policy will help to protect Give and the information that has been entrusted to Give.

Non compliance with this Information Security Policy will lead to disciplinary action including termination.

IT Risk Management Reviews

To ensure our organization's continuous adherence to PCI DSS requirements and maintain robust IT security, we conduct monthly IT Risk Management Reviews.

Responsible Party: Risk Management Team

Responsible Party Contact:  risk@givecorporation.com

These reviews focus on evaluating controls, documenting findings, and collecting evidence related to various security objectives. The key objectives of these reviews include:

Objectives:

1. Periodic Evaluations for Malware Risk (every 6 months per agreement of executive management)

• Conduct evaluations of system components that are not at risk for malware, as defined in the entity’s targeted risk analysis in accordance with Requirement 12.3.1.

2. Periodic Malware Scans (every 6 months per agreement of executive management).
3. Access Reviews (every 6 months per agreement of executive management)

• Review access every 6 months.
• Ensure access appropriateness and address any inappropriate access.
• Obtain management acknowledgment for review findings.

4. Password/Passphrase Protection (every 6 months per agreement of executive management)

• Change passwords/passphrases periodically and upon suspicion or confirmation of compromise.
• Ensure password complexity is based on change frequency.

5. Media Inventory (every 12 months per agreement of executive management)

• Conduct an inventory of electronic media containing cardholder data at least once every 12 months.

6. POI Device Inspections (every 12 months per agreement of executive management)
7. Log Reviews (every 1 month per agreement of executive management)
8. Vulnerability Management (every 1 month per agreement of executive management)

• Address vulnerabilities based on the risk assessment.

9. Change- and Tamper-Detection Mechanism (every 6 months per agreement of executive management)
10. Task Reviews (every 3 months)

• Conduct task reviews every three months by personnel other than those responsible for the tasks, including daily log reviews and configuration reviews.

11. Incident Response Training (annually)
12. Backup Tests (every 1 year per agreement of executive management)

• Perform routine comprehensive tests to ensure data integrity and system operations.

13. Vendor Security Monitoring (annually)

• Conduct periodic assessments based on vendor criticality and the sensitivity of the data/systems.

14. Penetration Testing (annually)

• Simulate cyberattacks yearly to identify and rectify vulnerabilities.
• Additionally, conduct regular penetration testing using GuardDuty and Detective.

15. External ASV Scans (every 3 months)

• Conduct regular assessments to evaluate and address vulnerabilities in externally accessible systems, using an ASV (Accredited Scanning Vendor).

16. Cryptographic Key Rotation (annually)

• AWS KMS to create and rotate encryption keys.

17. Security Awareness Training  (annually)

• Provide regular training to raise security awareness.

18. Secure Coding Training  (annually)

• Offer regular training on secure coding practices.

19. Configurations of NSCs (every 6 months)

• Review configurations of NSCs at least once every six months to confirm they are relevant and effective.

Each monthly review will document findings, collect evidence, and implement corrective actions where necessary to maintain compliance and enhance our overall security posture. This ongoing process ensures that all relevant PCI DSS requirements and internal security policies are continuously monitored and addressed.

IT Security Role

Aaron Miller is designated as the Chief Technology and Risk Officer (CTRO) at Give Corporation. CTRO is responsible for supporting the objectives of the Information Technology function and acknowledging internal control responsibilities. A.M. is also accountable for the implementation, review, and approval of the Information Security Program, ensuring it meets organizational and regulatory requirements.

Aaron Miller: aaron@givecorporation.com

The information contained herein is intended to provide a general overview of the Company’s policies and procedures relating to compliance with this Policy and does not constitute legal advice or a complete description of the laws and regulations relating to this Policy. The Company has made every effort to ensure the accuracy and completeness of this Policy.  This document is intended to provide guidance to employees of Company on how to comply with applicable laws and regulations related to this Policy. Employees should consult with the Legal or Compliance Department if they have any questions about the Policy or how to comply with it. Company reserves the right to modify or update this Policy at any time without notice. Employees are responsible for reviewing the Policy on a regular basis to ensure that they are aware of any changes. This Policy applies to all employees of Company, regardless of their position or location unless stated otherwise in the Policy. Employees are responsible for complying with the Policy and for reporting any suspected violations to their respective supervisor, the Legal Department, AMLCO or respective recipient of such violation as outlined in this Policy.