|
||
|
November 14, 2012 - Vol 2, Issue 19
|
||
|
||
|
Feature Article
The World's Easiest IBM i Heist?
By Robin Tatam I anticipated that they'd conduct a background check when I applied for the job at the bank; however, I only had to submit to a common drug test. I may be a lot of things, but a "doper" isn't one of them. Fortunately, it didn't expose that I'd been fired from my previous three jobs for helping myself to money in the register. I requested access to the walk-in safe after I had been working at the bank for a few days. Interestingly, it turns out my front door passkey was duplicated from someone who had already been granted access so I am already set up. Of course, if I ever forget my key, there are quite a few spares still lying around from employees that no longer work here. There are solid locks on the outside doors to keep the public out when we're closed, but no one worries too much about employees (I assume they're all employees) coming and going as most of them don't know much about the "behind the scenes" movement of the money. Besides, most employees have been around for years and no one thinks that they'll ever do anything bad. Surveillance cameras are mounted on the ceiling, although none of them are anywhere near the back door; an entry that's accessible to all of us with a passkey. The funniest part is that I found out that the bank doesn't even bother to use any of these cameras! At one time a few were hooked up, but the video tapes were reused after only one day and I heard that some got accidentally thrown away by the janitor. I figured no one was reviewing them anyway as there's no screen on the VCR that's there to record the video stream. I was quickly discovering that this job would be far more profitable than I'd imagined . . . Okay, it probably sounds like I'm setting the scene for the world's easiest bank heist. I certainly wouldn't invest a dime of my hard-earned money with an institution that overlooked security like this one does, but you might be surprised to know just how many organizations approach IBM i security in a similar lackadaisical fashion. Many companies do require potential hires to submit to a drug test. While this is certainly commendable, it obviously won't identify anything other than substance abuse. Investigating an applicant's work history won't help because many employers are too concerned with the legality of disclosing private information to release anything more than the dates of employment. That privacy concern even exists when—or perhaps especially—if the employee's departure was due to misconduct. When a business uncovers illegal or unethical activity such as fraud, theft, and even workplace harassment or violence, it's not uncommon to simply fire the employee to avoid embarrassment and further scrutiny. Without insight into an applicant's work history, it's quite possible that undesirable traits will remain hidden throughout the hiring process. Under IBM i, new user profiles are rarely created from scratch. Typically, copies are made from a "similar" profile which may lead to inconsistencies regarding the authorities that the employee obtains. Copying (and later copying that copy) frequently results in the over-assignment of authority, especially when the source profile belongs to a more tenured user. This is the equivalent of duplicating the passkey that inadvertently authorized the nefarious employee's access to the safe! |
|
In This Issue
Quick Links
Thank You! To Our Great Sponsors
Platinum Sponsor |
IBM i Security and Audit ResourcesIBM 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 PCI SSC Data Security Standards 
|
|
IBM i Security News BytesRaz-Lee Software Announces Self Service Password Reset for IBM iRaz-Lee Security has announced the availability of Password Reset, a user password self-authentication product which enables IBM i (AS/400) based companies to provide their users with a quick, reliable and easy-to-use process for resetting their passwords.
IBM i Security Calendar of Events
|
|
|
Featured YouTube Educational VideoIBM i Security
Cannot Access YouTube from your office? Download the video in wmv format. 
|
||
Security Shorts -
By Dan Riehl The IBM i has excellent built-in auditing capabilities. You can audit various types of important events, you can ausit user activity, you can audit object access, and you can audit access to IFS "objects". I have used the object auditing facilities quite heavily. But, the other day I was stumped. I was asked the question "How do you turn on auditing for newly created files and directories in the IFS?" I knew that there was a way to do this, but the method did not come readily to mind. After searching the web and performing quite a bit of testing, I now have the answer to that question. I hope that the information is helpful to you. Auditing Newly Created QSYS.LIB ObjectsThe System value QCRTOBJAUD specifies the global default value for the auditing level specified for newly created objects. The shipped value is *NONE, meaning, newly created objects will not be audited at the global/system level. You can override the QCRTOBJAUD system value at the library level by specifying the CRTOBJAUD parameter of the CRTLIB(Create Library) and CHGLIB(Change Library) command as shown here. CHGLIB LIB(MYLIB) CRTOBJAUD(*CHANGE) When a library is created, the default value for the CRTLIB's CRTOBJAUD parameter is *SYSVAL, but can be set as desired to *ALL, *CHANGE, *USRPRF, *NONE or *SYSVAL. CRTLIB LIB(MYLIB) . . CRTOBJAUD(*CHANGE) So, now, whenever a new object is created in MYLIB, the object's OBJAUD value will automatically be set to *CHANGE. Auditing Newly Created IFS "Objects"The IFS /root file system is used to store various types of files, directories, folders and documents. Often sensitive data is stored there in MS/Excel spreadsheets, Word documents, images, audio, pdf reports, and many other types of files. In addition to being the global setting for the QSYS.LIB file system, the system value QCRTOBJAUD is also the global setting applied to IFS directories. If you want to turn on auditing for all newly created IFS "objects", you set the system value QCRTOBJAUD as required to *ALL, *CHANGE or *USRPRF. Within the IFS, this global setting can be overridden at the directory level using the CHGATR(Change Attribute) command as shown here. CHGATR OBJ('home/myuser') ATR(*CRTOBJAUD) VALUE(*CHANGE) If you want the *CRTOBJAUD auditing attribute to be applied to subdirectories also, include the SUBTREE(*ALL) option of the CHGATR command. So, the key to managing auditing for newly created objects in the IFS is the QCRTOBJAUD System Value when used in conjunction with the CHGATR command. With the CHGATR command, you specify the *CRTOBJAUD attribute and corresponding value for the selected IFS directory, and the associated sub-directories. |
Sponsored Links
IBM i, iSeries and AS/400
|
|
|
||
|
Send your IBM i Security Related News and Events! Advertise in SecureMyi.com Security Newsletter Copyright 2012 - SecureMyi.com, all rights reserved SecureMyi.com | St Louis MO 63017 |
||