- What are the privileges for members in a security contact?
- What are Group Security Contacts used for?
- What are Service Provider Security Contacts and how do they work?
- How are security notices routed?
- Does the application support IPv6?
- Does the application support DHCP registration?
- What is the process if another contact is non-responsive when I want to claim or transfer something immediately?
- Security contact X and my security contact used to both claim subnet A. Why can't we still do that?
- Why can I see the name of another security contact that claims an individual IP address on some subnets but not on others?
- Can you display the email address of the other security contacts so I can contact them directly?
- What are the different types of email generated by NetReg? Can I opt out from receiving any/all of them?
- I've received an "IP address to transfer" message.
- What email address should I use for my security contact?
- Can I self-register Fixed IP address assignments?
- Can I self-register Dynamic DNS hostnames?
There are four privilege levels for any member of a security contact:
View-only: can view registration information.
Device: can make changes to Device registrations.
IP Information: can claim subnets, request IP Addresses, register subdomains and offsite hostname. Can register RD Applications. Can also make changes to Device registrations.
Admin: includes Device and IP Information privileges. Can also make profile and membership changes to the security contact itself.
A Group Security Contact (GSC) is created by a Department Security Contact (DSC) when a separation of responsibilities is needed. Each DSC will have an orgnode set, and the GSC will be associated to the department via its parent, the DSC.
A Group Security Contact can be used to help departments separate devices into sets that receive (or do not receive) IT support from a Service Provider Security Contact (SP SC). Additionally, when responses to security incidents is the responsibility of different groups (e.g., a research lab within a larger department, student systems vs. an administrative one) a DSC can create a GSC to receive targeted notices.
Service Provider Security Contacts (SCs) are a special purpose security contact. As a service provider, they don't have registered network assets, but they are flagged within NetReg as providing support for another SC. For example, the Service Provider SC might register devices for the Client SC. Service Provider SCs have "device-based" privileges with the Client SC; they can create, edit and delete devices from the Client SC.
Service Provider SCs can be grouped or departmental. Notifications about security events (compromises, vulnerabilities, etc.) will go to members of both Service Provider and Client SCs.
Security notices are routed based upon the most specific registration information available in NetReg.
For example, if an IP address has a registered security contact, the security notice is sent to that contact. If there is no specific IP address registration then the notice is sent to the security contact that claimed the subnet. Notices will also be sent to:
• the registrant contact role's service provider if any
• its departmental / parent contact role if any,
• and any contact roles that have 'CC SC' status for the IP address
OR, if the IP addresses is for a DHCP device (in the LIPs subdomain) the security notice will go to whomever was using the address at that time (to CalNet ID).
NetReg supports IPv6.
DHCP registration was added to NetReg in Oct 2015. For instructions on how to use NetReg to register devices for use with the Campus DHCP Service, please visit the "Register Devices" page in the NetReg documentation.
Overlap is not allowed in NetReg. If two departments share a subnet, during the data conversion the department who claims the most IP addresses for that subnet will get the entire subnet. The other department will get individual IP addresses.
Additionally, one SC will own and be primarily responsible for an IP address, although other SCs may be provided shared notification..
For complicated situations, e.g., where two different groups are responsible for systems on a subnet, a Contact Role created just for that shared responsibility might be the best solution.
NetReg is designed to facilitate communication between security contacts for the purpose of keeping network registration information up-to-date, without revealing private security mailing list addresses or allowing out-of-band communication between security contacts on other issues.
If you claim the entire subnet you can view the names of the security contacts that claim individual IP addresses on that subnet. If you only claim an individual address then you cannot see the names of the other security contacts.
No. Requests for IP addresses, CC IP Address status are handled via the request/approve/deny process. Any other communication issue can be handled by contacting ISO.
There are three types of email generated by NetReg:
- FYI emails: These emails are rolled up into a single digest which is sent once per day. Users can opt out of receiving the digest by setting "Receive FYI digest" to off. However, at least one Security Contact (SC) member should continue to receive them.
- Notices of "requests to approve or deny": These are sent within 5 minutes from when the request is made via the NetReg application, and are sent to all members in the SC. Users do not have the option to opt out of receiving these.
There are 4 kinds of "requests to approve or deny" which users may receive:
- Request to transfer an individual IP address. (Note: the request can be initiated by either the SC that currently claims it (request to give), or by the SC that wants it (request to take).)
- Request for CC SC status for an IP address
- Request for membership within a SC
- Request to create of a group SC within a department SC
- Notices to "outside" entities (i.e., ISO RT ticketing system, DNS Administrator, or IT Policy): These are initiated by NetReg backend processes or sometimes by NetReg users and are cc'd to any relevant SC's membership.
For example, when a request is made for a new departmental SC the request will go to the Information Security Office (ISO). ISO will conduct an intake process and will create the DSC.
You've received the message because Netreg has encountered a mismatch between the security contact that claimed an IP address (individually or by subnet) and the security contact that registered a subdomain.
(Note: In Netreg the assignment of a subdomain enables the transfer of IP address responsibility to the right party, but does not assign security contact responsibility).
For example, if security contact A registers a subdomain xyz.berkeley.edu and another security contact B claims subnet a.b.c.0/24 and there is a set of hostnames defined in DNS:
security contact A and B will each get a message suggesting that the IP addresses be transferred from B to A.
Either security contact can initiate the transfer: Security contact A can 'request to take'; B can 'request to give'.
If the other party agrees and approves the transfer then B ends up with the subnet and A has 3 individual IP records out of that subnet because of its subdomain registration.
Remember: NetReg does not automatically make the transfer because there may be alternate solutions to resolve the discrepancy. In the above example, security contact A could relinquish the IP addresses, or have their DNS hostname changed to something not in the xyz subdomain.
You are receiving this "IP address to transfer" message so that you can choose the best solution.
The email address should reach multiple people 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.
Department and Group Security Contact roles can register devices for Fixed IP address assignment – where a device always gets the same IP on its primary subnet, but a Dynamic IP on any other subnet – provided that the contact role has a registered subnet, with available IP address space, and a registered subdomain.
For details about registering devices for Fixed IP address assignment, please review the "Register Devices" page in the NetReg documentation.
Yes. Security Contacts can assign a Dynamic DNS (DDNS) hostname to a device when using Dynamic IP addressing (DDNS is not available for devices registered with a Fixed IP address assignment). Please review the "Register Devices" page in the NetReg documentation for details.
Note: Dynamic DNS hostnames will be reviewed by the campus DNS Administrator and changed if inappropriate.