Chapter 3 – Program Security Section 3.4 Targeted Malicious Code Section 3.5 Controls Against...

22
Chapter 3 (Part 2) Network Security Chapter 3 – Program Security Section 3.4 Targeted Malicious Code Section 3.5 Controls Against Program Threats

Transcript of Chapter 3 – Program Security Section 3.4 Targeted Malicious Code Section 3.5 Controls Against...

Page 1: Chapter 3 – Program Security Section 3.4 Targeted Malicious Code Section 3.5 Controls Against Program Threats.

Chapter 3 (Part 2)Network SecurityChapter 3 – Program Security

Section 3.4 Targeted Malicious CodeSection 3.5 Controls Against Program

Threats

Page 2: Chapter 3 – Program Security Section 3.4 Targeted Malicious Code Section 3.5 Controls Against Program Threats.

In this SectionProgram Threats

TrapdoorsSalami AttackPrivilege EscalationMan-in-the-MiddleCovert Channels

Controls Against Program ThreatsModularityMutual SuspicionHazard Analysis

Page 3: Chapter 3 – Program Security Section 3.4 Targeted Malicious Code Section 3.5 Controls Against Program Threats.

Targeted Malicious CodeSo far looked at code written to affect users

and machines indiscriminatelyTargeted Malicious Code – written for a

particular system or application with a particular purpose

Similar to viruses but with the addition of new techniques

Page 4: Chapter 3 – Program Security Section 3.4 Targeted Malicious Code Section 3.5 Controls Against Program Threats.

TrapdoorTrapdoor – an undocumented entry point to a module.

Inserted for code development“Hooks” to add additional future enhancements

Can be legitimate or non-legitmateSoftware Testing

Unit TestingIntegration TestingStubs and Drivers – routines that inject information

during testing Control Stubs – used to invoke debugging codeAccidently left in placePoor Error Checking

Page 5: Chapter 3 – Program Security Section 3.4 Targeted Malicious Code Section 3.5 Controls Against Program Threats.

TrapdoorsPoorly defined Data

Incomplete MediationUndefined Opcodes – instructions that have

not been defined for the processorTrapdoors can be useful

Software audits may request trapdoors to be inserted

Trap doors should always be documented.

Page 6: Chapter 3 – Program Security Section 3.4 Targeted Malicious Code Section 3.5 Controls Against Program Threats.

Causes of TrapdoorsForgot to removeIntentionally for TestingIntentionally left for maintenanceIntentionally left for covert means of

access

Trapdoors are not bad. They are not faults until the trapdoor is not shut.

A system is not secure if a trapdoor is present but unknown by others

Page 7: Chapter 3 – Program Security Section 3.4 Targeted Malicious Code Section 3.5 Controls Against Program Threats.

Salami AttackNamed after the way scrap meat is used to form salamiSalami Attack – merges seemingly inconsequential

bits of data to yield something important Classic Salami Attacks

Missing ½ centMissing percentageTaking a bit from a bunchCharging higher fees

Why do they happen?Sometimes programmers just except small errorsCode many times it to large to look for salami type errors

Page 8: Chapter 3 – Program Security Section 3.4 Targeted Malicious Code Section 3.5 Controls Against Program Threats.

RootkitsRootkit – is a piece of malicious code that

goes to great lengths not to be discoveredIf discovered tries to reestablish itselfTries to run itself as “root” on the system

(UNIX administrator)Resides between user and OSIntercepts commands in order to keep itself

hiddenRootkit Revealer – program written to reveal

rootkitsXCP rootkit – used to help prevent copying of

music

Page 9: Chapter 3 – Program Security Section 3.4 Targeted Malicious Code Section 3.5 Controls Against Program Threats.

OthersPrivilege Escalation-Attack is a means for

malicious code to be launched by a user with lower privileges but run with higher privileges

Interface Illusions - spoofing an attack in which all or part of a web page is false

Keystroke Logging – keeps a copy of everything pressed

Man-in-the-Middle Attack- Malicious program exists between tow programs

Timing Attack – identify how fast something happens

Page 10: Chapter 3 – Program Security Section 3.4 Targeted Malicious Code Section 3.5 Controls Against Program Threats.

Covert ChannelsCommunication information to people/systems

that should not have itUnnoticed communication and accompanies

other informationData written to a drive, sent across a network,

placed in a file or printoutStorage Channel – passes information based on

presence or non-presence of dataFile lock Channel – lock or non-lock of fileTiming Channels – varying speed in system or

not using assigned computational time

Page 11: Chapter 3 – Program Security Section 3.4 Targeted Malicious Code Section 3.5 Controls Against Program Threats.

Controls Against Program ThreatsDevelopment of Controls

Specify the systemDesign the systemImplement the systemTest the systemReview the system at various stagesDocument the systemManage the systemMaintain the systems

Typically it is not one person that does all of these

Page 12: Chapter 3 – Program Security Section 3.4 Targeted Malicious Code Section 3.5 Controls Against Program Threats.

Designing Secure and Usable SystemsYou can’t retrofit usable securityTools aren’t a solutionMin the upper layersKeep the customers satisfiedThink Locally; act locally

Page 13: Chapter 3 – Program Security Section 3.4 Targeted Malicious Code Section 3.5 Controls Against Program Threats.

ModularitySmall self-contained unitsModularity

IsolatesHides

Keep it isolated from the effects of other components

Encapsulation – is isolationInformation Hiding – each component

hides its precise implementation of some other design decision from others.

Page 14: Chapter 3 – Program Security Section 3.4 Targeted Malicious Code Section 3.5 Controls Against Program Threats.

ModularizationProcess of dividing into subtasksGoal of Modular Units

Single-purposeSmallSimpleIndependent

Advantages of ModularityMaintenanceUnderstandabilityReuseCorrectnessTesting

Page 15: Chapter 3 – Program Security Section 3.4 Targeted Malicious Code Section 3.5 Controls Against Program Threats.

ModularityHigh Cohesion

All the elements of a component have a logical and functional reason for being there

Low CouplingThe degree with which a component depends

on other components in the system Encapsulation – does not mean complete

isolationInformation Hiding – a “black box” approach

Page 16: Chapter 3 – Program Security Section 3.4 Targeted Malicious Code Section 3.5 Controls Against Program Threats.

Mutual SuspicionPrograms are not always trustworthyMutual suspicion – each program operates

as if other routines in the system were malicious or incorrect

Confinement – program is strictly prohibited in what system resources can be accessed

Page 17: Chapter 3 – Program Security Section 3.4 Targeted Malicious Code Section 3.5 Controls Against Program Threats.

Peer ReviewsPeer reviewHazard analysisTestingGood design PredictionsStatic analysisConfiguration managementAnalysis of mistakes

Page 18: Chapter 3 – Program Security Section 3.4 Targeted Malicious Code Section 3.5 Controls Against Program Threats.

Types of Peer ReviewReview- presented formallyWalk-Through – creator leads and controls

the discussionInspection – formal detailed analysis Finding a fault and dealing with it:

By learning how, when, and why errors occurBy taking action to prevent mistakesBy scrutinizing products to find the instances

and effects of errors that were missed.

Page 19: Chapter 3 – Program Security Section 3.4 Targeted Malicious Code Section 3.5 Controls Against Program Threats.

Hazard Analysis/Testing Hazard Analysis – set of systematic techniques to expose potentially

hazardous system states. Hazards and Operability Studies Failure Modes and effects analysis Fault tree analysis

Testing Unit Testing Integration Testing Function Testing Performance Testing Acceptance Testing Installation Testing Regression Testing Black-box Testing Clear-box Testing Independent Testing Penetration Testing

Page 20: Chapter 3 – Program Security Section 3.4 Targeted Malicious Code Section 3.5 Controls Against Program Threats.

Good DesignUsing a philosophy of fault toleranceHaving a consistent policy for handling

failuresCapturing the design rationale and historyUsing design patterns

Passive fault detection – waiting for a system to fail

Active fault detection – construct a system that reacts to a failure

Page 21: Chapter 3 – Program Security Section 3.4 Targeted Malicious Code Section 3.5 Controls Against Program Threats.

Good DesignHandling Problems

Retrying – restoring the system to previous state and try again

Correcting – resorting the system to previous state and correcting some system characteristic before trying again

Reporting – restoring and reporting but not trying again

Page 22: Chapter 3 – Program Security Section 3.4 Targeted Malicious Code Section 3.5 Controls Against Program Threats.

Configuration ManagementWho is making the changes

Corrective changeAdaptive changePerfective changePreventive change

Configuration Management – is the process by which we control changes during development and maintenanceConfiguration identificationConfiguration control and change managementConfiguration auditingStatus accounting