[Re: CMS Security]

[dsr-mzpnVDyJpH4k7aNtvndDlA at public.gmane.org (Dan Ritter)]

On Thu, Dec 31, 2009 at 01:24:50PM -0500, Fred at PlanetaryServer.com wrote:
> >> Of course, if this site is set up so that it can only be access via a 
> >> VPN, then the security question is contained to how secure the VPN is, 
> >> thus eliminating any potential flaws in the CMS itself.
> >
> I should have qualified that statement. "Assuming the user authorized 
> can be trusted."

You can never make that assumption. If you could reliably make
that assumption, you would simply give them a list of things
they can do and tell them not to do anything else. 

> As far as I'm concerned, if you can't trust the people you give access 
> too, all bets are off anyway.

The point of identification/authentication/authorization systems
is to distinguish between actions and data that people can be
trusted with, and the actions and data that they can't. 

In other words, this is the hard part.

> This also assumes that there are no critical software flaws (bugs) that 
> would distort data or inadvertently allow access to a restricted area. 

The authors of a typical CMS do not have the same threat model
as the author of a financial management system. They have a
generic sort of attacker in mind: "somebody want to commit a
little vandalism", or  "someone wants to store warez in a
secluded place".

They won't be thinking "a current employee wants to steal
identities" or "a current employee wants to commit fraud" or "an
ex-employee wants to embarass the company" or "an authorized
user wants to get access to unauthorized accounts".

First you need requirements for functionality. Then you can come
up with a threat model. Off-the-shelf CMS (open source or not)
does not have the same threat model.

> This is where testing (QA) comes into play, and again, if you don't do 
> that, all bets are still off.

You can't test security without a good threat model, which will tell
you the attacker's capabilities and determination and resources.
Then you can construct tests for QA to run.

> But to prevent an unauthorized person (read: not authorized with VPN 
> access) from exploiting potential flaws in the CMS, VPN is effective 
> (again, assuming all the proper secure practices for establishing a VPN 
> are in place).

Unless. Let's see. Unless the attacker has physical access to the
servers. Unless the attacker has physical access to the internal
network. Unless the attacker has stolen credentials.  Unless the attacker
has a trojan on an authorized user's machine. Unless the attacker has
social-engineered authorization. Unless the attacker can sign up for an
account automatically.

Oh, and VPN credential management becomes extremely complex
somewhere around 20 to 50 people.

> Sure, if there is a flaw in the CMS and you can't trust your employees, 
> the VPN isn't going to matter diddly. I assumed that was obvious and 
> didn't need to be stated.

Many security problems start with reasonable answers to
reasonable questions... where the asker didn't specify something
he thought was obvious and/or the responder didn't say something
she thought was obvious.

-dsr-



-- 
http://tao.merseine.nu/~dsr/eula.html is hereby incorporated by reference.
You can't defend freedom by getting rid of it.