| ACF2 Administration | RACF Administration |
| OS/390 Auditing & Event Monitoring | Open Systems Event Monitoring |
| Other OS/390 Security | Security Matters |
OS/390 security solutions on this page:
| MegaCryption/MVS | Secure\FTP|
| WWW Links |
Now just MegaCryption!
The need to use cryptography to enhance data security is becoming widely recognised. In particular, the DTI's data classification guidelines recommend the use of encryption for data classified as either SEC2 or SEC3 -- i.e. data whose disclosure would cause significant harm or serious damage -- and even for SEC1 data - whose disclosure would be inappropriate or inconvenient -- when transmitted over public TCP/IP networks. However, cryptographic solutions can be both costly and complex.
MegaCryption/MVS provides easy encryption/decryption and digital sealing for OS/390 data sets, enhancing the confidentiality and integrity of data within your company or for business-to-business data movement.
The purpose of MegaCryption is to achieve data protection on MVS platforms by going further than traditional ways, like protecting data sets with RACF. The point is to provide an almost ultimate protection with a flexible and easy to use tool.
The developer's requirements when devising MegaCryption were these:
The developer warrants that MegaCryption does not contain any backdoor and is as cryptographically secure as a software encryption product can be: cryptographic security may be lost only if keys are unfolded in any way or if progress in cryptanalysis makes the algorithms weaker. MegaCryption will not introduce additional risks or breaches in the OS/390 system integrity.
Support for IBM's Integrated Cryptograhic Service Facility (ICSF) (a dedicated hardware solution) is planned for future versions. MegaCryption/MVS will complement ICSF, by providing, e.g., superior interfaces and PGP compatibility.
In addition, the developer aims to quickly address new customer needs.
MegaCryption/MVS provides:
In addition, MegaCryption/MVS provides a number of distinctive features:
In addition, MegaCryption/MVS's decryption functions are available free: i.e. you can use MegaCryption/MVS for one-way b2b data transfer without imposing the need for a full license on your business partners.
For more information, see the MegaCryption/MVS Web page.
Many organisations meet the major part of their file transfer needs by using solutions that are specifically designed to this end. Examples are XFB from Interpel, Connect:Direct and Connect:Mailbox from Sterling Commerce, XCOM from Computer Associates and Attach\FT from Link\Manage. In general, these solutions include all necessary security controls to limit the users to execute only those specific actions to which they are authorised. This type of solution typically requires modules at both the client and the server side.
In addition, organisations nearly always make use of FTP. They don't necessarily want to install the client modules on every single machine that might need a file transfer capability, especially where the client machines are not in their own organisation, but rather with the company's partners, large customers or vendors. And typically companies don't want or are not allowed to force their partners to implement the client modules of their file transfer solution. In these cases FTP is the solution: it is a de facto standard and available on every commercially available platform.
With respect to securing the FTP traffic, it completely unimportant how much FTP is used: as soon as the FTP Server is active, the security hole is there!
FTP is an application that comes with the TCP/IP stack and that offers a lot of options (commands): one can 'surf' on OS/390 directories, allocate space, transfer files, ..., even submit jobs!
Most IT organisations feel the pressure from the business to open up their mainframes for FTP communication, amongst others. However, they realize that they cannot allow users (internal or external) to do whatever they want with FTP. Their goal is to offer each user a 'limited version' of FTP, one which allows him to execute exactly those commands to which he is authorized: nothing less, but also nothing more.
FTP allows users to allocate disk space: without a capability to limit this, there is a high risk that a lot of diskspace is 'wasted' in this way.
Every single user with a valid userid and a password with which they can access data sets automatically has the capability of transfering these same files via FTP to another location, as long as they know how to do this.
An external user can allocate some diskspace on mainframe and transfer a binary file (executable) to this place; he can also activate this module (e.g. to try and intercept userids and other data).
Typically external (or internal for that matter) users will need to get or put data only in specific directories, but are allowed to wander around anywhere within the OS/390 directory structure.
Companies install firewalls to secure the external access, and indeed the firewall can specify which specific users are allowed to use FTP, potentially even with a further restriction on the IP-address where they are coming from; but... that's the level of detail that can be handled by the firewall, it doesn't go any deeper, into the level of every single FTP command
Secure\FTP secures the use of every single FTP command and site subcommand at the level of the combination: userid/password and IP-address. With Secure\FTP it becomes possible to allow users:
Secure\FTP uses the standard SAF-interface for integration with all popular security packages on OS/390 (RACF, CA-ACF2 and CA-Top Secret). By doing so, it allows security officers to use the interface that they are familiar with for the specification of the rules and policies for FTP security.
Secure\FTP also offers a full audit trail. Whenever a user's attempt to use any FTP command is checked via Secure\FTP's SAF interface, whether the attempt is allowed or denied, that attempt can be logged on SMF in a standard way for each SAF product. FTP usage can then be reported with any SMF reporting tool, such as Consul/Audit.
Link\Manage has implemented Secure\FTP in assembler language in the command exit of the FTP server for both IBM's OS/390 eNetwork Communications Server V2R5 (or higher) and Sterling Software's SOLVE:TCPaccess version 5.2 (or higher).
However, there is a difference between the levels of security that can be attained with each of these TCP/IP stacks on OS/390.
The FTP Client of the OS/390 eNetwork Communications Server directly goes to the FTP Server on the target platform without passing by the OS/390 FTP Server (this FTP Server doesn't even have to be activated for outgoing FTP); the FTP Client itself does NOT offer any exits, which means that outgoing FTP cannot be secured at the FTP command level.
SOLVE:TCPaccess uses a '3 part architecture' in which the FTP Client on OS/390 first connects to the OS/390 FTP Server which executes the FTP to the FTP Server of the target platform; in these way all FTP-commands, as well for outgoing as for incoming FTP, always pass by the FTP Server on OS/390 and through the exits of this server; the net result is that Secure\FTP on SOLVE:TCPaccess allows the same level of command-level security for both incoming and outgoing FTP
For more information, see Link\Manage's website.
The Blowfish Encryption Algorithm
Information about Blowfish on Counterpane Internet Security, Inc.'s Web pages. Blowfish was designed in 1993 by Bruce Schneier, one of the founders of Counterpane. These pages contain many other useful and interesting items about cryptography. [Now on Schneier’s own pages.]
Copyleft & Creative Commons (cc) 2000–2008 Ant: This XHTML encoding is dual-licensed under both ― |
||||
|
The GNU Free Documentation License |
|
A Creative Commons Attribution-Noncommercial-Share Alike 3.0 License |
|
|
http://homepage.mac.com/antallan/otheros3.html |
|
Last updated Friday 8 August 2008 |
|
 
|
|
 
|