WO2016036321A1

WO2016036321A1 - Methods for generating a vulnerability pattern, methods for determining a security threat, vulnerability pattern generators, and vulnerability pattern scanners

Info

Publication number: WO2016036321A1
Application number: PCT/SG2015/050305
Authority: WO
Inventors: Thandava Krishnan SAIDAPET PADMANABHAN; Seetha Manognya JANDHYALA; Wang Hao LEE
Original assignee: Agency For Science, Technology And Research
Priority date: 2014-09-05
Filing date: 2015-09-07
Publication date: 2016-03-10

Abstract

According to various embodiments, a method for generating a vulnerability pattern may be provided. The method may include: determining a super seed file based on data format information; determining a seed file map based on the super seed file; and determining the vulnerability pattern based on the seed file map.

Description

METHODS FOR GENERATING A VULNERABILITY PATTERN, METHODS FOR DETERMINING A SECURITY THREAT, VULNERABILITY PATTERN GENERATORS, AND VULNERABILITY PATTERN SCANNERS

Cross-reference to Related Applications

[0001] The present application claims the benefit of the Singapore patent application No. 10201405531V filed on 5 September 2014, the entire contents of which are incorporated herein by reference for all purposes.

Technical Field

[0002] Embodiments relate generally to methods for generating a vulnerability pattern, methods for determining a security threat, vulnerability pattern generators, and vulnerability pattern scanners.

Background

[0003] Latent software defects in computing systems like mobile platforms and unforeseen usage such as malicious exploitation of the discovered defects may cause serious problems. As such, there may be a need to prevent damage from such defects.

Summary

[0004] According to various embodiments, a method for generating a vulnerability pattern may be provided. The method may include: determining a super seed file based on data format information; determining a seed file map based on the super seed file; and determining the vulnerability pattern based on the seed file map.

[0005] According to various embodiments, a method for determining a security threat may be provided. The method may include: determining input data; determining data format rules; determining a reference vulnerability pattern; and determining whether the input data include a security threat based on the data format rules and the reference vulnerability pattern.

[0006] According to various embodiments, a vulnerability pattern generator may be provided. The vulnerability pattern generator may include: a super seed file determination circuit configured to determine a super seed file based on data format information; a seed file map determination circuit configured to determine a seed file map based on the super seed file; and a vulnerability pattern determination circuit configured to determine a vulnerability pattern based on the seed file map.

[0007] According to various embodiments, a vulnerability pattern scanner may be provided. The vulnerability pattern scanner may include: an input circuit configured to receive input data, data format rules, and a reference vulnerability pattern; and a determination circuit configured to determine whether the input data include a security threat based on the data format rules and the reference vulnerability pattern.

Brief Description of the Drawin2S

[0008] In the drawings, like reference characters generally refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the invention. In the following description, various embodiments are described with reference to the following drawings, in which:

FIG. 1A shows a flow diagram illustrating a method for generating a vulnerability pattern according to various embodiments;

FIG. IB shows a flow diagram illustrating a method for determining a security threat according to various embodiments;

FIG. 1C shows a vulnerability pattern generator according to various embodiments;

FIG. ID shows a vulnerability pattern scanner according to various embodiments;

FIG. 2 shows an illustration of a system according to various embodiments and of a super seed file generation phase according to various embodiments;

FIG. 3 shows an illustration of the generation and testing phase according to various embodiments;

FIG. 4 shows an illustration of the vulnerability pattern generation phase and the pattern generation phase activities according to various embodiments;

FIG. 5 shows an illustration of the vulnerability scanning phase using the patterns previously generated according to various embodiments; and

FIG. 6 shows an illustration of an overall process for creating a vulnerability pattern according to various embodiments.

Description

[0009] Embodiments described below in context of the devices are analogously valid for the respective methods, and vice versa. Furthermore, it will be understood that the embodiments described below may be combined, for example, a part of one embodiment may be combined with a part of another embodiment.

[0010] In this context, the vulnerability pattern generator as described in this description may include a memory which is for example used in the processing carried out in the vulnerability pattern generator. In this context, the vulnerability pattern scanner as described in this description may include a memory which is for example used in the processing carried out in the vulnerability pattern scanner. A memory used in the embodiments may be a volatile memory, for example a DRAM (Dynamic Random Access Memory) or a non-volatile memory, for example a PROM (Programmable Read Only Memory), an EPROM (Erasable PROM), EEPROM (Electrically Erasable PROM), or a flash memory, e.g., a floating gate memory, a charge trapping memory, an MRAM (Magnetoresistive Random Access Memory) or a PCRAM (Phase Change Random Access Memory).

[0011] In an embodiment, a "circuit" may be understood as any kind of a logic implementing entity, which may be special purpose circuitry or a processor executing software stored in a memory, firmware, or any combination thereof. Thus, in an embodiment, a "circuit" may be a hard-wired logic circuit or a programmable logic circuit such as a programmable processor, e.g. a microprocessor (e.g. a Complex Instruction Set Computer (CISC) processor or a Reduced Instruction Set Computer (RISC) processor). A "circuit" may also be a processor executing software, e.g. any kind of computer program, e.g. a computer program using a virtual machine code such as e.g. Java. Any other kind of implementation of the respective functions which will be described in more detail below may also be understood as a "circuit" in accordance with an alternative embodiment.

[0012] Latent software defects in computing systems like mobile platforms and unforeseen usage such as malicious exploitation of the discovered defects may cause serious problems. According to various embodiments, device and methods may be provided to prevent damage from such defects.

[0013] According to various embodiments, a systems and processes may be provided for automated software vulnerability discovery, classification and defence.

[0014] According to various embodiments, latent software defects in computing systems like mobile platforms may be automatically found, and unforeseen usage such as malicious exploitation of the discovered defects may be prevented.

[0015] According to various embodiments, a distributed architecture such as client- server may be provided. The server may generate malformed test data for clients whose software platform may be vulnerable to a (remote) attack. The client may be a desktop system, mobile phone, tablet or any embedded system that holds sensitive data that may be of interest to the intruder. The client component may process the test data (for example the client may render the file generated by the server). According to various embodiments, the client may discover latent software defects including (but not limited to) zero-day vulnerabilities that may be security related. Defects detected by the client may be reported to server. The server (in other words: the server component) may classify the defects according to levels of exploitability and may create vulnerability patterns for exploitable defects. The said vulnerability patterns may then be used to form the indispensible layer of defense against unknown/zero-day attacks. [0016] According to various embodiments (and for example unlike commercial antivirus tools that are dependent on malware samples), 0-Day vulnerabilities and potentially block off malicious security threats may be discovered autonomously even before it reaches the end-users (in other words: even before the end-user is made aware of these vulnerabilities or security threats).

[0017] FIG. 1 shows a flow diagram 100 illustrating a method for generating a vulnerability pattern according to various embodiments. In 102, a super seed file may be determined based on data format information. In 104, a seed file map may be determined based on the super seed file. In 106, the vulnerability pattern may be determined based on the seed file map.

[0018] In other words, a vulnerability pattern may be generated based on information which in turn has been generated based on data format information.

[0019] According to various embodiments, the method may further include determining test parameters. According to various embodiments, the vulnerability pattern may be determined further based on the test parameters.

[0020] According to various embodiments, the method may further include determining a crashing input file. According to various embodiments, the vulnerability pattern may be determined further based on the crashing input file.

[0021] According to various embodiments, the method may further include determining a fuzzed file and determining the crashing input file based on the fuzzed file.

[0022] According to various embodiments, the fuzzed file may be determined based on the super seed file. [0023] According to various embodiments, the vulnerability pattern may be determined further based on the data format information.

[0024] FIG. IB shows a flow diagram 108 illustrating a method for determining a security threat according to various embodiments. In 1 10, input data may be determined. In 1 12, data format rules may be determined. In 1 14, a reference vulnerability pattern may be determined. In 1 16, it may be determined whether the input data include a security threat based on the data format rules and the reference vulnerability pattern.

[0025] In other words, it may be determined whether input data is a potentially malicious based on a reference vulnerability pattern and based on data format rules.

[0026] According to various embodiments, determining whether the input data include a security threat may include or may be determining a present vulnerability pattern based on the input data.

[0027] According to various embodiments, determining the present vulnerability pattern may include or may be determining for each data format rule of the data format rules how often the input data violates the respective data format rule.

[0028] According to various embodiments, determining the reference vulnerability pattern may include or may be: determining a super seed file based on data format information, determining a seed file map based on the super seed file, and determining the reference vulnerability pattern based on the seed file map.

[0029] FIG. 1C shows a vulnerability pattern generator 1 18 according to various embodiments. The vulnerability pattern generator 1 18 may include a super seed file determination circuit 120 configured to determine a super seed file based on data format information. The vulnerability pattern generator 1 18 may further include a seed file map determination circuit 122 configured to determine a seed file map based on the super seed file. The vulnerability pattern generator 1 18 may further include a vulnerability pattern determination circuit 124 configured to determine a vulnerability pattern based on the seed file map. The super seed file determination circuit 120, the seed file map determination circuit 122, and the vulnerability pattern determination circuit 124 may be coupled with each other, like indicated by lines 126, for example electrically coupled, for example using a line or a cable, and/ or mechanically coupled.

[0030] According to various embodiments, the vulnerability pattern determination circuit 124 may be configured to determine the vulnerability pattern further based on test parameters.

[0031] According to various embodiments, the vulnerability pattern determination circuit 124 may be configured to determine the vulnerability pattern further based on a crashing input file.

[0032] According to various embodiments, the vulnerability pattern generator 118

(for example a determination circuit of the vulnerability pattern generator 1 18) may be configured to determine the crashing input file based on a fuzzed file.

[0033] According to various embodiments, the vulnerability pattern generator 118

(for example a determination circuit of the vulnerability pattern generator 1 18) may be configured to determine the fuzzed file based on the super seed file.

[0034] According to various embodiments, the vulnerability pattern determination circuit 124 may be configured to determine the vulnerability pattern further based on the data format information. [0035] FIG. ID shows a vulnerability pattern scanner 128 according to various embodiments. The vulnerability pattern scanner 128 may include an input circuit 130 configured to receive input data, data format rules, and a reference vulnerability pattern. The vulnerability pattern scanner 128 may further include a determination circuit 132 configured to determine whether the input data include a security threat based on the data format rules and the reference vulnerability pattern. The input circuit 130 and the determination circuit 132 may be coupled with each other, like indicated by lines 134, for example electrically coupled, for example using a line or a cable, and/ or mechanically coupled.

[0036] According to various embodiments, the determination circuit 132 may further configured be to determine a present vulnerability pattern based on the input data.

[0037] According to various embodiments, the determination circuit 132 may further be configured to determine for each data format rule of the data format rules how often the input data violates the respective data format rule.

[0038] According to various embodiments, the reference vulnerability pattern may be determined based on determining a super seed file based on data format information, determining a seed file map based on the super seed file, and determining the reference vulnerability pattern based on the seed file map.

[0039] According to various embodiments, six main phases may be provided, like will be described in more detail in the following. The six main phases may be as follows: super seed file generation phase, test generator evaluation phase, testing engine phase, vulnerability classification engine phase, vulnerability pattern generation phase, and vulnerability pattern scan engine phase. [0040] According to various embodiments, the super seed file generation phase may be responsible (in other words: may provide) for preparing the system for automatic probing of target code bases. This process may include both manual and automatic sections by generating high-data-format coverage inputs (which may also be known as super seed files) for negative testing. The process may ensure that the seed files abide by the file format RFCs. File format tools like EXIF (or Exif; Exchangeable Image File Format) tool, hex editor, audacity, and others alike may be used to further enhance the file structure and eliminate unnecessary sections from the file. The super seed file may also be used to create a Seed-file Map. This Seed-file Map together with a fuzzing input based on the super seed file which successfully induced a vulnerability symptom may be used to create the vulnerability pattern.

[0041] FIG. 2 shows an illustration 200 of a system according to various embodiments and of a super seed file generation phase according to various embodiments. Portions of the system may provide vulnerability discovery (like indicated by block 202), and portions of the system may provide vulnerability protection (like indicated by block 204). A test server 206 may create super seed files 212 (like indicated by 210) based on data format or RFCs (Requests for Comments) 208. A test generator 214 in the test server 206 may provide fuzzing jobs (like indicated by 216) and provide output to a web server 218, which may provide information to a database 220 and to SOFT clients 222. A seedmap generator 224 may receive the super seed file and may create seed file maps 226, which may be provided to a vulnerability pattern rule generator 232. The vulnerability pattern rule generator 232 may provide output to a vulnerability pattern rule (data)base 236. Data- format rule creation 228 may receive data- format (for example RFCs) 208 as input and may provide data- format rules 230 as an output, which may be provided to a vulnerability pattern scanner 234.

[0042] Like indicated by 238, data-format information may be provided for creating super seed files and for data-format rule creation. A super seed file may be provided to the test generator 214 and to the seed map generator 224, like indicated by 240. The seed map generator 224 may provide seed file maps to the vulnerability pattern generator 232, like indicated by 242. Data-format rules may be provided to the vulnerability pattern scanner 234, like indicated by 244.

[0043] According to various embodiments, the test generator evaluation phase may evaluate multiple security testing engines based on the quality and uniform distribution of the delta (in other words: difference) against the original input. The engines may are also be rated on three levels of uniqueness of the output. The selected engines may be integrated into the system seamlessly. The test generator evaluation phase may return a set of configurations that may produce excellent quality output with high uniqueness and uniformity.

[0044] According to various embodiments, the testing engine may be the main testing unit where multiple malformed and malicious test files are generated from the Super Seed files created in the super seed file generation phase and distributed to the client devices. The testing engine may include a server component and an agent in each of the test devices. The tests may be sent to the client agent which may perform the tests on the device and then send the results back to the server. During testing, the agent may record the vulnerable symptoms (including but not limited to crashes, undefined behavior, execution flow deviation). The server may intelligently balance and scale the load from the devices.

[0045] FIG. 3 shows an illustration 300 of the generation and testing phase (in other words: of the test generator evaluation phase and the testing engine phase) according to various embodiments. Various portions of the illustration 300 of FIG. 3 may be similar or identical to the illustration 200 of FIG. 2, so that the same reference signs may be used and duplicate description may be omitted.

[0046] Like illustrated by 302, super seed files may be provided to the test generator 214. The test generator 214 may provide malformed files 304 as test cases 216 (which correspond to fuzzing jobs) as tests 306 to the web server 218. The web server 218 may communicate with the clients 222 (which may be target host platforms), for example download tests like indicated by 308, or communicate test results like indicated by 310. The web server 218 may provide crash information 312 to the database 220. Furthermore, an incoming data stream 314 and an admit/ reject signal 316 are shown.

[0047] According to various embodiments, the vulnerability classification engine may classify all the vulnerability reports, from the tests done in the test engine phase, based on their severity, uniqueness and exploitability.

[0048] According to various embodiments, a vulnerability pattern may be generated based on results from the vulnerability classification engine phase. A database management system or equivalent information management component may store the said vulnerability patterns obtained from the vulnerability classification engine. The vulnerability pattern may also be generated from sources including but not limited to vulnerabilities discovered through fuzzing, static analysis, symbolic execution and other program analysis techniques.

[0049] FIG. 4 shows an illustration 400 of the vulnerability pattern generation phase and the pattern generation phase activities according to various embodiments. Various portions of the illustration 400 of FIG. 4 may be similar or identical to the illustration 200 of FIG. 2, so that the same reference signs may be used and duplicate description may be omitted.

[0050] Like illustrated by 402, test parameters and a crashing input file may be provided from the database 220 to the vulnerability pattern rule generator 232. Like illustrated by 404, data-format rules may be provided to the vulnerability pattern rule generator 232. Like illustrated by 406, a seed file map may be provided to the vulnerability pattern rule generator 232. The vulnerability pattern rule generator 232 may provide the vulnerability pattern 408 to the vulnerability pattern rule base 236. Furthermore, an incoming data stream 410 and an admit/ reject signal 412 are shown.

[0051] A according to various embodiments, a (vulnerability) pattern scan engine may provide proactive protection by automatic near real-time scanning of high-level data stream for inputs that might trigger known new vulnerabilities based on vulnerabilities documented in the vulnerability pattern generation.

[0052] FIG. 5 shows an illustration 500 of the vulnerability scanning phase (in other words: vulnerability protection phase) using the patterns previously generated according to various embodiments. Various portions of the illustration 500 of FIG. 5 may be similar or identical to the illustration 200 of FIG. 2, so that the same reference signs may be used and duplicate description may be omitted. [0053] According to various embodiments, an incoming data stream 502, data format rules 504, and vulnerability patterns 506 may be provided to the vulnerability pattern scanner 234. The vulnerability pattern scanner 234 may output an admit/ reject signal 508 based on the incoming data stream 502, the data format rules 504, and the vulnerability patterns 506.

[0054] According to various embodiments, a systematic approach to zero- day/unknown vulnerability discovery on a mobile platform by means of a few carefully crafted automatic and semi-automatic stages may be provided. Various embodiments may be highly scalable, distributed and easily extendable to any computing platform.

[0055] According to various embodiments, the system may utilize cloud computing for rapid association of incoming data traffic with the vulnerability information database.

[0056] According to various embodiments, vulnerability-triggering patterns may be created from the input format characteristics rather than signature of the malicious input or vulnerable code sections in the target platform. No instrumentation of target platform may be required. According to various embodiments, no additional software installation may be required on computing devices to be protected.

[0057] A system according to various embodiments may be deployed in various points in the network infrastructure; including but not limited to server, networking appliance, end-user devices or a hybrid of these points.

[0058] Various embodiments may be deployed in ways including but not limited to being offered as a value-added service by telecommunications operator, be an add-on feature by OEMs (Original Equipment Manufacturer), or be a device software add-on application that can be installed. [0059] In the following, an example of how various embodiments may be applied to a real world data-format will be described. As an example, for illustrative purposes, the GIF file format (which is a simple image file format allowing up to 256-color images with animation, transparency and LZW (Lempel-Ziv- Welch) compression) may be used. Despite its simplicity, the GIF data-format vulnerabilities still occur in various softwares.

[0060] According to various embodiments, Fuzzing may be the security testing method.

[0061] According to various embodiments, when fuzzing against the target devices, the process may involve the creation of super seed files. Fuzzing activities for a data-type may operate on the data-type's super seed file, so vulnerability patterns may be made based on the super seed file layout. The process may start by generating good fuzzing configurations by analyzing fiizzing parameters selecting the best parameters for performing the fuzzed file generation. Then fuzzing may begin and fuzzed files may be distributed to the target devices. Once test results arrive back at the server inventors, a process like described below with reference to FIG. 6 may ensue.

[0062] FIG. 6 shows an illustration 600 of an overall process for creating a vulnerability pattern according to various embodiments. Like illustrated by 602, a seed map generator 604 (for example a SeedMap script or program or circuit) may read the super seed file and may generates the seed file map. Like illustrated by 606, the seed file map may be given to a vulnerability pattern rule generator 614 (for example a vulnerability pattern rule generator script or program or circuit). Like indicated by 608, the vulnerability pattern rule generator 614 may read an instance of the input file that induces a crash on a target device. Like indicated by 610, the vulnerability pattern rule generator 614 may read the data-format rules. In this example, the data- format rules may describe the GIF file specification rules that when violated do not render the file- unreadable but might cause undefined behavior. Like indicated by 612, the vulnerability pattern rule generator 614 may read in the fuzz parameters that produce the crashing input file. Like indicated by 616, the vulnerability pattern rule generator 614 may create the vulnerability pattern and store it as an XML (Extensible Markup Language) in the vulnerability pattern rule-base 618. At this point, the vulnerability pattern may be ready to be used. When an incoming GIF data-stream 622 is detected by the (for e.g.) network gateway, it passes this GIF data stream to the Vulnerability Pattern scanner 624 before sending it to the end device (for example like indicated by processes i. to iii. 622, 624, 626 in FIG. 6). The vulnerability pattern scanner 624 may read relevant data rules 620, any may provide an admit/ reject signal 626 as an output (for example based on the incoming file stream 622 and the read relevant data-format rules 620.

[0063] With respect to rule structure, according to various embodiments, a rule may be a true/false predicate that says if an incoming stream (for example incoming GIF stream) violates the file format (for example violates a certain part of the GIF specification.

[0064] Examples of a GIF rule may be "do image dimensions in <logical-screen- descriptor> not match dimensions in <image-descriptor>" or "image has invalid <graphic-control-extension> block size indicator value".

[0065] According to various embodiments, there may be as many rules in the rule- base as the protocol predicate space in the (for example GIF) data format specification. [0066] In the above example embodiment, a vulnerability pattern may look like the following after extraction:

gif{2: 247, 10: 1 , 4: 0, 5: 1, 6: 1, 3: 4}

[0067] The format may be 'gif as indicated by the first 3 chars (characters) of the pattern allowing discretionary filtering of data. The remaining data may be items as structured in a dictionary format. The keys in the dictionary may be the rule numbers corresponding to rules in the GIF rule base. The key's values may correspond to how many times each rule was fired when scanning the crashing input. For example, rule 2 may be fired 247 times, rule 10 may be fired 1 time, rule four may not be fired, rule 5 may be fired once, rule 6 may be fired one, and rule 3 may be fired 4 times.

[0068] According to various embodiments, devices and methods may be provided for matching a vulnerability pattern. A vulnerability pattern may be generated for every incoming file stream. According to various embodiments, the incoming file's vulnerability pattern may be matched against that of others in the rule base (which may be referred to as reference vulnerability patterns). According to various embodiments, if the vulnerability pattern consists of exactly the same fired rules as that of another vulnerability pattern in the vulnerability rule-base, the incoming file stream may be flagged as malicious and may be dropped.

[0069] According to various embodiments, devices and methods (in other words: systems and processes) may be provided for discovering and classifying zero-day vulnerabilities on any computing system. According to various embodiments, devices and methods may be provided to achieve platform-independent and community-wide protection from exploitation using the found vulnerabilities using vulnerability patterns. [0070] While the invention has been particularly shown and described with reference to specific embodiments, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. The scope of the invention is thus indicated by the appended claims and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced.

Claims

Claims What is claimed is:

1. A method for generating a vulnerability pattern, the method comprising:

determining a super seed file based on data format information;

determining a seed file map based on the super seed file; and

determining the vulnerability pattern based on the seed file map.

2. The method of claim 1, further comprising:

determining test parameters;

wherein the vulnerability pattern is determined further based on the test parameters.

3. The method of claim 1, further comprising:

determining a crashing input file;

wherein the vulnerability pattern is determined further based on the crashing input file.

4. The method of claim 3, further comprising:

determining a fuzzed file; and

determining the crashing input file based on the fuzzed file.

5. The method of claim 4,

wherein the fuzzed file is determined based on the super seed file.

6. The method of claim 1,

wherein the vulnerability pattern is determined further based on the data format information.

7. A method for determining a security threat, the method comprising:

determining input data;

determining data format rules;

determining a reference vulnerability pattern; and

determining whether the input data comprise a security threat based on the data format rules and the reference vulnerability pattern.

8. The method of claim 7,

wherein determining whether the input data comprise a security threat comprises determining a present vulnerability pattern based on the input data.

9. The method of claim 8,

wherein determining the present vulnerability pattern comprises determining for each data format rule of the data format rules how often the input data violates the respective data format rule.

10. The method of claim 7,

wherein determining the reference vulnerability pattern comprises: determining a super seed file based on data format information; determining a seed file map based on the super seed file; and determining the reference vulnerability pattern based on the seed file map.

11. A vulnerability pattern generator comprising:

a super seed file determination circuit configured to determine a super seed file based on data format information;

a seed file map determination circuit configured to determine a seed file map based on the super seed file; and

a vulnerability pattern determination circuit configured to determine a vulnerability pattern based on the seed file map.

12. The vulnerability pattern generator of claim 1 1 ,

wherein the vulnerability pattern determination circuit configured to determine the vulnerability pattern further based on test parameters.

13. The vulnerability pattern generator of claim 1 1 ,

wherein the vulnerability pattern determination circuit configured to determine the vulnerability pattern further based on a crashing input file.

14. The vulnerability pattern generator of claim 13, wherein the vulnerability pattern generator is configured to determine the crashing input file based on a fuzzed file.

15. The vulnerability pattern generator of claim 14,

wherein the vulnerability pattern generator is configured to determine the fuzzed file based on the super seed file.

16. The vulnerability pattern generator of claim 1 1,

wherein the vulnerability pattern determination circuit configured to determine the vulnerability pattern further based on the data format information.

17. A vulnerability pattern scanner comprising:

an input circuit configured to receive input data, data format rules, and a reference vulnerability pattern; and

a determination circuit configured to determine whether the input data comprise a security threat based on the data format rules and the reference vulnerability pattern.

18. The vulnerability pattern scanner of claim 17,

wherein the determination circuit is further configured to determine a present vulnerability pattern based on the input data.

19. The vulnerability pattern scanner of claim 18, wherein the determination circuit is further configured to determine for each data format rule of the data format rules how often the input data violates the respective data format rule.

The vulnerability pattern scanner of claim 17,

wherein the reference vulnerability pattern is determined based on determining a super seed file based on data format information, determining a seed file map based on the super seed file, and determining the reference vulnerability pattern based on the seed file map.