| Both sides previous revision Previous revision Next revision | Previous revision |
| abstract:caviness:security-changes-2025 [2025-10-20 14:05] – anita | abstract:caviness:security-changes-2025 [2025-10-20 16:32] (current) – [2025-2026 Caviness Security Change] anita |
|---|
| As part of the University's efforts to identify and mitigate risk to its networks and computing systems, potential issues with Caviness have been identified. It is necessary that we address those issues to balance risks versus users' ongoing access to and functionality of the cluster. The mitigations include: | As part of the University's efforts to identify and mitigate risk to its networks and computing systems, potential issues with Caviness have been identified. It is necessary that we address those issues to balance risks versus users' ongoing access to and functionality of the cluster. The mitigations include: |
| |
| * Augment SSH username/password authentication with multi-factor authentication ([[abstract:caviness:security-changes-2025#mfa|MFA]]) | |
| * Caviness will be moved into a different [[abstract:caviness:security-changes-2025#network-changes|network]] to isolate it from other campus computing systems | * Caviness will be moved into a different [[abstract:caviness:security-changes-2025#network-changes|network]] to isolate it from other campus computing systems |
| | * Augment SSH username/password authentication with [[abstract:caviness:security-changes-2025#mfa|multi-factor authentication]](MFA) |
| * [[abstract:caviness:security-changes-2025#hpc-passwords|HPC accounts]] for UD users will no longer synchronize with UDelNet passwords | * [[abstract:caviness:security-changes-2025#hpc-passwords|HPC accounts]] for UD users will no longer synchronize with UDelNet passwords |
| |
| |
| |
| IT RCI staff thank the community for their understanding as we work to better-secure the clusters and protect their access and their research computing resources. | IT-RCI staff thank the community for their understanding as we work to better-secure the clusters and protect their access and their research computing resources. |
| |
| ==== MFA ==== | ==== Network changes ==== |
| |
| One security control widely-used today is multi-factor authentication (MFA). A username and password are still employed, but additional credentials are required to successfully authenticate. For Caviness, the additional credential is slated to include either of the following: | To harden protection of critical University computing systems, the University is seeking to **HEAVILY-CONSTRAIN** Caviness users' access to those systems by introducing a "block all" firewall policy on connections made **FROM** Caviness **TO OTHER SYSTEMS** on the University's campus network. |
| |
| * The system attempting to SSH to Caviness is on the UD campus network (including UD VPN) | The DARWIN system has a similar policy already in-place by virtue of its being on a special network called the ScienceDMZ. The UD ScienceDMZ is not subject to the filtering and introspection that exists on other University networks and has a higher-bandwidth path to other institutions (Internet2). Logically: |
| |
| **OR** | * External-facing Caviness network interfaces will be **MOVED TO THE** ScienceDMZ to effect the necessary "block-all" firewall policy AND improve bandwidth and latency w.r.t. other institutions |
| |
| * Solicitation of a second passcode (e.g. six-digit code, push notification) | The ScienceDMZ firewall policy **WILL BLOCK ACCESS TO ON-CAMPUS SYSTEMS** like license servers and other clusters — effectively any UD system a user connects to **FROM** Caviness. IT RCI and Security have been working to capture a list of such systems, but Caviness community members **SHOULD TAKE TIME TO IDENTIFY ANY UD SYSTEMS THEY ACCESS FROM** Caviness and contact IT RCI. Exceptions to the "block-all" policy will have to be negotiated with IT Security on a case by case basis by IT RCI and affected parties. All such exceptions are audited annually by IT Security and will be subject to review for renewal. |
| |
| IT RCI is exploring options with respect to the second passcode and will provide the community further updates when a solution is chosen and a date for its implementation is planned. | ==== Multi-Factor Authentication ==== |
| |
| ==== Network changes ==== | One security control widely-used today is multi-factor authentication (MFA). A username and password are still employed, but additional credentials are required to successfully authenticate. For Caviness, the additional credential is slated to include either of the following: |
| |
| To harden protection of critical University computing systems, the University is seeking to **HEAVILY-CONSTRAIN** Caviness users' access to those systems by introducing a "block all" firewall policy on connections made **FROM** Caviness **TO OTHER SYSTEMS** on the University's campus network. | * The system attempting to SSH to Caviness is on the UD campus network (including UD VPN) |
| |
| The DARWIN system has a similar policy already in-place by virtue of its being on a special network called the ScienceDMZ. The UD ScienceDMZ is not subject to the filtering and introspection that exists on other University networks and has a higher-bandwidth path to other institutions (Internet2). Logically: | **OR** |
| |
| * External-facing Caviness network interfaces will be **MOVED TO THE** ScienceDMZ to effect the necessary "block-all" firewall policy AND improve bandwidth and latency w.r.t. other institutions | * Solicitation of a second passcode (e.g. a push notification) |
| |
| The ScienceDMZ firewall policy **WILL BLOCK ACCESS TO ON-CAMPUS SYSTEMS** like license servers and other clusters — effectively any UD system a user connects to **FROM** Caviness. IT RCI and Security have been working to capture a list of such systems, but Caviness community members **SHOULD TAKE TIME TO IDENTIFY ANY UD SYSTEMS THEY ACCESS FROM** Caviness and contact IT RCI. Exceptions to the "block-all" policy will have to be negotiated with IT Security on a case by case basis by IT RCI and affected parties. All such exceptions are audited annually by IT Security and will be subject to review for renewal. | IT-RCI is exploring MFA options and will provide the community further updates when a solution is chosen and a date for its implementation is planned. |
| |
| ==== HPC passwords ==== | ==== HPC passwords ==== |
| * UDelNet passwords will **NO LONGER BE SYNCHRONIZED** with HPC accounts; a user's HPC account password will be distinct | * UDelNet passwords will **NO LONGER BE SYNCHRONIZED** with HPC accounts; a user's HPC account password will be distinct |
| |
| IT RCI will provide a web portal for HPC users to reset the HPC password. Users will be asked to NOT reuse their UDelNet password as their HPC password. | IT-RCI will provide a web portal for HPC users to reset the HPC password. Users will be asked to NOT reuse their UDelNet password as their HPC password. |
| |