Subject: [Netconf] SarbanesOxley and super-user

From: Phil Shafer <[email-masked]>
Date: Mon, 22 Mar 2010 14:13:36 -0400

Googling sarbanes oxley super-user yields some links that discuss
the issues:

http://erpseminars.com/files/SuperUserAccessBestPractices

http://ca.com/files/brochures/superuser113007.pdf

Basically it made many organization adopt tight policies
about the idea of "super user" and who has access to it.

Thanks, 
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 22 Mar 2010 16:08:16 -0700

> about the idea of "super user" and who has access to it.

OK, a server MAY (not SHOULD) support a superuser.
If so, it should be configurable in the server CLI.
When used correctly, a superuser account can help
prevent operators from fat-fingering a catastrophic
system change, if nothing else.  When the 'sudo' program
is used as a front-end, then root logins can be avoided.

In nacm.yang, the /nacm container is tagged
as nacm:very-secure, because even reading the
ACM configuration can aid an attacker.  So by
design, no NETCONF user can possibly add any
ACLs if NACM is enabled.

What are the requirements for NETCONF bootstrap configuration?

IMO, it is a vendor choice whether to require a console
connection, or allow a superuser to configure in-band,
or require the initial startup config to contain the bootstrap
ACM configuration. Or none-of-the-above, e.g. radius.

My concern about the current casual reference to radius
in the 4741bis spec is the level of interoperability that is possible.
Is there a standard way to allow a user invoke
the edit-config operation (for example), that every
radius user will find obvious (I don't know radius)?
Or is it different for every vendor?

Is somebody going to write an RFC on how to meet the NETCONF ACM
requirements using a radius solution?  If so, that would
acceptable.  I prefer to have a simple mechanism available in
the NETCONF server, especially if I am worried about the radius server
availability impacting NETCONF server access.

>  Phil

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 22 Mar 2010 16:22:44 -0700 (PDT)

> ACM configuration. Or none-of-the-above, e.g. radius.

I think that is fine.

> Or is it different for every vendor?

I wouldn't mind if someone defined a standard way of doing this.  But
I think it is important that the NACM document does not preclude
external authentication or external authorization.

Also, NACM defines a couple of concepts; module rules, data node rules
etc.  If we can agree on these concepts, it will be easier to write a
standard mapping to e.g. radius.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 23 Mar 2010 00:52:41 +0100

> Or is it different for every vendor?

RFC 5607 defines management policy and privilege attributes. They do
not carry detailed access control rules but instead select one out of
several access control policies to be applied to a RADIUS
authenticated session.
 
> requirements using a radius solution?  If so, that would acceptable.
> I prefer to have a simple mechanism available in the NETCONF server,
> especially if I am worried about the radius server availability
> impacting NETCONF server access.

You likely want a mapping of an authenticated user identity to a role
and the RFC 5607 attributes can be used to do setup such a mapping.
The access control rules applied to a role remain local configuration.
This is the model ISMS ended up with.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>