Preventing Website Breaches

No company no matter how big is immune to a cyber attack

Blog originally published by FlowTraq™, authored by Dr. Vincent Berk

The highly publicized Apple Developer website breach, which left upwards of 100,000 records with personal names, mailing addresses and emails potentially accessed by intruders released little detail about the situation, which may mean they have discovered a larger, fundamental issue with their developing infrastructure. Especially since the company response was to completely overhaul its systems and databases—a fairly substantial reaction.

The magnitude of the company allowed Apple to handle its situation well. The attacker managed to download some personal information, but by no means did the attacker have unfettered access to Apple resources. Nor was the attacker capable of logging into servers deep inside the Apple network or capable of launching or injecting malware into App Store applications. Apple has been safe from such large-scale, high-profile breaches for a long time because of the company’s vast knowledge and experience in cyber protection.

For organizations less versed in building a wall of defense against outside hacks, there are three things they can do now to help prevent such a breach in the future.

  • Compartmentalize your data. This is the equivalent of storing records in locked file cabinets and only giving people access on a need-to-know basis. It is an architectural decision—keep your login information away from the blogs, and separate that from the payment information. Encrypt everything, and stick a firewall in front of these data resources.
  • Perform behavioral analysis on network traffic. 100,000 customer data records coming from a sign-on database is an anomalous traffic pattern, which can be detected manually (humans are great anomaly detectors!) or with software packages. Computers communicate in very predictable patterns, these patterns can be profiled, and anomalies can be detected quickly.
  • Hack yourself. Although audits and Red Team attempts often miss the more subtle attack vectors, an outside team can often pinpoint small vulnerabilities that might allow an attacker access to your systems and data. Place the audit or Red Team in front of the developers first, and force them to be honest. Pride should not stand in the way of securing your customers’ data.

It’s important to remember that 100% security is only possible if you have no data to protect. The question we should be asking is: What are the best steps one can take to ensure as close to 100% protection as possible, no matter how much data needs to be protected?