On the Feasibility of Online Malware Detection with Performance Counters

Total Page:16

File Type:pdf, Size:1020Kb

On the Feasibility of Online Malware Detection with Performance Counters On the Feasibility of Online Malware Detection with Performance Counters John Demme Matthew Maycock Jared Schmitz Adrian Tang Adam Waksman Simha Sethumadhavan Salvatore Stolfo Department of Computer Science, Columbia University, NY, NY 10027 [email protected], [email protected], fjared,atang,waksman,simha,[email protected] ABSTRACT 1. INTRODUCTION The proliferation of computers in any domain is followed by Malware { short for malicious software { is everywhere. the proliferation of malware in that domain. Systems, in- In various forms for a variety of incentives, malware exists cluding the latest mobile platforms, are laden with viruses, on desktop PCs, server systems and even mobile devices like rootkits, spyware, adware and other classes of malware. De- smart phones and tablets. Some malware litter devices with spite the existence of anti-virus software, malware threats unwanted advertisements, creating ad revenue for the mal- persist and are growing as there exist a myriad of ways to ware creator. Others can dial and text so-called \premium" subvert anti-virus (AV) software. In fact, attackers today services resulting in extra phone bill charges. Some other exploit bugs in the AV software to break into systems. malware is even more insidious, hiding itself (via rootkits or In this paper, we examine the feasibility of building a mal- background processes) and collecting private data like GPS ware detector in hardware using existing performance coun- location or confidential documents. ters. We find that data from performance counters can be This scourge of malware persists despite the existence of used to identify malware and that our detection techniques many forms of protection software, antivirus (AV) software are robust to minor variations in malware programs. As a being the best example. Although AV software decreases result, after examining a small set of variations within a fam- the threat of malware, it has some failings. First, because ily of malware on Android ARM and Intel Linux platforms, the AV system is itself software, it is vulnerable to attack. we can detect many variations within that family. Further, Bugs or oversights in the AV software or underlying system our proposed hardware modifications allow the malware de- software (e.g., the operating system or hypervisor) can be tector to run securely beneath the system software, thus exploited to disable AV protection. Second, production AV setting the stage for AV implementations that are simpler software typically use static characteristics of malware such and less buggy than software AV. Combined, the robustness as suspicious strings of instructions in the binary to detect and security of hardware AV techniques have the potential threats. Unfortunately, it is quite easy for malware writers to advance state-of-the-art online malware detection. to produce many different code variants that are functionally equivalent, both manually and automatically, thus defeating Categories and Subject Descriptors static analysis easily. For instance, one malware family in C.0 [Computer Systems Organization]: General|Hard- our data set, AnserverBot, had 187 code variations. Alterna- ware/software interfaces; K.6.5 [Management of Com- tives to static AV scanning require extremely sophisticated puting and Information Systems]: Security and Pro- dynamic analysis, often at the cost of significant overhead. tection|Invasive software Given the shortcomings of static analysis via software im- plementations, we propose hardware modifications to sup- General Terms port secure efficient dynamic analysis of programs to detect Security in Hardware, Malware and its Mitigation malware. This approach potentially solves both problems. First, by executing AV protection in secure hardware (with Keywords minimum reliance on system software), we significantly re- Malware detection, machine learning, performance counters duce the possibility of malware subverting the protection mechanisms. Second, we posit that dynamic analysis makes 1 detection of new, undiscovered malware variants easier. The This work was supported by grants FA 99500910389 (AFOSR), FA 865011C7190 (DARPA), FA 87501020253 (DARPA), CCF/TC intuition is as follows: we assume that all malware within a 1054844 (NSF), Alfred P. Sloan fellowship, and gifts from Microsoft certain family of malware, regardless of the code variant, at- Research, WindRiver Corp, Xilinx and Synopsys Inc. Any opinions, tempts to do similar things. For instance, they may all pop findings, conclusions and recommendations do not reflect the views of the US Government or commercial entities. up ads, or they may all take GPS readings. As a result, we would expect them to work through a similar set of program Permission to make digital or hard copies of all or part of this work for phases, which tend to exhibit similar detectable properties personal or classroom use is granted without fee provided that copies are in the form of performance data (e.g., IPC, cache behavior). not made or distributed for profit or commercial advantage and that copies In this paper, we pose and answer the following central bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific feasibility question: Can dynamic performance data be used permission and/or a fee. to characterize and detect malware? We collect longitudi- ISCA ’13 Tel-Aviv, Israel nal, fine-grained microarchitectural traces of recent mobile Copyright 2013 ACM 978-1-4503-2079-5/13/06 ...$15.00. 559 AnserverBot Android malware and Linux rootkits on ARM and Intel plat- DroidKungFu forms respectively. We then apply standard machine learn- ing classification algorithms such as KNN or Decision Trees Coarse-Grained: Dynamic traces to detect variants of known malware. Our results indicate Suspicious Programs Signature that relatively simple classification algorithms can detect Honey Pot Current Generation malware at nearly 90% accuracy with 3% false positives for Fine-Grained: (μ)-arch execution some mobile malware. New Zitmo profiles Plankton Signatures We also describe hardware support necessary to enable Proposed online malware detection in hardware. We propose methods ANALYST Behavioral Analysis and techniques for (1) collection of fine-grained runtime data Internet without slowing down applications, (2) secure execution of USER AV algorithms to detect at runtime the execution of malware and (3) secure updating of the AV algorithms to prevent Internet (Filled With subversion of the protection scheme. Malware) Signatures, Coarse Fine Classifiers Another important contribution of the paper is to describe Grained: Grained: Call & File (μ)-arch Profile the experimental framework for research in the new area of Analysis Analysis hardware malware detection. Towards this we provide a dataset used in this research. This dataset can be down- Alerts (Current) Alerts (Proposed) loaded from: http://castl.cs.columbia.edu/colmalset. The rest of the paper is organized as follows. In Section 2 Figure 1: AV signature creation and deployment. we provide background on malware, then describe the key intuition behind our approach (Section 3), and explain our experimental method (Section 4), followed by evaluations of tion, users anonymously send cryptographic signatures of Android ARM malware, x86 Linux Rootkits and side chan- executables to the AV vendor. The AV vendor then deter- nels (Sections 5, 6, 7). We describe hardware support in mines how often an executable occurs in a large population Section 8 and our conclusions in Section 9. of its users to predict if an executable is malware: often, un- common executable signatures occurring in small numbers 2. BACKGROUND ON MALWARE are tagged as malware. This system is reported to be effec- tive against polymorphic and metamorphic viruses but does In this section, we provide an abbreviated and fairly in- not work against non-executable threats such as malicious formal introduction on malware. pdfs and doc files [8]. Further it requires users to reveal 2.1 What is Malware and Who Creates It? programs installed on their machine to the AV vendor and trust the AV vendor not to share this secret. Malware is software created by an attacker to compro- mise security of a system or privacy of a victim. A list of 2.3 How Good is Anti-Virus Software? different types of malware is listed in Table 1. Initially cre- Just like any other large piece of software, AV systems ated to attain notoriety or for fun, malware development tend to have bugs that are easily exploited, and thus AV today is mostly motivated by financial gains [1, 2]. There are reports of active underground markets for personal in- formation, credit cards, logins into sensitive machines in the United States, etc. [3]. Also, government-funded agencies Table 1: Categories of Malware (allegedly) have created sophisticated malware that target Malware Brief Description specific computers for espionage or sabotage [4, 5, 6]. Mal- Worm Malware that propagates itself from one infected host to other hosts via exploits in the OS interfaces ware can be delivered in a number of ways. To list a few, an typically the system-call interface. unsuspecting user can be tricked into: clicking on links in Virus Malware that attaches itself to running programs \phishing" emails that download and install malware, open- and spreads itself through users' interactions with various systems. ing email attachments with malicious pdfs or document files, Polymorphic A virus that,
Recommended publications
  • 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]
  • Detecting Kernel Rootkits
    Dartmouth College Dartmouth Digital Commons Computer Science Technical Reports Computer Science 9-2-2008 Detecting kernel rootkits Ashwin Ramaswamy Dartmouth College Follow this and additional works at: https://digitalcommons.dartmouth.edu/cs_tr Part of the Computer Sciences Commons Dartmouth Digital Commons Citation Ramaswamy, Ashwin, "Detecting kernel rootkits" (2008). Computer Science Technical Report TR2008-627. https://digitalcommons.dartmouth.edu/cs_tr/314 This Technical Report is brought to you for free and open access by the Computer Science at Dartmouth Digital Commons. It has been accepted for inclusion in Computer Science Technical Reports by an authorized administrator of Dartmouth Digital Commons. For more information, please contact [email protected]. Detecting kernel rootkits Ashwin Ramaswamy Department of Computer Science Dartmouth College Masters Thesis Proposal Dartmouth Computer Science Technical Report TR2008-627 Proposal Presentation Date: 2 September, 2008 Abstract Kernel rootkits are a special category of malware that are deployed directly in the kernel and hence have unmitigated reign over the functionalities of the kernel itself. We seek to detect such rootkits that are deployed in the real world by first observing how the majority of kernel rootkits operate. To this end, comparable to how rootkits function in the real world, we write our own kernel rootkit that manipulates the network driver, thus giving us control over all packets sent into the network. We then implement a mechanism to thwart the attacks of such rootkits by noticing that a large number of the rootkits deployed today rely heavily on the redirection of function pointers within the kernel. By overwriting the desired function pointer to its own function, a rootkit can perform a proverbial man-in-the-middle attack.
    [Show full text]
  • Unix/Mac/Linux OS Malware 10/15/2020
    Unix/Mac/Linux OS Malware 10/15/2020 Report #: 202010151030 Agenda • Executive Summary • Origin of Modern Operating Systems • Overview of Operating Systems o Desktop o Servers o Super Computers o Mobile o Attack Surface and CVEs • Malware Case Studies o Drovorub o Hidden Wasp o Operation Windigo o MAC Malware Slides Key: • Defending Against Malware The picture can't be displayed. Non-Technical: Managerial, strategic and high- • Summary level (general audience) The picture can't be displayed. Technical: Tactical / IOCs; requiring in-depth knowledge (system admins, IRT) TLP: WHITE, ID# 202010151030 2 Executive Summary • Unix and Unix-like systems drive most of today's computer systems. • Vulnerabilities and malware • Threat mitigation o Comprehensive security policies o Access control o Regular updates and backups o Training employees o Improving posture and maturity TLP: WHITE, ID# 202010151030 3 Modern Operating Systems "Determining the operating system on which the server runs is the most important part of hacking. Mostly, hacking is breaking into the target's system to steal data or any such purpose. Hence, the security of the system becomes the thing of prime importance." Source: Parikh, K. (2020, August) The Hackers Library Functions of Operating Systems Timeline of the Origins of Operating Systems TLP: WHITE, ID# 202010151030 4 Overview of Operating Systems (Non-Mobile) Unix Chrome OS •Derived from Original AT&T Unix •Free and open-source •Command-line input •Graphical user interface •Very popular among scientific, •Based on Linux
    [Show full text]
  • Academic Linux Kernel Module Rootkit — Final Year Engineering Project
    Academic Linux Kernel Module Rootkit — Final Year Engineering Project AUTHOR TUTOR Victor Ruben Lacort Pellicer Julio Hernandez-Castro University of Valencia University of Portsmouth May 7, 2010 ii Contents Abstract 1 I Overview 3 1 Introduction 5 1.1 Overview . .5 1.1.1 Problem statement . .6 1.1.2 Project aims . .6 1.1.3 Project constraints . .7 1.1.4 Project deliverables . .8 iii iv CONTENTS 1.2 Literature review . .9 1.3 Report structure . 11 2 Rootkits 13 2.1 Backdoors . 14 2.2 Taxonomy of UNIX Rootkits . 16 2.2.1 User-mode Rootkits: Toolkit . 16 2.2.2 Kernel-mode Rootkits . 17 2.3 Well-known Rootkits . 19 2.4 Countermeasures . 20 2.4.1 Kernel without Dynamic Module support . 21 2.4.2 Admin Tools: chrootkit & rkhunter . 22 3 How to build an evil LKM 25 3.1 Structure of a LKM . 26 CONTENTS v 3.2 Compiling modules . 27 3.3 User Mode and Kernel Mode . 28 3.3.1 System Calls . 29 3.3.2 printk() function . 30 3.4 Hacking system calls . 31 3.4.1 Risks of hacking sys_call_table .............. 34 3.4.2 Kernel version 2.4 . 35 3.4.3 Kernel version 2.6 . 37 II Design 41 4 Project Methodology 43 4.1 Available methodologies . 44 4.1.1 Waterfall Model . 44 4.1.2 Prototyping Model . 45 vi CONTENTS 4.1.3 Spiral Model . 46 4.1.4 Incremental Model . 47 4.1.5 Component Assembly Model . 48 4.2 Selected model . 48 5 Requirement analysis 49 5.1 Ubuntu 9.10 .
    [Show full text]
  • Designing a New Infrastructure for ATLAS Online Web Services
    EPJ Web of Conferences 245, 07030 (2020) https://doi.org/10.1051/epjconf/202024507030 CHEP 2019 Designing a New Infrastructure for ATLAS Online Web Ser- vices Sergio Ballestrero1, Franco Brasolin2, Arturo Sanchez Pineda3, Diana Alessandra Scannicchio4;∗, and Matthew Shaun Twomey5 1University of Johannesburg, South Africa 2Istituto Nazionale di Fisica Nucleare Sezione di Bologna, Italy 3INFN Gruppo Collegato di Udine and Università di Udine, Italy 4University of California Irvine, United States of America 5University of Washington, United States of America Abstract. Within the ATLAS detector, the Trigger and Data Acquisition system is responsible for the online processing of data streamed from the detector dur- ing collisions at the Large Hadron Collider (LHC) at CERN. The online farm is composed of ∼4000 servers processing the data read out from ∼100 million detector channels through multiple trigger levels. The capability to monitor the ongoing data taking and all the involved applications is essential to debug and intervene promptly to ensure efficient data taking. The base of the current web service architecture was designed a few years ago, at the beginning of the AT- LAS operation (Run 1). It was intended to serve primarily static content from a Network-attached Storage, and privileging strict security, using separate web servers for internal (ATLAS Technical and Control Network - ATCN) and exter- nal (CERN General Purpose Network and public internet) access. During these years, it has become necessary to add to the static content an increasing number of dynamic web-based User Interfaces, as they provided new functionalities and replaced legacy desktop UIs. These are typically served by applications on VMs inside ATCN and made accessible externally via chained reverse HTTP proxies.
    [Show full text]
  • [ Rootkit Hunter Version 1.3.4 ] Checking Rkhunter Data Files
    [ Rootkit Hunter version 1.3.4 ] Checking rkhunter data files... Checking file mirrors.dat [ No update ] Checking file programs_bad.dat [ No update ] Checking file backdoorports.dat [ No update ] Checking file suspscan.dat [ No update ] Checking file i18n/cn [ No update ] Checking file i18n/de [ No update ] Checking file i18n/en [ No update ] Checking file i18n/zh [ No update ] Checking file i18n/zh.utf8 [ No update ] [ Rootkit Hunter version 1.3.4 ] File updated: searched for 151 files, found 122 Checking system commands... Performing 'strings' command checks Checking 'strings' command [ OK ] Performing 'shared libraries' checks Checking for preloading variables [ None found ] Checking for preload file [ Not found ] Checking LD_LIBRARY_PATH variable [ Not found ] Performing file properties checks Checking for prerequisites [ OK ] /bin/awk [ OK ] /bin/basename [ OK ] /bin/bash [ OK ] /bin/cat [ OK ] /bin/chmod [ OK ] /bin/chown [ OK ] /bin/cp [ OK ] /bin/csh [ OK ] /bin/cut [ OK ] /bin/date [ OK ] /bin/df [ OK ] /bin/dmesg [ OK ] /bin/echo [ OK ] /bin/ed [ OK ] /bin/egrep [ OK ] /bin/env [ OK ] /bin/fgrep [ OK ] /bin/grep [ OK ] /bin/kill [ OK ] /bin/login [ OK ] /bin/ls [ OK ] /bin/mail [ OK ] /bin/mktemp [ OK ] /bin/more [ OK ] /bin/mount [ OK ] /bin/mv [ OK ] /bin/netstat [ OK ] /bin/ps [ OK ] /bin/pwd [ OK ] /bin/rpm [ OK ] /bin/sed [ OK ] /bin/sh [ OK ] /bin/sort [ OK ] /bin/su [ OK ] /bin/touch [ OK ] /bin/uname [ OK ] /bin/gawk [ OK ] /bin/tcsh [ OK ] /bin/true [ OK ] /usr/bin/awk [ OK ] /usr/bin/chattr [ OK ] /usr/bin/curl [ OK
    [Show full text]
  • SFL-ED01-Ossec-The-Quick-And-Dirty
    OSSec howto – The quick and dirty way Savoir-faire Linux – SFL-ED01 TABLE OF CONTENT PREFACE..................................................................................................................................................................... 4 About the Author............................................................................................................................................... 4 About Savoir-faire Linux.................................................................................................................................... 4 Credits.................................................................................................................................................................. 5 1 INTRODUCTION.................................................................................................................................................... 8 1.1 If you are in a hurry, and be on track........................................................................................................9 2 FIRST STANDALONE INSTALLATION.............................................................................................................12 2.1 Installation.................................................................................................................................................. 12 2.1.1 Package installation....................................................................................................................................12 2.1.2 Manual installation......................................................................................................................................13
    [Show full text]
  • Malware Forensics Field Guide for Linux Systems: Digital Forensics
    Chapter 3 Postmortem Forensics Discovering and Extracting Malware and Associated Artifacts from Linux Systems Solutions in this Chapter • Linux Forensic Analysis Overview • Malware Discovery and Extraction from a Linux System • Examine Linux File System • Examine Linux Configuration Files • Keyword Searching • Forensic Reconstruction of Compromised Linux Systems • Advanced Malware Discovery and Extraction from a Linux System INTRODUCTION If live system analysis can be considered surgery, forensic examination of Linux systems can be considered an autopsy of a computer impacted by mal- ware. Trace evidence relating to a particular piece of malware may be found in various locations on the hard drive of a compromised host, including files, configuration entries, records in system logs, and associated date stamps. Foren- sic examination of such trace evidence on a Linux system is an important part of analyzing malicious code, providing context and additional information that help us address important questions about a malware incident, including how malware was placed on the system, what it did, and what remote systems were involved. This chapter provides a repeatable approach to conducting forensic examinations in malware incidents, increasing the consistency across mul- tiple computers, and enabling others to evaluate the process and results. Employing this approach, with a measure of critical thinking on the part of a digital investigator, can uncover information necessary to discover how malware was placed on the system (a.k.a. the intrusion vector), to determine Malware Forensics Field Guide for Linux Systems. http://dx.doi.org/10.1016/B978-1-59749-470-0.00003-6 Copyright © 2014 Elsevier Inc. All rights reserved.
    [Show full text]
  • Geek Guide > Self-Audit
    GEEK GUIDE SELF-AUDIT: CHECKING ASSUMPTIONS AT THE DOOR Table of Contents About the Sponsor .......................................................... 4 Introduction .................................................................... 5 Two Steps Necessary for Security ................................. 7 Verify Configurations ...................................................... 9 Assume Security Has Been Compromised .................. 10 Tools to Scan for Malware ............................................ 11 rkhunter �������������������������������������������������������������������������������������������������12 chkrootkit ����������������������������������������������������������������������������������������������13 LMD�������������������������������������������������������������������������������������������������������14 lynis �������������������������������������������������������������������������������������������������������19 Checking for Stealth Ports ........................................... 22 lsof ��������������������������������������������������������������������������������������������������������23 unhide ���������������������������������������������������������������������������������������������������24 Rootkits ......................................................................... 25 Conclusion .................................................................... 27 GREG BLEDSOE is VP of Operations at Personal, Inc. (http://www.personal.com). He is CEH and CPT certified and has 20 years of hard-fought experience
    [Show full text]
  • How to Securely Isolate and Execute Lynis from Kali Linux
    How to securely isolate and execute Lynis from Kali Linux Version 0.1, Last Updated: 11 Oct 2020 Table of Contents 1. Introduction . 1 2. Requirements. 3 2.1. Writing Conventions . 3 2.2. VirtualBox . 3 2.2.1. Clean VirtualBox Networking. 3 2.2.2. Add VirtualBox Networking . 4 2.3. Vagrant. 5 2.4. Kali Linux and Damn Vulnerable Web Application (DVWA) . 5 2.4.1. Vagrantfile . 5 2.4.2. bootstrap.sh . 8 3. Lynis. 12 3.1. Lynis output on Kali Linux VM . 14 3.2. Lynis Output on RHEL 7 VM . 25 3.3. Running Lynis on a Remote Server . 35 4. Conclusion . 36 5. Appendix . 37 1. Introduction The motivation behind this paper is to explore using the tool Lynis that comes with Kali Linux. What is this tool: "Lynis is an open source security auditing tool. Its main goal is to audit and harden Unix and Linux based systems. It scans the system by performing many security control checks. Examples include searching for installed software and determine possible configuration flaws. Many tests are part of common security guidelines and standards, with on top additional security tests. After the scan a report will be displayed with all discovered findings. To provide you with initial guidance, a link is shared to the related Lynis control." source: Kali Linux "Since Lynis is flexible, it is used for several different purposes. Typical use cases for Lynis include: - Security auditing - Compliance testing (e.g. PCI, HIPAA, SOx) - Penetration testing - Vulnerability detection - System hardening " source: Lynis What does Lynus run on? "Lynis runs on almost all UNIX-based systems and versions, including: - AIX - FreeBSD - HP-UX - Linux - macOS - NetBSD - NixOS - OpenBSD - Solaris - and others It even runs on systems like the Raspberry Pi, IoT devices, and QNAP storage devices." source: Lynis "Lynis scanning is modular and opportunistic.
    [Show full text]
  • Understanding and Preventing Common Attacks Romain Wartel 7Th March 2010, ISGC Security Workshop, Taiwan
    WLCG Group Understanding and preventing common attacks Romain Wartel 7th March 2010, ISGC Security Workshop, Taiwan. 1 Overview Underground market • The main motive behind most security attacks: money. 3 Exposure and motivation • Grids are valuable to attackers – Large numbers of distributed hosts – High availability – High throughput network • Grids are also particularly exposed – Transparent access/attack propagation from one site to another – Large number of identical hosts – Heterogeneous skills, staffing and security standards 4 Incidents in the grid • Security incidents affecting WLCG sites: 15 11 8 4 0 2004 2005 2006 2007 2008 2009 • All these incidents are standard site security issues – Several could have been avoided 5 How do attacks happen? What can be done to prevent them? Typical incident • Gain local access – Stolen account – Web application vulnerability – Design errors (incorrect AFS ACL, password on CVS) – Poor password choice – etc. • Attempt to obtain root privileges – Use a (or wait for a new) “local root exploit vulnerability” – Exploit the system, gain root access – Game over. • Maintain access with a rootkit, harvest credentials • Use new harvested credentials against further hosts • Go to step 1 7 Most common cause of incidents • Security incidents are often caused by: – Failure to apply security patches provided by vendors – Security vulnerabilities on exposed services – Poor access control management (ex: root password)‏ – Incidents at other sites – Unresolved past security incidents (lack of traceability)‏ –
    [Show full text]
  • DCS-04 APPLICATION CYBER SECURITY Unit-1 Desktop
    DIPLOMA IN CYBER SECURITY DCS-04 APPLICATION CYBER SECURITY BLOCK SYSTEM SECURITY 1 Unit-1 Desktop Security Unit-2 Programming Bugs and Malicious Codes Unit-3 Database Security Unit-4 Operating System Security Odisha State Open University Page 1 EXPERT COMMITTEE Dr. P.K. Behera (Chairman) Reader in Computer Science Utkal University Bhubaneswar, Odisha Dr. J.R. Mohanty (Member) Professor and HOD KIIT University Bhubaneswar, Odisha Sri Pabitrananda Pattnaik (Member) Scientist-E, NIC Bhubaneswar, Odisha Sri Malaya Kumar Das (Member) Scientist-E, NIC Bhubaneswar, Odisha Dr. Bhagirathi Nayak (Member) Professor and Head (IT & System) Sri Sri University Bhubaneswar,Odisha Dr. Manoranjan Pradhan (Member) Professor and Head (IT & System) G.I.T.A Bhubaneswar, Odisha Sri Chandrakant Mallick (Convener) Consultant DIPLOMA (Academic) IN CYBER SECURITY School of Computer and Information Science Odisha State Open University Sambalpur, Odisha DIPLOMA IN CYBER SECURITY Course Writer Course Writer Chandrakant Mallick Bijay Kumar Paikray Consultant (Academic) Lecturer, School of Computer School of Computer and Science and Engineering, Information Science Centurion University of Odisha State Open Technology and University, Sambalpur Management, Odisha Odisha State Open University Page 2 UNIT-1 DESKTOP SECURITY Unit Structure 1.0 Introduction 1.1 Learning Objectives 1.2 Overview of Computer Security 1.3 What is a Desktop Computer? 1.4 Why Desktops need to be secured? 1.5 What do you mean by securing desktops? 1.6 Desktop Security Policies 1.7 Best Practices for Desktop Security 1.7.1 Basic Steps to ensure Desktop Security 1.7.2 Patching the Operating System 1.7.3 Patching Applications and Software 1.7.4 Steps for basic Linux Desktop Security 1.8 Password Policies 1.8.1 Characteristics of Weak Password 1.8.2 Characteristics of Strong Password 1.9 Let us Sum-up 1.10 Self-assessment Questions 1.11 References and Further Readings Odisha State Open University Page 3 1.0 Introduction Use of desktop still dominates the other computing devices in many organizations.
    [Show full text]