Malware, Malicious Tools, and Tools

Slides:



Advertisements
Similar presentations
Decision Structures - If / Else If / Else. Decisions Often we need to make decisions based on information that we receive. Often we need to make decisions.
Advertisements

Chapter 7 Designing Classes. Class Design When we are developing a piece of software, we want to design the software We don’t want to just sit down and.
Use Cases Use Cases are employed to describe the functionality or behavior of a system. Each use case describes a different capability that the system.
Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Requirement Engineering Virtusa Training Group 2004 Trainer: Ojitha Kumanayaka Duration : 1 hour.
Objects – State u There are only two things we can do to an object u Inspect it’s state u Alter it’s state u This is a profound statement! u If you think.
Basic Scheme February 8, 2007 Compound expressions Rules of evaluation Creating procedures by capturing common patterns.
How-to Build In-Banner Lead Forms Website: | | Phone:
Rootkits Jonathan Barella Chad Petersen. Overview What are rootkits How do rootkits work How to detect rootkits How to remove rootkits.
George Wang, Ph.D. COMP 380/L Lesson 2. Use Case Use cases are a way to capture system functionalities (i.e., functional requirements) Based on use case.
A Method for Improving Code Reuse System Prasanthi.S.
1 © 2017 Pearson Education, Inc. Hoboken, NJ. All rights reserved. for-each PROS easy to use access to ALL items one-by-one ability to change the state.
VAdata Tools VAdata: Virginia’s Sexual and Domestic Violence Data Collection System.
JavaScript Controlling the flow of your programs with ‘if’ statements
Edward De Valle Exciting Internet Marketing Ideas That Anyone Can Use
Finding Magazine & Newspaper Articles in a Library Database
for-each PROS CONS easy to use access to ALL items one-by-one
Modularity Most useful abstractions an OS wants to offer can’t be directly realized by hardware Modularity is one technique the OS uses to provide better.
Finding Scholarly Articles in a Library Database
Basic Scheme February 8, 2007 Compound expressions Rules of evaluation
C. What is a Feasibility report
Working with Java.
Firewall Configuration and Administration
Security SIG in MTS 05th November 2013 DEG/MTS RISK-BASED SECURITY TESTING Fraunhofer FOKUS.
Theodore Lawson CSCE548 Student Presentation, Topic #2
Short & Simple • © 2017 Thinkshortcut Publishing, LLC • Created by MarketingZoo.com Clogged Drain Dramas It sits in the center of every sink, at the end.
Harvesting Runtime Values in Android Applications That Feature Anti-Analysis Techniques Presented by Vikraman Mohan.
SafeHome Product.
IF statements.
CPSC 315 – Programming Studio Spring 2012
Lecture 25 More Synchronized Data and Producer/Consumer Relationship
Big-Data Fundamentals
Interested in our Clinical Encounters: Pain?
Good and Bad Data Visualizations
Auburn University COMP 2710 Software Construction Use Case Analysis and Exercises (Part 2) Dr. Xiao Qin Auburn University.
Evaluating a Real-time Anomaly-based IDS
A Trojan is a computer program that contains the malicious code and it misleads users and user's computer. It aims to designed to perform something is.
Control Structures.
Introduction To Robot Decision Making
Analyzing WebView Vulnerabilities in Android Applications
LESSON 11 – WHILE LOOPS UNIT 5 – 1/10/17.
Step-By-Step Instructions for Miniproject 2
The Object-Oriented Thought Process Chapter 05
CSCI 1260 – Lecture 2: Instantiation, Aggregation, and Composition
Portability CPSC 315 – Programming Studio
Social Media and Networking for a University
Learning to Program in Python
Use Cases.
BMC TrueSight Capacity Optimization (BCO)
Attributes of Information
The Decision Making Process
CTI Specification Organization
Program Evaluation, Archival Research, and Meta-Analytic Designs
Conditional Logic Presentation Name Course Name
State Design Pattern Brandon Jacobsen.
Programming with Alice
Spreadsheets, Modelling & Databases
Chapter 4: Boolean Expressions, Making Decisions, and Disk Input and Output Prof. Salim Arfaoui.
Performance Metric Achievement Log
Applying Use Cases (Chapters 25,26)
Software Requirement and Specification
Applying Use Cases (Chapters 25,26)
Software Security Slide Set #10 Textbook Chapter 11 Clicker Questions
Testing Electronic Health Records Applications with a Security Test Pattern Developed Using Empirical Data Ben Smith Motivation Knowledge gap in software.
Selection Statements Chapter 3.
Career Decision Arguments
Introduction to the Lab
Botnets and Remote Administration Tools
Reading and effective note-making
Types of Software Testing Course. CONTENT  Black-box testing course  White-box software testing course  Automated software testing course  Regression.
Presentation transcript:

Malware, Malicious Tools, and Tools

Option 1: Weapon + Tool TLO (“Weapon”) is defined to capture information about weaponized tools: malware, tools that are always/nearly always malicious, and tools used maliciously. Potentially, a flag indicates whether the item is malware. Or, maybe it doesn’t matter. TLO (“Tool”) is defined to capture information about non-malicious tools. This would be used to capture “target” information, ???

Option 2: Malware + (Tool + Relationship) TLO (“Malware”) is defined to capture information about malware (malicious software executed without the user’s intent) TLO (“Tool”) is defined to capture information about all other tools (software?). Relationships are used to indicate whether the tool is a target of an attack or is being used maliciously itself

Option 3: Malware + (Tool + Flag) TLO (“Malware”) is defined to capture information about malware (malicious software executed without the user’s intent) TLO (“Tool”) is defined to capture information about all other tools (software?). A boolean flag on tool indicates whether the TLO represents that tool being used maliciously or benignly (in addition to relationships, if any)

Scenario: Simple Indicator for Malware 1 2 3 Indicator Indicator Indicator indicates indicates indicates Weapon Title = CryptoWall [Malware = True] Malware Title = CryptoWall Malware Title = CryptoWall

Scenario: Simple Indicator for Tool 1 2 3 Indicator Indicator Indicator indicates indicates indicates Weapon Title = nmap [Malware = False] Tool Title = nmap Tool Title = nmap Used Maliciously = True uses Campaign, Actor, Attack Pattern, etc.

Scenario: Tool as Target 1 2 3 Campaign Campaign Campaign targets targets targets Tool Title = IE8 Tool Title = IE8 Tool Title = IE8 Used Maliciously = False

Option 1: Evaluation PRO CON Doesn’t require deciding whether something used maliciously is malware or a malicious tool There’s a single TLO specifically for malicious code, no interpretation required CON No TLO for “Malware”, so people* would have to understand that malware is represented as a malicious tool Flag approach is perhaps not as clean. Might be a cop out to just adding a different TLO. Fields to describe malware might be different from fields to describe malicious tools * People = developers and/or users, depending on how good tools are at abstracting away the decision

Option 2: Evaluation PRO CON Has a malware TLO, so is very easy for people to tackle that common use case Theoretically cleaner, absent of any boolean flags (which sometimes feel like an anti-pattern) CON People* need to understand (and correctly indicate) the distinction between malware and malicious tools Though, with the flag approach in option 1, they do as well. Requires using relationships to indicate whether something is malicious, which might be limiting depending on what people want to share and are able to represent Fields to describe malicious tools may be different from fields to describe normal tools * People = developers and/or users, depending on how good tools are at abstracting away the decision

Option 3: Evaluation PRO CON Has a malware TLO, so is very easy for people to understand how to tackle that common use case Still possible to indicate from just the TLO whether a tool is malicious, no relationships required CON People* need to understand (and correctly indicate) the distinction between malware and malicious tools Though, with the flag approach in option 1, they do as well. Flag approach is perhaps not as clean. Might be a cop out to just adding a different TLO. Fields to describe malicious tools may be different from fields to describe normal tools * People = developers and/or users, depending on how good tools are at abstracting away the decision

Other thoughts What are the use cases for representing non-malicious tool usage? Target seems like an obvious one: attacks often target particular software Do we fully understand this use case? How does it fit in with the Vulnerability object? Could it be more easily captured some other way to remove the need to capture benign tools? Are the fields to support this use case different than the fields to support malicious tools? Information source is another (User agent, essentially) Is this MVP? Could it just be a text string in some other object?

Other thoughts Implementations can hide things from the user I.e. if we have a “malicious-tool” TLO and they mostly do malware, they just call it malware and always set malware=true So our decisions should be based on enabling tools to make those types of decisions, and making sure busy developers can find things (not users) The difference between a boolean flag and a separate TLO is minor in some ways Separate TLO basically just allows us to have separate fields and relationships Boolean flag still requires you to make the decision just as much as a separate TLO does