IBM i Password Rules

By Rich Loeber

The first line of defense for most systems is the combination of user profile and password.  For most IBM i shops that I’ve worked in, once you know one user profile, you can usually guess most of the rest of the user profiles.  Different shops use different approaches, but they all seem to key off the user’s name or initials.  Some shops may use a more obscure method, but that only tends to make support more difficult when you need to quickly identify the user based only on their profile name.

Given that guessing a user profile can be pretty easy, it makes it very important that passwords not fall into the category of being easy to guess.  For many years, the IBM i OS has provided tools to let you implement a variety of measures to help you with this goal.  This tip will look at some of these and point you in the direction where you can find even more.

The keys to knowing how to enforce password rules are found in the system values that are included in the IBM i OS.  The OS includes a whole set of system values that start with QPWDxxxxx.  Each of these can be used to do things like set the password expiration time period, limit specific characters in a password, limit adjacent characters and digits, enforce password length minimums and maximums, control how often a password can be reused and more.  My personal favorites in this of rules is to disallow any vowels in a password, disallow repeating characters and require at least one digit.  These simple rules go a very long way in forcing users to create passwords that are hard to guess.

With more recent releases of the IBM i OS, there are a wealth of new password options open to you.  These are all available under the system value of QPWDRULES (Password Rules).  This single system value can be set with a maximum of 23 different rules.  You can enforce all of the earlier rules that were available in earlier OS releases plus you can implement new rules.

If you like the way you’ve had things set up before, then you need to make sure that the QPWDRULES parameter is set to the value *PWDSYSVAL.  This will tell the OS to use the individual settings.

A word of warning at this point.  If you are planning on using any of the new values available to you, then you need to first document how each of the old QPWDxxxx system values is currently set.  Once you change the QPWDRULES to any value other than *PWDSYSVAL, then the older system values will all be ignored (with the exception of QPWDLVL which is always in force).  You must first make sure that the current settings you are using are duplicated within the new  QPWDRULES that you set up.

Some of the newer possibilities that I’ve seen that appeal to me include:

•    *LMTPRFNAME – when this is set, the user profile cannot appear as a string anywhere within the password.  For example, user profile JOHN cannot have a password of DOEJOHN.

•    *MIXCASEn – allows you to require that a password contain at least n upper case characters and n lower case characters.  This is only valid on systems running with a QPWDLVL setting of 2 or higher.  For example, if you specify *MIXCASE2, then the password A12bC45 is not valid because it is missing one lower case character.

•    *REQANY3 – requires that a password must contain at least one character from the four character types of uppercase letters, lowercase letters, digits and special characters.  For example, the password of ABCabcd is rejected since it does not contain any numbers or special characters.

For a complete list of all of the QPWDRULES options, go to the IBM i Information Center at the following link:  Select the IBMi OS version option and then enter the value QPWDRULES in the search box.  Look at the first article that comes up called “Password Rules” and you’ll find a complete list of the options.  Keep in mind that this is only available if you are running a currently supported OS level (6.1or higher).

If you have any questions about this topic, you can reach me at rich at, I’ll give it my best shot.  All email messages will be answered.

Security in the IFS

By Rich Loeber

The IBM i OS is rightly known for good built-in security features.  For those of us who grew up with it since the early AS/400 days, security requirements for the “native” library file system are pretty easy to understand and administer.  When it comes to the Integrated File System (IFS), however, things can work differently.  This tip will explore some of the differences and how best to try and deal with them.

If you grew up with the IBM i OS from the early days, you know that the native file system that is based on libraries and objects within those libraries.  Security can be implemented at the library level and at the object level and the hierarchy is intuitive.  The IFS can be different.

First, remember that the IFS is a global term for a variety of file systems that are available to the IBM i user.  In fact, it includes what we refer to as the “native” file system within the QSYS.LIB file system.  Other file systems include the “Shared Folder System”, also known as the QDLS file system; the “/root’ file system, the QOPT file system, the QopenSys file system, the QFileSvr.400 file system and more.  These other file systems all employ an organization based on nested directories.  Where your files reside will determine your approach to securing them.  If you’re just using the native file system, this tip is not for you.  If you’re using any of the other file system (and most IBM i shops today are in this boat), then read on for some things to watch out for.

The exact security set up that you choose will depend on how the files are stored in the file system in question.  For example, the QOPT file system (for optical drive operations) has no security at all since there is no way to write security information to the file system, it is read-only.

The IFS file system is designed to follow POSIX (Portable Operating System Interface) standards wherever possible and certain unusual behaviors can happen when this is mixed in with the IBM i OS.  Here are some things to watch out for.

When you create a directory, the owner must also appear in the security authorization for the directory.  In the native file system, the owner has clear rights to an object, but not so in the IFS.  The owner’s rights must be defined as a private authority.

For files in the IFS, keep in mind that adopted authority is not honored for most file systems including the root, QDLS and QopenSys file systems.  Your application designs may rely on adopted authority for the native file system, but this approach will not work for most other file systems on the IBM i.

Most file systems will require *RX authority to read an IFS file.  This will apply to every step in the directory path.  If your application needs to read objects in the IFS, make sure that *RX is in place for the entire path structure.  Object management rights (the X character) are needed for some functions that you might not normally think of, so it is best to include it.

When making copies of files in the IFS, be careful which command you use.  The COPY (or CPY) command will duplicate the file including the file’s authority settings.  The CPYTOSTMF command, however, is only intended to copy the data in the file.  The file created by CPYTOSTMF will be owned by the user that runs the command and the owner’s rights from the original file will be dropped.  You will have to reset the authority the way you need it once the copy has completed.

For a complete discussion on these along with other things to watch out for, check out the IBM i Knowledge Center in the Security area for your level of the OS.

If you have any questions about this topic, you can reach me at rich at, I’ll give it my best shot.  All email messages will be answered.

A Case For Contextual Security

By Rich Loeber

My wife and I live in the Adirondack Mountains of northern New York state.  During most of the year, except for 10 weeks during the summer, we have very few neighbors with the closest being almost a mile away.  On a normal day, we get a handful of cars that drive down our road (unless you count the number of times the snow plow goes by).  In this context, we’re not very concerned about security.  We rarely, if ever, lock our doors.  We know all of the year round residents and they know us.  We all look out for each other and that seems to be all of the security that we need.  Our biggest security consideration is the local bear population, they get into the trash if you’re not careful and make quite a mess.

In the IBM i world, context can define how you handle security.  Security in the OS is not attenuated to context, so you have to think about your requirements and implement contextual considerations as they apply.

What do I mean by contextual security?  Here’s the classic example.

Suppose that you have an order processing application that records credit card information and then processes that information to obtain credit card authorization approvals.  Obviously, the clerk entering the order needs to have access to your customer database in order to enter the credit card information or validate the information that you already have on file.  Within your standard security model, you will need to grant this user access to the information with sufficient authority to add new information, change existing information or even delete current erroneous information.  For their normal order processing tasks, this user can be configured easily to provide for database access and change authority.

But, what about other possible accesses to this data that do not fall within the normal context of their job execution?  The same level of access that they normally require is inappropriate when accessing your customer credit card information via FTP or by using IBM iAccess download functions.  When using these functions, this same profile can make a copy of all the credit card information on their desktop, then copy the information to a flash disk or memory stick and walk out of the office with all of your credit card information in tact and nobody would be the wiser until the story breaks in the NY Times.

Given this reality, obviously the single context approach to database security is not going to work.  The user does need access rights to do their normal job requirements, but they need to be restricted from access for other contexts.

Fortunately, there are several ways to accomplish this on the IBM i and I’ll just mention three of them here so you can start thinking of how to get this taken care of.

First, and possibly easiest although not always cheapest, is to buy and install a good exit point security solution.  There are several such solutions available on the market from reputable software developers.  (I recommend SafeNet/i, the solution from my company.)  The exit point solution lets you define a network access context for your users and restrict network accesses that might otherwise be wide open to them.  You won’t have to change the security setup in the IBM i OS, but the extra layer of security from the exit point solution will add the contextual security you need from network based applications like those already mentioned.  You could write your own exit programs, but exit point programming is not for the feint of heart and the rules periodically change as the OS goes from release to release, so it is better to go with a good solution from a trusted software supplier (like ours!).

There are two other approaches that are similar in nature and can also let you define security on your IBM i based on context.  One is adopted authority, the other is profile swapping.  In both cases, the security in force when you application runs is NOT based on the user profile doing the work but on some other method.  With adopted authority, your program is set to base security decisions on the user profile that owns the program, not on the profile that is running the program.  This way, you can control who gets to use the program, then the program itself can control the resources that it needs access rights to.  With profile swapping, you can let the requesting user profile control things up to the point where different access rights are needed, then under program control, you can call an API in the OS to swap profiles and run under a different profile for a given duration of processing.  Either way, the user profile used to determine access rights is different from the user signed into the application, giving you contextual control over the situation.

If you have any questions about this topic, you can reach me at rich at, I’ll give it my best shot.  All email messages will be answered.

Watching Your Super Users

By Rich Loeber

Every IBM i shop has a few super users that you, as security officer, have to be concerned about.  For one reason or another, a few user profiles just have to have full access to your system.  This tip will show you one way to check up on what these users are up to, using the system security journal.

For specific user profiles, you can implement additional security auditing that is over and above what your system is configured to capture.  To make sure that your super users are not over stepping their bounds, you can set up the security journal to capture additional security events for these specific profiles.

To get started, you need to have the security journal active on your system.  If it is not active, you can just run the Change Security Auditing (CHGSECAUD) command.  Running the command with the defaults shipped with the OS will set up the security journal (QAUDJRN).  By setting the default values to *NONE, you will limit what the security journal captures so you can experiment with tracking an individual user profile’s activity.  Of course, if you already have the security journal active and running on your system, you can skip this step and continue on with setting up the individual profile controls.

With the security audit journal active, you are now able to set up specific event controls at the user profile level.  This is done using the Change User Auditing (CHGUSRAUD) command.  Type this command in and use the F4 key to prompt for the parameters.  For this tip, we’ll concentrate on the “User action auditing” (AUDLVL) parameter and what things you can track at the user profile level.  These include the following:


  • *CMD – this setting will record command strings used by the profile in the journal for your review.  With this setting, you can see what specific OS commands the super user is using and make sure that command line abuse is not happening.
  • *CREATE – this setting will let you track all new objects created by the super user.
  • *DELETE – using this setting, you can see when a super user deletes an object.  Since this is a concern for super users, you can track it easily using this method.
  • *OBJMGT – this setting tracks object renames and moves.
  • *SAVRST – this setting lets you track save and restore operations by the super user.
  • *SERVICE – this setting lets you track the super user’s use of system service tools.
  • *SPLFDTA – this setting lets you track actions taken on spool files.
  • *SYSMGT – this setting tracks system management functions.
  • …. more

Different levels of IBM’s i/OS include a number of new/different functions that you mAY want to explore.  The AUDLVL parameter accepts many more options thaN I’ve listed here.  For your installation, you may find some of the other values of particular interest.

A nice side benefit of logging super user activity to the security journal is that it is a good proof for your auditors that super user profiles are being used responsibly.  Every auditor I know of who knows what they are doing is concerned about what super users are up to.  This method goes a long way to satisfy their requirements.

If you have any questions about anything included in this tip you can reach me at rich at,  All email messages will be answered as quickly as possible.

Tracking IBM i Program Object Changes

By Rich Loeber

In an era of steadily increasing computer security interest, it is inevitable that your shop will be audited by someone looking specifically at computer security arrangements.  There are lots of aspects of a security audit, but one control all auditors seem to have in common is seeing proof that your IBM i program base is not tampered with.  This tip will give you a simple method for providing this proof, plus it gives you a good opportunity to quickly review all changes to program objects by just scanning a few simple reports.

For your tracking to work, you will first have to set up a baseline of information about the programs on your system.  I suggest that you dedicate a separate library on your system for this purpose and then make sure that access to the library is restricted to your security officers only.  For purposes of this tip, I set up a library called KISPGMTRK and I’m going to track changes to *PGM objects only.  In your implementation, you can expand the implementation to other program objects as you have need.  To set up the baseline information about all programs on your system, just run the following command:


This will create a database file in your library named PGMMST which will become your baseline file.  The file will contain information about all *PGM objects on your system from all user libraries.  To expand your baseline to include all programs in the OS, just change the OBJ parameter to specify *ALL libraries, not just *ALLUSR libraries.

Once you have this baseline established, wait for some program change activity on your system.  Then, repeat the above command only specify a different OUTFILE file.  For my example, I have used a file name of CURMST.  This will capture a second picture of all *PGM objects on your system taken at the second point in time.

Now, all that’s left is to compare the two files and produce your control listings.  For my example, I used the IBM i Query tool (WRKQRY).  This tool will let you run a query joining two files together dynamically.  I joined them on library name and object name.  If you are tracking more than just *PGM objects, then you will also have to join on object type.

For my tracking, I generate three different reports.  A list of new programs added to the system, a  list of programs deleted from the system and a list of programs that have changed.  To get the new programs added, set up the current file first and the baseline file second, then specify a key join for unmatched records with the primary file.  For deleted programs, set up the baseline file first and the current file second using the same unmatched records with primary file join (the opposite of your first report).  Then for changed programs, process the two files using the matched records join option.  To get just the changed programs, select records where the object size, create date or create time have changed.

When your reports have been created, you will then just need to replace your baseline database file with the most recent current file.  In my example, I just do a copy/replace from the CURMST to the PGMMST file.  Now you’re all set up for the next report cycle.

Once you have this set up and working, you could even work with it to keep a history database on file for all of the adds, deletes and changes over time.  At a minimum, when your auditor shows up, you’ll have a nicely bound volume of reports showing all changes.  And, you can review the program change activity for yourself to make sure there are no surprises along the way.  After all, isn’t that the point of security checking?

If you’re interested, I’ll send you a save file of the library on my system where I developed my version of this process along with a simple CL program and CMD object to run it.  If you have any questions about anything included in this tip, or you would like the sample, you can reach me at rich at,  All email messages will be answered as quickly as possible.

Recovering Your IBM i Security Configuration

By Rich Loeber

I once worked, many years ago, with a company that had a disaster recovery plan in place and actually tested it once or twice.  The plan called for us to arrive at the recovery center and then, almost immediately, turn security on the recovery box OFF to make things easier during the recovery.  There was no corresponding step later in the recovery to reactivate security, so for the duration of any disaster, the backup system was exposed to security violations.  Now, to give them some credit, this was in the days before networks and the Internet, so their exposure was probably pretty limited.  In today’s world, however, when you have to switch over to a disaster recovery site, you will need to have your security plan in place and built into the recovery process.

To understand how best to do this, you first have to understand what the different security objects and settings are on your system along with how and where they are saved.

System values make up a large component of your security policy implementation.  The system values are all stored in the QSYS library.  They are saved when you run a SAVSYS, the “Entire system” or “System data only” options on the SAVE menu or when you save your entire system using the “Run Backup” (RUNBCKUP) command.  When you get to your recovery site and restore your OS from one of these, your system values will get restored in the process.  Keep in mind that these settings will be restored the way they existed when your SAVSYS was created.

User profiles, including group profiles, are also stored in the QSYS library and are saved when you save the OS.  Since these can change more frequently than the OS, you can also save them using the “Save Security Data” (SAVSECDTA) command.  When you restore your OS, you will get the profiles as they existed when that backup was taken.  If you have saved the the profiles separately, make sure that you restore them again as soon as the OS has been restored so that you get the most current set of passwords available.

Job Descriptions can also have an important affect on how jobs run and how security is enforced on your system.  IBM generally recommends that you create your job descriptions in the QGPL library where they keep theirs, but a job description can be created and stored in any library on your system, especially if you are running any third party software.  When you backup a library using the “Save Library” (SAVLIB) or “Save Object” (SAVOBJ) command, the job descriptions will travel along and will be restored when those libraries are restored.

Finally we get to your resource security setup.  This, by its very nature, is a bit more complicated than the above items, but certainly manageable.  The good news is that a lot of the resource security information is stored directly with the object.  This includes its public authority setting, its object audit setting, the profile of the object’s owner, the primary group and the link, if any, to an authorization list.  So, when you save the objects in your library, you will also be saving these security items.  The two resource security pieces that are not included are the authorization list itself and the private authority configuration.

All authorization lists are stored in the QSYS library.  They are saved when you save your OS and they are also saved when you run the SAVSECDTA command.  As with the user profiles already mentioned, these can change more dynamically than the OS, so having a separate SAVSECDTA is a good idea.  After you restore your OS, make sure to include a restore of your security data to get the most recent versions of your authorization lists.

Private authorities are also stored in the QSYS library and are included as a part of the user profile data.  So, when you save the most recent profile information, you are also saving the most recent private authorities.  When you recover your profiles, you are also recovering the private authorities.  But …. there is a catch.  After your system has been recovered, including the most recent profiles and ALL application libraries, you will also have to run the “Restore Authority” (RSTAUT) command for *ALL users.  This will restore the private authorities to objects and to authorization lists.  This is a step that can be overlooked with dire consequences as far as your security implementation is concerned.

There is more information about all of this in IBM’s Security Manual for the OS.  I recommend you review the manual for more details.

If you have any questions about anything included in this tip, you can reach me at rich at kisco dot com,  All email messages will be answered as quickly as possible.

Setting and Locking Your System Values

By Rich Loeber

When you implement your company’s security policy on your IBM i, often the first thing you do is review your system values.  System values define global, system-wide settings on your IBM i platform.  Many of these system values pertain to how you want to implement system security.  This tip will review how to look at these settings and then, how to lock them in place so that they cannot be changed.

So many of these system values are security related that the OS designers provided an easy way for you to review and work with the security settings.  This is by using the “Work with System Values” command (WRKSYSVAL) with the “System value” (SYSVAL) parameter set to the special value of *SEC.


Setting the OUTPUT parameter to *PRINT will produce a listing of the security system values for you.  Or, you can just run the command with the OUTPUT parameter blank and the system will bring the security system values up for you to review.  A similar review function is available from IBM i Access, but the security functions are spread out over several different selection tabs (at least on my version) and you have to go several places to find everything that is available from the single *SEC review ability of the WRKSYSVAL command.

When working with the values interactively, you can review the current setting using option 5 or you can change the value using option 2.  The list of system values displayed shows the name of the value and a text description.  Often, this is not enough information for you to determine exactly what you’re looking at.  When I find myself in this situation, I put a 5 next to it, then position the cursor over the current value displayed and press the HELP (or F1) key.  The help text that comes with this command is quite comprehensive and very helpful.

Changing any of your security system values should not be done on a whim.  Planning and preparation are the watchwords for this process.  It is all too easy to shoot yourself in the foot by making a security change on the fly and then losing, for example, the ability to log into your system.  All security changes should be researched in advance to determine the exact impact on your system.  If you’re not sure, do the work to find out rather than just trying it out without knowing the impact.

Once you have your security system values set along with the other system value (and there are loads of them), it is a good idea to lock them in place.  On too many systems, there are just too many users with all object (*ALLOBJ) and security administrator (*SECADM) permissions in their user profiles.  By locking the system values, this will prevent casual changes to the system values and thereby preserve the security policies that you’ve designed and implemented.

To lock your system values in place, you can use the System Service Tools.  To lock the settings, start up the System Service Tools from a display session using the Start System Service Tools (STRSST) command.  You will need to supply your service tools user ID and password to complete the start of the tools.  Once completed, choose option #7 from the menu (Work with system security).  Then, from the next screen, use option 2 to lock the security system values in place.

Once these are locked in place, you can only unlock them to make changes by first going back into the System Service Tools and unlocking them from the same screen where you locked them.  The unlock option is done by entering option 1.  These settings can also be manipulated during IPL time by running the Dedicated System Tools (DST).  Once locked, even users with *SECADM or *ALLOBJ cannot make capricious changes to the security system values so your security policy decisions will remain in force without worry.

If you have any questions about anything included in this tip, you can reach me at rich at,  All email messages will be answered as quickly as possible.

IBM i Security Basics – Implementation

By Rich Loeber

In my last blog, I wrote about how to create a security policy for your IBM i.  This time, I’ll take a broad overview look at how to best implement your policy on your IBM i.

Some of your security policy will be implemented globally through the setup of your IBM i system values.  Much has already been written about this and is generally available from this website and others.  I do not want to duplicate that.

What is unique to each application, however, is the object level security setup that protects your basic data and programming elements.  This is what I want to explore here by reviewing a few key practices that, over time, will simplify your security administration task.

The first of these key practices is implementing your object level security based on group profiles.  Security can be implemented by individual profiles or by groups.  Each user profile on your system can be assigned to a single group along with up to fourteen supplemental groups.  A group profile is nothing more than an additional profile that is defined to your system but is set up so that it cannot be used for logon purposes.  Its only purpose is to control object access.  Once a group profile has been created, you can then add individual profiles to the group by placing the group profile in the GRPPRF (Group profile) field or in the SUPGRPPRF (Supplemental group).  With group profiles implemented, you no longer have to create object access rules for each profile, just for the group profile.  By reference, the rules for the group will then apply to each individual user profile that is included in the group.

With your security policy document, check it to identify the specific groups that you are going to need and get them set up on your system.  Then, code the individual users into each group.  When people leave the company, you will not have the issue of having to get all of your security setup modified.  Plus, adding a new user profile will be greatly simplified by not having to maintain an extensive set of individual object accesses.  When you are all set up, you can generate listings for each group using the DSPUSRPRF (Display User Profile) command with the *GRPMBR option.

The other key practice that I want to discuss today with your security implementation is the use of Authorization Lists for object security.  An individual object can be controlled by entering profile information directly associated with the object or by reference to an Authorization List.  When you store your profile access rules directly with the object, then you cannot make updates to these rules when your object is in use.  Using Authorization Lists, however, removes this obstacle and saves you from a lot of late night sessions.

Also, with an Authorization List, you can create a single security configuration that can then be applied to multiple objects on your system.  At the individual object level, just reference the Authorization List and the rules created in the list will apply to the object.  From your security policy, you will find general rules that apply within an application.  These can easily be assign to an Authorization List.

But, you ask, what about exceptions?  Every security policy is going to have exceptions and you can deal with them as they arise.  I try to discourage them by asking that a clear business case be made for each exception.  The response, “well, it would just be a lot easier” is no longer acceptable.  Those kind of exceptions these days can easily lead to banner headlines that will be embarrassing to you and to your company.

If you have any questions about anything included in this tip, you can reach me at rich at,  All email messages will be answered as quickly as possible.

IBM i Security Basics – Policy

By Rich Loeber,

If you are a security officer for your IBM i, then securing databases on your IBM System i is your primary responsibility.  Good security starts with a clearly defined policy.  This tip will help focus on how you can create this policy.

Before you start creating a security policy, you will have to get your user community involved.  A security policy created and implemented without end user participation is destined to always be a problem.  If your end users, however, are asked to participate and buy into the policy, then the results will be a much smoother implementation.  If you find resistance to participation in policy creation, get management on your side.  Whatever you do, don’t create the policy on your own as an IT project.

The first decision you need to make when formulating your security policy is what your overarching objectives are going to be.  You have two choices at this point:

  • You can decide that your policy will be very strict
  • You can decide that your policy will be relaxed

With a strict policy, access to every object in your system will be determined and enforced at the operating system level.  Each user’s specific requirements will be analyzed and then encoded in the security implementation provided by the IBM i OS.  With a more relaxed approach, you can decide that users will have broader access to objects on your system with strict access rules only for certain pre-defined data assets.  In actual practice, most IBM i shops adopt the second approach, but your auditors will love you if you go for the first one.

Once you’ve made this decision to your general approach, then proceed to make a list of the applications on your system.  For each application, you will need to define the owner of the application.  This will be the person who will have to make final security decisions.

Within each application, you should then list the data assets created and used by the application with a note on each one as to it security status.  Some applications will need little or no security while others will have very strict requirements.  Make sure that your users are in full agreement about the nature of each data asset and its security requirements.

When deciding on the security requirements for each asset, there are three things to consider:

  • Is this information that should be restricted from all employees?
  • Is this information that is critical to the way you do business?  Does it give your organization a competitive advantage in the marketplace?
  • Is this information crucial to your day to day operations?

Obviously, payroll falls into the first category and is the classic data type for this consideration.  But, you may have other data assets that also come into play.  Included in this would be any data assets that record credit card information, banking information or any other personal identity information for your employees or your customers.

An example of the second data type would be a Customer Master database or a Contact database.  These are compiled databases that clearly help you to do business and that you do not want falling into the hands of competitors.

Finally, an example of the last type of data asset might be your month to date sales database or your current accounts receivable.  These are management tools that are needed to maintain your day to day business operation.

With each of these assets defined, you can then describe the type of security that you want in place.  When you are all done with each application, have a final review and signoff by the user (or owner) for each application.  Only after this legwork has been done can you consider how to best implement the security requirements.  More on that step soon.

If you have any questions about anything included in this tip, you can reach me at rich at,  All email messages will be answered as quickly as possible.

Are You An Accidental Security Officer?

By Rich Loeber

How can you be a more effective security officer given that you probably are in the job completely by accident?  This tip will explore this idea and provide some suggestions for you.

Computer Security, as a specialty, is still fairly new.  Chances are, you did not get into this field by taking it as a major in college or going to a technical school and specializing in the field.  As I look back over my career, I can recall lots of people who ended up working in various segments of IT who came from some of the wildest original intentions.  One guy I worked with came from a background as a pitcher for the Pittsburgh Pirates followed by a long career as a plant manager for a chemical plant.  Another started out in college to be a psychiatrist.  For my part, I never even went to college but got started in IT right out of high school working as an input/output control clerk.  I suspect that we are all “accidental” security officers.

So, how do you become an effective security officer considering that your training and education probably did not prepare you for it?  It’s a very good question to ask yourself.

I recently published a couple of tips about how to learn the security officer position.  I encourage you to check these two articles out, Learning To Be A Security Officer and Learning …. Part 2, as a starting point.  But, for today’s consideration, you need to do some introspection before heading out to become a better security officer.

A lot depends on what you did prepare for in your career.  If you prepared to become a programmer, then you probably don’t need to concentrate on the programming aspects of the security officer function.  In fact, you may have a tendency to stick with these tasks because they are most familiar to you and you are very comfortable with them.  It is a fact of human nature that we tend to go where we are appreciated and where we can demonstrate competency.  So, if you find yourself hanging around where you already know how things work …. it is time to move out.

To become an effective security officer, you need to back fill the areas of learning that you never prepared for in the first place.  This is where the introspection comes in.  For my part, I started out as an application programmer.  When I got to the whole area of security, it was a new arena for me and I found that communications and networking were my weakest spots.  I still have trouble fully understanding how TCP/IP works and how to really secure it so that it is foolproof (if that is even possible).  Worse, the people who do know how TCP/IP works all appear to speak a foreign language that is liberally peppered with three and four character acronyms that I’m supposed to know the meaning of.

Once you’ve identified your “weak” area or areas, then you need to identify resources that can help you to understand concepts and strengthen your security consciousness.  I always try to start by finding a peer or an associate who knows that stuff and pick their brain.  Then, I see if they can give me recommendations on reading materials, websites and publications that can help.

I also have to confess to you that I am still a reader of technical manuals and IBM Redbooks.  Having them all on-line is a real benefit these days and when I have spare time, I will often go browsing in the manuals library to find what’s new and see things that I haven’t read before.  I know that the manuals can be pretty dry reading, but they really do contain the manufacturer’s explanation of how things are supposed to work.

I’d love to hear from you if anything here strikes a chord with you.  Do you have an unusual story of how you ended up as an accidental security officer?  Send it in.  You can reach me at rich at kisco dot com,  All email messages will be answered as quickly as possible.