This is not a “black or white” issue though. I think there’s a lot of good happening in this space right now, and it all fundamentally comes down to the maturity of information security as a discipline. I’ve said this for years, and it bears repeating – this field is still really in its infancy, and has a long way to go. This post is just me observing the state of things, and I’ll list a few points that I think illustrate the good coming out of our field.

1. We are coming to the realization that we WILL be breached. This is a huge, fundamental shift in mindset that’s actually healthy, not redolent of defeatism. We have too much surface area to cover, not enough people and technology, and dammit, defense is HARD.
2. We are all risk managers and advisors. This does not mean  we WIN or LOSE. We assess and advise, and then we live with the damn decision whether we like it or not. That’s how business has worked, and traditionally those organizations that were more willing to take risks and stick their necks out were rewarded (or crushed). You can’t expect business people to change that mentality overnight. And we’re starting to figure this out.
3. A healthy offense can inform defense, and more and more organizations are figuring this out. And we’re actually getting better at it. Sadly, all the kids want to be superhax0rz, seems like defense is BORING. Maybe, but the truth of the matter is that most people aren’t cut out to be good superhax0rz, and without defense there would BE no offense. Let me say that another way. The only reason we do pen tests is to find holes and fix them. In other words, defense. So we’ve got a Yin and Yang deal going on here, and this is also becoming a healthy realization in more organizations than ever.
4. We’re becoming less tolerant of bullshit bureaucrats who spout “policy” and “governance” with no credible skills to back this up. Thank God. If you’re the boss (CSO/CISO, etc) and have no real technical skill, then block and tackle for your folks, then get the hell out of the way and let them make you look good. Still more “infosec politicians” than I’d like to see, but at least we’re learning to work around this issue.
5. We’ve realized the government is not going to help/save us. This may seem obvious to longer-term practitioners, but we’re basically on our own, and we’re just getting on with it.
6. We’ve got some hella smart new blood coming into this field. If we could stop being crusty, snarky ASSHOLES long enough to embrace them, we’d see the industry advance even faster.

I’m a  big fan of the work of Tim Ferriss. While I haven’t quite managed the 4-hour work week yet (more like the 84), the dude is smart and has no fear of saying what many of us just think. In Outside magazine’s July 2011 issue, while promoting his new book “The 4-Hour Body,” Ferriss describes his opinion on human motivations:

It pays not to be puritanical with incentives. Just look at what’s effective. We like to talk about reward, positive thinking, positive reinforcement. But the sad or useful fact of the matter is that shame, humiliation, peer pressure, financial loss – those things are all more effective.

There are so many corollaries to infosec in this statement it’s hard to know where to begin – the flaccid ineffectiveness of security awareness, repeated insane attempts to buy our way out of proper security process and tactics, and on and on. Here, though, I want to focus on the new and exciting realm of CLOUD SECURITY. There are numerous projects underway out there that are seeking to provide some degree of provider transparency. The most well-known include the following:

• The Cloud Security Alliance Security, Trust, and Assurance Registry. This is a voluntary effort on the part of CSPs, who can choose to answer all or most of the questions posed in the CSA Consensus Assessments Initiative (CAI) Questionnaire, as well as adhere to the controls listed in the Cloud Controls Matrix, from CSA as well.
• The Open Data Center Alliance (ODCA) provides guidance on standards, usage models, and other areas related to data center operations and cloud computing.
• The Cloud Standards Customer Council is focused on providing strategy and tactical changes and recommendations for cloud adopters.

There’s lots of discussion in the security community around cloud standards and “best practices” related to cloud provider practices, architecture models, and such. This will continue for some time, surely, but one of the most pressing issues has been getting CSPs to disclose how well they’re safeguarding assets and operating a security-savvy environment. To this effect, STAR is probably the most high-profile effort to date, where shiny, happy CSPs can proudly proclaim that they are awesome. I think this has some merit, but I think we need a different model. Coming back around to Ferriss’ quote, this doesn’t really address the most successful motivations we have as humans (and as organizations, by extension). I think it’s time for a “Wall of Shame” for CSPs who blatantly disregard security. How many CSPs would take security more seriously if they knew there was a provision in every contract stating that customers could publicly describe security failings at the CSP, and immediately move their data and systems elsewhere with no questions asked. I’m sure you’re saying “Yeah, right, Shack – on a cold day in hell”. OK, we’re not there, but I think we need to get away from the “chosen few” mentality of STAR, which to date, has very limited participation, and on to a more realistic model, especially for SMBs and specialized companies who need very vertical-specific SaaS offerings, for example. Do you think a small healthcare billing SaaS is going to offer themselves up for STAR? Uh, no.

While some efforts along these lines have started (the one that still have hopes for is Cloutage, although it needs a lot more community involvement), we need to thinking about this problem a little differently. No STAR listing, SSAE 16, SOC2 or 3 report, etc. will get us to a point where people know what to do and where to do business. Or in this case, where NOT to do business.

What does this have to do with infosec? My thoughts – we are really lacking a proper “long tail”. RSA is coming up soon – what will we see that points to real innovation in the space? I always tell people that I spend the majority of my time on the show floor at RSA roaming among the smallest, least flashy booths. The reason is that I’m always searching for that next trend or innovator that is doing something new or original. In a few cases, I’ve been rewarded – last year I saw a lot of “cloud” startups that were peddling Identity and Access Management (IAM) solutions. This space has a lot of growth, based on what we’ve seen in the last year. More often than not, though, you see a rallying cry of buzzwords. DLP!!! Cloud <insert term here>!!! And we all, of course, make fun of this with our usual, lovable snark. But snark only goes so far. At some point, we have to take a long, hard look at what we’re doing in security, and whether it’s working. Based on the breaches of the past 10 years, I think it’s safe to say that we’re not winning. Hell, I don’t even know that we’re SOLVING any problems, really.

Folks, we NEED a long tail. We need those organizations that are desperate to find unusual, different solutions that are not available at all right now. And we need small startups to provide them. Peter Kuper, a super-smart guy at In-Q-Tel who I love watching present, often gives talks about the lack of innovation and VC investment in security. His talks are amusing…and depressing. But we need that focus. One of our fellow security wonks in the space argued to me a few years ago that he was “really innovating” now that he was working at one of the biggest vendors. Bullshit. Big vendors typically buy their way to innovation. The question is – who are they buying? I encourage you all to pay attention to those tiny little booths in the dark corners of the Moscone Exhibit Hall at RSA 2012. And pray you see more of them.

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.

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?

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.

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.

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.