Information and network security very important

Introduction:

Information and the knowledge based on it have increasingly become recognized as ‘information assets’, which are vital enablers of business operations. Hence, they require organizations to provide adequate levels of protection. For banks, as purveyors of money in physical form or in bits and bytes, reliable information is even more critical and hence information security is a vital area of concern.

Robust information is at the heart of risk management processes in a bank. Inadequate data quality is likely to induce errors in decision making. Data quality requires building processes, procedures and disciplines for managing information and ensuring its integrity, accuracy, completeness and timeliness. The fundamental attributes supporting data quality should include accuracy, integrity, consistency, completeness, validity, timeliness, accessibility, usability and auditability. The data quality provided by various applications depends on the quality and integrity of the data upon which that information is built. Entities that treat information as a critical organizational asset are in a better position to manage it proactively.

Information security not only deals with information in various channels like spoken, written, printed, electronic or any other medium but also information handling in terms of creation, viewing, transportation, storage or destruction .This is in contrast to IT security which is mainly concerned with security of information within the boundaries of the network infrastructure technology domain. From an information security perspective, the nature and type of compromise is not as material as the fact that security has been breached.

To achieve effective information security governance, bank management must establish and maintain a framework to guide the development and maintenance of a comprehensive information security programme.

Basic Principles of Information Security:

For over twenty years, information security has held confidentiality, integrity and availability (known as the CIA triad) to be the core principles. There is continuous debate about extending this classic trio. Other principles such as Authenticity, Non-repudiation and accountability are also now becoming key considerations for practical security installations.

 Confidentiality: Confidentiality is the term used to prevent the disclosure of information to unauthorized individuals or systems. For example, a credit card transaction on the Internet requires the credit card number to be transmitted from the buyer to the merchant and from the merchant to a transaction processing network. The system attempts to enforce confidentiality by encrypting the card number during transmission, by limiting the places where it might appear (in databases, log files, backups, printed receipts, and so on), and by restricting access to the places where it is stored. If an unauthorized party obtains the card number in any way, a breach of confidentiality has occurred. Breaches of confidentiality take many forms like Hacking, Phishing, Vishing, Email-spoofing, SMS spoofing, and sending malicious code through email or Bot Networks, as discussed earlier.

 Integrity: In information security, integrity means that data cannot be modified without authorization. This is not the same thing as referential integrity in databases.

Integrity is violated when an employee accidentally or with malicious intent deletes important data files, when he/she is able to modify his own salary in a payroll database, when an employee uses programmes and deducts small amounts of money from all customer accounts and adds it to his/her own account (also called salami technique), when an unauthorized user vandalizes a web site, and so on.

On a larger scale, if an automated process is not written and tested correctly, bulk updates to a database could alter data in an incorrect way, leaving the integrity of the data compromised. Information security professionals are tasked with finding ways to implement controls that prevent errors of integrity.

 Availability: For any information system to serve its purpose, the information must be available when it is needed. This means that the computing systems used to store and process the information, the security controls used to protect it, and the communication channels used to access it must be functioning correctly. High availability systems aim to remain available at all times, preventing service disruptions due to power outages, hardware failures, and system upgrades. Ensuring availability also involves preventing denial-of-service (DoS) and distributed denial-of service (DDoS) attacks.

 Authenticity: In computing, e-business and information security it is necessary to ensure that the data, transactions, communications or documents (electronic or physical) are genuine. It is also important for authenticity to validate that both parties involved are who they claim they are.

 Non-repudiation: In law, non-repudiation implies one's intention to fulfill one’s obligations under a contract / transaction. It also implies that a party to a transaction cannot deny having received or having sent an electronic record. Electronic commerce uses technology such as digital signatures and encryption to establish authenticity and non-repudiation.

In addition to the above, there are other security-related concepts and principles when designing a security policy and deploying a security solution. They include identification, authorization, accountability, and auditing.

 Identification: Identification is the process by which a subject professes an identity and accountability is initiated. A subject must provide an identity to a system to start the process of authentication, authorization and accountability. Providing an identity can be typing in a username, swiping a smart card, waving a proximity device, speaking a phrase, or positioning face, hand, or finger for a camera or scanning device. Proving a process ID number also represents the identification process. Without an identity, a system has no way to correlate an authentication factor with the subject.

 Authorization: Once a subject is authenticated, access must be authorized. The process of authorization ensures that the requested activity or access to an object is possible given the rights and privileges assigned to the authenticated identity. In most cases, the system evaluates an access control matrix that compares the subject, the object, and the intended activity. If the specific action is allowed, the subject is authorized. Else, the subject is not authorized.

 Accountability and auditability: An organization’s security policy can be properly enforced only if accountability is maintained, i.e., security can be maintained only if subjects are held accountable for their actions. Effective accountability relies upon the capability to prove a subject’s identity and track their activities. Accountability is established by linking a human to the activities of an online identity through the

security services and mechanisms of auditing, authorization, authentication, and identification. Thus, human accountability is ultimately dependent on the strength of the authentication process. Without a reasonably strong authentication process, there is doubt that the correct human associated with a specific user account was the actual entity controlling that user account when an undesired action took place.

Information Security Governance

Information security governance consists of the leadership, organizational structures and processes that protect information and mitigation of growing information security threats like the ones detailed above.

Critical outcomes of information security governance include:

Alignment of information security with business strategy to support organizational objectives

Management and mitigation of risks and reduction of potential impacts on information resources to an acceptable level

Management of performance of information security by measuring, monitoring and reporting information security governance metrics to ensure that organizational objectives are achieved

Optimisation of information security investments in support of organizational objectives

It is important to consider the organisational necessity and benefits of information security governance. They include increased predictability and the reduction of uncertainty in business operations, a level of assurance that critical decisions are not based on faulty information, enabling efficient and effective risk management, protection from the increasing potential for legal liability, process improvement, reduced losses from security-related events and prevention of catastrophic consequences and improved reputation in the market and among customers.

A comprehensive security programme needs to include the following main activities:

 Development and ongoing maintenance of security policies

 Assignment of roles, responsibilities and accountability for information security

 Development/maintenance of a security and control framework that consists of standards, measures, practices and procedures

 Classification and assignment of ownership of information assets

 Periodic risk assessments and ensuring adequate, effective and tested controls for people, processes and technology to enhance information security

 Ensuring security is integral to all organizational processes

 Processes to monitor security incidents

 Effective identity and access management processes

 Generation of meaningful metrics of security performance

 Information security related awareness sessions to users/officials including senior officials and board members

Organizational Structure, Roles and Responsibilities:

Boards of Directors/Senior Management

The Board of Directors is ultimately responsible for information security. Senior Management is responsible for understanding risks to the bank to ensure that they are adequately addressed from a governance perspective. To do so effectively requires managing risks, including information security risks, by integrating information security governance in the

overall enterprise governance framework of the organization. It is reported that the effectiveness of information security governance is dependent on the involvement of the Board/senior management in approving policy and appropriate monitoring of the information security function.

The major role of top management involves implementing the Board approved information security policy, establishing necessary organizational processes for information security and providing necessary resources for successful information security. It is essential that senior management establish an expectation for strong cyber security and communicate this to their officials down the line. It is also essential that the senior organizational leadership establish a structure for implementation of an information security programme to enable a consistent and effective information security programme implementation apart from ensuring the accountability of individuals for their performance as it relates to cyber security.

Given that today’s banking is largely dependent on IT systems and since most of the internal processing requirements of banks are electronic, it is essential that adequate security systems are fully integrated into the IT systems of banks. It would be optimal to classify these based on the risk analysis of the various systems in each bank and specific risk mitigation strategies need to be in place.

Information security team/function

Banks should form a separate information security function/group to focus exclusively on information security management. There should be segregation of the duties of the Security Officer/Group dealing exclusively with information systems security and the Information Technology Division which actually implements the computer systems. The organization of the information security function should be commensurate with the nature and size of activities of a bank including a variety of e-banking systems and delivery channels of a bank. The information security function should be adequately resourced in terms of the number of staff, level of skills and tools or techniques like risk assessment, security architecture, vulnerability assessment, forensic assessment, etc. While the information security group/function itself and information security governance related structures should not be outsourced, specific operational components relating to information security can be outsourced, if required resources are not available within a bank. However, the ultimate control and responsibility rests with the bank.

Information Security Committee

Since information security affects all aspects of an organization, in order to consider information security from a bank -wide perspective a steering committee of executives should be formed with formal terms of reference. The Chief Information Security Officer would be the member secretary of the Committee. The committee may include, among others, the Chief Executive Officer (CEO) or designee, chief financial officer (CFO), business unit executives, Chief Information Officer (CIO)/ IT Head, Heads of human resources, legal, risk management, audit, operations and public relations.

A steering committee serves as an effective communication channel for management’s aims and directions and provides an ongoing basis for ensuring alignment of the security programme with organizational objectives. It is also instrumental in achieving behavior change toward a culture that promotes good security practices and compliance with policies.

Major responsibilities of the Information Security Committee, inter-alia, include:

 Developing and facilitating the implementation of information security policies, standards and procedures to ensure that all identified risks are managed within a bank’s risk appetite

 Approving and monitoring major information security projects and the status of information security plans and budgets, establishing priorities, approving standards and procedures

 Supporting the development and implementation of a bank-wide information security management programme

 Reviewing the position of security incidents and various information security assessments and monitoring activities across the bank

 Reviewing the status of security awareness programmes

 Assessing new developments or issues relating to information security

 Reporting to the Board of Directors on information security activities

Minutes of the Steering Committee meetings should be maintained to document the committee’s activities and decisions and a review on information security needs to be escalated to the Board on a quarterly basis.

Chief information security officer (CISO)

A sufficiently senior level official, of the rank of GM/DGM/AGM, should be designated as Chief Information Security Officer, responsible for articulating and enforcing the policies that banks use to protect their information assets apart from coordinating the security related issues / implementation within the organization as well as relevant external agencies. The CISO needs to report directly to the Head of Risk Management and should not have a direct reporting relationship with the CIO. However, the CISO may have a working relationship with the CIO to develop the required rapport to understand the IT infrastructure and operations, to build effective security in IT across the bank, in tune with business requirements and objectives.

Critical components of information security:

 Policies and procedures:

 Banks need to frame Board approved Information Security Policy and identify and implement appropriate information security management measures/practices keeping in view their business needs.

 The policies need to be supported with relevant standards, guidelines and procedures. A policy framework would, inter-alia, incorporate/take into consideration the following:

 An information security strategy that is aligned with business objectives and the legal requirements

 Objectives, scope, ownership and responsibility for the policy

 Information security organisational structure

 Information security roles and responsibilities that may include information

security-specific roles like IT security manager/officer, administrators, information security specialists and information asset-specific roles like owners, custodians, end-users

̀⠀⤀ĀᜀĀ Periodic reviews of the policy – at least annually and in the event of significant changes necessitating revision

̀⠀⤀ĀᜀĀ A periodic compliance review of the policy – about the adherence of users to information security policies and put up to the information security committee.

̀⠀⤀ĀᜀĀ Exceptions: An exception policy for handling instances of non-compliance with the information security policy including critical aspects like exception criteria including whether there is genuine need for exceptions, management of the exception log or register, authority to grant exemptions, expiry of exceptions and the periodicity of review of exceptions granted. Where exemptions are granted, banks need to review and assess the adequacy of compensating controls initially and on an ongoing basis. A sign -off needs to be obtained from the CISO on the exceptions

 Penal measures for violation of policies and the process to be followed in the event of violation

 Identification, authorisation and granting of access to IT assets (by individuals and other IT assets)

 Addressing the various stages of an IT asset’s life to ensure that information security requirements are considered at each stage of the lifecycle

 An incident monitoring and management process to address the identification and classification of incidents, reporting, escalation, preservation of evidence, the investigation process

 Management of technology solutions for information security like a firewall, anti-virus/anti-malware software, intrusion detection/prevention systems, cryptographic systems and monitoring/log analysis tools/techniques

 Management and monitoring of service providers that provides for overseeing the management of information security risks by third parties

 Clearly indicating acceptable usage of IT assets including application systems that define the information security responsibilities of users (staff, service providers and customers) in regard to the use of IT assets

 Requirements relating to recruitment and selection of qualified staff and external contractors that define the framework for vetting and monitoring of personnel, taking into account the information security risk

 Strategy for periodic training and enhancing skills of information security personnel, requirement of continuous professional education

 Specific policies that would be required include, but not limited to, the following:

 Logical Access Control

 Asset Management

 Network Access Control

 Password management

 E-mail security

 Remote access

 Mobile computing

 Network security

 Application security

 Backup and archival

 Operating system security

 Database administration and security

 Physical security

 Capacity Management

 Incident response and management

 Malicious software

 IT asset/media management

 Change Management

 Patch Management

 Internet security

 Desktop

 Encryption

 Security of electronic delivery channels

 Wireless security

 Application/data migration

 Accountability for security is increased through clear job descriptions, employment agreements and policy awareness acknowledgements. It is important to communicate the general and specific security roles and responsibilities for all employees within their job descriptions. The job descriptions for security personnel should also clearly describe the systems and processes they will protect and their

responsibility towards control processes. Management should expect all employees, officers and contractors/consultants to comply with security and acceptable-use policies and protect the institution’s assets, including information.

 Given the critical role of security technologies as part of the information security framework, banks need to subject them to suitable controls across their lifecycle like guidelines on their usage, standards and procedures indicating the detailed objectives and requirements of individual information security-specific technology solutions, authorisation for individuals who would be handling the technology, addressing segregation of duties issues, appropriate configurations of the devices that provide the best possible security, regularly assessing their effectiveness and fine-tuning them accordingly, and identification of any unauthorised changes.

 Digital evidence is similar to any other form of legal proof - it needs to withstand challenges to its integrity, its handling must be carefully tracked and documented, and it must be suitably authenticated by concerned personnel as per legal requirements. Since the evidence resides on or is generated by a digital device, a trained information security official or skilled digital forensics examiner may need to be involved in the handling process to ensure that any material facts is properly preserved and introduced. A suitable policy needs to be in place in this regard.

 Risk Assessment

 The likelihood that a threat will use a vulnerability to cause harm creates a risk. When a threat does use a vulnerability to inflict harm, it has an impact. In the context of information security, the impact is a loss of availability, integrity and confidentiality, and possibly other losses (lost income, loss of life, loss of property).

 Risk assessment is the core competence of information security management. The risk assessment must, for each asset within its scope, identify the threat/vulnerability combinations that have a likelihood of impacting the confidentiality, availability or integrity of that asset - from a business, compliance or contractual perspective. Standards like ISO27001 and ISO 27002 are explicit in requiring a risk assessment to be carried out before any controls are selected and implemented and are equally explicit that the selection of every control must be justified by a risk assessment.

 In broad terms, the risk management process consists of:

 Identification of assets and estimation of their value. Some aspects to be included are people, buildings, hardware, software, data (electronic, print) and supplies

 Conducting a threat assessment which may include aspects like acts of nature, acts of war, accidents, malicious acts originating from inside or outside the organization

 Conducting a vulnerability assessment for each vulnerability and calculating the probability that it will be exploited. Evaluating policies, procedures, standards, training, physical security, quality control and technical security in this regard

 Calculating the impact that each threat would have on each asset through qualitative or quantitative analysis

 Identifying, selecting and implementing appropriate controls. Providing proportional response including considerations like productivity, cost effectiveness, and the value of the asset

 Evaluating the effectiveness of the control measures. Ensuring the controls provide the required cost-effective protection.

 The process of risk management is an ongoing iterative process. The business environment is constantly changing and new threats and vulnerabilities emerge every day. The choice of countermeasures or controls used to manage risks must strike a balance between productivity, cost-effectiveness of the countermeasure and the value

of the informational asset being protected. The risk assessment should be carried out by a team of people who have knowledge of specific areas of the business. The assessment may use a subjective qualitative analysis based on informed opinion, or where reliable figures and historical information is available, quantitative analysis.

 Quantitative methods involve assigning numerical measurements that can be entered into the analysis to determine total and residual risks. The various aspects that are considered a part of measurements include costs to safeguard the information and information systems, value of that information and those systems, threat frequency and probability, and the effectiveness of controls. A shortcoming of quantitative methods is a lack of reliable and predictive data on threat frequency and probability. This shortcoming is generally addressed by assigning numeric values based on qualitative judgments.

 Qualitative analysis involves the use of scenarios and attempts to determine the seriousness of threats and the effectiveness of controls. Qualitative analysis is by definition subjective, relying upon judgment, knowledge, prior experience and industry information. Qualitative techniques may include walk-throughs, surveys/questionnaires, interviews and specific workgroups to obtain information about the various scenarios.

 Inventory and information/data classification

Effective control requires a detailed inventory of information assets. Such a list is the first step in classifying the assets and determining the level of protection to be provided to each asset.

The inventory record of each information asset should, at the least, include:

 A clear and distinct identification of the asset

 Its relative value to the organization

 Its location

 Its security/risk classification

 Its asset group (where the asset forms part of a larger information system)

 Its owner

 Its designated custodian

Information assets have varying degrees of sensitivity and criticality in meeting business objectives. By assigning classes or levels of sensitivity and criticality to information resources and establishing specific security rules/requirements for each class, it is possible to define the level of access controls that should be applied to each information asset. Classification of information reduces the risk and cost of over- or under - protecting information resources in aligning security with business objectives since it helps to build and maintain a consistent and uniform perspective of the security requirements for information assets throughout the organization. ISO 27001 standards require the inventorying of information assets and the classification, handling and labelling of information in accordance with preset guidelines.

 Defining roles and responsibilities

All defined and documented responsibilities and accountabilities must be established and communicated to all relevant personnel and management. Some of the major ones include:

Information owner

This is a business executive or business manager who is responsible for a bank’s business information asset. Responsibilities would include, but not be limited to:

 Assigning initial information classification and periodically reviewing the classification to ensure it still meets business needs

 Ensuring security controls are in place commensurate with the classification

 Reviewing and ensuring currency of the access rights associated with information assets they own

 Determining security requirements, access criteria and backup requirements for the information assets they own

Information custodian

The information custodian, usually an information systems official, is the delegate of the information owner with primary responsibilities for dealing with backup and recovery of the business information. Responsibilities include, but are not limited to, the following:

Performing backups according to the backup requirements established by the information owner

When necessary, restoring lost or corrupted information from backup media to return the application to production status

Ensuring record retention requirements are met based on the information owner’s requirements

Application owner

The application owner is the manager of the business line who is fully accountable for the performance of the business function served by the application. Responsibilities, inter-alia, include:

Establishing user access criteria, availability requirements and audit trails for their applications

Ensuring security controls associated with the application are commensurate with support for the highest level of information classification used by the application

Performing or delegating the following - day-to-day security administration, approval of exception access requests, appropriate actions on security violations when notified by the security administration, the review and approval of all changes to the application prior to being placed in the production environment, and verification of the currency of user access rights to the application

User manager

The user manager is the immediate manager or supervisor of an employee or HR official of the business function in which an employee works. He has the ultimate responsibility for all user IDs and information assets owned by bank employees. In the case of non employee individuals such as contractors, consultants, etc., this manager is responsible for the activity and for the bank assets used by these individuals. He/she is usually the manager responsible for hiring the outside contractor. Responsibilities include the following:

Informing security administration of the termination of any employee so that the user ID owned by that individual can be revoked, suspended or made inaccessible in a timely manner

Informing security administration of the transfer of any employee if the transfer involves the change of access rights or privileges

Reporting any security incident or suspected incident to the Information Security function

Ensuring that employees are aware of relevant security policies, procedures and standards to which they are accountable

Security Administrator

Security administrators have the powers to set system-wide security controls or administer user IDs and information resource access rights. These security administrators usually report to the Information Security function. Responsibilities include the following:

Understanding different data environments and the impact of granting access to them

Ensuring access requests are consistent with the information directions and security guidelines

Administering access rights according to criteria established by the Information Owners

Creating and removing user IDs as directed by the user manager

Administering the system within the scope of their job description and functional responsibilities

Distributing and following up on security violation reports

End user

The end users would be any employees, contractors or vendors of the bank who use information systems resources as part of their job. Responsibilities include :

Maintaining confidentiality of log-in password(s)

Ensuring security of information entrusted to their care

Using bank business assets and information resources for management approved purposes only

Adhering to all information security policies, procedures, standards and guidelines

Promptly reporting security incidents to management.

Access Control

An effective process for access to information assets is one of the critical requirements of information security. Internal sabotage, clandestine espionage or furtive attacks by trusted employees, contractors and vendors are among the most serious potential risks that a bank faces. Current and past employees, contractors, vendors and those who have an intimate knowledge of the inner workings of the bank’s systems, operations and internal controls have a significant advantage over external attackers. A successful attack could jeopardise customer confidence in a bank’s internal control systems and processes.

Hence, access to information assets needs to be authorised by a bank only where a valid business need exists and only for the specific time period that the access is required. The various factors that need to be considered when authorising access to users and information assets, inter-alia, include business role, physical location, method of connectivity, remote access, time, anti-malware and patch updation status, nature of device used and software /operating system.

The provision of access involves various stages like identification and authentication which involves determination of the person or IT asset requesting access and confirmation of the purported identity and authorisation. This involves an assessment of whether access is allowed to an information asset by the request or based on the needs of the business and the level of information security required. These processes are applicable to both users as well as IT assets.

A bank should take appropriate measures to identify and authenticate users or IT assets. The required strength of authentication needs to be commensurate with risk. Common techniques for increasing the strength of identification and authentication include the use of strong password techniques (i.e. increased length, complexity, re-use limitations and frequency of change) and increasing the number and/or type of authentication factors used.

The examples where increased authentication strength may be required, given the risks involved include : administration or other privileged access to sensitive or critical IT assets, remote access through public networks to sensitive assets and activities carrying higher risk like third-party fund transfers, etc. The period for which authentication is valid would need to be commensurate with the risk.

Among the important controls that banks need to consider are:

 A systematic process of applying and authorizing the creation of user ids and the access control matrix

 Conducting a risk assessment and granting access rights based on the same. For example, contractors and temporary staff would have higher inherent risks

 Implementation of role-based access control policies designed to ensure effective segregation of duties

 Changing default user names and/or passwords of systems and prohibiting sharing of user ids and passwords including generic accounts

 Modification of access rights whenever there is a change in role or responsibility and removal of access rights on cessation of employment

 Processes to notify in a timely manner the information security function regarding user additions, deletions and role changes

 Periodic reconciliation of user ids in a system and actual users required to have access and deletion of unnecessary ids, if any

 Audit of logging and monitoring of access to IT assets by all users

 Regular reviews of user access by information asset owners to ensure appropriate access is maintained

 Applying the four-eyes principle to very critical/sensitive IT assets

 Considering de-activating user ids of users of critical applications who are on prolonged leave

(vii) Banks may consider using automated solutions to enable effective access control and management of user ids. Such solutions should also be managed effectively to ensure robust access management.

 For accountability purposes, a bank should ensure that users and IT assets are uniquely identified and their actions are auditable.

 Transaction processes and systems should be designed to ensure that no single employee/outsourced service provider could enter, authorize and complete a transaction.

 Segregation should be maintained between those initiating static data (including web page content) and those responsible for verifying its integrity. Further, segregation should be maintained between those developing and those administering e-banking systems.

 E-banking systems should be tested to ensure that segregation of duties cannot be bypassed.

 Mutual authentication system may be considered. Mutual Authentication, also called two-way authentication, is a security feature in which a client process must prove his identity to a server, and the server must prove its identity to the client, before any application traffic is sent over the client-to-server connection. Identity can be proved through a trusted third party and use of shared secrets or through cryptographic means as with a public key infrastructure. For e.g., with the mutual authentication implemented, a connection can occur only when the client trusts the server's digital certificate and the server trusts the client's certificate. The exchange of certificates will happen through special protocols like the Transport Layer Security (TLS) protocol. This process reduces the risk that an unsuspecting network user will inadvertently reveal security information to a malicious or insecure web site.

 System administrators, security officers, programmers and staff performing critical operations invariably possess the capability to inflict severe damage on the banking systems they maintain or operate by virtue of their job functions and privileged access. Personnel with elevated system access entitlements should be closely supervised with all their systems activities logged, as they have inside knowledge and the resources to circumvent systems controls and security procedures. Some of the control and security practices enumerated below needs to be considered:

 Implementing two-factor authentication for privileged users

 Instituting strong controls over remote access by privileged users

Restricting the number of privileged users

Granting privileged access on a “need-to-have” or “need-to-do” basis

Maintaining audit logging of system activities performed by privileged users

Ensuring that privileged users do not have access to systems logs in which their activities are being captured

Conducting regular audit or management review of the logs

Prohibiting sharing of privileged IDs and their access codes

Disallowing vendors and contractors from gaining privileged access to systems without close supervision and monitoring

Protecting backup data from unauthorized access.

 Information security and information asset life-cycle

 Information security needs to be considered at all stages of an information asset’s life-cycle like planning, design, acquisition and implementation, maintenance and disposal. Banks need to apply systematic project management oriented techniques to manage material changes during these stages and to ensure that information security requirements have been adequately addressed.

 Planning and design level controls need to be in place to ensure that information security is embodied in the overall information systems architecture and the implemented solutions are in compliance with the information security policies and requirements of a bank.

 Ongoing support and maintenance controls would be needed to ensure that IT assets continue to meet business objectives. Major controls in this regard include change management controls to ensure that the business objectives continue to be met following change; configuration management controls to ensure that the configuration minimises vulnerabilities and is defined, assessed, maintained and managed; deployment and environment controls to ensure that development, test and production environments are appropriately segregated; and patch management controls to manage the assessment and application of patches to software that addresses known vulnerabilities in a timely manner

 The other relevant controls include service level management, vendor management, capacity management and configuration management which are described in later chapters. Decommissioning and destruction controls need to be used to ensure that information security is not compromised as IT assets reach the end of their useful life. (for example, through archiving strategies and deletion of sensitive information prior to the disposal of IT assets.)

 Personnel security

 Application owners grant legitimate users access to systems that are necessary to perform their duties and security personnel enforce the access rights in accordance with institution standards. Because of their internal access levels and intimate knowledge of financial institution processes, authorized users pose a potential threat to systems and data. Employees, contractors, or third-party employees can also exploit their legitimate computer access for malicious or fraudulent reasons. Further, the degree of internal access granted to some users can increase the risk of accidental damage or loss of information and systems.

 Risk exposures from internal users include altering data, deleting production and back-up data, disrupting/destroying systems, misusing systems for personal gain or to damage the institution, holding data hostage and stealing strategic or customer data for espionage or fraud schemes.

 Banks should have a process to verify job application information on all new employees. Additional background and credit checks may be warranted based on the sensitivity of a particular job or access level. Personnel with privileged access like administrators, cyber security personnel, etc. should be subjected to rigorous

background checks and screening. Institutions should verify that contractors are subject to similar screening procedures. The verification considerations would include:

 Character references – business and personal

 Confirmation of prior experience, academic record, and professional qualifications

 Confirmation of identity through a government issued identification

 There also needs to be a periodic rotation of duties among users or personnel as a prudent risk measure.

Physical security

The confidentiality, integrity, and availability of information can be impaired through physical access and damage or destruction to physical components. Conceptually, those physical security risks are mitigated through zone-oriented implementations. Zones are physical areas with differing physical security requirements. The security requirements of each zone are a function of the sensitivity of the data contained or accessible through the zone and the information technology components in the zone.

The requirements for each zone should be determined through the risk assessment. The risk assessment should include, but is not limited to, threats like aircraft crashes, chemical effects, dust, electrical supply interference, electromagnetic radiation, explosives, fire, smoke, theft/destruction, vibration/earthquake, water, criminals, terrorism, political issues (e.g. strikes, disruptions) and other threats based on the entity’s unique geographical location, building configuration, neighboring environment/entities, etc.

A bank needs to deploy the following environmental controls:

Secure location of critical assets providing protection from natural and man-made threats

Restrict access to sensitive areas like data centres, which also includes detailed procedures for handling access by staff, third party providers and visitors

Suitable preventive mechanisms for various threats indicated above

Monitoring mechanisms for the detection of compromises of environmental controls relating to temperature, water, smoke, access alarms, service availability alerts (power supply, telecommunication, servers), access log reviews etc

User Training and Awareness

It is acknowledged that the human link is the weakest link in the information security chain. Hence, there is a vital need for an initial and ongoing training and information security awareness programme. The programme may be periodically updated keeping in view changes in information security, threats/vulnerabilities and/or the bank’s information security framework. There needs to be a mechanism to track the effectiveness of training programmes through an assessment/testing process designed on testing the understanding of the relevant information security policies, not only initially but also on a periodic basis. At any point of time, a bank needs to maintain an updated status on user training and awareness relating to information security and the matter needs to be an important agenda item during Information Security Committee meetings.

Some of the areas that could be incorporated as part of the user awareness programme include:

 Relevant information security policies/procedures

 Acceptable and appropriate usage of IT assets

 Access controls including standards relating to passwords and other authentication requirements

 Measures relating to proper email usage and internet usage

 Physical protection

 Remote computing and use of mobile devices

 Safe handling of sensitive data/information

 Being wary of social engineering attempts to part with confidential details

 Prompt reporting of any security incidents and concerns

 Incident management

 Incident management is defined as the process of developing and maintaining the capability to manage incidents within a bank so that exposure is contained and recovery achieved within a specified time objective. Incidents can include the misuse of computing assets, information disclosure or events that threaten the continuance of business processes.

 Major activities that need to be considered as part of the incident management framework include:

 Developing and implementing processes for preventing, detecting, analyzing and responding to information security incidents

 Establishing escalation and communication processes and lines of authority

 Developing plans to respond to and document information security incidents

 Establishing the capability to investigate information security incidents through various modes like forensics, evidence collection and preservation, log analysis, interviewing, etc.

 Developing a process to communicate with internal parties and external organizations (e.g., regulator, media, law enforcement, customers)

 Integrating information security incident response plans with the organization’s disaster recovery and business continuity plan

 Organizing, training and equipping teams to respond to information security incidents

 Periodically testing and refining information security incident response plans

 Conducting post-mortem analysis and reviews to identify causes of information security incidents, developing corrective actions and reassessing risk, and adjusting controls suitably to reduce the related risks in the future

 Common incident types include, but not limited to, outages/degradation of services due to hardware, software or capacity issues, unauthorised access to systems, identity theft, data leakage/loss, malicious software and hardware, failed backup processes, denial of service attacks and data integrity issues.

 A bank needs to have clear accountability and communication strategies to limit the impact of information security incidents through defined mechanisms for escalation and reporting to the Board and senior management and customer communication, where appropriate. Incident management strategies would also typically assist in compliance with regulatory requirements. Institutions would also need to pro-actively notify CERT-In/IDRBT/RBI regarding cyber security incidents.

 All security incidents or violations of security policies should be brought to the notice of the CISO.

 Application Control and Security:

 Financial institutions have different types of applications like the core banking system, delivery channels like ATMs, internet banking, mobile banking, phone banking, network operating systems, databases, enterprise resource management (ERP) systems, customer relationship management (CRM) systems, etc., all used for different business purposes. Then these institutions have partners, contractors, consultants, employees and temporary employees. Users usually access several different types of systems throughout their daily tasks, which makes controlling access and providing the necessary level of protection on different data types difficult and full of obstacles. This complexity may result in unforeseen and unidentified holes in the protection of the entire infrastructure including overlapping and contradictory controls, and policy and regulatory noncompliance.

 There are well-known information systems security issues associated with applications software, whether the software is developed internally or acquired from an external source .Attackers can potentially use many different paths through the application to do harm to the business. Each of these paths represents a risk that may or may not be serious enough to warrant attention. Sometimes, these paths are easy to find and exploit and sometimes they are extremely difficult. Similarly, the harm that is caused may range from minor to major. To determine the risk to itself, a bank can evaluate the likelihood associated with the threat agent, attack vector, and security weakness and combine it with an estimate of the technical and business impact to the organization. Together, these factors determine the overall risk.

 The following are the important Application control and risk mitigation measures that need to be implemented by banks:

 Each application should have an owner which will typically be the concerned business function that uses the application

 Some of the roles of application owners include:

 Prioritizing any changes to be made to the application and authorizing the changes

 Deciding on data classification/de-classification and archival/purging procedures for the data pertaining to an application as per relevant policies/regulatory/statutory requirements

 Ensuring that adequate controls are built into the application through active involvement in the application design, development, testing and change process

 Ensuring that the application meets the business/functional needs of the users

 Ensuring that the information security function has reviewed the security of the application

 Taking decisions on any new applications to be acquired / developed or any old applications to be discarded

 Informing the information security team regarding purchase of an application and assessing the application based on the security policy requirements

 Ensuring that the Change Management process is followed for any changes in application

 Ensuring that the new applications being purchased/developed follow the Information Security policy

 Ensuring that logs or audit trails, as required, are enabled and monitored for the applications

 All application systems need to be tested before implementation in a robust manner regarding controls to ensure that they satisfy business policies/rules of the bank and regulatory and legal prescriptions/requirements. Robust controls need to be built into the system and reliance on any manual controls needs to be minimized. Before the system is live, there should be clarity on the audit trails and the specific fields that are required to be captured as part of audit trails and an audit trail or log monitoring process including personnel responsible for the same.

 A bank needs to incorporate information security at all stages of software development. This would assist in improving software quality and minimizing exposure to vulnerabilities. Besides business functionalities, security requirements relating to system access control, authentication, transaction authorization, data integrity, system activity logging, audit trail, security event tracking and exception handling are required to be clearly specified at the initial stages of system development/acquisition. A compliance check against the bank’s security standards and regulatory/statutory requirements would also be required.

 All application systems need to have audit trails along with policy/procedure of log monitoring for such systems including the clear allocation of responsibility in this regard. Every application affecting critical/sensitive information, for example, impacting financial, customer, control, regulatory and legal aspects, must provide for detailed audit trails/ logging capability with details like transaction id, date, time, originator id, authorizer id, actions undertaken by a given user id, etc. Other details like logging the IP address of the client machine, terminal identity or location may also be considered.

 Applications must also provide for, inter-alia, logging unsuccessful logon attempts, access to sensitive options in the application, e.g., master record changes, granting of access rights, use of system utilities, changes in system configuration, etc.

 The audit trails need to be stored as per a defined period as per any internal/regulatory/statutory requirements and it should be ensured that they are not tampered with.

 There should be documented standards/procedures for administering the application, which are approved by the application owner and kept up-to-date.

 The development, test and production environments need to be properly segregated.

 Access should be based on the principle of least privilege and “need to know” commensurate with the job responsibilities. Adequate segregation of duties needs to be enforced.

 There should be controls on updating key ‘static’ business information like customer master files, parameter changes, etc.

 Any changes to an application system/data need to be justified by genuine business need and approvals supported by documentation and subjected to a robust change management process. The change management would involve generating a request, risk assessment, authorization from an appropriate authority, implementation, testing and verification of the change done.

 Potential security weaknesses / breaches (for example, as a result of analyzing user behaviour or patterns of network traffic) should be identified.

 There should be measures to reduce the risk of theft, fraud, error and unauthorized changes to information through measures like supervision of activities and segregation of duties.

 Applications must not allow unauthorized entries to be updated in the database. Similarly, applications must not allow any modifications to be made after an entry is authorized. Any subsequent changes must be made only by reversing the original authorized entry and passing a fresh entry.

 Direct back-end updates to database should not be allowed except during exigencies, with a clear business need and after due authorization as per the relevant policy.

 Access to the database prompt must be restricted only to the database administrator.

 Robust input validation controls, processing and output controls needs to be built in to the application.

 There should be a procedure in place to reduce the reliance on a few key individuals.

 Alerts regarding use of the same machine for both maker and checker transactions need to be considered.

 There should be a proper linkage between a change request and the corresponding action taken. For example, the specific accounting head or code which was created as a result of a specific request should be established clearly.

 Error / exception reports and logs need to be reviewed and any issues need to be remedied /addressed at the earliest.

 Critical functions or applications dealing with financial, regulatory and legal, MIS and risk assessment/management, (for example, calculation of capital adequacy, ALM, calculating VaR, risk weighted assets, NPA classification and provisioning, balance sheet compilation, AML system, revaluation of foreign currency balances, computation of MTM gains / losses, etc.,) needs to be done through proper application systems and not manually or in a semi-automated manner through spreadsheets. These pose risks relating to data integrity and reliability. Use of spreadsheets in this regard should be restricted and should be replaced by appropriate IT applications within a definite time-frame in a phased manner.

 Banks may obtain application integrity statements in writing from the application system vendors providing for reasonable level of assurance about the application being free of malware at the time of sale, free of any obvious bugs, and free of any covert channels in the code (of the version of the application being delivered as well as any subsequent versions/modifications done).

 For all critical applications, either the source code must be received from the vendor or a software escrow agreement should be in place with a third party to ensure source code availability in the event the vendor goes out of business. It needs to be ensured that product updates and programme fixes are also included in the escrow agreement.

 Applications should be configured to logout the users after a specific period of inactivity. The application must ensure rollover of incomplete transactions and otherwise ensure integrity of data in case of a log out.

 There should be suitable interface controls in place. Data transfer from one process to another or from one application to another, particularly for critical systems, should not have any manual intervention in order to prevent any unauthorized modification. The process needs to be automated and properly integrated with due authentication mechanism and audit trails by enabling “Straight Through Processing” between applications or from data sources to replace any manual intervention/semi-automated processes like extracting data in text files and uploading to the target system, importing to a spreadsheet, etc. Further, proper validations and reconciliation of data needs to be carried out between relevant interfaces/applications across the bank. The bank needs to suitably integrate the systems and applications, as required, to enhance data integrity and reliability.

 Multi-tier application architecture needs to be considered for relevant critical systems like internet banking systems which differentiate session control,

presentation logic, server side input validation, business logic and database access.

In the event of data pertaining to Indian operations being stored and/or processed abroad, for example, by foreign banks, there needs to be suitable controls like segregation of data and strict access controls based on ‘need to know’ and robust change controls. The bank should be in a position to adequately prove the same to the regulator. Regulator’s access to such data/records and other relevant information should not be impeded in any manner and RBI would have the right to cause an inspection to be made of the processing centre/data centre and its books and accounts by one or more of its officers or employees or other persons.

An application security review/testing, initially and during major changes, needs to be conducted using a combination of source code review, stress loading, exception testing and compliance review to identify insecure coding techniques and systems vulnerabilities to a reasonable extent.

Critical application system logs/audit trails also need to be backed up as part of the application backup policy.

Robust System Security Testing, in respect of critical e-banking systems, needs to incorporate, inter-alia, specifications relating to information leakage, business logic, authentication, authorization, input data validation, exception/error handling, session management, cryptography and detailed logging, as relevant. These need to be carried out atleast on annual basis.

 Migration controls:

 There needs to be a documented Migration Policy indicating the requirement of road-map / migration plan / methodology for data migration (which includes verification of completeness, consistency and integrity of the migration activity and pre and post migration activities along with responsibilities and timelines for completion of same). Explicit sign offs from users/application owners need to be obtained after each stage of migration and after complete migration process. Audit trails need to be available to document the conversion, including data mappings and transformations.

 The key aspects that are required to be considered include:

a. Integrity of data— indicating that the data is not altered manually or electronically by a person, programme, substitution or overwriting in the new system. Integrity thus, includes error creep due to factors like transposition, transcription, etc.

 Completeness— ensuring that the total number of records from the source database is transferred to the new database (assuming the number of fields is the same)

 Confidentiality of data under conversion—ensuring that data is backed up before migration for future reference or any emergency that might arise out of the data migration process

 Consistency of data— the field/record called for from the new application should be consistent with that of the original application. This should enable consistency in repeatability of the testing exercise

 Continuity—the new application should be able to continue with newer records as addition (or appendage) and help in ensuring seamless business continuity

 It is a good practice that the last copy of the data before conversion from the old platform and the first copy of the data after conversion to the new platform are maintained separately in the archive for any future reference.

 The error logs pertaining to the pre-migration/ migration/ post migration period along with root cause analysis and action taken need to be available for review.

 Banks may need to migrate the complete transaction data and audit trails from the old system to the new system. Else, banks should have the capability to access the older transactional data and piece together the transaction trail between older and newer systems, to satisfy any supervisory/legal requirements that may arise.

 Implementation of new technologies:

 Banks need to carry out due diligence with regard to new technologies since they can potentially introduce additional risk exposures. A bank needs to authorise the large scale use and deployment in production environment of technologies that have matured to a state where there is a generally agreed set of industry-accepted controls and robust diligence and testing has been carried out to ascertain the security issues of the technology or where compensating controls are sufficient to prevent significant impact and to comply with the institution’s risk appetite and regulatory expectations.

 Any new business products introduced along with the underlying information systems need to be assessed as part of a formal product approval process which incorporates, inter-alia, security related aspects and fulfilment of relevant legal and regulatory prescriptions. A bank needs to develop an authorisation process involving a risk assessment balancing the benefits of the new technology with the risk.

 Encryption

 Encryption Types:

Symmetric encryption is the use of the same key and algorithm by the creator and reader of a file or message. The creator uses the key and algorithm to encrypt, and the reader uses both to decrypt. Symmetric encryption relies on the secrecy of the key. If the key is captured by an attacker, either when it is exchanged between the communicating parties, or while one of the parties uses or stores the key, the attacker can use the key and the algorithm to decrypt messages or to masquerade as a message creator.

Asymmetric encryption lessens the risk of key exposure by using two mathematically related keys, the private key and the public key. When one key is used to encrypt, only the other key can decrypt. Therefore, only one key (the private key) must be kept secret. The key that is exchanged (the public key) poses no risk if it becomes known. For instance, if individual A has a private key and publishes the public key, individual B can obtain the public key, encrypt a message to individual A, and send it. As long as an individual keeps his private key secure from disclosure, only individual A will be able to decrypt the message.

 Typical areas or situations requiring deployment of cryptographic techniques, given the risks involved, include transmission and storage of critical and/or sensitive data/information in an ‘un-trusted’ environment or where a higher degree of security is required, generation of customer PINs which are typically used for card transactions and online services, detection of any unauthorised alteration of data/information and verification of the authenticity of transactions or data/information.

 Since security is primarily based on the encryption keys, effective key management is crucial. Effective key management systems are based on an agreed set of standards, procedures, and secure methods that address

 Generating keys for different cryptographic systems and different applications

 Generating and obtaining public keys and distributing keys to intended users, including how keys should be activated when received

 Storing keys, including how authorized users obtain access to keys and changing or updating keys, including rules on when keys should be changed and how this will be done

 Dealing with compromised keys, revoking keys and specifying how keys should be withdrawn or deactivated

 Recovering keys that are lost or corrupted as part of business continuity management

 Archiving, destroying keys

 Logging the auditing of key management-related activities

 Instituting defined activation and deactivation dates, limiting the usage period of keys

 Secure key management systems are characterized by the following precautions:

 Additional physical protection of equipment used to generate, store and archive cryptographic keys

 Use of cryptographic techniques to maintain cryptographic key confidentiality

 Segregation of duties, with no single individual having knowledge of the entire cryptographic key (i.e. two-person controls) or having access to all the components making up these keys

 Ensuring key management is fully automated (e.g., personnel do not have the opportunity to expose a key or influence the key creation)

 Ensuring no key ever appears unencrypted

 Ensuring keys are randomly chosen from the entire key space, preferably by hardware

 Ensuring key-encrypting keys are separate from data keys. No data ever appears in clear text that was encrypted using a key-encrypting key. (A key encrypting key is used to encrypt other keys, securing them from disclosure.)

 Make sure that keys with a long life are sparsely used. The more a key is used, the greater the opportunity for an attacker to discover the key

 Ensuring keys are changed frequently.

 Ensuring keys that are transmitted are sent securely to well-authenticated parties.

 Ensuring key-generating equipment is physically and logically secure from construction through receipt, installation, operation, and removal from service.

 Normally, a minimum of 128-bit SSL encryption is expected. Constant advances in computer hardware, cryptanalysis and distributed brute force techniques may induce use of larger key lengths periodically. It is expected that banks will properly evaluate security requirements associated with their internet banking systems and other relevant systems and adopt an encryption solution that is commensurate with the degree of confidentiality and integrity required. Banks should only select encryption algorithms which are well established international standards and which have been subjected to rigorous scrutiny by an international cryptographer community or approved by authoritative professional bodies, reputable security vendors or government agencies.

Data security

Banks need to define and implement procedures to ensure the integrity and consistency of all data stored in electronic form, such as databases, data warehouses and data archives.

A data security theory seeks to establish uniform risk-based requirements for the protection of data elements. To ensure that the protection is uniform within and outside of the institution, tools such as data classifications and protection profiles can be used, as indicated earlier in the chapter.

Data classification and protection profiles are complex to implement when the network or storage is viewed as a utility. Because of that complexity, some institutions treat all information at that level as if it were of the highest sensitivity and implement encryption as a protective measure. The complexity in implementing data classification in other layers or in other aspects of an institution’s operation may result in other risk mitigation procedures being used. Adequacy is a function of the extent of risk mitigation, and not the procedure or tool used to mitigate risk.

Policies regarding media handling, disposal, and transit should be implemented to enable the use of protection profiles and otherwise mitigate risks to data. If protection profiles are not used, the policies should accomplish the same goal as protection profiles, which is to deliver the same degree of residual risk without regard to whether the information is in transit or storage, who is directly controlling the data, or where the storage may be.

There should be secure storage of media. Controls could include physical and environmental controls such as fire and flood protection, limiting access by means like physical locks, keypad, passwords, biometrics, etc., labelling, and logged access. Management should establish access controls to limit access to media, while ensuring that all employees have authorization to access the minimum data required to perform their responsibilities. More sensitive information such as system documentation, application source code, and production transaction data should have more extensive controls to guard against alteration (e.g., integrity checkers, cryptographic hashes). Furthermore, policies should minimize the distribution of sensitive information, including printouts that contain the information. Periodically, the security staff, audit staff, and data owners should review authorization levels and distribution lists to ensure they remain appropriate and current.

The storage of data in portable devices, such as laptops and PDAs, poses unique problems. Mitigation of those risks typically involves encryption of sensitive data, host-provided access controls, etc.

Banks need appropriate disposal procedures for both electronic and paper based media. Contracts with third-party disposal firms should address acceptable disposal procedures. For computer media, data frequently remains on media after erasure. Since that data can be recovered, additional disposal techniques should be applied to sensitive data like physical destruction, overwriting data, degaussing etc.

Banks should maintain the security of media while in transit or when shared with third parties. Policies should include contractual requirements that incorporate necessary risk-based controls, restrictions on the carriers used and procedures to verify the identity of couriers.

Banks should encrypt customer account and transaction data which is transmitted, transported, delivered or couriered to external parties or other locations, taking into account all intermediate junctures and transit points from source to destination.

A few other aspects that also needs to be considered include appropriate blocking, filtering and monitoring of electronic mechanisms like e-mail and printing and monitoring for unauthorised software and hardware like password cracking software, key loggers, wireless access points, etc.

Concerns over the need to better control and protect sensitive information have given rise to a new set of solutions aimed at increasing an enterprise’s ability to protect its information assets. These solutions vary in their capabilities and methodologies, but collectively they have been placed in a category known as data leak prevention (DLP). It provides a comprehensive approach covering people, processes, and systems that identify, monitor, and protect data in use (e.g., endpoint actions), data in motion (e.g., network actions), and data at rest (e.g., data storage) through deep content inspection and with a centralized management framework.

Most DLP solutions include a suite of technologies that facilitate three key objectives:

Locate and catalogue sensitive information stored throughout the enterprise

Monitor and control the movement of sensitive information across enterprise networks

Monitor and control the movement of sensitive information on end-user systems Banks may consider such solutions, if required, after assessing their potential to improve data security.

Vulnerability Assessment

Soon after new vulnerabilities are discovered and reported by security researchers or vendors, attackers engineer the malicious exploit code and then launch that code against targets of interest. Any significant delays in finding or fixing software with critical vulnerabilities provides ample opportunity for persistent attackers to break through, gaining control over the vulnerable machines and getting access to the sensitive data they contain. Banks that do not scan for vulnerabilities and address discovered flaws proactively face a significant likelihood of having their computer systems compromised.

The following are some of the measures suggested:

Automated vulnerability scanning tools need to be used against all systems on their networks on a periodic basis, say monthly or weekly or more frequently.

Banks should ensure that vulnerability scanning is performed in an authenticated mode (i.e., configuring the scanner with administrator credentials) at least quarterly, either with agents running locally on each end system to analyze the security configuration or with remote scanners that are given administrative rights on the system being tested, to overcome limitations of unauthenticated vulnerability scanning.

Banks should compare the results from back-to-back vulnerability scans to verify that vulnerabilities were addressed either by patching, implementing a compensating control, or by documenting and accepting a reasonable business risk. Such acceptance of business risks for existing vulnerabilities should be periodically reviewed to determine if newer compensating controls or subsequent patches can address vulnerabilities that were previously accepted, or if conditions have changed increasing the risk.

Vulnerability scanning tools should be tuned to compare services that are listening on each machine against a list of authorized services. The tools should be further tuned to identify changes over time on systems for both authorized and unauthorized services.

The security function should have updated status regarding numbers of unmitigated, critical vulnerabilities, for each department/division, plan for mitigation and should share vulnerability reports indicating critical issues with senior management to provide effective incentives for mitigation.

Establishing on-going security monitoring processes

 A bank needs to have robust monitoring processes in place to identify events and unusual activity patterns that could impact on the security of IT assets. The strength of the monitoring controls needs to be proportionate to the criticality of an IT asset. Alerts would need to be investigated in a timely manner, with an appropriate response determined.

 Common monitoring processes include activity logging (including exceptions to approved activity), for example, device, server, network activity, security sensor alerts; monitoring staff or third-party access to sensitive data/information to ensure it is for a valid business reason, scanning host systems for known vulnerabilities, checks to determine if information security controls are operating as expected and are being

complied with, checking whether powerful utilities / commands have been disabled on attached hosts by using tools like ‘network sniffer’), environment and customer profiling, checking for the existence and configuration of unauthorised wireless networks by using automated tools, discovering the existence of unauthorised systems by using network discovery and mapping tools and detecting unauthorised changes to electronic documents and configuration files by using file integrity monitoring software.

 Banks’ networks should be designed to support effective monitoring. Design considerations include network traffic policies that address the allowed communications between computers or groups of computers, security domains that implement the policies, sensor placement to identify policy violations and anomalous traffic, nature and extent of logging, log storage and protection and ability to implement additional sensors on an ad hoc basis when required.

 Banks would need to establish a clear allocation of responsibility for regular monitoring, and the processes and tools in this regard should be in a position to manage the volume of monitoring required, thereby reducing the risk of an incident going undetected.

 Highly sensitive and/or critical IT assets would need to have logging enabled to record events and monitored at a level proportional to the level of risk.

 Users, like system administrators, with elevated access privileges should be subjected to a greater level of monitoring in light of the heightened risks involved.

 The integrity of the monitoring logs and processes should be safeguarded through appropriate access controls and segregation of duties.

 Banks should frequently review all system accounts and disable any account that cannot be associated with a business process and business owner. Reports that may be generated from systems and reviewed frequently may include, among others, a list of locked out accounts, disabled accounts, accounts with passwords that exceed the maximum password age, and accounts with passwords that never expire.

 Banks should establish and follow a process for revoking system access by disabling accounts immediately upon termination of an employee or contractor.

 Banks should regularly monitor the use of all accounts, automatically logging off users after a standard period of inactivity.

 Banks should monitor account usage to determine dormant accounts that have not been used for a given period, say 15 days, notifying the user or user’s manager of the dormancy. After a longer period, say 30 days, the account may be disabled.

 On a periodic basis, say monthly or quarterly basis, banks should require that managers match active employees and contractors with each account belonging to their managed staff. Security/system administrators should then disable accounts that are not assigned to active employees or contractors.

 Banks should monitor attempts to access deactivated accounts through audit logging.

 Banks should validate audit log settings for each hardware device and the software installed on it, ensuring that logs include a date, timestamp, source addresses, destination addresses, and various other useful elements of each packet and/or transaction. Systems should record logs in a standardized format such as syslog entries. If systems cannot generate logs in a standardized format, banks need to deploy log normalization tools to convert logs into a standardized format.

 System administrators and information security personnel should consider devising profiles of common events from given systems, so that they can tune detection to focus on unusual activity, reducing false positives, more rapidly identify anomalies, and prevent overwhelming the analysts with insignificant alerts.

 The following technologies/factors provide capabilities for effective attack detection and analysis:

 Security Information and Event Management (SIEM) - SIEM products provide situational awareness through the collection, aggregation, correlation and analysis of disparate data from various sources. The information provided by these tools help in understanding the scope of an incident.

 Intrusion Detection and Prevention System (IDS and IPS) - IPS products that have detection capabilities should be fully used during an incident to limit any further impact on the organization. IDS and IPS products are often the primary source of information leading to the identification of an attack. Once the attack has been identified, it is essential to enable the appropriate IPS rule sets to block further incident propagation and to support containment and eradication.

 Network Behaviour Analysis (NBA) - Network wide anomaly-detection tools will provide data on traffic patterns that are indicative of an incident. Once an incident has been identified through the use of these tools, it is important to capture that information for the purposes of supporting further mitigation activities, including operational workflow to ensure that the information from these tools is routed to the appropriate response team.

 Managed Security Service Provider (MSSP) - If an organization has outsourced security event management to an MSSP, the latter should provide notification when an incident requires attention. Organisation must obtain as much information on the incident as possible from MSSP and implement remediation steps as recommended by MSSP.

 Banks also need to pro-actively monitor various authentic sources like CERT-In, security vendors, etc. for any security related advisories and take suitable measures accordingly.

 Security measures against Malware:

Malicious software is an integral and a dangerous aspect of internet based threats which target end-users and organizations through modes like web browsing, email attachments, mobile devices, and other vectors. Malicious code may tamper with a system's contents, and capture sensitive data. It can also spread to other systems. Modern malware aims to avoid signature-based and behavioral detection, and may disable anti-virus tools running on the targeted system. Anti-virus and anti-spyware software, collectively referred to as anti-malware tools, help defend against these threats by attempting to detect malware and block their execution.

Typical controls to protect against malicious code use layered combinations of technology, policies and procedures and training. The controls are of the preventive and detective/corrective in nature. Controls are applied at the host, network, and user levels:

At host level: The various measures at the host level include host hardening(including patch application and proper security configurations of the

operating system (OS), browsers, and other network-aware software), considering implementing host-based firewalls on each internal computer and especially laptops assigned to mobile users. Many host-based firewalls also have application hashing capabilities, which are helpful in identifying applications that may have been trojanized after initial installation, considering host IPS and integrity checking software combined with strict change controls and configuration management, periodic auditing of host configurations, both manual and automated.

At network level: The various measures include limiting the transfer of executable files through the perimeter, IDS and IPS monitoring of incoming and outgoing network traffic, including anti-virus, anti-spyware and signature and anomaly-based traffic monitors, routing Access Control Lists(ACLs) that limit incoming and outgoing connections as well as internal connections to those necessary for business purposes, proxy servers that inspect incoming and outgoing packets for indicators of malicious code and block access to known or suspected malware distribution servers, filtering to protect against attacks such as cross-site scripting and SQL injection.

At user level: User education in awareness, safe computing practices, indicators of malicious code, and response actions.

Enterprise security administrative features may be used daily to check the number of systems that do not have the latest anti-malware signatures. All malware detection events should be sent to enterprise anti-malware administration tools and event log servers.

Banks should employ anti-malware software and signature auto update features to automatically update signature files and scan engines whenever the vendor publishes updates. After applying an update, automated systems should verify that each system has received its signature update. The bank should monitor anti-virus console logs to correct any systems that failed to be updated. The systems deployed for client security should be delivering simplified administration through central management and providing critical visibility into threats and vulnerabilities. It should also integrate with existing infrastructure software, such as Active Directory for enhanced protection and greater control.

Administrators should not rely solely on AV software and email filtering to detect worm infections. Logs from firewalls, intrusion detection and prevention sensors, DNS servers and proxy server logs should be monitored on a daily basis for signs of worm infections including but not limited to:

Outbound SMTP connection attempts from anything other than a bank’s SMTP mail gateways

Excessive or unusual scanning on TCP and UDP ports 135-139 and 445

Connection attempts on IRC or any other ports that are unusual for the environment

Excessive attempts from internal systems to access non-business web sites

Excessive traffic from individual or a group of internal systems

Excessive DNS queries from internal systems to the same host name and for known “nonexistent” host names. Using a centralized means such as a syslog host to collect logs from various devices and systems can help in the analysis of the information

Banks should configure laptops, workstations, and servers so that they do not auto-run content from USB tokens, USB hard drives, CDs/DVDs, external SATA devices, mounted network shares, or other removable media.

Banks should configure systems so that they conduct an automated antimalware scan of removable media when it is inserted.

Banks can also consider deploying the Network Access Control (NAC) tools to verify security configuration and patch level compliance of devices before granting access to a network. Network Admission Control (NAC) restricts access to the network based on the identity or security posture of an organization. When NAC is implemented, it will force a user or a machine seeking network access for authentication prior to granting actual access to the network. A typical (non-free) WiFi connection is a form of NAC. The user must present some sort of credentials (or a credit card) before being granted access to the network. The network admission control systems allow noncompliant devices to be denied access, placed in a quarantined area, or given restricted access to computing resources, thus keeping insecure nodes from infecting the network. The key component of the Network Admission Control program is the Trust Agent, which resides on an endpoint system and communicates with routers on the network. The information is then relayed to a Secure Access Control Server (ACS) where access control decisions are made. The ACS directs the router to perform enforcement against the endpoint.

Email Attachment Filtering - Banks should filter various attachment types at the email gateway, unless required for specific business use. Some examples include .ade .cmd

.eml .ins .mdb .mst .reg .url .wsf .adp .com .exe .isp .mde .pcd .scr .vb .wsh .bas .cpl

.hlp .js .msc .pif .sct .vbe .bat .crt .hta .jse .msi .pl .scx .vbs .chm .dll .inf.lnk .msp .pot

.shs .wsc… etc. Banks should consider only allowing file extensions with a documented business case and filtering all others.

Patch Management:

A Patch Management process needs to be in place to address technical system and software vulnerabilities quickly and effectively in order to reduce the likelihood of a serious business impact arising.

There should be documented standards / procedures for patch management. The standards / procedures for patch management should include a method of defining roles and responsibilities for patch management, determining the importance of systems (for e.g., based on the information handled, the business processes supported and the environments in which they are used) , recording patches that have been applied (for e.g., using an inventory of computer assets including their patch level).

The patch management process should include aspects like:

Determining methods of obtaining and validating patches for ensuring that the patch is from an authorised source

Identifying vulnerabilities that are applicable to applications and systems used by the organisation

Assessing the business impact of implementing patches (or not implementing a particular patch)

Ensuring patches are tested

Describing methods of deploying patches, for example, through automated manner

Reporting on the status of patch deployment across the organisation

Including methods of dealing with the failed deployment of a patch (e.g., redeployment of the patch).

Methods should be established to protect information and systems if no patch is available for an identified vulnerability, for example, disabling services and adding additional access controls.Organizations should deploy automated patch management tools and software update tools for all systems for which such tools are available and safe.

Organizations should measure the delay in patching new vulnerabilities and ensure the delay is not beyond the benchmarks set forth by the organization, which should be less for critical patches, say not more than a week, unless a mitigating control that blocks exploitation is available.

Critical patches must be evaluated in a test environment before being updated into production on enterprise systems. If such patches break critical business applications on test machines, the organization must devise other mitigating controls that block exploitation on systems where the patch is difficult to be deployed because of its impact on business functionality.

Change Management:

A change management process should be established, which covers all types of change. For example, upgrades and modifications to application and software, modifications to business information, emergency ‘fixes’, and changes to the computers / networks that support the application.

The change management process should be documented, and include approving and testing changes to ensure that they do not compromise security controls, performing changes and signing them off to ensure they are made correctly and securely, reviewing completed changes to ensure that no unauthorised changes have been made.

The following steps should be taken prior to changes being applied to the live environment:

Change requests should be documented (e.g., on a change request form) and accepted only from authorised individuals and changes should be approved by an appropriate authority

The potential business impacts of changes should be assessed (for e.g., in terms of the overall risk and impact on other components of the application)

Changes should be tested to help determine the expected results (for e.g., deploying the patch into the live environment)

Changes should be reviewed to ensure that they do not compromise security controls (e.g., by checking software to ensure it does not contain malicious code, such as a trojan horse or a virus)

Back-out positions should be established so that the application can recover from failed changes or unexpected results

Changes to the application should be performed by skilled and competent individuals who are capable of making changes correctly and securely and signed off by an appropriate business official.

Audit trails

Banks needs to ensure that audit trails exist for IT assets satisfying the banks business requirements including regulatory and legal requirements, facilitating audit, serving as forensic evidence when required and assisting in dispute resolution. This could include, as applicable, various areas like transaction with financial consequences, the opening, modifications or closing of customer accounts, modifications in sensitive master data, accessing or copying of sensitive data/information; and granting, modification or revocation of systems access rights or privileges for accessing sensitive IT assets.

Audit trails should be secured to ensure the integrity of the information captured, including the preservation of evidence. Retention of audit trails should be in line with business, regulatory and legal requirements.

Some considerations for securing the integrity of log files include :

Encrypting log files that contain sensitive data or that are transmitting over the network

Ensuring adequate storage capacity to avoid gaps in data gathering

Securing back-up and disposal of log files

Logging the data to write-only media like a write-once/read-many (WORM) disk or drive

Setting logging parameters to disallow any modification to previously written data

As indicated earlier, network and host activities typically are recorded on the host and sent across the network to a central logging facility which may process the logging data into a common format. The process, called normalization, enables timely and effective log analysis.

Other aspects related to logging to be considered include:

All remote access to an internal network, whether through VPN, dial-up, or other mechanism, should be logged verbosely

Operating systems should be configured to log access control events associated with a user attempting to access a resource like a file or directory without the appropriate permissions

Security personnel and/or administrators designated in this regard should identify anomalies in logs and actively review the anomalies, documenting their findings on an ongoing basis