[Dailydave] APT

Tue Mar 11 16:14:02 EDT 2014

As a defender working in the *real* world, I have to say that it sounds like a lot of what Richard is saying comes from a somewhat utopic view of what playing defense is really like and I’d like to counter some of his statements. 

"He emphasizes the role of encryption to defeat many defensive tools, but ignores that security and information technology architects regularly make deployment decisions to provide visibility in the presence of encryption.”

While this is true, what percentage of companies or organizations actually do SSL inspection? I’ll go out on a limb and say 10%, but that is probably way too high.

"He ignores or is ignorant of technology to defeat obfuscation and encryption used by intruders.”

Again, yes this technology exists, but how many use it? It doesn’t count if nobody uses it, and in the real world not a lot of people do.

"He says "archiving large amounts of traffic is insanely expensive and requires massive analytics to process," which is wrong on both counts. On a shoestring budget my team deployed hundreds of open source NSM sensors across my previous employer to capture data on gateways of up to multi-Gbps bandwidth. Had we used commercial packet capture platforms we would have needed a much bigger budget, but open source software like Security Onion has put NSM in everyone's hands, cheaply. Regarding "massive analytics," it's easier all the time to get what you need for solid log technology. You can even buy awesome commercial technology to get the job done in ways you never imagined.”

First of all, how big was that team, and how big are defensive teams usually? Second, the sad truth is that not a lot of companies are going to go for a large open source deployment. Third, it’s not just about having the technology, it’s about having people with the skillset required to analyze all that data. A lot of defensive teams are made up of ex network- or firewall admins, and not a lot of them have that skillset.

"Third, and this is really my biggest issue with Dave's post, is that he demonstrates the all-too-common tendency for security professionals to constrain their thinking to the levels of tactics and tools. What do I mean? Consider this diagram from my O'Reilly Webinar on my newest book:”

With all due respect Richard, I think I’ll pass.

To conclude, while a lot of what Richard is saying is technically true, it doesn’t mean that it is the truth for everyone. Just because something is possible and that Richard was privileged enough to get to do it (and I’m sure he did it well), doesn’t mean that it is possible for everyone or even most. The truth is that defense in a majority of cases means default configured security systems that take care of themselves, with a defender taking a peak at the console every now and then between meetings. If ever.

No one would be happier than me (well, maybe Richard) if we were actually able to do all the cool things, but unfortunately that’s not the case. Maybe one day, but for now attackers have the upper hand.

/Andreas

On 11 mar 2014, at 17:09, J. Oquendo <joquendo at e-fensive.net> wrote:

> On Tue, 11 Mar 2014, Dave Aitel wrote:
> 
>> So the thing about being advanced enough is that you don't really have
>> to be persistent in any normal sense of the word. Nobody has pointed out
>> how the first stage of the NSA shellcode (as leaked by "backgrounded by
>> the Constitution and definitely not at all a narcissist" Snowden) just
>> avoids executing anything on systems protected by HIPS. Imagine if you
>> were so good at your job you could ignore targets you already had
>> execution on if you felt even a /little bit/ queasy about their defense.
>> 
>> Look, Richard Beitlitch thinks I don't know anything about "Strategy"
> 
> "I never read any treatises on strategy... When we fight,
> we do not take any books with us." Mao Tse-Tung
> 
> Working in an MSP/MSSP I *have* deployed defenses, working
> in the malware analysis arena, I *know* about encryption
> tactics used by bad actors, performing network analysis
> functions for over 14 years (http://seclists.org/incidents/2000/Aug/278)
> I think I can qualify myself to chip in my .02.
> 
> I will counter-argue some of Mr. Bejtlich's points.
> 
> 1) Providing visibility. This all depends on the environment
> sometimes an architect CANNOT decrypt traffic without red
> tape (regulatory controls, HIPAA, Sox, whatever). While
> we'd LIKE to decrypt, we also have to put privacy at the
> forefront as well depending on where the guidance is coming
> from especially when CPOs (Chief Privacy Officers) gripe
> and moan about privacy. 
> 
> While on the network and security scope, we'd ALWAYS love
> to see what is occurring, the reality is, every network
> differs PERIOD.
> 
> 2) "technology to defeat/decrypt obfuscation" is a moot
> point. If things were so grand, we wouldn't have instances
> of "advanced persistent" anything on a network for days,
> weeks - wait oh look here... YEARS - on end. All we have
> is what is visible. There are NOT enough resources in ANY
> company to weed out the anomalies, "sic" a malware analyst,
> create IOCs in real time. Not even close to "near real time"
> so we oft rely on the security vendors and researchers to
> tell us: "something is off with these connections, these
> applications, etc." But against REALLY good threats? This
> is not happening. You *WON'T* see them in your honeypots,
> NSMs, IDS', IPS', ITS' (because who doesn't love Intrusion
> TOLERANCE Systems). Obfuscation via way of "hiding in plain
> sight" works a long way on the offensive side, which is
> how, and why, groups like the "Comment Crew" likely pervaded
> in orgs for so long.
> 
> 3) Archiving, and analyzing network traffic is looking for
> a needle in a haystack. You're playing the signature game
> again. You're either ignoring the known knowns, weeding
> out anomalies. You can do it modularly (deploy NSM to say
> a segment, to make it easier), but its unfeasible to pretend
> for a minute that you'd be able to pick a needle out of a
> haystack and isolate someone INTENT and ADVANCED. 
> 
> So you go out on an NSM spree, deploy hundreds, heck even
> thousands of instances. Isolate the knowns, ignore them,
> and look for the discrepancies. Guess what? What are you
> going to do in say the case of Target where you MAY have
> ignored a "known" (third party vendor). What are you going
> to do in the following scenario:
> 
> Company --> data --> internet --> EBay
> 
> In this scenario, from your company, someone is visiting
> the LEGITIMATE EBay site. However, an attacker decided to
> shove in spliced bits of data with those connections,
> because somewhere along the lines, he/she is sniffing
> the connection, to compile spliced data. Think your NSM
> skills are going to be able to piece that together? I can
> assure you it won't.
> 
> Program Goals and "Strategies" from my perspective can be
> combined since they rampantly change no matter HOW you
> want to cut it. CISOs depend too much on book level nonsense
> and often ignore those in the trenches. Those who see the
> attacks, those who PERFORM the attacks. This is the reason
> why so many companies get themselves "owned." You can
> strategize all you want, and I go back to:
> 
> "Strategies too often fail because more is expected of them
> than they can deliver" 
> 
> http://www.economist.com/news/books-and-arts/21588834-strategies-too-often-fail-because-more-expected-them-they-can-deliver-why
> 
> Maybe I missed something on the "Drinking the Cool Aid"
> thread, with "strategies" or even tools and tactics. I
> read it to be some form of a starting point for counter
> and defense. On Bejtlich's writings, it goes off into a
> "this is what worked for me... How I strategized" which
> *may* have worked for him, but should not be an umbrella
> for defensive anything. I'd run circles around the entire
> concept of what he perceives as defense. IN PLAIN sight.
> 
> 
> -- 
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
> J. Oquendo
> SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM
> 
> "Where ignorance is our master, there is no possibility of
> real peace" - Dalai Lama
> 
> 42B0 5A53 6505 6638 44BB  3943 2BF7 D83F 210A 95AF
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF
> _______________________________________________
> Dailydave mailing list
> Dailydave at lists.immunityinc.com
> https://lists.immunityinc.com/mailman/listinfo/dailydave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.immunityinc.com/pipermail/dailydave/attachments/20140311/43558dad/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.immunityinc.com/pipermail/dailydave/attachments/20140311/43558dad/attachment-0001.sig>