Rational Survivability

BOSTON MA, March 3 /PRNewswire/ - Rational Security 
BlogoDomination Corp. (RSBC) announced its intention 
today to continue the expansion of its consolidation 
strategy in the overly saturated Security Blog Market 
with the unsolicited hostile takeover bid and acquisition
of Alan Shimel's "StillSecure After All These Years 
(SSAATY)" Blog.

Christofer Hoff, CEO and Dark Overlord of the Security
Blogsolidation Dominion, today announced that upon 
release of SSAATY's recent earnings report showing a 
marked uptake in revenues with income hovering at over 
$18 per month, that RSBC would offer an unheard of 20X 
revenue multiplier in a stock-for-stock exchange and
an "I (heart) NAC" bumper sticker.

Alan Shimel, SSAATY's CEO/CTO/CMO/CIO/CFO/CSO refused 
comment other than to crisply and vehemently reject
Hoff's bid citing unacceptable terms; balking at only a 
20X multiplier, he pointed to Ken Xie's $4B sale of 
NetScreen to Juniper and suggested that Hoff "...get real if he expects this bulls**t
takeover attempt to warrant any sort of attention other than a trackback and lower 
Technorati rating."  

Art Coviello, CEO of RSA, complemented his prognostications from his recent 2007 RSA 
Security Conference keynote wherein he stated that there would there not be any 
independent security companies in 3 years, and Hoff's RSBC would "...subsume all 
security blogs within the same timeframe."  Mike Rothman was quoted as "...not giving
a crap because neither of them purchased a copy of the P-CSO."  

Hoff's response was just as shrill, "If Shimel doesn't pony up like the little bitch
that he is, I'll buy his lap dog Mitchell's blog instead."

Contact:

Christofer Hoff				Alan Shimel
CEO and Dark Overlord of the Security	CEO/CTO/CMO/CIO/CFO/CSO
Blogsolidation Dominion			StillSecure After All These Years
satanwithacheckbook@packetfilter.com	finallygotanexit@stillsecureafteralltheseyears.com

Hey, do you remember reading this little snippet as a quote from a certain industry personality we all know and love in regards to his lack of love for UTM?

"I have a problem with the idea of Universal Threat Management
appliances.  Leaving aside the horrible terminology (Who wants to
manage threats? Don’t you want to block them and forget about them?)
the question that I always ask is: If best-of-breed is the standard for
large enterprises why would it be good practice for a smaller entity to
lump a lot of security functions such as firewall, email gateway, spam
filter, anti-virus, anti-spyware, IDS, IPS, and vulnerability
management all in one under-powered device?"

I’ll give you a hint.  It was posted here by the original author and I responded to it, here.

That’s right!  It was my buddy, Richard Stiennon — lambasting Universal (sic) Threat Management appliances…like those of Fortinet, before they offered him a job.  Perhaps Fortinet doesn’t count because they make Unified, not Universal, Threat Management devices?

Don’t hate the player, baby, hate the game!  (i.e., be careful what you blog, it could come back to hire haunt you.)

Sorry, Rich.  3 Bourbons and a long week make Johnny a lit boy.  Couldn’t help myself.  Fire Away!

/Hoff

As a reprise to the cartoon published earlier today, here’s all you ever need to know about SOA; well, a few things actually.  The entire list is here. 

• SOA is the only thing Chuck Norris can’t kill.
• SOA invented the internet, and the internet was invented for SOA.
• SOA is not complex. You are just dumb.
• In the last year, SOA increased Turkey’s GDP by a factor of 10.
• One person successfully described SOA completely, and immediately died.
• Another person successfully described SOA completely, and was immediately outsourced.
• Larry Ellison once died in a terrible accident, but was quickly
  given SOA. He came back to life, built a multibillion dollar software
  company, and now flies fighter jets.
• Guns don’t kill people, the SOA WS-* stack kills people.
• SOA can write and compile itself.
• SOA is an anagram for OSA, which means female bear in spanish. It
  is a well-known fact in the spanish-speaking world that female bears
  are able to model business processes and optimize reusable IT assets
  better than any other hibernating animal.
• SOA is so great 10 facts aren’t enough.
• SOA is the mistress to all CIOs.
• SOA is just one letter away from SOB. On purpose.
• If a tree falls in the forest, SOA knows about it.
• If you google ‘SAP’ and ‘Chuck Norris’, the top site is SOA Facts.
• SOA is being used in the developing world to solve hunger. Entire populations will be fed on future business value.

…now you know.

Funny.  For more chuckles, see SecurityBullshit!

Hey, at least I’ve never said "military grade hardware." 😉

Gunnar Peterson (1 Raindrop blog) continues to highlight the issues of implementing security models which are not keeping pace with the technology they are deployed to protect.  Notice I didn’t say "designed" to protect.

Specifically, in his latest entry titled "Understand Web 2.0 Security Issues – As Easy as 2, 1, 3" he articulates (once again) the folly of the security problem that we cannot solve because we simply refuse to learn from our mistakes and proactively address security before it becomes a problem:

"So let’s do the math, we have rich Web 2.0 and its rich UI and lots
of disparate data and links, we are protecting these brand new
2007-built apps with a Web 1.0 security model that was invented in
1995. This would not be a bad thing at all if the attacker community
had learned nothing in the last 12 years, alas they have already
upgraded to attacker 3.0, and so can use Web 2.0 to both attack and distribute attacks.

2.0 functionality, 1.0 security, 3.0 attackers. this cannot stand."

A-Friggin’-Men.  Problem is, unless we reboot the entire human race (or at least developers and security folk) it’s going to take a severe meltdown to initiate change.

Oh, and BTW, just because it bugged me when Thomas Ptacek bawked while asking what I meant in a presentation of mine where I said:

"What happens when we hit Web3.0 and we’re still only at
Security 2.4beta11?"

…and he asked:

What does this even mean?

…the answer is simple: Please see Gunnar’s post above.  It’s written much better, but i trust this is all cleared up now?

It’s not often that I will read back through every post archived on a blog, but I must tell you that I have found kindred spirits (even if they don’t know it) in Alex and Jack’s RiskAnalys.is blog.  Fantastic stuff.  The work they have done bringing FAIR (Factor Analysis of Information Risk) to the world at large is awesome. 

Something I’d like to do is relate FAIR to OCTAVE which I have used to feed SRM systems like Skybox (because I’m obviously not busy enough…)

I’m not usually at a loss for words, but these guys really, really have an amazing grasp of the realities, vagaries and challenges of assessing, communicating and managing risk. 

Please do yourself a favor and read/subscribe to their blog and better yet, check out FAIR and Risk Management Insight’s (RMI) website.

Really great stuff.

I’ve followed Alan Shimel’s musings on the furture of vulnerability assessment (VA) and found myself nodding along for the most part about where Alan sees the VA market and technology heading:

    "Over the past year, many have asked what is next for   
    VA.  I think we
are seeing the answer.  The answer is VA
    is morphing into security
configuration management."

Alan preceded this conclusion by illustrating the progression VA has taken over the lifecycle of offerings wherein pure "scanning"  VA toolsets  evolved with integration into vulnerability management (VM) suites that included reporting, remediation and integration and ultimately into a compliance measurement mechanism.

So Alan’s alluded that ultimately VA/VM was really a risk management play and I wholeheartedly agree with this.  However, I am confused as to how broadly the definition of "security configuration management (SCM)" spreads its arms under the fold of the definition of "risk management;" it seems to me that SCM is a subset of an overall risk management framework and not vice versa. Perhaps this is already clear enough to folks reading his post, but it wasn’t to me.

So, to the punchline:

My vision for where VA is going aligns with Alan’s except it doesn’t end (or even next-step to) configuration management.  It leapfrogs directly to security risk management (SRM.)  It’s also already available in products such as Skybox and RedSeal.  (Disclosure: I am on Skybox’s Customer Advisory Board.)

Before you dismiss this as an ad for Skybox, please realize that I’ve
purchased and implemented this solution in conjunction with the other tools I
describe.  It represents an incredible tool and methodology that provided a level of
transparency and accuracy that allowed me to communicate and make decisions that were totally aligned to the most important elements within my business which is exactly what security should do.

Skybox is the best-kept secret in the risk manager’s arsenal.  It’s an amazing product that solves some very difficult business problems that stymie security professionals due to their inability to truly communicate (in real time) the risk posture of their organization.  What do I focus on first?

SRM is defined thusly (pasted from Skybox’s website because it’s the perfect definition that I couldn’t improve upon):

IT Security Risk Management is the complete process of understanding
threats, prioritizing vulnerabilities, limiting damage from potential
attacks, and understanding the impact of proposed changes or patches on
the target systems.
  – IT SRM Solution for Vulnerability Management, Gartner, 2005

Security
Risk Management collects network infrastructure and security
configurations, evaluates vulnerability scan results, maps dependencies
among security devices and incorporates the business value of critical
assets. SRM calculates all possible access paths, and highlights
vulnerabilities that can be exploited by internal and external
attackers as well as malicious worms.

By using
Security Risk Management, the information overload associated with
thousands of network security policies, control devices and
vulnerability scans can be demystified and automated. This is
accomplished by prioritizing tens of thousands of vulnerabilities into
just the few that should be mitigated in order to prevent cyber
attacks. The benefit is a more secure network, higher operational
efficiency and reduced IT workload.

That being said, starting some 3 years ago I saw where VA/VM was headed and it was down a rathole that provided very little actionable intelligence in terms of managing risk because the VA/VM tools knew nothing of the definition or value of the assets against which the VA was performed. 

We got 600 page reports of vulnerability dumps with massive amounts of false positives.  While the technology has improved, the underlying "evolution" of VA is occurring only because the information it conveyed is not valuable if you want to make an informed decision.    If you manage purely threats and vulnerabilities, you’ll be patching forever.

Qualys, Foundstone (nee McAfee) and nCircle (for example) all started to evolve their products by attaching qualitative or quantitative weighting to IT assets (or groups of them) which certainly allowed folks to dashboard the relative impact a vulnerability would have should it be exploited.

The problem is that these impact or "risk" statements (and the ensuing compliance reporting) were still disconnected from the linked dependencies and cascading failure modalities that occur when these assets are interconnected via a complex network.   These tools measure compliance and impact one vulnerability at a time and within a vulnerability diameter of a single host.  They don’t have the context of the network, actors, skill sets or hierarchical infrastructure dependencies.  Throw in dynamic routing and numerous controls and network components in between them and these models proved unrealistic and unreliable.

These tools also assume that somehow you’re able to apply the results of a risk assessment (RA) and be able to translate the groups of assets to a singular "asset" against which impact can be measured based upon the existence of a vulnerability but not necessarily the potential for exploit — VA tools have no concept of whether a  control is in place that mitigates the risk.  You also have to understand an map the sub-components of impact against known elements such as confidentiality, integrity and availability.

That’s exactly where Skybox and SRM comes in. [From their materials]

The four step process of SRM is a continuous, consistent, automated and repeatable framework:

• Model the IT environment
• Simulate access scenarios and attack paths
• Analyze network connectivity, business risk and regulatory compliance
• Plan optimal mitigation strategies and safe network changes

What this means is that you can take all that nifty VA/VM data, understand and model the network and the steady-state risk posture of your organization, perform "what-if’s" and ultimately understand what a change will do to your environment from not only a pure threat/vulnerability perspective, but also a risk/impact one. The accuracy of your data depends on how good you risk input  data is and how up-to-date the  network and  vulnerability results are.  Automate this and it’s as close as you can get to "real-time."  Let’s call it "near-time."

You can communicate these results at any level up and down the stack of your organization and truly show compliance as it matters not only to the spirit of a regulation or law, but also to your business (and sometimes those are different things.)  It slots into configuration management/security configuration management programs and interfaces with CMM models and quality and governance management frameworks such as CobiT and ITIL.

This, in my opinion, is where VA is headed — as a vital component of an intelligent risk management portfolio that is called Security Risk Management.

/Hoff

I immediately looked on Snopes when I saw this raw image as I just couldn’t understand how on Earth someone thought this was a good idea:

Put a clear plastic bag with a fake bomb contained within in conspicuous spaces of a public mall with a "public service message" written on the front.  The point was to suggest that with a little attention to detail, people can avert a tragedy.

The message reads:

It’s this obvious if you are alert.  If you spot anything suspicious, please inform security.
Dummy Explosives
A public service initiative by R Mall

So, if I see a bag that contains an explosive, I should get close enough to read the tagline that says "Boom!  You’re Dead!?"

In Boston our police force blew up little aqua teen hunger force brite-lites that were part of an advertising stunt.  Could you imagine what the hell they’d do with this?

This stroke of brilliance comes from what appears to be an Indian advertising company called Y&R in Mumbai.  Unbelievable.

/Hoff

I read ZDNet’s coverage of the Wharton Technology Conference in Philadelphia by Larry Dignan and was astounded by what Larry reported was said in regards to comments made by TD Ameritrade’s Chief Security Officer, Bill Edwards.

I’m not trying to pick on Mr. Edwards as I have never met the man, but his comments regarding SOA left me disillusioned about how security and emerging technologies are approached in what continues to be a purely reactive, naive and disconnected manner.

Specifically, SOA is not exactly "new."  The evolution of technology, maturing of standards, proliferation of Web 2.0 and massive deployments of SOA’s in some of the world’s largest companies shouldn’t come as a surprise to anyone…even in the risk averse financial services sector.  That being said, SOA is disruptive and innovative and needs to be approached both strategically as well as tactically.

As a former CISO of a $25 Billion financial services firm, I was embroiled in our first SOA deployments 2.5 years ago.  It’s blood and guts.  It involves dealing with the business, business partners, IT and development staffs in ways you never have.  It takes communication, education, expertise and business acumen.  It’s not something you wait to be dragged into.

The notion that a security team would be "dragged" into SOA rather than embrace and approach it proactively and from the perspective of a thought leader and collaborative contributor astounds me.

That said, here’s what I had a problem with:

TD Ameritrade Chief Security Officer Bill Edwards figures that he’s
going to be pulled onto the service oriented architecture (SOA)
bandwagon soon. He might as well use it to enhance security.

"When the architects approached me about SOA my first reaction was ‘no
you can’t do that,’" said Edwards, who spoke at a financial services
online fraud panel at Wharton Technology Conference in Philadelphia on
Friday. "But then I realized I’m going to be dragged along with SOA
anyway so I should use it to rebuild security from the ground up. I
know it’s coming so my team got friendly with the architecture group."

What disturbs me is that SOA represents potentially monumental impact to business, technology and security and instead of embracing (see below) this in a proactive manner, the ad hoc formation of a "strategic" response is "…if you can’t beat ’em, join ’em" and perhaps leverage this to fix problems that weren’t fixed prior.

Paying for sins of the past with currency of the future and confusion in the present isn’t exactly showing alignment to the business as an enabler.  But that’s just me.

It’s clear that the first reaction of saying "no, you can’t do that" is so incredibly typical and representative of the security industry in general; fear what you don’t understand and can it. I can’t imagine how making decisions on risk without an effective model is doing the business justice.

Realizing that this is a train on the tracks that can’t be ducked and that he’s going to be "dragged along with SOA" and that something must be done to head off disaster at the pass (or at least get more budget,) I’m having trouble reconciling this:

"SOA is going to be embraced by security. I don’t know if the industry
is ready for security on SOA, but I’m looking forward to it as it will
make my job easier," he said. "SOA allows you to get granular on
security and focus on specific modules."

I am really having trouble understanding whether this is a statement or a question, but I just cannot comprehend how much sense that last sentence fails to make. 

You’re not embracing SOA when you describe being "dragged into it" and your first reaction is "no." Further, if you’re deploying SOA and you’re not baking in security, you should be fired.

Secondly, Explain to me how SOA is going to make security (his job) easier?  Because you can get "granular on security?"  Huh?  SOA is complex.  If you don’t have your "stuff" together in the first place, it’s only going to make your life more difficult.

I’m sorry for this reading like I’m a grumpy bastard (I am) and that I’m singling out Mr. Edwards (he chose to be on a panel) but this just doesn’t jive.

My advice to Mr. Edwards and anyone else looking for the right approach to take with SOA and security is to read Gunnar Peterson’s blog or some more of his work.
 

/Hoff

Over the last couple of months, the topic of virtualization and security (or lack thereof) continues to surface as one of the more intriguing topics of relevance in both the enterprise and service provider environments and those who cover them.  From bloggers to analysts to vendors, virtualization is a greenfield for security opportunity and a minefield for the risk models used to describe it.

There are many excellent arguments being discussed which highlight in an ad hoc manner the most serious risks posed by virtualization, and I find many of them accurate, compelling, frightening and relevant.  However, I find that overall, to gauge in relative terms the impact  that these new combinations of attack surfaces, vectors and actors pose, the risk model(s) are immature and incomplete. 

Most of the arguments are currently based on hyperbole and anecdotal references to attacks that could happen.  It reminds me much of the ballyhooed security risks currently held up for scrutiny for mobile handsets.  We know bad things could happen, but for the most part, we’re not being proactive about solving some of the issues before they see the light of day.

The panel I was on at the RSA show highlighted this very problem.  We had folks from VMWare and
RedHat in the audience who assured us that we were just being Chicken Little’s and that the risk is
both quantifiable and manageable today.  We also had other indications that customers felt that while the benefits for virtualization from a cost perspective were huge, the perceived downside from the unknown risks (mostly theoretical) were making them very uncomfortable.

Out of the 150+ folks in the room, approximately 20 had virtualized systems in production roles.  About 25% of them had collapsed multiple tiers of an n-tier application stack (including SOA environments) onto a single host VM.  NONE of them had yet had these systems audited by any third party or regulatory agency.

Rot Roh.

The interesting thing to me was the dichotomy regarding the top-down versus bottom-up approach to
describing the problem.  There was lots of discussion regarding hypervisor (in)security and privilege
escalation and the like, but I thought it interesting that most people were not thinking about the impact on the network and how security would have to change to accommodate it from a bottoms-up (infrastructure and architecture) approach.

The notions of guest VM hopping and malware detection in hypervisors/VM’s are reasonably well discussed (yet not resolved) so I thought I would approach it it from the perspective of what role, if any, the traditional  network infrastructure plays in this.

Thomas Ptacek was right when he said "…I also think modern enterprises are so far from having reasonable access control between the VLANs they already use without virtualization that it’s not a “next 18 month” priority to install them." And I agree with him there.  So, I posit that if one accepts this as true then what to do about the following:

If now we see the consolidation of multiple OS and applications on a single VM host in which the bulk of traffic and data interchange is between the VM’s themselves and utilize the virtual switching fabrics in the VM Host and never hit the actual physical network infrastructure, where, exactly, does this leave the self-defending "network" without VM-level security functionality at the "micro perimeters" of the VM’s?

I recall a question I asked at a recent Goldman Sachs security conference where I asked Jayshree Ullal from Cisco who was presenting Cisco’s strategy regarding virtualized security about how their approach to securing the network was impacted by virtualization in the situation I describe above. 

You could hear cricket’s chirp in the answer.

Talk amongst yourselves….

P.S. More excellent discussions from Matasano (Ptacek) here and Rothman’s bloggy.  I also recommend Greg Ness’ commentary on virtualization and security @ the HyperVisor here.