News & Commentary
5/2/2014
01:00 PM
J.J. Thompson
J.J. Thompson
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
100%
0%

Why Perimeter Defenses Are No Longer Enough

When it comes to corporate information security and data protection, the new normal is "due care" in managing day-to-day operations.

"Breaches happen. Expect to be hacked. Expect to lose data. It’s all about how quickly you respond." True. We've all heard this rhetoric shift from absolute compromise avoidance to acceptance of a new reality that the security industry can finally see when an attack has taken place and we should own up to the fact that perimeter defenses no longer prevent them. That reality has set the tone for demonstration of "due care" in managing day-to-day security operations.

With visibility tools such as IDS, IPS, SIEM, and malware detection in place in many companies, the standard of due care has also changed. If you can see that you are under attack, or that your customer data is compromised, you have to do something about it -- like block it. Or, if the alert came after the fact, at least contain it and prevent more data from being exfiltrated.

Target is a case in point. FireEye was not only in place, it detected the malware and the IT operations team in Minneapolis was alerted. This intelligence likely came through a trusted source, either from the vendor (FireEye) or from inside Target's infrastructure, security, or procurement teams, based on the information reported in the now renowned Businessweek cover story, "Missed Alarms and 40 Million Stolen Credit Card Numbers: How Target Blew It."

People, process, and technology
I'm inclined to go along with the assertions and assume that the alert took place, on multiple dates, and that the alerts did not get managed to resolution. But the real question, in my mind, is what are the possible reasons why this didn't happen?

Tools don't solve the problem. Period. Ever. The combination of people, process and technology do. Tired of hearing this from your auditors? Well, get over it because they're right and it’s time we all embraced the concept. Each and every time I get called into a security consulting engagement in a large enterprise, I get push back when my team tries to evaluate process and supporting "policy decisions" as part of the overall security program.

Usually this comes from mid-level IT managers or directors who simply want to see a penetration test, and for us to move on. The general agreement of large enterprise security teams is that they have the best tools and the best people. So since their risk management program requires a third-party assessment, please just do the pen test and get moving. Target is now our new illustrative case as to why we don’t, because, by most criteria, Target did it right. Millions of dollars in security tool spend, tens of security team members. Strong leading-edge tools like FireEye in place. Yet, how did that work out for them? 

Stop missing the bulls-eye
The bulls-eye is not checking the box on deploying all the latest and greatest tools. Recently, articles from Dark Reading and The Motley Fool touted that buying more tools is the solution. Not surprising, yet very disappointing. Tools will not solve this issue. The solution is simple. Beyond simple. The big secret is that this issue can be solved in four simple steps: 

Step No. 1: Define the security service catalogue.
Step No. 2: Identify the policy decisions that are informally in place in how incidents are categorized, classified, and managed to resolution. 
Step No. 3: Only measure metrics that matter (a.k.a.: "outcome-based metrics"). 
Step No. 4: Discuss the output in a real way, make a decision, document the decision in the "policy decisions matrix," and re-visit these decisions monthly. 

From the time I first heard about the Target incident, I had no reason to think that it would become one of the pivotal moments that would shape precedent, case law, and the way organizations define due care and due diligence. According to Harvard Law Review, "The care others exercise should at most be only evidence of the care that a reasonably prudent man would exercise under the circumstances." What is the expectation of due care when applied in the Target Breach? How would it apply to your company? Let's chat about it in the comments.

J.J. Thompson is the CEO and Managing Director at Rook Security and specializes in strategy, response, and next-generation security operations. View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
jjthomps
100%
0%
jjthomps,
User Rank: Apprentice
5/5/2014 | 11:03:39 AM
Re: Pivotal moment for "due care"
"...proof that internal policies were followed" <- exactly. My guess here is that Target had a policy that stated something like "... events categorized as X,Y,Z are escalated according to table A, with the following SLA's in table B."

Was their policy and supporting proceedures designed that way? If so, did they follow their defined process? If not, then what? Is the standard of due care in following the process as DESIGNED? In tests of operating effectiveness, Target "passed" for PCI, either their auditor did not properly test the controls, ignored residual risk issues, or that they reported on these issues and Target ignored the feedback. PCI does not do a good job forcing assessors to consider residual risk (the way accounting firms have to). Even if they did, then allowing QSACs and P's to opine on residual risk would be a mismatch in skills to activity being expected of the QSAPs.

Going back to design, what if the process and controls are not designed correctly, then who is responsible for determining that and what impact would that finding have? Right now the consumer and AG's are the option for accountability as there is no regulatory function in place to adequately manage this situation when it comes to consumer protection. 
Bprince
100%
0%
Bprince,
User Rank: Ninja
5/5/2014 | 1:13:02 AM
Re: Pivotal moment for "due care"
Seems like the bare minimum of due care would be compliance standards and proof that internal policies were followed. But does there need to be more, since as the Businessweek article points out there were signs that were missed? What if your internal policies aren't strong enough to prevent a breach? Should there be a law that says if alert X is triggered due to an unuauthorized act and an organization doesn't take action Y to remediate it they are liable? That could be very difficult to do right.  

 
jjthomps
100%
0%
jjthomps,
User Rank: Apprentice
5/2/2014 | 6:43:58 PM
Re: Pivotal moment for "due care"
Marilyn,

When I said "that would shape precedent, case law", I was saying that the pending legislation against Target, and the resultant decisions by the court, will shape case law moving forward about standards of due care and negligence. Please see case 14-CV-2069 Trustmark National Bank v. Target and Trustwave. As this is pending, we need to wait and see the outcome as well as the other suits being filed by state AG's. 
Marilyn Cohodas
100%
0%
Marilyn Cohodas,
User Rank: Strategist
5/2/2014 | 4:54:30 PM
Pivotal moment for "due care"
Thanks for the blog , J.J. I'm curious to learn more about the legal precedent you mention. Is there litigation pending against Target based on the due care standard? 
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading December Tech Digest
Experts weigh in on the pros and cons of end-user security training.
Flash Poll
10 Recommendations for Outsourcing Security
10 Recommendations for Outsourcing Security
Enterprises today have a wide range of third-party options to help improve their defenses, including MSSPs, auditing and penetration testing, and DDoS protection. But are there situations in which a service provider might actually increase risk?
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-4807
Published: 2014-11-22
Sterling Order Management in IBM Sterling Selling and Fulfillment Suite 9.3.0 before FP8 allows remote authenticated users to cause a denial of service (CPU consumption) via a '\0' character.

CVE-2014-6183
Published: 2014-11-22
IBM Security Network Protection 5.1 before 5.1.0.0 FP13, 5.1.1 before 5.1.1.0 FP8, 5.1.2 before 5.1.2.0 FP9, 5.1.2.1 before FP5, 5.2 before 5.2.0.0 FP5, and 5.3 before 5.3.0.0 FP1 on XGS devices allows remote authenticated users to execute arbitrary commands via unspecified vectors.

CVE-2014-8626
Published: 2014-11-22
Stack-based buffer overflow in the date_from_ISO8601 function in ext/xmlrpc/libxmlrpc/xmlrpc.c in PHP before 5.2.7 allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code by including a timezone field in a date, leading to improper XML-RPC encoding...

CVE-2014-8710
Published: 2014-11-22
The decompress_sigcomp_message function in epan/sigcomp-udvm.c in the SigComp UDVM dissector in Wireshark 1.10.x before 1.10.11 allows remote attackers to cause a denial of service (buffer over-read and application crash) via a crafted packet.

CVE-2014-8711
Published: 2014-11-22
Multiple integer overflows in epan/dissectors/packet-amqp.c in the AMQP dissector in Wireshark 1.10.x before 1.10.11 and 1.12.x before 1.12.2 allow remote attackers to cause a denial of service (application crash) via a crafted amqp_0_10 PDU in a packet.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Now that the holiday season is about to begin both online and in stores, will this be yet another season of nonstop gifting to cybercriminals?