On The Spot: Mario Linkies on SAP security

This month Mario Linkies answers all of your SAP security questions.

On The Spot features a new guest expert on a hot SAP topic every month. This is your chance to get your questions answered by some of the best and brightest in the business, but hurry up: Each guest expert makes one appearance only! This month's topic is SAP security with Mario Linkies, Chief Executive Officer of SECUDE Global Consulting. Next month's topic SAP Basis/administration with Joey Hirao, Senior Basis consultant for Groupbasis (www.groupbasis.com).

Submit your SAP Basis/administration questions for Joey Hirao below.

About mario Linkies:
Mario Linkies is the Chief Executive Officer of SECUDE Global Consulting since February 2007. Before taking on this role, he was a Platinum Management Consultant with a focus on IT Security topics, especially in the field of strategic security and risk management consulting, authorization concepts, change management, and regulatory and legal compliance. With more than 15 years of business and SAP experience, he was leading the security practice at SAP SI AG/SAP Consulting Germany and was director of the Global Focus Group Risk Management & IT Security. Prior to joining SAP AG, he held a Business Analyst position at Shell Chemicals Europe in Germany and both a senior consultant and senior manager position at Deloitte in Canada.



 1. Common SAP security snags
 2. Exceptions for 90 day password changes
 3. From Basis to security consultant
 4. Field level security to a t-code so the name and address are protected
 5. Limiting transactions for individual users
 6. Preventing the login attempt counter auto-reset
 7. The future of biometrics and SAP
 8. An at-a-glance list of users who have been given authorizations
 9. Hardening security at the OS level
 10. Can we prevent social hacking?



1. Common SAP security snags

We're upgrading from R/3 4.6C to ECC 6.0 and I've been researching SAP security methodologies for NetWeaver. Do you have any words of advice to make sure we don't miss any common security "gotchas" that may leave us vulnerable after the upgrade?

-- Li Peng,
    Sunnyvale, Calif.


An upgrade project is never just a technical upgrade. It always contains minor or major aspects of a business and SAP functionality challenge. Please review your SAP NetWeaver architecture and the security impact on a new security architecture in a first strategic step. Upgrade projects also provide an opportunity for reassessing the current authorization structure. Consider new SAP standard technology like SAP Governance, Risk & Compliance (GRC) and SAP NetWeaver Identity Manager as possible solutions for control and security. Build a solid project plan and leave enough time for testing. The increased number of transaction codes, new functionality, new authorization concepts and new authorization objects have to be part of your specific requirements analysis. Existing tools like SAP Profile Generator (TCD PFCG) act differently. Do not underestimate the effort to do things properly. Review the security notes and the latest security leading practices. Build and follow a comprehensive upgrade checklist. Professional advice might help you in strategy and specific areas of the project.

On the technical side, look at saving old instances and note down system parameter values before the upgrade. Look at table changes from 4.7 to ECC 6.0; considerable effort could be required to update custom programs (Z* and Y* programs that use these tables). Use the technical step list for upgrades using TCD SU25 (upgrade of the roles and default tables via TCD SU25, steps 2A-2D). In transaction SU25, when running step 2C (Roles to be checked), the roles affected by the upgrade are highlighted, based of new transaction codes, authorization objects etc. However, the changes performed in order to adapt them are not transported in step 3 (Transport the Customer Tables). Do not go live without proper testing. Many requirements and upgrade procedures are listed on the SAP SERVICE MARKETPLACE and there are various OSS notes on upgrade issues (https://websmp207.sap-ag.de/erp-inst).

Note: BW (BI / business intelligence in ECC 6.0) is integrated with ERP. So probably you may have BW and ERP in one system if using ECC 6.0.

FYI: End of support maintenance for ECC 6.0 is 2013 (standard) and 2016 (extended), while 4.6C is 2006 and 2009, 4.7 is 2009 and 2012.

-- Mario Linkies


2. Exceptions for 90 day password changes

We are automatically forcing our users to change their R/3 4.7 Enterprise BW 3.5 passwords every 90 days, but we need some exceptions from that rule. How can that be done?

-- Stein Bakke,
    Bergen, Norway


I assume that you have made a sound risk assement to verify the validity of your requirement. On the technical side, I presume that you use system parameter 'login/password_expiration_time' to enforce a password change every 90 days. Report RSPARAM or TCD RZ11 can be used to display all profiles in the system with their values. I guess the user type you are discussing is dialog user. There are several options. I just mention two:
  1. As 'login/password_expiration_time' only affects dialog users (user type "A"), you could try to change the user type for these users to service (user type "S"). Be aware that this has some other effects like that service users can login multiple times.
  2. A better option would be to analyze your overall requirements and then implement a Single Sign On (SSO) solution based on those requirements.

-- Mario Linkies


3. From Basis to security consultant

I've spent the past two years in Basis support, and I'm tempted to try becoming a security consultant. I'm certified but I don't have a lot of real-life SAP security experience. How can I get my foot in the door?

-- Nayadar Gupte,
    Bangalore, India


The approach to security, especially to SAP security, is to consider all aspects of the complete security requirements and solutions, like risk and control management, identity and access management, data protection and privacy, corporate governance, legal and regulatory compliance, and many others. You need to decide for yourself what area(s) interest you most. Additionally, you should read the book SAP Security and Authorizations (Linkies/Off, SAP Press) to get an overview and introduction to Enterprise Risk Management.

A good way to start getting real-time experience is in project and production support to learn design and methodology on how to implement and secure SAP systems. It is important to get business knowledge while upgrading your technical skills. Security as part of the solution side of risk management is an increasingly important but wide area, and focus is one of the essential elements to be successful.

Also, go to different Security forums and post your questions and read answers to various questions, for example http://www.sdn.sap.com and http://www.sapfans.com. On the SDN website you can also learn various aspects on SAP Security using the e-learning link on the menu bar.

The next logical step would be the SAP certification to show your expertise. Go for ADM 940, ADM 950, ADM 960 and HR 40- security related courses. You can find more details about courses on the SAP website.

-- Mario Linkies


4. Field level security to a t-code so the name and address are protected

How do I apply field level security to t-code FBL1N so the name and address are protected?

-- Robert Weber,
    Austin, Texas


For transaction FBL1N (Vendor Line Item Display) I don't think that it can be done using authorization object and field level security as vendor name and address are stored in table LFA1 (Vendor Master), and you can not restrict table data using an authorization field. However, you can create a custom program (based on FBL1N functionality) and then attach it to a custom transaction (for an example ZFBL1N) and on the ALV output requirement, uncheck name and address table fields from table LFA1 in the custom program. Give access of this custom transaction to end users using a role.

-- Mario Linkies


5. Limiting transactions for individual users

I want to grant all transaction rights to one user except all Basis transactions. Specifically, I want remove the authorization of transactions like stms, scc4, su01, pfcg and so on. Is there a way to do this?

-- Ahmed Al-Famiir,
    Los Angeles, Calif.


It is not advisable to do that. You need to follow a better approach than to allocate functionality (more than 50,000 TCD) in one role to do so. A better approach would be to allocate authorizations based on functionality, risks, organizational and legal requirements.

-- Mario Linkies


6. Preventing the login attempt counter auto-reset

Is there a way to prevent the login attempt counter reset that happens when the user closes the SAPGUI? For example, the system has been set to lock the user after three failed login attempts. But when the user closes the SAPGUI after two failed attempts, he can try to login to system again three more times without being locked out.

-- Joseph Wills,
    Montreal, Canada


This can be done using profile parameters 'login/fails_to_session_end' and 'login/fails_to_user_lock'. Parameter 'login/fails_to_session_end' (Number of invalid login attempts until session end) has default value '3' and after 3 failed attempts, a session would be closed and the user would not be locked in SAP until he/she tries the number of times mentioned in parameter 'login/fails_to_user_lock' (Number of invalid login attempts until user lock). The difference between these two parameters is that 'login/fails_to_session_end' closes the session and 'login/fails_to_user_lock' locks the user id in SAP.

For example: If login/fails_to_session_end has the value 3 and login/fails_to_user_lock has the value 6 in SAP, a user's session would be closed after 3 trials and then the user has to log on again. But this time, the counter won't start from 0, but from 3 and after 3 more attempts in a second trial (which makes a total of 6 trials - 3 from previous session and 3 from new session), the user id would be locked. Note: It does not reset the counter, even if the user closes his session after two failed attempts). After that, even if the user enters the correct password the user would get an error message saying 'Password logon no longer possible - too many failed attempts' and the id would be locked in SAP. If you would like to give 3 more attempts in a second try, set the values for parameter 'login/fails_to_session_end' to 3 and 'login/fails_to_user_lock' to 6.

-- Mario Linkies


7. The future of biometrics and SAP

What's your take on the future of biometrics in an SAP environment?

-- Ellen O'Hara,
    London, UK


In the IT world, biometrics have been broadened to include the study of methods for uniquely recognizing humans based upon one or more physical or behavioral traits. Biometric characteristics can be divided into two types: Physiological (finger prints, face recognition, hand geometry, iris recognition, DNA) and behavioral (signature, keystroke dynamics and voice).

Smart card, password, unique key log, token/Keys, biometrics - all can record when each of those devices was used, but biometrics is the only true protection since the user will be uniquely identified. Besides biometrics, all other tools/cards can be stolen, lost or passed to other employees, and so they offer limited protection. That is why, in a legal environment, it is hard to prove who accessed the system and harmed it. For example, fingerprint can put a unique identifier into the system, and it records who has touched an SAP system and specific accessed data information. Typical risk factors to any IT system include but are not limited to theft, destruction, interception and alteration of financial data and so for companies, greater control over data input, processing and output is really required. This is mandatory, especially in SAP as it holds critical enterprise data about a company's production planning details, customers, vendors, finances, marketing, employees etc. In Human Capital Management, SAP also stores critical information such as credit card or bank account number, health insurance data, salaries and other sensitive information. Any unauthorized access or changes to those data could cost a lot to any organization. SAP systems should be protected against any unauthorized access and the use of biometrics can improve identity and access management solutions. This way, companies comply with mandatory regulations and are better protected from damages.

Research firm Frost & Sullivan predicts fingerprint-scanning technology revenues will grow to $1.5 billion by 2009. Above all, due to mandatory requirements imposed by various laws and acts: Sarbanes-Oxley Act (Section 404. Management Assessment of Internal Controls), California Privacy Act, and HIPAA, the future of biometrics in SAP as well as in IT is really bright as all these acts imposed mandatory requirements on more sophisticated identity management solutions.

-- Mario Linkies


8. An at-a-glance list of users who have been given authorizations

I would like an at-a-glance list of users who have been given authorizations for a particular table AND when they last accessed it. Is there something already in place for this functionality, or would I have to create it? If the latter, how?

-- Rod Marquez,
    Orlando, Florida


This is a very complicated topic since everything depends on tables, and there are many ways to access these tables. For example, you can have direct access via TCD SE16, you can have access via an allocated TCD, or access the tables through the database, RFCs and many more. For that reason, there are several ways to limit the access that users should have through transactions like TCD SM31 or transaction variants.

An appropriate approach would be to introduce a proper table authorization concept that includes components like allocating access rights via TCD and to limit the direct access to tables. Of course, you can always turn on the security audit log to try log sensitive tables or using TCD SE13. More information like the system and release you are working in would be required to provide you with additional solutions.

To protect table access find out if the table has an authorization group assigned to it. Use table TDDAT (from transaction SE16) to find out the authorization group allocation. While accessing tables, the S_TABU_DIS authorization object is checked and if the table has been allocated to an authorization group the value should be in the user master record for authorization group in S_TABU_DIS. If the table is not assigned to any authorization group a blank authorization group value '&NC&' is required for the authorization object S_TABU_DIS for the user master record. A new authorization group should then be created using table TBRG.

Based on authorization object S_TABU_DIS and the values for selected table authorization groups use TCD SUIM to find out a list of users who have access to tables. Use TCD ST03N (Workload and Performance Statistics) to find out the table access by users on a particular day. In TCD ST03N, select one of the application server, and from 'Analysis Views' select 'User Profile' within 'User and Settlement Statistics'. Click on any user id and 'Report/Transaction' column would give you the required information about accessed tables, reports and transactions. One more thing is to find out through the table change log. Table change logging is controlled by the 'rec/client' parameter in the SAP system profile. Report RSPARAM or transaction RZ11 can be used to display all profiles in the system with their values. If table logging is enabled there are different ways to get the table change logs using TCD SCU3 or TCD OY18.

You should also consider to use rec/client to log changes on specific tables.

-- Mario Linkies


9. Hardening security at the OS level

A security consultant recommended we harden security at the OS level, but never specified exactly how to go about it. How can we accomplish this? Are there any guides that address this?

-- Stefan M.,
    Stuttgart, Germany


Follow your hardware vendor hardening guidelines for your OS together with your SAP guidelines.

Some examples include:

Operating system access should be administered via the operating system itself and not from within SAP. Security at Operating System level (OS) means restrict access to security services which protects SAP files and directories, OS commands and programs. To do so:

- Necessary permissions (create/read/write/delete) need to be restricted on OS files and directories
- Password and user access policy need to be defined and enforced
- OS access and directory changes need to be logged and continuously monitored
- Create/edit/delete unnecessary OS level users or services
- Proper set up of ACL (Access Control List) for critical files and directories

All above tasks should be done by SAP Basis/OS manager.

Also restrict following authorization objects in roles to protect external commands from being executed from SAP:

- Restrict the S_DATASET authorization object. This object allows you to assign authorizations for particular files from particular programs. You can also assign the authorization to use operating system commands as a file filter
- Restrict S_LOG_COM authorization object as this object allows you to execute Logical Operating System Commands
- Restrict S_RZL_ADM authorization object as it authorizes to execute Logical Operating System Commands

Transaction SM69 allows access to perform a pre-defined set of operating system commands as well as creating and executing new commands. Access to all above should be restricted from all users in the production environment.

Also, SAP PRESS Book 'SAP Security and Authorizations' (Linkies/Off) provides details about Security at OS level:

SAP Web Application Server ...Restricting Operating System Access ... Page 167
SAP Web Application Server ...Introducing Hardening Measures on the Operating System Level ... Page 177
SAP Exchange Infrastructure ... Securing the File Adapter at Operating-System Level ... Page 404
SAP Partner Connectivity Kit ... Securing the File Adapter at Operating-System Level ... Page 411

-- Mario Linkies


10. Can we prevent social hacking?

Social hacking (tricking employees to divulge information) remains something of an elephant in the room whenever you talk about security. Beyond emphasizing the need to stay vigilant and send periodic email reminders, what can we do to make sure users don't say too much when, say someone claims to call from the IT department and start asking questions?

-- Jennifer Fisher,
    Boston, Mass.


You should create a risk awareness culture in your organization.

According to Wikipedia.org: 'Social Hacking (Engineering) is a collection of techniques used to manipulate people into performing actions or divulging confidential information. While similar to a confidence trick or simple fraud, the term typically applies to trickery for information gathering or computer system.' There's always the technical way to break into a network. But using Social Engineering, it's easier to go through the people in the Company. Employees can easily be fooled and so they end up giving up their own security and so, making a door wide open for Company's data.

Technically, a company can have all types of secure products: encrypted communication lines, firewalls, SSL in place, locks, secure data center, secure entrance building with 24 hrs monitoring, various security tools to protect hardware and software but using Social Engineering, data can still be hacked/revealed and none of these tools/techniques protect any Company. It's really wise to design some simple, but easy to follow, security protocols than let employees to read security manual!

An company should design procedures on how to access secure data over company's Intranet/Internet, how it can be restricted, classify different types of data and make policies on when it's good to disclose to someone else, make easy-to-follow policies on sharing data (id/pwd/other sensitive information) and when it's good to trash/shred companies documents, media (CD, DVD, VHS tapes etc) and how. Company should also focus on to prevent Physical attacks and monitor communication line and enforce policy not to give password to anyone over the Phone.

Having said so, a company can have security policies and procedures in place, but the truth is that nothing is enough until education of end users on risks and threats reaches a certain level. A separate training and security awareness program should be outlined and must be enforced.

Sometimes, it's always good to gain access of people using Social Engineering and present them with real time data before making them to follow on security protocols. This way, they would be aware about Social Engineering and become proactive against personal/company data.

There are few good books on this subject by reformed computer criminal and security consultant Kevin Mitnick (www.mitnicksecurity.com): 'The Art of Deception' and 'The Art of Intrusion' which explains this topic in more details and also presents guide-lines on how to create an awareness program for all employees.

-- Mario Linkies

  for next month's topic:

SAP Basis/administration with Joey Hirao, Senior Basis consultant for Groupbasis (www.groupbasis.com).

(100 words max for questions! -- Be sure to include all information requested!)

Dig Deeper on SAP security