Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

CISSP > CISSP Domain 8 - Flashcards > Flashcards

CISSP Domain 8 - Flashcards

1
Q

Defining Good Code - Quality

A
  • How fit for a purpose something is
  • When developing software: It’s usually thought of after the fact
  • Keys to ensuring quality:
  • Code Reviews
  • Interface Testing
  • Misuse cases
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Defining Good Code - Software Controls

A

To address input, output, encryption, logical flow, methods for performing calculations, interprocess communication, access, and interaction with other software

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Defining Good Code - Security Controls

A
  • Usually technical
  • Will depend on:
  • Application’s purpose
  • Environment in which it will run
  • Sensitivity of the data it will process
  • Functionality it will execute
  • Security policy attached to it
  • Example: If software will only be run behind 3 firewalls and accessible only by an administrator, it will have fewer security requirements. If it is a publicly-accessible web application it will be subject to quite a few very restrictive security controls
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Where Do We Place Security? - Introduction

A
  • Software is responsible for the vast majority of vulnerabilities
  • The importance of implementing proper security in software is a relatively new focus
  • It is very uncommon to find a software developer who is also a security professional
  • Software vendors are trying to get products to market as soon as possible and do not make security a priority
  • Customers have become accustomed to receiving software with security flaws that are then patched
  • Customers cannot fix the security flaws in software they purchase, so they resort to perimeter solutions
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Where Do We Place Security? - Environment vs. Application

A
  • Environment (At the OS)
  • Great to ensure a consistent approach, but the OS has no visibility or control of access activities within an application
  • Perimeter devices are more reactive in nature: they protect best against known vulnerabilities that are discovered over time
  • Application
  • Provides very granular control, but does nothing for security outside of the application, including any external resource the application requires
  • The more functionality that is packed into an application, the more difficult it becomes to achieve a good level of security hygiene
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Where Do We Place Security? - Implementation and Default Issues

A
  • Software should default to ‘No Access’ after installation
  • Security patches: Often not installed because the administrator:
  • Does not keep up to date on security vulnerabilities
  • May not realize the importance of applying patches
  • Might fear the patches will cause other problems
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Software Development Life Cycle - Introduction

A

SDLC: Concerned with creating a repeatable and predictable process that development teams will follow

  • Desired results
  • Higher level of product quality
  • Fewer missed deadlines
  • Lower cost
  • Acceptable level of functionality
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Software Development Life Cycle - Phases

A
  • Requirements gathering: Figure out what the product will do when completed
  • Design: Plan how the product will be put together
  • Development: Put the product together
  • Testing/validation: Make sure the product does what the requirements said it should do
  • Release/maintenance: Ship the product and update as-needed
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Software Development Life Cycle - Phases with a Security Perspective

A
  • Requirements gathering
  • Security risk assessment
  • Privacy risk assessment
  • Risk-level acceptance
  • Informational, functional and behavioral requirements
  • Design
  • Attack surface analysis
  • Threat modeling
  • Development
  • Automated CASE tools
  • Static analysis
  • Testing/validation
  • Dynamic analysis
  • Fuzzing
  • Manual testing
  • Unit, integration, acceptance and regression testing
  • Release/maintenance
  • Final security review
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Software Development Life Cycle - Project Management - Introduction

A
  • Ties together all of the pieces required to deliver a product
  • Specifically ensures that each phase is addressed properly
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Software Development Life Cycle - Project Management - Security management

A
  • Part of PM in which a security plan is created from the beginning
  • It must be able to stand alone and have its own lifetime
  • Will be referenced after the project has been completed during audits and as a way to validate the product meets specific security objectives
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Software Development Life Cycle - Project Management - Statement of work (SOW)

A
  • Drives software projects being developed for specific customers
  • Helps clarify customer requirements
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Software Development Life Cycle - Project Management - Scope Creep

A
  • Addition of new requirements not originally envisioned

* Project management must ensure that it adheres to the SOW closely to avoid it

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Software Development Life Cycle - Project Management - Work Breakdown Structure (WBS)

A
  • Defines the tasks and subtasks that are required to meet the stated requirements
  • The SDLC depends on it to be accurate
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Software Development Life Cycle - Requirements Gathering Phase - Focus

A
  • What the finished product should be capable of
  • What it should look like
  • How it should behave
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Software Development Life Cycle - Requirements Gathering Phase - Security related tasks

A
  • Security requirements
  • Security risk assessment
  • Privacy risk assessment
  • After completing it, we assign a privacy impact rating to each data element
  • Privacy Impact Ratings
  • P1: High Privacy Risk: PII is routinely handled and stored
  • P2: Moderate Privacy Risk: PII is handled in a one-time, user-initiated data transfer
  • P3: Low Privacy Risk: No PII is handled or stored
  • Risk-level acceptance: All possible risks will probably not be addressed, so the team should address the most important ones first
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Software Development Life Cycle - Requirements Gathering Phase - Models for Software Requirements

A
  • Informational model: Lists the type of information to be processed and how they are processed
  • Functional model: Lists the tasks and functions an application needs to provide
  • Behavioral model: Lists the states the application will be in during and after specific transactions take place
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Software Development Life Cycle - Design Phase - Introduction

A
  • Takes each requirement and shows how the product will meet it
  • Skipping this step: Unstable and insecure product
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Software Development Life Cycle - Design Phase - Outputs

A
  • Data design
  • Architectural design
  • Procedural design
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Software Development Life Cycle - Design Phase - Attack Surface

A
  • Portion of the application visible to an attacker
  • It’s made as small as possible by reducing
  • The amount of code running
  • Entry points
  • Privilege levels
  • Unnecessary services
  • Attack surface analysis
  • Automated scan of an application resulting in a report
  • Looks at files, registry entries, data stored in memory, session information, and process and service details
  • End goal: Identify and reduce the amount of code and/or functionality that is accessible by untrusted users
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Software Development Life Cycle - Design Phase - Threat modeling

A
  • Imagining various malicious scenarios and designing the software to counteract the threats
  • Threat Tree
  • Useful tool to visualize and document various attack vectors into the software
  • Visually shows each threat and how it is related to other threats
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Software Development Life Cycle - Development Phase - Introduction

A
  • The design is broken down into scheduled deliverables, and developers get down to work
  • Computer-Aided Software Engineering (CASE) tool
  • To auto-generate code
  • Create automated tests
  • Handle debugging activities
  • Writing secure code is not an easy task
  • Most vulnerabilities result from poor programming practices
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Software Development Life Cycle - Development Phase - Common mistakes

A
  • Not checking the input length to avoid buffer overflows
  • Not inspecting code to prevent the use of covert channels
  • Not checking/enforcing proper data types
  • Not ensuring checkpoints cannot be bypassed by users
  • Not verifying proper syntax
  • Not verifying checksums
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Software Development Life Cycle - Development Phase - Buffer Overflows

A
  • Can result in Privilege Escalation:
  • This is the act of exploiting a process or configuration setting to gain access to resources that normally are off limits to the process or user
  • Can be mitigated by
  • Using input validation
  • Ensuring least privilege
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

Software Development Life Cycle - Development Phase - Static Analysis

A
  • Process of examining the source code for defects or security policy violations
  • Limitation: cannot understand logic flows
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

Software Development Life Cycle - Testing/Validation Phase - Approaches to Testing

A
  • Unit Testing: Testing individual components
  • Integration Testing: Testing multiple components working together
  • Acceptance Testing: Testing to ensure the application meets the customer’s requirements
  • Regression Testing: After a change, rerunning all previously passing tests to ensure the application is still on solid footing
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

Software Development Life Cycle - Testing/Validation Phase - Unit Testing

A
  • Automated test that will exercise individual code modules or classes
  • Simulates a range of inputs and checks the resulting output for the expected result. This ensures the code will always run in an expected and secure manner
  • Allows the software to be automatically retested at any point to validate that changes have not introduced new defects
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

Software Development Life Cycle - Testing/Validation Phase - Test-Driven Development (TDD)

A
  • The unit test is written first, followed by the source code that will pass the test
  • If done properly, it can result in superior code
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q

Software Development Life Cycle - Testing/Validation Phase - Separation of duties

A

A separate team should beresponsible for formal testing

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q

Software Development Life Cycle - Testing/Validation Phase - Testing

A
  • Should happen in an environment that mirrors the production environment as close as possible
  • The identified risk must be expressed in terms of a repeatable test that proves that the vulnerability has been mitigated to an acceptable level
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q

Software Development Life Cycle - Testing/Validation Phase - Security Testing

A
  • Should use:
  • Manual Testing: Needs to be carried out by testers skilled in the security area, and sometimes involves the use of social engineering
  • Automatic Testing
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q

Software Development Life Cycle - Testing/Validation Phase - Fuzzing

A
  • Attack technique in which a large amount of randomly malformed and unexpected inputs are provided to an application
  • Fuzzing tools: Used for discovering:
  • Buffer overflows
  • DoS vulnerabilities
  • Validation problems
  • Injection weaknesses
  • Any other input that can cause a crash, freeze or unexpected errors
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
33
Q

Software Development Life Cycle - Testing/Validation Phase - Dynamic Analysis

A
  • An application is being evaluated in real-time as it is running
  • Profiles the application and checks for memory leaks or dependencies without having access to the source code
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
34
Q

Software Development Life Cycle - Testing/Validation Phase - Problems

A

1) Reported to the development team
2) The development team addresses the issues
3) More testing to ensure the issues were properly fixed
4) This cycle continues until everyone agrees the application is ready for production
4a) If the application is intended for a specific customer, that customer should perform their own testing and formally accept the product when they are satisfied

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
35
Q

Software Development Life Cycle - Testing/Validation Phase - Verification/Validation

A
  • Verification: Does the product meet the requirements as written?
  • Validation: Does the product meet the original goal as it was envisioned?
  • It is possible for a product to be verified, but not valid due to missed or incorrect requirements. It is extremely unlikely that a product could ever be valid but fail verification
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
36
Q

Software Development Life Cycle - Release/Maintenance Phase - Patches

A
  • More issues are almost guaranteed to appear
  • The development team will address the issue by creating them
  • The patch will need to be tested and formally accepted, followed by a rollout to the already installed product
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
37
Q

Software Development Life Cycle - Release/Maintenance Phase - Zero-Day Vulnerability

A

When an issue with software is discovered, it remains a zero-day vulnerability until a patch, update or a configuration change is made available that will address it

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
38
Q

Software Development Models - Build and fix model

A
  • Used when a development team follows no formal SDLC model

* No formal requirements or design phases

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
39
Q

Software Development Models - Waterfall Model

A
  • Linear-sequential life-cycle approach
  • Each phase must come to a complete close before the next phase is allowed to begin
  • At the end of each phase, a review is held
  • Once the next phase is started, there is no capability to go back and change the output from a previous phase
  • It is virtually impossible to know all requirements up-front, so the entire process must be completed before changes can be made on the next release
  • Phases
  • Feasibility
  • Analysis
  • Design
  • Implement
  • Test
  • Maintain
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
40
Q

Software Development Models - V-Shaped Model

A
  • Allowing testing to start earlier and continue throughout the entire SDLC
  • Higher chance of success than the Waterfall model, but not by much
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
41
Q

Software Development Models - Prototyping

A
  • Prototype: Simple model of a complex idea that can be used to vet or explore that complex idea without investing too much time or effort
  • Rapid Prototype: Creates a ‘throwaway’ product with just enough functionality to decide whether it is worth pursuing
  • Evolutionary Prototype: Not intended to be discarded, but rather incrementally improved upon until it reaches full maturity and can be placed into production
  • Operational Prototype: Same as an evolutionary prototype but it is designed to be placed into production immediately and ‘tweaked’ on-the-fly as customer feedback is received
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
42
Q

Software Development Models - Incremental Model

A
  • Involves iterations of something similar Waterfall Model
  • After each iteration of the entire SDLC, the customer provides feedback (i.e. more requirements) and the team goes back to the beginning with the new set of requirements and enhances the previous product.
  • Phases of each iteration
  • Analysis
  • Design
  • Code
  • Test
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
43
Q

Software Development Models - Spiral Model

A
  • Uses an iterative approach
  • Employed when a focus on risk analysis is desired
  • Good choice for complex projects in which requirements change often
  • Phases
  • Determine objectives
  • Identify and resolve risks
  • Development and test
  • Plan the next iteration
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
44
Q

Software Development Models - Rapid Application Model (RAD)

A
  • Working product is quickly developed
  • The intention is to use the product to elicit requirements, as opposed to using the requirements to build the product
  • It is a good fit when the customer is unsure of what they want, or requirements are guaranteed to change quickly and often at the beginning of a project
  • Phases
  • Analysis and quick design
  • RAD (build, demonstrate, refine)
  • Testing
  • Implementation
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
45
Q

Software Development Models - Agile Models - Introduction

A
  • Approaches that emphasize incremental product deliveries built on continuous-feedback from the customer
  • User Story: A simple description of a single feature written by an end-user
  • Agile models do not use prototypes. Instead, they break the product down into smaller features that are being continuously delivered
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
46
Q

Software Development Models - Agile Models - Scrum

A
  • Most widely recognized Agile model
  • Can handle projects of any size
  • Very focused on customer feedback
  • Recognizes upfront that customer needs will never be fully understood and will change. Therefore, focus is put on close collaboration with the customer and continuous delivery
  • Allows for interruptions at clearly defined points (sprints), after which everyone gathers back together and puts the ball back into play
  • Sprints:
  • Pre-defined interval (usually 2 weeks) during which the customer is not allowed to make changes
  • At the end of each sprint, the customer has the freedom to completely change direction if it so desires
  • At the beginning of each sprint, the development team selects the user stories, starting at the top of the backlog
  • Backlog: Prioritized list of user stories
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
47
Q

Software Development Models - Agile Models - Extreme Programming (XP)

A
  • Relies on Pair Programming
  • Developers work in pairs, with one developer telling the other what to type
  • Two eyes are constantly reviewing the code as it is being written, which reduces code complexity as well as errors
  • Requires test-driven development (TDD)
  • The test is written before any code is laid down, so it will immediately fail
  • Code is added until the test passes
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
48
Q

Software Development Models - Agile Models - Kanban

A
  • Stresses a visual tracking of development tasks, resulting in a just-in- time delivery of features
  • Kanban wall
  • Sticky notes representing each task and the wall being divided up into vertical sections, with the sections usually being labelled Planned, In Progress and Done
  • Developers will always take the top sticky note in the Planned column when they free up
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
49
Q

Software Development Models - Agile Models - Exploratory Model

A

Used when the goals of a project are not well-known, but final specifications that the product must meet are known

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
50
Q

Software Development Models - Agile Models - Joint Application Development (JAD)

A

Can be used when non-developers are able to dedicate their full time to the project and sit with the development team as work progresses

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
51
Q

Software Development Models - Agile Models - Reuse Model

A

Assumes that existing prototypes have already been created and are progressively enhanced

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
52
Q

Software Development Models - Agile Models - Cleanroom Model

A
  • Used when preventing errors and mistakes is the highest priority
  • Achieved by using structured and formal methods for development and testing
  • Usually employed for extremely high-quality and mission-critical applications that will need to pass a strict certification process.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
53
Q

Integrated Product Team - Definition

A
  • Made up from
  • Development team
  • Representatives from each stakeholder
  • More focused on internal customers than external customers
  • IPT is not a methodology, but works well with certain methodologies such as JAD or Agile
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
54
Q

Integrated Product Team - DevOps

A
  • Intersection of
  • Software development
  • IT
  • QA
  • Security is the big winner as it is addressed from the beginning because of IT’s involvement
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
55
Q

Capability Maturity Model Integration (CMMI) - Introduction

A
  • Software industry:
  • Multiple versions of a capability maturity model (CMM)
  • CMM: Attempts to provide guidelines for best-practiced development processes
  • CMMI:
  • Developed to combine them all into a single cohesive set
  • Used as a set of guidelines on establishing a mature software development process
  • Companies can become CMMI certified by third-parties
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
56
Q

Capability Maturity Model Integration (CMMI) - Maturity Levels

A

Each level builds on the previous levels: they are accumulative

  • Level 1: Initial: Process is unpredictable, poorly controlled and reactive
  • Level 2: Repeatable: Process within a project is repeatable
  • Level 3: Defined: Process within an organization is repeatable
  • Level 4: Managed: Process is quantitatively measured and controlled
  • Level 5: Optimizing: Has a focus on continually improving the process
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
57
Q

Change Control - Definition

A
  • Process of controlling any changes that take place during a product’s lifetime and documenting the activities that result
  • Should be in place at the beginning of a project or chaos will result
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
58
Q

Change Control - Reasons for enforcing a change control process

A
  • To have an agreed upon baseline before work starts: any changes may justify additional charges to the customer
  • So the development team knows how to deal with changes as they happen
  • To ensure changes do not negatively affect other components of the project
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
59
Q

Change Control - Common change control process

A
  1. Make a formal request for a change
  2. Analyze the request
    a. Develop the implementation strategy
    b. Calculate the costs
    c. Review security implications
  3. Record the change request
  4. Submit the change request for approval
  5. Develop the change
    a. Implement the change
    b. Link the changes to the formal change control request
    c. Test the software
    d. Repeat until quality is adequate
    e. Make version changes
  6. Report results to management
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
60
Q

Change Control - Software Configuration Management (SCM) - Introduction

A
  • Tool that provides traceability throughout the lifetime of the project by tracking change requests as they are entered, approved and delivered to the customer
  • Almost always used for implementing change control procedures related to software development
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
61
Q

Change Control - Software Configuration Management (SCM) - Versioning systems

A
  • Keeps track of each change made to a file
  • At any point the current copy can be ‘rolled back’ to a previous version
  • Keep track of the ‘who, what and when’ of each change
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
62
Q

Change Control - Software Configuration Management (SCM) - Synchronization

A

More than one developer working on the same project simultaneously

63
Q

Change Control - Software Configuration Management (SCM) - Code repository

A
  • Can implement SCM
  • Can protect integrity of the source by managing versioning and synchronization among multiple developers
  • Must be securely protected
  • Allow only authorized users to access the code
  • Reasons to protect this asset
  • Someone could steal the source code for their own use
  • An attacker could look at the source code to find vulnerabilities to exploit later
  • An attacker could inject vulnerabilities that can be exploited later
  • Most effective method for securing source code
  • Create an isolated network containing all development, test and QA systems
  • ‘Air-gap’ the whole thing
  • Remote work is no longer possible
  • Software Escrow
  • Companies use it to protect themselves in the event that partner company goes out of business or violates a contract
  • Only the compiled version that is usable for run-time is delivered
  • The source code is given to a third-party who holds on to it in case something unforeseen happens and the two companies no longer wish to cooperate
  • In this case, the third-party will release the source code held in escrow to the first company
64
Q

Programming Languages and Concepts - Programming Language

A
  • Invented in the 50’s

* Language that humans can understand and that is easily translated into binary so computers understand it

65
Q

Programming Languages and Concepts - Programming Language Categories - Machine Language

A
  • It’s the binary Language

* Computers speak it

66
Q

Programming Languages and Concepts - Programming Language Categories - Second Generation Language

A
  • aka Assembly Language
  • Uses instructions instead of 0’s and 1’s
  • Assembler: Converts assembly language into machine language
  • Programs written in assembly language are hardware-dependent and not portable to other processor types
67
Q

Programming Languages and Concepts - Programming Language Categories - Third Generation Language

A
  • aka High-Level Languages
  • Introduced the if…then…else construct
  • Allowed programmers to focus on abstract concepts
  • Programs written in third-generation languages are portable
  • Examples: C++, Java
68
Q

Programming Languages and Concepts - Programming Language Categories - Fourth Generation Language

A
  • aka Very High-Level Languages
  • Further abstracted the underlying complexity of computers from the programmer
  • Examples: SQL
69
Q

Programming Languages and Concepts - Programming Language Categories - Fifth Generation Language

A
  • These did not simply improve on fourth-generation languages
  • New way of expressing instructions: Using visual tools
  • Also called natural language
  • Technology has not quite caught up yet to this level of programming
70
Q

Programming Languages and Concepts - Assemblers, Compilers, Interpreters

A
  • Assembler
  • Takes assembly language
  • Converts it into machine language
  • Compiler
  • Takes a high-level language
  • Converts it into a machine-level format
  • Interpreter
  • Another abstraction layer
  • JVM (Java Virtual Machine)
  • CLR (Common Language Runtime)
  • Platform independent
  • Garbage Collection
  • Memory management is done automatically by the abstraction layer
  • Huge security advantage
71
Q

Programming Languages and Concepts - Object-Oriented Concepts

A
  • Object-Oriented Programming (OOP): Focuses on objects instead of a linear progression of code
  • Encapsulation: Hiding the procedural code behind walls
  • Message: How outside code communicates and provides input to an object
  • Method: Internal code that is executed in response to a message
  • Behavior: The results of a message being processed through a method
  • Class: A collection of methods that define some behavior
  • Instance: An object is an instance of a class
  • Inheritance: Methods from a parent class are inherited by a child class
  • Delegation: If an object does not have a method to handle a message, it will forward (delegate) that message to another object
  • Polymorphism: A characteristic of an object that allows it to respond with different behaviors to the same message
  • Cohesion: The strength of the relationship between methods of the same class; a high cohesion means a class limits the scope of what it does, which is better software design
  • Coupling: The level of required interaction between objects; low coupling means a class is less dependent on another class, which is a better software design
  • Data modeling: Views the data independently from code
  • Data structures: Views the logical relationships between data and how it is presented to code
  • Abstraction: Hides complex details from being seen, leaving only the bare minimum necessary for interaction
  • Application Programming Interface (API): Provides a reusable component by abstracting complexity
72
Q

Programming Languages and Concepts - Object-Oriented Concepts - Object-Oriented Programming (OOP)

A

Focuses on objects instead of a linear progression of code

73
Q

Programming Languages and Concepts - Object-Oriented Concepts - Encapsulation

A

Hiding the procedural code behind walls

74
Q

Programming Languages and Concepts - Object-Oriented Concepts - Message

A

How outside code communicates and provides input to an object

75
Q

Programming Languages and Concepts - Object-Oriented Concepts - Method

A

Internal code that is executed in response to a message

76
Q

Programming Languages and Concepts - Object-Oriented Concepts - Behavior

A

The results of a message being processed through a method

77
Q

Programming Languages and Concepts - Object-Oriented Concepts - Class

A

A collection of methods that define some behavior

78
Q

Programming Languages and Concepts - Object-Oriented Concepts - Instance

A

An object is an instance of a class

79
Q

Programming Languages and Concepts - Object-Oriented Concepts - Inheritance

A

Methods from a parent class are inherited by a child class

80
Q

Programming Languages and Concepts - Object-Oriented Concepts - Delegation

A

If an object does not have a method to handle a message, it will forward (delegate) that message to another object

81
Q

Programming Languages and Concepts - Object-Oriented Concepts - Polymorphism

A

A characteristic of an object that allows it to respond with different behaviors to the same message

82
Q

Programming Languages and Concepts - Object-Oriented Concepts - Cohesion

A

The strength of the relationship between methods of the same class; a high cohesion means a class limits the scope of what it does, which is better software design

83
Q

Programming Languages and Concepts - Object-Oriented Concepts - Coupling

A

The level of required interaction between objects; low coupling means a class is less dependent on another class, which is a better software design

84
Q

Programming Languages and Concepts - Object-Oriented Concepts - Data modeling

A

Views the data independently from code

85
Q

Programming Languages and Concepts - Object-Oriented Concepts - Data structures

A

Views the logical relationships between data and how it is presented to code

86
Q

Programming Languages and Concepts - Object-Oriented Concepts - Abstraction

A

Hides complex details from being seen, leaving only the bare minimum necessary for interaction

87
Q

Programming Languages and Concepts - Object-Oriented Concepts - Application Programming Interface (API)

A

Provides a reusable component by abstracting complexity

88
Q

Distributed Computing - Introduction

A
  • Solution that has at least two components separated by a network
  • Client/Server architecture
  • One client
  • One server
  • n-tier architecture
  • 3 or more tiers
  • Tiers
  • Client
  • Services layer
  • Server
  • Remote Procedure Call (RPC)
  • Generic term used for a client invoking a service on a remote computer
  • The client doesn’t understand the details of how the interaction happens
  • RPC hides the details
89
Q

Distributed Computing - Distributed Computing Environment (DCE)

A
  • Standard developed by Open Software Foundation (OSF)
  • First attempt at providing a standard method for distributing computer communication
  • Enables users, servers and resources to be contacted regardless of where each lives
  • Uses a UUID (Universal Unique Identifier)
  • No longer being used
90
Q

Distributed Computing - CORBA and ORBs - Common Object Request Broker Architecture (CORBA)

A
  • Open Standard
  • Developed by the Object Management Group (OMG)
  • Platform independent
  • Dictates how the components communicate by defining the API and communication protocols
91
Q

Distributed Computing - CORBA and ORBs - Object Request Brokers (ORBs)

A
  • Form the middle layer of services
  • Responsible for knowing where objects live
  • CORBA objects can be created in any language or format as long as it aligns with the CORBA standard
  • Work structure
    1) A client requests services from an ORB by giving it:
  • The name of the object it is interested in
  • The requested operation
  • Any necessary parameters
    2) The ORB
  • Locates the object
  • Carry out the request
  • Return any resulting data
92
Q

Distributed Computing - Component Object Model (COM)

A
  • Created by Microsoft
  • Goal: Provide the ability for Interprocess communication (IPC) on a single computer
  • It is language independent
  • Only used for Windows systems
93
Q

Distributed Computing - Distributed Component Object Model (DCOM)

A
  • COM extension for distributed environments

* Only used for Windows systems

94
Q

Distributed Computing - Object Linking and Embedding (OLE)

A
  • Based on COM
  • Allows objects such as images, spreadsheets and Word documents to be shared on a Windows computer
  • The object can be
  • Linked: One program calls another in real-time
  • Embedded: The foreign object is fully contained inside of a native application
95
Q

Distributed Computing - Java Platform, Enterprise Edition (Java EE)

A
  • Created by Oracle
  • Goal: Extend the Java language across the network
  • Works on multiple platforms
  • Uses CORBA standard for communications
96
Q

Distributed Computing - Service-Oriented Architecture (SOA) - Introduction

A
  • Not a technology or a standard: It’s a pattern
  • Provides clear-cut patterns to follow when creating services
  • Goal: The services layer can provide reusable building blocks for any number of applications and currently unknown future uses
  • Main idea:
  • Slice functionality up in discrete services that have high cohesion and low coupling
  • Expose an abstract interface
97
Q

Distributed Computing - Service-Oriented Architecture (SOA) - Simple Object Access Protocol (SOAP)

A
  • Usually based on HTTP
  • Web Services Description Language (WSDL, an XML format): Describes the methods and parameters a SOA service offers
  • Universal Description, Discovery and Integration (UDDI) service: Provides the ability to lookup a service
  • The service itself will provide a WDSL: Describing the supported methods
  • Platform independent
  • Can communicate of normal HTTP ports
  • Provides significant security capabilities. This makes it ‘fat’ compared to Representational State Transfer (REST)
98
Q

Mobile Code - Definition

A
  • Any type of code that can be transmitted through a network

* Compiled, self-contained component that is downloaded and executed on a client

99
Q

Mobile Code - Java

A
  • Run-time environment in which bytecode can be executed
  • Java Virtual Machine (JVM)
  • Must be installed on a client computer
  • Converts bytecode to machine-language and runs it
  • Supposed to prevent the applet from doing bad things. But hackers routinely figure out ways to circumvent the sandbox
  • Applet: Bytecode that is
  • Downloaded across the network
  • Executed in the JVM
100
Q

Mobile Code - ActiveX control

A
  • Similar to Java applets
  • Specific to Windows machines
  • Downloaded in a native format specific to the machine
  • Built on COM and OLE
  • Security issues
  • Can allow other apps to run within the browser using a component container
  • There is no sandbox
  • The code will execute with the privileges of the current user
  • Microsoft relies on Digital Certificates
  • ActiveX components are stored on the user’s hard drive
101
Q

Web Security Threats - Administrative Interfaces

A
  • Very convenient but dangerous if exposed over the Internet
  • Access should be limited to local IP addresses: Being able to connect using a VPN
  • Better solution: An out-of-band administrative interface. Example: SSH
102
Q

Web Security Threats - Authentication and Access Control

A
  • Passwords
  • Most common authentication method
  • Do not prove identity
  • Usernames: Can be mined or easily guessed
  • Many financial organizations require multi-factor authentication
  • Credentials: Should be sent TLS-encrypted
103
Q

Web Security Threats - Input Validation - Introduction

A
  • Deals with the consumption of user-provided variables
  • Ways to send variables
  • Through the URL
  • Using input fields
104
Q

Web Security Threats - Input Validation - URL attacks

A
  • Path or Directory Traversal Attack
  • aka dot-dot-slash attack
  • Carried out by inserting the ‘../’ characters into a URL
  • ’../’ command: Instructs the web server to walk back up one level from the current directory
  • Prevention: URL filtering
  • Example: If the URL ‘http://www.mydomain.com/pages/../../../../c:\windows\system32’ is sent to a web site and the site is located in c:\inetpub\www\mydomain\pages, the web server might try to send back a list of al files in c:\windows\system32 and possibly even run a program from there
  • Unicode Encoding
  • Unicode: Standard that allows all characters to be expressed as a hexadecimal equivalent
  • Instead of inserting the normal character, inserting its Unicode equivalent, this could circumvent URL filtering
  • URL Encoding
  • Using an alternate method for sending characters
  • Also aimed at bypassing filtering mechanisms
105
Q

Web Security Threats - Input Validation - Input fields attacks - SQL Injection

A
  • The attacker puts SQL commands into a text field and submits a form
  • The server then executes the text as legitimate SQL allowing the attacker to run SQL commands directly against the database
  • This could result in reading, updating or deleting data
  • Countermeasures:
  • Input values should be scrubbed and cleaned of any SQL-like clauses
  • Use ‘parameterized statements’
  • The input is not string-concatenated into SQL and executed
  • The values are provided as parameters to the SQL engine
106
Q

Web Security Threats - Input Validation - Input fields attacks - Script Injection - Introduction

A
  • Entry point to Cross-Site Scripting (XSS) attacks

* An attacker somehow gets their own script to execute inside of a user’s browser

107
Q

Web Security Threats - Input Validation - Input fields attacks - Script Injection - Non-Persistent XSS Vulnerabilities

A
  • aka Reflected Vulnerabilities
  • The attacker convinces the web server to emit HTML that downloads a rogue script from another site
  • This is accomplished when the web server ‘reflects’ back to the browser data that was previously submitted, normally in the form of query parameters embedded in the URL
  • Cross-Origin Resource Sharing (CORS) controls
  • Normally prevent this from happening
  • Workaround: JSONP
  • Countermeasure: Always encode the values from the query line if they need to be emitted back to the browser
  • Example: An attacker could get a user to click on a link such as https://www.mydomain.com?search=link_to_evil_script. If the website doesn’t properly filter the input or output, it can embed the evil script in the HTML that goes back to the browser
108
Q

Web Security Threats - Input Validation - Input fields attacks - Script Injection - Persistent XSS Vulnerabilities

A
  • When an attacker is able to convince a server to store their data in a database field
  • Later, another visitor views a page that contains the attacker’s code, resulting in execution of the malicious payload
  • Countermeasure: Always encode the input values before storing in the database
  • This often results in some rather ugly content, but usability must be weighed against security
  • Example:
  • An attacker posts a message to a forum, and the message contains ‘alert(‘I am evil!’);’
  • When another visitor views that forum post, the browser will pop up a scary message as soon as the page is loaded saying ‘I am evil’’
109
Q

Web Security Threats - Input Validation - Input fields attacks - Script Injection - Document object model XSS Vulnerabilities

A
  • Leverage the ability to dynamically generate content within the browser using the DOM
  • Example: If a page’s script executes ‘document.write(‘You are viewing: ‘ + document.location)’, then the following URL can force a message to pop up: ‘http://www.mydomain.com?alert(‘I am evil!’);’
  • Countermeasures
  • Not perform this type of DOM manipulation in a web page
  • Or include code to properly encode the value before inserting it into the DOM
110
Q

Web Security Threats - Input Validation - Input fields attacks - Script Injection - Client-side Validation

A
  • Occurs when client code ensures that all required fields are provided and checks for invalid values
  • Once client-side validation is passed, the request is then sent to the server
  • Server code should never trust data regardless of what type of client-side validation was performed. Hackers can easily bypass browsers and substitute their own values, thereby completely negating any client-side validation
111
Q

Web Security Threats - Parameter Validation

A
  • While input validation centers around the server examining and validating values provided from the user before processing them. The server also needs to be concerned about another class of values
  • Concerned with the server examining and validating values that are assumed to be beyond the ability of a user to change
  • Many web applications assume the user does not have the ability to change cookies or parameters
  • Examples:
  • Values stored in a client-side cookie or hidden fields
  • By using a web proxy on the client machine an attacker can intercept any HTTP traffic (even if it is encrypted!) and change cookie values, hidden fields, the URL, pretty much anything sent over an HTTP connection can be manipulated, including HTTP header values
  • Countermeasures
  • Never send any server-side data to the browser and expect it to be to be returned unless it is intentionally supposed to be manipulated by the user
  • Execute pre-validation: The client ensures the data is valid before submission to the server; this is optional
  • Execute post-validation: The server validates incoming values before trusting them
112
Q

Web Security Threats - Session Management

A
  • The ability to tie a browser request with an existing user interaction
  • The connectionless nature of HTTP and HTTPS means that the server will rely on the browser to tell it which session the browser wants to work with
  • Relies on the server generating a unique session ID the first time a browser connects
  • Requires the browser to always send back the session ID for any subsequent HTTP request
  • Session ID
  • Can be stored in a cookie, sent as a hidden input field, or added as part of every URL requested
  • Almost always sent over as clear text unless HTTPS is used
  • Session Hijacking
  • If TLS is not enabled, it can occur in which an attacker sniffs a current session ID, and uses it in her own packets
  • Countermeasures
  • Session IDs should be randomly generated to prevent an attacker from predicting a valid value
  • Some type of timestamp should be required to prevent replay attacks
  • Cookies containing session information should contain encrypted data: At least the attacker will be unable to look at information such as shopping cart contents
113
Q

Web Security Threats - Web Application Security Best Practices

A
  • Keep it simple: Security loves simplicity, and the simpler a site is, the easier it is to enforce proper security and detect issues
  • Look at user input: Closely scrutinize areas that allow user input and ensure the values are being properly vetted
  • Look at system output: Look for any places where data is emitted. It should always be HTM, encoded to prevent XSS
  • Encrypt everything: Any traffic between the server and the browser should be encrypted
  • Fail securely: When an error is encountered, always provide a friendly and generic message to the user and never divulge internal details
  • Strike a good security/usability balance: Too much security and users will hate your site; too little security and hackers will love your site
  • Never use security through obscurity: There is no such thing on the web; either it is in plain site or it needs to be wrapped in proper authentication/authorization measures
114
Q

Database Management - Introduction

A
  • Access to a database should be based on roles only
  • Not individual user accounts
  • This limits the damage that can be done if an external attacker gains direct access to the database
115
Q

Database Management - Database Management Software

A
  • Database definition: Persisted data which users can view and modify as-needed
  • Database Management System (DMS): Software that exposes the database, enforces access control, provides data integrity and redundancy, and provides procedures for data manipulation
  • A database should:
  • Ensure consistency among all associated servers
  • Provide for easy backups
  • Provide transaction persistence: Transactions are durable and reliable
  • Provide recovery and fault tolerance
  • Support sharing of data among multiple users
  • Provide security controls that implement integrity, access control and confidentiality
116
Q

Database Management - Database Models

A
  • Hierarchical Data Model
  • Relational Database Model (RDBM)
  • Network Database Model
  • Object-Oriented Database (OOD)
  • Object-Relational Database (ORD)
117
Q

Database Management - Database Models - Hierarchical Data Model

A
  • Combines records and fields in a tree structure without using indexes
  • Example: LDAP
118
Q

Database Management - Database Models - Relational Database Model (RDBM)

A
  • Uses attributes (columns) and tuples (rows) to store data in 2-dimensional tables
  • Cell: Intersection of a column and a row
  • Primary Key: Field that provides a unique value to every record in the table
119
Q

Database Management - Database Models - Network Database Model

A
  • Built on the hierarchical data model
  • Useful for many parent/many children relationships
  • Set: Defines parent/child relationships
120
Q

Database Management - Database Models - Object-Oriented Database (OOD)

A
  • Designed to handle multiple data types

* Each object contains its own data and methods

121
Q

Database Management - Database Models - Object-Relational Database (ORD)

A
  • Backed by a standard RDBM

* It’s an RDBM with an OOP layer on top for implementing business logic

122
Q

Database Management - Database Programming Interfaces

A
  • Introduction: Make possible for programming code to talk to various databases
  • Open Database Connectivity (ODBC):
  • Applications interact with the ODBC API, allowing the same interface to work regardless of the backend database
  • ODBC locates the database-specific driver and uses it to translate its common language into a database-specific language, but still understands SQL only.
  • Object Linking and Embedding Database (OLE DB)
  • Separates data into components that run on middleware and works with different databases in real-time
  • Replacement for ODBC
  • Supports non-SQL database
  • Windows-only solution
  • ActiveX Data Objects (ADO)
  • Official API for OLE DB
  • Java Database Connectivity (JDBC)
  • ODBC for Java applications
123
Q

Database Management - Relational Database Components - Relational Database Components

A
  • Schema: Table details
  • Structure:
  • Everything outside of tables
  • Table size
  • Index size
  • Views
  • Table relationships
  • Data Definition Language (DDL): Defines the structure and schema
  • Data Manipulation Language (DML): Provides access to the data
  • Data Control Language (DCL): Defines the internal organization of the database
  • Ad hoc Query Language (QL): Allows users to make requests (SQL is based on this)
  • Report Generator: Produces printouts of data in a user-defined format
  • Data dictionary
  • Centralized collection of information about all users, user roles, tables, indexes, privileges, etc
  • Used to provide access controls
  • Primary key: A unique value across all records in a table, used for indexing
  • Foreign key: A relationship where Table A has a column that matches a primary key in Table B
124
Q

Database Management - Relational Database Components - Integrity - Concurrency

A
  • Dealing with multiple users trying to modify the same data at the same time
  • Lock:
  • Solution to this problem
  • A database can lock data so that only one user can modify the value
  • Can be applied on the following levels
  • Table
  • Page
  • Row
  • Field
125
Q

Database Management - Relational Database Components - Integrity - Other integrity checks

A
  • Semantic Integrity: Ensures the database’s structure remains secure
  • Referential Integrity: Ensures that all foreign keys reference a valid primary key
  • Entity Integrity: Ensures that all primary keys have a unique value within the table
126
Q

Database Management - Relational Database Components - Integrity - Transaction

A

Sequence of operations performed as a single unit of work

127
Q

Database Management - Relational Database Components - Integrity - Transaction Integrity

A
  • Rollback: Cancels the current transaction and reverts the database to the state it was before the transaction started
  • Commit: Completes a transactions and executes all changes just made within the transaction
  • Two-Phase Commit: For transactions in a distributed environment, all database make a ‘pre-commit’, and once all database have reported back successfully, they all perform a ‘commit’
  • Batch Processing: Requests for database changes are put into a queue and executed all at once
128
Q

Database Management - Relational Database Components - Integrity - Online Transaction Processing (OLTP)

A
  • Used to provide fault tolerance and better performance with clustered databases
  • Monitors the entire transaction process across multiple systems and takes steps to ensure integrity across all components while making sure the system remains usable by enabling load-balancing if necessary
  • Enforces ACID
  • Atomicity: All changes take effect or none do
  • Consistency: All data remains consistent in all databases
  • Isolation: Transactions execute in isolation until completed
  • Durability: Once the transaction is committed it cannot be rolled back
129
Q

Database Management - Relational Database Components - Integrity - Mechanisms to handle unexpected error states

A
  • Savepoint: Periodic save of a database that can be restored in case of severe interruption
  • Checkpoint: Triggered when the database fills up a specific amount of memory
130
Q

Database Management - Relational Database Components - Integrity - Security perspective

A
  • Database View: A virtual table comprised of one or more underlying tables that restrict or aggregate data according to access control policy
  • Polyinstantiation: Interactively creating two instances of the same object with different attributes; this is used to stop inference attacks
131
Q

Database Management - Relational Database Components - Data Warehousing

A
  • Combines data from two or more databases into a single large database
  • Goal: Providing an aggregated view of the source data exclusively for follow-up analysis
  • During the aggregation process:
  • Redundant information is removed
  • The remaining data is properly formatted and correlated
  • Security should be more stringent
132
Q

Database Management - Relational Database Components - Data Mining

A
  • Combing through the data warehouse information and extracting metadata
  • Knowledge Discovery in Databases (KDD)
  • Another term for Data Mining
  • Approaches to identify patterns
  • Classification: Groups according to similarities
  • Probabilistic: Identifies relationships and calculates probabilities
  • Statistical: Identifies relationships and uses rule discovery
133
Q

Database Management - Relational Database Components - Big Data

A
  • Very large data sets
  • Unsuitable for traditional analysis
  • Reasons
  • Heterogeneity
  • Complexity
  • Variability
  • Lack of reliability
  • Volume
134
Q

Malicious Software (Malware) - Viruses

A
  • Virus
  • Macro Virus
  • Boot Sector Virus
  • Tunneling Virus
  • Stealth Virus
  • Polymorphic Virus
  • Multipart Virus
  • Meme Virus
  • Script Virus
135
Q

Malicious Software (Malware) - Viruses - Virus

A
  • Small application that infects software and can replicate itself
  • Requires a host application
  • Carries payloads that cause the real harm
136
Q

Malicious Software (Malware) - Viruses - Macro Virus

A

Written in a macro language such as Visual Basic or VBScript, and usually associated with Microsoft Office products

137
Q

Malicious Software (Malware) - Viruses - Boot Sector Virus

A
  • Infects the boot sector of a computer

* Often hides itself in hard drive sectors that the virus has marked as bad

138
Q

Malicious Software (Malware) - Viruses - Tunneling Virus

A
  • Intercepts requests for a file
  • Presents a forged version of it instead. The virus can convince the antimalware that everything is fine and to move along
139
Q

Malicious Software (Malware) - Viruses - Stealth Virus

A
  • Hides the modifications it has made by acting as a tunneling virus
  • Can also mask the size of the file it is hiding in
  • Move itself around during antimalware activity to avoid detection
140
Q

Malicious Software (Malware) - Viruses - Polymorphic Virus

A
  • Can alter its appearance in an effort to outwit virus scanners
  • It will make multiple copies of itself, each with a different appearance so that it reappears when the antimalware software thinks it has eradicated it
  • Appearance changes
  • Using different encryption schemes
  • Change their own code by embedding noise or changing its instructions sequence
141
Q

Malicious Software (Malware) - Viruses - Multipart Virus

A

Has several components that are distributed in multiple locations on each system, allowing it to spread more quickly

142
Q

Malicious Software (Malware) - Viruses - Meme Virus

A
  • Not a real virus

* Harm: Wasted bandwidth and possible fear based on the email’s message

143
Q

Malicious Software (Malware) - Viruses - Script Virus

A
  • Sent in script form in an interpreted language

* Often these scripts are downloaded by a web browser, and when launched can cause great damage

144
Q

Malicious Software (Malware) - Worms

A
  • Self-contained programs
  • Can reproduce without requiring a host application
  • Example: Stuxnet
145
Q

Malicious Software (Malware) - Rootkit

A
  • Bundle of tools that can be used to cause further mayhem after a system has been compromised and the attacker escalated privileges, such as installing a backdoor or to start sniffing for credentials.
  • Rootkit Types
  • User-Level Rootkit
  • Kernel-Level Rootkit
  • Firmware-Level Rootkit
  • Tools
  • Trojan Programs
  • Replaces valid programs
  • Will often appear to run correctly
  • Log Scrubber
    Removes traces of the attacker’s movements from the system log files
146
Q

Malicious Software (Malware) - Spyware

A

Malware that exists to gather information about a victim

147
Q

Malicious Software (Malware) - Adware

A
  • Not intended to harm a system
  • It is invasive
  • Can cause privacy concerns
148
Q

Malicious Software (Malware) - Botnets

A
  • Bot:
  • Malware that can be installed through
  • E-mail
  • Drive-by downloads
  • Trojan horses
  • Shared media
  • Will check in to let the hacker know it has successfully compromised a system
  • Then lie dormant until it receives further instructions
  • Botnet: Network of bots
  • Bot Herder:
  • Owner of a botnet
  • Controls the botnet usually through IRC
  • Botnet uses
  • Carry out DDoS attacks
  • Spamming
  • Brute-force attacks
  • Others
  • Fast Flux: Evasion technique used to continually be on the move by updating DNS entries
  • Command-and-Control (C&C) Servers: Servers that send instructions to a botnet
149
Q

Malicious Software (Malware) - Logic Bombs

A

Programs that are set to go off and execute its payload whenever a specific trigger is activated

150
Q

Malicious Software (Malware) - Trojan Horses

A
  • Programs disguised as other programs
  • Often carry out the activity that the original program is designed to, but additionally operate in the background
  • Remote Access Trojan (RAT): Malicious program that allows an intruder to access and use a system remotely
151
Q

Malicious Software (Malware) - Spam Detection

A
  • Ongoing effort as spammers continually work to evade our best detection efforts
  • Spam:
  • The receipt of unsolicited junk email
  • Bayesian Filtering
  • Technique that applies statistical modeling to the words in an email message to determine how often each is used and in what order
  • From that analysis make a determination if the message is spam or not
  • Spammers intentionally misspell words or substitute symbols in an effort to get past the spam filters
152
Q

Malicious Software (Malware) - Malware Components

A
  • Insertion: Installs itself
  • Avoidance: Avoid detection
  • Eradication: Removes itself after the payload has been delivered
  • Replication: Makes copies of itself and spreads
  • Trigger: Use an event to execute the payload
  • Payload: Carries out its function
153
Q

Malicious Software (Malware) - Antimalware Programs

A
  • Antimalware policy
  • Companies should have it
  • Details the type antimalware and antispyware software that should be installed, including configuration parameters
  • Virus Walls
  • Scan incoming SMTP, HTTP and FTP traffic for malware
  • Can be integrated with
  • E-mail servers
  • Proxy servers
  • Firewalls

CISSP (4 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions