Security Engineering

Security Engineering SPC-2004009-MC Version 3.1 June 2009

Evaluation 1.2.3.4.5.6. Administrative Details

Agenda – 1 Morning • Introduction • Security issues that span the system life cycle • Security issues during concept development and requirements • Security issues during design Day 1 – Security Engineering in the SDLC Afternoon • Security issues during design (cont.) • Security issues during implementation • Security issues during testing • Security issues during deployment and operation • Summary

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

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

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

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

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

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

Contents of Notebook – 1

Contents of Notebook – 2

SSCI Today 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 Beyond process improvement—impacting member growth

SSCI’s Security Focus Security Engineering “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 companiesin many aspects of security

For More Information • LM Account Team • Michael Brandischok (member relations): brandischok@systemsandsoftware.org, 703-742-7179 • Susan Rose (technical program): rose@systemsandsoftware.org, 703-742-7252 • Bob Small (security / agile): small@systemsandsoftware.org, 703-742-7122 • Clearinghouse (general questions): ask-spc@systemsandsoftware.org, 800-827-4772 Go to www.systemsandsoftware.org and selectFor Members Onlyto download documents

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

“Security engineering is about building systems to remain dependable in the face of malice, error, and mischance.” 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.” From Ross Anderson, Security Engineering

“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.” Security Engineering Mindset “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 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.” From Bruce Schneier, Crypto-Gram, April 15, 2008

Think Creatively About Information Security Catch Me If You Can The Italian Job The Shawshank Redemption

Auto- coordinated Attack Sophistication Cross-site scripting “stealth”/ advanced scanning techniques Intruder Knowledge denial ofservice High Staged packet spoofing distributed attack tools sniffers sweepers www attacks GUI automated probes/scans back doors network mgmt. diagnostics disabling audits hijacking sessions burglaries exploiting known vulnerabilities password cracking self-replicating code password guessing Low 2000 1980 1985 1990 1995 Evolving Threat Environment Today cyber crime is state sponsored and organized; see Russian Business Network Source: Pethia, Rich. Internet Security Trends. Pittsburgh Pennsylvania: Carnegie Mellon University, 2001.

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

Incidents Reported to CERT CERT discontinued reporting this information in 2003 Source: http://www.cert.org/stats/cert_stats.html

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

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

Canonical Attacks Eve Eavesdropping Alice Bob Eve Denial of service Alice Bob Eve “Man” in the middle Alice Bob

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 system Source: RFC 4949, Internet Security Glossary V2, August 2007, http://tools.ietf.org/html/rfc4949

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

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

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

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

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.

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, …)

Development Legend O Principal emphasis for key practice Concept Dev./Requirements Design • Secondary emphasis for key practice Spanning the Life Cycle Deployment and Operation Testing X Key practice does not apply Implementation Key Practices Designate a security engineering advocate O • • • • • Create a security engineering plan O • • • • • Learn from past security mistakes O • • • • • Understand security in the system’s operational environment X • O • • • Specify security requirements X O X X X X Analyze system threats and vulnerabilities X X O • • O Use security engineering guiding principles X • O • • • Validate system inputs X • • O • X Secure COTS applications X • X O • • Secure outsourced software X • X O • • Implement a coherent audit policy X • O • • • Key Practices by Life-cycle Phase

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

Security Engineering