Xpandion's Guide to SAP Systems

Discover How Simple It Can Be To Manage a Role Catalog

giora@litesites.co.il (Yoav Michaeli) — Thu, 16 May 2013 14:01:07 +0000

One of your accounting clerks just left on maternity leave (congratulations to Sally). Another employee is replacing her and thus has the new responsibility of performing Invoice Reconciliation (good luck to John). To perform this task, John needs to open a new request in the portal for the proper authorization. Then he must browse through the business process list and select Invoice Reconciliation, add an explanation for the request and submit it. The financial top-user receives the request and approves/disapproves it. Upon approval, John is automatically assigned the required authorization role, and even receives and email indicating this.

Sounds too simple to be true? Not necessarily, that is if you have a well-planned role catalog in your company. Some of our customers have already managed this successfully and the scenario above is actually their business routine when it comes to allocating authorizations.

A role catalog is essentially a structured list of business processes including all the authorization roles that enable each process. Business processes and business roles are created by business analysts; and authorization roles by technical authorization consultants. Hence a role catalog enables end users to communicate easily with the technical authorization team, saving valuable time in the authorization-allocation process.

Learn what the basic elements of creating a role catalog are

The first step in creating a role catalog is to define the list of business processes in an organization. Remember that most of the authorization requests will now be handled by end users and will include the business role name instead of free text; therefore defining the business process list is of great significance. The list of business roles shouldn’t be too broad or too narrow; this way the amount of business roles is reasonable and easy to manage. If your list is very large (don’t panic), simply split it into areas such as Finance, Human Resources, and into sub-areas like Vendor/Master Data and Finance/Assets.

The next step is to define the activities in each business process and the authorization roles required for each activity. The authorization roles should be master roles, meaning they do not include company codes, plant numbers and other organizational objects; these will be added according to employees’ positions.

The final step is to define the required roles as sensitive, and then define the workflow of authorization request approvals for sensitive and non-sensitive roles. For example, if the role is sensitive you might want to demand additional approval from the security manager before the role is granted. Don’t forget to verify that there are no SoD (Segregation of Duties) conflicts in the roles, per each business process. If SoD conflicts exist, each user that requests this business process is sure to create an SoD violation.

Sit back and let your role catalog start rolling

Upon completing the role catalog, you can integrate it into your organizational portal and concentrate on managing it. Believe me, I know that defining the role catalog is not a simple process technically (and politically), yet once the role catalog is in place the focus is shifted from granting authorizations to managing business processes effectively. Well-built role catalogs enable organizations to automate authorization management, focus on what really needs attention and overall free up valuable time.

Are We Human or Are We Software

giora@litesites.co.il (Yoav Michaeli) — Tue, 07 May 2013 12:45:35 +0000

Does the following dialog ring a bell?

Auditor:	How in the world was activity FS02 (Change G/L Account) not marked as high risk?!
Risk Manager:	Well… it was marked… but then John told me to remove it…
Auditor:	Can you show me the email from John?
Risk Manager:	Well… it should be here somewhere… let me try and find it…

How about this one?

Auditor:	How in the world is the activity Create Vendor not included in Vendor-Master group?
Risk Manager:	Well… it was included, but I took it out because you told me to…
Auditor:	Me? Can’t be!

If these types of conversations sound familiar to you, you’re not alone. Across the globe, employees perform actions without documenting them. Then, when asked about the change (which apparently wasn’t supposed to be made…) they simply don’t remember or can’t find the appropriate evidence. This is definitely not ok when dealing with systems that can affect financial reports or other sensitive areas.

My advice?

If you want to put an end to conversations with your auditor that begin with “how in the world”; and if you wish to answer the auditor without having to mumble “well…”; then my advice to you is: do not make any change that can be questioned by the auditor without documenting it first.

Documentation should answer (at least) the following questions:

Who made the change?
When was the change made?
What was changed?
Why was the change made?
Who approved/required the change?

When your auditor arrives, be prepared with all the changes neatly and clearly documented. This way you will find required answers quickly and your auditor will trust you even more, as you have proven to reliably manage audit-related processes in your company.

Is your software sensitive?

This advice (do not make any change without documenting it first) also applies to software. Software tools that control important data or configurations should include a mechanism for recording user changes and documenting them for later inspection. In other words, sensitive software must include an audit-trail of any and all changes made to the software itself, including: recording of the change, the person who performed the change, the time of change and where the change was made.

Changes can be (and are) made to software. Here are some of my favorite examples (all true):

Removing an activity from being marked as sensitive.
Adding/removing an activity to/from an activity group.
Approving a Segregation of Duties conflict.
Setting a Segregation of Duties rule as inactive.

The more automated the software is in documenting changes, the less unanswered questions are left for your auditor. This equation will keep both you and your auditor confident and happy.

Do You Know What to Do In Case of an Emergency?

dror.aviv@xpandion.com (Dror Aviv) — Tue, 30 Apr 2013 14:59:13 +0000

Emergencies happen. Yes, even in businesses. The ones I’m referring to are related to work processes and ERP security. Ok, so it’s not a fire or flood; still any business must be able to handle operational emergencies quickly and effectively.

Emergencies of this sort can include resolving configuration changes, troubleshooting critical issues, or providing immediate assistance to business users. Solving these problems is done in the production environment, usually by the IT team (system administrators, programmers, training staff, etc.).

So far you see no problem, right? Wrong. Accessing the production environment entails the following risks: fraud, misuse of authorizations and deficiency in audit reports. Although risky, timely and privileged access into production systems is essential for enabling an organization to operate smoothly and efficiently, at all times. In case of an urgent business requirement, a company needs to allow its IT team the flexibility around the production environment, as they must prevent, attend and manage critical issues then and there.

Let’s say that a financial implementer requires urgent access to the production environment in order to take care of a critical bug, which is preventing the Payment Run program to run properly (a very stressful situation indeed…). The financial implementer should be granted with the required authorizations to ensure that this situation is handled immediately and effectively. Nonetheless, while working in the production environment to fix the bug, a lot can happen, whether by mistake or on purpose…

How IT teams can support production systems without compromising security and control

The ideal solution for guaranteeing full control over production systems is setting an emergency access (sometimes referred to as IT access) process in place. Such a process defines the rules for privileged access in case of an emergency; specifically for users that are not supposed to enter the production environment on a regular basis, as well as business users required to handle ad-hoc issues.

Based on what I hear from customers, the best process should run more or less like this:

User requests access to the production environment and needs to provide a reason justifying the request.
Automated testing system determines whether the request for accessing the production system is justified. If the reason provided did not “pass the test” (meaning the user’s request is suspicious in comparison to the user’s regular behavioral profile) the request is directed to a security administrator for further inspection.
The request is automatically sent to the relevant manager for approval.
Upon approval the user’s account in the production system is unlocked, or a dedicated user name is provided, and a powerful role is assigned for enabling the prompt completion of the urgent task.

Wait, there’s more: to make sure things don’t go wrong from here, all activity in the production environment needs to be monitored continuously. What I mean by this is that every action taken in the production system is recorded (just in case the user was fooling around in there, or even made an innocent mistake). In addition, alerts should be sent if a sensitive activity was performed. After a defined amount of time the username is automatically locked and all extra authorizations – granted for the purpose of resolving the issue – are removed. Finally, and I really recommend this, a full report of all activities in the production environment should be generated, available to security managers for further inspection.

In a nutsell: emergency access is inevitable. Managing and controlling it is essential.

The Adventures of a Bored Programmer

giora@litesites.co.il (Yoav Michaeli) — Tue, 23 Apr 2013 19:58:49 +0000

What may be considered by a programmer as just playing around might end up as a security nightmare for a SAP® based enterprise. I actually want this to sound dramatic and grab your attention – I have dealt with the consequences of bored programmers' actions too many times...

Programmers are valuable assets to a company, yet bored programmers can be plain trouble.

I can reassure you that adventurous programmers initially intend to simply have some fun and stimulate their senses a bit, before going back to their real tasks. That being said, I can also assure you that what begins as an innocent harmless adventure, may not end happily ever after.

Fact: most programmers can easily take over an inactive user account. In fact, all it takes are just 3 moves. Let me lay out the general sequence of actions for you:

Step 1: Identify a dormant user account using T-Code: SE16 (Table Browser) and Browse Table: USR02 (Logon Data)

Step 2: Add SAP_ALL and Change Password and Unlock User T-Code: SU01 (Maintain User)

Step 3: Login as a new user – so all activities are now performed under another user's name

Now what, you ask? Well, according to our customers, salaries and invoices seem to interest programmers very much. So here are examples of what can happen next:

Example 1 – check how much you boss earns
Once a programmer has succeeded to login to the SAP system as a new user, viewing salaries is very simple:

T-Code: PA30 (Maintain HR Master Data)
Infotype: 0008 (Basic Pay), "Display"

Yes, most programmers are "shocked" to find out that their boss makes so much more money than they do.

Example 2 – discover company's highest invoices
Once in SAP, what harm would it do (ponders the programmer) if the details of the highest invoices are revealed? Retrieving this data is easy:

T-Code: SE16 (Table Browser), Browse table: BKPF_BSAD (Customer financial documents)
Document type = DZ (customer payment), Amount > 1,000,000

If the company is doing well (the programmer continues to ponder), why not ask for a raise, or let others know?

When things go too far

At times the innocent and harmless programmers get used to playing around and become bored once again. Sometimes they are tempted to take things even a step further (for their own personal – and wrongful – benefit). This time, their exploring around might end up in transferring money to the programmer's account instead of to the vendor's. Yes you are reading my thoughts correctly: fraud, security breach, etc.

I don't want to complicate things more; however do you remember that the programmer is using an actual legitimate account instead of his/her own? This means that these activities are practically untraceable, and even if eventually traced, so much time has surely gone by, that reacting to such incidents becomes painfully impossible and pointless.

In my previous post I promised to suggest an effective solution for adventurous programmers. So here we go:

Alerts Alerts Alerts!

Let's revisit the 3 moves in which a programmer can take over an account. Now, let's see how this can be prevented
step-by-step with the right alerts.

Step 1 can be prevented by receiving an alert if an employee made use of the following:

T-Code SE16 with table USR02 (Logon data)
Irregular use of T-Code SU01 (Change User)

Step 2 can be avoided if alerts are sent out for:

Usage of sensitive T-Code SU01 (Maintain User)
Adding high risk authorization profile SAP_ALL
Irregular behavior of user

Step 3 (if a programmer reached this step) can be stopped with alerts for:

Usage of sensitive T-Code: PA30 (HR Master Data)
Irregular behavior of user

Sophisticated and automated alerts ensure that taking over an inactive user account does not go unnoticed.

What about the invoices?
Alerts for the following:

Usage of sensitive T-Code SE16 (Table Browser) with sensitive tables: BKPF* (Financial Docs), etc.

Transferring money?!
There are many alerts for preventing an attempt to transfer money dishonestly, see a few examples:

Irregular activity of a user
Usage of sensitive T-Code: F110 (Payment Run)
Activating Debugging mode

Remember to stay alert
Smart, customized and real-time alerts are the key to implementing a proactive approach to security in any organization. Don't leave room for blunders. Even the best of programmers can go bored...

Visit again soon... I still owe you some insights on how to enable justified access to the production environment without compromising on security.

3 Standards Every Risk Manager Should Require From Developers

giora@litesites.co.il (Yoav Michaeli) — Fri, 12 Apr 2013 06:58:11 +0000

I recently held a conversation with a highly-experienced risk manager from one of our valued customers. As we were discussing the topic of development it dawned on me that this subject is often neglected by risk managers – despite the fact that development issues are a major potential for business risk.

What I mean by development are the codes added to the standard ERP package, including isolated own-developed programs and reports, user exits (term in SAP), enhancements and code snippets.

I must say it was a very productive discussion and I came out identifying the following key standards risk managers should require of developers.

1. Avoid Bad Coding in Production

Nothing good can come of bad coding. If your company has not yet defined appropriate programming standards, you may end up with mediocre coding. Bad coding calls for hackers and bored programmers (next week’s blog will convey the adventures and consequences of a bored programmer). Furthermore, bad coding easily increases the probability of mistakes even if just through normal use. Risk managers should insist on a well-managed process for transferring codes from the development environment to production systems, including testing (unit and functional) and code review.

In addition, make sure that every programmer and code-changer is obligated to comply with these standards. I’ve often seen senior programmers who transfer codes to the production environment on their own, bypassing the recommended procedures set in the company. Although these codes may be fine, a well-managed process means that procedures are followed by everyone, at all times.

2. Authorization Check for Enhanced Protection

An authorization check essentially serves as the gatekeeper protecting the system from unauthorized use (in SAP the ABAP command for this is AUTHORITY-CHECK). Hence, an authorization check should be added to any sensitive path in the program. For example when displaying the population, right before issuing an invoice in the code, prior to altering the database, etc.

Be prepared for justifications on the programmers’ side. They may excuse the lack of authorization checks by claiming that a program is private and should be used only once by a specific person. That being said, make sure to stick to the standard; authorization checks must always be added before a program is transferred to the productive environment.

3. Monitor Access to Production Systems

There are various reasons for why developers login to the production environment. Most of them are legitimate, such as checking performance of the codes, fixing bugs, etc. However, in many cases developers will not stop there. Furthermore, bored programmers are likely to start poking around looking for interesting information as invoice amounts, high salaries, and yes, you can definitely let your imagination take you from here.

Access to production systems should be granted if (and only if) there is a genuine reason for it. In any case, developers should be monitored while in the production environment in order to ensure ongoing security and control, as well as enabling future inspection if needed.

***

By ensuring that developers stick to these easy-to-follow norms, risk managers are certain to benefit from a significantly lower chance for risk alongside enhanced security throughout their organization.

Visit again next week to read about the full adventures of the bored programmer. I promise to also suggest an effective way to handle the “adventurous type” in a way that enables justified access to the production environment, yet ensures no breach in security.

If It Ain’t Broke, Don’t Fix It

dror.aviv@xpandion.com (Dror Aviv) — Thu, 28 Mar 2013 10:09:53 +0000

I, for one, feel confident when implementing new software on a client’s server or on our secured cloud; nonetheless I can’t necessarily say the same about the customer... Sometimes I feel that customers are a bit nervous when I’m around, especially when I ask questions about their SAP authorizations or SAP licensing contracts.

It’s not that they’re scared of me – after all I’m quite a nice guy – what customers fear is that their ERP system/s will slow down, or even stop working following the implementation of new software.

When I think about the severe consequences a business could experience if its ERP system malfunctioned in any way (and for any reason), I can’t say I blame those fearful customers. Imagine if you were in charge of the ERP system in your company and someone – inquiring about security or structure of authorizations – was in the process of implementing a newly purchased product. You too would be extremely cautious (and nervous) of any changes made to the system, no matter how amazing the product turned out to be. After all if an error causes the ERP system to stop, resulting for example in leaving trucks waiting for goods, your job would unfortunately be in danger. Now who would want to take responsibility for that?!

It seems to me as though clients always have the most persuasive argument for their fear. They logically explain to me that they need to consider what there is to gain and lose by implementing a new product. In their words: We need to carefully weigh the benefits of the product against the risk of unsuccessful changes resulting from the installation of the software. Again, if the person telling me this is also the person responsible for ERP, I can totally understand (and even agree) with this notion. This is why at Xpandion we are all in favor of the rule if it ain’t broke, don’t fix it. In other words, do not make changes to a client’s fully functional software, unless there is absolutely no other way.

Consider SAP for example: If you are implementing a product externally to SAP, there is no reason to think about how to overcome system changes as a result of the new software, since external installation means that no changes are made to SAP to begin with. Therefore, there would be nothing to fix. You get my point… I’ll move on now…

From day one, we have ensured that our software obeys this rule and does not require adding codes to SAP (in other words, there is no need for an ABAP Change Request). We also use known methods and designs so that end-users remain confident and stay in full control working with SAP, just as they did before.

Take my word, if you are implementing a product installed externally to SAP, there is no risk hovering over the SAP system and surely there is no reason for you to worry about your job… Furthermore, the implementation process of such external products is much simpler and faster; there is no need for SAP expertise, and ROI is exceptionally fast. You will end up saving time and money for your organization, alongside receiving compliments for a successful integration and implementation process. Can’t get much better than that!

Get Rid of Power Users Once and For All

dror.aviv@xpandion.com (Dror Aviv) — Thu, 14 Mar 2013 14:51:21 +0000

Organizations have Power Users in all systems (at least I have not yet come across an organization without them). Power Users hold a vast amount of authorizations, or even full authorizations in specific applications.

In most cases, Power Users are system administrators or employees holding senior positions in an organization. It is also very common that senior programmers, system analysts or project managers aim – and succeed – at obtaining full authorizations. Such Power Users tend to believe that they are above making mistakes and will never misuse their authorizations. Their need for wide authorizations is at times purely for work, such as IT employees claiming to save the company from a production bug and cannot therefore afford to be stopped by lack of authorizations.

You must be thinking to yourself that these IT employees have a point… Of course, production bugs must be fixed immediately; however handing out SAP_ALL to any “important” employee is not the point. I promise however to get back to this matter.

Never forget the auditor:

Auditors perceive Power Users as a major risk! And they provide their reasons:

First, believe it or not, auditors are not convinced that Power Users make no mistakes.
Second, Power Users are highly inclined to violate SoD (Segregation of Duties) combinations.
Third, if a hacker takes over a username with wide authorities, well no need to spell it out…

Make peace with your auditor:

There a few ways to keep your auditors satisfied.

1. Cheat a bit… this is the most common solution organizations choose to use. Instead of granting users with full authorizations (i.e. SAP_ALL in SAP systems) the IT team creates a module-oriented wide authorization profile, for example FI_ALL for all authorizations in FI module, HR_ALL for all the authorizations in HR, and so on. Then SAP_ALL is removed and replaced with the relevant profile. A more sophisticated way to “cheat” is by replacing the word ALL with WIDE, ALMOST_ALL, etc.

This solution is wrong for three main reasons:

It is not nice to cheat.
Auditors do not appreciate being outsmarted (it is actually becoming harder to do so in any case). Auditors have learnt to identify Power Users by the number of authorizations inside the role; hence changing the name of role is not longer sufficient.
Removing ALL from the a role name leads to more Power Users, since it becomes less frightening to grant wide authorizations as they no longer include SAP_ALL. From our observation, if you add up the numbers of employees with FI_ALL, MM_ALL, HR_ALL, etc. you get a number that is twice or even three times higher than the number of employees who previously held SAP_ALL!

2. Be strict – setting a strict policy across the organization is the best way to make your auditors happy, yet within the organization you will be liked a bit less…. Policies that declare nobody has SAP_ALL tend to remain in place only until after the audit. Somehow, there are always those employees (especially system administrators and senior IT people) that succeed in achieving their desired status of Power Users. Of course Power Users take management’s policies seriously, however they are also very successful in convincing management that wide authorizations is essential for running the business smoothly (and they kind of have a point… I know, I didn’t forget my promise and I will refer to this right below).

3. Narrow authorization according to actual behavior – this is the winning solution. No, I don’t mean for you to do this manually, that would be such a waste of time… (you would have to start by investigating last year’s log of activities per each Power User, uploading the data to Excel, removing un-required and/or duplicate authorizations, and then you could begin building authorization roles… yawn…). I suggest doing this efficiently. What you really need is a tool that can narrow user authorizations according to the user’s de-facto behavior, automatically. This tool would build a dedicated authorization role accordingly and replace the SAP_ALL with the dedicated authorization role. This would result in happy auditors alongside pleased employees, who could continue their business as usual without even noticing or being affected by the fact that they no longer have.

It’s really very simple: Dedicated authorization roles ready to replace SAP_ALL.

The Concept of Isolation

giora@litesites.co.il (Yoav Michaeli) — Thu, 28 Feb 2013 13:34:35 +0000

In order to manage a Segregation of Duties project successfully, it is essential that you eliminate business risk across your organization. To accomplish this you need to implement a comprehensive rule-set.

What is a rule-set?

A rule-set is an extended list of rules, each including business activities that should not be performed simultaneously by one person. Prohibiting a single person from performing a set of activities prevents potential situations of fraud. For example, the same person should not be permitted to open a new vendor and also pay the vendor.

Why? Because this may result in an employee opening a fake vendor and then paying that fake vendor, where the bank account to which the money is being transferred actually belongs to the employee himself/herself.

What happens after implementing a rule-set?

Upon applying a rule-set, each rule must be reviewed in order to identify users who can potentially perform forbidden combinations of activities. Such risky potentials need to be eliminated by removing related authorizations, accordingly.

What if a combination of activities is essential for business performance?
If in your organization the business decision requires the employee in charge of opening vendor accounts to also be the one responsible for paying vendors (which is a forbidden rule), you will need to apply compensating controls.

Example of forbidden combinations (rules), written in plain language ready to be uploaded to ProfileTailor Dynamics from Excel file.

What goes on in SAP?

In SAP systems the rules of business risks include activities (or T-Codes), authorization objects and values. For example, in order to implement the rule: a single user may not be authorized to perform Payment Proposal and Payment Run together, you must include T-Code F110 (Payment Run) and
T-Code FBZ0 (Payment Proposal) in a rule and then check who has the authorization to violate such rule. However when dealing with SAP, leaving this at the level of T-Codes is not enough, as each
T-Code operates differently depending on the values of different authorization objects. In this case, T-Code F110 and FBZ0 are highly dependent on the values of authorization objects F_REGU_BUK.

The following are possible values of field FBTCH in this authorization object: 02 Edit parameters, 03 Display parameters, 11 Execute proposal, 12 Edit proposal, 13 Display proposal, 14 Delete proposal, 15 Create payment medium proposal, 21 Execute payment run, 23 Display payment run, 24 Delete payment run payment data, 25 Create payment media of payment run, 26 Delete payment orders of payment run, 31 Print payment medium manually…. So, in fact the rule should be: T-Code F110 with object F_REGU_BUK, Field FBTCH and value 21 and T-Code FBZ0, object F_REGU_BUK, Field FBTCH and value 11.

Hello! Are you still there? Did the above make any sense? Did it scare you away? No need to feel uncomfortable. Whatever takes place inside the SAP system is either too complex for most business users, or of no interest to them.

Most business users do not understand activities, authorizations objects and values. Furthermore, they have no interest in trying to make sense of them, since they must handle their own expertise-related tasks. It is for this reason that in most organizations GRC consultants (who understand SAP authorizations) define the rules for the users, tying them with a rule-set that they cannot change independently.

Putting the notion into motion

We believe that business users should define business rules, whereas technical people should handle technical issues. For this reason, we present you with the concept of isolation.

Integrated into ProfileTailor Dynamics, the concept of isolation means that each activity
(e.g. T-Code) has a different logical mode, which is technically defined by the combination of authorization objects, fields and values. Business users define the business rules only by using activities and modes, and technical people define the modes for each T-Code, dealing with authorization objects and values.

In order to shorten the technical process, we have already analyzed most of the SAP standard activities and pre-included approximately 60,000 different modes. Thus, in many cases there is no need for new modes to be defined by users at all, allowing them to focus on enhancing their business rules (also pre-loaded in ProfileTailor Dynamics).

The way we perceive things here at Xpandion, the concept of isolation literally cheers up business users; they understand the rules and have full ownership on them. In addition, they also can change the rules when business risks change without any assistance from external resources. Finally, instead of dealing with technical issues, business users are able to efficiently concentrate on the vital task of mitigating business risk and accomplishing Segregation of Duties throughout their organization.

How Responsible Are You?

giora@litesites.co.il (Yoav Michaeli) — Wed, 06 Feb 2013 08:02:31 +0000

When it comes to requesting and granting authorizations, I found that in many companies the process is performed manually – via email – as follows:

User sends email to IT requesting additional authorization to perform activity.
IT transfers request to relevant manager, who approves required authorization (at times without even inspecting the real intention of the request).
IT allocates the required authorization to user.

Check out the following case:

John from the finance department requests an additional authorization for the purpose of changing a vendor’s details.
Barbara from IT receives the request (which makes sense to her) and she grants John the required authorization.
John receives an email from Barbara informing him that he was granted the requested authorization.

John is very happy. The auditor is not.

What Upset the Auditor?

Flaws! Auditors do not like potential for flaws and misuse in the authorization request process.

First, the request was made by email and not via an automated workflow tool – the use of emails increases the chances of requests falling between the cracks.

Second, the process cannot be easily monitored and therefore is unlikely to improve accordingly.

Third, Barbara, who happens to be friendly with John, approved his request without further looking into the reason of the request. Even if John is totally honest, a hacker might pretend to be John, taking advantage of the fact that John is friendly with Barbara, and attempt to perform a fraud using John’s account.

Finally, the sensitivity rate of the request was not taken into account. If a request is for a sensitive activity (like changing vendor details) or entails a violation of SoD (Segregation of Duties) rules, at least one additional approval should be required, such as by the security team or SoD manager.

What Would Please the Auditor?

Responsibility! Auditors like a clear process with the right responsible owner. Clearly in this case, Barbara decided to grant a user an authorization based on a good feeling or friendship, and this is exactly what auditors do not like. We do not recommend that IT personnel be responsible for granting authorizations. The way we perceive things: business personnel should approve granting authorizations for business activities; IT should perform the task; security teams should monitor the task.

So what could and should have been performed differently? The process needs to be automated as much as possible, allowing further investigations when required.

I want to suggest the following alternative:

John requests additional authorization for changing a vendor’s details.
His direct manager approves the request.
A sensitivity check is performed, and since changing a vendor’s details is considered a sensitive activity, additional approval is required from the financial data owner.
A reasonability check (explained below) is performed, based on John’s business profile.
IT person in charge of the finance module chooses the required authorization.
A SoD check is performed; as John is able to open invoices changing vendor details, he is also violating a SoD rule. In such a case, additional approval is required from the risk assessment manager.
The system grants the required authorization to John and notifies him accordingly. Alternatively, the system opens a task for granting John the authorization, and IT closes it after updating John’s authorization status.

This process is fully automated and can be re-inspected anytime. This kind of process would surely please your auditors.

Reasonability Check

What is it and why should you perform it? A reasonability check is a unique technique for identifying potential business risk situations at a dynamic level. Basically, a set of tests and business rules are applied to determine whether a request for a specific authorization is reasonable or not. Even if one test fails (indicating that the authorization request is not reasonable), then additional approval is required by the security team.

Reasonability Checks – Examples

A user should request authorizations within the practical usage zone. If a user who normally executes financial activities asks for authorizations to perform activities in the arena of human resources, additional approval will be required.
Request for additional authorization should be submitted from the user’s regular computer. If a request was submitted from a totally different segment of computers (such as from a different branch of the company), this will demand another hierarchy of approval.

Remember, identifying risky situations is critical from fraud-detection point-of-view. Use a smart automated tool and keep your auditors happy.

Who Authorized It?!

giora@litesites.co.il (Yoav Michaeli) — Sun, 16 Dec 2012 08:33:00 +0000

Who authorized it is definitely the most asked question following a fraud event or leakage of information.

Although access to information is conducted and controlled through authorizations, this is not a flawless method, and mistakes can (and do) happen: Employees might change positions within the organization, yet remain with their previous authorizations; authorizations granted for specific timely tasks may be forgotten and never removed.

We all agree, mistakes happen – and when they do things may get complicated, leading to an investigation. Therefore, it is vital to be able to easily trace relevant approvers, while providing reason and justification for each and every case. A fraud investigation is not something to take lightly. My suggestion – be prepared!

Managing authorizations effectively involves the following processes:

Authorization request

Authorization review

Authorization Request

This is where the confusion starts… In most organizations the process of requesting and granting authorizations is performed via emails without any further documentation describing or justifying the process. A user sends an email to the helpdesk team, which will then require the approval from an authorization manager, and following approval the user is granted the requested authorization. Evading this process is easy; and often misused by IT teams. The best way to avoid this is by implementing an automated tool that manages the authorization request process from beginning to end.

To obtain complete control over the authorization request process, the following capabilities are needed: (1) multi-system for enabling users to request authorizations for any system in the enterprise; (2) fully web-based for ease-of-use and simplicity (3) well documented steps for facilitating organization and auditors as one; (4) streamlined process, such as recommending best suited authorizations that are based on user-behavior profile; (5) integration with the costly GRC/SoD (Segregation of Duties) systems; (6) alerting system, immediately notifying if authorizations granted have bypassed standard process.

Authorization Review

From my experience, the most effective way to avoid wrong or improper authorization usage is conducting an Authorization Review process (which is obligatory for companies under SOX regulations). In this process all authorizations are re-certified by direct managers, followed by approval from senior managers. This ensures that no one holds unnecessary authorizations, in addition to all authorizations being revisited.

The manual process of reviewing authorizations is time consuming and a big burden on managers. To comply with regulations while controlling internal operations, an automated end-to-end tool is strongly recommended. To really simplify the authorization review process the following must be enabled: (1) different review selections with various filtering options, such as reviewing only risky authorizations, by roles, by position, and more; (2) full transparent system with clear documentation and complete history records; (3) web-based platform eliminating the need for spreadsheets, sending emails or chasing after employees; (4) advanced behavioral profiling analysis producing accurate decisions that are based on actual authorization usage.

Answering the Question

Integrated into ProfileTailor™ Dynamics suite, Authorization Request and Authorization Review successfully address the question: who authorized it. Managers simply need to select users and authorizations which they wish to inspect and view the list of previously granted approvals, together with dates and names. Moreover, auditors on their end, are able to view and examine the entire process at any given time, allowing managers to attend to their work peacefully and undisturbed.

Hooray! We Caught a Thief!

giora@litesites.co.il (Yoav Michaeli) — Tue, 02 Oct 2012 08:29:00 +0000

This is a true story from last week – an Xpandion expert received a phone call from one of our European clients, claiming they just received a High Risk Irregular Behavior alert pertaining to unauthorized access of salary information. After a quick investigation using ProfileTailor™ Dynamics, it was clear that something “fishy” was going on and actions had to be taken accordingly.

Some background details:

Irregular Behavior means that an employee (let’s call him John Smith) is using an activity, which is not part of his profile of activities. The profile of activities is created by ProfileTailor Dynamics according to a user’s de-facto usage.

The Data – in this case it was Display Access to infotype 0008 (payroll information) in Human Resources module of SAP®, which is marked as very sensitive.

A High Risk alert type means that the event’s scoring was climbing high, due to irregular and sensitive activities.

The client was advised to locate the exact physical IP address that John Smith was using, and sure enough John Smith was found using previous authorizations, which he no longer should have been using.

How did this happen?

John Smith had just been transferred from one of the payroll teams, where he held authorizations for viewing payrolls. However, when ProfileTailor Dynamics identified that John Smith had left his current position and was moved to a new one – his previously learnt profile was cleared, so that any prior activities would not influence the new business profile in his new position.

So now what?

Two actions were taken, right away:

First, John Smith’s actions were dealt with accordingly, and the incident was communicated internally so that all employees were aware and would beware... The global CISO explained to us that this incident vividly showed the effectiveness of ProfileTailor Dynamics, and the level of security within the company has never been better.

Second, an authorization review process was conducted using ProfileTailor Dynamics, in which all managers were asked to re-approve their employees’ sensitive authorizations. This complicated-sounding process becomes simple and straightforward with ProfileTailor Dynamics, and most important, highly effective. In addition to automating and shortening the review process, unnecessary authorizations were identified and removed, saving money and further increasing security.

CISOs, Internal Auditors, Security & Risk Managers – if you relate to this story in any way, take a closer look at ProfileTailor Dynamics. Learn from John Smith. Let Xpandion help you achieve full control over SAP usage from an application-security point of view.

Control GRC and Segregation of Duties in your Organization – It’s your Duty!

giora@litesites.co.il (Yoav Michaeli) — Wed, 19 Sep 2012 08:26:00 +0000

Companies of all kinds and sizes are focusing more and more on finding the most adequate GRC (Governance, Risk, and Compliance) and SoD (Segregations of Duties) solutions.

Why? Failure to comply with GRC and SoD requirements can affect a business severely.

SoD basically means ensuring that more than one person is required for completing a task within an organization. Today, companies understand the critical role SoD plays. Specifically, when dealing with money and sensitive information, SoD has become a key factor for gaining control and confidence in a business environment, as well as in assisting companies to successfully pass audit inspections. By complying with SoD rules an organization reduces the likelihood of fraud, significantly.

Since you and everyone else already know all this, you are probably wondering whether you will actually benefit from any new information. The answer is YES, of course, so to find out what is new, enjoy reading the rest of the blog…

Did you ever ask yourself what is the point of authorizing an employee to perform actions x, y and z, when that employee never actually uses such combination of authorizations? Authorizations are not free. They require monitoring and maintenance. Excessive authorizations merely floating around the company inevitably entail greater risk and unnecessary expenses.

What can you do?

Xpandion values its customers’ point of view. We like it when our customers enjoy our products. That’s why we offer ProfileTailor Dynamics GRC. You could use it as well.

What’s so special about it?

ProfileTailor Dynamics GRC identifies any SoD violations not only on a static level (the authorizations granted to users), but also on the dynamic level (as a compensating control). Essentially, the actual usage behavior of each and every SAP user is monitored in real time; all the time.

How does it work?

Only if and when a user performs actions x, y, and z, an alert is sent; and only then the need to allocate the resources for further inspection arises. There really is no need to check user actions based on theoretical authorizations on a regular basis.

Why does it matter?

Because customers using ProfileTailor Dynamics GRC are able to complete their entire SoD project successfully in just one month!

We have (painfully) witnessed organizations handling SoD projects (and there’s really no better word to describe this) in a “primitive” way. This project can take a year (!). The organization checks user after user in an attempt to determine who needs authorization/s and which of the authorization/s are really needed. Did I already mention that this process can carry on for a whole year?! I know it’s hard to believe. The first step of such a project: Import a set of rules or build a new set of rules based on best practice of about 10,000 rules. Then, the relevant rules for the company are determined. Let’s say 2,000 rules were selected; to this all the customer-development own objects need to be added; finally, you now have a set of rules suitable for the organization.

Second step: Initial running of the rules on the users will show that in an average organization there are about 900,000 violations (anyone with SAP_ALL or similar authorization violates all the rules). With 900,000 violations, you now need to check each and every violating employee, one after the other; set up a meeting, investigate and then analyze. This is a long, tedious and exhausting project. The average time for understanding a current situation of a company is – and I cannot stress this enough – a whole year. Don’t forget that after these steps are completed, you still need to provide recommendations and implement.

[Side note: Suppose only 20 users are violating rules. Do the math: 1000 rules, 20 users with SAP_ALL, that alone already adds up to 20,000 violations.]

What is the solution?

Applying dynamic SoD makes a difference. You can try it before beginning your SoD project the old way. Save meeting the users to begin with, in 95% of the times. How? Upload all rules to see what each and every employee is authorized to perform, and then dismiss all employees that have never used their authorization/s in the past year.

With ProfileTailor Dynamics GRC, if an employee is authorized to maintain a supplier account (SAP T-Code XK02), yet does not use it, the activity can be modified to XK03 (which allows display and not open), thus immediately that employee’s actions will not be defined as a violation. At the same time, if an employee really needs to perform a violation, a compensating control technique is then implemented (checking up on what the employee is really doing).

Keep a proactive approach and stay in control with ProfileTailor Dynamics GRC.

Optimize Licensing Costs. Increase Security

giora@litesites.co.il (Yoav Michaeli) — Fri, 15 Apr 2011 08:24:00 +0000

Increased licensing costs. Security. Breaches. Hackers. Budget cuts. Downsizing.

These are amongst some of the most worrying words that enterprises and managers can hear. And, yet, they are a part of day to day terminology- whether whispered behind soundproof board room doors, discussed openly by upper management or colleagues addressing them casually over the water cooler. Whether we like it or not, these issues are front and center, day in, day out.

In these difficult economic times, corporations have downsized staff; eliminated raises and bonuses for existing employees and have halted purchasing of equipment. As the hunt to find areas where corporate spending can still be cut, departments are fighting to reallocate costs to other departmental budgets or geographic locations.

But there are always options, aren't there? There is always one area everyone knows is costly but everyone skims over it. Business Applications like SAP and Oracle. Companies cannot run globally without them, but they are expensive and complex systems.

So why do enterprises quickly skim over and across this area? Because Business Applications are complicated to understand and to control. Most attempts at analyzing are costly, extremely time consuming and demand a lot of man power-and enterprises with less staff and less resources are scrambling and remain in the Catch 22 of it. Need to cut costs; to cut costs, need to expend a lot of resources to analyze; can’t use so many resources right now but need to cut costs….and so on and so on. A lot of confusion, pressure and frustration.

So, as a CIO, CISO, Authorization Manager, Security Manager or other top tier titan, what can YOU do to gain control, increase security, optimize licenses and decrease TCO, ASAP?

Gartner recently suggested, that when dealing with, for instance, SAP systems “Understand SAP’s business-oriented way to define usage and select the minimum usage for the majority of users.”

Most organizations have far too many users with too many authorized roles. How, as Gartner suggests, can a manager know how to select the minimum usage for the majority of users; How can the users themselves become more responsible and careful?

What strategy can management formulate in their enterprises in order to decrease costs without additional downsizing?, How can they optimize the resources on hand and reduce extraneous resources?

By taking back control over budgetary expenditures; By expanding their views over their business applications and reassessing actual usage; By taking stock of licensing types being paid for and determining how many are dormant, how many are unused and can easily be reallocated to other users in lieu of additional purchases; and how many licenses can be downgraded from the costliest Professional license and downgraded to Limited Professional or Employee licenses instead; By decreasing roles authorized to decrease risks. So much can be done, but there is so little time to get it done in.

Our ProfileTailor Suite of solutions-

-Tightens controls over user permissions in order to minimize granting excessive authorizations.

-Segregates which users need which designated roles streamlining and reducing risk of security breaches

-Seamlessly detects unnecessary licenses.

-Provides real-time security alerts

-Installation time- In most cases 1-2 days

-Disruption to Business Applications running- NONE. Our products run externally and in parallel to your systems.

-Impact- Immediate

-ROI-Immediate

9NYSG93SVPFF

Our entire suite of products work by reviewing and assessing actual usage, all in real-time.

How to Become a Successful Security/Authorization Manager

giora@litesites.co.il (Yoav Michaeli) — Thu, 10 Mar 2011 08:22:00 +0000

The more Security and SAP Licensing Managers that Xpandion works with, the more confirmation we receive that there is a distinct difference in the actions taken by successful managers vs. unsuccessful managers. Using ProfileTailor Dynamics/ LicenseAuditor these successful managers implement specific action items which are the only ones possible to increase ROI and decrease TCO in the world of SAP.

Part 1 - Immediate Impact Projects

No matter what company type, the underlying attitude that successful managers share is the focus on 'Immediate Impact' types of projects at the onset of their position. The most obvious and important example would be to assess and eliminate as many power users as possible throughout the organization. Using ProfileTailor Dynamics one can quickly and easily remove the “SAP_ALL” profile and create a dedicated authorization profile for each power user just by using a few clicks of a button. An alternate example would be to implement a more simple set of between 5-10 rules of (for example)-Segregation of Duties.

This type of task can easily be reduced to only 2 days worth of work and immediately position the Security/Authorization Manager as an initiator of successful projects resulting in reliability, increased security and an almost immediate budgetary impact. Upon completion- the ProfileTailor Dynamics system can track SoD violations immediately-That means any unusual behavior is reported via an alerts as it happens.

Part 2 - High Impact Low Risk

Successful managers try to leverage what they can from their resources. Let’s assume that the organization is using either SAP-HR or Active Directory to manage their employees. Using ProfileTailor Dynamics, managers can efficiently implement PTD’s built-in, ready-to-use workflow process for an authorization request. The immediate impact on the entire organization is to thoroughly reassess and streamline resources all the way up to Auditors and top-managers level. To put it in the simplest of terms, this project stands to save a potential of thousands of man hours over the course of the process.

Part 3 - Focus on the Money

Successful managers always focus on decreasing cost. In today’s climate, it’s impossible to overlook the financial impact and ROI (or lack thereof) from each project. Project must be initialized with the intent of decreasing TCO built in.

One increasingly important and often overlooked project in this all too important “Decrease TCO ” arena is simple. The necessary elimination of unused, dormant SAP accounts. To do this, the organization must reclassify their SAP licenses and reduce the numbers of roles in the organization – the main functionalities in ProfileTailor Dynamics/LicenseAuditor. Using this software, which is easily justifiable to management given the immense long term savings, offers the highest impact on ROI.

Immediate Decrease of TCO + Increasing ROI = Indispensable Manager

These projects are especially successful in SMEs as upper management in smaller and medium sized enterprises are much more involved in lower management level positions.

The CEO might see their Security/Authorization Manager every day. Because of this, the resulting impact of the 3 projects outlined above is much more visible to upper management. Since the actual implementation time is fast and the impact to the bottom line is practically instant, the Security/Authorization Manager is immediately able to show their value to the organization and in these tough economic times, showing your value by increasing the company's is priceless.

Concurrent Licenses

giora@litesites.co.il (Yoav Michaeli) — Mon, 24 Jan 2011 08:17:00 +0000

Although this topic may generate a lot of excitement among some of you – it's not a formal SAP licensing type (yet). However, it might make sense to consider it, since using LicenseAuditor, we often see organizations of 10,000+ SAP users with a daily average use of only 800 actual users - or less. These organizations have recently started to talk with us and SAP about licensing according to concurrent users.

What is licensing by concurrent users?

In this method of licensing, the organization is buying an amount of users who can work simultaneously. If the organization has bought X concurrent users, then, when the X+1 user tries to log-in, he or she will be turned off and will have to wait until another user logs out.
Each license based on this method would cost considerably more than licensing by named users. However, there will be significantly fewer licenses needed, so, it is a more "honest" approach, and it makes more sense to organizations. Furthermore, you would be able to support different SAP systems with different numbers of licenses for each system.
The idea is: "if you don't need a license, don't pay for it", especially when dealing with very expensive licenses.

SAP has been using "licensing by named users" for years. This model was developed to support SAP product development – from a single R/3 machine back in 1993 to a package-based named 'user licensing' in 2010. This method allows multiple usernames for each employee for use in multiple SAP systems, and 5-10 different types of licensing for each organization. Complex methods like this cause frustration among customers - and many organizations do not understand what they are paying for. They need a special tool to handle their SAP usernames.
In fact, organizations with more than 1,000 SAP users who use this method of licensing (and there's no other type,) MUST use a dedicated software program (for example, ProfileTailor LicenseAuditor) to control their licensing situation and reduce unused, underused and misclassified users.

I have recently been hearing about some "new winds" blowing inside SAP regarding new licensing models for very large enterprises -- I am proud that we support these trends and enable the possibility of concurrent users licensing in SAP.

What is your opinion - can SAP change its classic licensing model?

Office Space- A funny movie about hackers or a real life security threat?

giora@litesites.co.il (Yoav Michaeli) — Thu, 18 Nov 2010 08:15:00 +0000

Though most SAP programmers are reliable, serious professionals, there are a few who are intent on harming their organizations – and because of these few, we are rightfully afraid of the power of SAP Programmers. They almost always have a significant number of authorizations in the production system - and access to almost every part of the system.

Because of this clear threat, for the last few years I have been a strong advocate in pushing the idea that programmers shouldn't have access to production systems; they should only have access to DEV and QA systems - and if there’s a real bug in production – they can use a special username to perform a debugging for a limited time. Unfortunately, the idea was premature and I wasn't able to convince any of the organizations I worked with about the importance of segregation of duties and reduction of absolute power to any one user.

They always said that they trusted their programmers….mistake.

From my experience in the field, I see three types of potential risks from programmers in the SAP production system:

1. Risk of stealing sensitive data. The simplest way would be to use table browsing (SAP transaction SE16) to downloading all the required data to a disk-on-key/local file.

2. Risk of performing business processes on behalf of someone else. For example, transferring money to an account. A good programmer can change the name of the creator, so no one knows who really made the transfer.

3. Risk of transferring malicious codes - and by “malicious” here, I am not referring to a malignant virus, I am speaking from a business perspective. For example, when a purchase order from a customer is issued, and the amount is greater than $100K and I send an email so I can buy the stock. Another example is to take 1 cent from each money transfer and move it to a shadow account as in the movie ‘Office Space’.

While designing our product, ProfileTailor Dynamics, we’re currently focusing on dynamic security from a business perspective: Who accessed HR-sensitive data? Who attempted a money transfer even though it is not part of their usual day-to-day activity?

We just wonder why customers don’t seem to understand the security risk posed by a few bad seed programmer’s intent on causing harm.

When SAP® users get sleepy

giora@litesites.co.il (Yoav Michaeli) — Tue, 12 Oct 2010 08:12:00 +0000

“Dormant” SAP users

Some licensing-optimization tools for SAP, including ProfileTailor LicenseAuditor claim that they can identify “dormant user accounts”. Some customers don’t understand what this means and say – we identify dormant user accounts by ourselves – just look at table ‘USR02’ and see the “last logon date” – what more do I get from Xpandion?

To expand a bit about a “Dormant User Account” and share Xpandion’s view of this term, I want to emphasize how you can optimize your SAP licensing by finding lesser-used “dormant” user accounts.

One definition for “dormant” is: “marked by a suspension of activity, temporarily in abeyance yet capable of being activated” (Merriam-Webster Dictionary). In the common definition, a “dormant username” is a user who is inactive for a period of time, however still requires a username in SAP licensing. As SAP licensing is based on “named users”, each user, including the dormant ones, requires a named user. Therefore, eliminating dormant user accounts can free up many licenses.

Xpandion’s definition of a dormant user is more attached to the “field” itself rather than the textbook definition. In our concept, “Dormant Users” are both inactive users (e.g. the last login date is less than three months ago) however it also includes users with very low activity; for example, users that might use one report per month or logs into the system twice in two months. Those kinds of users are wasting SAP licenses, as they don’t really “use” the system as it was intended. Those kinds of users cannot be identified by the standard “last logon date” inspection, as their logon date is always too close. In order to identify them you must use usage-based methods, as used in LicenseAuditor.

When “dormant users” are identified by LicenseAuditor, the client should consider eliminating their username and offer an appropriate solution for their needs.

Customers choose different approaches to solve this challenge; For example, some customers replaced SAP functionality done by SAP GUI with the same functionality done by a portal page – thus reducing the level (and price) of the username involved. Another example by other customers is to designate a dedicated person (such as a department administrator) to produce the required report instead of the “dormant user” itself. Each customer must supply a solution to those “dormant users” after eliminating the usernames based on their flavor and concepts.