911 Software
Implementation Guideline
911 Software Development Team
2013/10/28
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.10 Estimate the review........................................................................................................................... 8
5
4.10.1
Tracing the imperfections until solved ................................................................................................. 8
4.10.2
Analyze the data during review, provide an improvement approach ................................................... 8
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
Page 2
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.1 Aim 15
10.2 Roles and Responsibility ................................................................................................................. 15
10.3 Start Standards ............................................................................................................................... 15
10.4 Input ............................................................................................................................................... 16
10.5 Main 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.6 Output ............................................................................................................................................. 16
10.7 End Standards ................................................................................................................................ 16
11 REQUIREMENTS TRACING ................................................................................................................... 17
11.1 Aim 17
11.2 Character and Duty ........................................................................................................................ 17
11.3 Start Standards ............................................................................................................................... 17
11.4 Input ............................................................................................................................................... 17
11.5 Main 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.6 Output ............................................................................................................................................. 18
11.7 End Standards ................................................................................................................................ 18
12 REQUIREMENT CHANGE CONTROL ...................................................................................................... 18
12.1 Aim 18
12.2 Character and Duty ........................................................................................................................ 18
12.3 Start Standards ............................................................................................................................... 18
12.4 Input ............................................................................................................................................... 19
12.5 Main 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
Page 3
12.6 Output ............................................................................................................................................. 20
12.7 Notes for Change Control............................................................................................................... 20
12.8 End 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 ....................................................................................................................................... 58
Requirement Recreation and Confirmation ........................................................................................... 58
Coding ................................................................................................................................................... 58
Unit Test ................................................................................................................................................ 58
Walk through ......................................................................................................................................... 58
Code review ........................................................................................................................................... 58
Check in code......................................................................................................................................... 58
18 OUTPUT ............................................................................................................................................... 58
19 END STANDARDS................................................................................................................................. 59
20 RELEASE AND DELIVERY ..................................................................................................................... 59
21 PATCH/UPDATE MANAGEMENT .......................................................................................................... 62
22 MAINTENANCE .................................................................................................................................... 65
SYSTEM TEST IMPLEMENTATION GUIDELINE ............................................................................. 66
23 AIM ..................................................................................................................................................... 66
24 INTRODUCTION .................................................................................................................................... 66
25 SYSTEM TEST ...................................................................................................................................... 67
25.1 Aim 67
25.2 Roles and Responsibilities .............................................................................................................. 68
25.3 Start Standards ............................................................................................................................... 68
25.4 Input ............................................................................................................................................... 68
25.5 Main Steps ...................................................................................................................................... 68
25.5.1
Make a plan of system test ................................................................................................................. 68
Page 4
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.6 Output ............................................................................................................................................. 72
25.7 End Standards ................................................................................................................................ 72
25.8 Measurement .................................................................................................................................. 73
APPENDICES.............................................................................................................................................. 74
26 SOFTWARE AND HARDWARE ENVIRONMENTS ..................................................................................... 74
27 SAMPLE KEY CUSTODIAN FORM ......................................................................................................... 75
Page 5
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
Chairman
Spokesman
Recorder
Conferee
3
Review Type
Type
Formal review
Individual review
Walkthrough
4
Responsibilities Description
Response for the plan and management of the review
Response for explaining the contents and goal of the review
Response for recording the contents and questions of the review
All those who need to attend the meeting, must give opinions about the
content of the review
Description
Suitable for the key points of the project progress
Suitable for the details of the project progress
Level
High
Medium
Low
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.
Page 6
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.
Page 7
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
5.1
Informal review
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.
Page 8
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 review
The 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.
Page 9
5.5.3
Modification, tracing and review
1. Modification and tracing
The owner modifies the work products, eradicate the imperfections.
The adjudicator traces the status of every imperfection.
2. Review
After 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 Review
1. Code changes are reviewed by knowledgeable individuals other than the originating
code author
2. Appropriate corrections are implemented prior to release
3. 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.
Page 10
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.
Web Application
1. Code review ensures code is developed according to secure coding guidelines such as
OWASP
2. 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.
Wireless Applications
3. 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.
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
Page 11
• 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
7.1
Other
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.
Page 12
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.
Page 13
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.
Page 14
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.
Page 15
10.4 Input
Clients’ new requirements
The 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.
Page 16
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.
11.3 Start Standards
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.
Page 17
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.net
The 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.
12.3 Start Standards
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:
Page 18
But then the client sent emails to us to sort the column dialog for additional
requirements.
12.4 Input
Requirement list in Project.net
We 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.net
Page 19
If 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 documented
2. Every change must have management sign-off
3. Every change must be tested for operational functionality
4. 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”.
Page 20
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.
Page 21
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">.
Page 22
17 Process
Page 23
Page 24
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 authentication
1. 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.
Page 25
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.
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.
Page 26
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.

Collect sensitive data only when needed to solve a specific problem
 Collect the least amount of sensitive data possible to solve the problem
 Store sensitive data in specific, known locations with limited access

Encrypt sensitive data while stored
 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):
Page 27
Choose a time period:
Then press OK, the support files will be generated in 911\SUPPORTFLIES.
Page 28
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.
Page 29
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.
Page 30
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.
Page 31
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.
Page 32
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
Page 33
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.
Page 34
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”
Page 35
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.
Page 36
We can manage these keys on the UI of Manager program.
Page 37
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: The previous keys are deleted by the secure deletion which does not allow
keys to be retrieved by other means. The steps are:
1. Overwrite the whole file with random values to make sure the original binary
key information written on the track of the hard disk has been overwritten.
2. Deleted the file from the disk.
3. Create a new file and store the new keys.
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.
Page 38
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.
Page 39
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.
Page 40
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 .
Page 41
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
Page 42
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.
Page 43
We can reset the password if it’s the first time to log in.
Page 44
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:
Page 45
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:
Page 46
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:
Page 47
Delete the default admin account:
Add directions that the admin user must be deleted here.
Page 48
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.
Page 49
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.
Page 50
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.
Page 51
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.
Page 52
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.
Page 53
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)
Page 54
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 and by doing so Windows will log:
• Individual access to cardholder data
• Actions taken by any individual with administrative privileges
• Access to application audit trails managed by or within the application
• Invalid logical access attempts
• Use of the payment application's identification and authentication mechanisms
• Initialization of application audit logs
• Creation and
deletion of system-level objects within or by the application
And for each event record:
• User identification
• Type of event
• Date and time stamp
• Success or failure indication
• Origination of event
• Affected data, system component, or resource
Page 55
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.
Page 56
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 TLSv1 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)
Page 57
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.
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
Page 58
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:
Page 59
We can replace the file CCV_INFO.DAT in the DATA folder to test different
processors:
Page 60
4. When the software is ready to be released, we will update the version according to the
following version methodology:
911 Software utilizes a major, minor, subminor version methodology and an
internal build number in the following format:
Version 'Major'.'Minor' SP 'Subminor' Build 'Build#'
'Build#' numbers: indicate non-functional changes and are incremented when
cosmetic or other non-functional changes are made.
'Subminor' numbers: indicate bug fixes and are incremented when defects in intended
functionality are corrected.
'Minor' numbers: indicate minor changes and additions and are incremented when
minor changes and additions to functionality are implemented.
'Major' numbers: indicate major changes and additions and are incremented when
major changes and additions to functionality are implemented.
e.g. Version 4.1 SP88 Build 1102 indicated Major=4, Minor=1, Subminor=88,and
Build#=1102
Page 61
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.
We upload the installation file and corresponding *.MD5 file to 911 software’s
official download site (http://www.911software.com/files/) in every routine delivery.
Here are the steps of generating and Verifying MD5 file, you can also find the
information on 911 software’s website:
The steps to generate the original MD5 file:
1. Please download MD5summer.exe from
http://www.md5summer.org/download.html
2. Run the MD5 summer.exe and add the original installation file to create sums, then
click OK to generate and save the MD5 file.
Page 62
The steps to confirm the correctness of the customer’s installation file:
3. Please download the MD5 file that match the installation file from
http://www.911software.com/files/.
4. Put the customer’s installation file and the original MD5 file in the same folder.
5. Right click the original MD5 file->Verify with md5summer.
Page 63
6. Save the verified result to txt file.
7. Open the txt file to see the verified 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.
Page 64
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
Page 65
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.
Page 66
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.
Page 67
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.
25.3 Start Standards
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 method
Environments
Personnel and task list
PM’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.
Page 68
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 deployment
1. Verify validation of input (to prevent cross-site scripting, injection flaws, malicious
file execution, etc...)
2. Verify proper error handling
3. Verify secure cryptographic storage
4. Verify secure communication
5. Verify proper role-based access control
6. 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:
Page 69
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:
Page 70
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) vulnerabilities
2. Test for injection flaws (SQL, etc...)
3. Test for malicious file execution
4. Test for insecure direct object references
5. Test for cross-site request forgery
6. Test for improper error handling and information leakage
7. Test for broken authentication and session management
8. Test for insecure cryptographic storage
Page 71
9. Test for insecure communications
10. Test for failure to restrict URL access
This 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 information
2. Test the application for new vulnerabilities once per month
3. 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
DMZ
2. 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%.
Page 72
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.
Page 73
Appendices
26 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
Software
Protocol
Service
PC,
PINPAD
Framework 2.0 or higher version,
Windows Notepad
TCP,
TLS,
HTTPS,
CGI,
COM,
FILE SHARING
N/A
Page 74
27 Sample Key Custodian Form
The responsibilities of a key custodian include protecting the key itself as well as
access to the key. By signing below, I __________________ acknowledge and
understand that:

I will follow the policies and procedures associated with key management and
agree to comply with them to the best of their ability.

Non‐compliance with these policies can lead to termination of employment and possible
legal liability.

I must never divulge to any unauthorized party the key management practices, procedures
or permit unauthorized access to systems, passwords, processes, or other sensitive
information associated with the company.

I must promptly report any suspicious activity to management, to include suspected key
compromise, unauthorized access to systems, and theft.
I agree to the above in full and understand my responsibilities as indicated above.
Signed: _______________________________________________________
Printed Name: ___________________________________________________
Date: ________________________________________________________
Manager: ______________________________________________________
Printed Name: __________________________________________________
Date: _________________________________________________________
Page 75