Security Engineering

Copyright © 2009, Systems and Software Consortium, Inc.

www.systemsandsoftware.org

Security Engineering

SPC-2004009-MC

Version 3.1

June 2009

1-2Copyright © 2009, Systems and Software Consortium, Inc.


Version 3.1

Administrative Details

Evaluation

1.2.3.4.5.6.



Version 3.1

Agenda – 1

Morning• Introduction• Security issues that

span the system life cycle

• Security issues during concept development and requirements

• Security issues during design

Afternoon• Security issues during

design (cont.)• Security issues during

implementation• Security issues during

testing• Security issues during

deployment and operation

• Summary

Day 1 – Security Engineering in the SDLC



Version 3.1

Agenda – 2

Attacks Module• Attacks on people,

networks, applications• Web-based attacks• Buffer overflow• Summary

Day 2 – Optional - Negotiable

Information Assurance Module

• DoD-D-8500.1, IA• DoD-I-8500.2, IA

Guidance• Certification &

Accreditation• DoD 8570.01, IA

Workforce Improvement• Common Criteria• Risk Assessment



Version 3.1

Course Objectives

After completing this course, you should be able to

• Understand the security engineering challenge• Describe how security can be “engineered in,”

throughout the systems development lifecycle (SDLC)

• Improve the “security awareness” of your SDLC• Understand the anatomy of the most important

computer attacks• Understand DoD systems security engineering

strategy and requirements



Version 3.1

What Are the Benefits?

• Intentional decision making about the system’s security properties

• Effective use of limited resources by– Making security-aware decisions throughout the

SDLC– Building in security rather than bolting it on at

the end– Reducing rework

• Reduced system vulnerabilities to avoid threats

• More effective, defense-in-depth solutions• Leverage DoD’s strategy to work for you



Version 3.1

Intended Audience

• Systems and software engineers

• Project / product managers

• Test engineers• System operators and

administrators

Everyone concerned with improving the security of the

system you are building



Version 3.1

Your Course Priorities

• Please finish the following sentence:“I really liked this course because …”

• Pretend the course is over• You are telling me what made it worthwhile

for you• I will try to make your prediction come true

by– Emphasizing particular aspects of the

course—or …– Skipping some parts in order to bring in

optional materials

• We’ll evaluate how we did at the end



Version 3.1

Introductions

Please introduce yourself to everyone• Name• Organization• What you do• Background• Expectations

1-10



Version 3.1

Contents of Notebook – 1

TAB Topic1 Introduction

2 Life Cycle Issues

3 Concept Development & Requirements Issues

4 Design Issues

5 Implementation Issues

6 Testing Issues

7 Deployment and Operation Issues

8 Summary

9 Attacks on People, Networks, Applications

10 Web-based Attacks

1-11



Version 3.1

Contents of Notebook – 2

TAB Topic11 Buffer Overflows12 Summary13 DoD-D-8500.1, IA14 DoD-I-8500.2, IA Guidance15 Certification & Accreditation16 DoD 8570.01, IA Workforce Improvement1718

Common CriteriaRisk Assessment

A Acronyms and AbbreviationsB ReferencesC Common Threats and Mitigations

1-12



Version 3.1

SSCI Today

Beyond process improvement—impacting member

growth

Beyond process improvement—impacting member

growth

Founded to facilitate collaboration among our members, who are leaders in Federal/Commercial marketplace

Focused on the challenges of complex system and software development

Committed to the business performance of our members

Structured to provide “neutral ground” and a voice for industry

Systems and Software Engineering

– Architecture– Disciplined Agility– Measurement, analysis & estimation– Model-based development & testing– Product line engineering and reuse – Requirements– Security– Systems engineering– Verification & validation

Process Improvement– Process implementation– Compliance frameworks– Process appraisals up to level 5– Appraisal preparation– Framework models & maps– Team participation in the development

of standards

1-13



Version 3.1

SSCI’s Security Focus


“Security is an emergent system

property, not merely the sum

of the security features”•Enhancing the security

awareness of the SDLC

•Ensuring security is built in, not bolted on and avoiding rework

•Balancing security with other imperatives (e.g., schedule, cost, functionality)

Information Assurance (IA)“What is the value of our

information assets and how do we know

they are adequately protected?”

• Planning and implementing an organization’s information security management system (ISMS)

• Satisfying government requirements for security certification and accreditation

We have consultedwith member companies

in many aspects of security

1-14



Version 3.1

For More Information

Go to www.systemsandsoftware.org and

selectFor Members Only

to download documents

LM Account Team

• Michael Brandischok (member relations): [email protected], 703-742-7179

• Susan Rose (technical program): [email protected], 703-742-7252

• Bob Small (security / agile): [email protected], 703-742-7122

• Clearinghouse (general questions): [email protected], 800-827-4772

1-15



Version 3.1

Security Challenges

• Systems today are exposed to more security threats than ever before– Increasing connectivity, complexity, and commonality– Increasing population of hackers and exploits– Instant global communication of vulnerabilities

• Engineering secure systems requires activities and decisions throughout the life cycle– Bolting on security late in development generally does

not work– Engineers cannot build secure systems unless they

understand threats and vulnerabilities– Engineers are generally not trained in processes for

threat identification and mitigation

Security Engineering – It Takes A Process

1-16



Version 3.1

Security Engineers Think Differently

“Security engineering requires cross-disciplinary expertise, ranging from cryptography and computer security through hardware tamper-resistance and formal methods to a knowledge of applied psychology, organizational and audit methods and the law.”

“Systems engineering skills, from business process analysis through software engineering to evaluation and testing, are also important; but they are not sufficient, as they deal only with error and mischance rather than malice.”

“Security engineering is about building systems to remain dependable in the face of malice, error, and mischance.”

From Ross Anderson, Security Engineering

1-17



Version 3.1

“Security requires a particular mindset. Security professionals -- at least the good ones -- see the world differently. They can't walk into a store without noticing how they might shoplift. They can't use a computer without wondering about the security vulnerabilities. They can't vote without trying to figure out how to vote twice. They just can't help it.”

“This kind of thinking is not natural for most people. It's not natural for engineers. Good engineering involves thinking about how things can be made to work; the security mindset involves thinking about how things can be made to fail. It involves thinking like an attacker, an adversary or a criminal. You don't have to exploit the vulnerabilities you find, but if you don't see the world that way, you'll never notice most security problems.”

Security Engineering Mindset

From Bruce Schneier, Crypto-Gram, April 15, 2008

“The lack of a security mindset explains a lot of bad security out there: voting machines, electronic payment cards, medical devices, ID cards, internet protocols. The designers are so busy making these systems work that they don't stop to notice how they might fail or be made to fail, and then how those failures might be exploited. Teaching designers a security mindset will go a long way toward making future technological systems more secure.”

1-18



Version 3.1

Think Creatively About Information Security

Catch Me If You Can

The Shawshank Redemption

The Italian Job

1-19



Version 3.1

Evolving Threat Environment

1980 1985 1990 1995

AttackSophistication

High

Low

2000

IntruderKnowledge

Cross-site scripting

password guessing

self-replicating code

password cracking

exploiting known vulnerabilities

disabling audits

back doors

hijacking sessions

sweepers

sniffers

packet spoofing

GUI automated probes/scans

denial ofservice

www attacks

“stealth”/ advanced scanning

techniques

burglaries

network mgmt. diagnostics

distributedattack tools

Staged

Auto- coordinated

Source: Pethia, Rich. Internet Security Trends. Pittsburgh Pennsylvania: Carnegie Mellon University, 2001.

Today cyber crime is state sponsored and organized; see Russian Business Network

1-20



Version 3.1

Vulnerabilities Reported to CERT

Number of Vulnerabilities Reported

Source: http://www.cert.org/stats/ As of 4q08, CERT has stopped collecting and publishing this data

3q08

1-21



Version 3.1

Incidents Reported to CERT

Source: http://www.cert.org/stats/cert_stats.html

0

20,000

40,000

60,000

80,000

100,000

120,000

140,000

160,000CERT discontinued reporting this information

in 2003

1-22



Version 3.1

System Attributes with Security Implications

• Information: Classified, unclassified, proprietary, confidential, private, public

• Users: Restricted set of employees, all employees, business partners, general public

• Connectivity: Internet, private network, stand alone

• Integration of COTS and new code• Special requirements for safety, availability, or

other system attributes• Degree of system complexity• Use of new technology• Requirements for certification and accreditation

1-23



Version 3.1

Basic Security Properties

• Confidentiality: Information is not made available or disclosed to unauthorized individuals, entities, or processes

• Integrity: Information is not changed, destroyed, or lost in an unauthorized or accidental manner

• Availability: A system or resource is accessible and usable on demand by an authorized system entity, according to the system’s performance specifications

• Secondary properties: Accountability, authentication, authorization, non-repudiation, privacy, transparency, timeliness, trusted, …

Source: RFC 2828, Internet Security Glossary, May 2000, http://www.faqs.org/rfcs/rfc2828.html

1-24



Version 3.1

Canonical Attacks

Alice

Eve

Bob

Alice

Eve

Bob

Alice

Eve

Bob

Eavesdropping

Denial of service

“Man” in the middle

1-25



Version 3.1

Basic Security Terminology

• Vulnerability: A flaw or weakness in a system’s design, implementation, or operation and management that could be exploited to violate the system’s security policy

• Threat: A potential for violation of security, which exists when there is a circumstance, capability, action, or event that could breach security and cause harm

• Risk: An expectation of loss expressed as the probability that a particular threat will exploit a particular vulnerability with a particular harmful result

• Attack: An assault on system security that derives from an intelligent threat, i.e., an intelligent act that is a deliberate attempt to evade security services and violate the security policy of a systemSource: RFC 4949, Internet Security Glossary V2, August 2007,

http://tools.ietf.org/html/rfc4949

1-26



Version 3.1

Common Attacks* – 1

• Network attacks: Sniffing, spoofing, session hijacking, denial of service, reconnaissance

• Host attacks: Malware, footprinting, password cracking, denial of service, arbitrary code execution, unauthorized access

• Application attacks– Input validation: Buffer overflow, Cross-site

scripting (XSS), SQL injection, canonicalization– Authentication: Network eavesdropping, brute

force attack, dictionary attack, cookie replay, credential theft, social engineering

* See Tab C for descriptions of these attacks and mitigation approaches

1-27



Version 3.1

Common Attacks – 2

• Application attacks (cont.)– Authorization: Elevation of privilege, disclosure of

confidential data, data tampering, luring attacks– Configuration management: Unauthorized access

to administrative interfaces, unauthorized access to configuration stores, retrieval of plaintext configuration secrets, lack of individual accountability, over-privileged process and service accounts

– Sensitive data: Access to sensitive data in storage, network eavesdropping, data tampering

– Session management: Session Hijacking, session replay, man in the middle

1-28



Version 3.1

Common Attacks – 3

• Application attacks (cont.)– Cryptography: Poor key generation or key

management, weak or custom encryption, checksum spoofing

– Parameter manipulation: Query string manipulation, form field manipulation, cookie manipulation, HTTP header manipulation

– Exception management: Attack reveals implementation details, denial of service

– Auditing and logging: User denies performing an operation, attackers exploit an application without leaving a trace, attackers cover their tracks

1-29



Version 3.1

Understanding Security Implicationsof Development Decisions

• Do the customer and the developers understand the security implications of the system in its operational environment?

• Does the development team understand that each decision they make, from the earliest conceptualization of the system through deployment, might have security implications?

Goal: Make proactive, informed decisions about matters of consequence to the

system’s security characteristics and behavior

1-30



Version 3.1

Security Engineering: Key Practices

• Designate a security engineering advocate (KP1)• Create a security engineering plan (KP2)• Learn from past security mistakes (KP3)• Understand security in the system’s operational

environment (KP4)• Specify security requirements (KP5)• Analyze system threats and vulnerabilities (KP6) • Use security engineering guiding principles (KP7)• Validate system inputs (KP8)• Secure COTS applications (KP9)• Secure outsourced software (KP10)• Implement a coherent audit policy (KP11)

Source: Systems and Software Consortium, Inc.. Key Practices for Engineering Security Into Mission-Critical Systems, SPC-2003071-MC, version SPC-2003071-MC. Herndon, Virginia: Systems and Software Consortium, Inc. 2003.

1-31



Version 3.1

Applying the Key Practices

Life-cycle stages• Spanning the life cycle• Concept development and requirements• Design• Implementation• Testing• Deployment and operation

Activities are independent of the process model (e.g., spiral,

waterfall, …)

1-32



Version 3.1

Key Practices by Life-cycle Phase

•••O•XImplement a coherent audit policy••OX•XSecure outsourced software••OX•XSecure COTS applicationsX•O••XValidate system inputs•••O•XUse security engineering guiding principlesO••OXXAnalyze system threats and vulnerabilitiesXXXXOXSpecify security requirements•••O•XUnderstand security in the system’s operational environment•••••OLearn from past security mistakes•••••OCreate a security engineering plan•••••ODesignate a security engineering advocate

Key practice does not applyX

Secondary emphasis for key practice•

Principal emphasis for key practiceO

Legend

Sp

ann

ing

th

e L

ife

Cyc

le

Co

nce

pt

Dev

./R

eq

uir

emen

ts

Dep

loym

ent

and

Op

era

tio

n

Des

ign

Tes

tin

g

Imp

lem

enta

tio

n

Development

Key Practices

1-33



Version 3.1

Topic Summary

• Systems that you develop are exposed to increasingly severe threats

• Increased system complexity is the enemy of security

• Development teams make myriad decisions that affect security

• Know your enemy – think about security from the bad guy’s point of view

• Goal is to make security-aware decisions in order to meet the requirements of the customers and users

• It takes a systems development process that involves certain key practices throughout the life cycle

Documents

Security Engineering