In SAS 9.4, the SAS programming language continues add new features by the truckload. I've already discussed PROC DELETE (which is actually an old feature, but like an 80s hit song it's now back with a better version).
In this SAS Tech Talk video from SAS Global Forum 2013, I talked with Rick Langston about the advancements in the SAS programming language. Rick has been with SAS for...well, a long time. He's considered to be the steward of the SAS programming language. In this session, Rick discusses the process that we use to add new syntax to the language and to ensure its integrity.
Rick also talks about three specific new features in 9.4, all of which were added because customers asked for them. (It's difficult to read the Rick's syntax examples in the video, so I've included reference links below so that you can learn more.)
FILENAME ZIP access method
This brings the ability to read and write compressed ZIP files directly into the SAS language. For more information, see the FILENAME ZIP documentation. If you don't have SAS 9.4, you can still create ZIP files using ODS PACKAGE.
DOSUBL function
Rick calls this "submitting SAS code on the side", as it allows you to run a SAS step or statement from "inside" a currently running step. You can learn more from the DOSUBL function reference, or from this SAS Global Forum paper. I've also written a post with a specific example in SAS Enterprise Guide.
LOCKDOWN system option and statement
This one will excite SAS administrators. You can set the LOCKDOWN system option in a batch SAS session or SAS Workspace server to limit some of the "dangerous" functions of SAS and, more importantly, limit the file areas in which the SAS session will operate. We don't currently have a documentation link for this, so I'll dive in a bit further in a future blog post.
That's just a small taste of what's new. Be sure to check out the complete What's New in SAS 9.4 document for even more goodies.
7 Comments
The “Filename Zip” access and “dosubl” are nice new functions. The”lockdown” for administrators however is a very doubtful approach. Very often the dangerous use administrators see is the SAS usage as a whole. They want to lockdown the SAS usage, getting rid of that.
Coming into a situation seen SAS as opening up all data without control and being too difficult and expensive (Gartner reports under cautions) to operate, is bad promotion-sales for the market position.
The real problem is that the people at SAS architects, product managers, decisions makers are missing the growing importance on “data governance” and more in detail “standard of good practice” generic guidelines. Security should be there by design. It is not something to be done as a bug-fix. There are many references
http://owasp.org (nist docs http://nist.gov ,sans https://www.sans.org/critical-security-controls/)
http://istwb.org (technical application test, see the glossary) and many more.
As SAS cannot and is not allowed to overrule The OS security, Windows, Unix and a likes and the involved DBMS. It will be a DOA (Dead On Arrival) to promote something in this direction.
The better approach would be to try to get those security requirements to be fulfilled in a normal way according the common guidelines. It is needing to build it up from all involved technical layers, Using their controls, up to the daily usage.
Jaap, I agree with your points about using the DBMS and OS permissions as the first line approach to limit what end users can/should access. The SAS options like NOXCMD or LOCKDOWN do not grant privileges that end users don't already have, but they are simply an extra point of control that is specific to the SAS application. These options are something that admins have asked for to provide more flexibility, but they are not necessarily a best-practice approach to OS or data security.
In most cases, the SAS application runs as the user account, and is thus subject to the user's limitations on access and capability. SAS does nothing to override permissions that are set at the OS or data layer.
Chris, Thanks for your reply. I agree with your explanation and that was the reason for my reaction. I have experienced that, are recognizing elsewhere. What I see:
a/ Setting op security on user accounts at OS level is seen as very difficult within many organizations. They have to think about it to conform to existing procedures and guidelines. Mostly it is done by RBAC (Role Base Access Control) that is fundamental different to the SAS RBAC that is controlling the menu’s, SAS should call their approach MBAC and then getting aligned to RBAC.
b/ The other too difficult part is “priviledged access management” that is saying you should not grant more access rights to a person as normal is needed. Administrator actions should be centrally monitored as. The way SAS (BI/Di) is working, forking processes and setting rights (root level) is a replacement for the standard terminal way SSH way of working at the OS level.
The monitoring on elevating access rights is missed as this is normal SUDO usage. Sorry for the technical Unix terminology, the concepts at Windows and Mainframe are globally the same.
As a kind of reaction on this issues with all those difficulties the reaction of people not knowing “SAS” at this level well, are proclaiming to forbid use of personal keys. The users/analysts are not allowed to login at the OS and “SAS” should solve all the original requirements.
Marvelous to see instructions popping up that users analysts should directly login to the OS in some cases and expecting analysts to process data (flat files) to be placed there. Seeing all the cautions being mentioned about power users (Eguide) in Sas documentation. I have even experienced some design failures in metadata security concepts.
There is a contradiction by expectations, misunderstandings and lacking knowledge and failing consulting and explaining. Instead of granting some technical I would prefer to have this solved.
Pingback: Favorite SAS Blogs – Kathy Wisniewski's UNC Website
Pingback: Favorite SAS Blogs – UNC SAS Users Group
Hi, my name is kuldeep singh, i m a clinical sas programmer. i have query.
i have data set those have character and numeric variables. how can i check number of numeric variable and number of character variable.
id name age sex
1 a 24 f
2 b 34 m
3 c 30 f
4 d 32 f
5 e 40 m
;
This is a great question to post to the SAS Support Communities - be sure to include details about exactly what your goal is, so that your peers can offer the best help.