83-03-31 Getting the Most from CA-ACF2: Part 1

Previous screen
William Gibney
Payoff
Computer Associates' CA-ACF2 access control software provides a variety of mechanisms
for controlling and monitoring user access to system resources. However, this software is
effective only if it has been properly implemented. This article, the first in a two-part series,
describes the careful planning that must be taken to ensure that CA-ACF2 provides
optimum control without sacrificing system efficiency.

Introduction
The purpose of this article is to guide management and security officers in implementing
Computer Associates' CA-ACF2 access control software to control system access and
therefore prevent computer crime. CA-ACF2 provides default-based mechanisms for
controlling, tracking, and measuring user access and use of system resources. It is the
author's experience that security software that employs default controls provides the best
assurance against unauthorized access. Of course, any security software is effective only if
it has been properly implemented. Accordingly, this article describes a program for
implementing CA-ACF2 controls following a programmatic implementation approach
consisting of these steps:

· Analyzing the organization.

· Analyzing the environment.

· Analyzing the users.

· Preparing CA-ACF2 data bases.

· Installing CA-ACF2.

This article, the first in a two-part series, addresses the first three steps of the
implementation. The last two steps are covered in the second article of the series; Part 2
also addresses technical issues related to the control of such major subsystems as TSO ,
Internet Multicasting Service, and Canadian Independent Computing Services Association.

Analyzing the Organization

This section describes the managerial and organizational issues that should be addressed to
ensure an effective implementation of CA-ACF2. These include the development of policy
statements on access control, the organizational structure and responsibilities of the
implementation team, and the procedures for CA-ACF2 ID and rule modification and
password controls.

Policy Statement
The goal at this stage is to ensure that the organization has documented its support for
information security in the form of a security policy statement. The statement should
specify the objectives of the information security program, management's commitment to
the program, and the users' responsibilities for security. All employees should be aware of
the security policy and its implications. New employees should receive notice of the
 security policy during orientation, and all employees should be required to sign a log-on ID
Previous screen
nondisclosure form. This form should read that all employees are fully responsible for the
use of their log-on IDs and passwords and that the sharing of IDs and passwords is strictly
prohibited. Employees may also be held accountable for failing to report anyone involved
in unauthorized use, abuse, or manipulation of data and resources. Any breach of policy
may result in penalties ranging from a reprimand to termination and possible legal
prosecution. A nondisclosure statement of this sort signals the commitment of management
to enforce its policies and make security everyone's business.

Organizing the Implementation Team

To accomplish the many steps involved in successful CA-ACF2 implementation, an
implementation team must be established. This team helps develop communication lines
and responsibilities between security officers and departments and keeps management
involved in the decision-making process. This group is also responsible for identifying data
ownership , system flows, organizational procedures, and system software definitions.
Using a copy of the organization chart, the responsible manager should identify and
recruit team representatives from the appropriate departments and systems user groups,
especially from the IS department (including such functional areas as data base
management, operations, and applications development), and the auditing and quality
control departments.
The members of the implementation team should document the software products they
are responsible for maintaining. For example, data base administration may be responsible
for Internet Multicasting Service data bases, technical support for scheduling software, and
operations for tape maintenance. Exhibit 1 provides a sample software document form for
the operations department. Team members should also review the use of default software
passwords which might jeopardize systems security and change these defaults as required.

Software Product Maintenance Form

Department: Operations
Manager: J. Dowd
Software Products: Omegamon
Description: To provide online support for operating systems
Users: Operation personnel
Started Task(initialization) Omeg

Regions
Name MVS

For such online regions as IMS, Canadian Independent Computing Services

Association, and Integrated Data Management System, the region started task names and
the region application group names should also be documented. This documentation will be
useful in establishing the CA-ACF2 security data bases.
After the system software has been documented, the following actions should be
begun:

· Assembling a signature authorization book. This book serves to identify those

managers who are authorized to grant access to data resources. The book consists of
the names and signatures of managers and the data resources to which they are
authorized to grant access. The security officer uses this book to verify access forms
(described next).
 · Creating Information Security Department access forms. These forms are
Previous screen
used to grant users specific CA-ACF2 access rights (i.e., read, write, allocate, and
execute). The appropriate manager must sign this form; the security officer then verifies
the signature and requested access using the signature authorization book.

· Establishing procedures for password control updates. The security officer

must decide who will be authorized to maintain passwords. The following section
describes effective procedures for password maintenance.

Password Maintenance
Mainframe online systems typically have thousands of users who cannot be readily
authenticated by telephone. In order to handle potentially voluminous problems with user
passwords , it is recommended that security officers be assigned at each remote site. For
example, in the banking industry, the branch manager or supervisor is the on-site security
officer responsible for coordinating password changes. In government agencies, password
controls usually are assigned in the same manner to agency supervisors. It is also
recommended that a backup security officer be assigned at each site.
In all cases, the information security officer is responsible for verifying the remote
security officer's identity using a unique identifier such as social security number,
employee start date, and mother's maiden name before making a password change. This
verification process may take considerable time to construct and should therefore be started
as soon as possible.
CA-ACF2 supports the use of scope records, which can be used to grant specific log-
on IDs the authority to change a group of log-ons. For example, scope records can be used
to give the remote site security officers the authorization to change passwords for the
employees they are supervising. Use of scope records can save much time in maintaining
such information.
The following CA-ACF2 commands can be used to create a scope record; the LEADER
attribute is used to attach the scope record name to the site security officer's log-on ID:
ACF
SET SCOPE(SCP) INSERT BRANCH1 LID(BRANCH1) UIDS)
END

TESTID TEST NAME

PRIVILEGES TSO SCOPE(BRANCH1) LEADER
ACCESS ACC-CNT(1) ACC-TIME(12:00)
STATISTICS SEC-VIO(0)

In the above example, TESTID has the ability to access TSO with the privileges of the
SCOPE record; the SCOPE record restricts the authority of TESTIDto change passwords for
BRANCH1 IDs only.
In establishing a scope record, care should be taken not to lock yourself out—this is not
an uncommon error. In fact, you should always have a backup security ID. The importance
of correctly establishing and maintaining log-on IDs and user ID strings is further
illustrated in the sections on analyzing system users and creating the log-on ID data base.

Analyzing the Environment

This section describes various types of CA-ACF2 security interfaces with such subsystems
as SAF, Internet Multicasting Service, and Canadian Independent Computing Services
Association. Classifying data, analyzing the network, and defining ownership are also
discussed.
 Examining Security Links
Previous screen
Although CA-ACF2 can interface with such products as IMS, Integrated Data
Management System, and CICS, it does not have a direct interface coded for all
products.(The “Other Products” section of the CA- ACF2 Administrators Guide provides a
list of products that CA-ACF2 can directly interface with.)
To protect software for which CA-ACF2 does not have a coded interface, it is first
necessary to collect information about control points, subsystems names, and class records
unique to the software. The control points, subsystem name, and identity or class records
needed to write a SAFPROT record may be available from the software company. If so, the
appropriate SAFPROT and SAFSAFErecords can be created directly, using this information.
(Examples of the related SAFPROT and SAFSAFE commands are shown below.) If the
necessary information is not available from the software vendor, SAF records can be
generated to capture this information.
To do so, the SAFTRACE option in the information storage data base is used; the
SAFTRACE option can be turned on only when CA-ACF2 is active; in addition, the SAF-
TRC attribute must be turned on for the ID of the user executing the software. The resulting
SAFTRACE records are written to SYSLOG and appear in this format:

SAF ENVIRONMENT* DEFINE TESTID $TSOTEST TESTID

SAF SUBSYSTEM TEST
SAF CONTROL POINT CLOSE
SAF CLASS DATASET
SAF ENTITY SYS1.SPF.MENUS

Because SAFTRACE records are produced for every call made by the ID for which the
SAF-TRC attribute is turned on, the security analyst must look for records that are known to
be unique to the software.
This process of identifying attributes that are unique to the software requires patience
and care. It is always advisable to first consult the product vendor for information
pertaining to these SAF records. Lack of sufficient care in specifying software attributes can
lead to disastrous results. Consider, for example, this SAFPROT record, which was written
by an associate of the author:
SAFPROT.NVE CLASSES(-) CNTLPTS(-) SUBSYS(CONTENTS)

This SAFPROT record was not unique to the targeted software; it was, in fact, a
common MVS resource call. This record caused all production and test system batch jobs
to fail. Worse yet, because no TSO or CA-ACF2 commands could be executed, it seemed
impossible to delete the SAFPROT record and return the system to normal. Even an Initial
Program Load could not bring up the system, because the same erroneous SAFPROTrecord
remained.
If this should ever happen, the master console command to delete a SAFPROT record
is:
F CA-ACF2,REFRESH(SAFPROT),SYSID(DUMY)

When this command is entered, all SAFPROT records on the system it is executed on
will be suspended. The inappropriate SAFPROT record can then be deleted; the following
refresh makes the other SAFPROT records effective again:
F,CA-ACF2,REFRESH(SAFPROT)

While the security specialist determines the security links to be applied, the members of
the implementation team should begin documenting the transactions for each region. Brief
examples of each type of interface follow.
 ACF2 GSO SAF Records.
Previous screen
The following SAFPROT record causes CA-ACF2 to intercept all users accessing a
data set by any software product whose control points and subsystem are test:
SAFPROT.PRODUCT CLASSES(DATASET) CNTLPTS(TEST)SUBSYS(TEST)

More than one SAFPROT record may be required to provide the required level of
security. In this case, it is sufficient to add a different extension to another SAFPROT
record. It is not the extension of the record but the SAFPROT record name and its contents
that provide the security. For example:
SAFPROT.NTV1 CLASSES(DATASET) CNTLPTS(DBG-) SUBSYS(-)
SAFPROT.NTV2 CLASES(VERIFY) CNTL[PTS(DBG-) SUBSYS(-)

The first record intercepts the MVS call with control points of DBG- and classes of
DATASET to provide data set protection. The second record intercepts the MVS call with
control points of DBG- and classes of VERIFY to provide log-on ID and password security.
The subsystem records in the above example apply CA-ACF2 security to all subsystems
with control points of DBG- and classes of DATASET and VERIFY.
A separate record called the SAFSAFE record should be written for combinations of
classes, control points, and subsystems that bypass CA-ACF2 and SAF validation and
eliminate duplicate MVS calls for products that have been secured. The following record
should be included:
SAFSAFE CLASSES(-) CNTLPTS(-) SUBSYS(-)

ACF2 GSO IMS APPLDEFS.

When used in combination with other CA-ACF2/IMS records, the following
APPLDEF and resource rule records protect IMS regions and their transactions:

APPLDEF.IMS1 APPLDIV(-) APPLDLEN(8)

Test/ Resource.1 NAME($AGN) TYPE(IAG) VALIDATE
Test/ Resource.2 NAME($PRITRAN) TYPE(ITR) VALIDATE
Test/ Resource.3 NAME($SECTRAN) TYPE(ITR) VALIDATE

The resource rules must be written, compiled, and stored with IAG and ITR types. The
IAGresource rule pertains to an application group name which is a group of terminals,
transactions, and program-specific blocks that an IMS -dependent region is permitted to
access. The ITR resource type is used for Transaction Processing. (Further discussion of
IMS security appears in Part 2 of this series of articles.)
The following CA-ACF2/CICS CSECT records ignore file and program validation
while validating transaction authorizations:
 ACF2/CICS CSECT
ACF#PCVT CSECT
Previous screen @CICSKEY RSRC=FLE,
Option=Ignore,
Key=CFC

@CICSKEY RSRC=PGM,
Option=Ignore,
Key=CPC

@CICSKEY RSRC=TRN,
Option=Validate,
Key=CKC

@CICSSAFE RSRC=FLE
@CICSSAFE RSRC=PGM

@CICSOPT AUTH = AUTHORIZATION BIT

CNSLTRN = ALLOW ALL CONSOLE TRANSACTION
CSSN = LOCAL SIGNIN PROGRAM USED
DCON = PERMANENT DISCONNECT
DFTLID = DEFAULT TERMINAL ID
MAXVIO = MAXIMUM VIOLATIONS
QNAME = LID ENQNAME
SUSPSWD = SUSPEND WITH PASSWORD VIOLATIONS
SUSPVIOL = SUSPEND WITH TRANS VIOLATIONS

Resource rules with a type CKC must be written, compiled, and stored.
CA-ACF2/CICS can also be secured using the SAF facility, but CSECT records are
more centralized and easier to maintain and control. For further information, it is
recommended that readers consult the CICS installation manual or their CICS systems
programmers.
Investigating and planning security interface routines for all system software products
requires the active participation of management from each affected area as well as of all
members of the implementation team. It is important that team members be kept informed
of these often complicated issues during this development phase.

Examining Batch IDs and Flow Control.

To determine requirements for secure subsystem startups and user access, it is
important to define the flow of allocated data sets. Users must have access to the data sets
in their startup proc or they will receive CA-ACF2 violations and not be able to log on.
Started tasks execute a proc which may call other executable Job Control Language which
initialize systems. If subsequent JCL is submitted by the proc, a log-on ID and password
card is required.
This is a potential security exposure. For example, the log-on ID and password cards
inserted with the JCL might be discovered and used inappropriately by someone who
would otherwise have no access. To secure this operation, one or more of the following
controls should be implemented:

· Make the ID restricted. This will eliminate the effective use of a password and prevent
the ID from logging on to the system

· Attach the SUBAUTH attribute, making the batch ID submittable only by an Authorized
Program Facility authorized program.

· Force the use of the ID to a program using the PROGRAM field on the ID. The program
then must be APF authorized.
 · Place the program in a highly protected dataset for which member level protection rules
Previous screen
have been written. This will provide program protection.

· Apply a timeshift attribute to lock the use of the batch ID into certain times of the day,
and use the SOURCE field to restrict the use of the ID to a terminal , group of terminals ,
or internal readers.

It is recommended that these controls be used in combination with strict rule writing to
define appropriate access paths. (Examples of writing program pathing rules are provided
in Part 2 of this series.)
The following log-on ID demonstrates the use of the RESTRICT, PROGRAM, SOURCE,
SUBAUTH, and SHIFT attributes:

TESTID TEST NAME

PRIVILEGES RESTRICT SUBAUTH PROGRAM(PGM NAME) SHIFT(DAILY)
ACCESS ACC-CNT(1) ACC-TIME(12:00)
STATISTICS SEC-VIO(0)
SOURCE SOURCE(INTERNAL READER)

In this example, the group names PRIVILEGES, ACCESS, STATISTICS, and SOURCEare
defined in the CA-ACF2 Field Definition Record. The RESTRICT attribute prevents the ID
from being used to log on. SUBAUTH permits the use of the ID TESTID only when it has
been submitted by an APF authorized program. PROGRAM(PGM NAME)locks the SUBAUTH
program to a specific name, and SHIFT(DAILY) allows the ID to be locked into certain times
of the day. The SOURCE(INTERNAL READER) field restricts the use of the ID to a terminal ,
a group of terminals , or an internal reader. The CA-ACF2 Administrators Guide provides
more detailed information on creating the SHIFT and SOURCE records.
It should be noted that CA-ACF2 also provides the JOBCOPY and ACFSUB facilities for
program pathing batch IDs that work similarly to the pathing techniques just discussed.

Defining Ownership
After the systems, security interfaces, and started tasks have been defined, all data sets
must be assigned ownership. This makes it possible to determine which signature
authorizations are required when requests for data set or system access are received.
All data set access requests are authorized by the contents of the $OWNERS field in each
data set rule. For example:
$KEY(SYS1)
$OWNERS(MVS SYSTEMS)
-UID(USERS) READ(A) EXEC(A)

The procedures should specify that all requests for data set access be authorized by
department managers as well as data set owners.

Classifying Data
Classifying data can help reduce the cost of processing and employee resources by
avoiding overprotecting information as well as avoiding losses that can result from lack of
protection. To classify data, the data owners should consider the consequences of its
exposure and manipulation. The same analysis should be done for all transactions within
Canadian Independent Computing Services Association, IMS, IDMS, and other online
subsystems.
 All access rules depend on the accurate description of transactions, classification of
Previous screen
data, and establishment of appropriate access standards. To provide the appropriate level of
security, members of the implementation team and data owners must provide specific,
complete, and accurate information.
Security can be provided on multiple data set levels. For example, owners of data
classified as critical may want access restricted, expired after a time limit, or logged.
CA-ACF2 logging allows access, and creates an System Management Facility type230
record that records the log-on ID used, the users name, the time, date, job name, library
name, program name, and type of access. CA-ACF2 reporting utilities then interpret the
information contained in this SMF record. The following is an example of a logging rule in
which access expires on 01/01/94:
$Key(TEST)
-uid(user) read(L) exec(L) write(L) alloc(L) until(01/01/94)

A sample CA-ACF2 logging report might look like this:

TESTID 93.212 07/09 12:00 DATASET LOGGING
TESTIDJOB VOL=TEST DDN=SYSUT1 DSN=TEST.LIBRARY
STEP1 VOL= PGM=IEBGENER LIB=SYS1.LINKLOAD
JOB0001 DA-OPN INPUT RULELOG NAME=TEST USER
TEST SRC=INTRDR UID(TESTID)

This logging report shows the TESTID executing the IEBGENER utility in
SYS1.LINKLOAD; the job name is TESTIDJOB and the TEST.LIBRARY data set was read as
input. Time and date stamps are also shown.

Analyzing Users
To establish appropriate and secure access rights, it is necessary to evaluate the job
functions of users. Access rights will be assigned on the basis of the specific tasks and
responsibilities assigned to users and user groups. The following sections describe the
various mechanisms (e.g., records, files, and profiles) that are used to specify access
rights.

CA-ACF2 Field Definition Record

Log-on IDs responsible for initializing online regions must be defined to CA-ACF2.
This is accomplished by using System Modification Program (SMP) software to update the
CA-ACF2 Field Definition Record (FDR). This definition permits the initializing ID to act
as a Multiple User Single Address Space System. A multiple user single address space
system (MUSASS) refers to a single region that is defined to many users (e.g., Canadian
Independent Computing Services Association). (In contrast, a single user single address
space system refers to a system in which each user owns his or her own address space
(e.g., TSO ).) A multiple user single address space system (MUSASS) enables individual
users to continue validation against transaction rules while the batch or region ID executes
the tasks of the region.
In addition to updating the FDR, a MiniLID should be defined at the same time the
multiple user single address space system (MUSASS) definition is created. The minilid
(MLID) causes the supervisory call that is initiated by the control region on behalf of the
multiple user single address space system (MUSASS) to call the minilid (MLID) definition
in the FDR and limit the number of fields brought into the region buffer. Only the log-on
ID fields required by the region for validation are stored, and only a portion of the total ID
field is brought into storage. This helps to greatly reduce storage requirements and speeds
 CA-ACF2 processing. With the exception of the FDR, no other records need to be created
Previous screen
or modified for use of minilid (MLID).
The CA-ACF2 FDR also includes the mapping of the user ID string, privilege
definitions for special IDs (i.e., LEADER, ACCOUNT, SECURITY), and bit definitions (i.e.,
TSO , Canadian Independent Computing Services Association, Internet Multicasting
Service) that will be attached to user IDs. CA-ACF2 validates a user's log-on ID, password
, and bit definition to allow entry to the system. CA-ACF2 then processes rule validations
on the basis of the user ID string profile.

User ID String Profiles

The structure of the user ID (UID) string must be carefully planned. If the system is
being converted to CA-ACF2, the existing IDs should be evaluated; it may be possible to
carry over certain field definitions to the CA-ACF2 user ID string. Under CA-ACF2, the
length and other attributes of the user ID fields are defined in the CA-ACF2 FDR.
Well-planned user IDs enable the security officer to establish profiles for groups of
users and help manage user groups by specifying structured UID string profiles in data set
access rules. All users in a department can be given access to the same data by writing one
rule as opposed to writing rules for each user. For example:
$KEY(SYS1) versus $KEY(SYS1)
- UID(B13AE) READ(A) -UID(SYSTEMS) READ(A)
- UID(B14BE) READ(A)
- UID(B15CE) READ(A)

The following example provides a more detailed view of the UID string:
TESTID CSTSS1NY
TESTID (positions 1-6) denotes the ID.
CS (positions 10-11) denotes Computer Systems division.
TS (positions 12-13) denotes Tech Support department.
S (position 14) denotes Staff position.
1 (position 15) denotes first shift.
NY (positions 16-17) denotes New York site.
Open (positions 18-25) for future use.

The log-on ID varies in length with a maximum of 1024 bytes. CA-ACF2 reserves 640
bytes, and the rest can be used for installation-defined fields. All log-on ID fields are
defined in the FDR.
A number of techniques can be used to make the log-on ID useful for reporting, cross-
referencing, and maintenance. For example, employee numbers can be used for IDs.
Employee numbers that are cross-referenced with personnel data bases facilitate the
automated maintenance of the CA-ACF2 log-on ID data base. (For example, the security
officer can write a program to match employee numberbased IDs with employee
numberreferenced records in the personnel file.) The use of department prefixes can also
facilitate the writing of group rules.
Once the UID string has been designed, implementation team members should be
consulted to establish authorized access levels. Remember that only data set owners have
the authority to grant access. Although some system libraries may be shared, data set
owners may restrict access by permitting some employees full access, some update access,
and others read and execute access.
The design of the UID string should complement the writing of rule profiles. The
following is an example of effective group rule writing:
 $Key(TEST)
SHARED.DATASET UID(CSTSS1) READ(A) WRITE(A) ALLOC(A) EXEC(A)
Previous screen CLOSED.DATASET UID(CSTSS1NY) READ(A) WRITE(A) ALLOC(A) EXEC(A)
- UID(CST) READ(A) EXEC(A)

In this example, the TEST.SHARED.DATASET rule gives full access to all users with a
UID string of CSTSS1, while the TEST.CLOSED.DATASET rule gives full access only to
those with UID string CSTSS1NY. The default access rule UID(CST) limits all users with
the UID string of CST to read and execute privileges. (Part 2 in this series of articles
provides more detailed examples of rule writing.)

Command Lists, Source Groups, and Shift Parameters

Command lists should be constructed to control the use of ID privileges. For example,
commands for file transmission (e.g., XMITshould be controlled. Likewise many software
tools have commands whose use may need to be restricted (e.g., INFILE and OUTFILE TSO
commands). Operations, systems, applications, data base, and user service groups may
have different requirements for executing the same command functions.
The CA-ACF2 Systems Programmers Installation manual provides the macros that are
used to build the command list load module. The load module name is attached to the log-
on ID, which forces supervisory calls to be made for command validation. For example,
the following records restrict TESTID to the commands in the TSOCMDA group:
TESTID TEST NAME
PRIVILEGES TSO TSOCMDS(TSOCMDA)
ACCESS ACC-CNT(1) ACC-TIME(12:00)
STATISTICS SEC-VIO(0)
SOURCE SOURCE(NY)

The security officer inserts the source field as part of the log-on ID in order to restrict
use of the log-on ID to a specific group of resources(e.g., a group of terminals ).
Such source groups may also be used in conjunction with SAFPROT records to set up
secondary accessor IDs for securing data base 2 access. A secondary accessor ID, which
consists of the source group name record, is passed to DB2 for processing. If there is no
source group name in CA-ACF2 or in the DB2 data base, the user's primary log-on ID is
passed.
The following example shows how to establish source groups on line in CA-ACF2.
The source group names are then attached to the log-on ID limiting the use of the ID to a
group of terminals:
ACF
SET ENTRY(SGP)
INSERT GRPNAME NEWDATA(TERMINALS)
end
TESTID TEST NAME
PRIVILEGES TSO
ACCESS ACC-CNT(1) ACC-TIME(12:00)
STATISTICS SEC-VIO(0)
SOURCE SOURCE(GRPNAME)

The SHIFT attribute can be a useful tool for controlling the times log-ons are authorized.
The LOGSHIFT attribute can be used in conjunction with SHIFT to allow access past shift
hours while logging the access time, date, terminal , and user. The following is an example
of the CA-ACF2 online command and the log-on ID with the SHIFT and LOGSHIFT
attributes:
 ACF
Set Shift
Previous screen Insert Daily(07:00-17:00)
end
TESTID TESTNAME
PRIVILEGES TSO SHIFT(DAILY) LOGSHIFT
ACCESS ACC-CNT(1)
STATISTICS SEC-VIO(0)

Conclusion
To ensure that the system is efficiently controlled, tracked, and secured, CA-ACF2
installation must be carefully planned. There are no substitutes for managerial support and
teamwork to ensure that corporate policies and standards are correctly implemented. This
article has addressed the first three prerequisites for effective planning:

· Analyzing the organization.

· Analyzing the systems environment.

· Analyzing the users.

Part 2 in this series on CA-ACF2 covers the final two steps: preparing the CA-ACF2
data bases and rule sets and performing the installation. Part 2 also addresses technical
issues related to control of such major subsystems as TSO and Canadian Independent
Computing Services Association.

Author Biographies
William Gibney
William Gibney, a Certified Systems Security Professional with a masters degree in
business management, is an information security analyst for Financial Information Services
Agency in New York City. He has over 12years of experience working with CA-ACF2
access control software. Gibney also served for several years on the board of directors of
the New York chapter of the Information Systems Security Association.