claudetools/clients/glaztech/reports/2026-06-03-pci-cardholder-data-finding.md

Glaz-Tech Industries — Cardholder Data Storage Finding (PCI-DSS)

Classification: CONFIDENTIAL — Security / PCI Date: 2026-06-03 Prepared by: Arizona Computer Guru (Mike Swanson) System: Glaztech e-commerce/customer-portal web application (server WWW, 192.168.8.72) and its SQL Server backend (192.168.8.62,3436) Method: Read-only database inspection via GuruRMM. No actual card numbers were retrieved. All determinations were made by column classification and aggregate counts (length, all-digits vs. masked vs. encrypted patterns). No PAN, CVV, or cardholder value is reproduced in this report.

---

Executive Summary

Glaztech's internal PSA (GTIware) stores full credit card numbers (PAN) in plaintext and retains card security codes (CVV/CID) in its SQL databases — and those databases sit on the same SQL instance the public website connects to (the website itself stores nothing; it is the access path, see the website security assessment). This is a serious PCI-DSS compliance failure and a significant breach-liability exposure. Approximately 780 saved customer cards (card-on-file) and tens of thousands of historical payment records are affected, with confirmed plaintext PANs and ~hundreds of stored CVV values.

The Sage 100/MAS ERP database (mas_gti) is not the problem — its native card module is disabled (CreditCardEnable = N, 0 stored cards). The exposure is entirely in GTIware's card-on-file tables (cc_file / cof_payments_header), which live in the same SQL instance the public website connects to.

---

Findings

Finding 1 — Full PAN stored in plaintext (card-on-file) — HIGH/CRITICAL

• Table: dbo.cc_file (cc_number varchar(50), cc_exp, cc_name, cc_code, activate, …), present in every per-office database.
• Encryption: none. Values classify as all-digits or digits-with-spaces/dashes (recoverable PAN). Zero rows contained alpha/base64 (encrypted) content.
• Scale (cc_file row counts by office DB):

DB	rows	DB	rows
glaz_prod_elp	179	glaz_prod_alb	44
glaz_prod_den	190	glaz_prod_slc	41
glaz_prod_phx	141	glaz_prod_boi	26
glaz_prod_brl	88	glaz_prod_shp	14
glaz_prod (tuc)	54	glaz_prod_corp	3
Total			≈ 780 saved cards

• Sample classification (glaz_prod / tuc, 54 rows): 29 plaintext PAN + 25 formatted PAN, 0 encrypted, length 15–20.
• PCI-DSS Req 3.4: PAN must be rendered unreadable anywhere it is stored. Violated.

Finding 2 — Stored CVV / card security codes — CRITICAL (indefensible)

• Column: dbo.cc_file.cc_code (varchar(20)).
• Result: populated with 3–4 digit values. In glaz_prod (tuc): 50 of 54 rows hold a stored CVV (3–4 numeric digits). Other office DBs expected to mirror this.
• PCI-DSS Req 3.2: sensitive authentication data (CVV/CVV2/CID) must never be stored after authorization — no exception, even encrypted. This is the most serious item and the fastest to remediate.

Finding 3 — Plaintext PAN in historical payment records — HIGH (large volume)

• Table: dbo.cof_payments_header (cc_number varchar(50)), per-office.
• Scale / classification:
  • glaz_prod_phx: 14,496 rows — 11,794 full plaintext PANs, ~2,700 masked/other.
  • glaz_prod (tuc): 2,245 rows — 367 plaintext + 597 formatted + ~1,242 masked/other.
• Represents years of transaction history retained with recoverable card numbers.

Finding 4 — Access controls / context

• The web application connects with a single shared SQL login (tom) that has full read on the card columns (verified: HAS_PERMS_BY_NAME = 1 on cc_number and cc_code). No column-level protection or data masking.
• Connection strings (with this login + password) are stored in the site Web.config on the web server.
• The Sage 100 DB (mas_gti) has its native card module disabled (0 stored cards) — scope of this finding is GTIware's card-on-file tables, which share a SQL instance with (and are reachable from) the public website.

---

Risk & Impact

• Breach exposure: if the SQL server or web server is compromised, this is a reportable cardholder-data breach (full PAN + CVV in the clear).
• Compliance: clear violations of PCI-DSS Req 3.2 (CVV retention) and Req 3.4 (PAN protection); likely invalidates the merchant's self-assessment and exposes Glaztech to card-brand fines and liability.
• CVV retention specifically removes most "we were compliant" defenses in the event of a breach.

---

Remediation Plan

Immediate (days):

1. Stop writing cc_code (CVV) in the application and purge all stored CVV values (cc_file.cc_code). This is the highest-priority, lowest-effort risk reduction and is indefensible to retain.
2. Inventory and restrict who/what can read cc_file / cof_payments_header.

Short term (weeks): 3. Stop storing raw PAN. Move card-on-file to the CyberSource token vault (already in use for processing) — store a token reference instead of the PAN. 4. Purge or strongly encrypt the historical cc_number columns in cof_payments_header and cc_file once tokenization is in place.

Hardening: 5. Least-privilege SQL accounts (separate read/write, no blanket card-column read), encryption at rest (TDE) as defense-in-depth, and secrets management for Web.config connection strings. 6. Re-scope/refresh the merchant PCI SAQ after remediation.

---

Evidence / Methodology (PAN-free)

• Column discovery via INFORMATION_SCHEMA.COLUMNS (names matching card/cvv/expir/etc.).
• Storage classification via aggregate CASE/COUNT only — e.g. SUM(CASE WHEN col NOT LIKE '%[^0-9]%' AND LEN(col) BETWEEN 13 AND 19 THEN 1 ELSE 0 END) to count full-PAN-shaped values without selecting them.
• CVV detection via count of 3–4 digit cc_code values. No raw card data was selected, displayed, or stored at any point.

---

Status: Reported to ownership 2026-06-03. No data was modified or deleted — remediation pending client (Steve Eastman / Tom) direction. This finding should be raised with the client as a priority compliance/security item.