Is our security team right

[eddieturbo]

Hi,

We are currently moving our clients systems to a new environment which
will require us to rebuild their environments from scratch onto new
hardware. The original servers were not built with any hardening
(Windows 2000) but we are going to correct this in the new environment.


Unfortunately someone in the security team has decided (presumably
cause it is easier for them) to build the standard OS and then harden
the machine. Only then are we going to be allowed to install our
applications on the servers!

Now excuse my ignorance but should it not be the other way around -
install OS, install Apps, confirm they are working, make (hardening)
security change, test app ........... if it still works continue, if it
does not then roll back hardening step and identify why it has broken
the app ????

Am I missing something? Can anyone point me to supporting documentation
which will allow me to stop this happening (and me spending weeks
trying to work out what is wrong)?

Thanks,

EddieT

 

[Roger Abell [MVP]]

It seems to me that the procedure would depend on the objective.
What the build person is doing seems to me to be possibly, and/or
partly, right. Possibly - if the hardening is doing the correct things.
Partly - they are apparently not providing you with the list of those
things. A server build engineer that does have a valid server result
would have a reason why each setting is as it is, and would have a
basis on which to say - this is the platform deployed.

However, that is not helpful dealing with an app that does not meet
the bar for that platform. This is where the "partly" comes into it.
Apps may be debugged in a number of ways. What you outline is
of use to admins intalling apps but without knowledge of what the
apps do or require, at least in detail. It is a methodical approach
that is sure to determine the point at which the app fails. However,
from this you end up knowing what OS settings cause the issue, not
what of the app is problematic. The other way around, is testing the
app incrementally for its functions. This of course is not possible if
the app completely falls on its face and fails to install or run at all,
but if this approach can be taken then one is diagnosing the app
directly. The reality is probably somewhere in between these two.

Now, as I initially said, it depends on the objectives.
If the objective is to have a platform on which a suite of apps works,
or if the objective is to have an environment that can meet a defined
set of security/privacy requirements, then one might take a different
approach in the continuum between the two approaches.

 

[Karl Levinson]

Unfortunately someone in the security team has decided (presumably
cause it is easier for them) to build the standard OS and then harden
the machine. Only then are we going to be allowed to install our
applications on the servers!

Now excuse my ignorance but should it not be the other way around -
install OS, install Apps, confirm they are working, make (hardening)
security change, test app ........... if it still works continue, if it
does not then roll back hardening step and identify why it has broken
the app ????

Am I missing something? Can anyone point me to supporting documentation
which will allow me to stop this happening (and me spending weeks
trying to work out what is wrong)?

Sorry, I don't see any problem with the way they are planning to do it. I'm
also not sure how it will harm you if it is done this way. You're going to
have to research what the problem is no matter what way it is done. They're
not going to make one change, then let you test, then make another change.
They're going to apply them all at once. MS has some tools that can make
this process easier, especially for Windows 2003 and XP, and filemon and
regmon from www.sysinternals.com may help too. A good migration plan such
as keeping the old servers online until the new servers are validated as
working may also help prevent pain. But either way, migrating can mean some
unavoidable pain.

 

[eddieturbo]

Thanks to both of you for replying.
It appears that I will have to approach this with a more open mind than
I have done up to now.

eddieT

 

[Steven L Umbach]

That probably makes the most sense and follows guidance in the Windows 2003
Server Security Guide.

http://www.microsoft.com/technet/security/prodtech/windowsserver2003/w2003hg/s3sgch04.mspx

Though more inconvenient it is more secure to lockdown first and then find
out why something does not work rather then have it work and then lock it
down to see what happens. You probably won't find too many problems and you
can post back here and/or in the server.security newsgroup if you do and
maybe someone can help. The link below may help if you run into problems and
always check the logs via Event Viewer for clues. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;823659

 

[Seeker]

Unfortunately someone in the security team has decided (presumably
cause it is easier for them) to build the standard OS and then harden
the machine. Only then are we going to be allowed to install our
applications on the servers!

Now excuse my ignorance but should it not be the other way around -
install OS, install Apps, confirm they are working, make (hardening)
security change, test app ........... if it still works continue, if it
does not then roll back hardening step and identify why it has broken
the app ????

We have had this debate where I work. I think the important point is
that the server is hardened before being attached to the network, or if
that is not possible, then use a host-based firewall to protect the host
before hardening (and ideally leave it on afterwards).

That being said, my personal experience with hardening Windows is that
it is sometimes easier to harden first and then install the app. The
reason is that the app will sometimes grant itself a user right or
permissions it needs to function during the install. If you harden
afterwards, you may take that away.

*That* being said, the vendors often do things which aren't necessary.
I've been able to take away privileges with no ill effects... sometimes.

Windows hardening is somewhat of a black art. It's much more difficult
in my experience than hardening Linux. I rarely have applications
problems after hardening Linux.