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 usedbut 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.