Solving accountability problems in warehouse environment:
In many work environments multiple users share or switch between different computers. If anything is not accounted for, the first user that logged into any of the PCs, will be blamed and held responsible.
By realtime North America
bioLock checks the SAP User ID to uniquely identify the Actual User
THE CHALLENGE
In many work environments multiple users share or switch between different computers. Examples could be a bank (teller), insurance, customer service counter, production, hospital, research and basically any internal department. This case study outlines the challenge in a warehouse where different workers confirm inbound deliveries, book outbound deliveries, create transfer orders, file reports, check out parts, etc. They are supposed to log in using their own SAP USER before every task and then exit out of the SAP system after their task is finished.
This type of process is very inconvenient, decreases productivity and costs companies a lot of money. Normally, the first user “Joe” logs into the SAP system in the morning and then his colleagues use his SAP user profile (“Joe” all day to perform their tasks in the SAP system. It is very likely that they even switch between multiple PCs and choose the one that is closest to them. If anything is not accounted for, “Joe” or the first user that logged into any of the PCs, will be blamed and held responsible. There is no accountability and, therefore, a much greater possibility for “human error”
THE SOLUTION
realtime’s bioLock will control access and accountability to any of your PCs via biometrics, increase productivity and save you money at the same time.
(Figure 1.)
Step 1.
The SAP Administrator creates generic SAP Users for any of the used workstations. In our example, we used 3 computers and have created the following 3 SAP IDs: “Warehousepc1”, “warehousepc2” and “Warehousepc3”. Please note that we could also use existing SAP IDs (like Joe, Thomas or April), but this way will explain it better in our example and would make it more transparent for the auditor looking at the log file on a daily basis.
Step 2.
The biometric Administrator will assign biometric templates for any of the warehouse employees and assign their biometric template (BIS-USER below) to any of the participating SAP IDs that we have assigned in step one. In our example, we have assigned Amanda, April, Joe, John, Peter and Thomas to all of the 3 PCs (Warehouse SAP ID’s).
Please Note:
Amanda and April could only be assigned to PC1 while Joe and John are assigned to PC2 and Pete and Thomas can only use PC3. We have assigned all users to all PCs for greater flexibility and productivity.
(Figure 2.)
Step 3.
Now we need to define which tasks in the SAP System we want to protect with biometrics. The first one is obviously the logon to the SAP System, so we can clearly tell which person logged onto which PC at the beginning of the shift.
We have also protected the MB01 to show how later on two authorized individuals could only execute extremely sensitive functions.
The 4 main transactions that we have protected for the warehouse scenario are for logistics:
VL31N Create Inbound Delivery
VL01N Create Outbound Delivery
LT03 Create TO for Delivery
LT 21 Display Transfer Order
Please Note:
bioLock can not only protect transactions, but info types, fields and even field inputs: If an amount is less than a predefined value, no action is necessary, if it is over the predefined value (like US$10,000) biometric authentication is required. The biometric authentication could also be required on the execution level so we can prove who actually “hit the enter key”.
(Figure 3.)
Step 4.
At this point we need to enable the biometric user for any of the protected functions:
The easiest way would be to activate the system wide protection “global check” when the function is created.
This way, the function is protected for any SAP User ID within the SAP System. Since the bioLock technology sits on top of existing SAP security, this would even prevent the Administrator SAP ALL (SAP) to open up the protected HR Infotype 167 (below). The global protection makes a lot of sense for critical financial or HR applications, where we undoubtedly only want a few selected authorized users to have access and nobody else!
For our scenario, we might want the shift supervisor to be able to sit in his office and access the protected transactions without putting his finger on the sensor. Obviously, this is not recommended, but we wanted to point out the flexibility of the bioLock technology that will allow you to do this.
We individually assigned all 4 protected functions (105-108) to all 3 SAP IDs and enabled them for biometrics. Other SAP Users, as long as they have authorization based on their profile, would still be able to execute the same transactions even if they are not enrolled in the system with biometrics.
The system is set up and running in a few days and now bioLock offers complete protection and accountability for the entire warehouse team and their actions. It even protects them from erroneous accusations. Nobody can abuse the system anymore and blame another coworker! The log file below will clearly show who did what and protect both parties.
The first entry shows that user Neudenberger tried to log onto Warehouse PC1, and although he is an employee of the company and his biometric identity is known to the system, his attempt was declined -- due to the fact that his biometric template is not assigned to the SAP USER “WarehousePC1” (Figure 1.). The log file, that could be sorted or filtered for improved display, shows color-coded that Neudenberger was “not authorized for the function”.
Line 2 shows how Peter successfully logged on to “WarehousePC1” at 9:32 p.m. and “was recognized.” We can also see that John initially logged onto the Warehouse PC 2 and Thomas onto Warehouse PC 3 (Line 6 and 10). Normally, there would not be a need to log out of these PCs at all, other than to turn down the computer at the end of a workday.
While Peter, John and Thomas originally started working on the same PCs, you see at a later point that they are actually switching PCs. Line 17 shows that John is using PC3 to issue an outbound delivery and Peter is creating a transfer order on the same PC shortly after (Line 19). April and Amanda support the team on different PCs with different tasks.
(Figure 4.)
TWO INCIDENTS DURING THE SHIFT
At 9:36 p.m. an unsupervised truck driver tries to display a transfer order while he is waiting next to PC2. His request is rejected and unfortunately the system cannot identify the truck driver, since he is not enrolled in the system (Line 9).
At 9:40 p.m. Mike, from a different warehouse, tries to display a Transfer Order on our PC1. Even though he has full authorization in his warehouse, he is not able to display the Transfer Order in our warehouse. Obviously his biometric template is enrolled in the SAP system and the log file shows (Line 22) that Mike tried to display the transfer order on the Warehouse PC1 but was “not authorized for this function” on this specific computer.
DUAL CONFIRMATION GROUP OR TWO SIGNATURES ON A CHECK WITHIN SAP:
(Figure 5.)
As we have pointed out earlier, protection for any task can be customized with biometrics and or smart card for the ultimate dual authentication (Figure 2).
An additional customer request is to require two individuals to authenticate extremely critical tasks. We created a dual confirmation group for certain tasks, then assigned a “Confirmation Group Number” and a name “Receipt PurchaseOrd” to protect the transaction MB01. If multiple transactions would have to be protected with the same group, we could create a general group like “A003 Finance” and assign Joe and John to it and protect multiple individual transactions with the same group.
In this table we assign two or more people to any dual confirmation group. In our case Thomas and April to A002.
(Figure 6.)
The last step is to assign the group A002 to any individual SAP User and Function Number. We have linked the A002 to our Warehouse PC1 specifically to protect the function 008 (MB01).
(Figure 7.)
Thomas executes the MB01 and after authenticating the request with his finger a window pops up requesting a second user from the group (April) to confirm Thomas’ request. The log file above clearly shows that Thomas requested (Line 24 and April confirmed the task (Line 25).
For more information, please send your e-mails to swm@infothe.com.
ⓒ2007 www.SecurityWorldMag.com. All rights reserved.
|
