Electronic Business: Concepts, Methodologies, Tools, and Applications (4-Volumes) P220 pps

• Web service security: SOAP message security: 7KLVLVDVSHFL¿FDWLRQGHYHORSHG by the Organization for the Advancement of Structured Information Standards OASIS.. In general, access control

Trang 1

SOAP M essage 1 SOAP M essage 2

SOAP M essage n

)LJXUH62$3PHVVDJHVÀRRGLQJ

Initial

Ultimate Receiver

Figure 6 A SOAP message routes via an intermediary

Malicious Locati on

Ultimate Receiver

Compromised Intermediary

Initial Sender

Figure 7 Compromised intermediary route a SOAP message to a malicious location

GUHVVWKHLVVXHRIGDWDFRQ¿GHQWLDOLW\DQGLQWHJULW\

UHVSHFWLYHO\+RZHYHUWKHVHWZRVSHFL¿FDWLRQV

do not specify implementation issues of SOAP

PHVVDJHVLQWHJULW\DQGFRQ¿GHQWLDOLW\7KLVSDUW

is covered by additional standard that has been

GH¿QHG LQ 1DGDOLQ DOHU +DOODP%DNHU DQG

0RQ]LOOR7KHGHWDLORIHDFKVSHFL¿FDWLRQ

is described as follows:

• XML encryption: 7KH ;0/

HQFU\S-WLRQ V\QWD[ DQG SURFHVVLQJ VSHFL¿FDHQFU\S-WLRQ describes the processing rules for encrypt-ing/decrypting data (Eastlake & Reagle,

7KLV VSHFL¿FDWLRQ DOVR GH¿QHV WKH V\QWD[WKDWUHSUHVHQWVWKHHQFU\SWHGGDWDLQ

;0/IRUPDW;0/HQFU\SWLRQVXSSRUWVWKH encryption of arbitrary data (including an

Trang 2

HOHPHQWFRQWHQW7KHIROORZLQJH[DPSOHLO-lustrates how to keep sensitive information

FRQ¿GHQWLDOE\HQFU\SWLQJDQ;0/HOHPHQW

(Eastlake & Reagle, 2002) Listing 5 shows

the payment information that contains credit

FDUGQXPEHULQFOHDUWH[WIRUPDWZKLOH/LVW-ing 6 shows the entire CreditCard element

is encrypted from its start to end tags An

eavesdropper does not know any sensitive

LQIRUPDWLRQFRQWDLQHGLQWKLV;0/GRFX-ment The CreditCard element is encrypted

using TripleDES algorithm in cipher block

FKDLQLQJ &%& PRGH ZKLFK LV VSHFL¿HG

by the EncryptionMethod element The

resulting encrypted data is contained in the

CipherValue element.

• XML

signature:7KH;0/VLJQDWXUHV\Q-WD[ DQG SURFHVVLQJ VSHFL¿FDWLRQ SURYLGHV

the security services in terms of data

integ-rity, message authentication, and/or signer

authentication (Eastlake et al., 2002) This

VSHFL¿FDWLRQ GH¿QHV WKH SURFHVVLQJ UXOHV

IRUFUHDWLQJDQGYHULI\LQJ;0/VLJQDWXUHV

,WDOVRLQFOXGHVWKHV\QWD[IRUUHSUHVHQWLQJ

the resulting signature information Listing

LVDQH[DPSOHRI;0/VLJQDWXUH(DVW-lake et al., 2002) The signature algorithm

for signing the document is DSA, which is

VSHFL¿HGLQWKHSignatureMethod element, while the DigestMethodHOHPHQWVSHFL¿HV

the digest algorithm (i.e., SHA-1 in this case) applied to the signed object The resulting digital signature value and digest value are HQFRGHGXVLQJEDVHDQGVSHFL¿HGLQWKH

SignatureValue element and the DigestValue

element respectively

• Web service security: SOAP message security: 7KLVLVDVSHFL¿FDWLRQGHYHORSHG

by the Organization for the Advancement of Structured Information Standards (OASIS) 7KLV VSHFL¿FDWLRQ GH¿QHV D VHW RI 62$3 H[WHQVLRQVWRSURYLGHWKHVXSSRUWRIPHV-VDJHLQWHJULW\DQGFRQ¿GHQWLDOLW\1DGDOLQ HWDO7KHVSHFL¿FDWLRQLVÀH[LEOHDQG can be accommodated to various security models such as PKI, Kerberos, and SSL

Authentication and Authorization

Authentication in e-business is the process to validate the identities of business entities, while authorization is a process to determine an authen-ticated party can access what sort of resources RU SHUIRUP ZKDW NLQG RI DFWLRQV )RU H[DPSOH RQO\ VSHFL¿F DXWKHQWLFDWHG EXVLQHVV SDUWQHUV

Initial Sender

NoQH[Lstent Destination

Compromised Intermediary

Ultimate Receiver

Initial Sender

Figure 8 Compromised intermediary route a SOAP message to a nonexistent destination

Trang 3

should be able to access sensitive information In

general, access control rules are created to apply

WKHUHVWULFWLRQWRVSHFL¿FFRQWHQWVRUDSSOLFDWLRQ

IXQFWLRQDOLW\7KHIROORZLQJVSHFL¿FDWLRQVVKRXOG

be applied in the Web service architecture to

ensure these security goals

• Security assertion markup language

(SAML): This specification defines a

IUDPHZRUN IRU H[FKDQJLQJ DXWKHQWLFDWLRQ

and authorization information between

e-business partners (Cantor, Kemp, Philpott,

& Maler, 2005) SAML supports single

sign-RQ662IRUDI¿OLDWHGVLWHV%DVLF6$0/

components include assertions, protocols,

ELQGLQJVDQGSUR¿OHV7KHUHDUHWKUHHW\SHV

of assertions: authentication, attribute, and

authorization The authentication statements contain authenticated related information

of a user The attribute statements describe VSHFL¿F GHWDLOV DERXW WKH XVHU ZKLOH WKH authorization statements identify what the user is permitted to do There is a set of request/response protocols for obtaining DVVHUWLRQV7KHELQGLQJVGH¿QHKRZ6$0/ protocols map onto the transport protocol, VXFKDV+773ZKLOHWKHSUR¿OHVGH¿QHKRZ SAML assertions, protocols, and bindings are combined for a particular use case

• XML access control markup language (XACML): 7KLV VSHFL¿FDWLRQ SURYLGHV D

FRPPRQ ODQJXDJH IRU H[SUHVVLQJ DFFHVV FRQWUROSROLFLHVLQ;0/YRFDEXODU\0RVHV

,WGH¿QHVWKHPHFKDQLVPIRUFUHDWLQJ

<?[Pl version='1.0'?>

<PaymentInfo[mlns='http://e[Dmple.org/paymentv2'>

<Name>John Smith</Name>

<Issuer>([ample Bank</Issuer>

([Siration>([Siration>

</CreditCard>

</PaymentInfo>

<?[Pl version='1.0'?>

<PaymentInfo[mlns='http://e[Dmple.org/paymentv2'>

<Name>John Smith</Name>

<EncryptedDaWD[mlns='http://www.w3.org/[Plenc#'

Type='http://www.w3.org/[Plenc#Element'/>

<ds:KeyInfo [Plns:ds='http://www.w3.org/2000/09/[Pldsig#'>

<ds:KeyName>John Smith</ds:KeyName>

</ds:KeyInfo>

<CipherData><CipherValue>DEADBEEF</CipherValue></CipherData>

</EncryptedData>

</PaymentInfo>

Listing 5 Simple payment information (Source: W3C)

Listing 6 Encrypting an XML element (Source: W3C)

Trang 4

the rules and policy sets that determine what

users can access over a network

• Access control for SOAP messages: It is

important to apply a security mechanism

such as access control to SOAP messages

Damiani, De Capitani di Vimercati,

Parabos-chi, and Samarati (2001, 2002) have proposed

DZRUNRQ¿QHJUDLQHGDFFHVVFRQWUROIRU

SOAP e-services The authorization model

enforces access restrictions to SOAP

invo-FDWLRQV7KHUHLVDQDXWKRUL]DWLRQ¿OWHUWR

intercept every SOAP message and evaluates

LWDJDLQVWWKHVSHFL¿HGDFFHVVFRQWUROUXOHV

Based on the policies, each soap message

may (1) be rejected; (2) be allowed; or (3) be

¿OWHUHGDQGH[HFXWHGLQDPRGL¿HGIRUP

Audit Trails

Audit trails are also an important security

re-quirement in Web services architecture (Booth,

et al., 2004) They can audit the activities for the Web services architecture such as changes in DQ\FRQ¿JXUDWLRQ2QWKHRWKHUKDQGWKH\PD\ provide audit on a business level All the Web service transactions can be recorded as a proof

of the business transaction occurred In addition, they can support, for tracing, user access and behavior when there is any security breach The audit trails may also provide as data sources for

an intrusion detection system in the Web services environment

Intrusion Detection and Prevention

$OPRVWHYHU\RUJDQL]DWLRQDOORZVQHWZRUNWUDI¿F pass through port 80 or 443 to access Web ap-SOLFDWLRQV$VVXFKWUDGLWLRQDOQHWZRUN¿UHZDOOV

do not block most of the SOAP messages that transport via HTTP (port 80) or HTTPS (port 443) In addition, they do not check if there are any malicious contents in the SOAP messages As

</Transforms>

<DigestValue>j6lZ[3rvEPO0vKtMup4NbeVu8nk=</DigestValue>

</Reference>

</SignedInfo>

<SignatureValue>MC0CFFrVLtRlk= </SignatureValue>

</DSAKeyValue>

</KeyValue>

</KeyInfo>

</Signature>

Listing 7 An example of XML signature (Source: W3C)

Trang 5

attackers generally manipulate SOAP messages

for attacking Web services, it is inadequate for

WUDGLWLRQDOQHWZRUN¿UHZDOOVWRSURWHFWWKHH[LVW-ing Web service architecture

Web service-based intrusion detection and

prevention systems may address this issue

7KH\FDQPRQLWRU62$3WUDI¿FDQGLQVSHFWWKH

SOAP contents for anomaly behaviors or

intru-VLRQ SDWWHUQV 0DOLFLRXV 62$3 WUDI¿F VXFK DV

parameter tampering and SQL injection, should

be denied before they travel to a critical system

,QDGGLWLRQWKH\VKRXOGYDOLGDWHV\QWD[RI62$3

PHVVDJHVDQG¿OWHUWKRVHZLWKLPSURSHUV\QWD[

such as oversized payloads The systems may

also provide access control based on different

roles, groups, and responsibilities for preventing

XQDXWKRUL]HGXVHRI:HEVHUYLFHV)RUH[DPSOH

only authenticated business partners are allowed

to view some of the restricted WSDL documents

for critical Web services

FUTURE TRENDS

,WLVH[SHFWHGWKDWQHZVSHFL¿FDWLRQVDQGSURWRFROV

ZLOOEHGH¿QHGDV:HEVHUYLFHVWHFKQRORJ\HYROYH

Also, new applications related to Web services will

be developed gradually All these new

technolo-gies may introduce new vulnerabilities to the Web

VHUYLFHVDUFKLWHFWXUH,WLVUHTXLUHGWRH[DPLQH

every security aspect of the new Web services

technologies The study and analysis of potential

attacks and their countermeasures is important

in this issue Automated testing or benchmarking

tools may be developed for evaluating the security

of the Web services

Malicious codes such as viruses and worms

VSUHDGDFURVVWKHH[LVWLQJQHWZRUNLQIUDVWUXFWXUH

and result in a great deal of business loss It may

foresee that the Web services architecture will

be another new avenue for the propagation of

the malicious codes Antivirus scanners should

ensure that they have the ability to recognize

ma-OLFLRXVFRGHVWKDWHPEHGGHGLQ;0/GRFXPHQWV

as well as to control the propagation of malicious software within the Web services architecture (Negm, 2005)

*XWLpUUH]HWDOVWDWHGWKDWDQ;0/YR-FDEXODU\IRUH[SUHVVLQJDXGLWGDWDDQGSURWRFROIRU GLVWULEXWHGDXGLWSURFHVVHVPD\EHGH¿QHGDVDQ H[WHQVLRQWRVRPHH[LVWLQJVHFXULW\VSHFL¿FDWLRQV They also proposed that contingency protocols, security alerts management, and countermeasures need to be developed in the future All these UHVHDUFKHVZLOOEHHVVHQWLDOIRUEXLOGLQJHI¿FLHQW intrusion detection and prevention systems in the Web services architecture

CONCLUSION

Web services provide a framework for inter-V\VWHP FRPPXQLFDWLRQ WKDW HQDEOHV ÀH[LEOH implementation and integration of e-business systems However, there are risks for adopting Web services by enterprises if they do not address security challenges in the Web services architec-ture Therefore, it is crucial for the developers and users to understand the security issues in Web services This chapter is meant to provide

a state-of-the-art view of security attacks and preventive countermeasures in Web services

We presented core components of Web services such as SOAP, WSDL, and UDDI In addition, we EULHÀ\GLVFXVVHGWKHLUUROHVDQGRSHUDWLRQV7KH inherently insecure nature of the Web services architecture is susceptible to numerous attacks :HDOVRGLVFXVVHGWKHVHDWWDFNVDQGH[DPLQHG KRZDWWDFNHUVH[SORLWYXOQHUDELOLWLHVLQWKH:HE services architecture Proper security schemes should be applied to counter these attacks We presented these security countermeasures and VSHFL¿FDWLRQV WR SURWHFW :HE VHUYLFHV GHSOR\-ments in e-business We also discussed some security issues to be addressed for future direc-tions of Web services technology

Trang 6

Beznosov, K., Flinn, D J., Kawamoto, S., &

Hart-man, B (2005) Introduction to Web services and

their security Information Security Technical

Report, 10, 2-14.

Booth, D., Haas, H., McCabe, F., Newcomer, E.,

Champion, M., Ferris, C., et al (Eds.) (2004)

Web services architecture (W3C Working Group

Note) Retrieved April 18, 2005, from http://www

w3.org/TR/2004/NOTE-ws-arch-20040211/

Booth, D., & Liu, C K (Eds.) (2005) Web services

description language (WSDL) version 2.0 part 0:

Primer (W3C Working Draft) Retrieved August

14, 2005, from

http://www.w3.org/TR/2005/WD-wsdl20-primer-20050803

Bray, T., Paoli, J., Sperberg-McQueen, C M.,

Maler, E., & Yergeau, F (Eds.) (2004) Extensible

markup language (XML) 1.0 (Third Edition)

(W3C Recommendation) Retrieved May 16,

2005, from

http://www.w3.org/TR/2004/REC-[PO

Byron, P., & Malhotra, A (Eds.) (2004) XML

schema part 2: Datatypes (W3C

Recommenda-tion) Retrieved April 18, 2005, from http://www

ZRUJ755(&[POVFKHPD

Cantor, S., Kemp, J., Philpott, R., & Maler, E

(Eds.) (2005) Assertions and protocols for

the OASIS security assertion markup language

(SAML) V2.0 (OASIS Standard) Retrieved August

4, 2005,from http://docs.oasis-open.org/security/

saml/v2.0/saml-core-2.0-os.pdf

Chinnici, R., Haas, H., Lewis, A., Moreau, J.-J.,

Orchard, D., & Weerawarana, S (Eds.) (2005)

Web services description language (WSDL)

version 2.0 part 2: Adjuncts (W3C Working

Draft) Retrieved August 14, 2005, from http://

www.w3.org/TR/2005/WD-wsdl20-adjuncts-20050803

Chinnici, R., Moreau, J.-J., Ryman, A., &

Weer-awarana, S (Eds.) (2005) Web services descrip-tion language (WSDL) version 2.0 part 1: Core language (W3C Working Draft) Retrieved August

14, 2005, from http://www.w3.org/TR/2005/WD-wsdl20-20050803

Clement, L., Hately, A., Riegen, C von, &

Rog-ers, T (Eds.) (2004) UDDI version 3.0.2 (UDDI

Spec Technical Committee Draft) Retrieved May

16, 2005, from http://uddi.org/pubs/uddi-v3.0.2-20041019.htm

Damiani, E., De Capitani di Vimercati, S., Paraboschi, S., & Samarati, P (2001, May 1-5) Fine grained access control for SOAP e-services

In V Y Shen, N Saito, M R Lyu, & M E Zurko

(Chair), Proceedings of the 10 t h International Conference on World Wide Web (pp 504-513)

Hong Kong, China New York: ACM Press Damiani, E., De Capitani di Vimercati, S., Paraboschi, S., & Samarati, P (2002) Securing

SOAP e-services International Journal of Infor-mation Security, 1(2), 100-115.

Eastlake, D., & Reagle, J (Eds.) (2002) XML encryption syntax and processing (W3C

Rec-ommendation) Retrieved August 4, 2005, from KWWSZZZZRUJ755(&[POHQFFRUH 20021210/

Eastlake, D., Reagle, J., & Solo, D (Eds.) (2002)

XML-signature syntax and processing (W3C

Recommendation) Retrieved August 4, 2005, IURPKWWSZZZZRUJ755(&[POGVLJ core-20020212/

Faust, S (2003) SOAP Web services attack — Part 1: Introduction and simple injection Retrieved

May 10, 2005, from http://www.spidynamics com/whitepapers/SOAP_Web_Security.pdf Geuer-Pollmann, C., & Claessens, J (2005) Web

services and Web service security standards In-formation Security Technical Report, 10, 15-24.

Gudgin, M., Hadley, M., Mendelsohn, N., Moreau,

J.-J., & Nielsen, H F (Eds.) (2003a) SOAP

Trang 7

ver-sion 1.2 — Part 1: Messaging framework (W3C

Recommendation) Retrieved May 16, 2005, from

http://www.w3.org/TR/2003/REC-soap12-part1-20030624/

Gudgin, M., Hadley, M., Mendelsohn, N., Moreau,

J.-J., & Nielsen, H F (Eds.) (2003b) SOAP

ver-sion 1.2 part 2: Adjuncts (W3C

Recommenda-tion) Retrieved May 16, 2005, from http://www

w3.org/TR/2003/REC-soap12-part2-20030624/

Gutiérrez, C., Fernández-Medina, E., & Piattini,

M (2004, May 14-17) A survey of Web services

Security In A Laganà et al (Eds.), Computational

science and its applications — ICCSA 2004,

Proceedings of the International Conference

on Computational Science and Its Applications

— ICCSA 2004, Assisi, Italy (LNCS 3043, pp

968-977) Berlin: Springer

Lindstrom, P (2004) Attacking and defending

Web services Retrieved April 7, 2005, from http://

forumsystems.com/papers/Attacking_and_De-fending_WS.pdf

Mitra, N (Ed.) (2003) SOAP version 1.2 Part 0:

Primer (W3C Recommendation) Retrieved May

16, 2005, from

http://www.w3.org/TR/2003/REC-soap12-part0-20030624/

Moses, T (Ed.) (2005) eXtensible access control

markup language (XACML) version 2.0 (OASIS

Standard) Retrieved August 4, 2005, from http://

GRFVRDVLVRSHQRUJ[DFPODFFHVVBFRQWURO [DFPOFRUHVSHFRVSGI

Nadalin, A., Kaler, C., Hallam-Baker, P., &

Monzillo, R (Eds.) (2004) Web services security: SOAP message security 1.0 (WS-Security 2004)

(OASIS Standard) Retrieved August 4, 2005, from http://docs.oasis-open.org/wss/2004/01/oa-sis-200401-wss-soap-message-security-1.0.pdf 1DHGHOH06WDQGDUGVIRU;0/DQG:HE

services security IEEE Computer, 36(4), 96-98 Negm, W (2004) Anatomy of a Web services attack Retrieved April 26, 2005, from http://

forumsystems.com/papers/Anatomy_of_At-tack_wp.pdf

Negm, W (2005) XML malware: Controlling the propagation of malicious software within service oriented architectures Retrieved July 15,

2005, from http://forumsystems.com/papers/Fo-UXPB;0/B0DOZDUHBZSBVXPPHUBSGI Thompson, H., Beech, D., Maloney, M., &

Men-delsohn, N (Eds.) (2004) XML schema part 1: Structures (W3C Recommendation) Retrieved

April 18, 2005, from http://www.w3.org/TR/2004/ 5(&[POVFKHPD

Wilson, P (2003) Web services security Network Security, 2003(5), 14-16.

This work was previously published in Web Services Security and E-Business, edited by G Radhamani and G Rao, pp

Trang 8

Chapter 7.11

A Security Blueprint for

E-Business Applications

Jun Du

Tianjin University, China

Yuan-Yuan Jiao

Nankai University, China

Jianxin (Roger) Jiao

Nanyang Technological University, Singapore

ABSTRACT

This chapter develops a security blueprint for

an e-business environment taking advantage of

the three-tiered e-business architecture This

security blueprint suggests best practices in

general It involves (1) security control by layers

— from physical access, to network

communica-tion, to operating systems, to applications, and

(2) different stages of the management process,

including planning, deployment, administration,

and auditing Also reported is a case study of the

implementation of the proposed security blueprint

in a Singapore multinational corporation Such

issues as security control analysis, management

SURFHVVDQDO\VLVDQGFRVWEHQH¿WVDQDO\VLVDUH

discussed in detail

INTRODUCTION

The Internet has created huge opportunities for new companies and new business for those established organizations formerly bound by a saturated market (EXVLQHVV LV GH¿QHG DV WKH conduction of business with the assistance of tele-communications and telecommunication-based tools, mainly over the Internet (Clarke 1999),

including to-business (B2B), business-to-customer (B2C), and intra-organizational

com-merce (Siau & Davis, 2000) Security is essential and very critical to e-business applications The importance of information privacy to e-business has been recognized for some time (Agre & Ro-tenberg, 1997; Bingi, Mir, & Khamalah, 2000; Lichtenstein & Swatman, 2001), with the Gartner

Trang 9

Group (2002) nominating information privacy

as the greatest impediment to consumer-based

e-business through 2006

However, when building up a secure

environ-ment for e-business applications, there are no

industry standards for people to follow on their

design or implementation jobs All that can be

referred is from the security product

manufac-turers and system integrators The truth is that

security systems can only provide a certain

level of protection to an e-business environment

Therefore, security protection must be in place

at different layers, and the management process

must be carried out at different stages From the

authors’ viewpoint, security is not a by-product;

it is a combination of managing technologies and

VHFXULW\SURFHVVHVUDWKHUWKDQ³SXWWKH¿UHZDOO

here, put the intrusion detection system there.”

This chapter develops a security blueprint for

a typical e-business environment based on the

discussion of the major components in three-tiered

e-business architecture This security blueprint

includes general security control layered from

physical access, network communication,

operat-ing system, to application; and security

manage-ment processes staged from planning, deploymanage-ment,

administration, to auditing

TYPICAL E-BUSINESS

ENVIRONMENT

Originally, business computing was carried out

as a point task, without any real concept of a

net-worked operation All the business processes are

run on a single platform or single tier Later, many

systems evolved to a two-tiered approach, also

known as client/server architecture, where most

of the business process runs on the server and the

client is mainly concerned with presentation and

RQO\KROGVDOLPLWHGDPRXQWRIXVHUVSHFL¿FGDWD

Today, more and more e-business applications are

deployed as a three-tiered architecture owing to

LWVLQFUHDVHGSHUIRUPDQFHÀH[LELOLW\PDLQWDLQ-ability, reusLWVLQFUHDVHGSHUIRUPDQFHÀH[LELOLW\PDLQWDLQ-ability, and scalLWVLQFUHDVHGSHUIRUPDQFHÀH[LELOLW\PDLQWDLQ-ability, while hiding the complexity of distributed processing from the user After this, things get more complicated, with additional applications running in different tiers, which is so-called multi-tiered architecture However, multi-tiered architectures have arisen not necessarily because great thought was given

to this choice of architecture; in truth, they are more the result of trying to make the best of what was there

This section will describe a typical three-tier e-business environment and identify the major components from system architecture perspec-tives

Three-Tier E-Business Architecture

When it comes to an e-business environment, usually, these three tiers (layers) can be described

as the presentation layer, business logic layer, and data layer These tiers are logical, not physical

One machine can run several business tiers and tiers can be distributed across several machines

A typical three-tiered e-business architecture is shown in Figure 1

Major Components in an E-Business Environment

In the three-tiered e-business architecture, the PDMRU FRPSRQHQWV FDQ EH LGHQWL¿HG DV D :HE browser, a Web server, an application server, a database server, an AAA/directory service, a corporate network, and the Internet, as illustrated

in Figure 2

A SECURITY BLUEPRINT

A secure e-business environment must prevent most attacks from successfully affecting valuable business resources While being secure, the e-business environment must continue to provide critical services that users expect Proper security

Trang 10

Figure 1 A typical e-business environment

Figure 2 Major components in an e-business environment

science and its applications — ICCSA 2004,

Proceedings of the International Conference

on Computational Science and Its Applications

—... runs on the server and the

client is mainly concerned with presentation and

RQO\KROGVDOLPLWHGDPRXQWRIXVHUVSHFL¿FGDWD

Today, more and more e-business applications are...

communica-tion, to operating systems, to applications, and

(2) different stages of the management process,

including planning, deployment, administration,

and auditing Also reported is

Định dạng
Số trang	10
Dung lượng	444,72 KB