Transcript Lecture 1 - School of Information Sciences

Assurance
Nov 15, 2005
IS2150/TEL2910: Introduction of Computer Security
1
Overview
Trust
Problems from lack of assurance
Types of assurance
Life cycle and assurance
Waterfall life cycle model
Other life cycle models
IS2150/TEL2910: Introduction of Computer Security
2
Trust
 Trustworthy entity has sufficient credible
evidence leading one to believe that the system
will meet a set of requirements
 Trust is a measure of trustworthiness relying on
the evidence
 Assurance is confidence that an entity meets its
security requirements based on evidence
provided by the application of assurance
techniques
Formal methods, design analysis, testing etc.
IS2150/TEL2910: Introduction of Computer Security
3
Relationships
P olicy
Statement of requirement s that explicit ly defines
t he security expect ations of the mechanism(s)
Assurance
P rovides just ification that the mechanism m eet s polic
t hrough assurance evidence and approvals based on
evidence
Mechanisms
Executable entities t hat are designed and implemented
t o meet t he requirements of the policy
Evaluation standards
Trusted Computer System Evaluation Criteria
Information Technology Security Evaluation Criteria
Common Criteria
IS2150/TEL2910: Introduction of Computer Security
4
Problem Sources (Neumann)
1.
2.
3.
4.
5.
6.
7.
8.
9.
Requirements definitions, omissions, and mistakes
System design flaws
Hardware implementation flaws, such as wiring and chip
flaws
Software implementation errors, program bugs, and
compiler bugs
System use and operation errors and inadvertent mistakes
Willful system misuse
Hardware, communication, or other equipment malfunction
Environmental problems, natural causes, and acts of God
Evolution, maintenance, faulty upgrades, and
decommissions
IS2150/TEL2910: Introduction of Computer Security
5
Examples
 Challenger explosion (1986)
Sensors removed from booster rockets to meet
accelerated launch schedule
 Deaths from faulty radiation therapy system
Hardware safety interlock removed
Flaws in software design
 Bell V22 Osprey crashes
Failure to correct for malfunctioning components; two
faulty ones could outvote a third
 Intel 486 chip bug (trigonometric function)
Cost a lot of time and money
IS2150/TEL2910: Introduction of Computer Security
6
Role of Requirements
Requirements are statements of goals that
must be met
Vary from high-level, generic issues to lowlevel, concrete issues
Security objectives are high-level security
issues and business goals
Security requirements are specific,
concrete issues
IS2150/TEL2910: Introduction of Computer Security
7
Types of Assurance
 Policy assurance is evidence establishing
security requirements in policy is complete,
consistent, technically sound
To counter threats and meet objectives
 Design assurance is evidence establishing
design sufficient to meet requirements of
security policy
 Implementation assurance is evidence
establishing implementation consistent with
security requirements of security policy
Need to use good engineering practices
IS2150/TEL2910: Introduction of Computer Security
8
Types of Assurance
Operational assurance is evidence
establishing system sustains the security
policy requirements during installation,
configuration, 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.
IS2150/TEL2910: Introduction of Computer Security
9
Assurance steps
Security requirement s
2
3
Design
Assurance
justification
4
Design and
im plem ent at ion
refinement
1
Implement ation
IS2150/TEL2910: Introduction of Computer Security
10
Life Cycle
Conception
Manufacture
Deployment
Fielded Product Life
IS2150/TEL2910: Introduction of Computer Security
11
Conception
 Idea
 Decisions to pursue it
 Proof of concept
 See if idea has merit
 Rapid prototyping, analysis, etc.
 High-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?
IS2150/TEL2910: Introduction of Computer Security
12
Manufacture
 Develop 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 entity
Includes decisions whether to proceed, for example due
to market needs
 May be the longest stage
IS2150/TEL2910: Introduction of Computer Security
13
Deployment
Delivery
Assure that correct (assured) masters are
delivered to production and protected
Distribute to customers, sales organizations
Installation and configuration
Developers must ensure that the system
operates properly in the production environment
IS2150/TEL2910: Introduction of Computer Security
14
Fielded Product Life
Routine maintenance, patching
Responsibility of engineering in small
organizations
Responsibility may be in different group than
one that manufactures product
Customer service, support organizations
Answering questions; recording bugs
Retirement or decommission of product
Migration plans for customers
IS2150/TEL2910: Introduction of Computer Security
15
Waterfall Life Cycle Model
Requirements definition and analysis
Functional and non-functional
General (for customer), specifications
System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance
IS2150/TEL2910: Introduction of Computer Security
16
Relationship of Stages
Requirements
definition and
analysis
System and
software
design
Implementation
and unit
testing
Integration
and system
testing
IS2150/TEL2910: Introduction of Computer Security
Operation
and
maintenance
17
Other Models of
Software Development
 Exploratory 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)
Objective is to establish system requirements
Future iterations (after first) allow assurance techniques
IS2150/TEL2910: Introduction of Computer Security
18
Models
 Formal transformation
Create formal specification
Translate it into program using correctnesspreserving transformations
Very conducive to assurance methods
 System 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
IS2150/TEL2910: Introduction of Computer Security
19
Models
 Extreme 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
IS2150/TEL2910: Introduction of Computer Security
20
Key Points
Assurance critical for determining
trustworthiness of systems
Different levels of assurance, from
informal evidence to rigorous
mathematical evidence
Assurance needed at all stages of system
life cycle
IS2150/TEL2910: Introduction of Computer Security
21
Threats and Vulnerabilities
 Threat
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
 Vulnerability
 A weakness that makes it possible for a threat to occur
IS2150/TEL2910: Introduction of Computer Security
22
Architectural considerations
Determine the focus of control of security
enforcement mechanism
Operating system: focus is on data
Applications: more on operations/transactions
Centralized or Distributed
Distribute them among systems/components
Tradeoffs?
Generally easier to “assure” centralized system
Security mechanism may exist in any layer
IS2150/TEL2910: Introduction of Computer Security
23
Architectural considerations
Example: Four layer architecture
 Application layer
Transaction control
 Services/middleware layer
Support services for applications
Eg., DBMS, Object reference brokers
 Operating system layer
Memory management, scheduling and process control
 Hardware
Includes firmware
IS2150/TEL2910: Introduction of Computer Security
24
Architectural considerations
 Select 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 layer
Application security means OS security as well
Special-purpose OS?
All DBMSs require the OS to provide specific security
features
IS2150/TEL2910: Introduction of Computer Security
25
Build or Add?
 Security is an integral part of a system
 Address security issues at system design phase
 Easy to analyze and assure
 Reference monitor (total mediation!)
 Mediates all accesses to objects by subjects
 Reference validation mechanism must be–
1. Tamperproof
2. Never be bypassed
3. Small enough to be subject to analysis and testing –
the completeness can be assured
 Security kernel
 Hardware + software implementing a RM
IS2150/TEL2910: Introduction of Computer Security
26
Trusted Computing Base
 TCB consists of all protection mechanisms
within a computer system that are responsible
for enforcing a security policy
 TCB monitors four basic interactions
Process activation
Execution domain switching
Memory protection
I/O operation
 A unified TCB may be too large
Create a security kernel
IS2150/TEL2910: Introduction of Computer Security
27
Security Policy Requirements
 Can be done at different levels
 Specification must be
 Clear
 “meet C2 security”
 Unambiguous
 “users must be identified and authenticated”
 Complete
 Methods 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: completeness and consistency
IS2150/TEL2910: Introduction of Computer Security
28
Design assurance
Identify design flaws
Enhances trustworthiness
Supports implementation and operational
assurance
Design assurance technique employs
Specification of requirements
Specification of the system design
Process to examine how well the design meets
the requirement
IS2150/TEL2910: Introduction of Computer Security
29
Techniques for Design Assurance
 Modularity & 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 abstraction
 Subsystem (memory management, I/O subsystem, creditcard processing function)
 Subcomponent (I/O management, I/O drivers)
 Module: set of related functions and data structure
 Use principles of secure design
IS2150/TEL2910: Introduction of Computer Security
30
Design Documents
 Design documentation is an important component in life
cycle models
 Documentation 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
IS2150/TEL2910: Introduction of Computer Security
31
Design meets requirements?
 Techniques needed
To prevent requirements and functionality from being
discarded, forgotten, or ignored at lower levels of design
 Requirements tracing
Process of identifying specific security requirements that
are met by parts of a description
 Informal Correspondence
Process of showing that a specification is consistent
with an adjacent level of specification
IS2150/TEL2910: Introduction of Computer Security
32
Requirement mapping and informal
correspondence
Security Functional Requirements
External Functional Specification
Internal Design Specification
Requirement
Tracing
Informal
Correspondence
Implementation Code
IS2150/TEL2910: Introduction of Computer Security
33
Design meets requirements?
 Informal arguments
Protection profiles
 Define threats to systems and security objectives
 Provide rationale (an argument)
Security targets
 Identifies mechanisms and provide justification
 Formal methods: proof techniques
Formal proof mechanisms are usually based on logic
(predicate calculus)
Model checking
 Checks that a model satisfies a specification
IS2150/TEL2910: Introduction of Computer Security
34
Design meets requirements?
Review
When informal assurance technique is used
Usually has three parts
Reviews of guidelines
Conflict resolution methods
Completion procedures
IS2150/TEL2910: Introduction of Computer Security
35
Implementation considerations for
assurance
 Modularity with minimal interfaces
 Language 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)
IS2150/TEL2910: Introduction of Computer Security
36
Assurance through Implementation
management
Configuration 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?
IS2150/TEL2910: Introduction of Computer Security
37
Implementation meets Design?
 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 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
IS2150/TEL2910: Introduction of Computer Security
38
Code development and testing
Code
Unit test
Code
Code
bugs
Test the test
On current build
Integrate tested
test into automated
Test suite
Integrate
Build system
Build test suite
Execute system
Test on current Build
IS2150/TEL2910: Introduction of Computer Security
39
Operation and maintenance assurance
Bugs in operational phase need fixing
Hot fix
Immediate fix
Bugs are serous and critical
Regular fix
Less serious bugs
Long term solution after a hot fix
IS2150/TEL2910: Introduction of Computer Security
40