abuse_cases/tracking

18 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Abuse Case spreadsheet required sheets

The abuse case tracking spreadsheet must contain three sheets: FEATURES (list of business features planned for the workshop), ABUSE CASES (all abuse cases identified during the workshop), and COUNTERMEASURES (optional sheet with list of possible countermeasures and descriptions).

FEATURES sheet table structure

The FEATURES sheet contains a table with columns: Feature unique ID, Feature name, and Feature short description. Example: Feature unique ID (FEATURE_001), Feature name (DocumentUploadFeature), Feature short description (Allow user to upload document along a message).

COUNTERMEASURES sheet table structure

The COUNTERMEASURES sheet contains a table with columns: Countermeasure unique ID, Countermeasure short description, and Countermeasure help/hint. Example: Countermeasure unique ID (DEFENSE_001), Countermeasure short description (Validate the uploaded file by loading it into a parser), Countermeasure help/hint (Use advice from the OWASP Cheat Sheet about file upload).

ABUSE CASES sheet table structure

The ABUSE CASES sheet contains columns: Abuse case unique ID, Feature ID impacted, Abuse case's attack description, Attack referential ID (if applicable), CVSS V3 risk rating (score), CVSS V3 string, Kind of abuse case, Countermeasure ID applicable, and Handling decision (To Address or Risk Accepted).

Abuse case unique ID format

An example of unique ID format for abuse cases is ABUSE_CASE_001, allowing tracking throughout the whole project or sprint.

Use identity signals beyond email for abuse detection

Device fingerprints, payment-method fingerprints, phone number verification, and KYC verification carry more signal than email addresses, which are cheap to create in bulk. Use these richer identity signals to detect multi-accounting abuse patterns.

Log all value-dispensing operations with full context

For any operation that dispenses value, changes permissions, or moves money, log: the authenticated user, the target resource, the action taken, the outcome, request context to reconstruct what happened (IP, user agent, correlation ID), and business context to audit (the price computed, the coupon applied, the new state). These logs should be tamper-evident and separate from general application logs.

Alert on signups from same IP or device

Alert on unusually high rates of signups from the same IP address, device fingerprint, or payment instrument. This pattern often precedes or accompanies multi-accounting abuse.

Alert on repeated failed password reset requests

Alert on unusually high rates of repeated failed password-reset requests from the same source. This can indicate account enumeration or targeted account takeover attempts.

Alert on abnormally high promo and referral redemption rates

Alert on unusually high rates of promo redemptions, referral completions, or credit issuances. Simple thresholds on per-user, per-IP, and per-device rates catch most automated abuse without requiring machine learning.

Alert on workflows completing in inhuman time

Alert on workflows that complete in substantially less time than a human would need to execute them. This can indicate automated abuse of the business process.

Enable Kubernetes API audit logging for security analysis and compliance

Kubernetes API audit logger is a beta feature recording API server actions for later analysis in event of compromise. Enable audit logging and archive audit files on secure server. Monitor logs for anomalous or unwanted API calls, especially authorization failures (status message 'Forbidden'). Authorization failures may indicate attackers attempting to abuse stolen credentials. Managed Kubernetes providers like GKE provide audit data access in cloud console with alert configuration capability.

Kubernetes audit log example structure and fields

Audit logs contain the following fields: kind and apiVersion for audit event type; metadata with creationTimestamp; level indicating Metadata, Request, RequestResponse, or None; timestamp and auditID for event tracking; stage and stageTimestamp for RequestReceived or ResponseComplete; verb for API action (list, get, create, delete); requestURI for API endpoint; user object containing username and groups; sourceIPs array; objectRef with resource, namespace, and apiVersion; requestReceivedTimestamp and stageTimestamp.

Kubernetes audit policy levels: None, Metadata, Request, RequestResponse

Audit policy rules determine audit level for events. None does not log events matching rule. Metadata logs request metadata (requesting user, timestamp, resource, verb) but not request or response body. Request logs event metadata and request body but not response body (not for non-resource requests). RequestResponse logs event metadata, request and response bodies (not for non-resource requests). Events are evaluated against rules in order; first matching rule sets the audit level.

Enable audit logging with --audit-policy-file flag on kube-apiserver

Pass audit policy file to kube-apiserver using --audit-policy-file flag. If flag is omitted, no events are logged. The rules field must be provided in audit policy file. A policy with zero rules is treated as illegal.

Container logging to stdout and stderr streams in Kubernetes

The easiest method for logging containers is writing to standard output (stdout) and standard error (stderr) streams. The container engine streams logs to the logging driver set by Kubernetes configuration. In most cases logs end up in /var/log/containers directory on the host. This approach allows centralized collection via Fluentd or similar agents into logging hubs like Google Stackdriver Logging or Elasticsearch for viewing with tools like Kibana.

Use sidecar container for persisting container logs to log files

Containers logging to stdout/stderr are ephemeral. For persisting logs, write to a log file and use a sidecar container running in the same pod. The sidecar mounts the same volume as the application container and processes logs separately. Example uses emptyDir volume mounted at /var/log with application writing to /var/log/example.log and sidecar tailing the file.

View container logs in Kubernetes with kubectl log command

To view logs for a container, run: kubectl log <container-name>

Give your agent this brain