Re: Role of a Security Administrator

[Magosányi Árpád <mag () bunuel tii matav hu>]

A levelezőm azt hiszi, hogy Maddy a következőeket írta:
[]
> 1. creating security policies, standards and guidelines

1.5 creating and updating security infrastructure

> 2. administering user and resource controls
> 3. ensuring security compliance
[]

I think that (1.5) is a unending task; If you know your systems, you will
always be aware of great holes in it. You shall plug them somehow.

> 1. Is it practical for the same group to perform task (2) and (3) ?
> Aren't they conflicting ?

There are more layers of (2). To put the locks on the doors (2.1), and to
give the keys to the correct personnel (2.3) . And to polish the doors daily (2.2).

I think 1.5, 2.1 and 2.2 are somehow close to each other. 2.2 is not conflicting,
but needs a largely different mindset and considerably less IT skill. So separating
them might be a good idea.

There are two different subproblems: You want to see if the locks are
put on the right places, and if the keys are given to the right persons.
About the second: On one hand ensuring its compliance is relatively easy
by automatic means (to ensure that subject S in A scope of activities
can assume only roles R1, R2, ...), and on the other hand it is the 
responsibility of the audit folks (that proper procedures for S getting
A are in place and ensured).
The big question is the position of the locks. And if you keep in mind
that the doors and the locks are always on the move because the industry
quickly runs, pushed by market forces...
You will soon realize that if you want to build a castle which can withstand
any little siege, you shall put any useable staff on 1.5, 2.1 and 2.2. You will
simply have no one to do 3, because they are already on the gates,
strenghtening them. And the marketing already insists on giving a new
service to your company's clientele, your executives decide on 
reorganising the company structure. Both of which means you shall
rethink of your security policies (and implementation) from the basics.

You have more options now; you will use all of them:
-Make (3) to be the second nature of your staff. Think twice, act once,
see the big picture, know every little detail, discuss the threats
and possibilities. Employ paranoid schizophrenic supermen.
-Do audits with outsiders. If your staff is even marginally good,
they will not found anything you wouldn't know in advance. But the
global-eyed auditors will create nice third-party executive summaries 
of the current state, the cracker type will scare your bosses to
death. They do extremely good for you: it is very healthy to have
an adrealin shower seeing your problems you thought of only one by one
nicely piled up in a big stack, and being assured that you have 
only those simply exploitable holes you knew of. And those reports are
very valuable when you use your next option (If you are still alive
and in your position);
-Beg for more resources to plug at least the most significant holes.
Cry, lie, steal, make dirty deals with anyone in and out the organisation.
-Educate everyone who has even marginal contact with IT; on the long
run (one ore two century) you will have nice little miracles also: the IT 
architects start thinking of security even when they design a system,
the user community will behave in a little bit more security aware fashion,
the security experts of your outsourcing company will understand your
reasons (a bit more than those of their "experts"),
even (with the help of all your friends, relatives and enemies) you will
be able to explain to the marketroid, what kind of legal and technical
brakes shall he build into our next service if he don't want to end
up in jail.

> 2. Some said task (3) belongs to audit group but from my discussion with
> my audit folks, they are interested only mainly in accountabilities and
> controls (and proper procedures), they do not perform micro-analysis of
> systems and networks to ensure security compliance. Are they telling the
> right things ?

This is the two-faced (j)anus of IT security audit (if we don't think of
the grammatical problem of the audit trail for a while); There are 
guidelines and procedures, which can be auditable with the good old
audit methods. But (I love MJR's plan to certificate a lan bridge as an A1
device) there are those little tricky technical d3t41lz.
For vitality use vitamins, for brutality use brutalins.

> 3. I am thinking of splitting the IS group into 2 teams, a security
> implementation team and a policy & compliance team. However, recent
> assessment by a contracted consultant recommends that there will be a
> conflict of interest in the IS group performing both implementation and
> compliance verification tasks.  I see that compliance verification
> ensures the quality of the implementation and there is no conflict. What
> do you guys think ?

I think that there is only a mild conflict of interest. It is easily
zeroed out with good commmunications. I just simply like when you are deep
down in some hard problem with your pair, you get out an
extremely good idea from your pocket, your pair starts to hammer it
with intergalactical objections, you keep it polishing until both of
you satisfied with it, use it against the problem, and the problem goes
away. Or when you come in at the morning and see _that_ smile on your
pair's face: you have made a little error in the 795th line of some config
file. But you go out together with your families after work.
[Hi Edge!]

Your biggest problems will be with the staffing, education and resource
problems, not with these minor problems. This art is full of pressures,
and those who can stand them, will not have time to go to each other.
And of course don't forget to make a team from your men.

> 4. Another possibility would be to move the security implementation
> responsibilities  to the system administrators and the IS group would
> concentrate only on policies and compliance tasks. Is this a common
> practice ?

There are two problems with it, which is one problem. The security
administration and the system administration shall be separated.
Your average system administrator will not be able to tell even
the minimal necessary information for making the system secure.
And they will turn off any security measures at the first time
they think that in their way to find or correct a problem.

> I am sorry for the long mail but the answer to this cannot be found in
> any textbooks. :=) I don't have much choice other that to resort to

Because there is no good way to go. Look at the situation from a
holistic standpoint, use your brain and try to find the right problem
to the answer (which is 42 as we all know).

> expert opinions on this. My most sincere appreciation to anybody who can
> contribute to this. TIA
>
> Rgds
> Maddy
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () nfr com
> http://www.nfr.com/mailman/listinfo/firewall-wizards

-- 
GNU GPL: csak tiszta forrásból

_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://www.nfr.com/mailman/listinfo/firewall-wizards