Security Best Practices for SC//HyperCore Customers

Backplane (Network Security) Best Practices

• Ensure your system is up to date with the latest release. Keeping a system updated is crucial because updates often include patches for vulnerabilities and flaws that could be exploited by malicious actors. Customers should upgrade clusters to the latest General Availability (GA) release of SC//HyperCore as Scale Computing makes them available to ensure they have the latest protections against potential security threats.

• A critical aspect of network security is safeguarding the backplane. The Scale Computing backplane is used by storage and virtualization management daemons to perform input/output (I/O) and administrative operations on the cluster. A compromised backplane would allow attackers the ability to intercept, modify, or disrupt data traffic. Backplane traffic is not encrypted in Scale Computing deployments and thus should be considered sensitive.

  Scale Computing offers three deployment options:

  1. A single Network-Interface-Cards (NIC) deployment.
  2. A dual NIC deployment with backplane over VLAN. Option
  3. A four-NIC deployment with two physically segregated LAN ports.

  A good best practice for customers who prioritize security is to isolate backplane and local-area network (LAN) traffic by using dedicated switches with separate NICs. Backplane over VLAN can be secure as long as the VLAN is appropriately configured. By securing the backplane, organizations can protect against intrusions and ensure that sensitive data flows within controlled and trusted pathways.

• To ensure the integrity of their network, all customers should implement a layered security approach, often called "defense in depth.” This strategy involves multiple layers of security controls, such as firewalls, intrusion detection systems, endpoint security, and network segmentation, each serving as an independent safeguard against potential threats. Network segmentation, in particular, limits the spread of any intrusion by dividing the network into smaller, isolated segments, each with its own security policies. This approach prevents unauthorized access from moving laterally across the network, making it much harder for attackers to access critical assets.

Authentication/Authorization Best Practices

• Implement and enforce a strong password policy for all users and admins. Strong password policy requirements should include:
  1. A minimum of 12 characters consisting of upper and lower case letters, numbers, and symbols.
  2. New passwords should be significantly different from previously used passwords.
  3. Require scheduled password updates.
• Ensure you use an approved OpenID Connect (OIDC) provider (ADFS, EntraID, or Okta) to manage access control. Scale Computing provides users with detailed information on configuring OIDC providers Okta and EntraID with their SC//HyperCore environments in the auxiliary documentation: Okta & SC//HyperCore and EntraID & SC//HyperCore. For other OIDC providers, please refer to the service provider’s documentation or contact Scale Computing Support.
• Leverage appropriate authentication methods and policy control available in OIDC providers. SC//HyperCore customers are strongly encouraged to use OIDC single-sign-on (SSO) / multi-factor authentication (MFA) security measures to secure their SC//HyperCore User Accounts. It is recommended that customers consult with their chosen OIDC provider’s documentation or support staff to determine best practices for configuring SSO or other layers of advanced user authentication protections such as MFA.

Logging Best Practices

• Use the system logging protocol standard (syslog) to transmit SC//HyperCore logs to a syslog server. Syslog servers (Getting Started with Splunk and SC//HyperCore) are used to store, route, and filter plaintext logs for a period of time as defined by the user. Some other options for syslog servers include:
  • Rsyslog (Linux)
  • Visual Syslog Server (Windows)
  • Kiwi (Linux, Unix, Windows)
• Leverage your syslog server’s centralized records to audit and analyze user activities and maintain records according to your compliance policy needs.
• Use SC//HyperCore’s native syslog integration functions to apply filters according to the type of data contained within the logs. Organizations may then apply rules in their syslog server’s access controls (consult your syslog server’s documentation to determine if the level of access control features meets your policy requirements) to configure and monitor user access authorization.
  • For example, adding the Personally Identifiable Information (PII) filter to logs that contain sensitive customer or user information. In this scenario, a customer may choose to allow only users with the highest level of authorization to access logs with the PII filter.

Physical Hardware Security Best Practices

• Out-of-band Management (OOB) is provided on nearly all Scale Computing hardware platforms in some form. This mechanism provides a wealth of tools to remotely interface with a node as if the user were locally connected. Keyboard-video-mouse, virtual media, serial-over-LAN, and remote graphical consoles are among the tools most OOB implementations provide. These powerful tools can facilitate local-equivalent access and, as such, should be guarded against unauthorized use.

  OOB goes by many trade names:

  • Intel AMT (vPro)
  • Supermicro IPMI
  • Dell iDRAC
  • HPE iLO
  • Lenovo XCC

  The specifics, interfaces, and even feature sets may differ between the various implementations, but the core principles of security are consistent, regardless of which OOB implementation your node provides.

  OOB Best Practices:

  • Change default login credentials
  • Isolate the OOB to its own network
  • Remove unused user accounts
  • Maintain up-to-date firmware
• BIOS / UEFI security refers to the protection of a computer system's firmware layer that controls the initial boot process, ensuring that the OS is loaded securely and without unauthorized tampering. BIOS (Basic Input/Output System) and UEFI (Unified Extensible Firmware Interface) are responsible for initializing hardware components and loading the OS when a node is powered on. There are three fundamental practices and one optional action all Scale Computing customers should follow and track to ensure the integrity of BIOS/UEFI security:
  • Change the default administrator password to a strong, unique password to restrict access to BIOS/UEFI settings, ensuring that only authorized users can make changes.
  • Regularly check for and apply firmware updates from verifiable, trusted sources to ensure your system has the latest security patches and improvements.
  • Periodically confirm settings such as the system date, time, enabled bootable devices, and boot entries reflect the intended scenario. The factory configuration of an SC//HyperCore node will reflect this default state. Upon each SC//HyperCore version upgrade, these values are checked again for accuracy. Vigilance is always recommended to guard against potential local malicious (or mistaken) actors.
  • If a suspected or actual incident leaves you unsure regarding the state or authenticity of the settings, a hard “CMOS reset” is encouraged to return the hardware to its factory state. This action will not impact your existing data on the node. Scale Computing Support is ready to assist with this action should instructions be needed.
• Create an external port access security policy. External ports like USB, Ethernet, or other peripheral devices are often used in the general course of business to connect devices and perform data transfers, but they can also serve as entry points for cyberattacks, data theft, or system tampering if not properly secured. There are several approaches to securing external ports and mitigating them from being exploited as a potential attack vector by malicious actors:
  • SC//HyperCore’s CLI access limits what an actor can do locally when it comes to external ports. Additionally, the HyperCore™ OS does not mount newly introduced storage media and does not automatically incorporate communications devices that are not predefined in the hardware manifest. That said, role-based access control via user creation and curation, as well as physical access control and policies for interacting with the cluster hardware, are recommended.
  • Block unused ports such as USB or Thunderbolt when not in use to dissuade casual users from interacting with them.
  • A committed malicious actor with local access to a hardware platform may devise clever workarounds for any policies, access controls, and deterrence employed. Tamper evidence is an approach to ensure you are alerted if unauthorized tampering has occurred. One-time use, self-destructive labels (such as ‘Warranty Void if Removed’ labels) are low cost and increase the level of effort an actor would need to apply to complete a malicious act undetected. Further, it provides evidence that you should treat the affected device with additional scrutiny until an investigation is completed.
• Use only official, qualified components with transparent supply chains. Threat actors have become extremely sophisticated in their approach to supply chain interdiction and data exfiltration. For example, peripherals that appear and operate like standard USB cables can be openly purchased on the gray/black markets, which contain entire computing platforms, complete with multiple cores, memory, persistent storage, and network capabilities that are invisible to a casual observer. To guard against mistakenly introducing such vulnerabilities into your infrastructure, the following standard protocols should be adhered to:
  • Always contact Scale Computing for replacement or add-on components while your equipment is under an active support contract. This ensures you receive fully vetted components and peripherals backed by the manufacturer and Scale Computing Support.
  • When procuring components outside of that scope, choose reputable brands with published supply chain security statements and procedures in place.
  • Always procure components from an authorized distributor or vendor. Making the odd purchase from an online vendor like Amazon, for example, can be convenient and cost-saving; however, the provenance of the materials you purchase is unknown and should be treated with additional scrutiny.
  • Network switches are capable computing platforms that, by their intended use, communicate with a potentially broad spectrum of your infrastructure. The protocols listed above should be given additional consideration when procuring switching equipment.

Data Encryption Best Practices

Customers should consider the encryption of their data at three distinct but equally important levels:

• Data encryption at rest refers to the process of encoding data stored on a physical medium, such as hard drives, databases, or cloud storage, to protect it from unauthorized access. Scale Computing does not currently offer native functionality to encrypt data at rest on customer hardware. Scale Computing strongly encourages customers to leverage third-party disk encryption software such as Bitlocker Drive Encryption (for Windows systems) to ensure data integrity and confidentiality.
• Data encryption in transit refers to data actively moving from one location to another, whether across the internet, through internal networks, or between devices. Data in transit is more vulnerable to intercept by malicious actors, and customers should take the following actions to ensure data integrity is maintained when moving from one network location to another:
  • Ensure data transfers are executed using secure protocols such as HTTPS with Transport Layer Security (TLS) 1.2 or 1.3.
  • Maintain the integrity of your backplane VLAN to segment network traffic, and isolate sensitive data and critical applications from unauthorized access and potential threats. Creating distinct VLANs to control traffic flow, enhance overall network security, and ensure that only authorized devices and users can access specific network resources.
  • Physically protect network devices.
• Data encryption in use refers to data that is actively being processed by applications, computers, or systems. Due to the data being actively accessed it is unencrypted and therefore vulnerable to potential access. Best practices for securing data being actively accessed include:
  • Securing the environment in which the data is being accessed. This includes physically securing resources with password protections and advanced access control features.
  • Isolating sensitive workloads to a single system or device while actively being worked on (i.e., not connected to a network database).