Registration & Incident Notification - Overview
Below is a high-level description and diagram of how asset registration and security incident management relate to each other. Accurate and complete registration of assets is imperative for information security operations and to safeguard Protected Data.
Please note: Users accessing socreg.berkeley.edu from an off-campus IP address, or while connected to CalVisitor, will need to use the campus VPN to connect.
Asset registration
-
(1) Security Contacts register assets in Socreg for which they are responsible. They also define Protected Data (PD) Applications (which could include other Unit Security Contacts’ assets in addition to their own).
Incident Management
ISO’s incident management system uses Asset and Protected Data registration information to:
-
(2) Initiate enhanced scanning of PD Assets.
-
(3) Set the significance of other incoming security events.
-
(4) Route security incident notices back to Security Contacts.
Registration & Incident Notification - Diagram
Periodically Review Registrations
It's important to periodically review your registrations, Security Contact information (Org node, email address), and Security Contact membership. Also, review registered assets (e.g., subnets, IP addresses, offsite hostnames, and devices) for accuracy and integrity.
For each Security Contact in your Security Contact list, select ‘View’ from the gear icon drop-down menu, and review each tab.
Things to look for:
- Is the Security Contact email address correct? This is the email address that is used by ISO to send security notices.
- Is the member list correct and complete?
- Does at least one member have ‘Receive FYI Email?’ set to Yes?
- Does at least one member have Admin privilege within the Security Contact?
- Are there Subnets that have Protected Data but are not behind a firewall? (To change subnet description information contact the Campus DNS Administrator at dns@berkeley.edu.)
- Are there Offsite hostnames with a Protection Level above P1? Is that still correct?
- Are there Offsite hostnames in a requested status? If so, there is an open ticket with ISO requesting more information or confirmation.
- Are lists of assets complete and correct? (If there are obsolete subdomains that need to be removed from DNS contact the Campus DNS Administrator at dns@berkeley.edu.)
- University-owned Devices should be registered to a Unit Security Contact and not to individuals. (This is particularly true if the device is part of a Protected Data Application.)
- Only personally-owned devices should be registered to individuals. If University-owned devices are registered to individuals, use the ‘Contact Us’ link to send a list of MAC addresses for the devices along with the name of the Unit Security Contact the devices should be registered to.
Review Protected Data Applications/Services:
Security Contacts will be sent an annual notice to review PD Application and PD Service registrations. Security Contacts should review:
-
Protection Level(s) and record quantity
-
Components:
-
Subnets should be claimed.
-
Offsite hostnames should be approved and registered to a Unit Security Contact.
-
Devices: University-owned devices should be registered to a Unit Security Contact (not an individual).
-
The Security Contact for the asset does not need to be the same as the Security Contact that registered the PD Application. PD Applications should be registered to the Unit Security Contact that is responsible for responding to security incidents involving the PD Application. If you aren’t sure, contact socreg@berkeley.edu.
For PD Partners: If one Security Contact's asset is used in another Security Contacts' PD Application, that makes the first Security Contact a partner of the PD Application. Partners can add and remove their own components from the PD Application. Partners will be notified when their asset is included in someone else's PD Application. If a Security Contact feels that is incorrect they can remove the component or contact netreg@berkeley.edu.
For PD Service Owners: In addition to reviewing all of the above, review which PD Applications are consuming your PD Services.
Protection Level Matching:
A component within a PD Application must have a PL number equal to or higher than the PD Application it is a component of. That means that the controls applied to a component must be better than, or equal to, the controls necessary to protect data within the PD Application.
For example: “Medium-Secret Application” with P3 data can consume a PD Service “Encrypted Backup Service” as long as the service is rated for P3 or above. If the service is only rated for P2 then Socreg will alert the Security Contact.
Registering Components:
All components within a PD Application should be registered. In the case of Devices, they should be registered to a Unit Security Contact as opposed to an Individual.
Protected Data Applications with No Components:
Each PD Application registration includes certain attributes (name, description, Protection Level, record count, etc.,) AND one or more network components (IP address, Subnet, Device, etc.,). The first set of information is necessary to classify the PD Application appropriately. The second set is necessary to correctly identify the components within the PD Application, and more importantly, give the Information Security Office (ISO) information on which network assets to monitor. Until you add at least one network component to the PD Application, this registration does NOT result in increased protection from ISO.
Making Changes & Updates
If changes to the Security Contact’s registered assets are needed, someone in the Security Contact with the appropriate level of access should be able to perform these updates.
For more substantial changes like:
-
A Security Contact needs to be reorganized.
-
Assets need to be moved from one Security Contact to another.
-
A Security Contact needs to be retired.
-
Move a Security Contact into a subgroup beneath a parent.
Send an email to socreg@berkeley.edu describing the change needed and our office will work with you.