In a message dated: Thu, 22 Jun 2000 10:53:10 EDT
Bob Bell said:
>The drawbacks (or even problems) with this setup are:
>(A) How do I handle information exchange between these networks? If
>they're separated for security, how do I put my latest patches onto
>the test machines, or telnet in and run commands? (You sysadmins may
>have an answer, and I'm interested in the proper "secure" setup)
Ideally use ssh to log into other machines and move data between machines,
however, there's no reason why you couldn't use normal ftp and telnet
(provided you comfortable with the fact that these commands transmit your
password in cleartext).
>(B) While the production environment may be running different software
>than the testing environment, it still is going to be somewhat recent.
>We have what we call an IFT, or internal field test, where we install
>our own unreleased but close-to-being-done software. I can't see this
>going away, as how can we tell a customer how good our product is when
>we aren't even using it ourselves yet? However, at this stage of the
>game, there may still be some bugs in the product, perhaps (though
>hopefully not) serious enough to cause security compromisses.
Well, obviously compromise needs to come into play at times. I would
recommend that in these instances (best case scenario) this team would have a
member of the sysadmin staff actully dedicated to them. This would provide
sysadmin skill dedicated to this team, and hopefully this environment could be
located in a separate physical location such that access to the location can
be physically secured. This "lab" could be connected to the normal production
network and used in a "real life" scenario. When the software is "really
done" it will likely be released to the whole company to run anyway.
Now, granted, this is the ideal situation and may not work in some instances.
I don't have an answer for all possible scenarios, since each one is unique
and separate. But I believe that through co-operation and communcation
an solution agreeable to both sides could be met.
>(C) Given that I have root on my own machine, the main thing we are
>doing is keeping it separate from production machines. Why? It was
>stated that anyone who knows what they are doing can extend root on
>one machine to root on another in the same environment, exploiting
>things like NIS. Well, if such a problem exists, shouldn't it be
>fixed? Since we are writing all the software for a supposedly
>high-end UNIX, shouldn't we be confident that these types of
>situations shouldn't occur, and then rapidly fix them when they do?
Yes, we should definitely fix the problems exist, but the problem exists now,
and it's not Fidelity Investment's job to fix that software, or Nortel
Networks', or Lucent's, etc. All these companies have people writing software,
in Unix environmnets, but not one of them is working to fix the inadequacies
of NIS (Sun tried, that fiasco is call NIS+, and even Sun isn't using it!)
>(D) Keep in mind that a malicious employee is writing the software
>that will eventually be used in the production environment. If he is
>really malicious, the possibility exists for him to specifically
>overlook some security flaw he created and wait for that software to
>be installed in the production environment.
Absolutely. And there's not much we can do about that other than knowing
where we get our software from. There are companies who certify software like
RSA, L0pht, etc. For open source, there are md5 checksums and source code.
As I said earlier, we can't possibly protect against every conceivable idea
someone may have to thwart our efforts, but we'd be negligent if we ignored
those things we *can* do.
>(E) Let's not overlook the people factor. I know you sysadmins would
>probably disagree that this should be a considered factor, but I feel
>obliged to at least point out the dissension (sp?) that may occur
>among employees. A company may find it harder to attract quality
>engineers when they balk at not having root access to their own
>machines. If they are really good they'll recognize a properly
>secured configuration, you say. Perhaps, but let's at least keep this
>factor in mind.
Well, I think it depends on how the environment is presented. If the
potential candidate is told "No one has root access other than the sysadmins,
period!" and it's presented in such a draconion and dictatorial manner, than I
can't blame them for not wanting to work there (Raytheon anyone?).
But if it's presented in a manner that extols the benefits and the level of
security that the sysadmin team has obtained, and the engineers who do work
there have learned how to do their jobs just as productively as before, I
don't see this as a problem. It's all in the delivery as they say:
"We're really proud of our network, the sysadmin team has bent over
backwards making sure we're secure. We all use sudo to access
stuff that requires root priviledges, everyone uses ssh to log
into remote systems or move data between systems which aren't
connected to the production network (or anywhere for that matter),
and this here is our pride and joy. A state of the art development
lab that is completely isolated from the rest of the network. In
here we have complete access to root on every machine, we can set
up any network scenario imaginable all on our own, and simulate
potential customer sites and problems. Again, if we need something
on the production network, we use ssh to grab it off one of the
servers, or to log into our desktop machines so we can run our e-mail
clients. It's really cool!"
Which environment would you want to work at. I'd prefer the latter, since
they take security seriously, I've worked in the former, and let me tell you,
security there was a joke! (Rule of thumb, if the gov't is at related, you bet
security is not seriously employed at that site. Raytheon, Lockheed, FBI, CIA,
NSA, Los Alamos, all of them have had serious breeches of security.)
>Please note that I am *NOT* trying to antagonize any sysadmins. I
>respect the quality of the sysadmins on this list, as they generally
>appear to be higher knowledgeable, and I find this an interesting (and
>classic) discussion.
I understand that, and likewise, we're not trying to antagonize anyone here
either. Rather, we're trying to point out that security is something serious
and should be taken as such. Additionally, we're trying to point out that
security is something that needs attention from everyone, not something that
just gets paid lip service, or dished off to the sysadmins. It's just as
important for the CEO to observe good security practices as it is the
sysadmin. Good security is a team effort. If one person doesn't play, the
whole team suffers.
--
Seeya,
Paul
----
"I always explain our company via interpretive dance.
I meet lots of interesting people that way."
Niall Kavanagh, 10 April, 2000
If you're not having fun, you're not doing it right!
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
