JP2018506808A - Network data characterization system and method - Google Patents

Abstract

Embodiments of systems and methods for network data characterization and / or classification that overcome the shortcomings of the prior art are described herein. These and other advantages are achieved by a method for network data characterization. The method receives a network event in which at least some of the network events include content, and at least some of the data messages include the content and metadata describing the event and the content. Converting the received content into a data message containing, and forwarding the data message to a plurality of analyzers based on specific message criteria signed by individual analyzers, of the one or more analyzers Each receiving the forwarded data message analyzing content in a data message to characterize the content, and the one or more analyzers may indicate that the content is malicious, or The prediction that the content is malicious is correct Including at least one machine learning analyzer that classifies content by a confidence percentage that indicates realness, and outputs a characterization result of the one or more analyzers to be subsequently taken based on the characterization result Comparing the output characterization result with a plurality of criteria to determine an action.

Description

RELATED APPLICATION This application claims priority from US Provisional Application No. 62 / 083,090 “Systems and Methods for Network Characterization”, which is hereby incorporated by reference in its entirety.

background
In 2014, a sample of 50 global organizations reported 1,367 data breach events in over 63,437 network security incidents.
These data breaches represent successful cyber attacks that were otherwise circumvented, infiltrated, or otherwise undetected by organizations with significant existing investments in network security hardware and software. Yes.
Mostly done to the victim organization by an external party, using malware or using hacking techniques, takes months to discover and is generally sacrificed by a third party Reported to the person.
The company was not a “soft targets”.
The company used common network security equipment and best management techniques.

Current network security products such as firewalls, intrusion prevention systems (IPS), anti-virus software, policy enforcement tools, configuration management tools, data loss prevention (DLP) systems, It plays a vital role in implementing a thorough defense approach to security.
Such security products, when used properly, can block many of the lesser malicious activities on the market.
In fact, once the malware is discovered and fingerprinted, these security products can help improve leaks by providing an existing framework to remove the malware from the affected system. Play an important role.
Nevertheless, these products / tools lack two basic areas:

1. Individual tools require additional integration of hardware and software resources and custom integration that negates the efficiency available due to system overlap.
2. Detection is too slow and too limited to previously observed malware / threat actors,
As such, such tools are ineffective against more modern threats.

In the first area, traditional defense tools (eg IPS / IDS, policy enforcement, CM, DLP, etc.) and more advanced information analysis tools are used to stream assembly, content extraction, data tagging, association, And overlap with the central function for workflow integration.
However, if there is no assistance in leveraging this overlap, data integration requires custom implementation (execution) resources.
A platform is needed to provide threat intelligence delivery devices, stand-alone components, and SIEM tools for seamless integration and to enable multi-faceted analysis leveraging these core functions.

In the second area, today's malware detection engine is tuned for certainty.
Signatures are written specifically to hit the malicious software for which they are designed.
To address the shortcomings of signature-based systems, defenders (defenders) now use a sandbox—a carefully controlled virtual environment to perform and investigate suspicious file actions. Yes.
Because signature-related malware is more resilient to change, the sandbox is simply too slow to keep up with the vast amount of corporate network traffic.
Since individual files may take a few minutes to investigate, these systems allow the rest to pass through without investigation and pre-filter to determine which files to view. (Pre-filters) must be used.
In general, it is too expensive to form a sandbox large enough to investigate all traffic.
Pre-filters, in most network environments, have signatures that are no larger than signature-based detection mechanisms associated with file metadata or behavioral patterns.
Pre-filters can look for files sent by email from someone outside the company by URL linked to the file. These behavior patterns are just as fragile as signatures and require previously repeated behavior monitoring.
Only a small subset of potential malware is examined, and many potential threats remain untouched.

Even if new malware should be chosen for analysis, most sandbox environments only look for previously observed malicious activity, such as changes to the Windows registry.
New malware authors understand sandbox detectors, run malware, detect sandbox network settings, mimic safe execution, and very specific computer configurations where sandboxes are not replicated ( Have a simple way to avoid detection, including sleeping the malware for a few minutes, before designing the computing configuration.
Both approaches are attempted to mitigate their vulnerable designs by widespread reporting and sharing of malicious signatures.
These techniques keep the guardian following the threat and provide no path to proactive or prophetic defense. Existing solutions are too slow and useless for the latest threats.

A paradigm shift (revolutionary change) is necessary.
Proactive threat search and discovery using real-time, unsigned-based technology must supplement outdated technology based on signatures and behavior.
Automated threat identification must reduce the discovery chronology from month to minute.
Rather than waiting for someone outside the defense organization to alert the leaked guardian, the guardian must stop the attack from proceeding.

Summary Embodiments of systems and methods for network data characterization and / or classification that overcome the shortcomings of the prior art are described herein.
These and other advantages are achieved by a method for network data characterization and a corresponding system.
The method receives a network event in which at least some of the network events include content, and at least some of the data messages include the content and metadata describing the event and the content. Converting the received content into a data message including: forwarding (routing) the data message to a plurality of analyzers based on specific message criteria signed by individual analyzers, and the one or more analyzes Each of the devices receives the forwarded data message analyzing content in a data message to characterize the content, and the one or more analyzers may indicate that the content is malicious Or the assumption that the content is malicious Includes at least one machine learning analyzer that classifies content by a confidence percentage that indicates certainty that it is correct, outputs a characterization result of the one or more analyzers, and is based on the characterization result Comparing the output characterization result with a plurality of criteria to determine a subsequent action to be performed.

These and other advantages are also achieved by a system for network data characterization.
The system includes one or more characterization sensors including one or more processors and a memory, the memory including instructions for performing the following processes by the one or more processors, Data in which at least some of the network events receive a network event that includes content, and at least some of the data messages include the content and metadata describing the event and the content Converts the received content into a message and forwards (routes) the data message to multiple analyzers based on specific message criteria signed by individual analyzers, and includes one or more machine learning analyzers Each contains a container in the data message to characterize the content. Certainty that the one or more machine learning analyzers have received the forwarded data message to analyze the content, and that the probability that the content is malicious or that the prediction that the content is malicious is correct Including at least one machine learning analyzer that categorizes content by a confidence percentage that indicates a subsequent characterization result of the one or more machine learning analyzers to be taken based on the characterization result In order to determine the action, the output characteristic evaluation result is compared with a plurality of criteria.
The characterization sensor may be a specially programmed computer specialized to perform the described task.

BRIEF DESCRIPTION OF THE DRAWINGS Embodiments of network data characterization and / or classification systems and methods are understood and described in conjunction with the following drawings:
FIG. 1A is a block diagram illustrating an embodiment of a system for network data characterization. FIG. 1B is a block diagram illustrating an embodiment of a system for network data characterization. FIG. 2 is a flowchart illustrating an embodiment of a method for evaluating network data characteristics. FIG. 3 is a flowchart illustrating an embodiment of a method for evaluating network data characteristics. FIG. 4A is a screenshot of a dashboard showing characterization results in an embodiment of a network data characterization system and method. FIG. 4B is a screenshot of a dashboard showing characterization results in an embodiment of a network data characterization system and method. FIG. 5 is a screenshot of a categorized event list showing characterization results in an embodiment of a network data characterization system and method. FIG. 6 is a screenshot of a sorted event list showing the results of filtered characterization in an embodiment of a network data characterization system and method. FIG. 7A is a screenshot of a categorized file showing the results of characterization in an embodiment of a network data characterization system and method. FIG. 7B is a screenshot of a categorized file showing characterization results in an embodiment of a network data characterization system and method. FIG. 8 is a screenshot of a rule setting interface for applying rules to results in an embodiment of a network data characterization system and method. FIG. 9A is a screenshot of a categorized event list with a pinpoint tool showing the results of an accurately shown (pinpointed) and filtered characterization in an embodiment of a network data characterization system and method It is. FIG. 9B is a screenshot of a classified event list with a pinpoint tool showing the results of an accurately shown and filtered characterization in an embodiment of a network data characterization system and method. FIG. 9C is a screenshot of a categorized event list with a pinpoint tool that shows the results of an accurately shown and filtered characterization in an embodiment of a network data characterization system and method. FIG. 9D is a screenshot of a categorized event list with a pinpoint tool that shows the results of an accurately shown and filtered characterization in an embodiment of a network data characterization system and method. FIG. 9E is a screenshot of a categorized event list with a pinpoint tool that shows the results of an accurately shown and filtered characterization in an embodiment of a network data characterization system and method. FIG. 10 is a screenshot of a confidence percentage result for a characterization result file type in an embodiment of a network data characterization system and method. FIG. 11A is a screenshot of a configuration tool in an embodiment of a network data characterization system and method. FIG. 11B is a screenshot of a configuration tool in an embodiment of a network data characterization system and method.

DETAILED DESCRIPTION Embodiments of network data characterization and / or classification systems and methods are described herein.
Embodiments are considered for characterizing or classifying received network content, including whether the content is malicious, suspicious or secure / trusted.
Embodiments include a sophisticated and open cyber intelligence platform that automatically detects, analyzes, and facilitates response to advanced threats.
The platform can handle the most demanding network environments, sift through large amounts of data, and be accurate, non-fragile and resilient to find malware that existing network security tools have missed An analysis can be used.
Platform embodiments implement machine learning techniques to protect corporate assets and easily harmonize with existing cyber security tools.
The platform can be scaled to protect large enterprises without the need for extra hardware.
Embodiments are performed at near real-time line speeds.
Analysts examine individual events and ensure that individual events are associated with an integrated real-time intelligence provider for larger event situations, while cyber intelligence platforms are cyber security managers. Allows the analyst's workload and the threat detection threshold to be adjusted dynamically.

Embodiments of network data characterization systems and methods to achieve high malware detection accuracy on line speeds up to 10 Gbps on a single 2U sized appliance with very low latency Use a new and proactive approach.
Embodiments do not rely solely on signatures or other static threat characteristics.
Rather, we have described here that using machine learning and other advanced techniques implemented is effective against the latest and rapidly changing threats.
The cyber intelligence platform includes a file analysis framework, streaming analysis for near real-time workflow integration (“cyber time”), real-time intelligence interaction, post-analyzer for additional content processing, and system integration. Provides user-definable output events that are forwarded (routed) for
Embodiments enhance intelligence analysis by working in concert with other technologies and easily interfacing with intelligence delivery devices, analysis tools, and SIEM consoles.

New technology possibilities for network data characterization system and method embodiments include the following:
1. Line-speed file analysis framework, real-time threat and intelligence supply interaction, post-analyzer for additional content processing, and user-definable outputs routed for system integration. Cyber intelligence platform with
2. Analysis hosted by a set of platforms that provide innovative machine learning based on analytics and provide resilient, robust, accurate and fast malware detection.

With reference to FIG. 1A, an embodiment of a network data characterization system 10 is shown.
The software architecture of the characterization or classification sensor 12 provided by the system 10 is illustrated.
In the characterization sensor 12, the collector subsystem 104 is a data entry (input) point and receives network events from the external network 14 and the internal network 16 through the interface 102.
Interface 102 may be any of a variety of network interfaces with varying speeds (eg, a 1G or 10G interface).

A network event may include content, such as a file.
The collector 104 may be a reassembler that reconstructs data from a supply device (eg, SMTP, HTMP, and FTP supply devices) into events and content (eg, files).
In an embodiment, the collector 104 may utilize a deep packet inspection framework to provide content and metadata regarding events for which content has been pulled to the scalable file analyzer 106.
In an embodiment, the collector 104 creates a message from the content and metadata and forwards the message to the scalable file analyzer (analyzer) 106.
In other embodiments, the scalable file analyzer 106 creates a message from the content and metadata transferred from the collector 104.
Embodiments include a graphical user interface (GUI) and / or a collector based on a command line interface (CLI) for manual file upload and analysis, and a file-based API for external file analysis And a collector.

In an embodiment, the collector subsystem 104 provides a file analysis framework (scalable file analyzer 106) that hosts a set of memory-to-memory analyzers (analysis tools).
In an embodiment, the scalable file analyzer 106 includes a plurality of event and file analyzers 108.
For example, in the illustrated implementation, the scalable file analyzer 106 hosts seven types of event and file analyzers 108.
Some analyzers 108 are event analyzers, some are file analyzers, and some may be considered both event and file analyzers.
Based on load and other factors, embodiments may include one or more event and file analyzers of each type.
In an embodiment, the analyzer 108 receives a message forwarded to the scalable file analyzer 106 based on signature criteria (depending on whether the collector 104 or the scalable file analyzer 106 creates a message) Alternatively, the message transferred by the scalable file analyzer 106 is received.
For example, an individual analyzer 108 may receive a certain type of content (eg, a certain type of file, a certain type of content received from a certain type of source, or a certain type of network). Only certain types of content) can be signed.
The analyzer 108 and the analysis performed by the analyzer 108 are described in detail below.

When receiving a message from the collector 104, the scalable file analyzer 106 determines which analyzer 108 signs the content of the individual message and routes the message with the signed content to the signature analyzer 108. Just (routing).
In other words, messages (content and metadata) are routed to the analyzer 108 based on what event the message contains content for, or which file analyzer 108 signs. .
For example, some analyzers such as the Hector Analyzer described below are PE32s, PDF, MS-DOS executable, MS Word, PowerPoint, Excel, CDF / MSI, Android APK, JAR, ELF, Windows Installer XML Content, including bitmaps, and GIF files can be signed.
Other analyzers can only sign a subset of this content (eg, only PE32 and MS-DOS files).
The scalable file analyzer 106 can determine whether the content in the message is signed with the metadata contained within the message.
Similarly, the scalable file analyzer 106 can maintain files or other data with individual analyzer 108 signatures.
Alternatively, such files or data can be maintained by analyzer 108 and examined by scalable file analyzer 106.
It should be noted that multiple analyzers 108 can sign the same type of content, while some content is only signed by a single analyzer 108; The signature of one or more analyzers 108 can overlap with the signature of one or more other analyzers 108.

With continued reference to FIG. 1A, the results output from the scalable file analyzer 106 can be stored on the disk 110 and the database 112.
For example, the analyzer 106 can output a tagged and classified file that has been classified (e.g., classified as malicious or malicious beyond a set threshold percentage). Can be stored on the disk 110, while metadata describing the analysis results from the analyzer 106 can be stored in the database 112.
The resulting disc 110 of the analyzer 106 can be viewed by a GUI viewer 114 that allows custom filtering on a large set of content and session metadata.
The GUI event viewer 114 finds the file based on the detection threshold configuration (eg, built in or user-defined from the start) and supports collaborative analysis groups as described in detail below. Notifying the user of an analyzer 108 that can provide a workflow to tag an item as UNKNOWN, TRUSTED, SUSPICIOUS, or MALICIOUS Can do.

Also, the results of the scalable file analyzer 106 may be configured to be associated with a threat intelligence provider and output to a user definable system for interoperability and scalability, or The workflow can transfer (route) the file to the post analyzer 18 for additional analysis.
The post analysis subsystem 116 can retrieve the tagged and classified files from the disk 112 and output them to the post analyzer 18 through the interface 118.
Interface 118 may be any of a variety of network interfaces with varying speeds (eg, a 1G MGMT interface).
The metadata output from the analyzer 106 can also be retrieved by the output subsystem 120 and output externally through the interface 118 to other tools such as the Security Information and Event Management (SIEM) tool 19 it can.
Open approaches and technologies can be applied to information community integration.
Embodiments of the system 10 also provide a dashboard showing workload routing of data weighted by work, overall analysis status, trending files, hosts, and hit snapshots.

An analytical approach or embodiment is to do the following:
1. Use tools that analysts prefer (do not prevent or re-execute) and allow them to work cooperatively at the network gateway for faster identification and meta-analytic recognition. .
2. Deliver unprecedented new analysis so that current capabilities are praised by providing resilient, accurate and fast malware detection.

With continued reference to FIG. 1A, an embodiment of the system 10 for network data characterization hosts seven user-configurable analyzers 108.
Table 1 below provides a list of the analyzers 108 hosted in the system 10 embodiment.

Analyzer: Description
Hector: A highly configurable machine that learns based on an analyzer for detection of previously invisible malware
hURI: A machine learning approach to suspicious URL characterization
ClamAV: Signature-based analyzer for malware detection
Extractor: Password cracker analyzer for encrypted archive files
PEScanner: portable executable analyzer for PE32 and MS-DOS
YARA: Rule-based pattern matching analyzer for malware detection
Intel Lookup Intel Lookup: Intel correlation analyzer for signed processes

Hector is a prophetic and machine learning private analyzer that uses highly configurable machine learning prediction techniques to detect previously invisible malware, and content is malicious Feature-based to detect malware and classify or characterize content using a percentage that indicates the likelihood of being full (ie, a confidence percentage that indicates the confidence that the file is malicious) Use analysis and characterization.
The Hector embodiment and the process used by the Hector embodiment are described in pending US Patent Application No. 14 / 038,682, entitled “Automated Machine Learning, Improved System and Method for Zero-Day Malware Detection”. And are therefore incorporated by reference in their entirety.
The Hector Analyzer embodiment uses a feature-based algorithm or outputs a confidence percentage of whether the file is malicious based on a comparison of features derived from the file, and the content is malicious A process can be used to determine if it is a thing, and a classifier built from known malicious file and known safe file features can be used.
Embodiments may also host a private analyzer of hURI that utilizes highly configurable machine learning techniques, for example, to classify URLs as suspicious, clean, or dirty.
The hURI sensor can classify URLs based on semantic analysis of domain names.

Embodiments may host third party or open source tools for network data characterization.
For example, an embodiment of system 10 may host a signature-based analyzer for malware detection, such as ClamAV. Embodiments of the system 10 may host a password cracker analyzer for encrypted archive file analysis and characterization, such as an Extractor.
Embodiments of the system 10 may host a portable executable analyzer for analysis and characterization of PE32 and MS-DOS executables such as PEScanner.
Embodiments of the system 10 may host a rule-based pattern matching analyzer for malware detection and characterization such as YARA.
Similarly, embodiments of system 10 may host an Intel correlation analyzer for signed processes such as Intel Lookup.
These and other analyzers may be hosted by the system 10 embodiment.

Machine Learning: Automated Search (Search) and Discovery According to the continuous reference in Figure 1A and Table 1, machine learning, such as that used by Hector and hURI, is of different types through exposure to various example objects. Or it is used to train computers to distinguish class objects and has been successfully applied in many areas such as face recognition, speech recognition, and image processing.
An important step is the selection of object features that are used to learn class differences.
The result of the learning process is called a classifier.
The classifier allows the computer to predict a class of objects that the computer has never seen before and can therefore be used to search for similar types of objects.
Automation of machine learning algorithms greatly reduces the time required to investigate the entire object space.

For example, in the Hector embodiment used in the network data characterization system and method embodiment, machine learning is based on a complex combination of features to distinguish malware from secure software. Applied to build and to search large amounts of traffic.
Embodiments of network data characterization systems and methods examine network traffic and human analysts focus on examining events that are likely to occur.
This approach has different advantages than the signature and sandbox based approach. First, in Hector, the approach utilized by the embodiments described herein is all, ie, to very high traffic volumes so that all or virtually all network traffic can be inspected. Expanded.
No other form of pre-filter or upstream decimation is necessary. Second, unlike signatures or actions, the Hector classifier is resilient to changing malware and tactics.
It has been shown that classifiers can detect threats even years after the threat has changed.
This increases the likelihood and accuracy of detection.
Hector embodiments support the analysis of the following file types: PE32s, PDF, MS-DOS executable, MS Word, PowerPoint, Excel, CDF / MSI, Android APK, JAR, ELF, Windows Installer XML, Bit Maps and GIFs.

It should be noted that competitor malware detection tools rely on information indicative of previously detected malware.
These tools create and update a hash that indicates whether the file is previously detected malware.
The problem with this paradigm is that it relies on previous detections of malware reported to malware detection tools.
Thus, it may take days, weeks, months before malware is detected and included in the detection tool.
Also, such tools only analyze files that match their hashes, and always pass malware that was not previously detected.
Embodiments described herein that utilize Hector and other machine learning techniques detect malware in near real time without concern for hashes.
The embodiments described herein analyze all received files, not just those that match the hash.
Furthermore, embodiments can analyze all received files, even those that cannot be practically handled with current sandbox tools.

With continued reference to FIG. 1A, the characterization sensor 12 can be implemented as a single container physical appliance (ie, one box). The characterization sensor 12 can be implemented as a 2U x86-based appliance with 256GB memory.
In an embodiment, the characterization sensor 12 has two 1 Gbps RJ45 management network interface cards (NICs) and two to six 10 Gbps SFP + high-end data processing NICs.
The characterization sensor 12 can run on enhanced CentOS and is managed using encrypted and signed RPMs.
The characterization sensor can be implemented on multiple x86-based instruments, other processor-based instruments, eg, a server stack with blades.

Interoperability: The interoperability of the embodiments described herein can be provided through an open standards-based interface.
For example, embodiments provide RESTful API services that expose data in syslog, common event format (CEF), JSON, XML, and other standards.
Embodiments implement the trusted automated eXchange of Indicator Information TAXII and consumption of other Structured Treat Information Exchange STIX standards.
The extracted files can be made public for interoperability in a wider analysis ecosystem.

Scalability: Embodiments can be scaled higher than 10 Gbps data rates by standard load balancing techniques.
To reduce the processing required for the machine learning approach, much less hardware is required than to extend the sandbox-based approach.
Next, with reference to FIG. 1B, another embodiment of a system 10 for network data characterization is shown.
As shown, an embodiment of the system 10 is a data grid approach to management that includes a plurality of characterization sensors 12 where the characterization sensors 12 are arranged in a peer-to-peer mesh. Can be implemented.
In the illustrated data grid, the individual characterization sensors 12 share a non-volatile state in a robust and transactional manner, thereby removing the central administrator and data and configuration. ) To provide redundancy and simplify overall management and architecture.
In this method, multiple characterization sensors 12 are connected to each other in a peer-to-peer mesh called a data grid, and each characterization sensor 12 provides resiliency and redundancy to the other sensors 12.
In such an arrangement, the characterization sensor 12 can share the disk 110 and the database 112.
Alternatively, individual characterization sensors 12 can internally maintain a dual storage location for internal disk 110 and database 112 (not shown in FIG. 1B).
In this way, a small cloud of characterization sensors 12 can be replaced based on other characterization sensors 12 with redundant settings and data if one characterization sensor 12 is in offline operation. Implemented.

Performance: The embodiment is designed to work with 1 and 10 Gbps network links.
Embodiments may be intended to be built for in-memory analysis of various protocols and large amounts of web traffic on high-speed gateway links.
This allows for the collection of up to 1000 objects per second and the typical amount of traffic for corporate gateways for web and email protocols.

Security: Embodiments can be managed as encrypted RPM package managers (RPMs) on a strong CentOS platform that leverages a trusted platform module (TPM) that supports hard disk encryption. Good.

Next, with reference to FIG. 2, an embodiment of a method 20 for network data characterization is shown.
The method 20 may be implemented by a system that includes a characterization sensor as described herein, eg, with reference to FIGS. 1A-1B.
The method 20 receives network data (block 202).
As described above, the characterization sensor 12 can receive network data (eg, events) through an interface that connects to the external network 14 and / or the internal network 16.
The data collector can receive network data as a data supply device, for example as an SMTP, HTTP, and FTP supply device.
The data collector may assemble events and content from the received network data (block 204).
As mentioned above, an event may include content (eg, a file). Furthermore, embodiments may allow content (eg, files) to be uploaded, for example, by a GUI / CLI-based collector for manual file upload, or by a file-based API collector ( Block 206).
Events and content are converted into data messages (block 208).
The message may include metadata identifying the events and content contained therein.
The message is forwarded (routed) to one or more of the plurality of analyzers in the characterization sensor 12 based on one or more signatures of the individual analyzers, block 210.
The analyzer signature may be defined by specific message criteria.
If a given message meets the specific message criteria of the analyzer signature, for example if the message is determined by comparing the specific criteria with the metadata contained in the message, The message is forwarded (routed) to the analyzer.
As mentioned above, individual analyzers can sign one or more types of messages, and in the method 20 embodiment, multiple analyzers can sign the same type of messages.

Also, forwarding (routing) messages (210) can be based on resource allocation, processing time and load.
For example, embodiments may configure multiple characterization sensors 12 in a peer-to-peer grid, as described below.
As such, forwarding (routing, 210) may take into account the current load of a given characterization sensor, and in order to better balance the load being processed, messages may be sent to different characterization sensors. And 210 may be forwarded (routed).

When the analyzer receives a signed and forwarded (routed) data message, the analyzer analyzes the content contained in the data message with specific analysis algorithms and techniques, and based on that analysis, A characterization result is generated (block 212).
The result of the characteristic evaluation may include metadata describing the analysis, the result of the characteristic evaluation, and the analyzed content (eg, a file).
Analyzed files are tagged with, for example, metadata and a percentage display that indicates whether the file is malicious, the file is safe, or the file may be malicious. May be.
As noted above, embodiments include multiple analyzers including proprietary analyzers, third party analyzers, and / or open source analyzers.
Embodiments include machine learning analyzers such as hector and hURI as described above.
Multiple analyzer characterization results can be collected and combined and output from, for example, a scalable file analyzer, for visualization in the system GUI or other subsequent actions based on criteria and thresholds (Block 214).
Characterization results may include, for example, a flag or other indication that the analyzer considers the file to be malicious or considers the percentage of the file's likelihood of being malicious it can.
Output (214) may include saving the characterization metadata in a database and saving the classified files in disk space.
Output (214) is an additional processing of the characterization data results so that the combined characterization results are provided in a way that is useful to the user (eg, through the GUI described herein). May be included.

With continued reference to FIG. 2, the characterization results can be compared to criteria and thresholds (block 216).
The criteria and thresholds may be modified and set based on the needs and requirements of the enterprise or based on other users of the system.
If the criteria are met, then a subsequent action to be taken can be commanded, while the threshold value can command whether the analyzed content meets a threshold value that should be considered malicious.
For example, if the characterization results indicate that Hector considers the file 65 percent (65%) malicious and the business user sets the threshold as 50 percent (50%) to flag the file as malicious Set the criteria to be labeled, flag the file to include more review results lists by the company, include the file in the GUI visualization of the system, direct more action, etc. If so, then the system takes the displayed action.
As a result, the method 20 is visualized and / or takes other actions based on the comparison (216) (block 218).

As mentioned, the criteria and thresholds for visualization can be adjusted.
That is, the reference and threshold can be modified and set by the user.
In the characterization sensor embodiment, the criteria and thresholds may be set to a default level based on, for example, an understanding of the security sensitivity of a company or other user.
For example, if there is an ever-increasing risk to the company, the threshold may be set lower to flag, list, and visualize the file as malicious.
Companies and other users can adapt or adjust these settings based on the results of their initial settings or subsequent settings.
For example, if a large number of files are flagged and visualized for effective subsequent review, the criteria and thresholds for such flagging and visualization may be increased.
As a result, the method 20 can determine whether the user has set a change in the criteria and / or threshold (block 220).
If changes are set, the method 20 accepts changes to the reference and / or threshold (block 222) and processes these changes (block 224).
Process 224 causes a change and causes the system to re-comparison the results of the characterization with criteria and thresholds (216) and to take visualizations and / or other actions based on the re-comparison. Can (218).
If no change occurs in the criteria and / or threshold, as described above, method 20 receives network data (202) and continues characterization or classification.

Reference is now made to FIG. 3 to illustrate a process that describes in more detail how an embodiment of the network data characterization method 30 processes the characterization results.
The process shown is how the embodiment of method 30 compares characterization results to criteria and thresholds (see, eg, block 216), visualizes, and / or other based on the comparison. Indicates whether an action can be taken (see, for example, block 218).
The method 30 may receive characterization results from an analyzer (eg, from a scalable file analyzer) (block 302). The current criteria and threshold settings are retrieved (block 304).
The method 30 determines which criteria and thresholds are met, for example, by comparing the characterization result metadata with criteria and / or thresholds (block 306).
The method 30 can then take any one or more of various actions based on the decision 306 (block 308).
FIG. 3 describes examples of actions that the embodiment may take (308).
Note that further analysis can be performed by an external analyzer.

Next, with reference to FIGS. 4A and 4B, a dashboard visualization GUI 40 screen depicting visualization of the generated characterization results by an embodiment of a system and method for characterization of network data A shot (screen copy) is shown.
As shown in FIG. 4A, the dashboard visualization GUI 40 can provide an indication of the characterization status of events received within a certain period of time (eg, the last hour).
For example, a characterization status is unknown, trusted, malicious, suspicious, or needs further review.
The dashboard visualization GUI 40 may also include a depiction of the file data flow within a certain period of time (eg, the last hour).
The file data flow illustrates the amount of file source types received within a period of, for example, HTTP, SMTP, FTP, CLI inject file, and GUI upload file.
The flow also illustrates an analyzer that analyzes the received content and the amount of files that are signed, received, and analyzed by individual analyzers.
Dashboard visualization GUI 40 also illustrates the amount of analysis files classified as malicious or likely malicious (eg, flagged) by various analyzers .

Next, with reference to FIG. 4B, the dashboard GUI 40 determines the number of files that are considered malicious or likely to be malicious (eg, flagged) over a period of time. Depending on the type of file, it is illustrated.
In addition, the dashboard GUI 40 provides a ranked list of malicious events or sources of potentially malicious events (referred to here as hosts) within a period of time (eg, suspicious hosts). Is provided.
The ranked list is ranked by the number of malicious events received or likely to be malicious from the host or source.
In addition, the dashboard GUI 40 ranks files that are flagged as malicious or likely malicious by an analyzer (eg, Yara, ClamAV, Hector, etc.) or all analyzers. Other ranked lists may be provided, such as a list.
The results of the characterization and other data drawn on the dashboard GUI are determined by the criteria and thresholds set as described above and can be configured by the company or other users.

Next, referring to FIG. 5, the events classified by the network data characterization system and method embodiment (as containing malicious, suspicious or more reviewable content) are listed. As a result of the characteristic evaluation, a visualization GUI 50 is shown.

The characterization result visualization GUI 50 will, for each file classified as such, date and time stamp, source IP address, recipient or target IP address, host name (or IP Graphical indication of whether it is address), malicious (eg, red X), suspicious (eg, orange exclamation mark), or something that requires further review (eg, blue flag) And a graphical display of analysis / characterization results (eg, a graphical display of file types (eg, Windows, Word, MS-DOS, etc.) and one that classified the content as malicious or suspicious. Or multiple analyzers (for example, an icon showing the analyzer) and malware file name if known) Or it may be you.
In the implementation, the content listed and displayed in the characterization result visualization GUI 50 is intended to be further considered or analyzed by a company or other user. As a result, the user may wish to further filter the results.

One of the advantages of the network data characterization system and method described herein and the analyzer embodiments utilized, such as Hector, is that the risk of false negative is minimized. is there.
False negative means that a malicious event or file is mistakenly classified as safe.
Unfortunately, the embodiments that include the hector described herein are so effective that sometimes very many detected events are generated.
Users need to have tools to manage the results so that they can be reviewed effectively.
As shown, the characterization result visualization GUI 50 can provide a variety of filters to a filter tool that allows a user to filter the results displayed by the characterization result visualization GUI 50.
For example, the characterization result visualization GUI 50 can be used for file name, file type, source IP address, host name, target IP address, classified time, analyzer characterization or classification, file name cryptography The results can be filtered by hash function (eg, secure hash algorithm (SHA) -256 hash of file name), file size, etc.
These filters allow the user to better manage the results.

Next, with reference to FIG. 6, a characterization or classification result visualization GUI 60 is shown along with the filtered results.
The characterization results shown are filtered by the SHA-256 hash of the file name.
In other words, only those characterization results that have the same SHA-256 hash are listed.
As shown, time / date stamp, destination or target IP address, destination port, source IP address, source port, host name (host name for source that can be derived from raw network data packet Is listed, and shows a graphical display of whether additional research intelligence is available for the file, status (malicious, suspicious, requires further review), and analysis / characterization results.
The characterization results can be sorted by all of these categories.

Next, with reference to FIGS. 7A-7B, a detailed visualization GUI 70 of the classified or characterized file is shown.
In order to view the detailed visualization GUI 70 of the classified file, one of the results shown in the characteristic evaluation result visualization GUI 60 is selected.
The characterized file detail visualization GUI 70 depicts additional details of the categorized file and provides further action options chosen by the user.
For example, details may include the following.
Analyzer that classifies files as malicious or suspicious, Hector confidence percentage (eg, shows a bar graph with confidence threshold display set by a company or other user), file metadata (eg , File name, file type, string of associated details (magic string “Magic String”), file size, file cryptographic hash (eg MD5 and SHA-256 hash), most classified file Bar graphs showing the frequency of files detected over the last few days, including further review (internal or external), file quarantine, including when recently viewed and when first viewed) , Action selection like file deletion suggestion, file details download, (by user Set status for file review, summary of analysis results showing applicable analyzers (ie, analyzers who have signed messages containing classified files) and characterization results (for example, none (Yara ), Malware name identification (ClamAV), or confidence percentage (hectare)), data and other intelligence in the next analysis, and a list of recent events, including the classified files, if any.

With reference to FIG. 8, the rule setting GUI 80 is shown.
Rules are another tool that users can use to manage characterization or classification results.
For example, the user defines rules that define how certain characterization results are handled, including what actions are taken by selecting the rules tab shown in Figure 5 and Figure 6. can do.
For example, a user has a certainty hectare level of hectare over a certain percentage, for example, from a certain host or source IP address, and includes a certain filename, You can enter a query string for a rule that assigns an address to the target IP address.
The user can either drop an event that matches the query or set a certain status of action to be taken so that the status of the event is set to require trust, unknown, suspicious, malicious, or further review. A type can be defined.
The embodiment also processes the rule immediately so that the user can see the immediate impact of the rule, and in the rule configuration GUI 80, it is new for a certain period of time (eg, the previous 5 days). Displays the number of events that the rule would have matched.

Another tool provided by embodiments of methods and systems for network data characterization is the ability to pinpoint results.
Next, referring to FIGS. 9A-9E, a characterization result visualization GUI 90 with a pinpoint tool is shown.
The pinpoint tool allows the user to select a time frame (for example, a time and date range) of events that have been classified for display, and sort and display the results using a descending / ascending classification method. Filter results by various metadata (see above), eg host, input source type, file type, application type, classification method (flag), domain name, location, time, file Group the results by whether they are “signed” (ie, certificates, signed from a “trusted” authority), or all metadata or characterization results Included in the results of characterization or characterization allows the results to be grouped.
Literally, the pinpoint tool characterizes the categorized events and content used to select hundreds of characterization result metadata and to pinpoint the results, group the results, and sort the results And provide.
Actually, the pinpoint tool 90 is a tool for showing the result workflow of the analyzer.

The results of the event characterization listed in the characterization result visualization GUI are filtered and listed based on the pinpoint tool 90 selection.
Further, the pinpoint tool 90, when operated, lists the results of the pinpoint selection.
For example, as shown in FIG. 9B, the pinpoint tool lists the number of events detected and classified by the host and indicates how those events were classified (with appropriate flags).
In the example shown, the host with the most characterization results is bluvector.cli.inject.
The host has 551 events flagged as safe, 4401 events flagged as unknown, 31 events flagged as suspicious, and malicious Has 275 events flagged.
The user can expand the pinpoint results list, as shown for example under a given host, to indicate the input source type of the flagged event, for example, HTTP, CLI_INJECT, SMTP, and FTP Can do.
Similarly, as shown in FIG. 9C, the user can provide a given input source, for example, to indicate the type of file (eg, image file, cdf, html, jar, elf, pe32, pdf, dos, apk, etc.) Below the type, you can expand the pinpoint results list.
Similarly, as shown, the user can expand the pinpoint results list, eg, under a given file type, to show the analyzer that classified the file (eg, ClamAV, Hector, Yara, etc.) Can do.
As shown in FIG. 9D, the pinpoint tool allows the user to change the grouping order so that different categories are used for the initial grouping.
For example, the input source type (eg meta.app) is used as the first grouping and the input source type (eg http, null, cli_inject, gui_upload, smtp, ftp) is expanded to get other information Is done.

As described above, the pinpoint tool 90 can accurately indicate (pinpoint) the results based on any of the metadata that provided the results of the characterization by the analyzer.
With reference to FIG. 9E, a pinpoint tool 90 set up to group the results based on the language used in the file is shown.
The analyzer may not be able to determine the language that was used all the time, but if the language can be determined, then embodiments of methods and systems for network data characterization will be based on the language. Filter and group results.
For example, as shown, results using English, Russian, or Chinese can be displayed. Unknown language results may be grouped as neutral.
This is particularly beneficial when an enterprise is aware of a threat that originates in a certain country or region or is primarily concerned with a threat that originates in a certain country or region.
The pinpoint tool also filters by results that include certain signatures (ie, malware signatures that have been detected previously, eg, detected by PEScanner) or by results that are detected only by certain analyzers, It may be divided into groups.

One of the most powerful aspects of method and system embodiments for network data characterization is that they greatly increase the usefulness and effectiveness of the results of machine learning analyzers (eg, hectares). is there.
With reference to FIG. 10, the files sorted by file type are sorted and a histogram is displayed showing the number of files of that type sorted by the machine learning analyzer into various characterization confidence percentage ranges. A characterization trust GUI 100 is shown.
To be refreshed, the confidence percentage is the percentage confidence that the file is malicious, as determined by the machine learning analyzer.
The trust GUI 100 also sets the threshold set for each file type, the number of files of that file type that have a certainty percentage that exceeds that threshold, and the hit rate percentage (the number of files of the file type, the total number of files The percentage of files that exceed the confidence percentage divided by.
The trust GUI 100 helps the user to visualize the number and percentage of results and determine whether the threshold is too high or too low.

Next, with reference to FIGS. 11A-11B, a configuration GUI 110 for setting a threshold of confidence percentage is shown for each file type.
As shown, the threshold can be set on a slider bar.
Embodiments provide one recommended threshold setting for each file type.
This recommended threshold setting can be determined by a machine learning analyzer.
For example, the post-analysis results can later be fed back to a machine learning analyzer that indicates the confidence percentage of separately confirmed malware.
These results can be used by embodiments to set a recommended threshold.
This ability to set different configurations, thresholds and visualize the results of the analyzer in another way makes it very easy to adapt the system to analyst workload capabilities.
As shown in FIG. 11A, the configuration GUI 110 is flagged with the current threshold setting (configuration) as well as the percentage of the file of the given type flagged beyond the threshold percentage. Can show the number of files per day.
If the threshold percentage setting is changed, the configuration GUI 110 will flag the new threshold percentage as well as the percentage of the given type of file flagged beyond the new threshold percentage, as shown in FIG. 11B. Can be used to indicate the expected number of files per day that will be flagged.
This information can allow the user to determine what threshold percentage is beneficial to the user's enterprise.
Also, as can be seen in FIGS. 11A-11B, the user can also select or deselect the file type that the analyzer will sign in the configuration GUI 110.
These choices determine which file types are transferred (routed) to that type of analyzer (see Figure 1-2 above).

Those having ordinary skill in the art will recognize that various modifications and changes can be made to the embodiments described above without departing from the spirit and scope of the invention.
Accordingly, it should be understood that the invention is not limited to the specific embodiments disclosed above, but is intended to encompass modifications and variations as defined by the following claims.

Claims (22)

At least some of the network events receive network events including content;
Converting the received content into a data message, wherein at least some of the data messages include the content and metadata describing the event and the content;
Forwarding the data message to multiple analyzers based on specific message criteria signed by individual analyzers;
Each of the one or more analyzers receiving the forwarded data message analyzing content in a data message to characterize the content;
Including at least one machine learning analyzer that classifies content by a confidence percentage that indicates the likelihood that the content is malicious or that the prediction that the content is malicious is correct;
Outputting a result of the characterization of the one or more analyzers; and determining the subsequent action to be taken based on the result of the characterization, a plurality of criteria, Compare,
A computer-implemented method for network data characterization. Receiving the network event;
The method of claim 1, comprising receiving network data from one or more network data supply devices including HTTP, FTP, and SMTP data supply devices.   The method of claim 2, further comprising reconfiguring the network data into events and content. Receiving the network event;
The method of claim 1, comprising receiving uploaded content from a command line interface or a graphical user interface.   The method of claim 1, wherein the content comprises a file.   The method of claim 1, wherein the outputting comprises combining results of characterization of one or more analyzers.   The method of claim 1, wherein the output characterization results include characterization metadata describing the classified content and characterization results.   A tag indicating whether the output is malicious, suspicious, safe, unknown, or something that needs further review is added to the classified content. The method of claim 1 including applying.   9. The method of claim 8, wherein the outputting includes storing the classified and tagged content on a disc.   The method of claim 7, wherein the outputting includes storing characterization metadata in a database. Subsequent actions are to store the classified content and characterization metadata,
The method of claim 1, comprising modifying network traffic, or forwarding the classified content to an external analyzer.   The method of claim 1, wherein an analyzer can sign the same type of message or a different type of message than other analyzers.   The method of claim 1, wherein the particular message criteria that the analyzer signs comprises a file type, an event source, or an event destination.   The machine learning analyzer uses features-based processing to determine a confidence percentage based on a comparison of content features, and features known malicious files and known safe files. The method of claim 1 including a classifier constructed using the method.   The method of claim 1, wherein the forwarding also forwards the message to the analyzer based on a resource allocation factor.   The method of claim 1, further comprising generating a visualization of content characterization by the machine learning analyzer.   The visualization is determined based on one or more threshold levels or other criteria set by the user, the threshold determining the number of events that are classified as suspicious and require user attention. The method of claim 16.   20. The method of claim 17, further comprising receiving an input to change one or more threshold levels or other criteria.   19. The method of claim 18, further comprising indicating a prediction of future characterization results based on changes in one or more threshold levels or other criteria. With one or more characterization sensors including one or more processors and memory,
The memory includes instructions for execution of the following processes by one or more processors:
The processing performed is
At least some of the network events receive network events including content;
Converting the received content into a data message, wherein at least some of the data messages include the content and metadata describing the event and the content;
Forwarding the data message to multiple analyzers based on specific message criteria signed by individual analyzers;
Each of the one or more analyzers that receive the forwarded data message that analyzes the content in the data message to characterize the content may be that the content is malicious Including at least one machine learning analyzer that classifies content by a percentage of confidence indicating gender or certainty that the prediction that the content is malicious is correct;
Outputting the characterization results of the one or more machine learning analyzers; and a plurality of the characterization results output to determine subsequent actions to be taken based on the characterization results; A system for network data characterization that is to compare with criteria.   The system of claim 21, wherein the machine learning analyzer is implemented by one or more characterization sensors.   The one or more characterization sensors include one or more interfaces that connect an external network external to the company that hosts the one or more characterization sensors and an internal network that is internal to the company. The system of claim 21.