Problem
Network managers always want to or are forced to control the information flowing around a network. Most of the time, filtering is a good way to do the control. Inside this big category, we always like to use block list to prevent information comes in or goes out, to and from the network.

Scenarios
Flora doesn’t want her daughter wallow in Japan pop star. Flora knows that her daughter always navigate to some sites with domain name ending as ‘.jp’, she is looking for a tool that can control what kinds of websites their PC can reach.

IT administrator in PC middle school discovered that their mail system started receiving porn advertisement and students are trying to share these links through the mail system, they are planning to have a filter that can block all such mail flows.

Justin loves blogging so much, he is writing them weekly. He loves to collect and read feedbacks from the audiences. However, he hates those spammer pasting unrelated advertisement on his posts. He want to figure out a way to stop them appearing from other audiences.

Solution
The trivial filtering solution to help these people out is bad word filtering. The basic idea is the same as general block list, users can specify the tokens they want to look for when deciding to block the information. In general, there are at least two different definitions to distinguish whether we found the bad word or not. Given an input message M,

1. Split the message M into a sequence of words Ws, we found a bad word bW is in the message only if Ws contains bW.
2. Take the message M as an input stream, we found a bad word bW when there is a list of consecutive characters equals bW.

Both definition has there own advantages and disadvantages, but we will keep this discussion later since the current topic is how to test the filter. Let’s say we pick the first definition for our filter, then what should we test? (Take some time to think about scenarios before continue reading)

Functional Test
According the input of this filter (input message M), we can design few functional test cases. Basic scenarios are,

• empty message [Expected: Accept];
• only a word (either good or bad word) [Expected: good - Accept, bad - Reject];
• two words (good and bad) with different delimiter [Expected: Depends on how the feature define delimiter];
• a list of word and contains (0, 1, 2, all) bad words [Expected: all reject];
• a bad word is embedded in a word (eg. assume evil is bad word, message conatins residentevil.com) [Expect: By design, this message will be accepted]

Beside these functional test cases, we should to have a lengthy message to check boundary cases of the feature. Assume the longest message we accept is N characters, we need to have message with length N, N+1 and N+2. On the other hand, globalization and localization test may be required, depends on who is your target user.

Security Concern
Then we would ask: is there other way to bypass the filter (eg. message using different encoding)? Is it possible to have code injection or script injection attack? Who can use the feature? Where is the bad word list? Who have rights to touch the list? These are security concerns when testing the feature. Drawing a data flow diagram always help to identify what kind of security issues we may have. However, this post only focus on functional testing a feature. May be next time we can discuss how to design security test cases of a feature.

Conclusion
We have only discussed some elementary skills to design the test plan of a feature. You can consider what kind of input the feature can have, both valid and invalid input. Output is another way to discover new scenarios, output is anything that the feature shown. Since we assumed that this filter only say accept or reject of a message and throw some exceptions (eg. input size exceed), the test cases we found here are almost dominated by what we found with the input. Now, you are able to test your program more systematically!

Have a good weekend!

Practice (Just for fun)
Should you want to have some practice, we can discuss how to test an IP block list filter. Here is a simple definition:

INPUT: Only allow IPv4 address, one at a time
IMPLEMENTATION: An IP block list is stored as a text file in the same folder of the filter, user need to directly modify the text file if he want to Add/Remove/Edit an IP address in the block list. The filter will perform a binary search to see if the input address is on the list. If it is, then it will announce reject, otherwise output accept.
OUTPUT: Accept/ Reject the address

Stuart used the VirusTotal and FireEye’s findings as a source of malware. How accurate is that? Stuart admitted the data being imprecise, and I am not in the field with data to tell a very precise one about VirusTotal either. Let me try to deduce, if anyone can submit a sample to VirusTotal, it is possible there are significant number of samples that never got out far enough to reach more than a small population, or some people wrote their own and submitted up there, with no victims. For his company’s source of malware, I will assume it is very real as the collecting appliances are deployed on real production boxes. I have no idea what boxes are they though. This is my thoughts to justify the accuracy of his findings. So, I assume only a portion of it concerns the majority of us. So it might not be less than 60%.

After reading Stuart’s post, I got to know some numbers of what’s going on. I do not believe in the ability of the signature matching ( and this is not byte-to-byte matching! ) alone, but I think AVs are still OK to detect a good number of those popular roaming malware your father or mother is being infected with. For some new detection, especially “nasty root of all evil” the rootkits, there is behavioral analysis that Tim Fraser developed that looks interesting. Though, if you ask for perfect detection, no way.