07-26-2015 07:03 AM
Is it possible under sas to make hidden sas code in all log and in particulor the log of administrator ?
I know the option "options nosource; " ?
Is it possible to develop a sas function or program, the user can use it, but, they have not acces to program code ?
07-26-2015 09:00 AM
Hiding sas code as security measure in a log makes no sense as of auditing tracability requirements you should have logs for that.
With good coding habits one of those is avoiding hard coding physical names users and passwords. All with is related to DTAP business-code or DTAP business-data should be eliminated by some standards being set by admins. The config area-s (usermods_autoexec usermods_config and usermods_scripts) are offering point to do that.
For the password being coded somewhere (macro) use _PASSWORD (caps!) suffix. The usename itself is not relevant to hide in contrary. See Hiding Passwords and Other Sensitive Data SAS(R) 9.4 Stored Processes: Developer's Guide, Third Edition. The same applies to Eguide and ARM handling.
These hiding data options are not very well documented by SAS as some security measure.
There is another reason you cannot hide code, that is SAS code is normally interpreted. That is the code is read compiled and executed at run-time. By that you do not have segregated code and executable files. Noting this you can compile sas macro-s and sas datasteps. There are more like those like fcmp formats SCL.
The datastep view SAS(R) 9.4 Statements: Reference, Fourth Edition The macro compile SAS(R) 9.4 Macro Language: Reference, Fourth Edition
You could give access to the compiled parts and not able to see any code. The disadvantage of this you must have a very strict release management process not allowing to change any code are break the code / loadable combination. Having a working program you are responsible for but not knowing or having any code to show is even worse than abel te see the code. The main argument for Open-source is everyone can see the code and get convinced it is correct.
When the only real requirement is developers should not be able to change production that gets unintended to production, than solve that. This sentence is the goal with regulations, the sentence of not able to get the code it is often practized not really trustworthy implementation. Get back to the one asking for this.
It can be found at eg ISO/EIC 27002 9.4.5
Access to program source code should be restricted.
Access to program source code and associated items (such as designs, specifications, verification plans and validation plans) should be strictly controlled, in order to prevent the introduction of unauthorized functionality and to avoid unintentional changes as well as to maintain the confidentiality of valuable intellectual property. For program source code, this can be achieved by controlled central storage of such code, preferably in program source libraries. The following guidelines should then be considered to control access to such program source libraries in order to reduce the potential for corruption of computer programs:
a) where possible, program source libraries should not be held in operational systems;
b) the program source code and the program source libraries should be managed according to established procedures;
c) support personnel should not have unrestricted access to program source libraries;
d) the updating of program source libraries and associated items and the issuing of program sources
to programmers should only be performed after appropriate authorization has been received;
e) program listings should be held in a secure environment;
f) an audit log should be maintained of all accesses to program source libraries;
g) maintenance and copying of program source libraries should be subject to strict change control procedures (see 14.2.2).
If the program source code is intended to be published, additional controls to help getting assurance on its integrity (e.g. digital signature) should be considered.
The construction can be as easy by defining at least 4 segreagated locations D.T.A.P (many more options) for the application code. Than define concatenated loactions for those. At D (Develop) only allowing code that is being maintained nothing more. Moving the code and having that concatenation is eliminating all other kind of questions.
The moving should be done as part of privileged actions not by personal keys but by dedicated functional ones.
07-26-2015 12:50 PM
Macro STORE and SECURE option.
SECURE | NOSECURE
causes the contents of a macro to be encrypted when stored in a stored compiled macro library. This feature enables you to write secure macros that will protect intellectual property that is contained in the macros. The macros are secured using the Encryption Algorithm Manager.
A NOSECURE option has been implemented to aid in the global edit of a source file or library to turn on security (for example, when you are creating several macros that will need to be secure). When creating the macros, use the NOSECURE option. When all macros are completed and ready for production, you can do a global edit and change NOSECURE to SECURE.
If you use the SECURE and SOURCE options on a macro, no output is produced when you use the %COPY statement. The following NOTE is written to the SAS log:
NOTE: The macro %name was compiled with the SECURE option. No output will be produced for this %COPY statement.
07-27-2015 05:21 AM
I agree with the above posters, if you don't trust your users to see the code, why are you asking them to run it? I have had this recently myself, closed box macro library, sent to me. I ran the code and it fell over at the first macro call. The code is hidden from me, so I stopped at that point and sent the whole thing back to the owner. If its passwords you want hidden, then I can understand that. Have a look at pwencode - creates and encrypted string which you can then use in other programs without knowing the underlying password.
07-27-2015 02:29 PM
RW9, That is the bad joke about pwencoded passwords. When seen you can copy and paste it to other SAS code and it will work in the copied one. No need for knowing the underlying password. SAS will convert it back to the underlying when that is need at run-time.
07-28-2015 03:54 AM
Yes, of course, however that only works through SAS, and as the SAS system would be access controlled, you can log activities using that through the SAS setup.
07-28-2015 05:32 AM
Let me see wat your statement is. You have the access open to be copied by coders from one source to other sources en you are controlling every possible editor for that. (cut/paste notepad windows?). I do no believyou are in control at that level. Getting in another part of code the connection can be made to any location it was supposed to protect. You are starting some big-data project to have the proof of which invollved desktop /connection to which server and server connections has been made to find the evil one (or others).
Suppose it was your house. Put your front door key and all other information to valuable information under the front-door mat. Than make the claim everything is safe because you an advanced monitoring system by which you can see which evil and all other ones have entered your house. Doing things they like eg an unplanned transportation of goods.
Making it physical it is obvious the approach doesn't make sense.
07-28-2015 07:56 AM
Nope. I was thinking more on these lines: Say we have a standard login to a database, I want the team to access the database from SAS, but not access it in other software. Now all those members authorise into the SAS environment. Usig the pwencode, they can login to SAS using their credentials, access the database using the encrypted key, but otherwise not be able to login. Each tools has its own purpose, the pwencode is to obscure the pw for anything but the SAS environment.
07-28-2015 08:34 AM
Ok That is better, still not completely closed. The assumption of everyone sharing the same key and password to oracle will make it impossible at the oracle side to be auditable/traceable. That can be a result of the data classification being not that critical/important.
The other one it is a hash, you are expecting it cannot be reverted. Wrong, it is reverted by SAS. Knowing/finding that one you can do it also yourself. Another one: at the moment you are having some requirement of an external procedure being used needed the password in that non-sas script it cannout be encoded. (Bteq publishing)
Often security people are making teh statement security by obscurity is no securiyt.
The physical one: You have put the key not under the doormat but in the -th flower-pot aside the entry.
07-27-2015 02:51 AM
Need further help from the community? Please ask a new question.