Surely 2014 was the year of simplicity with SAP's emphasis on simplification, simplicity, "Run simpler," or any of the variations on that theme trumpeted loudly and clearly at every SAP event and opportunity. This new emphasis seemed to be well received by customers, and why not? Who *wouldn't* want their SAP landscape to be simpler and easier to support and sustain? Security is no exception: doing more with less, squeezing a lean team harder to support more projects, more systems, and more users is just the given these days. Assuming that we start with at least a minimum number of well trained and competent SAP security staff, what does it take to simplify security to make it sustainable and bring about sustainable compliance? Here are some suggestions for your consideration.
Consistent security design
In my experience, there is not a "one size fits all" of security design except to say that sustainable results are more likely to be achieved with a consistent design. Are your security roles built using the derived role functionality, the enabler role model, or a haphazard mix of both? Is the design task-based, job-role based, or not clearly one or the other? If Business Role Management (BRM) is in use, is the model easy for the business users to understand? Is it your organization's practice that security roles have standalone integrity, or do some unknown number of them not fully functional unless some other functional role is assigned, which is not documented but "everyone in the plants knows that?" Are end user roles restricted from assignment to the SAP support team, or are exceptions frequent? Whatever approach the organization takes, taking it consistently and documenting it thoroughly will make your security much more sustainable in the long run, reducing the confusion among the people requesting access and the demands on the security resources to maintain and explain it.
Security design aligned with the business model
Whatever the basis of your security role designs, aligning the designs with the business is imperative for simplification. Otherwise, the requesters and role approvers will find themselves in an endless cycle of submitting requests to the security team for adding and removing roles from the users, and adding/ removing access from roles, in frustrating attempts to get the access levels just right. But what if the jobs are not defined in a consistent manner? Then there is really very little the security team can do until the HR function works with the business to review the job and task descriptions to improve the consistency.
Organizational standards
In my experience and observation, it is often the case that the organization's management wishes to have users' access restricted organizationally, often for compliance reasons. Whether the division is geographically based, product/service line based, data sensitivity based, or some other reason, sustainable security and compliance is much easier to achieve when the rules are documented, applied consistently, and enforced via automation. There is not much point in stating that users with access to one business unit should not have access to data of another business unit, when one functional area has a different idea from another of what organizational values represent each business unit, and end users are frequently granted roles from more than one functional area.
Furthermore, when the rules must be enforced manually, and approved exceptions are kept in a spreadsheet or file drawer instead of in a GRC toolset, compliance is anything but sustainable.
Governance model
So how does an organization that is lacking in any of these areas bring about the changes that are needed for sustainable security and compliance? In my experience, governance is the key. Role designs should not only be required to meet a documented standard, they should also be subject to periodic governance review. If role designs are any which way that the role owner and/or his/her business lead wish, if organizational standards are only a suggestion instead of a policy, if exceptions are numerous and monitored manually, the security team will find themselves in an endless cycle of role and user modifications, which can take so much time and effort that value-added proactive initiatives, such as automating the user access review or some of that manual monitoring, are forever on the back burner. Without a governance model that has teeth, the security team may find themselves the scapegoats for the breaches and non compliance that are almost inevitable.
I hope that some of these suggestions spark improvement ideas that help bring about simpler and more sustainable security and compliance in your SAP landscape. Are any such initiatives already in the works for 2015 at your organization or among your clients? I welcome your comments and observations. What did I miss that you have found to be key to sustainable security and compliance?
