[Re: CMS Security]

[fred-/Lcn8Y7Ot68+JxQryabxnkEOCMrvLtNR at public.gmane.org (Fred at PlanetaryServer.com)]

Dan Ritter wrote:
> 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.
>   
It also depends on the scale of what we're talking about here. If it's 
just a small company, say, <=100 employees, that's one thing. If we are 
talking a Fortune-500 company, that's something else entirely.

In the latter case, you would already have -- presumably -- a 
knowledgeable IT staff in place, and so you would not be asking 
questions on this forum.

So I assume a relatively small company on a strict budget who can't 
afford the development costs of creating a *really* secure system with 
all the access controls, etc.

I have worked both for startups and Fortune-500s. The resources and 
budget are markedly different, as are their security requirements.
>> 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.
>   
And another hard part is balancing the costs of implementing a *perfect* 
security system with all the access control bells and whistles, vs. 
sending the company into bankruptcy spending lots of capital on 
something that has no direct ROI.

It's a balancing act, for sure.

Drupal has inherent access control, but I would doubt it's secure enough 
for "mission-critical" applications that demand high levels of security.

In fact, I would not trust anything written in PHP for that, for a 
number of technical reasons peculiar to PHP.
>> This also assumes that there are no critical software flaws (bugs) that 
>> would distort data or inadvertently allow access to a restricted area. 
>>     
....
> 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.
>   
Agreed. But in theory you could alter it to meet the threat model. But 
then it becomes a question of doing it that way vs. rolling your own (or 
a commercial package geared for security concerns).

...
>> 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.
>   
Yes, all true, and the price tag of dealing with each potential threat 
will escalate to the point of being unworkable for a small to mid-sized 
business.

So, one must decide where the biggest, most likely threats are and deal 
with them first, and if budget allows, for some of the more obscure threats.

I would deem it more important to have a solid "disaster recovery" 
procedure in place in case the worst happens. How does one recover from 
any of your "Let's see" examples or others no one thought of. Part of 
that answer will lie with technology; part with policy.

And of course, you'll have to be very convincing with the CFO.

-Fred