We're all familiar with the Target payment card breach late last year. Up to 110 million payment card numbers were stolen through a huge hole in the company's network, right down to the security of the PIN pads. The breach cost Target CIO Beth Jacobs her job; it was, and still is, a serious matter.
Target is obviously a public company, so this situation garnered a lot of attention. As a CIO or member of the executive technical staff, though, there are some observations about the situation that can apply to your company.
Here are four key lessons from Target's very public example of a data breach.
1. It's Vital to Know Which Alarms You Can Safely Ignore
In this connected age, security vulnerabilities are a dime a dozen. Different software has different risk profiles, and some of the vulnerabilities that affect certain organizations severely are already safely mitigated in other organizations simply by the structure of how components are set up. Performing a thorough threat analysis is crucial, but knowing how to manage the onslaught of event logs, audit logs, vendor vulnerability notifications and intrusion prevention messages is just as critical.
One best practice: Develop a rubric by which a weight is assigned to alerts about security vulnerabilities and attempted penetration. Depending on what business you're in, you can score this either by system involved or by the source of the alert. Some considerations might include the following:
- For a retail business, payment systems alerts should be given clear priority. Typically, these payment systems are segregated from other networks, but patching alerts from your vendors, security audit logs and activity monitoring should be done on a high frequency, with particular attention paid to anomalies that appear in these results. Internet-facing businesses should always ensure that fraud prevention measures are in place and ensure shopping cart and ecommerce software is patched and monitored.
- Alerts from your intrusion detection system or honeypots should also be given a higher priority than other alerts. However, it may be necessary to fine-tune thresholds. One-off attempts shouldn't raise alarms, but repeated attempts that display similar characteristics should be evaluated for their consistency and then bubbled up to the appropriate levels for technical review and analysis.
- Other regular software vulnerabilities, like those in file servers and desktop software, should be cataloged and analyzed but should fall below other, riskier parts of your technology stack.
Create a judgment structure by which you can evaluate alerts and threat messages so the signal-to-noise ratio is high as it can be. This way, "red alert" messages get the attention they deserve immediately, while "yellow alert" type messages are analyzed at a less urgent pace.