What a difference a day makes, 24 insecure ecommerce hours...

happygeek 0 Tallied Votes 326 Views Share

If a week is a long time in politics, then 24 hours is an absolute age in ecommerce security terms. Which make the findings of a Tripwire survey, published today, all the more worrying.

The survey, conducted by Atomic Research, questioned 102 financial organizations and 151 retail organizations which process card payments in the United Kingdom. It has concluded that 35% of organisations takes two or three days to detect a breach, with 44% admitting they could protect customer data better.

This gets more worrying when you realise that 24% had already been victims of a data breach which saw Personally Identifiable Information either stolen or accessed, and 36% of those asked said they didn't have confidence in their incident response plans. With only 51% being 'somewhat confident' that the security controls they have in place are capable of detecting malicious applications you might think this would be a serious cause for concern for the organisations concerned. Yet an incredibly high 40% of them simply refused to believe that all those recent, and very high profile, card holder breaches we have been reading about have changed the opinions of high level executives when it comes to security strategy.

Tim Erlin, director of IT security and risk strategy for Tripwire which sponsored the report, calls it shocking that there is such a high level of confidence exhibited by respondents. "60% of respondents said they are confident that their security controls are able to prevent the loss of data files" Erlin says, continuing "but this confidence flies in the face of recent evidence to the contrary."

Dani AI

Generated

As points out, the Tripwire survey underlines a familiar problem: long detection windows and misplaced confidence turn a single day of exposure into a major business event. The practical gap in the thread is actionable remediation—what to do right away to shorten time-to-detect, limit blast radius, and make incident response reliable.

Immediate defensive steps

  • Centralize logs and alerting (application, web, firewall, DNS). Feed them into a SIEM or managed-detection service and tune alerts for unusual outbound traffic, new external script loads, or unexpected changes to checkout pages.
  • Add file‑integrity monitoring on web roots and payment handlers. Alert on any modification to checkout or payment-processing files.
  • Deploy endpoint detection (EDR) and network IDS/IPS; consider an MDR provider for 24/7 coverage if in-house staffing is limited.
  • Harden admin access: least privilege, MFA for all privileged accounts, dedicated admin networks, and strict change control with review of every deployment to payment pages.
  • Reduce scope of card data handling: prefer tokenization or hosted-payment forms so PANs don’t touch merchant systems.
  • Treat third‑party scripts as high risk: serve critical code from controlled domains, use Content Security Policy/Subresource Integrity where possible, and monitor any third‑party changes.

A concise incident‑response workflow

  1. Detect (alert validation).
  2. Triage (scope and affected components).
  3. Contain (isolate affected hosts, disable suspect scripts).
  4. Preserve (collect logs, make forensic copies).
  5. Notify (payment processor, counsel, regulators as required).
  6. Remediate and restore from known‑good sources.
  7. Post‑incident review with measurable follow-up (tabletops, SLA for MTTD/MTTR).

Quick troubleshooting checklist

Compare current checkout JS to a baseline; inspect egress destinations and volumes; review recent admin logins and code deployments; if a skimmer is suspected, pull live scripts offline and switch to processor-hosted payments while investigating. Leadership commitment and regular tabletop exercises turn slow discovery into rapid containment.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.