RE: Getting security back from the sys admin

["Rivest, Philippe" <Rivestp () metro ca>]

Thanks for the 2 very good ids (work together to implement IDS, and the report one).

For our responsibility, we basically only manage user access right now. We lost all of our "responsibility" over the 
last few years due to lack of knowledge on the security team part. Having changed this situation, my director wants us 
to take some responsibility back (in a controlled way).

Basically, I can't even log on to Windows servers but I have root access to the unix servers (managed by the unix 
team). That shows that we didn't have knowledge over Microsoft, but on unix we were good enough to keep stuff. 
That is one of the many example and exception that we have to manage with.
We also have full access to SQL, but not the windows machine on witch its running..


So on every situation; I can only secure 1 part and not the whole. And since we are the one answering the auditors we 
need to AT the very least see how things are set up.


As for your help, I already added your ids to my document im writing. That with separation of duties did help a lot.

If anyone has other IDs, example or hints, please help :)

Merci
 
Philippe Rivest, Certified Ethical Hacker
Analyste en sécurité de l'information
Métro Richelieu
514-662-3300x3115
P Est-ce vraiment nécessaire d'imprimer cette page ?

-----Message d'origine-----
De : listbounce () securityfocus com [mailto:listbounce () securityfocus com] De la part de Franck Vervial
Envoyé : vendredi 7 décembre 2007 04:30
À : lowney
Cc : security-basics () securityfocus com
Objet : Re: Getting security back from the sys admin

  Hi,

Does security team have operational responsability or only
control/audit responsability ?
I have known the same situation and I think every body is winner if
the two teams work
together.
You will always need expertise of system guy in system and security application.
And they need help of security team for the things for which they
don't have the time for :
security survey, audit and risk analysis methods, etc.
A good thing to know in order to keep good relations is to not
under-estimate their skills
and understand the production contraints.

An example :
you have to install a security audit tool to product reports about
security level of systems
they manage. Instead of just install it and make a report that is very
red because of a lot of
security weaknesses. Give them the referential with which this tool
works (like CIS security), so they can make a effort to increase the
systems security level before reports.
That is good because two teams have the same aim : increase security.
Anyway the reports will produce some weaknesses because lack of time or other.

another argument is to justify budgets against direction (it is easier
when two differents
teams are agree that an IDS is necessary).

In clear : be dip)lomatic and works together, the kwowledge and
productivity of everybody will be better.

Hope this helps,

Franck

PS : sorry for bad english language ;-)