Upload
halien
View
216
Download
1
Embed Size (px)
Citation preview
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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