Topic
4 replies Latest Post - ‏2012-04-25T08:21:54Z by SystemAdmin
MattiP
MattiP
2 Posts
ACCEPTED ANSWER

Pinned topic Using a Tuple in Policies

‏2012-04-11T07:36:42Z |
Hi,

Can anyone provide details on how a 5-tuple group works in a Guardium v8.01 policy for determine traffic to log from STAPs? Specifically:

  • are wildcards supported in the attribute members
  • is the order of attribute members significant i.e. does Client IP always need to be attribute #1, Source Program Attribute 2 etc
  • Why you can’t do a three-way tuple in a policy?

Thank you in advance.
Updated on 2012-04-25T08:21:54Z at 2012-04-25T08:21:54Z by SystemAdmin
  • SystemAdmin
    SystemAdmin
    483 Posts
    ACCEPTED ANSWER

    Re: Using a Tuple in Policies

    ‏2012-04-11T17:17:48Z  in response to MattiP
    Hi,

    If I could ask, what traffic do you want to log? If you can tell me your goal, then I could probably tell you how to configure the policy to log/ignore that specific traffic. For example, here's an example policy rule

    Server IP 10.10.10.10/255.255.255.255 (just match this server IP)
    client IP where you select a Group (1.1.1.1, 2.2.2.2) and (NOT)
    Object - %creditcard (match anything ending in creditcard)
    Command - Group (DML COmmands)
    Action - Log full Details
    In this rule, if the traffic is:
    • going to the Server IP (10.10.10.10),
    • and the client IP is NOT from an authorized application server of 1.1.1.1 or 2.2.2.2 which is in a group. This means every other IP but 1.1.1.1 or 2.2.2.2
    • and the object matches "creditcard", "joe.creditcard", "aacreditcard", etc
    • and the SQL Command is a DML command (insert, update, delete, truncate, etc)

    then log full details on this action so that you know what unauthorized user has modified the contents of any creditcard table.

    The policies rules can be very granular so that you can capture or ignore specific traffic to meet your requirements. let me know if this helps.
    • MattiP
      MattiP
      2 Posts
      ACCEPTED ANSWER

      Re: Using a Tuple in Policies

      ‏2012-04-12T09:52:18Z  in response to SystemAdmin
      Hi Joe,

      I want to add a new rule to our existing policy that logs Full SQL when specific source programs are matched. One such source program is ISQL which is often used interactively by individuals to access a database. We want to capture this traffic when it is used by individuals. However, ISQL is often embedded into applications, and for practical reasons we don’t want to log this traffic (volumes too large). So in summary, log the traffic when its used by an individual, ignore when used by an application.

      I could create rules to ‘ignore STAP session’ for particular application server IP to database IP combinations where the program is ISQL, however my problem is that there are hundreds of these combinations and therefore would result in hundreds of rules. Someone from IBM suggested that the Tuple feature (see Tools-Group BuilderGroup Type: Client IP/Srv App/DB User/Server IP/Svc Name) is a good way of addressing this problem as it allows you to group particular source/destination/username/programs and then apply that group to a single rule.

      I tested the tuple and it worked, however as per my original question, without experimenting I don’t know if wild cards are supported in the attribute members, or if the order of attribute members in the tuple is significant. I checked the production documentation but couldn’t locate an answer there.

      Thank you for the response. If you can help regarding some of the details of how a tuple works then I’d be appreciative.
      • SystemAdmin
        SystemAdmin
        483 Posts
        ACCEPTED ANSWER

        Re: Using a Tuple in Policies

        ‏2012-04-16T18:45:02Z  in response to MattiP
        Hi Matti,

        In the 'Client IP/Src App./DB User/Server IP/Svc. Name' tuple from the policy, the attributes must be listed in the same order as the name (Client IP, Source App(program), DB User, Server IP, Service (instance) Name). You can use all 5 attributes or enter wildcards in the attributes.

        For example, you might only want to filter iSQL when it is making a very specific connection like, '*192.168.169.2+iSQL+FuntionalID01+192.168+169.2+Example*' but other connections might only require one or two of these attributes to trigger the rule - '*10.10.9.3+RMAN+backupUser+%+%*'.

        You can also use wildcards within an attribute. For example, '192.168.169.2+iSQL+%bill%+%+%' will trigger on a user connecting from 192.168.169.2 using iSQL with any user name contain bill (domain\bill, bill, billmanty).

        Thanks,
        Bill
    • SystemAdmin
      SystemAdmin
      483 Posts
      ACCEPTED ANSWER

      Re: Using a Tuple in Policies

      ‏2012-04-25T08:21:54Z  in response to SystemAdmin
      Hi Joe,

      I understand Guardium rules is based on AND concept.

      Based on your example, may I say that if based on the following case, the rule will not be trigger, right?

      1. From Client 1.1.1.1
      2. to Server 10.10.10.10
      3. Accessing %creditcard
      4. Perform DROP command
      regards,
      Teh