Integrating Security Design Into The Software Development Process For E-Commerce Systems

1. Integrating Security Design Into The Software Development Process For E-Commerce Systems By: M.T. Chan, L.F. Kwok (City University of Hong Kong)

2. Introduction • WWW has evolved from static info dispatcher to full blown distributed computing environment • E-commerce: • Business to Customer Transactions • Business to Business Transactions • E-commerce systems are built on top of the WWW and internet, which are well known for their exposure to security threats of various kinds

3. Security Design and Software Development Process • SSE-CMM (Systems Security Engineering Capability Maturity Model) • Security Engineering: • Risk Process: • identifies and prioritizes dangers inherent to the developed product or system • Engineering Process: • Works with the other engineering disciplines to determine and implement solutions to the problems presented by the dangers • Assurance Process: • Establishes confidence in the security solutions and conveys this confidence to users or customers

4. SSE-CMM • provides a concrete framework in the design and development of a secured system. • designed to be generic • applied to different domains. • defines “what” but not “how”. • SSE-CMM is going to be used as a framework to specify SDPSS by further defining details of how to design and develop secured e-commerce systems for different application domains.

5. SDPSS Risk Process • SSE-CMM requires assessment of 4 entities: • Impact • Security risk • Threats • Vulnerabilities

6. Risk Data Repository Information Security Model (RDR) • Focuses on risk documentation and captures risk information about the entities and their linkages • Entities are grouped under 3 domains: • Environment domain: • entities that host or support the operation of the information processing system • Platform domain: • Covers the description of the information processing system and its related threats and countermeasures • Asset domain: • Represents information assets that are of certain value.

7. RDR concept used…but adapted • select entities that are relevant in software development and represent them as an object oriented design pattern • entities are modeled as classes and the links between entities are represented as associations between classes in an object oriented design

8. Security Design Pattern • Entities are represented as classes which contain attributes describing the properties and methods defining operations that can be performed on the classes. • Vulnerabilities, Threats, Risks, and Impacts • Asset – represents a unit of the e-commerce system being designed that has a value and loss of it may have an impact, financially or otherwise.  • Deployment – a combination of hardware/software on which the asset operates.   • Vulnerabilities are then classified into 2 main categories: asset vulnerabilities and deployment vulnerabilities.

9. Example • A function in an e-commerce system, which is responsible to send out purchase orders in the form of e-mail. • This function is an asset and the e-mail purchase order being intercepted is the vulnerability.  • The cost of damage to the company if the purchase orders are tempered is the impact. • The potential of being intercepted is represented as the risk attribute in the link class threat and one of the countermeasures is to perform encryption before the purchase order is sent.

10. Software Development Process as the Engineering Process • The software process used to reengineer three-tier client/server systems to Web-based systems is adopted and extended with security design considerations. • It is based on unified modeling language (UML).

11. UML and SDPSS • To facilitate communication between designers, five types of diagrams are selected to support SDPSS: • Use case • Class • Collaboration • Component • Deployment diagrams

12. 4 steps • The proposed SDPSS has 4 major steps: • Object and collaboration modeling • Tier Identification • Component Identification • Deployment Specification

13. SDPSS is designed to… • Model e-commerce applications in a well-defined manner • Provide a generic model • Security design will be meaningful and applicable across different application domains • Document the architecture of e-commerce application with clear and precise definition of security perimeters • Give flexibility to designers to perform trade-off in security design on top of functional design according to defined design goals

14. Object and Collaboration Modeling • Object modeling • Capture the functional requirements of the system using use case diagrams • Establish the general layout of the system design in terms of class diagrams. • Collaboration Modeling • Analyze how objects or classes interact with each other. • Goal: to ensure all functional requirements are met by step-wise refinement and going through all identified use cases.

15. Specifying Security Needs Through Tier Identification • Objects are first grouped into tiers according to functional requirements and deployment considerations. • Tiers are examined according to vulnerabilities, risks and impacts to identify assets. • Regrouping may be necessary • corresponding countermeasures, risks and impact could be specified and documented • The mapping of tiers to assets therefore brings together the risk process and the engineering process.

16. Component Identification • Component – identifies sets of objects that are coherent in terms of functional requirements and are reused. • Criteria to identify components: • A component serves as the basic unit of security perimeter • Components are derived from objects coming from the same tier • Components are derived from objects coming from the same physical deployment, i.e. same technological platform.

17. Deployment Specification and Platform Security • Possible to deploy different parts of the system on more than one platform. • In UML notation deployment diagrams describe physical machines used to run components. • Too restrictive for e-commerce applications • Semantics of node in UML extended to include deployment technology specification. • Identify a set of known vulnerabilities for that platform. • The risk of deploying a tier of components can be evaluated and suitable countermeasures can be built into the design.

18. Deployment (continued) • A link between a deployment and an asset representing the software components of that asset would be run in the deployment platform. • Before the coding phase of a project starts: • designers can model different deployment scenarios • balance the pros and cons • make a trade-off to arrive at an optimal solution.

19. Example • An internet server provides web services to external clients and the intranet server provides database access and internal inventory control operations. • Security design considerations for the 2 servers are quite different. • The intranet server should have very stringent security needs and should be protected behind a firewall • Internet server has to be opened to the Internet and other countermeasures should be employed.

20. The Assurance Process • With the assistance of CASE (computer aided software engineering) tools • All security related design information would be accessible as a central repository • Possible to perform various assurance exercises with the model • Whether security needs are met and can be checked by verifying that assets are actually linked to the correct vulnerabilities, tiers and components are correctly aggregated into assets and linked to deployment properly.

21. Example • It is the company policy to require that any order information sent to a supplier must be encrypted. • To verify this, a cross-reference report could be generated from CASE tools and see if the vulnerability association of the place order component actually points to the repudiation vulnerability.

22. Conclusion • All vulnerabilities, impacts, threats and risks could be continuously monitored and updated. • Countermeasures could be improved and verified through feedback from actual deployment or security alerts issued by vendors. • By separating the risk and the engineering process, any updated countermeasures can be easily implemented without intensive modification of the application system. • Dedicated teams with clear responsibilities can be separately assigned to the risk, engineering and assurance process sharing the centralized model built from the SDPSS.

23. Chan, M.T. and L.F. Kwok, "Integrating Security Design Into the Software Development Process for E- Commerce Systems", Information Management & Computer Security, Volume 9, No. 3. 2001. Pages 112-122.