white paper, the basics of data security

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.

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.

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.

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.