Currently i've been hired as an advisor. By hired i mean they are giving me 100 bucks for my opinion.
This company wants a CMS. Their IT person is a security guru, he refuses to use one that he will haveto protect because simply, it's too much extra crap. Beforehand their webserver just had apache installed, and all files were static HTML. Now his business is looking really to find someone to find the least objectinable software. So so far the concepts from other people have been "just remove the copyright, no one will ever figure it out!"... Yes i facepalmed there too. I'm think security through obscurity would be their best best, using a simple cms. KuJoe recommendation from a while ago, SSnews came to mind, single file, with a flatfile database. If the database was correctly put somewhere, that area could be encrypted.
Is this the right approach to be taking to this situation? I'm really thinking its the best they've had, but before i submit my final suggestion.
How large of a project you looking at? I mean flatfile can be great but if your looking at hundreds and thousands of pages you'll want a database driven CMS.
And, obscurity can work well you'll just have to do all the templates from the ground up (so they can't look at common classes and what not).
(2011-09-07, 04:07 PM)Alex Smith Wrote: [ -> ]How large of a project you looking at? I mean flatfile can be great but if your looking at hundreds and thousands of pages you'll want a database driven CMS.
And, obscurity can work well you'll just have to do all the templates from the ground up (so they can't look at common classes and what not).
We are looking at 200-300 pages maximum at one time.
I don't want to be a grape (but I probably am being one) but isn't this suppose to be "your job".
(2011-09-07, 03:58 PM)Aristotle Wrote: [ -> ]This company wants a CMS. Their IT person is a security guru, he refuses to use one that he will haveto protect because simply, it's too much extra crap. Beforehand their webserver just had apache installed, and all files were static HTML. Now his business is looking really to find someone to find the least objectinable software.
Sounds awfully familiar. My uni had the same security concerns about CMS and they ended up using a CMS system that runs in the Intranet only and generates static HTML files for the outside world. In theory its a great compromise, you get all the advantages of a CMS and at the same time no new security concerns for the world wide web. Plus you also have speed as no dynamic content means no database and no PHP, nothing that could put a load or a strain on the server.
In practice however, the system was horrible. It didn't have any real support for menus so if you wanted one you ended up taking one and copy&pasting it for every single page. Which worked fine until you wanted to add a new menu entry which meant having to reimport, and rebuild the menu for an awful lot of pages.
If security means you have to use a system that will force you to work with two legs and one arm bound behind your back, then thanks but no thanks.
Taking a small unknown cms and relabeling it or any other kind of security through obscurity is even worse, though. Take a CMS that is big, active, well known, and maintained by professionals (real ones, not the self proclaimed kind). There are many CMS out there that are used by companies and supported by them too.
Then all you need to do is to hire someone who will be responsible for it; that person should involve him/herself with the system so that he/she knows it inside out and who will be responsible for updates and maintenance. Add another person who knows about security (could be the same one) and you're good or at least not any worse than anyone else on the internets.
There's no guarantee you won't ever get hacked but you should make sure that when it happens, someone is there who will know what to do and what are the right steps to take. In a way that will be worth a lot more than some security guy whose idea of security is to just pull the plug (or never put the plug in in the first place). While that's undoubtely secure, its also highly impractical.
I'm a believer in security through obscurity. I hide certain details of my security layers because I know if they were known they would be less effective. But I don't think using an obscure script is very obscure. And security through obscurity is not the "best bet" either. Most likely an obscure script is also weak. Site are often scanned with sql injection scripts so obscurity in that regard is pointless. Whether it's a custom script or one well known. IMHO you choose a script that updates when there is a security breach quicky. If a well-known exploit is published then it should be patched within 48 hours. Sooner if possible.
And if he's in charge of security he should work with what's most familiar. Having him learn something new might actually make the site less secure. So consider that and make sure any project you use is well documented and offers strong support.
Joomla for instance is a very well respected projected used by a lot of pros and big sites.
Security is also about backups and contigency plans. Always assume you're going to be penetrated eventually. So plan for that day. Have a host you can switch to, dns control, site and server backups, and anything else you can think of.
(2011-09-07, 08:26 PM)labrocca Wrote: [ -> ]I'm a believer in security through obscurity. I hide certain details of my security layers because I know if they were known they would be less effective. But I don't think using an obscure script is very obscure. And security through obscurity is not the "best bet" either. Most likely an obscure script is also weak. Site are often scanned with sql injection scripts so obscurity in that regard is pointless. Whether it's a custom script or one well known. IMHO you choose a script that updates when there is a security breach quicky. If a well-known exploit is published then it should be patched within 48 hours. Sooner if possible.
And if he's in charge of security he should work with what's most familiar. Having him learn something new might actually make the site less secure. So consider that and make sure any project you use is well documented and offers strong support.
Joomla for instance is a very well respected projected used by a lot of pros and big sites.
Security is also about backups and contigency plans. Always assume you're going to be penetrated eventually. So plan for that day. Have a host you can switch to, dns control, site and server backups, and anything else you can think of.
Offsite backups are a must too. Theres no point in backing up to a local hard disk only, as you can guarantee the day your host goes down and you lose your data server side, you hard disk will fail too (or other misc. problems with an onsite backup).
I'd say go for a well known script that, like labrocca says, is updated quickly. You have to weight up the advantages of an obscure script against the advantages of a script well know for security and updates.
(2011-09-07, 04:38 PM)Richard Wrote: [ -> ]I don't want to be a grape (but I probably am being one) but isn't this suppose to be "your job".
Have you never got an opinion on what your doing? I have an outline, and if you read, i said i have my idea, i was asking for possible critisms to the idea.
(2011-09-07, 05:04 PM)frostschutz Wrote: [ -> ] (2011-09-07, 03:58 PM)Aristotle Wrote: [ -> ]This company wants a CMS. Their IT person is a security guru, he refuses to use one that he will haveto protect because simply, it's too much extra crap. Beforehand their webserver just had apache installed, and all files were static HTML. Now his business is looking really to find someone to find the least objectinable software.
Sounds awfully familiar. My uni had the same security concerns about CMS and they ended up using a CMS system that runs in the Intranet only and generates static HTML files for the outside world. In theory its a great compromise, you get all the advantages of a CMS and at the same time no new security concerns for the world wide web. Plus you also have speed as no dynamic content means no database and no PHP, nothing that could put a load or a strain on the server.
That's actually ideal, was this a custom coded system? Or desktop based? If it exists, they will buy it 
In practice however, the system was horrible. It didn't have any real support for menus so if you wanted one you ended up taking one and copy&pasting it for every single page. Which worked fine until you wanted to add a new menu entry which meant having to reimport, and rebuild the menu for an awful lot of pages.
They have a dedicated website clerk who all they do is update the website, three days a week, so that's no issue, as that is what they are doing right now.
If security means you have to use a system that will force you to work with two legs and one arm bound behind your back, then thanks but no thanks.
Taking a small unknown cms and relabeling it or any other kind of security through obscurity is even worse, though. Take a CMS that is big, active, well known, and maintained by professionals (real ones, not the self proclaimed kind). There are many CMS out there that are used by companies and supported by them too.
Are you reffering to the coding standards? Or how it might never get a audit, so no one knows if the code is good? I hadn't really considered that since i assumed they'd require it.
Then all you need to do is to hire someone who will be responsible for it; that person should involve him/herself with the system so that he/she knows it inside out and who will be responsible for updates and maintenance. Add another person who knows about security (could be the same one) and you're good or at least not any worse than anyone else on the internets.
There's no guarantee you won't ever get hacked but you should make sure that when it happens, someone is there who will know what to do and what are the right steps to take. In a way that will be worth a lot more than some security guy whose idea of security is to just pull the plug (or never put the plug in in the first place). While that's undoubtely secure, its also highly impractical.
[b]Which they know, and i explained greatly, the Admin just wants to minimize his work for it, since before, it was just making sure apace was updated and secure. They are against hiring, i don't know why, training was considered, but no update on that, and i likely won't be. They are looking for a yay, and a link, or a nay.
(2011-09-07, 08:26 PM)labrocca Wrote: [ -> ]I'm a believer in security through obscurity. I hide certain details of my security layers because I know if they were known they would be less effective. But I don't think using an obscure script is very obscure. And security through obscurity is not the "best bet" either. Most likely an obscure script is also weak. Site are often scanned with sql injection scripts so obscurity in that regard is pointless. Whether it's a custom script or one well known. IMHO you choose a script that updates when there is a security breach quicky. If a well-known exploit is published then it should be patched within 48 hours. Sooner if possible.
And if he's in charge of security he should work with what's most familiar. Having him learn something new might actually make the site less secure. So consider that and make sure any project you use is well documented and offers strong support.
Joomla for instance is a very well respected projected used by a lot of pros and big sites.
Security is also about backups and contigency plans. Always assume you're going to be penetrated eventually. So plan for that day. Have a host you can switch to, dns control, site and server backups, and anything else you can think of.
Well, backup wise i'm told daily wise to an image server, that is setup. He is familiar with it, he just preferred it not.
As others have stated:
Straight up tell them that your advice is to "Stop being lazy and work for your paycheck".
I hate lazy IT people. They're the ones who are responsible for so many websites being hacked, because they try to do 0 work for their pay. Or as close to it as possible.
Great security imho starts server side. Because a site being hacked is really different than your server being taken.