|
||
|
SecureMyi.com Security and Systems Management Newsletter for the IBM i
March 27, 2013 - Vol 3, Issue 26
|
||
|
||
|
Feature Article
An Interview with Patrick Townsend – Townsend Security If you’re a company using an IBM operating system (AS/400, iSeries) to store your data, but you still haven’t upgraded to V7R1; or if you have upgraded but are not sure how to utilize the new FIELDPROC procedure to best protect your data, don’t be discouraged! Patrick Townsend, President and CEO of Townsend Security answers some questions about FIELDPROC and how it aids in helping you secure your sensitive data. Q. What exactly is FIELDPROC?FIELDPROC is a new feature in V7R1 that was not available in earlier releases of the AS/400 and iSeries. FIELDPROC stands for Field Procedures--it’s a column and field level exit point for the IBM i iDB2 database. There is no need for application changes to encrypt your data when using FIELDPROC. As an Exit Point, FIELDPROC is not actually encryption software. FIELDPROC allows system administrators to select which data they want to encrypt on a column by column basis, however IBM does not provide actual encryption or key management software that is called on by the exit point. Encryption and Key Management must be implemented by vendors like us who have encryption solutions tailored for FIELDPROC. Q. What Was Encryption on IBM i Like Before FIELDPROC?Before the implementation of FIELDPROC, encryption was almost always a complicated, multifaceted application software project involving many application changes. After identifying all fields needing encryption, IBM developers often used SQL views and triggers to implement encryption, but that was only a partial solution. |
|
In This Issue
Quick Links
Our Newsletter Sponsors
Platinum Sponsor |
IBM i Security ResourcesJohn Earl Memorial Tribute - Jan 2013 IBM i Security Videos from SecureMyi.com SecureMyi Newsletter Home and ArchivesSearch Security Site for IBM i and i5/OS IBM i Security Reference - IBM i 6.1 IBM i Security Reference - IBM i 7.1 QAUDJRN Audit Types By AUDLVL 6.1 QAUDJRN Entry Type Record Layout 6.1 RedBook - Security Guide for IBM i 6.1 Open Security Foundation - DataLoss DB PCI SSC Data Security Standards 
|
|
IBM i Security and Systems Management News BytesPowerTech and COMMON Establish Speaker's Scholarship in Memory of John Earl
John Earl In January, John Earl, one of PowerTech's founders, succumbed to his brave and long-fought battle with cancer. According to PowerTech, "After relying on John as mentor, friend, leader, and contributor for so many years, we had a duty to share John’s joy of knowledge with the IBM i community." "In order to recognize John’s impact on the security industry, we worked with the COMMON Education Foundation to establish a memorial fund that pays the conference fee for speakers to share their expertise at a COMMON spring event. There are other wonderful scholarships available to help finance attendees; however, we felt John’s special legacy came from his encouragement of people to share their knowledge with others." The recipient of the first award will be announced at the opening session in Austin in a few weeks. Thank you PowerTech and COMMON for creating, funding and managing this wonderful tribute to the memory of John Earl. IBM i Security Calendar of Events
|
|
|
Security Shorts -
By Dan Riehl When you create a new file or program, you have the option of specifying the authority to the new object. But we typically do not specify that authority. Each CL command used to create objects has the parameter Authority (AUT), which is used to specify the *PUBLIC authority for the new object. For most of us, we do not even see the AUT parameter because we seldom prompt the CRTxxx commands. Even if you do prompt the CRTxxx commands, the AUT parameter is usually the very last parameter in the long list. We seldom get that far in the prompt. Understanding CRTAUT and *LIBCRTAUTFor almost all object types, the CRTxxx command uses the default value AUT(*LIBCRTAUT). This value *LIBCRTAUT is specified to assign the new object authority based upon the library in which it is created. So for one library, the value *LIBCRTAUT may mean AUT(*CHANGE), for another library it may mean AUT(*EXCLUDE), depending all on the library's CRTAUT value. The CRTAUT setting for a library can be set explicitly, or can be derived from the System Value QCRTAUT, which ships from IBM with a value of *CHANGE. Allowing the QCRTAUT System Value to determine the CRTAUT value for your sensitive program and data libraries is usually not what you want. When you create or change a library (CRTLIB, CHGLIB), one of the parameters is Create Authority (CRTAUT), as shown in this command to create a library: CRTLIB LIB(MYLIBRARY) CRTAUT(*EXCLUDE) When the library's CRTAUT value is *EXCLUDE, new objects created within the library will be set to *PUBLIC AUT(*EXCLUDE), based upon the CRTAUT of the library. Note: Be careful to specify the correct CRTAUT for your libraries, since CRTAUT(*SYSVAL) is the default value when initially creating a Library. Overriding the Library's CRTAUT ValueYou do not need to accept the CRTxxx command default of AUT(*LIBCRTAUT). You can specify the authority for the object as needed, as in the following command to Create a Data Area: CRTDTAARA DTAARA(MYLIBRARY/MYDATA) TYPE(*CHAR) LEN(100) AUT(*USE) Here, the CRTAUT value of MYLIBRARY is not considered, and the data area is assigned *PUBLIC AUT(*USE) authority. Using an Authorization ListWhen setting the value for a library's CRTAUT parameter, the name of an authorization list can be assigned, as shown here on the Change Library (CHGLIB) command: CHGLIB LIB(MYLIBRARY) CRTAUT(MYAUTL) Then, when a new object is created in the library, the new object will be secured by the MYAUTL authorization list. This assumes that we accepted the default value on the CRTxxx command of AUT(*LIBCRTAUT) or that we specified AUT(MYAUTL). Using an authorization list to assign the authority for a newly created object gives you some nice flexibility. You are not limited to only assigning *PUBLIC authority, but when using an authorization list, you can assign all private authorities to the object at the time the object is created. Object Ownership: The GotchaThe only gotcha when it comes to assigning authority to a new object is that the object will be owned by the creator or by the creator's primary group profile. The owner will have *ALL authority to the new object, which might not be what you want, especially if you are securing the new object with an authorization list. In these cases, you will need to develop a method to reassign the ownership of the new object. I'd be anxious to hear your ideas on the best way to set the exact authority that you want on a newly created object when the creator/owner should not have a distinct authority to the object. I am one who believes that most objects types should be owned by an "owning" profile, whose sole purpose for existence is to own objects. For example, create the user profile PRODOWNER. Assign PRODOWNER as the owner of your production objects. This owning profile PRODOWNER is not a group profile. It is simply a profile to own objects. This works great until someone creates a new object, which makes them (or their primary group) the owner of the new object, and not PRODOWNER. What I'd Like to SeeIt would be great to have an OBJOWNER parameter on all the Create commands, where you could specify something like OBJOWNER(*LIBOBJOWN), which would assign the ownership of the new object based upon a library attribute of "Library Default Object Owner." But alas, right now we may need to retrofit the ownership of these newly created objects to set them correctly. Another option may be to restrict users from creating new objects in sensitive libraries. |
Sponsored Links
IBM i, iSeries and AS/400
|
|
|
||
|
||
|
Send your IBM i Security and Systems Management News and Events! Send your Questions, Comments, Tips and Stories Copyright 2013 - SecureMyi.com, all rights reserved SecureMyi.com | St Louis MO 63017 |
||
