[PLUG] best practices

Quentin Hartman qhartman at gmail.com
Mon May 25 20:57:11 UTC 2009


On Sat, May 23, 2009 at 12:40 PM, Ed Sawicki
>
>
> Ed
>
> 1. The customer wants users to be able to contribute content
>    to their Web server, which runs Apache and MySQL on Linux.
>    Most of the time, this means users saving PDF documents
>    to the Web server so other users can access them via their
>    browsers.
>
>    He has Samba running and has configured the Web site's
>    DocumentRoot to be a Samba share. Every user in the
>    company can now access all the Web site data. The
>    MySQL tables are not in DocumentRoot but there are PHP
>    files in the DocumentRoot that access the tables. I'm
>    guessing he thinks he'll control security by only mapping
>    drive letters for certain users.
>
>    I mentioned to the customer that this is a significant
>    security issue and that there are more secure ways for
>    users to contribute content but he is unconvinced (see
>    item 2).
>

I don't know that I'd call this a "security issue" in and of itself. I mean
really, if he trusts everyone who has this access and/or they need it to do
their work, the security is exactly what it needs to be. My biggest concern
with this is that it's "weird", and weird things invariably cost more to
maintain. Doing things "right" in terms of security for security's sake is
never going to sell. The business owner will need a business reason to
change their practice. Some way that is easier / faster / cheaper than the
current way. I think it would be worthwhile to find out _why_ things are
setup the way they are and propose a solution that solves the original
problem more elegantly, while also conforming more closely to best practices
in general, with specific emphasis on security.


> 2. The customer ignores security issues because:
>
> a) He claims they are on a "private network"; they are safe.
>    The Web server serves only internal users; it cannot be
>    accessed directly from the Internet. However, their
>    "private network" is not private in the sense of NAT
>    and RFC1918 private addressing. Everyone in the company
>    has a public IP address. Every desktop computer runs
>    Windows with the usual complement of Windows applications.
>
>    Their border gateway/firewall provides insulation from the
>    outside but I'm able to use a variety of protocols, such as
>    SSH, to make connections to hosts on the Internet from
>    their network. He seems to be unaware of threats that
>    originate from the inside.
>

This is naive. One must have defense in depth. Unless a machine needs to
have routable IP to provide a service, it should not have one. End of
discussion. This is the security problem, not the web server setup in and of
itself. If one of those juicy Windows machines gets whacked, they're just a
single hop away from owning the (presumably public facing?) website. If that
happens, what is the cost to the business in terms of goodwill / trust?
Again, make the argument based on business values. Trying to sell security
with "we need to be more secure" rarely works. Even if it does work, it
makes the security guy look like a resource sink to the execs. Wouldn't you
rather look like the guy who paid for his fee several times over in
efficiency gains?


> b) Their virus scanners are up to date.
>

Well, my best advice here is what I've already said. Also, resist the urge
to say "I told you so" when they get hit by some zero-day that the scanner
didn't know about.

Also remind your friend that as an IT person, it's not his job to do risk
assessment. He's there to advise the decision makers with whom the ultimate
responsibility of deciding if a risk is worth bearing rests. If he lays out
the risks he sees in good faith, and does his best to make sure all the
bases are covered, and they decide not to change, he's still done his job.
Besides, when they come running to him for help rebuilding because their
site got destroyed, he'll likely collect a healthy fee.

Feel free to email me directly if you want more info.

QH



More information about the PLUG mailing list