1
Program Security
Part II
Targeted Malicious Code
2

General purpose malicious code
 Affect

users and machines indiscriminately
Targeted malicious code
 Written
for a particular system, for a particular
application, and for a particular purpose
 Trapdoor
 Salami attack
 Covert channel
Salami Attack
3


A salami attack merges seemingly inconsequential
data to yield powerful results
Example
 Bank
programmer: transfer one cent of interest from
each account to his/her account
Covert Channels
4

Covert channels
Programs that communicate information to people who
should not receive it
 The communication travels unnoticed, accompanying other,
perfectly proper, communications


A human example

Reveal answers to multiple choice questions



Coughing for (a)
Sighing for (b)
…
Covert Channels (Cont’d)
5

Structure of
cover channels

A sender


Service program
A receiver


Legitimate user
Spy
Service Program
A Trojan horse is
always involved
Spy
Protected data
Preventing security flaws
6


We have seen a lot of possible security flaws. How
to prevent (some of) them?
Software engineering concentrates on developing
and maintaining quality s/w


We’ll take a look at some techniques useful specifically for
developing/maintaining secure s/w
Three types of controls against pgm flaws:
Developmental controls
 OS controls
 Administrative controls

7
Developmental Controls Collaborative
effort

Team of developers, each involved in ≥ 1 of stages:








Requirement specification
 Regular req. specs: ”do X”
 Security req. specs: ”do X and nothing more”
Design
Implementation
Testing
Documenting at each stage
Reviewing at each stage
Managing system development through all stages
Maintaining deployed system (updates, patches, new versions, etc.)
Developmental Controls, cont.
8

Fundamental principles of s/w engineering
 Modularity
 Encapsulation
 Information
hiding
Developmental Controls, Modularity
9

Modules should be:
Single-purpose - logically/functionally
 Small - for a human to grasp
 Simple - for a human to grasp
 Independent – high cohesion, low coupling




High cohesion – highly focused on (single) purpose
Low coupling – free from interference from other modules
Modularity should improve correctness

Fewer flaws => better security
Developmental Controls, Encapsulation
10

Minimizing information sharing with other modules



Limited interfaces reduce # of covert channels
Well documented interfaces
”Hiding what should be hidden and showing what
should be visible.”
11
Developmental Controls, Information
hiding

Module is a black box
 Well


defined function and I/O
Easy to know what module does but not how it does
it
Reduces complexity, interactions, covert channels, ...
=> better security
12
Developmental Controls, building solid
software








Peer reviews
Hazard analysis
Testing
Good design
Risk prediction & mangement
Static analysis
Configuration management
Additional developmental controls
Development Controls
13

Peer reviews

Review



Walk-through



Presented informally to a team of reviewers
Goal: consensus and buy-in before development proceeds further
Presented to the team by its creator
Goal: education; focus is on learning about a single document
Inspection


Formal process; detailed analysis in which the artifact is checked
against a prepared listed of concerns
Goal: verify properties of the artifact of concern
Development Controls (Cont’d)
14

Hazard analysis
Intended to expose potentially hazardous system states
 Involves developing




Hazard lists, and
Procedures for exploring “what if” scenarios to trigger consideration
of non-obvious hazards
Example: Failure modes and effects analysis (FMEA)




Bottom up technique
Identify each component’s possible faults
Determine what could trigger the fault and the system-wide effects of
the fault
Often lead to possible system failures that are not made visible by
other analytical means
Development Controls (Cont’d)
15

Testing
Involves several stages
 Unit testing





Each component is tested on its own, isolated from the other
components in the system
Done in a controlled environment
AKA, module testing, component testing
Integration testing


Ensure the interface among the components are defined and handled
properly
Verify that the system components work together as specified
Testing (Cont’d)
16

Function test


Performance test


Evaluate the system to determine whether the functions
described by the requirement specification are actually
performed by the system
Compare the system with the remainder of the software and
hardware requirements
Security requirements are examined during the
function and performance tests
Testing (Cont’d)
17

Acceptance test


Installation test


Ensure that the system works according to customer
expectations
A final test to ensure the system still functions as it should
Regression test

After a change is made to enhance or fix the system,
regression testing ensures that all remaining functions are
still working
Development Controls (Cont’d)
18

Good design
 Using
a philosophy of fault tolerance
 Active
fault detection
 Redundancy
 Isolate the damage and minimize the disruption
 Having
a consistent policy for handling failures
 Using design patterns
Developmental Controls, Good design,
cont.
19

Value of Good Design
 Easy
maintenance
 Understandability
 Reuse
 Correctness
 Better testing
Development Controls (Cont’d)
20

Prediction
 Identify
what unwanted events might occur
 Make plans to avoid them or mitigate their effects

Static analysis
 Examine
design and code to locate and repair security
flaws
 Control
flow
 Data flow
 Data structure
 Many
approaches; automated tools needed
Development Controls (Cont’d)
21

Configuration management
The process by which we control the changes during
development and maintenance
 Four activities





Configuration identification
 Build an inventory (baseline) of all components of the system
Configuration control and change management
 Coordinate separate, related versions
Configuration auditing
 Confirms that the baseline is complete and accurate, changes are
recorded, recorded changes are made, the actual software is
reflected accurately in the documents
Status accounting
 Record the information about the components
Operating System (OS) Controls
22
Developmental controls not always used
OR:
 Even if used, not foolproof
=> Need other, complementary controls, incl. OS
controls


Such OS controls can protect against some pgm
flaws
Operating System (OS) Controls
23

Trusted software



A part of the OS that has been rigorously developed and
analyzed
Called Trusted Computer Base (TCB)
Key characteristics during rigorous analysis and testing



Functional correctness
Enforcement of integrity
Limited privilege



Access is minimized; sensitive data not disclosed
Appropriate confidence level
Often used as a safe way for general users to access
sensitive data
Operating System (OS) Controls
(Cont’d)
24

Mutual suspicion
 Programs

do not trust each other
Confinement
 Program
is strictly limited in what system resources it
can access

Access (audit) log
 List
of who accessed what objects
 Allow tracking down what has been done
Operating System Controls for Security,
Audit log / access log
25



Records who/when/how (e.g., for how long) accessed/used
which objects
 Events logged: logins/logouts, file accesses, pgm
ecxecutions, device uses, failures, repeated unsuccessful
commands (e.g., many repeated failed login attempts can
indicate an attack)
Audit frequently for unusual events, suspicious patterns
Forensic measure not protective measure
 Forensics – investigation to find who broke law, policies,
or rules
Administrative Controls
26

Standards of program development
Capture the wisdom from previous projects
 Standards of design



Standards of documentation, language, and coding style


Mandatory peer reviews, periodic code audits, compliance with
standards
Standards of testing


Layout of code, choices of variable names, recognized program
structures
Standards of programming


Design tools, languages, methodologies
Program verification, archiving test results, independent testers,…
Standards of configuration management
Administrative Controls (Cont’d)
27

Separation of duties
Break development tasks into pieces to be performed by
separate developers/testers/administrators
 Force developers/testers/administrators to cooperate
 More rigorous examination
