security of payment cards

8/10/2019 Security of Payment Cards

1/16


2/16

!ntroductionOne of the biggest concerns relating to security in e-commerce applications is the use ofthe credit/debit cards. Failure to secure the card information can cause a major damage to

the organization in terms of financial fraud, identity theft, legal regulations, loss ofconsumer confidence, etc. This document will highlight the various security controls thatcan be employed in maing an ecommerce application more robust and thwart brea-insat the application level. The first section of this document will focus on security measuresthat can be used by development teams in building a secure e-commerce applicationemploying customer!s payment cards "debit/credit cards#. The final section of thisdocument will focus on the industry standards, guidelines and best-practices focused onsecuring the e-commerce application and its accompanying environment.

"ar#et $udienceThis document is intended for developers engaged in developingecommerce applications and the networ management team responsible for the

deployment and monitoring of the application/components. This guide can also be usedby the business owners of e-commerce applications to plan the appropriate securitycontrols to be used in their applications and by the $% "$nformation security# person toreview/audit e-commerce applications and provide feedbac on any wea securitycontrols.

%ote&This document focuses only on application security and as such does not coversecurity at the host or the networ layer.


3/16

!ntroduction........................................................................................................................&' $pplication Controls...................................................................................................'

'' $SP "op '*...................................................................................................''+ ,est Practices in handlin# payment card details/transactions......................(

'+' Data stora#e/display..................................................................................(

'++ andlin# transactions...............................................................................)'+. hen card details hae been breached....................................................)'. Controls on indiidual domains........................................................................*

'.' $uthentication............................................................................................*'.+ $ccount 0aintenance................................................................................+'.. Pass1ord policy..........................................................................................+'.2 $ccount 3ockout........................................................................................+'.4 Session 0aintenance..................................................................................+'.5 $uthori6ation.............................................................................................'.7 3o#out.........................................................................................................'.8 Cache control..............................................................................................

'.9 Phishin#......................................................................................................'.'* :enderin# non-html documents...............................................................'.'' $udit trail...................................................................................................'.'+ Database....................................................................................................&'.'. eb Serer...............................................................................................&'.'2 SD3C.........................................................................................................&&'.'4 "estin#.......................................................................................................&&'.'5 Encryption................................................................................................&'.'7 Soft1are Confi#uration 0ana#ement...................................................&'

+ !ndustrial Standards and best practices................................................................&'+' C!SP (Cardholder !nformation Security Pro#ram).....................................&'++ PC! (Payment Card !ndustry) Data Security Standard '*........................&(+. Electronic Commerce Security $rchitecture ,est Practices - 0asterCard. . .

...............................................................................................................................&(

+2 ;!S$


4/16

The recent trend in the attac mechanisms targeting the applications cannot be preventedby traditional security measures lie networ and host layer security. This re0uires astrong defense built within the application to resist any such attac. The attac vectorstargeting the end applications "123, 423, %upply chain and other ey businessapplications# can vary from information disclosure "revealing sensitive data to

unauthorized users# to hijacing user sessions. 5dditionally providing security at theapplication layer serves as another control within the organization!s layered line ofdefense.

'' $SP "op '*

The O65%3 Top & is a list of the most significant web application securityvulnerabilities. 5dditionally the Payment Card !ndustry (PC!) Data SecurityStandard&mentions the use of O65%3 Top & in developing secure coding guidelines.7elow is the list of O65%3 Top & vulnerabilities along with a description for each taenfrom the O65%3 manual "O65%3 Top Ten 6eb 5pplication vulnerabilities#, for more

information on these vulnerabilities visit the O65%3 site "www.owasp.org#.

' SS) ?la1s = The web application can be used as amechanism to transport an attac to an end user!s browser. 5 successful attac candisclose the end user!s session toen, attac the local machine, or spoof content tofool the user.

4 ,uffer erflo1s = 6eb application components in some languages that do notproperly validate input can be crashed and in some cases used to tae control of aprocess. These components can include 4:$, libraries, drivers, and webapplication server components.

5 Command !njection ?la1s = 6eb applications pass parameters when theyaccess e9ternal systems or the local operating system. $f an attacer can embed

&3ayment 4ard $ndustry "34$# ;ata %ecurity %tandard was created by


5/16

malicious commands in these parameters, the e9ternal system may e9ecute thosecommands on behalf of the web application.

7 Error handlin# Problems = 1rror conditions that occur during normal operationare not handled properly. $f an attacer can cause errors to occur that the web

application does not handle, they can gain detailed system information, denyservice, cause security mechanisms to fail, or crash the server.

8 !nsecure use of crypto#raphy = 6eb applications use cryptographic functions toprotect information and credentials. These functions and the code to integratethem have proven difficult to code properly, fre0uently resulting in weaprotection.

9 :emote administration fla1s = =any web applications allow administrators toaccess the site using a web interface. $f these administrative functions are notcarefully protected, an attacer can gain full access to all aspects of a site.

'* eb and $pplication Serer 0isconfi#uration8 >aving a strong serverconfiguration standard is critical to a secure web application. These servers havemany configuration options that affect security and are not secure out of the bo9.

'+ ,est Practices in handlin# payment card details/transactions

6hile the O65%3 Top & tals about the most critical vulnerabilities in webapplications, there are specific guidelines for using payment cards in applications"web based or thic client applications#. The payment card industry ""


6/16

values must be removed. 5ccount number, e9piration date, and name maybe e9tracted and retained.[PCI Data Security Standard 3.2.1]

;o not display the full account number anywhere unless if re0uired. The

first si9 and last four digits are the ma9imum number of digits to bedisplayed.[PCI Data Security Standard 3.3]

;o not store the cardholder data unencrypted anywhere "render this dataunreadable#. This includes the data on portable media, in logs anddatabases, etc.[PCI Data Security Standard 3.4]

'++ andlin# transactions

The following are some of the controls from the e-4ommerce section of theO65%3 guide.

3rocess transactions immediately online or hand off the processing to your

ban. $n cases of recurring payments, limit the payment term to no more than

one year, particularly if you have A4ard holder not presentB "4@3#transactions. 5dditionally e9punge/delete the credit card details as soon asthe agreement is finished.

;on!t ship goods until you have an authorization receipt from the payment

gateway. The authorization number returned after a transaction should be preserved

and communicated to the customer along with the other re0uired details ofthe transaction.

For high value goods, consider maing the payment on over the phone or

fa9 authority. 5ll charge bacs and reversals, re0uire logging, auditing and manual

authorization. 2eversals should always be performed by hand and should be signed off

by two distinct employees or groups. =ost of the payment cards have a strong relationship between 7$@

numbers and the issuing institution!s country. %trongly consider notshipping goods to out-of-country 7$@ cards.

=oney is not negative. ?se strong typing to force zero or positive

numbers, and prevent negative numbers. $nform the card owner of any transaction through email. 5dditionally

encrypt the contents of the mail.

'+. hen card details hae been breached

$nform the payment card owner of the breach and the follow-up actions by

phone and through email.[California SB1386]


7/16

$nvestigate the cause of the problemC if the breach occurred through the

application/system handling the payment card, consider stopping allfurther transactions on all the payment cards in the application. $f re0uired,tae the systems "application server/web server/database server and anysystems part of the application# offline for the time period until the

problem for the security breach has been identified. %uspend/%top all transactions on the payment card when the cause of the

breach could not be determined and the application needs to go online.There should be an administrative functionality designed in the applicationto revoe/cancel selected credit/debit card in the application.

For more information on the re0uired actions after a suspected or confirmedsecurity breach read the 4ardholder $nformation %ecurity 3rogram 8 $f4ompromised.httpD//usa.visa.com/business/acceptingEvisa/opsErisEmanagement/cispEifEcompromised.html

'. Controls on indiidual domains

'.' $uthentication

5pplication should use a standard mechanism for identifying and

verifying user!s identity e.g. 55% "ava 5uthentication and5uthorization %ervice#, %ingle %ign On solutions, etc. $n case ofcustom code for authentication, the code should be reviewed for

proper verification and identification and setting the authenticationtoen. For high value transactions consider a secondary form of

authentication. This second authentication mechanism may be usedat the time of transaction generated by the user.

;on!t give the user the option for saving username or passwords

which might increase the ris of credential abuse in sharedcomputers, this can be controlled by using the feature5?TO4O=3G1T1 - OFF in the >T=G form element forlogin/password elements. This is not supported by all browsers, butstill can be a good control in place.

There should be a mechanism for users to reset the passwords.


8/16

'.+ $ccount 0aintenance

4hange the passwords for all default accounts provided by the web

server and its components including database server, any admincomponents, etc. $f these default accounts are not being used,

consider disabling them. 2emove inactive user accounts at least every days. [PCI Data

Security Standard 8.5.5]

5pplication should re0uire a uni0ue username and comple9

password for all administrative access and access to cardholderdata.[PCI Data Security Standard 8.1 and 8.2 (!]

5ll passwords in the application must be encrypted "either when

stored or transmitted#. 5pplication should not store passwords inclear te9t or in any easily reversible form.[PCI Data Security Standard8..4 (!]

%et first-time passwords to a uni0ue value per user and change

immediately after first use.[PCI Data Security Standard 8.5.3].

'.. Pass1ord policy

5 strong pass1ord policyshould be in place including 3assword change "at least every days#[PCI Data Security Standard

8.5."].

=inimum password length "at least + characters#[PCI Data SecurityStandard 8.5.1#].

3asswords with both numeric and alphanumeric characters [PCIData Security Standard 8.5.11].

3assword history is maintained for at least ( previous passwords

and enforced to prevent users from re-using them.[PCI Data Security

Standard 8.5.12].

'.2 $ccount 3ockout

3revent attacs lie password guessing or brute forcing by locing

the user account after more than * repeated attempts.[PCI DataSecurity Standard 8.5.13].

%et the account locout duration to ' minutes or until

administrator enables the user $;.[PCI Data Security Standard 8.5.14].

'.4 Session 0aintenance

$f the session has been idle for a certain amount of time "e.g. &)

minutes#, inactive the session and as the user to re-login to theapplication.[PCI Data Security Standard 8.5.15].

%et an e9piration time on the session toen based on the

application usage "generally this can be ' minutes or () minutes#.;isplay a warning to the user on the last ) minutes informinghim/her to save the wor.

4onsider implementing A2e0uest ToensB or A3age ToensB in the

application to avoid the session information "session cooie# being


9/16

stolen and re-used. This control narrows the window ofopportunity for which the session cooie remains valid.

5ny cooie "including session cooie# used in the application

should have the AsecureB and AhttpOnlyB attribute set on them andshould be non-persistent.

'.5 $uthori6ation

Gimit access to computing resources and cardholder information to

only those individuals whose job re0uires such access.[PCI DataSecurity Standard $.1].

;esign and implement a proper access control model for the

application. $n most cases this can be done by taing advantage ofthe security model provided by the application e.g. role-basedsecurity, code access security in .@1T framewor. $n cases wherethe security model provided by the underlying language seemsinsufficient, custom coding should be in place to tae care of the

user authorization process and the code should be reviewed for anyvulnerability.

'.7 3o#out

The application should have a logout button at every page or every

lin. 6hen a user clics on logout button, crush the session cooies on

the server and additionally clear the cooies on the browser andclose the browser.

'.8 Cache control

The application should set the tag ASet cache-control: no-cache,no-storeB on every page to avoid the pages being stored on theuser!s computer after he/she has logged out. This may be a usefulcontrol in shared computers or when an attacer gets hold of thecomputer previously used to access the payment application. Thiscontrol does not wor in >TT3 &. caches and additionally non->T=G documents lie 3;F and 1H41G files do not adhere to thecache-control tags and can be stored on the client!s computer.

The application should not send any sensitive information in the

?2G "0uery parameters#. $nformation passed in the ?2G!s are notsafe from being sniffed even when the communication channel is

>TT3%. 5dditionally the information in the ?2G is stored in thebrowser cache and by any logging devices in the path of theapplication traffic.

'.9 Phishin#

;o not send >T=G email.


10/16

@ever use any user!s secrets lie %%@, 7an accounts to verify

customer!s accounts. 5nd clearly communicate this to the users inthe policy section on the front page of the application.

5lthough there are numerous prevention tips to avoid phishing

attacs, user education is the only control which can avoid thisproblem completely. The e-commerce application should have apolicy and usage notice informing the user of the application!sbehavior.

5n e9ample is given belowD

'.'* :enderin# non-html documents

6hen the application needs to serve the user with sensitive

information lie transaction history, payment receipts, order status,etc in non-html format "e.g. 3;F, 1H41G#, consider generatingthese documents online within the program and then serving to the

user. @on->T=G documents should not be stored on the server,since it!s difficult to set access controls on them.

'.'' $udit trail

For any action involving a payment card or payment card holder!sdata, maintain the following records as part of the audit log [PCI

Data Security Standard 1#.2 to 1#.$]


11/16

Secure the audit trail

To only those with a need to view

7ac up audit logs to a centralized log server or media which is

well protected.

4onsider using file integrity software!s to detect any unauthorizedmodifications to audit logs.

2etain the log files for a certain period of time.

2eview the logs at periodic intervals "$n case of high valued e-

commerce application, this should happen daily#.'.'+ Database

$mplement only one primary function per server.[PCI Data SecurityStandard 2.2.1]

5uthenticate all access to database containing cardholder

information. This includes access by applications, administrators,and all other users.[PCI Data Security Standard 8.5.16]

1ncrypt all non-console administrative access. ?se technologiessuch as %%>,


12/16

1ncrypt all non-console administrative access. ?se technologies

such as %%>,


13/16

5ll custom code should be reviewed for any potential vulnerability

prior to production or customers.[PCI Data Security Standard 6.3.$] 5ny enhancements/changes to the code should be documented and

approved. The application might need a security review based onthe enhancement or changes to the e9isting code.

'.'5 Encryption

Encryption al#orithm

The 34$ ;ata security standard mandates that the cardholder

information be encrypted with a strong encryption algorithm with aey size of at least & bits, 5lthough Triple;1% and 51% are

given as e9amples in the 34$ data security standard it!s wise to use51% as it is the F$3%-5pproved symmetric encryption algorithm ofchoice.[PCI Data Security Standard 3.4].

$pplicable $reas

The cardholder information should be encrypted anywhere it!s

stored. This includes database storage, web server log files,portable media, bacup media

5ny email communication to the customer containing cardholder

information should be encrypted. .[PCI Data Security Standard 4.2] For wireless networs, there should be a combination of 613

protection along with 6-Fi 3rotected 5ccess "635# technology if635 capable, or


14/16

%ecure ey distribution. Leys are sent in a secure communication

channel and only to authorized parties upon verification andvalidation.[PCI Data Security Standard 3.6.2]

%ecure ey storage.[PCI Data Security Standard 3.6.3]

3eriodic ey changes. Leys should be changed fre0uently and the

time period for doing so should be identified. Leys with long lifeshould be sparsely used.[PCI Data Security Standard 3.6.4]

;estruction of old eys.[PCI Data Security Standard 3.6.5]

%plit nowledge and dual control of eys "so that it re0uires or '

people, each nowing only their part of the ey, to reconstruct thewhole ey.[PCI Data Security Standard 3.6.6]

5ll activities related to ey management should be logged.

3revention of unauthorized substitution of eys. [PCI Data SecurityStandard 3.6.$]

2eplacement of nown or suspected compromised eys.[PCI DataSecurity Standard 3.6.8]

2evocation of old or invalid eys "mainly for 2%5 eys#.[PCI Data

Security Standard 3.6."]

2e0uirement for ey custodians to sign a form specifying that they

understand and accept their ey custodian responsibilities. [PCIData Security Standard 3.6.1#]

Ley management is fully automated "e.g. personnel do not have

the opportunity to e9pose a ey or influence the ey creation#.

'.'7 Soft1are Confi#uration 0ana#ement

=aintaining records of changes "file version, modified date,

modified by and additional data describing the changes# made to a

particular file with the ability to roll bac to a previous version ifre0uired.[PCI Data Security Standard 6.4.4]

5ny changes to the software and its accompanying environment

should be carried in a controlled manner "2e0uest for change,2e0uest evaluation, 4hange impact assessment, 4hange 2e0uest5pproval/2ejection, Testing the change for operationalfunctionality, %chedule for change, @otification of changeprocedures communicated to all affected parties and all theseworflows must be documented and preserved#. [PCI Data Security

Standard 6.4.1 till 6.4.4]

+ !ndustrial Standards and best practices

+' C!SP (Cardholder !nformation Security Pro#ram)

$nstituted by


15/16

data. The program applies to all payment channels, including retail "bric-and-mortar#, mail/telephone order, and e-commerce.

++ PC! (Payment Card !ndustry) Data Security Standard '*

This standard mandates the re0uirements as set by =aster4ard $nternational and


16/16

when the code is revisited and changed to fi9 security vulnerabilities after thedevelopment is completed.

:eferences

Open 6eb 5pplication %ecurity 3roject "O65%3#httpD//www.owasp.org

# O65%3 guidehttpD//www.owasp.org/documentation/guide.html

'# $mproving 6eb 5pplication %ecurityD Threats and 4ountermeasureshttpD//msdn.microsoft.com/library/default.aspMurlN/library/en-us/dnnetsec/html/Threat4ounter.asp

(# 4alifornia %7 &'*httpD//www.legalarchiver.org/sb&'*.htm

)# 1ncryption and ey managementhttpD//www.ffiec.gov/ffiecinfobase/boolets/informationEsecurity/(cEencryption.html

*# 4$%3 "4ardholder $nformation %ecurity 3rogram#httpD//usa.visa.com/business/acceptingEvisa/opsErisEmanagement/cisp.html

+# 4$%3 "4ardholder $nformation %ecurity 3rogram# 8 $f 4ompromised.httpD//usa.visa.com/download/business/acceptingEvisa/opsErisEmanagement/cispE6hatEToE;oE$fE4ompromised.pdfMitNil/business/acceptingEvisa/opsErisEmanagement/cispEifEcompromised.html6hatPtoP;oP$fP4ompromised
http://www.owasp.org/http://www.owasp.org/documentation/guide.htmlhttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/ThreatCounter.asphttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/ThreatCounter.asphttp://www.legalarchiver.org/sb1386.htmhttp://www.ffiec.gov/ffiecinfobase/booklets/information_security/04c_encryption.htmlhttp://www.ffiec.gov/ffiecinfobase/booklets/information_security/04c_encryption.htmlhttp://usa.visa.com/business/accepting_visa/ops_risk_management/cisp.htmlhttp://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_What_To_Do_If_Compromised.pdf?it=il%7C/business/accepting_visa/ops_risk_management/cisp_if_compromised.html%7CWhat%20to%20Do%20If%20Compromisedhttp://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_What_To_Do_If_Compromised.pdf?it=il%7C/business/accepting_visa/ops_risk_management/cisp_if_compromised.html%7CWhat%20to%20Do%20If%20Compromisedhttp://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_What_To_Do_If_Compromised.pdf?it=il%7C/business/accepting_visa/ops_risk_management/cisp_if_compromised.html%7CWhat%20to%20Do%20If%20Compromisedhttp://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_What_To_Do_If_Compromised.pdf?it=il%7C/business/accepting_visa/ops_risk_management/cisp_if_compromised.html%7CWhat%20to%20Do%20If%20Compromisedhttp://www.owasp.org/http://www.owasp.org/documentation/guide.htmlhttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/ThreatCounter.asphttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/ThreatCounter.asphttp://www.legalarchiver.org/sb1386.htmhttp://www.ffiec.gov/ffiecinfobase/booklets/information_security/04c_encryption.htmlhttp://www.ffiec.gov/ffiecinfobase/booklets/information_security/04c_encryption.htmlhttp://usa.visa.com/business/accepting_visa/ops_risk_management/cisp.htmlhttp://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_What_To_Do_If_Compromised.pdf?it=il%7C/business/accepting_visa/ops_risk_management/cisp_if_compromised.html%7CWhat%20to%20Do%20If%20Compromisedhttp://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_What_To_Do_If_Compromised.pdf?it=il%7C/business/accepting_visa/ops_risk_management/cisp_if_compromised.html%7CWhat%20to%20Do%20If%20Compromisedhttp://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_What_To_Do_If_Compromised.pdf?it=il%7C/business/accepting_visa/ops_risk_management/cisp_if_compromised.html%7CWhat%20to%20Do%20If%20Compromised

security of payment cards

Documents