Improving AS/400 Internet securrity with Secure Sockets Layer

Feature

Improving AS/400 Internet securrity with Secure Sockets Layer

I believe that adding Secure Sockets Layer support improves AS/400 Internet security. How so, and how do I go about it? Also, given the AS/400's reputation for A1 security is there any point adding SSL support anyway?

With the dramatic way in which the internet has become a pervasive tool over the last few years, and with e-business becoming a reality both for B2B (Business to Business) and B2C (Business to Consumer), security has become an increasingly important issue, writes Nigel Adams.

So far as the AS/400 is concerned it has always had an excellent security record, and it is worth spending a little time reviewing those security characteristics which are such a strength. Firstly, AS/400 security is fully integrated into OS/400 and is used by the operating system, middleware, and applications. Very important, in that the AS/400 is an object based system.

Everything that is stored on an AS/400 is an object, and each type of object can only have certain operations carried out on it. This means for example that instructions that work on a program (eg Execute) will not operate on a file. It is thus not possible to disguise a file as a program in order to create a virus. Also Pointers cannot be created on the AS/400.

This is a popular means of attacking systems by turning an offset into a pointer and wiping out what is stored at that address. The AS/400 uses hardware tags to indicate when a pointer contains a valid address and when a user changes the contents of any pointer in memory, the hardware turns this tag off.

Another aspect of AS/400 security is that users require special authority in order to copy and restore a program from one system to another. This means that users cannot simply copy a program to another system and then run it.

The AS/400 also will stop unauthorised reboots of the system. The AS/400 security is flexible allowing administration authorisation to be given to users on an individual basis. In order to simplify the task of AS/400 administrators in setting up security on the system, the AS/400 Security Wizard makes recommendations for settings and policies based upon the intended uses of the system. This takes full advantage of the integrated security, by allowing these recommendations to be accepted or modified to fit particular circumstances, and the wizard can then implement the security automatically.

The US Government has certified V4R4 of OS/400 as compliant to their C2 Security Rating as:

  • a standalone system;

  • multiple AS/400s on a single Lan; and,

  • multiple AS/400s with multiple Lan segments. The DB2 Universal Database is also included in this certification.

    All of this shows that the AS/400 does indeed have very powerful inherent security characteristics. However, as I mentioned at the beginning, with the advent of the internet, this fundamental security needs to be even further enhanced. The capabilities of the AS/400 that address this include IP filtering, Network Address Translation (Nat), Virtual Private Networking (VPN), Proxy Server, Mail relay, DNS server, as well as Secure Sockets Layer (SSL).

    Each of these will be appropriate in different circumstances. For example IP packet filtering is best used as a second level of defence protecting the AS/400 behind a secure gateway such as a firewall or a router. Use masquerade or hide Nat when the AS/400 is used as a security gateway connected directly to the public network. VPNs are appropriate when you wish to simulate the characteristics of a private network over public links.

    So far as SSL goes, the recently available V4R5 supports Transport Layer Security (TLS) which is an industry standard definition of SSL. TLS standardises and clarifies SSL protocol definitions as well as adding some new security features. TLS allows AS/400 users to take advantage of the very latest capabilities in terms of internet application security. This capability is supported within standard AS/400 software with no extra charge involved. SSL is implemented in the transport layer (TCP/UDB) and only TCP/IP server and client applications, which have been written to SSL can use this protocol.

    SSL should be used when you wish to provide confidentiality and server authentication in transactions over the internet. It is appropriate for web based applications when the remote client is a browser, and both client and server authentication and digital certificates can be used. SSL not only establishes secure communications but also protects the integrity of data that is transmitted.

    In summary, I would say that the inherent security offered on the AS/400 is one its core strengths - and one that is becoming increasingly important as we go down the road of moving to a networked world. There are many capabilities that can be used on the AS/400 to extend this security even further. SSL is an important offering that can be used to establish secure communications over the web.

    An excellent Redbook produced by IBM's International Technical Support Organisation has recently become available which addresses the subject on Internet Security in considerable detail. It is entitled AS/400 Internet Security Scenarios - A Practical Approach, SG24-5954.

    This publication gives an overview of network security concepts, AS/400 network security features, Cisco router firewall features, and considerations when selecting an ISP. It then looks at connecting an AS/400 securely to the internet in a variety of scenarios. I would recommend that anyone interested further in this subject consult this publication. Another ITSO publication that may also be helpful is AS/400 Internet Security: Developing a Digital Certificate Infrastructure, SG24-5659.


  • Email Alerts

    Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
    By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

    This was first published in October 2000

     

    COMMENTS powered by Disqus  //  Commenting policy