ee579u/4 #1 spring 2004 © 2000-2004, richard a. stanley ee579u information systems security and...
Post on 20-Dec-2015
213 Views
Preview:
TRANSCRIPT
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/4 #1
EE579UInformation Systems Security
and Management4. Application Development Security
Professor Richard A. Stanley
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/4 #2
Overview of Today’s Class
• Review of last class
• Application Development Security
Spring 2004© 2000-2004, Richard A. Stanley
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.
Spring 2004© 2000-2004, Richard A. Stanley
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
Spring 2004© 2000-2004, Richard A. Stanley
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)
Spring 2004© 2000-2004, Richard A. Stanley
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
Spring 2004© 2000-2004, Richard A. Stanley
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?
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/4 #8
The Three Supermarkets
• Problem: how to cut shrinkage?
• Solutions:– RF tags– Face recognition– Self checkout
Ref: Anderson, 22.2.1
Spring 2004© 2000-2004, Richard A. Stanley
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?
Spring 2004© 2000-2004, Richard A. Stanley
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
Spring 2004© 2000-2004, Richard A. Stanley
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
Spring 2004© 2000-2004, Richard A. Stanley
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.
Spring 2004© 2000-2004, Richard A. Stanley
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
Spring 2004© 2000-2004, Richard A. Stanley
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
Spring 2004© 2000-2004, Richard A. Stanley
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
Spring 2004© 2000-2004, Richard A. Stanley
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
Spring 2004© 2000-2004, Richard A. Stanley
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)
Spring 2004© 2000-2004, Richard A. Stanley
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
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/4 #19
Methodologies
• Waterfall model
• Iterative model
• Exploratory programming
• Prototyping
• Formal transformation
• Reusable components
• Extreme programming
Spring 2004© 2000-2004, Richard A. Stanley
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
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/4 #21
Waterfall Model View
Requirements
Specification
Implement/Unit test
Integration/System test
Opns & Maintenance
Refine
Code
Build
Field
Validate
Validate
Verify
Verify
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/4 #22
Waterfall Model Advantages
• Easy to control
• Limits cross-team interaction
• Relatively easy to estimate resources
• Nicely compatible with project management schemes
Spring 2004© 2000-2004, Richard A. Stanley
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?
Spring 2004© 2000-2004, Richard A. Stanley
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
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/4 #25
Spiral Model
http://www.cc.gatech.edu/classes/cs3302_98_winter/1-08-mgt/sld012.htm
Spring 2004© 2000-2004, Richard A. Stanley
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
Spring 2004© 2000-2004, Richard A. Stanley
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.”
Spring 2004© 2000-2004, Richard A. Stanley
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
Spring 2004© 2000-2004, Richard A. Stanley
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
Spring 2004© 2000-2004, Richard A. Stanley
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
Spring 2004© 2000-2004, Richard A. Stanley
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?
Spring 2004© 2000-2004, Richard A. Stanley
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
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/4 #33
Threat Tree: Human Actors
Using Network Access
http://www.cert.org/archive/pdf/OCTAVEthreatProfiles.pdf
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/4 #34
Threat Tree: Human Actors Using Physical
Access
http://www.cert.org/archive/pdf/OCTAVEthreatProfiles.pdf
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/4 #35
http://www.cert.org/archive/pdf/OCTAVEthreatProfiles.pdf
Threat Tree: System
Problems
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/4 #36
Threat Tree: Other
Problems
http://www.cert.org/archive/pdf/OCTAVEthreatProfiles.pdf
Spring 2004© 2000-2004, Richard A. Stanley
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
Spring 2004© 2000-2004, Richard A. Stanley
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
Spring 2004© 2000-2004, Richard A. Stanley
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
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/4 #40
Managing the Process
• Risk management
• Using parallel processes
• Real world economics
• Real world sociology
• Real world politics
• Providing for audits
Spring 2004© 2000-2004, Richard A. Stanley
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
Spring 2004© 2000-2004, Richard A. Stanley
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.”
Spring 2004© 2000-2004, Richard A. Stanley
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
Spring 2004© 2000-2004, Richard A. Stanley
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?
Spring 2004© 2000-2004, Richard A. Stanley
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
Spring 2004© 2000-2004, Richard A. Stanley
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
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/4 #47
Auditing Guidelines
• ISO 17799
• COBIT (Control Objectives for Information and Related Technology)
• ISO 9001 (maybe)
Spring 2004© 2000-2004, Richard A. Stanley
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)
Spring 2004© 2000-2004, Richard A. Stanley
EE579U/4 #49
A Parting Thought
• “Management is that for which is no algorithm. Where there is an algorithm, it’s administration.”
» Roger Needham
Spring 2004© 2000-2004, Richard A. Stanley
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?
top related