DOCSLIB.ORG

Using Internal Sensors for Computer Intrusion Detection

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Using Internal Sensors for Computer Intrusion Detection USING INTERNAL SENSORS FOR COMPUTER INTRUSION DETECTION A Thesis Submitted to the Faculty of Purdue University by Diego Zamboni CERIAS TR 2001-42 Center for Education and Research in Information Assurance and Security, Purdue University August 2001 USING INTERNAL SENSORS FOR COMPUTER INTRUSION DETECTION A Thesis Submitted to the Faculty of Purdue University by Diego Zamboni In Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy August 2001 ii To my parents for giving me life, and to Susana for sharing it with me. iii ACKNOWLEDGMENTS As usual, a large number of people were very important for the completion of this thesis work, and I would like to acknowledge at least some of them. First the official acknowledgments: Portions of the research contributing to this dis- sertation were supported by the various sponsors of CERIAS, and my stay at Purdue was partially funded by a Fulbright/Conacyt fellowship. Their support is gratefully acknowl- edged. I would like to thank my advisor, Eugene Spafford. He received me with open arms from my first day at Purdue, and provided continuous guidance and support throughout my stay here. For that I am very, very grateful. I would like to acknowledge the other members of my Ph.D. committee: Stephanie For- rest, Mikhail Atallah, Jens Palsberg and Carla Brodley. They provided invaluable feedback and advice for my work and for this dissertation. Many people contributed significantly to my work, and my deepest gratitude goes to all of them. Susana Soriano, Benjamin Kuperman, Thomas Daniels, Florian Kerschbaum, Rajeev Gopalakrishna and Jim Early provided me with many hours of discussion, continu- ously questioned my assumptions, and led to many new ideas. The original ideas for how internal sensors would be implemented evolved from discussions with Ben Kuperman, and he also came up with the name “ESP”. Florian Kerschbaum poured enormous amounts of work into implementing and testing detectors, and Jim Early implemented the file integrity detector. Angel Soriano guided me through the statistical analysis of the experimental results, and suggested multiple avenues for future research. The staff at the Statistical Con- sulting Service at Purdue also provided invaluable guidance in the analysis of data. Other iv students at CERIAS provided support for my work: Sofie Nystrom (who let me use her office), Kevin Du, Hoi Chang, Chapman Flack, Chris Telfer, and many others. Substantial administrative, technical and logistic support were needed for the comple- tion of my work. The system administrators at CERIAS, Susana Soriano and Vince Koser, always maintained our computers up and running and kept up with my continuous requests and questions, even at times when what they really wanted to do was remove my account and get rid of me. All the administrative personnel at CERIAS, including Mary Jo Maslin, Lori Floyd, Paula Cheatham, Steve Hare and Andra Boehning, always gave me their sup- port. In particular, I would like to thank Marlene Walls, who tirelessly stayed on top of things at CERIAS to make sure everything was going as it should. Without her, my life (and the scheduling for seeing my advisor) would have been infinitely more complicated. Before and throughout my stay at Purdue there were people who contributed to my ca- reer by inspiring, supporting, and challenging me. These include Gerardo Cisneros (who may not know it, but he was my main inspiration for pursuing a Ph.D.); my friends Rey- naldo Roel, Carlos Gonzalez,´ Claudia Fajardo, Agust´ın and Adriana Casimiro, Luis and Claudia Graf, Luis and Carmen Teresa Mart´ınez and Eduardo Asbun, all of whom gave me so much support and friendship; Ivan Krsul, Christoph Schuba, Tanya Mastin, Kathy Price, Keith Watson and Robin Sundaram, who gave me a great welcome to the COAST laboratory and helped me through my first years at Purdue. Thank you all. Who I am is a result of my formation, and for that I have to thank my family. My parents, Laura Zamboni and Gilberto De La Rosa, and my sisters, Ana, Daniela and Ines,´ have been an inexhaustible source of inspiration, support, advice, and happiness. And finally, but most importantly, I would like to thank my best friend and wife, Susana Soriano. She lifted me at times when I thought I could not keep going, and her support and care made it possible for me to start and finish this endeavor. She listened patiently to my ideas and tolerated me being locked up in my office 20 hours a day (although she always found ways of spending some time together!), and on top of that, she managed to expertly proofread my dissertation. Susana: you are the love of my life, and words cannot express how much I need to thank you. v TABLE OF CONTENTS Page LIST OF TABLES :::::::::::::::::::::::::::::::::: ix LIST OF FIGURES ::::::::::::::::::::::::::::::::: xi LIST OF DEFINITIONS :::::::::::::::::::::::::::::: xiii ABSTRACT ::::::::::::::::::::::::::::::::::::: xiv 1 INTRODUCTION :::::::::::::::::::::::::::::::: 1 1.1 Background and problem statement :::::::::::::::::::: 1 1.2 Basic concepts ::::::::::::::::::::::::::::::: 2 1.2.1 Intrusion detection ::::::::::::::::::::::::: 2 1.2.2 Desirable characteristics of an intrusion detection system ::::: 3 1.3 Problems with existing intrusion detection systems :::::::::::: 5 1.4 Thesis statement :::::::::::::::::::::::::::::: 5 1.5 Document organization :::::::::::::::::::::::::: 6 2 RELATED WORK AND ARCHITECTURES FOR INTRUSION DETECTION 7 2.1 Data collection architectures :::::::::::::::::::::::: 7 2.1.1 Data collection structure: centralized and distributed ::::::: 10 2.1.2 Data collection mechanisms: direct and indirect monitoring :::: 11 2.1.3 Data collection mechanisms: host-based and network-based ::: 14 2.1.4 Data collection mechanisms: external and internal sensors :::: 16 2.2 Data analysis architectures ::::::::::::::::::::::::: 21 2.3 Experiences in building a distributed intrusion detection system ::::: 22 2.4 Comments about intrusion detection architectures ::::::::::::: 25 2.5 Related work :::::::::::::::::::::::::::::::: 26 vi Page 3 AN ARCHITECTURE FOR INTRUSION DETECTION BASED ON INTER- NAL SENSORS ::::::::::::::::::::::::::::::::: 29 3.1 Embedded detectors :::::::::::::::::::::::::::: 29 3.1.1 How embedded detectors work :::::::::::::::::: 30 3.1.2 Relationship between internal sensors and embedded detectors :: 31 3.1.3 Stateless and stateful detectors ::::::::::::::::::: 33 3.1.4 Strengths and weaknesses of embedded detectors ::::::::: 34 3.2 The ESP architecture :::::::::::::::::::::::::::: 35 3.2.1 Internal sensors and embedded detectors ::::::::::::: 35 3.2.2 Per-host external sensors :::::::::::::::::::::: 35 3.2.3 Network-wide external sensors :::::::::::::::::: 35 3.3 Distinguishing characteristics of the ESP architecture ::::::::::: 36 3.3.1 Types of data observed ::::::::::::::::::::::: 36 3.3.2 Tighter coupling between event collection and event analysis ::: 37 3.3.3 Intrusion detection at the application and operating system level : 38 3.3.4 Size of the intrusion detection system ::::::::::::::: 38 3.3.5 Timeliness of detection :::::::::::::::::::::: 39 3.3.6 Impact on the host ::::::::::::::::::::::::: 39 3.3.7 Resistance to attack :::::::::::::::::::::::: 39 4 THE ESP IMPLEMENTATION ::::::::::::::::::::::::: 41 4.1 Purpose of the implementation ::::::::::::::::::::::: 41 4.2 Specific and generic detectors ::::::::::::::::::::::: 41 4.3 Sources of information ::::::::::::::::::::::::::: 42 4.4 Implementation platform :::::::::::::::::::::::::: 43 4.5 Reporting mechanism ::::::::::::::::::::::::::: 44 4.6 Methodology for implementation of detectors ::::::::::::::: 46 4.7 Applicability of CVE entries :::::::::::::::::::::::: 47 4.8 Design and implementation considerations for detectors :::::::::: 48 vii Page 4.9 Naming, testing and measuring detectors ::::::::::::::::: 49 4.10 Relationships between detectors :::::::::::::::::::::: 50 4.11 Recording information about sensors and detectors :::::::::::: 51 4.12 Case studies :::::::::::::::::::::::::::::::: 53 4.12.1 Embedded detectors for network-based attacks :::::::::: 53 4.12.2 Embedded detectors for sendmail attacks ::::::::::::: 60 4.13 Detectors implemented ::::::::::::::::::::::::::: 65 4.13.1 By vulnerable platform or program :::::::::::::::: 65 4.13.2 By implementation directory ::::::::::::::::::: 67 4.13.3 By size ::::::::::::::::::::::::::::::: 67 4.13.4 By type :::::::::::::::::::::::::::::: 70 4.13.5 By data sources used :::::::::::::::::::::::: 72 4.13.6 By vulnerability type ::::::::::::::::::::::: 74 4.13.7 By detection and implementation rates :::::::::::::: 77 4.14 Auxiliary components ::::::::::::::::::::::::::: 77 4.15 Comments about the ESP implementation ::::::::::::::::: 80 5 TESTING THE ESP IMPLEMENTATION ::::::::::::::::::: 82 5.1 Performance testing :::::::::::::::::::::::::::: 82 5.1.1 Test design and methodology ::::::::::::::::::: 82 5.1.2 Results of the NetPerf test ::::::::::::::::::::: 85 5.1.3 Results of the http load test :::::::::::::::::::: 88 5.1.4 Comparison and comments about the tests ::::::::::::: 88 5.2 Detection testing :::::::::::::::::::::::::::::: 93 5.2.1 Test design and methodology ::::::::::::::::::: 93 5.2.2 Results from the detection test ::::::::::::::::::: 97 5.2.3 Comments about the detection test ::::::::::::::::: 109 6 CONCLUSIONS, SUMMARY AND FUTURE WORK ::::::::::::: 112 6.1 Conclusions :::::::::::::::::::::::::::::::: 112 viii Page 6.2 Summary of main contributions :::::::::::::::::::::: 114 6.3 Future work :::::::::::::::::::::::::::::::: 115
Load more

Recommended publications
  • Software Security for Open-Source Systems
    Open-Source Security Software Security for Open-Source Systems Debate over whether open-source software development leads to more or less secure software has raged for years. Neither is in- trinsically correct: open-source software gives both attackers and defenders greater power over system security. Fortunately, several security-enhancing technologies for open-source sys- tems can help defenders improve their security. classify methods that CRISPIN ome people have claimed that open-source ensure and enforce COWAN software is intrinsically more secure than closed the “nothing else” part into three broad categories: WireX source,1 and others have claimed that it’s not.2 Communications Neither case is absolutely true: they are essen- • Software auditing, which prevents vulnerabilities by Stially flip sides of the same coin. Open source gives both searching for them ahead of time, with or without auto- attackers and defenders greater analytic power to do matic analysis something about software vulnerabilities. If the defender • Vulnerability mitigation, which are compile-time tech- does nothing about security, though, open source just niques that stop bugs at runtime gives that advantage away to the attacker. • Behavior management, which are operating system fea- However, open source also offers great advantages to tures that either limit potential damage or block specif- the defender, giving access to security techniques that are ic behaviors known to be dangerous normally infeasible with closed-source software. Closed source forces users to accept the level of security diligence Software auditing that the vendor chooses to provide, whereas open source The least damaging software vulnerability is the one that lets users (or other collectives of people) raise the bar on never happens.
    [Show full text]
  • Hardening Linux
    eBooks-IT.org 4444_FM_final.qxd 1/5/05 12:39 AM Page i eBooks-IT.org Hardening Linux JAMES TURNBULL 4444_FM_final.qxd 1/5/05 12:39 AM Page ii eBooks-IT.org Hardening Linux Copyright © 2005 by James Turnbull All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher. ISBN (pbk): 1-59059-444-4 Printed and bound in the United States of America 987654321 Trademarked names may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, we use the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. Lead Editor: Jim Sumser Technical Reviewer: Judith Myerson Editorial Board: Steve Anglin, Dan Appleman, Ewan Buckingham, Gary Cornell, Tony Davis, Jason Gilmore, Chris Mills, Dominic Shakeshaft, Jim Sumser Project Manager: Kylie Johnston Copy Edit Manager: Nicole LeClerc Copy Editor: Kim Wimpsett Production Manager: Kari Brooks-Copony Production Editor: Kelly Winquist Compositor: Linda Weidemann Proofreader: Lori Bring Indexer: Kevin Broccoli Artist: Kinetic Publishing Services, LLC Cover Designer: Kurt Krames Manufacturing Manager: Tom Debolski Distributed to the book trade in the United States by Springer-Verlag New York, Inc., 233 Spring Street, 6th Floor, New York, NY 10013, and outside the United States by Springer-Verlag GmbH & Co. KG, Tiergartenstr. 17, 69112 Heidelberg, Germany. In the United States: phone 1-800-SPRINGER, fax 201-348-4505, e-mail [email protected], or visit http://www.springer-ny.com.
    [Show full text]
  • Securing Linux
    466_HTC_Linux_FM.qxd 10/2/07 10:05 AM Page iii How to Cheat at Securing Linux Mohan Krishnamurthy Eric S. Seagren Raven Alder Aaron W. Bayles Josh Burke Skip Carter Eli Faskha 466_HTC_Linux_FM.qxd 10/2/07 10:05 AM Page iv Elsevier, Inc., the author(s), and any person or firm involved in the writing, editing, or production (collectively “Makers”) of this book (“the Work”) do not guarantee or warrant the results to be obtained from the Work. There is no guarantee of any kind, expressed or implied, regarding the Work or its contents.The Work is sold AS IS and WITHOUT WARRANTY.You may have other legal rights, which vary from state to state. In no event will Makers be liable to you for damages, including any loss of profits, lost savings, or other incidental or consequential damages arising out from the Work or its contents. Because some states do not allow the exclusion or limitation of liability for consequential or incidental damages, the above limitation may not apply to you. You should always use reasonable care, including backup and other appropriate precautions, when working with computers, networks, data, and files. Syngress Media®, Syngress®,“Career Advancement Through Skill Enhancement®,”“Ask the Author UPDATE®,” and “Hack Proofing®,” are registered trademarks of Elsevier, Inc.“Syngress:The Definition of a Serious Security Library”™,“Mission Critical™,” and “The Only Way to Stop a Hacker is to Think Like One™” are trademarks of Elsevier, Inc. Brands and product names mentioned in this book are trademarks or service marks of their respective companies. PUBLISHED BY Syngress Publishing, Inc.
    [Show full text]
  • Operating System Stability and Security Through Process Homeostasis
    Operating System Stability and Security through Process Homeostasis by Anil Buntwal Somayaji B.S., Massachusetts Institute of Technology, 1994 DISSERTATION Submitted in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy Computer Science The University of New Mexico Albuquerque, New Mexico May 2002 c 2002, Anil Buntwal Somayaji ! iii Dedication To all those system administrators who spend their days nursemaiding our computers. iv Acknowledgments Graduate school has turned out to be a long, difficult, but rewarding journey for me, and I would not have made it this far without the help of many, many people. I cannot hope to completely document how these influences have helped me grow; nevertheless, I must try and acknowledge those who have accompanied me. First, I would like to thank my committee: David Ackley, Rodney Brooks, Barney Maccabe, Margo Seltzer, and especially my advisor, Stephanie Forrest. They all had to read through a rougher manuscript than I would have liked, and had to do so under significant time pressures. They provided invaluable feedback on my ideas and experiments. Most importantly, they have been my teachers. I’m also grateful to have been part of the Adaptive Computation Group at the University of New Mexico and to have been a member of the complex adaptive systems community here in New Mexico. Fellow graduate students at UNM and colleagues at the Santa Fe Institute have shaped my thoughts and have inspired me to do my best work. I will miss all of you. The Computer Science Department at UNM has been my home for the past several years.
    [Show full text]
  • Smashguard: a Hardware Solution to Prevent Security Attacks on the Function Return Address
    1 SmashGuard: A Hardware Solution to Prevent Security Attacks on the Function Return Address H. Ozdo¨ gano˜ glu˜ ∗, T. N. Vijaykumar‡, C. E. Brodley†, B. A. Kuperman§ and A. Jalote¶ ∗[email protected], ‡[email protected], ¶[email protected] School of Electrical and Computer Engineering Purdue University, West Lafayette, Indiana 47906–1285 †[email protected], Department of Computer Science Tufts University, Medford, MA 02155 §[email protected] Department of Computer Science Swarthmore College, Swarthmore, PA 19081 Abstract A buffer overflow attack is perhaps the most common attack used to compromise the security of a host. This attack can be used to change the function return address and redirect execution to the attacker’s code. We present a hardware-based solution, called SmashGuard, to protect against all known forms of attack on the function return addresses stored on the program stack. With each function call instruction, the current return address is pushed onto a hardware stack. A return instruction compares its address to the return address from the top of the hardware stack. An exception is raised to signal the mismatch. Because the stack operations and checks are done in hardware in parallel with the usual execution of instructions, our best- performing implementation scheme has virtually no 1 performance overhead. While previous software-based approaches’ average performance degradation for the SPEC2000 benchmarks is only 2.8%, their worst-case degradation is up to 8.3%. Apart from the lack of robustness in performance, the software approaches’ key disadvantages are less security coverage and the need for recompilation of applications.
    [Show full text]
  • Practical Linux Forensics by Bruce Nikkel! As a Prepublication Title, This Book May Be Incom- Plete and Some Chapters May Not Have Been Proofread
    P R A C T I C A L LINUX FORENSICS A GUIDE FOR DIGITAL INVESTIGATORS BRUCE NIKKEL EARLY ACCESS NO STARCH PRESS EARLY ACCESS PROGRAM: FEEDBACK WELCOME! Welcome to the Early Access edition of the as yet unpublished Practical Linux Forensics by Bruce Nikkel! As a prepublication title, this book may be incom- plete and some chapters may not have been proofread. Our goal is always to make the best books possible, and we look forward to hearing your thoughts. If you have any comments or questions, email us at [email protected]. If you have specific feedback for us, please include the page number, book title, and edition date in your note, and we’ll be sure to review it. We appreciate your help and support! We’ll email you as new chapters become available. In the meantime, enjoy! PR CA T IC A L L INU X FOR E N SI C S BRUCE N IK KE L Early Access edition, 6/18/21 Copyright © 2021 by Bruce Nikkel. ISBN-13: 978-1-7185-0196-6 (print) ISBN-13: 978-1-7185-0197-3 (ebook) Publisher: William Pollock Production Manager: Rachel Monaghan Production Editor: Miles Bond Developmental Editor: Jill Franklin Cover Illustrator: James L. Barry Technical Reviewer: Don Frick Copyeditor: George Hale No Starch Press and the No Starch Press logo are registered trademarks of No Starch Press, Inc. Other product and company names mentioned herein may be the trademarks of their respective owners. Rather than use a trademark symbol with every occurrence of a trade- marked name, we are using the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark.
    [Show full text]
  • Linux Distrib Vendors Make Patches Available for GHOST 29 January 2015, by Nancy Owano
    Linux distrib vendors make patches available for GHOST 29 January 2015, by Nancy Owano patches were available from Linux distributions, he added, in the Tuesday posting. What is "glibc"? This is the Gnu C library and a core part of the OS. "The vulnerability is in one of the functions of glibc," said Sarwate, where a buffer overflows.The vulnerability can be triggered locally and remotely from any of the gethostbyname*() functions. So what's the risk? An attacker, said Sarwate, could send a malicious email to an email server and get a remote shell to the Linux machine. The good news is that most Linux vendors have released patches. "So the best way to mitigate this issue," said Sarwate, "is to apply a patch from your Linux distribution." Gavin Millard, technical director of Tenable Network Security, told the Telegraph: "Patches are being released for the major Linux distributions and should be applied with a priority on any vulnerable systems with services that can be reached from the Internet." Qualys said on Tuesday that there was a serious Sarwate said the vulnerability is called "GHOST" weakness in the Linux glibc library. During a code because of the GetHOST functions by which the audit, Qualys researchers discovered a buffer flaw can be exploited. The vulnerability has a overflow in the __nss_hostname_digits_dots() history; it was found some years ago and it was function of glibc. The weakness can allow fixed but it was not classified as a security attackers to remotely take control of the victim's vulnerability. Nonetheless, as of Tuesday, system without any prior knowledge of system distributions have released patches, said Sarwate, credentials.
    [Show full text]
  • OS Hardening Making Systems More Secure
    OS Hardening Making systems more secure Seminar paper Ausgew¨ahlte Kapitel der IT-Security Author: John Ostrowski Student identification number: 1710475050 Date: 28.1.2020 Contents 1 Introduction 1 2 Security Requirements 2 2.1 Security Requirements . .2 2.2 Operating System Security Evaluation . .3 2.3 Common Threats . .4 3 OS Hardening 8 3.1 Safe Environments . .8 3.2 Access Control . 11 3.3 Reducing the Attack Surface . 14 4 Conclusion 15 Bibliography 16 i Chapter 1 Introduction The operating system (OS) serves as the intermediary between the computer's hard- ware and the application programs. It assists the user in performing operations on the underlying physical components and manages the interactions between different devices connected to a computer system. The two main activities are processing and the coordination of the input/output (I/O) devices connected to the computer system. Processing includes the management and scheduling of different user programs run- ning simultaneously as well as the definition, management and preservation of data in memory. Since multiple internal and external users and programs can interact with one com- puter system at the same time, the OS has to ensure that they only can read and write to files and devices where they have permission to. Otherwise, data can be stolen and used maliciously. [SGG13] To reduce the attack surface of an operating system different procedures and poli- cies need to be enforced to allow for a secure operation of a system. This process is called \operating system hardening"[PP09] In this paper the term security is explored and applied to the security requirements of an operating system.
    [Show full text]
  • Secure Programmer: Prevent Race Conditions
    Secure programmer: Prevent race conditions Resource contention can be used against you David Wheeler ([email protected]), Research Staff Member, Institute for Defense Analyses Summary: Learn what a race condition is and why it can cause security problems. This article shows you how to handle common race conditions on UNIX-like systems, including how to create lock files correctly, alternatives to lock files, how to handle the file system, and how to handle shared directories -- and, in particular, how to correctly create temporary files in the /tmp directory. You'll also learn a bit about signal handling. Date: 07 Oct 2004 Level: Intermediate Also available in: Japanese Activity: 9098 views Comments: (View | Add comment - Sign in) Rate this article Using a stolen password, "Mallory" managed to log into an important server running Linux. The account was limited, but Mallory knew how to cause trouble with it. Mallory installed and ran a trivial program with odd behavior: It quickly created and removed many different symbolic link files in the /tmp directory, using a multitude of processes. (When accessed, a symbolic link file, also called a symlink, redirects the requester to another file.) Mallory's program kept creating and removing many different symlinks pointing to the same special file: /etc/passwd, the password file. A security precaution on this server was that every day, it ran the security program Tripwire -- specifically, the older version, 2.3.0. As Tripwire started up, it tried to create a temporary file, as many programs do. Tripwire looked and found that there was no file named /tmp/twtempa19212, so that appeared to be a good name for a temporary file.
    [Show full text]
  • Wikireader Free Software and Free Contents
    WIKIREADER FREE SOFTWARE AND FREE CONTENTS A COLLECTION OF ARTICLES FROM WIKIPEDIA, THE FREE ENCYCLOPEDIA Last change: June 28th, 2004 W I K I M E D I A F O U N D A T I O N IMPRINT Authors: The volunteer writers of the english Wikipedia Editor: Thomas R. "TomK32" Koll Notable Wikipedians for this WikiReader: Used fonts: FreeSerif und FreeMono Cover: Last change in this edition: June 28th 2004 at 22:40 CEST Webdress of Wikipedia: http://en.wikipedia.org ISSN (Onlineedtion): 1613-7752 ISSN (Printedtion): not known yet A complete list of used articles and the names of all registered authors who worked on these articles can be found in the appendix. WIKIREADER INTERNET 1 ON WIKIPEDIA Wikipedia is a free encyclopedia which was started to give everyone a free source of knowledge which you not only can read but also extend in form of writing for it. On the website http://en.wikipedia.org you can not only find the current articles of Wikipedia but you can also start writing imediately without registration or identification. With this revolutionary method more than 700.000 articles were written since 2001 in more than 40 languages, and it's growing faster. In some languages Wikipedia is the first ency- clopedia ever. Since 2003 the Wikimedia Foundation is taking care of running the farm of webservers and also hosts and supports other projects like the multilinugual dictionary Wiktionary and the textbooks project WikiBooks. ON WIKIREADER WikiReader is a randomly published series of collections of Wikipedia articles, a detai- led overview over a certain topic presented in a editored form.
    [Show full text]
  • Bridging the Detection Gap: a Study on a Behavior-Based Approach Using Malware Techniques" (2014)
    Eastern Washington University EWU Digital Commons EWU Masters Thesis Collection Student Research and Creative Works 2014 Bridging the detection gap: a study on a behavior- based approach using malware techniques Geancarlo Palavicini Eastern Washington University Follow this and additional works at: http://dc.ewu.edu/theses Part of the Computer Sciences Commons Recommended Citation Palavicini, Geancarlo, "Bridging the detection gap: a study on a behavior-based approach using malware techniques" (2014). EWU Masters Thesis Collection. 186. http://dc.ewu.edu/theses/186 This Thesis is brought to you for free and open access by the Student Research and Creative Works at EWU Digital Commons. It has been accepted for inclusion in EWU Masters Thesis Collection by an authorized administrator of EWU Digital Commons. For more information, please contact [email protected]. BRIDGING THE DETECTION GAP: A STUDY ON A BEHAVIOR-BASED APPROACH USING MALWARE TECHNIQUES ________________________________________________________________________ A Thesis Presented To Eastern Washington University Cheney, WA ________________________________________________________________________ In Partial Fulfillment of the Requirements for the Degree Master of Science, in Computer Science ______________________________________________________ By Geancarlo Palavicini Jr Winter 2014 ii THESIS OF GEANCARLO PALAVICINI JR APPROVED BY _________________________________________ DATE_________ CAROL TAYLOR, GRADUATE STUDY COMMITEE _________________________________________ DATE_________ BILL
    [Show full text]
  • Master Template
    Open-Source Security Software Security for Open-Source Systems Debate over whether open-source software development leads to more or less secure software has raged for years. Neither is in- trinsically correct: open-source software gives both attackers and defenders greater power over system security. Fortunately, several security-enhancing technologies for open-source sys- tems can help defenders improve their security. classify methods that CRISPIN ome people have claimed that open-source ensure and enforce COWAN software is intrinsically more secure than closed the “nothing else” part into three broad categories: WireX source,1 and others have claimed that it’s not.2 Communications Neither case is absolutely true: they are essen- • Software auditing, which prevents vulnerabilities by Stially flip sides of the same coin. Open source gives both searching for them ahead of time, with or without auto- attackers and defenders greater analytic power to do matic analysis something about software vulnerabilities. If the defender • Vulnerability mitigation, which are compile-time tech- does nothing about security, though, open source just niques that stop bugs at runtime gives that advantage away to the attacker. • Behavior management, which are operating system fea- However, open source also offers great advantages to tures that either limit potential damage or block specif- the defender, giving access to security techniques that are ic behaviors known to be dangerous normally infeasible with closed-source software. Closed source forces users to accept the level of security diligence Software auditing that the vendor chooses to provide, whereas open source The least damaging software vulnerability is the one that lets users (or other collectives of people) raise the bar on never happens.
    [Show full text]