Please take advantage of the comments field to get answers to your compliance-related security queries!]]> Thu, 03 Jul 2008 15:30:00 +0000 includes dave howell comments field andrew maloney brad davenport security queries rsa bloggers john mcdonald advantage join More RSA Compliance Solutions Bloggers http://securityratty.com/article/2b23eb6f67ca4fcc9f54908547f7ef90 http://securityratty.com/article/2b23eb6f67ca4fcc9f54908547f7ef90

One of the first social networking upstarts, MySpace, is facing continuing security problems that threaten to spoil many of the innovative features that make the site useful.

Hackers, spammers and Internet malcontents have turned many of the "group" sites, which are dedicated to interests such as home beer brewing, animal welfare and gay rights issues, into cyber-graffiti walls, filled with offensive comments and photographs.

The first session, on deception, was fascinating. It emphasised the huge range of problems, from detecting deception in interpersonal contexts such as interrogation through the effects of context and misdirection to how we might provide better trust signals to computer users.

Over the past seven years, security economics has gone from nothing to a thriving research field with over 100 active researchers. Over the next seven I believe that security psychology should do at least as well. I hope I’ll find enough odd minutes to live blog this first workshop as it happens!

[Edited to add:] See comments for live blog posts on the sessions; Bruce Schneier is also blogging this event.

In On EP and Analytics, good friend and respected colleague Opher Etzion applies the well known metaphor of the big elephant to describe how, if you are observing certain specific domains of a subject, like fraud detection, then your view of the whole elephant is biased by your lack of perspective of entire big elephant.

I am pleased that dear Opher continues to use this metaphor in counterpoint because the same metaphor can be used to describe the carefully selected group of vendors that have banded together to called themselves CEP Vendors.  This group, many founding members of the EPTS, have formed a merry band of well-intended event processing “specialists” and the same lovely elephant causes this group of bonded colleagues to make elephant-blinded statements, as Opher has made in his quoted post:

“Currently most CEP applications do not require analytics.” 

The reason, I believe, that Opher makes the statement above is because the group of software vendors calling themselves “CEP vendors” represent a very small part of the overall event processing elephant;  and hence, since these self-described CEP applications appear to require very little or no analytics, then, by the same logic, CEP requires no analytics. 

(I should outline the boolean logic in a future post!)

For example, one friend and colleague in Thailand is the CTO of True Internet, a leading telecommunications, voice, Video and Internet service provider in Thailand.   True processes myriad events on their network using a dynamic, self-learning neural networking technology.    The US company providing this very clever and highly recommended event processing application do not call themselves a “CEP vendor”; however, they process complex events better and more interesting than the band of merry self-described “CEP players”.

Again,  visualize the gentle giant elephant metaphor that Opher likes to use as a basis for his comments in CEP counterpoint.

When folks define the term “complex event processing” to match a technology marketing campaign that is primarily driven by software running rules against time-series data streaming in a sliding-time windows, and then go on to take the same software capabilities and apply these capabilities to problems that are suitable for that domain, then you match Opher’s elegant description of “a small view of the overall elephant”.

The fact of the matter is that the overall domain of event processing is at least three orders of magnitude larger than the combined annual revenue of the self-described companies marketing what they call “CEP engines.”  The very large “rest of the big elephant” is doing what is also “complex event processing” in everyday operations that are somehow overlooked in ”other” analysis and counterplay.

Therefore,  I kindly remain unmoved of my view  that the self-described CEP community, as currently organized, is not immune to counterpoint using the same gentle giant elephant metaphor.  I like this metaphor and hope well-respected colleagues will continue to use this metaphor; because we can easily apply this elegant manner of discussion to explain why the current group of self-described CEP vendors are, in a manner of speaking, selling Capital Market Snake Oil because they are making outrageous claims about the capabilities of their products, as if they can solve the entire ”elephant” of event processing problems.   Recently, in this article, CEP was positioned as a technology to mitigate against corporate megadisasters like the subprime meltdown.

Advice:  Tone down the hype.

Furthermore, the noise in the counter arguments marginalize most of the real event processing challenges faced by customers.

In consistant and well respected rebuttal, Opher likes to use the “glass half-full, half-empty” metaphor.   Opher’s point is a valid attempt to paint my operational realism as “half empty” negativism; while at the same time positioning the promotion of the (narrow) event processing capabilities of the self-described CEP rules community as “half-full” thinking. 

For the record, I do see my worldview as “half full” or “half empty”; but an unbiased pragmatic view based on day-to-day interaction with customers with what they would call “complex event processing” problems. 

These same customers would fall over laughing if we tried to bolt one of these rule-based, time-series streaming data processing engines on their network and told them they can detect anything other than trival business events, business opportunities and threats, in near real-time. 

Is it “half empty” thinking to caution people that a “glass” of software that is being touted as the answer to a wide range of complex (even going so far in a recent news article to imply CEP would have magically stopped the subprime crisis!) tangible business problems is not really as that it is hyped to be?  

If so, then I plead guilty to honesty and realism, with the added offense of a sense of fiscal responsibility to customers and end users.

I am pleased that dear Opher continues to use this metaphor in counterpoint because the same metaphor can be used to describe the carefully selected group of vendors that have banded together to called themselves CEP Vendors.  This group, many founding members of the EPTS, have formed a merry band of well-intended event processing “specialists” and the same lovely elephant causes this group of bonded colleagues to make elephant-blinded statements, as Opher has made in his quoted post:

“Currently most CEP applications do not require analytics.” 

The reason, I believe, that Opher makes the statement above is because the group of software vendors calling themselves “CEP vendors” represent a very small part of the overall event processing elephant;  and hence, since these self-described CEP applications appear to require very little or no analytics, then, by the same logic, CEP requires no analytics. 

(I should outline the boolean logic in a future post!)

For example, one friend and colleague in Thailand is the CTO of True Internet, a leading telecommunications, voice, Video and Internet service provider in Thailand.   True processes myriad events on their network using a dynamic, self-learning neural networking technology.    The US company providing this very clever and highly recommended event processing application does not call themselves a “CEP vendor”; however, they process complex events better and more interesting than the band of merry self-described “CEP players”.

Again,  visualize the gentle giant elephant metaphor that Opher likes to use as a basis for his comments in CEP counterpoint.

When folks define the term “complex event processing” to match a technology marketing campaign that is primarily driven by software running rules against time-series data streaming in a sliding-time windows, and then go on to take the same software capabilities and apply these capabilities to problems that are suitable for that domain, then you match Opher’s elegant description of “a small view of the overall elephant”.

The fact of the matter is that the overall domain of event processing is at least two orders of magnitude larger (maybe more) than the combined annual revenue of the self-described companies marketing what they call “CEP engines.”  The very large “rest of the big elephant” is doing what is also “complex event processing” in everyday operations that are somehow overlooked in ”other” analysis and counterplay.

Therefore,  I kindly remain unmoved from my view  that the self-described CEP community, as currently organized, is not immune to counterpoint using the same gentle giant elephant metaphor.  I like this metaphor and hope well-respected colleagues will continue to use this metaphor; because we can easily apply this elegant manner of discussion to explain why the current group of self-described CEP vendors are, in a manner of speaking, selling Capital Market Snake Oil because they are making outrageous claims about the capabilities of their products, as if they can solve the entire ”elephant” of event processing problems.   Recently, in this article, CEP was positioned as a technology to mitigate against corporate megadisasters like the subprime meltdown.

Advice:  Tone down the hype.

Furthermore, the noise in the counter arguments marginalize most of the real event processing challenges faced by customers.

In consistant and well respected rebuttal, Opher likes to use the “glass half-full, half-empty” metaphor.   Opher’s point is a valid attempt to paint my operational realism as “half empty” negativism; while at the same time positioning the promotion of the (narrow) event processing capabilities of the self-described CEP rules community as “half-full” thinking. 

For the record, I do see my worldview as “half full” or “half empty”; but an unbiased pragmatic view based on day-to-day interaction with customers with what they would call “complex event processing” problems. 

These same customers would fall over laughing if we tried to bolt one of these rule-based, time-series streaming data processing engines on their network and told them they can detect anything other than trival business events, business opportunities and threats, in near real-time. 

Is it “half empty” thinking to caution people that a “glass” of software that is being touted as the answer to a wide range of complex (even going so far in a recent news article to imply CEP would have magically stopped the subprime crisis!) tangible business problems is not really as that it is hyped to be?  

If so, then I plead guilty to honesty and realism, with the added offense of a sense of fiscal responsibility to customers and end users.

Is there security needed between virtual machines?  Some say no, some say yes.  I've been out talking to a number of virtualization users and non users on this topic and I'm finding that some say no and some say yes.  The users of virtualization technology tend to say yes while others looking at virtualization from the outside tend to say no.  Why is this?

Well, I thought I'd blog on my thoughts on this!

You see, in the physical datacenter there is no firewalling between servers plugged into the same switch and because of this some people think, well if its not done in the physical world why should it be done in the virtual world.  I believe that its not done in the physical world today because there are no solutions today that embed security into datacenter switches.  Should it be done in the physical world?  I think so!  It never hurts to get security as close as possible to the things you are trying to protect and what better place than the switch port in which the critical asset are connected to.  This is why people have HOST BASED FW/IPS ON SERVERS!  To get security as close as possible!  Is that needed? 

So my first response to those that say, security between virtual machines is not needed because its not done in the physical world is:  Well, just because people have done things one way for many years doesn't mean there isn't a better way.

Would environments be more secure if there was security between servers?  I tend to think so.  You see, many of the attacks that are taking place these days are not attacks for fame but attacks for fortune and gone are the days where people just hacked to spread nasty viruses.  Its all about the data these days (ie. credit cards, social security numbers, etc).  We've all heard about the TJ Max security breach where customer data was compromised and many others like banks that have had credit cards compromised. 

How and the heck do you think most of these things happened?  Attackers are targeting the datacenter these days.  Physical or Virtual.  Their gateway into these environments are the Web Front End Servers.  Let me say that again.  The Web Front End Servers!  Hackers get to the data from the web front end server that talks to the database backend server.  This useually occurs by something called "Cross-Site Scripting" or "SQL Injection" breaches. 

Here is a trival way of how this happens:

A hacker finds a vulnerable web site.  He sometimes does this by something called Google Hacking.  He uses Google to search for sites that has vulnerabilities on it.  Say a web site has some content on one of the pages that says "Powered by Drupal 4.1".  If a hacker knows that Drupal 4.1 software has a vulnerability in it, he can now target all the search results related to this.  Click Here for more detail.

Now lets say Drupal 4.1 on a web site has a SQL-Injection vulnerability because the developer of the Drupal software didn't do Form Field Validation properly.  A Form field is something you fill out on a web page like a form that asks for the user name and password.  User names and passwords to log into the web site are stored on whats called a Database Server.  Hmmm... So this means the web server needs to talk to the database server right?  Yes!  Keep this in the back of our head for now.  The hacker enters in "Admin" for the user ID and "password doesn't matter 'or 1=1--" for the password.  And presto!  He is logged in to the server as Admin.

The reason he was able to log in is because the web site sends a SQL Database command to the Database server and because the developer of the Drupal software didn't do "Form Field Validation" properly (method of checking for invalid characters like the ' (single quote)  symbol), the user was able to bypass the password.  Notice the 'OR 1=1 command appended to the password.  One does equal one so therefore it will return a TRUE result to the password checker and the OR says use the password typed in (password doesnt matter) OR check to see if one is equal to one.  If its true then the password is valid for this user which is Admin.

Now that the user is on the web server, he probably has the ability to connect to the database server or other servers in the network.  Why?  Because there is connectivity from the web front end to all of the backend servers.  He essently can backdoor his way throughout the network.

Another method is for him to append some SQL statement to another SQL statement.  Lets say their is a FORM FIELD on the website that collects some information from the database to display it to web site users.  It could be entering in the Zip code to find store locations in your area.  Instead of putting in the zip code you could put in "95123 'UNION SELECT * FROM credit_card_table--".  The hacker is injecting via the UNION command (which means join one SQL statement with another one) a command that says grab all (via the asterisk) information out the credit card table.

Lastly, the hacker can use the UNION command to write text of his desire to a text file on the database server.  He may write some nasty code, tell the database to write the code to a file and then tell the server to execute that file.  The code could be used to do a denial of service attack to the other virtual machines or whatever.  The possibilities are endless!!

Anyway, these are high level examples.  I think you get the point.

The Web Front End Virtual Machine has a need to talk to the Web Back End Virtual Machine and security such as Firewalling, Intrusion Prevention definately needs to be in place to have a higher level of security.

Another reason to have security between virtual machines is because servers are now mobile in the virtual world.  They move between trust domains to take advantage of computing resources that may be available on a given piece of hardware.  Lets say one PHYSICAL server was hosting database VM's and another PHYSICAL server was hosting file server VM's.  The file server VM could VMOTION to the same environment as the database VM's.   Now where is your isolation between trust domains or unlike resources?

People should think about this problem in greater detail.  I'd love to hear everyones comments as to whether or not they think security between VM's is needed.

John Peterson
Montego Networks