Category Archive: Security
NVIDIA Issues Warning for Updating Windows 10 for GeForce, NVS, Quadro And Tesla Drivers
NVIDIA has released a software security update for the NVIDIA GPU Display Driver. This update addresses issues that may lead to local code execution, denial of service, or escalation of privileges. For access to NVIDIA driver updates and more information, click here.
We want to ensure our customers are always aware of the vital improvements and features from our trusted partners. Be sure to follow Dedicated Computing on LinkedIn and Twitter for all the latest updates.
By Bill Gray, Senior Systems Engineer, Dedicated Computing
You want to keep your embedded system secure, so you decide to install a virus scanner. However, the device does not have an internet connection, and you can’t afford to send a service person to update the virus definitions as often as is needed, so is it really worth it? There are three approaches to safeguarding your device; understanding which practice best fits your system will lower costs and ensure your device is secure.
Blacklisting
Typical virus scanners use a blacklisting technology where a list of code signatures is kept — and when any code includes those signatures the application is quarantined. Utilizing a blacklisting approach on embedded systems has a number of downsides, including the frequency of updates for true protection, or performance impacts to the quarantined system can be significant.
Whitelisting
Whitelisting, on the other hand, needs no virus definition updates, has no impact on performance, and only allows what has been defined as “good” to be executed, with no other applications being impacted. An operator using an embedded system will not be allowed to run any rogue code and will not be allowed to infect the embedded system.
Anti-virus products work by creating a list of programs and code signatures that are known to contain rogue software and then search an operating system, including its file system and memory space. The anti-virus engine can often identify and compartmentalize software just after having been executed, in (somewhat) real-time. Anti-virus databases must be updated often to address the most recent malware and exploits. Zero-day vulnerabilities software that has yet to be fixed or otherwise identified as susceptible by the community at large, are impervious to anti-virus products.
Whitelisting is a technology opposite to the implementation of anti-virus scanning techniques. Instead of locating and removing known vulnerabilities, the whitelisting approach simply refuses to load and execute any file not already allowed. This is accomplished by creating within a secure environment, a list of files (executable or otherwise) and their respective cryptographic checksums. A whitelisting kernel driver or shim is loaded during boot and is responsible for intercepting all filesystem reads/writes. For a file to be successfully loaded, it must first pass all security restrictions implemented by the whitelisting product. The result is a secure system that has no performance impacts, needs no virus definition updates, and can protect against zero-day attacks. Blacklisting is a perfect fit for general purpose computing. Purpose-specific computing, on the other hand, must operate without IT oversight, and do so within very specific operating requirements — making whitelisting a highly effective security solution for an embedded system.
Deep Freeze
Another approach to protecting the state of a deployed system is accomplished through a product called Deep Freeze. Deep Freeze is a proprietary software product developed by Faronics, available for Microsoft Windows and macOS operating systems. The software protects the operating system (at the hard drive level) by implementing a mechanism similar to Copy-on-Write. In this environment, the user is not allowed to modify the hard drive contents (OS or data, per configuration directives) and all changes are redirected to an overlay filesystem, most likely residing in main memory. On reboot, all changes are lost, and the operating system reverts back to the original state. Changes can be accomplished by first removing the protection mechanism (a process called “thawing”), making the necessary OS changes and then applying the lock (“freeze”).
Deep Freeze does not protect the system from running malicious software after a reboot. This protection scheme does not protect a user from using alternative bootable media (e.g. USB flash drive) which would allow modifications to the “frozen” operating system drive contents.
By Wade Brown, Senior Research and Design Engineer, Dedicated Computing
Secure boot is a component of the UEFI firmware package and does not exist in legacy BIOS implementations. The intended use of this component is to protect against boot kits (as opposed to root kits, which target the OS). The general boot path is: computer starts, UEFI loads, seeks first bootable device and loads it’s boot sector. Depending on the architecture, the boot sector points to software (i.e. first stage boot loader) that will eventually load and execute. On a non-secure boot enabled system, the software is loaded and executed without verification.
UEFI provides non-volatile, private storage space that can be used to store public key infrastructure (PKI) based certificates. With secure boot enabled, the UEFI firmware will verify the boot loader has been digitally signed, has not been modified and the signature matches one of the certificates stored in NVRAM. If the boot loader fails verification, it will not be loaded and executed, and the boot process stops.
A boot loader implementing the Trusted Boot methodology, only concerns itself with the verification of the next software component. For example, in Windows and Linux operating systems, this next component is often called the “kernel.” The kernel, in turn, can use Trusted Boot to verify every driver and other software components. In this manner, an anti-virus engine can be loaded before any other 3rd party driver/software. Trusted Boot normally uses a hardware component called a Trusted Platform Module (TPM), which is a small microprocessor dedicated to cryptographic functions, including integrated PKI keys.
By Wade Brown, Senior Research and Design Engineer at Dedicated Computing
Hardware based encrypting storage drives utilize cryptographic logic directly on the controller chip. Any hard drive using this technology is constantly encrypting and decrypting data, regardless of whether the drive has been locked. Unlike software-based encrypting techniques, hardware crypto engines are faster and transparent to the end user.
Self-encrypting drives (SEDs) are locked by providing a password, which is used to encrypt the hard drive’s internal private key. After the hard drive has been reset or power cycled, the password must be provided to decrypt the private key. If the correct password has been provided, the hard drive media can be accessed normally. Otherwise, all data including master boot records are inaccessible.
There are three typical methods of unlocking a SED. The first method, if supported by the motherboard BIOS, makes use of the ATA Security feature. On boot, a BIOS can ask the user to provide a password to “unlock” the drive. A SED can use this feature to decrypt the private key. However, each hard drive implementing the ATA Security feature must be unlocked, as well.
The second method uses the SED concept, called “MBR Shadowing”. This method involves the use of a small, embedded operating system stored on the SED. On boot, a fake MBR is presented to the BIOS which will then load the embedded OS. The embedded OS is designed to either ask the user for the password or to contact a central hub (e.g. software-based an IT security server) for credentials. On successful authentication, the embedded OS reboots and when the BIOS scans the drive again, the “real” MBR is presented. The embedded OS can unlock other SEDs in the same system.
Finally, the last method does not lock the entire drive or does not specifically lock the boot drives. In this case, the booting operating system is responsible for unlocking other drives (i.e. data drives) in the system. This method is ideal if the operating system drives are located internally while the data drives are accessible from the front of the chassis (e.g. removable drives). Theft of a data drive will be useless as when the drive loses power, it must be unlocked again.
Data on SEDs can be easily destroyed by simply asking the drive to generate a new private key. As previously stated, a SED constantly encrypts/decrypts data using the private key and when this key is regenerated, all previously stored data is immediately lost.
The encryption and locked functionality follows the OPAL 1.x or 2.x Trusted Computing Group (TCG) specifications. This specification defines the protocol for encryption devices and also defines the capability to lock specific LBA ranges on the storage media. Thus, it is possible to encrypt an entire hard drive or only specific block ranges. The OPAL specification also defines two user roles (admin, user), each with individual passwords. The OPAL specification is generally directed toward consumer grade storage devices (SATA, NVMe) while another specification, named “EnterpriseHardware-based targets enterprise grade storage devices (SAS).
In an era where unprecedented data breaches are affecting corporate and government entities, the devices used in hospitals and other medical settings represent an often overlooked, yet vital source of vulnerability. For years, security researchers have cautioned the healthcare industry about their exposed medical devices.
Too often these devices are internet-capable or networked internally without encryption technology, cloud computing safeguards, or even password protection. This makes them an easy target for hackers who have the ability to steal data, disable medical devices responsible for providing life-saving care, or launch a widespread cyber attack that can affect every device on a particular network.
The Food and Drug Administration issued new guidelines in 2014 covering medical devices in the market. These guidelines stated that all such devices should be secure, be able to easily update to correct any flaws, and have safeguards in place to protect care in the event the device is hacked or otherwise compromised. The guidelines also mandated that, ideally, medical devices should include the ability to be updated and be accompanied by a list of software components that would allow hospitals to check the device for any vulnerabilities.
A Constant Threat
Infusion pumps make up almost half of all medical devices, according to the Zingbox 2018 Threat Report, making them the largest potential source of attack for cyber-related threats. Currently the industry standard is to segment these types of devices, which limits any potential cyber intrusions to an individual device. Yet, this practice also makes it more difficult to provide widespread automatic security updates to such devices.
The individual operators and medical personnel themselves leave another unyielding source of vulnerability. The above study discovered that the most common security risks originated from user practice issues, which included using web browsers on medical workstations for personal online browsing, chatting, and downloading content.
The Way Forward
The FDA offers a series of recommendations to prevent and otherwise fortify medical devices against the life threatening and/or privacy violating compromises that can result from a targeted attack. These include preemptive mitigation of cybersecurity risks early before they can be taken advantage of by hackers, as well as adopting a coordinated vulnerability disclosure policy and practice. They also encourage healthcare providers to put policies and procedures in place that will enable them to understand and evaluate risks, and discover any vulnerabilities in equipment or software.
According to the guidelines, healthcare providers must also have a plan in place to not only mitigate threats, but to respond and recover quickly and efficiently to limit patient risk. IT personnel in healthcare must be empowered to locate and neutralize cybersecurity threats, which means they must have established procedures in place for discovery and elimination of vulnerabilities.
Finally, it is always incumbent upon those managing healthcare IT systems to apply the five core principles put forth in the 2014 NIST voluntary Framework for Improving Critical Infrastructure Cybersecurity:
- Identify
- Protect
- Detect
- Respond
- Recover
Cybersecurity for IoT and Beyond
The burden on the industry to protect medical devices is great. Those who produce and utilize medical devices need IoT development partners who will work with them through the life of their devices, rather than supplying a basic framework before abandoning them to configure and manage the updates and security threats or breaches that occur on their own.
Contact Dedicated Computing today to learn more about the cloud computing solutions that will keep your systems current and free of vulnerabilities to threats.
