I found a nice link: ISO/IEC 27002 code of practice technical implementation.
A more generic is: Standard of Good Practice - Wikipedia, the free encyclopedia
Detailed and Unix folders and processes Linux Directory Hierarchy: Oriented to the Software Parts
Related threads:
- https://communities.sas.com/thread/62575
- https://communities.sas.com/message/236488#236488
IMO it is something to do more about this as of regulations. Any additional thoughts to discuss?
Hi Jaap, thanks for opening this discussion.
Unfortunately, I am not a standards expert, not for ITIL, TOGAF or for ISO. So no direct thoughts on it, for now. But some indirect thoughts, I do. I feel interested on those topics, and also strongly interested about the different perspectives about how SAS implements Business standards (or it does not).
So maybe you and other people here can guide me well through this delicate path. My higher interest now is to find out some kind of relationship mapping across pros and cons for this topic on the most practical way.
And for it, I will start with a single and simple comment: what I can see from my experience, is that looks like SAS is adapting some standards, and best practices for the business and IT on security, deployment, etc. I still can see how SAS is also imposing some requirements to the business and to IT, its own. I believe it is not necessarily a bad situation. I do believe it serves on the interest on several areas inside and outside SAS.
Which functionalities and standards do you think are included within latest versions of SAS and which ones are you (or your business needs) missing? I feel curious.
Juan, a you are working at the NL area and your company is doing a lot healtharea, this link is interesting. Links overzicht - NEN 7510 If a google I can find similar ones for other countries.
http://en.wikipedia.org/wiki/Internationalization_and_localizationThere is a reference back to that iso 27002 NEN 7510 - NEN 7510 . There is no need to be a standards expert as it are guidelines. Something like driving a car. There are a lot of rules on avoiding accidents (keep the right side). Important is understanding the intentions and how to get aligned with those. Call that "data governance".
US links:
- http://csrc.nist.gov/publications/nistpubs/800-123/SP800-123.pdf
- CDC - Cancer - NPCR - Frequently Asked Questions about Data Security
- http://www.r-project.org/doc/R-FDA.pdf (r-bloggers.org)
SAS dedicated blogs & proceedings:
- How to tune storage arrays and clustered file systems for use with SAS - SAS Users (blogs SAS M.Crevar)
- http://support.sas.com/resources/papers/proceedings14/SAS305-2014.pdf high availablility 9.4
More generic links:
- https://www.docker.com/whatisdocker/ (thanks Anreas Menrath)
Contents subjects for numbering
- 1/ Common guidelines information/cyber technology
This attitude to do that and reviewing reading those guidelines, is mostly missing.
- 2/ SAS improvements by releases
SAS development is hearing some technical signals to do and they are adding things, but IMO see 1/
+3/ SAS Admin improvements on business spec's
There are a lot of those goals you can achieve when doing a design a go for small modifications of the out of the box "setup" typing.
+4/ cookbooks templates
A holistic view on the implementation in a business/operational is very good possible. Needed is some additional thinking and adjustments.
With the latest versions (7 nov 2014 last updated):
- 1/ Common guidelines information/cyber technology
- 1.1 The guidelines of nist, cdc, fda are given a clear direction on the OS with tool integration.
These topics/subject are failing or missing with a sas deployment. (please prove me wrong)
- 1.2 The architecture - installation of SAS BI/DI environment should start at the expected hardware load & performance see Crevar.
As being locked in by a virtualization dogma that each machine is having a low load, the start is often at that idea with a very limited machine.
- 1.3 What is a SAS application? This is not well specified it can be:
+ the SAS installation/configuration as done by the SDW and others.
+ the code build by sas-developers analyzing business data
This confusing is causing a lot of trouble a many managers are reacting on the word application with an Pavlov idea who is responsible for doing things. Sometimes assuming SAS is becoming responsible for their business data.
The docker (what is docker) figures are nice to be used. For isolated java build (3gl) applications it can be a good approach. As the position it seems to be the installation/configuration.
The SAS installation/configuration is different. The metadata server is a central point. By that is cooperates with the object spawner to serve "applications" SAS(R) 9.2 Intelligence Platform: Application Server Administration Guide
Place the metadata /objectspawner (compute) grid service / midtier at the position of docker in figure (replacing that) and you will see the appserver implementing all those additional applicatons.
In the security admin guide there is only a caution note SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition on power users. (Doing analytics is power)
How to setup metadata folders? There are two nice variations given. SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition Normally both of them are needed (combination) as they both are practized in organizations
- 2/ SAS improvements by releases
+ 2.1 dual users for local Restricted administrators. SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition
This is common practice with a RDBMS (SYSDBA LocalDBA). It is mentioned in those ISO 27002 is something to do.
The acceptance of going for this has a too low and it is not sufficiently promoted to do this.
+ 2.2 The clustering of metadata-servers SAS(R) 9.4 Intelligence Platform: System Administration Guide, Third Edition
The same applies to webservers (midtier) although this part is not clear for me
+ 2.3 Monitoring is getting a place in the SAS ecosystem
As it should be segregated duties / privileges there is still a lot to do on that before it gets compliant to that ISO goals.
+3/ SAS Admin improvements on business spec's
+ 3.1 You can segregate between the installation (install key) and configuration with all dedicated service accounts SAS(R) 9.4 Intelligence Platform: Installation and Configuration Guide
This is not documented by but easy to do when understanding it all.
- 3.1.1 The default out of the box of just 2 keys is bad. When going for those ISO guidelines will result in more keys with several roles
The problem can be IT departments having problems with SAS and claiming it should be as less keys as possible. (Also ignoring business interests)
- 3.1.2 There is often a problem with the SDW approach.
For MS environments MSI-packaging is needed. For Linux/Unix rpm usage is wanted.
Follow the link for Unix folder structure (start) and you see also there a problem as it contradicts with SAS defaults. It can be adjusted with symbolic links.
- 3.1.3 LDAP host authentication authorization is mostly not well understood on the impact.
The sasauth/saselsrv construction is replacing the same kind of ssh/sudo functionality but not according those with their accepted behavior.
For example an expired (need to change password) is not recognized.
+ 3.2 You can segregate in the configuration at ports and Lev- indications. SAS(R) 9.4 Intelligence Platform: Installation and Configuration Guide
It makes it possible to do DTAP for the infrastructure (multiple versions) and business (release and version management)
+4/ cookbooks templates
+ 4.1 You can build a fully supported business DTAP structure conforming the requirements off all segregations.
Everything to do that is often seen as very complicated. A documented accepted template could be very helpful (missing)
Needed System keys:
- installation key (sasinst) usable for sas and lsf and others
- configuration key (sasconf) usable for sas and lsf and others
- metdataserver (sasmeta) isolated key for this service.
- objectspawner (sasspw) isolated key for this service. Within Unix acting as the template for all forked processed (ulimits)
- sasshrP sasshrA sasshrT sasshrD sasshrB (Lev1,Lev2,Lev3,Lev4,Lev5) (other 5 for an other SAS version) where SAS infra services are needing OS access to business data. (sensitive)
- ...
Adviced system groups:
- sas (adding users to this group will allow sas -infra- usage, still needing that user login)
- lsf (adding users to this group will allow lsf -infra- usage, still needing that user login)
+ 4.2 Using multiple appserver supporting a business with many departments is very well possible (Orion star).
Documented accepted templates could be very helpful (missing) . The connection to a RBAC process will be important with that.
The pitfall: build many local installations in not by ICT supported approaches.
+ 4.3 While building a DWH shared-data the security segregations are not mentioned, but they are important for business interests and requirements.
The pitfall with this is getting all data unwanted unmonitored open.
This is what often is said of SAS, you can access anything and nobody is in control of that. By this it gets on a list of tools to be removed from the organization.
Good and elaborate initial guideline for me, Jaap. You have my appreciation for it.
Many things to think about And also some others that I already realized.
All those remarks look like a good objective for the future and also a lot of work for SAS developers (and rest of departments). I also think there are some current good improvements that creates a good path (the new env manager, the new backup tool) that makes me wonder what will come next.
The complexity of all those changes also brings to my mind the idea that, maybe and only maybe, that objective is already there, but it takes time to implement everything, prioritize and keep selling by versions.
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
SAS technical trainer Erin Winters shows you how to explore assets, create new data discovery agents, schedule data discovery agents, and much more.
Find more tutorials on the SAS Users YouTube channel.