First, a quick primer on FAIR and loss estimates: In estimating losses, FAIR splits the estimate between direct losses to the primary stakeholder and losses triggered by secondary stakeholders. Losses are then estimated (using calibrated ranges and confidence statements) in 6 categories: Productivity, Response, Replacement, Competitive Advantage, Fines & Judgments, and Reputation. In most cases, the first 3-4 categories tend to be primary losses, while the last 2-3 tend to be secondary losses.
However, let's now turn this around to the public sector. Assuming that they're the primary stakeholder, and that the public and other entities are the secondary stakeholders, can we produce a reasonable loss estimate? First off, let's think about those 6 categories... we can immediately remove the last 3 (CompAdv, F&J, and Rep) as not applying. The government doesn't seem to fine itself, and there's really not much you can do if they're compromised. After all, so long as you're within the borders of the US, you're subject to the US Government. It's not like you can physically stay put and opt out to a different government. This just leaves us Productivity, Response, and Replacement. Leaving "government productivity" jokes aside, it's pretty clear that any loss estimates here should be fairly low, and thus not necessarily meaningful or compelling. So, perhaps this is a failed approach...
What then would be a better approach? One notion floated is to flip the stakeholders. What if you were to first estimate the loss to the public as the primary stakeholder, and then considered other costs (such as to the government itself) as the secondary stakeholder losses? That is perhaps a lot more interesting, since there may be some reasonable arguments that the compromise of certain datasets will have a sizable negative impact on the public (especially when viewed as a whole - so each individual loss rolled up to a large aggregate). Suffice to say, this line of thinking certainly opens the door to a more compelling analysis, and it's definitely worth exploring further...
What do you think?
]]>Using an analogy to healthcare or epidemiology is certainly not a new thing. Some circles have been talking about this idea for quite a while. In fact, one need only think about malware being referred to as "viruses" to get an immediate connection. It's also fairly similar to the ecological analogy that some have posed in the past, particularly as it relates to application security.
That said, I noticed this week at Secure360 that many risk management people were now talking about the analogy to epidemiology, not only as it relates to evidence-based medicine and evidence-based risk management, but also as an overarching concept.
I've not had adequate time to fully parse through this notion, but intuitively I rather like the concept. It seems to map fairly cleanly to many security and risk management problems, and it certainly aligns very well with the imperative for business survivability. Whether it will continue to hold-up to other practices remains to be seen, but for a starting point we could do much worse. It also provides a very good case of where compliance regimes can be beneficial (think of all the places where checklists are relied upon to ensure patient safety and wellbeing).
Once this idea has had some time to percolate, I'll try to loop back and write more about it...
Personally, my favorite part of the conference was the "risk practitioners' panel" that I helped organized (I know that sounds a bit ego-centric, but it was a lot of fun!). It was great to have such a range of talented, experienced risk management professionals talk about their experiences, challenges they've encountered, and how they see the future unfolding.
Given the success of this inaugural event, I think it's safe to say that there will be another. It's obviously way too early to say when and where it will be, but it'll definitely happen. We hope that you'll be able to join us next time!
]]>The point to this mild rant is simply this: the more deeply politicians seem to get involved with cybersecurity, the worse things seem to get. And, lest we be led astray, we should not forget that, aside from the Education sector, civilian agencies in the federal government are perhaps the worst offenders when it comes to failing to implement reasonably solid cybersecurity. There are a few reasons why I think this is the case.
]]> 1) NIST Is Not the AnswerI've already written a bit about standards devolving into compliance regimes. However, there's more that needs to be said on the topic, especially as it applies to NIST and FISMA. Of all the compliance regimes I've seen, the one operated by the US Government is the worst offender in terms of ignoring reasonable risk management functions in favor of mindless compliance with requirements that may or may not make any sense in context. Let's look at three examples of where NIST fails.
RMF and "Worst Case Scenarios"
NIST's Risk Management Framework (RMF) is a prime example of compliance regimes gone bad. If RMF were to lead to performing actual risk analysis, then perhaps things would be better. Alas, it's not the case. In fact, it's worse than you might imagine. Rather than not doing risk analysis, they actually advocate doing a very poor approximation based - not on what's reasonable or realistic - but on "worst case" scenarios. It's no wonder everything in the federal space seems to be driven by FUD.
Evidence of this allegation can be found in response to the first question listed under the RMF "Step 1 FAQs" - "1. WHAT IS SECURITY CATEGORIZATION AND WHY IS IT IMPORTANT?" - which says:
"The security category is based on the potential impact (worst case) to an organization should certain events occur that jeopardize the information and information systems needed by the organization to accomplish its assigned mission, protect its assets and individuals, fulfill its legal responsibilities, and maintain its day-to-day functions."
DOE RMP & ESCRMMI
Similar thinking is now emerging within the world of the energy sector, and specifically through the DOE "Risk Management Process" (RMP) - adapted directly from NIST RMF - and the DOE "Electric Sector Cybersecurity Risk Management Maturity initiative" (ESCRMMI), which is not about risk management, but rather about assessing security capabilities in electric sector organizations.
There are many issues around the energy and electric sectors (critical infrastructure in general, really), and this post is not about that. Rather, the key here is to note that the government is once again pushing a prescriptive approach, rather than trying to legislate to a desired outcome. Oh, sure, they think they're driving toward an outcome, but the problem is that their approach is outdated, provably wrong, and detrimental to cybersecurity improvements. These approaches are being sought because of the perception that the NERC CIP requirements haven't been adequately met, and that the electric sector is so woefully insecure that a catastrophic event is in the offing.
Of course, as noted above, we should not be surprised by this fatalistic mindset based on "worst case" thinking - it's how they view "risk assessment"! However, it's also worth pointing out that electricity is still quite reliable and that, despite incidents and outages, the built-in fail-safe reliability measures have - by design! - prevented a major catastrophe. Unfortunately, any risk assessment and analysis that does not take into consideration the probability of given scenario impacts will overlook these truths in favor of FUD and rhetoric. It should give us pause and make us question the agenda(s) that may be in play (e.g., DHS and US CyberCommand perhaps making a play for more direct control over critical infrastructure cybersecurity - not that they have any track record of success in this space!).
Quashing Innovation Through Specificity
All of these various initiatives have one thing in common: They're overly prescriptive, leading to mindless compliance regimes, and resulting in a detrimental impact on creativity and innovation. If the government applies it's old school thinking to the problem, and then prescribes in great detail their old school approach, then we should not be surprised when a) it fails, and b) it causes people not to seek improvements, but to simply do (and think) less. We do not need more mindless compliance today; we need more innovation!
2) Poor White House Leadership
One might want to eagerly attribute government compliance regimes to Congress since they are ultimately the ones who created the organizing frameworks. However, I think that attribution would be misplaced. Specifically, I think that the White House is increasingly to blame for the wrong directions being followed. Many had high hopes when Howard Schmidt was appointed as Cybersecurity Coordinator for the Obama Administration. Unfortunately, if what I've seen and heard lately is any indication, the wheels are coming off this crazy train, and fast.
Lest you think this is just random innuendo, consider a couple examples... the first is DOE ESCRMMI (mentioned above)... there were a couple interesting attributes to this project. The "ask" from the White House was "assess the security capabilities of electric sector organizations." Somehow this turned into a CMM-style "risk maturity model" that has little to do with "risk" and isn't even really about measuring capability maturity. Rather, an incredibly short timeframe (by government standards) was set to get the assessment running (about 4 months). As such, those behind the initiative appear to have spent more time going down a familiar road (e.g., building off of the Smart Grid CMM) rather than researching and evaluating other viable methods. Ultimately, this comes directly back to the White House.
In at least one other case, I've heard anecdotally that the White House is pushing back on a current line of innovation, questioning the trustworthiness of key components, and advocating an alternative approach that essentially scraps the entire innovation, with the added "plus" of asking for a complete 180-degree flip in data flow (as if this is something that can just be magically done). No clear indication has been revealed thus far as to why their approach - which seems to cater to the whims of auditors (because they're never wrong) - would be preferable. Suffice to say, it's frustrating to be an industry where innovation ends up being actively undermined by people living in an antiquated mindset. Why enable the current failed practices when the important aspects can be automated, freeing traditional resources (like auditors) to focus on more important concerns? (btw, this is not a new problem - it was mentioned at least as far back as 2010 when the current wave of "continuous monitoring" initiatives were starting to gain traction)
If only this was our only challenge...
3) Counter-Productive Legislation
If we're looking to politicians to solve our problems, then I hate to say it, but that's just one more thing we're wrong about. More importantly, we do not need inexpert politicians telling us how to do our jobs. Rather, where regulations are often most effective is in legislating a desired outcome, such as legal defensibility, survivability, or data privacy. Alas, in this age of insipid corruption and excessive corporate influence, we are seeing regulations that are increasingly detailed, and obviously designed to either benefit specific special interests, or be so detailed as to be unsupportable.
To make matters worse, we seem to be in an era of unprecedented government overreach, with politicians not only selling-out wholesale (such as with ACTA and SOPA/PIPA), but also trying to grab more and more power in the digital realm (such as with CISPA).
So, to bring things back full-circle... not only are we seeing exceedingly specific pieces of legislation, sponsored by unqualified amateurs, based on grossly outdated concepts, and serving the needs of special interests, but they're also written in such a way that they expand the role and power of the central government, which cannot even seem to secure its own systems. This doesn't strike me as a recipe for success. In fact, I think I'll go so far as to say that "no good can come of this."
More importantly, we need to mindful of any regulation that is so specific as to dictate how to do cybersecurity. Such a bill is not productive, and is immediately in danger of becoming obsolete and ineffective before it's signed into law. Instead, the focus needs to be on legislating toward a desirable future state; one that puts a premium on rigorous, defensible risk management, increased visibility and detection, continuous monitoring and reporting that helps shorten the lifecycle on incidents, and an overall approach that ensures survivability rather than implementation of arbitrary controls that may or (more likely) may not make any appreciable difference.
Closing Thoughts
Allow me to close by doing what I've done many times in the past: drawing a parallel with education. We've seen the impact of No Child Left Educated (er, Behind). Schools have shifted dramatically away from "education" to "training," with the end result of teaching to test, incentivizing teachers to cheat in order to save their own jobs, and an overall effect of decreased educational quality. This is a prime example of federal government overreach making a bad situation worse.
Now, in contrast, let's look at the public school system in New Orleans. Yes, that's right, New Orleans - the Big Easy - a notoriously low-end urban environment that historically produces violent drop-outs. According to a recent OpEd in the Washington Post, the schools there have started improving dramatically in the aftermath and recovery from Hurricane Katrina in 2005. Why? It seems that the local politicians have gotten out of the way of teachers and administrators, and have shifted to a more outcome-oriented approach. With a directive to make the schools better, and holding people accountable, the results are quite interesting.
The only major negative I still see in the piece is the use of standardized tests as the benchmark of success. As such, this may just be an example of effectively teaching to the test. However, the point still stands: performance increased while politician intervention decreased. In general, innovation thrives when it's not being actively quashed by those in power.
Suffice to say, it's a small victory, but a positive sign. Hopefully it's an early indicator of changes in other areas, including changes in cybersecurity. If ever there was a time to innovate and start demonstrating a better reality - one that beats out the constant deluge of FUD - then now is it. We can get there by making better use of risk analysis techniques, as well as by demonstrating that reasonable outcomes are achievable. Showing positive changes that break from the failed mindset(s) of the past would be a great way to counter all the bad changes that the US Government has been promoting as of late. Here's to hoping for a better future!
]]>First up in May is the inaugural edition of the Society of Information Risk Analysts conference (something we hope to host annually). This is a 1-day event hosted at the same venue as Secure360, and it's very affordable ($119, $99 for SIRA members - membership is free!). Check out the event site (linked above) for full details. I'll be moderating the "Risk Management Practitioners Panel," which will feature some great panelists talking about their real-world experiences with risk management and risk analysis, including a promising discussion on how to find qualified candidates and how to improve education for upcoming graduates to help improve risk management teams.
This will be a relatively small event, which means there will be lots of opportunities for interaction, discussion, chit-chat, and in-depth discussion of all things "risk." If you have any interest in the topic, then I highly encourage attending!
Secure360 - May 8 & 9 - St. Paul, MN (River Center)
Next up will be me 2nd time at the Secure360 conference in Minnesota. I was very impressed by the event last year (2011), and eagerly submitted a couple talk proposals. I'm slated to deliver my talk "Back to Basics: Pragmatic Risk Management For the 99%" on Day 2 (Wednesday) at 11:15am (abstract below). There will be several other awesome talks that I highly recommend. If you're anywhere near the Twin Cities, then I hope you'll be able to make it out for what promises to be another excellent event!
Abstract:
"If you've spent any time investigating how to build or mature a risk management program, then you've likely had at least one moment where your eyes have crossed and you've thought "who would ever do this?" Much of the current literature comes to us from the financial services sector, but very little of it seems to translate well to other industries; especially not to the more than 99% of U.S. employer firms who qualify as small businesses. This situation begs the question: Just what can and should organizations be doing? This presentation will demonstrate how to make pragmatic use of risk analysis in any business and discuss how to scale risk management practices while still having a positive impact."
Rocky Mountain Information Security Conference (RMISC) - May 18 - Denver, CO (Sheraton)
The next week I'll be making my secondary appearance at RMISC in Denver. As was the case with Secure360, I was also very impressed by the quality of RMISC. They brought in many excellent speakers and did a good job creating networking opportunities for attendees to encounter sponsors. I expect this year will continue to build on the previous success.
For my part, I'll be delivering my talk "Cloud Control: Assurance in a Massively Scalable World" at 1:15pm (abstract below). This is a talk that I first developed last Summer, but that has only started to come into its own this year. I'm very much looking forward to giving it in this venue!
Abstract:
"Ubiquitous access to data and applications is here. No longer are our resources confined to enterprise networks and data centers of our own making. Rather, applications and platforms are now available on-demand, anywhere, anytime, to virtually anybody. Moreover, these environments can scale on demand, automating what has traditionally required expertise in system design and capacity planning. Assuring security in this environment poses new and evolving challenges. While they may resemble the same obstacles we've been managing for decades, they are increasingly more difficult to address. Now, more than ever, companies need to extend their governance, risk, and compliance initiatives to take cloud-related strategies and initiatives into account to proactively protect their data and their bottom line."
NESCO Town Hall: Security Risk Management Practices for Electric Utilities - May 30 & 31 - New Orleans, LA (Marriott)
My last stop in May will be in New Orleans, LA, for a NESCO Town Hall event. This will be a fairly quick event, split over 2 days, crammed full of great speakers and panels. For my part, I'll be participating on a panel titled "What Risks Are We Trying to Manage?" that will explore the role of risk management in the electricity sector and how we can (hopefully) get the "cybersecurity" side caught up with the rest of the average organization. Overall, this should be an interesting experience. I'm very much looking forward to the conversation and the types of questions people will raise.
See you out and about!
]]>What got the wheels turning for me was an article I read back in March on The New York Review of Books blog titled "Age of Ignorance". In the article, they pointedly lament what seems to be a rush toward idiocracy and away from a more golden time where intelligence, academia, and open-ended R&D were considered positives. In fact, tying this back into the security meme of my blog, they marvel at even the most fundamental failing of our current society to even know our own basic histories, pinned largely on extremism on both ends of the political spectrum, and representing a very 1984-like reality.
]]> So, what does this have to do with infosec? Well, for one thing, it means we're oftentimes getting ourselves bogged down in fighting the wrong fight. Rather than wagging in futility at all the various attacks using half-baked or long-since-deprecated approaches (e.g., AV, firewalls), we should probably be working with people to help them truly raise their intelligence on properly handling data. Unfortunately, this is not an easy task.3 Practices to Encourage Improvement
In order to address these societal differences, we must then start modeling appropriate behavior while actively educating people on the thought processes involved and the analyses that should be applied. And, when all is said and done, we must hold people accountable for when they violate the rules and decisions that have been rightly made.
1) Apply good risk analysis within discussions. It's imperative that we first model better behavior. A key part of this will work toward de-operationalizing infosec and bifurcating the former infosec organization into standard IT operations and a GRC program. The hallmark of this shift is to quit flogging technologies and solutions without first performing a reasonable risk analysis, as well as walking others through the analysis. It's this last part - of actively educating people through routine discussion - that is perhaps the most important point. Doing this is nothing less than modeling the desired behavior that we wish others to exhibit in the future.
2) Clearly articulate expectations. One of my favorite quotes from my Dad is "if you never communicate your expectations, then you shouldn't be disappointed when people don't meet them." If you don't clearly state what people are expected to do (and why!), then you're not creating an environment that will easily or readily achieve your definition of "success." There are many ways to communicate expectations, such as through policies, controls, awareness activities, assessments, audits, continuous monitoring, etc. The key is that all of these should be turned into educational tools, and presented in a manner that is not designed to attack people, but rather to help them and make them feel empowered to make good decisions. This might sound like a bunch of psycho-babble, but the basis is sound: if you want people to modify their behavior, then it has to be easy, makes sense, and benefit them in some way.
3) Establish an accountability culture. Part of maintaining a healthy learning culture means allowing people to experiment, innovate, and - yes - even fail. However, this does not mean allowing people to operate in a consequence-free environment. If there are rules in places (preferably properly vetted ones), then it's imperative that those rules be enforced, with infractions flagged and violators sanctioned. How your organization accomplishes this can vary widely, but it must be meaningful and have a deterrent effect. At the same time, we should also be looking for ways to prop up laudable practices, further modeling the desired future state; just so long as we don't get so caught-up in being positive that we overlook violations that inherently threaten the stability, success, or security of the organization.
I was tempted, in writing the subtitle above, to call these "simple steps" for improvement. However, when you think about it, these steps are anything but simple. Sure, the concepts are straightforward, but the execution is typically very difficult. As such, make sure to set reasonable expectations for yourself, your team, or your organization when undertaking such initiatives. Consider yourself an education, but contrary to the old "those who can, do; those who can't, teach" insult, you are a "can do" educator who is active in your field.
Good luck!
Note: Updated 4/19 to correct a rather significant typo... if you don't communicate expectations, then you *shouldn't* be surprised when people don't meet them...
]]>The story starts out set in Washington, DC, where we follow perennial slacker security uber-genius Frank Adversego, currently stumbling through a job at the Library of Congress (LoC), thanks in large part to his former mentor tossing him a lifeline. All of a sudden, things start going very bad, first at the LoC, and then elsewhere, and all fingers point toward Frank. Spin in some not-so-friend inter-department uncooperation between the Bureau and the Company, a little bit of international intrigue, and the threat of nuclear war, and you have a fun techno-thriller.
Overall, the techies in the crowd will enjoy this book, even though it manages not to get down in the weeds. Non-techies will likely still enjoy the pace and story, as well as a couple patient explanations of the more technical topics as delivered to Frank's daughter Marla. In the end, this story has a little bit of everything in it, and it even has a couple friends twists and turns that will keep you a bit off-balance.
The book is only $2.99 for Kindle, so hurry up and check it out! In doing so, you'll be helping promote an up-n-coming author from our own infosec ranks, with the promise of more to come!
]]>In thinking about this question a bit today (while reading-up on NIST RMF), I started thinking about how this notion fits into risk management approaches. Specifically, in looking at RMF, it appears that rather than achieving a true risk management program, NIST has essentially created a very heavy, bureaucratic compliance regime. Now, I don't think this was even remotely their intent, but rather wonder if it's really just an inevitable outcome from how we as an industry have historically approached information/IT/infosec risk management.
]]> A Quick AnalysisI'm going to assume that you agree with the assertion that most applications of technical standards do, in fact, devolve into compliance regimes (if not, please just play along). When I say "compliance regime," I'm literally talking about going away from a judicious decision process based on a reasonable risk analysis, and instead falling into the rut of "these are best practices, we must do them" followed by "we're the auditors, and we're here to check the boxes." It seems to me that the very act of recording detailed implementation requirements means an inevitable slide into a compliance regime. After all, if you've decided to make something a requirement, then all that's left is to make sure it's implemented, right?
Now, mind you, I'm not (necessarily) saying that this is a bad thing, at least in terms of an actual operational response to levied business requirements. However, the problem comes when this becomes the heart, if not sole component, of the security and risk management program. I'm sure you've been in one of those conversations where someone (often an auditor or pentester) says "you should implement change X" and you say "really, why is that?" and their response, quite plainly, is "well, it's an industry best practice." Hopefully you hear screeching brakes in your mind as you try to stop this statement cold in its tracks. "Just because" or "because I said so" is rarely a good business reason for making a technical change; especially if it's going to cost money to implement (and, pretty much everything does).
All of this brings me back to two related notions: 1) That security and risk management should be deoperationalized into a comprehensive GRC program (GRC as a discipline), and 2) That the duty to implement security requirements should be relegated to true operations teams, which are in turn abstracted from the decision and enforcement authorities (i.e., from those who set and enforce the requirements).
How To Solve The Problem
Ultimately, I don't think a compliance regime at the operations level is a bad thing. In fact, I think it could be very useful, a la Gal Shpantzer's discussion of using procedures to minimize errors in his talk Security Outliers: Cultural Cues from High-Risk Professions. That is to say, IF the requirements specified have a proper vetting and risk management basis, THEN it is absolutely, positively appropriate to allow them to devolve into a compliance regime.
However, this then opens up an interesting challenge. If we're ok with allowing technical security standards to devolve into a compliance regime that makes use of checklists and well-documented procedures, then how do we make sure that those artifacts are in fact derived from a reasonable lineage? The answer is "a risk management program," though I can't say it's "just that simple."
What does this mean? First, it means you need to have a formal risk management program in place. Second, as part of that program, you need to have a reasonable risk assessment capability that can be used to vet the organization in determining context and respective value classes. Third, you need to then bring requirements through the risk analysis process to understand their business impact within each respective value class (e.g., different portions of a networked environment will vary... all data and systems are not created equal, and context is everything!). At the end of the day, this may mean having different sets of technical standards for each value class, which then must be enforced as appropriate. There will also likely be some common core requirements, such as around monitoring, response, and routine assessment, though even some of the specifics there may vary (e.g., a low priority system may not need to be recovered as quickly as a high priority one).
Today much of this may look like manual effort, though this is changing. Specifically, we're starting to see movement toward integration of tools like security configuration management with audit and compliance management products that allow for mapping of resources, control requirements, and implemented controls to continually monitor and report on the state of each environment. Similarly, integration with risk management capabilities furthers this integrated approach such that the mandated controls can go through a vetting process before being published into the compliance regime for administrators to deploy.
The last question that all of this may raise is if it's worth it, and if so, how to measure it? The answer is two-fold. At the operational level, measuring the state of compliance should be sufficient, combined with monitoring and response capabilities, assuming that proper risk management consideration has gone into the specification of control requirements. At the strategic level, there is then an increasingly important need for a formal, well-defined, well-documented risk management process that leads to legally defensible decisions that help the business establish reasonable risk tolerance and risk capacity levels, and that ensures business survivability (because survivability should be the goal, rather than the failed perspective of trying to stop all badness from happening). Note, by the way, that following this bifurcated approach is then fully compatible with outsourcing arrangements, such as with cloud services providers, at least provided that specifying and enforcing reasonable controls is written into the contract and SLAs.
So, to conclude the post... yes, a compliance regime does seem to be inevitable when specifying technical security standards, and that's ok - provided that there is a reasonable GRC program in place to ensure that the dictated standards are appropriate, reasonable, defensible, and enforce the survivability mission.
]]>For full details, please check out the event page at www.societyinforisk.org/siracon.
Tickets are now on-sale at siracon.eventbrite.com. The cost is $119, though there is a $20 discount for SIRA members (it's currently free to join, so ping us if you need the code!). Lunch, snacks and refreshments will be provided by the facility and are included in the price of admission.
There is also a special student "cover the cost of food" discount available (please email me for details). Speakers and volunteers are free - if they want to be - OR they can pay the "cover the cost of food" discounted price in order to help SIRAcon achieve it's objective of breaking even. :)
Here are a some of the titles from the confirmed talks:
* Rolling with Resistance: Because Risk Management Isn't Just About Being Right
* Organizing Risk Management Programs, or, What I Learned from the Secret Service and the Aviation Industry
* The Base Rate Fallacy: How Fourfold Tables can help in Information Security
* OpenPERT: Modeling Expert Opinion
* Risk Management Practitioners Panel
We hope to see you in St. Paul this May! :)
]]>As per usual, I didn't make it to as many talks as I wanted to, but I did see a couple, and they were great. I also got to see the Flash Talks (PechaKucha), which were all good. Especially funny were the talks by Mike Rothman and Hugh Thompson (Hugh's being the best - his timing was impeccable!). If you ever get a chance, then please go see the Flash Talks as they were great!
It was awesome catching-up with so many people, meeting so many new people, and just generally being surrounded by people from the industry. Last week was by far the busiest conference week I've experience, and yet - as exhausting as that was - it was enjoyable and survivable.
A huge "thank you" is owed to David Spark and Tripwire for doing a bunch of great interviews again this year. You can check mine out - Are All These New "Risk" Tools Actually Risk Management Tools? - below.
I very much enjoyed the closing session. Hugh's guests Dan Gardner and Frank Luntz were interesting - especially Luntz, who wrote the book Words That Work: It's Not What You Say, It's What People Hear, when he spoke about the messaging the security industry should be using with customers, speaking to their (the customers') desire for "peace of mind."
Lastly, former-PM Tony Blair was also an interesting speaker despite being out of his depth on the topic. I didn't feel that he was quite as good as former-President Bill Clinton was the previous year (Clinton covered lots of economic stats), but otherwise he was very solid. His Q&A with Art was especially impressive (way better than Clinton's). Despite not having any depth in the topic, I think he had a solid implicit understanding of things, which came through with solid comments.
It's time to close the book (mostly) on this RSA and start thinking about next year (already!). Let's hope 2012 is as productive as I feel like it can be right now given all the positive energy coming out of the conference.
Update: I can't believe I forgot to mention one very important session! Hands-down, the most important session I saw during the week was on burnout in the security industry. The studies have just started, and there's more yet to do, but it was very interesting. For more info, please check out www.secburnout.org.
]]>My participation was both as an attendee and as a speaker. For my speaking topic, I presented my notion of "scaling risk management," posing the question for discussion of "If you're an SMB, what is a reasonable expectation for performance of risk management? What should SMBs be minimally required to do?" This discussion took an interesting turn early on, revealing that there are really two questions contained within the topic: 1) "How do you scale-down 'big finance' risk management practices to the SMB space?" and 2) "How should a small business bridge the gap until it's big enough to adopt formal risk management practices?"
]]> Bridging the GapDuring the discussion, it quickly became apparent that there really is a necessary tipping point that each organization has to reach before being able to formally adopt risk management practices. All people and organizations use risk management techniques, but through our discussion we concluded that many of those early prototypical practices are implicit and closely align to Donn Parker's thoughts on diligence. This line of thinking was fascinating, and brought up the question: If an organization isn't yet ready for a formal RM program, then how should they be addressing the gap between the existing risk management needs and their ability to apply formal techniques?
There were two lines of thinking around this topic. First and foremost, we debated whether or not industry or government regulations are necessary. However, it became quite apparent that for the smallest companies, setting requirements (e.g., as PCI DSS does) simply isn't adequate or fair. If a small business cannot afford to adopt formal risk mgmt practices (and, by extension, hire someone to help in that area), then they also probably cannot very well deal with detailed requirements being foisted onto them.
Instead, the focus needs to be on a) pushing them to outsource support and solutions, b) making sure the outsourcers are addressing security and risk management, and c) requiring the SMBs to pick-up appropriate insurance policies to cover any gaps. The PCI Council has already targeted outsourcers with their requirements for service providers and solutions (i.e., PA-DSS). However, it appears that enforcement still isn't quite up-to-par. On the last point, we noted that insurance may or may not be adequately available today. One attendee noted that merchants used to be required to carry insurance policies, back when physical cards were being processed on paper, but that such requirements went away with eCommerce. General consensus seemed to be that such a requirement should in fact be brought back.
Of course, while a solution like insurance helps address the risk management concerns, it does not do much to address the occurrence of fraud and data breaches. This means that, while this should be part of the solution, there still needs to be a scaled-down set of practices that every business, regardless of industry (including restaurants, hospitality, and other non-technical verticals), can adopt and follow.
Scaling-Down Practices
Working from the assumption that "bridging the gap" only addresses the financial liability, and does not necessarily improve the security posture (note here that you can potentially improve risk posture without improving security posture o_O). How, then, do you scale-down practices - particularly as they apply to risk management (in this context) - for the small business that hasn't yet reached the necessary tipping point to staff-up?
There are a couple different angles to this discussion to consider:
* Practices: The practices themselves will vary. At a minimum, Parkerian "diligence" is the default state. People make risk management decisions based on experience, available information, and typically without a formal process. The question is: is there a lightweight way to formalize these decisions? If so, how do you train the masses? Or, is this really just too much academicism and not enough pragmatic practicality?
* Mandate & Enforcement: At the end of the day, businesses are not going to adopt formal practices that add overhead cost unless there's a good reason to do so or they are required to make changes. Similarly, the changes will only follow if there is at least a perception of enforcement (and penalties). In considering "requiring" formal risk management practices for the SMB space (pre-tipping-point), it's imperative to consider how you would set, communicate, and enforce those requirements.
* Legal Aspects: At the end of the day there are two key measures to consider with respect to the law: are practices commercially reasonable and legally defensible? In the first case, "commercially reasonable" helps look at what the rest of the industry is doing and determines whether or not your organization is maintaining a level of practice that is at least on-par with everyone else. In a very real way this looks at negligence concerns. At the same time, there is also an imperative for ensuring that practices (or the lack thereof) are legally defensible. So, even if the state of the industry does not require meeting certain levels of performance, if you know of a reasonable risk to the business and do not take reasonable measures to at least analyze it, if not find ways to treat it, then stakeholders may determine that you didn't do enough, and you could find yourself in court arguing over whether or not your actions (or lack thereof) were defensible. This is not a scenario in which you want to find yourself.
The discussion at the Risk Management Summit touched on some of these points, but we did not ever reach a consensus. Several notions were mentioned in passing, such as relying on industry self-regulation, relying on government regulation (such as through the Small Business Administration), or setting performance benchmarks through other means like contracts (e.g., as tied to insurance premiums and coverage, as tied to the ability to accept credit cards for payments).
At the end of the day, there is probably a need for articulating a minimum set of expectations as regards the awareness of information risk that affects any organization using IT resources and handling data (especially sensitive data). We've seen some of these programs in action, such as in healthcare where small family practices started issuing privacy statements and requiring the signing and myriad forms in order to allow the practice of medicine on a patience (it should be noted that many of these practices are a bit over-reactionary and undermine the intent of laws like HIPAA, which were meant to facilitate treatment and information sharing, not put up significant roadblocks to them).
Two final thoughts occur. First, if your organization is small and has not reached the tipping point, then you need to figure out (somehow) what your minimum responsibilities are. It's your duty to know this. However, it may fall to other industries or the government to help make you aware of these duties. Second, once your organization reaches the tipping point of adopting formal risk management practices, then a good first step is likely to hire or contract a subject-matter expert who can help get a reasonable framework and process in place.
]]>Overall, I saw three major themes during the conference (four, really, but I'll leave that for the next section).
1) Mobile - It seems like this was the hot topic of the year, especially with all the buzz around "bring your own device" (BYOD) policies. It's definitely a challenging area, and one rife with exploits. It seems in many ways like we started from square one again, despite having a couple decades (at least) of good experience on how to do things like develop reasonably secure applications. It was interesting to me to see that the Cloud Security Alliance is now adding a project area around mobile ("gateway to the cloud"). In some ways, that seems like jumping the shark, but hey, maybe they'll have success.
2) "Big Data" - Every time I hear this phrase, I hear it in my head as comedian Jim Gaffigan in sing-song falsetto a la his classic "Hot Pockets" bit (see video below). Is this really a new area? No. Is there really anything interesting or unique here? No. We've been dealing with "big data" for a long time. Data mining, data warehousing, and business intelligence are all mature product areas that evolved to work with very large data sets. That it's "new" to infosec is... meh. Nonetheless, it was a major theme this year, and one likely to persist throughout 2012.
3) Risk Management - It seems like everyone wants a piece of the risk management puzzle these days, and for good reason. Security really is about reducing information (and/or operational) risk, which can then be used to peg solutions to improved business performance or reducing business exposure/liability. However, as I'll discuss below, "risk" as a term is becoming increasing abused and misused. Just because you address risk factors does not mean you are the risk management solution. This is not just an issue with semantics, either...
Misconceptions
1) "Everything Is Risk" - As noted above, a major theme for RSA this year was tying every single product to "risk" - right or wrong. This trend first emerged last year as major vendors began recasting their image from treating threats or vulnerabilities to being about managing risk. Unfortunately, this is a major misconception and an outright lie. If you cannot articulate in real terms the impact side of the risk equation, then you're not address risk. You might be address risk factors (e.g., threats, weaknesses), but you're not speaking about "risk" and you're not managing it accordingly. I hold little hope that we'll be able to wrest control of this term from the PR forces, but I am hopeful that we can at least steer vendors toward also talking about impact as it relates to the threats or weaknesses their products address.
2) "Security Is Failed/Dead" - This was a strange theme this year, and one that I thing directly derives from RSA experiencing a major security breach last year. The funny thing is that it's not true (not even close). The vast majority of breached organizations are still in business today. They survived. So, why the fatalistic viewpoint? Chris Hoff has a fairly good, ranty piece on the topic that's worth reading. To me, I think it ultimately comes back to a new spin on FUD in order to drive product sales. I couldn't help noticing that Art's opening keynote had numerous veiled references to their products, all in context of how security has failed, but how we will overcome. If you think security is dead or failed, then I don't think you properly understand the role of security (or risk management, for that matter). The focus should be on business survival, legally defensible practices, and risk management. Minimize the negative impacts from inevitable events and you win. *shrug* Seems straightforward to me...
3) "Government Will Help Solve Problems" - A major topic in the past few years has been a call from the US Government for more "public/private partnerships." As I look at many of these initiatives, it strikes me more as fishing expeditions. They come up with a dream list of requirements, and then private industry does a lot of the heavy lifting. Ok, that sounds cynical, but the point here is this: We don't look to government to solve problems or innovate. We look to government to regulate when market forces aren't adequate, and to help ensure as level a playing field as possible. Anything more than that strikes me as a pipe-dream. Their motives are vastly different than the commercial world's. We should be very careful what we wish or ask for with respect to government intervention.
Down-trending Topics
1) Cloud - Has this topic finally become passé? So it seems. Cloud is everything and everywhere. I still think there's a lot of confusion (thanks in large part to marketing/PR efforts) about just what actually qualifies as "cloud." That said, it's here, it's going to stay, and we need to make sure our GRC programs are in the critical path for dealing with cloud-based solutions. I'll be surprised if this doesn't rise again soon, at least in other incarnations or evolutions. In related news, there seemed to be some interesting security solutions on display at RSA for managing cloud-based data and apps, which I found encouraging.
2) Point Solutions - I've noticed a heavier emphasis on integration and risk management lately, even though the majority of solutions still appear to be point solutions. We need to get away from these specialized and difficult-to-integrate tools in favor of stitching together a well-integrated, well-functioning enterprise security space. Hopefully the down-trend away from point solutions will continue.
3) Ubiquitous Encryption - I didn't hear much explicit discussion of encryption this year, which I take to mean that it's either another passé topic, or it's become so mainstream that we don't have to think about it much any more. In many ways, the only times I heard much about crypto was in regards to protecting data in the cloud, berating broken SSL Certificate Authorities (really, Comodo? "high assurance"?!?), and with a few point solutions (e.g., encrypted removable media). Overall, though, it seems like there's been far less emphasis here of late. Perhaps the PCI DSS requirements have finally sunk in.
Stayed tuned for more thoughts in 2 additional posts on RSA 2012...
]]>But it's not just that... despite Art's overblown rah-rah speech in the opening keynote yesterday, I really do think that people are feeling a bit optimistic these days. Sitting in the 2nd annual "risk management smackdown" panel, it actually sounds like many people are starting to grok risk management. Sitting in the security burnout panel on Monday, I think people truly appreciated that we are a high-risk career field that needs support structures. Speaking with various (true) geniuses at the speakers' dinner last night, I learned of new advances in cryptography that are already advancing well to replace our aging frameworks, and I even met the phenom Ang Cui from Columbia University, who has not only demonstrated a way to hack an HP printer by simply printing his resume (in postscript), but has done considerable research around automated embedded system exploitation AND DEFENSE!!
I've not had much opportunity to walk around the expo floor, where I'm sure I'll find a variety of nauseating marketing themes, but I regardless can't help feeling like we're turning a corner here in 2012. It's very exciting to be able to watch and participate in a transformative time in history. Let's hope this trend continues.
]]>On the (very) off chance that you're interested, here's where you can find me throughout my west coast visit:
Want to meet-up at some point? Please leave a comment here, email me, or hit me on twitter. Or, hang out at the W and you'll likely run into me eventually. ;)
]]>Before talking about this further, let me point you to his pieces:
* "Power. Law."
* "More or Less"
* "People in the Loop: Are They a Failsafe or a Liability?"
At OWASP USA 2010 (my notes), David Rice talked about the parallels between the anti-pollution movement and application security. He suggested that we're still at the "green movement" stage of things (at best), trying to reduce the overhead costs associated with application security, but not yet to the point of "going blue"; that is, moving to sustainable practices that can help grow top-line revenue. Those thoughts seem even more prescient today in light of Geer's articles and speech. What we're doing is not sustainable, and will require a major paradigm shift. More importantly, we're so far behind, and falling ever-farther behind on a daily basis, that any notion of catching up following the same trajectory is simply unrealistic and irrational.
Instead, what's becoming increasingly obvious is that we need to completely change the problem space. Today, the problem space is still largely defined by the traditional mindset of systems and network administrators slogging it out in the trenches, trying to keep up with the ever-evolving and accelerating attacks being thrown at them. This approach relies on the zero-sum mentality that all attacks must (can) be stopped. In reality, this approach is failing precisely because it relies on humans to counter attacks and threats, rather than allowing systems to automate the growth and defenses. Attackers can evolve attacks exponentially, while defenders can only respond linearly. This is not a good situation to be in!
For some time now, some of us have advocated two key changes. First, we've talked about the need to shift from the zero-sum approach to a survivability mentality. Instead of believing that all attacks can be rebuffed, it's instead imperative to assume that attacks will succeed, and then build out monitoring and response capabilities that equal or exceed defensive capabilities in order to ensure continue operations despite degraded conditions, and to reduce the overall (negative) impact of an event.
In an example that furthers my thinking here, consider my response to the post "Insecure at any speed.", which talks about the findings in the recent breach data report from Trustwave SpiderLabs:
Perhaps the problem here is focusing on the occurrence of breaches rather than on the recovery from them and the subsequent impact on the bottom line. If the focus shifts away from the traditional "all breaches are bad, they must all be stopped" to "the business must continue to operate and survive despite degraded conditions," then the overall approach can be revised accordingly. I found the TW report to be unnecessarily inflammatory and derogatory, seemingly implying that people are stupid for not having specific technologies in place. Yet, who are they to make that call? It's up to the business to assess and understand the risks in those decisions and account for them accordingly. There are many tools that /can/ be used, but the right question is "what tools will help us continue functioning as a business?" That's where this security industry has gone so terribly wrong, and where we still see continued resistance to change.
Second, we've talked about the need to dissolve "infosec," splitting it between operational responsibilities and GRC (as a discipline). We're starting to see cases emerging where this very thing has been done, which has resulted in a far more effective risk management program, and that allows operations to become better optimized. In both cases, these changes lead to more legally defensible approaches and decisions, which means that risk and legal liability are better managed (see a bit more on legal defensibility here and here)
The tie-in to the Geer pieces is this: Once you split-out the operational duties, you can then start looking at methods to automate those activities. Where we have people sifting through logs, SIEM reports, etc., today (as well as pushing out patches, hardening servers, improving elasticity, etc.), we can instead start looking at sentient systems (beyond simple AI) that can start managing all those tasks. The down-side to this reality is that it means losing a lot of those human operators (admins) as they're replaced by machines. The up-side is that machines (in theory) will be better able to detect, respond to, and evolve defenses as threats evolve.
On the flip side, the GRC (as a discipline) program remains largely human. Where automation comes into play is in helping collect, aggregate, and correlate data, and automate reporting. However, overall, you still need humans to follow processes, make (risk management) decisions, etc. These are business leadership responsibilities, supplemented to a degree by systems, but not completely replaceable. This situation, by the way, is one that we encounter frequently in the GRC (software) industry, where customers ask us for solutions that, ultimately, map to processes that humans have to follow, rather than to activities that can simply be automated. Tools are great for collecting, aggregating, and correlating data. They're even great for helping build reports. However, when you then start talking about topics like enterprise risk management, you quickly find that there are significant limits to what can and cannot be automated. Finding the right balance is, of course, the challenge; and, I think that things are still too unsettled to know what that "right balance" might be (though that may change soon, and quickly, if Geer is correct).
At the end of the day, this is a thought piece; and, a compelling one at that. We are already aware of sound alternative approaches, and they will integrate well with the vision that Geer has espoused. The question is whether or not we'll have the intestinal fortitude necessary to make the hard decisions and move forward. I can't help but wonder if the socio-politico-economic question on wealth redistribution won't end up being the lynchpin question to resolve. Certainly here in the US, the right has no interest in addressing the problem in an egalitarian way. Yet, what if the problem space comes precisely down to the fact that the old models do not fit the modern reality? What if the old economics have no relevance to current fiscal realities? These are heady questions, and they ultimately come back to the need to aggressively reach consensus on the "right" (i.e., correct) path forward and vision for the future. It seems increasingly likely that we're at a proverbial crossroads that could either take us to Utopia or Dystopia, depending on whether or not we pull together or fly apart. It's clear that we live in interesting times.
]]>