DOCSLIB.ORG

CERIAS Tech Report 2017-5 Deceptive Memory Systems by Christopher N

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
CERIAS Tech Report 2017-5 Deceptive Memory Systems by Christopher N CERIAS Tech Report 2017-5 Deceptive Memory Systems by Christopher N. Gutierrez Center for Education and Research Information Assurance and Security Purdue University, West Lafayette, IN 47907-2086 DECEPTIVE MEMORY SYSTEMS ADissertation Submitted to the Faculty of Purdue University by Christopher N. Gutierrez In Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy December 2017 Purdue University West Lafayette, Indiana ii THE PURDUE UNIVERSITY GRADUATE SCHOOL STATEMENT OF DISSERTATION APPROVAL Dr. Eugene H. Spa↵ord, Co-Chair Department of Computer Science Dr. Saurabh Bagchi, Co-Chair Department of Computer Science Dr. Dongyan Xu Department of Computer Science Dr. Mathias Payer Department of Computer Science Approved by: Dr. Voicu Popescu by Dr. William J. Gorman Head of the Graduate Program iii This work is dedicated to my wife, Gina. Thank you for all of your love and support. The moon awaits us. iv ACKNOWLEDGMENTS Iwould liketothank ProfessorsEugeneSpa↵ord and SaurabhBagchi for their guidance, support, and advice throughout my time at Purdue. Both have been instru­ mental in my development as a computer scientist, and I am forever grateful. I would also like to thank the Center for Education and Research in Information Assurance and Security (CERIAS) for fostering a multidisciplinary security culture in which I had the privilege to be part of. Special thanks to Adam Hammer and Ronald Cas­ tongia for their technical support and Thomas Yurek for his programming assistance for the experimental evaluation. I am grateful for the valuable feedback provided by the members of my thesis committee, Professor Dongyen Xu, and Professor Math­ ias Payer. I am thankful for the financial support provided by the National Science Foundation, under award number 1548114. Personal thanks to my Mom, Dad, and Grandma for instilling me the value of hard work and supporting my passion for computing at an early age. Thank you for allowing me to forgo a year of birthday and Christmas gifts for my first computer. A heartfelt thank you to my wife, Gina, for her unwavering support throughout my time as a graduate student. Thanks to Je↵ Avery, Paul Wood, Mohammed Almeshekah, Oyindamola Oluwatimi, and Abram Magner for their valuable feedback and support. Thank you to all of my colleagues in the Dependable Computing Systems Laboratory for their comments on the preliminary results. To all of my friends and family who have shown me nothing but love, I thank you. Finally, huge thanks to my cat Buntu for making me laugh and smile every day. v TABLE OF CONTENTS Page LIST OF TABLES ................................ viii LIST OF FIGURES ............................... ix ABSTRACT ................................... xi 1 INTRODUCTION .............................. 1 1.1 Thesis Statement ............................ 3 1.2 DecMS Goals .............................. 4 1.2.1 Preserve ............................. 4 1.2.2 Impede .............................. 5 1.2.3 Reduce .............................. 5 1.2.4 Identify ............................. 6 1.3 Contributions .............................. 6 2 BACKGROUND AND RELATED WORK ................. 8 2.1 Digital Assets to Protect ........................ 9 2.2 Threat Space .............................. 11 2.3 Data Destruction Methods ....................... 13 2.3.1 Delete .............................. 13 2.3.2 Secure Delete .......................... 14 2.3.3 Data Replacement ....................... 16 2.3.4 Transformation ......................... 17 2.4 Data Destruction in Anti-Forensics .................. 17 2.5 Defending Against Unauthorized Data Destruction ......... 18 2.5.1 Access Control ......................... 18 2.5.2 Data Preservation Strategies .................. 20 2.5.3 Data Recovery and Repair ................... 25 2.5.4 Unauthorized Destruction Detection Strategies ........ 28 2.5.5 Combining Detection and Preservation ............ 30 2.6 Deception for Defense .......................... 32 2.7 Other Related Work .......................... 38 3 THREATS AND DECEPTION ....................... 42 3.1 Threat Model and Assumptions .................... 43 3.1.1 Wiper Malware Threats on Integrity ............. 45 3.1.2 Anti-Forensics Threats to Availability and Utility ...... 46 3.1.3 Anti-Forensics Threats to Authenticity ............ 47 vi Page 3.1.4 Crypto Ransomware Threats to Authenticity ......... 49 3.1.5 Benign User ........................... 50 3.1.6 Assumptions ........................... 50 3.2 Planning Deception ........................... 51 3.2.1 Strategic Goal .......................... 51 3.2.2 Adversary Reaction ....................... 52 3.2.3 Attacker Bias .......................... 52 3.2.4 Deceptive Components ..................... 53 3.2.5 Feedback Channels and Monitoring .............. 58 3.2.6 Risks and Countermeasures .................. 59 3.3 Cost of Deception ............................ 60 3.3.1 Types of Systems ........................ 63 3.3.2 Cost Impact of Deception on Systems ............. 65 4 ARCHITECTURE AND DESIGN SPACE ................. 70 4.1 DecMS Integration Location ...................... 70 4.1.1 User-Level ............................ 72 4.1.2 Kernel-Level ........................... 74 4.1.3 Hardware-Level ......................... 76 4.1.4 VM-Level ............................ 78 4.1.5 Networking-Level ........................ 80 4.1.6 Summary ............................ 81 4.2 DecMS Integration Methods ...................... 83 4.2.1 Modification ........................... 85 4.2.2 Introspection .......................... 86 4.2.3 Interposition ........................... 87 4.2.4 Wrapper ............................. 88 4.3 Monitoring Methods and Policy .................... 89 4.3.1 Deception and Adversary Co-location ............. 90 4.3.2 Co-location with Protection .................. 90 4.3.3 Deception in External Layers ................. 91 4.3.4 Identification Methods ..................... 91 4.3.5 Policies and Components of DecMS .............. 91 4.4 Protection Methods and Policies .................... 93 4.4.1 Deception Policy ........................ 93 4.4.2 Preservation Policy ....................... 94 4.4.3 Other Protection Policies .................... 94 4.5 Summary of Integration Location ................... 94 5 PROOF OF CONCEPT DESIGN ...................... 96 5.1 Desired Traits .............................. 96 5.1.1 Identification .......................... 96 5.1.2 Impedance ............................ 97 vii Page 5.1.3 Preservation ........................... 97 5.1.4 Reduce .............................. 98 5.2 Threat Instances ............................ 98 5.2.1 Ransomware ........................... 98 5.2.2 Wiper Malware ......................... 99 5.2.3 Anti-forensics .......................... 100 5.3 Randomness Classifier ......................... 102 5.3.1 Parameter Settings for Randomness Classifier ........ 105 5.3.2 Randomness Tests ....................... 105 5.3.3 Classification Training and Validation ............. 106 5.4 Other Destructive Patterns ....................... 107 5.5 Design Overview for DecMS-Kernel .................. 109 5.6 Design Overview for DecMS-VMI ................... 112 5.6.1 Assumptions ........................... 114 5.6.2 Requirements .......................... 115 6 EVALUATION ................................ 116 6.1 Kernel-Based Evaluation ........................ 116 6.1.1 Observation Policy and Service ................ 116 6.1.2 Analysis Policy and Service .................. 117 6.1.3 Preservation Policy and Service ................ 118 6.1.4 Deception Policy and Service ................. 119 6.1.5 Service Location ........................ 119 6.1.6 Metrics of Interest ....................... 119 6.1.7 Experimental Results ...................... 121 6.1.8 Discussion ............................ 125 6.2 VMI-based Evaluation ......................... 127 6.2.1 Observation Policy and Service ................ 129 6.2.2 Analysis Policy and Service .................. 132 6.2.3 Preservation Policy and Service ................ 134 6.2.4 Experimental Results ...................... 136 7 CONCLUSION ................................ 150 7.1 Summary ................................ 150 7.2 Shortcomings, Enhancements, and Future Work ........... 151 7.2.1 Counterdeception ........................ 152 7.2.2 Alternative Analysis Policy .................. 156 7.2.3 Other Limitations ........................ 158 7.3 Conclusion ................................ 160 LIST OF REFERENCES ............................ 161 A ADDITIONAL PERFORMANCE RESULTS ................ 171 VITA ....................................... 176 viii LIST OF TABLES Table Page 4.1 Summary of possible layers to monitor and preserve data under destruc­ tion. ..................................... 82 4.2 Methods to support the goals of a DecMS ................ 84 5.1 Wiper Malware samples for evaluation .................. 99 5.2 A list of secure delete methods considered in the evaluation of DecMS- VMI. .................................... 101 A.1 DecMS-VMI latency for 32 MiB files. ................... 174 A.2 DecMS-VMI latency for 4 KiB files. .................... 175 ix LIST OF FIGURES Figure Page 3.1 Threats and loss of Parkerian security elements for various data destruc­ tion attacks. ................................. 44 3.2 The costs of using deception on various systems. ............. 66 4.1 Possible layers of abstraction and monitoring methods for deception, based on [81, Chapters 5, 7]. ..........................
Load more

Recommended publications
  • Oracle's Zero Data Loss Recovery Appliance
    GmbH Enterprise Servers, Storage and Business Continuity White Paper Oracle’s Zero Data Loss Recovery Appliance – and Comparison with EMC Data Domain Josh Krischer December 2015 _____________________________________________________________________________ 2015 © Josh Krischer & Associates GmbH. All rights reserved. Reproduction of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Josh Krischer & Associates GmbH disclaims all warranties as to the accuracy, completeness or adequacy of such information. Josh Krischer & Associates GmbH shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The reader assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed herein are subject to change without notice. All product names used and mentioned d herein are the trademarks of their respective owners. GmbH Enterprise Servers, Storage and Business Continuity Contents Executive Summary ...................................................................................................................... 3 Oracle’s Zero Data Loss Recovery Appliance ............................................................................... 4 Oracle’s Zero Data Loss Recovery Appliance – Principles of Operation ....................................... 5 Oracle’s Maximum Availability Architecture (MAA) ......................................................................
    [Show full text]
  • HTTP-FUSE Xenoppix
    HTTP-FUSE Xenoppix Kuniyasu Suzaki† Toshiki Yagi† Kengo Iijima† Kenji Kitagawa†† Shuichi Tashiro††† National Institute of Advanced Industrial Science and Technology† Alpha Systems Inc.†† Information-Technology Promotion Agency, Japan††† {k.suzaki,yagi-toshiki,k-iijima}@aist.go.jp [email protected], [email protected] Abstract a CD-ROM. Furthermore it requires remaking the entire CD-ROM when a bit of data is up- dated. The other solution is a Virtual Machine We developed “HTTP-FUSE Xenoppix” which which enables us to install many OSes and ap- boots Linux, Plan9, and NetBSD on Virtual plications easily. However, that requires in- Machine Monitor “Xen” with a small bootable stalling virtual machine software. (6.5MB) CD-ROM. The bootable CD-ROM in- cludes boot loader, kernel, and miniroot only We have developed “Xenoppix” [1], which and most part of files are obtained via Internet is a combination of CD/DVD bootable Linux with network loopback device HTTP-FUSE “KNOPPIX” [2] and Virtual Machine Monitor CLOOP. It is made from cloop (Compressed “Xen” [3, 4]. Xenoppix boots Linux (KNOP- Loopback block device) and FUSE (Filesys- PIX) as Host OS and NetBSD or Plan9 as Guest tem USErspace). HTTP-FUSE CLOOP can re- OS with a bootable DVD only. KNOPPIX construct a block device from many small block is advanced in automatic device detection and files of HTTP servers. In this paper we describe driver integration. It prepares the Xen environ- the detail of the implementation and its perfor- ment and Guest OSes don’t need to worry about mance. lack of device drivers.
    [Show full text]
  • Ext4 File System and Crash Consistency
    1 Ext4 file system and crash consistency Changwoo Min 2 Summary of last lectures • Tools: building, exploring, and debugging Linux kernel • Core kernel infrastructure • Process management & scheduling • Interrupt & interrupt handler • Kernel synchronization • Memory management • Virtual file system • Page cache and page fault 3 Today: ext4 file system and crash consistency • File system in Linux kernel • Design considerations of a file system • History of file system • On-disk structure of Ext4 • File operations • Crash consistency 4 File system in Linux kernel User space application (ex: cp) User-space Syscalls: open, read, write, etc. Kernel-space VFS: Virtual File System Filesystems ext4 FAT32 JFFS2 Block layer Hardware Embedded Hard disk USB drive flash 5 What is a file system fundamentally? int main(int argc, char *argv[]) { int fd; char buffer[4096]; struct stat_buf; DIR *dir; struct dirent *entry; /* 1. Path name -> inode mapping */ fd = open("/home/lkp/hello.c" , O_RDONLY); /* 2. File offset -> disk block address mapping */ pread(fd, buffer, sizeof(buffer), 0); /* 3. File meta data operation */ fstat(fd, &stat_buf); printf("file size = %d\n", stat_buf.st_size); /* 4. Directory operation */ dir = opendir("/home"); entry = readdir(dir); printf("dir = %s\n", entry->d_name); return 0; } 6 Why do we care EXT4 file system? • Most widely-deployed file system • Default file system of major Linux distributions • File system used in Google data center • Default file system of Android kernel • Follows the traditional file system design 7 History of file system design 8 UFS (Unix File System) • The original UNIX file system • Design by Dennis Ritche and Ken Thompson (1974) • The first Linux file system (ext) and Minix FS has a similar layout 9 UFS (Unix File System) • Performance problem of UFS (and the first Linux file system) • Especially, long seek time between an inode and data block 10 FFS (Fast File System) • The file system of BSD UNIX • Designed by Marshall Kirk McKusick, et al.
    [Show full text]
  • File Scavenger User Guide
    File Scavenger® Version 3.2 Comprehensive Data Recovery Tool For Microsoft® Windows® 7, Vista, XP, 2008, 2003, 2000 and NT User’s Guide Revision: 4 Date: September 2010 QueTek® Consulting Corporation COPYRIGHT © Copyright 1998-2010. This document contains materials protected by International Copyright Laws. All rights reserved. No part of this manual may be reproduced, transmitted or transcribed in any form and for any purpose without the express written permission of QueTek® Consulting Corporation. TRADEMARKS Companies and products mentioned in this manual are for identification purpose only. Product names or brand names appearing in this manual may or may not be registered trademarks or copyrights of their respective companies. NOTICE Reasonable effort has been made to ensure that the information in this manual is accurate. QueTek® Consulting Corporation assumes no liability for technical inaccuracies, typographical, or other errors contained herein. QueTek® Consulting Corporation provides this manual “as is” without warranty of any kind, either express or implied, including, but not limited to the implied warranties or conditions of merchantability or fitness for a particular purpose. In no event shall QueTek® Consulting Corporation be liable for any loss of profits, or for direct, indirect, special, incidental or consequential damages arising from any defect or error in QueTek® Consulting Corporation’s products or manuals. Information in this manual is subject to change without notice and does not represent a commitment on the part of QueTek® Consulting Corporation. User Guide - ii LICENSE AGREEMENT AND LIMITED WARRANTY READ THE FOLLOWING TERMS AND CONDITIONS CAREFULLY PRIOR TO PURCHASING THE LICENSE CODE TO UNLOCK FILE SCAVENGER®.
    [Show full text]
  • User's Manual Undelete® for Windows
    User’s Manual Undelete® for Windows® Up-to-the-minute Data Protection® July 2007 This document describes the installation and operation of the Undelete file recovery solutions. It applies to the Server, Desktop Client, Professional and Home Editions of Undelete and is intended for Windows users and system managers. Revision/Update Information: This is a revised manual Software Versions: Undelete 5.0 Server Edition Undelete 5.0 Professional Edition Undelete 5.0 Home Edition Undelete 5.0 Desktop Client Operating Systems: Windows Server 2003 Windows XP Windows 2000 Diskeeper Corporation, Burbank, California ________________________ July 2007 _________ © 2000 — 2007 by Diskeeper Corporation The Software described in this document is owned by Diskeeper Corporation and is protected by United States copyright laws and international treaty provisions. Therefore, you must treat the Software like any other copyrighted material (e.g. a book or musical recording) except that you may either (a) make one copy of the Software solely for backup or archival purposes, or (b) transfer the Software to a single hard disk provided you keep the original solely for backup or archival purposes. You may not copy the user documentation provided with the Software, except for your own authorized use. RESTRICTED RIGHTS LEGEND The software and documentation are provided with RESTRICTED RIGHTS. Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 or subparagraphs (c)(1) and (2) of the Commercial Computer Software-Restricted Rights at 48 CFR 52.227-19 as applicable.
    [Show full text]
  • CS 152: Computer Systems Architecture Storage Technologies
    CS 152: Computer Systems Architecture Storage Technologies Sang-Woo Jun Winter 2019 Storage Used To be a Secondary Concern Typically, storage was not a first order citizen of a computer system o As alluded to by its name “secondary storage” o Its job was to load programs and data to memory, and disappear o Most applications only worked with CPU and system memory (DRAM) o Extreme applications like DBMSs were the exception Because conventional secondary storage was very slow o Things are changing! Some (Pre)History Magnetic core memory Rope memory (ROM) 1960’s Drum memory 1950~1970s 72 KiB per cubic foot! 100s of KiB (1024 bits in photo) Hand-woven to program the 1950’s Apollo guidance computer Photos from Wikipedia Some (More Recent) History Floppy disk drives 1970’s~2000’s 100 KiBs to 1.44 MiB Hard disk drives 1950’s to present MBs to TBs Photos from Wikipedia Some (Current) History Solid State Drives Non-Volatile Memory 2000’s to present 2010’s to present GB to TBs GBs Hard Disk Drives Dominant storage medium for the longest time o Still the largest capacity share Data organized into multiple magnetic platters o Mechanical head needs to move to where data is, to read it o Good sequential access, terrible random access • 100s of MB/s sequential, maybe 1 MB/s 4 KB random o Time for the head to move to the right location (“seek time”) may be ms long • 1000,000s of cycles! Typically “ATA” (Including IDE and EIDE), and later “SATA” interfaces o Connected via “South bridge” chipset Ding Yuan, “Operating Systems ECE344 Lecture 11: File
    [Show full text]
  • Legality and Ethics of Web Scraping
    Murray State's Digital Commons Faculty & Staff Research and Creative Activity 12-15-2020 Tutorial: Legality and Ethics of Web Scraping Vlad Krotov Leigh Johnson Murray State University Leiser Silva University of Houston Follow this and additional works at: https://digitalcommons.murraystate.edu/faculty Recommended Citation Krotov, V., Johnson, L., & Silva, L. (2020). Tutorial: Legality and Ethics of Web Scraping. Communications of the Association for Information Systems, 47, pp-pp. https://doi.org/10.17705/1CAIS.04724 This Peer Reviewed/Refereed Publication is brought to you for free and open access by Murray State's Digital Commons. It has been accepted for inclusion in Faculty & Staff Research and Creative Activity by an authorized administrator of Murray State's Digital Commons. For more information, please contact [email protected]. See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/343555462 Legality and Ethics of Web Scraping, Communications of the Association for Information Systems (forthcoming) Article in Communications of the Association for Information Systems · August 2020 CITATIONS READS 0 388 3 authors, including: Vlad Krotov Murray State University 42 PUBLICATIONS 374 CITATIONS SEE PROFILE Some of the authors of this publication are also working on these related projects: Addressing barriers to big data View project Web Scraping Framework: An Integrated Approach to Retrieving Big Qualitative Data from the Web View project All content following this
    [Show full text]
  • Next Generation Disaster Data Infrastructure
    Next Generation Disaster Data Infrastructure A study report of the CODATA Task Group on Linked Open Data for Global Disaster Risk Research Supported by Study Panel Lead Authors in alphabetical order Bapon Fakhruddin, Tonkin & Taylor International, New Zealand Edward Chu, CODATA Task Group on Linked Open Data for Global Disaster Risk Research Guoqing Li, Institute of Remote Sensing and Digital Earth, Chinese Academy of Sciences, China Contributing Authors in alphabetical order Amit Paul, BNA Technology Consulting LTD., India David Wyllie, Tonkin & Taylor International, New Zealand Durga Ragupathy, Tonkin & Taylor International, New Zealand Jibo Xie, Institute of Remote Sensing and Digital Earth, Chinese Academy of Sciences, China Kun-Lin Lu, CODATA Task Group on Linked Open Data for Global Disaster Risk Research Kunal Sharma, National Disaster Management Authority, India I-Ching Chen, CODATA Task Group on Linked Open Data for Global Disaster Risk Research Nuha Eltinay, Arab Urban Development Institute, Kingdom of Saudi Arabia Saurabh Dalal, National Disaster Management Authority, India Raj Prasanna, Joint Centre for Disaster Research, Massey University Richard Reinen-Hamill, Tonkin & Taylor International, New Zealand Tengfei Yang, Institute of Remote Sensing and Digital Earth, Chinese Academy of Sciences, China Vimikthi Jayawardene, The University of Queensland, Australia Acknowledgments This work is supported by the Committee on Data for Science and Technology (CODATA) of International Science Council (ISC), Integrated Research on Disaster Risk (IRDR); National Key R&D Program of China (2016YFE0122600) and Tonkin & Taylor International Ltd, New Zealand. LODGD (2019), Next Generation Disaster Data Infrastructure -White Paper. CODATA Task Group, Linked Open Data for Global Disaster Risk Research (LODGD).
    [Show full text]
  • Filesystem Considerations for Embedded Devices ELC2015 03/25/15
    Filesystem considerations for embedded devices ELC2015 03/25/15 Tristan Lelong Senior embedded software engineer Filesystem considerations ABSTRACT The goal of this presentation is to answer a question asked by several customers: which filesystem should you use within your embedded design’s eMMC/SDCard? These storage devices use a standard block interface, compatible with traditional filesystems, but constraints are not those of desktop PC environments. EXT2/3/4, BTRFS, F2FS are the first of many solutions which come to mind, but how do they all compare? Typical queries include performance, longevity, tools availability, support, and power loss robustness. This presentation will not dive into implementation details but will instead summarize provided answers with the help of various figures and meaningful test results. 2 TABLE OF CONTENTS 1. Introduction 2. Block devices 3. Available filesystems 4. Performances 5. Tools 6. Reliability 7. Conclusion Filesystem considerations ABOUT THE AUTHOR • Tristan Lelong • Embedded software engineer @ Adeneo Embedded • French, living in the Pacific northwest • Embedded software, free software, and Linux kernel enthusiast. 4 Introduction Filesystem considerations Introduction INTRODUCTION More and more embedded designs rely on smart memory chips rather than bare NAND or NOR. This presentation will start by describing: • Some context to help understand the differences between NAND and MMC • Some typical requirements found in embedded devices designs • Potential filesystems to use on MMC devices 6 Filesystem considerations Introduction INTRODUCTION Focus will then move to block filesystems. How they are supported, what feature do they advertise. To help understand how they compare, we will present some benchmarks and comparisons regarding: • Tools • Reliability • Performances 7 Block devices Filesystem considerations Block devices MMC, EMMC, SD CARD Vocabulary: • MMC: MultiMediaCard is a memory card unveiled in 1997 by SanDisk and Siemens based on NAND flash memory.
    [Show full text]
  • DMFS - a Data Migration File System for Netbsd
    DMFS - A Data Migration File System for NetBSD William Studenmund Veridian MRJ Technology Solutions NASAAmes Research Center" Abstract It was designed to support the mass storage systems de- ployed here at NAS under the NAStore 2 system. That system supported a total of twenty StorageTek NearLine ! have recently developed DMFS, a Data Migration File tape silos at two locations, each with up to four tape System, for NetBSD[I]. This file system provides ker- drives each. Each silo contained upwards of 5000 tapes, nel support for the data migration system being devel- and had robotic pass-throughs to adjoining silos. oped by my research group at NASA/Ames. The file system utilizes an underlying file store to provide the file The volman system is designed using a client-server backing, and coordinates user and system access to the model, and consists of three main components: the vol- files. It stores its internal metadata in a flat file, which man master, possibly multiple volman servers, and vol- resides on a separate file system. This paper will first man clients. The volman servers connect to each tape describe our data migration system to provide a context silo, mount and unmount tapes at the direction of the for DMFS, then it will describe DMFS. It also will de- volman master, and provide tape services to clients. The scribe the changes to NetBSD needed to make DMFS volman master maintains a database of known tapes and work. Then it will give an overview of the file archival locations, and directs the tape servers to move and mount and restoration procedures, and describe how some typi- tapes to service client requests.
    [Show full text]
  • PROTECTING DATA from RANSOMWARE and OTHER DATA LOSS EVENTS a Guide for Managed Service Providers to Conduct, Maintain and Test Backup Files
    PROTECTING DATA FROM RANSOMWARE AND OTHER DATA LOSS EVENTS A Guide for Managed Service Providers to Conduct, Maintain and Test Backup Files OVERVIEW The National Cybersecurity Center of Excellence (NCCoE) at the National Institute of Standards and Technology (NIST) developed this publication to help managed service providers (MSPs) improve their cybersecurity and the cybersecurity of their customers. MSPs have become an attractive target for cyber criminals. When an MSP is vulnerable its customers are vulnerable as well. Often, attacks take the form of ransomware. Data loss incidents—whether a ransomware attack, hardware failure, or accidental or intentional data destruction—can have catastrophic effects on MSPs and their customers. This document provides recommend- ations to help MSPs conduct, maintain, and test backup files in order to reduce the impact of these data loss incidents. A backup file is a copy of files and programs made to facilitate recovery. The recommendations support practical, effective, and efficient back-up plans that address the NIST Cybersecurity Framework Subcategory PR.IP-4: Backups of information are conducted, maintained, and tested. An organization does not need to adopt all of the recommendations, only those applicable to its unique needs. This document provides a broad set of recommendations to help an MSP determine: • items to consider when planning backups and buying a backup service/product • issues to consider to maximize the chance that the backup files are useful and available when needed • issues to consider regarding business disaster recovery CHALLENGE APPROACH Backup systems implemented and not tested or NIST Interagency Report 7621 Rev. 1, Small Business planned increase operational risk for MSPs.
    [Show full text]
  • Unionfs: User- and Community-Oriented Development of a Unification File System
    Unionfs: User- and Community-Oriented Development of a Unification File System David Quigley, Josef Sipek, Charles P. Wright, and Erez Zadok Stony Brook University {dquigley,jsipek,cwright,ezk}@cs.sunysb.edu Abstract If a file exists in multiple branches, the user sees only the copy in the higher-priority branch. Unionfs allows some branches to be read-only, Unionfs is a stackable file system that virtually but as long as the highest-priority branch is merges a set of directories (called branches) read-write, Unionfs uses copy-on-write seman- into a single logical view. Each branch is as- tics to provide an illusion that all branches are signed a priority and may be either read-only writable. This feature allows Live-CD develop- or read-write. When the highest priority branch ers to give their users a writable system based is writable, Unionfs provides copy-on-write se- on read-only media. mantics for read-only branches. These copy- on-write semantics have lead to widespread There are many uses for namespace unifica- use of Unionfs by LiveCD projects including tion. The two most common uses are Live- Knoppix and SLAX. In this paper we describe CDs and diskless/NFS-root clients. On Live- our experiences distributing and maintaining CDs, by definition, the data is stored on a read- an out-of-kernel module since November 2004. only medium. However, it is very convenient As of March 2006 Unionfs has been down- for users to be able to modify the data. Uni- loaded by over 6,700 unique users and is used fying the read-only CD with a writable RAM by over two dozen other projects.
    [Show full text]