“Amazon EC2 public AMIs (Amazon Machine Image) generate unique SSH (Secure Shell) host keys each time you launch an instance. This enables you to get the host SSH keys from the console output and verify the host to which you are connecting.”

Important note: SSH host keys enable clients to verify the server identity (”are you really my server?”) and are separate from SSH user keys that allow the user to prove their identity to the server (”he really is Jeff”).

What does this mean?

It means that EC2 instances created from a public AMI after June 23rd have unique SSH host keys and thus are not vulnerable to a man in the middle attack against the SSH protocol, but only *if* you manually verify the host SSH key during your initial SSH connection.

OK, but I created my AMI before June 23rd - am I vulnerable?

According to Amazon, yes.  Every EC2 instance copied from a public AMI will have the same SSH host keys as the original AMI.  The only exception to this is if the original AMI creator spotted this problem and used a hook to force SSH host key regeneration upon first boot. This means that an attacker who say, uses a DNS cache poisoning attack, can intercept the communication between your SSH client and your AMI.

How can I fix my pre-June 23rd AMIs?

Regenerate the SSH host key.  The exact commands will depend on your operating system (hint: ssh-keygen).

Who is to blame?

Either the creators of the original AMI or Amazon - depends how you look at it.  If Amazon created the public AMI then it could be argued they are responsible.  However, anyone can submit a public AMI and Amazon makes no guarantee they are fit for use (Amazon do review the AMI listing according to their documentation).

Amazon can in fact make the argument they are acting in the interests of their users by implementing a shared solution to key regeneration (rather than requiring each user to manually regenerate the ssh host keys after booting an image).   That’s fine going forward but what of potential exposure to customers using the pre-June 23rd public AMI copies?

Just to be clear, its not the fault of SSH - ’secure channels’ require proper key management and the need for unique host keys is well documented.

Are there any mitigating factors?

Yes, if you have used security groups to limit SSH access to your AMI from IP ranges you trust (rather than the entire Internet).  You’ll still want to regenerate the ssh host keys sooner than later.

Is the Amazon environment vulnerable to Man-in-the-middle attacks?

I don’t know.  But that isn’t the real question - is the path between you and your AMI immune to MITM attacks and the answer is most definitely no.  If SSH on your AMI is only accessible from another AMI then its a fair question but its unlikely Amazon are going to show you their network diagrams ;-).  From experience performing MITM attacks, I would assume most networks are vulnerable (one of the reasons why we use SSH).

Why Didn’t Amazon Tell Me I’m Vulnerable?  They know from their logs what AMIs I use!

Didn’t they?  Whoops - naughty Amazon :P.

But seriously, Amazon are not responsible for the configuration of the public AMIs you use.  Its important not to confuse the AMI selection and cloning mechanism that Amazon provides, with the content of an AMI itself.

Does Amazon have a mailing list for customers to learn about new security problems (even if its not Amazon’s fault).

Not that I know of.   Right now you have to search forum posts and monitor documentation updates - which is time consuming and makes it easy to miss something.  I also can’t find an area on the AWS website where they collect security related items together (e.g. best practices, advisories, key management).   In my view, this is a shame as it probably undermines the effort that Amazon are putting into their security  (for some customers, if they don’t “see it”, it doesn’t “exist”).

A ‘Security’ link on the main AWS homepage pointing to those resources would go a long way to improving the visibility of the AWS security related information.

Had a great time Sunday with Rob Newby. We solved the world’s problems over deep fried whitefish and french fries (fish & chips to him).  It was a very good time, even if my driving did make him a bit uneasy.  If I may quote myself (said in an attempt to soothe Rob’s uneasyness about being lost in the car of a complete stranger in a strange country):

If your life doesn’t imitate the surreal aspects of a Douglas Adams book at least once a day, you’re just not living right.

Aside:  Bruce Scheier already has too many awards and too much recognition, so go vote for Rob instead :)   :  http://robnewby.blogspot.com/2008/07/award-up-for-grabs.html

SEPARATION OF CHURCH AND (CURRENT) STATE

Rob and I spent some time discussing risk and security,  and our conversation circled around the (now) recurring blogo-topic concerning the State of the Practice.  It’s a favorite topic of mine, so I’ve been delighted that it has reappeared in blogodom.

Rob writes about it some here in PCI the Priest.  LonerVamp’s and Richard Bejtlich’s blogs talk about Galileo, his confrontation with his church, and lessons we can learn from history (there’s nothing wrong with them recycling the meme, IMHO - because I, for one, never got closure the first time). Jon added a nice quote from Feynman today that’s also inline with the meme.

I’m not going to belabor the analogy, the “art vs. science” misnomer, nor discuss the problems with our various canon (PCI, ISO, CoBTI, COSO, blah, blah, blah).  Rather I’d like to talk about some essential things I think our industry needs to “sort out”  before it can move on towards a more scientific view of the world.  And by “sort out” of course, I mean agree with me on

CAN’T WE ALL JUST GET ALONG?

1 - Can we agree that risk is a probability issue?
Now obviously, you can retreat in probability theory a century or so and claim that risk is a Knightian uncertainty and that we just can’t “know” it.  Have fun.  But you should know that there’s the catch - “security” is also a probability issue.  So I’m betting that you can’t know “secure” for much of the same reasons Frank Knight would argue we can’t know “risky”.

But if risk (and security) is a probability issue, however, then we’re going to have to do better than “A’s in three college courses in statistics” to address the problem.  We will have to do as Curphey (and others) suggest and bring elements of other disciplines to bear on our problem space.  Let me suggest probability theory and economics as fine, fine places to start.

2 - Can we agree to stop measuring stupidly?
We have to agree that Ordinal Scales are not measurements, and Interval Scales are not useful measurements?

I had a post titled “More Ways To Confuse Your Auditor/Assessor” but it turned out to be a pretty cruel discussion about how we tend to try to act like our calculations based on ordinal or interval scales are useful (hint:  insist that your auditor/assessor/consultant replace the label “one” with the label “zero”).

Note that if risk is a probability issue, then we’re going to have to throw out the concepts of measuring in any scale other than a ratio anyhow.

3 - Can we agree on a (good) taxonomy?
We’re going to have to do (much) better than ISO 27005 (nudge, nudge).

4 - Can we agree we need to do a better job with our data?
We’re going to have to do better with measurements, metrics, models and testing.

It’s a shame that honeypots tend to be under appreciated.

5 - Can we agree to test that data and share it with each other?
We may not need to share specific data, but we will need to share when a model falls down.

I’d like to be as idealistic as some of my fellow ‘New Schoolers’ and suggest we’ll someday all be sharing data together, but I’m skeptical.  But that doesn’t mean we can’t demonstrate where results from the models we use are not repeatable, consistent or logical.   One thing Rob and I talked about at length yesterday was the ability to disprove a model using realistic but “substitute” or sanitized data.  There’s gonna be a TON of work to be done here, and that work will take not years but careers.  Which begs a great question:

Is it the sharing of data that we need, or the sharing of models?

HELP ME OUT, HERE
That’s my list of 5 fundamental concepts I wish we could move past.  Let me ask you - what else am I missing?  What’s it going to take to get past our current malaise?  How does the New School reach critical mass?  Who is going to help us agree in a centralized manner?

Your comments or own blog posts are most welcome (please include a trackback or post here)

1. Misspell both HIPAA and SOX (how the f does one misspell SOX?)
2. Confuse "risks" and "threats"
3. Think that "Trojan is a vulnerability" AND "DoS is a vulnerability"
   
4. Quote "Insiders are 80%" without thinking for one darn second
5. Think that a loss of "$20 million is catastrophic to any company"
6. Talk about "NIST compliance"
   

• State of Nature. State of Nature just means what the current state is.  There are two ISSA Journals on my desk right now - State of Nature statement.

• State of Knowledge:  Analysis derived from examination of State of Nature.  “One of these ISSA Journals has an article co-authored Donn Parker on ROI.  I’ve read it, and it makes some statements he regards as truth.  Looking at those, well, I know that risk is quantifiable, best practices have significant issues, and there are many, many other statements of authority in the article that I can refute on evidence.” - Analysis or State of Knowledge.

• State of Wisdom:  Synthesis from the analysis.  The “So” moment.  “So since there are many statements of authority made in the article that I can refute on evidence, I should be open but skeptical about whether the conclusions of this article are likely to have much value to me in my quest to understand the value of risk reducing investments.”  What I’ve synthesized from the quality of the article - State of Wisdom.

(Just a clue for our readers, anytime you read someone talk about risk and mention the term “actuarial” - be skeptical about the conclusions they have you draw from the statement using that word. 9 times out of 10 what I’ve read after someone says actuarial is made as authoritative but shows a level of ignorance on the subject.  If you really want to mess with them - say “Really! Well, tell me how you feel about the use of non-parametric Bayesian Methods” and wait… )

MMMMM-MMMMMMM CHECKLISTS!

So what about Checklists?  They’re worth discussing because we’re swamped by them!  Heck, we’ve got people in love with the idea of checklists of checklists and claiming GRC nirvana is not in the checklist itself, but in the mapping of checklists.

Here ya go:  Checklists have one of two uses -

First they can give us a path to accomplish something.  I make a checklist every morning I call a “Todo List”.   Useful Checklists could be as Curphey mentions - steps for operating machinery or performing a certain task (heck, scientific method could be said to be a checklist of steps in analysis).  Checklists are useful in this way because, well, we’re fallible, absent minded, and novices.  They serve to reduce some level of variability in a process.

Second, they can help us develop a State of Nature.  PCI or the ISO are very nice checklists that, once you’re done, certifies that you have the existence of a certain amount of control.  Again, this serves to reduce some level of variability, comparing you to a “best practice”.

And so…..

They are both useful in each use - as long as the limitations therein are understood!   And that’s where we get into trouble.  Too many times we believe that checklists are a State of Knowledge.  Checklists allow for some limited analysis, just like the use of ordinal numbers to describe “risk” - they only serve to identify some level of variability, nothing more.

But outside of that they usually offer us no analytical function at all, they cannot provide a State of Knowledge and therefore, more succinctly, Checklists are dumb.

As slightly paranoid, skeptical and jaded risk management professionals, we know this to be true.  A PCI compliant company may or may not be at all “secure” or “risk-free” or even “risk-reduced”.  That’s an aspect of analysis that the checklist is some prior information for, but not nearly all the information we need for an analysis of risk or even a statement about the ability to control or resist.  We know an ISO certified organization did what they claim they do enough to at least fool an auditor once, but cannot arrive at any other State of Knowledge without more effort.

Make no mistake, the checklists we commonly deal with provide a very, very limited State of Knowledge.  Only analysis (with rigor and testing) will provide that.  And note that a State of Wisdom (what we’re really after, after all) is predicated on a strong State of Knowledge.

WHAT ARE YOU MANAGING TOWARDS, REDUX
So if checklists only provide a State of Nature, and are incapable of really giving us Knowledge or Wisdom - then let me encourage you to think about the amount of time you spend just getting a certain State of Nature and the relative return on that investment vs. the amount of time you spend in analysis and synthesis.  Is your time best spent mapping checklist to checklist - or is it better spent developing the analytics that allow us to synthesize wisdom?

AMAZE AND CONFUSE YOUR FRIENDS AUDITORS
Let me finish by encouraging you to have a frank discussion with those who perform your audit function.  You must really pin them down if they are out to give you any analysis at all - and when/if they do provide analysis - press them on what rigor they use to create a State of Nature, and then the means by which they create a State of Knowledge (that belief statement based on the State of Nature they see).

Cloud Computing is starting to escape the technical and business press.

The proof?

I was invited to talk about Cloud Computing and Security on NPR “Morning Edition”.

NPR - National Public Radio - is a US based, non-commercial radio station covering news, talk and current affairs. British readers may find it similar to BBC Radio 4.

Every Monday, the “Morning Edition” has a technology theme. The Cloud Computing segment was high level and aimed primarily at a non-tech audience. I always find it hard to answer the question ‘what is Cloud Computing?’ as there are so many different definitions. Regardless, it was a great chance to talk about an exciting technology and highlight the need for a real security conversation between the providers and people interested in IT security - the primary reason why I created cloudsecurity.org.

The show boasts a very impressive audience - around 13 million! I’ve never before had the opportunity to confuse that many people in one shot ;-).

If you would like to listen (its short - 3.5 mins), click here.

I’d like to publicly thank Nina at NPR for reaching out and extend a warm ‘Welcome’ to any NPR listeners who have dropped by. Feel free to leave a message below or email me if you have any comments or questions.

Ironically, our favorite software vendors have decided, in a nutshell, to redefine Dr. David Luckham’s definition of “event cloud” to match the lack-of-capabilities in their products.  

This is really funny, if you think about it. 

The definition of “event cloud” was coordinated over a long (over two year) period with the leading vendors in the event processing community and is based on the same concepts in David’s book, The Power of Events. 

But, since the stream-processing oriented vendors do not yet have the analytical capability to discover unknown causal relationship in contextually complex data sets, they have chosen to reduce and redefine the term “event cloud” to match their product’s lack-of-capability.  Why not simply admit they can only process a subdomain of the CEP space as defined by both Dr. Luckham and the CEP community-at-large? 

What’s the big deal?   Stream processing is a perfectly respectable professional!

David, along with the ”event processing community” defined the term “event cloud” as follows:

Event cloud: a partially ordered set of events (poset), either bounded or unbounded, where the partial orderings are imposed by the causal, timing and other relationships between the events.

Notes: Typically an event cloud is created by the events produced by one or more distributed systems. An event cloud may contain many event types, event streams and event channels. The difference between a cloud and a stream is that there is no event relationship that totally orders the events in a cloud. A stream is a cloud, but the converse is not necessarily true.

Note: CEP usually refers to event processing that assumes an event cloud as input, and thereby can make no assumptions about the arrival order of events.

Oddly enough, quite a few event processing vendors seem to have succeeded at confusing their customers, as evident in this post, Abstracting the CEP Engine, where a customer has seemingly been convinced by the disinformational marketing pitches  - “there are no clouds of events, only ordered streams.”

I think the problem is that folks are not comfortable with uncertainty and hidden causal relationships, so they give the standard “let’s run a calculation over a stream” example and state “that is all their is…” confusing the customers who know there is more to solving complex event processing problems.

So, let’s make this simple (we hope). referencing the invited keynote at DEBS 2007, Mythbusters: Event Stream Processing Versus Complex Event Processing.

In a nutshell…. (these examples are in the PDF above, BTW)

The set of market data from Citigroup (C) is an example of multiple “event streams.”

The set of all events that influence the NASDAQ is an “event cloud”.

Why?

Because a stream  of market data is a linear ordered set of data related by the timestamp of each transaction linked (relative speaking) in context because it it Citigroup market data.    So, event processing software can process a stream of market data, perform a VWAP if they chose, and estimate a good time to enter and exit the market.  This is “good”.

However, the same software, at this point in time, cannot process many market data feeds in NASDAQ and provide a reasonable estimate of why the market moved a certain direction based on a statistical analysis of a large set of event data where the cause-and-effect features (in this case, relationships) are difficult to extract.  (BTW, this is generally called “feature extraction” in the scientific community)

Why?

Because the current-state-of-the-art of stream-processing oriented event processing software cannot perform the required backwards chaining to infer causality from large sets of data where causality is unknown, undiscovered and uncertain.

Forward chaining, continuous query, time series analytics across sliding time windows of streaming data can only perform a subset of the overall CEP domain as defined by Dr. Luckham et al.

It is really that simple.   Why cloud and confuse the community?

We like forward chaining using continuous queries and time series analysis across sliding time windows of streaming data. 

There is nothing dishonorable about forward chaining using continuous queries and time series analysis across sliding time windows of streaming data.   

There is nothing wrong with forward chaining using continuous queries and time series analysis across sliding time windows of streaming data. 

There is nothing embarrassing about forward chaining using continuous queries and time series analysis across sliding time windows of streaming data. 

Forward chaining using continuous queries and time series analysis across sliding time windows of streaming data is a subset of the CEP space, just like the definition above, repeated below:

The difference between a cloud and a stream is that there is no event relationship that totally orders the events in a cloud. A stream is a cloud, but the converse is not necessarily true.

It is really simple.   Why cloud a concept so simple and so accurate?