Document information and change log

Document Information

Change log

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

Coordinator and Teams        4

Security Coordinator        4

IT Security Team / Patch Management Team        4

1.1 Vulnerability Monitoring        4

For investigating vulnerabilities        4

Go Platform        5

Top 10        5

Benchmarks        5

1.1.2. Vulnerability Patch Management before Merge and Deployment to Production Procedure        5

Create Issue In GitHub        5

1.2. Vulnerability Scanning        5

1.3. Vulnerability Assessment        5

CVSS Rating Calculator        5

1.4. Notification and Escalation        6

1.5. Remediation        6

1.6. Verification and Validation        6

1.7. Reporting        6

2.1. Inventory of Software and Systems        7

2.2. Patch Prioritization        7

2.3. Testing and Validation:        7

2.4. Patch Deployment:        7

2.5. Monitoring and Reporting:        7

2.6. Incident Response:        8

2.7. Production Deployment and Sprint Release Procedure        8

1. Advance Notice Requirement        8

2. Deployment Timing        8

3. Post-Deployment QA Validation        8

4. Approval and Change Request Documentation        8

5. Release Notes and Legacy Data Impact        8

6. Operations Team Awareness and Support        9

3.0 Change Requests        9

Change Request Required Fields        9

Description of Change Request        9

Reason for Change        9

Scope of Change        9

Impact / Systems Affected by Change        10

Testing Validation        10

Breakout Procedure        10

3.1 Application Change Requests        10

OWASP Top 10 Review and Approval        10

Example Application Change Request Comment        11

Merging Composite PRs into another Branch        11

3.1.1 Application Change Request Approvers Onboarding        11

Policy        11

3.2. Network Change Requests        12

Example Network Change Request        12

3.3. Production Environment / CDE Change Requests        13

Example Production Environment Change Request        13

3.4. Firewall Change Requests        14

Example Firewall Change Request        14

Coordinator and Teams

Security Coordinator

• aaron@givecorporation.com

IT Security Team / Patch Management Team

Send emails to irt@givecorporation.com

Team is comprised of the following Senior Developers:

• marian@givecorporation.com
• youcef@givecorporation.com
• hosni@givecorporation.com 

1.0 Vulnerability Alerting Procedure

1.1 Vulnerability Monitoring

Monitor industry sources, vendor alerts, and other sources of vulnerability information for potential threats to cardholder data. This includes regularly checking the National Vulnerability Database (NVD), vendor websites, and security forums for alerts and updates.

The designated lead security coordinator (aaron@givecorporation.com) will conduct a monthly meeting between the senior development and network teams to share information from various sources and review all systems for potential vulnerabilities.

Sources of industry information include, but are not limited to:

        For investigating vulnerabilities

• National Vulnerability Database (NVD)
• Common Vulnerabilities and Exposures (CVE)
• KREBS Security Blog  (add link)

        Go Platform

• Go Vulnerability Database
• Exploit Database

        Top 10

• Open Web Application Security Project (OWASP)

Benchmarks

• Center for Internet Security (CIS)

1.1.2. Vulnerability Patch Management before Merge and Deployment to Production Procedure

If a vulnerability is found in the PR, a comment and fix can be applied immediately without necessitating an escalation to the IRT.

Create Issue In GitHub

In the case of a vulnerability in the Go standard library, package or lib version that requires a patch or update, Create a new Issue in Github to track the progress of updating the dependencies and fixing the vulnerability.

1.2. Vulnerability Scanning

Perform regular vulnerability scans (at least quarterly) of all systems that store, process, or transmit cardholder data. Use an industry standard vulnerability identification tool suited for the deployed environment. The scanning tool must objectively scan and report known vulnerabilities to system administrators without the possibility of modification to provide an objective report to system admins.

1.3. Vulnerability Assessment

Assess the severity and risk of identified vulnerabilities using a risk-based approach. Prioritize vulnerabilities based on their severity and likelihood of exploitation. To perform this, Give Corporation will use the CVSS v3 rating system to determine vulnerabilities and exploitability.

The official website for the Common Vulnerability Scoring System (CVSS) is maintained by FIRST (Forum of Incident Response and Security Teams). Here is the URL:

• CVSS - Official Website by FIRST

        CVSS Rating Calculator

        https://www.first.org/cvss/calculator/3.1

1.4. Notification and Escalation

The Scanning Team will notify the IT Security team (irt@givecorporation,com) of identified vulnerabilities and associated risks. Escalate critical or high-risk vulnerabilities to the Patch Management Team (irt@givecorporation.com).

1.5. Remediation

Develop and implement a plan to remediate identified vulnerabilities. This plan should include a timeline for remediation, responsibilities for remediation, and regular progress reports. High and Critical vulnerabilities will be patched per vendor recommendations within 30 days of discovery; Medium, Low, and Informational findings will be handled within 90 days of discovery. Vulnerabilities that do not have a known solution will be added to the company risk registry with proposed remediation solution and date.

1.6. Verification and Validation

Patch management team will verify that remediation efforts have been successful in addressing identified vulnerabilities.

1.7. Reporting

Regularly report on vulnerability management activities, including vulnerability scans, assessments, notifications, and remediation efforts. Provide reports to senior management and the PCI compliance team as required. Internal vulnerability scanning of the entire PCI scope shall be completed at least quarterly per data security standard requirements. The results of the scans and the remediations of scans are included in the audit package and shall be stored for at least 2 years.

2.0 Patch Management Procedure

2.1. Inventory of Software and Systems

Reference:

Asset Inventory

2.2. Patch Prioritization

Prioritize patching based on risk and severity, with critical security patches being addressed first. The IT Security team should be responsible for evaluating and prioritizing patches based on the level of risk and impact to the organization.

Use the following prioritization statuses:^[a]

• Critical Patch
• High Priority Patch
• Medium Priority Patch
• Low Priority Patch

2.3. Testing and Validation:

Before deploying patches, they should be tested in a non-production environment to ensure that they do not cause any unintended consequences or conflicts with other software. Once testing is complete, patches should be validated to ensure that they have been successfully applied and that no vulnerabilities remain.

2.4. Patch Deployment:

Deploy patches in a timely manner, using automated patch management tools where possible. High and Critical patches should be deployed within 30 days of discovery; Medium, low, and informational patches should be deployed within 90 days of discovery. Patches should be deployed during non-business hours to minimize the impact on system availability and performance.

2.5. Monitoring and Reporting:

Monitor all systems for compliance with patch management procedures, and report on any non-compliance or vulnerabilities that are discovered. The IT Security team should review patch management reports regularly to ensure that all systems are up to date with the latest security patches.

2.6. Incident Response:

In the event of a security incident or breach, the IT Security team should review patch management procedures to determine if any missed patches contributed to the incident. If patches were missed, the Incident Response Procedure should include procedures for immediately deploying critical patches to affected systems.

2.7. Production Deployment and Sprint Release Procedure

To maintain operational stability and ensure visibility across departments, all production deployments at GiveCorporation must follow the standardized deployment process outlined below. This procedure supports cross-functional coordination and meets our internal compliance and risk management standards.

1. Advance Notice Requirement

Deployment plans must be communicated at least one (1) business day in advance to relevant stakeholders. Last-minute or unplanned deployments are not permitted.

2. Deployment Timing

All deployments must be scheduled early in the business day, preferably first thing in the morning. This allows sufficient time for post-deployment testing and issue resolution within working hours.

3. Post-Deployment QA Validation

Immediately after a sprint deployment, QA must perform functional testing of critical business workflows.

4. Approval and Change Request Documentation

Sprint deployments require formal approval from the Security Coordinator, consistent with network change request protocols.

A Production Change Request Form must be submitted and thoroughly completed prior to deployment. It must include:

• Scope and description of the release
• Identified risks and anticipated impacts
• Risk mitigation and rollback plans

5. Release Notes and Legacy Data Impact

• Release notes must be shared prior to deployment, not post-release.
• Notes must clearly outline:

• Features or changes included in the sprint
• How existing or legacy data may be affected, enabling the operations team to distinguish between expected behavior and potential bugs
  

6. Operations Team Awareness and Support

The deployment communication should briefly describe the impact on existing workflows or data, especially if changes may influence what the operations team sees or supports. This ensures proper awareness and response readiness on their end.

3.0 Change Requests

The appropriate procedures must be adhered and properly reported whenever changes are requested and made for the following environments:

• Application Change Requests (Submitted in the Github Repo Pull Requests)
• Network Change Requests (Submitted via Slack and recorded in the ticketing system)
• Production Environment / CDE Change Requests (Submitted via Slack and recorded in the ticketing system)
• Firewall Change Requests (Submitted via Slack and recorded in the ticketing system)

Change Request Required Fields

Each Change Request must contain the following required fields unless otherwise specified:

• Description of Change Request
• Reason for Change (Could be optional - see below)
• Scope of Change (Could be optional - see below)
• Impact / Systems Affected by Change
• Testing Validation
• Breakout Procedure

Description of Change Request

The description of the change request can be the title of the PR. If more context is required add the description of the change request in the comment when creating the PR.

Reason for Change

Write a brief explanation for the reason for the change or why the change is necessary. If the reason for the change is obvious in the description leave it blank.

Scope of Change

List resources, applications, or processes that will be affected by the change. If the scope of the change is obvious in the description or reason, leave it blank.

Impact / Systems Affected by Change

When creating the PR make a comment with a brief description of the impact or systems affected by the change. If the impact is general or not specific to any particular part of the system, use “Production Systems” as the impact description.

Testing Validation

When creating the PR make a comment with a brief description of the testing validation for the change request. If the testing validation is general or not specific, use “QA Regression Tests”

Breakout Procedure

When creating the PR make a comment on the breakout procedure. We will use the same description in each PR which is “Revert to the last known approved and stable branch or version” unless specific scenarios require greater detail of what we need to do to roll it back.

[Need to expand on this for rolling back DB migrations]

3.1 Application Change Requests

Application change requests will be maintained in the Give Corporation Github Repository Code Pull Requests.

Each Pull Request must contain the required fields mentioned above and also include a comment by the approver that OWASP Top 10 was reviewed and approved.

Default Values:

OWASP Top 10 Review and Approval

All PR’s must be reviewed and approved by at least one of the following Senior Developer team:

• marian@givecorporation.com
• youcef@givecorporation.com
• aziz@givecorporation.com 
• timur@givecorporation.com 

The first Senior Developer to review the PR must review the OWASP Top 10 and sign off (by writing a comment in the PR “Reviewed OWASP Top 10 and no vulnerabilities found”) that the Top 10 was reviewed and no vulnerability or security risk was introduced in the PR.

• OWASP Top 10 Website

Example Application Change Request Comment

PR Title:

fix/GB-4781/transfer-error-message #463

Initial Comment:

Change Description:

Generalize transfer error message to not show response code from ACH provider.

Impact:

Could expose the response message to the end user.

Testing Validation:

Check response when making a transfer request with the ACH provider.

Breakout Procedure:

Revert to the last known approved and stable branch or version

Approver Comment:

Reviewed OWASP Top 10 and no vulnerabilities found

Merging Composite PRs into another Branch

When merging a bunch of PRs from one branch into another - example dev -> main. Use the following description.

Change Description:

Composite merge all change requests already reported in each PR

3.1.1 Application Change Request Approvers Onboarding

This section establishes the policy and procedures for onboarding individuals as Application Change Request Approvers at Give Corporation.

Policy

To maintain robust security and operational integrity, all Application Change Request Approvers must:

1. Be formally onboarded as Give Corporation employees, including issuance of a corporate email (@givecorporation.com).
2. Complete all mandatory training requirements, including:

• Security Awareness Training
• Secure Coding Training

3. Be added to the following groups and systems:

• New User Form completed and approved
• Added to the BE Group
• Included in the Give Corporation Employee Roster

4. Be authorized and listed within the Application Change Request approver list.
5. Acknowledge and adhere to relevant policies, including those governing Application Change Requests and OWASP Top 10 standards.

Designation as Approver

• All prospective approvers must be reviewed and approved by the Chief Technology Officer or designated representative.
• The Lead Developer will enforce this policy from the Developer side.

3.2. Network Change Requests

All Network Change Requests must be submitted through RoundRush, the designated ticketing system. The ticket must include the required fields for a Network Change Request.

All Network Change Requests must include the required fields within the ticket submitted in RoundRush.

Default Values:

Once the request is submitted in RoundRush, a notification should be sent via Slack to the relevant approval channel, specifying that the request is ready for review and approval. All communication regarding the approval process must take place within the Slack channel to ensure transparency and streamlined collaboration.

Example Network Change Request

Subject:

Network: Jenkins Prod Security Group Inbound Rules

Body:

Change Description:

Add inbound rules to Jenkins subnet inside the EKS Cluster VPC.

Reason for Change:

Moved Jenkins inside the EKS cluster VPC and created security group rules to restrict traffic inside the VPC.

Inbound Rules:

Allow 22, 80, 443

Impact:

Jenkins will only be accessible through the EKS cluster VPC bastion host

Testing Validation:

Network Regression Tests

Breakout Procedure:

Restore configuration from backup and monitor for any issues

3.3. Production Environment / CDE Change Requests

All changes to the Production Environment / Cardholder Data Environment (CDE) must be submitted through RoundRush, the designated ticketing system. The ticket must include the required fields for a Production Environment / CDE Change Request.

All Production Environment Change Requests must include the required fields within the ticket submitted in RoundRush.

Default Values:

Once the request is submitted in RoundRush, a notification should be sent via Slack to the relevant approval channel, specifying that the request is ready for review and approval. All communication regarding the approval process must take place within the Slack channel to ensure transparency and streamlined collaboration.

Example Production Environment Change Request

Subject:

Production Environment: Enforce HSTS on API subdomain

Body:

Change Description:

Configure HTTP header for Strict-Transport-Security on subdomains.

Reason for Change:

Fix pentest issue Strict Transport not enforced on api subdomain.

Scope:

api.givesync.com

Impact:

Production Systems

Testing Validation:

Production Environment Regression Tests

Breakout Procedure:

Restore configuration from backup and monitor for any issues

3.4. Firewall Change Requests

All Firewall Change Requests must be submitted through RoundRush, the designated ticketing system. The ticket must include the required fields for a Firewall Change Request.

All Firewall Change Requests must include the required fields within the ticket submitted in RoundRush.

Default Values:

Once the request is submitted in RoundRush, a notification should be sent via Slack to the relevant approval channel, specifying that the request is ready for review and approval. All communication regarding the approval process must take place within the Slack channel to ensure transparency and streamlined collaboration.

Example Firewall Change Request

Subject:

Production Environment: Enforce HSTS on API subdomain

Body:

Change Description:

Allow 22 Inbound

Reason for Change:

Users need to SSH to Bastion Host

Scope:

Bastion Host

Impact:

The changes are expected to have low impact on existing services and are crucial for maintaining PCI compliance.

Testing Validation:

Network connectivity, insecure ports/protocols. possible exploitations of the change,

Breakout Procedure:

Restore configuration from backup and monitor for any issues

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.