NYT covers China cyberthreat

Tue Feb 26 16:39:22 UTC 2013

I think it is safe to say that finding a foothold inside of the United
States from which to perform/proxy an attack is not the hardest thing
in the world. I don't understand why everyone expects that major
corporations and diligent operators blocking certain countries'
prefixes will help. That being said, you make a solid point to which
people should absolutely listen: applying an understanding of your
business-needs-network-traffic baseline to your firewall rules and
heuristic network detections (in a more precise fashion than just "IPs
from country $x") is a SOLID tactic that yields huge security
benefits. Nobody who cares about security should really be able to
argue with it (plenty of those who care don't will hate it, though),
and makes life _awful_ for any attackers.

On Tue, Feb 26, 2013 at 3:43 AM, Rich Kulawiec <rsk at gsp.org> wrote:
> On Thu, Feb 21, 2013 at 11:47:44AM -0600, Naslund, Steve wrote:
>
> [a number of very good points ]
>
> Geoblocking, like passive OS fingerprinting (another technique that
> reduces attack surface as measured along one axis but can be defeated
> by a reasonably clueful attacker), doesn't really solve problems, per se.
> If you have a web app that's vulnerable to SQL injection attacks, then
> it's still just as hackable -- all the attacker has to do is try from
> somewhere else, from something else.
>
> But...
>
> 1. It raises the bar.  And it cuts down on the noise, which is one of the
> security meta-problems we face: our logs capture so much cruft, so many
> instances of attacks and abuse and mistakes and misconfigurations and
> malfunctions, that we struggle to understand what they're trying to tell
> us.  That problem is so bad that there's an entire subindustry built
> around the task of trying to reduce what's in the logs to something
> that a human brain can process in finite time.  Mountains of time
> and wads of cash have been spent on the thorny problems that arise
> when we try to figure out what to pay attention to and what to ignore...
> and we still screw it up.  Often.
>
> So even if the *only* effect of doing so is to shrink the size of
> the logs: that's a win.  (And used judiciously, it can be a HUGE win,
> as in "several orders of magnitude".)  So if your security guy is
> as busy as you say...maybe this would be a good idea.
>
> And let me note in passing that by raising the bar, it ensures that
> you're faced with a somewhat higher class of attacker.  It's one
> thing to be hacked by a competent, diligent adversary who wields
> their tools with rapier-like precision; it's another to be owned
> by a script kiddie who has no idea what they're doing and doesn't
> even read the language your assets are using.  That's just embarassing.
>
> 2. Outbound blocks work too, y'know.  Does anybody in your marketing
> department need to reach Elbonia?  If not, then why are you allowing
> packets from that group's desktops to go there?  Because either
> (a) it's someone doing something they shouldn't or (b) it's something doing
> something it shouldn't, as in a bot trying to phone home or a data
> exfiltration attack or something else unpleasant.  So if there's
> no business need for that group to exchange packets with Elbonia
> or any of 82 other countries, why *aren't* you blocking that?
>
> 3. Yes, this can turn into a moderate-sized matrix of inbound and
> outbound rules.  That's why make(1) and similar tools are your friends,
> because they'll let you manage this without needing to resort to scotch
> by 9:30 AM.  And yes, sometimes things will break (because something's
> changed) -- but the brokeness is the best kind of brokeness: obvious,
> deterministic, repeatable, fixable.
>
> It's not hard.  But it does require that you actually know what your
> own systems are doing and why.
>
> 4. "We were hacked from China" is wearing awfully damn thin as the
> feeble whining excuse of people who should have bidirectionally firewalled
> out China from their corporate infrastructure (note: not necessarily
> their public-facing servers) years ago.  And "our data was exfiltrated
> to Elbonia" is getting thin as an excuse too: if you do not have an
> organizational need to allow outbound network traffic to Elbonia, then
> why the hell are you letting so much as a single packet go there?
>
> Like I said: at least make them work for it.  A little.  Instead of
> doing profoundly idiotic things like the NYTimes (e.g., "infrastructure
> reachable from the planet", "using M$ software", "actually believing that
> anti-virus software will work despite a quarter-century of uninterrupted
> failure", etc.).  That's not making them work for it: that's inviting
> them in, rolling out the red carpet, and handing them celebratory champagne.
>
> ---rsk
>

-- 
Kyle Creyts

Information Assurance Professional
BSidesDetroit Organizer