Interpretation is left as an exercise for the reader This went a tad bacterial (viral is too strong of a description) on Twitter:
Interpretation is left as an exercise for the reader This went a tad bacterial (viral is too strong of a description) on Twitter:
I could probably just ask this of some of my friends — many of whom are the best in the business when it comes to Red Teaming/Pen Testing, but I thought it would be an interesting little dialog here, in the open:
When a Red Team is engaged by an entity to perform a legally-authorized pentest (physical or electronic) with an explicit “get out of jail free card,” does that change the tactics, strategy and risk appetite of the team were they not to have that parachute?
Specifically, does the team dial-up or dial-down the aggressiveness of the approach and execution KNOWING that they won’t be prosecuted, go to jail, etc.?
Blackhats and criminals operating outside this envelope don’t have the luxury of counting on a gilded escape should failure occur and thus the risk/reward mapping *might* be quite different.
To that point, I wonder what the gap is between an authorized Red Team action versus those that have everything to lose? What say ye?
Namely, hundreds of detailed discussions (read: lots of booze and whining) over the last 5 years has resulted in the following:
Most in-line security appliances (excluding firewalls) with the ability to actively dispose of traffic — services such as IPS, WAF, Anti-malware — are deployed in “monitor” or “learning” mode are rarely, if ever, enabled with automated blocking. In essence, they are deployed as detective versus preventative security services.
I have many reasons compiled for this.
I am interested in hearing whether you agree/disagree and your reasons for such.
This is deliciously ironic.
Intel‘s implementation of the TCG-driven TPM — the Trusted Platform Module — often described as a hardware root of trust, is essentially a cryptographic processor that allows for the storage (and retrieval) and attestation of keys. There are all sorts of uses for this technology, including things I’ve written of and spoken about many times prior. Here’s a couple of good links:
But here’s something that ought to make you chuckle, especially in light of current news and a renewed focus on supply chain management relative to security and trust.
The Intel TPM implementation that is used by many PC manufacturers, the same one that plays a large role in Intel’s TXT and Mt. Wilson Attestation platform, is apparently…wait for it…manufactured in…wait for it…China.
I wonder how NIST feels about that? ASSurance.
Talk amongst yourselves.
Imagine you are part of a company in the “Pet Industry.” Let’s say dogs, specifically.
Imagine further that regardless of whether you work on the end that feeds the dog, provides services focused on grooming the dog, sells accessories for the dog, actually breeds and raises the dog or deals with cleaning up what comes out the other end of the dog, that you also simultaneously spend your time offering your opinions on how much you despise the dog industry.
Now, either you’re being refreshingly honest, or you’re simply being shrewd about which end of the mutt you’re targeting your services toward — and sometimes it’s both ends and the middle — but you’re still a part of the dog industry.
And we all know it’s a dog-eat-dog world…in the Pet business as it is in the Security business. Which ironically illustrates the cannibalistic nature of being in the security industry whilst trying to distance oneself by juxtaposing the position of the security community.
Claiming to be a Dog Whisperer in an industry of other aimless people shouting and clapping loudly whilst looking to perpetuate bad dog-breeding practices so they can sell across the supply chain is an interesting tactic. However, yelling “BAD DOG!” and wondering why it continues to eat your slippers doesn’t change behavior.
You can’t easily dismantle and industry but you can offer better training, solutions or techniques to make a difference.
Either way, there’s a lot of tail wagging and crap to clean up.
Lots to consider in this little analog. For everyone.
P.S. @bmkatz points us all to this amazing resource you may find useful.
Lori Macvittie is at the Gartner DC conference today and tweeted something extraordinary from one of the sessions focused on SDN (actually there were numerous juicy tidbits, but this one caught my attention:
— Lori MacVittie (@lmacvittie) December 4, 2012
To which my response was:
@lmacvittie Someone should have told them that the server huggers said the same thing about virtualization.
— [Christofer] Hoff (@Beaker) December 4, 2012
Regardless of how one might “feel” about SDN, the notion of agility in service delivery wherein the network can be exposed and consumed as a service versus a trunk port and some VLANs is…the right thing. Just because the network is “flat” doesn’t mean it’s services are or that the delivery of said services are any less complex. I just wrote about this here: The Tyranny Of Taming (Network) Traffic: Steering, Service Insertion and Chaining…
“Flat networks” end up being carved right back up into VLANs and thus L3 routing domains to provide for isolation and security boundaries…and then to deal with that we get new protocols to deal with VLAN exhaustion, mobility and L2 stretch and…
It seems like some of the people at the Gartner DC show (from this and other tweets as I am not there) are abjectly allergic to abstraction beyond that which they can physically exercise dominion.
Where have I seen this story before?
Many people who may only casually read my blog or peer at the timeline of my tweets may come away with the opinion that I suffer from confirmation bias when I speak about security and Cloud.
That is, many conclude that I am pro Private Cloud and against Public Cloud.
I find this deliciously ironic and wildly inaccurate. However, I must also take responsibility for this, as anytime one threads the needle and attempts to present a view from both sides with regard to incendiary topics without planting a polarizing stake in the ground, it gets confusing.
Let me clear some things up.
Digging deeper into what I believe, one would actually find that my blog, tweets, presentations, talks and keynotes highlight deficiencies in current security practices and solutions on the part of providers, practitioners and users in both Public AND Private Cloud, and in my own estimation, deliver an operationally-centric perspective that is reasonably critical and yet sensitive to emergent paths as well as the well-trodden path behind us.
I’m not a developer. I dabble in little bits of code (interpreted and compiled) for humor and to try and remain relevant. Nor am I an application security expert for the same reason. However, I spend a lot of time around developers of all sorts, those that write code for machines whose end goal isn’t to deliver applications directly, but rather help deliver them securely. Which may seem odd as you read on…
The name of this blog, Rational Survivability, highlights my belief that the last two decades of security architecture and practices — while useful in foundation — requires a rather aggressive tune-up of priorities.
Our trust models, architecture, and operational silos have not kept pace with the velocity of the environments they were initially designed to support and unfortunately as defenders, we’ve been outpaced by both developers and attackers.
Since we’ve come to the conclusion that there’s no such thing as perfect security, “survivability” is a better goal. Survivability leverages “security” and is ultimately a subset of resilience but is defined as the “…capability of a system to fulfill its mission, in a timely manner, in the presence of attacks, failures, or accidents.” You might be interested in this little ditty from back in 2007 on the topic.
Sharp readers will immediately recognize the parallels between this definition of “survivability,” how security applies within context, and how phrases like “design for failure” align. In fact, this is one of the calling cards of a company that has become synonymous with (IaaS) Public Cloud: Amazon Web Services (AWS.) I’ll use them as an example going forward.
So here’s a line in the sand that I think will be polarizing enough:
I really hope that AWS continues to gain traction with the Enterprise. I hope that AWS continues to disrupt the network and security ecosystem. I hope that AWS continues to pressure the status quo and I hope that they do it quickly.
Almost a decade ago, the Open Group’s Jericho Forum published their Commandments. Designed to promote a change in thinking and operational constructs with respect to security, what they presciently released upon the world describes a point at which one might imagine taking one’s most important assets and connecting them directly to the Internet and the shifts required to understand what that would mean to “security”:
- The scope and level of protection should be specific and appropriate to the asset at risk.
- Security mechanisms must be pervasive, simple, scalable, and easy to manage.
- Assume context at your peril.
- Devices and applications must communicate using open, secure protocols.
- All devices must be capable of maintaining their security policy on an un-trusted network.
- All people, processes, and technology must have declared and transparent levels of trust for any transaction to take place.
- Mutual trust assurance levels must be determinable.
- Authentication, authorization, and accountability must interoperate/exchange outside of your locus/area of control
- Access to data should be controlled by security attributes of the data itself
- Data privacy (and security of any asset of sufficiently high value) requires a segregation of duties/privileges
- By default, data must be appropriately secured when stored, in transit, and in use.
These seem harmless enough today, but were quite unsettling when paired with the notion of “de-perimieterization” which was often misconstrued to mean the immediate disposal of firewalls. Many security professionals appreciated the commandments for what they expressed, but the the design patterns, availability of solutions and belief systems of traditionalists constrained traction.
Interestingly enough, now that the technology, platforms, and utility services have evolved to enable these sorts of capabilities, and in fact have stressed our approaches to date, these exact tenets are what Public Cloud forces us to come to terms with.
If one were to look at what public cloud services like AWS mean when aligned to traditional “enterprise” security architecture, operations and solutions, and map that against the Jericho Forum’s Commandments, it enables such a perfect rethink.
Instead of being focused on implementing “security” to protect applications and information based at the network layer — which is more often than not blind to both, contextually and semantically — public cloud computing forces us to shift our security models back to protecting the things that matter most: the information and the conduits that traffic in them (applications.)
As networks become more abstracted, it means that existing security models do also. This means that we must think about security programatticaly and embedded as a functional delivery requirement of the application.
“Security” in complex, distributed and networked systems is NOT a tidy simple atomic service. It is, unfortunately, represented as such because we choose to use a single noun to represent an aggregate of many sub-services, shotgunned across many layers, each with its own context, metadata, protocols and consumption models.
As the use cases for public cloud obscure and abstract these layers — flattens them — we’re left with the core of that which we should focus:
Build secure, reliable, resilient, and survivable systems of applications, comprised of secure services, atop platforms that are themselves engineered to do the same in way in which the information which transits them inherits these qualities.
So if Public Cloud forces one to think this way, how does one relate this to practices of today?
Frankly, enterprise (network) security design patterns are a crutch. The screened-subnet DMZ patterns with perimeters is outmoded. As Gunnar Peterson eloquently described, our best attempts at “security” over time are always some variation of firewalls and SSL. This is the sux0r. Importantly, this is not stated to blame anyone or suggest that a bad job is being done, but rather that a better one can be.
It’s not like we don’t know *what* the problems are, we just don’t invest in solving them as long term projects. Instead, we deploy compensation that defers what is now becoming more inevitable: the compromise of applications that are poorly engineered and defended by systems that have no knowledge or context of the things they are defending.
We all know this, but yet looking at most private cloud platforms and implementations, we gravitate toward replicating these traditional design patterns logically after we’ve gone to so much trouble to articulate our way around them. Public clouds make us approach what, where and how we apply “security” differently because we don’t have these crutches.
Either we learn to walk without them or simply not move forward.
Now, let me be clear. I’m not suggesting that we don’t need security controls, but I do mean that we need a different and better application of them at a different level, protecting things that aren’t tied to physical topology or addressing schemes…or operating systems (inclusive of things like hypervisors, also.)
I think we’re getting closer. Beyond infrastructure as a service, platform as a service gets us even closer.
Interestingly, at the same time we see the evolution of computing with Public Cloud, networking is also undergoing a renaissance, and as this occurs, security is coming along for the ride. Because it has to.
As I was writing this blog (ironically in the parking lot of VMware awaiting the start of a meeting to discuss abstraction, networking and security,) James Staten (Forrester) tweeted something from @Werner Vogels keynote at AWS re:invent:
Werner: “There’s no excuse not to use fine grained security to make your apps secure from the start.” Echoing @kindervag Zero Trust
— Staten7 (@Staten7) November 29, 2012
I couldn’t have said it better myself
So while I may have been, and will continue to be, a thorn in the side of platform providers to improve the “survivability” capabilities to help us get from there to there, I reiterate the title of this scribbling: Amazon Web Services (AWS) Is the Best Thing To Happen To Security & I Desperately Want It To Succeed.
I trust that’s clear?
P.S. There’s so much more I could/should write, but I’m late for the meeting
I usually don’t spend much time when I write a blog, but this was ridiculously difficult to write.
I’m neither a neuroscientist or a computer scientist. I’ve dabbled in AI and self-organizing maps, but I can barely do fractions, so every sentence of this blog had me doubting writing it. It’s probably shit, but I enjoyed thinking about it.
The further I tried to simplify my thoughts, the less cogent they became and what spooled outward onto my screen resembled more porridge than prose.
That said, I often feel stymied while writing. When someone else has crystallized thoughts to which adding commentary seems panderous, redundant, or potentially intellectually fraudulent, it feels like there’s no possible way that my thoughts spilling out are original, credible, or meaningful.
This is especially the case as when brilliant people have written brilliant things on the topic.
“On the shoulders of giants” and all that…
Skynet, The Matrix, The Singularity, The Borg…all of these examples popped into my head as I wrote, destroying my almost sensical paragraphs with clumbsy analogs that had me longing to reduce my commentary to nothing more than basic Twitter and Facebook-like primitives: “< +1″ or “Like.” It was all just a big pile of fail.
The funny thing is, that’s actually where this story begins and why its genesis was so intriguing.
Alex Williams wrote an article titled “How Machines Will Use Social Networks To Gain Identity, Develop Relationships And Make Friends.”
He offered up a couple of interesting examples from some conceptual “demos” from last week’s VMworld. I re-read the article and found that the topic was profound, relevant and timely.
At its core, Alex challenges us to reimagine how “machines” — really combinations of infrastructure and applications that process information — might (self) identify, communicate, interoperate, organize and function as part of a collective construct, using a codified language that mimics the channels that we humans are today using in social patterns and grafs that define our relationships online.
The article wobbled a bit with the implication that machines might “feel,” but stripping relevant actions or qualitative measures such as “like” or “dislike” down to their core, it’s not hard to imagine how machines might evaluate or re-evaluate relationships, behavior and (re)actions based on established primitives such as “good,” “bad,” “available” or “malfuctioned.”
I know that’s how my wife generally thinks of me.
Frankly, it’s a simple concept. Even for humans. As an intelligently-complex species, humans define even heady things like emotional responses as a function of two fundamental neurotransmitters — chemical messengers — the biogenic amines serotonin and dopamine. The levels of these neurotransmitters are normally quite reasonably regulated but can be heightened or depressed based on the presence of and interaction with other chemical compounds. These neurochemical interactions may yield behavioral or even systemic immune system responses that manifest themselves in a variety of ways; from happiness to disease.
One might imagine that machines might likewise interact and form behavioral responses to, and thus relationships with, other groups of machines in either like-minded or opposing “clusters” using a distilled version of the very “activity streams” that humans feed into and out of using social media, defined by the dynamic, organic and chaotic social graph that ties them.
[I just noticed that my friend and prior colleague Mat Matthews from Plexxi wrote a blog on "affinity" and described this as Socially Defined Networks. Brilliant. ]
I’m sure that in some way, they already do. But again, I’m hung up on the fact that my NEST thermostat may actually be out to kill me…and tweet about it at an ecologically sound point in time when electricity costs are optimal.
The notion that machines will process these activity streams like humans do and act on them is really a natural extension of how today’s application architectures and infrastructure designs which utilize message buses and APIs to intercommunicate. It’s a bit of a re-hash of many topics and the autonomic, self-learning, HAL-9000 batshit crazy compute concepts we’ve all heard of before.
On Twitter, reacting to what he sensed as “sensationalism,” Thomas Lukasik (@sparkenstein) summarized my assessment of this concept (and thus rendering all these words even more useless) thusly:
“…my immediate response was that a “social network” is an ideal model 2 take advantage of N autonomous systems.”
My response: +1 (see what I did there?
But what differentiates between the human social graph and the non-kinetic “cyber” graph is the capacity, desire and operational modality that describes how, when and why events are processed (or not.) That and crazy ex-girlfriends, pictures of dinner and politicial commentary.
I further addressed Thomas’ complaint that we’d seen this before by positing that “how humans are changing the way we interact will ultimately define how the machines we design will, too.”
To wit, machines don’t necessarily have the complexity, variety, velocity and volume of unrelated stimuli and distractions that humans do. We have more senses and we have fuzzy responses to binary responses. They are simpler, more discrete “creatures” and as their taskmasters, we enjoy a highly leveraged, somewhat predictable and reasonably consistent way in which they process and respond to events.
Usually until something kinetic or previously undefined occurs. Then, the dependency on automation and the ability for the discrete and systemic elements to “learn,” adapt, interact and leverage previously unrelated relationships with other nodes becomes important. I wrote about that here: Unsafe At Any Speed: The Darkside Of Automation
What’s really relevant here, however, is that the “social graph” approach — the relationship between entities and the policies established to govern them — can help close that gap. Autonomous is cool. Being part of an “autonomous collective” is cooler. As evidence, I offer up that scene with the peasants in Monty Python’s “Quest for the Holy Grail.”
In fact, if one were to look at computer networks, we’ve seen the evolution from centralized to distributed and now hybrid models of how the messages and state between entities are communicated and controlled.
Now, take a deep breath because I’m about to add yet another bit of “sensationalism” that Thomas will probably choke on…
The notion of separating the control, data and management planes that exist in the form of protocols and communication architectures are bubbling to the surface already in the highly-hyped area of software defined networking (SDN.)
I’m going to leave the bulk of my SDN example for another post, but bear with me for just a minute. (Actually, this is where the blog descends into really crappily thought out rambling.)
If we have the capability to allow the applications and infrastructure — they’re both critical components of “the machine” — to communicate in an automated manner while contextualizing the notion that an event or message might indicate a need for state change, service delivery differences, or even something such as locality, and share this information with those who have a pre-defined relationship with a need-to-know, much goodness may occur.
This starts to bring back into focus the notion that like a human immune system, the ability to identify, localize and respond, signalling to the collective the disposition of the event and what may be needed to deal with it.
The implications are profound because as the systems of “machines” become increasingly more networked, adaptive and complex, they become more like living organisms and these collective “hives” will behave less like binary constructs, and much more like fuzzy communities of animals such as ants or bees.
If we bring this back into the teeniest bit more relevant focus — let’s say virtualized data centers or even (gasp!) Cloud, I think that collision between “social” and “networking” really can take on a broader meaning, especially within the context of how systems intercommunicate and interact with one another.
As an example, the orchestration, provisioning, automation and policy engines we’re deploying today are primitive. The fact that applications and infrastructure are viewed as discrete and not as a system further complicates the problem space because the paths, events, messages and actions are incomprehensible to each of these discrete layers. This is why we can’t have nice things, America.
What’s coming, however, are really interesting collisions of relevant technology combined with fantastic applications of defining and leveraging the ways in which these complex systems of machines can become much more useful, interactive, communicative and “social.”
I think that’s what Alex was getting at when he wrote:
…points to an inevitable future. The machines will have a voice. They will communicate in increasingly human-like ways. In the near term, the advancements in the use of social technologies will provide contextual ways to manage data centers. Activity streams serve as the language that people understand. They help translate the interactions between machines so problems can be diagnosed faster.
By treating machines as individuals we can better provide visualizations to orchestrate complex provisioning and management tasks. That is inevitable in a world which requires more simple ways to orchestrate the increasingly dynamic nature for the ways we humans live and work with the machines among us.
Johnny Five is Alive.
A “Potemkin village” is a Russian expression derived from folklore from the 1700′s. The story goes something like this: Grigory Potemkin, a military leader and statesman, erected attractive but completely fake settlements constructed only of facades to impress Catherine the Great (empress of Russia) during a state visit in order to gain favor and otherwise hype the value of recently subjugated territories.
I’ll get to that (and probably irate comments from actual Russians who will chide me for my hatchet job on their culture…)
Innovation over the last decade in technology in general has brought fundamental shifts in the way in which we work, live, and play. In the last 4 years, the manner in which technology products and services that enabled by this “digital supply chain,” and the manner in which they are designed, built and brought to market have also pivoted.
Virtualization and Cloud computing — the technologies and operational models — have contributed greatly to this.
Interestingly enough, the faster technology evolves, the more lethargic, fragile and fractured security seems to be.
This can be explained in a few ways.
First, the trust models, architecture and operational models surrounding how we’ve “done” security simply are not designed to absorb this much disruption so quickly. The fact that we’ve relied on physical segregation, static policies that combine locality and service definition, mobility and the (now) highly dynamic application deployment options means that we’re simply disconnected.
Secondly, fragmentation and specialization within security means that we have no cohesive, integrated or consistent approach in terms of how we define or instantiate “security,” and so customers are left to integrate disparate solutions at multiple layers (think physical and/or virtual firewalls, IDP, DLP, WAF, AppSec, etc.) What services and “hooks” the operating systems, networks and provisioning/orchestration layers offers largely dictates what we can do using the skills and “best practices” we already have.
Lastly, the (un)natural market consolidation behavior wherein aspiring technology startups are acquired and absorbed into larger behemoth organizations means that innovation cycles in security quickly become victims of stunted periodicity, reduced focus on solving specific problems, cultural subduction and artificially constrained scope based on P&L models which are detached from reality, customers and out of step with trends that end up driving more disruption.
I’ve talked about this process as part of the “Security Hamster Sine Wave of Pain.” It’s not a malicious or evil plan on behalf of vendors to conspire to not solve your problems, it’s an artifact of the way in which the market functions — and is allowed to function.
What this yields is that when new threat models, evolving vulnerabilities and advanced adversarial skill sets are paired with massively disruptive approaches and technology “conquests,” the security industry basically erects facades of solutions, obscuring the fact that in many cases, there’s not only a lacking foundation for the house of cards we’ve built, but interestingly there’s not much more to it than that.
Again, this isn’t a plan masterminded by a consortium of industry “Dr. Evils.” Actually, it’s quite simple: It’s inertial…if you keep buying it, they’ll keep making it.
We are suffering then from the security equivalent of the Potemkin Village syndrome; our efforts are largely built to impress people who are mesmerized by pretty facades but don’t take the time to recognize that there’s really nothing there. Those building it, while complicit, find it quite hard to change.
Until the revolution comes.
To wit, we have hardworking members of the proletariat, toiling away behind the scenes struggling to add substance and drive change in the way in which we do what we do.
Adding to this is the good news that those two aforementioned “movements” — virtualization and cloud computing — are exposing the facades for what they are and we’re now busy shining the light on unstable foundations, knocking over walls and starting to build platforms that are fundamentally better suited to support security capabilities rather than simply “patching holes.”
Most virtualization and IaaS cloud platforms are still woefully lacking the native capabilities or interfaces to build security in, but that’s the beauty of platforms (as a service,) as you can encourage more “universally” the focus on the things that matter most: building resilient and survivable systems, deploying secure applications, and identifying and protecting information across its lifecycle.
Realistically this is a long view and it is going to take a few more cycles on the Hamster Wheel to drive true results. It’s frankly less about technology and rather largely a generational concern with the current ruling party who governs operational security awaiting deposition, retirement or beheading.
I’m looking forward to more disruption, innovation and reconstruction. Let’s fix the foundation and deal with hanging pictures later. Redecorating security is for the birds…or dead Russian royalty.
However, the recent rash of commentary from security wonks on Twitter and blogs regarding who is to “blame” in Mat Honan’s unfortunate experience leaves me confused and misses an important point.
Firstly, the title of the oft-referenced article documenting the series of events is at the root of my discontent:
As I tweeted, my assessment and suggestion for a title would be:
How my poor behavior led to my epic hacking & flawed trust models & bad luck w/Apple and Amazon assisted
…especially when coupled with what is clearly an admission by Mr. Honan, that he is, fundamentally, responsible for enabling the chained series of events that took place:
In the space of one hour, my entire digital life was destroyed. First my Google account was taken over, then deleted. Next my Twitter account was compromised, and used as a platform to broadcast racist and homophobic messages. And worst of all, my AppleID account was broken into, and my hackers used it to remotely erase all of the data on my iPhone, iPad, and MacBook.
In many ways, this was all my fault. My accounts were daisy-chained together. Getting into Amazon let my hackers get into my Apple ID account, which helped them get into Gmail, which gave them access to Twitter. Had I used two-factor authentication for my Google account, it’s possible that none of this would have happened, because their ultimate goal was always to take over my Twitter account and wreak havoc. Lulz.
Had I been regularly backing up the data on my MacBook, I wouldn’t have had to worry about losing more than a year’s worth of photos, covering the entire lifespan of my daughter, or documents and e-mails that I had stored in no other location.
Those security lapses are my fault, and I deeply, deeply regret them.
The important highlighted snippets above are obscured by the salacious title and the bulk of the article which focuses on how services — which he enabled and relied upon — however flawed certain components of that trust and process may have been, are *really* at the center of the debate here. Or ought to be.
There’s clearly a bit of emotional transference occurring. It’s easier to associate causality with a faceless big corporate machine rather than swing the light toward the victim, even if he, himself, self-identifies.
Before you think I’m madly defending and/or suggesting that there weren’t breakdowns with any of the vendors — especially Apple — let me assure you I am not. There are many things that can and should be addressed here, but leaving out the human element, the root of it all here, is dangerous.
I am concerned that as a community there is often an aire of suggestion that consumers are incapable and inculpable with respect to understanding the risks associated with the clicky-clicky-connect syndrome that all of these interconnected services brings.
People give third party applications and services unfettered access to services like Twitter and Facebook every day — even when messages surrounding the potential incursion of privacy and security are clearly stated.
When something does fail — and it does and always will — we vilify the suppliers (sometimes rightfully so for poor practices) but we never really look at what we need to do to prevent having to see this again: “Those security lapses are my fault, and I deeply, deeply regret them.”
The more interconnected things become, the more dependent upon flawed trust models and the expectations that users aren’t responsible we shall be.
There’s a lot of interesting discussion regarding the effectiveness of security awareness training. Dave Aitel started a lively one here: “Why you shouldn’t train employees for security awareness”
It’s unfortunate the the only real way people learn is through misfortune, and any way you look at it, that’s the thing that drives awareness.
There are many lessons we can learn from Mr. Honan’s unfortunate experience…I urge you to consider less focusing blame on one link in the chain and instead guide the people you can influence to reconsider decisions of convenience over the potential tradeoffs they incur.
P.S. For you youngsters who don’t get the Soylent Green reference, see here. Better yet, watch it. It’s awesome. Charlton Heston, FTW.
P.P.S. (Check out the sentiment of all the articles below)