911 Software911software.com/cert/PCI/911_PADSS_ Implementation Guide... · Web viewAnd our test...

911 Software

Implementation Guideline

911 Software Development Team

2016/5/18

Implementation Guideline

REVIEW IMPLEMENTATION GUIDELINE...........................................................................................6

1 INTRODUCTION.......................................................................................................................................6

1.1 Aim.....................................................................................................................................................6

1.2 Range.................................................................................................................................................6

2 ROLES AND RESPONSIBILITIES...............................................................................................................6

3 REVIEW TYPE.........................................................................................................................................6

4 STEPS OF FORMAL REVIEW....................................................................................................................6

4.1 Establish Review Plan.......................................................................................................................6

4.1.1 Confirm the products needed to review.................................................................................................6

4.1.2 Book the review time, the location and the related personnel...............................................................7

4.1.3 Provide the work products to the relevant personnel.............................................................................7

4.2 Formal review....................................................................................................................................7

4.3 Chairman’s speaking.........................................................................................................................7

4.4 The owner introduce the work products............................................................................................7

4.5 Verification the work products..........................................................................................................7

4.6 Identify imperfections and make an open reply.................................................................................7

4.7 Discuss about solutions of the imperfections.....................................................................................7

4.8 Results after the meeting....................................................................................................................8

4.9 Output................................................................................................................................................8

4.10Estimate the review............................................................................................................................8

4.10.1 Tracing the imperfections until solved...................................................................................................8

4.10.2 Analyze the data during review, provide an improvement approach....................................................8

5 INFORMAL REVIEW.................................................................................................................................8

5.1 Aim.....................................................................................................................................................8

5.2 Roles...................................................................................................................................................8

5.3 Start Standards..................................................................................................................................9

5.4 Input...................................................................................................................................................9

5.5 Main Steps..........................................................................................................................................9

5.5.1 Prepare Review......................................................................................................................................9

5.5.2 Review...................................................................................................................................................9

5.5.3 Modification, tracing and review.........................................................................................................10

5.6 End Standards..................................................................................................................................10

6 NOTES...................................................................................................................................................10

7 OTHER..................................................................................................................................................12

7.1 A technical review should be integrated with quality assurance dynamically. It’s a good way to

invite the QA staff to participate and supervise the formal review.................................................12

7.2 A technical review should be integrated with the configuration managements dynamically. Those

work products which do not pass the technical review cannot be the baseline files.......................12

REQUIREMENT MANAGEMENT GUIDELINE...................................................................................13

8 INTRODUCTION.....................................................................................................................................13

9 REQUIREMENT MANAGEMENT PROCESS..............................................................................................14

10 CONFIRM REQUIREMENTS.....................................................................................................................14

10.1Aim 15

10.2Roles and Responsibility..................................................................................................................15

10.3Start Standards................................................................................................................................15

10.4Input.................................................................................................................................................16

10.5Main Steps........................................................................................................................................16

10.5.1 Get new requirements from the clients’ system...................................................................................16

10.5.2 Recreate the requirements....................................................................................................................16

10.5.3 Get Commitment of the Requirements................................................................................................16

10.6Output..............................................................................................................................................16

10.7End Standards..................................................................................................................................16

11 REQUIREMENTS TRACING....................................................................................................................17

11.1Aim 17

11.2Character and Duty.........................................................................................................................17

11.3Start Standards................................................................................................................................17

11.4Input.................................................................................................................................................17

11.5Main Steps........................................................................................................................................17

11.5.1 Write Deliver Xml and Code Comments.............................................................................................17

11.5.2 Find the inconsistency..........................................................................................................................17

11.5.3 Eliminate the inconsistency.................................................................................................................18

11.6Output..............................................................................................................................................18

11.7End Standards..................................................................................................................................18

12 REQUIREMENT CHANGE CONTROL......................................................................................................18

12.1Aim 18

12.2Character and Duty.........................................................................................................................18

12.3Start Standards................................................................................................................................18

12.4Input.................................................................................................................................................19

12.5Main Steps........................................................................................................................................19

12.5.1 Request for a Requirement Change.....................................................................................................19

12.5.2 Review the Request..............................................................................................................................19

12.5.3 Modify the Requirement Document....................................................................................................19

12.5.4 Reconfirm the Requirement.................................................................................................................19

12.6Output..............................................................................................................................................20

12.7Notes for Change Control................................................................................................................20

12.8End Standards..................................................................................................................................20

TECHNOLOGY SOLUTION IMPLEMENTATION GUIDELINE......................................................21

13 AIM.......................................................................................................................................................21

14 ROLES AND RESPONSIBILITIES.............................................................................................................21

Industry Standards..................................................................................................................................21

Separation between Dev/Test and Production........................................................................................21

15 START STANDARDS..............................................................................................................................22

16 INPUT....................................................................................................................................................22

17 PROCESS...............................................................................................................................................23

Select Candidate Solution.......................................................................................................................25

Implement Design...................................................................................................................................25

Implement Standards............................................................................................................................................25

Review Design.........................................................................................................................................56

Requirement Recreation and Confirmation............................................................................................56

Coding.....................................................................................................................................................57

Unit Test..................................................................................................................................................57

Walk through...........................................................................................................................................57

Code review.............................................................................................................................................57

Check in code..........................................................................................................................................57

18 OUTPUT................................................................................................................................................57

19 END STANDARDS..................................................................................................................................57

20 RELEASE AND DELIVERY......................................................................................................................57

21 PATCH/UPDATE MANAGEMENT...........................................................................................................60

22 MAINTENANCE.....................................................................................................................................65

SYSTEM TEST IMPLEMENTATION GUIDELINE..............................................................................66

23 AIM.......................................................................................................................................................66

24 INTRODUCTION.....................................................................................................................................66

25 SYSTEM TEST.......................................................................................................................................67

25.1Aim 67

25.2Roles and Responsibilities...............................................................................................................68

25.3Start Standards................................................................................................................................68

25.4Input.................................................................................................................................................68

25.5Main Steps........................................................................................................................................68

25.5.1 Make a plan of system test...................................................................................................................68

25.5.2 Design system test use cases................................................................................................................68

25.5.3 Start System Test.................................................................................................................................68

25.5.4 Imperfection management and modifications......................................................................................69

25.5.5 Verification..........................................................................................................................................69

25.5.6 Vulnerability Testing for Web Applications........................................................................................71

25.5.7 External Vulnerability Identification...................................................................................................72

25.5.8 Cardholder data must not be internet accessible..................................................................................72

25.6Output..............................................................................................................................................72

25.7End Standards..................................................................................................................................72

25.8Measurement....................................................................................................................................73

Review Implementation Guideline

1 Introduction

1.1 Aim

Establish our organization’s review Implementation guideline to guide our work better.

1.2 Range

This document is suitable for all review tasks.

2 Roles and Responsibilities

Roles Responsibilities DescriptionChairman Response for the plan and management of the reviewSpokesman Response for explaining the contents and goal of the reviewRecorder Response for recording the contents and questions of the reviewConferee All those who need to attend the meeting, must give opinions about the

content of the review

3 Review Type

Type Description LevelFormal review Suitable for the key points of the project progress High

Individual review Suitable for the details of the project progress MediumWalkthrough Low

4 Steps of Formal Review

4.1 Establish Review Plan

4.1.1 Confirm the products needed to review

If time is allowed, for the purpose of the product quality control, we must have a technical review of all our work products. If not, for saving time, we can select some important ones to have a technical review.

4.1.2 Book the review time, the location and the related personnel

Book the review time and the location according to the schedule in the <”Project Plan”>

Book the chairman and the conferee according to the features of the work products.

4.1.3 Provide the work products to the relevant personnel

Send the work products and checklists to the review relevant personnel one day in advance.

4.2 Formal review

4.3 Chairman’s speaking

The chairman speaks about the agenda, the priorities, the principles and the time limit of the review meeting.

4.4 The owner introduce the work products

The owner introduces the work products briefly.

4.5 Verification the work products

The conferee verifies the work products according to the checklist. If there are some items which do not meet the demands of the checklist, the review cannot continue. Only if all items meet the demands of the checklist we do the review.

4.6 Identify imperfections and make an open reply

The conferee looks for imperfections of the work products according to the checklist.The owner replies the questions of the conferee. Both sides must reach an agreement of each imperfection.

4.7 Discuss about solutions of the imperfections

The owner and the conferee discuss about the solutions of the imperfections together.If a problem cannot be solved in the meeting, the chairman can decide if it is necessary to continue the discussion or to discuss it in another time.

4.8 Results after the meeting

The conferee makes a conclusion and some opinions to the work products. The meeting ends after the chairman signs in the conclusion. There are three kinds of conclusions:

Qualified, “no need to modify” or “need minor modifications but no need to review once more”.

Basically qualified, need some modifications, and must pass a review after the modifications.

Not qualified, need a large amount of modifications, and must review the work products again after the modifications.

4.9 Output

Team Leader provides a <”Review Report”> and project emails.

4.10 Estimate the review

4.10.1 Tracing the imperfections until solved

As to the imperfections found in the review meeting, if there is a proper way to solve them, then trace them until solved. If not, decide whether it’s need to have another review meeting according to the circumstances.

4.10.2 Analyze the data during review, provide an improvement approach

Summarize and analyze the review data for improvements to the process of the review.

5 Informal review

5.1 Aim

Review the work products rapidly and flexibly, to identify and eradicate the imperfections in the work products before it’s too late.

5.2 Roles

Owner: the developer of the work products which need to be reviewed can be some Individual or a team. The owner replies the questions of the conferee, and tries to find the imperfections and discuss about the solutions of those imperfections with the conferee. When the review is over, the owner should eradicate the imperfections in the work products as soon as possible.

Adjudicator: An adjudicator can be one of the owner’s companions or an expert of the same occupation. One or two is enough. The adjudicator should look for the imperfections in the work products carefully according to the checklist, and discuss about the solutions to the imperfections in the work products. Because an informal review does not need so many people to attend, a recorder can act as an adjudicator at the same time.

5.3 Start Standards

The owner has finished his work according to the desired pattern (For instance a template), and has done an internal check in his work products, has eradicated the primary mistakes such as spelling mistakes and composing mistakes.

5.4 Input

The work products waiting for a review

5.5 Main Steps

5.5.1 Prepare Review

The adjudicators and the owner decide the time, the location, the devices, and the conferee together. The adjudicators have had a walkthrough of the work products and files related, the schedule of the review, the checklist etc.

5.5.2 Review

1. The owner introduces the work products briefly.2. The adjudicators look for imperfections in the work products carefully according to

the checklist.3. The owner replies the adjudicator’s questions. Both sides must reach an agreement to

every imperfection (avoid misunderstanding).4. Discuss about the solutions to the imperfections. For problems that can’t be solved

during the review time, we can affirm that the result of the review is not qualified. And we must report this to the superior.

5. Make a result of the reviewThe adjudicator makes a conclusion and some opinions to the work products. The

meeting ends after the chairman signs in the conclusion. There are three kinds of conclusions:

Qualified, “no need to modify” or “need minor modifications but no need to review once more”.

Basically qualified, need some modifications, and must pass a review after the modifications.

Not qualified, need a large amount of modifications, and must review the work products again after the modifications.

5.5.3 Modification, tracing and review

1. Modification and tracingThe owner modifies the work products, eradicate the imperfections.The adjudicator traces the status of every imperfection.

2. ReviewAfter all the imperfections are eradicated, the owner should send the modified work

products to the adjudicator for review purpose.3. Review the work products. There are two kinds of conclusions:

(1) The modified work products are qualified.(2) The modified work products are still not qualified, need to be modified again.

4. The adjudicator updates problems found to <”Code Review”>, <”Walk Through”>.

5.6 End Standards

All the identified imperfections have been eradicated from the work products.

6 Notes

Code Review1. Code changes are reviewed by knowledgeable individuals other than the originating

code author2. Appropriate corrections are implemented prior to release3. Code review results are reviewed and approved by management prior to release

During our code review process, the code author will never be the code reviewer.

The code reviewer is usually a programmer with more experiences, might be the

technical manager or a senior programmer. They will point out the imperfections in the

code for the author; even the code style must meet the standards of our company. And a

production release will not start until all the appropriate corrections on the imperfections

are made.

During code review, we will first check whether our implementation meets the

requirements of our clients. And we’ll then check whether our implementation is rational

without redundant code and with high efficiency.

When the code has passed the review, the author will upload the related code to our

SVN server. So that means the code review process is finished. And a review report will

be written by the reviewer. After verified by PM, the report will also be archived to the

SVN server.

The reviewers are usually assigned by PM of the project. One or two will be needed

for the review process. The reviewers must be familiar to the project and must be senior

programmers.

Every time the code is changed, we’ll add some comment on the change. This

includes the author, the time for the change and a brief introduction of clients’

requirements. SVN will manage all the changes. So we can easily return any code

change to its’ original author at any time.

After the code review is over, the reviewer must hand over the review report to PM.

And PM will need to check the report and sign off the code review process.

(For KJE 02-13 row 41)

Web Application 1. Code review ensures code is developed according to secure coding guidelines such as

OWASP2. Training requirements for developers based on guidance such as OWASP

The 911 software is a windows application. It’s not a web application and it does not

have any web-facing components.

(For KJE 02-13 row 44-53)

Wireless Applications3. Use strong encryption for wireless authentication and transmission.

The 911 software is a windows application. It’s not a wireless application and does

not have any wireless module in it.

(For KJE 02-13 row 58)

If wireless is used:

• Change encryption keys at installation and whenever anyone with knowledge of the keys leaves the company or changes positions

• Change default SNMP community strings

• Change default passwords and passphrases

• Update firmware to support strong encryption for authentication and transmission

• Identify and change any other security-related vendor defaults

• A firewall must be installed between any wireless networks and systems that store cardholder data

• Firewalls must be configured to deny or control (if such traffic is necessary for

business purposes) any traffic from the wireless environment into the cardholder data

environment

7 Other

7.1 A technical review should be integrated with quality assurance dynamically. It’s a good

way to invite the QA staff to participate and supervise the formal review

7.2 A technical review should be integrated with the configuration managements

dynamically. Those work products which do not pass the technical review cannot be

the baseline files.

Requirement Management Guideline

8 Introduction

There are three parts of requirement management which are requirement confirmation, requirement tracing, and requirement change management. Requirement confirmation is that we review the requirements with Clients, reach an agreement on the

requirements and make promises. We can implement it by means of a phone call, an email or a meeting. Requirement tracing is that we build and maintain a bidirectional relationship on the requirements through comparing the correspondence between the requirements and the follow-up work such as design documents, coding, and test use case, so as to ensure that our products are developed according to the requirements. Requirement change management is that we handle the change of requirements according to a process of “Request for Change-Review-Change-Reconfirm”, so as to ensure that the change of requirement should not lose control and cause chaos to our project.

9 Requirement Management Process

10 Confirm requirements

Requirement confirmation is the process of recreation in the picture. We will confirm with our clients every Wednesday.

For example, in the following picture, add a column to show whether a transaction was MANUAL or SWIPED. We should discuss with our clients about the details, such as the caption and location of the column added. And ensure that what we will do meets the clients’ requirements.

The following description will take this requirement as an example.

10.1 Aim

Recreate clients’ requirements, so as to confirm the authenticity of clients’ requirements. And then manage them by Project.net.

We ensure that in the picture there was no relevant column to show whether a transaction was MANUAL or SWIPED. And we should ensure that the requirement is feasible and our change is stable.Then we will manage the requirement by Project.net.

10.2 Roles and Responsibility

Test members or the assigned requirements manager recreate the requirements according to the description.

And our test members will test our program and check the dialog. They should ensure that our program did the same procedure as the picture showed. And they should ensure that the change is meaningful. Then they will report it.

10.3 Start Standards

Every morning test members should check the clients’ requirement management system to see if there are new requirements. If yes, then we start to work on them.

Every day the test members should report “Daily Bug Status” for us. The “Daily Bug Status” let us know if there is any bug or requirement. And it also let us know what we should do.

10.4 Input

Clients’ new requirementsThe test member should confirm the requirements every day. Then add it to

Project.net and mark the status of the requirement.

10.5 Main Steps

10.5.1 Get new requirements from the clients’ system

Every morning test members should check the clients’ requirement management system to see if there are any new requirements, record them to Project.Net, and set their status to confirming. And send emails to inform the team leader and PM.

10.5.2 Recreate the requirements

Test members recreate clients’ requirements in our system. The results should be as following:

1. Can be recreated, set the requirement status in Project.net to “Confirmed”.2. Cannot be recreated, set the requirement status in Project.net to “Pending”. And

send an email to confirm it with clients. Once we get the results of the confirmation:a. If it can be recreated, follow step 1;b. If not, set the requirement status to “Rejected”,” Canceled” or “Resolved”. If the

time used in confirmation is over 1 hour, the test member should write a Deliver Xml.

10.5.3 Get Commitment of the Requirements

Related personnel should add a blog of commitment to undertake the requirement after PM distributes the requirements to them.

10.6 Output

Requirements and the promises in Project.Net

In Project.net we should describe the requirement and confirmation. At the same time we should show the expected result. Those will help developer to code and the test member to test.

10.7 End Standards

Requirements are confirmed and added to Project.net. And related personnel make promises to undertake them.

11 Requirements Tracing

Ensure developers and test members to make corresponding changes when the requirements changes, and change requirements status in time.

11.1 Aim

The descriptions or expected results of clients may change, so the code and tests should also change.

When the descriptions of clients are changed, we should change our work plan, especially the developer and the test member should do as new description.

11.2 Character and Duty

The related personnel write a deliver xml of the current requirement and add comments to the code. There should be an index of the requirement in the comments.

The deliver xml will let the clients know what we have done about the requirements. And it also records the changes in our program at the same time. We will know the details about the change in future. And the developer will trace code conveniently.


The requirement is recreated.Before we do, we should ensure the problem. It will avoid that what we do is

unnecessary. And it will help the developer to know more about the requirement.

11.4 Input

Maintenance type project: a list of requirements after they are recreated, the code, docs of requirements (optional).

For requirements, we should record them in detail. The developer will code it with reference. The test member will test them as description. The PM also manages it easily.

11.5 Main Steps

11.5.1 Write Deliver Xml and Code Comments

A deliver xml is used to explain that which files are modified for which requirements. The comments in the code are used to explain that which requirements are related to this file.

11.5.2 Find the inconsistency

Reopen the status of a requirement, by walkthrough, add new descriptions of new requirements and update the xml.

11.5.3 Eliminate the inconsistency

Eliminate the inconsistency by tests and walk through.The developer should do unit test and ensure the change. If OK. The test member

will walk through it. Those will eliminate the inconsistency. And ensure the requirement to be met.

11.6 Output

Changes of requirements in Project.netThe test member or PM will output the changes of requirements in Project.net. It will

record the change. It will also help developer and test member to code or test.

11.7 End Standards

All the requirements are marked as “confirmed”.After we confirm the requirements, we will mark it as “conformed”. It will let us

know which requirement to confirm and which requirement confirmed. It also helps developer to start coding and it will let the test member to write test documents.

12 Requirement Change Control

12.1 Aim

Modify the incorrect places in the old requirement documents and create new requirement documents.

Manage the changes of requirements.

12.2 Character and Duty

The sponsor of development control changes of requirements together with clients.The sponsor of development keeps in touch with clients. If requirements change, the

sponsor can update it quickly.


Clients send emails to request for changes in requirements.If clients change the requirements, they can send emails to the sponsor.About the requirement we take as example, at first we change it as the following

picture:

But then the client sent emails to us to sort the column dialog for additional requirements.

12.4 Input

Requirement list in Project.netWe should input the updated the requirement in Project.net.

12.5 Main Steps

12.5.1 Request for a Requirement Change

Receive an email that clients request for a requirement change.

12.5.2 Review the Request

PM will decide whether or not to accept the request in the email.PM will take the updated requirement into account. If ok, he will tell developers to

update the program. Then test members also update the test documents.

12.5.3 Modify the Requirement Document

Add a newest description in the requirement descriptions in Project.net.

12.5.4 Reconfirm the Requirement

Remake commitments in Project.netIf PM decides to modify the requirements, and the status also should be remarked.

12.6 Output

Modified requirement descriptions in Project.net

12.7 Notes for Change Control

1. Every change must have customer impact documented2. Every change must have management sign-off3. Every change must be tested for operational functionality4. Every change must have a back-out or de-installation procedure

We make changes according to customers’ request. We have an email system to

handle with this. When a request email comes from a customer, we’ll discuss it with our

customer through phone calls or IM tools. When we reach an agreement with our

customer, we’ll request an email as a confirmation from our customer. We won’t make

any changes until we get the confirmation letter. And of course we’ll run a thorough test

before we send the release to our customer. We will record every change with a revision

number in our SVN. We can easily roll back all these changes.

12.8 End Standards

The status in Project.net is modified as “confirmed”If we finish updating the requirements, we will mark the status as “confirmed”.

Technology Solution Implementation Guideline

13 Aim

Clarify how to design, code and unit test.

14 Roles and Responsibilities

Roles Responsibilities

PM Responsible for roles, assignments, evaluation, supervision etc.

Designer Responsible for designing documents based on customers’ requirements in Project.net.

Developer Responsible for coding and unit test

Test member Walk through and test before checking in

Code Reviewer

Review the code before checking in

Industry Standards

Our general software development processes based on CMM3 standards. All

personnel involved in our development must be trained with the basic knowledge of

CMM3 and use it throughout our development processes.

Separation between Dev/Test and Production

We set up different virtual machines for Dev/Test and Production. The virtual machines for Dev/Test are more in favor of development, with IDE tools in them. While the virtual machines for Production is much closer to the customers’ environment. The virtual machines for Production are well monitored and kept with a clean environment. Only when the time comes for a Production release, we’ll use them. The virtual machines for Dev/Test belong to the develop department, while the virtual machines for Production belong to the Production department.

Different virtual machines are kept in different pcs. They’re independent and will not affect each other.

Everyone must provide his account and password to log on to these virtual machines. And the password will be changed periodically. Only PM of the project and the related QA have access to the production systems.

When a build in the DEV machine passes all the tests, all the code changes will be reviewed. When the review process is passed, we’ll update the code in the production machine and make a production build for the clients.

15 Start Standards

The project has been approved. The requirement status of the project has been marked as "Confirmed" in Project.net.

16 Input

The requirement list of clients is in Project.net and the <”product requirements specifications">.

17 Process

Select Candidate Solution

Select a candidate solution from the blog in Project.net. The rule for selecting a candidate solution is that the solution must be easy to implemented, and will not increase the burden on the system.

Implement Design

Designers are responsible for implement design. This includes system architecture design, module design, database design, interface design, UI design etc. Not every project has to do all the design, for instance some projects don’t need a database, or some projects don’t need UI.

Use JUDE or MS Visio to create UML diagrams and work flow diagrams, and use Toad module to design the database during implement design.

Implement Standards

1) Protect sensitive authentication data prior to authentication1. Minimize the sensitive authentication data that need to be stored prior to

authorization.

2. If sensitive authentication data is stored prior to authorization, encrypt it.

3. If sensitive authentication data is stored prior to authorization, delete the data securely

afterwards by filling out all zeros.

For example:

Let’s use a typical online transaction as an example. When the customer swipes their

cards, the system will store the encrypted cards' data in a file with the suffix SES. And

send this file to 911server.

(KJE 02/13, for row 1)

Our software temporarily stores SAD prior to authorization. If it is a swiped

transaction necessary data from card track will be stored. If it is a manually input

transaction, necessary input data will be temporarily stored depending on what has been

input. The necessary data includes PAN, name, CVV, Address Data, Address Zip.

These data will be deleted immediately after authorization.

(KJE 02/13, for row 2 and 3)

For the application, logs cannot be configured by customers, or resellers/integrators.

The following are the logs needed by the Operating System, the log path is "SYSTEM\

CurrentControlSet\Services\EventLog\Application\CreditLine":

1. Cannot allocate memory for card processing: This log will be created if there is not enough

memory space when doing settlement.

2. "Processor Name" Batch Successful: This log will be created when batch successful.

3. "Processor Name" Batch Failed: This log will be created when batch failed.

Whether the transaction is online or offline, the card number and the expiration date

will be stored in the file CCV_JOR.DAT. This file is encrypted with AES256 encryption

algorithm with multi-level key management.

*Our software will not collect SAD by any means. Temporarily stored SAD will only

be used for bug tracing. And it will be fully encrypted and deleted after used.

*Before deleting the files, make sure to fill all the binary bits in the files with zero.

2) Delete any sensitive authentication data (pre-authorization) gathered as a result of troubleshooting the payment application.

1. Collect sensitive data only when needed to solve a specific problem

2. Collect the least amount of sensitive data possible to solve the problem

3. Store sensitive data in specific, known locations with limited access

4. Encrypt sensitive data while stored

5. Securely delete sensitive data immediately after use

The client can use this menu item to collect support files (containing the log file

and other program setup files):

Choose a time period:

Then press OK, the support files will be generated in 911\SUPPORTFLIES.

In this zip package, the MESSAGE folder is used to store transaction session files.

The LOG folder is used to store the log files after a batch. The JOR folder is used to store

the batched transaction data. The DATA folder is used to store log files and transaction

data which are not batched. The log of all actions taken can be found in the data folder

within the file CCV_LOG.txt.

In these files, only masked account number and the transaction time and the

processor file are recorded, in order to compare those transactions with a host when

necessary. And these will be the least data we need for the purpose of tracing problems.


Debug files do not save the SAD. And files in the JOR directory and the LOG directory only

encrypt and save the account number and the expiration date. These files only contain

private information about transaction process, and have nothing to do with clients’ private

information. This information is used by the technicians to debug.

And finally, we reserved the insignificant data into log files.

These log files will be deleted immediately after support work is done. End users will

also need to delete these trace logs after the issue is resolved. Check the following picture

for how to delete the trace files. This is VERY IMPORTANT for PCI compliance:

Logs must not be disabled and doing so will result in non-compliance with PCI DSS.

When this is done, all SAD collected to solve the issue will be purged from the log

file.

The customers can use the menu item in following screenshot to manually purge data after the defined retention period.

Strongly advise that customers and resellers/integrators control access, via unique user ID and PCI DSS-compliant secure authentication, to any PCs, servers, and databases with payment applications and cardholder data.


3) Implement key management process and procedures for keys used to encrypt cardholder data

1. Payment application must generate strong keys

2. Payment application must distribute keys securely

3. Payment application must store keys securely

4. Payment application must facilitate periodic key rotation

When customers update encryption keys, the update date will be recorded in file

“C:\911\Data\911_CCV.INI”

The encryption keys’ default lift cycle is 90 days which is defined in file “C:\911\

Data\911_CCV.INI”. The customers can change the default “KeyLiftCycle”.

The encryption keys were used more than the period defined in “KeyLifeCycle”.

You cannot do any action in CreditLine’s interface and there is a popup to remind

customers to update key.

5. Payment application must facilitate archiving, destruction, or revocation of old keys

6. Payment application must facilitate replacement of compromised keys

7. Payment application must facilitate split knowledge of keys

8. Payment application must prevent unauthorized key substitution

9. Payment application must allow for key custodians to sign a form specifying that they

understand and accept their key-custodian responsibilities

(KJE 02/13, for row 16)

When a user start 911CreditLine main program, the program will generate a unique

KEKEK by using DPAPI.

And then our program will use AES256 algorithm to generate an encrypted KEK

with the KEKEK and some random 32 bit string. This will be done for 1000 times to form

an Encrypted KEKs table with a key index from 000 to 999.

In the following process, our program will use AES256 algorithm to generate an

encrypted DEK with a KEK which has the corresponding index and some random 32 bit

string. This will also be done for 1000 times to form an Encrypted DEKs table which will

also record the index of every DEK.

When the program is going to encrypt some transaction data, it will pick up an index

randomly first. Then it decrypts the KEK which has the corresponding index from

Encrypted KEKs Table with KEKEK. And it decrypts the DEK which has the

corresponding index from Encrypted DEKs Table with this KEK. And finally the

program encrypts transaction data with this DEK and records the index.

Our program will use the recorded index to get the DEK from Encrypted DEKs

Table to decrypt transaction data.

1. There is a table of 1000 “data encrypting keys”

a. Each piece of encrypted data contains the index of the “data encrypting key”

which is used for the encryption

b. Each “data encrypting key” is encrypted using a “key encrypting key”

c. The application provides the function to re-generate the “data encrypting

keys”

i. It generates the new keys

ii.It decrypts the previous data using the old keys

iii. It re-encrypts the data using the new keys

2. There is a table of 1000 “key encrypting keys”

a. Each encrypted “data encrypting key” contains the index of the “key

encrypting key” which is used for the encryption

b. Each “key encryption key” is encrypted using a “master key”

c. The application provides the function to re-generate the “key encrypting

keys”

i. It generates the new keys

ii.It decrypts the “data encrypting keys” using the old keys

iii. It re-encrypts the “data encrypting keys” using the new keys

3. The “master key” is protected by Microsoft “Data Protection API” – DPAPI

a. The DPAPI is set to use the machine credential, different PC has different

machine credential, so there will be much difference in encrypting or

decrypting data. The encrypted data can only be decrypted in the same

machine

b. The secondary entropy is set using the application’s hash value

c. The application provides the function to re-generate the “master key”

i. It generates the new key

ii.It decrypts the “key encrypting keys” using the old master key

iii. It re-encrypts the “key encrypting keys” using the new master

key

When the CCV_MANAGER is initializing three “.ini” files will be generated in the “Data”

folder to archive old keys which are “MasterKey.ini”, “KeyEncryptingKey.ini”,

“DataEncryptingKey.ini”. And they are encrypted.

Please pay attention that:

In order to keep the same length in “KeyEncryptingKey.ini” and

“DataEncryptingKey.ini”, all the DEK and KEKs are converted by Base64 Algorithm. So

it should be rollback in the code when encrypting sensitive data.

We can manage these keys on the UI of Manager program.

The menu item “Update KeyEncryptingKey” and “Update DataEncryptingKey”

are used in destruction or revocation of old keys and facilitating the replacement of

compromised keys. The previous keys will be overwritten if you click these two

menu items (Such irretrievability is absolutely necessary for the end-user's PCI DSS

compliance.).

Note: Cryptographic key material and/or cryptograms from prior versions of the

application must be rendered irretrievable.

Access should be removed from all users other than administrators. You can do this

according to the following screenshot:

Note: Customers must limit administrative access on the operating system and the application

to keep personnel with key access and log access to the fewest number of personnel possible.

Right click the KEY files>Properties>Security>Edit>click the group or user>Click

Remove>Click OK.

Cardholder data exceeding a retention period must be purged. This can be done by delete all the contents within the JOR folder and the LOG folder in the installation directory (for example c:\911). There is no place to set a customer-defined retention period within the software and that this must be performed by an administrative user on their own schedule.

These two folders (“C:\911\LOG”, “C:\911\JOR”) are where cardholder data could possibly be stored.

In order to prevent inadvertent capture or retention of cardholder data, please

configure the system wisely. Below are the steps:

In order to protect the installation files from the arbitrary deletion/modification, please change the

default permission as soon as you complete the installation. You can change the permissions

according to the steps below:

1. Right-click the installation directory (“911” folder), click Properties.

2. Click the “Security” tab, then click “Edit” button.

3. You can click the checkbox below to allow or deny the access permissions of the specified

user/group or click remove button to remove the specified user/group directly.

Note: If your operating system is Windows XP, you should uncheck the “Use simple file

sharing(Recommended)” option in Folder Options(Start->Control Panel>Folder Options)

first before trying to installation directory’s default permission .

To prevent inadvertent capture or retention of cardholder data, please do NOT

include the 911 folder in restores and backups by the following steps:

1. Open Control Panel\All Control Panel Items\Backup and Restore

2. Click on "Change settings"

3. Select the same target as before and click Next.

4. Click on "Let me choose"

5. Expand the structure of disk

6. Uncheck the checkbox next to the “C:\911” folder

4) Payment application must facilitate use of unique usernames and secure authentication for all administrative access and for all access to cardholder data

1. All users must have a unique ID

2. The authentication method is user name and password

3. Group, shared, or generic accounts and passwords must not be used

4. Passwords must be changed at least every 90 days

5. Passwords must be at least seven characters long

6. Passwords must contain both numeric and alphabetic characters

7. Passwords must not repeat any of the last four used

8. Accounts must lock out after no more than six failed attempts

9. Accounts must remain locked out for at least 30 minutes or until an administrator re-

enables the ID

10. Account logins must time-out and require password re-entry after no more than 15

minutes

We set up a user name and a password for every custodian. The name is unique. And

every record of custodian info has a unique ID. Custodians can change their password

anytime at our web site “license.911software.com”. We have rules when custodians

change their password just like the above. And we’ve got the session-break rules and

account-lock rules for our web server log-in system.

For example:

When 911 software is installed the default user name pre-stored in ccv_info.dat is “admin”

and the password is “creditline1”.

When the users are using their own processor file, this default name and password will be

deleted and replaced by their own administrator accounts. They will need to apply for a

new administrator’s account for the software and sign a certification with 911 software to

claim that they understand and accept their key-custodian responsibilities.

In CCV_INFO file Group, shared or generic accounts and passwords do not exist. So group,

shared, or generic accounts and passwords will not be used.

(KJE 02/13, from row 12 to row 17)

We can reset the password if it’s the first time to log in.

If the new password is shorter than 7 bytes, the program will prompt as below:

If the new password is not combined with letters and numbers, the program will

prompt as below:

If the new password is the same with any of the last 4 passwords, the program

will prompt:

We can set multiple user accounts and passwords by choose menu Configuration->Security:

After selecting Security from the main menu, the user needs to log in as an administrator so

that he can enter the User Management window.

Use Add to add an account for an administrator or a normal user. Account name needs to be

unique, or our system will prompt "Try another name". Please modify to grant

authorizations for the account as below.

In order to protect your CreditLine application, please create your owner user having

administrator’s permission and then delete the default admin account.

Create custom user with administrator’s permission:

Delete the default admin account:

Add directions that the admin user must be deleted here.

When a user logs in, if the system detects that it’s already longer than 90 days since the

last login, or the password has been user for longer than 90 days, the program will

prompt as below.

After a user logs in successfully, if no operation is detected by the system for 15 minutes, the

session will be automatically timeout. The program will prompt:

After press OK button, the user needs to re-login.

If an account has not a particular authorization, a hint will pop out when he tries to use the

function.

Click "Delete" button to delete the selected account.

If the user has input wrong passwords for 6 times, the current account will be locked and not

usable. The user needs to call an administrator to unlock his account. If there is no current

available administrator account anymore, he will have to call 911 software for support.

We use the binary file CCV_INFO.DAT to store these accounts and passwords. Only

911CreditLine knows how to change the contents of this file.

The binary file CCV_INFO.DAT can be renewed from 911 software.

Before moving our software to production, we'll rebuild installation package

with a clean environment. Before making this production installation package, all

test data will be removed. In the package, there are only executables, dependency dll

files and other configuration files. And the test accounts will be removed from the

customer account configuration file "CCV_INFO.dat" before packaged in.

Customers will be required to create one administrator account as well as one normal

user account before using our software, if not, all functionalities will stop working.

Pic 1, the customers are required to create their own accounts before using our

software:

Pic 2, where to create the accounts, we can see that default installation will have

no test accounts in the system:

*Important Notice: Before releasing a new version, we MUST remove any

default administrator accounts.

File operations can be logged by the following system setup:

1. From Start menu, Open "Control Panel" ->”System and Security” ->"Administrative

Tools"->"Local Security Policy".

Expand “Local Policies” and choose "Security Options"-> change "Audit: Force audit

policy subcategory settings..." to "Disabled".

2. Choose "Audit Policy"->change "Audit object access" by ticking up the "Success"

checkbox.

3. Right click on the 911 folder, select "Properties", go to "Security" tab, click

"Advanced" button. Then go to the "Auditing" tab, click "Continue".

4. Click "Add..." button to add a user or group, check "Full control" under Successful

and Failed in the Auditing Entry screen. Check "Apply these auditing entries to

objects...", then click "OK" button. Click "Apply" or "OK" for all other screens to

save all these settings. (Please do this action for all users)

5. If a user who has been added to the auditing entries deletes any file or folder within

the 911 folder, we can open windows event log ("Control Panel"->"Administrative

Tools"->"Event Viewer").

Choose “Windows Logs”->“Security” all file deletion operations will be logged here.

Below is one instance:

(KJE 02/13, from row 19 to row 27)

Other notifications:

1. MD5 hash check files accompany our build release. This is to check whether the released

build is infected with viruses, or edited by other possible tools.

2. A firewall must be in use within the merchant environment as required by other points

within the documentation.

3. Customers need to encrypt all non- console administrative access with strong cryptography,

using technologies such as SSH, VPN, or SSL/TLS for web-based management and other

non-console administrative access. Note: Telnet or rlogin must never be used for

administrative access.

4. A review will be performed at least annually and updates to keep the documentation

current with all major and minor software changes as well as with changes to the

requirements in this document.

5. Payment application resellers and integrators need to know how to implement the payment

application and related systems and networks according to the PA-DSS Implementation

Guide and in a PCI DSS-compliant manner. Please refer to our website

www.911software.com for the directions.

6. The training materials on our website will be updated on an annual basis and whenever new

payment application versions are released.

7. If vendors, resellers/integrators, or customers can access customers’ payment applications

remotely, the remote access must be implemented securely. Note: Examples of remote access

security features include: Change default settings in the remote access software (for example,

change default passwords and use unique passwords for each customer). Allow connections

only from specific (known) IP/MAC addresses. Use strong authentication and complex

passwords for logins (See PA-DSS Requirements. 3.1.1 through 3.1.1.0) Enable encrypted

data transmission according to PA-DSS Requirement 12.1. Enable account lockout after a

certain number of failed login attempts. (See PA- DSS Requirement 3.1.8.) Configure the

system so a remote user must establish a Virtual Private Network (“VPN”) connection via a

firewall before access is allowed. Enable the logging function. Restrict access to customer

passwords to authorized reseller/integrator personnel. Establish customer passwords

according to PA-DSS Requirements 3.1.1through3.1.10.Aligns with PCI DSS Requirement

8.3

8. There is no two-factor solution provided by 911 Software. All remote access to CreditLine

Manager requires two-factor authentication. Access must be controlled by the customer, only

enabled when in use, monitored while in use, and disabled immediately after use.

9. The 911 Software does not allow the sending of PAN by end-user messaging technologies.

10. The911 software allows data transmission over public networks using SSLv3 encryption

protocols.

11. The magnetic stripe data, card validation codes, PINs, and PIN blocks are NOT stored by

previous versions of the 911 software. The cardholder data stored in the folder "C:\911\JOR"

is the only sensitive data stored by previous versions which must be purged. This can be done

by removing all the contents within the JOR folder. (Note: Such removal is absolutely

necessary for the end-user's PCI DSS compliance)

Review Design

PM and related personnel will participate in the review. The purpose is to determine that the design meets users' requirements, well-structured, easy to implement, scalable, maintainable, etc.

Requirement Recreation and Confirmation

After receiving requirements from clients’ requirement management system, test members need to recreate them and confirm the existence of the issue. If confirmed, go for the next step. If not, then we need to confirm it with clients.

Coding

Coding is the process that the programmer turns requirements into real products. The code must meet our company's coding standards. Or need to use the code formatting tools of our company to format the code.

Unit Test

When coding is over, the programmer must run the unit test, to ensure that the program can be executed correctly and efficiently.

Walk through

When the unit test is passed, test members need to walk through the program to verify the implementation of the program.

Code review

When the walk through is passed, the programmer needs to ask for a code review. The project manager has to sign off on the code review process.

(KJE 02/13, for row 41)

Check in code

When the code review is over, we need to check in the code to the specified position of the server with specified version control tools. If it is a maintenance type project we should write a deliver xml.

18 Output

Required: architecture design document, interface design document, the source code, the deliver xml

Optional: module design document, database design document, UI design document, user manual

19 End Standards

For a maintenance type project: the code checked in, the deliver xml is written

20 Release and delivery

Before delivery we must do the pre-release cleanup:

1. Live PANs are not used for testing or development

2. Test data and accounts must be removed before a production system becomes active

3. Custom accounts, usernames, and passwords must be removed before customer

release

We ask the processor for test accounts and scripts. They will provide us all the

physical test cards.

The test data is only activated for test server of the host. When the test is done, we’ll

uninstall the program and manually delete the test data. These data is not effective for the

production server of the host.

We use test cards for our testing and developments. These accounts are acquired

from the host when we add support of new processors to our project. For example, we use

the test card account number “4111111111111111” for a TSYS processor. And these

accounts can only be used for testing. When we do a production release, these accounts

will be removed.

And we use test usernames and passwords for our license registration web service

project. Before the real web service is deployed, all these test usernames and passwords

will be cleared out from the database.

We’ll do sanity test before a version release. First modify 911_CCV.ini, open test

mode, to keep the safety of the data:

We can replace the file CCV_INFO.DAT in the DATA folder to test different

processors:

21 Patch/Update Management

1. Patches must be developed and deployed in a timely manner

2. Patches must be delivered in a secure manner with a known chain-of-trust

3. Patches must be delivered in a manner that maintains integrity of the deliverable

4. Patches must be integrity checked by the target system prior to installation

When a new requirement is coming from the client, we will establish a new

requirement doc for it. Then the programmers will implement the requirement. After this

is done, Our QA will test the program to verify the implementation. When the test is

passed, we’ll make a patch for the client. When the implementation is approved by the

client, we’ll include the change in the next public version release.

The download site does not use HTTPS. But it uses MD5 Hash. The download file

and the setup files all have the Hash file generated and available. The customers

download the installation package as well as the MD5 file. By verifying the Hash Value,

it can be determined that if the installation package has been tampered.

Here are the steps of generating and Verifying MD5 file:

1. Run the MD5summer.exe

2. Add the original application to sum

3. Generate MD5 file

4. Save the MD5 file

5. Verify the correction of Original application and MD5 file

6. Save the verified result

7. Save the final result in txt file

8. Open the txt result

Our sanity test includes all transaction types and uses all test cards supplied by

different processors. And all the tests are running according to the test scripts supplied by

different processors. The below is part of the test script:

We have a monthly delivery plan. New build will be available for customers to

download from our web site. Every month, we collect requests for changes and possible

issues from our customers, and trying to make these changes and solve these issues. We

do a thorough sanity test before the delivery to test for the integrity and security. The

downloading web site contains all history versions of our software.

22 Maintenance

1. The Implementation Guideline must be disseminated to all customers, resellers, and

integrators

2. The Implementation Guideline must cover all applicable requirements in the PA-DSS

3. The Implementation Guideline must be reviewed and updated at least annually

4. The Implementation Guideline must be reviewed and updated whenever the

application is updated

5. The Implementation Guideline must be reviewed and updated whenever the PA-DSS

is updated

System Test Implementation Guideline

23 Aim

The aim of a system test is to do an overall test to the final software system, to ensure that the final software system meets the product requirements and follows the system design steps.

24 Introduction

The system test flow is as Pic 3-1. The aim of a system test is to verify that the final software system meets the product requirements and follows the system design steps, so after product requirements and system design documents are finished, the system test team can make the plan of the test and design the test use cases. The system test team does not need to wait for the implementation and testing to be finished. They can begin to make test plans and test use cases ahead of time. This can benefit the efficiency of the system test.

The imperfections found in the system test must use poject.net. Developers must eradicate the imperfections as soon as possible.

Pic 3-1 diagram of the system test flow

25 System Test

25.1 Aim

The aim of a system test is to do an overall test to the final software system, to ensure that the final software system meets the product requirements and follows the system design steps.

25.2 Roles and Responsibilities

The PM establishes the system test team, and assigns a member to be the team leader.

All members of the system test team make test plans together, design test use cases together and execute the test together and write documents about the tests. The team leader is in charge of all the arrangements.

Developers must eradicate all the imperfections found by the test team.


After product requirements and system design documents are finished.

25.4 Input

<”Product requirements specifications”>

25.5 Main Steps

25.5.1 Make a plan of system test

Members of the system test team discuss about the test plan together. The team leader writes the <”System Test Plan”> according to an assigned template. This plan should include:

Test range (contents)Test methodEnvironmentsPersonnel and task listPM’s approval on <”System Test Plan”>

25.5.2 Design system test use cases

Members of system test team make test use cases according to the <”System Test Plan”> and assigned templates.

The team leader can tell the developers to review the <”System Test Use Cases”> together. After the test use cases pass the review, we can start the system test immediately.

25.5.3 Start System Test

Members of the system test team execute system tests according to the <”System Test Plan”> and <”System Test Use Cases”>.

Record the test results in the <”System Test Report”>. Manage the imperfections with Project.net. And inform developers as soon as possible.

25.5.4 Imperfection management and modifications

During the test, anyone who finds an imperfection needs to record the problem to Project.net. As for the bugs to be modified before delivery, developers must solve them as soon as possible. The developers must run a regression test after the bugs solved, in order not to bring new bugs into the project.

25.5.5 Verification

All security patches and system and software configuration changes must be

tested before deployment1. Verify validation of input (to prevent cross-site scripting, injection flaws, malicious

file execution, etc...)2. Verify proper error handling3. Verify secure cryptographic storage4. Verify secure communication5. Verify proper role-based access control6. Tests for injection flaws, particularly SQL injection (Validate input to verify user data

cannot modify meaning of commands and queries, utilize parameterized queries, etc.)7. Tests for buffer overflow (Validate buffer boundaries and truncate input strings.)8. Tests for all "High" vulnerabilities as identified by internal risk analysis.9. Processes to assign a risk ranking to identify vulnerabilities. (At minimum, the most

critical, highest risk vulnerabilities should be ranked as “High”)

For example:Test the input box with different irregular inputs;Let’s input some special characters in 911CreditLine Manager as below:

It cannot pass the verification, the error message will be:

Try to do transactions with incorrect card info;We’ll input some invalid card numbers without any special character as below:

It still cannot pass the verification, the error message will be:

25.5.6 Vulnerability Testing for Web Applications

1. Test for cross-site scripting (XSS) vulnerabilities2. Test for injection flaws (SQL, etc...)3. Test for malicious file execution4. Test for insecure direct object references5. Test for cross-site request forgery6. Test for improper error handling and information leakage7. Test for broken authentication and session management8. Test for insecure cryptographic storage9. Test for insecure communications

10. Test for failure to restrict URL accessThis is not a web application and we do not have any web -facing components.

25.5.7 External Vulnerability Identification

1. Use MSRC as an outside source of security vulnerability information2. Test the application for new vulnerabilities once per month3. The vulnerability identification process must apply to all software provided with or

required by the payment application

MSRC is in our consideration. When some new security problems are reported by Microsoft,

we will estimate the possible influence to our product. First we’ll inform our QA to run a

test for it. If that causes some vulnerability problems of our product, we’ll tell the

programmer to make possible modifications to deal with it. We have a monthly testing

plan for this. This is done along with the monthly sanity test of our software. All

programs will be tested including the CCV_SERVER.EXE, CCV_MANAGER.EXE, and

all the DLL interfaces which include clc.dll, CLClient.ocx, ClcCs.dll, CLCAPIW2.dll.

25.5.8 Cardholder data must not be internet accessible

1. The application must store cardholder data on the internal network only, never in the

DMZ2. The application must allow for the use of a DMZ to separate the Internet from

systems storing data

CHD is stored in the server machine of our software as a file. This file is encrypted and

placed in an internal network. It’s easy to prove that. Even if the internet is not accessible,

this file can be generated. A firewall system is needed here to keep this file from the

internet.

25.6 Output

<”System Test Use Cases”><”System Test Report”>

25.7 End Standards

For non-strict systems we can use the rule “based on test use cases”: Functional test use cases should be passed by a rate of 100%.Non-functional test cases should be passed by a rate of 80%.

25.8 Measurement

Members of the test team and the develop team should record the amount of work in tests and modifications, and the quantity and types of the imperfections, and should fill the data to the rating form.

26 Appendices

26.1 The Sample of Key Custodian form

Date / Time

Key Start Date / Expiration Date

Key Custodian Name and Title

Signature Witness

xx 2013.11.20/2014.2.18 Kerry Newell(Department Manager)

xx xx

… … … … …Note: The key custodians must sign the form before to get the key and they cannot

leak the keys.

26.2 Software and Hardware Environments

This is a table of all required protocols, services, components, and dependent software and hardware that are necessary for 911 software, including those provided by third parties:Type Item Name

Hardware PC,PINPAD

OS Windows XP or higher version

Software Framework 2.0 or higher version,Windows Notepad

Protocol TCP,SSL,HTTPS,CGI,COM,FILE SHARING

Service N/A

26.3 Software Version Control

CreditLine Version is composed of four parts: Major_Version_Number, Build Number, version indicator and Revision_Number.

For example, the version number 4.1Build1111SP25, 4.1 is the Major version, 1111 is the build number and 25 is the reversion number.

Major Version number indicate the major change, this version number change always means important feature, not forward compatible change.

Build version number indicate the minor change, small feature, applications have same Major version but different build version will always compatible.

Reversion number indicates very small change, like minor bug fix or enhancement.

Version indicator indicate the version type, it could have 5 different types:Alpha: internal test versionBeta : test versionLA: Limited available versionGA: General available versionSP: Stable provide version

26.4 “Info” Button Feature

In latest CreditLine version, a new button named “Info” has been added to view the archive batch

transaction information, below list several things about this feature.

1) Only specified user can perform this action to view the Full PAN, CreditLine will authorize

the user and will record the user name when the action performed, and the log will like

below, and will contain action time and user name.

16-05-23|23:44:23.312{CCV_MGR-admin}Security Log - Secure Operation Performed: Action

[Info Button Click]

16-05-23|23:44:23.312{CCV_MGR-admin}Security Log - Secure Operation Performed: User

Name [admin]

2) To enable this button, you need edit the CreditLine configuration file 911/Data/911_CCV.ini,

enable the configuration parameter “ShowInfoButton” .

3) Below are screen shot for where the “Info” button is and what will be displayed.

911 Software911software.com/cert/PCI/911_PADSS_ Implementation Guide... · Web viewAnd our test...

Documents

Transcript of 911 Software911software.com/cert/PCI/911_PADSS_ Implementation Guide... · Web viewAnd our test...