To the List and to Jan and Mark,>> Mark McCullough <[email protected]> wrote:
>> My 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, "[email protected]"
<[email protected]> 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$liKe42baNan@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" <[email protected]> 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
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/
_______________________________________________
Discuss mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/
