www systemsandsoftware org Copyright 2009 Systems and

80dab3d2012e8a3221c3572463bbd723.ppt

Количество слайдов: 33

Security Engineering Agenda – 1 Day 1 – Security Engineering in the SDLC • • Morning Introduction Security issues that span the system life cycle Security issues during concept development and requirements Security issues during design Copyright © 2009, Systems and Software Consortium, Inc. • • • Version 3. 1 Afternoon Security issues during design (cont. ) Security issues during implementation Security issues during testing Security issues during deployment and operation Summary 3

Security Engineering Agenda – 2 Day 2 – Optional - Negotiable • • Attacks Module Attacks on people, networks, applications Web-based attacks Buffer overflow Summary Copyright © 2009, Systems and Software Consortium, Inc. Information Assurance Module • Do. D-D-8500. 1, IA • Do. D-I-8500. 2, IA Guidance • Certification & Accreditation • Do. D 8570. 01, IA Workforce Improvement • Common Criteria • Risk Assessment Version 3. 1 4

Security Engineering 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 Do. D systems security engineering strategy and requirements Copyright © 2009, Systems and Software Consortium, Inc. Version 3. 1 5

Security Engineering 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 Do. D’s strategy to work for you Copyright © 2009, Systems and Software Consortium, Inc. Version 3. 1 6

Security Engineering 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 Copyright © 2009, Systems and Software Consortium, Inc. Version 3. 1 7

Security Engineering 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 Copyright © 2009, Systems and Software Consortium, Inc. Version 3. 1 8

Security Engineering Introductions Please introduce yourself to everyone • Name • Organization • What you do • Background • Expectations Copyright © 2009, Systems and Software Consortium, Inc. Version 3. 1 9

Security Engineering Contents of Notebook – 1 TAB 1 2 3 4 5 6 7 8 9 10 Topic Introduction Life Cycle Issues Concept Development & Requirements Issues Design Issues Implementation Issues Testing Issues Deployment and Operation Issues Summary Attacks on People, Networks, Applications Web-based Attacks Copyright © 2009, Systems and Software Consortium, Inc. Version 3. 1 10

Security Engineering Contents of Notebook – 2 TAB 11 12 13 14 15 16 17 18 A B C Topic Buffer Overflows Summary Do. D-D-8500. 1, IA Do. D-I-8500. 2, IA Guidance Certification & Accreditation Do. D 8570. 01, IA Workforce Improvement Common Criteria Risk Assessment Acronyms and Abbreviations References Common Threats and Mitigations Copyright © 2009, Systems and Software Consortium, Inc. Version 3. 1 11

Security Engineering SSCI Today Systems and Software Engineering 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 Process Improvement Beyond process improvement— impacting member growth Copyright © 2009, Systems and Software Consortium, Inc. Architecture Disciplined Agility Measurement, analysis & estimation Model-based development & testing Product line engineering and reuse Requirements Security Systems engineering Verification & validation Version 3. 1 – – – Process implementation Compliance frameworks Process appraisals up to level 5 Appraisal preparation Framework models & maps Team participation in the development of standards 12

Security Engineering 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 consulted with member companies in many aspects of security Copyright © 2009, Systems and Software Consortium, Inc. Version 3. 1 13

Security Engineering 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 select For Members Only to download documents Copyright © 2009, Systems and Software Consortium, Inc. Version 3. 1 14

Security Engineering 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 Copyright © 2009, Systems and Software Consortium, Inc. Version 3. 1 15

Security Engineering Security Engineers Think Differently “Security engineering is about building systems to remain dependable in the face of malice, error, and mischance. ” “Security engineering requires cross-disciplinary expertise, ranging from cryptography and computer security through hardware tamperresistance 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 Copyright © 2009, Systems and Software Consortium, Inc. Version 3. 1 16

Security Engineering Mindset “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. ” “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. ” From Bruce Schneier, Crypto-Gram, April 15, 2008 Copyright © 2009, Systems and Software Consortium, Inc. Version 3. 1 17

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

Security Engineering Vulnerabilities Reported to CERT Number of Vulnerabilities Reported 3 q 08 Source: http: //www. cert. org/stats/ As of 4 q 08, CERT has stopped collecting and publishing this data Copyright © 2009, Systems and Software Consortium, Inc. Version 3. 1 20

Security Engineering Incidents Reported to CERT discontinued reporting this information in 2003 Source: http: //www. cert. org/stats/cert_stats. html Copyright © 2009, Systems and Software Consortium, Inc. Version 3. 1 21

Security Engineering 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 Copyright © 2009, Systems and Software Consortium, Inc. Version 3. 1 22

Security Engineering 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/rfc 2828. html Copyright © 2009, Systems and Software Consortium, Inc. Version 3. 1 23

Security Engineering 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 V 2, August 2007, http: //tools. ietf. org/html/rfc 4949 Copyright © 2009, Systems and Software Consortium, Inc. Version 3. 1 25

Security Engineering 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 Copyright © 2009, Systems and Software Consortium, Inc. Version 3. 1 26

Security Engineering 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 Copyright © 2009, Systems and Software Consortium, Inc. Version 3. 1 27

Security Engineering 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 Copyright © 2009, Systems and Software Consortium, Inc. Version 3. 1 28

Security Engineering Understanding Security Implications of 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 Copyright © 2009, Systems and Software Consortium, Inc. Version 3. 1 29

Security Engineering: Key Practices • • • Designate a security engineering advocate (KP 1) Create a security engineering plan (KP 2) Learn from past security mistakes (KP 3) Understand security in the system’s operational environment (KP 4) Specify security requirements (KP 5) Analyze system threats and vulnerabilities (KP 6) Use security engineering guiding principles (KP 7) Validate system inputs (KP 8) Secure COTS applications (KP 9) Secure outsourced software (KP 10) Implement a coherent audit policy (KP 11) 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. Copyright © 2009, Systems and Software Consortium, Inc. Version 3. 1 30

Security Engineering 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, …) Copyright © 2009, Systems and Software Consortium, Inc. Version 3. 1 31

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

Security Engineering 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 Copyright © 2009, Systems and Software Consortium, Inc. Version 3. 1 33