ShackF00

Writing a book has put a serious crimp in my time for many other things, blogging included. I was warned, I know. I’ll quit bitching now.

I did a presentation with Alex Hutton and Rich Mogull yesterday to kick off 2012 at IANS, and we talked about a lot of major trends and themes in our space today. These ranged from mobile security and “consumer-ization” of mobile devices to cloud security, advanced threats, blah blah blah. We made no predictions, since all the same stuff from last year is still on the plate. Well, I guess we could have predicted that. During one of our discussions, focusing on advanced threats and incident response, Rich made a really good point (he does that). We were discussing the slowly dawning realization that we WILL be breached, and need to focus on detection and reaction more than anything at this point. At some point in the conversation, Rich said our prevention tools and processes just need to “fail gracefully” and lead us into detection and response mode. I started thinking about this, and I think the concept holds for a lot of things we do.

First, and probably most obviously, there’s code. Whether it’s the Rugged Manifesto started by Josh Corman and Dave Rice, or just general coding best practices, it stands to reason that sometimes people will do things with your function calls, input vectors, and the like that you did not plan for or intend to happen. Invariably, this will lead to some unintended consequence. Now, to be clear, sometimes that consequence is really nothing. Nada. It just pretends nothing happened and moves on. But more often than not, something doesn’t work. And the question, of course, is what happens then? Do you post a happy little message to someone’s browser announcing that Microsoft SQL Server 2005 could NOT execute SQL query X? Hopefully not. Worse yet, you just cough up *really* sensitive data.

Another classic preventive control is antivirus. It fails. A lot. And then what? What other controls do you have to allow A/V to fail gracefully? Behavior-based detection at the host or network? Protocol-aware firewalls that can spot HTTP/HTTPS C&C traffic? What about your security awareness program and email spam/malware controls? When they fail, people click on links. And then bad things happen. What controls can catch that (aside from A/V)? Do you have more innovative controls for your browsers, etc. like Invincea’s browser protection?

The list could go on and on, but I think a shift we need in security overall is to start thinking in terms of failure scenarios. Every single solution/control/process should be viewed in context of the others, really more like a “controls ecosystem” than any one specific point control. This is somewhat related to the age old “Defense in Depth” concept we’ve touted for years, but it goes beyond that, I think. We’re pretty good at “if-then” analysis for controls in security, it’s the kind of analytical process many of us enjoy. Let’s turn it around though, and start thinking “if-then” in the negative sense.

Fail gracefully, my friends.

And NO, I am not talking about the great folks at Offensive Security. I KNOW they exist.

I had some great commentary and discussion on my last post, “Doom, Gloom, and Infosec“. Jericho rightly pointed out the ever-popular Charlatans page at Attrition. This could definitely lead some to feel a little despondent or at least irritated in this field. Asshats have a way of doing this. Wendy at 451 had some interesting thoughts, too, as did a few other sites and folks. My friends at the Infosec Daily Podcast, Rick and crew, had a discussion about the post that really got me thinking, though.

In my post, I list some general ideas of reasons why infosec might suck. These were totally off the top of my head, based on a lot of conversations I’ve had in the last few years with people in all walks of the industry (consultants, company and end user practitioners, CISOs, trainers, you name it). The ISD crew talked about them, and made an interesting statement – “as offensive folks, many of these don’t apply to me|us”. The premise being that folks playing DEFENSE (responders, intrusion analysts, firewall folks, etc) have a worse time of it. This is likely true. But the point that stuck with me was the concept of “offensive infosec” roles. The assumption, of course, is that this means vulnerability assessment teams, red teams, pen testers, and so on. And I get what they are saying. However, I want to refute the concept of “offensive” vs. “defensive” security staff. I don’t think that’s realistic. Reason? Offense really exists for one reason only – to inform defense. In my mind, this really means we’re ALL defense. We just accomplish our defensive strategy and tactics in different ways.

I am a pen tester and someone who enjoys “breaking” as well as “fixing”. Would “breaking” fit into a security philosophy if not for the perceived benefits to “fixing”, though? I’m not trying to blow this all out of context, I know exactly what the ISD dudes meant, but it just got me thinking – when we classify ourselves that way, we may in fact be doing ourselves a disservice as a whole. Interested in your thoughts.

I’m perennially happy. I am almost always in a pretty good mood, despite my inherent sarcasm and less-than-politically-correct approach. But I get the impression that many in infosec are not. Everyone is different, and I don’t want to stereotype, but I do run into a lot of gloomy folks. Why is the infosec profession so unhappy in general? I closed out the IANS forum in Chicago today (which ROCKED, by the way, just too much awesomeness in CHI to contain), and Ron Ritchie made some comments that I thought were pretty spot-on in his closing thoughts. He mentioned a few good reasons to be in infosec, and I’ll list some below, including his:

Reasons infosec rocks:

• Money is good! (Ron)
• We have tons of interesting things to work on! (Ron)
• We bring real value to our organizations! (Ron)
• We can actually detect and prevent crime in some cases!
• We have one hell of a solid career path, in general!

I’m sure this all sounds good. High-fives all around! Hmmm. Wait. We’ve still got that “Sad Panda” problem. So there are surely some negative aspects to infosec as well. What are they? Based on my experience as a practitioner, consultant, trainer, and general curmudgeon (albeit a pretty jolly one), a few things I can think of:

Reasons infosec sucks:

• People ignore us, hate us, or perceive us as roadblocks. Or all three.
• Infosec never seems to be “done”, ever. Always an ongoing endeavor.
• The landscape in infosec changes so rapidly it’s difficult to keep up.
• Overall, infosec is “hard”.
• Related to the first point in this list, we may feel “at odds” with business units and IT organizations.
• There’s a general sense of “futility” – we can’t “win”.
• Our career paths are wack – do we really have any respect?

Surely I’m missing things here, likely both good and bad. However, being the “glass half full” kind of cat that I am, I am inclined to think the list of “things that rock” far outweighs the list of things that suck. Seriously! What are we so worked up about? Lots of jobs are much drearier than most of ours. And people make the best of them, get the paycheck, and go have a life outside of work. I won’t even try to speak for everyone here, that’s crazy, but I see a lot of people internalizing their positions and the issues they see in their jobs, when they should really be trying hard to leave that stuff at the office. Infosec is not a calling. There, I said it. It’s not. It’s not a crusade. It’s not the end of the world if a security control fails, or an employee gets phished, or you lose some data. Sure, it SUCKS and all, but deal with the stress of the moment and move on! Life is short. Enjoy the good aspects, deal with the bad, and most of all, get some hobbies that do not involve a computer, security, or anything else related to infosec. I love this field with all my heart, but I recognize that this is not sustainable. So…why are folks so burnt out? What am I missing here?

As most of you know, I spend a significant amount of my time with virtualization technologies and discussing virt security, with a sprinkling of cloud thrown in. Given the recent updates to VMware’s vSphere product line, I decided to post a simple summary of the available security features and capabilities in the product, namely in vCenter and ESXi v5. These are in no particular order, and I’m not striving to be the most thorough in any of these. For those of you looking to get a fairly quick overview, as well as some key pointers and additional resources that I’ve found useful, this should be helpful.

1. A New ESXi Firewall: Although many would argue that the firewall capabilities built into previous versions of ESX were, umm…less than adequate, we all got a real shock when ESXi didn’t even give us THAT much. So…now we’ve got one. Albeit a STATELESS one (aaargh!) For those of you used to managing the ESX firewall through the vCenter management console, you’re in luck – the location is the same, and the general layout is similar, as well. Simply navigate to Configuration –> Security Profile and you’ll see it right away, as shown here:

There are some new features to be aware of. First, you can now configure incoming and outbound TCP and UDP ports, which is a plus. By selecting Properties, you can choose existing rules and modify the ports, as well as IP addresses and subnets that can connect, as shown here:

You can also configure the firewall rules at the ESXi Shell, or via SSH. This is where you’ll likely want to configure any specific rulesets that require definition of custom services. There are several options for doing so. The first is to modify the existing XML files at /etc/vmware/firewall/service.xml and /etc/vmware/service/service.xml. These files contain information on existing services that are recognized on the host platform. Another option is to define new and customized files in the /etc/vmware/firewall folder. You’ll need to define any specific services you want, as well as the direction (inbound/outbound), protocol, ports, etc. An example of a service called (what else) Shack is shown here:



To ensure this gets included in the ruleset, run the command esxcli network firewall refresh. To see the firewall list of services, you can then run the command esxcli network firewall ruleset list. This is shown in the next screenshot:

Now, you can start tweaking things more seriously by ensuring not everyone can connect to these services, and specifying the IP addresses that *are* allowed. The next screenshot includes those commands:

A great list of the new esxcli firewall commands can be found at VMware’s site here.

2. Enhanced Logging: ESXi v5 has a different, more granular set of Syslog capabilities and files than previous versions. TCP, UDP, and TCPS (SSL)-based logging are all supported, along with multiple log hosts, built-in size and rotation control, etc. For admins and security/audit folks who have hunted all over the place for log and config files and tried to tweak settings for them in the past, the latest version will likely be a Godsend. The configuration for logging is broken into several components. The default syslog config file is called /etc/vmsyslog.conf, and contains minimal information by default. Individual files for specific log types can also be found in the /etc/vmsyslog.conf.d folder. One of these files may look like the following:

Modifying log settings can be done with the esxcli command set. The following are some simple examples:

esxcli system syslog config logger set –id=fdm –rotate=20 –size=2048
This command will set “fdm” logs to rotate up to 20 cycles, with a maximum log size of 2048 KB.

esxcli system syslog config logger list
This command will list the various log types on the host itself.

esxcli system syslog config set –default-rotate 20 –loghost tcp://syslog1.daveshackleford.com:514,ssl://syslog2.daveshackleford.com:514
This command sets the rotation default to 20 for all log types, and sends them to two remote log hosts using TCP and secure TCP protocol implementation

3. Host Image Profile Acceptance Levels: This is a sort of “integrity level check” for VMware Installation Bundles, or VIBs. Four levels are available that range from very strict (VMware Certified) to downright promiscuous (Community Supported). This can be configured through a host’s Security Profile in vCenter:

4. Other stuff: There are plenty of other security features in ESXi and vSphere in general, not all of which are brand spanking new in v5. v5 does have improved MIB support for SNMP v2, which is an improvement for monitoring hosts. v5 does force you to set a root password prior to accessing any sort of console. Native integration with Active Directory, LDAP, and Kerberos is built-in, and IPSec is natively supported for all 14 organizations using IPv6. The list goes on. Here’s a few more GREAT resources that you should familiarize yourself with:

• VMware ESXi v5 Security eBook
• Eric Siebert’s Righteous List of vSphere 5 links
• VirtuallyGhetto’s esxcli reference

There’ll be plenty more coverage of ESXi 5 and vSphere in general soon as more people start adopting these versions. With that will come more security guidance, to be sure. In fact, Paul Henry, Rob Vandenbrink, and I are updating our SANS course that will cover this and other topics in much more depth, and we’re looking to run this late this year and in January: SEC579 course site.

I have noticed a trend in the infosec community over the past few years. A new idea or concept emerges, a few “thought leaders” espouse or eschew the idea, and many sort of “go along” with the “yes” or “no” mentality. Sure, there’s a bit of debate, but it seems to be largely confined to a similar group of rabble-rousers and trouble makers (of which I am one, unabashedly). Overall, though, here’s the rub: There are almost no security absolutes. Aside from some obvious things (shitty coding techniques, the use of WEP, hiring Ligatt Security to protect you, etc)…everything is in the gray area.

Let me say that again: There is no black, there is no white – only gray. Why? Because each case is different. Every company, every environment, every person and how they operate, etc. Many decry the buzz-laden overhyped acronym technologies like DLP. There are companies that are getting immense value out of DLP today. So no, it’s not just crap. What about compliance? Plenty of organizations see it as a headache, sure, but many are really benefiting from a structured approach and some sort of continual oversight or monitoring. So again, no absolutes. Some other examples, just things I have observed through consulting, being a practitioner in end user orgs, and teaching, as well as just having debates on various topics:

• Security awareness: Some would argue security awareness programs are beneficial. If even 5 people change their behavior to be more security-conscious, then it’s a win, right? I recently argued that these *traditional* programs are worthless, and speculated that building security in is a better option. A guy I like and respect a lot, Ben Tomhave, argued that I’m totally off base, and connecting people to the consequences of their actions is a better move. Who’s right? Really, there’s a very solid chance we both are. One organization may take a draconian lockdown approach, others may take the “soft side”, but in reality, some of both is probably what’s needed. A great debate, and one that’s likely to continue for some time.
• Metrics: This is another area where people tend to have wildly polar beliefs. Metrics rule! Metrics suck! Those that have latched onto the Drucker mentality that you cannot manage what you cannot measure largely fill the former camp, those that are just trying to keep their heads above water often say metrics are a waste of time. I’ve actually changed my position on metrics a few times – for me, it’s one of those areas that I just can’t draw a good bead on, and thus it falls squarely into the gray. My friend Alex Hutton is a huge proponent of metrics, and worked hard to overhaul this year’s Metricon conference. Alex believes in metrics, and he’s a smart dude. Many others have argued we’re trying desperately to “fit” security into business, and it’s a round hole / square peg issue. Another tough one – what do we measure? How do we do it? What are the tangible benefits? On the other side, if we DON’T measure things, how do we have a clue what is going on?
• Pen Testing: Pen tests are awesome. Wait, no, they are a total waste of time. But we need them for compliance?! And yet another gray area emerges. I do a lot of pen tests. I would love to think they have value when I do them. But I’ve seen plenty of cases, and customers, that get them performed just to check a box for compliance. So what’s the answer? Hmmmm.

This list can go on and on. But infosec is such a subjective area, I think we all have to take a step back sometimes and realize that our passion and desire to “get things fixed” usually has the caveat that one size almost never fits all. I am guilty of this. I think many in the “echo chamber” are sometimes. The pendulum will swing one way, then another, but almost always settles somewhere in the middle…the gray area. I’m going to try harder to be more open-minded, and understand other points of view, even on topics I feel passionate about. Sounds like a New Years resolution, only in August…I know. But who puts a damn time frame on these things!? They surely must be wrong.

I don’t mean to offend anyone with the implied language of this post, or the image at left. But there’s no more apt way to describe the fundamental concept of this message. Imagine your users being totally, completely honest with you when you talk about the need for security. In a world not colored by political correctness and “business etiquette”, many of them would probably tell you (regarding security): I Don’t Give A F***. Unfortunately, whether they really articulate this or not (likely not), there’s a very solid chance that this is exactly what your general user population is saying to you and your beloved security policies. Gasp! But…but…(sputter)…don’t they read the NEWS?! Don’t they know they’re rapin…errrrr, HACKING EVERBODY OUT HERE!?

Well, we’ve all known for quite some time that, in reality, the hardest job in infosec is changing people’s behavior. When someone sends your users an email with an attached file or link that purports to show them the most incredible dancing bear they have ever seen, or the funniest caption with a cat picture EVAH, guess what happens? Yep. They click. Happily. Facebook? There they are! Downloads? PDF files? Flash games? Yes, yes, and YES. YES! Connecting to wireless ANYWHERE is NO PROBLEM. They want iPads! They want iPhones! They want Droid devices! Their own computers! And this is not going to get better, or go away. What’s my point? Well, it’s opinion time:

Traditional security awareness programs are useless. Give them up. Do it now.

Trying to get people to change how they do things is futile. You’ll convert a few, sure. But most people do not think like us. They will not take 2 extra steps or endure a nagging popup asking “Are you sure?”. In fact, they’ll work HARDER to find a way to circumvent your security than they would have worked just adapting to the security. Why? It’s human nature. So I say we toss this concept of “Educate them, and they’ll come around”. Instead, let’s start doing something we’ve bantered about for years. Let’s build security in, and accommodate the IDGAF mentality.

This means putting EVERYTHING into a “Default Deny” mode. Which means moving to application whitelisting. Some form of NAC. Lockdown of host-based and network-based ports on the firewalls and other access controls. Severe restriction of privileges. Yep, in other words – all that stuff we have discussed for quite a while. If we would just design this way, either in a green field scenario or when updating our environment, we’d be in better shape. How about a VM sandbox for any device people want to use to connect? That doesn’t print locally or access local files? I’d like to think we’ll stop this silly dance of “integrating into the business” at some point and come to the realization that we are fundamentally at odds with everyone else in the business ideologically, as it’s our job to RESTRICT things from happening. But if we design for IDGAF, and build it in so that we control the behaviors from the get-go, we just might reign in the users and their Pandora’s box of wacky, unsafe behavior.

With apologies to my friends and fellow panelists, this was too hilarious not to post:

So, I’ve spent the past month traveling all over the place, teaching and working with clients. I’ve taught two groups of people in the Middle East and Europe how to demolish Web applications. And it has been unbelievably fun, trust me. However, I’ve become attuned to something that I think could be a problem in the infosec space in the near future: most security people are not coders. Now, I’m not admonishing those of you that are network types. Hell, I’ve really got more of a network background than anything. But I know C++, spent some time writing it, can crawl through Java, and can whip up some Perl and Python when I need it. And JavaScript? Yeah, I got that too. What I’m finding, though, when working with infosec teams around the globe, is that there’s a bit of apathy toward coding skills. Well, you heard it here, folks:

90% of your security problems are related to bad code, somewhere down the line.

And being a paranoid type, and a bit of a worrier about THINGS, I fear we’re losing some Kung Fu. What does the next generation of security folks look like? From what I can see, they’re even LESS inclined to code. This, in my opinion, is a problem. The 2011 Verizon DBIR mentions malware and hacking, all of which usually comes down to a patch, a flaw, a vulnerability. A piece, or pieces, of bad code. The number of Web application-related flaws is going up and up, particularly XSS (SQLi is steady, even down a slight bit, yay). We need to understand code, period. Here’s a few reasons why:

• Your organization’s developers need help. Think convincing the rank and file of your organization that security is important? Coders are under WAY more pressure to deliver projects in many cases, so security almost always takes a back seat. Help them.
• You need to understand what vulnerabilities mean, and what exploits are doing. That may include a bit of code.
• You need to crank out some scripts, or write a few simple programs, during security assignments (particularly pen tests).

These are just some ideas to get you started. But if you’re one of those security folks that routinely convinces yourself that you don’t need any coding skills, you really need to develop some. This is, in fact, a career development thing. Forget that latest shiny vendor widget. Learn some fundamentals. Here’s a few suggestions to get you started if you are new to this, or maybe even just rusty:

• Teach Yourself C++ in 24 Hours: This one is a great refresher if you’ve been away from code for awhile. Or a good intro to object-oriented programming.
• Python Programming for the Absolute Beginner: A *great* start in Python. A little basic, so you’ll want to expand, but this is hard to beat for beginners.
• Programming Python: Once you’ve finished the first two, get this. It rocks.
• Classic Shell Scripting: A killer fundamental book on shell scripting. Comes in handy a LOT.
• Wicked Cool Shell Scripts: They are, in fact, wicked cool. More importantly, you’ll learn to think outside the box. And that counts a LOT in security.

There’s plenty more. I have books on Ruby, Perl, and lots of other languages. Pick one you like! These are just some that are easy to work with and may help you ease back into the world of programming. I, for one, am not a talented programmer, and never claim to be. But I can pull it off, and I *get* code. There’s a solid chance you need to, as well.

Earlier this month in NYC, my friend Marcus Ranum and I were having dinner and drinks after a day at the IANS forum. Marcus, in a lighthearted mood, posed the following question to me:

A fight breaks out between giant robots, pirates, and ninjas. Who wins?

We had a fun and spirited debate about this, and laughed at the sheer ridiculousness of the question itself – a pointless conversation, but fun, to be sure. The problem is, we’re having a lot of the same kinds of conversations in infosec right now.

Recently, my friend Josh Corman posted an article on CSO Magazine’s site entitled “The rise of the chaotic actor: Understanding Anonymous and ourselves”. As I would expect (coming from Josh), it is interesting, well-written, and insightful. It’s also totally, completely unimportant. Let me say that another way: IT’S A WASTE OF %*&^$ TIME. Now, lest you get the impression that I am bashing Josh, please know that I am not. I count him as a friend, he’s incredibly smart and talented. In fact, his Rugged Software project is one of the best, and likely most important, efforts underway in the infosec industry right now, and needs all the support it can get. But this? Drivel. And no, it’s not the content that chaps me. Not at all. Although, I must say, the use of D&D references crosses even MY boundary of geekiness acceptance.

Nope, not the content. What, then? The thing that pisses me off about this, and lit a fire under my ass yesterday, is that Josh, and CSO Magazine, put this out there with the disclaimer that this was “important”. Folks, it is not. It’s not because this kind of input is the equivalent of my conversation with Marcus – a watercooler discussion point, an anecdote, a thing to have a short chat and discuss casually – NOT something that will really change the fact of what we are dealing with. And what we are dealing with is the same problem we’ve had for a while now, in my opinion – too much blah blah blah, not enough elbow grease security.

I don’t blog a whole lot. I spend my time in a breakdown that consists of about 30% teaching people to fix shit (sometimes by breaking it first), 60% actually fixing shit (or breaking it first), and 10% speaking about these things. That is 10% of my time spent proselytizing or (hopefully) educating in some way, usually on a technical subject. What I see a lot of out there is people wasting their cycles debating shit that DOES NOT HELP ACTUALLY SECURE ANYTHING. This is not a good trend, folks. We need more do-ers, people who can put hands to keyboard and actually get some security done.

Josh and I had a spirited debate about this on Twitter. He reminded me of the Plan-Do-Check-Act cycle, and said we need to Plan before we Do. He’s right, of course. I’m not insinuating that. But this is not planning. This is mental masturbation. And too much planning, with too little doing, leads to “analysis paralysis” and that is a death-knell for your security program. I’d rather see a CISO who’s a former drill sergeant than one who is an endless pontificator of “what could be”. My friends Alex Hutton and Mike Dahn made small points that are valid – Alex reminded me that not all work is purely hands-on technically, as he and his team at Verizon compile metrics and risk data that all of us rely on. Totally valid, and that IS important. Mike nudged me and said that theory and practice must go together like PB and J (great analogy), and certainly there’s some truth to that as well. But if you are ALL theory, or spend too much time there, you don’t get around to the doing. And there’s a lot that needs doing. Check this stat from Alex and team’s latest Verizon Data Breach report:

Wow. If we spent just 10% of the time we waste on mental masturbation like “what do they want? who are they? are they nice people” kinds of crap on ACTUALLY hardening boxes, screening and pruning ACLs and FW rules, tuning IDS, performing sound vulnerability management practices, and actually fixing our code, we’d be in hella better shape. Are these conversations fun? Sure. Do we need to really rethink our focus? Maybe. I personally do not care if Anonymous is a secret league of 1337 grandmothers from Poland, or whether they want to hack me for vengeance, political motivation, or just plain old theft. Nope. Don’t care. I just know I have adversaries, and I need to protect my sensitive data. That’s what I care about, and that’s what you should care about too.

A few months ago I posted a post-RSA note on “Change we can Believe in”. I had grown tired of all the whining in this industry about how we “need change”. Well, here’s a change for ya: Stop wasting your time on crap like this that is not impactful unless you are a state agency. Most of us just need to hunker down and fix some things.

I recently read Richard Clarke’s book Cyberwar. I was prepared not to like it, honestly – the whole “cyberwar” concept has been hyped pretty badly, and I wanted to read something on the topic quickly just to see what was out there. I won’t say the book was life-changing, by any means – but the guy makes some pretty good points, and his writing style is far less dry than one might imagine.

The most interesting point he makes in the book is one of asymmetry in information security overall. What this means is that certain organizations and countries stand to be hurt significantly more than others in the case of “cyberwar”, or really any electronic attack scenario. This takes a number of factors into account, including:

• Overall dependence on the Internet and networks in general
• Capabilities to wage electronic warfare, both offensive and defensive
• “Connectedness” as a country or entity

For example, a country like North Korea is actually a very dangerous adversary in the potential case of an electronic conflict. They have very little in the way of connected assets, so they’re less worried about the damage we could do to them. On the flip side, we are extremely dependent on networks and the Internet, and any attacks they launch could easily cripple many systems and capabilities we have. Although they may not have the total offensive capacity that the US has, they are at much less risk in terms of being impacted themselves, while still having a fairly competent offense. Not a good scenario. The same applies for countries like Russia and China – both stand to gain more than they lose, in all likelihood, especially given the current state of defensive measures for critical infrastructure like the electric grid.

Asymmetry is not a new concept in warfare theory, by any means. Nor is nonlinearity (basically think predictability of outcome based on input factors). However, I think there are some interesting points to muse about for all of us in infosec, not just those in the military. Our industry has been pissing and moaning about “change” for a while now, which I am definitely fed up with up (as this post of mine states pretty clearly). There are certainly things that would be NICE to see change – more focus on appsec, general computing users with a clue, less bullshit in general (read: APT). But overall, our problem is one of asymmetry – attackers have MUCH more to gain by attacking us, and really very little to lose based on a) current electronic crime law and precedent, and b) the fact that many of the attackers are in countries where they’re likely to never be found. In general, though, our best offense is a good defense. We can’t legally “hack back” and cause damage to attackers’ systems in almost every case. What we can control is the difficulty of hacking us. And that’s where we should focus our time, making ourselves less attractive as a target. You’re probably saying, “But Dave – that’s what we ARE doing.” Cool. Then what needs to change again, exactly