|
 |
       |
|
|
VCPs:
User defined commands are a great way to launch programs because through the command definition you can prescribe the valid values and default for a particular parameter, perform dependency checking between parameters and attach on-line help text to describe the command's function. Moreover you can attach a Validity Checking Program (VCP) to the command that will perform additional validation not provided for by the parameter values and dependencies specified in the command definition. The VCP executes before the Command Processing Program (CPP). One little known fact about Validity Checking Programs is that they execute during SEU. In other words if you type a command into a source member of type CLP, the VCP of the command will execute right then and there! That's a neat trick you say, but how does it represent a security exposure? Well not only does the VCP execute during SEU but it also executes during compilation! Image that a disgruntled programmer (a.k.a. IBOD -an Individual Bent In Destruction) bundles up a package of software that includes a CL program and the command that has a VCP attached. The change control process will dutifully compile all the objects from source including the CL program that includes your command with the VCP attached. Voila! IBOD has successfully launched a rogue program on your production processor with the full authority of a super user profile such as your application owner. The question is – how do you stop a programmer burying a nefarious function into a VCP? You could ban the use of VCPs altogether but then you would deny yourself of there value. Due diligence is the answer I think. \ The three basic tenets of a good security policy are: secure, control and then audit. In the case of VCPs it is the audit function that is appropriate. Make sure you know what VCPs are on your system and what they do - and check on them regularly.
|
