Re: SAN Vulnerabilities

[mjd <bragot () gmail com>]

Thanks to all those who have replied.  I've received a lot of great
feedback and some great points of discussion.  I'd like to add some
additional points that were covered in our conversation that may or
may not influence some of the reasons provided here:

> > > SAN Zoning has been compared to the concept of VLANs.  Any misconfiguration in the Zoning Rules can lead to a 
> > > vulnerability.  Furthermore, when drawing this out physically, there is a trusted resource connected to an 
> > > untrusted resource although logically they cannot communicate.

When I was presented this argument I was asked to explain how this is
any different than using our firewall to segment our trusted and
untrusted networks.  I didn't have a good argument against this
question as a firewall is also susceptible to vulnerabilities if the
rules are not configured correctly.

> > > Cost.  Does the risk justify the cost of purchasing a whole new SAN unit for our Web segment?

It's our role to determine the cost of a data breach.  However, what's
challenging for us in this situation is defining the exact risks that
we are worried about.  Obviously, in the worst case, our PHI data
would be compromised.  But when it comes to enumerating active
exploits, we couldn't find anything other than the proof of concept
document presented at Black Hat.

> > > One option presented was to encrypt the data on the SAN so that only the internal servers would be able to decrypt 
> > > the data while our Web Servers would not have the keys.

Very interesting option.  Definitely something that we'll need to test
and research on our end as it could introduce performance issues.  If
anyone else has successfully done this, I'd love to hear more about
your implementation.

Would love to hear more feedback especially in response to the new
points presented.

Thanks all!

--
mjd


> --- original message ---
> From: "mjd" <bragot () gmail com>
> Subject: SAN Vulnerabilities
> Date: 17th December 2010
> Time: 9:04:52 pm
>
> We are evaluating a proposal wherein our Web Server Admins would like
> to use our internal SAN to host data for our external websites.  Our
> external websites are on our outfacing DMZ which means they could be
> subject to all sorts of attack.  Our internal SAN hosts some very
> sensitive health care data so I'm reluctant to allow this since it
> puts our most protected data physically very close to our most
> vulnerable segment.
>
> They have given me assurance that they have locked down the SAN to the
> point wherein one server accessing cannot access any other disk unless
> it is explicitly mounted.  I do not have heavy experience with SANS,
> but based on their explanation, the SAN switch can be likened to a
> firewall in that it blocks any communication not explicitly allowed.
>
> When drawing this out on a board, it just doesn't look right.  We're
> physically connecting servers in our External DMZ to our SAN which
> hosts very sensitive data.
>
> Any advice on this situation?  Are we overreacting to this and should
> we trust in the security boundaries created by the SAN
> switch/controller?  Are there vulnerabilities out there that allow an
> attacker to take control of the whole SAN?
>
> Thanks in advance!
> mjd
>
>
>
> Ashvin Oogorah
> Information Security Analyst
> Emtel Ltd.
> Mobile: +230 421 6080
> Sent from Emtel Blackberry Service
>
> EMTEL Note: SAVE A TREE. Don't print this e-mail unless it's really necessary!
> This email and all contents are subject to the following 
> Disclaimer:“<http://www.emtel.com/email-disclaimer.php>”------------------------------------------------------------------------
> Securing Apache Web Server with thawte Digital Certificate
> In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, 
> how it benefits your company and how your customers can tell if a site is secure. You will find out how to test, 
> purchase, install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for 
> set-up are highlighted to help you ensure efficient ongoing management of your encryption keys and digital 
> certificates.
>
> http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
> ------------------------------------------------------------------------



-- 
mark dy-ragos

------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, how 
it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, 
install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are 
highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.

http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
------------------------------------------------------------------------