A Security Barrier Device That Can Protect Critical Data Regardless of OS or Applications by Just Installing It. by Keiji Toda
2 likes1,384 views
The document discusses the development of a Security Barrier Device (SBD) designed to protect critical data regardless of the operating system and applications. It provides mechanisms for sector-based and file-based access control, as well as malware prevention features. Future work includes enhancements for various file systems and improvements in performance and robustness.
![SBD: File Based Access Control
Disk-Relating OS Caches
[Problems] Linux (also Windows) utilizes following
caches for performance:
• Superblock (block group descriptor, bitmaps of free
block and free i-node, …)
• i-node cache
• Directory entry cache
• Buffer cache (for disk block data)
• Page cache (for file data)
Write inhibition on the disk causes
inconsistency between OS caches and the disk!18](https://image.slidesharecdn.com/kenjitodaenpub-140312044025-phpapp01/85/A-Security-Barrier-Device-That-Can-Protect-Critical-Data-Regardless-of-OS-or-Applications-by-Just-Installing-It-by-Keiji-Toda-18-320.jpg)
A Security Barrier Device That Can Protect Critical Data Regardless of OS or Applications by Just Installing It. by Keiji Toda
- 1. Security Barrier Device Protects Critical Data Regardless of OS and Applications by Just Attached Kenji TODA, Ichiro EBIHARA, Koji SEGAWA, Koichi TAKAHASHI and Kazukuni KOBARA The National Institute of Advanced Industrial Science and Technology (AIST) in cooperation with Control System Security Center (CSSC)
- 2. Contents • Background • Concept of SBD • Data Protection Mechanism • Hardware and Security Tag • Sector Based Access Control • File Based Access Control • Malware Prevention • Demonstration Video • Future Work Currently NTFS is implemented. EXT and FAT are under development. Applicable for other file systems. 2
- 3. Background: PC and/or Server • Hard to fix all the vulnerabilities of complex OS and applications. • There exists undefended period called zero-day exposing unknown or discovered-but-not-yet- fixed vulnerabilities. #Identified Vulnerabilities in a year (http://www.symantec.com/ja/jp/threatreport/topic.jsp?id=vulnerability_trends&aid= total_number_of_vulnerabilities)3
- 4. Background: Control System • Additional security software is not affordable for restricted hardware resources and / or realtime systems • Outdated OS and applications might be used without any security patch. We develop SBD, the hardware solution of easy attachable regardless of any OS and applications without software installation. 4
- 5. SBD – Easy Attaching Target System Just insert SBD between IO Ports on the original hardware. Protecting important data regardless of OS and applications.5
- 6. SBD: Data Protection Mechanism ①The target system issues an IO request to the original HDD. ②SBD reads the security information of corresponding IO blocks. ③Data access is handled according to the information (permitted / inhibited / queried) . ① ② Added HDD: Security Information ←Invisible from the System! Original HDD: Data RW=10 ③ Read〇 Write× 6
- 7. ＳＢＤ: Full View Security Barrier Device FPGA board developed for SBD 7
- 8. Security Barrier Device (SBD): Board and Specifications • Board size: PCI Express card (230mm x 110mm) • FPGA chip： Xilinx Kintex-7 676pin XC7K325T • Configuration Flush Rom: for power-on-write to FPGA • Memory I/F: DDR3 SODIMM×1 • Display input: HDMI×1 • Display output: HDMI×1 • Optical audio: input×1, output×１ • Storage I/F： SATA (7pin)×5 • Ethernet I/F： 1G/100Mbit Ether (RJ-45) ×2 • USB I/F： USB (Type A)×6 (USB2.0) • SBD host PC I/F： PCI Express×18
- 9. SBD Board Connections SBD Control PC SBD Board Target Control Device USB0 Ethernet (LAN) HDMI SATA0 PCIe (card slot) SATA1 USB1 SATA0 SATA1 USB0 USB1 HDMI Ethernet (LAN) Peripherals of Target Control Device 9
- 10. Security Barrier Device (SBD): Security Tags (sector based control) Security Barrier Device (SBD) Additional Storage for SBD Security Target Control Device User Login to SBD SBD PASSWORD FILE USER NAME PASSWORD (root) UID 0 GID SBD Control PC (Linux kernel 2.6 or above) SBD Board OWNER GROUP OTHER RqraWqra RqraWqra RqraWqraRqraWqra UID GID Original Storage of Target Control Device SBD SECURITY TAGs for corresponding BLOCK BLOCK Original Data in Target Storage USER NAME PASSWORD UID 1 GID Storage Access Storage Access Additional Storage Access Loop Back ... LoopBack / AccessControl: {Query - assert / negate}, {Recording - all / no}, {Alert - no} SBD SECURITY MODE for storage access (R: read, W: write, q: query, r: record, a: alert) USB USB HDMI SATA PCIe UID SBD DEFAULT UID & GID Ethernet Loop Back GID • SATA Port Handling Logic is implemented. • Ethernet can be cut-off. 10
- 11. Security Barrier Device (SBD): Sector Based Access Control The target of storage access control is block devices such as HDD / SSD / USB memory. Since storage access is performed sector based (512Byte unit), implementation of sector based access control is straightforward. • Defense of disk regions and partitions is OK! • Gathering to-be-write-protected data and system files to write-protected partitions. • Gathering to-be-read-protected data to read-protected partitions.11
- 12. SBD: File Based Access Control Motivation File based access control extends defense coverage and improves convenience dramatically: • Critical system and user data is mostly files. • No need to gather important files to protected partitions • Original data disk can be protected as is. • Easy assigning and releasing of protection on files. • No stress on attaching and detaching of SBD (just plug in/out IO connectors). 12
- 13. SBD: File Based Access Control Requirements Commonly-used file systems: • NTFS (Windows, …） • EXT(Linux, Android, …） • FAT(old Windows, MS-DOS, VxWorks, USB memory,..） • HFS+(Mac OS X,…) Requirements to handle the above file systems: • On access control of data blocks, →〇 sector based control is appropriate; →〇 read access control is appropriate; →×write access control is NOT appropriate because pointers to the data blocks may change their locations. In non-resident data file and parent directories 13
- 14. SBD: File Based Access Control Fine Grain Control Protection is required on data of file and path from the root. Access granularity for directories and pointer areas ≦ sector size (512B) 1. Put access control granularity to the security information corresponding to a sector. 2. In case of write to a sector, in addition to the security information, the content of the sector is also read. Then the write protected portion of the read data is used instead of the sector data intended to write. Consequently, fine grain control is achieved.14
- 15. Security Barrier Device (SBD): File Read Protection (no difficulty) In case SBD returns zeroes for read protected data: An error message on opening protected data on a target system (Ubuntu) → 15
- 16. SBD: Requirement for Write Protection -- EXT2（Linux） • /appdata/app_critical is a write protected file. Path from the root directory needs protection.16
- 17. SBD: File Based Access Control Remaining Difficulties Problems of write protection on NTFS file: ① Inconsistency between disk-relating caches on the memory of a defense target system and the disk may destroy file system and cause OS crash. ② The locations of pointer entries relating the write protected file in its parent directories may change by addition or deletion of other non- protected files. Because, the location is rearranged by balanced tree algorithm in NFTS. (←SBD achieves high performance by means of FPGA circuit assuming fixed location.) 17
- 18. SBD: File Based Access Control Disk-Relating OS Caches [Problems] Linux (also Windows) utilizes following caches for performance: • Superblock (block group descriptor, bitmaps of free block and free i-node, …) • i-node cache • Directory entry cache • Buffer cache (for disk block data) • Page cache (for file data) Write inhibition on the disk causes inconsistency between OS caches and the disk!18
- 19. SBD: File Based Access Control Solution Problems of write protection on NTFS file: ① Inconsistency between disk-relating caches on the memory of a defense target system and a data disk may destroy file system and cause OS crash. ② The locations of pointer entries relating the write protected file in its parent directories may change by addition or deletion of other non- protected files. Because, the location is rearranged by balanced tree algorithm in NFTS. (←SBD achieves high performance by means of FPGA circuit assuming fixed location.) By observing OS behavior using SBD →SBD makes the OS handle an accessed write- protected file entry as a (pseudo) bad block by returning a disk access error to the OS! →The pointer location to its patent directory is never changed as long as its directory pass is not changed!19
- 20. SBD: File Based Access Control Write Protection Procedure Write protection on NFTS file: ① In case of write, if rename or deletion is performed to the write protected file, the operation is done on caches and appears successful. ② In a short period, the contents of the caches are written to the disk, then SBD detects it. ③ SBD returns a device error on the file access and issues an alert to a user. OS handles the file entry as it is in a (pseudo) bad block. (An Ethernet port can be shut-off by the alert as a trigger.) ① When a user reboots the OS, SBD restores the write protected files in prior to OS booting. Hence, the OS can be booted as it was. SBD makes write protection consistent with the OS! The pseudo bad blocks are restored from $BadClus file.24
- 21. SBD: File Based Access Control Mechanism Security Barrier Device (SBD) Additional Storage for SBD Security Target Control Device User Login to SBD SBD PASSWORD FILE USER NAME PASSWORD (root) UID 0 GID SBD Control PC (Linux kernel 2.6 or above) SBD Board OWNER GROUP OTHER RqraWqra RqraWqra RqraWqraRqraWqra UID GID Original Storage of Target Control Device SBD SECURITY TAGs for corresponding BLOCK BLOCK Original Data in Target Storage USER NAME PASSWORD UID 1 GID Storage Access Storage Access Additional Storage Access Loop Back ... LoopBack / AccessControl: {Query - assert / negate}, {Recording - all / no}, {Alert - no} SBD SECURITY MODE for storage access (R: read, W: write, q: query, r: record, a: alert) USB USB HDMI SATA PCIe UID SBD DEFAULT UID & GID Ethernet Loop Back GID Detecting information is prepared in prior to detection. File system Dependent Detection is performed in fine grain, byte unit, by FPGA. File system Independent 25
- 22. ＳＢＤ： Performance of Access Control In case of fine grain, byte unit, detection (at high overhead sate) = File based access control (read / write) is enabled: Experimentally 100MByte/s Measuring Condition： A original data disk and a security information disk: Samsung SSD 830, 128GB Benchmark Program: Read-Only Benchmark, Ubuntu Disk Utility Sector-wide comparator with byte unit mask circuit + Multi-sector IO buffer circuit 26
- 23. Security Barrier Device (SBD): Malware Prevention Protection by SBD： • Bootkit • Rootkit 27
- 24. 28 Bootkit: Definition and Win32/Gapz • The most dangerous infectious form bootkit launches before Windows and hides in between hardware and OS. Hence, it becomes undetectable and accesses system resources unlimitedly. 。 (technet.microsoft.com) • Win32/Gapz: Advanced Evasion Techniques VBR infection type replaces only a few bytes in BIOS Parameter Block. Hence, it is hard to detect. (Evolved form of MBR infection type） (blog.eset-smart-security.jp)
- 25. 29 Bootkit Win32/Gapz MBR Infection type • Fig shows the infection sequence of MBR infection type （Traditional Techniques） ① Bootkit code is loaded from disk, Int 13h disk handler is hooked. ② ntldr, bootmgr, winload.exe and loInitSystem are hooked in series, kernel mode code (rootkit) is launched.
- 26. 30 Bootkit Win32/Gapz VBR Infection type • VBR Infection Type disk image (Advanced techs) ① Hidden Sectors (4B) at BIOS Parameter Block in Volume Boot Record is modified. ② Bootkit is launched instead of IPL by mean of skipping whole NTFS volume in front of bootkit
- 27. 31 Bootkit: ELAM • ELAM（Early Launch Anti-Malware Module）, introduced in Windows 8, does not work. (blog.eset-smart-security.jp)
- 28. 32 Bootkit Win32/Gapz • VBR Infection Type disk image (Advanced techs) ① Hidden Sectors (4B) at BIOS Parameter Block in Volume Boot Record is modified. ② Bootkit is launched instead of IPL by mean of skipping whole NTFS volume before bootkit ③ The rest is the same as MBR Infection type. SBD protectable!
- 29. 34 Bootkit: Secure Boot • On the secure boot, UEFI (Unified Extensible Firmware Interface) verifies boot loader in advance of its loading. In case the boot loader is modified or replaced (by bootkit), the secure boot prevents its execution. (technet.microsoft.com, blogs.msdn.com) The boot loader code itself is not protected! The boot loader is stored in a file for verification!
- 30. 35 Bootkit: Secure Boot • On the secure boot, UEFI (Unified Extensible Firmware Interface) verifies boot loader in advance of its loading. In case the boot loader is modified or replaced (by bootkit), the secure boot prevents its execution. (technet.microsoft.com, blogs.msdn.com) The boot loader code itself is not protected! The boot loader is stored in a file for verification! SBD protectable!
- 31. 36 Rootkit: Definition and Sample • Generic name of tool which invades and modifies computer system with root (system manager) privilege (ASCII.jp) • Typical rootkit hides Logon, Process, File and Log. It often monitors input from network and/or keyboard. In many cases, rootkit is also Trojan Horse. (Wikipedia) • SONY BMG CD XCP case: It is audio player software with Copy Guard function, on the side, access control (permitting outgoing transmission and system invasion) using rootkit is installed. It transmits data on computer and also prevents other media player software from playing a music CD and/or copying to disk. Its vulnerability was found and abused by malware. （→Currently, Windows update has fixed it.） (Wikipedia) System files are modified!
- 32. 37 Rootkit: Definition and Sample • Generic name of tool which invades and modifies computer system with root (system manager) privilege (ASCII.jp) • Typical rootkit hides Logon, Process, File and Log. It often monitors input from network and/or keyboard. In many cases, rootkit is also Trojan Horse. (Wikipedia) • SONY BMG CD XCP case: It is audio player software with Copy Guard function, on the side, access control (permitting outgoing transmission and system invasion) using rootkit is installed. It transmits data on computer and also prevents other media player software from playing a music CD and/or copying to disk. Its vulnerability was found and abused by malware. （→Currently, Windows update has fixed it.） (Wikipedia) System files are modified!SBD protectable!
- 33. SBD prevents write on boot area and shut-off Ethernet, and stops Remote Control. Attacker Victim Network is shut-off. Defense by SBD 38
- 34. Future Work • Feasibility study and its feedback to SBD at Control System Security Center (CSSC) • Linux EXT families and widely-used FAT families are under development. (Applicable for other file systems also.) • Improvements on performance and robustness • Tests using various malware • Extension of SBD defense ability by developing Ethernet, USB and HDMI port-supervisory circuit. • Downsizing (such as a SBD storage) 39
- 35. FIN 40