BIJ92

166

Benchmarking An InternationalJournal Vol 9 No 2 2002pp 166-181 MCB UP Limited1463-5771DOI 10110814635770210421836

An integrated approach forsecuring electronic

transactions over the WebN Kolokotronis C Margaritis and P Papadopoulou

Department of Informatics and Telecommunications National andKapodistrian University of Athens Athens Greece

P KanellisArthur Andersen Athens Greece and

D MartakosDepartment of Informatics and Telecommunications National and

Kapodistrian University of Athens Athens Greece

Keywords Information Security Strategy Internet Business policy Systems development

Abstract The decentralised nature of Web-based information systems demands a carefulevaluation of the pantheon of security issues in order to avoid the potential occurrence of businessrisks that could not be easily mitigated Understanding that information security is not merely atechnical solution implemented at each endpoint of the inter-organizational application this paperdescribes an integrated approach based on a rigorous multi-level and multi-dimensional modelHaving as a starting point the overall business goals and objectives the model drives thedevelopment of a strategy from the lower levels of securing data in storage and transition to thehigher levels of business processes Its use and applicability is demonstrated over ` Billing Mallrsquorsquo ndasha system for electronic bill presentation and payment

IntroductionAs organisations are rushing to revamp business models and align operationsaround e-commerce initiatives information systems (IS) must be thought of as` servicescapesrsquorsquo ndash enablers of a virtual realm where products and services existas digital information and can be delivered through information-basedchannels (Wanninger et al 1997 Papadopoulou et al 2000) It follows that theoccurrence of business risks is now more eminent as the corporate networkprocesses and critical business data are vulnerable to attacks by anyonehaving Internet access (Abela and Sacconaghi 1997 Derivion Corp 1999Segev et al 1998 Walker and Cavanaugh 1998) What has been observedhowever is that most organisations treat the Internet simply as a transportmedium The result as Segev et al (1998) noted is that ` Internet securityremains a relatively technical local and distinct issue from the corporate level[IS] design and managementrsquorsquo We advocate that as security is the dependentvariable for the success of Web-based IS the formation of any information

T h e r e s e a r c h r e g is t e r f o r t h is jo u r n a l i s a v a i la b le a t

httpwwwemeraldinsightcomresearchregisters

T h e c u r r e n t is s u e a n d f u l l te x t a rc h iv e o f th is jo u r n a l i s a v a i la b le a t

httpwwwemeraldinsightcom1463-5771htm

The authors gratefully acknowledge the Greek Secretariat for Research and Technology (GSRT)for financing the ` Billing Mallrsquorsquo project They would also like to thank the partners involved inthe project Athens University of Economics and Business Cyberce Datamedia Dias SyswareTeiresias and the University of Crete

Securingtransactions over

the Web

167

security strategy should begin by taking into account the business vision goalsand objectives Furthermore it should not be approached as an afterthoughtbut rather it has to be designed and evolve concurrently with the developmentof the system Any other way to approach this issue will quickly lead tomassive fraud system failure and acrimonious lawsuits (Hughes 1997) Thedefinition of any effective information security strategy should thus be a wellplanned and concentrated effort initiated at the corporate level and not be seenonly as a local technology issue or as an ad hoc mix of particular technicalsolutions to specific problems

With this in mind we offer an integrated approach to the development andimplementation of an information security strategy for IS operating in Webenvironments Based on a comprehensive multi-level and multi-dimensionalmodel it defines the issues and sets the guidelines for infusing security both ata low and higher level The section that follows presents the model and itsbuilding blocks for aiding the implementation of an effective security strategyIts application is demonstrated in sections 3 and 4 over a Web-based electronicbill presentment and payment (EBPP) system developed for the HellenicTelecommunications Organisation (OTE) and currently in its deploymentphase A concluding discussion closes the article

An information security strategy modelA long-held but false assumption is that security is largely a technological issueand an afterthought that has to be addressed during a systemrsquos implementationphase Baskerville (1993) noted the existence of this developmental duality (the ISand its security are treated as separate developments) arguing that it may causeconflict and tension between a system and its security The model that ispresented herein was developed taking the above issue into consideration Itacquired an added importance as it was developed during our attempt to definean information security strategy for `Billing Mallrsquorsquo ndash a system for on-line billpresentation and payment whose intended ` security-sensitiversquorsquo users range fromcorporate customers to households

The model which is depicted in Figure 1 portrays a cyclic iterative processfor designing and deploying an information security strategy

Each iteration is performed in the context of a phased IS development planwith the emphasis on the various activities and the level of engagementchanging from one iteration to the next (see Figure 2) The development phasesclosely resemble those of the rational unified process methodology (Kruchten2000) In the inception phase of building the information security strategy thefocus is on gaining a high-level understanding of the overall securityrequirements and determining the scope of the development effort In theelaboration phase the focus is on weighting risks and costs whilst in theconstruction phase the focus shifts on design and implementation Finally inthe transition phase the focus is on ensuring that the system maintains thequality levels required in meeting business objectives The steps identifiednamely business needs analysis risk analysissecurity strategy

BIJ92

168

Figure 1Information securitystrategy model

Figure 2Information securitystrategy developmentplan and levels ofengagement

Securingtransactions over

the Web

169

implementation and monitoring research and analysis are described in therest of this section

Business needs analysisBusiness needs analysis is the foundation step for creating and maintaining aninformation security strategy that correctly reflects the overall mission andgoals of the organisation whilst identifying possible issues rising in caseswhere the system surpasses the organisationrsquos boundaries and extends acrossmultiple organizational entities The analysis starts by identifying theobjectives and business activities of the enterprise and its major units Goalsare set for each objective and critical success factors (CSFs) are highlighted toemphasize what must go right if these are to be met The information needed inorder to draw specific security requirements for any identified critical resourcesis recorded as information sets

Figure 3 depicts the main information entities that need to be examinedduring this step Each entity is represented by a rectangle A line with anarrowhead drawn from one entity to another indicates that there is arelationship between them

Risk analysis and cost assessmentThe distributed nature of Web-based systems implies the existence of amultitude of vulnerabilities and threats which have to be thoroughly examinedto guarantee a secure environment for commercial transactions Risk analysis

Figure 3Business needs analysis

entity diagram

BIJ92

170

and cost assessment specifies against which threats the critical informationresources identified in the previous step should be protected from This has tobe considered in conjunction with the cost of deploying the security strategy

Potential vulnerabilities and threats should be identified at all levelsincluding network services architecture operating systems and applicationswith the purpose of facilitating decision making about the desired level ofsecurity and identifying any corresponding risk management methods thatshould be adopted

The information entities produced during this step are depicted in Figure 4As already mentioned any CSFs and other information sets derived during theprevious step are used in the analysis performed in this step cross-referencedwith the perceived risks

Risk quantification should be undertaken including a cost assessment of thepossible damage associated with each threat against the cost of preventing thethreat in terms of time expenses and resources The identified risks shouldthen be categorised according to their probability and the severity of theirimpacts (see Figure 5) Certainly one needs to consider first those threats

Figure 4Risk analysis entitydiagram

Securingtransactions over

the Web

171

resulting in greater losses (classes D and C) but still not to ignore threats of lessprobable financial impact which occur more frequently (class B)

In completing this step the organisation should be able to outline strategicsecurity objectives These are general security objectives which may bedefined for instance in terms of the levels of confidentiality integrityavailability and accountability that the enterprise wishes to attain Theseobjectives along with the set of rules and practices that regulate how assets areadministered protected and distributed should be described in detail in acorporate information security policy (CISP) document

Security strategy implementationThe security strategy implementation step should aim to ensure the mosteffective use of resources and must constitute a consistent approach even in thecase of different systems The influence that the implementation step exertsupon the overall systems development lifecycle is twofold as the informationgathered during the previous steps is utilised to

(1) identify security services that should be offered by technicalinfrastructure components such as standard protocols and commercialoff-the-shelf products and

(2) extend the system analysis and design tasks by infusing the securitysemantics of business processes

The identification of security services involves the selection of those that needto be provided by the technical infrastructure in order to protect theorganisationrsquos information assets from known and unknown threats (seeFigure 1) The process includes the analysis of a plethora of commerciallyavailable products and protocols by examining relevant industry reports andbest practice guides This is essential since not all security services can be usedfor the protection of all kinds of information resources ndash different classes ofdata require different levels of security Classes of security services includeintegrity confidentiality authentication accountability and auditingauthorisation availability and non-repudiation In order to provide such

Figure 5Risk classification

BIJ92

172

services one has to consider the security mechanisms offered for data in transitand the security mechanisms offered for data in storage These are illustratedin Tables I and II respectively

When data in transit are considered (Table I) protocols offering securityservices are divided into three main categories depending on the InternationalStandards Organisationrsquos (wwwisoch) Open Systems Interconnection (OSI)layer they operate namely the network transport and the application layerFurthermore the application layer security mechanisms can be subdividedaccording to the specific structure and nature of the data they are targetingdifferentiating sensitive from non-sensitive data

Security for data in storage caters for the ` enemy-withinrsquorsquo ie the employeewho intentionally or accidentally may cause severe security incidents Thisrequires that security for data in storage should not only depend on thetechnology used but also on the proper administration of systems as well asthe observance of related business procedures physical access controls andaudit functions Not all business requirements and objectives are identicalConsequently security mechanisms for data in storage are not absolute ndash thereis not one standard that will fit all cases In Table II we present the dominant

Table IMechanisms used toenforce the securitypolicy for data intransit

OSI layer Protection Mechanism

Network Host-to-host IP security (IPSEC) IP authentication header (AH) IPencapsulating security payload (ESP) network layersecurity protocol (NLSP) point-to-point tunnelling protocol(PPTP)

Transportsession

Process-to-process Secure sockets layer (SSL) transport layer security (TLS)open financial exchange (OFX)

Application Data structure-specific

Secure hypertext transfer protocol (S-HTTP) pretty goodprivacy (PGP) privacy enhanced mail (PEM) secure multi-purpose Internet mail extensions (SMIME)

Data nature-specific

Secure electronic transactions (SET) open financialexchange (OFX)

Table IIMechanisms used toenforce the securitypolicy for data instorage

Type Solutions

Hardware Smart cards (PVC EMV) other tamper-proof devices screeningrouters biometric devices

SoftwareOperating system level

Password-based authentication password expiration and filteringKerberos-based distributed authentication access control lists(ACL) security identifiers (SID)

Database managementsystem level

Password expiration password standards enforcement break-indetection and evasion dormant user ID identification centralisedsecurity administration comprehensive report generationmaintenance of audit logs

Application level Anti-virus software audit log analysers firewalls back-up utilities

BIJ92

168

Figure 1Information securitystrategy model

Figure 2Information securitystrategy developmentplan and levels ofengagement

Securingtransactions over

the Web

169

implementation and monitoring research and analysis are described in therest of this section

Business needs analysisBusiness needs analysis is the foundation step for creating and maintaining aninformation security strategy that correctly reflects the overall mission andgoals of the organisation whilst identifying possible issues rising in caseswhere the system surpasses the organisationrsquos boundaries and extends acrossmultiple organizational entities The analysis starts by identifying theobjectives and business activities of the enterprise and its major units Goalsare set for each objective and critical success factors (CSFs) are highlighted toemphasize what must go right if these are to be met The information needed inorder to draw specific security requirements for any identified critical resourcesis recorded as information sets

Figure 3 depicts the main information entities that need to be examinedduring this step Each entity is represented by a rectangle A line with anarrowhead drawn from one entity to another indicates that there is arelationship between them

Risk analysis and cost assessmentThe distributed nature of Web-based systems implies the existence of amultitude of vulnerabilities and threats which have to be thoroughly examinedto guarantee a secure environment for commercial transactions Risk analysis

Figure 3Business needs analysis

entity diagram

BIJ92

170

and cost assessment specifies against which threats the critical informationresources identified in the previous step should be protected from This has tobe considered in conjunction with the cost of deploying the security strategy

Potential vulnerabilities and threats should be identified at all levelsincluding network services architecture operating systems and applicationswith the purpose of facilitating decision making about the desired level ofsecurity and identifying any corresponding risk management methods thatshould be adopted

The information entities produced during this step are depicted in Figure 4As already mentioned any CSFs and other information sets derived during theprevious step are used in the analysis performed in this step cross-referencedwith the perceived risks

Risk quantification should be undertaken including a cost assessment of thepossible damage associated with each threat against the cost of preventing thethreat in terms of time expenses and resources The identified risks shouldthen be categorised according to their probability and the severity of theirimpacts (see Figure 5) Certainly one needs to consider first those threats

Figure 4Risk analysis entitydiagram

Securingtransactions over

the Web

171

resulting in greater losses (classes D and C) but still not to ignore threats of lessprobable financial impact which occur more frequently (class B)

In completing this step the organisation should be able to outline strategicsecurity objectives These are general security objectives which may bedefined for instance in terms of the levels of confidentiality integrityavailability and accountability that the enterprise wishes to attain Theseobjectives along with the set of rules and practices that regulate how assets areadministered protected and distributed should be described in detail in acorporate information security policy (CISP) document

Security strategy implementationThe security strategy implementation step should aim to ensure the mosteffective use of resources and must constitute a consistent approach even in thecase of different systems The influence that the implementation step exertsupon the overall systems development lifecycle is twofold as the informationgathered during the previous steps is utilised to

(1) identify security services that should be offered by technicalinfrastructure components such as standard protocols and commercialoff-the-shelf products and

(2) extend the system analysis and design tasks by infusing the securitysemantics of business processes

The identification of security services involves the selection of those that needto be provided by the technical infrastructure in order to protect theorganisationrsquos information assets from known and unknown threats (seeFigure 1) The process includes the analysis of a plethora of commerciallyavailable products and protocols by examining relevant industry reports andbest practice guides This is essential since not all security services can be usedfor the protection of all kinds of information resources ndash different classes ofdata require different levels of security Classes of security services includeintegrity confidentiality authentication accountability and auditingauthorisation availability and non-repudiation In order to provide such

Figure 5Risk classification

BIJ92

172

services one has to consider the security mechanisms offered for data in transitand the security mechanisms offered for data in storage These are illustratedin Tables I and II respectively

When data in transit are considered (Table I) protocols offering securityservices are divided into three main categories depending on the InternationalStandards Organisationrsquos (wwwisoch) Open Systems Interconnection (OSI)layer they operate namely the network transport and the application layerFurthermore the application layer security mechanisms can be subdividedaccording to the specific structure and nature of the data they are targetingdifferentiating sensitive from non-sensitive data

Security for data in storage caters for the ` enemy-withinrsquorsquo ie the employeewho intentionally or accidentally may cause severe security incidents Thisrequires that security for data in storage should not only depend on thetechnology used but also on the proper administration of systems as well asthe observance of related business procedures physical access controls andaudit functions Not all business requirements and objectives are identicalConsequently security mechanisms for data in storage are not absolute ndash thereis not one standard that will fit all cases In Table II we present the dominant

Table IMechanisms used toenforce the securitypolicy for data intransit

OSI layer Protection Mechanism

Network Host-to-host IP security (IPSEC) IP authentication header (AH) IPencapsulating security payload (ESP) network layersecurity protocol (NLSP) point-to-point tunnelling protocol(PPTP)

Transportsession

Process-to-process Secure sockets layer (SSL) transport layer security (TLS)open financial exchange (OFX)

Application Data structure-specific

Secure hypertext transfer protocol (S-HTTP) pretty goodprivacy (PGP) privacy enhanced mail (PEM) secure multi-purpose Internet mail extensions (SMIME)

Data nature-specific

Secure electronic transactions (SET) open financialexchange (OFX)

Table IIMechanisms used toenforce the securitypolicy for data instorage

Type Solutions

Hardware Smart cards (PVC EMV) other tamper-proof devices screeningrouters biometric devices

SoftwareOperating system level

Password-based authentication password expiration and filteringKerberos-based distributed authentication access control lists(ACL) security identifiers (SID)

Database managementsystem level

Password expiration password standards enforcement break-indetection and evasion dormant user ID identification centralisedsecurity administration comprehensive report generationmaintenance of audit logs

Application level Anti-virus software audit log analysers firewalls back-up utilities

Securingtransactions over

the Web

169

implementation and monitoring research and analysis are described in therest of this section

Business needs analysisBusiness needs analysis is the foundation step for creating and maintaining aninformation security strategy that correctly reflects the overall mission andgoals of the organisation whilst identifying possible issues rising in caseswhere the system surpasses the organisationrsquos boundaries and extends acrossmultiple organizational entities The analysis starts by identifying theobjectives and business activities of the enterprise and its major units Goalsare set for each objective and critical success factors (CSFs) are highlighted toemphasize what must go right if these are to be met The information needed inorder to draw specific security requirements for any identified critical resourcesis recorded as information sets

Figure 3 depicts the main information entities that need to be examinedduring this step Each entity is represented by a rectangle A line with anarrowhead drawn from one entity to another indicates that there is arelationship between them

Risk analysis and cost assessmentThe distributed nature of Web-based systems implies the existence of amultitude of vulnerabilities and threats which have to be thoroughly examinedto guarantee a secure environment for commercial transactions Risk analysis

Figure 3Business needs analysis

entity diagram

BIJ92

170

and cost assessment specifies against which threats the critical informationresources identified in the previous step should be protected from This has tobe considered in conjunction with the cost of deploying the security strategy

Potential vulnerabilities and threats should be identified at all levelsincluding network services architecture operating systems and applicationswith the purpose of facilitating decision making about the desired level ofsecurity and identifying any corresponding risk management methods thatshould be adopted

The information entities produced during this step are depicted in Figure 4As already mentioned any CSFs and other information sets derived during theprevious step are used in the analysis performed in this step cross-referencedwith the perceived risks

Risk quantification should be undertaken including a cost assessment of thepossible damage associated with each threat against the cost of preventing thethreat in terms of time expenses and resources The identified risks shouldthen be categorised according to their probability and the severity of theirimpacts (see Figure 5) Certainly one needs to consider first those threats

Figure 4Risk analysis entitydiagram

Securingtransactions over

the Web

171

resulting in greater losses (classes D and C) but still not to ignore threats of lessprobable financial impact which occur more frequently (class B)

In completing this step the organisation should be able to outline strategicsecurity objectives These are general security objectives which may bedefined for instance in terms of the levels of confidentiality integrityavailability and accountability that the enterprise wishes to attain Theseobjectives along with the set of rules and practices that regulate how assets areadministered protected and distributed should be described in detail in acorporate information security policy (CISP) document

Security strategy implementationThe security strategy implementation step should aim to ensure the mosteffective use of resources and must constitute a consistent approach even in thecase of different systems The influence that the implementation step exertsupon the overall systems development lifecycle is twofold as the informationgathered during the previous steps is utilised to

(1) identify security services that should be offered by technicalinfrastructure components such as standard protocols and commercialoff-the-shelf products and

(2) extend the system analysis and design tasks by infusing the securitysemantics of business processes

The identification of security services involves the selection of those that needto be provided by the technical infrastructure in order to protect theorganisationrsquos information assets from known and unknown threats (seeFigure 1) The process includes the analysis of a plethora of commerciallyavailable products and protocols by examining relevant industry reports andbest practice guides This is essential since not all security services can be usedfor the protection of all kinds of information resources ndash different classes ofdata require different levels of security Classes of security services includeintegrity confidentiality authentication accountability and auditingauthorisation availability and non-repudiation In order to provide such

Figure 5Risk classification

BIJ92

172

services one has to consider the security mechanisms offered for data in transitand the security mechanisms offered for data in storage These are illustratedin Tables I and II respectively

When data in transit are considered (Table I) protocols offering securityservices are divided into three main categories depending on the InternationalStandards Organisationrsquos (wwwisoch) Open Systems Interconnection (OSI)layer they operate namely the network transport and the application layerFurthermore the application layer security mechanisms can be subdividedaccording to the specific structure and nature of the data they are targetingdifferentiating sensitive from non-sensitive data

Security for data in storage caters for the ` enemy-withinrsquorsquo ie the employeewho intentionally or accidentally may cause severe security incidents Thisrequires that security for data in storage should not only depend on thetechnology used but also on the proper administration of systems as well asthe observance of related business procedures physical access controls andaudit functions Not all business requirements and objectives are identicalConsequently security mechanisms for data in storage are not absolute ndash thereis not one standard that will fit all cases In Table II we present the dominant

Table IMechanisms used toenforce the securitypolicy for data intransit

OSI layer Protection Mechanism

Network Host-to-host IP security (IPSEC) IP authentication header (AH) IPencapsulating security payload (ESP) network layersecurity protocol (NLSP) point-to-point tunnelling protocol(PPTP)

Transportsession

Process-to-process Secure sockets layer (SSL) transport layer security (TLS)open financial exchange (OFX)

Application Data structure-specific

Secure hypertext transfer protocol (S-HTTP) pretty goodprivacy (PGP) privacy enhanced mail (PEM) secure multi-purpose Internet mail extensions (SMIME)

Data nature-specific

Secure electronic transactions (SET) open financialexchange (OFX)

Table IIMechanisms used toenforce the securitypolicy for data instorage

Type Solutions

Hardware Smart cards (PVC EMV) other tamper-proof devices screeningrouters biometric devices

SoftwareOperating system level

Password-based authentication password expiration and filteringKerberos-based distributed authentication access control lists(ACL) security identifiers (SID)

Database managementsystem level

Password expiration password standards enforcement break-indetection and evasion dormant user ID identification centralisedsecurity administration comprehensive report generationmaintenance of audit logs

Application level Anti-virus software audit log analysers firewalls back-up utilities

BIJ92

170

and cost assessment specifies against which threats the critical informationresources identified in the previous step should be protected from This has tobe considered in conjunction with the cost of deploying the security strategy

Potential vulnerabilities and threats should be identified at all levelsincluding network services architecture operating systems and applicationswith the purpose of facilitating decision making about the desired level ofsecurity and identifying any corresponding risk management methods thatshould be adopted

The information entities produced during this step are depicted in Figure 4As already mentioned any CSFs and other information sets derived during theprevious step are used in the analysis performed in this step cross-referencedwith the perceived risks

Risk quantification should be undertaken including a cost assessment of thepossible damage associated with each threat against the cost of preventing thethreat in terms of time expenses and resources The identified risks shouldthen be categorised according to their probability and the severity of theirimpacts (see Figure 5) Certainly one needs to consider first those threats

Figure 4Risk analysis entitydiagram

Securingtransactions over

the Web

171

resulting in greater losses (classes D and C) but still not to ignore threats of lessprobable financial impact which occur more frequently (class B)

In completing this step the organisation should be able to outline strategicsecurity objectives These are general security objectives which may bedefined for instance in terms of the levels of confidentiality integrityavailability and accountability that the enterprise wishes to attain Theseobjectives along with the set of rules and practices that regulate how assets areadministered protected and distributed should be described in detail in acorporate information security policy (CISP) document

Security strategy implementationThe security strategy implementation step should aim to ensure the mosteffective use of resources and must constitute a consistent approach even in thecase of different systems The influence that the implementation step exertsupon the overall systems development lifecycle is twofold as the informationgathered during the previous steps is utilised to

(1) identify security services that should be offered by technicalinfrastructure components such as standard protocols and commercialoff-the-shelf products and

(2) extend the system analysis and design tasks by infusing the securitysemantics of business processes

The identification of security services involves the selection of those that needto be provided by the technical infrastructure in order to protect theorganisationrsquos information assets from known and unknown threats (seeFigure 1) The process includes the analysis of a plethora of commerciallyavailable products and protocols by examining relevant industry reports andbest practice guides This is essential since not all security services can be usedfor the protection of all kinds of information resources ndash different classes ofdata require different levels of security Classes of security services includeintegrity confidentiality authentication accountability and auditingauthorisation availability and non-repudiation In order to provide such

Figure 5Risk classification

BIJ92

172

services one has to consider the security mechanisms offered for data in transitand the security mechanisms offered for data in storage These are illustratedin Tables I and II respectively

When data in transit are considered (Table I) protocols offering securityservices are divided into three main categories depending on the InternationalStandards Organisationrsquos (wwwisoch) Open Systems Interconnection (OSI)layer they operate namely the network transport and the application layerFurthermore the application layer security mechanisms can be subdividedaccording to the specific structure and nature of the data they are targetingdifferentiating sensitive from non-sensitive data

Security for data in storage caters for the ` enemy-withinrsquorsquo ie the employeewho intentionally or accidentally may cause severe security incidents Thisrequires that security for data in storage should not only depend on thetechnology used but also on the proper administration of systems as well asthe observance of related business procedures physical access controls andaudit functions Not all business requirements and objectives are identicalConsequently security mechanisms for data in storage are not absolute ndash thereis not one standard that will fit all cases In Table II we present the dominant

Table IMechanisms used toenforce the securitypolicy for data intransit

OSI layer Protection Mechanism

Network Host-to-host IP security (IPSEC) IP authentication header (AH) IPencapsulating security payload (ESP) network layersecurity protocol (NLSP) point-to-point tunnelling protocol(PPTP)

Transportsession

Process-to-process Secure sockets layer (SSL) transport layer security (TLS)open financial exchange (OFX)

Application Data structure-specific

Secure hypertext transfer protocol (S-HTTP) pretty goodprivacy (PGP) privacy enhanced mail (PEM) secure multi-purpose Internet mail extensions (SMIME)

Data nature-specific

Secure electronic transactions (SET) open financialexchange (OFX)

Table IIMechanisms used toenforce the securitypolicy for data instorage

Type Solutions

Hardware Smart cards (PVC EMV) other tamper-proof devices screeningrouters biometric devices

SoftwareOperating system level

Password-based authentication password expiration and filteringKerberos-based distributed authentication access control lists(ACL) security identifiers (SID)

Database managementsystem level

Password expiration password standards enforcement break-indetection and evasion dormant user ID identification centralisedsecurity administration comprehensive report generationmaintenance of audit logs

Application level Anti-virus software audit log analysers firewalls back-up utilities

Securingtransactions over

the Web

171

resulting in greater losses (classes D and C) but still not to ignore threats of lessprobable financial impact which occur more frequently (class B)

In completing this step the organisation should be able to outline strategicsecurity objectives These are general security objectives which may bedefined for instance in terms of the levels of confidentiality integrityavailability and accountability that the enterprise wishes to attain Theseobjectives along with the set of rules and practices that regulate how assets areadministered protected and distributed should be described in detail in acorporate information security policy (CISP) document

Security strategy implementationThe security strategy implementation step should aim to ensure the mosteffective use of resources and must constitute a consistent approach even in thecase of different systems The influence that the implementation step exertsupon the overall systems development lifecycle is twofold as the informationgathered during the previous steps is utilised to

(1) identify security services that should be offered by technicalinfrastructure components such as standard protocols and commercialoff-the-shelf products and

(2) extend the system analysis and design tasks by infusing the securitysemantics of business processes

The identification of security services involves the selection of those that needto be provided by the technical infrastructure in order to protect theorganisationrsquos information assets from known and unknown threats (seeFigure 1) The process includes the analysis of a plethora of commerciallyavailable products and protocols by examining relevant industry reports andbest practice guides This is essential since not all security services can be usedfor the protection of all kinds of information resources ndash different classes ofdata require different levels of security Classes of security services includeintegrity confidentiality authentication accountability and auditingauthorisation availability and non-repudiation In order to provide such

Figure 5Risk classification

BIJ92

172

services one has to consider the security mechanisms offered for data in transitand the security mechanisms offered for data in storage These are illustratedin Tables I and II respectively

When data in transit are considered (Table I) protocols offering securityservices are divided into three main categories depending on the InternationalStandards Organisationrsquos (wwwisoch) Open Systems Interconnection (OSI)layer they operate namely the network transport and the application layerFurthermore the application layer security mechanisms can be subdividedaccording to the specific structure and nature of the data they are targetingdifferentiating sensitive from non-sensitive data

Security for data in storage caters for the ` enemy-withinrsquorsquo ie the employeewho intentionally or accidentally may cause severe security incidents Thisrequires that security for data in storage should not only depend on thetechnology used but also on the proper administration of systems as well asthe observance of related business procedures physical access controls andaudit functions Not all business requirements and objectives are identicalConsequently security mechanisms for data in storage are not absolute ndash thereis not one standard that will fit all cases In Table II we present the dominant

Table IMechanisms used toenforce the securitypolicy for data intransit

OSI layer Protection Mechanism

Network Host-to-host IP security (IPSEC) IP authentication header (AH) IPencapsulating security payload (ESP) network layersecurity protocol (NLSP) point-to-point tunnelling protocol(PPTP)

Transportsession

Process-to-process Secure sockets layer (SSL) transport layer security (TLS)open financial exchange (OFX)

Application Data structure-specific

Secure hypertext transfer protocol (S-HTTP) pretty goodprivacy (PGP) privacy enhanced mail (PEM) secure multi-purpose Internet mail extensions (SMIME)

Data nature-specific

Secure electronic transactions (SET) open financialexchange (OFX)

Table IIMechanisms used toenforce the securitypolicy for data instorage

Type Solutions

Hardware Smart cards (PVC EMV) other tamper-proof devices screeningrouters biometric devices

SoftwareOperating system level

Password-based authentication password expiration and filteringKerberos-based distributed authentication access control lists(ACL) security identifiers (SID)

Database managementsystem level

Password expiration password standards enforcement break-indetection and evasion dormant user ID identification centralisedsecurity administration comprehensive report generationmaintenance of audit logs

Application level Anti-virus software audit log analysers firewalls back-up utilities

BIJ92

172

services one has to consider the security mechanisms offered for data in transitand the security mechanisms offered for data in storage These are illustratedin Tables I and II respectively

When data in transit are considered (Table I) protocols offering securityservices are divided into three main categories depending on the InternationalStandards Organisationrsquos (wwwisoch) Open Systems Interconnection (OSI)layer they operate namely the network transport and the application layerFurthermore the application layer security mechanisms can be subdividedaccording to the specific structure and nature of the data they are targetingdifferentiating sensitive from non-sensitive data

Security for data in storage caters for the ` enemy-withinrsquorsquo ie the employeewho intentionally or accidentally may cause severe security incidents Thisrequires that security for data in storage should not only depend on thetechnology used but also on the proper administration of systems as well asthe observance of related business procedures physical access controls andaudit functions Not all business requirements and objectives are identicalConsequently security mechanisms for data in storage are not absolute ndash thereis not one standard that will fit all cases In Table II we present the dominant

Table IMechanisms used toenforce the securitypolicy for data intransit

OSI layer Protection Mechanism

Network Host-to-host IP security (IPSEC) IP authentication header (AH) IPencapsulating security payload (ESP) network layersecurity protocol (NLSP) point-to-point tunnelling protocol(PPTP)

Transportsession

Process-to-process Secure sockets layer (SSL) transport layer security (TLS)open financial exchange (OFX)

Application Data structure-specific

Secure hypertext transfer protocol (S-HTTP) pretty goodprivacy (PGP) privacy enhanced mail (PEM) secure multi-purpose Internet mail extensions (SMIME)

Data nature-specific

Secure electronic transactions (SET) open financialexchange (OFX)

Table IIMechanisms used toenforce the securitypolicy for data instorage

Type Solutions

Hardware Smart cards (PVC EMV) other tamper-proof devices screeningrouters biometric devices

SoftwareOperating system level

Password-based authentication password expiration and filteringKerberos-based distributed authentication access control lists(ACL) security identifiers (SID)

Database managementsystem level

Password expiration password standards enforcement break-indetection and evasion dormant user ID identification centralisedsecurity administration comprehensive report generationmaintenance of audit logs

Application level Anti-virus software audit log analysers firewalls back-up utilities

Securingtransactions over

the Web

173

mechanisms (hardwaresoftware based) currently available for safeguardingcritical data in storage within the organisation

Our discussion thus far has focused on the implementation of a securitystrategy mainly at the lower infrastructure level We agree with Baskerville(1993) that a security strategy should evolve concurrently with the design ofthe system and not be approached as an afterthought As such any integratedapproach should address how security could be possibly implemented at ahigher level ie the business process level

In order to arrive at a complete understanding of the security requirementsat the business process level Rohm et al (1998) suggested examining abusiness transaction from at least five different perspectivesviews each oneextended accordingly in order to capture the security semantics

The business process view representing the flow of work in terms ofactivities and participating entities from the viewpoint of the wholebusiness process It is used both as a means to communicate thearchitecture of the system to the stakeholders and to guide the modellingefforts for the other four views

The informational view representing the information entities theirstructure and any relationships between them

The behavioural view showing what tasks and activities are associatedwith the various objects the events that trigger these activities and themessage exchanging that occurs between them

The dynamic view representing for each information entity all possiblestates and any transitions that may occur within the life cycle of theinformation entity

The structural view showing where and by whom tasks and activitiesare performed

The above can guide the analyst towards acquiring a holistic view of anybusiness process We adopt those views placing them within the securitystrategy implementation step of our model and defining the order in which theymust be performed Their practical application is demonstrated in the nextmain section of the paper

Monitoring research and analysisThe monitoring research and analysis step can be performed using a plethoraof tools widely available by software vendors such as audit log analysers andintrusion detection mechanisms Their effective use may pinpoint the need forfurther analysis and a re-evaluation of the risk level in the context of ` liversquorsquooperating conditions (indicated by the broken line connecting steps 4 and 2 inFigure 1) This exercise may identify implementation flaws or weaknesses ofthe current strategy or serious gaps emanating from a change in the businessscope and activities In the former case the modification of existing securitymechanisms or the addition of new ones might be deemed necessary The latter

BIJ92

174

case may constitute the starting point for radical changes in the securitystrategy which have to be adequately addressed during subsequent iterationsof the steps in the model

In this section we described a model for aiding the development of aninformation security strategy from a multi-level and multi-dimensionalperspective What follows is a description of how this model was used toimplement the security strategy of ` Billing Mallrsquorsquo ndash an EBPP system developedfor the Hellenic Telecommunications Organisation (OTE)

Applying the model` Billing Mallrsquorsquo (for a description see httpalexandradiuoagr) is a system thatoffers facilities for bill presentation and payment customer applicationprocessing and personalised marketing (see Figure 6) The architectural modelof the system is based on the open Internet billing (OIB) model According toOIB a central service provider the consolidator collects and stores electronicsummary bills from registered billers While offering a single point of accessfor viewing and paying bills it provides the customer with the option to haveaccess to the billerrsquos Web site for detailed bill information When the customervisits the Web site requesting to see a detailed bill the biller presents himherwith informative messages regarding available products and services that canbe purchased directly

Following the steps prescribed by the model as presented in the previoussection a business needs analysis was conducted It emphasised the fact that inorder to mitigate the cost of deploying a secure communication mechanism forfinancial transactions between the consolidator and the banks the existinginfrastructure currently in use for fund transfer between financial institutionsin Greece had to be leveraged This implied the need for including an additionalentity to the OIB model the biller payment provider (see Figure 6) serving asan intermediary

An excerpt of the information entities derived during the first step ispresented in Tables III-V

The resources that were to be protected were finalised at both organizationaland inter-organizational levels during the second step These corporate assetswere deemed necessary to be protected from internal as well as externalattacks either intentional or accidental An example of the risk analysis resultsis presented in Tables VI-IX

The security mechanisms required for managing the identified risks wereidentified next Since the exchange of large amounts of financial information isinvolved the first task was to evaluate the security features of existingprotocols in the field Between Open Financial Exchange (OFX) (wwwofxnet)and Secure Electronic Transaction (SET) (wwwsetcoorg) the former wasfound more appropriate mainly because

it is based on cryptographic protocols

it supports the use of channel-level as well as application-level securityand

its security architecture is expandable and customisable

BIJ92

174

case may constitute the starting point for radical changes in the securitystrategy which have to be adequately addressed during subsequent iterationsof the steps in the model

In this section we described a model for aiding the development of aninformation security strategy from a multi-level and multi-dimensionalperspective What follows is a description of how this model was used toimplement the security strategy of ` Billing Mallrsquorsquo ndash an EBPP system developedfor the Hellenic Telecommunications Organisation (OTE)

Applying the model` Billing Mallrsquorsquo (for a description see httpalexandradiuoagr) is a system thatoffers facilities for bill presentation and payment customer applicationprocessing and personalised marketing (see Figure 6) The architectural modelof the system is based on the open Internet billing (OIB) model According toOIB a central service provider the consolidator collects and stores electronicsummary bills from registered billers While offering a single point of accessfor viewing and paying bills it provides the customer with the option to haveaccess to the billerrsquos Web site for detailed bill information When the customervisits the Web site requesting to see a detailed bill the biller presents himherwith informative messages regarding available products and services that canbe purchased directly

Following the steps prescribed by the model as presented in the previoussection a business needs analysis was conducted It emphasised the fact that inorder to mitigate the cost of deploying a secure communication mechanism forfinancial transactions between the consolidator and the banks the existinginfrastructure currently in use for fund transfer between financial institutionsin Greece had to be leveraged This implied the need for including an additionalentity to the OIB model the biller payment provider (see Figure 6) serving asan intermediary

An excerpt of the information entities derived during the first step ispresented in Tables III-V

The resources that were to be protected were finalised at both organizationaland inter-organizational levels during the second step These corporate assetswere deemed necessary to be protected from internal as well as externalattacks either intentional or accidental An example of the risk analysis resultsis presented in Tables VI-IX

The security mechanisms required for managing the identified risks wereidentified next Since the exchange of large amounts of financial information isinvolved the first task was to evaluate the security features of existingprotocols in the field Between Open Financial Exchange (OFX) (wwwofxnet)and Secure Electronic Transaction (SET) (wwwsetcoorg) the former wasfound more appropriate mainly because

it is based on cryptographic protocols

it supports the use of channel-level as well as application-level securityand

its security architecture is expandable and customisable

Securingtransactions over

the Web

175

Table IIIBusiness goals defined

during the businessneeds analysis step

Objective ID Descriptions

O1Business unitWeb services 15 per cent of existing customer base as EBPP users in the

first yearGoal ID

O1 G1 Create savings for billers and customers that use the EBPPservice

O1 G2 Promote products and services based on customer identifiedneeds and characteristics

Figure 6The `Billing Mallrsquorsquo

Internet bill presentationand payment system

BIJ92

176

In addition firewalls were selected as the first line of defence for all entities(excluding the customer) in the ` Billing Mallrsquorsquo system It was suggested thatimportant information should only be accepted from and delivered to serverswith a specific IP address Example procedures taking advantage of thisfeature were that

the consolidator only accepts bill summary information from a small setof IP addresses in the billerrsquos domain and

the consolidator only forwards customersrsquo payment requests to thespecific BPP IP address

Table VIIIIdentified threats

Threat ID Vulnerability ID Description

T1 V1 External attempts to unauthorised accessT2 V1 Internal attempts to unauthorised accessT3 V2 Modification of bill payment data

Table IVInformation setsdefined during thebusiness needs analysisstep

Information set ID Description

11 Customer profile12 Bill information13 Bill payment order

Table VCSFs defined duringthe business needsanalysis step

Goal ID CSF ID Information set ID Description

G1 CSF1 12 13 Provide non-repudiation for payment transactionsG2 CSF2 11 Ensure confidentiality of collected customer

information

Table VIIIdentifiedvulnerabilities

Vulnerability ID Asset ID Description

V1 A1 Unauthorised access to informationV2 A2 Unauthorised access to information

Table VIIdentified assets

Asset ID Information set ID Description

A1 11 Customer databaseA2 12 13 Bill payment order database

Securingtransactions over

the Web

177

During the monitoring research and analysis step it was revealed that the OIBmodel alone was not adequate to provide the anticipated level of security andreliability It was subsequently extended in order to accommodate theestablishment of a certification authority (CA) issuing and disseminatingdigital certificates to the customers (see Figure 3) Furthermore as a means foraddressing the risk of insolvent customers issuing payment transactions thatcould not be completed due to insufficient credit a credit bureau entity wasadded to the architectural model of the system (see Figure 3) The functionalrole of this entity is the provision of information related to the credit status ofcustomers eliminating the possibility of financial damage

Infusing security semantics in process specificationsOur aim during the design of the `Billing Mallrsquorsquo was that the objectives of theinformation security strategy had to be integrated in the development processIn line with the suggestion by Rohm et al (1998) as described elsewhere in thispaper we present an example of analysing the business process informationaland behavioural views of the ` bill-payment-orderrsquorsquo business process (step 17 inFigure 6) and its security requirement ` non-repudiationrsquorsquo (risk R4 in Table IX)We use the following notation components of existing model or attributes thatare not affected by security requirements are described using normal text Theattributes with relevance to non-repudiation are given in bold face

Business process viewThe European Communityrsquos 199993EC Directive requires documents to besigned digitally in electronic business transactions Examining this issue froma business process view perspective allows us to capture the security semanticsof business transactions and integrate them in the design of the process

Figures 7 and 8 depict graphically the ` bill-payment-orderrsquorsquo process usingUnified Modelling Language (UML) use case and activity diagrams The usecase diagram in Figure 7 depicts the scenarios and actors involved in thebusiness process of our example while Figure 8 shows the activities performedin completing the PayBill use case In order to meet the ` `non-repudiationrsquorsquorequirement our model has been extended by the appropriate actors(certification authority signature manager) use cases (certificate renewalpayment order archival) and activities (verify digital signature verifycertificate validity)

Table IXIdentified risks

Risk ID Threat ID CSF IDRiskclassification Description

R1 T1 CSF2 D IP spoofing or misrepresentationR2 T2 CSF2 C Data tamperingR3 T1 T2 CSF2 C Eavesdropping and password sniffingR4 T3 CSF1 D Repudiation of bill payment order

BIJ92

178

Figure 8Activity diagramillustrating securitysemantics of PayBill

Figure 7Business process viewextended by securitysemantics

Securingtransactions over

the Web

179

Informational viewThe same European Community directive requires that in order to sign anelectronic document the ` sealrsquorsquo or digital signature of each signatory and thecorresponding certificates are necessary Accordingly to carry out the ` bill-payment-orderrsquorsquo process effectively and to establish non-repudiation theinformational view of the transaction had to be extended by information about thesignatories the certificates used and the trusted parties responsible for issuingthe certificates The analysis and modelling can be performed using UML classdiagrams In Figure 9 we have extended the class diagram containing thecustomer-biller relationship of our example by appropriate classes and memberfields necessary for supporting non-repudiation These are

A new class certification authority

A new association class certificate

Modification of the existing committal class by adding the appropriatefields for the digital signatures and information about what algorithmswere used for signing The commital class is used to model any kind ofdocument that should be signed by a customer (bill payment order) abiller (bill statement) or both (service level agreement)

In addition customer and biller are manifestations of a generic type signerwhich must have a certificate relating the signer to a certification authority

Behavioural viewThe interactions and corresponding information flows between the entitiesinvolved in the ` bill-payment-orderrsquorsquo process can be analysed through thebehavioural view using UML sequence diagrams In order to assure non-

Figure 9Informational view

extended by securitysemantics

BIJ92

180

repudiation the behavioural view of the process had to be modified as depictedin Figure 10 The customer must digitally sign the bill payment order and thesignature must be verified In addition because the certificate of a public keymay have expired further actions are necessary to guarantee the provability ofdigitally signed documents These actions lead for example to extensions ofthe behavioural view of an object class (verifier) responsible for validating theintegrity and provability of the payment order Again in Figure 10 necessaryextensions due to security requirements are given in bold face (the sequencediagram has been enhanced by the use of scripts for accommodating complexscenarios involving conditions and iterations)

Using the views suggested by Rohm et al (1998) for analysing andmodelling the security semantics of business processes this section offered anexample of a single transaction and the security requirements that had to beinfused and performed by the ` Billing Mallrsquorsquo It becomes clear that by modellingand analysing the security semantics of the business transactions it supportsthe IS and its security are not treated as separate developments As the formerbecomes part of the design process the possible duality as a cause for conflict(Baskerville 1993) is eliminated

Figure 10Behavioural viewextended by securitysemantics

Securingtransactions over

the Web

181

ConclusionsIn this article we presented an integrated approach for the development of aninformation security strategy based on a rigorous multi-level and multi-dimensional model The position that any security strategy must evolveconcurrently with the design of the system and not be approached as anafterthought is reflected in the model which monitors closely the developmentphases of an IS and addresses security at the business process level Enablingthe practitioner to evaluate and use the available security tools and techniquesin a consistent manner the structure of the model enforces the view that anysecurity strategy must be conducted primarily at a higher level and not be seenmerely as a local technology issue Without doubt we believe that the approachpresented herein could be further refined and enhanced We hope that itsfurther adoption will result in any necessary enhancements or modificationsincrementing thus its value regarding its practical applicability ` Waterproofrsquorsquosecurity of large inter-organizational systems is an issue of immensecomplexity but we believe that we have at least made a few but necessarysteps towards meeting this challenge

References

Abela A and Sacconaghi JR (1997) ` Value exchange the secret of building customerrelationships on linersquorsquo The McKinsey Quarterly Vol 2 pp 216-19

Baskerville R (1993) ` Information systems security design methods implications forinformation systems developmentrsquorsquo ACM Computing Surveys Vol 25 No 4 pp 375-414

Derivion Corp (1999) ` Internet billing and the mid-tier biller enjoying the benefits of electronicbill presentment and payment without operational compromisersquorsquo available at httpwwwderivioncomindex 9html

Hughes E (1997) `A long-term perspective on electronic commercersquorsquo Networker NovemberDecember Vol 38 p 50

Kruchten P (2000) The Rational Unified Process ndash An Introduction Addison-Wesley ReadingMA

Papadopoulou P Triantafillakis A Kanellis P and Martakos D (2000) `A generic frameworkfor the deployment of an Internet billing servicescapersquorsquo Proceedings of the 1st WorldCongress of Electronic Commerce Hamilton Ontario 19-21 January

Rohm AW Pernul G and Herrman G (1998) `Modelling secure and fair electronic commercersquorsquoProceedings of the 14th Annual Computer Security Applications Conference ScottsdaleAZ 7-11 December IEEE Computer Society Press

Segev A Porra J and Roldan M (1998) ` Internet security and the case of Bank of AmericarsquorsquoCommunications of the ACM Vol 41 October pp 81-7

Walker KM and Cavanaugh LC (1998) Computer Security Policies and SunScreen FirewallsSun Microsystems Press

Wanninger L Anderson C and Hansen R (1997) `Designing servicescapes for electroniccommerce an evolutionary approachrsquorsquo available at httpwwwmisrcumneduwpaperdefaultasp

BIJ92

176

In addition firewalls were selected as the first line of defence for all entities(excluding the customer) in the ` Billing Mallrsquorsquo system It was suggested thatimportant information should only be accepted from and delivered to serverswith a specific IP address Example procedures taking advantage of thisfeature were that

the consolidator only accepts bill summary information from a small setof IP addresses in the billerrsquos domain and

the consolidator only forwards customersrsquo payment requests to thespecific BPP IP address

Table VIIIIdentified threats

Threat ID Vulnerability ID Description

T1 V1 External attempts to unauthorised accessT2 V1 Internal attempts to unauthorised accessT3 V2 Modification of bill payment data

Table IVInformation setsdefined during thebusiness needs analysisstep

Information set ID Description

11 Customer profile12 Bill information13 Bill payment order

Table VCSFs defined duringthe business needsanalysis step

Goal ID CSF ID Information set ID Description

G1 CSF1 12 13 Provide non-repudiation for payment transactionsG2 CSF2 11 Ensure confidentiality of collected customer

information

Table VIIIdentifiedvulnerabilities

Vulnerability ID Asset ID Description

V1 A1 Unauthorised access to informationV2 A2 Unauthorised access to information

Table VIIdentified assets

Asset ID Information set ID Description

A1 11 Customer databaseA2 12 13 Bill payment order database

Securingtransactions over

the Web

177

During the monitoring research and analysis step it was revealed that the OIBmodel alone was not adequate to provide the anticipated level of security andreliability It was subsequently extended in order to accommodate theestablishment of a certification authority (CA) issuing and disseminatingdigital certificates to the customers (see Figure 3) Furthermore as a means foraddressing the risk of insolvent customers issuing payment transactions thatcould not be completed due to insufficient credit a credit bureau entity wasadded to the architectural model of the system (see Figure 3) The functionalrole of this entity is the provision of information related to the credit status ofcustomers eliminating the possibility of financial damage

Infusing security semantics in process specificationsOur aim during the design of the `Billing Mallrsquorsquo was that the objectives of theinformation security strategy had to be integrated in the development processIn line with the suggestion by Rohm et al (1998) as described elsewhere in thispaper we present an example of analysing the business process informationaland behavioural views of the ` bill-payment-orderrsquorsquo business process (step 17 inFigure 6) and its security requirement ` non-repudiationrsquorsquo (risk R4 in Table IX)We use the following notation components of existing model or attributes thatare not affected by security requirements are described using normal text Theattributes with relevance to non-repudiation are given in bold face

Business process viewThe European Communityrsquos 199993EC Directive requires documents to besigned digitally in electronic business transactions Examining this issue froma business process view perspective allows us to capture the security semanticsof business transactions and integrate them in the design of the process

Figures 7 and 8 depict graphically the ` bill-payment-orderrsquorsquo process usingUnified Modelling Language (UML) use case and activity diagrams The usecase diagram in Figure 7 depicts the scenarios and actors involved in thebusiness process of our example while Figure 8 shows the activities performedin completing the PayBill use case In order to meet the ` `non-repudiationrsquorsquorequirement our model has been extended by the appropriate actors(certification authority signature manager) use cases (certificate renewalpayment order archival) and activities (verify digital signature verifycertificate validity)

Table IXIdentified risks

Risk ID Threat ID CSF IDRiskclassification Description

R1 T1 CSF2 D IP spoofing or misrepresentationR2 T2 CSF2 C Data tamperingR3 T1 T2 CSF2 C Eavesdropping and password sniffingR4 T3 CSF1 D Repudiation of bill payment order

BIJ92

178

Figure 8Activity diagramillustrating securitysemantics of PayBill

Figure 7Business process viewextended by securitysemantics

Securingtransactions over

the Web

179

Informational viewThe same European Community directive requires that in order to sign anelectronic document the ` sealrsquorsquo or digital signature of each signatory and thecorresponding certificates are necessary Accordingly to carry out the ` bill-payment-orderrsquorsquo process effectively and to establish non-repudiation theinformational view of the transaction had to be extended by information about thesignatories the certificates used and the trusted parties responsible for issuingthe certificates The analysis and modelling can be performed using UML classdiagrams In Figure 9 we have extended the class diagram containing thecustomer-biller relationship of our example by appropriate classes and memberfields necessary for supporting non-repudiation These are

A new class certification authority

A new association class certificate

Modification of the existing committal class by adding the appropriatefields for the digital signatures and information about what algorithmswere used for signing The commital class is used to model any kind ofdocument that should be signed by a customer (bill payment order) abiller (bill statement) or both (service level agreement)

In addition customer and biller are manifestations of a generic type signerwhich must have a certificate relating the signer to a certification authority

Behavioural viewThe interactions and corresponding information flows between the entitiesinvolved in the ` bill-payment-orderrsquorsquo process can be analysed through thebehavioural view using UML sequence diagrams In order to assure non-

Figure 9Informational view

extended by securitysemantics

BIJ92

180

repudiation the behavioural view of the process had to be modified as depictedin Figure 10 The customer must digitally sign the bill payment order and thesignature must be verified In addition because the certificate of a public keymay have expired further actions are necessary to guarantee the provability ofdigitally signed documents These actions lead for example to extensions ofthe behavioural view of an object class (verifier) responsible for validating theintegrity and provability of the payment order Again in Figure 10 necessaryextensions due to security requirements are given in bold face (the sequencediagram has been enhanced by the use of scripts for accommodating complexscenarios involving conditions and iterations)

Using the views suggested by Rohm et al (1998) for analysing andmodelling the security semantics of business processes this section offered anexample of a single transaction and the security requirements that had to beinfused and performed by the ` Billing Mallrsquorsquo It becomes clear that by modellingand analysing the security semantics of the business transactions it supportsthe IS and its security are not treated as separate developments As the formerbecomes part of the design process the possible duality as a cause for conflict(Baskerville 1993) is eliminated

Figure 10Behavioural viewextended by securitysemantics

Securingtransactions over

the Web

181

ConclusionsIn this article we presented an integrated approach for the development of aninformation security strategy based on a rigorous multi-level and multi-dimensional model The position that any security strategy must evolveconcurrently with the design of the system and not be approached as anafterthought is reflected in the model which monitors closely the developmentphases of an IS and addresses security at the business process level Enablingthe practitioner to evaluate and use the available security tools and techniquesin a consistent manner the structure of the model enforces the view that anysecurity strategy must be conducted primarily at a higher level and not be seenmerely as a local technology issue Without doubt we believe that the approachpresented herein could be further refined and enhanced We hope that itsfurther adoption will result in any necessary enhancements or modificationsincrementing thus its value regarding its practical applicability ` Waterproofrsquorsquosecurity of large inter-organizational systems is an issue of immensecomplexity but we believe that we have at least made a few but necessarysteps towards meeting this challenge

References

Abela A and Sacconaghi JR (1997) ` Value exchange the secret of building customerrelationships on linersquorsquo The McKinsey Quarterly Vol 2 pp 216-19

Baskerville R (1993) ` Information systems security design methods implications forinformation systems developmentrsquorsquo ACM Computing Surveys Vol 25 No 4 pp 375-414

Derivion Corp (1999) ` Internet billing and the mid-tier biller enjoying the benefits of electronicbill presentment and payment without operational compromisersquorsquo available at httpwwwderivioncomindex 9html

Hughes E (1997) `A long-term perspective on electronic commercersquorsquo Networker NovemberDecember Vol 38 p 50

Kruchten P (2000) The Rational Unified Process ndash An Introduction Addison-Wesley ReadingMA

Papadopoulou P Triantafillakis A Kanellis P and Martakos D (2000) `A generic frameworkfor the deployment of an Internet billing servicescapersquorsquo Proceedings of the 1st WorldCongress of Electronic Commerce Hamilton Ontario 19-21 January

Rohm AW Pernul G and Herrman G (1998) `Modelling secure and fair electronic commercersquorsquoProceedings of the 14th Annual Computer Security Applications Conference ScottsdaleAZ 7-11 December IEEE Computer Society Press

Segev A Porra J and Roldan M (1998) ` Internet security and the case of Bank of AmericarsquorsquoCommunications of the ACM Vol 41 October pp 81-7

Walker KM and Cavanaugh LC (1998) Computer Security Policies and SunScreen FirewallsSun Microsystems Press

Wanninger L Anderson C and Hansen R (1997) `Designing servicescapes for electroniccommerce an evolutionary approachrsquorsquo available at httpwwwmisrcumneduwpaperdefaultasp

Securingtransactions over

the Web

177

During the monitoring research and analysis step it was revealed that the OIBmodel alone was not adequate to provide the anticipated level of security andreliability It was subsequently extended in order to accommodate theestablishment of a certification authority (CA) issuing and disseminatingdigital certificates to the customers (see Figure 3) Furthermore as a means foraddressing the risk of insolvent customers issuing payment transactions thatcould not be completed due to insufficient credit a credit bureau entity wasadded to the architectural model of the system (see Figure 3) The functionalrole of this entity is the provision of information related to the credit status ofcustomers eliminating the possibility of financial damage

Infusing security semantics in process specificationsOur aim during the design of the `Billing Mallrsquorsquo was that the objectives of theinformation security strategy had to be integrated in the development processIn line with the suggestion by Rohm et al (1998) as described elsewhere in thispaper we present an example of analysing the business process informationaland behavioural views of the ` bill-payment-orderrsquorsquo business process (step 17 inFigure 6) and its security requirement ` non-repudiationrsquorsquo (risk R4 in Table IX)We use the following notation components of existing model or attributes thatare not affected by security requirements are described using normal text Theattributes with relevance to non-repudiation are given in bold face

Business process viewThe European Communityrsquos 199993EC Directive requires documents to besigned digitally in electronic business transactions Examining this issue froma business process view perspective allows us to capture the security semanticsof business transactions and integrate them in the design of the process

Figures 7 and 8 depict graphically the ` bill-payment-orderrsquorsquo process usingUnified Modelling Language (UML) use case and activity diagrams The usecase diagram in Figure 7 depicts the scenarios and actors involved in thebusiness process of our example while Figure 8 shows the activities performedin completing the PayBill use case In order to meet the ` `non-repudiationrsquorsquorequirement our model has been extended by the appropriate actors(certification authority signature manager) use cases (certificate renewalpayment order archival) and activities (verify digital signature verifycertificate validity)

Table IXIdentified risks

Risk ID Threat ID CSF IDRiskclassification Description

R1 T1 CSF2 D IP spoofing or misrepresentationR2 T2 CSF2 C Data tamperingR3 T1 T2 CSF2 C Eavesdropping and password sniffingR4 T3 CSF1 D Repudiation of bill payment order

BIJ92

178

Figure 8Activity diagramillustrating securitysemantics of PayBill

Figure 7Business process viewextended by securitysemantics

Securingtransactions over

the Web

179

Informational viewThe same European Community directive requires that in order to sign anelectronic document the ` sealrsquorsquo or digital signature of each signatory and thecorresponding certificates are necessary Accordingly to carry out the ` bill-payment-orderrsquorsquo process effectively and to establish non-repudiation theinformational view of the transaction had to be extended by information about thesignatories the certificates used and the trusted parties responsible for issuingthe certificates The analysis and modelling can be performed using UML classdiagrams In Figure 9 we have extended the class diagram containing thecustomer-biller relationship of our example by appropriate classes and memberfields necessary for supporting non-repudiation These are

A new class certification authority

A new association class certificate

Modification of the existing committal class by adding the appropriatefields for the digital signatures and information about what algorithmswere used for signing The commital class is used to model any kind ofdocument that should be signed by a customer (bill payment order) abiller (bill statement) or both (service level agreement)

In addition customer and biller are manifestations of a generic type signerwhich must have a certificate relating the signer to a certification authority

Behavioural viewThe interactions and corresponding information flows between the entitiesinvolved in the ` bill-payment-orderrsquorsquo process can be analysed through thebehavioural view using UML sequence diagrams In order to assure non-

Figure 9Informational view

extended by securitysemantics

BIJ92

180

repudiation the behavioural view of the process had to be modified as depictedin Figure 10 The customer must digitally sign the bill payment order and thesignature must be verified In addition because the certificate of a public keymay have expired further actions are necessary to guarantee the provability ofdigitally signed documents These actions lead for example to extensions ofthe behavioural view of an object class (verifier) responsible for validating theintegrity and provability of the payment order Again in Figure 10 necessaryextensions due to security requirements are given in bold face (the sequencediagram has been enhanced by the use of scripts for accommodating complexscenarios involving conditions and iterations)

Using the views suggested by Rohm et al (1998) for analysing andmodelling the security semantics of business processes this section offered anexample of a single transaction and the security requirements that had to beinfused and performed by the ` Billing Mallrsquorsquo It becomes clear that by modellingand analysing the security semantics of the business transactions it supportsthe IS and its security are not treated as separate developments As the formerbecomes part of the design process the possible duality as a cause for conflict(Baskerville 1993) is eliminated

Figure 10Behavioural viewextended by securitysemantics

Securingtransactions over

the Web

181

ConclusionsIn this article we presented an integrated approach for the development of aninformation security strategy based on a rigorous multi-level and multi-dimensional model The position that any security strategy must evolveconcurrently with the design of the system and not be approached as anafterthought is reflected in the model which monitors closely the developmentphases of an IS and addresses security at the business process level Enablingthe practitioner to evaluate and use the available security tools and techniquesin a consistent manner the structure of the model enforces the view that anysecurity strategy must be conducted primarily at a higher level and not be seenmerely as a local technology issue Without doubt we believe that the approachpresented herein could be further refined and enhanced We hope that itsfurther adoption will result in any necessary enhancements or modificationsincrementing thus its value regarding its practical applicability ` Waterproofrsquorsquosecurity of large inter-organizational systems is an issue of immensecomplexity but we believe that we have at least made a few but necessarysteps towards meeting this challenge

References

Abela A and Sacconaghi JR (1997) ` Value exchange the secret of building customerrelationships on linersquorsquo The McKinsey Quarterly Vol 2 pp 216-19

Baskerville R (1993) ` Information systems security design methods implications forinformation systems developmentrsquorsquo ACM Computing Surveys Vol 25 No 4 pp 375-414

Derivion Corp (1999) ` Internet billing and the mid-tier biller enjoying the benefits of electronicbill presentment and payment without operational compromisersquorsquo available at httpwwwderivioncomindex 9html

Hughes E (1997) `A long-term perspective on electronic commercersquorsquo Networker NovemberDecember Vol 38 p 50

Kruchten P (2000) The Rational Unified Process ndash An Introduction Addison-Wesley ReadingMA

Papadopoulou P Triantafillakis A Kanellis P and Martakos D (2000) `A generic frameworkfor the deployment of an Internet billing servicescapersquorsquo Proceedings of the 1st WorldCongress of Electronic Commerce Hamilton Ontario 19-21 January

Rohm AW Pernul G and Herrman G (1998) `Modelling secure and fair electronic commercersquorsquoProceedings of the 14th Annual Computer Security Applications Conference ScottsdaleAZ 7-11 December IEEE Computer Society Press

Segev A Porra J and Roldan M (1998) ` Internet security and the case of Bank of AmericarsquorsquoCommunications of the ACM Vol 41 October pp 81-7

Walker KM and Cavanaugh LC (1998) Computer Security Policies and SunScreen FirewallsSun Microsystems Press

Wanninger L Anderson C and Hansen R (1997) `Designing servicescapes for electroniccommerce an evolutionary approachrsquorsquo available at httpwwwmisrcumneduwpaperdefaultasp

BIJ92

178

Figure 8Activity diagramillustrating securitysemantics of PayBill

Figure 7Business process viewextended by securitysemantics

Securingtransactions over

the Web

179

Informational viewThe same European Community directive requires that in order to sign anelectronic document the ` sealrsquorsquo or digital signature of each signatory and thecorresponding certificates are necessary Accordingly to carry out the ` bill-payment-orderrsquorsquo process effectively and to establish non-repudiation theinformational view of the transaction had to be extended by information about thesignatories the certificates used and the trusted parties responsible for issuingthe certificates The analysis and modelling can be performed using UML classdiagrams In Figure 9 we have extended the class diagram containing thecustomer-biller relationship of our example by appropriate classes and memberfields necessary for supporting non-repudiation These are

A new class certification authority

A new association class certificate

Modification of the existing committal class by adding the appropriatefields for the digital signatures and information about what algorithmswere used for signing The commital class is used to model any kind ofdocument that should be signed by a customer (bill payment order) abiller (bill statement) or both (service level agreement)

In addition customer and biller are manifestations of a generic type signerwhich must have a certificate relating the signer to a certification authority

Behavioural viewThe interactions and corresponding information flows between the entitiesinvolved in the ` bill-payment-orderrsquorsquo process can be analysed through thebehavioural view using UML sequence diagrams In order to assure non-

Figure 9Informational view

extended by securitysemantics

BIJ92

180

repudiation the behavioural view of the process had to be modified as depictedin Figure 10 The customer must digitally sign the bill payment order and thesignature must be verified In addition because the certificate of a public keymay have expired further actions are necessary to guarantee the provability ofdigitally signed documents These actions lead for example to extensions ofthe behavioural view of an object class (verifier) responsible for validating theintegrity and provability of the payment order Again in Figure 10 necessaryextensions due to security requirements are given in bold face (the sequencediagram has been enhanced by the use of scripts for accommodating complexscenarios involving conditions and iterations)

Using the views suggested by Rohm et al (1998) for analysing andmodelling the security semantics of business processes this section offered anexample of a single transaction and the security requirements that had to beinfused and performed by the ` Billing Mallrsquorsquo It becomes clear that by modellingand analysing the security semantics of the business transactions it supportsthe IS and its security are not treated as separate developments As the formerbecomes part of the design process the possible duality as a cause for conflict(Baskerville 1993) is eliminated

Figure 10Behavioural viewextended by securitysemantics

Securingtransactions over

the Web

181

ConclusionsIn this article we presented an integrated approach for the development of aninformation security strategy based on a rigorous multi-level and multi-dimensional model The position that any security strategy must evolveconcurrently with the design of the system and not be approached as anafterthought is reflected in the model which monitors closely the developmentphases of an IS and addresses security at the business process level Enablingthe practitioner to evaluate and use the available security tools and techniquesin a consistent manner the structure of the model enforces the view that anysecurity strategy must be conducted primarily at a higher level and not be seenmerely as a local technology issue Without doubt we believe that the approachpresented herein could be further refined and enhanced We hope that itsfurther adoption will result in any necessary enhancements or modificationsincrementing thus its value regarding its practical applicability ` Waterproofrsquorsquosecurity of large inter-organizational systems is an issue of immensecomplexity but we believe that we have at least made a few but necessarysteps towards meeting this challenge

References

Abela A and Sacconaghi JR (1997) ` Value exchange the secret of building customerrelationships on linersquorsquo The McKinsey Quarterly Vol 2 pp 216-19

Baskerville R (1993) ` Information systems security design methods implications forinformation systems developmentrsquorsquo ACM Computing Surveys Vol 25 No 4 pp 375-414

Derivion Corp (1999) ` Internet billing and the mid-tier biller enjoying the benefits of electronicbill presentment and payment without operational compromisersquorsquo available at httpwwwderivioncomindex 9html

Hughes E (1997) `A long-term perspective on electronic commercersquorsquo Networker NovemberDecember Vol 38 p 50

Kruchten P (2000) The Rational Unified Process ndash An Introduction Addison-Wesley ReadingMA

Papadopoulou P Triantafillakis A Kanellis P and Martakos D (2000) `A generic frameworkfor the deployment of an Internet billing servicescapersquorsquo Proceedings of the 1st WorldCongress of Electronic Commerce Hamilton Ontario 19-21 January

Rohm AW Pernul G and Herrman G (1998) `Modelling secure and fair electronic commercersquorsquoProceedings of the 14th Annual Computer Security Applications Conference ScottsdaleAZ 7-11 December IEEE Computer Society Press

Segev A Porra J and Roldan M (1998) ` Internet security and the case of Bank of AmericarsquorsquoCommunications of the ACM Vol 41 October pp 81-7

Walker KM and Cavanaugh LC (1998) Computer Security Policies and SunScreen FirewallsSun Microsystems Press

Wanninger L Anderson C and Hansen R (1997) `Designing servicescapes for electroniccommerce an evolutionary approachrsquorsquo available at httpwwwmisrcumneduwpaperdefaultasp

Securingtransactions over

the Web

179

Informational viewThe same European Community directive requires that in order to sign anelectronic document the ` sealrsquorsquo or digital signature of each signatory and thecorresponding certificates are necessary Accordingly to carry out the ` bill-payment-orderrsquorsquo process effectively and to establish non-repudiation theinformational view of the transaction had to be extended by information about thesignatories the certificates used and the trusted parties responsible for issuingthe certificates The analysis and modelling can be performed using UML classdiagrams In Figure 9 we have extended the class diagram containing thecustomer-biller relationship of our example by appropriate classes and memberfields necessary for supporting non-repudiation These are

A new class certification authority

A new association class certificate

Modification of the existing committal class by adding the appropriatefields for the digital signatures and information about what algorithmswere used for signing The commital class is used to model any kind ofdocument that should be signed by a customer (bill payment order) abiller (bill statement) or both (service level agreement)

In addition customer and biller are manifestations of a generic type signerwhich must have a certificate relating the signer to a certification authority

Behavioural viewThe interactions and corresponding information flows between the entitiesinvolved in the ` bill-payment-orderrsquorsquo process can be analysed through thebehavioural view using UML sequence diagrams In order to assure non-

Figure 9Informational view

extended by securitysemantics

BIJ92

180

repudiation the behavioural view of the process had to be modified as depictedin Figure 10 The customer must digitally sign the bill payment order and thesignature must be verified In addition because the certificate of a public keymay have expired further actions are necessary to guarantee the provability ofdigitally signed documents These actions lead for example to extensions ofthe behavioural view of an object class (verifier) responsible for validating theintegrity and provability of the payment order Again in Figure 10 necessaryextensions due to security requirements are given in bold face (the sequencediagram has been enhanced by the use of scripts for accommodating complexscenarios involving conditions and iterations)

Using the views suggested by Rohm et al (1998) for analysing andmodelling the security semantics of business processes this section offered anexample of a single transaction and the security requirements that had to beinfused and performed by the ` Billing Mallrsquorsquo It becomes clear that by modellingand analysing the security semantics of the business transactions it supportsthe IS and its security are not treated as separate developments As the formerbecomes part of the design process the possible duality as a cause for conflict(Baskerville 1993) is eliminated

Figure 10Behavioural viewextended by securitysemantics

Securingtransactions over

the Web

181

ConclusionsIn this article we presented an integrated approach for the development of aninformation security strategy based on a rigorous multi-level and multi-dimensional model The position that any security strategy must evolveconcurrently with the design of the system and not be approached as anafterthought is reflected in the model which monitors closely the developmentphases of an IS and addresses security at the business process level Enablingthe practitioner to evaluate and use the available security tools and techniquesin a consistent manner the structure of the model enforces the view that anysecurity strategy must be conducted primarily at a higher level and not be seenmerely as a local technology issue Without doubt we believe that the approachpresented herein could be further refined and enhanced We hope that itsfurther adoption will result in any necessary enhancements or modificationsincrementing thus its value regarding its practical applicability ` Waterproofrsquorsquosecurity of large inter-organizational systems is an issue of immensecomplexity but we believe that we have at least made a few but necessarysteps towards meeting this challenge

References

Abela A and Sacconaghi JR (1997) ` Value exchange the secret of building customerrelationships on linersquorsquo The McKinsey Quarterly Vol 2 pp 216-19

Baskerville R (1993) ` Information systems security design methods implications forinformation systems developmentrsquorsquo ACM Computing Surveys Vol 25 No 4 pp 375-414

Derivion Corp (1999) ` Internet billing and the mid-tier biller enjoying the benefits of electronicbill presentment and payment without operational compromisersquorsquo available at httpwwwderivioncomindex 9html

Hughes E (1997) `A long-term perspective on electronic commercersquorsquo Networker NovemberDecember Vol 38 p 50

Kruchten P (2000) The Rational Unified Process ndash An Introduction Addison-Wesley ReadingMA

Papadopoulou P Triantafillakis A Kanellis P and Martakos D (2000) `A generic frameworkfor the deployment of an Internet billing servicescapersquorsquo Proceedings of the 1st WorldCongress of Electronic Commerce Hamilton Ontario 19-21 January

Rohm AW Pernul G and Herrman G (1998) `Modelling secure and fair electronic commercersquorsquoProceedings of the 14th Annual Computer Security Applications Conference ScottsdaleAZ 7-11 December IEEE Computer Society Press

Segev A Porra J and Roldan M (1998) ` Internet security and the case of Bank of AmericarsquorsquoCommunications of the ACM Vol 41 October pp 81-7

Walker KM and Cavanaugh LC (1998) Computer Security Policies and SunScreen FirewallsSun Microsystems Press

Wanninger L Anderson C and Hansen R (1997) `Designing servicescapes for electroniccommerce an evolutionary approachrsquorsquo available at httpwwwmisrcumneduwpaperdefaultasp

BIJ92

180

repudiation the behavioural view of the process had to be modified as depictedin Figure 10 The customer must digitally sign the bill payment order and thesignature must be verified In addition because the certificate of a public keymay have expired further actions are necessary to guarantee the provability ofdigitally signed documents These actions lead for example to extensions ofthe behavioural view of an object class (verifier) responsible for validating theintegrity and provability of the payment order Again in Figure 10 necessaryextensions due to security requirements are given in bold face (the sequencediagram has been enhanced by the use of scripts for accommodating complexscenarios involving conditions and iterations)

Using the views suggested by Rohm et al (1998) for analysing andmodelling the security semantics of business processes this section offered anexample of a single transaction and the security requirements that had to beinfused and performed by the ` Billing Mallrsquorsquo It becomes clear that by modellingand analysing the security semantics of the business transactions it supportsthe IS and its security are not treated as separate developments As the formerbecomes part of the design process the possible duality as a cause for conflict(Baskerville 1993) is eliminated

Figure 10Behavioural viewextended by securitysemantics

Securingtransactions over

the Web

181

ConclusionsIn this article we presented an integrated approach for the development of aninformation security strategy based on a rigorous multi-level and multi-dimensional model The position that any security strategy must evolveconcurrently with the design of the system and not be approached as anafterthought is reflected in the model which monitors closely the developmentphases of an IS and addresses security at the business process level Enablingthe practitioner to evaluate and use the available security tools and techniquesin a consistent manner the structure of the model enforces the view that anysecurity strategy must be conducted primarily at a higher level and not be seenmerely as a local technology issue Without doubt we believe that the approachpresented herein could be further refined and enhanced We hope that itsfurther adoption will result in any necessary enhancements or modificationsincrementing thus its value regarding its practical applicability ` Waterproofrsquorsquosecurity of large inter-organizational systems is an issue of immensecomplexity but we believe that we have at least made a few but necessarysteps towards meeting this challenge

References

Abela A and Sacconaghi JR (1997) ` Value exchange the secret of building customerrelationships on linersquorsquo The McKinsey Quarterly Vol 2 pp 216-19

Baskerville R (1993) ` Information systems security design methods implications forinformation systems developmentrsquorsquo ACM Computing Surveys Vol 25 No 4 pp 375-414

Derivion Corp (1999) ` Internet billing and the mid-tier biller enjoying the benefits of electronicbill presentment and payment without operational compromisersquorsquo available at httpwwwderivioncomindex 9html

Hughes E (1997) `A long-term perspective on electronic commercersquorsquo Networker NovemberDecember Vol 38 p 50

Kruchten P (2000) The Rational Unified Process ndash An Introduction Addison-Wesley ReadingMA

Papadopoulou P Triantafillakis A Kanellis P and Martakos D (2000) `A generic frameworkfor the deployment of an Internet billing servicescapersquorsquo Proceedings of the 1st WorldCongress of Electronic Commerce Hamilton Ontario 19-21 January

Rohm AW Pernul G and Herrman G (1998) `Modelling secure and fair electronic commercersquorsquoProceedings of the 14th Annual Computer Security Applications Conference ScottsdaleAZ 7-11 December IEEE Computer Society Press

Segev A Porra J and Roldan M (1998) ` Internet security and the case of Bank of AmericarsquorsquoCommunications of the ACM Vol 41 October pp 81-7

Walker KM and Cavanaugh LC (1998) Computer Security Policies and SunScreen FirewallsSun Microsystems Press

Wanninger L Anderson C and Hansen R (1997) `Designing servicescapes for electroniccommerce an evolutionary approachrsquorsquo available at httpwwwmisrcumneduwpaperdefaultasp

Securingtransactions over

the Web

181

ConclusionsIn this article we presented an integrated approach for the development of aninformation security strategy based on a rigorous multi-level and multi-dimensional model The position that any security strategy must evolveconcurrently with the design of the system and not be approached as anafterthought is reflected in the model which monitors closely the developmentphases of an IS and addresses security at the business process level Enablingthe practitioner to evaluate and use the available security tools and techniquesin a consistent manner the structure of the model enforces the view that anysecurity strategy must be conducted primarily at a higher level and not be seenmerely as a local technology issue Without doubt we believe that the approachpresented herein could be further refined and enhanced We hope that itsfurther adoption will result in any necessary enhancements or modificationsincrementing thus its value regarding its practical applicability ` Waterproofrsquorsquosecurity of large inter-organizational systems is an issue of immensecomplexity but we believe that we have at least made a few but necessarysteps towards meeting this challenge

References

Abela A and Sacconaghi JR (1997) ` Value exchange the secret of building customerrelationships on linersquorsquo The McKinsey Quarterly Vol 2 pp 216-19

Baskerville R (1993) ` Information systems security design methods implications forinformation systems developmentrsquorsquo ACM Computing Surveys Vol 25 No 4 pp 375-414

Derivion Corp (1999) ` Internet billing and the mid-tier biller enjoying the benefits of electronicbill presentment and payment without operational compromisersquorsquo available at httpwwwderivioncomindex 9html

Hughes E (1997) `A long-term perspective on electronic commercersquorsquo Networker NovemberDecember Vol 38 p 50

Kruchten P (2000) The Rational Unified Process ndash An Introduction Addison-Wesley ReadingMA

Papadopoulou P Triantafillakis A Kanellis P and Martakos D (2000) `A generic frameworkfor the deployment of an Internet billing servicescapersquorsquo Proceedings of the 1st WorldCongress of Electronic Commerce Hamilton Ontario 19-21 January

Rohm AW Pernul G and Herrman G (1998) `Modelling secure and fair electronic commercersquorsquoProceedings of the 14th Annual Computer Security Applications Conference ScottsdaleAZ 7-11 December IEEE Computer Society Press

Segev A Porra J and Roldan M (1998) ` Internet security and the case of Bank of AmericarsquorsquoCommunications of the ACM Vol 41 October pp 81-7

Walker KM and Cavanaugh LC (1998) Computer Security Policies and SunScreen FirewallsSun Microsystems Press

Wanninger L Anderson C and Hansen R (1997) `Designing servicescapes for electroniccommerce an evolutionary approachrsquorsquo available at httpwwwmisrcumneduwpaperdefaultasp