Systems Security Engineering Working Group Activities at IW08

1. Systems Security Engineering Working Group Activities at IW08 INCOSE Enchantment Meeting February 13, 2008 John W. Wirsbinski

2. A Brief History of the Working Group

3. Genesis of the Working Group? • How we got started • Idea was proposed at IW06 during Specialty Engineering Enabler workshop • Why INCOSE • ASIS • ISSA • Why an SSE Group? • ATIWG

4. PhysSec COMPUSEC/ Information Systems Security COMSEC INFoSEc OPSEC Prodsec KeySEC TSCM Counter-intelligence Psyops Insider Protection Anti-terrorism Counter-terrorism Business Continuity and Disaster Recovery Etc. SSE is Not:

5. What is SSE An element of system engineering that applies scientific and engineering principles to identify security vulnerabilities and minimize or contain risks associated with these vulnerabilities. It uses mathematical, physical, and related scientific disciplines, and the principles and methods of engineering design and analysis to specify, predict, and evaluate the vulnerability of the system to security threats.1 1 Handbook for Systems Security Engineering Program Management Requirements, D.o. Defense, Editor. 1995, Headquarters Air Force Systems Command, Office of the Chief of Security Police.

6. Alternate (LMC) Definition • SSE is a technical discipline that uses a systems engineering approach to determine the total protection for a system or program in all protection disciplines: physical, information, information systems, communications, personnel, operations, product, and emissions.

7. Working Group History • Established at IW07 • 18 attendees • Established leadership • John Wirsbinski – chair • Rick Dove – co-chair • First activities • Collect supporting evidence and examples • Write Manifesto • Meeting at IS07 • Discussed evidence and examples

8. Working Group Status • Members • ~40 members • ~5 INCOSE leadership membership • 2007 Products • Charter • INCOSE Connect Site • https://connect.incose.org/tb/specialty/systemsecurity/default.aspx • E-mail Reflector • securitywg@incose.org • Public information page on INCOSE website • http://www.incose.org/practice/techactivities/wg/securitywg/ • Draft Manifesto • Proposal • Modify name to avoid confusion with Systems Science Enabler (SSE) working group

9. Working Group Charter The Systems Security Engineering Working Group (SSEWG) was established in response to observations that current methods of integrating security into systems and enterprises are not working – security is costing more (operationally and financially) and our vulnerability is holding constant or increasing. In response the SSEWG was established to identify or develop systems engineering methods to: 1) provide security solutions that are harmoniously integrated into systems 2) ensure that security capabilities and requirements are adequately considered in systems engineering activities.

10. Security Manifesto • We speak here of security. Not narrowly of only cyber or physical security, but total system security – that which provides the faith and trust we want in continued safety, service, and economic effectiveness of the systems we count on as part of life in society… • We hold these truths to be self evident: • that engineered systems are designed for purpose; • that they are engineered by their designers to meet certain fundamental requirements; • that among these are security, safety, service, and the pursuit of economic effectiveness; • that to secure these requirements design principles are instituted among the community of engineers, deriving their just nature from first principles, natural laws and best practice; • that whenever such principles become inadequate to these ends, it is the responsibility of the community to abolish them, and to institute new principles that shall seem most likely to deliver security, safety, service, and effectiveness.

11. Security Manifesto-System Engineering Practices • employ holistic systems thinking; • assume penetration always and constantly; • define and embody resilient reactive concepts; • define and embody innovative proactive concepts; • integrate physical and cyber security; • embed security within system architecture; • represent meaningful measures of risk and security-effectiveness; • identify and address the realities of the environment, including: human behavior, organizational behavior, technology pace, systems complexity, globalization, agile enterprise practices, and agile adversaries; • remain both vigilant and innovative as expressions and possibilities of reality continue to change; ------------- Traditional Risk analysis is based upon history – Forecasting is a different beast that may be more amenable to the problems we are facing

12. Assertions Embodied in Manifesto • Security is an implicit systems engineering responsibility that must be made explicit • Adversaries • Adversaries are agile • Adversaries exist in an open community • We cannot rely on a fortress approach • Systems are too complex to test out vulnerabilities • Networked / Distributed systems • We don’t control or design everything to which our systems connect • Cylinders of excellence (aka stovepipes) create exploitable vulnerabilities • Success lies in: • Forcing the adversaries to adapt to us • Responding efficiently when the adversaries get ahead of us

13. We Need … • Systems engineering to explicitly embrace security • Security as value added • Security as an architectural characteristic • Systems tools and techniques to address security problems • Problem structuring methods to understand and characterize security problems • Security solutions that are Agile • Security for decentralized systems • Working group members interested in working to address these issues • Products that will be valuable • Effective • Transparent to systems users • Implementable by systems architects and engineers • Affordable

14. Future Activities • Theme for July 2009 Insight • The Interplay of Architecture, Security, and Systems Engineering

15. Potential Essay Topics Provide a view of what has to be in a government proposal (Josh S.) Survey of patterns for thought/strategy/principles (John W.) Structural pattern types related to strengths and weaknesses (Rick D.) Architectural “views” and relationships to security(structure/ behavior/ principles/ temporal/ context/ qualities) (Mike W.) – encompasses concept of “security architecture” Simulation tools to help explore and test architectural strategies (Bandit G.) Placement of security in existing architectural frameworks (Jackson W.) Use case application in characterizing security …. (John H.) Best practice collections illuminating architecture-embedded security (David D.) Vertical relationships (architectural “layers”) … embedded layering (Marcos C.) Horizontal relationships(interoperability) of system-system (Rick D.) Security as an emergent quality (Rick D.) Security as an externalized property (Jackson W.) Catalysts that sustain/maintain/stimulate security (John W.) Security System as a football (or other ) metaphorical pattern (John H.) Security “view” vs incorporating security in the existing architectural “views” Security architectural patterns (value propositions of): 1) security that emerges from an agglomeration of parts in the total system (emergent), 2) security inherent in each part of a system (encapsulated), 3) security as an independent put servicing function Architectural concepts that facilitate/impede graceful/clumsy migration into the future