The document discusses security considerations for service-oriented architectures (SOA). It outlines common problems with disconnects between functional and non-functional security requirements. It also discusses how security needs to remain agile and responsive to innovation by attackers. The document proposes a layered security architecture and parallel security and service engineering lifecycles. It frames security concepts in terms of a generic business schema.

1. Service Oriented Security Engineering Richard Veryard

2. Security Is Sometimes Seen As A Challenge And Inhibitor For Enterprise SOA My product will make SOA safe. Is SOA safe? You can afford it. How much does it cost?

3. Decision Problems If I go ahead with this innovation, does it introduce new security risks and requirements? Should I abandon or postpone this innovation until the security issues are completely resolved? Risk Assessment How can I assemble a collection of security mechanisms and standards from different sources? Would I be better off acquiring everything from a single source? Integration Interoperability Should I adopt this standard, or insist that my suppliers conform to this standard? What does adoption entail? Standards How can I justify a given level of expenditure in security? How can I assess whether I am getting value-for-money from my investment in security? Business Case Do I need this class of security product? If so, how do I choose between the competing products in this class? What is a reasonable cost for this kind of product (direct and indirect)? Evaluation Comment Security Decision

4. Process Problems Disconnect between Functional Requirements and Non-Functional Requirements Disconnect between Business-Level and Detailed Security Requirements Piecemeal tool-driven approach to security No systematic business case for security. Tendency towards Cost-Avoidance rather than Risk/Reward Non-Functional Requirements as Afterthought

5. Why Security Doesn’t Remain Stationary Absolute Security My security is unaffected by what anyone else does. Relative Security I have to maintain at least as much security as everyone else. Innovation by other potential targets Innovation by attackers Responsive Security My security must respond to innovation by attackers. Agile Security My security should stay one step ahead of the game.

6. Layered Security Architecture (extract) Domain Services Stand-Alone Security Services Security in Platform Capability Services Business Transaction Risk and Compliance

7. Model-View-Controller Domain Services Security Services Security in Platform Capability Services Model View Controller

8. Multiple Entry Points Security Assessment Reviewing the levels of security contained in existing systems and artifacts (including models and plans) Security Implementation Implementing and activating a complete and consistent set of security policies and mechanisms Security Requirements Modeling the business and its ecosystem to determine detailed requirements and opportunities for (greater) security. Security Architecture Producing plans and portfolios that integrate security with other desired characteristics, including agility.

10. How the Security Schema follows a Generic Business Schema What the attacker does attack capability attack opportunity attack goal What the defender does defensive capability defensive action threat security goal What the business does capability response (unit of work) event outcome (goal) anti-requirements requirements generic schema