<p dir="ltr">Good post. Well written, Clear, many agree of the contents. I have a Question, probably Basic. If everything is encrypted how the poor sysadmin can do some Basic troubleshotting ? I have to be an hacker and doing an mitm for this ? I Dunno</p>
<div class="gmail_quote">Il 22/feb/2014 16:28 "Dave Aitel" <<a href="mailto:dave@immunityinc.com">dave@immunityinc.com</a>> ha scritto:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<table cellpadding="2" cellspacing="2" border="1" width="100%">
<tbody>
<tr>
<td valign="top"><i>Security Technology</i><i><br>
</i></td>
<td valign="top"><i>What am I blind to?</i><i><br>
</i></td>
<td valign="top"><i>Benefits</i><i><br>
</i></td>
</tr>
<tr>
<td valign="top">Email Gateway (FireEye, TrendMicro, etc.)<br>
</td>
<td valign="top">Best practices for sensitive information
recommends endpoint to endpoint encryption such as
GPG/PGP/SMIME. These completely blind any email gateway.
Virtualization based gateways trivial to detect and evade by
malware; signature based gateways trivial to bypass by being
0day.<br>
</td>
<td valign="top">Can catch things headed inbound before they
are on your network - and directly effect the way the
majority of attacks happen.<br>
</td>
</tr>
<tr>
<td valign="top">Network Sniffers (Netwitness, Tenable PVS,
IDS, IPS)<br>
</td>
<td valign="top">Proper networks, even internally, should use
IPSEC, HTTPS, or other cryptographic technology, which
completely blinds these things. Archiving large amounts of
traffic is insanely expensive and requires massive analytics
to process (which makes you blind in retrospect even if you
have the data, since you can't find it or draw conclusions
off it). High level of false positives since you cannot
account for host configuration when on the network when not
correlated properly with SIEM (which cuts into your trust of
these products).<br>
</td>
<td valign="top">Forces attackers to learn how to tunnel into
innocuous traffic, which is a very good thing.<br>
</td>
</tr>
<tr>
<td valign="top">Network Scanners (Qualys, Nessus, Rapid7)<br>
</td>
<td valign="top">Authenticated scanners are a bad practice
(imho), but non-authenticated scanners have huge amounts of
false positives. Continuous monitoring required to capture
devices as they pop up and down on the lan, but proper
network segmentation makes this extremely expensive. Again,
with massive amounts of scan data comes massive
responsibility for purchasing storage and analytics (aka,
it's expensive). IPv6 makes scanning much more difficult as
well. Likewise scanners can interfere with the ability to do
active response.<br>
</td>
<td valign="top">Continuous monitoring allows good situational
awareness of when assets are placed on your network in a
historical way that can be very useful later.<br>
</td>
</tr>
<tr>
<td valign="top">WAF<br>
</td>
<td valign="top">Might protect you from input validation
vulnerabilities without having to change source code and
without impacting customer experience. But then again, might
not. No way to know! Keeps life exciting.<br>
</td>
<td valign="top">Makes attackers uncertain if their attack
will work. Directly addresses your ability to rapidly put
defenses in place in one of the most vulnerable areas of
your network (web apps).<br>
</td>
</tr>
<tr>
<td valign="top">Exploit Scanners (CORE, Rapid7, Immunity
CANVAS)<br>
</td>
<td valign="top">Might crash stuff. Using EMET or other host
protection measures (ACLs, NAC, AV, etc.) can cause high
false negative rates.<br>
</td>
<td valign="top">Can often surprise you with how limited your
host protection really is.<br>
</td>
</tr>
<tr>
<td valign="top">Modern HIPS (AV, Mandiant/Crowdstrike/El
Jefe) <br>
</td>
<td valign="top">Reputational systems blind to powershell or
AutoIT. Once attacker is on the box, they can of course turn
the software off.<br>
</td>
<td valign="top">Attacker has to spend a lot of time writing
things that turn off HIPS.<br>
</td>
</tr>
</tbody>
</table>
<br>
So one exercise I was going through in my head yesterday during this
little mini-con is trying to figure out what the "Security Best
Practices" were that would invalidate any given product category.
These are usually pretty simple. Just as an example: Sniffing
products are invalidated by proper network crypto, and scanners are
invalidated by proper network segmentation, etc. <br>
<br>
Just something to think about in the product whirlyhaze that is RSA.
It doesn't mean you shouldn't buy one of these product categories,
but knowing where you are blind is a good thing, even if it sounds
very negative for California.<br>
<br>
-dave<br>
<br>
<br>
</div>
<br>_______________________________________________<br>
Dailydave mailing list<br>
<a href="mailto:Dailydave@lists.immunityinc.com">Dailydave@lists.immunityinc.com</a><br>
<a href="https://lists.immunityinc.com/mailman/listinfo/dailydave" target="_blank">https://lists.immunityinc.com/mailman/listinfo/dailydave</a><br>
<br></blockquote></div>