A brief look at things to consider when building a data security framework.

1. Data Security: The Basics
There are twenty-one basics of a solid, local security organization. By “local”, I
mean a single organization within a company. That may be a single application, a group
of similar applications, or an organization within a larger group (e.g. a database support
group within a corporate system support group). However, we can equally apply these
concepts to the entire company’s organization. As I have far more experience with
mainframe security than network security, I will use RACF to illustrate my points.
However, the concepts are the same in any environment. UNIX permissions are an
exception.
1. Security objects should have good, clear names.
2. Security objects should have user data clearly describing the item’s usage, if they
can (not all objects allow user data).
3. Groups, not user IDs, must own security objects.
4. The data owner should own all dataset protections related to that data.
5. Special authority must be controlled by scope-of-group, not by granting special
authority in many groups.
6. Groups, not user IDs, must control access to resources.
7. Groups should be limited to one function.
8. Logon user IDs should not be in the same group as user IDs that do not log on.
9. Groups with access to business data should not own personal user IDs.
10. The creators of user IDs should not also have access to or authority over controls
on business data. Conversely, authority over business data should not allow the
alteration of a user ID.
11. Dataset profiles should be limited to one function and/or data owner.
12. Prohibit access to business data across lines of business except where necessary
for data integrity and business continuity.
13. Resource profile access lists should contain only groups, not user IDs.
14. Resource profiles must have some way of notifying the security administrator of
violations.
15. Resource profiles for business data should have a universal access (UACC) of
NONE.
16. Resource profiles should audit failures at one level above the UACC.
17. If the product has a WARN mode (i.e. access permitted with warning messages),
it should be only be used temporarily on new profiles, or when making major
access changes to the profile.
18. Upon a change in a person’s responsibilities, examine their user ID and remove
them from sensitive groups immediately.
19. Revoke user IDs immediately upon notice of termination and delete them within
two weeks.
20. Personal user IDs should not have direct access to database datasets.
21. Datasets should have a naming standard that clearly shows who owns the data,
what kind of data it is, the purpose of the data, and whether it is production or test.

2. The Basics Explained
Data security provides two basic functions.
 It allows access to those who need it.
 It restricts access to only those who need it.
To provide those functions cleanly, a security administrator needs a solid auditing
structure to catch violations. Standardization of rules, protections, and resource names
greatly streamlines the audit process. The rules outlined above provide this. When all
twenty-one of the general rules are in place, the organization is secure from almost all
accidental, and most deliberate, unauthorized access. Further, the security administrator
can catch the few deliberate attempts early, before any real damage occurs.
1. Security objects should have good, clear names. With a clear name, there is no
doubt what the object is. A group naming standard should include the letters R
(read), U (update), and A (all access). A good place for this letter is the last letter
in the group name. A dataset profile must follow the dataset naming rules, thus a
good DSN standard is required. User IDs should differentiate between a logon
user ID (i.e. one you would give to a person) and a batch user ID (one which a
batch job would use).
2. Security objects should have user data clearly describing the item’s usage. This is
particularly necessary because often the name of a RACF object can be only eight
characters. Without user data there is no way to understand why a profile, user
ID, or group exists. Be clear; good examples might be as follows.
a. USER123, user data TECH SUPPORT TSO USER ID.
b. JOB1357D, user data DAILY BATCH UPDATE OF XYZ DATABASE.
c. DBASAPPR, user data ALLOWS APPLICATIONS ACCESS TO
DBASE AUTOMATION TOOLS.
3. Groups, not user IDs, must own security objects. User IDs should not own
anything. The main reason: groups are permanent, user IDs are not. User IDs
are for people (who can leave at any time) or batch (which can change at any
time). Most security products cannot delete a user ID if it owns a resource.
Company control over a resource is compromised if a person owns it. If a user
owns a group, scope-of-group ends for that access path. Finally, if a user owns a
profile, only that user can make changes to the profile. All of these issues mean
problems for audit trails, creates access loopholes, and can invalidate protections.
4. The data owner should own all dataset protections related to that data. A dataset
profile owned by a non-data group or user ID could leave ownership of the
resource in doubt, especially if the group’s usage is redefined while the data
ownership remains unchanged. This also prevents unauthorized access.
Remember, the data owner is not a person but a group created for ownership.

3. The Basics Explained continued
5. Special authority must be controlled by scope-of-group, not by granting Special
within each group. Putting a user in a group solely for SPECIAL authority also
allows that user access to resources the group covers; that can severely
compromise access controls.
6. Groups, not user IDs, must control access to resources. This is similar to having
groups as owners of resources rather than user IDs (see the previous bullet). It
also eases maintenance in that, when a user ID is deleted, it only has to be
removed from a few groups rather than (perhaps) hundreds of profiles.
7. Groups should be limited to one function. This provides better control over who
can perform what actions. Specifically, groups should be used for access control
to only one type of resource.
8. Logon user IDs should not be in the same group as user IDs that do not log on.
The purpose of this is to restrict people from accessing critical data without
proper verification. Batch IDs are not controlled by emotions, bribes, etc. and
thus are somewhat safer and easier to control. User IDs that can log on via a
person are by nature unpredictable. Further, authorization of batch ID creation is
dependent only on the requestor, who presumably was checked out when assigned
the security administrator position. Authorization of logon user IDs must be
independently verified.
9. Groups with access to business data should not own personal user IDs. In other
words, groups owning user IDs should provide access only to those resources
necessary to log on. Application area security administrators are the ones
responsible for vetting users for their required access to business data. However,
they should not be the ones creating user IDs (see the next bullet).
10. The creators of user IDs should not also have access to or authority over controls
on business data. Conversely, authority over business data should not allow the
alteration of a user ID. If a person creates an ID and is responsible for its access
to business data, there is no control over that person creating an ID solely to hack
the company’s systems. Audit alone cannot catch this kind of security breach.
11. Dataset profiles should be limited to one function and/or data owner. This is the
same argument as with restricting groups to one function. The owner of the group
owning business data should not own utility libraries, and vice versa.
12. Prohibit access to business data across lines of business except where necessary
for data integrity and business continuity. This is self-evident.

4. The Basics Explained continued
13. Resource profile access lists should contain only groups, not user IDs. This is
true for the same reasons only groups should own resources.
14. Resource profiles must have some way of notifying the security administrator of
violations. Audit reports are not necessarily reliable, and they are certainly not
up-to-the-minute. Relying on reports, even if produced hourly, cannot catch all
security violations. Further, an access violation may well be a person who should
have access but does not. If the security administrator is notified immediately,
access problems can be corrected that much sooner.
15. Resource profiles for business data should have a UACC of NONE. One must
assume business data is private and should only be viewed on a need-to-know
basis. Permit access by business need only. Note this does not include general
program libraries, but does include business-specific program libraries.
16. Resource profiles should audit failures at one level above the UACC. In this way,
the data owner can audit resource access at any time while ignoring valid
accesses.
17. WARN mode should be only be used temporarily on new profiles, or when
making access changes to the profile. WARN mode allows access, so its use must
be limited.
18. Upon a change in a person’s responsibilities, examine their user ID and remove
them from sensitive groups immediately. Move the user ID to its new group
ownership structure as soon as possible to avoid any questions of incorrect data
access.
19. Revoke user IDs immediately upon notice of termination and delete them within
two weeks. We do not want any disgruntled employee causing problems.
20. Personal user IDs should not have direct access to database datasets. If an ID has
direct access to database datasets, that user can delete, or worse, update a database
incorrectly and not be caught immediately. There are other ways to manage the
necessity of updating databases (i.e. using a batch job) that are both auditable and
recoverable.
21. Datasets should have a naming standard that clearly shows who owns the data,
what kind of data it is, the purpose of the data, and whether it is production or test.
With a solid naming standard, building protective profiles becomes far easier, as
does auditing. If done right, the naming standard automatically groups like data
with like and similar protections with similar protections. This grouping makes
the security administrator’s job much easier.