Nov 15, 2005

IS2150/TEL2910: Introduction of Computer Security 1

Nov 15, 2005Nov 15, 2005

AssuranceAssurance

2IS2150/TEL2910: Introduction of Computer Security

OverviewOverview

TrustTrustProblems from lack of assuranceProblems from lack of assuranceTypes of assuranceTypes of assuranceLife cycle and assuranceLife cycle and assuranceWaterfall life cycle modelWaterfall life cycle modelOther life cycle modelsOther life cycle models


TrustTrust

TrustworthyTrustworthy entity has sufficient credible entity has sufficient credible evidence leading one to believe that the system evidence leading one to believe that the system will meet a set of requirementswill meet a set of requirements

TrustTrust is a measure of trustworthiness relying on is a measure of trustworthiness relying on the evidencethe evidence

AssuranceAssurance is confidence that an entity meets its is confidence that an entity meets its security requirements based on evidence security requirements based on evidence provided by the application of assurance provided by the application of assurance techniquestechniques Formal methods, design analysis, testing etc.


RelationshipsRelationships

Policy

Mechanisms

Assurance

Statement of requirements that explicitly definesthe security expectations of the mechanism(s)

Provides justification that the mechanism meets policythrough assurance evidence and approvals based onevidence

Executable entities that are designed and implementedto meet the requirements of the policy

Evaluation standardsTrusted Computer System Evaluation Criteria

Information Technology Security Evaluation Criteria Common Criteria


Problem Sources (Neumann)Problem Sources (Neumann)

1.1. Requirements definitions, omissions, and mistakesRequirements definitions, omissions, and mistakes2.2. System design flawsSystem design flaws3.3. Hardware implementation flaws, such as wiring and chip Hardware implementation flaws, such as wiring and chip

flawsflaws4.4. Software implementation errors, program bugs, and Software implementation errors, program bugs, and

compiler bugscompiler bugs5.5. System use and operation errors and inadvertent mistakesSystem use and operation errors and inadvertent mistakes6.6. Willful system misuseWillful system misuse7.7. Hardware, communication, or other equipment malfunctionHardware, communication, or other equipment malfunction8.8. Environmental problems, natural causes, and acts of GodEnvironmental problems, natural causes, and acts of God9.9. Evolution, maintenance, faulty upgrades, and Evolution, maintenance, faulty upgrades, and

decommissionsdecommissions


ExamplesExamples

Challenger explosion (1986)Challenger explosion (1986) Sensors removed from booster rockets to meet

accelerated launch schedule Deaths from faulty radiation therapy systemDeaths from faulty radiation therapy system

Hardware safety interlock removed Flaws in software design

Bell V22 Osprey crashesBell V22 Osprey crashes Failure to correct for malfunctioning components; two

faulty ones could outvote a third Intel 486 chip bug (trigonometric function)Intel 486 chip bug (trigonometric function)

Cost a lot of time and money


Role of RequirementsRole of Requirements

RequirementsRequirements are statements of goals that are statements of goals that must be metmust be met Vary from high-level, generic issues to low-

level, concrete issuesSecurity objectivesSecurity objectives are high-level security are high-level security

issues and business goalsissues and business goalsSecurity requirementsSecurity requirements are specific, are specific,

concrete issuesconcrete issues


Types of AssuranceTypes of Assurance

Policy assurancePolicy assurance is evidence establishing is evidence establishing security requirements in policy is complete, security requirements in policy is complete, consistent, technically soundconsistent, technically sound To counter threats and meet objectives

Design assuranceDesign assurance is evidence establishing is evidence establishing design sufficient to meet requirements of design sufficient to meet requirements of security policysecurity policy

Implementation assuranceImplementation assurance is evidence is evidence establishing implementation consistent with establishing implementation consistent with security requirements of security policysecurity requirements of security policy Need to use good engineering practices


Types of AssuranceTypes of Assurance

OperationalOperational assuranceassurance is evidence is evidence establishing system sustains the security establishing system sustains the security policy requirements during installation, policy requirements during installation, configuration, and day-to-day operationconfiguration, and day-to-day operation Also called administrative assurance Example,

Do a thorough review of product or system documentation and procedures, to ensure that the system cannot accidentally be placed in a non-secure state.


Assurance stepsAssurance steps

Security requirements

Design

Implementation

1

32

4

Assurancejustification

Design andimplementationrefinement


Life CycleLife Cycle

ConceptionConception

ManufactureManufacture

DeploymentDeployment

Fielded Product LifeFielded Product Life


ConceptionConception

IdeaIdea Decisions to pursue it

Proof of conceptProof of concept See if idea has merit Rapid prototyping, analysis, etc.

High-level requirements analysisHigh-level requirements analysis What does “secure” mean for this concept?

Identify threats Is it possible for this concept to meet this meaning of

security? Is the organization willing to support the additional resources

required to make this concept meet this meaning of security?


ManufactureManufacture

Develop detailed plans for each group involvedDevelop detailed plans for each group involved May depend on use; internal product requires no sales Plans: marketing, sales training, development, testing Software development and engineering process

Implement the plans to create entityImplement the plans to create entity Includes decisions whether to proceed, for example due

to market needs May be the longest stageMay be the longest stage


DeploymentDeployment

DeliveryDelivery Assure that correct (assured) masters are

delivered to production and protected Distribute to customers, sales organizations

Installation and configurationInstallation and configuration Developers must ensure that the system

operates properly in the production environment


Fielded Product LifeFielded Product Life

Routine maintenance, patchingRoutine maintenance, patching Responsibility of engineering in small

organizations Responsibility may be in different group than

one that manufactures productCustomer service, support organizationsCustomer service, support organizations

Answering questions; recording bugsRetirement or decommission of productRetirement or decommission of product

Migration plans for customers


Waterfall Life Cycle ModelWaterfall Life Cycle Model

Requirements definition and analysisRequirements definition and analysis Functional and non-functional General (for customer), specifications

System and software designSystem and software design Implementation and unit testingImplementation and unit testing Integration and system testingIntegration and system testingOperation and maintenanceOperation and maintenance


Relationship of StagesRelationship of Stages

Requirementsdefinition andanalysis

System andsoftwaredesign

Implementationand unittesting Integration

and systemtesting

Operationandmaintenance


Other Models of Other Models of Software DevelopmentSoftware Development

Exploratory programmingExploratory programming Develop working system quickly Used when detailed requirements specification cannot

be formulated in advance, and adequacy is goal No requirements or design specification, so low

assurance Prototyping (Similar to Exploratory)Prototyping (Similar to Exploratory)

Objective is to establish system requirements Future iterations (after first) allow assurance techniques


ModelsModels

Formal transformationFormal transformation Create formal specification Translate it into program using correctness-

preserving transformations Very conducive to assurance methods

System assembly from reusable componentsSystem assembly from reusable components Depends on whether components are trusted Must assure connections, composition as well Very complex, difficult to assure This is common approach to building secure and

trusted systems


ModelsModels

Extreme programmingExtreme programming Rapid prototyping and “best practices” Project driven by business decisions Requirements open until project complete Programmers work in teams Components tested, integrated several times a day Objective is to get system into production as quickly as

possible, then enhance it Evidence adduced after development needed for

assurance


Key PointsKey Points

Assurance critical for determining Assurance critical for determining trustworthiness of systemstrustworthiness of systems

Different levels of assurance, from Different levels of assurance, from informal evidence to rigorous informal evidence to rigorous mathematical evidencemathematical evidence

Assurance needed at all stages of system Assurance needed at all stages of system life cyclelife cycle


Threats and VulnerabilitiesThreats and Vulnerabilities

ThreatThreat A potential occurrence that can have an undesirable

effect on the system assets of resources Results in breaches in confidentiality, integrity, or a denial

of service Example: outsider penetrating a system is an outsider

threat (insider threat?) Need to identify all possible threats and address them to

generate security objectives VulnerabilityVulnerability

A weakness that makes it possible for a threat to occur


Architectural considerationsArchitectural considerations

Determine the focus of control of security Determine the focus of control of security enforcement mechanismenforcement mechanism Operating system: focus is on data Applications: more on operations/transactions

Centralized or DistributedCentralized or Distributed Distribute them among systems/components Tradeoffs? Generally easier to “assure” centralized system

Security mechanism may exist in any layerSecurity mechanism may exist in any layer


Architectural considerationsArchitectural considerationsExample: Four layer architectureExample: Four layer architecture

Application layerApplication layer Transaction control

Services/middleware layerServices/middleware layer Support services for applications Eg., DBMS, Object reference brokers

Operating system layerOperating system layer Memory management, scheduling and process control

HardwareHardware Includes firmware


Architectural considerationsArchitectural considerations

Select the correct layer for a mechanismSelect the correct layer for a mechanism Controlling user actions may be more effective at

application layer Controlling file access may be more effective at the

operating system layer Recall PEM!

How to secure layers lower to target layerHow to secure layers lower to target layer Application security means OS security as well Special-purpose OS? All DBMSs require the OS to provide specific security

features


Build or Add?Build or Add?

Security is an integral part of a systemSecurity is an integral part of a system Address security issues at system design phase Easy to analyze and assure

Reference monitor (total mediation!)Reference monitor (total mediation!) Mediates all accesses to objects by subjects

Reference validation mechanism must be– Reference validation mechanism must be– 1. Tamperproof2. Never be bypassed3. Small enough to be subject to analysis and testing –

the completeness can be assured Security kernelSecurity kernel

Hardware + software implementing a RM


Trusted Computing BaseTrusted Computing Base

TCB consists of all protection mechanisms TCB consists of all protection mechanisms within a computer system that are responsible within a computer system that are responsible for enforcing a security policyfor enforcing a security policy

TCB monitors four basic interactionsTCB monitors four basic interactions Process activation Execution domain switching Memory protection I/O operation

A unified TCB may be too largeA unified TCB may be too large Create a security kernel


Security Policy RequirementsSecurity Policy Requirements

Can be done at different levelsCan be done at different levels Specification must be Specification must be

Clear “meet C2 security”

Unambiguous “users must be identified and authenticated”

Complete Methods of defining policiesMethods of defining policies

Extract applicable requirements from existing security standards (e.g. Common Criteria)

Create a policy based on threat analysis Map the system to an existing model

Justify the requirements: Justify the requirements: completenesscompleteness and and consistencyconsistency


Design assuranceDesign assurance

Identify design flawsIdentify design flaws Enhances trustworthiness Supports implementation and operational

assuranceDesign assurance technique employsDesign assurance technique employs

Specification of requirements Specification of the system design Process to examine how well the design meets

the requirement


Techniques for Design AssuranceTechniques for Design Assurance

Modularity & LayeringModularity & Layering Well defined independent modules Simplifies and makes system more understandable Data hiding Easy to understand and analyze

Different layers to capture different levels of abstractionDifferent layers to capture different levels of abstraction Subsystem (memory management, I/O subsystem, credit-

card processing function) Subcomponent (I/O management, I/O drivers) Module: set of related functions and data structure

Use principles of secure designUse principles of secure design


Design DocumentsDesign Documents

Design documentation is an important component in life Design documentation is an important component in life cycle modelscycle models

Documentation must specifyDocumentation must specify Security functions and approach

Describe each security function Overview of a set of security functions Map to requirements (tabular)

External interfaces used by users Parameters, syntax, security constraints and error conditions Component overview, data descriptions, interface description

Internal design with low-level details Overview of the component Detailed description of the component Security relevance of the component


Design meets requirements? Design meets requirements?

Techniques neededTechniques needed To prevent requirements and functionality from being

discarded, forgotten, or ignored at lower levels of design Requirements tracingRequirements tracing

Process of identifying specific security requirements that are met by parts of a description

Informal CorrespondenceInformal Correspondence Process of showing that a specification is consistent

with an adjacent level of specification


Requirement mapping and informal Requirement mapping and informal correspondencecorrespondence

Security Functional Requirements

External Functional Specification

Internal Design Specification

Implementation CodeRequirement

Tracing

InformalCorrespondence


Design meets requirements?Design meets requirements?

Informal argumentsInformal arguments Protection profiles

Define threats to systems and security objectives Provide rationale (an argument)

Security targets Identifies mechanisms and provide justification

Formal methods: proof techniquesFormal methods: proof techniques Formal proof mechanisms are usually based on logic

(predicate calculus) Model checking

Checks that a model satisfies a specification


Design meets requirements?Design meets requirements?

ReviewReview When informal assurance technique is used Usually has three parts

Reviews of guidelines Conflict resolution methods Completion procedures


Implementation considerations for Implementation considerations for assuranceassurance

Modularity with minimal interfacesModularity with minimal interfaces Language choiceLanguage choice

C programs may not be reliable Pointers – memory overwrites Not much error handling Writing past the bounds of memory and buffers

• Notorious for Buffer overflow! Java

Designed to support secure code as a primary goal Ameliorates C security risks present in C Sandbox model (mobile code security)


Assurance through Implementation Assurance through Implementation managementmanagement

Configuration management toolsConfiguration management tools Control of the refinement and modification of

configuration items such as source code, documentation etc.

CM system functions Version control and tracking Change authorization Integration procedures Tools for product generation

CVS?


Implementation meets Design?Implementation meets Design?

Security testing Security testing Functional testing (FT) (black box testing)

Testing of an entity to determine how well it meets its specification

Structural testing (ST) (white box testing) Testing based on an analysis of the code to develop test cases

Testing occurs at different timesTesting occurs at different times Unit testing (usually ST): testing a code module before

integration System testing (FT): on integrated modules Security testing: product security

Security functional testing (against security issues) Security structural testing (security implementation) Security requirements testing


Code development and testingCode development and testing

Code

Unit test

Integrate

Build system

Execute systemTest on current Build

Code

Test the testOn current build

Integrate testedtest into automated

Test suite

Build test suite

Codebugs


Operation and maintenance assuranceOperation and maintenance assurance

Bugs in operational phase need fixingBugs in operational phase need fixingHot fixHot fix

Immediate fix Bugs are serous and critical

Regular fixRegular fix Less serious bugs Long term solution after a hot fix