Security Contacts


A Security Contact is a role used by authorized members to register IT Resources and to receive security notices involving those resources. It must have an email address that reaches multiple people either via a listserv, group address, or, ideally, a CalNet SPA account so that security incidents involving a department or group's IT Resources receive prompt attention. CalNet SPAs (Special Purpose Accounts) are CalNet IDs that can be shared by multiple users for collaborative purposes, and are recommended for this purpose. See CalNet's SPA page for information and instructions on setting up a SPA account for a Security Contact to receive security notices

One significant advantage of NetReg is the use of different kinds of security contacts (SC). This allows the application to support the different ways IT is managed within departments and groups; and at the same time correctly route security notices to the right party.

Departmental Security Contact (DSC):

The Department Security Contact (DSC) is the SC whose members respond to security notices, including routing as necessary, for a University organization or department. By definition, they are associated with a node in the organizational tree. Only DSCs can have child security contacts (i.e., Group SCs).

The initial creation of a DSC requires review by the Information Security Office (ISO).

Group Security Contact (GSC):

Group Security Contacts (GSCs) are created by DSCs when a separation of responsibility is necessary. Group contact roles will not have an org node set but will have a DSC "parent".

Both GSCs and DSCs have the same functionality within NetReg. They can claim, request, and transfer IP address entities. They have membership, receive and respond to security notices, and can register devices for use with DHCP. DSCs are associated with a node in the organizational tree, i.e, have an org node. GSCs do not have an org-node but must have a parent DSC. In that way, security incident reporting can ‘roll-up’ to nodes within the organizational tree. GSCs cannot themselves have children GSCs. This is to avoid the situation where GSCs link to each other but not to a parent DSC.

GSCs can be created for a variety of reasons:

  • Separating devices into sets that receive (and do not receive) IT support from a Service Provider Security Contact (see below).
  • Relatedly, to create sets of members for the purpose of providing service, i.e. GSC as Service Provider Security Contact.
  • When response to security incidents is the responsibility of different groups, e.g., a research lab within a department.

Note: It is not necessary to use GSCs to provide or receive support from another SC but it may make it more convenient.

When a DSC creates a GSC it will add its first member. The GSC is authorized by the DSC to register devices and restricted data applications, claim IP addresses and so on. The GSC’s first member can in-turn add any additional members. Individuals can be members in both SCs if that makes sense. In addition, notices sent to the GSC can also be sent to the parent DSC. This configuration option of the GSC is set by the parent DSC.

Currently there is no restriction to how many DSCs can exist at a given node in the organizational tree. However, in order to maintain accountability and strong authorization, it is highly recommended that the fewest number of DSCs exist at an org-node as is possible. The use of GSCs to separate areas of responsibility within a department is preferred to using multiple DSCs.

Individual Security Contact (ISC):

Each user of NetReg has an ISC used to request membership in other Contact roles or request creation of a Group Security Contact with a Department Contact role.  When DHCP registration is implemented in NetReg, a user's ISC will be used to register personally owned devices for use with the campus DHCP service.

Service Provider Security Contact (SPSC):

This SC provides IT management to another contact role, a client SC. As part of providing service it may need to update information belonging to the client SC. For example, the service provider might register devices for the client SC. SPSCs can be group or departmental.

A Security Contact has some devices that are managed by another party (e.g., an IT group in another department, IT Client Services, etc.) For purposes of notifications regarding compromises, vulnerabilities or security reporting, both organizations need to be associated with the devices.

The client SC selects its service provider from a list of available service providers.

Notifications about security events (compromises, vulnerabilities, etc.) will go to members of both Service Provider and client SCs. Security reports will show incidents belonging to both the Service Provider and client SCs, to their respective parent departments.

Client Security Contact (Client SC):

The Client SC is the customer of a Service Provider Security Contact (SPSC). Choosing a Service Provider in an attribute that Client sets for itself. Client SCs can be group or departmental.

Please contact for any questions, or additional support.