Strong Recommendation: If you're a writer, I cannot urge you strongly enough to avoid or flee InfoSec Island. If you're a reader, then I strongly recommend that you not use their site any further. A business that profits from and exists because of the free contributions from people like me do not deserve continued patronage when they clearly disrespect the people who provide the content upon which they base their business.
]]> Summary: On Thursday, January 5th, 2012, I submitted a revision of an earlier blog post to InfoSec Island. I'd spent a couple hours the previous night revising the text, since I felt it used first-person too much, plus integrating some feedback I'd received that would make it a better piece. The article was posted on Friday, January 6th, though I don't know when exactly. Someone cc'd me on twitter saying they liked it, and someone else commented on the post itself expressing their approval.When I clicked through to see the comment, I noticed that the version posted was the original blog post and not the piece I had submitted. This upset me greatly, causing me to email them to complain about the impropriety of posting the wrong piece. The site does not provide a way for submitters to edit their articles once they're published. Michael Menefee of InfoSec Island responded very quickly and threatened to delete the post outright. When I objected, and provided the correct text for the post, he then threatened to delete my account. He then deleted the text of the post (to maintain the comment) and redirected it back to my blog. My account was then deleted altogether, so the post and comment are gone. Things snowballed into a drama-storm that is sadly typical of the infosec industry. There are several issues at play here, which I'll now discuss.
The Issues (as I see them)
As InfoSec Island is a business, there are potential copyright infringement issues in their not posting the text provided (my blog is protected under a Creative Commons license with Noncommercial). They did not have approval to go pull the draft from my site.
Apparently, InfoSec Island is/was having issues with their web site. According to a separate email from Anthony Freed (one of their curators), my submission came through as a garbled mess (I pasted plaintext into their WYSIWYG editor). Making a bad assumption, he went and pulled the blog post of the same title rather than contacting me first to make sure this was ok and to confirm that it was, in fact, the same text.
I very much feel like they (Menefee in particular) projected their angst from the site issues onto me. How dare I complain that they improperly used text for which they weren't authorized, apparently. :S I was not aware of their issues, nor am I responsible for their issues. Their site directly benefits from the freely-submitted content of people like me. They actively recruited me to contribute to their site for 6 months. Four months later, my account is canned for complaining about their posting the wrong content? Bad form.
Ultimately, what I expected from them was a quick apology and an offer to get the right text posted. Instead, they threatened to delete the post in their initial response. Talk about a "burning down the house" approach. Moreover, they continued to escalate things, threatening to delete my account altogether (which they did), and even going so far as to post the email exchange to pastebin.
Tweets and The Email Thread
In addition to sending a complaint to InfoSec Island via their "contact us" link, I also tweeted on Friday night about my frustration in finding that they'd magically posted text that hadn't been submitted.
imagine my great annoyance at realizing that InfoSec Island did not publish the piece I submitted, but a prior revision from my blog
— Ben Tomhave (@falconsview) January 7, 2012
After receiving the emails from Menefee threatening to delete the post and my account, I tweeted the following bit of frustration. Several people responded, and I had limited banter. The sum-n-total of it was that people suggested it was time to walk away, which I agreed with. Other people offered to reach out and mediate with someone higher up the food chain than Menefee.
Wow... complained to infosec island re wrong text being posted for my post, their response? threaten to delete post and my account. #wtf ?!?
— Ben Tomhave (@falconsview) January 7, 2012
Hearing from one friend on Sunday, who was speaking with a site higher-up (Lance Miller @wireheadlance - site owner?), it sounded like things were going to be ok. I held off on writing this post, and from saying anything else. Imagine my surprise Monday morning, then, when I saw the following:
@falconsview saved you the time...http://pastebin.com/RM5M04ky
— Infosec Island (@InfosecIsland) January 9, 2012
Someone (presumably Menefee) took it upon themselves to post the email thread to pastebin (I presume in response to this tweet). Definitely classy, especially for a business that is benefiting financially from the freely-contributed content of authors like me.
Interestingly, the posted thread left out two email messages in the exchange. First, after saying "I can send you the correct text." I then sent him a follow-up email with the correct text. It's at that point that he said he'd unpublished the article for me to edit it, which turned out not to be true.
Second, after my brief "Seriously? This is your response?" email back to Menefee after his threat of deleting my account, I then sent the following:
"What you also don't seem to be grasping [sic] here is that I spent 2 hours of my own time to revise that article in order to deliver a better quality piece for your site. The result? It gets tossed without a glance because the site is broken, and with no way for me to know that."
Conclusion
Sadly, despite intervention from a key acquaintance who knows all parties involved urging them to contact me, there has been no further official communication from InfoSec Island, nor have I received an official apology for their mistake. This is a business that profits financially from free contributions by people like myself. I'm still rather shocked that I was attacked for complaining, and that there is apparently no interest on their part to speak to me to sort things out. Clearly, this is an organization run by amateurs who don't respect the people who volunteer their time and intellectual property.
This post was first authored on January 9th, 2012, and held for review to see if a favorable resolution would occur. The key acquaintance sent a final admonishment late that week (around Jan. 13th) to encourage them to contact me to resolve this matter. Sadly, after giving them more than a week to do the simple task of reaching out to me, it seems that apologizing is beyond their conscience. It's unfortunate, because I believe that some of their people (e.g., Anthony Freed) are working in earnest to help build a solid portal, and yet this poor treatment of contributors is a black mark that leads me to conclude that everybody should pull back, stop contributing, stop reading, and stop supporting the organization. Any business that is unwilling to recognize when they've erred and work to make it right does not deserve continued patronage.
]]>The first issue was a simple question I asked about whether or not a QSA was still required if a business had an ISA. To my great surprise, Branden responded that not only was a QSA not required, but it never had been! His response even surprised a couple other QSAs. I'll go into this more below, but suffice to say that when you dig into each card brand's requirements, it turns out that self-certification is allowed with the signature of a company officer.
The second thread that came out of the original discussion revolved around the topics of businesses needing to become competent on PCI requirements (or, what's reasonable to expect), as well as a side-bar about whose risk is actually being managed. We'll discuss these topics as well.
]]> No QSA RequiredIf you think a QSA is required to sign your RoC, then think again! It turns out that it's not a requirement, and never has been. However, the card brands, PCI Council, and what I'll call the "audit-industrial complex" have a lot to gain financially from your believing otherwise.
Branden lays this all out in his post, but just to reiterate for convenience:
* The PCI Council sets the requirements, but are not the enforcers.
* Each card brand sets its own enforcement rules.
* In general, you are not (and apparently have not) been required to use a QSA. Instead, you can use an internal auditor and then have a company officer sign the RoC. That said, the requirement may be shifting (e.g., see MasterCard's statement here) that you would at least need an ISA (Internal Security Assessor) rather than just using a non-certified auditor.
With me so far? So, if it's really true that a QSA has never been required, then why is it that companies almost universally believe that one is necessary? It may be because of a false belief that using a QSA transfers liability (or, risk) to a third party. Or, it may be because both the card brands and the "audit-industrial complex" wants you to believe that a QSA is needed. After all, both groups benefit financially from misunderstanding this requirement (or lack thereof).
Perhaps this sounds a bit conspiratorial, but it wouldn't be the first time that the audit industry behaved in this way. In fact, discussions seem to be popping up again about the proper role of auditors (internal and external), auditor independence, and even whether multi-year contracts with a single audit firm are sensible. The simple fact is that these companies stand to profit handsomely from the audit-industrial complex that's been built-up over the years, and I find it hard to believe that it's an accident that businesses have been led to believe that a QSA is a requirement.
A Flawed Approach
PCI and the card brands have been much maligned over the last several years. PCI DSS represents a set of requirements that are oftentimes unfathomable to the average person. To make matters worse, contracts are excessively complex, and leave businesses in a no-win scenario; either they accept the terms, or they lose customers due to a lack of support for payment cards. Especially for small business, which have particularly limited resources, it's simply unreasonable to expect them to somehow develop enough competency around security and compliance to understand all the details of contracts and standards like PCI DSS. Unfortunately, Branden seems to disagree, as he states in his "Corporate Responsibility" piece:
"Companies must make security and compliance a core part of their competency if they choose to operate in a manner that puts them in the cross-hairs of regulation."
More to the point though, I question where or not it's really sound logic to think that merchants should be held to these standards. While it's true that they signed the contracts, one could potentially make the argument that PCI DSS and the payment card contracts are too complex for businesses to understand, not to mention that PCI DSS represents a moving target. Even Branden admits "Is it overly-complex? Definitely." Unfortunately, he goes on to an "ignorance is no defense" line of thinking that may not be sound logic, and once again belies the faulty thinking behind this program. In fact, he even goes on to say:
"Citizens of a civilized society are expected to follow the rules of that society. Ignorance is never a defense."
The long-n-short of it is this: PCI DSS itself is not a law. It's a convoluted mess that is rarely, if ever, presented clearly (e.g., we didn't even have an immediate agreement and consensus on the previous post about whether or not a QSA is required, with QSAs actually questioning the statement). If professionals working in the field are unclear on these things, how is it that we expect organizations (especially small businesses) to somehow be "expert" or even "adequately educated" on these requirements, especially when card processing and card security are merely an ancillary supporting function, not anything core to their business? Which leads to the last question...
Whose Risk?
Exactly whose risk are these merchants managing, anyway? In the case of PCI DSS, they are being asked to act on behalf of, and in the interest of, the card brands. PCI DSS is part of the card brands' risk management program, in which - really - the merchants are part of the threat community against which they (the card brands) are defending themselves. In this sense, PCI DSS represents the greatest coup of modern times in that the card brands have successfully pushed much of the responsibility for their security onto the shoulders of merchants and acquirers, whether they can afford it or not.
As such, when I hear arguments made that merchants should be taking a more active interest and role in "managing risk" related to things like payment cards, it makes me pause because this would be like petroleum companies holding mechanics liable for engine failures resulting from poor quality oil or fuel. Ultimately, the payment card architecture is inadequate from a security perspective, introducing a high potential for fraud losses for the card brands. Unfortunately, rather than addressing this core deficiency, the card brands are driving compensating controls that transfer that risk to the merchants (without the merchants really having much option to say no - more on this in a minute), and then reinforced further with a fine scheme that at times seems arbitrary and capricious.
So, why don't the merchants quit accepting payment cards? There are several reasons:
* Checks: There is considerable disincentive to take checks. Also, banks are decreasingly willing to accept them. Walmart, for example, scans the check and still requires you to enter your PIN to complete the transaction just as if you'd swiped a debit card.
* Cash-Only: While a compelling case could be made in some places favoring cash-only, there are a few contingencies that are necessary. Branden and I actually discussed at length before I wrote this piece. First, if you're cash-only, then an ATM needs to be available either on-site or in very close proximity (oh, and preferably with a truly reasonable fee structure). Second, there is likely a ticket size at which cash-only becomes less feasible (is it $20? $40? $50? I don't know.). If you're going to a fine dining restaurant and expecting a check over $100, would you not be surprised if they didn't take payment cards?
* Dropping Card Support: If your business has supported payment cards, then it will be very difficult to terminate support. Customers tend to feel very strongly about having services available, and tend to attract negatively when they go away, even if the true (vs perceived) impact is minimal.
* Social Pressure: Depending on your locale and primary demographic, there may be a very strong expectation by your customers to support payment cards (going forward, this may also include mobile payments support). If not having payments cards will drastically limit or decrease the willingness of your customers to purchase from you, then you're going to sign up for payment cards, no matter what the contract says.
Now, you might be reading and still thinking "So what? Why do they accept this risk? Why don't they transfer it?" And on that point we of course agree (Branden does, too!). I don't think there is really any disagreement on this point about outsourcing. However, I do disagree with how you define it. PA-DSS exists to certify point-of-sale (POS) systems. If, as a merchant, I buy a POS, then my expectation is that it's compliant. If it later turns out that the POS is not compliance, then don't fine me (the merchant), but instead fine the POS maker! From my perspective as a merchant, I transferred the compliance responsibilities to the POS maker when I bought their (regulated) product. Similarly, few merchants directly support their POS systems. Instead, many will leverage integrators who will provide direct POS product support, and may even lease the product to the merchant. In this case, also, as a merchant I would assume (right or wrong) that I've transferred my risk and do not have a responsibility to do anything further.
Unfortunately, there's no good consensus on these points today, and the PCI Council certainly hasn't done well to clear the muddied waters. Perhaps the restaurant lawsuit will help set a benchmark for responsibility, but it will likely be a while before we see resolution (assuming it's resolved in court at all, which is never a safe bet). Until we achieve better consensus, I will continue to maintain that PCI DSS represents a regulation regime that is strongly stacked against merchants, and serves to further grow the audit-industrial complex, which has been as much a negative as positive force in the industry. For every improvement we might be able to trace to PCI DSS implementation, there are increasing numbers of examples where security was not improved, or where confusion led to worse results that could have been addressed through more clear, more responsible behavior by all parties (including the card brands).
]]>5 Putridly Egregious Failures
In my opinion, there are 5 major failures in this case that proves STRATFOR to be negligent (possibly criminally). I'm very much hoping some lawyer will step up and file a class action lawsuit against them. Money isn't my interest, but rather making sure that this company and these business "leaders" are severely hindered from being able to ever be in a position again to do this to people. In my mind, this provides a textbook example of where the legal code needs to be updated to outright ban these "executives" from owning, operating, or leading a business for a few years because they've shown themselves to be completely incompetent and dangerous to people and the market.
Sorry, enough venting... let's look at what I see as the 5 main failures:
1) No data encryption
STRATFOR maintained a database (or a few?) containing personal data, including credit card information (undoubtedly fore recurring subscriptions). Under PCI DSS, they are required to encrypt that full credit card number. It's now clear that they did not do so. It's hard to even begin to describe how completely ignorant and irresponsible this is. More importantly, why maintain the data yourself when there are so many 3rd party services out there that can tokenize the value and reduce your risk profile? This is cardholder data management 101, and they failed, big-time.
2) Storing CVV
As if the lack of encryption isn't bad enough, it also turns out that they stored the CVV value from the cards (the number on the back of your card on the signature strip). This is strictly forbidden in Requirement 3.2 of PCI DSS 2.0 ("Do not store sensitive authentication data after authorization (even if encrypted)."). While the lack of encryption is egregious, the storage of sensitive authentication data is simply unforgivable and reflects a wanton disregard for regulations and protection of customer data.
3) Blank or default passwords
As if the cardholder data handling wasn't bad enough, it also seems that STRATFOR's systems weren't even using basic security measures. Specifically, it's been reported that they had no password for their SQL Server access, and likely had default passwords in other cases. Seriously?!? How is it even remotely possible in 2011 (time of incident) that a company can be so ignorant and incompetent that they didn't even bother to set a basic database password? Of course, the answer is...
4) Failure to hire competent staff
STRATFOR did not hire good people. In fact, it's unclear if they had *any* security people onboard at any point in time. I'm guessing they never had an external pentest of their systems (if they did, and didn't act, then that would be another point toward negligence). According to one report, they were notorious for hiring people straight out of school with no real experience, and almost certainly with no security background. Their IT "lead" left the company in Sept. 2011 and was not replaced. Moreover, they'd been trying (without success) to hire an alternative resource for almost a year. Moreover, the idea has also been floated that this breach may have received insider help, which may never be known for sure, but certainly wouldn't help much. But wait, it gets better...
5) Failure to learn from previous incident
I've thus far been unable to find any citations to corroborate this assertion, but it was heard in passing last week that STRATFOR may have had a breach in 2010 as well. This would not surprise me in the least. This has to be about the softest target ever, and one with lots of juicy appeal (splashy in the news, lots of credit card numbers complete w/ CVVs, etc.). I mean, who wouldn't want to pop these guys just for the Lulz? *sigh* Suffice to say, if true, then this is, imo, the fifth and final nail in the negligence coffin. I'll post an update here if/when I get corroboration.
---
Left off this list are 2 additional points that people have raised:
* Their communication on the incident has been weak. While I'm not as upset about this as, say, subscribers to the free service, I can see the point. What I did find interesting is that they've relied more on posting updates to their Facebook group than they have in emailing customers. This is particularly interesting as some have asserted that the hackers stole all their data and then recursively deleted all the data on the servers (if true, how did they still have my email address? maybe through a 3rd party mailing service?).
* Inadequate enforcement of decent user passwords. I. Don't. Care. This will be in a separate blog post soon, but the user password question is grossly overblown. It didn't lead to this compromise, nor can it generally be attributed to major compromises anywhere. Yet, people in the industry loooooove to obsessively deride users for picking poor passwords. Whatever. Look for my post later this week, or check out my 2010 post "Password Complexity Is Lame."
In Closing...
I hope that STRATFOR is done for good. I hope the execs there find themselves banished from corporate America and, more importantly, the intel and military communities. Their sheer incompetence rises to a definitive level of negligence and incompetence that should not be seen in this day and age. There is no excuse for their failings, and they should be punished accordingly.
cryptome has been maintaining a running list of the data disclosures, available here:
http://cryptome.org/0005/stratfor-hack.htm
Nick Selby (@nselby) provides an interesting overview of STRATFOR's initial response and communication, which seems fair:
http://policeledintelligence.com/2011/12/25/rating-the-stratfor-incident-response/
ps: I intentionally waited a while on writing this piece to allow my anger to subside a bit. No, seriously! :)
]]>Closing out 2011, there are a variety of breaches to look back on. I'm sure there are comprehensive lists somewhere, but I'm too lazy to go find them (I hear Google searches work for that sort of thing;). From my recollection, the big ones seem to be related to HBGary, RSA, and now STRATFOR (though I don't know that I consider it to be in the same class). The RSA breach was probably the most interesting one from within the infosec industry. It's always interesting to see in-industry companies having issues. HBGary was intriguing, too, for similar reasons, though they did suffer from poking the bear a bit, whereas RSA was likely more of a strategically interesting hack to compromise technology.
The STRATFOR hack perplexes me. I don't get targeting them, aside from the flash of press hype that's ensued (slow news week?). Sure, they had some high-profile companies as customers, but they weren't really all that interesting a target. They seem to provide fairly objective analysis, and they don't seem to take sides. Moreover, they've done very little in the "cybersec" space, which makes me scratch my head even more. Ah, well...
Looking forward to 2012 for security, I hope that we can continue making progress in key areas like GRC and risk management. 2011 seemed to see a lot of bandwagon-jumping around use of the term "risk," and that will hopefully lead to a better approach going forward. We need more data points, more open sharing, and more maturity. I think we can and will continue making progress in this area, and I'm hopeful that the Society of Information Risk Analysts (SIRA) - to which I was voted a board member recently - will help us with maturing the state of art. I'm also hopeful that I'll be able to help customers improve their practices while providing useful tools through high-quality GRC solutions (note: I'm a bit biased given my employer!).
Outside of infosec, 2011 was intriguing for other reasons. Severe weather was more severe than we've seen in ages. Just in the DC metro area (where I live), we had an earthquake and hurricane in the span of a couple weeks. This was followed by more rain than we rightly needed, and then a very early first snow in late October. Lots of tornadoes hit around the country, and the ring of fire seems to be rumbling back to life as we start seeing an increase in earthquake activity all over the place. Average temps are soaring, which seems to partially validate global warming theories, though I still maintain that a major ice age is the logical conclusion to such activity.
People were also interesting in 2011, such as the Occupy Wall Street movement. The economy still stinks, and I don't think we've yet seen the end of that down-cycle. Will the eurozone survive? It's anybody's guess at this point. At the same time, some companies are doing just fine, and I expect we'll continue to see pockets of stability surrounded by large waves of uncertainty. Has it always been this way? It's hard to say, but my guess is not necessarily. 2012 will be an interesting year to see if politicians and business leaders can continue stabilizing things, or if the wheels will completely fall off. I can't help thinking that the specter of China lingers in the background, just waiting patiently...
2011 was definitely a bad year for dictators, but it's not yet clear if the new regimes will be any more democratic and less repressive. The elections in Egypt and Tunisia seem promising, to a degree, though I think it's too early to be certain if the outcome will be favorable. Iraq is already starting to fall into civil war, and you can just feel the influence of Iran in that area. Likewise, Syria continues to hold on to power, but I can't imagine that will last through 2012. Similarly, the transition of power in North Korea will be interesting to watch, though I will be surprised if we really see much change there (who knows). I'll also be interested to see what happens throughout South and Central America. Will Chavez last another year in power, or will we see a sweep of "Latino/Chicano/Hispanic Spring" movements? Nothing would surprise me.
Speaking of which, the Arab Spring movements were very fascinating to me, not only because of the role of technology, but because of the rapid transition we saw. It piques my interest because I wonder if there are intelligence agencies pulling strings in the background, actively working to destabilize these countries? If so, are we seeing the influence of the US or Iran or China or Israel or someplace else? I'm not a big fan of coincidence, and it seems way too coincidental that all these movements sprang up in quick succession. Then throw in the current anti-Putin protest movement in Russia and it starts seeming rather well-coordinated. On the one hand, I also wondered if the OWS movement was connected, though it didn't seem to have the same type of organization and structure, so maybe not. My guess is that 2012 will reveal something greater behind these changes... I just hope that the outcomes are predominantly positive and don't instead end up in some sort of global military conflict.
Lastly, I hope that 2012 will be a year of great personal growth. For the first time in a while I feel like I'm in a good place career-wise, and am very hopeful that I can now increase my contributions to the industry (no, I'm not talking of a "thought leadership" mythos). There is much we can do, and I think that many of the right pieces have started falling into place. Barring the introduction of absurd regulations like SOPA/PIPA into our cache of requirements, I'm very hopeful that organizations will continue improving their grasp on duties and responsibilities. The way forward is to de-operationalize security duties, elevating "infosec" to a "GRC" program (discipline, not platform), distributing security responsibilities to all personnel, and asserting accountability. Easy, right? ;) The groundwork is lain, the tools are suitably mature, and people are slowly starting to come to grips with this new reality. Sociologically, Boomers are retiring, elevating Gen Xers into leadership positions, helping achieve the necessary "it takes a generation" requirement for full social change. I'm hopeful that 2012 will be a great turning point in infosec, and that we can finally assert the needed paradigm shift.
At the same time, I'll be watching the political movements in hopes that things start to moderate again, and that we can see politicians actually seeking out and accepting input from true experts. Following the SOPA markup was truly depressing at times, with some members of the committee saying proudly that they didn't know anything about technology, nor did they need to hear from experts on the impact of the legislation. Hopefully 2012 will see some of these people and trends fade out in favor of a more informed future. Hey, I can dream, can't I? :)
So, that's it for my ruminations. May you have a happy, productive, positive 2012!
ps: I'm sure I've left out tons of stuff, but that's ok. ;)
pps: Updated to correct a number of typos...
]]>First up, you have to read Jack Daniel's "The Pandering Pentagram of Prognostication" as he absolutely hits the nail on the head as concerns the annual prognostications we see.
Next up, you have to watch the Chris Eng's sequel on "infosec thought leadership," titled "The Thought Leader... One Year Later" - it's so spot-on, it's almost eerie to watch. ;)
Happy Holidays! :)
]]>Risk = Threat x Vulnerability x ImpactAs part of the discussion around "risk" back in those days we also had to talk about what those terms really meant. Broken down, "threat" was really more a matter of "threat frequency" - as in, how likely an attacker would hit your environment. Similarly, "vulnerability" was really more about "probability of compromise" and how likely it was that an attacker would be successful. If you're thinking that this sounds an awful lot like FAIR, then you're right. In retrospect, it's definitely very much inline with that thinking.]]> All of that said, there's one key factor that was always present in these conversations; at least, it was until recently. "Impact" has always been expressed in some form of value, and typically as a monetary representation. The source of that monetary estimate varied widely, and to this day even continues to be a topic of intense discussion. Do you base your estimate on the asset value (whatever that might be), or on a set of related factors a la FAIR (Productivity, Response, Replacement, Competitive Advantage, Fines & Judgements, and Reputation), or do you use something else altogether?
This topic brings us to three key points:
1) "Risk" expressed in the absence of contextualized "impact" is not really "risk."
2) "Impact" needs to be represent a reasonable approximation of "value" to the business.
3) What's really important to the business may not be easily represented in monetary terms.
Does "Risk" Require "Impact"?
At it's most basic, "risk" is the potential for injury or loss. As such, "impact" absolutely has to be represented, otherwise you lose that foundational essence of loss. To talk just about "threats" and "vulnerabilities" (or, my preference, "weaknesses") does not provide a complete enough picture on their own. Just because there are bad people in the world does not immediately mean that you are bearing a reasonable potential for loss. Similarly, just because your environment may have weaknesses does not mean that we will necessarily sustain a meaningful (or material) loss.
As such, when we talk about "risk" it is imperative that we include some representation of "impact" in the discussion. If nothing else, "impact" provides the real-world context that is important when talking about the other major factors. I'm personally fond of the breakdown that FAIR uses, but there are certainly other equally useful methods (e.g., VERIS Framework uses a similar breakdown to FAIR, but then adds in an "Impact Qualification" field that let's a reporting organization qualify the loss as Insignificant, Distracting, Painful, Damaging, or Unknown).
The bottom line here is, quite simply: Any attempt to estimate risk that does not include an impact estimate is, by definition, not a "risk" estimate in that "risk" must represent the potential for loss or injury. This definition derives from standard dictionaries and is not coming from special "risk wizard handbook." Trying to alter the core meaning of this word is at best disingenuous or misinformed, and at worst it is intentionally misleading.
What's Really Important?
Now that we've established that "impact" is important, the next logical question is "What's really important?" In the end, as a community we seem to resort to using monetary value to represent importance, but it's not necessarily the right answer to this question. In fact, before getting into dollar figures, a very strong case can be made for using qualitative labels (with reasonable, non-monetary definitions) to survey key stakeholders to rank what they view as important.
Still, there is that question of "what" and how to pick it. Are we talking about assets? Data? Processes? It's an interesting question, and one that warrants serious discussion, and which may produce a wide range of answers that vary from organization to organization. One customer has suggested looking at business processes, and has had great success using that approach. He started by asking key stakeholders what processes the business used (e.g., accounts payable, accounts receivable, invoicing) and then went through a prioritization/ranking exercise to determine which processes were the most important to the business. It wasn't until after he'd completed these surveys that he then went about translating those processes into data, systems, and financial value.
The key to answering this "What's really important?" question, then, lies in understanding the business at it's most fundamental level. How does work get done? Answering that question will likely lead to an interesting set of answers and, ultimately, a healthier perspective than starting with technology and trying to tell the business that something has relatively value. Starting with how the business operates is a very sensible right approach to determining what is really important.
Estimating Value and Impact
Gauging what's important means trying to assess the value of a given resource. There are myriad ways to go about defining value as you assess what is more important. Impact may factor in, or it may not. In general, I typically think of "value" as being positive, whereas "impact" tends to reflect a negative (or loss). For example, an asset may hold a certain (positive) value for the business, but the impact of an incident affecting that asset may be a different number altogether. (confused yet?)
For assessing "what's really important?" I suggest starting with a simple qualitative approach. The approach can use ranges of impacts, or any other number of measurement units (e.g., asset value, relative perceived importance to the business, etc.). For example, consider these generic impact-like definitions: Note that these descriptions do not define the estimated impact (potential loss) that would stem from an incident affecting the resource, but rather provides a quick shorthand to quickly prioritize resources given their relative value to the business. Consider this initial valuation exercise as step 1, to be followed later by a formal analysis that will try to provide a more robust impact assessment. Remember, too, that you may be estimating the value of a process here, whereas in later analyses you will most likely be assessing the impact for data or systems. In a sense, we're starting with an enterprise risk management outlook to help prioritize business resources, followed by a more detailed operational risk assessment that gets into the details of a specific business resource. In the end, one of the big things to remember is that "value" and "impact" are often not the same thing, but rather different aspects of related topics. Whereas it's not unusual to see the terms used interchangeably, it may not be correct to do so. Starting with a business-oriented, value-based approach can help provide a useful top-level prioritization of business resources. However, that's not the end of the process, but rather the start. Once the high-level value of resources is understood, the next step is to then understand the operational risk affecting those resources, including the impact of various loss scenarios. Conclusion The original motivation for this article is the recent trend of removing "impact" from many "risk" discussions. By definition, "risk" relates to a potential loss, which means that impact must be accounted for in some manner. Beyond that, the discussion naturally turns to how you estimate impact, and more broadly to how you determine what's important. It's too common today to see a lot of security discussions driven from the threat or vulnerability (weakness) perspective, when instead we should be starting from the perspective of what's important to the business. One welcome change in the risk management community is a shift toward discussing operational risk management, which itself flows into enterprise risk management as an important sub-component. Shifting thinking toward operational risk helps us step back from the in-the-weeds mentality that has led to this skewed view of "risk," and instead helps us to look at where the real valuation of business resources lies. Business resources in this sense may (and probably should) be higher-level concepts like key business processes rather than technical assets. That said, we cannot just look at a resource's relative value to the business, but must also conduct a risk analysis that looks at the impact of given loss scenarios, which may represent a greater financial liability than the relative value of the resource (e.g., properly invoicing customers likely has a high value for the business, but compromise of the list of the customers may have a greater financial cost than the loss of ability to invoice for a week or two). Though loss scenarios may look at the business resource, it's more likely that it will look at subsidiary components of that resource, such as data, applications, and systems. I get excited any time we can move forward from a given position and improve upon the status quo. Similarly, I become rather distressed when I see discussions moving in a regressive directions. It's time to put hard brakes on the current trend of discussing "risk" without considering context-specific impact. At the same time, we have a great opportunity to move the state of the art forward, shifting our thinking to an operational risk management mindset, and better aligning our approaches with what the business deems to be important.
- Low: The business can survive without the resource for X days.
- Medium: The business can survive without the resource for Y (
Soooo... rather than be one of those non-constructive criticizers of all things infosec, here are three solutions to the three problems:
]]> 1) De-Operationalize "Security"I first wrote about this notion in 2009 (see here), and it's started to gain traction in a few places, but it still bears reiterating.
There are several problems created when security exists as the responsibility of a standalone team or organization. First and foremost, you have the "enablement culture" problem where people conclude that "security is their responsibility, not mine" and thus proceed without making good decisions. The big take-away point here is this: security is an emergent property or an attribute of existing functions. It's not a role so much as a responsibility.
As such, it's time to disband those dedicated security teams and return operational responsibilities, such as for managing firewalls, IDS, AV, etc., to the operational teams that specialize in, well, operations. At the same time, it's imperative that security become a shared responsibility of everyone in the organization, and that an accountability culture be instantiated around these "new" responsibilities (I put that in quotes because it's not technical new, but will likely be perceived as such).
There are potentially exceptions to this rule as some teams may be justifiable, depending on how your organization is structured. For example, it may be useful to have dedicated resources for incident response management, business continuity management, and audit & assessment. However, those functions can just as easily be rolled under the resultant team or department, assuming they don't have a better home elsewhere. This leads to the next point...
2) Elevate "Security" to "GRC Program"
Once operational responsibilities are abstracted from your "security" team, it is then time to change focus - and name! You're now talking about a Governance, Risk Management, and Compliance (GRC) program. Note here that I'm talking about GRC as a discipline, not as a tool (see here for more on what that means).
Your main objective in elevating the previous practice to a GRC program is to start working as a peer at the senior management or executive level of the business, helping bring together the best information available to assist in making quality decisions while also actively managing liability and various risk factors. The GRC program needs to interface with business leaders, HR, Legal, IT, and any other key teams in your organization.
The GRC program does not exist purely as oversight or reporting, but also as an intelligence function. We've all heard about business intelligence over the past few years, and this is a natural extension of that capability (much as Operational Risk Management is a sub-component and extension of Enterprise Risk Management). The bottom line is that the GRC program will own Operational Risk Management (of which IT/security "risk" is a part), which will in turn feed into the overall Enterprise Risk Management program (formal or not).
One key in transforming into a GRC program is to become a liaison and bridge-builder, as well as an integral part of all decision paths (and not in a bureaucratic way!). The only way to start actively managing liability and risk factors is to have insight into what's going on, an understanding of what's important, and a voice in decisions being made. This position becomes increasingly vital as we continue to see cloud computing, social media, and mobile computing transform enterprise technology and how data is handled.
Lastly, the GRC program needs to take an active lead in helping transform the traditional approach to security awareness. With security being everyone's shared responsibility (and now, per #1, included in everyone's job description and duties), it becomes important to provide people with better tools and support so that they can understand the impact of their decisions before making them. In the future, this may include setting up collaboration and communication centers, as well as possibly exploring the "gamification" of awareness training.
3) Understand the Business
Your GRC program should reflect the core drivers of the business, and your models should be aligned to that purpose. What does this mean? In practical terms, it starts with concepts like "impact" and "value" (a topic for another post), which may mean focusing on key business processes, or assets, or some other vital aspect of the overall business structure. It's important to understand what the business does, how it does it, and how you can make small improvements throughout to improve security without negatively impacting overall value.
Case-in-point... compliance requirements, in many ways, drive me nuts. On the one hand, these requirements are beneficial (especially for consumers). Take healthcare as an example: it's good to have requirements around the handling of nuclear materials used in medical imaging. After all, you don't want radioactive materials just laying around unprotected. On the other hand, regulations can be distracting, if not outright repressive (and depressing!). For example, think of regulations like SOX, which are not very prescriptive, and which gave rise to a renewed audit complex that, for a short time, tried to dictate unhelpful things to public companies.
That said, compliance requirements aren't going anywhere anytime soon. That creates a unique challenge for the GRC program. Learn the business first, and then find out how to introduce and integrate the mandated changes with as little negative impact as possible. The alternative is what we've all seen fail in the past: breaking out the hammers and jack-boots to forcefully drive home the "you must change" message. We're all part of the business, and our jobs are dependent on the shared success of the organization. As such, driving toward a team approach that encourages collaboration and cooperation will be far more useful than a dictated approach; and that means getting to know the business better than anybody else in order to identify opportunities for mutually beneficial improvement.
Wrapping Up...
Obviously, much more could be said (and, if you know me at all, you know that I could probably do just that!;)... however, keeping this as short as possible, I'll just leave you with this one final thought:
"Perfection is not attainable, but if we chase perfection we can catch excellence." -Vince Lombardi
Good luck!
P.S. - Are these solutions "uncommon"? Maybe not (especially with #3). Hopefully in another couple years they'll be mainstream and commonplace! ;)
]]>2) It makes life more difficult. Control for the sake of control can be problematic. Security measures need to be easy and comprehensible whenever possible. Surreptitious changes that negatively impact peoples' ability to get work done is a bad thing, and it will not have a positive outcome for your efforts. Case-in-point, OWASP made a change recently to only allow owasp.org domain accounts to have access to their Google Apps instance. All good and fine in theory, except that it wasn't communicated (that I'm aware of), and it blocked me from conducting chapter business (updating a calendar of all things) because a) my personal account no longer worked, b) someone then had to add my owasp.org account to the calendar, and c) I somehow failed to record my new password for a forced owasp.org account update due to a (potential) security incident and account clean-up effort. If we make things more difficult and don't communicate that changes are happening and why they're needed, then we shouldn't be surprised when people get perturbed, frustrated, or simply find ways to bypass security altogether.
3) It doesn't understand what's important. I have a whole separate post brewing on the topic of "impact" and "value," but let's boil this down real quick: What's important is allowing the business to operate, thrive, and grow. That means not impeding key processes. It means helping ensure that every dollar spent on technology is done so wisely, and not out of some sense of "shiny object syndrome" or because such-n-such vendor says their tech is a "must have" for the year. More often than not, infosec people have a lousy reputation for failing to "get it" in terms of what is important to the business. This topic is well beyond simple IT realignment theory. It's a fundamental disconnect. Your job as a security professional is not to "stop bad things from happening" - it's to protect the business while allowing it to function. Understand all that that statement means and you'll be much better off in the future.
AND... finally... a bonus point to drive things home... says Gunnar Peterson:
We shouldn't look at security as a one off, an isolated department of "specialists", but rather leave the ivory tower and look for tools, processes, and training that help the people on this list do their jobs better. Making it faster, better, cheaper and easier to consume and integrate security services into their daily work is the biggest security influencer of all.
So... a little bit of a rant to help you get through the middle of your week. Fire up! :)
]]>Here's a wrap-up of some recent news, along with a promise to get back on the blogging beat very soon!
Toss in a bit of travel, a holiday, and a heap of sickness and that pretty much rounds out the last month for me. More writing to come soon!
I'm booked into two slots:
LAW-301 - "Hot Topics in Information Security Law 2012" (Panel) - Thursday, Mar 01, 8:00 AM
Abstract: The legal risk and regulatory environment for information security is in a state of constant flux. New regulations, lawsuits and compliance obligations arise on a regular basis. This panel, put on by the American Bar Association's Information Security Committee provides up-to-the-minute reporting on key infosec legal developments, and provides insight into where the law is going in the future.
STAR-304 - "Legal & Ethical Considerations of Offensive Cyber-Operations?" - Thursday, Mar 01, 1:00 PM
Abstract: Certainly nations have the right and in some cases obligation to use cyberspace tools in an offensive manner to defend themselves. What about businesses, do they also have this right? This session will explore the legal and ethical issues surrounding the use of offensive cyberspace by both nations and corporations.
Register here: http://www.rsaconference.com/events/2012/usa/registration.htm
]]>This post has been percolating for a few weeks now. Part of it was triggered as I read Taleb's The Black Swan, part of it was triggered by attending the ISSA International Conference a few weeks ago and hearing the same old quips, and part of it was triggered this morning by reading stories about yesterday's DARPA cybersecurity conference.
The challenge to this whole post is going to be keeping a coherent thread, so let me spell it out up-front: If "securing networks" is your goal, then I hate to tell you, but you've already failed. A strictly threat-centric approach to infosec is the failed approach we've been using for decades, and it's not going to solve any problems. The real problem is that we've lost sight of what is really important (assets!), and are not constructing our environments, defenses, etc., in a manner that is optimized toward protecting those things. More on this later.
]]> The Threat-Centric FallacyRunning scanners and conducting audits and penetration tests are easy. Enumerating threats and weaknesses can be a lot of fun for the assessors, but when done with the absence of asset information and impact estimates, the gleaned results lack context and meaning. Part of this is the old externality ax that Bruce Schneier likes to grind. Take consumers, for example: if their workstations become compromised as part of a botnet, and then used to spam the world, what's the impact to them? If none of their data is lost or compromised, then why should they care? This example illustrates weaknesses and threats without a necessary impact. Similarly, various reports on weaknesses ("vulnerabilities") and shallow threat modeling without any sort of meaningful, customized impact context makes it hard to know how serious to take the findings (e.g., a "serious" bug in a system that contains no valuable data is not likely a "critical" finding).
I'm starting to wonder how much longer we're going to continue listening to threat-centric talk before we realize that it's a failed approach? There are too many unknown unknowns from a threat and weakness perspective to be able to construct an adequate defensive strategy. It is this point that many risk critics have taken away from Taleb's "black swan" concept, and rightfully so. In a threat-centric world, you're always exposed to hidden risks, which are as likely as not to represent black swans (quick def: a "black swan" event must have three attributes: "rarity, extreme impact, and retrospective (though not prospective) predictability").
Here's the problem: If you look at the world through the lens of a standard distribution of threats and weaknesses, then the majority of your time and resources will be focused on the mundane every-day occurrence. Unfortunately, these aren't necessarily the occurrences you should care a lot about. Instead, you need to beware the long tails, where the big nasties lurk. Unfortunately, there's no good way to estimate all those hidden nasties.
Here's the answer: Quit trying to focus so much time and energy on the nebulous unknowables and instead start with what you can define completely. Start with assets.
Assets Are Most Important
Rather than relying on a threat-centric approach, which opens the door to all sorts of problems that are not solvable, it is instead better to start with the knowns. If you don't know what your corporate assets are, then you have no business using the word "risk," nor is there a lot of value in audits and assessments. If you do nothing else, then make it enumerating exhaustively your assets before you go about modeling anything else. Why? Because without the impact context associated with assets and their estimated value to your organization your information is fatally incomplete.
What's equally important here is this key point: You can exhaustively enumerate your assets and their associated values (to your organization). This is not an area where you're faced with such an extreme of imperfect data. In fact, in terms of statistical confidence, my hope is that your business would have a very good handle on just how valuable each asset is to the business. The only real uncertainty that I foresee would be in dependencies and externalities (e.g., value of assets to those outside your organization).
There are numerous benefits to starting with an asset-centric analysis. For starters, you can actually provide a useful impact context for various enumerated weaknesses and threats. For another, this should provide a ready shorthand method for prioritizing your defensive strategy. And, for one more thing, starting with asset profiles means that you'll be better positioned for modeling out threat scenarios going forward.
The main point here is this: Asset information leads directly to impact data, which is the key starting point for any analysis. Why? Because it's likely foolish and unnecessary to spend time and money running an in-depth analysis on various risk scenarios if the assets being analyzed have little or no value to the business. Moreover, while it can be interesting to have some threat and weakness information on various assets, you can never truly be exhaustive in these enumerations, bringing an analysis back to the relative importance of the given asset, either independently are chained through various dependencies.
FAIR, Black Swans & BCM
One of the more common criticisms of quantitative risk analysis methods (like FAIR) is that the Threat Event Frequency estimates are at best ballpark and at worse way off base. Since Taleb's The Black Swan was introduced, the din has grown around the artificiality of these estimates. I, however, am not so concerned, and I'll tell you why: FAIR is greatly for doing your "everyday risk analysis" where a normal distribution is adequate. Sure, it doesn't generally account for the long tails much (though that does depend on how many rounds you do in the Monte Carlo sim), but that's not necessarily pertinent, either. If it did account for the long tails, then the analysis would inevitably be skewed, since that's the effect of a "black swan" event.
On the flip side, there absolutely is a risk discipline analysis that is ideally geared toward addressing the "black swan" events, and that is business continuity management (BCM). Whereas your routine risk analysis with tools like FAIR can help guide your daily decisions, BCM is inherently focused on a higher purpose: survivability. As such, a good BCM program will spend a lot of its time looking at the long tails that include the "black swan" type events, but from the perspective of how to minimize the impact of a major event and how to quickly recover. In this sense, "prevention" is not so much a concern as "detection" and "correction" are. Recoverability and resilience are the key attributes that a BCM will often look at, whereas on a daily basis you're going to also consider preventative actions.
Ultimately, though, both of these analyses come back to asset-centrism; that is, if you don't know what is valuable to the business, then you won't be able to build contingencies and protective measures around them.
There's a Time and Place...
Now that I've dismissed threat-centrism, let me just say that I think there is definitely value in using threat-centric analysis methods, though with the caveat that it needs to be in a properly contextualized environment. Specifically, once assets have been enumerated and valued, it then may be useful to add threat modeling analysis.
Similarly, weakness enumeration techniques are also useful and valuable. In fact, from a purely operational perspective, running routine vulnerability scans can be provide tremendous value to ensure that patching and access management are properly configured and deployed.
However, in both cases it is still imperative that asset data be enumerated and available. Running scans that return findings is useful, but only if it's applied to assets that have a reasonable value. Asset value data can assist with prioritizing which systems get remediated first, as well as helping to ensure that resources are properly tasked. Fundamentally, this is the much-fabled "IT-business alignment" problem, but into concrete terms.
A Top-Down View of Risk Management
When all is said and done, there will always be a range of perspectives to consider. Much of the discussion here pertains to a top-down view of the enterprise, which is most concerned about financial impact. Operational teams should also be concerned with financial impact, since making money typically helps pay for things like salaries. Even for organizations that aren't profit-driven, it's still imperative that ops teams understand the relative value of the assets they're supporting.
Starting with asset information is a reasonable point because it's not as subject to the "black swan" phenomenon. In general, you should be able to exhaustively define all your direct assets and know their relative value to the organization. Where uncertainty crops in is with threat and weakness enumeration, which is where we then move to the bifurcated risk management approach, leveraging standard risk analysis methods using normal distributions (or equivalent) on the one hand, and BCM on the other hand to account for potentially catastrophic "black swan" events that hold the potential for inflicting material damage.
In the end, without a proper asset context you can't achieve a reasonable impact assessment, which in turn will negatively impact the reliability of things like remediation prioritization schemes. It's thus imperative to spin-up better asset inventory and valuation now before things get even further off-track than they already are.
There, I said it. No, seriously, if you listen to all the "risk" haters out there these days, you'd swear that the failings or limitations of a risk assessment or risk analysis methodology was equivalent to "proof" that risk management as a whole is faulty and a failure. Nothing could be farther from the truth.
Case-in-point: Many people, who don't have any training of or understanding about quantitative methods like FAIR, love to hate on those methods because of the "imperfect data" argument (newsflash: all data is imperfect). "We don't know what we don't know, therefore it's all wrong." The response to that quip is a separate post (coming soon!), but suffice to say, limitations of a specific method DO NOT prove that an overall management process is somehow inadequate, wrong, or a failure.
The 2008 credit crisis is not the result of poor risk management. Rather, it demonstrates the failure of traditional ORM risk assessment / risk analysis methods, which failed to properly account for a number of key risk factors, and which also overlooked major exposures (for more on this, see the "Modern ORM" paper).
So, the next time someone tells you that "risk management is a failure," please ask them not to throw out the RM baby with the bathwater, and instead prod them into explaining their quip, which will inevitably lead to complaints about risk assessment or risk analysis, which is not equivalent to RM.
That is all.
]]>
As a rule, I try not to toot my own horn too much. There are far smarter people out there. That said, I thought you might find the following articles of interest:
Big Fat Finance Blog: "Risk Chat: Is Your GRC in the Cloud?"
CRN: "How to Manage Cloud Risk"
The ISSA Journal (November 2011, Volume 9 - Issue 11)
"Scaling Risk Management"
Also, I highly recommend joining the ISSA!
]]>Rather than recap things in too much detail, I figured I'd just riff on a few themes that I noticed (or have arbitrarily declared)...
There were two key federal speakers: Gen. Alexander (US Cyber Command) and Shawn Henry (FBI). Both talked at length about the move to the cloud, and confirmed the news we also heard simultaneously from the intel sector that the US Government is moving to "the cloud." So, yeah... NIST has recently finalized SP 800-145 defining "cloud" for everyone... and now, watch as apps and data head that way. It's going to pose an interesting challenge, but nothing I'm sure they won't be able to out-botch. ;)
In all seriousness, though, I think there is reasonably good potential that moving to cloud-based services will help reduce costs. Although, at the same time, I can't help being a bit cynical since major government contractors could easily pick up the servers they've been running at agencies, move them into off-site data centers, and then declare it "cloud" and increase the cost for doing almost the exact same work (plus the actual hosting). And, this assumes a case where they're not already hosting. Anyway...
Suffice to say, "cloud" will continue to be a hot keyword for the fed sector for the foreseeable future.
That Old "Cyber Crime > Drug Trade" Schtick
The other thing trotted out by both Gen. Alexander and EAD Henry was this notion that cyber crime now costs more than the drug trade each year. It's unclear to me the actually source of this assertion, though I vaguely remember reading a blog post recently that debunked the myth, tracing it back to an old vendor report of some sort that did some fuzzy logic and bad math.
That said, "cyber crime" is certainly impacting life and businesses - enough so for the SEC to issue that guidance on reporting the material impact of cyber risks within quarterly reports by public companies. This is very much a "David v Goliath" type situation, too, in that there's really no realistic way to staff-up defensive forces or law enforcement agencies in order to fully pursue and prosecute attackers.
At any rate... actual losses may be farther away than what we are hearing, but to know that would require a whole lot more reporting and information sharing... which was another related topic mentioned during both talks, along with renewed calls for increased public/private partnerships (always a rally cry, never a success?).
These Problems Are Hard
One common thread from various conversations and a few talks is that there are many hard problems to solve, and none with any obvious answers. Risk assessment and analysis? Difficult. Prioritizing bugs or IT projects? Difficult. Trying to get people to agree to a common set of definitions around key terms like "risk"? Darn-near impossible. And so the litany can go on...
Of course, while there are certainly difficult problems, there are also lots of unqualified people willing to talk about these problems. For example, I suffered through a talk by an auditor dude who didn't understand the first thing about risk management or risk assessment. He criticized risk analysis techniques, but wanted to discard all of risk management as a result. Yet, he described as preferable fairly standard risk mgmt processes. *shrug* Most interesting was this little exchange:
Me: "If risk management is out, then how do you prioritize what work to do first?"
Him: "You fix the simple things first."
Me: "Ok, a follow-up. Say I've fixed all the simple things... now what?"
Him: "I don't know. There's no good way of dealing with this today."
Ummmm... yeah. No doubt. So, that was interesting. That said, I also had a good conversation with a really smart dude about prioritization, and while we didn't reach any conclusions, we certainly realized that there are some interesting challenges, particularly with defining the problem-space (what's the desired outcome?), that make developing solutions a bit of a challenge.
Maturing Risk Management: Learning to Talk to Grown-Ups
Two of the more interesting sessions I attended talked about, well, how to talk to the execs and board about security. One was a CISO/CSO panel that spent a good amount of time talking about this topic. They discussed how you can't just go throw around FUD these days, or ask for blank checks, but rather have to approach business leaders using business language in order to frame business problems.
The other good talk was specifically on how to speak to execs, spending a fair amount of time on do's and don't's. It was very interesting, though mostly intuitive, or so one would hope, though perhaps it's not nearly as intuitive as I thought it might be. ;) Mainly, a lot of the tips were inline with what the panel said. Don't drop bombs on the execs, empower them to make good decisions, avoid "told ya so" moments, and so on. Overall, good stuff!
---
So, that's my summary. It seemed like a smaller turnout this year, perhaps due in part to Raleigh ISSA having a conference at the same time. I've not heard official numbers, but I'd be surprised if it was more than a 300 people (Raleigh drew >400). The vendor expo area seemed much smaller this year than last year, which had to be a bit disappointing. Overall, I don't think attendees were as happy with the venue or level of organization (or, chaos) present. Hopefully next year we can rebound. I know that one pressing issue on the minds of chapter leads was how to make/keep ISSA relevant today in light of all the other security-oriented groups around. Talk about a hard problem to solve...
Please join me in sending positive thoughts, energy, prayers, or whatever your belief system may condone toward his full and speedy recovery. I also encourage you to join me in donating to the fund that Social-Engineer.org has setup to help defray out-of-pocket expenses.
Donate here: http://www.social-engineer.org/bradsmithdonation/