+

WO2009049570A1 - Procédé de détection de l'état d'un code - Google Patents

Procédé de détection de l'état d'un code Download PDF

Info

Publication number
WO2009049570A1
WO2009049570A1 PCT/DE2007/001858 DE2007001858W WO2009049570A1 WO 2009049570 A1 WO2009049570 A1 WO 2009049570A1 DE 2007001858 W DE2007001858 W DE 2007001858W WO 2009049570 A1 WO2009049570 A1 WO 2009049570A1
Authority
WO
WIPO (PCT)
Prior art keywords
virtual
update
job
data
code
Prior art date
Application number
PCT/DE2007/001858
Other languages
German (de)
English (en)
Inventor
Andreas Bruns
Felix Lindner
Stefan Tewes
Original Assignee
N. Runs Ag
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by N. Runs Ag filed Critical N. Runs Ag
Priority to PCT/DE2007/001858 priority Critical patent/WO2009049570A1/fr
Priority to DE112007003737T priority patent/DE112007003737A5/de
Publication of WO2009049570A1 publication Critical patent/WO2009049570A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3698—Environments for analysis, debugging or testing of software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3668—Testing of software
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/566—Dynamic detection, i.e. detection performed at run-time, e.g. emulation, suspicious activities

Definitions

  • ParsingCode is easiest to influence when reading in and interpreting data from attackers because it can directly influence this data and thus the code.
  • the invention is therefore based on the object to provide a method of the type mentioned, which eliminates the disadvantage of the prior art and, for. provides a secure AV solution.
  • the gist of the invention is that the virtual machine is completely isolated from the outside world, the control in the virtual machine is performed by an outside process, and in case of suspicion that part of the machine is immediately destroyed. The dangers and the viruses of all kinds can therefore no longer propagate in the real machines and cause damage there.
  • the virtual machine only data from a console and / or the virtual database and / or a virtual memory.
  • parameters of the virtual machine are analyzed and / or checked by a virtual machine controller.
  • the virtual data memory organizes itself and / or optimizes itself.
  • the distribution engine the code classifies and caches it in direct processing to one and / or more virtual machines and / or caches in the virtual memory and / or enters into a virtual queue.
  • the output is considered defective if at least one of these parameters deviates from the standard.
  • the time factor is a crucial factor. After entering a code, the time span for its examination must be minimized in order to be able to continue working on it for a corresponding examination result. For this purpose, it is advantageous if one and / or a plurality of virtual machines for checking the code are operated simultaneously with one and / or a plurality of real and / or virtual machines for processing the code for a trigger point and in the event of a fault of the testing machine, the processing Machine is reset to the trigger point.
  • testing machine and the testing machines have to be arranged within one room.
  • the possibility It is advantageous if the testing machine and the processing machine are connected via a network.
  • a testing machine in a company can be connected to the other processing machines.
  • the basic form for carrying out the abovementioned methods advantageously comprises at least one interface, at least one virtual controller, at least one virtual memory and at least one virtual machine, all of which cooperate with one another.
  • Fig.l Pasings-Safe components and main modules
  • Fig. 3 cash job managers (FSM);
  • Fig.4 Total time for 1 million records
  • Fig.5 Average time for 1 million records
  • Fig.6 Database size for 1 million records
  • Fig.7 Distribution of the sizes of MIME object sizes in 42,000 emails
  • FIG. 9 shows a detailed view of the module shown in FIG.
  • Fig. 10 is a diagram for explaining the operation of the virtual machine.
  • the method of detecting the state of one and / or more codes is performed by inputting the code and / or the codes into one and / or more virtual machines that activates and / or codes on the and / or the virtual machines is that the virtual machine outputs one and / or more parameters, one and / or more signals (eg, OK, not OK) about the function of and / or the code. If the function of the code does not comply with the specifications, the virtual machine will be deleted completely.
  • a code for recognizing its state via at least one front-end hereinafter called FE, entered, via at least one distribution machine or
  • Distribution Engine in the following called DE, managed and / or virtual machines, also execution
  • the communication is controlled via a link layer or protection level, namely from FE to DE and then DE to EE.
  • the code may be an executable code, an operating system, a program, and / or data and / or data attachments.
  • the transfer to the virtual machine is done by writing the code to a virtual database.
  • the DE classifies the data according to FE and collects it, for example, in queues, stacks, queues, intermediate stores, or else it passes on directly for possibly different types of EEs.
  • EEs may be, for example, virtual Turing machines and / or a so-called execution requirement.
  • the data in all modules in more than one queue eg parallel, serial and / or virtual.
  • These data are collected eg in the queue, stack, queue and / or buffer until a threshold value, trigger, a state, eg data volume, waiting time or cycle time, is exceeded or reached.
  • a so-called time jump is also possible, ie a significantly longer runtime is simulated in a short runtime.
  • the virtual machine controller analyzes and / or checks the parameters of the virtual machine. A signaling for correctness to the external system and / or a test for the existence of the activated virtual machine then takes place. If the virtual machine still exists, the code is still considered correct. Then, the outputs of the EE are returned to the FE together with the information as to whether the processing was successful.
  • the signaling takes place without connection by means of status data to the data memory and / or the virtual memory by interrogation and / or "write-over" of the data memory.
  • the output is considered as defective if at least one Parameter is faulty.
  • the data from multiple EE's and the output are considered faulty as soon as at least one EE produces a faulty output.
  • Figures 9 and 10 further show that at least one EE of the appropriate type is created and the data is e.g. from the queue to be passed. However, it is also possible for several EEs to be processed in parallel, serially, virtually, started, processed or "run.” After the end of the processing by the EE, the results and / or outputs and / or the system states of the EE are checked.
  • the EE is irretrievably destroyed after the output, or put into a defined state, so that the execution EE has no further influence on the overall system.
  • the output will be e.g. regarded as defective as soon as at least one EE produces a faulty output.
  • n of m for example in time dependence.
  • one or the virtual test machines can be operated in parallel with a real and / or virtual processing machine simultaneously to a trigger point, on the above described way. Should an error occur that is reported by the virtual test machine to the processing machine, then the processing machine is reset to the trigger point so that no more damaging or faulty code is left in the processing machine.
  • the virtual machines can then be e.g. in a data center that can be accessed and fed from outside with the appropriate codes.
  • each virtual machine operates in such a way that virtual time jumps and / or virtual memory changes and / or virtual multiple applications can be performed. Memory changes can be overflows or decreases in data.
  • a simple system for carrying out the described method therefore consists of at least one interface or front-end FE, at least one virtual controller, or Distribution Engine DE, at least one virtual memory and at least one virtual machine EE.
  • ParsingSafe is a multi-layered architecture for the isolation of potentially malicious external data.
  • the goal of the architecture is to behave almost like an ordinary antivirus solution while achieving maximum security and scalability.
  • the general design model was based on a class 4 high-security laboratory for the study of biological viruses.
  • ParsingSafe's design approach is very similar to a Class 4 biological laboratory.
  • the processing of potentially malicious external data is limited to a virtual machine running on a hardened LINUX system.
  • ParsingSafe uses a distributed infrastructure to counteract a potential performance problem in parallel execution. It also allows ParsingSafe to leverage multiple antivirus solutions in any combination to streamline content inspection in a corporate environment.
  • Components ParsingSafe consists of the following components:
  • An input / output front end is an independent process on a separate computer that is capable of communicating with a ParsingSafe infrastructure by implementing the associated ParsingSafe protocol.
  • An IOFE can be a service that provides a command line interface to search files for malware. It can also be an SMTP inline proxy that scans incoming emails for malware before forwarding them to the internal mail server.
  • the ParsingSafe Distribution Engine (DE) is the ParsingSafe Distribution Engine
  • the DE does the detection of already examined external data (cache),
  • VMC Virtual Machine Control ParsingSafe Virtual Machine Controls
  • ParsingSafe will use the Microsoft Virtual Server R2 (or higher) as a virtualization platform.
  • the Virtual Server can be automated and controlled both remotely and locally.
  • the file format used for virtual hard disks is known and it is guaranteed by the Microsoft License Agreement that there will be no significant changes in future versions of the product in this respect.
  • Microsoft will continue to develop the product and support new virtualization technologies without the need to change ParsingSafe.
  • ParsingSafe uses Linux as a guest OS within the virtual machine. It uses a special simplified version of a Linux operating system with exceptionally fast startup behavior. The Linux kernel is hardened using additional security patches against exploits.
  • ParsingSafe also provides an interface for administration purposes.
  • the administration interface is a C lient server A rchitecture which on the administrative workstation (client) as well as on the system is running, which hosts the DE.
  • the administration interface uses the same protocol as the other components.
  • ParsingSafe can be grouped into three categories:
  • Edge components are all components with interfaces to external systems or people. This also includes the IOFE and the
  • Platform or platform components are all components that contain the inner workings of ParsingSafe. This includes all modules of the Distribution Engine as well as both sides of the Virtual Machine Control Layer.
  • Virtual Machines are instances of a guest OS interacting with an existing antivirus solution that performs a scan.
  • ParsingSafe components and modules must always validate data that is passed to them.
  • ParsingSafe provides operational support across the entire platform
  • ParsingSafe consists of the implementation security of the product itself, its communication channels, and all guest OS installations, and by practicing thorough defense, authentication, and secure parsing.
  • the expected attacker is usually entertaining and highly knowledgeable.
  • ParsingSafe is built to deliver stable performance but never compromise security breaches.
  • ParsingSafe identifies samples (external data to be examined) by the cryptographic hash over the entire binary block of the file. It works with a so-called primary hash of external data.
  • the primary is a so-called primary hash of external data.
  • Hash function is fixed and can not be changed easily. Resistance to collisions is not an urgent requirement for this hash function, since
  • E-mails that come back negative from the DE are sent by the SMTP client to a configured internal MTA to deliver the mail. If the communication with the internal MTA fails or does not accept the email, the email is placed in a special directory for undeliverable messages.
  • a cache record contains the following data: • a primary hash
  • Permanent entries are not to be deleted by aging procedures and must be retained in the event of a cache reconstruction or restoration.
  • the number m of scan result entries, as well as the number n of secondary hashes, will be displayed during installation and / or Migration set. Changes in the hash algorithms or available resident AV types require rebuilding the cache.
  • These two lists in a chache record are short-name and value. Short names have a fixed size, the result status is 1 byte, and the value fields of the secondary hashes are of fixed size depending on the largest output of the secondary hash algorithm.
  • Cache entries must be removed from the cache by a timeout after a configurable time interval. The default value for the timeout interval is 24 hours.
  • the cache is generally implemented in two sub-elements: an in-memory cache structure and an in-memory cache structure.
  • a cache entry must be written to both the in-memory and in-memory structures when it is created.
  • the cache-in-storage backend is critical to fault-tolerant operation and must support the following features:
  • the cache must ensure that sufficient disk space is available in the configured storage location to perform the above actions.
  • Jobs containing a VHD image update will be placed in a separate Scheduler Update Queue. This queue is queried by the VMCM (see 2.6.3.5).
  • the scheduler runs a global queue for JobCollections, which are returned by pooling.
  • the global FIFO queue appears to the entire set of VMs and VMCs in the backend as a single resource.
  • the VMCM requests JobCollections from the global queue as soon as it has resources to process them.
  • the VMCM can mark problematic VMCs with "brown flagging” if they show questionable behavior. Brown-flagged VMCs are disconnected and reported to the administration server. They remain disconnected until the administrator manually removes the flag from the VMC.
  • the VMCM manages a list of all VMCs and all their VMs containing at least:
  • the VMCM For each VMC, the VMCM keeps a record of an update
  • Pending flag contains. If this flag is set, the VMCM has updates that have not yet been used for the VMC.
  • the VMCM operates approximately according to the following algorithm:
  • a "brownflagged" VMC is "disconnected from the VMCM at a high level.” This means that the VMC has been removed from the VMC list and no new jobs are being assigned to it.All in progress jobs for the VMC are considered lost and any communication originating from the VMC will be discarded and the VMC will remain flagged until the admin server deletes the flag. The Brownflag is preserved when the PSP connection to the VMC is lost and reestablished. The lost jobs are treated according to section 2.6.3.5.7.2.
  • Virtual Machine Updates are jobs that are sent through the Administration Server to the Distribution Engine.
  • the jobs will go through the scheduler, but will not be pooled or otherwise treated, but instead will be placed directly into the VMCM's update queue.
  • the VMCM is responsible for rolling out updates to all VMCs, regardless of their current configuration, because each VMC must have the full set of potentially requested VM images available locally to enable rapid reconfiguration of all available virtual machines.
  • the job is placed in the ScanJob queue of the VMCM.
  • All JobCollections already processed by the VMCs are related to jobs previously issued by the VMCM to the corresponding VMC / VM. Therefore, incoming jobs are first checked to determine if a corresponding JobCollection has actually been sent to that VM. If no corresponding JobCollection can be identified, the VMC will be flagged brown. Otherwise, the job is removed from the in-progress list.
  • the result is passed to the Validation Module and the issuing VM is marked as available.
  • the issuing VM is marked as having no active RAV.
  • VMC If an update job is received from a VMC, which contains an error block in the result section, the VMC will be "flagged" and the administration server will be informed by an update error.
  • the issuing VM is marked as available and marked with Residential AV in active status. 2.6.3.5.4.6. Set Configuration Job Failure Upon receipt of this job, the VMC brownf is lagged.
  • Every job given to a VMC or VM will be added to the in-progress list.
  • the VMCM sets a time limit for each job. If no answer comes from the VMC, it will be flagged brown. ("Black Hole Incident", should not happen, because the VMC let the job itself and send an error message.)
  • a virtual machine control represents a physical machine running multiple virtual machines.
  • a VMC receives jobs from the VMCM, which are either directed to a single virtual machine running on the VMC (ScanJobs, most ConfigureJobs), or addressed to the VMC as a whole (some ConfigureJobs, Update Jobs).
  • a Result Section is attached to the job and it is returned to the VMCM.
  • the VMC is responsible for managing the virtual machines on a physical host.
  • the VMC manages the so-called stock VHD images of the supported RAVs and their corresponding roll-back copies. She is also responsible for controlling the VM instances on the Virtual Server, including distributing their configuration to the virtual server environment, starting and stopping the virtual machines, and monitoring their runtime behavior. 2.6.3.6.1. Operation of the VMC
  • the VMC is connected to the DE by establishing a PSP communication channel.
  • the VMC will check:
  • the VMC expects jobs from the DE, namely from its counterpart, the VMCM. Jobs are processed immediately as soon as they are completely received over the network.
  • JobCollection backend scan job
  • a JobCollection is directed to an individual VM or the VMC.
  • the VMCM must monitor the availability of each VM, and thus can send a new job only to available VMs. Nonetheless, according to the defensive programming model, the following cases should be audited by the VMC:
  • a VMC receives a job for a VM that is not on the VMC, an error message should be included in the job and the job returned to the VMCM.
  • a VMC receives a job for a VM that is not available, for example, because it is processing another scan job, the job should have an error message. Message and return the job to VMCM.
  • JobCollection specifies a different RAV than is currently in use on the VM, an error message should be included in the job and the job returned to the VMCM. Otherwise, the scan data is copied to a VHD and the VM directory and the corresponding VM is started.
  • An update job is not directed to a single VM, but refers to the entire VMC. Once the VMC has received an update job, it will copy the received images to the stock directory according to the filename conventions.
  • the update job Upon completion, the update job will send either an update success or an update error (e.g., not enough disk space) to the VMC Manager.
  • an update success e.g., not enough disk space
  • a SetConfiguration job can currently only configure the equipment (in this case the RAV) and is issued to an individual virtual machine. If the VMC is processing an update job at this time, the Set Config Job will fail.
  • the VMC searches for the requested image in the VM directory and in the stock directory. If the stock directory contains an updated image or the VM directory does not contain the requested image at all (it could be because of a suspected damage has been deleted), the image is copied to the VM directory and mounted on the virtual server. Afterwards the job will be finished successfully. The job fails if the image is not found in the stock directory (or the disk is full and the copy fails, etc.). If the requested image is in the VM directory and the stock directory does not contain a newer image, the VHD image is mounted by the VM directory on the virtual server and the job finishes successfully. Upon completion of the Set Configuration job, either a SetConfigSuccess or a SetConfig failure is sent to the VMCM.
  • the VMC only sends jobs in response to jobs previously received from the VMCM. These are:
  • the result will be attached to the JobCollection and it will be returned to the VMCM.
  • the VMCM then forwards this to the validation module.
  • a VM Termination Report is sent to the VMCM and the VHD image used during the crash is deleted from the crashed VM directory. After a VM termination, the VM has no loaded RAV.
  • the Validation module receives jobs from the VM Control Manager as soon as they have been returned to the VMCM by the corresponding VM Control. Failed jobs are sent to the pooler for a re-inspection. Valid jobs contain a result section, which is parsed. The result is then sent to the cache.
  • JobCollections will always contain an output section.
  • the Validation module will act upon receipt of the JobCollection according to the contents of the output section.
  • the following sections list the possible output types that the Validation module must handle.
  • the validation module must provide queues for JobCollections or individual jobs coming back from a VM. There must be a queue for each supported RAV. The inspection is performed in a round-robin process, always with one at a time Queue is served. JobCollections remain in the corresponding queue until they have been successfully examined.
  • the inspection can also be carried out in parallel.
  • VM output section contains an exact copy of the data recorded by VM Control through the virtual serial interface (to which the console is redirected) of the virtual machine.
  • a resident AV must always be configured in such a way that the scanned files and the scan results are output in detail in order to allow the validation module to differentiate between the individual file results.
  • the validation engine will examine the RAV information contained in the JobCollection to instantiate the corresponding result string parser.
  • the RAV will output the result to another serial console of the VM. This allows the VMC to differentiate between kernel messages of the guest OS and the output of the RAV.
  • the Validation module must parse the output and generate an internal data structure that contains information about the infection status of each individual job in the JobCollection.
  • the Validation module is not allowed to pass jobs to the cache before it has successfully obtained exactly one result for each job in the JobCollection.
  • the results are kept in an internal data structure until completion. If parsing fails for a job of the JobCollectio after a good result, the entire JobCollection must be treated as invalid according to 2.6.3.7.2.2. If the internal data structure shows a complete set of results for all jobs, the JobCollection is considered valid and treated according to 2.6.3.7.2.1.
  • VM Termination Report The VM Control could decide that the VM instance must be terminated due to a threat or guest OS failure.
  • JobCollection contains a single job with a Poolable attribute set to false, mark the job as positive and valid, and forwarding is performed as described in section 2.6.3.7.2.1.
  • the Validation module must treat the JobCollection as invalid and pass it on as described in Section 2.6.3.7.2.2.
  • JobCollection contains more than one job and some of the jobs have a poolable attribute set to false, a fatal error condition must appear and the JobCollection must be fully logged in a debug information file.
  • the Validation module must pass the jobs.
  • JobCollection is split into individual jobs. If a job is considered clean, the job will be accompanied by a NEGATIVE Result Section.
  • the resulting job is submitted to the cache cache update cache and to the requesting IOFE.
  • the Validation module will send the jobs individually to the scheduler, where they will be treated as regular scan jobs that can not be pooled with other jobs.
  • the validation engine must handle output from the RAV, which potentially contains malicious code that has infected the RAV in the virtual machine. Accordingly, the parsing of the output must be robust to a vulnerability of the implementation. In addition, the validation should be flexible because the output formats of RAVs can and will change over time.
  • the o.g. Requirements lead to an implementation of the parsing functionality of the Validation module in the form of Python scripts.
  • the DE implements a robust Python interpreter.
  • the result sections of the jobs are forwarded to the corresponding Phyton-Sript.
  • the script is selected based on the RAV that sent the JobCollection.
  • the script implements a Result Parser and a Result Lexer interface provided by the managed code in the DE and returns the result of the scan to the calling process.
  • the Python interface to the validation module must be documented separately.
  • Receiving an inconsistent JobCollection as described in Section 2.6.3.7.1 must cause the JobCollection to fail the Validation module. A fatal error is logged and must be added to the administration message list. In this case, the entire JobCollection is logged.
  • the JobCollection must be kept in the inspection queue and an error message must be given to the administration frontend.
  • the administration client will display the script as errored and stop the inspections for that RAV. Other RAV inspection queues are not affected.
  • Administration Interface The purpose of the Administration Interface is to allow the administrator to investigate the function of ParsingSafe in real time, as well as administrative tasks perform. The goal is to provide an easily recognizable and understandable view of the entire ParsingSafe infrastructure and to allow it to perform administrative tasks in this context.
  • the administration interface is a client-server design, the server being called an administration server.
  • the administration server is a module of the distribution engine and runs in the process space of the DE. This design allows for deeper integration, allowing more information to be obtained from the current DE.
  • the Administration Server should provide the Administration Client with information about the status of individual system components on request.
  • the following sections list the information requested by each module.
  • the following information is required for each RAV-specific queue.
  • the information is obtained, unlike any other type, through a push mechanism from the DE to an admin client, if one Job queue is flushed (see section 2.6.3.4.1).
  • IOFEs and VMCs are from the perspective of DE Remote components.
  • Information provided by a remote component belongs to one of two classes:
  • the DE will create a history of values received from remote components over time.
  • the history functionality will provide three different values: ⁇ 1. Average over the last minute
  • Such history collections are kept for all nnumeric or boolean data types, and in normal uninterrupted operation, a remote component provides these values once with each PSS package as described in Section 4.3.3, and the implementation should not all individual values store for 30 minutes but provide a counter for the sum of all received values and 5 a second counter for the number of received values.
  • the installation of the administration client is per user-based.
  • the PSP Private Key is written to a protected directory (Read only for the owner and SYSTEM) below the base directory of the client.
  • the Fisheye List Box is a control that can host NULL, ONE, or multiple client panel controls, which can contain additional controls in themselves.
  • the fisheye list box places the client panels in a vertical list. All client panels are always visible.
  • the fisheye list box has no scrollbars.
  • the client panels can have different vertical sizes, but the fisheye list box is designed for use with panels that have the same vertical and horizontal size.
  • the benefits in terms of usability The fisheye list boxes are lost when used with variable sized panels.
  • the fisheye list box always shows a stylized wheel on the right. By default, this control is locked. It has a fixed width and always occupies the entire height of the Fish Eye List Box Control minus the configurable feature "wheel margin".
  • the sum of the heights of all client panels is less than the height of the client rectangle of the fisheye list box.
  • the client panels are arranged vertically and the entire construct is centered vertically in the Fisheye List Box Control.
  • a margin between the client panels can be provided as a configurable feature. In this operating mode, the Fisheye List Box offers no control options for the user.
  • the embedded client panels represent the control functionality per se.
  • the arrangement of the client panels will change.
  • the client panels are then scaled as if they were projected onto a cylinder.
  • the client panel must take into account an appropriate rescaling of its content controls.
  • the stylized wheel is released on the right side.
  • the pointer changes to a hand icon.
  • the user can click and move the mouse pointer vertically.
  • the hand icon changes to an accessing hand and the stylized wheel is animated as if it were turning.
  • the order of the client panels changes.
  • the bottom panel is placed in the top position and the other panels are moved down accordingly. This causes the fisheye focus to be pushed "up.” The opposite action occurs when the mouse moves up.
  • the TextEdit button control is a standard TextEdit control, which is embedded in a standard button control. This combines a binary on-off setting with the ability to enter text. , The control is used to filter log messages. If selected or text entered, the control becomes active (the button is pressed) and filtering is enabled. If selected again, the button becomes inactive, but the text remains in the control until later selection. 2.6.4.2.2.1.3.Context-indicating mouse pointer
  • a special mouse pointer icon is used, the context menus are available (standard access by right-click).
  • the administration client uses two primary views.
  • the first view (View 1) provides the user with the complete monitoring information. View 1 is shown when the administration client is started. View 2 is used to configure the platform and is shown when the configuration function in View 1 is invoked.
  • the view consists of three sub-views, which divides the main window into 3 columns.
  • the left and right columns are Fisheye List Views (REF), which show the configured IOFEs (Sub-View 1, left) and the VMCs (SubView 3, right).
  • This arrangement allows the User to monitor the entire configured environment in a single window with any scaling.
  • the middle column (Sub-View 2) shows the status of the Distribution Engine and also contains the Sub-View 4, which displays logging information.
  • Sub-View 2 is always displayed centered in the View-1 client frame. The arrangement and subdivision of View 1 can not be changed by the user.
  • the width of Sub-View 2 in View 1 is fixed.
  • the width of sub-view 1 and 3 is calculated from the remaining client-rectangle area, reduced by the width of sub-view 2.
  • the minimum width of view 1 is calculated by doubling the width of sub-view 2.
  • Vertical View 1 can be scaled as desired.
  • the minimum height of View 1 is equal to the height of Sub-View 2 plus the required height of Sub-View 4 to display four lines of log information.
  • View 1 includes the standard window control buttons for closing the application and maximizing and minimizing the window.
  • the regular event handlers are used and the sub-views are arranged according to the scaling specification.
  • View 1 shows a status bar at the bottom. This displays the host name of the Distribution Engine to which the Administra- tor client is connected. 2.6.4.2.3.2. Sub-view 1
  • the client rectangle of Sub-View 1 is fully exploited by a fisheye list box.
  • the client elements of the listbox are panels that display the following information about each IOFE:
  • Open jobs of the respective IOFE IOFE that are configured but not connected to the Distribution Engine are displayed in the corresponding panels and all their client controls are disabled.
  • the context menu mouse pointer is used (REF). Clicking the right mouse button will display a context menu with the following options:
  • Sub-View 2 shows the status of the Distribution Engine. Sub-View 2 also houses Sub-View 4 (2.6.4.2.3.4).
  • Sub-View 2 The layout and scaling of Sub-View 2 is fixed.
  • the context menu mouse pointer is used (REF).
  • One Clicking with the right mouse button displays the following options for the cache in the context menu:
  • ⁇ Flush Entries In the middle of Sub-View 2 two vertically centered fisheye list views are shown. The contents and the display status of both List Views are synchronized and the items are arranged in the same order. If a fisheye list view is scrolled, the other scrolls in sync.
  • the left view shows the status of the pooling queues.
  • Each configured RAV has exactly one pooling queue (REF), which is displayed as a percentage bar.
  • the value displayed in the percent bar is the sum of all sizes of external data relative to the pooling queue's maximum size (REF).
  • REF maximum size
  • the name of the RAV is displayed at the top of the percentile bar.
  • the display of a pooling queue is updated every time the queue is flushed.
  • the context menu mouse pointer is used (REF). Clicking with the right mouse button displays a context menu with the following options: ⁇ Queue Settings
  • the right list view shows the status of the validation script execution. It uses bar histogram controls (REF), which correspond to the RAV whose queue is shown in the left list view - therefore the synchronized display.
  • the bar histogram control is configured with the following settings:
  • the histogram is updated every time the Validation module finishes executing a validation script.
  • the context menu mouse pointer is used (REF). If the user moves the mouse pointer over a histogram indicating level 4 (script execution error), then the mouse pointer additionally shows a tool tip with an administrator message describing the error. 0
  • Sub-View 4 is located in the lower part of Sub-View 2 and consists of a tab control containing the following tabs:
  • the height of sub-view 4 depends on the height of the client rectangle of view 1 minus the fixed height of sub-view 2, which is shown above sub-view 4.
  • the width of sub-view 4 is fixed and equal to the width of sub-view 2.
  • the "Log file retrieval” tab shows an edit control with a path to a destination directory.
  • the path of the last retrieval operation (if taken place) must remember the application and it must be displayed as default.
  • the "Browse” button opens a standard directory selection dialog. The selection must be used in Path Edit Control if the user confirms by pressing the OK button.
  • the Retrieve button is shown which starts a logfile download. If this button is selected, the Administration Client will download the log file from the Distribution Engine and place it in the selected directory.
  • the downloaded logfile will be named according to the following format:
  • VMC requires attention and is
  • the Sub-View 3 Client Rectangle is fully utilized by a Fisheye List Box.
  • the client elements of the list box are panels that display the following information about each VMC:
  • View 2 is used for configuration settings. It is divided into an icon list box on the left and a main client area on the right. There is always either none or one instance of View 2. View 2 can be maximized or minimized.
  • the Icon List Box on the left has a fixed width. It has the full height of the client rectangle of View 2.
  • the configuration panel on the right uses the entire remaining space of the client rectangle.
  • View 2 contains the standard window control buttons for closing the window (cancel), maximizing and minimizing the window.
  • the regular event handlers are used and the sub-views are arranged according to the scaling specification.
  • an Icon List Box with the configuration subsections is displayed left-justified.
  • the entries in this list box represent the entirety of all the configuration options offered by the context menus of View 1.
  • the configuration panel will display the corresponding controls based on the configuration section selected in the Icon List Box.
  • each configuration panel will have an "Apply" button in the lower right corner, and pressing this button will send the configuration settings shown in the current panel to the Distribution Engine and create an Undo point on the Undo stack If the user changes a configuration option and then selects another configuration section in the list view, a yes / no confirmation box asks whether the changes made are to be confirmed or undone.
  • the elements of the configuration panel must be left-aligned and placed vertically in the client rectangle.
  • Log4Net configuration o Severity level drop-down control for the log messages to be stored in the local log file of the DE (Note: Messages with a lower severity are discarded by Iog4net).
  • Any configuration change made during the lifetime of the administration client process is stored in an undo stack.
  • the stack entry will contain the modified configuration values before and after the change. This allows the user to undo configuration steps.
  • Closing the Administration Client deletes the undo stack.
  • View 2 requires all pull data, which is also required by View 1. In addition, the following data is necessary for the configuration.
  • Log messages are transferred from the DE to the administration client as a push message.
  • the administration client can set the log level so that only messages of this or higher level are delivered.
  • the administration client can not set the log level to DEBUG.
  • the administration client offers the possibility to download the current DE-Logfile.
  • the administration client initiates the download by sending a message to the DE.
  • the DE must answer this request with an ACK message indicating the size of the log file to be transferred contains. Then she will start a PSP binary channel transaction.
  • Parsing Safe The purpose of Parsing Safe is to provide a secure Runtime 5 Environment for anti-virus solutions.
  • Antivirus software however, needs to be updated on a regular basis to allow for adequate malware detection.
  • This 10 section describes the components and DE modules required to update an RAV antivirus definition.
  • ParsingSafe updates are generally rolled out on a per-AV-20 basis. There is no general update that contains .NET runtime executable code for the platform itself. There are two types of updates:
  • VHD-Updates which change the stock image (VHD) on the VMC to install new or updated AV-Pattern-File or updated scanner-
  • Validation script updates which change the way the Validation module looks at the output of the RAV. These are not distributed to the VMCs, but put on their place in the DE.
  • ParsingSafe builds on the so-called pattern updates of the supported AV solution providers. Due to the fact that ParsingSafe is delivered with the AV solution, which runs delimited in a virtual machine without interfaces to the outside, one must offer the updates of the AV offerers to the ParsingSafe customers themselves. This requirement is further enforced by the need to ensure the quality of the AV updates and to ensure that the updated AV works correctly in ParsingSafe.
  • a new version of the validation script must be generated. This new version is set to recognize the new output and classify it correctly. If the new set consisting of a TAR file containing all new and changed files of the VHD image and a corresponding version of the validation script is completed for the AV in question, a new version number must be set. The package must be completed by an index file and stored on the update server.
  • a component of ParsingSafe the update daemon, will continuously monitor the update server and detect new updates. When a new update is detected, the update daemon downloads the update package and tries to deliver the update to the DE. If this is successful, the DE will process the update by first distributing the VHD update to the VMC and performing the installation. Finally, the new validation script is released and the scan operation resumed.
  • the ParsingSafe update process includes a number of systems and other elements involved. The following list is intended as a brief explanation of the terminology:
  • ⁇ AV Update is the update, in whatever form, issued by the AV provider to its regular customers (not ParsingSafe)
  • ⁇ AV update tool is the tool and / or the process that an AV provider its regular customers (not
  • ParsingSafe offers to update its AV installation
  • ⁇ VHD update is the update for the VHD of the RAV in ParsingSafe, which the applicant of the invention generates as a result of one or more AV updates
  • ⁇ Validation Script Update is a completely new version of the validation scripts of an updated RAV
  • ⁇ Update Package is the archive which is distributed by the applicant of the invention via the update server. It contains the VHD update, validation script update and a description file.
  • VHD updates are always generated as a difference of the entire file system of a RAV-VHD before and after an update. This must be done by comparing: 1. The directory structure before and after an update. Any directory or file that is generated during an AV update and that did not exist in a previous version must be included in the VHD update. 2. The primary hash of all files before and after an update. Any file that existed before an AV update but has a modified primary hash after the AV update must be included in the VHD update.
  • VHD update mechanism does not support the removal of files. If a file needs to be removed, this file with a file size of 0 will be included in the update. This does not remove the file, but any content associated with it. It should be noted that one should operate a number of virtual machines outside ParsingSafe. Each is running a copy of a supported AV solution. Some AV products use their own update mechanism, which can not be reproduced simply by using standard tools. It is recommended to use the procedures and tools of the respective vendors to perform AV updates instead of trying to replicate the vendor's update process.
  • Differences resulting from updates are detected by a file system level difference calculation based on the individual cryptographic checksum of the file.
  • the availability of a set of virtual machines allows the applicant to perform the AV update
  • the tools and procedures provided by the AV vendor are used, followed by a comparison of the current file-based version. It also allows the applicant to check the correctness of the update provided by the AV provider.
  • the first test of the update on a virtual machine allows the applicant to reject an update that would otherwise have caused the customer AV to behave erratically.
  • File system differences can still be calculated between the last good version of an AV installation and the new working update which is expected later.
  • the AV product must be installed in the same directory structure as ParsingSafe's RAV-VHD. ⁇ The installation must use the same version for Linux kernels and libraries as it does for ParsingSafe's RAV-VHD.
  • the AV test environment should already contain a list of all files except the directory containing the differential database.
  • the process to get a list of all files modified by the update can be implemented as a script. This script first compares the directory and file structure of the entire disk, excluding a list of changeable directories and the directory containing the differential database, and second compares the primary hashes of all the files found in both versions. Any difference will be included in the VHD update.
  • the list of before and after the update differing files, is to build up as a list with absolute file paths.
  • the GNU-TAR implementation will remove the leading "/" character from the absolute paths
  • the resulting TAR archive must update the post-update file system state from the pre-update file system state by extracting the TAR archive in can create the file system root.
  • the update server is the central element of the ParsingSafe update process.
  • the server should be accessible via the public Internet and be highly available.
  • Availability The update server should use a redundant operating system setup (cluster) with failover functionality and a redundant Internet connection through two separate Internet Service Providers. Alternatively, two servers can be installed in different locations with different ISPs. Availability is then implemented via DNS round robin.
  • the update server provides an external HTTPS service.
  • the HTTPS server certificate must correctly reflect the system name and must be valid against the usual set of root certificate authorities provided by Internet Explorer 7.
  • the server may not offer functionality via HTTP except a redirect to the HTTPS page. 2.6.5.3.4.3. authentication
  • the update server may only support HTTP Basic Authentication via HTTPS. There will be a single account for each customer. If no correct authentication takes place, the service must redirect the user to a page on another system. Only authenticated requests are to be used.
  • Successfully authenticated requests must map the authenticated user to a corresponding subdirectory and restrict it to this directory.
  • the mapping should be entered in a central configuration file. If no mapping can be found, then the
  • the mapped subdirectory may be visible in the URL.
  • directory listing creation should be supported to allow for customer update mechanisms. In general, directory listings should be disabled and should never be enabled for the top-level directory to prevent detection of customer data.
  • Each customer subdirectory (see Section 2.6.5.3.4.4) should contain the following structure:
  • Each directory in the tree contains all the updates that have been shipped since the first installation of VHDs for the ParsingSafe installation.
  • the content and format of the updates is described in Section 2.6.5.4.
  • the assignee of the invention may decide to use symbolic links on the server side to limit the amount of memory required if many update packages are supported.
  • Each directory will also contain a file called CURRENT.
  • the file will contain the name (as per section 2.6.5.4.1) of the latest update available for the platform / RAV and hosted in this directory.
  • the update name is in a single line (US-ASCII) followed by one or more CRLF.
  • the implementation of the update server can choose to automatically generate this file.
  • the upload process can override the file at any time when a new version is given online.
  • CURRENT may only be updated as soon as a new update package has been completely uploaded.
  • the update daemon is part of the ParsingSafe distribution, which is delivered to the customer. It is a standalone .NET binary that handles update deployment, verification, and installation in a ParsingSafe environment.
  • the update daemon is a completely independent communication cation partner of the DE and needs its own key-pair on a separate IP address to work.
  • the update daemon will not provide a GUI, but it is implemented as a Windows console application.
  • the options of the update daemon are controlled via options on the command line or via the application configfile.
  • the update daemon must be able to run unattended. He must be able to write error messages in the Windows Application Event Log.
  • the update daemon may offer an optional Progress Tracking GUI in future releases.
  • HTTPS HyperText Transfer Protocol
  • HTTP proxies and HTTP responses. This is not supposed to indicate the option to use plain text communication.
  • the general task of the update daemon is to use the
  • Update server at a user-defined interval to the latest version of the update packages query and compare them with the version, which is reported at this time by the DE. If a difference is detected, the updates must be downloaded, verified and delivered to the DE. Once this process is complete, the update daemon resumes polling the Upate server.
  • the update daemon Once the update daemon is started, it must first check if a connection to the update servers is available via HTTPS. From this test, the connectivity status must be derived. Possibly. The attempt to establish a connection must be made with and without the use of an HTTP proxy server. If the HTTP proxy requires user authentication, the update daemon can provide the necessary data if it is available in the configuration file.
  • the connectivity test must fail if validation of the certificate fails during HTTPS SSL handshake. Under no circumstances should the update daemon send customer account information or query an update package if the identity of the update server or the integrity of the connection is not guaranteed.
  • the update daemon must use the access data provided by the configuration to access the root directory of the customer's update section on the update server.
  • the update daemon should be terminated with a suitable error message.
  • the update daemon maintains a PSP connection to the DE, which is initiated as soon as the initial connectivity and authentication tests were successful. If no PSP connectivity is available, the update daemon behaves like any other PSP partner and runs the PSS protocol until a connection to the DE has been established. Operations towards the update server (s), especially for getting updates, should also be done if there is no PSP connection to the DE.
  • the guideline is the independence of the update query and the content verification process from the process of the update delivery to the DE.
  • An update cache directory is used for this purpose as described below.
  • the update daemon can request information about the currently installed versions of RAV from DE.
  • the DE will respond with the current image name, which includes the version as described in Section 2.6.5.4.1.
  • the DE will only report a single image name per RAV.
  • the update daemon is able to derive the directories on the update server, which have to be polled for new versions.
  • the DE will send a push message to a connected update daemon if, due to a successfully implemented update on all connected VMCs, the RAV image version changes. In this way, the update daemon is notified of the change and does not need to constantly poll the ParsingSafe infrastructure. 2.6.5.3.5.1.5. Determination of the update packages
  • the update daemon As soon as the update daemon has determined the directory on the update server, it must query the file "CURRENT" and parse its contents in accordance with section 2.6.5.3.4.6. If the version of the currently available update is higher than the version reported by the DE for the corresponding RAV image, all updates from the local version to the version that was displayed in the file "CURRENT" must be requested.
  • the update packages that were determined for the download must be cached locally in a directory.
  • the update daemon must not automatically delete updates in this directory.
  • the update daemon must verify the contents of the package without actually extracting the files from the tar archive to a temporary directory. The verification must ensure that the content corresponds to section 2.6.5.4.3. If this is not the case, the update daemon must log the format violation and delete the downloaded package.
  • the update daemon must keep information about which updates it has delivered to the DE. Until the DE a new, on the ParsingSafe platform reports running version of the RAV image, the update daemon must assume that the update has not been delivered and it must not trigger the delivery of another update. At the same time, only one update will be delivered.
  • Updates are delivered via the PSP Connection and the PSP Binary Channel. Before the update is delivered, the update daemon must calculate the primary hash of the update package. To initiate an update transfer, the update daemon will send a PSP message with the following content:
  • the DE will initiate the binary channel and receive the update.
  • the DE must answer the update message with a confirmation message as soon as the update package has been transferred correctly and its primary hash has been checked against the value calculated by the update daemon.
  • the update will be delivered as incomplete until the DE sends a push message with the newly active RAV image version and details the complete update of all online VMCs, which must correspond with the version included in the update.
  • the update daemon can continue its regular activity and query the update server.
  • errors must be logged, which occur during the update query on the update server or during corresponding download operations. Then the current operation has to be ended. The operation will be repeated automatically at the configured interval. regular update query on the server fails, the update daemon must log an error message and stop the current query. The next query is executed according to the configured interval.
  • the update daemon must log an error message and retry the query at the defined interval.
  • the Virtualization Platform and the Resident AV Name are camel-case alphanumeric strings, excluding bindings and underscores.
  • the version is an unsigned integer and has a maximum value of 2 32 .
  • the version number will be incremented by 1 with each update issued. 2.6.5.4.2. Content of an update
  • the RAV image update contains all the files that need to be updated or added to a RAV stick image to bring it up to the latest anti-virus definition, as well as some potential AV engine updates.
  • the RAV validation script update contains a potentially modified version of the RAV validation script, which may be required due to changes in RAV output
  • the update description contains a text info about the update. This allows the DE to present this description in their logfiles. In the admin frontend, these details would then appear in the log window.
  • the update-description is a free-form text and may contain any information that may be relevant to ParsingSafe customers.
  • the TAR archive contains:
  • the filename of the update package starts with the string "PAK_", followed by a name according to section 2.6.5.4.1 and carries the TAR extension.
  • An example update for ClamAV on a virtual server virtualization platform would be named: PAK_VirtualServer_ClamAV_1234.TAR and would contain the following files:
  • the order of the file in the TAR archive is not defined and must not be adhered to.
  • the classification of the files is done according to their extension.
  • the DE will always process only a single update at any time. It must be ensured that she does not accept another update while she is just another one Update processed. An update is considered in progress between the time the update was received by the update daemon and the time all online VMCs were successfully updated.
  • the update daemon sends an update message to the DE and transfers the update package via the PSP binary channel.
  • the update package is to be stored in a temporary location and the primary hash is to be compared with the reported primary hash in the PSP message of the update daemon.
  • the TAR archive is extracted and the content is verified against the requirements in section 2.6.5.4.3. 4.
  • the DE confirms that the update daemon accepts the update package
  • the DE sets the update for the transfer to the VMCs in the queues. Updates take precedence over backend scan jobs.
  • the DE sends the VHD update to all connected VMCs and awaits their confirmation that the update has been completely accepted. During this time will be no backend scan jobs for the affected
  • the DE confirms the installation of the update by sending the new stock image name to the update daemon.
  • the DE resumes processing backend scan jobs for the affected RAV.
  • the DE writes the description text of the update package (TXT file contents) in their log file to allow the admin frontend to see it. 2.6.5.5.2.Application of offline VMCs
  • the DE does not keep copies of the updates.
  • a VMC displays its availability and is connected to the DE, the current RAV image name is initially reported to DE.
  • the DE must keep a note of all VMCs and their RAV image versions.
  • the VMC When a VMC with an outdated RAV image version connects to the DE, the VMC must be flagged brown and no longer used. The error condition is logged.
  • the update rollouts take the form of files in GNU TAR format without additional compression.
  • the files are named according to the format described in section 2.6.5.4.1 and have the extension TAR.
  • Compression could be done by the update frontend before the archive rollout. There is no need to burden VMCs or VMCM with it.
  • Updates to the VHD are performed by extracting the TAR archives in the root directory of the Stock Image System VHD.
  • the VHD update process is as follows:
  • a copy of the latest Stock Image System VHD is filed in the Stock Image directory.
  • the filename of the update receives an additional prefix, which marks it as a temporary copy, so that a starting VMC does not consider the image usable.
  • the new image will be opened and the update will be extracted to the root directory.
  • Validation script updates follow the same naming convention as VHD updates (see 2.6.5.4.1). If the validation script was received by the DE, it must be stored in a temporary location until the corresponding VHD updates have been performed. The new validation script only needs to be applied if all VHD updates were successful. The DE will keep NUMROLLBACK backups from previous versions of the Validation script, matching the backups of the previous VHD versions to the VMC.
  • the whole ParsingSafe platform is a pretty big construct. Therefore, the flow of data through the platform should be simple, consistent, and easy to track and debug.
  • the following data flow requirements are design options:
  • the data should go through the platform in a unified form.
  • the transformation of data leads to software errors and unspecified behavior
  • the data flow must be traceable across the platform, including timing information for each processing step. As performance is paramount, tracking the data is required to detect hotspots and improve their performance.
  • ParsingSafe The function of ParsingSafe is built around a job concept. Any function requested by ParsingSafe is considered a job, including scanning a file for viruses, updating a virus scanner, or changing the system configuration.
  • a job can be thought of as a file folder in a bureaucratic organization.
  • the file folder contains only a few pages describing the task to be performed.
  • each person acts on the basis of their own rules combined with the information already available in the file folder.
  • the resulting material is also done in the file folder, along with the material that was created in actions performed at the conclusion of the sub-task.
  • the file will contain both the result of the task and all the materials that led to the result.
  • Each edge component starts by creating a job, an operation in ParsingSafe.
  • the job contains all the required information for all other components they can act on. This requires communication and allows easy distribution of jobs.
  • Each component and module that processes a job adds information to the job. Depending on this information, the job is passed on or considered finished, either completed successfully or aborted due to an error condition.
  • a job does not contain a binary file, such as external data, which should be scanned for viruses.
  • the job concept is applied everywhere; from the low-level communication protocols to the class hierarchy and the frontend visible to the user as well as during the communication between the components via network channels.
  • a job is an XML stream according to the XSD schema specification.
  • a job is abstracted as an instance of a job class that is initialized by an XML stream and can at any time reproduce its current status as XML.
  • Jobs are saved and fitted into XML documents, which consist of different sections.
  • the first section contains the job to be done.
  • An XML document also contains a log and a result section.
  • a result is defined either as a completion or error section.
  • the log section of an XML document contains subsections for zero or more modules used by the XML document as it moves through the platform. If the log section contains a subsection for the currently executing module, the module must fill the field within the subsection. In addition, the module may decide to add plaintext messages or warnings to its subsection, regardless of whether the module subsection exists. 3.1.2. Job Types
  • Scan Job Domain Communication between IOFE and cache.
  • a scan job contains all the information needed to scan external data for malware.
  • the external data is referenced by the cryptographic hash of the file, which is generated when the job enters the cache.
  • Backend scan job
  • a backend scan job is generated by the Cache Job Manager. It contains additional information for the job, which allows scheduling.
  • Job Collection Domain Communication between Scheduler and VMC Manager, VMCM and VMC, VMCM and Validation.
  • a job collection is a package of various backend scan jobs that is used to send pooled jobs to a VMC.
  • This job type results in a full update of a VHD image on a VMC.
  • the new image is not usable immediately. It is only stored in the instrument folder of the VMC and is activated by a VMC Configuration Setting Job if required.
  • Differential VHD image update jobs are the same as full VHD image update jobs, except for the data operation. This requests that the executing VMC copy an existing VHD image and apply a binary patch to it.
  • a cache flush job clears the entire cache.
  • This job type allows you to add positive cache entries. This functionality allows administrators to declare a specific file as unwanted / infected, regardless of the RAV actually used.
  • VMC Configuration Retrieval Job This job queries the entire configuration of a VMC.
  • This job sets the entire configuration of a VMC based on a previously determined configuration. Although such an operation is laborious, it guarantees consistency and causes the VMC 1 to potentially use new VHD images.
  • This job is issued by the admin frontend to query the configuration of the IOFE. • IOFE configuration setting job
  • This job is issued by the admin frontend to set the configuration of the IOFE.
  • Jobs can contain data (usually strings) that are taken from or influenced by external data. Because the primary design model is the protection of parsing requires external data, such strings must be normalized before they are included in the job XML.
  • a normalized name string is defined in the top-level XSD schema. Non-normalized strings will fail the XSD schema validation based on the "normalizedNameStringType" type of XSD
  • the creating and / or modifying the job module is responsible for ensuring that only normalized name strings are included in the XML file , The recommended procedure is to replace all characters with an underscore (_) that does not match the allowed character set.
  • normalized name strings are defined as:
  • NNS a normalized name string
  • a scan job is generated by an IOFE when it is busy inspecting external data.
  • the IOFE uses the primary hash algorithm to add a byte string which uniquely identifies the block of external data.
  • a scan job created by an IOFE contains:
  • the backend scan job is a direct descendant of the scan job. Its elements are the same as for the scan job with the following additional information: • the desired resident AV nickname, according to the lOFE rules
  • a backend scan job is called the same name in cache nomenclature. 3.1.4.3.Job Collection
  • a JobCollection merges multiple backend scan jobs into a single job.
  • JobCollections can not be composed from scan jobs.
  • JobCollections There are no other components for JobCollections. They can be used anywhere to specify a backand scan job.
  • Scheduling is of immense importance for the performance of ParsingSafe. Due to the distributed nature of the general design, specialized scheduling algorithms are to be used.
  • the general design requires a modular software design.
  • the organization and algorithms described herein may be subject to changes in other versions. However, it is necessary that no software component must be changed if changes occur in the scheduling.
  • ParsingSafe allows a large number of parameters to be used for scheduling. which must be taken into account in the scheduling design and resulting scheduling decision mechanisms.
  • Job type and corresponding resource usage (scan jobs are CPU-intensive, VHD updates are l / O-consuming) • Procedure for assigning JobCollection to VMs limiting parameters are:
  • VMC virtual machines
  • Installation constant but is will be configurable on the DE. This value is called P2VMC and has a default value of 3.
  • HOLDMAX The time (in seconds) that jobs can stand in pooling before they are needed for scanning is called HOLDMAX.
  • HOLDMAX is configurable configurable on the DE and is constant for the entire installation.
  • HOLDMAX has a default value of 120.
  • CONFIGHOLD The time (in seconds) that must pass between at least two instrumentation reconfigurations Called CONFIGHOLD.
  • CONFIGHOLD is configurable on the DE and is constant throughout the installation.
  • CONFIGHOLD has a default value of 900.
  • ParsingSafe treats MIME parts of emails individually, such as the body and separate attachments, the individual size of each object must be considered. As you can see in the figure, the overwhelming majority of MIME objects fall into the category below 500 kilobytes.
  • pooling is required to prevent costly VM runs for very small files. Pooling uses n queues, where n is the number of configured resident AVs. Jobs are queued based on the RAV requested in the job folder.
  • the first job queued in the pool sets a timer TMHOLD. Jobs are queued until TMHOLD reaches the configurable limit HOLDMAX.
  • ParsingSafe's communication protocols strive for availability and security as required by the primary and secondary design model (see sections 2.4.1 and 2.4.2).
  • the ParsingSafe protocol stack consists of two main protocols: the ParsingSafe (PSP) protocol, which handles job transfer, and the ParsingSafe Status Protocol (PSS), which handles information and keep-alive functionality.
  • PPS ParsingSafe
  • PSS ParsingSafe Status Protocol
  • the protocols are split to take advantage of the different characteristics of UDP and TCP traffic in IPv4 networks.
  • PSP runs on two TCP channels, one for signaling and one for binary transfer.
  • the connection-oriented nature of TCP provides a stable communication channel and a simple way of preventing protocol violations, such as e.g. malformed messages or failed signature checks. A connection is easy to stop after a protocol violation.
  • PSS runs over UDP.
  • the receipt of UDP packets proves that the station is online and can be contacted.
  • the absence of UDP packets for a given period of time indicates that the TCP channel can no longer be reliable, although it may still be operational in the API.
  • Using a UDP signaling protocol also allows for robust restart behavior, as it does not have the sequential dependencies such as TCP, and also introduces a random drift in the timing behavior of a rebooted DE that reconnects all remote components. Only a single IOFE or VMC can run per IP address. Multiple remote components on the same host are allowed, but are not recommended or tested for such setup.
  • PSP the ParsingSafe protocol
  • TCP Transmission Control Protocol
  • PSP is divided into two separate TCP channels:
  • the PSP Control Channel is a continuously open TCP connection from the DE to the remote component.
  • the connection is initiated by the DE to the remote component.
  • the connection is closed when a protocol violation is detected.
  • the PSP Binary Channel is an on-demand TCP connection initiated by the DE to the remote component.
  • the remote component server
  • the client does not send any data to the server. There is no control information included.
  • the two-channel approach is used to prevent mixing of control messages and binary data.
  • the PSP Control Channel is always bound to the defined server ports.
  • the ports are 4711 and 4712 and will be used for PSP. It is highly recommended, after the pilot phase of the product, to request a port allocation from IANA. PSP Control Channel connections are accepted on port
  • the PSP Control Channel transports PSP folders.
  • PSP folders are XML streams corresponding to the Folder XSD schema, which defines a simple XML element wrapping a Folder XML. The validity of the XML stream is checked against the schema after receiving the complete XML message. Failed validation will cause the connection to terminate without further notice. XML streams from the PSP Control Channel are signed.
  • the PSP Folder contains a mandatory attribute that contains the host name of the sending system. This attribute is used to identify the public key needed to verify the signature of the PSP folder. Incorrect authentication will cause the connection to terminate without further notice.
  • PSP Folder XML streams are not acknowledged by the recipient.
  • a PSP Folder XML contains:
  • Attributes host name and version (1) ⁇ a job (frontend job) or a jobCollection (backend job), according to section 3.1.4.
  • the PSP Binary Channel transports a single binary block during its lifetime.
  • the DE initiates the channel and is therefore the TCP client.
  • the server remote component IOFE or VMC
  • the server immediately starts sending the binary block as a sequential byte stream.
  • the server terminates the connection as soon as it has sent the entire stream.
  • PSS ParsingSafe Status Protocol
  • PSS is a periodic 2-way signaling mechanism. PSS is connectionless and uses UDP as a transport layer.
  • the PSS transmitter and receiver is always tied to the PSS port. According to [5] port 4713 is not allocated and will be used for PSS. It is highly recommended, after the pilot phase of the product, to request a port allocation from IANA.
  • PSS uses port 4713 / UDP as the source and destination port for all packets. 4.3.2. PSS format
  • PSS uses XML streams.
  • a PSS XML stream is defined by a PSS message XSD.-
  • a single valid PSS XML file in the stream is defined as a PSS message.
  • PSS XML streams are generated using the XSD schema as soon as they are received.
  • PSS XML streams are signed.
  • the signature algorithm and the key material used are identical to the PSS Control Channel (see Section 4.2.2). If schema or signature validation fails, discard the message and act as if no message has ever been received.
  • PSS messages contain the following information:
  • the PSS protocol is spoken by remote components (IOFE, VMC) to the DE and vice versa.
  • Each component can be both a receiver and a transmitter for PSS.
  • PSS messages are sent once every 20 seconds.
  • a component appears to a communication partner as no longer reachable if during the last 60 seconds no PSS message was received anymore.
  • the communication layer will then terminate any PSP connection that is still in use to that partner.
  • ParsingSafe uses hostnames to uniquely identify remote components.
  • the host name is also used as a lookup key to identify the public key used to verify the sender's XML signature.
  • Each ParsingSafe component uses a local text file that is similar to the "hosts" mechanism of earlier UNIX systems for resolving hostnames into IP addresses.
  • the use of dynamic name resolution would potentially result in resolution spoofing security vulnerabilities and would require additional communication channels to a central name resolution system.
  • the sender of a PSP signaling or a PSS XML stream signs the stream with its private signature key.
  • the recipient of a PSP signaling or a PSS XML stream verifies the sender's signature based on the sender's public key.
  • Both PSP and PSS contain the "hostname" attribute in the outer folder, and the recipient must have the public key of the sending host locally to verify the signature.
  • the signature algorithm used is DSA. Each component locally stores its own key pair (public and secret key) must communicate (host name of the communication partner).
  • the following sections list the error conditions that can occur.
  • the conditions are grouped according to the point of view from which the error is observed, namely the component which does not have the error. This is done to ensure a robust implementation of the corresponding components.
  • error conditions listed here only include the inter-component errors. Internal errors, such as Errors when initializing the PSPS or OOM conditions are not handled. A component may attempt to treat such error conditions locally. If local editing of the error conditions fails, the component must log and crash a problem description so that the conditions listed below apply.
  • ParsingSafe is by itself asynchronous and can handle the job processing of its own choice. 5.1.1. Not contacted by DE
  • the IOFE must run the PSS protocol and wait for the PSP protocol connection.
  • the handling of scan requests while not connected to the DE is IOFE-specific.
  • the IOFE must reset the instance of the communication layer to its initial status and continue to run the PSS messaging.
  • An IOFE can detect a scan job error.
  • a scan job error is signaled by the return of a job folder containing an error (no result) section.
  • the reason for a scan job error may be the loss of connection to the DE.
  • An IOFE can receive a scan result for a job over which it has no information. This happens especially when errors occur in the communication layer (see 5.1.2) and the job was already discarded.
  • the IOFE must log and discard the scan job result.
  • the DE must reset the communication layer instance for this endpoint to its initial state and keep the PSS protocol running for that endpoint.
  • the DE must ensure that all jobs sent to that VMC are considered unedited.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Software Systems (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Virology (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un procédé de détection de l'état d'un code. Ce procédé est caractérisé en ce qu'il consiste à : entrer un ou plusieurs codes dans une ou plusieurs machines virtuelles; activer les codes sur la machine virtuelle correspondante; produire un ou plusieurs paramètres et/ou signaux au moyen de la machine virtuelle via la fonction du ou des codes; et effacer intégralement la machine virtuelle dans le cas où la fonction du ou des codes est déterminée comme n'étant pas correcte.
PCT/DE2007/001858 2007-10-17 2007-10-17 Procédé de détection de l'état d'un code WO2009049570A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/DE2007/001858 WO2009049570A1 (fr) 2007-10-17 2007-10-17 Procédé de détection de l'état d'un code
DE112007003737T DE112007003737A5 (de) 2007-10-17 2007-10-17 Verfahren zum Erkennen des Zustands eines Codes

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/DE2007/001858 WO2009049570A1 (fr) 2007-10-17 2007-10-17 Procédé de détection de l'état d'un code

Publications (1)

Publication Number Publication Date
WO2009049570A1 true WO2009049570A1 (fr) 2009-04-23

Family

ID=39315152

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2007/001858 WO2009049570A1 (fr) 2007-10-17 2007-10-17 Procédé de détection de l'état d'un code

Country Status (2)

Country Link
DE (1) DE112007003737A5 (fr)
WO (1) WO2009049570A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170104767A1 (en) * 2009-11-30 2017-04-13 Red Hat, Inc. Monitoring cloud computing environments
US11895737B2 (en) * 2019-05-02 2024-02-06 Samsung Electronics Co., Ltd. Method and apparatus for supporting rapid cell activation in connection resumption procedure in next generation mobile communication system

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030135791A1 (en) * 2001-09-25 2003-07-17 Norman Asa Simulated computer system for monitoring of software performance
JP2003202966A (ja) * 2002-01-08 2003-07-18 Mitsubishi Electric Corp ストレージ共有計算機システム
US6820214B1 (en) * 1999-07-26 2004-11-16 Microsoft Corporation Automated system recovery via backup and restoration of system state
US20050080584A1 (en) * 2003-10-14 2005-04-14 Bonilla Carlos A. Automatic software testing
US20060021029A1 (en) * 2004-06-29 2006-01-26 Brickell Ernie F Method of improving computer security through sandboxing
WO2007107766A1 (fr) * 2006-03-22 2007-09-27 British Telecommunications Public Limited Company Procédé et appareil de test automatique de logiciel

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6820214B1 (en) * 1999-07-26 2004-11-16 Microsoft Corporation Automated system recovery via backup and restoration of system state
US20030135791A1 (en) * 2001-09-25 2003-07-17 Norman Asa Simulated computer system for monitoring of software performance
JP2003202966A (ja) * 2002-01-08 2003-07-18 Mitsubishi Electric Corp ストレージ共有計算機システム
US20050080584A1 (en) * 2003-10-14 2005-04-14 Bonilla Carlos A. Automatic software testing
US20060021029A1 (en) * 2004-06-29 2006-01-26 Brickell Ernie F Method of improving computer security through sandboxing
WO2007107766A1 (fr) * 2006-03-22 2007-09-27 British Telecommunications Public Limited Company Procédé et appareil de test automatique de logiciel

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MARKO HELENIUS: "Automatic and Controlled Virus Code Execution System", EICAR CONFERENCE, XX, XX, 1995, pages 1 - 8, XP002412872 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170104767A1 (en) * 2009-11-30 2017-04-13 Red Hat, Inc. Monitoring cloud computing environments
US10924506B2 (en) * 2009-11-30 2021-02-16 Red Hat, Inc. Monitoring cloud computing environments
US11949709B2 (en) 2009-11-30 2024-04-02 Red Hat, Inc. Monitoring cloud computing environments
US11895737B2 (en) * 2019-05-02 2024-02-06 Samsung Electronics Co., Ltd. Method and apparatus for supporting rapid cell activation in connection resumption procedure in next generation mobile communication system

Also Published As

Publication number Publication date
DE112007003737A5 (de) 2010-09-16

Similar Documents

Publication Publication Date Title
DE112015004500B4 (de) Automatisierte Verwaltung von vertraulichen Daten in Cloud-Umgebungen
DE60029643T2 (de) Verfahren und Vorrichtung zur Verwendung eines virenfreien Dateizertifikats
US7774832B2 (en) Systems and methods for implementing protocol enforcement rules
US7882265B2 (en) Systems and methods for managing messages in an enterprise network
DE69722266T2 (de) Anit-virus-agent zur verwendung mit datenbanken und postserver
US12093417B2 (en) Hybrid approach to data governance
US7664822B2 (en) Systems and methods for authentication of target protocol screen names
US7707401B2 (en) Systems and methods for a protocol gateway
US20090228973A1 (en) Techniques for automatic discovery and update of client environmental information in a virtual private network (vpn)
US9727424B2 (en) System and method for maintaining server data integrity
DE102011056502A1 (de) Verfahren und Vorrichtung zur automatischen Erzeugung von Virenbeschreibungen
US20110016528A1 (en) Method and Device for Intrusion Detection
US20040103318A1 (en) Systems and methods for implementing protocol enforcement rules
WO2009049570A1 (fr) Procédé de détection de l'état d'un code
Jain Lateral movement detection using ELK stack
DE102007050089A1 (de) Verfahren zum Erkennen des Zustandes eines Codes
AU2004272201A1 (en) Systems and methods for dynamically updating software in a protocol gateway
US11489852B2 (en) Method for protecting a private computer network
WO2006062961A2 (fr) Systemes et procedes permetttant de mettre en oeuvre des regles d'execution de protocole
Barnett {NOOSE--Networked}{Object-Oriented} Security Examiner
CN119583186A (zh) 天眼监测平台域名恶意软件处置方法以及应用的监测系统
Lukavsky Visualizing the malicious threat landscape
Lee et al. Development of oval based vulnerability management tool (OVMT) on a distributed network environment

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07817693

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 1120070037377

Country of ref document: DE

REF Corresponds to

Ref document number: 112007003737

Country of ref document: DE

Date of ref document: 20100916

Kind code of ref document: P

122 Ep: pct application non-entry in european phase

Ref document number: 07817693

Country of ref document: EP

Kind code of ref document: A1

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载