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

Data Control Template

I am working on Data control policy and has been success full with all the  built in policy Sophos has. I can stop/ monitor any financial information . however some of the financial document are not detecting by Sophos.

For example our payroll system upload electronic checks  to different bank every other week.  It is a txt file they upload but instead of using straight routing number and account number they mix and match some digit  such as 72208500001901258980 first 3 digit could be which state bank is 722 and then routing number 085000019 and then account number 012589800.

Problem I think is when all this digit are combined, Sophos doesn’’’’t know what to do. I have been trying to use this link to create new template but not successful yet http://www.sophos.com/support/knowledgebase/article/112192.html

Does other Sophos member create and share template ?  We monitor network with Soiralwind NPM , in SOlarwind we share template with other member , could you do some thing  in Sophos so we can share  custom template ?

:20087


This thread was automatically locked due to age.
  • Hello BopBop,

    so you are looking for strings with exactly 21 digits (although your combined string has only 20, but I assume it is a typo)? <expression value="\b\d{21}\b" count="1" weight="1" /> will detect these and setting contentCondition triggerWeight="1" will trigger the rules when at least one such string is detected. Setting triggerWeight="2" will never trigger the rule though, as count="1" specifies that only one occurrence should be considered and thus triggerWeight can't reach the value 2.

    If you'd show us what you've got so far we might be able to help you finding out why it doesn't work as intended. Is a single occurrence of the string alone the only criterion or do you have additional identifiers?

    Christian

    :20105
  • Hi BopBop,

    The main issue here is that the default sets are conservative to prevent false positives.  To create some more targeted matches, creating your own template is definitely the way to go, and we encourage sharing these templates on this forum.

    To create your template, you'll first want to fine-tune your requirements.  Do your files always contain <bank id><routing number><account number>?  If so, then you've got your fixed number of digits as the first thing you want to match.  After that, you'll also want to restrict your matches to acceptable subsets of those numbers... for the bank IDs, you'll probably want a list to choose from; for US routing numbers, you'll want the next set of numbers to be limited to a legitimate routing number (four different prefix variations followed by any 7-digit number).  Then for the account number, you'll need to limit your set to numbers that are legit account numbers (which, unfortunately, might be just about anything).

    So, you'll probably be wanting something like (assuming # is a named number): <expression value="\b(?:722|###|###|###|###|###)(?: (?:<routing prefixes>)\d{7} )(?:\d{8,11})\b" count="1" weight="1" />

    Remember that \b matches on a word ending, and so will be as happy matching '.' as an end of line or a space.

    eg: 72208500001901258980 .4456 will match to the '.'  Removing the \b matches will enable you to match any numeric substring, which will increase FP risk while decreasing FN risk.

    Now you have a few options: you can customize a rule for each style of document you send out, or you can attempt to generalize it to cover all cases.  The second option will be harder to debug if something goes wrong, and have more false positives.

    If you don't want your templates to be available publicly, feel free to use the forum's message system to discuss your templates with other users privately.

    If you want to share more, I'm sure others on the forum would be willing you provide more suggestions.

    :20449
  • (I added a space between the two (?: (?: bits as it converts to a smiley otherwise... but the space will cause the match to fail [as it would match a literal space]).

    :20491
  • Thank you for your feedback . I think  there are some  problem with Anti Virus 10.0. Since upgrading to 10.0 we can’’’’t block any banking or credit card document. I opened a case with Sophos, they too can’’’’t block any thing at their end with 10.0. It was working fine in 9.5.  Sophos Tech support sending the case to their Lab.

    :20711