Spotlight on Mainframe Security: Data Authenticity and Endpoint Security

Transcription

1 Spotlight on Mainframe Security: Data Authenticity and Endpoint Security P K W A R E W H I T E P A P E R WP 700.xxxx

2 Table of Contents Cloud Computing and the Mainframe 3 Different Kinds of Clouds and the Mainframe 4 The Cloud and Man-in-the-middle Attacks 4 Defeating Man-in-the-middle Attacks 5 Conclusion 7 2

3 Spotlight on Mainframe Security: Data Authenticity and Endpoint Security Mainframe modernization via Service-Oriented Architecture (SOA) and other means introduces certain risks to the quality and accuracy of data. Even though the mainframe has the most durable protections in the industry, necessary integration with small platform systems in order to provide user productivity interfaces opens the door to man-in-the-middle attacks and other threats far beyond those contemplated in the system s initial design. Market needs for improved operational efficiency and quicker time-to-market compels modernization in all of its forms, particularly through web application integration. IBM clearly recognizes this, as demonstrated in the recent release of the Solution Edition for the IBM System z Enterprise Linux Server. This offering provides a System z10 with no z/os running on it, simply z/vm with SUSE or Red Hat guests. The fact that IBM is packaging a mainframe without its flagship operating system sheds light on the fact that the mainframe is now just another server in your data center, with all the network connectivity, integration points, and risks of any other server. Twenty years ago, the mainframe was liquid-cooled and sat on a raised floor in the data center, physically protected by a series of badge readers with a limited network and well-defined 3270 end points. Now, the air-cooled mainframe can sit on a non-raised floor, serving web pages to anyone on the Internet, anywhere. In fact, more and more organizations are using the mainframe for just that purpose, since it remains superior in regard to Reliability, Availability, and Serviceability (RAS). It also offers efficiencies in power and workload management, when compared to smaller platforms. SOA provides a framework for distributed applications provisioned from the mainframe. No longer are missioncritical applications wholly resident within the protected application space of the traditional mainframe processing environment. Today, applications based on services rely on the Internet, or the internal network of an organization, for access to functions that once were contained within the boundaries of a single machineresident application. This change moves access to applications beyond the data center or organizational perimeter and extends processing capability globally through the spectrum of public, private, and hybrid clouds. Cloud Computing and the Mainframe Cloud computing is a huge buzz word in the industry today; those most experienced and familiar with the mainframe can be justifiably skeptical that a new concept has been introduced. It seems more like a variation of something else that has long existed within mainframe computing. For example, virtualization is not new; it has been around on the mainframe since the late 1960s. On closer inspection by the seasoned mainframe executive, the paradigm of cloud computing seems more of an evolutionary change than the over-hyped revolutionary change touted by some pundits. 3

4 Mainframe modernization, however, is likely to play a big role in cloud computing, as the mainframe already performs many of the services required by effective cloud computing: Software as a Service (SaaS) the application is hosted on the mainframe. Customer Information Control System (CICS) has been doing this for years. In today s paradigm, SaaS usually refers to applications delivered through a browser, which the mainframe ably serves via WebSphere on z/os or zlinux. Infrastructure as a Service (IaaS) a virtual server and storage are provided in a hosted environment, much like you find with guests on z/vm. This is a very common use case with z/os and zlinux. Platform as a Service (PaaS) desktop or server images are provided remotely. As with the previous examples, this concept traces back to the early 1970s mainframe shared computing. PaaS typically includes the development, testing, deployment, and hosting of the service; in contemporary terms it includes development, testing, and deployment over the web, again through z/os and zlinux. Different Kinds of Clouds and the Mainframe How services are provided, and by whom, defines the type of cloud that is being used: public, private, or hybrid cloud. Public Cloud A public cloud is where services are provided outside the organization, hosted by the data center of a third party, on infrastructure that is [almost always] shared by other customers. The provider of the services gains economies of scale that translate into reduced costs to customers, with the offset of reduced direct control. There are many additional advantages of using public cloud services. Organizations may require specific services to meet their business requirements that lie outside their core competencies, such as the customer relationship management automation needs of a hard goods manufacturer. A provider that focuses on delivering those services is going to be better equipped to do so than an organization whose core business is selling finished goods. Enterprises can take advantage of those services, the richness of their functionality, and the lower cost basis public cloud service provides, while still continuing to focus on their core business. Examples of public cloud services include Amazon S3, Google Docs, and Salesforce. Private Cloud A private cloud, then, is defined as cloud services delivered from within the organization s own data center for its own exclusive use. Private cloud provisioning may be somewhat more expensive, but holds the benefits of improved ability to provide higher service levels for availability, reliability, and response time. Hybrid Cloud Hybrid cloud, naturally, refers to implementations integrating both public and private cloud-based application to address a given business need (e.g., public cloud storage integrated with private cloud application support). The Cloud and Man-in-the-middle Attacks Just because an application is hosted in a cloud of any type, however, does not mean that it provides the 4

5 necessary or appropriate security for an organization s sensitive data. It is imperative that mainframe executives understand that this is not an issue restricted to public cloud delivery. Insider threats are so common today that private cloud implementations may represent greater risk. Many of the breaches that we read about are not about outside attackers that are penetrating the perimeter; the attackers are already on the inside of the perimeter where the attack surface is much richer than it is from outside the perimeter. By definition, cloud applications built using SOAs are modular and are composed of many smaller selfcontained components, all combining together to provide integrated application functions. They are distributed with components residing on any number of independent, interconnected machines particularly many PC-based browsers and open server-based applications connecting to the mainframe. This model of application development provides for unprecedented agility and scalability of business functions, extending many of the application development tenants the mainframe has helped to foster. While the benefits of service-oriented applications are leading more and more organizations to adopt servicebased application models, there are new risks associated with distributing application processing over the network. These risks raise new concerns on how to ensure these applications still meet requisite security requirements and are exponentially greater when the network extends to the Internet. Chief among the security concerns is how to retain both application and data integrity between all the distributed components. Distributed applications are particularly susceptible to a type of security vulnerability known as a man-inthe-middle attack. This type of attack can occur whenever there is an exchange of information between applications or application components over a communication link such as a network. Service-oriented applications are more susceptible to this type of attack because the components of an application may reside on separate machines and the data they process may move between machines during normal processing. The attack is implemented when an attacker, through misrepresentation, intercepts or alters the information exchanged between two legitimate process components and either receives information inappropriately or provides false information. The result of this type of attack is that the integrity and, therefore, the legitimacy of the data are compromised. For example, consider a bank clearing application that exchanges bulk files of checks needing to be settled. One component of the application accumulates all the check information, including the payer and the payee information, and then passes it to another component that posts all the necessary debits and credits to all impacted accounts. If a man-in-the-middle intercepts the file from the first component, substitutes his offshore account information in place of the legitimate payee s information, and then passes a still well-formed file to the second component, the attacker might successfully defraud an organization for millions of dollars. Defeating Man-in-the-middle Attacks To prevent against man-in-the-middle attacks, service-oriented applications must provide for authentication of data exchanged between components. This includes verification of the identity of each component on which the application depends, as well as authentication of the data received for processing. A number of validation methods can be utilized to verify the right component is being used. The best method for ensuring the data integrity of application data is through the use of digital signing. A digital signature provides an 5

6 identity between signed data and a Original Data verifiably trusted entity, whether an individual, organization, or application. Digital signing occurs when the full body of data is first passed through a cryptographic hash function to derive a Hashing Algorithm fixed length output. A hash function is a mathematical process for converting an One-way Hash input data set, often of large size, into a unique output value called a message Private Key Encryption Digital Signature digest. The message digest is then encrypted using the signer s private FIGURE 1 DIGITAL SIGNING key. This encrypted message digest then becomes the digital signature. The digital signature and a copy of the signer Original Data certificate are attached to the data. One-way Hash Authentication is performed by using the signer s public key to decrypt the signed Identical Hashes Validate Data Integrity hash. The signed hash is compared to an independently derived hash using Digital Signature Private Key Encryption One-way Hash the same input data and hash function. Contemporary hash functions include SHA-1 and SHA-2, in a variety of bit FIGURE 2 AUTHENTICATING A DIGITAL SIGNATURE strengths. Some service-oriented applications require assurance that the digital signature applied to the data is not only valid, but that it is from the expected digital signer. This provides extra assurance that the data presented is genuine and not only has not been tampered with since the data was signed, but also that the signature was applied by a specific named party. This process is often referred to as trusted authentication. Transaction authentication is well defined and can be achieved through two-factor authentication methods of identifying a user or application. This method is based on something a user has and something they know or something they are. A common example is the use of an X.509 held on a smart card, which many federal agencies require the user must have the smart card and know the passphrase to access the private key on the card before it can be used for decryption or signing. Transaction Verification (TV) is something slightly different; it authenticates the user as it does in Transaction Authentication (TA), but also ensures the integrity of the content of the transaction. What is not well defined is the authentication of data that is passed between applications that is not encapsulated in the transaction itself. When large amounts of data need to be exchanged between applications, the transaction itself usually 6

7 is authenticated; but what about the data? It is important to separate the protection of data privacy (i.e., through encryption) from the protection of the integrity of processing via authentication. Just because data is encrypted does not mean it came from an authenticated source - anyone can encrypt using a public key. For example, data that is collected as part of a mortgage application could be part of a private cloud registration application that assembles a series of forms and documents. This data will then be passed to another pre-approval application in the same private cloud where the data will be reviewed, bound, and sent to an approval application that exists in the public cloud. The bound data is digitally signed and encrypted before it is passed to the approval application in the public cloud. Consider, however, an insider man-in-the-middle attack in the private cloud that altered or tampered with the data between the registration application and the pre-approval application. A significant amount of time might elapse from the time the registration application stages the data for the pre-approval application before it actually processes the data exactly the kind of gap attackers seek. By digitally signing the data between applications, the pre-approval application would be able to determine if the registration data actually came from the registration application. Applications exchanging data in the cloud should digitally sign the data, as well as encrypt it. When the application signs the data with a private key, it ensures the data is protected while at rest; and the receiving application can validate that the data was not altered after the producer of the data digitally signed it. It can also validate that the data did, in fact, come from the trusted producing application. Conclusion The mainframe is a vital component for both backend processing and for web application hosting. Cloud computing meets the need of organizations requiring applications that attain specific cost, flexibility, or control levels. Yes, mainframe executives must take into account the risks of the cloud s distributed architecture and take appropriate actions to address them. While encryption mitigates risks to data privacy in cloud applications, the separate risk of data integrity in terms of both content and source is best addressed through digital signing and trusted authentication. Mainframe applications 20 years ago did not need to be concerned with encryption of data, let alone authentication issues, because there was enough physical and network security to sufficiently mitigate the risks. Mainframe applications today now need to apply the same risk mitigation security precautions as are applied on a Microsoft Windows server. About the Authors Joe Sturonas, Chief Technology Officer, PKWARE, Inc. Joe Sturonas was previously CTO of Premonition Software, as well as Spirian Technologies. He was also a founding member of OneNetPlus.com, an Internet-centric Management Service Provider. Mr. Sturonas holds a MS degree in Computer Science from DePaul University. Jeff Cherrington, Vice President of Product Management, PKWARE, Inc. Jeff Cherrington was previously Vice President at Bank One, Director of Product Management & Consulting Services for WorkPoint, Inc., and has also worked with other top US and international financial services companies. Mr. Cherrington has an Executive MBA degree from the University of Nebraska. 7

8 2010 PKWARE, Inc. All rights reserved. PKWARE, PKZIP, SecureZIP, and SecureZIP Mail Gateway are trademarks or registered trademarks in the U.S.A. and other countries. Any other trademarks are used for identification purposes only and remain the property of their respective owners. United States 648 N. Plankinton Ave., Suite 220 Milwaukee, WI PKWARE UK/EMEA Crown House 72 Hammersmith Road London W14 8TH United Kingdom ph: +44 (0)