[MUSIC PLAYING] Hello and welcome. My name is Abdullah Ahmed. I'm Senior Solutions Architect at One Identity. In this session, we will have a look at the integration capabilities between One Identity Manager and SAP GRC.
Here, we look to our agenda which topics we want to discuss. First, we will have integration capabilities between Identity Manager and SAP in general. Then we will start understanding the SAP GRC. The next step will be to see how the integration can be done between Identity Manager and GRC. And at the very end of that session, we will see a few use cases of step-by-step configuration of the GRE and Identity Manager.
So as you know, SAP software is, in general, by a lot of customers or by every customer the core of the business. And we have a certified SAP Connector since more than 20 years. So I think from the year 2003 we have a certified connector. Here on the left side, you see our Identity Manager with these main functions like Policy Engine, Workflow Engine, Risk Engine, and so on.
The right side, you see our certified ABAP Connector which has been certified by the SAP. We are able to connect with that certified ABAP connector to any ABAP-based on-prem system, and those on-prem systems, we have few examples of SAP HCM, SAP ERP, S/4HANNA On-Prem Business Intelligence, and so on.
We are also bringing in standard connectors for connecting to the SAP HANA DB. With custom integration capabilities, we are able to configure and connect to SAP GRC or to SAP NetViewer Application Server Java. Starling Connect platform is a SaaS application, and here, we have multiple standard connectors, especially for the cloud applications, like SuccessFactors, Concur, and SAP Litmos, and so on.
Using this SCIM interface, we are able to connect and configure also with the SAP Cloud Identity Services, which contains two main functions. One of them is the Identity Provisioning Service and the second one is Identity Authentication Service.
So with the IPS, we are able to provision to any SAP cloud type and application system. Our main focus will be, in this session, the integration between Identity Manager and SAP GRC.
Identity Manager contains a so-called GRC module, which is able and allow customers to loading, importing the GRC ruleset and configure them within the Identity Manager. This is usually used for cross-system or cross-application checks or rule definitions for SAP and non-SAP system. You're able to create critical functions within Identity Manager, but you can also import them from the GRC SoD matrix.
So, understanding SAP GRC, let's go to a few achieving business objects. While we are addressing risk. One of them is that the stakeholders demand high performance with high level of transparency. The regulations and enforcements are ever-changing and exponential growth of third-party relationships and risk is, of course, a management challenge.
So the cost of addressing risk is-- and requirements are spinning out of control, of course. And the impact is, of course, not always identified. The SAP GRC components are access control, process control, risk management and so on. We are focusing today on the access control and access control contains a few core functions.
One of them as the so-called ARA, which is the Access Risk Analysis. Then we have the EAM, which is the Emergency Access Management or firefighter. Then we have that so-called ARM module, which is for Access Request Management. And of course, the BRM as the Business Role Management. So we will today focusing within the access control, especially on the access risk and access request part.
The SAP account challenge or usually the complexity of authorization objects. A user can be assigned to either single or composite roles. And above single role, for example, contains transaction codes, authorization objects, authorization object values, fields, and so on.
And if a user has access to multiple SAP systems, it will be difficult for SAP team to get that overview. And especially if a user has also access to non-SAP systems that is more complex to get all those details from different user accounts to make sure the auditors get the data they are needed.
Our approach is using the so-called identity object, which means you have an employee and a real person, for example, and this employee has accounts in different systems like SAP Concur in the cloud or in SAP on-prem system, or maybe also a non-SAP system.
And with our capabilities, we are able to get all those risks together to report them to the SAP SoD officers or for the company and compliance officers.
So how can we integrate GRC with Identity Manager? We have different options to integrate GRE with Identity Manager. One of those options is using the GRC as workflow and provisioning engine. In that case, Identity Manager will create access requests within the GRC system, of course, based on assignments or order or requests.
The GRC will execute the approval workflows, executing the SoD checks, and if there is any kind of SoD conflict, that will be mitigated by the security officer within the GRC system. And the GRC is handling the provisioning into the backend systems.
The SAP GRC can be also used as workflow engine only. In that case, Identity Manager will create requests within the GRC. The approval workflow for the GRE will be executed within the GRC. Mitigation controls will be addressed there. But the provisioning of those assignments will be handled by Identity Manager.
Another option is using the GRC as so-called SoD info system. In that case, Identity Manager will create SoD checks, and those requests will be executed in GRC or in Identity Manager, and of course, the benefit is you're importing the GRC ruleset from the GRE and Identity Manager. We can configure rules which contains SAP GRC rule sets additional to that.
Also, additional objects from additional systems which is a non-SAP system-- for example, any group or file share, whatever. And the combination of SAP assess or risk combined with access to a file share or any group or something else, the combination maybe raise a risk.
So in that case, Identity Manager can, of course, then execute the workflow, getting the approval, and, of course, doing the mitigation controls, and starting the provisioning to the backend systems. There are also different options how the order of the steps can be for the integration and also which web service should be called when.
This is one of the options. In this example, a user is initiating a request in the web portal of Identity Manager. The compliance workflow will check and see if there is any, for example, other objects which should be checked or analyzed by GRC.
In that case, in web searches of the GRC will be executed out of the Identity Manager, and the GRC will send a result back. So in that result, it means is there a GRC risk violation or not?
In case there's no risk, the system can just start the provisioning of that assignment. In case there is a risk, which have been found out by that risk analysis or a simulation, then Identity Manager can create a GRC access request, that access request will be sent to the GRC via the GRC web services.
A GRC security officer will approve or mitigate that or maybe be decline it. In case he has approved, the provisioning can be handled by GRC access control themselves, or, of course, by Identity Manager. In case he has rejected that, again, the workflow can be done. Rejected, the request can be closed and the user will be then notified.
So, this is an example of if you're using GRE access control as information system, you're able to import the GRC rulesets to the Identity Manager. And these rule sets from the GRC can be used in the rules to make sure we can raise or find the risks between SAP and non-SAP systems.
The workflow can look like that or similar to that one. As you can see, we are using here, first of all, the workflow step compliance check. And if there's no risk, it's going to the manager approval, and if there's any kind of risk, that is going to the exception approval team. And after approvals, the assignment can be then executed.
From the end user perspective, the user can see in the workflow of the request and web portal that he has assigned or requested an [INAUDIBLE] that have been a risk. That risk has been handled by the security officer or he has mitigated that risk, and he has allowed the users to get that authorization for a certain time period. And the last step is here, that the manager of the user has also approved. So the provisioning is done.
Another example is using the access control SoD, approval workflow. In that case, first of all, we are performing a risk analysis in GRC by calling the GRC services from Identity Manager. We are only using the simulation function in GRC to make sure if our request is clean or not. And in case there's, again, no risk, it's going to manager approval, and in case there is a risk, it is going to the next step, creating or performing the next web service call and creating access request in GRC.
In that case, the SoD officers and the GRC team or the business owner, risk owner, they have to mitigate that request or, of course, decline that request. So in the GRC, once we are waiting for that, we can have an additional step, which can check regularly or frequently the result or the current status of that request.
And once that request has been closed, maybe it has been positively or negatively decided, then it can go to the next step and follow to the manager approval, or that request will be, of course, stopped and the system can then reject.
So from the workflow perspective of the end users, the end user can see that there was a GRC check. And that GRC check resulted in SoD conflict. We have used this standard SAP GRC web service in a custom process which we have triggered behind that workflow.
Once we found here the risk, we have, of course, triggered another function or another process which is using the standard workflow-- this one, the GRC Access Control User Access Web Service. And once we have executed that, the result was we have created an access request number here, which can be then also monitored or triggered.
So after waiting a time period or, of course, checking again and again the current status of that request, once that request has been closed, we will get the results. So the last web service here and the last step is exactly doing that. It's getting the request status from the GRC.
Getting that request status, we know, OK, if that request has been closed or this is still open, and if it's closed., It has been decided to approve or to decline that request. And we know, of course, which user has approved that request, for example. In our example, it is the GRC security here. You can see that.
So our recommendation is, of course, if you have SAP GRE or the SAP IAG, which is the successor of the GRC in the cloud, if you are already using that and it's in place, so please use that for access request, for role management, for firefighter processes, and for issue SoD analysis on roles.
The Identity Manager should be used for SAP user provisioning, for the SAP user role assignments, and, of course, the approval workflows within the Identity Manager for all those multi-step approvals like manager approval or system owner approval and so on. And of course, IDM should be also used for certification, recertification of users and role assignments.
So we always using, in this example, the web services of the GRC. Technically, it's also possible to use the RC-enabled function modules of the SAP GRC, but it is not recommended by SAP to use those function modules. For that reason, also please configure and use the web services to run the SoD the analysis during order assignment processes.
And optional, of course, we can import the rulesets from the GRE and Identity Manager and using them for additional steps of check with non-SAP systems, also called cross-system SoD analysis.
So now we are going to the step-by-step configuration. So first, we will see how GRC system can be used as information system. For that reason, we will download the SAP GRC access control rule set, executing the report GRC Access Control Download Rules. Then we will upload these GRC access control rule sets into Identity Manager. And of course, the last step will be performing SoD checks within Identity Manager.
So we are opening the ABAP SAP and SAP Logon and putting the transaction code as A38 or as E38. We have here the ABAP program execution, we have put it the name of the report there, and now we are selecting the certain ruleset, and your system usually you have multiple rule sets, and now you can-- should select one of them and put the target file, full pass where it should be saved.
And as you can see, the file selection part, you have nine files, like a business processes, functions, and the function permissions, and so on, and just give them those names, the full paths where they should be safe, and click to the Execute or F8 button, and that will be then, of course, exported. So, we can also go through those files once they have been downloaded and have a look at the content of those files.
So, once you have downloaded those files, the next step will be upload or import those files to the Identity Manager. For that reason, first of all, we have opened here the Manager tool and we can see that the subfunctions are empty currently here. So we are using the so-called Data Importer.
Of course, you can also use the Synchronization Editor, creating sync project to read those data from CSV or text files, but in that example, we are using Data Importer. We are selecting the first text file, which is done the business process. And from there, we are starting to import those data to Identity Manager.
So, we are picking here the business process as first file. We can here see which data are within that file, which encoding we can select, if we have an header line and not, and so on. So you see, we are letting everything here stand up, and we can here add a filter.
As you remember, we have different files. Maybe also a language-related columns. And here, you see the column number 2 is the language, and we want to import only English language data. For that reason, we are just adding here a filter on that column and starting to import that.
So here, you see the target table we are selecting, and the table we are currently, first of all, looking for is the SAP Function Category Table. And we are selecting the column that's in our example. Ident_SubFunctionCategory. We are using that as key column. And if necessary, we can also add additional columns or use them.
So we have selected the first and the third column. One of them as description, one of them as ident function. And let's start to import that. We can insert, update, and delete the entries, and of course, we can save our configuration or definition file in a local XML file, which can be done reused in the future for the same processes if it's necessary. So you don't need to do those steps again, you can just use those XML files to make the things very quick and simple.
So you see, I have here a name, business process to subfunction category, and I have a number there, I know which step it is. So as you can immediately see in the background, we have now an XML file created in the background, and here, we are waiting for the input of those data.
So in a few seconds, we will see that the input will begin. We have 303 lines and only 12 of them have been added. We are 12 because we have multiple languages there, and we have only set the filter to the language English. So, now we will see already we have not a function here, but if we are going to the basic configuration, we will see that all those 12 entries have been created as some subfunction categories. And we will see here are those 12 objects.
So we can click them. We can see we have a description there and the category name. That's our first step. And we will repeat those steps with different files until we have everything in the system. And again, once you have created those XML files, it is for you in the future very easy to reuse them.
So now we are importing this example, again, the business process, but this time as a functional area. That means we can reuse also the same file to create certain part of the objects or attributes within the Identity Manager.
So again, we are going for the English language here. We are putting a filter there. We are selecting the target table. And we are selecting, of course, also the columns where our data should be saved. And so we will repeat for all those nine files all those steps multiple times until we have all those XML files, and we will get the result, which should be done importing of the whole GRC ruleset in Identity Manager.
So again, our second step, another XML file. We can save again our definition file here. And giving them a name that we know in the future what's that. So that's the step number 2, for example. And we are importing the business process to function area.
So, again, the import will stop-- starting, and we will get 12 entries added to the system. And now, we are waiting to create the functional areas. So we will repeat that process again and again, but the end of the time, once we did all those process steps, we will see that we have all those data.
Now we are going to the function definitions. You see in the meantime, we have now imported all those nine files in a certain order, and now we have created the function definitions, we have the function categories.
The system has also now assigned-- or we have assigned the function instances to the function definitions, and we can here see the authorization objects which is part of the function definition. You see that's a very complex authorization object with different transaction codes, with different authorization objects, with different field values there, and all those stuff can be done there.
So in this example, everything is imported from the GRC ruleset. So if you're selecting here one of those function instances, we will see how many users in our system are affected by this instance and how many roles or groups and so on are also affected.
So we can see also if we found some rule violations which is new or do we have also exception approved for these rule violations. So everything is immediately in the system, and you see, we have standard reports that can be used.
So, now we have rule sets in Identity Manager, we have activated them. And in this example, the end user is going to the IT Shop of-- or to the web portal, selecting two ABAP rules, and want to submit that for approval.
So you can also check his shopping cart proactively to make sure if there is a compliance rule violation, maybe he can also decide to say, OK, one of those two assignments I don't need, or maybe he can upfront contact the colleagues to say, hey, I want to create an access request, but I will face an exception, but-- or an SoD conflict, and I need an exception approval from your side.
So if the end user perform that compliance check or not, the system-- as soon as the end user will submit that request, the system will immediately check the content of that request with this user, and if there is any compliance problem, the user will be informed, of course, but the compliance officers will be asked for exemption approval.
So here, we are now logging as a Kurt, which is one of those exception approvers, and he can decide if the user should get access to these [INAUDIBLE]. So he is also able to assign mitigation controls to that request if they are configured and available in the system.
And once they did that, he is also able to say, OK, the user cannot get access to that request for a long time. He should get access only for a few days or a few weeks because these requests may be very critical. After that period of validity, the system will immediately deprovision those assignments from the user or end user.
So, he is able to put his reason for approval, and once he is saving, the end user can, again, see in the workflow what's the current status of his request. You can see, the user Kurt has already-- has exception approver. He approved that request, but his reason is also a very critical combination.
So the next user in our workflow is the manager of the user, which is other Kurt that's called Jensen. The other was Kurt Olson. And now the second Kurt as manager will approve that request, and he is also able to put his reason also to see if the exception approver has approved and so on.
As soon as the manager has the last step of that workflow will decide and approve that request, the provisioning will immediately started, and the user will see that that request has been assigned to him. So on the job queue info, we will see that the processes for the provisioning will immediately start and the user will be assigned to those ABAP roles in the backend.
So let's go to the next example. So the next use case will be using the GRC Access Control as SoD Approval Engine. And here, we will learn how to configure access control SoD approval workflow step-by-step. First of all, we will test the GRC access control web services within Workbench, the so-called transaction SE80. Then we will configure the web services via the SOAMANAGER.
As transaction code, we will download the WSDL file, we will implement the web services in Designer, and create custom scripts to use the web services. And of course, as last part, we will create access request in Web Portal as end user, and it will show also the GRC access control user interfaces that GRC copied from the perspective of a GRC compliance officer.
So this is the GRC copied. A security officer has here logged in. He will create an access request. First of all, we will create an access request on behalf of another person manually, and we will repeat exactly these steps a few times from different point of our integration scenarios to make sure we are exactly always in this same certain step.
So, the aim is to create an access request for a user, and these access requests should contain an SoD conflict, and a GRC security officer should be then asked for mitigation control and approval.
So you see we have added here a user, we have added descriptions and so on. Now we are adding the ABAP roles. For that reason, we are selecting our system, which is connected to the GRC system. And we are searching for those ABAP roles and profiles which we want to assign to user. So we have selected now those two roles, and we will add, of course, additional user details like first name, last name, and email address, which is in the GRC access request.
Mandatory fields. The mandatory fields have to be, of course, fulfilled. And once we have added all those information, we can click to the Submit button and submit. So once we have submitted, an access request number-- we are starting here with the number 12-- is created.
So, we can go to the search the request and see the current instance status. So we are just putting here the number and searching for that. So, you see the number 12 have been found, and if you are clicking to the instance status, we see it is in approval process, and it's pending for the approval of the GRC security officer in the middle.
So, we will repeat that step now from the web server side to make sure we can exactly come to the same step. So for that reason, we are starting, first of all, with the above transaction SE80, which starts the above Workbench. We are going here for the repository information system, and, of course, under the Enterprise Services, we are clicking to the source definition, putting there a namespace, and searching for that.
So, the web service we are now using is the GRC access control user access web service, and we are picking here the Generate Request Template which creates an XML template which should be then filled with data. So, this is the template the system is generating for us, and we have, of course, to put at least all those mandatory values.
For that reason, we are clicking to the Edit of that editor and we can edit these XML file or change them or replace them. So we have click to the Edit mode and you see we have that XML. So, now we will put the XML data, which is necessary. You see, we have prepared an XML file with all those mandatory required data which contains the ABAP roles the system definition, and, of course, the user name, user first name, last name, email address, and so on.
So-- and we will raise that request on behalf of another person. So now we will execute it. And what we are waiting for is creating an access request, and that's the access request number 13. And we will go back again to-- or copy it and check if we have exactly created the same access request as we've done before with manual steps.
And if yes, we should have the same data there, we should have the same approval step there, and we are waiting for the same security officer to approve that.
So our next step will be the configuration of the web services. For that reason, we are calling the transaction code-- so a manager. And here, we are searching for the object namespace, GRCAC. And again, we are looking for our GRCAC access control user access, and if there is no web service configured, you can click to the Create Service. In that example, we have already created that.
And if you are going to the Edit mode, we will see all those details which we have added there. You see, we have a transport channel authentication of user ID and password, and all those other attributes are values or default, we have not changed here anything. So we just save it, and we can go and publish that.
So once we have published that, we have the so-called WSDL file, and you see here, again, a few parameters, which can be changed or configured. And then clicking to that button, we are getting the WSDL definition file. So this file has to be downloaded locally to be used for the Designer to create the web services for the GRC in Designer.
So, once we have downloaded this WSDL file, we have here the SoapUI to make sure we can test that web service from the outside of the GRC system. So we are adding that WSDL file to the SoapUI, and we're creating a new project there.
So, you see, we have not created that new project with all those requests. We have, again, here that request template, that XML structure, and we have to add the important entry data. You can see that the first three lines, they are additional to that one from the ABAP Workbench.
Just mentioned that if you're using-- or testing your own system, make sure that you're adding that Soap envelope body and envelope part, and of course, the beginning header line. So adding here the Basic Authentication method, again, we are using the GRC user. The GRC user is able to create access request on behalf of other persons. That's necessary to use that. And we have replaced the XML with our repaired one like before. You're just executing that and getting a result.
And if you're clicking to the XML, we see that our request has been successfully sent, that we have created an access request, and we received a number, which we can, again, search for that and see, we are exactly in the same step as before. So, now we from the outside of the GRC system, we are able to perform exactly the same steps as we did it at the very beginning manually. Again, we are waiting here for the GRC security officer to approve that request.
To implement the GRC web service within the Designer, we need the WSDL Excel file. For that reason, we are downloading the .NET Framework Developer Pack from Microsoft, and we install that in our system. So, once we have installed that, after the installation, we can search for the file, where it is saved or installed.
And the files we are looking for is the wsdl.exe and wsdl.exe config file. So we will take the last version of that, which we have now installed, and just copy that to a shorter path name because if the path name is long, maybe, in some cases, you will face an issue. So just, in my case, we have copied those two files in a shorter path name and we are using them in this session.
So, now we have the WSDL file, we will open that via a browser to make sure we are getting the absolute paths to that file from the browser perspective. So we're getting that URL to the local file, going to the Launchpad, and starting the web service.
Once we have clicked there, we will get that web service creation interface where we have to put our WSDL file URL. We can, from there, jump there to the WSDL file and selecting the necessary data. One of them is the service name, which we have to copy from the WSDL file, and put this file and the service name to the service definition here.
So again, the .NET namespace for the proxy connector should have the same name like the web service name. And, of course, we need the binding URL for this, so we copy also that one and put to the web service URL. So we have to select the service type.
In this example, it's the SOAP. And again, we have to provide a service user or a user who is able to create access requests on behalf of other persons, and here, we are, again, using our grcuser with his password, and then we can perform a test.
So, the name is grcuser, we are putting his password there. And for the proxy code generator, you can see, we have all of the wsdl.exe file there, but if it's empty, for example, you can just go to your folder and copy the full paths to your wsdl.exe file.
So once you copied that file name and edit there in the field, the next step will be to-- you have here extended capabilities if you're using proxy, but nevertheless, you can click them, do the check. And once you edit and check this and done, you will get this code auto-generated. This code can be used in your custom scripts to perform the web services and create all those data.
So you see, the system is also creating an example of a custom function for your custom script, which is importing the GRC user access control web service, which we have already now created. It is now instant sync them. And we can then using functions of those web services.
So, now we have implemented those web services and custom scripts and the custom scripts have been used in the processes, in the custom processes to perform those GRC services, and now a end user is going to the portal and raising an access request for approvals, which, again, will raise a conflict, an SoD conflict, but this time, we want to get those results from the GRC.
So, the user has now requested two ABAP roles, and he can go to the workflow and see, OK, something is in the background executing. The administrator can go to the job queue info, for example, and see there is an event has been fired, which is calling Perform GRC Access Control Risk Analysis, which is doing a simulation within the GRC system if that user will get some SoD risk.
And if yes, then the next step will be to firing another event, which will create an SoD-- or an access control request or an access request within the GRC system which have to be then approved within the GRC system. So here, we will see that we have created those access requests in the GRC system, and if you're switching to Manager or Designer, we can have a look into the workflow, and, of course, also to the process.
So here's the workflow. You see, we are executing an external approval step, which means we are performing that web service from the GRC. And in case we are getting an risk there, we will go to the next step and performing another web service called-- by firing that event from a workflow. And on the Designer side, we have the custom processes which they have as trigger exactly those events. And with those events, they can then perform additional web service calls.
So you see, we have, in the first step here, which is red, that SoD conflict, which will be followed if the user will get access to those two roles. That's a simulation of this-- after the simulation, we have sent-- or created the access requests, we have created the request number 22, in that example.
And again, we can go to the cockpit and search for that request, which is now coming directly from the Identity Manager system. And the GRC user can have a look at that request, for example and can decide to mitigate and approve that request or, of course, to decline.
So IDM will monitor the status of that request, and once it has been approved by a GRC team or declined, it can then continue the workflow or reject the request to the end user, send notification, and doing all those stuff. So we see, again, we are in the same step like the very beginning as we did it manually. So, the security officer should approve that request, and otherwise, we will just wait for that request until it has been declined or approved.
So, we have seen that in the Manager. We can also have a look. So that's that step. And going to the Designer, we will see, that's our custom processes for the GRC. You see, we have here an event which we are waiting for, and once this event is coming, we are performing different GRE web service calls, and the web service are called by the scripts which we have created.
And as parameter for those scripts, we are providing there a few values, which is relating to that request to the so-called person [INAUDIBLE] object, and to the person and to the shopping cart ID or order number to make sure we can collect all those data from the request or from the shopping cart order and send them then together.
So the last one is, of course, getting the approval step from the-- that approval status from the backend system from the GRE, and depending on that, following-- continuing the workflow.
Here, you see the name of the different functions we have created in our custom script to performing all those web services, to creating the simulation, creating access requests, getting the request number back once it has been created, and, of course, monitoring the status of request.
So in the meantime, we have approved that request in the backend, and if you are going to the workflow, we will see that the GRC security officer has approved that workflow, that SoD conflict. And the last approver in our example here is the manager of the current user, and the manager, he can get these access requests and decide if he will approve or not.
He will see all those GRC-related ticket number or request number. He can see the GRC officers have approved that request and so on. So he's adding the reason why he is deciding that request, and we will see that the provisioning to the backend system to the SAP systems will now immediately start, and the user will get authorization to those backend systems in a few seconds or minutes.
So, now we have seen the full integration capabilities how we can use the GRC access control as SoD Approval Engine for that reason. And so we have seen, first of all, the manual creation of access requests, then we did it the same with the web service within the ABAP Workbench, transaction SE80.
The next step was to creating the web services via the transaction code SOAMANAGER and publish them in the system. We have downloaded WSDL file. We have implemented after testing the SoapUI we have implemented the web services in Designer.
We have created custom scripts to perform those web services. And the last step was we have created access requests in web portal for end users, and we have seen that the system is immediately sending or creating access requests in GRC, performing SoD checks. If there is an SoD conflict, then SoD our security officer has to approve that request.
So-- and the very last step was that after the last step of the approval, the provisioning of the user and the ABAP role assignment has started to be provisioned in the backend system. So with that, we are now at the end of this session, and I thank you for your attention.
[MUSIC PLAYING]