SECURITRE is an interface that allows all ADABAS/NATURAL related security data to reside in the SSF. This enables the site to have a single rule base for all resources and allows the SSF to control ADABAS, NATURAL, and ADABAS/NATURAL Utilities, providing a complete security system.
Since its release, Treehouse Software, Inc. (TSI) has been asked many questions about the product and its capabilities. Although these questions date back several years and many of the product's features have been enhanced, they may be helpful during your evaluation. While evaluating SECURITRE, keep in mind that TSI employs a full-time development staff to ensure that the product's features are constantly enhanced to meet the needs of sites everywhere. For information on the latest release of each product, visit our Products and Services page or contact TSI.
How does SECURITRE help a site restrict access to an application function, such as "delete"? What would the RACF/ACF2/TOP SECRET rule look like?
Answer:
For NATURAL applications, the site might code the application to call the "STRNAT" module, as shown in the following example:
o
oo
0900 INPUT (IP=OFF) #FUNCTION
0910 COMPRESS 'PAYROLL.MAINT.' #FUNCTION INTO
0920 ENTITY LEAVING NO SPACE
0930 CALLNAT 'STRNAT' USING
ENTITY
ACCESS
CLASS
ALLOWED
COMM-OK
OTHER
0940 IF COMM-OK /* IS THE DATABASE UP?
0950 IF ALLOWED /* IS FUNCTION ALLOWED?
0960 IGNORE /* EVERYTHING IS OK
0970 ELSE
0980 PERFORM FUNCTION-DENIED /* NOT ALLOWED TO
0990 ESCAPE ROUTINE /* USE THE FUNCTION
1000 ELSE
1010 PERFORM DATABASE-DOWN /* UNABLE TO CHECK SECURITY
1020 ESCAPE ROUTINE
1030 END-IF
o
o
oNon-NATURAL programs would call the "STRASM" module. Calls to STRASM are very similar to the STRNAT call shown above.If the user entered "DELETE" for #FUNCTION, the RACF/ACF2/TOP SECRET rule generated in the above STRNAT example would be:PAYROLL.MAINT.DELETENote that this dataset name could contain any value and length that is supported by your security system (RACF, ACF2, or TOP SECRET). Refer to the documentation for your security system to determine if it places restrictions on the dataset names you may use.To grant a user access to the delete function, the Security Administrator would grant the user access to the dataset "PAYROLL.MAINT.DELETE". If the security system supports wildcarding, granting the user access to the dataset "PAYROLL.MAINT.*" would give the user access to all of the above application's functions.
Question:
We would like to have an application that allows some users to modify certain fields and other users to modify all fields on a given map in the application. Could SECURITRE be used to prevent some users from moving the cursor to certain fields on-line in a NATURAL program?
Answer:
It should be noted that SECURITRE for ADABAS stops unauthorized modification of data by any source, including NATURAL programs. This security is independent of NATURAL and the application the user might be running. However, SECURITRE for ADABAS will do nothing to prevent the user from moving the cursor to an "unauthorized" field and "attempting" to modify that field on-line.
However, if the application is coded to call SECURITRE's STRNAT feature before displaying the map, the functionality you desire could be easily implemented and controlled through the SSF. For example, your application could check for the user's authority to access a rule, such as "PAYROLL.MAP.SPECIAL.FLDS". If the user has the authority to access this rule, then the program can set the control variables for this map, so that the "special" fields are modifiable. If the user does not have authority to access the rule, the control variables should be set so that these fields are non-modifiable. When the fields are non-modifiable, NATURAL will not allow the user to place the cursor on those fields and modify them.In this situation, SECURITRE provides dual protection. The STRNAT feature keeps the user from modifying certain fields via the NATURAL map. The SECURITRE for ADABAS feature provides an additional layer of security by ensuring that sensitive fields are not modified by unauthorized persons. Therefore, even if someone finds a way to bypass the application, they still cannot modify this data.For non-NATURAL applications, a similar call to the STRASM feature could allow the site to code the non-NATURAL application to provide comparable functionality.
Question:
We are trying to keep people from updating data from ad hoc programs that look like the real programs. Can we limit access to databases such that we can restrict a user from accessing the data through a program in batch rather than on-line?
Answer:
Yes. This would be accomplished through the Program Pathing feature of SECURITRE combined with DDM level security. Program Pathing can be used to ensure that only users running specific programs from specific libraries can access certain data. Program Pathing can also ensure that only specific batch jobs running certain programs can access the data.
If NATURAL programs are involved, SECURITRE can restrict which users may EDIT, CAT, SAVE, STOW, or RUN the sensitive programs. This, combined with Program Pathing, will ensure that ad hoc programs do not replace the "real" programs, and that only the "real" programs can manipulate the data.
SECURITRE DDM level security may also help. DDM level security controls which users may access DDMs. Users without authorization to access DDMs for sensitive data cannot compile programs that reference those DDMs.
Through the application security interface, can our site limit access to application functions, etc., through RACF/ACF2/TOP SECRET?
Answer:
Yes. In fact, the N2O interface to SECURITRE uses a similar method to limit access to N2O functions via SECURITRE. Your applications can call STRNAT or STRASM and request that SECURITRE check to see if the user has access to the function, menu, etc. SECURITRE will return a "yes or no" answer.
Can users bypass SECURITRE, as they can bypass NATURAL SECURITY?
Answer:
SECURITRE for NATURAL is implemented as a set of user-exits to the NATURAL nucleus. Any attempt to initiate a NATURAL session, LOGON to a NATURAL library, EDIT/CAT/SAVE/STOW a NATURAL program, or compile a program with a DDM will be monitored by SECURITRE. This control could only be bypassed by a user with the ability to create a NATURAL nucleus that does not have the user-exits installed.
We would like to install a product that will not impair the functionality of our existing products. Is SECURITRE compatible with our existing ADABAS/NATURAL products? Is SECURITRE capable of operating without requiring us to purchase additional hardware or software?
Answer:
SECURITRE is installable and executable on any mainframe running the MVS operating system and ADABAS/NATURAL. SECURITRE requires no zaps to any operating system, teleprocessing system, or Software AG product. SECURITRE does require a System Security Facility, such as IBM's RACF, or Computer Associates' ACF2 or Top Secret. SECURITRE does not require the NATURAL Security System (NSS) and will not impair the functionality of any existing products. SECURITRE should not require changes to, or the addition of, any hardware.
Question:
We are considering switching our SSF from ACF2 to RACF. Will SECURITRE move with us?
Answer:
SECURITRE uses System Authorization Facility (SAF) protocol to communicate with the major SSFs. By simply changing the SECURE parameter in SECURITRE from ACF2 to RACF, you indicate to SECURITRE that you are now using RACF. All SECURITRE calls to the SSF will be generated in a form acceptable to RACF. Later, you may change SECURE to TSS if you switch to Top Secret. In other words, a single parameter change within SECURITRE is all that will be required to switch SSFs. Of course, you'll have to switch the security rules you coded in ACF2 to RACF, but you would have had to do that anyway.
Question:
We recently received correspondence from another vendor, which referred to "standardized user-exits", and talked about a zap to ADARUN. What does "standardized user-exits" mean to Treehouse? Will this zap to ADARUN affect SECURITRE Utility Security?
Answer:
Another vendor's standardization of user-exits does not affect TSI. The zap to ADARUN will not cause problems for TSI because SECURITRE Utility Security completes its execution before ADARUN is invoked. However, you would need to apply the zap to ADARUN before linking it to the SECURITRE Utility Security module.
Question:
We currently use ADAESI, which uses 20-byte non-delimited SSF rules for security checking. Can these same rules be used by SECURITRE, so that we can avoid having to re-enter them?
Answer:
Yes. SECURITRE supports delimited and non-delimited rules. By specifying a null value for the DELIM parameter, sites can ensure that SECURITRE will generate non-delimited rules. However, SECURITRE can also support a combination of delimited and non-delimited rules, as well as rules up to 44 bytes in length. Rules can follow the ADAESI "D102F110" style naming standards or use more meaningful names, such as "PROD.PAYROLL". Dataset naming for ADABAS is handled by the PREFIX, QUALIFY, DELIM, and DSNORDR parameters. The STRFNR statement allows the site to set specific dataset names that apply to a particular file or group of files. The SECURITRE manuals offer additional information about these and other SECURITRE parameters.
Question:
Will SECURITRE work with implementations of ADABAS that use ADABAS' data encryption feature?
Answer:
Yes. ADABAS data encryption has no effect on SECURITRE operation. SECURITRE will also have no effect on the operation of ADABAS data encryption. Users continue to supply the cipher code in the ADABAS control block, and SECURITRE passes this cipher code to ADABAS without modification.
Question:
What is the impact to Top Secret performance of non-ADABAS checks using SECURITRE?
Answer:
The only impact to Top Secret performance by non-ADABAS checks using SECURITRE would be the additional volume added by SECURITRE. This should not be noticeable. We have never had a complaint about SECURITRE negatively impacting Top Secret performance.
Question:
Does SECURITRE work with all current releases of ADABAS, NATURAL, and Top Secret?
Answer:
Yes. In fact, during the four years the product has been available, there has been no known compatibility problem between SECURITRE and ADABAS, NATURAL, or Top Secret.
Question:
When a new version of any of the above products is released, would we normally experience any outages due to incompatibility of SECURITRE with the new release? If so, how long would the outage last?
Answer:
SECURITRE uses standard SAG-supplied User-exits and other standard techniques to accomplish its interfaces to ADABAS, NATURAL, and PREDICT. It is in SAG's best interest to avoid changing how these User-exits operate, since even minor changes can potentially affect thousands of users and products (including SAG's own products).
Furthermore, SAG has not changed the format of various items from which SECURITRE gains its security information, such as the Control Block, Command Codes, File Numbers, Format Buffer field list, etc. It is unlikely that SAG will change these because of the problems this would create for all SAG users.The SECURITRE interface with TOP SECRET is performed through the standard RACROUTE macro. If this macro should ever change, SECURITRE should be able to adjust to the change very quickly and easily.Because we use no "special" interfaces to the SAG products or the security system, you will normally not experience any outages due to product incompatibility. Our normal time to figure out incompatibilities (if they exist) between SECURTIRE and a new version of ADABAS, NATURAL, and Top Secret has been approximately one day. Our longest period of incompatibility was one month.
Our extensive international network of contacts often gains us access to new releases of SAG products long before most U.S. customers receive them. As a result, by the time a site installs a new release of ADABAS, NATURAL, or Top Secret, SECURITRE is already compatible.
All of our current products interface with ACF2 using a 3-, 4-, or 5-part dataset names. In order to be consistent across all environments, we feel this is needed for ease of use and will decrease our workload in the future. Does SECURITRE support dataset names like those we use?
Answer:
You can generate similar dataset names in SECURITRE. You can also do some things that will decrease your workload even more. For example, if all Payroll files on the Production database are identically secured, rather than having to code many identical rules in the SSF, you could have SECURITRE generate the dataset name "ADABAS.PROD.PAYROLL" for all Payroll files on the Production database. Thus, only one SSF rule needs to be coded for many files. The same idea could be used to implement security for several related databases and hundreds of files, simply by having SECURITRE generate the same dataset name for all of those files.
Question:
In our ACF2 environment, datasets are secured. How does SECURITRE secure the ADABAS "datasets"? And how are these datasets defined to SECURITRE?
Answer:
SECURITRE logically breaks down each ADABAS database into 256 files (pseudo datasets). SECURITRE provides two macros that are used to describe all parameters to SECURITRE including dataset names. The first macro is STRDEF. It is used to specify default parameters in effect for the entire database. The second macro is STRFNR, and it is used to override the default settings for a given file or set of files. SECURITRE's ADABAS Utility Security feature provides dataset names, which also include the utility name and function.
Can the DBID be included in the RACF dataset name for utilities?
Answer:
Yes. SECURITRE for Utilities allows the site to specify whether the dataset name should include the DBID, FNR, Utility, and/or Utility function. SECURITRE also allows the site to determine the order in which these components are connected to each other. For example, one site may wish to specify the DBID/FNR first, followed by the Utility and Utility Function. Another site may wish to specify the Utility first, Utility Function next, and omit the DBID/FNR. Refer to the SECURITRE documentation for more information.
If I add a DDM to the FDIC and forget to grant a user access to the DDM, must CICS be brought down to give that user access to that DDM?
Answer:
No. Grant the user access to the DDM through the System Security Facility and purge the user's entry from the SECURITRE internal tables using the Real-time Monitor. The user will have access to the DDM on the next attempt.
SECURITRE has a very impressive list of features, including several levels of NATURAL access controls, such as Program and Library level security. If I install SECURITRE, do I have to use all of those features?
Answer:
No. The various SECURITRE features are designed to permit them to be used independently. For example, you may use only Session Initialization and Program Level security on the NATURAL side and not use DDM security if you prefer. If you later decide to discontinue use of Program Level security, or to begin using DDM level security, you may do so. SECURITRE will grow and adapt to meet your site's changing security needs.
Will SECURITRE work with implementations of ADABAS that use field-level security checking?
Answer:
Yes. SECURITRE does support field level security checking.
Question:
Will SECURITRE work with implementations of ADABAS that use field value level security?
Answer:
TSI's Evaluator Kit for SECURITRE contains an explanation entitled "The Security By Value (SBV) Issue", which includes specific information about this topic.
Yes, although it is unclear precisely what you mean by "stages". SECURITRE has been designed to be very flexible and to assist customers in "phasing in" security checking. SECURITRE can be activated on a file-by-file basis, and offers three modes of security checking (Dormant, Warn, and Fail). These mechanisms combine to allow for a very smooth implementation. Refer to the SECURITRE Administrator Guide for more information about implementing SECURITRE in stages.
When SECURITRE is initially installed, does the site need to specify everything that must be secured (or not secured)?
Answer:
No. SECURITRE supports a "phased implementation" process, whereby resources may be secured one at a time. For example, the site might secure one ADABAS file. Once this file is secured, and the rules are all defined to the security system, the next file may be secured, etc. until all desired files are secured.
In addition, SECURITRE provides three modes: Dormant, Warn, and Fail.In Dormant mode, no security checking is done. This mode allows you to install SECURITRE so that you may begin activating it later if desired.In Warn mode, security checking is performed, but unauthorized access is not stopped by SECURITRE. Warn mode allows you to ensure that all of the necessary security rules are defined to the security system without having to worry (for example) that a Production system might be stopped because a rule was incorrectly coded or not coded at all. In this mode, the security system will log all violations to security. By examining this log, the security administrator can determine if the violations were caused by an oversight. If they are caused by an oversight, the security administrator may correct the oversights before placing SECURITRE in Fail mode.With SECURITRE in Fail mode, security checking is performed, and unauthorized accesses are stopped. All violations are logged by the security system and can be viewed by the security administrator.
SECURITRE allows the "mode" to be set at a default level (for example, Dormant mode for one database, Warn for another, etc.). The default mode can be overridden at a resource level (for example, Dormant for the database, but Warn for files 102-110, and Fail for file 231). This gives a site considerable flexibility in terms of which resources are secured and how stringent the security is enforced on those resources.
Does SECURITRE log violations only, or does it have an option to log all or selected transactions for debugging purposes?
Answer:
The function of SECURITRE is to act as an interface between the ADABAS/NATURAL environment and the SSF. SECURITRE does no logging of its own. Any logging will be done by the SSF, so all of the logging and trace functions of the SSF are available. The number of violation messages can be controlled via the SECURITRE parameter LOGVIOL. This parameter can be specified as ALL to cause SECURITRE to tell the SSF to log all violations by a given user for a given file. LOGVIOL may be set to FIRST, causing only the first violation to be logged by the SSF. Subsequent calls rejected by SECURITRE are not logged.
SECURITRE does provide an internal trace printout for debugging purposes. The printout is designed to help customers and TSI technical support personnel to diagnose a problem rapidly. The trace may be activated or deactivated via the SECURITRE parameters or through the SECURITRE Real-time Monitor.
What library name is placed in the pseudo dataset name when a user executes a program from a STEPLIBed library?
Answer:
Currently, SECURITRE inserts the name of the library onto which the user is logged. We can provide a zap to insert the name of the library where the program resides if needed.
Question:
If USRMODE=OFF is specified for a library in the STNLIB parameters, and a user logs on to that library (LIB-A), then logs on to another library (LIB-B), and runs a program that sets NC=OFF (equivalent to USRMODE=ON), will the user be able to log back on the LIB-A and execute NATURAL commands?
Answer:
No. When the user logs back on to LIB-A, SECURITRE sets NC=ON (USRMODE=OFF).
Question:
In programs with highly sensitive data, we would like to re-verify the user's password before the user is allowed to examine or modify data. Can SECURITRE help with this?
Answer:
Yes. In your programs, before data is displayed or modified, you can request the password from the user and code a call to STRNAT. The pseudo dataset name might look like this:
NATURAL.PASSWORD.pswdIn the above example "pswd" is the password entered by the user. If the SSF grants the user access to this dataset, the program can assume this is the correct password for this user and allow the user to display or to modify the data. This provides the advantages of ensuring that the password given by the user is correct and that the user giving the password is actually authorized to use that password.
Question:
Is it possible to use just the SECURITRE for ADABAS component of SECURITRE, and not use the components for securing NATURAL, Utilities, etc.?
Answer:
Each component of SECURITRE can be used independently. It is possible to use SECURITRE for ADABAS without using any other part of SECURITRE. It is possible to use SECURITRE for NATURAL without using the ADABAS portion. It is possible to use only SECURITRE for Utilities. It is also possible to use any combination of the components. Each site determines what to secure and how strictly it should be secured.
Question:
Does SECURITRE work with single-user mode ADABAS and/or ADABAS utilities that do not use the ADABAS nucleus?
Answer:
SECURITRE works with single-user mode for ADABAS Utilities only. The file security user-exit does not get called in single-user mode ADABAS. However, access to single-user mode ADABAS can be controlled by securing access to the utilities.
Treehouse Software implements SECURITRE for ADABAS Utilities as a statically linked front-end to the ADARUN module. This enables SECURITRE to secure all ADABAS Utilities, whether those utilities use the ADABAS nucleus or not.
Question:
Is a benchmark comparison using ADABAS security versus SECURITRE and Top Secret available.
Answer:
No. Such a comparison would probably not be very meaningful, given the many potential variations of ADABAS security implementations, SECURITRE implementations, CPU environments, etc.
Does the Natural Command Processor adversely affect SECURITRE?
Answer:
The NATURAL Command Processor (NCP) at its most basic level merely takes a user's command line input and cross-references this to a specific NATURAL program that must be invoked. When NCP invokes that NATURAL program, SECURITRE will check to see that the user has the authority to run the given program. Thus, the use of NCP presents no problems for SECURITRE.
We like certain aspects of NATURAL Security (NSS) from Software AG. Won't SECURITRE require us to replace NSS?
Answer:
SECURITRE will not require you to eliminate NSS. However, there are some reasons you might want to consider doing this anyway.
NSS does not secure NATURAL resources through the SSF. If you install and use SECURITRE (for ADABAS) and NSS (for NATURAL), you will store security rules for NATURAL in NSS, security rules for ADABAS in the SSF, and non-ADABAS/non-NATURAL security rules in the SSF. You are therefore using two security rule bases, each of which is maintained separately, increasing the effort and the potential for administrative error. The NSS Conversion Facility of SECURITRE can be used to make the conversion process simpler.Many sites report that NSS consumes a significant amount of resources. SECURITRE for NATURAL, which is written in Assembler, is very efficient.SECURITRE provides some controls that are not available through NSS. To the best of our knowledge, all NSS checks are made at compile time only. SECURITRE makes both run-time and compile-time checks of security.Many sites have also complained about the difficulty of reporting on security related information from NSS. They also dislike having to combine reports from the SSF, NSS, and other sources to create a comprehensive document showing what a given user may access. Using SECURITRE, these sites are able to place all rules in the SSF, requiring them to report information from only one source (the SSF) to show what any user may access.
Question:
If SECURITRE is installed, will it replace the NATURAL Security System (NSS) from Software AG and allow us to bypass the NSS menus?
Answer:
With SECURITRE for NATURAL installed, it is possible to eliminate NSS completely from the site's environment as far as security checks are concerned. SECURITRE will check to ensure that each user's attempts to initiate a NATURAL session, logon to a library, examine/modify a program, access a DDM, etc. are all verified with the System Security Facility (RACF, ACF2, or Top Secret). In fact, SECURITRE includes (at no additional charge) a NATURAL Security Conversion Facility, which can assist the site in configuring SECURITRE for NATURAL. On the other hand, if the site wishes to continue to use NSS to control NATURAL instead of (or in addition to) SECURITRE, it may do so.
If the site wishes to use SECURITRE for its NATURAL access controls, and NSS for its various other functions (e.g., mailboxes, report size limits, etc.), this is also possible. The site can activate SECURITRE security checking, deactivate the equivalent NSS security checking, and leave all other NSS functions in operation. The site then has "the best of both worlds", with NSS providing mailboxes, etc. and SECURITRE handling security.
Does SECURITRE's NATURAL Session Initialization Security provide a way to force a user who specifies a given FUSER file to use a corresponding FDIC file?
Answer:
SECURITRE currently provides the capability to force a user to specify corresponding FUSER and FDIC files. Consider this example:
A site uses three NATURAL modules, one for the TEST environment, the next for the STAGE environment, and the last for the PROD environment. The Security Administrator codes the following SECURITRE for NATURAL parameters for the TEST environment:STNPARM PREFIX='NATURAL',QUAL='TEST',DELIM='.',NSIORDR=(FILE)
STNFILE TST,DBID=123,FNR=200 (TEST FDIC)
STNFILE TST,DBID=123,FNR=201 (TEST FNAT)
STNFILE TST,DBID=123,FNR=202 (TEST FUSER)To grant access to the TEST environment, the Security Administrator grants a user access to the following pseudo dataset name in the SSF:NATURAL.TEST.TSTIf the user attempts to initiate a session from the TEST NATURAL module using the TEST FNAT, STAGE FDIC, and PROD FUSER, SECURITRE verifies access to these pseudo dataset names:NATURAL.TEST.TST
NATURAL.TEST.STG
NATURAL.TEST.PRD
Because the Security Administrator did not grant the user access to all three of these dataset names, the session will not begin. In order to initiate a NATURAL session, the user must specify an authorized set of FNAT, FUSER, and FDIC files.
Can you please explain how users and rules are maintained at SECURITRE sites. When a new user arrives at the site, how and where is this user defined?
Answer:
When new users are added at a SECURITRE site, they are added to the security system (RACF, ACF2, and Top Secret) as they are normally added. The users are granted access to any resources they might need, such as COBOL datasets. If the users require access to ADABAS and NATURAL resources, they must be granted access to the dataset names by which these ADABAS/NATURAL resources are denoted to the security system. No changes need to be made to SECURITRE to support the new user.
When new ADABAS/NATURAL resources are added at a SECURITRE site, the site must determine the dataset name by which SECURITRE and the security system will refer to the resource.For example, assume a SECURITRE site adds a new ADABAS file, number 103 to its the Production database. The file is to be used for the Inventory application. If the site chooses to refer to the new file by the default dataset name of "ADABAS.PROD.F103", then no SECURITRE parameter changes would be required. The site would simply define this new dataset name to the security system and give the appropriate users access to this dataset name. On the other hand, if the site chooses to refer to the file by a more meaningful name, such as "ADABAS.PROD.INVFILE", this dataset name must be defined to the security system. It will also, in this example, have to be defined (once) to SECURITRE. The following SECURITRE parameter would be coded and added to the existing SECURITRE parameter set:STRFNR FILE=103,NAME=INVFILE
The new parameter set would be assembled and linked to ADABAS. The SECURITRE Real-time Monitor could be used to refresh this parameter dynamically, allowing SECURITRE to immediately begin checking security for this new resource.
Won't the overhead of security checking cause performance degradation?
Answer:
The developers of SECURITRE are very performance-conscious. They have taken every possible effort during the development of SECURITRE to reduce the overhead it generates to avoid a noticeable negative impact on response time. The SECURITRE internal tables are an example of these efforts. By storing information about recent ADABAS accesses in an in-core table, SECURITRE can perform fast look-ups and more quickly verify that a given user has access to a particular resource.
One of Treehouse Software's affiliates discussed SECURITRE overhead with a client. The client benchmarked SECURITRE overhead at 5% (or less) of the total CPU consumed by ADABAS in the client's environment. Since SECURITRE overhead can be affected by a number of factors, including SSF performance, table sizes specified by the site, the number of SSF checks made, etc. no estimate can be guaranteed to be accurate at all sites. Your site might experience a lower (or slightly higher) overhead with SECURITRE, depending upon the SECURITRE parameter settings you select and the performance characteristics of your specific environment.
Can SECURITRE parameter changes be made dynamically?
Answer:
Some parameters can be changed dynamically by modifying their values on-line in the SECURITRE Real-time Monitor. These changes will take effect immediately. The site may also change the parameter values and reload the parameter module via the SECURITRE Real-time Monitor. This will also cause the parameter to be immediately changed, and this change will be in effect even after the database is brought down and back up.
A few SECURITRE parameters, particularly those related to the size of the internal table, cannot be changed dynamically. Any parameter that affects the GETMAIN area acquired by SECURITRE when the ADABAS nucleus is brought up cannot be changed dynamically. The site only needs to bring the database down and up to reflect the changed parameters for the parameters that change the GETMAIN area.
Dynamic parameter changes do not affect the settings of the SECURITRE parameters that are statically linked to the ADABAS nucleus. As a result, such parameter changes are normally lost when the database is brought down and up. Thus, sites generally do not use dynamic parameter changes once SECURITRE is fully implemented, since these changes could be "lost".
When a user connects to the mainframe via CON-NECT from a PC or LAN, will SECURITRE's Program Pathing feature continue to work?
Answer:
Depending upon the Program Pathing options being used to protect a particular ADABAS file, Program Pathing would still continue to work with SECURITRE installed. We have no experience with CON-NECT and cannot comment specifically without further information.
What does TSI do to ensure the quality of its products?
Answer:
Treehouse Software has always considered product quality an important issue. Every product undergoes testing in-house before being shipped to BETA test sites. Following thorough BETA testing, the product is made available for general release.
More recently, Treehouse Software is improving its Quality Assurance program. Our Quality Assurance staff continuously improves our Standard Quality Procedures to monitor and control the quality of each release. Formal standards and policies are evolving for BETA testing to ensure that each release is properly tested.
Will SECURITRE function with RACF Group-ID in place of User-ID?
Answer:
Using RACF groups to administer the security rules is a great way to reduce administration requirements. No changes need to be made to the SECURITRE product to take advantage of this. SECURITRE controls access to ADABAS data by generating a dataset name that can be treated in RACF as controlling access to a dataset.
The use of DISCRETE or GENERIC profiles is also recommended.A DISCRETE profile contains a description of a dataset and a list of User-IDs authorized to access it.A GENERIC profile is similar to the DISCRETE profile except that it can protect many datasets having a similar naming structure. This saves administrative work because the individual datasets do not have to be defined to RACF.
Note that the options above must be activated by the RACF SETROPTS command. Refer to the IBM publication RACF SECURITY ADMINISTRATOR GUIDE SC28-1340 for the format and use of this command.
Is the SECURITRE internal table dynamic, and does it GETMAIN more space as needed?
Answer:
The SECURITRE internal table is GETMAINed when SECURITRE is first activated for a given database. This table size cannot be changed without bringing the database down and up.
Question:
Can you adjust the size of the SECURITRE internal tables?
Answer:
Yes. Because each site's environment is different and because each database at the same site may be used differently, SECURITRE includes a variety of parameters that adjust the size of the internal table. This allows a site to tailor the size of the table to meet its specific needs. The SECURITRE documentation describes how to determine the optimum table size. In addition, TRIM displays information about the efficiency of the SECURITRE internal tables. This information can assist in setting tables.
Customers have told us that ADAESI is somewhat inflexible with regard to dataset names used in the SSF. SECURITRE allows great flexibility with regard to dataset names. It appears that ADAESI does not secure ADABAS Utilities or NATURAL, while SECURITRE does. With ADAESI, a site must purchase NSS in order to get some measure of control over NATURAL. NSS does not store its rules in the SSF, which means that it adds another security rule base to the site, undermining the purpose of ADAESI. ADAESI seems to provide only rudimentary support for ADABAS file/field security. SECURITRE goes beyond this to encompass other issues, such as Program Pathing.
Question:
With ADAESI being given to us free, it is difficult for us to justify purchasing SECURITRE to our management. Don't you agree?
Answer:
Free is not always good. If your ADAESI security is not fully effective, security is breached, and corporate assets are lost or stolen. In this case, "free" doesn't mean "without cost", does it? We believe the prices reflect the value. SECURITRE provides all of the capabilities of ADAESI, along with many additional capabilities. SECURITRE will allow the use of ADABAS Utilities and NATURAL Utilities to be secured at the utility, utility function, database, and file levels, as appropriate. SECURITRE also secures NATURAL, providing both run-time and compile-time security checks. One of SECURITRE's greatest advantages over ADAESI is that it allows very flexible dataset naming based on site-specific dataset naming conventions. For example, a given file can be defined to the SSF as "ADABAS.PROD.PAYROLL", as "ADABAS.D123.F102", or in some other form determined by the site.
Must a site specify STNFILE parameters for ALL files, including data files?
Answer:
No. If STNFILE parameters are not specified, SECURITRE generates default pseudo dataset names based on the DBID/FNR combination. STNFILE statements provide "alias" names for files to simplify security administration. For example, rather than granting access to the cryptic pseudo dataset name "D213F123", the Security Administrator can grant access to the more meaningful database name "TEST" and file "PAYROLL". The resulting pseudo dataset name is "TEST.PAYROLL".
Does TSI provide support for SECURITRE outside normal business hours?
Answer:
Treehouse Software maintains a 24-hour, 7-day support system. Technical personnel are on call around the clock to solve customer questions or problems.
Question:
Is TSI dedicated to support of SECURITRE? Does TSI employ full-time developers to maintain and enhance SECURITRE and make it possible for us to speak directly with product developers to discuss problems and enhancements?
Answer:
Treehouse Software has considered SECURITRE to be an important, strategic product since SECURITRE was introduced in 1989. The SECURITRE Development Team includes three programmers, who acquire assistance from others as needed. Any SECURITRE customer or prospective customer wishing to speak to a developer needs only to call Treehouse Software. Often, the developers speak with current and potential customers to discuss the value and implementation of intended enhancements to evaluate how users would prefer these enhancements to be implemented.
Question:
Is TSI willing to travel to our site to assist in the installation and setup of SECURITRE? Does TSI offer training in the use of SECURITRE if needed?
Answer:
Treehouse Software's technical representatives are available to visit customer sites to assist with the installation, training, and setup of SECURITRE. Most sites, however, find that SECURITRE requires little or no formal training, and that the installation can be quickly and easily accomplished using in-house resources.
Can a site flush out the tables occasionally to prevent "old" security information from being maintained in them?
Answer:
Yes. SECURITRE can be set to periodically flush the tables at certain intervals or at certain hours of the day. In addition, it is possible to use the SECURITRE Real-time Monitor to remove one or all users from the internal table to ensure that the table is synchronized with RACF/ACF2/Top Secret.
Is TRIM desired and/or necessary to display SECURITRE information on-line including performance and violation statistics?
Answer:
SECURITRE provides its own Real-time Monitor, which allows a Security Administrator to perform many functions on-line. The SECURITRE Real-time Monitor allows the user to display SECURITRE parameter settings, reset one or all users' entries in the internal tables, reload parameters, etc.
TRIM is not a requirement for SECURITRE. However, the TRIM Real-time Monitor can report certain performance statistics about SECURITRE. TRIM can also display recent SECURITRE violations by several categories, including User-ID, NATURAL SECURITY Application, etc. If you wish to view these TRIM statistics, then TRIM is required.
Using Top Secret, it is possible to view the violation information for all resources protected by Top Secret. This includes the resources protected by SECURITRE. It is not necessary to have TRIM to view these statistics.
Is SECURITRE designed/structured in a way that allows for the activation/implementation and deactivation/removal of the product upgrades without significantly disrupting production facilities.
Answer:
Conversion from one version of SECURITRE to another generally requires nothing beyond a simple installation of the new software. SSF rules will not have to be modified.
The removal of SECURITRE from your system will have no effect on Production, except that the data and applications will no longer be secured.
SECURITRE controls appear to be defined per User-ID. Does a facility exist to define rules by groups of User-IDs similar to Top Secret Profiles?
Answer:
SECURITRE interfaces with Top Secret to determine a given user's access to a file. This means that a "PERMIT", written to a Profile for which the user is a member, will be recognized by SECURITRE.
Question:
You say that using User-IDs instead of passwords makes SECURITRE's control more effective. Why User-IDs instead of passwords? Does it mean that user access to all files (on the same database) is always verified once the User-ID has been connected to the database?
Answer:
The reason that SECURITRE uses User-IDs instead of passwords is that the use of passwords has an inherent weakness. If the password becomes known, then access to the file is allowed. This type of security is too easily breached. In response to the second question, SECURITRE will only verify authorization when access to a file is actually attempted. In other words, if a user attempts to access file 27 on database 13, SECURITRE will only check for authorization for file 27. Further, SECURITRE will not check for both READ and WRITE access if the command being authorized is only a READ command.
How would a site secure a non-ADABAS file, such as a VSAM file, when SECURITRE is installed?
Answer:
Non-ADABAS files, including VSAM files, are secured the same way that they were secured before SECURITRE was installed at the site. SECURITRE does not provide security for non-ADABAS files. NATURAL DDMs are secured by SECURITRE, regardless of whether those DDMs refer to ADABAS files or VSAM files.
