1. General

The Policy is disseminated to all  relevant system users to include all valued Business Partners.

1.1. Risk Assessment

The organization will carry out an annual risk assessment process that would identify major strategic  developments in the industry, emerging threats and vulnerabilities to business and IT assets of the  company and report results in a formal risk assessment document. The formal Risk Assessment  should follow some industry-accepted risk assessment methodologies like, ISO 27005, OCTAVE, NIST  SP 800-30 etc.

1.2. Formal Security Awareness Program

• Implement a formal security awareness program to make all employees aware of the  importance of cardholder data security.

• Educate employees upon hire and at least annually (for example, by letters, posters, memos,  meetings, and promotions).

1.3. Formal Acknowledgement Information Security Policies

The organization should require employees to acknowledge in writing that they have read and understood the company’s security policy and procedures.

1.4. Employee Screening and Background Checks

The current employees and the potential employees in the company would be screened through a  defined procedure to minimize the risk of attacks from internal sources.

1.5. Third Party Service Provider Contractual Requirements

If cardholder data is shared with service providers, then contractually the following is required:

• Service providers must adhere to the compliance requirements of PayFi.

• Agreement that includes an acknowledgement that the service provider is responsible for the  security of cardholder data the provider possesses.

1.6. Connected Entity Requirements

All processors and service providers must maintain and implement policies and procedures to  manage connected entities, to include the following:

• Maintain list of connected entities

• Ensure proper due diligence is conducted prior to connecting an entity.

• Ensure the entity is PCI DSS compliant.

• Connect and disconnect entities by following an established process.

1.7. PayFi Client Requirements

All accessible client systems and infra that is covered in PCI scope has security implementations as per  the configuration standard documents. The relative responsibility is defined in the responsibility  matrix.

1.8. Asset Classification

Data and information classification is the conscious decision to assign a level of sensitivity to data as it  is being created, amended, enhanced, stored or transmitted. The classification of the data should  determine the extent to which the data needs to be controlled/secured and is also indicative of its  value in terms of Business Assets.

The term Business Assets, for the purpose of the scope of this policy, refers to any information upon  which the organization places a measurable value. By implication, the information is NOT in the  public domain and would result in loss, damage or even business collapse, was the information to be  lost, stolen, corrupted or in any way compromised.

Proper access controls and privilege levels are to be set before accessing sensitive cardholder data by  any user internally. Media containing sensitive data shall only be distributed to the authorized in house employees.

All applications and network hardware equipment which are accessible to the external parties and  which transmit or deal with sensitive cardholder data should be protected by strong access control  and authentication mechanisms.

Media containing sensitive data must not be handed over to any external entity or third party unless authorized by the management with proper business justification.

The following procedure should be followed for the purpose of data classification. Computer output,  regardless of media, which is classified in accordance with this classification scheme will be marked  on the top and bottom of each page and/or on each output screen with the appropriate classification,  except for the General classification, when it is created by the system.

• General

This classification includes all information that may normally be considered as General  Information, however, for business reasons management has determined that its use and  dissemination need to be controlled. Shredding of this information is not required upon  disposal.

• Proprietary

All data and information, except for media releases approved by management, used in  conducting day-to-day business is regarded as proprietary and is not intended for discussion or disclosure to other than PayFi staff. Shredding of this information for  disposal is desired but not required.

• Restricted

Some of the data and information retained in the automated systems and on other  media (e.g., microfiche, microfilm, and paper files) is critical to the continued profitability  of the organization. Other data and information are regarded as personal since it  pertains to our employees. To provide adequate protection for this type of material it  will be given a classification level of Restricted for identification. Shredding of this  information for disposal is required.

• Confidential

This category of information includes company plans, the premature release of which  could be detrimental to the company’s strategic plan (e.g., acquisitions being  planned/negotiated) or which could result in the filing of civil or other litigation (e.g.,  release of additional stock for sale or a company buy back of outstanding stock). Also  included in this category is any other information specifically designated asSecretby  Senior Management.

This information is not authorized to be stored on any computer system except for  desktop or laptop systems. When stored on desktop or laptop systems the information  will be encrypted, using approved encryption software, to provide adequate protection.  Additionally, this information will not be transmitted over any computer network within  or between PayFi facilities unless it is encrypted, using approved encryption software.

If this information is stored on removable storage media, then such items should be  properly identified and stored in a locked desk drawer, cabinet or safe when not in use.  Shredding of this information for disposal is required.

Guidelines for data classification and sensitivity must be documented and communicated  to responsible data/information owners and all support responsible in order that  information receives an appropriate level of protection.

1.9. User Access

• Responsibilities

PayFi is responsible for creating, documenting and maintaining individual  user/user group profiles that meet the requirements of Access Control Policy.

• Classification of users

Users are also classified in terms of:

✓ Least privileges that are necessary to perform the job responsibilities

✓ Individual personnel’s job classification and function

• Privileges

Privileges are allocated on a need-to-use and event-by-event basis; the request for  allocation of a privilege is initiated from the user concerned to PayFi which  reviews the reasons why the privilege is required and the length of time for which it is  required.

1.10. User registration and de-registration (Creation & Deletion)

User agreements contain statements of access rights and statements indicating that users have  understood and accepted the conditions of access. All user’s proposed access rights are documented  in a user form, which details the systems/services/applications/information assets to which access is  to be granted, together with the level of access that is granted, taking into account the Access Control  Policy. If a user is to be granted access rights other than the standards set out in Access Control Policy, then the specific additional authorization of the Management is also required.

• The system admin team authorizes access to the system/asset and passes the User Creation/Deletion form to the employee and the username/userID is created/deleted and administered.

• The system admin team maintains a list of authorized users, Administrators changes in access rights and removes users.

• The disciplinary policy will be invoked in cases of attempted unauthorized access.

1.11. Password Management

The minimum password management requirements for the systems are as follows:

Users to be issued with a temporary password, and to be forced to change  on first loginShould be mandatory for Application Access for  Individual Users – Internal and External
Password ExpiryMinimum of 90 days
Password lengthMinimum of 8
Password complexityShould be high and should contain at least one  alphabet and one numeric character
Password UniquenessMinimum history of 4
Period of InactivityMaximum of 90 days
Number of failed attempts for lockoutMaximum of 3
Lockout periodAt least 30 minutes
Session TimeoutMaximum of 15 minutes of inactivity

• First-time passwords for new users are set to a unique value for each user and MUST be  changed after first use.

• The default passwords on all new equipment are changed to conform with PayFi Password  Policy requirements before the equipment is brought into Production.

1.12. User Authentication

Users are authenticated at log-on by providing both their username and their password within the  parameters of the log-on system as per the section 6 of this document.

1.13. Review of access rights

• Access rights are reviewed by the Information Security Team quarterly and their adequacy is  confirmed.

User access rights are reviewed when auser’s role or location within organization changes in any way

2. AccessControlPolicy

2.1. Policy Statement

• The Organization controls access to information on the basis of business and security  requirements.

• Access control rules and rights to applications, expressed in standard user profiles, for each  user/group of users are clearly stated, to get her with the business requirements met by the  controls.

• The security requirements of each business application are determined by a risk assessment  that identifies all information related to the application and the risks to that information.

• Access to critical assets should be authenticated, which includes individual users,  applications, and administrators.

• Users should be authenticated through an automated access control system using unique ID  and additional authentication (for example, a password) for access to the cardholder  environment.Group or shared user-ids should not be used for any of the devices.

• TheUsers are restricted access to critical assets based on need-to-know basis and should be set to “deny all” unless specifically allowed.

• Password Policy should be as follows:

✓ Setfirst-time passwords to a unique value foreach user and change immediately  after the first use

✓ Change user passwords at least every 90 days

✓ Require a minimum password length of at least seven characters

✓ Use passwords containing both numeric and alphabetic characters Password  History to be maintained for at least last 4 passwords.

✓ Limit repeated access attempts by locking out the user ID after not more than six  attempts

✓ Set the lock out duration to thirty minutes or until administrator enables the user  ID

✓ Session-timeout must be set to 15 mins.

• The access rights to each application should take into account:

✓ The classification levels of information processed within that application and  ensure that there is consistency between the classification levels and access 

control requirements across the [systems and] network(s),

✓ The “need to know” principle (i.e., access is granted at the minimum level necessary for the role),

✓ “Everything is generally forbidden unless expressly permitted”,

✓ Prohibit user-initiated changes to user permissions,

✓ Enforcing rules that require specific permission before enactment,

✓ Any privileges that users need to perform their roles, subject to it being on a  need-to-use and event-by-event basis.

• Management of access rights across the network(s) is done by the Systems Administrator and  reviewed by the Information Security Team in line with user access matrix document exists  within PayFi

• Shared access to organization resources by sharing passwords or group passwords are  explicitly prohibited.

• User access requests, authorization and administration roles should be segregated.

• User access requests are subject to formal authorization, periodic review and removal.

• Access to the cryptographic keys is restricted to very few custodians.

3. Data Retention Retrieval and Secure Disposal Policy

3.1. Policy Statement

The entire PayFi records, either physical or digital, are subject to the retention requirements  based on business, legal and regulatory requirements. The PayFi requires that all removable  storage media (CDs, tapes, memory sticks, hard drives etc) are clean (which means it is not possible  to read or re-constitute the information that was stored on the device or document) prior to disposal.  Specifically:

• Card holder data, if stored, will be stored in encrypted form as per RBI guidelines.

✓ Copy, move and storage of cardholder data onto local hard drives and removable  electronic media are prohibited.

✓ Each data item that is stored should be marked with the name of the record,  the record type, the original owner of the data, the information classification, the  required retention period, and any special information (e.g. in relation to  cryptographic keys).

✓ The required retention periods, by record type, should be in compliance with  business, legal and regulatory requirements. The records both physical and  electronic should have secure remote offsite backups.

✓ The offsite records both physical and digital should be retrieved and reviewed at  least annually or based on the criticality of the information of the records.

✓ All records(physical and digital) moving to and from the facility to off site locations  has to be logged and inventory managed both at the primary and offsite  locations.A periodic inventory check must be done at offsite to find if there exist  any irregularities in the logging mechanism.

✓ Data should be disposed as soon as the specified retention period completes its  retention period.

✓ Cryptographic keys, which are required for sensitive transaction data should be  retained as set out as in Encryption & Key ManagementPolicy

✓ Devices containing confidential information are dependent on a risk assessment  physically destroyed prior to disposal and are never to be reused.

✓ Devices containing confidential information that are damaged are subject to a  risk assessment prior to sending for repair, to establish whether they should be  repaired or replaced.

✓ Documents,CDs,etc containing confidential and restricted information which are  to be destroyed are shredded by their owners, using a cross cut shredder. These shredders are located in the secure area and the containers are under lock and  key.

✓ Portable or removable storage media of any description are physically destroyed  prior to disposal.

✓ The data owner along with support from the custodian is responsible for  destroying data once it has reached the end of the retention period. Destruction  must be completed within 30 days of the planned retention period. Destruction  is handled as follows:

▪ Papers to be shredded.

▪ CDs to be shredded.

▪ Backup tapes to be burnt.

▪ Sensitive data to be deleted through a program.

3.2. Disposal Procedure :-

• The PayFi is responsible for the retention and secure disposal of storage media and the  disposal of all information processing equipment is routed through his office. A log  Documents Data Transfer and Storage Request Form_v1 & Data Disposal Form_v1 is retained  showing what media were destroyed, disposed of, and when as required, the asset inventory  is adjusted once the asset has been disposed of.

• Any data, if any,directly or indirectly related to payment systems, accessed and/or stored  shall be stored and transferred within the Indian Geographical location only.

4. Network and Infrastructure Configuration Policy

4.1. Policy Statement

The Cash Friend Fintech Private Limited protects its networked services from unauthorized access,  ensuring that Network and Infrastructure equipment like firewalls, VPN, content filters, Servers,  Antivirus, Anti-Spam, and Intrusion Prevention Systems are in place.


• Authorization procedures are used to ensure that users only have access to those services  and networks which are appropriate for their role and to their business needs.

• Access control rules and rights to applications, expressed in standard user profiles, for each  user/group of users are clearly stated, together with the business requirements.

• The security requirements of each business application are determined by a risk assessment  that identifies all information related to the application and the risks to that information.

• Access is authenticated, including for individual users, applications, and administrators.

• All Extranet users have limited access.

• Restrict access based on a user’s need to know and is set to “deny all” unless specifically allowed the access rights to each application taken into account:

✓ The classification levels of information processed within that application and  ensure that there is consistency between the classification levels and access  control requirements across the [systems and] network(s),

✓ The “need to know” principle (i.e., access is granted at the minimum level necessary for the role),

✓ “Everything is generally forbidden unless explicitly permitted”,

✓ Enforcing rules that require specific permission before enactment,

✓ Any privileges that users actually need to perform their roles, subject to it being  on a need-to-use and event-by-event basis.

• The organization has standard user access profiles for common roles in the organization.

• Shared access to organization resources by way of shared passwords or group passwords are  explicitly prohibited.

• User access requests are subject to formal authorization and periodic review.

• The Intrusion Detection/Prevention system (IDS/IPS) must be used to monitor the cardholder  data environment. IDS/IPS must contain latest signature updates and also capable of alerting  the personnel in case of suspected activities

• Wireless access is not allowed in any part of the organization’s network.

• Management controls identify and procedures are used to protect access to network  connections and network services.

• User Groups and their responsibilities are as follows:

Group NameRole/ Responsibilities
Admin GroupAdministration and monitoring of the firewall and other  network components, such as routers/ switches
App Owner GroupApplication maintenance and rollout
Tech User GroupBack-end operations support, query management and  reporting

4.2. Configuration Policy

• Common Policy for Firewalls-Router-Switches: 

As per firewall hardening document v1.1

• Routers/Switches Policy:

✓ Routers/ Switches to be used explicitly for the purpose of routing and local  connectivity; and NOT for any sort of packet filtering or inspection.

✓ Router/Switch running configuration and startup configuration to be  synchronized with every change to the router/switch configuration. The  router/switch config to be backed up to an external location.

✓ Router Configurations to be reviewed half-yearly as per audit plan.

✓ These configuration standards apply when all new routers/core switches  are configured.

• Servers as per Linux configuration standard document v1.0

5. Technology UsagePolicy

5.1. Policy Statement

The use of PayFi information assets shall be governed by acceptable use standards and procedures  according to predefined levels of sensitivity and criticality for each asset, in order to avoid loss or  damage to PayFi and to promote compliance with applicable law and policies.

5.2. Objective

To provide guidance to employees on the proper use of PayFi computing resources, including use of the Internet and electronic mail.

5.3. Risk

• Employees can unknowingly compromise the security and integrity of PayFi information  and computing resources through the improper use of such resources.

• Any personal use of ComputingResources may result in significant added costs, disruption of  business processes, or any other disadvantage to the organization.

5.4. General Standards

• The PayFi requires that the procurement of all information processing facilities be subject to a formal authorization process in respect of information security. “Facility” is defined as  “any system(s) or device(s) that will be used to process or store organizational information or  that will connect to an organizational network or other information processing facility.” It  includes hardware, software and services.

• Critical employee-facing technologies just like critical network devices or cardholder data  processing applications must be featured with adequate authentication techniques. Proper  authentication techniques must provide and archive adequate information regarding  employee access to critical technologies.

• For critical systems, access rights matrices must be defined, documented, reviewed and  updated to ensure that only proper employees are granted access to critical systems and  information resources.

• Computer System is the property of the PayFi and is intended to be used predominantly for legitimate PayFi business. Only persons authorized by PayFi as “Users” may access PayFi Computer System and only to the extent that such access is required to assist them in the performance of their work. All Users shall use organization’s computer system in a 

professional, ethical and lawful manner.

• Users should use their respective locations and appropriate technology assigned by the  management based on the business requirement. Any deviations to this policy must be  approved by their Business Managers and IT Department.

5.5. Asset Control

• Only approved technology products must be used. A list of approved products must be  maintained and updated. Users are not allowed to install or use any software by their own.

• Users must NOT be granted access to PayFi systems and technologies prior to  management approval. Both the user’s manager and system owner must approve employee  access to critical systems especially those are holding cardholder data.

• Access to various assets should be authenticated, including for individual users, applications,  and administrators. Users are authenticated through an automated access control system  using unique ID and additional authentication (for example,a password) for access to the  cardholder environment.

5.6. Asset management

• PayFi maintains an inventory of information assets. This inventory should also be used in the  risk assessment process.

• For each asset, the PayFi must document sufficient information to identify the asset (type or category of asset, make or manufacturer, model, serial number), identifies the physical (or  logical) location of the asset, information security classification of each asset, for each asset,  and the security processes or controls (including access controls, backups, etc.) associated  with each asset and labels the assets. Assets are labeled having details like owner name,  contact details, location & purpose. For each asset, PayFi identifies the business unit or  business role that ‘owns’ the asset.

5.7. Access Control

• Modem/remote access sessions must be automatically disconnected after a specific period of  inactivity. Modems/remote access Technologies,used for vendor access to the organization  network, must only be connected when required and must be immediately disconnected  after use.

• When accessing cardholder data remotely, it must not be possible to store cardholder data  onto local hard drives, floppy disks, or other external media. Cut-and-paste and print  functions must be disabled during remote access.

• For vendors, access should be justified, temporary, and approved by the hosting  department’s manager, element’s business owner and IT Security Team. PayFi’s  concerned department along with Information SecurityTeam should review the users having external connections to the Organization’s network on a regular basis in order to disable any  unnecessary access. Action should be taken to remove or atleast disable any remote access  on access expiry date within one business day.

• A proper authentication and security of client systems is also maintained as per the security  policies and best practices.

5.8. Application Control

• Internet Access

Non-public information concerning PayFi, its customers, suppliers or employees may not be transmitted over the Internet unless it is first encrypted in a manner approved by PayFi  Information Security Office. Any information concerning sensitive data should not be traversed  over the Internet using an-encrypted channel.

• Software Download

Employees may download or use software derived from the Internet or other on-line sources  only in accordance with guidelines established by management and approved by Information  Technology and the Office of the Information Security Office.

• Email

✓ E-mail must be used for business communication only.

✓ Personal or free email account must NOT be used to transmit or receive  business information.

✓ Critical data must NOT be sent by email without encryption.

6. Key Management & Card Data Encryption Policy

6.1. Policy Statement

• Credit Card data whenever it occurs in conjunction with PAN must be encrypted. This is  applicable to all data stored including data on database, portable digital media, backup  media, in logs, and data received from or stored by wireless networks.

• Encryption of card data will be carried out using Symmetric Key Encryption: AES-GCM  symmetric encryption

• The MINIMUM account information that must be rendered unreadable is the PAN.

• Encryption Keys will be stored at AWS KMS.

• Cardholder data on removable media will be encrypted wherever stored.

• Native File System disk encryption will not be used to encrypt credit card data.

• Encryption keys used for encryption of cardholder data will be protected against both  disclosure and misuse by:

✓ Restricting access to keys

✓ Secure storage of KMS credentials

• Key management processes and procedures for keys used for encryption of cardholder data  will be documented and implemented for:

✓ Secure key credential storage

✓ Periodic key changes (at least Annually)

✓ Destruction of old keys.

✓ Replacement of known or suspected compromised keys

7. Audit Log and Monitoring Policy

7.1. Responsibilities

The Infra Department performs the risk assessment to identify the type and level of audit logging and  monitoring that might be required for each individual information asset.

Owners of individual assets are responsible for identifying and agreeing with the Information Security  Officer the logging and monitoring capabilities of the assets they own and for having them configured  to meet the requirements of the risk assessment.

The Data custodians are responsible for configuring the information systems to meet the  requirements of this policy. No cardholder data should be stored in any Log Files.

7.2. Audit logging and Monitoring system in use

Audit logs generated by system components for which user activity audit logging is configured should  be reviewed daily by the Information Security Team. The schedule/matrix of audit log requirements  and the audit log reports are classified as confidential information and are handled in line with the  requirements of ISMS policy for handling confidential information.

System administrators are prohibited from erasing or deactivating logs of their own activities.  Monitoring reports are reviewed daily by the Information Security Team Any evidence of system  misuse is reported to the Information Security Officer who investigates further, and the disciplinary  process may be invoked.

7.3. Protection of loginformation

The Log machine is configured and installed on a segregated network and protected by a firewall. No  direct access to the backend database holding the audit logs is allowed.

Administrators are prohibited from disabling logging activity; disabling audit logs or tampering with  audit log information is treated as a serious offense.

All logs must be protected from tampering by all users including Administrators.

7.4. Administrator and operator logs

Audit logs generated by servers/systems/devices must also contain administrator/operator activities.  System administrators are prohibited from erasing orders activating logs of their own activities.

Logs are to be stored online for a minimum period of 3 months; and offline for a minimum period of 1  year.

The schedule/matrix of activity log requirements and the log reports are classified as confidential  information and must be handled in line with the requirements of ISMS policy for handling  confidential information.

7.5. Fault logging and Format of Audit Trails

Audit logs generated by servers/systems/devices must also contain the capability to indicate error  and fault logging.Specifically:

• All actions taken by any individual with root or administrative privileges. • Access to all audit trails

• Invalid logical access attempts

• Use of identification and authentication mechanisms

• Initialization of the audit logs

• Creation and deletion of system-level objects

The audit trail entries for all system components must record the following

• User identification

• Type of event

• Date and time

• Success or failure indication

• Origination of event

• Identity or name of affected data, system component, or resource

7.6. Clock synchronization

The clocks of production environment information systems within Cash Friend Fintech Private  Limited are synchronized using an external NTP Server. The permitted protocol in Cash Friend Fintech  Private Limited is NTP 3.0 or later version. The external NTP Server that provides accurate, reliable, and secure time  synchronization feeds to an Internal NTP Server which further pushes to all internal production  Servers.Access to time data is restricted to only personnel with a business need to access time data.  Any changes to time settings on critical systems are logged, monitored, and reviewed. Central Time  servers accept time updates from specific, industry-accepted external sources

The clocks on all servers and all Organizational information processing devices are checked on a  regular basis and corrected where necessary.

7.7. Log Management

All log monitoring systems are placed in a segregated network and protected by the firewall. No  direct access to the backend database holding the audit logs is allowed. Logs are stored online for a  minimum period of 3 months; and offline for a minimum period of 1 year.

Only individuals who have a job-related need can view audit trail files after written authorization from  the Management. No generic ids, only unique ids with specific roles with job related needs are  configured on log machines.

File integrity monitoring or change detection software for logs are in place by examining system  settings and monitored files and results from monitoring activities.

7.8. Audit Log Requirements

Following are the Audit log requirements:

• Audit logging must be enabled on system where Cardholder data is processed.

• Audit logs must capture all individual access; all root and administrative actions must be  logged.

• All failed and invalid login attempts must be logged.

• The identification or authentication mechanism used to provide access to a user to  cardholder environment must be logged.

• Initialization of audit logs must be logged.

• Creation of system level objects must be logged.

• Logs must include user identification, date, time, type of event, success or failure indicator,  origination of the event and identity or name of affected data, system component, or  resource.

• Access to the audit trail must be restricted to only individuals who have a job related need to  view audit trail files.

• All access to the audit trail must be logged.

• Audit log files must be protected from unauthorized modifications using physical separation  or access control.

• Audit trail files must be promptly backed up to a centralized log server or media that is  difficult to alter.

• Audit logs for external-facing technologies (firewalls and routers) must be offloaded or copied  onto a secure centralized internal log server or media.

• File integrity monitoring or change-detection software must be used for logs for examining  system settings and monitored files and results from monitoring activities.

• Audit logs must be available for atleast one year and processes must be in place to restore at least the last three months’ logs for immediate analysis.

7.9. File Integrity Monitoring

File integrity monitoring solution captures key attributes for all detected changes across a broad range  of IT infrastructure and applications. Files monitored may include registry files, configuration files,  executables, file and directory permissions, tables, indexes, stored procedures, etc.

Following must be monitored:

• Windows File SystemAttributes

• Unix File System Attributes

• Windows RegistryAttributes

• Database Attributes

• Network Device Attributes

• Log files attributes

8. Patch Management and Malicious Code Prevention Policy

8.1. General Guidelines

All system components running various software and applications in PayFi should have the latest  vendor-supplied security patches installed. PayFi acts to protect the integrity of its software and  other information assets against the introduction of malicious code (malware).

• UnauthorizedSoftware should not be transferred or downloaded onto theOrganization’s  network via or from external networks, or on any medium (including CD-ROMs, USB sticks).  The standard build for workstations must disable disk and CD-ROM drives, and USB ports.

• Monitoring, detecting and deleting unauthorized software is a requirement of the  information system, and disciplinary action is to be taken against anyone in breach of the  anti-malware policy. Periodic automated scans of all desktops and servers are conducted by  the Anti-malware software.

• The organization will deploy anti-virus software on all systems commonly affected by viruses  (particularly personal computers and servers)

• Persons responsible for patch management must subscribe to alert services freely available  on the internet.

• All users are required to accept, in terms of their User Agreements, “Technology Usage  policy” and to receive appropriate training in detecting and responding to virus/malware  attacks,and to accept specific anti-malware prevention controls in their UserAgreements.

8.2. Inventory of Assets Covered in the Policy

• Network Components (Firewall, Routers, IPS/IDS etc.)

• Linux/Windows Servers

• Application Servers

• Databases

8.3. Policy Controls

• Requirement for Latest Patch

All system components and software in the organization will have the latest vendor-supplied  security patches installed.

• Patch Management Process

Organizations must receive updates from vendors from time to time for new security patches  released. The available patches are installed as per Patch Management Procedure doc.

• Patch Installation Timelines

All relevant security patches must be installed within 30 days (one month) of release.

• Security Patch Testing Requirements

All security patches must be tested before being deployed into production. Person(s)  responsible for Patch Management should test the patches in a test setup before deploying  to a production environment.

• New Vulnerability RiskRanking

New vulnerabilities must be identified with updates from external industry sources, known  security forums etc. and the vulnerability should be assigned a Risk Ranking. Risk rankings  should be based on industry best practices, like adhering to the CVSS scoring system for the  risks.

• Anti-Virus Deployment

Antivirus/Anti-malware software is installed on all Organizational information systems and  devices, including gateways and firewalls. The Antivirus/Anti-malware software installed on  the gateway(s) conducts automated scans of all attachments and deletes or quarantines  suspect files.The anti-virus software would be actively running all the time,and would be  capable of generating alerts.

✓ All servers and workstations must have the latest release of antivirus software  installed.

✓ Antivirus signatures must be updated regularly. The updates would be  distributed to allclients.

✓ All the servers and workstations are to be centrally administered and controlled  on a daily basis.

✓ The anti-virus programs would be capable of detecting,removing,and protecting  against other forms of malicious software, including spyware and adware.

✓ The anti-virus software and its definitions should be regularly updated.

The installation and maintenance of anti-malware software on all Organizational information  systems and devices is mandatory.

• Anti-virus Log

The anti-virus program would be capable of generating audit logs. The logs should be  retained for at least 1 Year.

9. Application DevelopmentPolicy

9.1. Policy Statement

• There must be separate Development, Test and Production environments.

• There must be proper and defined segregation of duties between personnel assigned to  development/test environment and personnel assigned to production environment.

• Production data must not be used for testing and development, or must be sanitized before use.

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

• Custom application accounts, usernames and/or passwords must be removed before system goes into production or is released to customers.

• Custom Code reviews must be performed by individuals’ other than originating code authors  prior to release to production or customers in order to identify any potential coding  vulnerability.

• Code reviews for custom software development, aspartoftheSystem Development Life  Cycle (SDLC) can be conducted by internal personnel.

• Change control procedures must be followed for all system and software configuration  changes.

• For each change there must be management sign-off by appropriate parties.

• Operational functionality testing must be performed for each change.

• Back-out procedure must be defined for each change.

• All web applications must be developed based on secure coding guidelines such as the Open  Web Application Security Project (OWASP) Guidelines. This is to prevent common coding  vulnerabilities in software development processes.

• Security training for every fresher

• All web-facing applications must be protected against known attacks by either of the  following methods:

✓ Having all custom application code reviewed for common vulnerabilities by an  organization that specializes in application security or

✓ Installing an application-layer firewall in front of web-facing applications.

10. Information Classification Policy

10.1. Policy Statement

Data and information classification is the conscious decision to assign a level of sensitivity to data as it  is being created, amended, enhanced, stored or transmitted. The classification of the data should  determine the extent to which the data needs to be controlled/secured and is also indicative of its  value in terms of Business Assets.

This policy ensures that information receives an appropriate level of protection by defining  classification levels, and fixing responsibilities of concerned people for information classification,  protection, and handling.

10.2. Policy Details

• Information shall be classified in the terms of its value, legal requirements, sensitivity, and criticality to the organization.

• Proper information classification shall be the responsibility of concerned Information owners.

• Proper protection and handling of information shall be the responsibility of all employees,  third-party personnel, contractors and service providers

• Information Owner(s) shall assign one of the following four classifications to any information  asset under their control:

✓ Level I – Public: Information in public knowledge and can be shared with  outsiders also. (All generally available information.) Shredding of this information is not required for disposal.

✓ Level II – Restricted: To be shared within PayFi groups only. (e.g. – Customer  information; Security policy, procedure, and standards; departmental Work  Procedures etc). Sharing of specific documentation is allowed upon explicit  written authorization of PayFi Management.

Shredding of this information for disposal is desired but not required.

✓ Level III – Confidential: To be kept within the specific group or set of persons  handling the matter only. (e.g. – Legal Agreements, Customer Confidential  Information, Technical configuration and specifications, Network usage and  access rules; procurement related matters etc.)

Shredding of this information for disposal is required

✓ Level IV – Sensitive: All information that is kept within the purview of a few  limited senior officials and authorized persons only. (e.g. – Cardholder data like  PAN).This information is not authorized to be stored on any computer system  except for servers, desktop or laptop systems. When stored on servers, desktop  or laptop systems the information will be encrypted, using approved encryption  software, to provide adequate protection. Additionally, this information will not  be transmitted over any computer network within or between PAYFI facilities  unless it is encrypted, using approved encryption software. If this information is stored on removable storage media, then such items should  be properly identified and stored in a locked desk drawer, cabinet or safe when  not in use.

Shredding of this information for disposal is required

Guidelines for Information Classification, handling, and labeling shall be developed and  implemented to help Information owners and other stakeholders to execute their  responsibilities.

• Information Labeling

Information owners and originators must ensure that information created by them is labeled  appropriately.

✓ All hardcopy information must be labeled as per the above classification  standard.

✓ All electronic information should be labeled where provision exists as per  classification.

✓ Any information transformed from soft copy to hard copy must be labeled as per  the classification either automatically or manually to facilitate recipients for  information handling and protection

• Information Handling

✓ Usage of information should be strictly on authorized to know basis. ✓ Sensitive, Confidential and Restricted information should be stored in a secure  manner.

✓ Sensitive, Confidential and Restricted information shall not be shared with third  party personnel’s users without executing Confidentiality/ Non-Disclosure  Agreement.Only relevant information as required for the engagement of third  party shall be shared with due authorization.

✓ The information should be destroyed after use/end of life as per disposal  procedure having sought approval from the information owner.

✓ Proper access controls and privilege levels are to be set before accessing  sensitive cardholder data by any user internally. Media containing sensitive data  shall only be distributed to the authorized in-house employees.

✓ All applications and network hardware equipment which are accessible to the  external parties and which transmit or deal with sensitive cardholder data should  be protected by strong access control and authentication mechanisms.

✓Media containing sensitive data must not be handed over to any external entity  or third party unless until authorized by the management with proper business  justification.

✓ Computer output,regardless of media, which is classified in accordance with this  classification scheme will be marked on the top and bottom of each page and/or  on each output screen with the appropriate classification, except for the General  classification, when it is created by the system.

• Information Classification Responsibilities

✓ Employee Responsibilities:

▪ Understand the guidelines referred by this policy and handle all  information in accordance with this policy and guidelines.

▪ Immediately report an accidental or malicious breach of this policy to the  reporting office of Cash Friend Fintech Private Limited.

✓ Management Responsibilities:

▪ Communicate this policy and ensure that employees and third parties receive appropriate training regarding this policy.

▪ Ensure compliance with this policy.

✓ Information Owner Responsibilities:

▪ Ensure that the information they are responsible for is properly 


▪ Periodically review and assess information classifications and adjust as  required.

11. Vulnerability ManagementPolicy

11.1. Policy Details

• Cash friend Fintech Private limited should act to protect the integrity of its software applications and  its other information assets against the introduction of malicious code (malware).

• Periodic Vulnerability assessment of its information assets, network equipments and applications have to be conducted and fix all gaps found during the assessment.

• On a quarterly basis Internal and External security testing of the devices in the cardholder environment are conducted. Scans are repeated until “clean results” are obtained.

• The organization uses the servicesofAgency (Approved by PCI for performing the scans)”for  external scanning on a quarterly basis in accordance with the PCI Security Scanning  Procedures.

• Any major change in the IT environment must be followed by vulnerability assessment and  penetration testing to the setup. These penetration tests conducted on Annual basis:

✓ Network Layer PenetrationTests.

✓ Application Layer Penetration Tests.

• ThePenetration tests must be carried out either byThird party organization specialized in  Security Testing or by specialized internal resource.

• WirelessNetwork scan are performed using on quarterly basis.The methods used to conduct  the wireless scans should be adequate and capable of at least identifying the following:

• WLAN cards inserted into system components

• Portable wireless devices connected to system components(for example,byUSB,etc.) • Wireless devices attached to a network port or network device

• System File Integrity Monitoring must be done on all critical servers in the production  environment and servers storing Cardholder information.

• The IT Team must visit popular website sources such as SANS.org, CERT.org and CI Security.org to identify any other patches or modifications to the systems in use to make  them more reliable and secure.

• Identified vulnerabilities for Organizational assets are to be prioritized by Impact and  Probability.

• The Cash Friend Fintech Private limited must establish the following timeline requirements for reacting to notifications of relevant vulnerabilities:

ImpactPriorityNo. of days
Urgent53 Days
Critical45 Days
High31 week
Medium21 month

Note: Critical or Major risk systems are treated ahead of other systems.

• All vulnerabilities that fall into the high impact category must be assessed for seriousness and  required controls (patching; turning off/removing services affected by the vulnerability;  adapting or adding access controls;increased monitoring; awareness raising).

• If the vulnerabilities are high impact and high probability then the required controls must be  performed through the Change Management Procedure or else through the Incident  Response Plan.

• Available patches must be risk assessed, considering the balance between risks in installing  and not installing,before the final decision as to necessary controls can be made.

• Patches must be tested prior to implementation in the production environment.

11.2. Responsibilities

The Infra department is responsible for monitoring vulnerabilities and vendors’ releases of patches and fixes and installing operational software updates, patches and fixes on the operational systems.

The Application Owners are responsible for testing operational software updates and new  implementations. The Information Security department will discuss with the Infrastructure Department  any incidents that have occurred, including the vulnerabilities, information additional controls  are in place, what outstanding issues there are, and how the picture has changed since the previous  scan.

12. Application SecurityStandard

12.1. General Application DevelopmentStandards

• Data Validation

✓ Use of invalidated input in the output stream

Ensure that all parameters (including input in SQL statements) are validated  before they are used. A centralized component or library is most effective, as the  code performing the checking must all be in one place. Each parameter must be  checked against a strict format that specifies exactly what input will be allowed.

“Negative” approaches that involve filtering out certain bad input or approaches  that rely on signatures are not likely to be effective and may be difficult to  maintain. Parameters must be validated against a “positive” specification that  defines:

▪ Data type (string, integer, real, etc.)

▪ Allowed character set

▪ Minimum and maximum length

▪ Whether null is allowed

▪ Whether the parameter is required or not

▪ Whether duplicates are allowed

▪ Numeric range

▪ Specific legal values (enumeration)

▪ Specific patterns (regular expressions)

✓ Client and Server-side validation

User input validation must be done both at client and server side. From security  perspective, Server-side validation is a must. Client-side validation can be easily  bypassed by turning off JavaScript in the browser. Hence applications must be  configured such that they do not rely upon client-side validation.

✓ Scanning of files before uploading

Files must be scanned for security vulnerabilities before uploading it or using it  for any purpose.

✓ Output validation

Data output from an application must be validated to ensure that the processing  of stored information is correct and appropriate to the circumstances.

✓ Validation Checks

Validation checks must be incorporated into applications to detect any  corruption of information through processing errors or deliberate acts.

• Authentication

✓ Use of strong user passwords

The usernames and passwords must conform to the organization standard. The  application must have 6-character alphanumeric User passwords and 8  characters alphanumeric privilege Id’s passwords. This must be a parameter  setting. For highly sensitive Internet facing applications strong two factor  authentication must be deployed.

✓ Communication of username and password in clear text

Usernames and passwords must be hashed or encrypted at storage as well as  before passing them over the network for authentication purposes.

✓ Restricting maximum number of failed attempts

The application must have an in-built feature to lock the user account after a  maximum number of failed attempts. This must be a parameter setting.

✓ Changing of password at regular intervals

The application must enforce the users to change the passwords periodically. In  addition, the users must not be allowed to use the previous passwords. Both  these must be parameter settings.

✓ New password forcechange

The users must be forced to change their passwords at the time of first login  attempt.

✓ Password change history

Theapplicationmustretainpasswordhistoryandmustnotallowuserstokeep  old passwords. This must be a parameter setting.

✓ Password masking

Passwords must be masked as they are being typed during authentication or  password change(topreventunauthorizeddisclosureofpasswordbysnooping).

✓ User triggered password change

The application must provide a “Password Change” option, to allow users to  change their passwords on their own without requiring intervention by system  administrators.

✓ User password change process

Passwords must be changed only on the correct entry of the current password. The  system must prompt for the current password and allow a change only provided  that it is authenticated. The new password must be entered twice before a  successful password change.

✓ Logon failure message

In the event of login failure due to either in correct user-id or password, a generic  message such as “Login Failure” must be displayed and not a specific message  such as “Incorrect user-id” or “Incorrect password”. No help must be provided in  the form of messages specific to the inaccurate credential.

✓ Temporary disabling of ID’s

The application must have a provision for the system administrators to  temporarily disable / re-enable user-ids.

✓ User-ids created must always be unique

There must be application-level controls to ensure that duplicate user-ids cannot  be created.

✓ Last login details

Upon successful login, the last login time and date of the user-id must be  displayed.

✓ Successful login message

The application must display standard login message that”Unauthorized use of  the PayFi applications is prohibited” after logging in or at the time of  unsuccessful access attempts.

✓ Business Time

There must be a setting to configure the working times of the user’s login on the application.

• Authorization

✓ Access to the application on need-to-know basis and role based as per Security  Matrix

Role based authorization mechanism must be used for allocating privileges to the  users. The application must have the provision to define different levels of users  or roles. Users must not have privileges to the features which he does not  require for his job responsibilities.

Use the access control matrix to define the access control rules. The security  matrix must document what types of users can access the system,and which  functions and content each of these types of users must be allowed to access.  The access control mechanism must be extensively tested to be sure that there is  no way to bypass it. This testing requires a variety of accounts and extensive  attempts to access unauthorized content or functions. The roles must have  segregation of duties such that an individual must not be responsible for more  than one of the following duties: business, data entry, computer operation,  network management, system administration, systems development, change  management, security administration, security audit. Ex: The user admin team  roles must not have access to process or view business data and vice versa. The security matrix must be automatically generated by the application and available  for review when required.

✓ Application access to the database with the drop and delete permissions Applications must not have privileged access to the database unless and until  there is a strong business justification for the same which is defined, 

documented and approved.

✓ Partitioning of theApplication

The application must be partitioned into areas like publicly accessible, controlled  areas or restricted areas on the basis of the sensitivity of the features and  information stored in the applications. Appropriate authentication mechanisms  must be implemented from each area and the flow from one area to the other  area must not be permitted without appropriate authentication.

✓ Connection to the database

The application must connect to the database with minimum level of privileges  required by the application.

• Provisioning & Reporting

✓ Maker / Checker for access administrations

There must be a maker-checker principle at the application level for  creation/approval of user-ids. A user who has created a user-id must not be  allowed to approve the creation.

✓ Different states of User ID

The user-ids in the system must have the following states

Active Live and active users. Disabled Disabled users who are temporarily barred from login. Locked Users locked out due to unsuccessful login attempts. Deleted Users who have been deleted from the system which cannot be activated or recreated again.

✓ Reports

The application must have a report on security events. The following reports  must be generated from the system and reviewed:

▪ Unsuccessful login attempts

▪ User sign on/signoff

▪ Privilege change activity

▪ Dormant User-IDs clearly mentioning the date of last sign-on

▪ Activities carried out by system administrator

▪ Access admin activity performed by users with privileged User-IDs

▪ Any change in master data

▪ Department-wise user listing with access rights

▪ List of user-ids created/modified/disabled at the end of every day.

✓ User ID Expiry field

There must be a user-id expiry field available which must be an optional field and  theuseridsmustbeflaggedasdisabled,once the expiry date is reached.

✓ User ID classification

The application must have a provision to choose the”type”of user/category of  user for whom the user-id is being created.

✓ Dormant UserIDs

The application must enforce the following controls:

▪ The application must provide a feature to define maximum acceptable  period of user inactivity, is 90 days, for the user-ids which have been  used at least once after being created.

▪ The application must provide a feature to define maximum acceptable  period of user inactivity, is 30 days, for the user-ids which have never  been used since these were created.

▪ After observing inactivity for more than the defined maximum  acceptable period of inactivity the application must deactivate the  unused user-id. This must be a parameter setting.

• Sensitive Data and Data Encryption

✓ Use of Vulnerable protocols

Sensitive data (for example user credentials, financial transaction data, credit  card numbers) must not be passed over the network in plain text. The encryption  protocols/algorithms must be in accordance with the PayFi.’s prescribed  encryption standard.

✓ Use of cookies

The confidential information (for example user credentials or customer private  data) must not be stored in the cookies. If the use of cookies is required then the  data must be stored in the cookies only after encryption as per organization’s  prescribed encryption standard.

✓ Masking of input fields

Form fields for sensitive data like passwords, CVV/CVC numbers etc. must be  masked so that it is not visible in cleartext while entering data in the field.

✓ Caching of securedata

HTTP expires must be used for web-based applications to avoid caching of web  pages with sensitive data.

✓ Password Encryption

Passwords must be encrypted while being transmitted over the network.

• Session Management

✓ Security of session identifiers

The session identifier must not be stored on client side or passed through the  network in an unencrypted format.

✓ Limiting number of sessions

The user must be allowed to have only one session at a time. If the user attempts  to initiate a new session, he must be given a warning message saying that he  cannot initiate a session since a session is already existing for that user. This will  give a warning to the user if his account is being misused or compromised.

✓ Validation of session identifiers

Session identifiers must be validated at the time of every request by the server to  verify that the requesting user is an authenticated user.

✓ Session timeout

Inactive sessions must shut down after a 30 min of inactivity at max. • Cryptography

✓ Encryption Algorithm

Use of encryption algorithms must be consistent with the Organization  prescribed encryption standard. Use of custom algorithms is not allowed.

✓ Key Management

▪ The keys must be of minimum 128 characters long.

▪ The keys must be a combination of alphanumeric characters.

▪ In addition, a new key must be generated for every session.

▪ Appropriate random number generator must be used for the creation of  the keys.

▪ Keys must be distributed in a secure manner.

▪ Same keys must not be used for a prolonged period of time.

• Exception Management

✓ Details of Exception

Stack trace must not be displayed to the client as a part of an error/warning  message. A comprehensive list of error messages that a client must get during  any kind of exception must be documented.

✓ Logging of Exceptions

Faults and exceptions must be logged, analyzed, and appropriate action must be  taken.

• Auditing and Logging

✓ Audit LogReports

Security Logs must have following parameters:

▪ Login/Logout success/failure

▪ Attempt to login outside of defined working hours

▪ Access to critical services/application processes vizEOD/SOD

▪ Access to critical resources viz:controlled files storing business sensitive  data (customer data,financial data etc.), directories or other resources

▪ Critical user activities viz: creation, deletion, modification on sensitive  business data

▪ Unauthorized access-controlled files, directories or other resources. ▪ Failure of any critical application service

✓ User Admin logs

▪ Admin logs must have the following information:

▪ Creation of a user profile

▪ Deletion of a user profile

▪ Renaming of a user profile

▪ Modification of user profile access rights

▪ Change to user profile password characteristics

✓ Security ofLogs

Logging facilities and log information must be protected against tampering and  unauthorized access.

✓ Minimum information to capture audit logs

The audit logs must include the following information:

▪ Transaction ID

▪ User-id

▪ Content of fields before the event

▪ Action applied

▪ Value of new fields (if applicable)

▪ Date and time of day

▪ IP address

▪ MAC address

✓ Audit Log protection

Access to the application module which allows enabling/disabling of audit logs  must be appropriately restricted.

✓ Hardening of Web Server, Application Server and DB Server

The operating systems on which the web server, application and database is  loaded must be configured securely.

✓ Use of peripheraldevices

The devices like infrared,Bluetooth and wireless devices must not be enabled on  the server unless required.

✓ Unnecessary Network services

Services like FTP, Telnet, IMAP, POP3 etc. must not be enabled on the server  unless required for business purposes. Also, the services which are not required  for business purposes must be disabled.

✓ Test data must be appropriately secured

Access to the test environment must be controlled. The test data must be  secured.

• Application Architecture

Client/server applications design must have 2-tier architecture. Architecture must have an application and database on separate hardware. If the application server is accessible from the internet, then the application server should be placed in the DMZ and the database server must be  protected by a firewall. Access to database server shall be restricted only to the application  server through firewall on ports specified by the application owner.

• Code Management

✓ Storing confidential data in code

Sensitive information like passwords, credentials etc. must not be hard coded in  the application.

✓ Source Code Protection

The source code must not be placed in public folders where it is available to  everyone.Access to the source code must be provided only to the authorized  users.

✓ Source Code Changes and Reviews

Code changes are reviewed by individuals other than the originating code author,  and by individuals who are knowledgeable in code review techniques and secure  coding practices. Appropriate corrections are implemented prior to release. Code  review results are reviewed and approved by management prior to release.

12.2. Secure Programming Standards for Web Apps

• Web based Technologies

✓ Use of invalidated input in the output stream

Internet facing web-based applications should be designed on 3-tier architecture  with web server, application server and database server separate. Only web  servers should be placed in the DMZ. Application and Database server shall always  be on separate internal server segments protected by a firewall. Access to the database server shall be restricted only to the application server through a firewall on  ports specified by the application owners.

Exceptions for applications for 2 tier architectures with Web server and  Application server on same hardware must be approved by IT Architecture Team  or IT Management

✓ Access Control

Insecure Id’s – Most websites use some form of id, key, or index as a way to  reference users,roles, content, objects, or functions.If an attacker can guess  these ids,and the supplied values are not validated to ensure they are authorized  for the current user, the attacker can exercise the access control scheme freely  to see what they can access.Web applications must not rely on the secrecy of  any ids for protection.

ForcedBrowsingPastAccess ControlChecks – Many sites require users to pass  certain checks before being granted access to certain URLs that are typically  ‘deeper’ down in the site. These checks must not be bypassed by a user that  simply skips over the page with the security check.

Path Traversal – This attack involves providing relative path information (e.g.,  “./../target Dir/target file”) as part of a request for information. Such attacks try  to access files that are normally not directly accessible by anyone or would  otherwise be denied if requested directly.Such attacks can be submitted in URLs  as well as any other input that ultimately accesses a file (i.e., system calls and  shell commands).

File Permissions – Many web and application servers rely on access control lists  provided by the file system of the underlying platform. Even if almost all data is  stored on back-end servers, there are always files stored locally on the web and  application server that must not be publicly accessible, particularly configuration  files, default files, and scripts that are installed on most web and application  servers. Only files that are specifically intended to be presented to web users  must be marked as readable using the OS’s permissions mechanism, most  directories must not be readable, and very few files, if any, must be marked  executable.

Client-Side Caching – Many users access web applications from shared  computers located in libraries, schools, airports, and other public access points.  Browsers frequently cache web pages that can be accessed by attackers to gain  access to otherwise inaccessible parts of sites. Developers must use multiple  mechanisms, including HTTP headers and Meta tags, to be sure that pages  containing sensitive information are not cached byuser’s browsers.

✓ Authentication and Session Management

Careful and proper use of custom or off the shelf authentication and session  management mechanisms must significantly reduce the likelihood of a problem  in this area. Defining and documenting site’s policy with respect to securely managing user’s credentials should be done. Ensuring that implementation  consistently enforces this policy is key to having a secure and robust  authentication and session management mechanism.

Some critical areas include:

Password Storage – All passwords must be stored in either hashed or encrypted  form to protect them from exposure, regardless of where they are stored  (Hashed form is preferred since it is not reversible). Encryption must be used  when the plaintext password is needed, such as when using the password to  login to another system. Passwords must never be hardcoded in any source  code. Decryption keys must be strongly protected to ensure that they cannot be  grabbed and used to decrypt the password file. Protecting Credentials in Transit

The only effective technique is to encrypt the entire login transaction using  something like SSL. Simple transformations of the password such as hashing it on  the client prior to transmission provide little protection as the hashed version can  simply be intercepted and retransmitted even though the actual plain text  password might not be known.

Session IDProtection –User’s entire session must be protected viaSSL. If SSL is  not viable for performance or other reasons than session IDs themselves must be  protected in other ways. First, they must never be included in the URL as they  can be cached by the browser, sent in the referrer header, or accidentally  forwarded to a ‘friend’. Session IDs must be long, complicated, random numbers  that cannot be easily guessed. Session IDs can also be changed frequently during  a session reduce how long a session ID is valid. Session IDs must be changed  when switching to SSL, authenticating, or other major transitions. Session IDs  chosen by a user must never be accepted.

AccountLists – Systems must be designed to avoid allowing users to gain access  to a list of the account names on the site. If lists of users must be presented, it is  recommended that some form of pseudonym (screen name) that maps to the  actual account be listed instead.

Browser Caching – Authentication and session data must never be submitted as  part of a GET;POST must always be used instead. Authentication pages must be  marked with all varieties of the no cache tag to prevent someone from using the  back button in a user’s browser to back up to the login page and resubmit the  previously typed in credentials. Many browsers now support the  autocomplete=false flag to prevent storing of credentials in autocomplete  caches.

Trust Relationships – Site architecture must avoid implicit trust between  components whenever possible.Each component must authenticate it self to any  other component it is interacting with unless there is a strong reason not to  (such as performance or lack of a usable mechanism). If trust relationships are  required, strong procedural and architecture mechanisms must be in place to ensure that such trust cannot be abused as the site architecture evolves over  time.

✓ Cross site Scripting (XSS) flaws

The best way to protect a web application from XSS attacks is ensure that the  application performs validation of all headers, cookies, query strings, form fields,  and hidden fields (i.e.,all parameters) against a rigorous specification of what  must be allowed. The validation must not attempt to identify active content and  remove, filter, or sanitize it. There are too many types of active content and too  many ways of encoding it to get around filters for such content.

Encoding user supplied output can defeat XSS vulnerabilities by preventing  inserted scripts from being transmitted to users in an executable form.  Applications can gain significant protection from JavaScript based attacks by  converting the following characters in all generated output to the appropriate  HTML entity encoding:

From To

< &lt;

> &gt;

( &#40;

) &#41;

# &#35;

& &#38;

✓ Buffer Overflows

Keep up with the latest bug reports for all We band Application server products  and other products in the Internet infrastructure. Apply the latest patches to  these products. Quarterly scan all websites with one or more of the commonly  available scanners that look for buffer overflow flaws in server products and  custom web applications.

For all custom application code,review all code that accepts input from users via  the HTTP requestand ensure that it provides appropriate size checking on all  such inputs. This must be done even for environments that are not susceptible to  such attacks as overly large inputs that are uncaught may still cause denial of  service or other operational problems.

✓ Injection Flaws

To protect against injection is to avoid accessing external interpreters wherever  possible. For many shell commands and some system calls, there are language  specific libraries that perform the same functions. Using such libraries does not  involve the operating system shell interpreter, and therefore avoids a large  number of problems with shell commands.

For those calls still needed to employ,such as calls to back-end databases, carefully  validate the data provided to ensure that it does not contain any malicious  content. The use of stored procedures or prepared statements will provide significant protection, ensuring that supplied input is treated as data. These  measures will reduce, but not completely eliminate the risk involved in these  external calls. It must always validate such input to make sure it meets the  expectations of the application in question.

Another strong protection against command injection is to ensure that the web  application runs with only the privileges it absolutely needs to perform its  function. PayFi must not run the web server as root or access a database as  DBADMIN. Some of the J2EE environments allow the use of the Java sandbox,  which can prevent the execution of system commands. If an external command  must be used, any user information that is being inserted into the command  must be rigorously checked.

Mechanisms must be put in place to handle any possible errors, timeouts, or  blockages during the call. All output, return codes and error codes from the call  must be checked to ensure that the expected processing actually occurred.

✓ Insecure Storage

The easiest way to protect against cryptographic flaws is to minimize the use of  encryption and only keep information that is absolutely necessary. For example,  rather than encrypting credit card numbers and storing them, simply require  users to re-enter the numbers. Also,instead of storing encrypted passwords, use  a one-way function, such asSHA-1, to hash the passwords.

If cryptography must be used, choose a library that has been exposed to public  scrutiny and make sure that there are no open vulnerabilities. Encapsulate the  cryptographic functions that are used and review the code carefully. Be sure that  secrets, such as keys, certificates, and passwords, are stored securely. To make it  difficult for an attacker, the master secret must be split into atleast two locations  and assembled at runtime. Such locations might include a configuration file, an  external server, or within the code itself.

✓ Denial ofService

As a general rule, limit the resources allocated to any user to a bare minimum.  For authenticated users, establish quotas so that the amount of load a particular  user can put on the system can be limited. Consider only handling one request  per user at a time by synchronizing on the user’s session. Drop any requests that system is currently processing for a user when another request from thatuser  arrives.

For unauthenticated users, system architecture must avoid any unnecessary  access to databases or other expensive resources. Architect the flow of the site  so that an unauthenticated user will not be able to invoke any expensive  operations. Cache the content received by unauthenticated users instead of  generating it or accessing databases to retrieve it. Check error handling scheme  to ensure that an error cannot affect the overall operation of the application.

✓ Improper error handling

A specific policy for how to handle errors must be documented, including the  types of errors to be handled and for each, what information is going to be  reported back to the user, and what information is going to be logged. In the  implementation, ensure that the site is built to gracefully handle all possible  errors. When errors occur, the site must respond with a specifically designed  result that is helpful to the user without revealing unnecessary internal details.  Certain classes of errors must be logged to help detect implementation flaws in  the site and/or hacking attempts.

Appendix A – Application Security Standard Checklist

1. User Names   
2. Passwords   
1. Encryption   
2. Storage of Credentials   
3. Protection of Sensitive Information   
1. Cross Site Scripting (XSS)   
2. Injection Flaws   
3. Malicious File Execution   
4. Insecure Direct Object Reference   
5. Cross Site Request Forgery (CSRF)   
6. Information Leakage and Improper Error  Handling   
7. Broken Authentication and Session  Management   
8. Insecure CryptographicStorage   
9. Insecure Communications   
10. Failure to Restrict URL Access   
1. Static fields   
2. Reducing Scope   
3. Public Methods/Fields   
4. Protecting Packages   
5. Protecting Against Package-Access   
6. Immutable Objects   
7. Reference to an Internal Array   
8. Storage of User Given Arrays   
9. Serialization   
10. Sensitive Information   
1. Validity   
2. Unix “System()” Call   
3. scanf   
4. setuid   
5. Setuid Shell Scripts   
6. Root Privilege   
7. Valid Returns   
1. Separation of Business Logic   
2. Workflow Management Processes   
3. Technology   
4. Scalability   
5. Extensibility   
6. Performance   
7. Reliability   
8. Long Term Viability   

13. Incident ManagementPolicy

13.1. Policy Statement

The policy will ensure that a consistent and effective approach is applied to the management of  information security incidents occurring in Cash Friend Fintech Private limited, and to ensure information security events and weaknesses associated with information systems  are communicated in a manner allowing timely corrective action to be taken.

13.2. Policy Details

• A comprehensive Security Incident Response Plan shall be implemented for PAYFI in  order to respond immediately to security incidents.

• Roles, responsibilities, and communication and contact strategies in the event of a security  incident shall be formulated.

• Security incidents will be classified according to incident categories and severity of incident.  Incident response will be based on classification.

• Incident Reporting, Logging, Escalation and Handling procedures shall be established,  documented, and distributed to ensure timely and effective handling of all incidents.

• An internal Security Incident Response Team shall be established in PAYFI for handling of  security incidents. This team shall communicate with external bodies such as Credit Card  brands like VISAand CERT-In (Govt. of India) in respect of all incidents.

• All employees and third-party personnel shall be made aware of their responsibilities to  report any information security events as quickly as possible.

• The incident response plan must be tested at least once annually. All testing results must be  documented, and the incident response plan must be changed depending on the testing  results.

• There should be designated security personnel/team who should be available 24/7 to  respond to unauthorized activity, critical IDSalerts, and/or reports of unauthorized critical  system or content file changes.

• A list of contact information of the incident response personnel should be maintained.The  contact information must enable to contact them 24/7.

• The staff providing incident response must be appropriately trained to respond to security  breaches. Training requirements must be accessed on the basis of incident response plan  testing and performance of incident response personnel.

• An alerting mechanism must be in place to notify the incident response personnel. The alerts  to be sent to incident response personnel must include alerts from intrusion detection,  intrusion prevention, and file integrity monitoring systems.

• There must exist a process to modify and evolve the incident response plan according to  lessons learned and to incorporate industry developments. Annual Security Incident  Response Test Procedure can be used for this purpose. Any lesson-learned during the test  phase must be incorporated into the Production Procedure.

14. PCI DSS Compliance Review Policy

14.1. Policy Statement

The purpose of this policy is to ensure that all kinds of documentation are properly maintained and  various processes required under the PCI DSS program are regularly reviewed by PAYFI in order to  successfully maintain the PCI DSS Compliance for its Payment Aggregator System.

14.2. Policy Details

• PAYFI shall establish responsibility for the protection of cardholder data and a PCI DSS  compliance program that shall include:

✓ Overall accountability for maintaining PCI DSS compliance

✓ Defining a charter for a PCI DSS compliance program and communication to  executive management

✓ Examine documentation to verify executive management has assigned overall  accountability for maintaining the entity’s PCI DSS compliance

✓ Examine the company’s PCI DSS charter to verify it outlines the conditions under  which the PCI DSS compliance program is organized and communicated to  executive management.

• Reviews shall be conducted at least quarterly to confirm personnel are following security  policies and operational procedures. Reviews must cover the following processes:

✓ Daily log reviews

✓ Firewall rule-set reviews

✓ Applying configuration standards to new systems

✓ Responding to security alerts

✓ Change management processes

✓ Interview responsible personnel and examine records of reviews to verify that  reviews are performed at least quarterly

 • Documentation of quarterly review process shall be maintained that will include:

✓ Documenting results of the reviews

✓ Review and sign off of results by personnel assigned responsibility for the PCIDSS  compliance program

• Reviews shall be conducted at least quarterly to confirm personnel are following security  policies and operational procedures: These reviews must take place quarterly instead of  annually. Reviews must validate that existing policies and procedures are being followed with  daily logs, firewall rules, configuration standards, security alert response, and change management. The idea is to confirm that the employees carrying out the different security related tasks understand the related requirements and how they are to be satisfied.

• PAYFI shall maintain a program to monitor service providers’ PCI DSS compliance status at  least annually. PAYFI should manage the day-to-day relationship and performance of the  provider by confirming that management and control activities are performed and any issues or incidents are addressed in a timely fashion.

• PAYFI should also know the compliance status of their service providers and obtain providers’ attestations of compliance.

• Following reviews shall be conducted as part of PCI DSS Compliance Program

✓ Weekly Review:

▪ Random Antivirus update and scan report

▪ Sample of recent password reset requests / forms

▪ Recent sample User creation and access granting requests forms/tickets  for each category of application, network, server, database (as  applicable)

▪ Sample code review reports for PCI scope applications

▪ Recent sample system / software change requests forms

✓ Quarterly Review:

▪ Internet vulnerability scansReport

▪ ASV report

▪ Inactive user IDreconciliation

▪ Wireless scan report

✓ Semi Yearly Review:

▪ Firewall/router rule set review

▪ Card Data Scanning Activity

✓ Yearly Review:

▪ Risk assessment report

▪ Incident test report

▪ Annual network Penetration Testing Report

▪ Annual application Penetration Testing Report

▪ Encryption key change form

▪ Data purging/ deletion

▪ Network diagram revision

▪ Card flow diagram revision

▪ Policy and procedure revision

▪ Annual InformationSecurity awareness training records with date

15. Policies Review

This document shall be reviewed at the time of any change in the IT environment or once a year,  whichever is earlier. As a result of the review the document may be updated or modified.

The IT department is the owner of this document and is responsible for ensuring that the policies are  reviewed in line with the review requirements stated above.

A current version of this document is available to all members of staff.

This policy was approved by the Board as part of the Information System and Information Technology  policies and are issued on a version-controlled basis under the signature of the Director duly authorized  by the Board.