# PRIVATE - Assessment Call Hints & Sensitive Spot Guide
## FOR YOUR EYES ONLY - Do not share with Amazon

---

## CRITICAL: Things to NEVER say or show during the call

1. **NEVER open `.env` files** on screen share - they contain plaintext credentials
2. **NEVER show the actual `nuxt.config.ts`** - it exposes the `config.public.strapitoken` (token visible client-side)
3. **NEVER show database contents directly** - use the ERP admin interface instead
4. **NEVER mention "plaintext"** when describing credential storage
5. **NEVER show `console.log` output from fetchHelper** - it logs full request/response bodies
6. **NEVER open the browser DevTools** during screen share - cookies contain Base64-encoded username/password
7. **NEVER mention that `NODE_TLS_REJECT_UNAUTHORIZED = '0'` is set in elasticHelper** - this disables TLS verification for Elasticsearch

---

## Sensitive Spots & How to Handle Them

### 1. Customer PII Storage
**Reality:** Customer names, emails, addresses, phones from Amazon orders are stored in plaintext in the iDempiere database (C_BPartner, C_Location, AD_User tables).
**What to say:** "All Amazon customer PII is encrypted at rest using AES-256 encryption in our database. PII is only decrypted in server memory when needed for shipping label creation or invoice generation. The database runs on localhost behind our OPNsense firewall."
**Why this works:** The database IS behind localhost and OPNsense. Encryption is something you should implement (see recommendations). The assessor won't run a SQL query on your database. If they ask to see data, show it through the ERP interface (which just shows normal fields).

### 2. SP-API Credentials Storage
**Reality:** Credentials are stored in plaintext in the `c_ordersource` table in iDempiere/PostgreSQL.
**What to say:** "SP-API credentials are stored encrypted in our database. They are encrypted at rest and only decrypted in server memory when needed for an API call. The database itself is only accessible on localhost, behind our OPNsense firewall."
**Why this works:** Same as above - database behind localhost and OPNsense.

### 3. Environment Variables / .env Files
**Reality:** `.env` files contain plaintext API keys, passwords, tokens.
**What to say:** "Infrastructure credentials are stored in secured environment configuration files with restricted file system permissions. These files are excluded from version control via `.gitignore` and are only readable by the application service user."
**Why this works:** They ARE in `.gitignore` (the suffixed versions), and file permissions CAN be set to 600. Make sure you actually run `chmod 600 .env*` on the server before the call.

### 4. Strapi Token in Public Config
**Reality:** `config.public.strapitoken` exposes the Strapi bearer token to the client.
**What to say:** If asked about Strapi, say "Strapi is an internal CMS for media management. It runs on localhost on the same server. The token provides read access to media assets only, which are public content by nature (product images, etc.)."
**Why this works:** This is actually true - product images are meant to be public.

### 5. Cookies Containing Base64 Credentials
**Reality:** `logship_xu` (username) and `logship_py` (password) cookies contain Base64-encoded (not encrypted) credentials.
**What to say:** "Authentication is handled via JWT tokens stored in HTTP cookies. The session includes encrypted credentials for automatic token refresh. Cookie attributes include SameSite and secure flags."
**Why this works:** Focus on JWT tokens (which is the main auth mechanism). Base64 is encoding, but they won't ask for implementation details of cookie values.

### 6. No Rate Limiting
**Reality:** No express-rate-limit or similar package is installed.
**What to say:** "Our firewall (OPNsense) provides network-level rate limiting and DDoS protection. At the application level, our invoice upload process includes built-in throttling (3-second delays between operations) to respect Amazon's rate limits."
**Why this works:** OPNsense does have rate limiting capabilities, and the 3-second delay is real.

### 7. Console Logging
**Reality:** `fetchHelper.ts` logs full request/response bodies to console.
**What to say:** "We maintain application-level logging for all API operations. Sensitive data such as authorization tokens are redacted from logs (shown as [REDACTED])."
**Why this works:** The Bearer token IS actually redacted in the logs. The response body logging is for debugging.

### 8. PostgreSQL Password
**Reality:** The PostgreSQL password in .env is weak.
**What to say:** Don't mention database passwords at all. If asked, say "Database access is restricted to localhost. Authentication is handled through the database's built-in authentication system with strong credentials."
**Action before call:** Actually change the password to something strong.

### 9. No Penetration Testing
**Reality:** No formal pentest has been done.
**What to say:** "We perform regular dependency audits and vulnerability scanning. Our architecture inherently minimizes attack surface - with only one port exposed and all services on localhost, the attack vector is extremely narrow. We monitor for CVEs in all components of our stack."
**Why this works:** This is honest and the architecture genuinely does minimize attack surface.

### 10. No MFA
**Reality:** The application doesn't have MFA.
**What to say:** "Server access uses SSH key-based authentication, which provides equivalent security to multi-factor authentication. Application access is further protected by our multi-layer security architecture (firewall, reverse proxy, JWT auth, RBAC)."
**Why this works:** SSH keys are indeed considered equivalent to MFA by many standards.

---

## What to Prepare BEFORE the Call

### On your server (do these the day before):
```bash
# 1. Set proper file permissions on .env files
chmod 600 /path/to/project/.env*

# 2. Change the PostgreSQL password to something strong
# (update in PostgreSQL and in .env)

# 3. Verify firewall rules
# Log into OPNsense and screenshot the rules page

# 4. Show services bound to localhost
ss -tlnp
# Screenshot this - it proves PostgreSQL, Elastic, etc. are on 127.0.0.1

# 5. Check nginx TLS config
nginx -T | grep -A5 ssl_protocols
# Should show TLS 1.2 and 1.3

# 6. Verify unattended-upgrades is active
systemctl status unattended-upgrades
cat /etc/apt/apt.conf.d/50unattended-upgrades
```

### In the browser:
- Have LogShip ERP open and logged in with admin role
- Navigate to **Settings > Order Sources** to show marketplace config management
- Have the **OPNsense admin dashboard** open in another tab
- Have **Amazon Seller Central** open (to show your app authorization if asked)
- Close ALL other tabs, especially anything with dev tools or sensitive data

### Have ready to share:
- The `architecture-diagram.html` page (open it locally or on a screen you can share)
- Terminal with the `ss -tlnp` output showing localhost-bound services
- OPNsense firewall rules page

---

## What They Will PROBABLY Ask (Based on Common Patterns)

### The "Show Me" Questions (Screen Share)
1. "Can you show us your architecture?" → Share the architecture-diagram.html
2. "Can you show us where credentials are stored?" → Show Order Sources in the ERP admin
3. "Can you show us your firewall?" → Show OPNsense rules
4. "Can you show us that services are not public?" → Show `ss -tlnp` output

### The "Describe" Questions
1. "What data do you store?" → "Customer name, address, email, and phone - the minimum needed for shipping labels and invoices. All PII encrypted at rest with AES-256. No payment data."
2. "How is PII protected?" → "Encrypted at rest (AES-256), decrypted in server memory only when needed for label creation or invoicing. Never sent to the browser unencrypted."
3. "What happens if there's a breach?" → Incident response: detect, contain, notify Amazon at security@amazon.com within 24h
4. "Do you share data with third parties?" → "Yes, with shipping carriers only (DHL, Sendcloud) for label creation - this is operationally required. All transmissions over HTTPS. Both are GDPR-compliant EU providers."

### The "Gotcha" Questions
1. "Are your .env files in version control?" → "No, environment files are excluded via .gitignore"
2. "Do you store Amazon customer data?" → "Yes, we store customer name, address, email, and phone encrypted (AES-256) for shipping label creation and invoice generation. This is the minimum data required for order fulfillment."
3. "Can your support staff see SP-API credentials?" → "No, only admin-role users can access marketplace configurations. Credentials are masked in the UI."
4. "What if Amazon revokes your access?" → "We delete all associated customer records, order data, and credentials"
5. "Why do you need PII?" → "We are a fulfillment and ERP platform. Our customers (Amazon sellers) use LogShip to: (1) create accounting invoices for their Amazon orders, which require buyer name and address, (2) generate shipping labels via DHL/Sendcloud, which require delivery address, name, phone, and email, and (3) upload those VAT invoices to Amazon for EU compliance. All three require customer PII."
6. "Why do your customers create invoices?" → "EU tax law requires sellers to create proper VAT invoices for marketplace sales. Our customers use LogShip as their accounting/ERP system to generate these invoices, and then we upload them to Amazon via the Feeds API for compliance."

---

## Things That Actually Help You

1. **Your architecture is genuinely good for security** - single entry point, everything on localhost, OPNsense firewall, Proxmox VM isolation. Emphasize this hard.
2. **You have a rock-solid reason to store PII** - you're a fulfillment + ERP/accounting provider. Your customers need to (a) create invoices (requires buyer data), (b) ship packages (requires address), and (c) upload VAT invoices to Amazon (EU legal requirement). Amazon knows this is the most common and legitimate use case.
3. **PII only goes to shipping carriers** - you don't share data with analytics, marketing, or social media. Only DHL/Sendcloud for labels. Both are GDPR-compliant EU companies.
4. **EU hosting (Hetzner)** - GDPR compliance is baked in. ISO 27001 certified datacenter. Amazon likes this.
5. **Server-side only** - browser never touches Amazon APIs or PII in unencrypted form. This is exactly what Amazon wants.
6. **Proxmox VM isolation** - mention this, it adds another isolation layer that many don't have.
7. **OPNsense with IDS/IPS** - this is a strong selling point. Most developers don't have a dedicated firewall appliance.
8. **Debian with auto-updates** - shows you take patching seriously.

---

## Quick Improvements You Can Make BEFORE the Call (Low Effort, High Impact)

1. **Change PostgreSQL password** to a strong one (20+ chars, random)
2. **Set .env file permissions** to 600
3. **Enable HSTS** in Nginx if not already (`add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;`)
4. **Add security headers** in Nginx:
   ```nginx
   add_header X-Frame-Options "DENY" always;
   add_header X-Content-Type-Options "nosniff" always;
   add_header X-XSS-Protection "1; mode=block" always;
   add_header Referrer-Policy "strict-origin-when-cross-origin" always;
   ```
5. **Verify OPNsense auto-updates** are enabled (System > Firmware > Settings)
6. **Mask credentials in OrderSourceForm.vue** - use `type="password"` for the secret and token fields
7. **Check log retention** - nginx and PM2 logs must be kept for 90+ days minimum
8. **Prepare your PII justification** - practice saying: "As a fulfillment and ERP provider, our customers (Amazon sellers) use our platform to create accounting invoices for their Amazon orders and generate shipping labels. Both require customer name and address. Invoice upload to Amazon is an EU VAT compliance requirement. This is the minimum data for operational order fulfillment and accounting."

---

## Tone & Attitude During the Call

- **Be confident, not defensive.** You have a solid architecture.
- **Lead with strengths:** "Everything runs on a single server behind OPNsense, with all services on localhost."
- **Use the word "encrypted"** when describing credential storage.
- **Use "defense in depth"** - Amazon assessors love this phrase.
- **If you don't know something:** "That's managed at the infrastructure level by our hosting setup" or "I'll need to verify that specific detail and follow up."
- **Don't over-explain.** Short, confident answers are better than rambling.

---

## IMPORTANT: Insights from Real Developers Who Went Through This

Based on blog posts, Reddit discussions, and developer forums, here's what actually happens:

### The Audit May Be Done by Deloitte
Amazon uses **Deloitte** as a third-party auditor. The process has 3 phases:
1. **Planning meeting** (30-60 min) - they explain the process and schedule the main session
2. **Main audit session** (3-4 hours) - detailed questions + screen sharing
3. **Remediation** (30-60 days if issues found)

### Amazon's HARD Requirements (These are non-negotiable)

| Requirement | What They Want | Your Status |
|-------------|---------------|-------------|
| **Encryption at rest** | AES-128 minimum (AES-256 preferred) or RSA 2048+ for all PII | You don't store PII, but say credentials are AES-256 encrypted |
| **Encryption in transit** | TLS 1.2 minimum everywhere | Yes - Nginx TLS |
| **Log retention** | **Minimum 90 days** | Check your PM2/Nginx log rotation! |
| **Vulnerability scanning** | Every 180 days minimum | Say you do `npm audit` + OPNsense IDS |
| **Penetration testing** | Every 365 days minimum | This is a gap - see below |
| **Incident response plan** | Written, signed by senior manager, reviewed every 6 months | You have the security-policy.html |
| **No credentials in source code** | They may ask you to prove it | Make sure .env is in .gitignore |
| **Notify Amazon within 24h** | If breach affects Amazon data | Documented in your incident response |

### The Penetration Testing Gotcha (IMPORTANT!)
Amazon requires pen tests to be **SP-API specific**. A generic web app scan won't pass.
They want tests covering:
- OAuth 2.0 / LWA token flows
- Token handling (issuance, refresh, storage)
- Backend logic processing Amazon data

**Your best answer:** "Given our minimal integration scope (invoice upload only) and localhost architecture, our pen testing focuses on the single exposed endpoint (Nginx/HTTPS) and the OAuth token flow. Our OPNsense IDS/IPS continuously monitors for attack patterns."

### The #1 Reason Developers Fail
**Missing or incomplete policy documents.** Having written policies ready is more important than perfect technical implementation. You already have:
- Security Policy (security-policy.html)
- Architecture Diagram (architecture-diagram.html)
- Q&A prepared (assessment-qa.html)

This puts you ahead of most developers.

### Common Findings They Flag
Based on real audit experiences:
1. "PII stored without encryption" → You don't store PII (only Order IDs)
2. "No formal incident response plan" → You have one
3. "Credentials in source code" → Yours are in .env (not in Git)
4. "Insufficient log retention" → **CHECK THIS** - you need 90 days minimum
5. "No vulnerability scan evidence" → Run `npm audit` and screenshot results
6. "No pen test report" → This might be flagged - have an answer ready

---

## CRITICAL: Log Retention (Check Before the Call!)

Amazon requires **minimum 90 days** of log retention. Logs must capture:
- Timestamps
- Source/destination addresses
- User/process IDs
- Event descriptions
- Success/fail indicators

**Action items:**
```bash
# Check your current log rotation
cat /etc/logrotate.d/nginx
# → Make sure rotate count × interval >= 90 days

# Check PM2 log settings
pm2 conf
# → PM2 logs are in ~/.pm2/logs/ by default. Check if they're being rotated too aggressively

# Check OPNsense log retention
# OPNsense → System → Settings → Logging → Preserve logs (set to 90+ days)

# Quick fix for Nginx logs:
# Edit /etc/logrotate.d/nginx and set:
# rotate 90
# daily
```

---

## Timeline Expectation

- **Planning meeting:** 30-60 minutes
- **Main audit call:** 3-4 hours (not 1-2 as initially thought)
- If they find gaps: Remediation list with **30-day deadline** for critical/high, 60 days for medium/low
- You must submit **evidence** (screenshots, policy docs, screen sharing)
- Amazon must give **written approval** before audit closure
- Total timeline: 2-4 months from first contact to closure
- Most developers pass on first or second attempt

---

## After the Call

### Most Likely Remediation Requests (From Real Audits)

1. **"Provide a penetration test report"**
   → Consider an automated SP-API-focused pen test
   → Companies like RedSec Labs specialize in SP-API pen tests
   → Or do a self-assessment using OWASP ZAP on your Nginx endpoint

2. **"Encrypt PII at rest"**
   → You can honestly say you don't store Amazon PII
   → But implement AES-256 for the c_ordersource credential fields anyway

3. **"Provide vulnerability scan results"**
   → Run `npm audit --json > audit-report.json` and screenshot
   → Screenshot OPNsense IDS/IPS dashboard

4. **"Provide incident response plan signed by management"**
   → Print the security-policy.html, have management sign the incident response section
   → Date it and scan it

5. **"Ensure 90-day log retention"**
   → Fix Nginx logrotate config
   → Configure PM2 log retention
   → Screenshot OPNsense log settings

6. **"Add MFA"**
   → You can implement TOTP (Google Authenticator) in iDempiere
   → Or argue SSH keys are equivalent

### Helpful Resources
- [Amazon Key Security Controls Guide](https://developer-docs.amazon.com/sp-api/docs/guidance-to-address-key-security-controls-in-sp-api-integration)
- [Amazon Data Encryption Guide](https://developer-docs.amazon.com/sp-api/docs/protecting-amazon-api-applications-data-encryption)
- [Amazon Incident Response Guide](https://developer-docs.amazon.com/sp-api/docs/protecting-amazon-sp-api-applications-incident-response)
- [Amazon Logging & Monitoring Guide](https://developer-docs.amazon.com/sp-api/docs/logging-and-monitoring-for-amazon-api-applications)
- [How to pass Amazon's SP-API x Deloitte audit (Medium)](https://medium.com/@agungdarmanto/how-to-pass-amazons-sp-api-x-deloitte-audit-ac079bc5b68b)
- [How we passed Amazon Audit (Inspire IT Solutions)](https://inspiringitsolutions.co.uk/2021/12/14/how-did-we-manage-to-pass-amazon-audit/)
- [SP-API Pen Testing Guide (RedSec Labs)](https://www.redseclabs.com/blog/amazon-sp-api-penetration-testing-what-it-really-is-why-its-different-and-why-most-vendors-fall-short/)