Effectiveness of Linux Rootkit Detection Tools

Total Page:16

File Type:pdf, Size:1020Kb

Effectiveness of Linux Rootkit Detection Tools Effectiveness of Linux Rootkit Detection Tools University of Oulu Faculty of Information Technology and Electrical Engineering Degree Programme in Information Processing Sciences Master’s Thesis Juho Junnila 27.3.2020 2 Abstract Rootkits – a type of software that specializes in hiding entities in computer systems while enabling continuous control or access to it – are particularly difficult to detect compared to other kinds of software. Various tools exist for detecting rootkits, utilizing a wide variety of detection techniques and mechanisms. However, the effectiveness of such tools is not well established, especially in contemporary academic research and in the context of the Linux operating system. This study carried out an empirical evaluation of the effectiveness of five tools with capabilities to detect Linux rootkits: OSSEC, AIDE, Rootkit Hunter, Chkrootkit and LKRG. The effectiveness of each tool was tested by injecting 15 publicly available rootkits in individual detection tests in virtual machines running Ubuntu 16.04, executing the detection tool and capturing its results for analysis. A total of 75 detection tests were performed. The results showed that only 37.3% of the detection tests provided any indication of a rootkit infection or suspicious system behaviour, with the rest failing to provide any signs of anomalous behaviour. However, combining the findings of multiple detection tools increased the overall detection rate to 93.3%, as all but a single rootkit were discovered by at least one tool. Variation was observed in the effectiveness of the detection tools, with detection rates ranging from 13.3% to 53.3%. Variation in detection effectiveness was also found between categories of rootkits, as the overall detection rate was 46.7% for user mode rootkits and 31.1% for kernel mode rootkits. Overall, the findings showed that while an individual detection tool‘s effectiveness can be lacking, using a combination of tools considerably increased the likelihood of a successful detection. Keywords rootkits, rootkit detection, digital forensics, computer security, operating systems, Linux Supervisor Ph.D., University lecturer, Ari Vesanen 3 Foreword This study was born of a personal curiosity to develop a deeper understanding of how rootkits work and how they can be detected using freely available tools. Its origins can be traced back to Trammell Hudson's exceptional presentation of the Thunderstrike EFI rootkit at the 31st Chaos Communication Congress (31C3) conference, which profoundly impressed me with its exotic nature, technical prowess and compelling narrative. Narrowing the research context to Linux was also due to both personal and professional interests, as it is the operating system I'm most deeply familiar with and the one I use and value the most. I would like to thank my thesis supervisor Ari Vesanen for his adept guidance and for the intriguing discussions during our meetings. I would also like to extend my sincere gratitude to my family and friends for all their support and patience during my work on this thesis, my studies and everything else. Juho Junnila Oulu, March 27, 2020 4 Abbreviations AIDE: Advanced Intrusion Detection Environment AMT: Active Management Technology APT: Advanced Package Tool EFI: Extensible Firmware Interface HIDS: Host-based Intrusion Detection System HPC: Hardware Performance Counter IDT: Interrupt Descriptor Table LKM: Loadable Kernel Module LKRG: Linux Kernel Runtime Guard ME: Intel Management Engine OSSEC: Open Source HIDS Security PAM: Pluggable Authentication Modules PID: Process ID SMM: System Management Mode SSDT: System Service Dispatch Table UID: User ID UMH: Linux Usermode Helper VM: Virtual Machine VMI: Virtual Machine Introspection VMM: Virtual Machine Monitor 5 Contents Abstract ............................................................................................................................. 2 Foreword ........................................................................................................................... 3 Abbreviations .................................................................................................................... 4 Contents ............................................................................................................................ 5 1. Introduction .................................................................................................................. 6 1.1 Motivation ............................................................................................................ 6 1.2 Research problem and questions .......................................................................... 6 1.3 Research method .................................................................................................. 7 1.4 Structure ............................................................................................................... 7 2. Background .................................................................................................................. 8 2.1 Literature search .................................................................................................. 8 2.2 Evaluation of rootkit detection effectiveness ....................................................... 9 2.3 Linux ................................................................................................................ 10 2.4 Rootkits .............................................................................................................. 12 2.5 Rootkit detection ................................................................................................ 15 3. Methodology .............................................................................................................. 18 3.1 Research method ................................................................................................ 18 3.2 Rootkits .............................................................................................................. 19 3.2.1 User mode rootkits ................................................................................. 19 3.2.2 Kernel mode rootkits .............................................................................. 21 3.3 Rootkit detection tools ....................................................................................... 23 3.4 Test environment ............................................................................................... 25 3.5 Test process ........................................................................................................ 27 3.6 Evaluation procedure ......................................................................................... 28 4. Results ........................................................................................................................ 29 4.1 Detection runs .................................................................................................... 29 4.2 OSSEC ............................................................................................................... 29 4.3 AIDE ................................................................................................................ 31 4.4 Rootkit Hunter ................................................................................................... 33 4.5 Chkrootkit .......................................................................................................... 36 4.6 LKRG ................................................................................................................ 38 4.7 Summary ............................................................................................................ 40 5. Discussion .................................................................................................................. 46 5.1 Relation to prior studies ..................................................................................... 46 5.2 RQ1: Rootkit detection effectiveness ................................................................ 46 5.3 RQ2: Differences in detection tool effectiveness .............................................. 47 5.4 RQ3: Detection of rootkit types ......................................................................... 48 5.5 Practicality of the detection tools ....................................................................... 49 6. Conclusion .................................................................................................................. 51 References ....................................................................................................................... 53 Appendix A. Literature search terms and results ........................................................... 57 Appendix B. Detection tool setup .................................................................................. 60 Appendix C. Rootkit setup ............................................................................................. 63 6 1. Introduction This chapter describes the background and motivation for this study. The research problem and research questions are also defined. Finally, the utilized research method and the structure of the thesis are described. 1.1 Motivation A rootkit is a type of software that specializes in hiding its presence in computer systems. The main purpose of a rootkit is to facilitate continuous access to the system it is installed on. While often associated with malware, the use of rootkits is not necessarily
Recommended publications
  • Integrity Checking of Operating Systems with Respect to Kernel Level Malware”
    To Bianca, for being who you are. Abstract Kernel-mode rootkits have gained a considerable momentum within the blackhat com- munity. They represent a considerable threat to any computer system, as they pro- vide an intruder with the ability to hide the presence of his malicious activity. These rootkits make changes to the operating system’s kernel, thereby providing particularly stealthy hiding techniques. Considering the kernel rootkit threat and other threats, the collection of reliable information from a compromised system becomes a central problem within the domain of computer security. This thesis addresses this problem. It looks at the possibility of using virtualization as a means to facilitate kernel-mode rootkit detection through integrity checking. The thesis describes several areas within the Linux kernel, which are commonly subverted by kernel-mode rootkits. It introduces the reader to the concept of virtual- ization and describes several technologies employing virtualization. The kernel-mode rootkit threat is then addressed through a description of their hiding methodologies. Some of the existing methods for malware detection are also addressed and analysed. A number of general requirements, which need to be satisfied by a general model enabling kernel-mode rootkit detection, are identified. A model addressing these requirements is suggested, and a framework implementing the model is set-up. The detection capabilities of the framework are tested on a couple of rootkits. iii Preface This report presents the results of my master thesis “Integrity checking of operating systems with respect to kernel level malware”. It is written as part of the Master de- gree (Sivilingeniør) in Computer Science at the Norwegian University of Science and Technology (NTNU), during Spring 2005.
    [Show full text]
  • A Story of an Embedded Linux Botnet
    A Moose Once Bit My Honeypot A Story of an Embedded Linux Botnet by Olivier Bilodeau (@obilodeau) $ apropos Embedded Linux Malware Moose DNA (description) Moose Herding (the Operation) What’s New? Take Aways $ whoami Malware Researcher at ESET Infosec lecturer at ETS University in Montreal Previously infosec developer, network admin, linux system admin Co-founder Montrehack (hands-on security workshops) Founder NorthSec Hacker Jeopardy Embedded Linux Malware What marketing likes to call "Internet of Things Malware" Malware Running On An Embedded Linux System Like consumer routers DVR Smart TVs IP Camera monitoring systems … Caracteristics of Embedded Linux Systems Small amount of memory Small amount of flash Non x86 architectures: ARM, MIPS Wide-variety of libc implementations / versions Same ABI-compatible Linux kernel (2.4 < x < 4.3) Support ELF binaries Rarely an integrated UI Networked Why Threats On These Systems Matters? Hard to detect Hard to remediate Hard to fix Low hanging fruit for bad guys It’s Real Several cases disclosed in the last two years A lot of same-old background noise (DDoSer) Things are only getting worse Wait, is IoT malware really about things? NNoo.. NNoott yyeett.. So what kind of malware can we find on such insecure devices? Linux/Aidra Linux/Bassobo ChinaZ family (XOR.DDoS, …) Linux/Dofloo Linux/DNSAmp (Mr Black, BillGates) Linux/Gafgyt (LizardStresser) Linux/Hydra Linux/Tsunami … LLeessssoonn LLeeaarrnneedd ##00 Statically-linked stripped binaries Static/stripped ELF primer No imports (library calls) present
    [Show full text]
  • The Science DMZ
    The Science DMZ Brian Tierney, Eli Dart, Eric Pouyoul, Jason Zurawski ESnet Supporting Data-Intensive Research Workshop QuestNet 2013 Gold Coast, Australia July 2, 2013 What’s there to worry about? © Owen Humphreys/National Geographic Traveler Photo Contest 2013 7/2/13 2 Lawrence Berkeley National Laboratory U.S. Department of Energy | Office of Science The Science DMZ in 1 Slide Consists of three key components, all required: “Friction free” network path • Highly capable network devices (wire-speed, deep queues) • Virtual circuit connectivity option • Security policy and enforcement specific to science workflows • Located at or near site perimeter if possible Dedicated, high-performance Data Transfer Nodes (DTNs) • Hardware, operating system, libraries all optimized for transfer • Includes optimized data transfer tools such as Globus Online and GridFTP Performance measurement/test node • perfSONAR Details at http://fasterdata.es.net/science-dmz/ Lawrence Berkeley National Laboratory U.S. Department of Energy | Office of Science Overview Part 1: • What is ESnet? • Science DMZ Motivation • Science DMZ Architecture Part 2: • PerfSONAR • The Data Transfer Node • Data Transfer Tools Part 3: • Science DMZ Security Best Practices • Conclusions Lawrence Berkeley National Laboratory U.S. Department of Energy | Office of Science The Energy Sciences Network (ESnet) A Department of Energy Facility Naonal Fiber footprint Distributed Team of 35 Science Data Network Internaonal Collaboraons Mul3ple 10G waves 5 Lawrence Berkeley National Laboratory U.S. Department of Energy | Office of Science ESnetSC Supports Supports Research DOE at More Office than 300 of Institutions Science Across the U.S. Universities DOE laboratories The Office of Science supports: 27,000 Ph.D.s, graduate students, undergraduates, engineers, and technicians 26,000 users of open-access facilities 300 leading academic institutions 17 DOE laboratories 6 Lawrence Berkeley National Laboratory U.S.
    [Show full text]
  • Intrusion Detection Systems (IDS)
    Intrusion Detection Systems (IDS) Adli Wahid Role of Detection in Security • Part of security monitoring o Violation of security policies o Indicators of compromise o Threat drive or Vulnerability driven o What’s happening on the network? • Rules o Detection is based on rules • Action • What do we do when detection happens? • Alert and Investigate • Drop / Block Perspective – Adversary Tactics and Techniques • Mitre Att&ck Framework https://attack.mitre.org • Tactics – what are the goals of the adversary? • Technique – how do they do it? • SubJect to: o Resources o Platforms • Can we used this knowledge for detection? o Observe Adversaries Behaviour o Techniques, Tactics and Procedures (TTPs) o Deploy in prevention, detection, response Your Adversaries Motives Infrastructure Targets Behaviour Your Assets Your Systems Reference: https://published-prd.lanyonevents.com/published/rsaus19/sessionsFiles/13884/AIR-T07-ATT%26CK-in-Practice-A-Primer-to-Improve-Your-Cyber-Defense-FINAL.pdf Reference: https://published-prd.lanyonevents.com/published/rsaus19/sessionsFiles/13884/AIR-T07-ATT%26CK-in-Practice-A-Primer-to-Improve-Your-Cyber-Defense-FINAL.pdf Making Your Infrastructure Forensics Ready • Detecting known or potentially malicious activities • Part of the incident response plan • If your infrastructure is compromised o Can you answer the questions: what happened and since when? o Can we ‘go back in time’ and how far back? • What information you you need to collect and secure? • Centralized logging Intrusion Detection Systems • An intrusion
    [Show full text]
  • Survivor: a Fine-Grained Intrusion Response and Recovery Approach for Commodity Operating Systems
    Survivor: A Fine-Grained Intrusion Response and Recovery Approach for Commodity Operating Systems Ronny Chevalier David Plaquin HP Labs HP Labs CentraleSupélec, Inria, CNRS, IRISA [email protected] [email protected] Chris Dalton Guillaume Hiet HP Labs CentraleSupélec, Inria, CNRS, IRISA [email protected] [email protected] ABSTRACT 1 INTRODUCTION Despite the deployment of preventive security mechanisms to pro- Despite progress in preventive security mechanisms such as cryp- tect the assets and computing platforms of users, intrusions even- tography, secure coding practices, or network security, given time, tually occur. We propose a novel intrusion survivability approach an intrusion will eventually occur. Such a case may happen due to to withstand ongoing intrusions. Our approach relies on an orches- technical reasons (e.g., a misconfiguration, a system not updated, tration of fine-grained recovery and per-service responses (e.g., or an unknown vulnerability) and economic reasons [39] (e.g., do privileges removal). Such an approach may put the system into a the benefits of an intrusion for criminals outweigh their costs?). degraded mode. This degraded mode prevents attackers to reinfect To limit the damage done by security incidents, intrusion re- the system or to achieve their goals if they managed to reinfect covery systems help administrators restore a compromised system it. It maintains the availability of core functions while waiting for into a sane state. Common limitations are that they do not preserve patches to be deployed. We devised a cost-sensitive response se- availability [23, 27, 34] (e.g., they force a system shutdown) or that lection process to ensure that while the service is in a degraded they neither stop intrusions from reoccurring nor withstand re- mode, its core functions are still operating.
    [Show full text]
  • The Samhain Host Integrity Monitoring System the Samhain Host Integrity Monitoring System This Is Version 2.4.3 of the Samhain Manual
    The Samhain Host Integrity Monitoring System The Samhain Host Integrity Monitoring System This is version 2.4.3 of the Samhain manual. Copyright © 2002-2019 Rainer Wichmann Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. You may obtain a copy of the GNU Free Documentation Licensefrom the Free Software Foundation by visiting their Web site or by writing to: Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. This manual refers to version 4.4.0 of Samhain. Table of Contents 1. Introduction .............................................................................................................. 1 1. Backward compatibility ...................................................................................... 1 2. Compiling and installing ............................................................................................. 2 1. Overview ......................................................................................................... 2 2. Requirements .................................................................................................... 3 3. Download and extract ......................................................................................... 3 4. Configuring the source ......................................................................................
    [Show full text]
  • BSD UNIX Toolbox 1000+ Commands for Freebsd, Openbsd
    76034ffirs.qxd:Toolbox 4/2/08 12:50 PM Page iii BSD UNIX® TOOLBOX 1000+ Commands for FreeBSD®, OpenBSD, and NetBSD®Power Users Christopher Negus François Caen 76034ffirs.qxd:Toolbox 4/2/08 12:50 PM Page ii 76034ffirs.qxd:Toolbox 4/2/08 12:50 PM Page i BSD UNIX® TOOLBOX 76034ffirs.qxd:Toolbox 4/2/08 12:50 PM Page ii 76034ffirs.qxd:Toolbox 4/2/08 12:50 PM Page iii BSD UNIX® TOOLBOX 1000+ Commands for FreeBSD®, OpenBSD, and NetBSD®Power Users Christopher Negus François Caen 76034ffirs.qxd:Toolbox 4/2/08 12:50 PM Page iv BSD UNIX® Toolbox: 1000+ Commands for FreeBSD®, OpenBSD, and NetBSD® Power Users Published by Wiley Publishing, Inc. 10475 Crosspoint Boulevard Indianapolis, IN 46256 www.wiley.com Copyright © 2008 by Wiley Publishing, Inc., Indianapolis, Indiana Published simultaneously in Canada ISBN: 978-0-470-37603-4 Manufactured in the United States of America 10 9 8 7 6 5 4 3 2 1 Library of Congress Cataloging-in-Publication Data is available from the publisher. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permis- sion should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4355, or online at http://www.wiley.com/go/permissions.
    [Show full text]
  • Hodetector: the Hidden Objects Detection Based on Static Semantic Information Library Outside Virtual Machine 1393
    HODetector: The Hidden Objects Detection Based on Static Semantic Information Library Outside Virtual Machine 1393 HODetector: The Hidden Objects Detection Based on Static Semantic Information Library Outside Virtual Machine YongGang Li1, 2, ChaoYuan Cui1, BingYu Sun1, WenBo Li3* 1 Institute of Intelligent Machine, Chinese Academy of Sciences, China 2 School of Information Science and Technology, University of Science and Technology of China, China 3 Institute of Technology Innovation, Chinese Academy of Sciences, China [email protected], {cycui, bysun, wbli}@iim.ac.cn Abstract objects for virtual machine security. For virtualization security, the traditional secure With the spread of malwares, the security of virtual tools detecting malwares are placed into the guest VM machine (VM) is suffering severe challenges recent years. (GVM) that may be injected by computer viruses. So, Rootkits and their variants can hide themselves and other it’s possible that the secure tool will be bypassed or kernel objects such as processes, files, and modules cheated. For example, a rootkit named f00lkit can making malicious activity hard to be detected. The bypass Chkrootkit and Rkhunter, the most popular anti- existed solutions are either coarse-grained, monitoring at malwares tools in Linux. Compared with the traditional virtual machine level, or non-universal, only supporting method, one mechanism called out-of-box [3] detecting specific operating system with specific modification. In malwares out of VM is a better way, because the this paper, we propose a fine-grained approach called secure tool is outside any span of malwares. Then HODetector based on static semantic information library another problem appears: semantic gap [4].
    [Show full text]
  • Sureview® Memory Integrity Advanced Linux Memory Analysis Delivers Unparalleled Visibility and Verification
    SureView® Memory Integrity Advanced Linux Memory Analysis Delivers Unparalleled Visibility and Verification Promoting trustworthy and repeatable analysis of volatile system state Benefits Increased Usage of Linux in Forensics Field Guide for Linux Global Enterprises Systems2,” the apparent goal n Enables visibility into the state n Scans thousands of The use of Linux is everywhere of these attackers is to steal all systems with hundreds of of systems software while in the world. Linux is used in types of information. Perhaps of gigabytes of memory executing in memory our stock exchange transactions, greatest concern are the synchro- on Linux systems n Provides a configurable social media, network storage nized, targeted attacks against n Delivers malware detection using scanning engine for automated devices, smartphones, DVR’s, Linux systems. For several years, scans of remote systems an integrity verification approach online purchasing web sites, organized groups of attackers to verify that all systems software throughout an enterprise running is known and unmodified and in the majority of global (a.k.a. threat actors) have been n Incorporates an easy-to- Internet traffic. The Linux infiltrating Linux systems and to quickly identify threats use GUI to quickly assess Foundation’s 2013 Enterprise have been communicating with n Allows the integration and interpret results End User Report indicates that command and control (C2) of memory forensics into n Delivers output in a structured 80% of respondents planned servers and exfiltrating data enterprise security information data format (JSON) to to increase their numbers of from compromised Linux sys- and event management facilitate analytics systems (SIEMS) supporting Linux servers over the next five tems.
    [Show full text]
  • Cloaker: Hardware Supported Rootkit Concealment
    Cloaker: Hardware Supported Rootkit Concealment Francis M. David, Ellick M. Chan, Jeffrey C. Carlyle, Roy H. Campbell Department of Computer Science University of Illinois at Urbana-Champaign 201 N Goodwin Ave, Urbana, IL 61801 {fdavid,emchan,jcarlyle,rhc}@uiuc.edu Abstract signers resorted to more complex techniques such as modi- fying boot sectors [33, 51] and manipulating the in-memory Rootkits are used by malicious attackers who desire to image of the kernel. These rootkits are susceptible to de- run software on a compromised machine without being de- tection by tools that check kernel code and data for alter- tected. They have become stealthier over the years as a ation [43, 13, 42, 21]. Rootkits that modify the system consequence of the ongoing struggle between attackers and BIOS or device firmware [25, 26] can also be detected by system defenders. In order to explore the next step in rootkit integrity checking tools. More recently, virtualization tech- evolution and to build strong defenses, we look at this issue nology has been studied as yet another means to conceal from the point of view of an attacker. We construct Cloaker, rootkits [31, 44]. These rootkits remain hidden by running a proof-of-concept rootkit for the ARM platform that is non- the host OS in a virtual machine environment. To counter persistent and only relies on hardware state modifications the threat from these Virtual Machine Based Rootkits (VM- for concealment and operation. A primary goal in the de- BRs), researchers have detailed approaches to detect if code sign of Cloaker is to not alter any part of the host oper- is executing inside a virtual machine [20].
    [Show full text]
  • A Brief Study and Comparison Of, Open Source Intrusion Detection System Tools
    International Journal of Advanced Computational Engineering and Networking, ISSN: 2320-2106, Volume-1, Issue-10, Dec-2013 A BRIEF STUDY AND COMPARISON OF, OPEN SOURCE INTRUSION DETECTION SYSTEM TOOLS 1SURYA BHAGAVAN AMBATI, 2DEEPTI VIDYARTHI 1,2Defence Institute of Advanced Technology (DU) Pune –411025 Email: [email protected], [email protected] Abstract - As the world becomes more connected to the cyber world, attackers and hackers are becoming increasingly sophisticated to penetrate computer systems and networks. Intrusion Detection System (IDS) plays a vital role in defending a network against intrusion. Many commercial IDSs are available in marketplace but with high cost. At the same time open source IDSs are also available with continuous support and upgradation from large user community. Each of these IDSs adopts a different approaches thus may target different applications. This paper provides a quick review of six Open Source IDS tools so that one can choose the appropriate Open Source IDS tool as per their organization requirements. Keywords - Intrusion Detection, Open Source IDS, Network Securit, HIDS, NIDS. I. INTRODUCTION concentrate on the activities in a host without considering the activities in the computer networks. Every day, intruders are invading countless homes On the other hand, NIDS put its focus on computer and organisations across the country via virus, networks without examining the hosts’ activities. worms, Trojans, DoS/DDoS attacks by inserting bits Intrusion Detection methodologies can be classified of malicious code. Intrusion detection system tools as Signature based detection, Anomaly based helps in protecting computer and network from a detection and Stateful Protocol analysis based numerous threats and attacks.
    [Show full text]
  • Ten Strategies of a World-Class Cybersecurity Operations Center Conveys MITRE’S Expertise on Accumulated Expertise on Enterprise-Grade Computer Network Defense
    Bleed rule--remove from file Bleed rule--remove from file MITRE’s accumulated Ten Strategies of a World-Class Cybersecurity Operations Center conveys MITRE’s expertise on accumulated expertise on enterprise-grade computer network defense. It covers ten key qualities enterprise- grade of leading Cybersecurity Operations Centers (CSOCs), ranging from their structure and organization, computer MITRE network to processes that best enable effective and efficient operations, to approaches that extract maximum defense Ten Strategies of a World-Class value from CSOC technology investments. This book offers perspective and context for key decision Cybersecurity Operations Center points in structuring a CSOC and shows how to: • Find the right size and structure for the CSOC team Cybersecurity Operations Center a World-Class of Strategies Ten The MITRE Corporation is • Achieve effective placement within a larger organization that a not-for-profit organization enables CSOC operations that operates federally funded • Attract, retain, and grow the right staff and skills research and development • Prepare the CSOC team, technologies, and processes for agile, centers (FFRDCs). FFRDCs threat-based response are unique organizations that • Architect for large-scale data collection and analysis with a assist the U.S. government with limited budget scientific research and analysis, • Prioritize sensor placement and data feed choices across development and acquisition, enteprise systems, enclaves, networks, and perimeters and systems engineering and integration. We’re proud to have If you manage, work in, or are standing up a CSOC, this book is for you. served the public interest for It is also available on MITRE’s website, www.mitre.org. more than 50 years.
    [Show full text]