A knowledge base article about Socreg FAQs provided by the UC Berkeley IT Service Hub - Knowledge Portal
Table of Contents
Department and Group Security Contacts 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 Security Contact has a registered subnet, with an available IP address space, and a registered subdomain.
For details, please review KB0015567 - Socreg: DHCP Device Registration.
Yes, Socreg supports IPv6.
You've received this message because Socreg 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. In Socreg, the assignment of a subdomain enables the transfer of IP address responsibility to the right party, but does not automatically assign security contact responsibility.
Either security contact can initiate the transfer (Security contact A can 'request to take'; B can 'request to give'). Socreg does not automatically make the transfer because there may be alternate solutions, such as relinquishing the IP address or changing the DNS hostname.
Overlap is not allowed in Socreg. To ensure 100% security coverage without gaps in accountability, a subnet can only be claimed by one Security Contact responsible for responding to notices and remediating incidents. Typically, the department that claims the most IP addresses on that subnet will claim the entire subnet as the primary contact.
Socreg is designed to facilitate coordination without revealing private security mailing list addresses. If you claim an entire subnet, you can view the names of Security Contacts that claim individual IP addresses on that subnet. If you only claim an individual address, you cannot see the names of other contacts.
A Group Security Contact (GSC) is a sub-unit created by a Department Security Contact (DSC) when a separation of responsibilities is needed. While a DSC is assigned directly to an org-node on the Campus Org Tree, a GSC shares the org-node of its parent DSC. Common uses include:
Limitations: A GSC must have a parent DSC and cannot create another GSC.
To ensure Least Privilege, members should only have the access necessary for their role. For example, a student employee should be granted "Device" privileges rather than "Admin" to prevent unauthorized changes to membership or subnets.
| Privilege Level | Permissions |
|---|---|
| Admin | Full Control: Manage the Security Contact’s profile and membership, plus all IP and Device privileges. |
| IP Information | Network Assets: Claim subnets/IPs and register PD Applications. Includes all Device privileges. |
| Device | Physical Assets: Register and manage devices for regular and Fixed DHCP services. |
| View | Read-Only: Review all registration and asset information without the ability to make changes. |
A Security Contact must use one email address that reliably reaches multiple people, such as a bConnected List or a shared departmental address. This ensures that security incidents receive prompt attention even if an individual is unavailable.
Notices are routed based on registration information. If an IP has a registered Security Contact, the notice goes to them. If not, it goes to the contact who registered the containing subnet. Notices are also copied to:
Log in and click your name in the top bar, then click Settings. This is separate from "FYI messages," which are managed per Security Contact.
| Email Type | Purpose | Opt-Out? |
|---|---|---|
| FYI Digests | General updates on asset status. Sent weekly as a digest or immediately upon PD App modification. | Partial: Users may toggle the digest off, but at least one member must receive them. |
| Requests | Pending approvals for membership or assets. Repeated weekly until approved or denied. | No. |
| External Notices | Notices to ISO tickets, DNS admins, or IT Policy. | No. |
ISO uses a balanced approach for all hosts. Enhanced services for Protected Data hosts include more frequent vulnerability scanning, a wider range of intrusion detection signatures, ingestion of system event logs for alerting, and elevated response times by ISO staff.
If you need to claim or transfer an asset immediately and the other party is not responding to automated Socreg requests, contact the Information Security Office at socreg@berkeley.edu.
Please see KB0015628 - Instructions for Registering PL4 Workstations in Socreg for step-by-step guidance.