SAP Security Administration Policies & Procedures

TOC \T "PAPHEAD1,1,PAPHEAD2,2,PAPHEAD3,3" 1. OBJECTIVE PAGEREF _TOC79230690 \H 7 2. HOUGHTON MIFFLIN SAP SECURITY STRATEGY PAGEREF _TOC79230691 \H 7 3. SCOPE PAGEREF _TOC79230692 \H 7 4. SECURITY ORGANIZATION PAGEREF _TOC79230693 \H 8 4.1 SECURITY ADMINISTRATION PAGEREF _TOC79230694 \H 8 4.2 SECURITY ADMINISTRATOR SEGREGATION OF DUTIES PAGEREF _TOC79230695 \H 8 User Administrator PAGEREF _Toc79230696 \h 8 Security Development Administrator PAGEREF _Toc79230697 \h 8 Security Team Lead Administrator PAGEREF _Toc79230698 \h 9 Reset Password Administrator PAGEREF _Toc79230699 \h 9 5. SECURING SAP CLIENTS AND SYSTEMS PAGEREF _TOC79230700 \H 9 5.1 SYSTEM AND CLIENT OWNERSHIP PAGEREF _TOC79230701 \H 9 Systems PAGEREF _Toc79230702 \h 9 Instances and Clients PAGEREF _Toc79230703 \h 10 5.2 TECHNICAL ROLE DEFINITIONS

PAGEREF _TOC79230704 \H 10 Security Development Administrator PAGEREF _Toc79230705 \h 10 Basis Administrator PAGEREF _Toc79230706 \h 10 ABAP/4 Developer PAGEREF _Toc79230707 \h 11 DataBase Administrator (DBA) PAGEREF _Toc79230708 \h 11 Operators PAGEREF _Toc79230709 \h 11 Network Administrator PAGEREF _Toc79230710 \h 11 UNIX Administrator PAGEREF _Toc79230711 \h 11 ALE Administrator PAGEREF _Toc79230712 \h 11 Spool Administrator PAGEREF _Toc79230713 \h 12 Help Desk PAGEREF _Toc79230714 \h 12 Workflow Administrator PAGEREF _Toc79230715 \h 12 Configurator PAGEREF _Toc79230716 \h 12 5.2.2 Technical Roles Defined for Production PAGEREF _Toc79230717 \h 12 5.3 SAP LANDSCAPE PAGEREF _TOC79230718 \H 12

Training (T01) PAGEREF _Toc79230719 \h 15 5.3.4 BW Overview PAGEREF _Toc79230720 \h 15 Sandbox (SW1) PAGEREF _Toc79230721 \h 16 Training (TW1) PAGEREF _Toc79230722 \h 16 Production (PW1) PAGEREF _Toc79230723 \h 16 6. SAP SYSTEM SUPPLIED SUPER USER(S) PAGEREF _TOC79230724 \H 16 SAP* PAGEREF _TOC79230725 \H 17 6.2 DDIC PAGEREF _TOC79230726 \H 17 7. NAMING CONVENTIONS PAGEREF _TOC79230727 \H 18 Profiles PAGEREF _Toc79230728 \h 19 Authorizations PAGEREF _Toc79230729 \h 19 8. USER GROUP SECURITY PAGEREF _TOC79230730 \H 20 Sandbox/Development System(s) PAGEREF _Toc79230731 \h 20 Integration/QA System PAGEREF _Toc79230732 \h 20 Training System

PAGEREF _Toc79230733 \h 20 Production System PAGEREF _Toc79230734 \h 20 9. HELP DESK PROCEDURES PAGEREF _TOC79230735 \H 21 9.1 HELP DESK RESPONSIBILITIES PAGEREF _TOC79230736 \H 21 9.2 RESETTING USER PASSWORDS PAGEREF _TOC79230737 \H 21 9.3 UNLOCKING USER IDS PAGEREF _TOC79230738 \H 21 9.4 RESOLVING ACCESS ISSUES/PROBLEMS (TROUBLESHOOTING) PAGEREF _TOC79230739 \H 21 10. SAP USER ACCESS PAGEREF _TOC79230740 \H 23

SAP USER ACCESS FORM PROCEDURES PAGEREF _TOC79230741 \H 23 11. USER MASTER RECORDS PAGEREF _TOC79230742 \H 24

CREATING A USER MASTER RECORD PAGEREF _TOC79230743 \H 24 Address Tab PAGEREF _Toc79230744 \h 25 Last Name PAGEREF _Toc79230745 \h 25 First Name PAGEREF _Toc79230746 \h 25 LogOn Data Tab

PAGEREF _Toc79230747 \h 25 Initial Password PAGEREF _Toc79230748 \h 25 User Group PAGEREF _Toc79230749 \h 25 Valid From/Valid Until PAGEREF _Toc79230750 \h 25 User Type PAGEREF _Toc79230751 \h 25 Default User Tab (Can be maintained by each user) PAGEREF _Toc79230752 \h 26 Output Device (Printers) PAGEREF _Toc79230753 \h 26 Print Controller Functions PAGEREF _Toc79230754 \h 26 Date Format PAGEREF _Toc79230755 \h 26 Decimal Notation PAGEREF _Toc79230756 \h 26 Personal Time Zone PAGEREF _Toc79230757 \h 26 Parameters Tab PAGEREF _Toc79230758 \h 26 USER PARAMETERS PAGEREF _TOC79230759 \H 26 Roles Tab PAGEREF _Toc79230760 \h 26 Roles PAGEREF _Toc79230761 \h 26

12.

PASSWORD ADMINISTRATION PAGEREF _TOC79230762 \H 26

12.1 ADMINISTERING USER PASSWORDS PAGEREF _TOC79230763 \H 27 12.2 DEFAULT PASSWORD REQUIREMENTS PAGEREF _TOC79230764 \H 27 12.3 RESETTING PASSWORDS PAGEREF _TOC79230765 \H 28 12.4 Password Expiration PAGEREF _Toc79230766 \h 28 12.5 Password Length PAGEREF _Toc79230767 \h 28 12.5 IMPERMISSIBLE PASSWORDS (SAP TABLE USR40) PAGEREF _TOC79230768 \H 29 13. SYSTEM PROFILE PARAMETERS PAGEREF _TOC79230769 \H 29 TO VIEW THE FOLLOWING PARAMETER SETTINGS GO TO SA38 - RSUSR003 PAGEREF _TOC79230770 \H 29 (THESE ARE CHANGED BY BASIS USING TCODE RZ11) PAGEREF _TOC79230771 \H 29 13.1 UNSUCCESSFUL LOGON ATTEMPTS - LOGIN/FAILS_TO_SESSION_END PAGEREF _TOC79230772 \H 31 13.2 AUTOMATICALLY LOCKING A USER - LOGIN/FAILS_TO_USER_LOCK PAGEREF _TOC79230773 \H 31 13.3 LOGGING OFF IDLE USERS - RDISP/GUI_AUTO_LOGOUT PAGEREF _TOC79230774 \H 31 14 USER ID LOCK/UNLOCK PAGEREF _TOC79230775 \H 33

14.1 LOCKING/UNLOCKING USER IDS PAGEREF _TOC79230776 \H 33 14.2 UNLOCKING USER IDS

PAGEREF _TOC79230777 \H 33 14.3 LOCKING USER IDS PAGEREF _TOC79230778 \H 33 14.4 Mass Locking and Unlocking PAGEREF _Toc79230779 \h 34 15 TRANSPORT SYSTEM (TMS) PROCEDURES FOR HOW TRANSPORTS WILL BE HANDLED GOING FORWARD NOT FINALIZED. PAGEREF _TOC79230780 \H 34 15.1 TRANSPORT PROCEDURE CORRECTIONS AND TRANSPORT SYSTEM PAGEREF _TOC79230781 \H 34 15.2 DOCUMENTATION SOURCES FOR TRANSPORTS PAGEREF _TOC79230782 \H 35 15.3 HOW TO CREATE A TRANSPORT PAGEREF _TOC79230783 \H 36 16. SECURITY CHANGE CONTROL PAGEREF _TOC79230784 \H 40

16.1 CREATING/MAINTAINING ACTIVITY GROUPS PAGEREF _TOC79230785 \H 41 16.2 MAINTAINING USER TO ACTIVITY GROUP RELATIONSHIPS PAGEREF _TOC79230786 \H 41 17. PROGRAM/REPORT SECURITY PAGEREF _TOC79230787 \H 41

17.1 ABAP/4 DEVELOPMENT/REPORT REQUEST PROCEDURE PAGEREF _TOC79230788 \H 42 17.2 RULES FOR CREATION OF NEW ABAP PROGRAM/REPORT PAGEREF _TOC79230789 \H 42 18. SECURITY FOR SAP TABLES PAGEREF _TOC79230790 \H 43

EXISTING SAP TABLES

PAGEREF _TOC79230791 \H 43 NEW SAP TABLES PAGEREF _TOC79230792 \H 43 PARAMETER TRANSACTIONS PAGEREF _TOC79230793 \H 44 19. 20. PRINTERS PAGEREF _TOC79230794 \H 44 INSTALLATION OF NEW RELEASES PAGEREF _TOC79230795 \H 44

20.1 UPGRADE/NEW RELEASE INSTALLATION PROCEDURE PAGEREF _TOC79230796 \H 44 SECURITY CONSIDERATIONS FOR NEW RELEASES PAGEREF _TOC79230797 \H 45 21 OBTAINING OSS LOGON, DEVELOPER KEY AND OBJECT KEY PAGEREF _TOC79230798 \H 46

21.1 OSS LOGON SETUP PROCEDURE PAGEREF _TOC79230799 \H 46 21.2 DEVELOPER KEY AND OBJECT KEY SETUP PROCEDURE PAGEREF _TOC79230800 \H 47 22. 23. 24. 25. 26. 27. CLIENT COPY PAGEREF _TOC79230801 \H 47 SYSTEM REFRESH PAGEREF _TOC79230802 \H 48 SAP PATCHES PAGEREF _TOC79230803 \H 48 SYSTEM DOWN TIME PAGEREF _TOC79230804 \H 49 BATCH JOB PROCESSING PAGEREF _TOC79230805 \H 50 SU24 TRANSACTION

PAGEREF _TOC79230806 \H 51 27.1 OVERVIEW OF SU24 PAGEREF _TOC79230807 \H 51 27.2 MAINTAINING SU24 PAGEREF _TOC79230808 \H 52 28. SECURITY MONITORING ACTIVITIES PAGEREF _TOC79230809 \H 52

STANDARD SECURITY MONITORING ACTIVITIES PAGEREF _TOC79230810 \H 53 29. STORAGE AND RETENTION OF HOUGHTON MIFFLIN SAP R/3 SECURITY ADMINISTRATION POLICIES AND PROCEDURES PAGEREF _TOC79230811 \H 59 29.1 PERIODIC REVIEW OF HOUGHTON MIFFLIN SAP R/3 SECURITY ADMINISTRATION POLICIES AND PROCEDURES PAGEREF _TOC79230812 \H 59 APPENDIX A IMPORTANT CONTACT INFORMATION PAGEREF _TOC79230813 \H 60 A.1 HOUGHTON MIFFLIN LEADERS PAGEREF _TOC79230814 \H 60 A.2 HOUGHTON MIFFLIN SECURITY TEAM PAGEREF _TOC79230815 \H 60 APPENDIX B SAP USER ACCESS FORMS PAGEREF _TOC79230816 \H 61 APPENDIX C SYSTEM REFRESH FORM PAGEREF _TOC79230817 \H 62 APPENDIX D CLIENT COPY REQUEST FORM PAGEREF _TOC79230818 \H 63

APPENDIX E TRANSPORT REQUEST FORM PAGEREF _TOC79230819 \H 64 APPENDIX F - GLOSSARY PAGEREF _TOC79230820 \H 65 APPENDIX G UNIX / ORACLE CONSIDERATIONS PAGEREF _TOC79230821 \H 67 RECOMMENDATIONS PAGEREF _TOC79230822 \H 67 POTENTIAL SECURITY RISKS IN UNIX PAGEREF _TOC79230823 \H 67 PROTECTED SAP DIRECTORY STRUCTURES UNDER UNIX PAGEREF _TOC79230824 \H 68 APPENDIX H ADDITIONAL SECURITY MONITORING REPORTS / PROGRAMS PAGEREF _TOC79230825 \H 69 SENSITIVE SECURITY MONITORING PROGRAMS PAGEREF _TOC79230826 \H 69

Objective
To ensure that SAP security provides an efficient and effective structure for ensuring the integrity, accuracy, and availability of the information within SAP.

Houghton Mifflin SAP Security Strategy

Houghton Mifflin SAP security will be implemented through the definition of security roles. Security roles will represent jobs/positions. The SAP Authorization Concept will be utilized to secure access to the process and technical functions: No default access will be given; users will have access only to the specific functions within the SAP application that they have a business or system reason to perform. Roles with authorizations performing specific business functions will be created to reflect a particular job function. Each job/position will represent a logical grouping of SAP transactions required for that job/position to carry out defined business activities and responsibilities. User access will be controlled through the assignment of roles to users. Further segregation in some instances have been done through derived roles. This is a variation of the role based on locations such as plants and sales offices. In some instances HR roles have been derived based on org key that reflects district locations. Profile Generator is used to create activity groups that are used as roles. Sensitive functions (tcodes) for each process and technical team have been defined, and access is controlled by the "owner" of the process or the technical team. Various security reporting and auditing tools will continually be refined and improved. The SAP Security Team will be responsible for developing application security, creating and processing access forms, and monitoring SAP application security. The users on all SAP clients will be monitored on a regular basis to ensure that all users are approved and that access is authorized. Only the SAP Security Team, including User Administrators, should have access to update another users master record.

Scope
This document contains SAP Security Development and Administration policies and procedures. As the Sunrise project is executed, this document will require review and

enhancement. The document includes the following topics: Objectives SAP Security Strategy Approval Process SAP Security Organization System and Client Security SAP Supplied Users Naming Conventions User Group Strategy Help Desk Procedures Requesting SAP access User Master Records Password Administration Logon Parameters User ID Lock/Unlock Transports Security Change Control ABAP/4 Programs ABAP Tables and Transactions Batch/Job Scheduling Output/Spool Security New Releases OSS Logon Developer and Object Key Client Copy & Client Refresh SAP Patches System Down Time OSS logon administration Unix Recommendations & Risks Security Monitoring SAP User Access Form Instructions

Security Organization
4.1 Security Administration
SAP security administration will be segregated into two functions: development and user administration. Development functions consist of developing and maintaining activity groups, establishing system parameters, monitoring clients and systems, and basis security. User administration functions include maintaining all users, assigning or changing user access, unlocking or locking users and resetting passwords. Development activities will be centrally handled. Additionally, user administration for Basis and Security administrators will be processed through the central SAP security administration function. Security development activities will be focused around the SAP implementation projects. In general, Security Administration and Development will be administered at the project level.

4.2 Security Administrator Segregation of Duties

In order to maximize system security, security administration will be broken up into four types of administrators: User Administrator, Security Development Administrator, Security Team Lead Administrator, and Reset Password

Administrator.

User Administrator
User administrators define and edit user master records. A user administrator can perform such tasks as creating user master records, editing the list of profiles in a user master record, and setting user parameters. A user administrator cannot maintain or activate profiles or authorizations. User Administrators will also be able to unlock or lock User IDs.

Security Development Administrator

Security Development Administrators define, edit and activate authorization profiles and authorizations (roles), create/change test users, and release Tasks ready to transport. These administrators can work only with the update versions of profiles and authorizations and cannot release Change Requests ready for transport.

Security Team Lead Administrator

The Security Team Lead Administrator will be able to do all tasks associated with a Security Development Administrator except in D01 client 100 (master configuration client); this client will be display only. Unlike Security Development Administrators, this administrator will be able to release Change Requests to be transported.

Reset Password Administrator

Reset Password Administrators will be able to reset passwords and lock or unlock users in both the development and the production environments. This does not include users that have been locked by the Systems Administrators only invalid login attempts. NOTE: When using Profile Generator in the creation or maintenance of authorizations, the generation will activate the changes automatically, but a transport to the production or target system is still required. The Security Team Lead Administrator will be responsible for releasing change request to be transported.

Securing SAP Clients and Systems

There are three systems with five instances used to support SAP. The three systems are R/3, BW and Solution Manager. Clients are defined within each instance and the number of clients defined to an instance varies. The client and instance structure requires security administration to not only consider the security requirements for the instance, but also include client specific security requirements. The requirements at the client level can vary within the same instance.

The primary concern for securing clients and instances is restricting ABAP/4, Basis, Configuration, Functional, Security and Table access based on the definition and use of each client and instance. This access will be administered through the definition of technical roles and production user roles. The design and administration of these roles will be controlled using the Profile Generator by the Security Development Administrators.

5.1 System and Client Ownership Systems

The owners approve all significant /major changes or specific access to a system. Major changes or access may include scheduling a job in a particular system, creation access for ABAP programs, client copies, system refreshes, access to client independent tables and sensitive data as defined by the Business Owner of each particular area.

Instances and Clients

The Instance or Client owner will have the final authorization or rejection capability for all access requests. Any questions or potential security risks regarding a request or modification of user access will be directed to the client owner. The Basis team will be responsible for administering and maintaining client ownership assignments and will coordinate with functional team leaders for all system changes.

5.2 Technical Role Definitions

The purpose of the technical roles is to provide the administrators and technical teams only with the access needed to complete their job responsibilities. This access is dependent on the instance and client.

Security Development Administrator

Security Development Administrators will have the ability to design and configure authorizations, profiles, and users within the SAP instances and clients. The security administrator will also have full access to client dependent and independent tables (enough access to allow the administrator to troubleshoot problems with users.) Listed below is a high level overview of Security Administrator responsibilities: Create or change SAP User IDs (User Master Records) for all users that have submitted approved SAP User Access Request forms.

Keep track of all SAP User ID creation and access. Create and maintain the SAP profiles and authorizations (all systems). Perform acceptance testing of new profiles and authorizations. (through Integration Testing) Present user management with a summary of user access for their direct reports. Proactively monitor and update all phases of the security strategy as needed. Research and create an SAP access strategy as well as Users/Profiles/ Authorizations for future project development. Create and update documentation concerning security. Train helpdesk. Analyze the effects of system upgrades on the access security strategy and implement changes. Create and maintain policies and procedures for firm wide security. Serve as an integration advisor for functional teams (all modules) Perform security monitoring and analysis according to security standard operating policies and procedures.

Basis Administrator
These users have the ability to support all Basis Administration. Additionally, Basis Administrators have access to ABAP/4 programming, database management system, operating system, tables and all Basis Administration related transactions. Basis roles are divided based on status of Junior and Senior Basis Administrators. Senior Basis users are allowed to make more system critical changes such as change system profiles, delete system locks, setting up RFCs, and delete updates The following is a list of Basis responsibilities: Approved Transports Patches Client Refresh SAP Archiving Database Administration Backup/Recovery Printer Administration SAP Upgrades Client Copy SAP System Monitoring Application Link Enabling UNIX Administration Configuration of SAP System System Integrity

ABAP/4 Developer
These users will have the ability to develop and maintain ABAP/4 programs, screens, menus and transactions. Additionally, they will have access to the Workbench Organizer and ABAP/4 Data Dictionary, which is required in order to execute development activities.

DataBase Administrator (DBA)

These users add tables, indexes and perform general database troubleshooting and monitoring. Some of this role is taken on by Developers, others by BASIS team members.

Operators
These users monitor the systems 24 hours a day for system alerts, batch job failures, and spooling problems. They can send system messages.

Network Administrator
These users monitor SAP for network problems. If they are unable to fix the problem through the network then they will notify Basis.

UNIX Administrator
These users monitor spooling and batch jobs at the UNIX level.

ALE Administrator
These users monitor the processing status of IDocs in ALE inbound and outbound processing between SAP instances and clients as well as the creation of the ALE connections.

Spool Administrator
These users will be responsible for monitoring and controlling the access by users to specific printers.

Help Desk
These users are the first line in support for SAP Security. They will create remedy tickets for issues that need to be handled by a Security Developer. They can also Unlock users who have been locked for too many invalid login attempts. but will not be able to unlock those locked by an Administrator.

Workflow Administrator
These users define in business processes who does what to what and in what order. They handle the items that error out of workflow. They determine why this happened and fix the error so it will process correctly. Usually the errors are related to escalation hierarchies.

Configurator
Configurators will have access to SAPs Implementation Management Guide (IMG). Access to the IMG is required in order to configure SAP functionality. Configuration access will require a combination of access to the IMG and client

table configuration

5.2.2 Technical Roles Defined for Production

TBD

5.3 SAP Landscape 5.3.1 Instance Overview

Development This instance is used to develop and configure what will eventually be used in the production environment. The development instance is the first area where functional configuration and ABAP development takes place. The Change Control process and security roles are used to ensure that all changes have been properly authorized and the development process is properly controlled. QA This instance is used for integration testing before changes are made to production and troubleshooting production problems. In QA a production problem can be recreated which eliminates the need to change data in production just to run a test. The QA environment is periodically refreshed from production. Production This instance is where the actual day to day business processing takes place. Sandbox This instance is primarily used for evaluating experimental system and application enhancements and upgrades. It is also the test area for different scenarios to be evaluated prior to being configured in Development. It can also be used to research new functionality. Training This instance is used to train users on SAP functionality before allowing them access into the production system. All instances contain the following clients: Basis Team Lead SAP AG Basis Team Lead Basis Team Lead SAP AG Earlywatch

000 001 066

Reference only Reference only SAP Analysis.

5.3.2 R/3 Overview

Development (D01)
CLIENT 100 OWNER NAME Golden USE All change requests that were tested and proven in sandbox 100 and are ready to be recorded are entered here. No master or transaction data in this client (except Hierarchical Master Data) All development and configuration is tested in this client. Configuration should be moved from client 100 using SCC1. After testing is complete these changes are moved to QA. Master & Transactional Data encouraged in this system. Client contains sufficient master data for unit testing. Changes are made in 100 and moved to this client when transports are released. Testing of Master Data loads and interfaces.

110

Configuration

120

Application and Role Development

Sandbox (S01)
CLIENT 100 OWNER NAME Configuration Sandbox USE All configuration is allowed in this instance. The creation of Master and Transactional data is encouraged. Experimental type configuration that may have a negative cross-functional impact; testing for team members with less experience with configuration.

Q/A (Q01)
CLIENT 100 OWNER NAME Golden Build USE This will start as a fresh copy of SAP 4.7c. All Transports from Development will be imported into this client before client 110 is created. No HMCO specific master data or transactions will be allowed in this client.

110

Integration Test

This client will be copied from Client 100 initially and from then on all transports into QA will go into this client as well as client 100. No manual configuration will be allowed in this client. Master & Transactional data is allowed

Production (P01)
CLIENT 100 OWNER NAME R/3 Production USE This is where the business is run. No configuration or development is done in this client directly.

Training (T01)
CLIENT 150 OWNER Training Lead NAME Training Dev Master USE The classes are developed here and copied to the class client. Classes are held in this client.

155

Training Lead

Training Client

5.3.4 BW Overview Development (DW1)

CLIENT OWNER NAME USE

100

BW Development

All development and configuration is done in this client. After testing is complete these changes are moved to QA. Infocubes are transported via RSA1 rather than the regular CTS method.

QA (QW1)
CLIENT 100 OWNER NAME BW Q/A USE This client contains data for integration tests of new development and configuration that was released from DW1-100.

Sandbox (SW1)
CLIENT 100 OWNER NAME BW Sandbox USE This client can be copied from any client from DW1. ABAP and client independent changes can be implemented and tested in this client.

Training (TW1)
CLIENT OWNER NAME USE

Production (PW1)
CLIENT OWNER NAME USE

SAP System Supplied Super User(s)

The SAP system has four default users that come with every SAP system. The four standard super users are SAP*, DDIC, Earlywatch, and SAPCPIC. These users should be strictly secured by the SAP Security Administrator. The Basis and Security Administrators will be the only users who know and have access to these two users.

SAP*
SAP* is the user that is setup in every client install or copy. Because this user is written into the SAP code, it is also the only user that does not have a user master record. This user also has complete access to the entire SAP system. At Houghton Mifflin SAP* has the profiles SAP_ALL and SAP_NEW and is controlled by Basis. The following tasks should be completed in order to properly secure this ID: (program RSUSR003 can be used to determine if the default password has been changed) Change the password because the original password is highly publicized. Create a user master record for SAP*. Ensure SAP* is assigned to the user group SUPER to warn against deletion or modification of the user master record. The SAP* user must always have a user master record in all clients otherwise the hard-coded password for SAP* prevails. SAP_ALL and SAP_NEW SAP Delivered Profiles SAP_ALL and SAP_NEW are system profiles provided by SAP. They contain unrestricted authorizations for the entire system, including the Basis system and all the applications. These profiles WILL NOT be given to any dialog user on the production system, however some BASIS functions may require this and will be evaluated on a case by case basis.

6.2 DDIC

User DDIC is a SAP supplied identifier that comes standard with every system. Unlike SAP*, this user has a defined user master record. DDIC has special privileges relating to the data dictionary in SAP and its the only user allowed to log in during a system upgrade. Therefore, this user must be secured against misuse or unauthorized access. This user may be needed for running jobs via UNIX (i.e. unsuccessful transports will require this user ID). The following steps should be performed to mitigate the risk of user DDIC: Change the password because the original password is highly publicized. Ensure DDIC is assigned to the user group SUPER. One person should be appointed as DDIC Administrator (Basis or ABAP/4 team member). Any changes that need to be made to the Data Dictionary will be sent to this person and he/she will be responsible for updating the Data Dictionary and its associated documentation. The Basis team will serve as backup DDIC Administrator. (Who is the DDIC administrator here TBD)

Earlywatch
This ID is used by SAP to analyze the system. They usually use this ID atleast once a year to return a report on how the system is functioning. At Houghton Mifflin this ID has SAP_ALL and SAP_NEW. (talk to Basis for more specifics)

SAPCPIC
This is a communication ID and should be given the profile S_A.CPIC. This ID does not need, nor will it have, SAP_ALL and SAP_NEW.

Naming Conventions
A standard naming convention is used to develop security activity groups, authorizations and profiles. This standard facilitates the process of identifying access privileges. SAP uses a standard naming convention for its own system objects and has reserved name ranges for customer objects (e.g. customized profiles, authorizations and authorization objects). SAP requires that the first character of a custom security activity group, authorization, profile and object, start with a Z or Y. Profiles. Following the SAP recommended naming conventions helps to ensure that customized objects are independent of the SAP supplied objects and will not be overwritten during the import of a new SAP releases/upgrades. Below is the naming convention outline for Activity Group Names.

Character Positions 1st 2nd 3rd and 4th M Colon Finance Role Sales & Marketing Logistics Business Warehous e Basis Security Batch/ Backgrou nd Global/ Common Underscor e Field Role Corporate Role Support Role Multiple Roles Display Update Report CrossApplicatio n Underscor e Descriptio n of Role

Master Roles Z (:) FI SM LO BW BS SE BT GL Colon

Derived Roles

Composite Roles C

(:) FI SM LO BW BS SE BT GL

Colon Finance Role Sales & Marketing Logistics Business Warehous e Basis Security Batch/ Backgrou nd Global/ Common Underscor e Field Role Corporate Role Support Role Multiple Roles Display Update Report CrossApplicatio n Underscor e Descriptio n of Role

(:) FI SM LO BW BS SE BT GL

5th 6th

_ F C S X

7th

D U R C

8th 9th 25th

Finance Role Sales & Marketing Logistics Business Warehous e Basis Security Batch/ Backgrou nd Global/ Common Underscor e Field Role Corporate Role Support Role Multiple Roles Display Update Report CrossApplicatio n Underscor e Descriptio n of Role

_ F C S X

_ F C S X

D U R C

D U R C

26th 27th-30th

Blank Blank

Underscor e

Underscor e

Example

See See Appropria Legend Appropria Legend te Suffix te Suffix based on based on derivation derivation M:FI_FD_Cash_R Z:FI_FD_Cash_R C:SD_XD_ORDE pt pt_MIMN R_HISTORY_D0 01

Valid Suffix Values: where this is a copy of the master (i.e., for support role) where XXXX = Location / Warehouse name (i.e., BOS) where 99 = Division Number where 000 = 000 999 (assigned sequentially) where 000 = 000 999 (assigned sequentially) where 000 = 000 999 (assigned sequentially) where 000 = 000 999 (assigned sequentially)

ALL

Full Authorization

XXXX D099 C000 M000 R000 V000

Location Specific Roles Division Specific Roles Corporate Specific Roles Org Level Data Specific Roles Non-Org Level Data Specific Roles View Only Role

Activity Group Text

Text describing the role.

Profiles
The SAP name beginning with T- and an SAP generated number is used. This is generated automatically by SAP when the authorization tab is generated.

Authorizations
Authorization names will be automatically generated by Profile Generator from the profile name when the authorization tab is generated. The last two digits are used as a counter for number of authorization objects used within the activity group. This

number relates to the buffer space for users provided in table USH04. An example of an authorization name would be T-R034105801 with 01 acting as the counter.

User Group Security

User and security administration can be segregated and decentralized through the use of user groups. User groups are logical groupings of users that provide a mechanism for allowing sub- or remote Security Administrators access to maintain a limited group of users or to quickly query on a set of users. The following are user groups that were defined by the Security Team:

Sandbox/Development System(s)
Role User Group

Integration/QA System
Role User Group

Training System
Role User Group

Production System
Role User Group

Help Desk Procedures

9.1 Help Desk Responsibilities
Front-line support for SAP end users requiring password changes Fill out remedy tickets and route them to the security team. The remedy tickets should contain Name, User ID, description of problem, and SU53 if needed.

9.2 Resetting User Passwords

Help Desk personnel will be given access to production SAP clients and systems. These individuals will have access to reset passwords for all end users, except those attached to the groups SUPER and Security. See section 12 Password Administration for change/reset password procedure. IMPORTANT: Only the Security Administrators and Basis will have the ability to reset passwords for end users in groups SUPER, and Security.

9.3 Unlocking User IDs

The Help Desk should only unlock end users that have been locked due to invalid logon attempts. Only the Security Administrator can unlock end users that have been locked by administrators.

9.4 Resolving Access Issues/Problems (Troubleshooting)

If an SAP end user cannot perform his/her job responsibilities because of a lack of security access, SAP displays an authorization error message. Examples of authorization error messages include: You are not authorized to use transaction MK02 You are not authorized to create assets You are not authorized for company code 1075 You have no authorization for class MC

The Help Desk should use the steps below to document the problem before sending a Remedy ticket to the Security Team. Identify the authorization error Ask the user what transaction he/she was attempting to execute. If only the menu path is known, advise the user to click on System > Status to identify the transaction code:

The System Status screen displays Usage, SAP, Host, System and Database data. The transaction is identified under the Repository data section of SAP data.

Have the users execute transaction SU53 (type this in the command box) when the authorization error appears at the bottom of the screen. The following information will appear (Authorization Object, Authorization Needed, Authorization available for the User):

Have the user download this data using the menu path System->List->Local File and then select the rich text format option. Have them email this and attach it to the Remedy ticket. The Help Desk should also record the User ID, user name, system and client in the Remedy ticket. NOTE: The Help Desk users will not be authorized to change any security configuration (i.e. Maintenance of user profiles). Any modifications to user profiles or other security issues will be forwarded to the security team for resolution.

SAP User Access

The Security Team will be responsible for creating and maintaining users in all SAP systems. See section 11 User Master Records for more detailed procedures on creating the user master record.

SAP User Access Form Procedures

Listed below are the steps that should be followed for SAP user access requests: Requestor/user will complete the appropriate SAP User Access Form according to the form instructions. After the form is complete, the requestor will send the form to the security team. The Security User Administrator will check to make sure the form is complete (i.e. all required information is present, including the appropriate approval signatures. If the form is not complete and does not have the correct approvals (process / functional area owner), the Security User Administrator will contact the requestor/user via a phone call or voice mail. After all the required approvals are received, the Security User Administrator will process the form according to the users request (create, delete or modify user ID). If a request is questionable, the Security User Administrator will contact the requestor for more information. After the request is fulfilled, the Security User Administrator will contact the user with the status of their request (their new user ID and password or the modifications that were made to their user ID). The security team will be responsible for the storage and retention of all user access request forms. *If an additional person besides the Team Lead is appointed as an approver of the form, the Team Lead must send a memo with their signature stating that this person has permission to approve SAP User Access forms to the Security Administrator. NOTE: If a person does not have access to a particular transaction and reports this to the Security User Administrator, they will reference the users SAP User Access Form to see if the access should be granted. If the profile is not listed on the SAP User Access Form, then Security User Administrator will inform the user that he/she will have to fill out a new SAP User Access Form to get approval.

User Master Records

The user master record contains all master data for the user in SAP. This includes user defaults, user addresses information, parameters, and passwords. User master records are client specific; therefore, the individual user master records need to be maintained for each of the clients. The following outlines procedures for creating a

new user master record.

Creating a User Master Record

The following lists of fields should be populated when creating a user master record on any client. While some of the fields are not required to be populated, the following are guidelines for what fields should be completed and the type of information.

Address Tab Last Name

Users last name.

First Name
Users first name.

LogOn Data Tab Initial Password

The initial password is a required field. The system prompts the administrator to type it in twice in order to reduce typing errors.

User Group
This field allows the administrator to categorize the users within groups. This categorization allows the administration functions to have separation of duties. For example, if the user is in the SUPER group, the only security administrator capable of maintenance must have access to that specific user group. It also allows for ease of querying users based on user group. See section 9 to determine which user group to use.

Valid From/Valid Until

These two fields are used for temporary or contract employees. If you want to specify the timeframe of access for a user, you would identify those terms here.

User Type
SAP uses the user type field to determine what type of processing the user will need. There are five types of users and each type defines if the user needs interactive, background, and/or external processing. Dialog- This is the default user type and is used for end users.

Communication This type of ID is used for dialog free communication between systems. (ie: RFC, or CPIC service users of different applications, for example, ALE, Workflow). Background processing is not allowed. System- This type of Id is used for dialog free communication between systems such as RFCs, CPIC, or background processing in one system. A user of this type is excluded from the standard settings for password validity period. The password can only be changed through SU01. Service Is a dialog user ID available to a large anonymous set of users. It usually has closely-restricted authorizations. There is no check for obsolete/initial passwords at logon. The password can only be changed through SU01. Reference This user ID is a general impersonal user like the Service user. You cannot logon with a reference

Default User Tab (Can be maintained by each user) Output Device (Printers)
This area will display all printers that are available to that particular user. All users should be given the default printer LOCL. Access to printers is controlled by S_SPO_DEV and all users require access to this authorization object in order to print SAP documents/reports.

Print Controller Functions

The Print Immediately button should be set.

Date Format
The standard date format should be set to MM/DD/YYYY.

Decimal Notation
The decimal notation should be set to 1,234,567.89.

Personal Time Zone

This personal time zone should be set to EST.

Parameters Tab User Parameters

The user parameter transaction in SAP allows users to manage certain key fields by automatically defaulting information into those fields. This will be populated by the users using transaction SU3.

Roles Tab

Roles
Roles for the R/3 and BW systems will need to be manually maintained according to the users job function. Complex roles will be created by the Security Development Administrator according to information gathered during Realization.

Password Administration
12.1 Administering User Passwords
When a user logs onto the SAP GUI, the user must supply both a user ID and a password. Both of these pieces of information are required for every logon. When a new user is created, an initial password is assigned. The first time a user logs onto SAP, the user will be prompted to immediately change his/her password. Passwords are never stored in the database in a readable form, but are stored as encrypted values. Before SAP allows a User access to the system and data, it checks the following. Has the User been locked? The SAP Security Team can prevent a User from logging onto the system by locking a Users account. For further details concerning locking User accounts, refer to section 14 User ID Lock/Unlock. Has the User's password expired? If so, the User must specify a new password. Has the user been terminated? If a user has exceeded their validity date they will not be allowed in the system.

12.2 Default Password Requirements

SAP provides several ways for administering User passwords for the SAP system and client: The following are default requirements within SAP that cannot be changed: The first character may not be ! or ?. The first 3 characters of the password may not be the same as the first 3 characters of the User ID. The first 3 characters may not appear anywhere in the User ID in the same sequence.

The space character is not allowed in the first 3 characters of the password. The password may not be PASS or SAP* (default passwords that are originally used by system ID's.) All characters found in the Syntactical Character Sets can be used. This includes all letters, digits and certain special characters. Passwords are not case sensitive. Thus, uppercase characters as well as lowercase characters are acceptable. Passwords may not be changed to any of the Users last five passwords used. A User can change his/her password only once a day. (This restriction does not apply to the User Administrator.) A relatively secure password might include a mixture of alphabetic and numeric characters with at least one special character in the middle of the password. To improve the security of passwords against unauthorized access attempts, proper names, common words and dates should be avoided as passwords.

12.3 Resetting Passwords

To reset passwords, follow the steps below: Log onto SAP and execute transaction SU01 (by typing /nSU01at the prompt) or enter the following menu sequence: " Tools>Administration>Maintain Users>Users". In the Maintain User: Initial Screen, the User's ID must be entered in the "User" box. Then press the Change Password button. Next, a small window will appear with the heading "Change Password." Type in the new password twice and press <ENTER>. After pressing enter, the following message should appear: " (User Id) has been reset." The User should be instructed that he/she will need to change the password when he/she logs on. A User can change his/her own password by: Logging on with their current ID and current password - without pressing enter. The small change password window will appear. The User should then enter his/her new password twice and then press the <ENTER> key. EMBED PBrush

12.4 Password Expiration

The maximum number of days that can elapse before a password must be changed is set by using the login/password_expiration_time system parameter. The password expiration period has been set to 90. This will force a user to change his/ her password every 90 days.

12.5 Password Length

The minimum length of the password is set by using the login/min_password_lng system parameter. The minimum length has been set to 8. The larger a minimum length the higher level of security.

12.5 Impermissible Passwords (SAP Table USR40)

SAP provides a standard mechanism that allows the establishment of invalid passwords. USR40 is a client independent table that is used to log all prohibited passwords. These are entered in the USR40 table using the SM30 transaction. Table USR40 is used during logon validation procedures and password checking to make sure the password does not violate any of the guidelines outlined in the table. USR40 is a table of impermissible values with two wild-card characters that may be used; ? - which stands for any single character and * - which stands for a sequence of any combination of characters of any length. Example: 123* forbids any password beginning with the sequence 123. *123* forbids any password containing the sequence 123. Another example: p?ss prohibits 'pass', 'pbss', etc. The table is manually maintained by the security team and should be consistently maintained across all systems. Standard passwords that are not allowed are: Pass*, *HMCO*, and Houghton.

13. System Profile Parameters

To view the following parameter settings go to SA38 RSUSR003 (These are changed by Basis using tcode RZ11)
SAP System Profile Parameter Description SAP Supplied Default Value Houghton Mifflin value for all production systems 8

Login/ min_passord_lng Login/ min_password_di gits

Minimum password length for user password Minimum number of digits in a password this will be enable in Production

Login/ min_password_sp ecials

Minimum number of special digits in a password this will be enabled in Production Login/ Number of days password_expirati between forced on_time password change. Login/ Number of invalid fails_to_session_en logon attempts d allowed before the SAP GUI is disconnected. Login/ Number of invalid fails_to_user_lock logon attempts within a day before the user id is automatically locked by the system. Rdisp/ Time, in seconds, gui_auto_logout that SAPGUI is automatically disconnected because of inactivity. Houghton Mifflin does not want users to be logged out of the portal of it goes down hence the long logout time. Auth/test_mode Switch to report RSUSR400 for authority check Auth/ Switch off system_access_che automatic authority ck_off check Auth/ Special no_check_in_some authorization checks _cases turned off by customer

90

12

1200 secs 15 mins

Login/ext_security

Security access controlled by external software. Auth/ Permission for rfc_authority_chec remote function k calls from within ABAP programs Login/ Disable system failed_user_auto_ function for unlock automatic unlock of users at midnight. Login/ Disable ability to no_automatic_use logon as SAP* with r_sapstar PASS of password when SAP* deleted. Login/ Disable multiple disable_multi_gui_ GUI logins on the login same account. This will be set to 1 in Production. Auth/ User buffer tcodes_not_checke overflow can lead to d losing authorization for tcodes SU53 and SU56. This setting can be used to exclude them from the auth check. Auth/ Does not allow authorization_trac every trace to be e logged once because USOBX is delivered complete. This could affect system performance if log is allowed. Auth/ Auth objects can be object_disabling_a globally deactivated ctive through tcode Auth_Switch_Objec ts

blank

SU53 SU56

Auth/ object_disabling_a ctive Rec/client

Authority Check Deactivation Auto Table Logging

Off

100?

13.1 Unsuccessful Logon Attempts - login/fails_to_session_end

A system parameter can be set to indicate the number of unsuccessful attempts at logon that are allowed before the users session is terminated. This value has been set at 3. No entry is made in the system log when a session is terminated. Default value: 3 Permitted values: 1 to 99

When a user successfully logs onto SAP, the system displays the date and time of the last logon. This information can also be viewed in table USR02 for all users. This allows the user to check whether anyone else has logged onto SAP using his/ her user ID since he/she last logged on. The logon date and time cannot be changed in the standard production system. The date and time of logoff are not recorded. NOTE: An external parameter in the logon script may be changed at the UNIX level to decrease the number of unsuccessful logon attempts to 3.

13.2 Automatically Locking a User - login/fails_to_user_lock

A system parameter can be set to indicate the number of unsuccessful attempts at logon that should be allowed before the user ID is locked. The value has been set to 5. Default value: 12 Permitted values: 1 to 99

An entry is made in the system log each time a user is locked, locked users can be viewed by executing program RSUSR002. The parameter login/ failed_user_auto_unlock has been set to prevent the locked user from becoming unlocked at midnight which would occur if just the above parameter was set. The SAP Security Team can also unlock a locked user at any time.

13.3 Logging off Idle Users - rdisp/gui_auto_logout

SAP provides the ability to automatically disconnect inactive users from the system. By utilizing this feature, security can be improved by assuring that SAP sessions at unattended terminals do not stay interminably inactive. By default, automatic logoff is not activated in the SAP system.

The value is set for 1200 seconds or 15 minutes. Users will be logged off after 15 minutes. The system does not perform a save before logging off the user. Thus, any unsaved data entered during the user's session will be lost. The dialog window requesting logoff confirmation is not displayed in an automatic logoff. A users session is considered to be idle between presses of the ENTER key or other actions that transfer control to the application server to which a user is logged on.

Extra considerations for log out settings.

The guidelines for the SAP production system should be more restrictive than those for the SAP development system. In the development system, ABAP developers may be automatically logged off while working in the workbench front-end application. When setting this parameter, consideration must be given to users who are typically "inactive" for extended periods of time. Such users may include: Programmers or other users of SAP editors who may be inactive for long periods of time only in the front-end (SAPGUI) software. Users who only occasionally enter data but who should not be logged off. Example: shop floor personnel who enter data in the SAP System only when an event such as a delivery of materials occurs. To protect such users from loss of data or the inconvenience of having to log on again, either the idle-time limit should be set to a large value or the auto-logoff should not be used on the SAP systems or servers on which such users are active. Auto-logoff can be activated selectively by SAP server by entering the parameter in certain system profiles only. With logon groups, users who should not be automatically logged off should be created on servers in which auto-logoff is not active.

14

USER ID LOCK/UNLOCK

14.1 Locking/Unlocking User IDs

The system will lock a user ID after 5 incorrect logon attempts. If the User is locked, the following error message will appear when he/she tries to log on "User is locked, please notify the person responsible." The automatic lock against a user's ID that is set by the system after incorrect logon attempts will be automatically released after midnight. If the user enters an incorrect password or user ID, the following error message is displayed: "Name or password is incorrect, please re-enter." The message will also be displayed if a user ID does not exist. If users need to be locked out of the system temporarily, the Security Administrator can also lock these users through SU01 and SU10.

14.2 Unlocking User IDs

To unlock user IDs, follow the steps listed below: Go to SU01 and enter the user ID. Click on the lock icon. A message will pop up explaining whether the lock was due to a system administrator or incorrect password tries. Click on the lock icon in the message box and the ID will be unlocked. A message at the bottom of the screen will confirm this. Ex (User user ID unlocked, if this is permitted in this system)

14.3 Locking User IDs

To lock user IDs, follow the steps listed below: Go to SU01 and enter the user ID. Click on the lock icon and a message box will appear that states not locked. Click on the lock icon in the message box and the ID will be locked. A message at the bottom of the screen will confirm this. Ex (User user ID locked) EMBED PBrush

14.4 Mass Locking and Unlocking

Multiple users can be locked and unlocked at one time, following the steps below: Go to transaction SU10, click on authorization data button and screen will appear that allows selection of users based on various criteria. Users based on name, user group, as well as all locked or unlocked users can be selected.

After the criteria has been entered, select the execute icon and a list of users meeting this criteria will appear. Select the users to lock or unlock and then select the transfer button. Select the lock or unlock icon and then an option appears to view the log. The log just lists the users who have been locked or unlocked. The lock or unlock at this point is complete.

15 Transport System (TMS) procedures for how transports will be handled going forward not finalized.
SAP has its own self-contained change control mechanism, the Transport Management System (TMS). This mechanism controls the changing and updating of information and includes tables, process configuration, ABAP/4 programs, screens, menus and SAP Security. The structure of the Transports Management System is critical when addressing how SAP security will be developed and administered. TMS is used to migrate changes within a controlled and secured manner (development), across the entire system landscape. TMS controls the flow of changes between Development, QA, Training and Production instances.

15.1 Transport Procedure Corrections and Transport System

Listed below are the steps that should be followed for all transports: Changes to the development instance are made that need to be transported to all other instances and clients in the system After the Change Request is created and saved, a Task is automatically created. The Task will contain all new or modified objects. Using STMS or SE10 the creator of the change request can release the task(s). During the release of the tasks a detailed explanation should be provided on the free form text page. Only team leaders will have access to release the higher level transport request. The requestor (functional or security team member) will complete the Transport Request Form in Lotus Notes. He/she will document the Change Request and a detailed description of what is contained in the request. The security team will need to complete a Transport Request form as well for security transports. If the change is an emergency the forms will need to be taken to each approver to sign off on the change. This will get the change into Q/A. When the form is obtained from the transport team (TBD) and the change has been tested in Q/A, the form will need to be signed again for movement into production.

If the change is a non-emergency the forms will be taken to the daily x:xx pm change request meeting and will be signed for movement to QA. When the form is obtained from the transport team and the change has been tested in Q/A, the form will need to be signed again for movement into production. The Q/A moves will be made first after the X:XX pm change management meeting and then the production moves will begin after 6:00 pm. After the Change Request is completed, the Transport technician will send an email message to the requestor, with a copy to the team leader that contains the Change Request number and that informs the requestor of the successful transport of the Change Request. The status of the transport will be updated in the Notes Database. If the Transport technician encounters any warnings or errors, the requestor will be contacted through email or voicemail. There are 4 parameters that are set for transport archiving. These can be reviewed at transaction STMS and then menu path Import Overview>Imports>GoTo> TP parameters and enter the system. The following are the parameters that affect archiving: datalifetime is the minimum lifetime of the files in data loglifetime is the minimum lifetime of the files in log olddatalifetime is the minimum lifetime of the files in olddata cofilelifetime is the minimum lifetime of the files in cofiles However archiving is not done automatically it occurs through a command "tp cleanold" to actually force the archive to occur. The data is then moved to a predefined archive directory.

15.2 Documentation Sources for Transports

Transport Monitoring The following reports can be used to monitor or search transport activity. STMS Transport Management System STMS_ALERT TMS Alert Monitor STMS_DOM TMS System Overview STMS_FSYS Maintain TMS system lists STMS_IMPORT TMS Import Queue STMS_INBOX TMS Worklist STMS_PATH TMS Transport Routes STMS_QA TMS Quality Assurance STMS_QUEUES TMS Import Overview STMS_TCRI Display/Maintain Table TMSTCRI STMS_TRACK TMS Import Tracking

15.3 How to Create a Transport

A Change request must be created to apply configuration changes made in the development instances to all other instances and clients within that system. When configuring a table in the IMG and selecting the SAVE icon for the first time a Change Request Query dialog box will appear. Any further changes made to this configuration will automatically be recorded to the initial CTS until it is released.

From here select create request or own request if one already exists and follow the steps to complete the CTS request. If this is a CTS for activity groups in profile generator PFCG, the transport must be initiated by selecting the transport Icon while on the initial PFCG screen. The role listed on this screen will be the role that is transported.

From here select create request or own request if one already exists and follow the steps to complete the CTS request. A large number of activity groups can be selected for transport by using the mass transport feature. While in PFCG the menu path Environment->MassTransport can be selected or the program PFCG_MASS_TRANSPORT can be run from SA38. Select the roles to be transported by using a * or range to include several activity groups. Then execute and select create request or own request if one already exists and follow the steps to complete the CTS request.

Releasing a Task in SAP: EMBED Word.Picture.8 Before the transport administrator can move the configuration/activity groups from development to all instances and clients on the same system, the Task must be released (this is where configuration is stored). This can be done with transaction SE10 or STMS. On the Customizing Organizer screen, look within the Customizing area (this area contains dependent table changes) or the Transportable area (this area contains independent table changes) to find your Task. Highlight the Task number by clicking on it once, then click on the release button. SAP will take you into the documentation screen for the Task. Enter in the documentation concerning the Task and click save button. In order for the request to be saved you must click on the save button whether documentation is entered or not. After the documentation has been saved, click on the green arrow to back out.

16. Security Change Control

All security changes must be have the following approved forms before the transport can be released. Transport Request Form This form is initiated by the functional team and explains why the transport is needed unless the change is related to a security error such as missing a transaction code or a role mapping over site. The Security team should also indicate the reason for this change.

16.1 Creating/Maintaining Activity Groups

The following are the procedures followed for creating new activity groups or adding new tcodes or authorization objects to an existing activity group. The user will contact the Help Desk with their security complaint. A Remedy ticket is created and routed to security. It is then routed to the functional team by security so the functional team can approve the need for the change. The change is added to the activity group and unit tested in the development environment. Unit testing refers to testing the activity group solo without other activity groups in the test ID. If the change is an emergency the Transport forms must be walked around to all approvers

for signatures. These forms should be hand carried to the transport team for immediate movement to Q/A. The Security team is responsible for releasing the task and the Security team lead is responsible for releasing the transport prior to turning the form over to the transport team. If the change is a non-emergency the Transport Form should be approved by X:XX pm so they will have time to get it to the change management team prior to the change management meeting at Y:YY pm. The Security team is responsible for releasing the task and the Security team lead is responsible for releasing the transport prior to turning the form over to the transport team. Once approved the change will be transported to Q/A for testing. The type of testing in Q/ A should be integrated testing which involves adding all the roles that the user will have in production to do both positive and negative testing. This can be used to prevent access creep. After testing is completed in Q/A approvals are needed to move the change to production. See steps 5 and 6. The same Transport forms can be used to obtain the production approvals. This form will need to be updated in the notes database

16.2 Maintaining User to Activity Group Relationships

Most of the roles will be assigned based on the job position of the user. It has not been determined yet what approval process will be used for user specific roles.

17.

Program/Report Security

17.1 ABAP/4 Development/Report Request Procedure

Listed below are the steps that should be followed when requesting a Developer resource: A Development request is made using the Development Specification form located in the eroom: http://eroom.dp.hmco.com/eRoomReq/Files/Corporate/ Sunrise/0_a622/Development%20%20Specification%20Template.doc This request form needs to be submitted to the Technical Team for review.

17.2 Rules for Creation of new ABAP Program/Report

All programs that will be executed in production must be assigned a custom transaction

code. End users will not be given SA38 but technical users will. Programs can be controlled by the authorization object S_PROGRAM, but currently Houghton Mifflin has not assigned authorization groups to their programs so this authorization object cannot be used to control access to programs. Table TRDIR lists all reports and the authorization groups they are assigned to. TPGP and TPGPT lists the available authorization groups that can be used by a program. Custom authorizations can be added to these tables. Since technical users will be given access to SA38, if there are programs that return or change sensitive data they should be further locked down by using a custom authorization object that only the approved users have in their access. Authorization objects called for in programs can be searched in the program code by calling up the code using transaction SE80. The find criteria should be entered as *auth* and tables also can be searched on using the criteria *tabl*. Security must ensure that the custom authorization has been written in the code by testing the program/report tcode in a user master without the custom authorization. The test should result in an SU53 that is looking for the custom authorization.

18. Security for SAP Tables

The ability to display and maintain table level data should be closely managed and granted on exception basis. No functional users will be given the transactions SM30, SM31 or SE16 to view table data directly in Production.

Existing SAP Tables

Display access will be granted based on configuration and functional requirements. Authorization Groups control table access and all table access will be explicitly granted based on authorization groups using the authorization object S_TABU_DIS. All functional user requests to update an existing table must be approved by the system and client owner. Production End users will not have access to transactions SM30, SM31 or SE16. Parameter transactions will be used to update tables.

New SAP Tables

All new tables must be secured with an authorization group. A table that does not have an authorization group assigned to it can be modified by any user with access to S_TABU_DIS with values of 02 and blank/spaces in fields activity or authorization group. The SAP Security Administrator must be consulted when new SAP tables are created. The following are steps that must be completed to properly secure a new SAP table: Identify the table or view name to be secured. Determine if there is an existing authorization group attached to similar tables that the new table should be grouped with. For new authorization groups, first create the authorization group name in the transaction SE54. Once the authorization group name is created, assign the authorization group to the table name using transaction SE16 to maintain the table TDDAT. (Note: This table must be added to a transport task manually. A transport will not automatically initiate when you make changes to this table.) When maintaining the table TDDAT, be careful, this is a client independent table. Once the authorization group has been applied, transport the change request to all subsequent clients and systems. IMPORTANT: While granting access to tables is controlled by two objects,

S_TABU_DIS and S_TABU_CLI for client independent tables only, users must also be granted access to the necessary transactions using the object S_TCODE.

Parameter Transactions
Table changes are usually done in the development instance and transported to all other clients and instances within a system. Occasionally there is a need to do table changes directly in production. A parameter transaction should be created to accomplish this. A custom transaction is created that is linked to the table, this transaction is used to do the direct table change. This prevents the need of changing tables via SM30, SM31 or SE16. These tables should be non-configuration tables so configuration will not need to be opened. The table type can be changed using transaction SE54 under tab attributes and the field delivery class. Parameter transactions are created using transaction SE93 and selecting transaction with parameters. A link should be made to the table in the fields name of screen fields and values. Authorization will be required for the new transaction to be executed by any user.

19.

Printers

General End-User restrictions: Spool access for general end-users is contained in our <HMCO Role> role given to all SAP users in Production. The role allows access to the following printers through the authorization object S_SPO_DEV: LOCL The <XXX> and <xxx> series (printer names are case-sensitive) were ranged out in the first <Z> entries and NON-SENSITIVE printers within the <xxx> range were specifically identified in the last <Y> entries. SENSITIVE printers (Check) (Invoices) (Customer Statements) were EXCLUDED. The authorization S_SPO_ACT controls what spools a user can view. Spools can be viewed using SP01 and SP02. The transaction SP01 allows you to choose other users and view their spools but this is only accessible if you are given permissions to view others spools through S_SPO_ACT. Houghton Mifflin has given the general non-technical user population the transaction SP02 that only allows view of the users own spool and does not

give the option to view other spools.

20. Installation of New Releases

20.1 Upgrade/New Release Installation Procedure
The following steps should be followed for a system upgrade: Once a new release is known and OSS notes have been reviewed, the Basis team will meet with all team leaders and the directors to get approval for the upgrade and set up a timeline for the installation (2-3 months). Basis will request the upgrade CDs from SAP. After the CDs are received, a Lotus Notes will be sent to all team leaders reminding them of the schedule for the upgrade around 48 hours before the upgrade begins. Each team leader will forward the Lotus Notes to each of the team members. Each system will take approximately 40 hours to upgrade and will be upgraded in the following order: Sandbox (S01) Development (D01) Integration/QA (Q01) Training (T01) Production (P01) Sandbox will always be the first system to be upgraded. After upgrading of Sandbox, it will be tested thoroughly by both programmers and configurators. After successful testing of Sandbox (usually two to three weeks) and team leader approval, Development will be upgraded. A backup of Development will be taken and overlaid over the Sandbox right before the upgrade to Development. A backup of Production will be taken and overlaid over Integration/QA prior to the upgrade to Integration/QA. After a backup is taken of Production, Integration/QA will be upgraded with the integration test team leaders approval. The Integration/QA system will require a thorough test of all functional processes by configurators and programmers before consideration of an upgrade to the Production system. Testing time for this system will depend on the upgrade. Upgrades to Production will be done only after all testing is complete and approval is received from all team leaders (the Production system owner). A Production upgrade will usually occur a few weeks after Integration/QA has

been upgraded. During the upgrade to Production, all transports will be frozen unless an emergency occurs. After a successful upgrade to Production, the Training system will be upgraded. NOTE: All newly upgraded systems will be extensively tested before the next systems upgrade begins. Development and Production upgrades will only be administered during the weekend.

Security Considerations for New Releases

As each new release or version of SAP is installed, there should be a detailed analysis of the impacts the new release may have on SAP application security. SAP provides two forms of supporting release documentation, an On-line Help CD and OSS notes. Both of these resources should be reviewed in detail as new releases are being considered. The following are guidelines for understanding how new releases may impact existing SAP security configuration: Review the on-line CD release notes. Typically, SAP categorizes changes by the module and security changes are usually contained with Basis documentation. Review the OSS upgrade installation procedures. These procedures may provide information on new security components or the potential impact on security. Analyze which objects SAP may have moved to obsolete. There is an object class that SAP uses to list all obsolete authorization objects. These objects should be reviewed to see how they might impact defined activity groups. Analyze new authorization objects. SAP uses the composite profile SAP_NEW to document new authorization objects. SAP_NEW contains a series of single profiles that are named according to the release. Review the new authorization objects to determine how they may need to be incorporated into existing activity groups. Additionally, review the new objects to determine if they replace any existing objects or obsolete objects. For the new objects, review the documentation and structure of the objects to determine how they are to be used. For objects impacting security, analyze which activity groups may be impacted. The number of activity groups impacted will indicate the potential time required to incorporate security changes. Meet with the Basis Team to discuss the impact the new SAP release may have on security. Consider recommending that the new release be installed in a Sandbox client; this will provide an environment for testing security without impacting existing security.

Review the listing of security programs supplied by SAP. Typically, these programs start with RSUSR followed by three digits. These reports may assist in handling upgrades or security monitoring activities. NOTE: It is imperative that each new upgrade or release to be implemented be extensively reviewed and tested.

21 Obtaining OSS logon, Developer Key and Object Key

OSS is a worldwide network service offered by SAP to help log issues or review issues concerning maintenance and configuration of the SAP system. It provides a communication bridge between SAPs customers and first-level customer support team. OSS Logon IDs are requested through OSS in SAP and will require functional team leader approval. Object Keys are only used when a standard SAP object needs to be modified to meet the requirements of the implementation. Listed below are the procedures for obtaining each of them:

21.1 OSS Logon Setup Procedure

The following steps should be followed for setup of an OSS ID: Functional users will send a request via Lotus Notes to a designated security OSS administrator. (Currently Paul Donovan) Security OSS administrator will log on to OSS and enter in the request information for an OSS logon ID. SAP will send back a password and account number to the security administrator. Security OSS administrator will then go into OSS and set up access privileges for the functional user. After setup of the users access to OSS, the security OSS administrator will inform the user of their OSS password and OSS logon ID.

21.2 Developer Key and Object Key Setup Procedure

The following steps should be followed for setup of a Developer and Object Key: ABAP programmers will request a Developer or Object key via a Lotus Notes message to ABAP team leader. ABAP team leader will register the Developer key or object key with OSS and give it to the programmer. (currently Paul Donovan)

22. Client Copy

A client copy should only be administered when necessary and approval by the persons specified below is required. The following steps should be performed for a client copy: Client copy request forms will be submitted to Basis team via Lotus Notes from the team leader with a notification time of at least 48 hours. (See appendix E for Client Copy Request form) Basis will forward the Client Copy Request form to the client owner/s. The form will then be presented at the SAP team leader meeting for discussion and final approval by client owner/s and the team leaders. If it is an urgent request, a Lotus Notes will be sent from the owner to the team leaders. A client copy of clients which contain client independent data (e.g.. D01 100) should be approved by all team leaders and directors. Clients with dependent data should have approval from owner of the source and target client owner/s (e.g. D01 110). After approval is granted, the Basis team will send out a Lotus Notes message to all team leaders and directors informing them of when the client copy will take place and identify the source and target clients. The team leaders will forward this note to the team members. A backup of the target client will also be done. All functional users must be out of both the target and source clients while it is running. Basis will perform a test run the evening prior to the client copy run. Basis will run all client copy requests at off times (10:00 p.m.). NOTE: Clients in Q01 and P01 are not client copy candidates. Any changes made to source client while the client copy is running will not be reflected in the target client.

23. System Refresh

System refreshes are used to reinstate data into a specific client. System refreshes allow a complete copy of the customizing environment of a source client to a target client. Refreshes should only be done before upgrades and at specified times (i.e. quarterly or before integration testing). Any needs for refresh will be discussed at Team Leader meeting and will require the approval of all three directors. The following steps should be followed for a System refresh:

Functional user must complete the System Refresh Request form (appendix C) and send it via Lotus Notes to team leader for their approval. Team leader will approve the request and will forward it on to the directors and Basis Administrator for approval. System Refresh Request form will be brought to the Team Leader meeting for discussion and set up of system refresh schedule. Team Administrator will notify team leaders of the system refresh (clients, date, time) via Lotus Notes and they will forward it on to team members Basis will send a system message regarding the system refresh approximately seven days before. An offline back up is taken of both Production - P01 (usually done around X:XX p.m.) and Integration - Q01, then the refresh is applied to Integration Q01 system. Q01 will have to be taken down for two to three days, but will be unavailable for <Z> days. After completion, the Basis Administrator will notify the all users via Lotus Notes or voicemail that they can now log on the target client. NOTE: During the refresh, all users will be locked out of the target system.

24. SAP Patches

Legal patches these will be downloaded directly from OSS and may contain fixes to bugs, performance problems, etc. The following procedure should be followed when a SAP patch is applied: Basis team will be informed of a new SAP patch through OSS notes (patches are usually announced in OSS notes). Basis Administrator will send a Lotus Notes message to the functional team leaders and managers to inform them that an SAP patch will be applied and the date and time of the application. Developers and configurators will check to see if their repairs will have any affect on the patch upgrade. If the team leader wants to postpone the application of the patch, they will contact the Basis team. The Basis team will send a final message to functional users to inform them of the patch application date and time. If the patch application date and time changes, the Basis Administrator will send an additional note informing functional users via a Lotus Notes message the new date/time when the application of the patch will take place. Patches to SAP are applied to client 000 for the following systems in the

following order: Sandbox Development Integration/QA Production (at 6:00 a.m.) Training

NOTE: Patches are applied to Development and QA during the day, Production at 6:00 a.m. Once the patch is applied, functional users will be allowed to log into the system to review their programs and configuration to ensure no change has taken place due to the patch upgrade. After testing of Sandbox for about a week, the patch will be moved to Development, a few days later to Integration/QA, and then to Production a couple of days after that, and finally to the Training system. Any erroneous changes to objects that occur after the application of the patch should be reported to the Basis team and an OSS note should be created.

25. System Down Time

Every fourth Sunday the system will be taken down at 12:00am and will be down for less than 20 hours. At other times, the system will be taken down around 12:00 noon or on the weekends. The system will only be taken down for emergency maintenance and upgrades. If this needs to occur, the team leader will notify all users immediately. For all other occasions, two SAP system messages will be sent out to all users that are in system or try to log on. The first message will be a warning message sent out about an hour before the downtime. The second system message will appear 10-15 minutes before down time asking people to logoff. Once downtime is complete, the Basis team will inform the Team Leads via voice mail that the system is available again and they will forward the message to all users. NOTE: For non-emergencies (e.g. upgrades), QA and Training will be taken down during the week; Production will follow on the weekend.

26. Batch Job Processing

All batch jobs will be managed centrally by the operations team (TBD). All jobs are scheduled under the communication ID BTCHMSTR. Standard Job Request Form Procedures Requester: This is for the requestor information: name, extension and date requested. Job Information: Job Name: The job name will consist of 2 or 3 alpha characters followed by 3 numeric characters. Ex. The first job requested by the BW team would be BW001. This field is not required but the # given must be a unique # or it will be changed to a unique # when it is entered into the scheduler. Job Description: Give a complete description of the job. This will be added to a section on the scheduler that will viewed for information about the job. Job Status: Is this job new to the scheduler or is it a change? Or does it need to be removed from the scheduler? System: Enter the system that the job is to be executed on. (Ex. P01) Script Name: Put the entire file string including the script name. Parameters (if any): If there are any parameters needed to execute the script list them in the order the script will be using them. Capture Alternate Output File (if any): If there is an output file needed put the entire file string where the file is located and the filename. The scheduler will not create this file so it must be existing or the script should create it. Estimated Run Time: This will be helpful when setting up the schedule, but not mandatory. Schedule Information: Periodic Execution: The frequency it runs. If other is chosen put the explanation in the Special Instructions section at the bottom of the form. Execute On: Choose the day(s) that you want the job to run on. Job Predecessor: List any other job or jobs that need to be run before this job can execute.

Job Dependencies: List any other job(s) that need to be run before this job can execute. Event Dependencies: List any event(s) that need to happen before this job can \ execute. Holiday Restrictions: Execute only on workdays: The job should run only on workdays and just skip the run that would execute on the holiday. Previous Workday: The job should be executed the workday prior to the holiday. Next Workday: The job should be executed the workday following a holiday. If none of the above are chosen then it will execute as usual regardless if its a Holiday. Abort Resolution: Skip Job-Continue: If the job aborts and there is another job to run then skip this job and continue with the next job. There will be an email sent that this job aborted so it can be handled later. Leave Down Until AM: The process requires that this job cannot continue until the step that aborted is fixed. If it cannot wait until morning then fill in the next section Open Call with the information of who needs to be called. Special Instructions: This section is for any extra details needed about the job that is not listed on the form.

27. SU24 Transaction

27.1 Overview of SU24
Profile Generator uses the data entered through transaction SU24 to determine what authorization objects and field values are pulled into the activity group. It also allows the user to prevent certain authorization objects from being called when a transaction is executed. When SAP transactions are executed, authorization objects can be checked before execution or full access is allowed. In order for these checks to be executed successfully, the user must have the appropriate authorizations in their user buffer.

For an authorization check to be executed, it must be included in the source code of a transaction and must not be explicitly exempt from the check within SU24. Authorization checks can be suppressed without changing the program code through check indicators. Also check indicators control which objects appear in the Profile Generator and which field values are displayed there for editing. The indicators that control authorization checks are listed below. U N C CM Test Status Authorization Object if defined in transaction code is checked. Authorization Object not checked when the transaction is called. Authorization Object checked when the transaction is called but values not entered into profile generator. Authorization Object checked under the transaction and the field values are entered into profile generator.

SAP supplies defaults for check indicator and authorization field values in the tables USOBT and USOBX. You can then edit these defaults using SU24 and the edits will be reflected in the tables USOBT_C and USOBX_C. The field that determines the checks above is the check flag field. Below is the definition of the values for this field. N Authorization object is not checked when the transaction is called even if it is in the code. Y Authorization object is checked when the transaction is called. The values for the fields of the authorization object must be maintained in SU24 and is used by profile generator. X Authorization object is checked, but the field values are not specified in SU24 there not used by profile generator. U Not maintained.

27.2 Maintaining SU24

Transaction SU24 should be maintained so no manual authorization objects need to be added to the authorization tab on profile generator. Also if an incorrect authorization object or field value is brought into the profile generator it should be changed only through SU24. This will then allow only correct or blank field values are brought in so the correct values can be entered and the proper authorizations assigned. These changes must only be made in the development environments and transported to all other environments so the USOBT_C and USOBX_C tables stay in sync in all environments.

28. Security Monitoring Activities

SAP supplies a series of reporting tools and ABAP/4 programs that provides detailed analysis and monitoring of SAP security at the client and system level. The monitoring reports can be accessed via two methods, executing the actual program using transactions SE38, SA38 or SUIM (Repository Information System).

Standard Security Monitoring Activities

The following procedures are standard security monitoring activities (see table on next page). Additional standard reports can be found in Appendix H.

No. Objective Monitoring Procedure ReportRecommended Frequency System ClientCompleted By (Who/Date)1 Ensure The report RSUSR0 invalid lists for 06 login each client attempts within the are system, all properly users with reviewed. invalid login attempts and those users locked either by Security Administr ators or too many invalid password attempts (4). Review the report to identify any inconsiste ncies or patterns.

Daily

Ensure changes to passwor ds are properly authorize d.

Review SU01 passwor d change documen ts (in SAP) for key users, includin g SAP*, DDIC, Basis and Security Adminis trators. The ability to reset passwor ds should be limited to Basis and Security Adminis trators, and Help Desk users.

Weekly

Ensure SAP System Profile Paramete rs are properly configur ed based on Deloitte & Touche Standard Operatin g Procedur es.

For each system, review the key security related system profile paramete rs. The paramete r values should be configur ed accordin g to the recomme nded values in section 13 System Profile Paramete rs in the SAP Security Adminis tration Standard Operatin g Procedur es. Addition ally, these paramete rs should be

Ensure changes to SAP security are properly approve d.

For selected key users, includin g Basis and Security Adminis trators, execute the report and review change history. Review the date of changes and who made the changes. Changes should be limited to other Basis or Security Adminis trators.

RSUSR 100 RSUSR 101 RSUSR 102

Biweekl y

Ensure security access is properly restricted to Security Team members as defined in Policies and Procedur es.

Review the users that have access to the authoriza tion objects S_USE R_GRP, S_USE R_AUT and S_USE R_PRO. Access to these objects should be limited to the Basis and Security Adminis tration Teams. The Basis Team should only have display access and the ability to reset passwor ds for all user groups

Ensure SAP supplied SAP* and DDIC are properly secured.

Review the report and verify that the passwor ds for SAP* and DDIC have been changed for all clients. The report shows all of the clients defined to the system. SAP* and DDIC passwor ds should be consiste ntly maintain ed on all clients.

RSUSR 003

Monthly

Ensure access to security transacti ons is properly secured.

Check RSUSR for 010 transacti onal access to security administ ration. Execute report RSUSR 010 and check for transacti ons PFCG, SU01, SU02, SU03 and SU05. They control access to the profile generato r, user administ ration, profile administ ration, authoriza tion maintena nce and internet user administ ration.

Monthly

Ensure table access is properly configur ed.

Access to maintain tables should be coordina ted with the Basis Team. And, table access needs to coincide with the ability to perform configur ation. Review the users that have table access for both client independ ent and depende nt table access. (S_TAB U_CLI and S_TAB U_DIS). Client independ ent table access should be

Ensure that all users are properly assigned to the correct user group.

Review RSUSR the users 002 defined for all clients and systems. Each user should be assigned to a valid preapprove d user group. Refer to section 8 User Group Security for approve d user groups.

Monthly

10

Ensure master addresse s are populate d accordin g to standard operatin g procedur es.

Execute the ABAP/4 program and select the address fields: first name, name field 1, building name, street, city, location, depart ment, phone, extensio n and country key (not currently on Access Form but can be maintain ed by each user). Review the user master records to ensure all users have the required address

11

Ensure that impermi ssible passwor ds are consiste ntly impleme nted and meet standard operatin g procedur es.

Verify SE16 the data containe d in table USR40. This table contains Houghto n Mifflin specific impermi ssible passwor d settings.

Semiannually

12

Ensure SAP Profile Generato r is properly configur ed.

Review SPRO the configur ation and activatio n of the SAP Profile Generato r. Review the documen tation in the Enterpris e IMG to ensure all configur ation steps have been successf ully complete d. This activity should focus on new systems.

Semiannually

29. Storage and Retention of Houghton Mifflin SAP R/ 3 Security Administration Policies and Procedures
The storage location and retention of Houghton Mifflin SAP/3 Security Administration Policies and Procedures will be determined by the team leaders and project directors, security/QA manager. The document will be stored on H:\SAP \Policy and will be secured via read-only access.

29.1 Periodic Review of Houghton Mifflin SAP R/3 Security Administration Policies and Procedures
Periodic review times for Houghton Mifflin SAP/3 Security Administration Policies and Procedures will be established by the project directors, team leaders, and security/QA manager. Supplementary review of these policies and procedures will be approved by the project directors, team leaders, and security/QA manager. Specific review times will be dependent on three things: Implementation of a new system New projects Significant changes in environment

Appendix A Important Contact Information

A.1 Houghton Mifflin Leaders
Houghton Mifflin Leaders Project Director

Finance Team Lead Order to Settlement Team Lead Supply Chain Team Lead Technology Teal Lead ABAP/4 Team Leader Security Team Leader

Jim Cashin Chris Goguen Bill Fotos Joe Serrano Shane Glasser Marilyn Harris GraceAnn Cohen Paul Donovan Vijay Tatipigari

A.2 Houghton Mifflin Security Team

Houghton Mifflin Security Team Team Leader Team Member Team Member Team Member Consultant Consultant Consultant Consultant Consultant

Appendix B SAP User Access Forms

ACCESS REQUEST FORM Sunrise Project
NEW CHANGE DELETE

USER INFORMATION Name FORMTEXT Phone FORMTEXT Date FORMTEXT

Approver FORMTEXT

Validity from: ____/___/______

To: ____/___/______

For new Implementation Team members only:

FORMCHECKBOX REQUESTED SAP SYSTEM ACCESS SYSTEM CLIENT Allow Access to Solution Manager

Solution Manager

FORMCHECKBOX 100 Please check the role(s) required for your project responsibilities: FORMCHECKBOX Functional User (All Application Access) FORMCHECKBOX Training Attendee

Sandbox

FORMCHECKBOX 100 Please check the role(s) required for your project responsibilities: FORMCHECKBOX ABAP/4 Developer FORMCHECKBOX Functional User (All Application Access) FORMCHECKBOX Configuration (All Areas) FORMCHECKBOX BASIS Administration

Development

FORMCHECKBOX 100 FORMCHECKBOX 110 FORMCHECKBOX 120 Please check the role(s) required for your project responsibilities: FORMCHECKBOX ABAP/4 Developer FORMCHECKBOX Functional User (All Application Access) FORMCHECKBOX Configuration (All Areas) FORMCHECKBOX BASIS Administration

Quality Assurance
110 Please check the role(s) required for your project responsibilities: FORMCHECKBOX ABAP/4 Developer User : FORMDROPDOWN FORMCHECKBOX BASIS Administration

FORMCHECKBOX 100 FORMCHECKBOX FORMCHECKBOX Functional

Training

FORMCHECKBOX 100 FORMCHECKBOX 110 Please check the role(s) required for your project responsibilities: FORMCHECKBOX ABAP/4 Developer FORMCHECKBOX Functional User : FORMDROPDOWN FORMCHECKBOX BASIS Administration

Production
Role: FORMDROPDOWN Please briefly list your responsibilities:

FORMCHECKBOX 100

__ FORMTEXT _______________________________________________________________________________________

Approved by: _____________________________________

Appendix C System Refresh Form System Refresh Request Form

Standards All requests must be approved by the appropriate team leader and Project Director Upon approval Basis will send a system message regarding the client refresh approximately seven days before An offline backup is taken of Production P01, then the refresh is applied to Integration Q01 system. Q01 will have to be taken down for two to three days, but it will be unavailable for a week Users will be locked out of the client where the refresh is being copied to (target client) User Information: Requested By: FORMTEXT Phone number: FORMTEXT Client Refresh Information: Objective of Client Refresh: Conflicts of System Refresh: Source system: FORMTEXT Approval: FORMCHECKBOX leader: FORMCHECKBOX Team leader: Manager/Team Integration Test Team: FORMTEXT Date needed: FORMTEXT

Target system: FORMTEXT FORMCHECKBOX Project Director:

SAP Basis only: Date Received: FORMTEXT Date completed: FORMTEXT

Completed by: FORMTEXT

Appendix D Client Copy Request Form Client Copy Request Form

Standards 48 hour notification required A test run is performed the evening prior to the client copy run All requests must be approved by the appropriate team leader Due to size limitations, Q01 and P01 are not client copy candidates Users must be out of the target client while the client copy is running Work made to the source client while the client copy is running will not be reflected in the target client Where appropriate, SAP Basis reserves the right to deny any request Date Requested Submitted By Team Leader Approval Project Director Approval Source system Source client Target system Target client FORMCHECKBOX D01 FORMTEXT FORMCHECKBOX S01 FORMTEXT FORMTEXT FORMTEXT FORMTEXT FORMTEXT FORMCHECKBOX D01 FORMTEXT FORMCHECKBOX D01 FORMTEXT FORMCHECKBOX T01 FORMTEXT FORMCHECKBOX T01 FORMTEXT

Profile information please select only one FORMCHECKBOX SAP_APPL Customizing, master and transactional data FORMCHECKBOX SAP_CUST Customizing data Customizing, master and transactional data, FORMCHECKBOX SAP_UAPP user masters FORMCHECKBOX SAP_UCUS Customizing data, user masters FORMCHECKBOX SAP_USR Authorizations and user masters

Reason for client copy

FORMTEXT

SAP Basis only Date received Date completed

FORMTEXT FORMTEXT

Appendix E Transport Request Form

See Lotus Notes DB.

Appendix F - Glossary
Authorization Objects - A template utilized by SAP transactions/programs for testing access privileges. The object may contain a group of 1 to 10 fields. The objects are checked using AND logic to determine if the user has been permitted through authorizations, to carry out the desired action. Authorizations - A set of permissible values (value set) for an authorization object. The values are assigned based on the fields defined in that authorization object and the required access capabilities (e.g. a value of 03 in the activity field will assign display access and value of 11 in the company code field will assign access to company 11). Authorization Group - An assignment of customized values to groups of similar information. The authorization groups are used in conjunction with authorizations associated with specific authorization objects. The field can contain an alphanumeric value up to 4 characters/digits. Single Profile - A mechanism for grouping either similar or dissimilar authorizations into a logical group. The profile provides an efficient method for administering user access to similar functionality through the assigning of a single profile to a user. The single profile can only contain authorizations. Composite Profile - A mechanism for grouping either similar or dissimilar access into a logical group. The composite profile provides an efficient method for administering user access to complex functionality spanning several modules. The profile may contain single profiles, authorizations, or other composite profiles. User Group - A mechanism for grouping SAP users into similar categories for administrative procedures. The basis administrators and security administrators are generally included in the SUPER group. The user group is a security administration attribute that can be used to decentralize user administration. A security administrator must be given explicit access to a user group. Activation - An action of making an authorization or profile activate. Activating an authorization or profile will replace the current active version with the maintenance version. All authorizations and profiles must be activated for the access to be applied to users. Activity Group Activity groups are used in conjunction with creating

authorization profiles using the Profile Generator. An activity group is a collection of activities (tasks, reports and transactions) for which you can then use Profile generator to generate an authorization profile automatically. You then assign the profile to the user via the activity group. Profile Generator The profile generator is an automated security development and administration tool developed by SAP AG. This functionality was integrated into the SAP software for release 3.1G. It automates the creation of activity groups, generating authorizations, creating single/simple profiles and assigning activity groups to users. The profile generator is a transaction based security administration tool. Transaction A four-character code used to SAP to identify a screen used within the SAP system. The transaction code (e.g. FB01, SU03) is the foundation for developing and administering SAP application security. Role A role is the first level for defining user access to the SAP system. For example, a role defined for Houghton Mifflin is A/P Clerk. In defining a role, scripts and/or transactions are assigned to a role based on the required functionality necessary to complete the job responsibilities for a given role. A role is the lowest level of security that can be granted to a user. A user may be granted/assigned to more than one role. Position A position is a logical grouping of roles that relate to a defined organizational position within Houghton Mifflin. For example, the position of the corporate A/P Clerk may consist of the roles A/P Clerk, Monthly Payables Review, and Corporate PO Review. The position provides a logical grouping for assigning all of the necessary roles that a user requires for their job responsibilities. A user should only be assigned one position. Functional user User that is involved in the configuration and/or development of the SAP project - Example: configurators of PA/PD team End user Production user Example: Accounts Payable Clerk

Appendix G UNIX / Oracle Considerations

Recommendations
The UNIX passwords should not include any of the following: employee names, employee spouses or children's names, coworkers names, operating system names, computer host names, phone numbers, license plate numbers, social security numbers, birthdays, words such as wizard, guru, etc., user names, locations, proper nouns, passwords of all the same letter, or keyboard patterns (qwerty). The SAP Security Administrator/s should create a list of all UNIX default accounts (such as bin, lib, uucp, and news). These passwords should also be changed. Passwords should be a length of at least 6 characters. Only Basis team members should know the passwords and have authorization to call external tools needed for monitoring UNIX functions (transaction STUN). Because SAP communicates with UNIX, only a select group of SAP end users, the Systems Administrator and a backup person should have a user ID on UNIX. SAP end users with a user ID on UNIX will have ftp access only. The Root password should be used in emergencies only. All user accounts should have unique passwords (no guests). Physical security of the SAP computer hardware should be enforced. The hardware should be stored in a locked room, with access to authorized individuals only. Cleaning staff should not have access to the room. No flammables should be stored in the room where the computer hardware is stored. ORACLE security should be investigated by reviewing the Database Parameters set up for SAP. Procedures for database and data file backups will assist in securing data. Backup procedures are covered in the Operations Manual in the computer room. Potential Security Risks in UNIX The following properties of the UNIX operating system can be misused: SUID/SGID The SUID/SGID property grants extended privileges to programs that exceed the privileges possessed by the User. Every UNIX system contains a large number of these programs for administrative purposes. Often these system

programs contain errors that unauthorized Users may be able to take advantage of in order to assign new access rights to themselves. The Password File: passwd If an intruder gains access to the UNIX password file (passwd), password information can be revealed by running password decoding programs on the encrypted passwords in the file. The security of the password file can be improved by the use of a shadow password file that restricts access to the encoded passwords to the Root User only. Yellow Pages (Network Information System) The Yellow Pages network information service entails a certain security risk. The NIS service (Network Information System) can be used to centrally manage User data and passwords. Each UNIX machine in a local area network is allowed to read the password file (including shadow password files) using the ypcat passwd command. On some platforms, an intruder can also replace the password file with a manipulated password using the NIS transmission protocol. Network File System (NFS) The NFS service is frequently used in the environment to enable transport and work directories to be accessible over the network. The authentication procedure is based on network addresses. Therefore, an intruder could gain access by using counterfeit network addresses (IP Spoofing). Caution should therefore be taken when assigning write authorization for NFS paths. The distribution of the HOME directories of Users across NFS should be avoided. BSD Remote Services rlogin and remsh The BSD rlogin and remsh services are used during logon to analyze the $HOME/.rhosts files. If either of these files contains the name or the address of the output host or a wild-card character (+), then a User can log on without supplying a password.

Protected SAP Directory Structures Under UNIX

For security reasons, the entire System together with the User data is stored in a special directory structure in the operating system. The directory structure is

protected with defined access authorizations. Directories that contain SAP data must not be exported to arbitrary recipients using the NFS. The directories should be exported to secure and authenticated systems only. The minimum requirements for maintaining secure directory structures are: Competent system administration. Anyone who can log in as the Root User has essentially unrestricted access to all of the SAP data on any of the currently mounted hard disks. The Root User can view and change this data, regardless of the local access rights settings. A reliable network connection. Anyone who has expert knowledge and access to the network can deceive NFS. At a minimum, protect the following users: root, <SID>adm and <DB><SID>. The "r" commands (rlogin, rsh, remsh, etc.) should not be used because they significantly weaken security. The latest release of the operating system software should always be installed in order to facilitate the rapid resolution of security problems associated with the operating system.

Appendix H Additional Security Monitoring Reports / Programs

The following are additional reports, which may be executed as needed, to monitor security. Reports should be executed using transaction SE38.

Program Name RSUSR000 RSUSR005 RSUSR008 RSUSR009 RSUSR020 RSUSR030 RSUSR050

RSUSR060 RSUSR070 RSUSR406 RSUSR998 RSM04000 RSM51000 RHAUTH00

Description Lists the active users logged on to the entire system. Analyzes all users defined to the system for critical authorizations This is transaction SU98, provides analysis of critical transaction combinations. Transaction SU96, allows analysis of critical combinations of authorizations Complex selection criteria based on profile Complex selection criteria based on authorization Compare tool. Compares two users to see difference and similarities in which transactions can be executed. Where-used selection , profiles only Complex search on activity group only Re-generate SAP_ALL profiles Information System Reporting Tree List of active users logged on to all clients in the system List of Servers defined to the current system List by User, all the objects that user has assigned to them based on Object Classes

Sensitive Security Monitoring Programs

The following are programs can be used for additional security administration activities but with extreme caution. These programs will directly impact the SAP Profile Generator and could cause security integrity problems between clients. Extreme caution should be used when executing any of these programs.

Program Name RSUSR303 RSUSR304 RSUSR400 RSUSR402 RSUSR403 RSUSR404 RSUSR408 RHPROFL0 RHAUTHUP1 Description Copies table TSTCA to TSTCA_C and populate TSTCA with S_TCODE. Copies the data in table TSTCA_C back into TSTCA and replaces S_TCODE Tests the environment checks for SAP systems Write special user data to sequential file. Assigns the profile S_A.CPIC to the user SAPCPIC Converts the Basis development Converts the data in USOBX-OKFLAG for upgrade tools (SU260 Program to generate user authorizations and activity groups. Performs user master comparison for activity groups. SAP recommends using transaction PFUD Actual master data comparison used within the HR module Performs system check

RHAUTHUPD RHCECK0

NOTE: The information pertaining to monitoring activities and additional programs will be periodically updated to reflect new releases of SAP and new functionality per OSS notes. PAGE 51 DRAFT DRAFT
2004 Houghton Mifflin Reproduction without prior written permission is prohibited.

DRAFT

2004 Houghton Mifflin LLP Reproduction without prior written permission is prohibited.

SAP SECURITY ADMINISTRATION POLICIES AND PROCEDURES