Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 0 subscribers
  • Views 6873 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DataControl.txt - what is logged and what not

QC

While replying top BopBop's post I found out that verbose logging does only log at least partially matched rules. Now we can assume that all rules are considered but some don't match for one reason or the other (if you think about it there's lots of work going on under the bonnet).

The problem I see is that you have no indication why some don't match and the more rules you have the more problematic it gets. I don't know the internals but I assume that the destination is checked first. The problem here is that you might miss a new destination (e.g. IE 9 or Firefox 4) as you don't get any information at all why the rules have not matched. Next are probably the exclusions and then type inclusions. Again you don't get any indication why a particular rule didn't match. Finally a content rule is not listed in the log if no expression matches. So I think the verbose log can help you to find out why a transfer has been blocked or only when there's at least a partial match in a content rule why it hasn't. Otherwise you're left in the dark.  

Or have I overlooked something?

Christian

:13067


This thread was automatically locked due to age.
Parents
  • 0

    Hello John,

    the cost of any additional performance overhead

    agreed, but as the logging level must be deliberately set on the client one is probably aware of the penalty when turning on verbose logging (although depending on the implementation the idle checks could cause significant overhead). 

    The log is IMO sufficient for testing CCLs as well as troubleshooting "false positives" but during "normal operation" you are probably more interested in (allegedly) false negatives and general audit. Verbose (or very verbose) logging should help you troubleshooting these whereas the normal log should ideally (I know, it has to be a trade-off) assure you that it is working as expected. At the risk of appearing nutty - I'd like the normal log to contain optionally  the items and their details for which Data Control rules have been appliedconsidered but not met. It could look like:

    Filename:    C:\Folder\File.ext
Filegroup:   Unknown
    Filetype:    Unknown
    Device:      n/a
Application: Firefox 4
    No rules matched

     or

    Filename:    C:\Folder\SomeOtherFile.pdf
Filegroup:   Document
Filetype:    PDF
Device:      Optical Drive
Application: n/a
No rules matched

     To clarify - either Device or Application must apply in order for these entries to be logged. In addition the rules (and perhaps CCLs) in effect should be dumped a startup and when the policy changes.

    What would be the benefit? First of all you are assured that Data Control hasn't failed to detect a transfer. Secondly you can use this information to check whether your "Allow and log" rules cover all the documents you are interested in. Thirdly it might make you aware that you've missed adding a newly available  destination (Firefox 4 is a recent example). 

    Probably a lot harder would be tracing why (e.g. file type not included, excluded by name) a particular rule did not match (apart from CCLs as this can't be reasonably logged). As currently a match triggers logging this would require another logging level. Guess I'll have to think a little bit more about the details.  

    BTW: It would be nice if the logging level (for all components) could be set from the console

    Christian

    :13379
Reply
  • 0

    Hello John,

    the cost of any additional performance overhead

    agreed, but as the logging level must be deliberately set on the client one is probably aware of the penalty when turning on verbose logging (although depending on the implementation the idle checks could cause significant overhead). 

    The log is IMO sufficient for testing CCLs as well as troubleshooting "false positives" but during "normal operation" you are probably more interested in (allegedly) false negatives and general audit. Verbose (or very verbose) logging should help you troubleshooting these whereas the normal log should ideally (I know, it has to be a trade-off) assure you that it is working as expected. At the risk of appearing nutty - I'd like the normal log to contain optionally  the items and their details for which Data Control rules have been appliedconsidered but not met. It could look like:

    Filename:    C:\Folder\File.ext
Filegroup:   Unknown
    Filetype:    Unknown
    Device:      n/a
Application: Firefox 4
    No rules matched

     or

    Filename:    C:\Folder\SomeOtherFile.pdf
Filegroup:   Document
Filetype:    PDF
Device:      Optical Drive
Application: n/a
No rules matched

     To clarify - either Device or Application must apply in order for these entries to be logged. In addition the rules (and perhaps CCLs) in effect should be dumped a startup and when the policy changes.

    What would be the benefit? First of all you are assured that Data Control hasn't failed to detect a transfer. Secondly you can use this information to check whether your "Allow and log" rules cover all the documents you are interested in. Thirdly it might make you aware that you've missed adding a newly available  destination (Firefox 4 is a recent example). 

    Probably a lot harder would be tracing why (e.g. file type not included, excluded by name) a particular rule did not match (apart from CCLs as this can't be reasonably logged). As currently a match triggers logging this would require another logging level. Guess I'll have to think a little bit more about the details.  

    BTW: It would be nice if the logging level (for all components) could be set from the console

    Christian

    :13379
Children
No Data
Unfiltered HTML