Post by Jan SchaumannMy biggest battle? The false belief that every improvement to
security hurts usability and every improvement to usability hurts
security. It is common in people who have been doing things long
enough they should know better, rather than just the newer people.
I think that's a very good and important point: the long-held beliefs by
(proudly grumpy) old-timers may well do more harm than any wide-eyed
naivete of junior people.
I would like to point out that Mark's beginning statement has been true, as it still is today, since companies have had DP/MIS/IT departments. After many years working in this field, the real issue regarding this subject, is that the wrong priorities are stressed if you wish to have a more secure IT.Â
Getting the App/Prog to market first (no matter what, attitude) is the wrong priority. Security that is part of the foundation of whatever (Op Sys, App, Protocol, Service, etc.) will allow solutions for unseen problem to be more quickly resolved, if developed and tested properly. Taking Short-cuts to get to market has not been the solution in the long run. If the foundations are wrong then replace them with new ones and not by tacking on fixes.
An example of this would be Steve Jobs's choice to build his MAC Os upon a more securely built, than other OS's that he had a choice of at the time, was the right direction to take, and this has been proven over time. I understand that it was FreeBSD.
I take offense to the implication that "grumpy old-timers" seem to be the roadblock. The real issue are persons with Closed Minds. These persons can be younger or older. The technology of today, just like our science, is built upon the foundations from the working past, such as Virtual technology from mainframe days. The working concepts just took the tech in another direction. Is the concept really a brand new concept or just applied differently ?Â
These are my views since starting in computers when I was a high school teenager and corporations were pretty much the only ones that needed and used computers. I thank the list for letting me present a different view on the same issues. I wish you ALL a Happy Holidays !
Sincerely,Harvey RothenbergSystems Integrator/Security Specialist
 âScience without religion is lame. Religion without science is blind.â Albert Einstein
On Saturday, December 6, 2014 2:37 AM, "***@nym.hush.com" <***@nym.hush.com> wrote:
Hi Jan!
I like that you are doing your homework! That's a good thing :)
Now on to some various topics that should help you out a bit. If these have been pointed out previously, just consider them confirmation on that topic.
I didn't have time to read through all the responses.
1) Linux file system permissions as they pertain to webserver functionality. In practice, it's great to have a layered security approach. Granular permisisons can be burdensome. Especially with resellers who like to have one user own a couple hundred wordpress sites on a server.
That wouldn't be so bad, except every plugin they install will eventually lead to an exploited server with hundreds of back doors and shell scripts hidden in every nook and cranny. CMS based sites are already inherently insecure, however with the correct user/permission structure you can limit the blast radius. The webserver user (www-data, apache, nobody) should never own the site. The webserver only needs read-only permission to the site for it to run. All updates should be carried out by an unprivileged user that owns the site.
Any directory that shouldn't have php rendered in it, should have an .htaccess directive that prohibits it, image directories for example.
Always do a quick security assessment of newly provisioned servers and review their filesystem permissions. Is /root world read/writable? it's shouldn't be. Too often I see simple mistakes like this that can cause quite a few issues for those who use control panel software like cPanel. Get a program in place for hardening all newly provisioned systems. I could go on forever about webserver/system security. So I'll stop here.
2) Learn regex and some other scripting language(s) - you will use it. (bash(required) - perl, python, c#, c++) and it makes you more desirable.
3) When it comes to passwords - I've seen many opinions on this in the responses you've gotten so I'll be brief. In many cases you can't opt for SSO or 2 factor. I tend to encourage end users to pick pass phrases if they must use a password. A passphrase should be multiple terms/digits/special characters. A dictionary attack will generally not be able to crack these. Avoid common phrases and memes. "my2d0NkEy$***@s" Use a password manager software that will generate random passwords if you can't remember them. LastPass or something like that.
4) Keep a KB and/or if you have it a case/ticket system and write things down in detail, because you will forget how you solved that one issue 6 months to a year+ ago.
5) Most organizations get so tunnel-vision on the next great thing, they tend to not keep up with updates/patches/maintenance for existing infra. Don't fall into that habit. Help your organization develop a maintenance program that will roll like clock-work once it's set up. Set aside the time each month to ensure you get it done. This is a compliance requirement!!!
6) Also ensure you audit and test your solutions to ensure they are always doing what they were implemented to do. I can't stress it enough - MONITOR EVERYTHING - use SNMP, use WMI, don't rely on PING for downtime events. Rely on actual processes that enable the functionality of the system. If those processes die due to whatever reason and the system is still up - how long until you notice and resolve? How many things were impacted? You can avoid not having these answers by ensuring you have everything in your arsenal monitored and acted on.
7) PCI - Don't offer information you don't have to. "Oh yeah we have an IDS, we finally got it working after being down for 8 months" <-- avoid that. Generally, the QSA won't care, but if you happen to get the one who does - he'll see it as a red flag and start digging deeper for more evidence in everything else and make your life more difficult. Just say "Yes we have IDS." You want them in and out. If you do have issues with something that could ding your compliance, be freaking honest. "This system is not patched right now because we have a particular mission critical application that will break if we do. But we are working on phasing it out/updating. We monitor all logs, employ the use of FIM, and access is strictly controlled via SDN/WAF/FIREWALL/ACLs/ etc.." This answer is more acceptable than "This system isn't patched and there's nothing we can do about it"
8) For PCI or SSA16, you need evidence. So collect it on a regular basis. Quarterly works. Have a central repository set up and dump your evidence in there. This will range from reports to screenshots. This way you aren't scrambling to provide it at the time of assessment.
9) Don't be afraid of breaking stuff. Cause you will, and you will learn from it. If you avoid doing particular things at work because you are worried about screwing up - you won't get anywhere. If you are absolutely unsure, simply ask. There's no harm in asking. Make mistakes (unintentional of course), if you are in an organization that hangs you out to dry over a mistake - then you are in the wrong organization. It's processes and controls that should be evaluated when mistakes are made. It could be a training issue, but in other cases it is usually the process that is broken.
10 ) Understand the workflow and how every solution interacts with your traffic/data. This will help you to better troubleshoot and identify everything that touches that data from point a to point b within your network.
Hopefully some of this hits a chord and helps you in your endeavors. I wish you the best!
Alicia
On 12/3/2014 at 9:48 AM, "Jan Schaumann" <***@netmeister.org> wrote:
Hello,
I'm currently exploring the intersection of #sysadmin / #infosec[1] a
bit. There is obvious overlap, yet at many companies the two camps also
frequently end up at loggerheads. I'd like to collect some feedback:
What #infosec or (PCI) compliance mandates and rules drive you nuts?
What (seemingly or actually) pointless, braindead things are demanded of
you?[2]
On the flip side, what are some of the security related concepts or
fundamentals that you think junior sysadmins are frequently lacking or
having trouble understanding?[3]
Feel free to email me off-list, if you prefer. Alternatively, you can
also reply to the tweets referenced.
Thanks in advance!
-Jan
[1] https://twitter.com/jschauma/status/540153322670661632
[2] https://twitter.com/jschauma/status/539626083583541249
[3] https://twitter.com/jschauma/status/539918484663062529
_______________________________________________
Discuss mailing list
***@lists.lopsa.org
https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/