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:
| Requirement | Condition |
| Users to be issued with a temporary password, and to be forced to change on first login | Should be mandatory for Application Access for Individual Users – Internal and External |
| Password Expiry | Minimum of 90 days |
| Password length | Minimum of 8 |
| Password complexity | Should be high and should contain at least one alphabet and one numeric character |
| Password Uniqueness | Minimum history of 4 |
| Period of Inactivity | Maximum of 90 days |
| Storage | Encrypted |
| Number of failed attempts for lockout | Maximum of 3 |
| Lockout period | At least 30 minutes |
| Session Timeout | Maximum 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.
Specifically-
• 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 Name | Role/ Responsibilities |
| Admin Group | Administration and monitoring of the firewall and other network components, such as routers/ switches |
| App Owner Group | Application maintenance and rollout |
| Tech User Group | Back-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.
✓ 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
classified.
▪ 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:
| Impact | Priority | No. of days |
| Urgent | 5 | 3 Days |
| Critical | 4 | 5 Days |
| High | 3 | 1 week |
| Medium | 2 | 1 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
< <
> >
( (
) )
# #
& &
✓ 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
| Standard | Yes | No | Comment |
| AUTHENTICATION | |||
| 1. User Names | |||
| 2. Passwords | |||
| AUTHORIZATION | |||
| ACCOUNTING | |||
| DATA INTEGRITY | |||
| DATA SECURITY | |||
| 1. Encryption | |||
| 2. Storage of Credentials | |||
| 3. Protection of Sensitive Information | |||
| ADMINISTRATIVE INTERFACE | |||
| DEFAULT CONFIGURATION SETTINGS | |||
| ERROR MESSAGES | |||
| DOCUMENTATION | |||
| OWASP TOP 10 WEB SECURITY GUIDELINES | |||
| 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 | |||
| JAVA CODE GUIDELINES | |||
| 1. Static fields | |||
| 2. Reducing Scope | |||
| 3. Public Methods/Fields | |||
| 4. Protecting Packages | |||
| 5. Protecting Against Package-Access | |||
| 6. Immutable Objects |
| Standard | Yes | No | Comment |
| 7. Reference to an Internal Array | |||
| 8. Storage of User Given Arrays | |||
| 9. Serialization | |||
| 10. Sensitive Information | |||
| C/C++ CODE GUIDELINES | |||
| 1. Validity | |||
| 2. Unix “System()” Call | |||
| 3. scanf | |||
| 4. setuid | |||
| 5. Setuid Shell Scripts | |||
| 6. Root Privilege | |||
| 7. Valid Returns | |||
| MISCELLANEOUS | |||
| 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.