azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

sync: auto-sync from GURU-5070 at 2026-06-03 15:55:57

Browse Source 
Author: Mike Swanson
Machine: GURU-5070
Timestamp: 2026-06-03 15:55:57
This commit is contained in:
Mike Swanson
2026-06-03 15:56:01 -07:00
parent ae1ec4517a
commit a98fed14c9
3 changed files with 36 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
clients/glaztech/session-logs/2026-06-03-session.md
View File

@@ -104,3 +104,19 @@ Performed a deep security assessment (read-only; no card numbers or passwords re
- GuruRMM client id `d857708c-5713-4ee5-a314-679f86d2f9f9`; WWW agent `455a1bc7-1c29-42bc-b597-fa1e64f08eec`.
- TLS fix pattern (legacy .NET → modern gateway): `SchUseStrongCrypto=1` + `SystemDefaultTlsVersions=1` both `.NETFramework\v4.0.30319` hives + app-pool recycle.
- LE-safe HTTP→HTTPS redirect: URL Rewrite rule with `{REQUEST_URI}` `^/\.well-known/acme-challenge/` negate condition.
---
## Update: 15:52 PT — Payrilla/CyberSource reconciliation + Sage finding
Mike reported Glaztech "no longer uses CyberSource, switched to Payrilla (secure card storage)." Verified the live system rather than take it at face value — and the technical reality contradicts the belief:
- **Website is STILL on CyberSource/PNC.** No `payrilla`/`payrix`/`paya`/`payroc` references anywhere in `D:\web\glaztech_4` code or config. Live payment pages remain `online-payment-pnc.aspx` / `quick-pay-pnc.aspx` → `api.cybersource.com`. `web_payment_header` shows live `CC-WebPayment-PNC` Approved/Error transactions **today** (2026-06-03 14:47 Approved, 15:07 Error) + E-Check.
- **Plaintext cards STILL being written daily.** `cc_file` last write: Tucson **2026-06-03 14:15** (8/60d), Phoenix **2026-06-03 10:19** (14/60d). Ongoing accumulation, not legacy.
- **Sage 100 (`mas_gti`) CC module is DISABLED** — `SY_Company` (Company GTI) `CreditCardEnable=N`, `CreditCardVaultOnlyID` empty, `AR_CustomerCreditCard` = **0 rows**. Corrects an earlier in-session assumption that Sage actively tokenizes via Paya: the tokenization columns exist in the Sage schema but are **unused**. Sage stores no cardholder data at all (strengthens the containment finding).
- **Payrilla/Paya is not visible in either system we can reach.** If in use, it's a separate channel (standalone virtual terminal / different portal / manual) that does NOT cover the website. This is the likely source of the client's "we moved to Payrilla for everything" belief — true at most for some standalone tool, NOT for the website (the system storing plaintext cards).
- **Anomaly:** `cc_file` now returns "Invalid object name" in the `corp` DB though it existed there this morning (3 rows) — needs a second look; per-office DBs (tuc/phx) unaffected and still writing.
**Actions:** updated `clients/glaztech/reports/2026-06-03-website-security-assessment.md` (added "Current State Verified — 2026-06-03" section; corrected two Sage lines from "uses tokenization / materially compliant" to "CC module disabled, 0 stored cards"). Posted public+emailed client comment on **#32378** (id 417040624) reflecting the live, ongoing risk and that Payrilla is not yet implemented on the site. Drafted a further client clarification (the Sage/Payrilla visibility gap) — **pending Mike's go** before posting (would be the 4th #32378 email today).
**Open:** confirm with Payrilla which flows actually route through them; investigate the corp `cc_file` anomaly; remediation path reframed to "migrate the website's card-on-file to the chosen processor's token vault, stop writing `cc_file`/`cof_payments_header`, purge plaintext + backups, decommission CyberSource."