<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: CC 5.2. Does this rule work ? in Application Development and Automation Discussions</title>
    <link>https://community.sap.com/t5/application-development-and-automation-discussions/cc-5-2-does-this-rule-work/m-p/2135560#M449265</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;yes it can become risk at permission level also. Depend how u define risk&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Mon, 23 Apr 2007 18:00:55 GMT</pubDate>
    <dc:creator>Former Member</dc:creator>
    <dc:date>2007-04-23T18:00:55Z</dc:date>
    <item>
      <title>CC 5.2. Does this rule work ?</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/cc-5-2-does-this-rule-work/m-p/2135555#M449260</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Gd morning guys, i've currently created a rule but due to insufficient authorization i was not able to test it out in the relevant roles but i would like to hear your advise on this sample/simple setup.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I want to create a rule such that a User should not be allowed to create a UserID and delete them. Therefore I created a Risk with 2 functions;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;1. Create User. Objects include S_TCODE which is of course tcode 'Su01'. In addition, under S_USER_AUT, i granted 01 access which is to create User.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;2. Delete User. Objects include S_TCODE which is of course tcode 'Su01'. In addition, under S_USER_AUT, i granted 06 access which is to delete User.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;For this risk created, will 2 roles having the same t_code but different authoriation values, be flagged out as a risk?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Message was edited by: &lt;/P&gt;&lt;P&gt;        Koh Boon Leng Peter&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 12 Apr 2007 01:59:30 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/cc-5-2-does-this-rule-work/m-p/2135555#M449260</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-04-12T01:59:30Z</dc:date>
    </item>
    <item>
      <title>Re: CC 5.2. Does this rule work ?</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/cc-5-2-does-this-rule-work/m-p/2135556#M449261</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi Peter,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The fundamental SOD principle is:The user who "create" should not have authorizations to "delete".Here the T-code for both the creation and the deletion is the same.This violates SOD;as much as this,this amounts to risk and will be flagged as such [Risk].&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;From the SOD point of view it is the risk of access that counts and  is not with standing the authorizations values.&lt;/P&gt;&lt;P&gt;hope this helps.&lt;/P&gt;&lt;P&gt;Regards,&lt;/P&gt;&lt;P&gt;Ramesh.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 16 Apr 2007 15:51:09 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/cc-5-2-does-this-rule-work/m-p/2135556#M449261</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-04-16T15:51:09Z</dc:date>
    </item>
    <item>
      <title>Re: CC 5.2. Does this rule work ?</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/cc-5-2-does-this-rule-work/m-p/2135557#M449262</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi, thanks for the answer... it is at least correct at the transaction level&lt;/P&gt;&lt;P&gt;if the User has 2 of the same tcode access, the system will flag out as an SOD (at action level).&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Message was edited by: &lt;/P&gt;&lt;P&gt;        Peter&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 17 Apr 2007 07:23:21 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/cc-5-2-does-this-rule-work/m-p/2135557#M449262</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-04-17T07:23:21Z</dc:date>
    </item>
    <item>
      <title>Re: CC 5.2. Does this rule work ?</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/cc-5-2-does-this-rule-work/m-p/2135558#M449263</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Wouldn't be easier to create a critical permission that contained both of these authorizations? Then you could create a risk that contained this critical permission. It wouldn't flag as an SOD but it would show up or your critical permissions report&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 17 Apr 2007 12:12:11 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/cc-5-2-does-this-rule-work/m-p/2135558#M449263</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-04-17T12:12:11Z</dc:date>
    </item>
    <item>
      <title>Re: CC 5.2. Does this rule work ?</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/cc-5-2-does-this-rule-work/m-p/2135559#M449264</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Good point.&lt;/P&gt;&lt;P&gt;Normally in such cases,we use to insist for compensatory controls.&lt;/P&gt;&lt;P&gt;The "critical permissions' are given only based on satisfactory " compensatory controls".Once the risk is compensated,this is no more 'SOD" violation.This is why you will not get the "SOD" Flag.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 17 Apr 2007 12:57:18 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/cc-5-2-does-this-rule-work/m-p/2135559#M449264</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-04-17T12:57:18Z</dc:date>
    </item>
    <item>
      <title>Re: CC 5.2. Does this rule work ?</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/cc-5-2-does-this-rule-work/m-p/2135560#M449265</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;yes it can become risk at permission level also. Depend how u define risk&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 23 Apr 2007 18:00:55 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/cc-5-2-does-this-rule-work/m-p/2135560#M449265</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-04-23T18:00:55Z</dc:date>
    </item>
  </channel>
</rss>

