http://sapsecurity.

info/category/sap-security-interview-questions/

http://www.saptechies.com/tutorials/basis/security/

Q. SAP Security T-codes Frequently used security T-codes SU01 - Create/ Change User SU01 Create/ Change User PFCG - Maintain Roles SU10 - Mass Changes SU01D - Display User SUIM - Reports ST01 - Trace SU53 - Authorization analysis Q How to create users? Execute transaction SU01 and fill in all the field. When creating a new user, you must enter an initial password for that user on the Logon data tab. All other data is optional. Q What is the difference between USOBX_C and USOBT_C? The table USOBX_C defines which authorization checks are to be performed within a transaction and which not (despite authority- check command programmed ). This table also determines which authorization checks are maintained in the Profile Generator. The table USOBT_C defines for each transaction and for each authorization object which default values an authorization created from the authorization object should have in the Profile Generator. Q What authorization are required to create and maintain user master records? The following authorization objects are required to create and maintain user master records: S_USER_GRP: User Master Maintenance: Assign user groups S_USER_PRO: User Master Maintenance: Assign authorization profile S_USER_AUT: User Master Maintenance: Create and maintain authorizations Q List R/3 User Types Dialog users are used for individual user. Check for expired/initial passwords. Possible to change your own password. Check for multiple dialog logon A Service user - Only user administrators can change the password. No check for expired/initial passwords. Multiple logon permitted System users are not capable of interaction and are used to perform certain system activities, such as background processing, ALE, Workflow, and so on. A Reference user is, like a System user, a general, non-personally related, user. Additional authorizations can be assigned within the system using a reference user. A reference user for additional rights can be assigned for every user in the Roles tab. Q What is a derived role? Derived roles refer to roles that already exist. The derived roles inherit the menu structure and the functions included (transactions, reports, Web links, and so on) from the role referenced. A role can only inherit menus and functions if no transaction codes have been assigned to it before. The higher-level role passes on its authorizations to the derived role as default values which can be changed afterwards. Organizational level definitions are not passed on. They must be created anew in the inheriting role. User assignments are not passed on either. Derived roles are an elegant way of maintaining roles that do not differ in their functionality (identical menus and identical transactions) but have different characteristics with regard to the organizational level. Follow this link for more info Q What is a composite role? A composite role is a container which can collect several different roles. For reasons of clarity, it does not make sense and is therefore not allowed to add composite roles to composite roles. Composite roles are also called roles. Composite roles do not contain authorization data. If you want to change the authorizations (that are represented by a composite role), you must maintain the data for each role of the composite role. Creating composite roles makes sense if some of your employees need authorizations from several roles. Instead of adding each user separately to each role required, you can set up a composite role and assign the users to that group. The users assigned to a composite role are automatically assigned to the corresponding (elementary) roles during comparison. Q What does user compare do? If you are also using the role to generate authorization profiles, then you should note that the generated profile is not entered in the user master record until the user master records have been compared. You can automate this by scheduling report FCG_TIME_DEPENDENCY on a daily.

Governance, Risk, and Compliance, almost always referred to as GRC, is the latest addition to the parade of three-letter acronyms that are used to describe the processes and software that run the business world. The goal of GRC is to help a company efficiently put policies and controls in place to address all its compliance obligations while at the same time gathering information that helps proactively run the business. Done properly, GRC creates a central nervous system that helps you manage your business more effectively. You also derive a competitive advantage from understanding risks and choosing opportunities wisely. In other words, GRC helps you make sure that you do things the right way: It keeps track of what you are doing and raises an alert when things start to go off track or when risks appear. GRC is not just about complying with requirements for one quarter or one year. Rather, those who are serious about GRC, meaning just about everyone these days, seek to create a system and culture so that compliance with external regulations, enforcement of internal policies, and risk management are automated as much as possible and can evolve in an orderly fashion as business and compliance needs change. Thats why some would say that the C in GRC should stand for controls: controls that help make the process of compliance orderly and make process monitoring and improvement easier. Some parts of the domain of GRC measures to prevent financial fraud, for example are as old as business itself. Making sure that money isnt leaking out of a company and ensuring that financial reports are accurate have always been key goals in most businessesonly recently have they attained new urgency. Other parts of GRC related to trade compliance, risk management, and environmental, health, and safety regulations are somewhat newer activities that have become more important because of globalization, security concerns, and increased need to find and mitigate risks. For example, to ship goods overseas, you must know that the recipient is not on a list of prohibited companies. These lists change daily. Growing concern about global warming and other pressures to reduce environmental impact and use energy efficiently have increased regulations that demand reporting, tracking, and other forms of sociopolitical compliance. Companies are also interested in sustainability reporting, measuring areas such as diversity in the workplace, the number of employees who volunteer, and environmental efforts, so that companies can provide data about corporate social responsibility. Financial markets punish companies that report unexpected bad news due to poor risk management. One simple goal of GRC is to keep the CFO out of jail, but that description is too narrow to capture all of the activity that falls under the umbrella of GRC. (Its also an exaggeration; the truth is that simple noncompliance is more likely to result in big fines rather than a long trip to the big house. But, that said, most executives prefer to leave no stone unturned rather than risk breaking rocks in the hot sun.) Most companies now face demands from regulators, shareholders, and other stakeholders. Financial regulations like Sarbanes-Oxley (SOX) in the United States and similar laws around the world mean that senior executives could face criminal penalties if financial reports have material errors.

All of this means a lot more testing and checking, which is costly without some form of automation.

GETTING STARTED WITH SAP GOVERNANCE, RISK, AND COMPLIANCE SOLUTIONS (GRC)
SAP BusinessObjects governance, risk, and compliance (GRC) solutions provide organizations with a preventative, real-time approach to GRC across heterogeneous environments, enabling complete insight into risk and compliance initiatives, greater efficiency, and a faster response to changing business conditions. The GRC area on the BPX Community aims at being a forum for business process experts who are using or intending to use SAP GRC solutions. It also introduces the best practices and methodology behind these solutions and demonstrates how they're being used in a variety of industries and business solution areas. SAP.com has a collection of customer successes, brochures, and whitepapers, as well as news and events. The SAP BusinessObjects GRC solutions roadmap comprises several applications, including SAP BusinessObjects Access Control, which enables all corporate compliance stakeholders to confidently control access and prevent fraud throughout the enterprise, and SAP GRC Process Control 3.0, which allows organizations to drive confidence through continuous control monitoring. The following image demonstrates where GRC solutions fit - the various industries and solution areas where they are applicable and currently being used:

SAP Security and Authorization Concepts

R/3 audit review questions. Here is a list of items most commonly reviewed by internal/external auditors when reviewing your R/3 system. It is always a good idea to review this list a couple times a year and to take the appropriate steps to tighten your security. Review the following :* System security file parameters (TU02) (e.g. password length/format, forced password sessions, user failures to end session etc.) have been set to ensure confidentiality and integrity of password.

Security-Parameter-Settings-Documentation * Setup and modification of user master records follows a specific procedure and is properly approved by management. * Setup and modification of authorizations and profiles follows a specific procedure and is performed by someone independent of the person responsible for user master record maintenance. * An appropriate naming convention for profiles, authorizations and authorization objects has been developed to help security maintenance and to comply with required SAP R/3 naming conventions. * A user master record is created for each user defining a user ID and password. Each user is assigned to a user group, in the user master record, commensurate with their job responsibilities. * Check objects (SU24) have been assigned to key transactions) to restrict access to those transaction. * Authorization objects and authorizations have been assigned to users based on their job responsibilities. * Authorization objects and authorizations have been assigned to users ensuring segregation of duties. * Users can maintain only system tables commensurate with their job responsibilities. * Validity periods are set for user master records assigned to temporary staff. * All in-house developed programs contain authority check statements to ensure that access to the programs are properly secure. Select a sample of :* Changes to user master records, profiles and authorizations and ensure the changes were properly approved. (The changes can be viewed with transaction (SECR). * Ensure that security administration is properly segregated. At a minimum there should be separate administrators responsible for: - User master maintenance. (This process can be further segregated by user group.)

- User profile development and profile activation. (These processes can be further segregated.) * Verify that a naming convention has been developed for profiles, authorizations and inhouse developed authorization objects to ensure: - They can be easily managed. - They will not be overwritten by a subsequent release upgrade (for Release 2.2 should begin with Y_ or Z_ and for Release 3.0 by Z_ only.) * Assess through audit information system (SECR) or through a review of table USR02, whether user master records have been properly established and in particular: - The SAP_ALL profile is not assigned to any user master records. - The SAP_NEW profile is not signed to any user master records. Verify that procedures exist for assigning new authorization objects from this profile to users following installation of new SAP releases. * Assess and review of the use of the authorization object S_TABU_DIS and review of table authorization classes (TDDAT) whether :- All system tables are assigned an appropriate authorization class. - Users are assigned system table maintenance access (Through S_TABU_DIS) based on authorization classes commensurate with their job responsibilities. * Assess and review of the use of the authorization objects S_Program and S_Editor and the review of program classes (TRDIR) whether: - All programs are assigned the appropriate program class. - Users are assigned program classes commensurate with their job responsibilities. * Ensure through a review of a sample of :- In-house developed programs that the program, code either:

- Contains an Authority-Check statement referring to an appropriate authorization object and valid set of values; or - Contains a program Include statement, where the referred program contains an Authority-Check statement referring to an appropriate authorization object and valid set of values. I think an auditor would want to know what methods you are using to approve who gets what profile and what method you are using to document it so that if you review your documentation you could compare it with what authorization the user currently has and determine if the user has more authorizations (roles) than he has been approved for by the approval system in place.