EE579U/4 #1 Spring 2004 © 2000-2004, Richard A. Stanley EE579U Information Systems Security and Management 4. Application Development Security Professor

Spring 2004© 2000-2004, Richard A. Stanley

EE579U/4 #1

EE579UInformation Systems Security

and Management4. Application Development Security

Professor Richard A. Stanley


EE579U/4 #2

Overview of Today’s Class

• Review of last class

• Application Development Security


EE579U/4 #3

Review of Last Class• A security policy is essential to a security posture

in any information system• Policies cannot be ad hoc if they are to be

effective; they must be written, sensible, enforcable, and evaluated

• Enforcement must be part of the policy• Regular audits must be undertaken to ensure the

effectiveness of the policy and to identify needs for change and updates.


EE579U/4 #4

Secure Development? Why?

• Security is like quality– You cannot improve the quality of a poorly-

manufactured product by inspecting it repeatedly

– You cannot improve the inherent security of software by trying to “bolt it on” after the software development is completed

• Thus, security has to be planned from the start, which means during development


EE579U/4 #5

Some definitions

• Threat: potential occurrence that can have an undesirable effect on the system assets or resources

• Vulnerability: a weakness that makes it possible for a threat to occur

• In general, threats and vulnerabilities are not well-defined at development time (and sometimes, never)


EE579U/4 #6

Balancing Technology and Reality

• Technologists tend to focus on technical solutions to technical problems

• Once the problem is defined, the “goodness” of the definition is rarely questioned

• A crucial issue is whether the problem as defined is actually the one that should be solved


EE579U/4 #7

An Example

• Problem as defined by the techie: Client company has sales of $10M, net profit of $1M, and fraud losses of $150K. Thus, problem is to reduce fraud loss

• Possible client view: Need to increase sales by 100% to $20M. Even if fraud losses remain at a constant percentage, this will provide profit of $1.7M, a 70% increase

• How does a technical solution to the first problem help to solve the second? Which does the client value more?


EE579U/4 #8

The Three Supermarkets

• Problem: how to cut shrinkage?

• Solutions:– RF tags– Face recognition– Self checkout

Ref: Anderson, 22.2.1


EE579U/4 #9

The Real Problem

• Balance risk and reward– Risk and reward is what business is all about– Business incur risk by entering into business

• Much money is spent before any receipts are taken

• If no one pays, business goes bankrupt

– Profit is reward for assuming risk

• How does this coincide with technical problem definition and solution?


EE579U/4 #10

Typical Security Problems

• “Just Say No”

• Failure to understand the business

• Focus on problems absent an understanding of the importance of the problem

• Inward- vs. outward-looking


EE579U/4 #11

Organizational Problems

• Risk thermostat

• Security/reliability interaction

• Solving the wrong problem

• Incompetent/inexperienced security staff

• Accountability

• Self-fulfilling prophesies

• Blame shared is blame diminished


EE579U/4 #12

Developmental Issues

• What problems to solve?

• Focus

• Methodology– Is the desired output a quality product, or strict

adherence to a methodology? Don’t be too quick to decide.


EE579U/4 #13

Lipner’s Security Requirements

• Users will not write their own programs• Program development will not be done on

production systems• Special process required to install program from

development to production system• The above special process must be both controlled

and audited• Managers and auditors must have access to both

system state and system logs


EE579U/4 #14

Principles of Operation

• These follow from Lipner’s Rules• Separation of duties

– Critical functions broken into steps, where no single individual can perform all needed steps

• Separation of functions– Development and production systems separated to prevent

info leakage from one to the other

• Audit– Analyze what actually was done, compare to policies,

identify inappropriate actions (if any)– Done by still another group of individuals from above


EE579U/4 #15

Life Cycle

• Systems have life cycles, just as do people• The life cycle begins with the statement of

specifications• The life cycle ends when the system is totally

phased out• Systems development must deal with security at

all phases of the life cycle• Minimizing cost over the life cycle is often a goal,

and is monumentally hard to measure


EE579U/4 #16

Life Cycle Stages

• Conception– Requirements definition– Specification development

• Manufacture– Detailed planning of each activity– Software development– Testing

• Deployment– Initial roll-out– Continued field support

• Retirement


EE579U/4 #17

Assurance and Requirements

• Assurance is confidence that an entity meets its security requirements, based on specific evidence provided by the application of assurance techniques

• Requirement is a statement of system goals that must be satisfied by the design

• Trusted System has been shown to meet well-defined requirements under credible evaluation by a disinterested third party (certification of the evaluator may be required)


EE579U/4 #18

More Assurance

• Policy Assurance is evidence establishing that the security requirements in the policy is complete, consistent, and technically sound

• Design Assurance is evidence that a design is sufficient to meet the security policy requirements

• Implementation Assurance is evidence establishing that the system implementation is consistent with the security policy requirements

• Operational Assurance is evidence that system sustains the the security policy requirements during installation, configuration, and operation


EE579U/4 #19

Methodologies

• Waterfall model

• Iterative model

• Exploratory programming

• Prototyping

• Formal transformation

• Reusable components

• Extreme programming


EE579U/4 #20

Top-Down Design: The Waterfall Model

• Evaluate the problem—This is where the concept is born. • Identify deficiencies with existing solutions and gather information. • Propose a solution—Present a detailed description of the solution, including pros

and cons and the problems the software will address. Finalize timelines, budgets, work breakdown structures, and other supporting documentation. Most importantly, identify and analyse requirements.

• Design the architecture—Once the proposal has been accepted, create models of the solution, including workflow and dataflow diagrams, module and functionality layouts, and any other descriptions required by the solution. A vigorous review process usually accompanies this phase.

• Develop the code—Use the blueprints created in previous phases to write, debug, and unit-test the code. Next, integrate the code and test portions of the system. Finally, test the entire system. This cycle isn’t complete until all tests have passed.

• Deploy and use the system—Roll out the resulting functionality and provide training and documentation to users as needed.

• Maintain the solution—Support and upgrade the software when necessary and fix post-production bugs.

http://www.zdnet.com.au/builder/manage/project/story/0,2000035082,20266893,00.htm


EE579U/4 #21

Waterfall Model View

Requirements

Specification

Implement/Unit test

Integration/System test

Opns & Maintenance

Refine

Code

Build

Field

Validate

Validate

Verify

Verify


EE579U/4 #22

Waterfall Model Advantages

• Easy to control

• Limits cross-team interaction

• Relatively easy to estimate resources

• Nicely compatible with project management schemes


EE579U/4 #23

Waterfall Model Disadvantages

• Easy for manager, hard for developers– Testing comes at the end

• Debugging can be complex• Entire system cannot be tested until close to

end of project, a high risk• Feedback nominally occurs only at end of

each phase• If final system fails, how to correct?


EE579U/4 #24

Iterative Development

• Spiral model developed by Barry Boehm, 1986– Boehm led the way in developing software cost models

in the 1980’s most notably COCOMO

– Uses prototypes to refine/define the requirements

– Uses waterfall model for each step• This fact is often overlooked by spiral supporters

– Provided number of iterations is limited (and pre-agreed) risk can be controlled

– Believed to be more flexible than waterfall model


EE579U/4 #25

Spiral Model

http://www.cc.gatech.edu/classes/cs3302_98_winter/1-08-mgt/sld012.htm


EE579U/4 #26

Exploratory Development

• No requirements

• No specifications

• “Quick and dirty” systems are developed, and then modified repeatedly until they achieve the desired performance


EE579U/4 #27

Prototyping

• Similar to exploratory development• BUT…the objective of phase one system is

to refine and produce system requirements• After that, a production-quality system is

developed, perhaps even using another model

• Goal is to avoid “You gave me just what I asked for, but it’s not what I wanted.”


EE579U/4 #28

Formal Transformation

• Begins with formal statement of specification

• Transformed into software by formal, correctness-preserving transforms

• Idea is to produce a system that provably complies to the specification

• This is where Bell and LaPadula and their contemporaries were headed


EE579U/4 #29

System Assembly FromReusable Components

• Objective is to avoid constantly re-developing components that already exist– e.g. sine function calculation

• Presupposes existence of library of tested, reusable components

• May be merged with other development models• Source, compliance of components is an issue

– What if they are in another language?– What is known about security, correctness, etc.?

• A goal of Ada, and a common technique


EE579U/4 #30

Extreme Programming

• Rapid prototyping

• Best practices

• Frequent review and test

• “Build a little, test a lot”

• Vulnerable to lack of an overall security (or any other) architecture

• Common approach for commercial software


EE579U/4 #31

Some Issues

• How define and verify security issues

• How do we write programs whose security can be verified?– Modular programming is often viewed as a

panacea in this role; it is not

• What about verifying the requirements?

• And how about the specification?


EE579U/4 #32

Threat Trees

• Security application of fault-tree analysis– Widely used in insurance industry

• Root is the undesired behavior• Successive nodes are decomposition into

possible causes• Can be expressed as a binary tree or as a

nested outline• Very useful for modeling threats


EE579U/4 #33

Threat Tree: Human Actors

Using Network Access

http://www.cert.org/archive/pdf/OCTAVEthreatProfiles.pdf


EE579U/4 #34

Threat Tree: Human Actors Using Physical

Access



EE579U/4 #35


Threat Tree: System

Problems


EE579U/4 #36

Threat Tree: Other

Problems



EE579U/4 #37

Threat Trees: Some Thoughts

• Threat trees work best when you have some idea of the probability of each threat– Then you can work up the tree along the lines of

highest probability to find the worst problems first

• This methodology can be automated, and simulations run to determine system issues

• It is seductive to allow this methodology to become the end result rather than a tool to produce a secure system


EE579U/4 #38

Failure Modes and Effects Analysis (FMEA)

• Threat tree upside-down: work from failure modes to overall effect– Widely used within NASA

• This is a fairly standard engineering approach in any complex system

• Combining top-down and bottom-up analysis should lead to better systems


EE579U/4 #39

Requirements Creep

• Every system experiences evolution in its requirements; the challenge is to capture and manage the changes– Bug fixes– Controls and governance– Tragedy of the commons– Organizational change


EE579U/4 #40

Managing the Process

• Risk management

• Using parallel processes

• Real world economics

• Real world sociology

• Real world politics

• Providing for audits


EE579U/4 #41

Risk Management

• Annual loss expectancy (ALE) is widely used, and is required in US Government procurements

Loss Type Amount Incidence/Yr ALE

EFT fraud $50,000,000 .005 $250,000

ATM fraud (large) $250,000 .2 $100,000

ATM fraud (small) $20,000 .5 $10,000

Teller fraud $3,240 200 $648,000


EE579U/4 #42

ALE Observations

• Intended to highlight most costly losses

• Vulnerable to poorly defined probabilities– e.g. is the teller fraud really as high as the ALE

seems to show, or is the incidence figure off?

• Vulnerable to jiggering the figures to match funds available– “We want all the security we can afford.”


EE579U/4 #43

Parallel Inputs

• Good ideas are not confined to those at the top of the hierarchical pyramid

• Lots of input can find things single contributors cannot

• Requires a very good, broad-minded “finisher” to collect all the inputs and put into a consolidated requirement, specification, or what have you


EE579U/4 #44

Economics

• How much can be afforded is a very real constraint

• How to reconcile this with security and performance demands?

• How to trade off security and performance or reliability?


EE579U/4 #45

Sociology

• Social engineering– People want to be liked, and most hate

confrontation– This can be used to compromise security

• Groups act differently from individuals

• Organizational culture is important

• Politics are a real facet of real life


EE579U/4 #46

Audits

• Lipner was right• Audits need to be accomplished at all stages

of the development process, to ensure that goals are met and to identify problems

• Objective is not necessary to lay blame, but rather to discover potential problems before they become actual problems

• Auditors must be independent and trusted


EE579U/4 #47

Auditing Guidelines

• ISO 17799

• COBIT (Control Objectives for Information and Related Technology)

• ISO 9001 (maybe)


EE579U/4 #48

Summary

• Developing systems is hard; developing secure systems is even harder

• It is important to define requirements and specifications at the beginning, and to understand what can be traded for what

• Many development models exist; none is the “best” for any particular purpose

• Beware systems that promise tight analytical information where you have sketchy inputs (which you almost always have)


EE579U/4 #49

A Parting Thought

• “Management is that for which is no algorithm. Where there is an algorithm, it’s administration.”

» Roger Needham


EE579U/4 #50

Homework• Reading:

– Bishop, Chapters 18 & 19

• Problems:1. Compare and contrast the waterfall and spiral

development models as concerns their ability to deliver a secure software system on time and within budget. Is the waterfall model fatally flawed?

2. Select a software development from literature or your own experience. Explain the development methods used to ensure security in the final product, and evaluate how well they worked. What could have been done to improve things?

Documents

EE579U/4 #1 Spring 2004 © 2000-2004, Richard A. Stanley EE579U Information Systems Security and Management 4. Application Development Security Professor