Incident response plans 1 to 3 paragraphs (non technical) that discuss: • • • • • • • • • • • Selecting team members Define roles, responsibilities and lines of authority Define a security incident Define a reportable incident Training Detection Classification Escalation Containment Eradication Documentation Change management Change management is a formal process for directing and controlling alterations to the information processing environment.
This includes alterations to desktop computers, the network, servers and software.
The objectives of change management are to reduce the risks posed by changes to the information processing environment and improve the stability and reliability of the processing environment as changes are made.
It is not the objective of change management to prevent or hinder necessary changes from being implemented.
Any change to the information processing environment introduces an element of risk.
Even apparently simple changes can have unexpected effects.
One of Managements many responsibilities is the management of risk.
Change management is a tool for managing the risks introduced by changes to the information processing environment.
Part of the change management process ensures that changes are not implemented at inopportune times when they may disrupt critical business processes or interfere with other changes being implemented.
Not every change needs to be managed.
Some kinds of changes are a part of the everyday routine of information processing and adhere to a predefined procedure, which reduces the overall level of risk to the processing environment.
Creating a new user account or deploying a new desktop computer are examples of changes that do not generally require change management.
However, relocating user file shares, or upgrading the Email server pose a Information security much higher level of risk to the processing environment and are not a normal everyday activity.
The critical first steps in change management are (a) defining change (and communicating that definition) and (b) defining the scope of the change system.
Change management is usually overseen by a Change Review Board composed of representatives from key business areas, security, networking, systems administrators, Database administration, applications development, desktop support and the help desk.
The tasks of the Change Review Board can be facilitated with the use of automated work flow application.
The responsibility of the Change Review Board is to ensure the organizations documented change management procedures are followed.
The change management process is as follows: • Requested: Anyone can request a change.
The person making the change request may or may not be the same person that performs the analysis or implements the change.
When a request for change is received, it may undergo a preliminary review to determine if the requested change is compatible with the organizations business model and practices, and to determine the amount of resources needed to implement the change. • Approved: Management runs the business and controls the allocation of resources therefore, Management must approve requests for changes and assign a priority for every change.
Management might choose to reject a change request if the change is not compatible with the business model, industry standards or best practices.
Management might also choose to reject a change request if the change requires more resources than can be allocated for the change. • Planned: Planning a change involves discovering the scope and impact of the proposed change; analyzing the complexity of the change; allocation of resources and, developing, testing and documenting both implementation and backout plans.
Need to define the criteria on which a decision to back out will be made. • Tested: Every change must be tested in a safe test environment, which closely reflects the actual production environment, before the change is applied to the production environment.
The backout plan must also be tested. • Scheduled: Part of the change review board’s responsibility is to assist in the scheduling of changes by reviewing the proposed implementation date for potential conflicts with other scheduled changes or critical business activities. • Communicated: Once a change has been scheduled it must be communicated.
The communication is to give others the opportunity to remind the change review board about other changes or critical business activities that might have been overlooked when scheduling the change.
The communication also serves to make the Help Desk and users aware that a change is about to occur.
Another responsibility of the change review board is to ensure that scheduled changes have been properly communicated to those who will be affected by the change or otherwise have an interest in the change. • Implemented: At the appointed date and time, the changes must be implemented.
Part of the planning process was to develop an implementation plan, testing plan and, a back out plan.
If the implementation of the change should fail or, the post implementation testing fails or, other “drop dead” criteria have been met, the back out plan should be implemented. • Documented: All changes must be documented.
The documentation includes the initial request for change, its approval, the priority assigned to it, the implementation, testing and back out plans, the results of the change review board critique, the date/time the change was implemented, who implemented it, and whether the change was implemented successfully, failed or postponed. • Post change review: The change review board should hold a post implementation review of changes.
It is particularly important to review failed and backed out changes.
The review board should try to understand the problems that were encountered, and look for areas for improvement.
Change management procedures that are simple to follow and easy to use can greatly reduce the overall risks created when changes are made to the information processing environment.
Good change management procedures improve the over all quality and success of changes as they are implemented.
This is accomplished through planning, peer 213 Information security review, documentation and communication.
ISO/IEC 20000, The Visible OPS Handbook: Implementing ITIL in 4 Practical and Auditable Steps  (Full book summary ), and Information Technology Infrastructure Library all provide valuable guidance on implementing an efficient and effective change management program.
Information security 214 Business continuity Business continuity is the mechanism by which an organization continues to operate its critical business units, during planned or unplanned disruptions that affect normal business operations, by invoking planned and managed procedures.
Unlike what most people think business continuity is not necessarily an IT system or process, simply because it is about the business.
Today disasters or disruptions to business are a reality.
Whether the disaster is natural or man-made, it affects normal life and so business.
So why is planning so important? Let us face reality that “all businesses recover”, whether they planned for recovery or not, simply because business is about earning money for survival.
The planning is merely getting better prepared to face it, knowing fully well that the best plans may fail.
Planning helps to reduce cost of recovery, operational overheads and most importantly sail through some smaller ones effortlessly.
For businesses to create effective plans they need to focus upon the following key questions.
Most of these are common knowledge, and anyone can do a BCP. 1.
Should a disaster strike, what are the first few things that I should do? Should I call people to find if they are OK or call up the bank to figure out my money is safe? This is Emergencey Response.
Emergency Response services help take the first hit when the disaster strikes and if the disaster is serious enough the Emergency Response teams need to quickly get a Crisis Management team in place. 2.
What parts of my business should I recover first? The one that brings me most money or the one where I spend the most, or the one that will ensure I shall be able to get sustained future growth? The identified sections are the critical business units.
There is no magic bullet here, no one answer satisfies all.
Businesses need to find answers that meet business requirements. 3.
How soon should I target to recover my critical business units? In BCP technical jargon this is called Recovery Time Objective, or RTO.
This objective will define what costs the business will need to spend to recover from a disruption.
For example, it is cheaper to recover a business in 1 day than in 1 hour. 4.
What all do I need to recover the business? IT, machinery, records…food, water, people…So many aspects to dwell upon.
The cost factor becomes clearer now…Business leaders need to drive business continuity.
My IT manager spent $200000 last month and created a DRP (Disaster Recovery Plan), whatever happened to that? a DRP is about continuing an IT system, and is one of the sections of a comprehensive Business Continuity Plan.
Look below for more on this. 5.
And where do I recover my business from…
Will the business center give me space to work, or would it be flooded by many people queuing up for the same reasons that I am. 6.
But once I do recover from the disaster and work in reduced production capacity, since my main operational sites are unavailable, how long can this go on.
How long can I do without my original sites, systems, people? this defines the amount of business resilience a business may have. 7.
Now that I know how to recover my business.
How do I make sure my plan works? Most BCP pundits would recommend testing the plan at least once a year, reviewing it for adequacy and rewriting or updating the plans either annually or when businesses change. Information security 215 Disaster recovery planning While a business continuity plan (BCP) takes a broad approach to dealing with organizational-wide effects of a disaster, a disaster recovery plan (DRP), which is a subset of the business continuity plan, is instead focused on taking the necessary steps to resume normal business operations as quickly as possible.
A disaster recovery plan is executed immediately after the disaster occurs and details what steps are to be taken in order to recover critical information technology infrastructure. Laws and regulations Below is a partial listing of European, United Kingdom, Canadian and USA governmental laws and regulations that have, or will have, a significant effect on data processing and information security.
Important industry sector regulations have also been included when they have a significant impact on information security. • UK Data Protection Act 1998 makes new provisions for the regulation of the processing of information relating to individuals, including the obtaining, holding, use or disclosure of such information.
The European Union Data Protection Directive (EUDPD) requires that all EU member must adopt national regulations to standardize the protection of data privacy for citizens throughout the EU. • The Computer Misuse Act 1990 is an Act of the UK Parliament making computer crime (EG
Cracking sometimes incorrectly referred to as hacking) a criminal offence.
The Act has become a model upon which several other countries including Canada and the Republic of Ireland have drawn inspiration when subsequently drafting their own information security laws. • EU Data Retention laws requires Internet service providers and phone companies to keep data on every electronic message sent and phone call made for between six months and two years. • The Family Educational Rights and Privacy Act (FERPA) (20 U.S.C. § 1232  g; 34 CFR Part 99) is a USA Federal law that protects the privacy of student education records.
The law applies to all schools that receive funds under an applicable program of the U.S.
Department of Education.
Generally, schools must have written permission from the parent or eligible student in order to release any information from a student’s education record. • Health Insurance Portability and Accountability Act (HIPAA) of 1996 requires the adoption of national standards for electronic health care transactions and national identifiers for providers, health insurance plans, and employers.
And, it requires health care providers, insurance providers and employers to safeguard the security and privacy of health data. • Gramm-Leach-Bliley Act of 1999 (GLBA), also known as the Financial Services Modernization Act of 1999, protects the privacy and security of private financial information that financial institutions collect, hold, and process. • Sarbanes-Oxley Act of 2002 (SOX).
Section 404 of the act requires publicly traded companies to assess the effectiveness of their internal controls for financial reporting in annual reports they submit at the end of each fiscal year.
Chief information officers are responsible for the security, accuracy and the reliability of the systems that manage and report the financial data.
The act also requires publicly traded companies to engage independent auditors who must attest to, and report on, the validity of their assessments. • Payment Card Industry Data Security Standard (PCI DSS) establishes comprehensive requirements for enhancing payment account data security.
It was developed by the founding payment brands of the PCI Security Standards Council, including American Express, Discover Financial Services, JCB, MasterCard Worldwide and Visa International, to help facilitate the broad adoption of consistent data security measures on a global basis.
The PCI DSS is a multifaceted security standard that includes requirements for security management, policies, procedures, network architecture, software design and other critical protective measures. — References  http:/ / www.
Com/ blog/ storage/ how-to-really-erase-a-hard-drive-update/ 148  Tutorial on Disk Drive Data Sanitization (http:/ / cmrr.
Edu/ people/ Hughes/ DataSanitizationTutorial.
Pdf) Gordon Hughes, UCSD Center for Magnetic Recording Research, Tom Coughlin, Coughlin Associates  “Special Publication 800-88: Guidelines for Media Sanitization” (http:/ / csrc.
Gov/ publications/ nistpubs/ 800-88/ NISTSP800-88_rev1.
September 2006. .
Retrieved 2008-11-09. (542 KB) • RCMP Lead Agency Publication B2-001, Technical Security Branch, IT Security Bulletin (www.
Rcmp-grc.gc.ca/tsb/pubs/it_sec/b2-001_e.pdf) External links • Secure Erase (cmrr.ucsd.edu/people/Hughes/SecureErase.shtml) Holistic Information Security Practitioner The Holistic Information Security Practitioner certification course is an integration course that provides practical education on the integration of best practices for Information Security Management, Information Systems Auditing, and multiple Regulatory Compliance requirements as well as how to map multiple regulatory requirements to the internationally accepted framework of ISO/IEC 27002.
The class introduces ISO/IEC 27002:2005, CobiT, COSO and ITIL, and then explains a methodology to map regulations such as Data Protection Act 1998 (UK), EU Directive on Privacy, Basel II, HIPAA, FFIEC, GLB Act, FIPS 200, Sarbanes-Oxley, FACT Act, PCI Data Security, California SB 1386, OSFI, PIPEDA, PIPA, Canadian Bill C-168 to the ISO 27002 framework.
The HISP Certification Course was originally authored by eFortresses, Inc.: an Atlanta, Georgia based risk management company, specializing in Information Security and Regulatory Compliance.
The training aspect of the HISP Certification Course is delivered by eFortresses and a number of authorized training partners including BSI Management Systems, however the certification aspect is handled by the HISP Institute , an independently run organization. Holistic Information Security Practitioner 652 External links • HISP Certification Course  • HISP Institute  References  http:/ / www.
Org/  http:/ / www.
Org  http:/ / www.
Org Identity Commandments The Jericho Forum® Identity, Entitlement & Access Management (IdEA) Commandments define principles that must be observed when planning an identity eco-system.
Whilst building on “good practice”, these commandments specifically address those areas that will allow “identity” processes to operate on a global, de-perimeterised scale; this necessitates open and interoperable standards and a commitment to implement such standards by both identity providers and identity consumers.
The IdEA commandments serve as a benchmark by which Identity, Entitlement and Access Management concepts, solutions, standards and systems can be assessed and measured.
They are supported by a Jericho Forum IdEA Glossary and other related documents.
They also build on the higher level Jericho Forum Commandments, in particular Commandments 2, 8, 9 and 10.
The Jericho Forum Identity commandments are issued under a creative commons license and can be found here: www.opengroup.org/jericho/Jericho Forum Identity Commandments v1.0.pdf  External links — Information security management system An information security management system (ISMS) is a set of policies concerned with information security management or IT related risks.
The idioms arose primarily out of ISO 27001.
The governing principle behind an ISMS is that an organization should design, implement and maintain a coherent set of policies, processes and systems to manage risks to its information assets, thus ensuring acceptable levels of information security risk. Plan-Do-Check-Act Cycle ISMS description As with all management processes, an ISMS must remain effective and efficient in the long term, adapting to changes in the internal organization and external environment.
ISO/IEC 27001 therefore incorporates the typical “Plan-Do-Check-Act” (PDCA), or Deming cycle, approach: • The Plan phase is about designing the ISMS, assessing information security risks and selecting appropriate controls. • The Do phase involves implementing and operating the controls. • The Check phase objective is to review and evaluate the performance (efficiency and effectiveness) of the ISMS. • In the Act phase, changes are made where necessary to bring the ISMS back to peak performance. ENISA: Risk Management and Isms activities Information security management system The best known ISMS is described in ISO/IEC 27001 and ISO/IEC 27002 and related standards published jointly by ISO and IEC.
Another competing ISMS is Information Security Forum’s Standard of Good Practice (SOGP).
It is more best practice-based as it comes from ISF’s industry experiences.
Other frameworks such as COBIT and ITIL touch on security issues, but are mainly geared toward creating a governance framework for information and IT more generally.
COBIT has a companion framework Risk IT dedicated to Information security.
There are a number of initiatives focused to the governance and organizational issues of securing information systems having in mind that it is business and organizational problem, not only a technical problem: • Federal Information Security Management Act of 2002 is a United States federal law enacted in 2002 that recognized the importance of information security to the economic and national security interests of the United States. The act requires each federal agency to develop, document, and implement an agency-wide program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source.  • Governing for Enterprise Security Implementation Guide  of the Carnegie Mellon University Software Engineering Institute CERT is designed to help business leaders implement an effective program to govern information technology (IT) and information security.
Our objective is to help you make well informed decisions about many important components of GES such as adjusting organizational structure, designating roles and responsibilities, allocating resources (including security investments), managing risks, measuring results, and gauging the adequacy of security audits and reviews.
The intent in elevating security to a governance-level concern is to foster attentive, security-conscious leaders who are better positioned to protect an organization’s digital assets, its operations, its market position, and its reputation. • A Capability Maturity Model for system security engineering was standardized in ISO/IEC_21827. • Information Security Management Maturity Model (known as ISM-cubed or ISM3) is another form of ISMS.
ISM3 builds on standards such as ISO 20000, ISO 9001, CMM, ISO/IEC 27001, and general information governance and security concepts.
ISM3 can be used as a template for an ISO 9001-compliant ISMS.
While ISO/IEC 27001 is controls based, ISM3 is process based and includes process metrics.
ISM3 is a standard for security management (how to achieve the organizations mission despite of errors, attacks and accidents with a given budget).
The difference between ISM3 and ISO/IEC 21827 is that ISM3 is focused on management, ISO 21287 on Engineering. 660 Need for a ISMS Security experts say and statistics confirm that: • information technology security administrators should expect to devote approximately one-third of their time addressing technical aspects.
The remaining two-thirds should be spent developing policies and procedures, performing security reviews and analyzing risk, addressing contingency planning and promoting security awareness; • security depends on people more than on technology; • employees are a far greater threat to information security than outsiders; • security is like a chain.
It is as strong as its weakest link; • the degree of security depends on three factors: the risk you are willing to take, the functionality of the system and the costs you are prepared to pay; • security is not a status or a snapshot but a running process.
These facts inevitably lead to the conclusion that: Security administration is a management and NOT a purely technical issue Information security management system The establishment, maintenance and continuous update of an ISMS provide a strong indication that a company is using a systematic approach for the identification, assessment and management of information security risks.
Furthermore such a company will be capable of successfully addressing information confidentiality, integrity and availability requirements which in turn have implications for:  • • • • • • business continuity; minimization of damages and losses; competitive edge; profitability and cash-flow; respected organization image; legal compliance 661 Chief objective of Information Security Management is to implement the appropriate measurements in order to eliminate or minimize the impact that various security related threats and vulnerabilities might have on an organization.
In doing so, Information Security Management will enable implementing the desirable qualitative characteristics of the services offered by the organization (IE
Availability of services, preservation of data confidentiality and integrity etc.). Large organizations or organizations such as banks and financial institutes, telecommunication operators, hospital and health institutes and public or governmental bodies have many reasons for addressing information security very seriously.
Legal and regulatory requirements which aim at protecting sensitive or personal data as well as general public security requirements impel them to devote the utmost attention and priority to information security risks. Under these circumstances the development and implementation of a separate and independent management process namely an Information Security Management System is the one and only alternative. As shown in Figure, the development of an ISMS framework entails the following 6 steps: 1. 2. 3. 4. 5. 6.
Definition of Security Policy, Definition of ISMS Scope, Risk Assessment (as part of Risk Management), Risk Management, Selection of Appropriate Controls and Statement of Applicability Critical success factors for ISMS To be effective, the ISMS must: • have the continuous, unshakeable and visible support and commitment of the organization’s top management; • be managed centrally, based on a common strategy and policy across the entire organization; • be an integral part of the overall management of the organization related to and reflecting the organization’s approach to Risk Management, the control objectives and controls and the degree of assurance required; • have security objectives and activities be based on business objectives and requirements and led by business management; • undertake only necessary tasks and avoiding over-control and waste of valuable resources; • fully comply with the organization philosophy and mindset by providing a system that instead of preventing people from doing what they are employed to do, it will enable them to do it in control and demonstrate their fulfilled accountabilities; • be based on continuous training and awareness of staff and avoid the use of disciplinary measures and “police” or “military” practices; • be a never ending process; — SLM is related to the disciplines of Security and Security Event management (SIEM), which the analysts Gartner summarise in their Magic Quadrant for Security Information and Event Management, and define as follows: “[…] SIM provides reporting and analysis of data primarily from host systems and applications, and secondarily from security devices — to support security policy compliance management, internal threat management and regulatory compliance initiatives.
SIM supports the monitoring and incident management activities of the IT security organization […].
SEM improves security incident response capabilities.
SEM processes near-real-time data from security devices, network devices and systems to provide real-time event management for security operations. […]” SIM and SEM relate to the infrastructure for realising superordinate security aims, but are not descriptive of a strategic management system with aims, measures, revisions and actions to be derived from this.
SLM unites the requisite steps for realising a measurable, functioning IT security structure in a management control cycle.
SLM can be categorised under the strategic panoply of IT governance, which, via suitable organisation structures and processes, ensures that IT supports corporate strategy and objectives.
SLM allows CSOs, CIOs and CISOs to prove that SLM is contributing towards protecting electronic data relevant to processes adequately, and therefore makes a contribution in part to IT governance. The Steps towards SLM Defining the Security Level (Plan): Each company specifies security policies.
The executive management defines aims in relation to the integrity, confidentiality, availability and authority of classified data.
In order to be able to verify compliance with these specifications, concrete aims for the individual security systems at the company need to be derived from the abstract security policies.
A security level consists of a collection of measurable limiting and threshold values.
Example: operative aims like “the anti-virus systems at our UK sites need to be up-to-date no longer than four hours after publication of the current definition” need to be derived from superordinate security policies like “our employees should be able to work without being interrupted.” Limiting and threshold values are to be specified separately and individually for different sites, locations and countries, because the IT infrastructure on-site and any other local determining factors need to be taken into consideration.
Example: office buildings in the UK are normally equipped with high-speed dedicated lines.
It is wholly realistic here to limit the deadline for supplying all computers with the newest anti-virus definitions to a few hours.
For a Security level management factory in Asia, with a slow modem link to the web, a realistic limiting value would have to be set that is somewhat higher.
The IT control manual Control Objectives for Information and Related Technology Cobit (CobiT) provides companies with instructions on transposing subordinate, abstract aims into measurable aims in a few steps.
Collecting and Analysing Data (Do):Information on the current status of the systems can be gleaned from the log file and status reports provided by individual anti-virus, anti-spyware or anti-spam consoles.
Monitoring and reporting solutions analysing software applications from all software houses can simplify and accelerate data collection.
Checking the Security Level (Check): SLM prescribes continual reconciliation of the defined security level with the current measured values.
Automated real-time reconciliation supplies companies with a permanent status report on the security status across all locations.
Adjusting the Security Structure (Act): Efficient SLM allows trend analyses and long-term comparative assessments to be made.
Through the rolling observation of the security level, weak spots in the network can be identified early on and appropriate adjustments made proactively in the security systems. 703 External links • COBIT: • Summary and material from the German Chapter of the ISACA – German  • 4.0 Deutsch.pdf Cobit 4.0 – German  • ISO/IEC 27000 • The ISO 27000 Directory  • International Organization for Standardization  • ITIL • “ITIL and Information Security” (ITIL und Informationssicherheit), Federal Office for Information Security (BSI), Germany – German  • “How ITIL can improve Information Security”, securityfocus.com – English  • Official ITIL website of the British Office of Government Commerce – English  References        http:/ / www.
De/ http:/ / www.
At/ Ressourcen/ CobiT http:/ / www.27000.
Org/ http:/ / www.
Org/ http:/ / www.
De/ literat/ studien/ ITinf/ itil.
Pdf http:/ / www.
Com/ infocus/ 1815 http:/ / www.
Asp Security of automated teller machines 704 Security of automated teller machines Automated Teller Machines were first used in 1939.
Nowadays, about 1.5 million are installed worldwide .
In the consideration of ATM, there are different aspects that should be considered.
First, one has to have an idea about the communication within ATMs.
Second, the issue of security is of paramount importance because all over the world, there is an increasing use of ATMs and so the risks of hacking turn to be a reality more than ever before.
In the past, the function of ATMs was to deliver cash in the form of bank notes and to debit a corresponding bank account.
Cards were used to identify the user.
As for the withdrawal of money, different methods were used.
For instance, punched cards were used.
By the use of such cards, only one payment was authorized.
Thereby, a user had to get a supply of cards from his/her bank because the punched cards were not returned to the user.
Another example was the use of a magnetic card which had a limited life.
The use of such cards allowed; for instance, twenty withdrawals of money.
From the beginning, personal identification number (PIN) has been of very great importance in the overall operation.
Davies & W.
Security for computer networks : an introduction to data security in teleprocessing and electronic funds transfer.
The use of it has been done with the aim to decrease the risks that might result from the loss of cards and the misuses that might be connected to that.
In fact, in the past as well as in the present, there have been different aspects in the consideration of the designing and the communicative basics of Automated Teller Machines.
One aspect of it has been how communication between its participants could be possible .
The second of it has been to take into consideration the purposes which could be a part and a parcel of any communicative act.
In this context, there are different participants involved in ATMs communication.
To cite but a few of them, in an ATM communication, there are remote partners and interfaces to the outside world and these interfaces are in their turn subject to more than one classification.
The first interface represents the relationship between the End-user and Automated Teller Machine.
The second interface occurs between the ATM and the central bank computer. Protection of Communication  PIN validation, Management and Algorithmic Checking The method of checking relies on an algorithm which is typically a cipher Cipher with a secret key.
PIN Validation for local Transactions On-Line PIN Validation The validation of on-line PIN occurs if the terminal in question is connected to the central data base.
The customer’s entered PIN is always compared against as in the financial institutions recorded PIN of reference.
Off-Line PIN Validation In off-line PIN validation, the ATM is not connected to the central data base.
A condition for off-line PIN validation is that the ATM should be able to compare the customer’s entered PIN against the PIN of reference.
The terminal must be able to perform cryptographic operations and it must have at its disposal the required encryption keys its very slow Security of automated teller machines PIN Validation for Interchange Transactions There are three PIN procedures for the operation of a high secure interchange transaction.
PIN is encrypted at the entry terminal, a secret cryptographic key is used.
In addition to other transaction elements, the encrypted PIN is transmitted to the acquirer’s system.
Second the encrypted PIN is routed from the acquirer’s system to a Hardware Security Module.
Within it, with the use of the cryptographic key of the terminal, the PIN will be decrypted.
With a cryptographic key used for interchange, the decrypted key will be immediately reencrypted and will be routed to the issuer’s system over normal communications channels.
Third, the routed PIN will be decrypted in the issuer’s security module and then validated on the basis of the techniques for on-line local PIN validation.
Shared ATMs  There are different methods used in shared ATMs with regards to the encipherment of PIN and message authentication among them is the so called “ZONE ENCRYPTION”.
In this method, a trustful authority is appointed to operate on behalf of a group of banks so as they could interchange messages for ATM payment approvals. 705
Read more about ITIL : ISO IEC 20000 The Visible OPS Handbook Implementing ITIL in….: