I 1111111111111111 11111 111111111111111 1111111111 1111111111 1111111111 11111111
`
`US009117075Bl
`
`c12) United States Patent
`Yeh
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 9,117,075 Bl
`Aug. 25, 2015
`
`(54) EARLY MALWARE DETECTION BY
`CROSS-REFERENCING HOST DATA
`
`(75)
`
`Inventor: Anne Yeh, Taipei (TW)
`
`(73) Assignee: Trend Micro Inc., Tokyo (JP)
`
`( *) Notice:
`
`Subject to any disclaimer, the term ofthis
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 743 days.
`
`(21) Appl. No.: 12/951,785
`
`(22) Filed:
`
`Nov. 22, 2010
`
`(51)
`
`Int. Cl.
`G06F 21100
`G06F 21156
`H04L29/06
`(52) U.S. Cl.
`CPC .............. G06F 21156 (2013.01); H04L 63/145
`(2013.01)
`
`(2013.01)
`(2013.01)
`(2006.01)
`
`( 58) Field of Classification Search
`USPC . ... ... ... .. ... ... ... ... ... .. ... ... ... ... ... .. ... ... ... ... .. 726/24
`See application file for complete search history.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`....................... 726/22
`3/2009 Kuo et al.
`2009/0083852 Al*
`2010/0138931 Al * 6/2010 Thorley et al. .................. 726/27
`* cited by examiner
`
`Primary Examiner - Lisa Lewis
`Assistant Examiner - Maung Lwin
`(74) Attorney, Agent, or Firm - Beyer Law Group LLP
`
`(57)
`
`ABSTRACT
`
`A computer network of an enterprise includes a central man(cid:173)
`agement computer linking at least one trusted host computer
`with at least one user computer. The trusted host computer is
`not used for normal day-to-day activities within the enter(cid:173)
`prise, and may also not be used for reading electronic mail nor
`for accessing the Internet and downloading Web site content.
`Antivirus software on the user computer screens for suspect
`activity or features and, if found, the suspect activity or fea(cid:173)
`tures are compared to rules database. If a determination of
`malware cannot be made, then these unresolved activities or
`features are sent to the central management computer to be
`compared to the trusted, known activities and features of the
`trusted computer. The suspect activities may be deemed
`acceptable if activities are shared amongst a certain number
`of user computers all configured to perform the same func(cid:173)
`tion. A user computer may be compared against itself over
`time.
`
`8,260,961 Bl * 9/2012 Wilkinson et al. ............ 709/245
`2002/0194489 Al* 12/2002 Almogy et al. ............... 713/200
`
`20 Claims, 9 Drawing Sheets
`
`Trusted Host
`
`Host A
`
`234
`
`235
`
`8% validated
`activity, due to
`shared host
`functions
`
`Host D
`
`Palo Alto Networks - Exhibit 1005
`Palo Alto Networks v. Taasera - IPR2023-00704
`Page 1 of 17
`
`

`

`U.S. Patent
`
`Aug. 25, 2015
`
`Sheet 1 of 9
`
`US 9,117,075 Bl
`
`Trusted Host Computer
`
`Trusted Host Computer
`
`10
`
`\.
`
`Central
`Management
`Computer
`
`Vender Pattern
`Update Server
`
`Laptop
`
`Computer
`
`Computer
`
`FIG. 1
`
`Palo Alto Networks - Exhibit 1005
`Palo Alto Networks v. Taasera - IPR2023-00704
`Page 2 of 17
`
`

`

`U.S. Patent
`
`Aug. 25, 2015
`
`Sheet 2 of 9
`
`US 9,117,075 Bl
`
`Anti-virus
`Software
`104
`
`White List
`Registry Keys
`116
`
`White List
`Processes
`108
`
`White List
`Ports
`118
`
`White List
`System Folder
`112
`
`White List
`URLs
`106
`
`Rules
`Database
`119
`
`12.
`
`Trusted Computer
`
`FIG. 2
`
`Anti-virus
`Software
`120
`
`Sniffer
`Software
`124
`
`Computer
`
`Monitoring
`Agent
`128
`
`.~
`
`...... ---
`
`~
`
`'"
`Rules
`Database
`130
`
`H.
`
`FIG. 3
`
`Palo Alto Networks - Exhibit 1005
`Palo Alto Networks v. Taasera - IPR2023-00704
`Page 3 of 17
`
`

`

`U.S. Patent
`
`Aug. 25, 2015
`
`Sheet 3 of 9
`
`US 9,117,075 Bl
`
`Cross-Reference
`Module
`140
`
`Rules
`Database
`150
`
`Administrator
`Domain Tree
`160
`
`Exception Rules
`Database
`170
`
`Central Management Computer
`
`20
`
`FIG. 4
`
`Palo Alto Networks - Exhibit 1005
`Palo Alto Networks v. Taasera - IPR2023-00704
`Page 4 of 17
`
`

`

`U.S. Patent
`
`Aug. 25, 2015
`
`Sheet 4 of 9
`
`US 9,117,075 Bl
`
`209
`
`25% of Host A is "known
`good", we don't have to
`worr_y about anything that
`falls into this area.
`
`FIG. 5
`
`214
`
`25%
`
`10%
`
`FIG. 6
`
`Palo Alto Networks - Exhibit 1005
`Palo Alto Networks v. Taasera - IPR2023-00704
`Page 5 of 17
`
`

`

`U.S. Patent
`
`Aug. 25, 2015
`
`Sheet 5 of 9
`
`US 9,117,075 Bl
`
`223
`
`Host D
`
`227
`
`FIG. 7
`
`225
`
`Trusted Host
`
`Host A
`
`234
`
`235
`
`8% validated
`activity, due to
`shared host
`functions
`
`Host D
`
`FIG. 8
`
`Palo Alto Networks - Exhibit 1005
`Palo Alto Networks v. Taasera - IPR2023-00704
`Page 6 of 17
`
`

`

`U.S. Patent
`
`Aug. 25, 2015
`
`Sheet 6 of 9
`
`US 9,117,075 Bl
`
`Trusted Host
`
`Host A
`
`FIG. 9
`
`254
`
`259
`
`25% over-lap for unknown
`activities on the same Host
`over a period of time
`
`FIG. 10
`
`Palo Alto Networks - Exhibit 1005
`Palo Alto Networks v. Taasera - IPR2023-00704
`Page 7 of 17
`
`

`

`U.S. Patent
`
`Aug. 25, 2015
`
`Sheet 7 of 9
`
`US 9,117,075 Bl
`
`Install AV Software
`
`Produce White Lists
`
`404
`
`408
`
`Add Rules Database to Central
`Computer
`
`412
`
`Add Exception Rules Database
`to Central Computer
`
`416
`
`Rush Subset of Databases out
`to each Computer
`
`Run Anomaly Monitoring
`System on User Computer to
`Capture Baseline Activities
`
`420
`
`424
`
`END
`
`FIG. 11
`
`Palo Alto Networks - Exhibit 1005
`Palo Alto Networks v. Taasera - IPR2023-00704
`Page 8 of 17
`
`

`

`U.S. Patent
`
`Aug. 25, 2015
`
`Sheet 8 of 9
`
`US 9,117,075 Bl
`
`Gather Data
`
`Gather Behaviors by Monitoring
`Agent
`
`Gather Features by Monitoring
`Agent
`
`Compare Behaviors and
`Features to Rules Database
`
`504
`
`508
`
`512
`
`Send Unresolved Behaviors and
`Features to Central Computer
`
`516
`
`520
`
`524
`
`Compare Unresolved Behaviors
`and Features to Trusted
`Computer
`
`Issue Malware Alert
`
`FIG. 12
`
`Palo Alto Networks - Exhibit 1005
`Palo Alto Networks v. Taasera - IPR2023-00704
`Page 9 of 17
`
`

`

`U.S. Patent
`
`Aug. 25, 2015
`
`Sheet 9 of 9
`
`US 9,117,075 Bl
`
`906
`
`904
`
`~ 9 0 0
`
`_5914
`0!)
`
`910
`
`FIG. 13A
`
`( 922
`
`( 924
`
`926
`
`(
`
`PROCESSOR(S)
`
`MEMORY
`
`FIXED DISK
`
`J~
`
`,,.
`
`~
`
`'
`
`(904
`
`'"
`DISPLAY
`
`J~
`
`11'
`
`'
`
`~
`
`,
`
`-~
`
`(910
`
`/912
`
`,,. (930
`
`"
`KEYBOARD
`
`"
`MOUSE
`
`SPEAKERS
`
`FIG. 13B
`
`~ 9 0 0
`
`( 914
`REMOVABLE
`DISK
`'
`
`920
`-
`
`'
`
`'
`
`,,. /940
`NETWORK
`INTERFACE
`
`Palo Alto Networks - Exhibit 1005
`Palo Alto Networks v. Taasera - IPR2023-00704
`Page 10 of 17
`
`

`

`US 9,117,075 Bl
`
`1
`EARLY MALWARE DETECTION BY
`CROSS-REFERENCING HOST DATA
`
`FIELD OF THE INVENTION
`
`The present invention relates generally to malware detec(cid:173)
`tion. More specifically, the present invention relates to cross(cid:173)
`referencing host data on a trusted enterprise host computer to
`compare to a suspect computer.
`
`BACKGROUND OF THE INVENTION
`
`2
`that includes a known, trusted host computer whose activities,
`behaviors and features may be compared against suspect
`behaviors of a user computer.
`In one embodiment, anomaly monitoring software on the
`5 user computer detects activities that, while not malware, are
`suspect. These activities are compared against a rules data(cid:173)
`base on the user computer. If the behavior is unresolved, the
`behaviors are compared against any of a number of white lists
`and known good behavior on the trusted computer to deter-
`IO mine if the activity matches that of the trusted computer. If
`there is no match, then a malware alert may be generated.
`Currently, computers are subject to malware attacks and
`Exceptions may be allowed for activities that do not match but
`considerable effort is expended in trying to prevent these
`are shared amongst a certain number of user computers that
`attacks or to address them once they occur. One particular
`type of virus is known as the zero-day virus. A zero-day virus 15 are peers or share a similar usage or purpose. The activities
`are more likely to be labeled as malware if the user computer
`is a previously-unknown computer virus for which specific
`is a rogue computer. The anomaly monitoring software
`antivirus software signatures are not yet available. Because a
`includes network sniffers, any IDS, antivirus software, and
`signature is not yet available, the virus cannot be detected by
`other targeted protection software
`software using virus patterns. Normally, antivirus software
`In a second embodiment, behavior on a first computer is
`that relies upon signatures to identify malware can be effec- 20
`tive, but cannot defend against malware unless samples have
`anomalous and behavior on a second computer is anomalous,
`been obtained and updates distributed to users. Therefore,
`the behaviors even rising to the level of suspected of being
`signature-based approaches are not effective against zero-day
`caused by malware. A central management computer deter(cid:173)
`viruses.
`mines that both these behaviors are the same and that these
`Similarly, a zero-day ( or zero-hour or day-zero) attack is 25
`behaviors are not shared with any behavior of a trusted com(cid:173)
`malware that exploits computer application vulnerabilities
`puter. Nevertheless, if both the first and second computers
`that are unknown to the software developer. Zero-day attacks
`perform a common service function within the enterprise,
`are used by attackers before the software developer knows
`then it may be determined that no malware alert is necessary.
`about the vulnerability.
`On the other hand, if a large number of unmatched behaviors
`Techniques exist to limit the effectiveness of zero-day
`are found ( on a single machine), then a malware alert may be
`attacks. For example, the Microsoft operating system 30
`generated.
`includes limited protection against generic memory corrup(cid:173)
`In a third embodiment, it is determined that a common,
`tion vulnerabilities. Another example is "multiple layers" that
`unknown behavior is shared amongst numerous (user-config(cid:173)
`provides service-agnostic protection. Access control lists are
`urable) computers within an enterprise. It is further deter(cid:173)
`implemented in the service itself, restricting network access
`mined that this same behavior is not shared with any behavior
`via local server firewalls, and then protecting the entire net- 35
`of the trusted computer. If the behavior does not match with
`work with a hardware firewall. The disadvantage is that net(cid:173)
`work access can be restricted and an extra hardware device
`any rule in an exception database and the behavior does not
`needed. The use of"port knocking" or single packet authori(cid:173)
`match with any white list on the trusted computer, then a
`zation daemons may provide effective protection against
`determination is made that malware is present.
`zero-day attacks in network services. These techniques, how- 40
`In a fourth embodiment, the activities, behaviors and fea-
`ever, are not suitable for environments with a large number of
`tures of a user computer are analyzed by anomaly monitoring
`users.
`software at a first point in time. It is determined which of these
`The use of white lists can protect against zero day attacks.
`activities, behaviors and features are not in common with a
`White lists will only allow known good applications to access
`trusted host computer. The user computer is then analyzed at
`a system and so any unknown applications are not allowed
`45 numerous points in time over a period of time. If a certain
`access. Although the use of white lists can be effective against
`percentage of these activities, behaviors and features remain
`zero-day attacks, an application "known" to be good can in
`the same over time, then a determination may be made that
`fact have vulnerabilities that were missed in testing. To
`these are likely are benign or regular behavior of the user
`increase protection, the use of white lists is often combined
`computer. Activities, behaviors and features that pop out from
`with the use of a blacklist of virus definitions, but this can be
`50 the normal and regular temporal activities, behaviors and
`quite restrictive to the user.
`features are considered suspicious.
`Another method to avoid zero-day attacks from a user
`perspective is to wait for a lengthy period of time before
`upgrading to a new version of software. The idea is that later
`software revisions will fix software vulnerabilities. While this
`method avoids zero-day attacks that are discovered before the 55
`next software release, security holes in any software can be
`discovered at any time. Also, the user must forgo the new
`version of software for a period of time.
`Given the importance of early threat detection without the
`use of pattern files, and the various drawbacks of prior art 60
`approaches, and improved technique is desired to detect zero(cid:173)
`day malicious activities on enterprise host computers.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`The invention, together with further advantages thereof,
`may best be understood by reference to the following descrip(cid:173)
`tion taken in conjunction with the accompanying drawings in
`which:
`FIG. 1 illustrates a computer system within an enterprise
`for use with an embodiment of the invention.
`FIG. 2 is a block diagram of trusted computer.
`FIG. 3 is a block diagram of user computer.
`FIG. 4 is a block diagram of central management computer.
`FIG. 5 is a Venn diagram showing trusted computer and
`65 two other computers.
`FIG. 6 is a Venn diagram showing trusted computer and
`two other computers.
`
`SUMMARY OF THE INVENTION
`
`To achieve the foregoing, and in accordance with the pur(cid:173)
`pose of the present invention, a computer system is disclosed
`
`Palo Alto Networks - Exhibit 1005
`Palo Alto Networks v. Taasera - IPR2023-00704
`Page 11 of 17
`
`

`

`US 9,117,075 Bl
`
`3
`FIG. 7 is a Venn diagram showing trusted computer and
`three other computers.
`FIG. 8 is a Venn diagram showing trusted computer and
`two system computers.
`FIG. 9 is a Venn diagram showing trusted computer and
`three enterprise computers.
`FIG. 10 is a Venn diagram showing trusted computer and a
`single user computer over time, shown as three computers.
`FIG. 11 is a flow diagram describing activities used to set
`up the present invention.
`FIG. 12 is a flow diagram describing how the features and
`behaviors of a user computer are compared to the trusted
`computer.
`FIGS. 13A and 13B illustrate a computer system suitable
`for implementing embodiments of the present invention.
`
`DETAILED DESCRIPTION OF THE INVENTION
`
`4
`have its version of white lists and allowed behavior. What
`might be considered normal in one location may be different
`from another; this distributed management thus allows for a
`more accurate description of what is allowed or normal in
`5 each local business unit.
`The data, features and behaviors of this host computer will
`be compared against other computers within the system in
`order to determine if a possible zero-day attack is occurring
`on any of the other computers. In one embodiment, there are
`10 any number of trusted host computers each dedicated to a
`particular function within the enterprise. For example, while
`trusted computer 12 may be configured as a database server of
`the enterprise, trusted computer 13 may be configured as an
`e-mail server. Other types of trusted computers configured to
`15 mimic a function within the enterprise include: end user com(cid:173)
`puters (IT, development, finance, administration), proxy serv(cid:173)
`ers, storage servers, source code build/management servers,
`and pattern update servers. Thus, if an actual database server
`within the corporation is suspected of having malware, its
`20 features and behaviors may be compared to the "gold stan(cid:173)
`dard" of trusted host computer 13 configured as a database
`server. Preferably, each trusted computer is a standalone hard(cid:173)
`ware appliance that may take the form of a laptop computer,
`desktop computer, rack-mounted device, etc.
`Computers 14-18 are user computers or other system com-
`puters that run antivirus and other software continuously to
`monitor the activities of each computer. These computers are
`used for the normal day-to-day business of enterprise, may be
`accessed by users for routine activities, used for reading elec-
`30 tronic mail, used for accessing the Internet to download infor(cid:173)
`mation, etc. Each computer may be connected over a suitable
`network connection 30 to the management computer 20, such
`as an Ethernet connection, wireless connection or any other
`suitable network connection. These computers need not nec-
`35 essarily be linked hub-and-spoke to the management com(cid:173)
`puter, but may be formed into network in any suitable fashion.
`Laptop computer 18 is an example of a portable computer
`within the network that may engage the network at various
`times and therefore be subject to malware detection by the
`40 invention described herein. Laptop computer 18 may also be
`an example of a rogue computer, that is, a computer that is not
`managed by the IT department of the corporation and does not
`necessarily have installed the monitoring agent 128 is shown
`in FIG. 3. As such, a rogue computer falls under greater
`45 suspicion if unknown features or behaviors are detected upon
`it.
`
`The basic idea is that a computer system will include a
`known, trusted computer host against which cross-referenc(cid:173)
`ing can be performed. There are a variety of specific features
`and behaviors that can be used for measurement and other
`computers in the system can be compared against the trusted
`host to see what percentage of features or behaviors differ
`from the trusted host. Features and behaviors that are 25
`unknown, undetected or otherwise odd are flagged. Further,
`the percentage of features and behaviors of a suspect com(cid:173)
`puter that do not match with the trusted host can be compared
`against percentages of other computers in the system. When
`there is an aberrant feature or unknown behavior on a com(cid:173)
`puter, this information can be used to analyze the threat and to
`lower the rate of false positives when detecting zero-day
`attacks.
`Features and behaviors on one computer that differ from
`the trusted host can be correlated across other computers in
`the system to find a trend. Or, features and behaviors on one
`computer can be compared against those same features and
`behaviors on that same computer over time in order to provide
`a time-based correlation. By sharing unknown features and
`behaviors across computers within an enterprise, the confi(cid:173)
`dence associated with threat identification can be increased
`and false positives are lowered.
`
`Block Diagrams
`
`FIG. 1 illustrates a computer system 10 within an enter(cid:173)
`prise for use with an embodiment of the invention. Included
`are trusted host computers 12 and 13, any number of user
`computers 14-18, and a central management computer 20.
`Trusted host computer 12 is a known, "good" computer with 50
`software that is kept malware free and updated with the latest
`antivirus software protection at all times. In one embodiment,
`host computer 12 is not used by users for normal day-to-day
`business of the enterprise, is not connected to the Internet, is
`not used by users for reading electronic mail, and is not used 55
`for peer-to-peer or network sharing. Alternatively, the com(cid:173)
`puter 12 is connected to the Internet, but preferably should be
`on a different network than the one used for normal business
`operations. Furthermore, this computer is preferably main(cid:173)
`tained to have most up-to-date patches and virus patterns.
`And, even though this computer is not used in daily opera(cid:173)
`tions, it is set up and configured the same as the other user
`machines of the same nature.
`Alternatively, the computer system 10 may be for a local
`business unit, instead of for an entire enterprise. In this
`embodiment, the invention allows for distributed manage(cid:173)
`ment as the distributed nature allows for each business unit to
`
`The central management computer 20 runs application
`software to implement the present invention and is preferably
`in communication with each of the computers shown within
`the computer system. Its role is to gather data from the host
`and user computers, to correlate this data, and to issue alerts
`and other actions if a zero-day attack is detected. It is also
`responsible for periodically deploying updated rules (based
`on the latest correlation results) to each computer's rule data(cid:173)
`base. Preferably, the management computer is its own hard(cid:173)
`ware device and is connected via network connections to all
`host computers and user computers. All computers also have
`access over the Internet to a vendor pattern update server 24
`that provides all antivirus patterns and updates, white lists,
`60 black lists, etc.
`Not shown is sniffer software module 124 that typically
`would be placed upon a network device such as a router in
`order to capture network traffic data. This module captures
`information such as: any bad URLs accessed that were not
`65 reported by existing anti-phishing protection; various net(cid:173)
`work protocol activities (FTP, SMTP, IRC, SMB, instant mes(cid:173)
`saging, ports); IP-level packet statistics; port pings and
`
`Palo Alto Networks - Exhibit 1005
`Palo Alto Networks v. Taasera - IPR2023-00704
`Page 12 of 17
`
`

`

`US 9,117,075 Bl
`
`5
`pangs; and e-mail traffic. Sniffer software 124 may be any
`suitable software such as Snort, Tcpdump, Wireshark or Our(cid:173)
`mon.
`FIG. 2 is a block diagram of trusted computer 12. Shown
`are software modules and databases that are additional to any
`normal hardware and software of the computer. Trusted com(cid:173)
`puter 12 is a standalone computer having the software and
`databases implemented thereon. Preferably, Internet security
`protection software 104 is sophisticated, up-to-date software
`that uses at least pattern files and also reputation-based logic
`to protect the trusted computer. Examples of such software
`include antivirus, host firewall, and host and network IDSs. In
`addition, special watchdog software may be used to ensure
`that the trusted computer is not compromised by malware.
`Examples include an ACL-protected system service that
`ensures security software is always running, and monitors
`any unauthorized attempts to access system files, security
`files, or registry settings and files.
`The trusted computer also includes a number of white lists
`106-118 that indicate features allowed within the enterprise. 20
`For example, white list 106 includes particular URLs, domain
`names or other network addresses that user computers may
`contact from within the organization. White list 108 lists all
`processes ( computer and network) that are allowed to run on
`any computer within the organization. White list 112 may 25
`contain the entire contents of important system folders such
`as the operating system folder, program files, the System32
`folder, etc. Alternatively, this white list 112 may simply con(cid:173)
`tain the hash values of files within particular important folder.
`This white list is valuable because malware may often 30
`modify, replace or add files into the system folder. The white
`list in this case also serves as a monitor list: once a snapshot
`has been taken, and unless changed by authorized updates, the
`values of these registry keys should not be modified. White
`list 116 includes values of important registry keys that ma!- 35
`ware often attempts to modify, such as Run, HKCU
`(HKLM)
`\Software\Microsoft\Internet
`Explorer\*,
`HKLM\Software\Microsoft\ Windows
`NT\CurrentVersion\Winlogon\*, RunServices, RunOnce,
`RunOnceEx,
`Policies\Explorer\Run, 40
`HKLM\SOFTWARE\Classes\CLSID,
`and
`HKLM\SOFTWARE\Classes\PROTOCOLS. White list 118
`includes port numbers that are acceptable for use within the
`network and can be trusted. Other white lists that may be
`included upon the trusted computer can be customized by a
`local security operator according to business regulatory rules.
`A rules database 119 includes activities, behaviors, or other
`patterns of normal behavior that may occur within a user
`computer or over the network by the computer. For example,
`a typical rule might be "user logins are appropriate up until 50
`midnight." Alternatively, if rules database 170 of manage(cid:173)
`ment computer 20 stores all the rules for each type of trusted
`computer, then database 119 is not needed.
`Preferably, this trusted computer is running the latest ver(cid:173)
`sion of any suitable Internet security protection software 104 55
`such as antivirus, host/network IDS, host firewall, spyware
`detection, etc. The protection software should be up to date
`and running the latest version, as well as have installed the
`latest virus patterns. The operating system of this computer
`will have the latest updates, as well as any needed software 60
`patches. In addition, any URLs accessed must be good, i.e.,
`the URL must be on the white list. If the trusted computer will
`not be used for day-to-day Internet activities, it may not be
`necessary to compare URLs.
`FIG. 3 is a block diagram of user computer 14. Shown are 65
`software modules in addition to any normal hardware and
`software of the computer. Computer 14 is an example of a
`
`6
`standalone computer within the enterprise such as a user
`computer, a server computer, or any other computing device
`that the enterprise wishes to cross-reference against trusted
`computer 12. A user computer will typically be used for
`5 performing routine tasks within the organization by a user,
`reading electronic mail, accessing the Internet, etc. Prefer(cid:173)
`ably, the antivirus software 120 running on computer 14
`performs information collection as well as checking for
`viruses on the computer. The information collected for later
`10 comparison with the trusted computer includes: whether the
`computer is up-to-date on virus patterns; when the pattern
`was last updated successfully; when was the last time a scan
`was done; when was the last time this computer was infected
`by malware; has there been any attempt to shut down the
`15 antivirus software; which process attempted to shut down the
`antivirus software; when was the last virus scan performed,
`and heartbeat information for the software. Antivirus soft(cid:173)
`ware 120 need not be the same as the antivirus software on the
`trusted computer but typically should include: a virus scan(cid:173)
`ner, a firewall, Web protection, URL scanning, Internet secu(cid:173)
`rity, etc.
`Also included on computer 14 is monitoring agent soft-
`ware 128 that has the ability to monitor processes, registry
`keys, system alerts, etc. Agent 128 collects information such
`as: the function of this computer; does the computer include
`a database server; does this computer run any Web services; is
`this a proxy server; have any failures or alerts been reported in
`the event log; have any unusual files been dropped into Sys(cid:173)
`tem32; have any unusual DLLs been loaded by svchost; is
`there any application software with a new patch available but
`not yet applied; which are new the programs installed, which
`registry keys were modified, which libraries are loaded by
`known executables, etc. Agent 128 also has the ability to log
`information such as: process launches, file path names of
`launched processes, attempts to update or delete Registry
`keys, URL accesses, browsing history, network access, etc.
`Agent 128 maybe implemented using any suitable software
`but is preferably implemented as a Microsoft operating sys(cid:173)
`tem service.
`Also included within each user computer as part of the
`monitoring agent (or separately) is a rules database 130.
`Database 130 includes rules that have been downloaded from
`the central computer 20 and describe behaviors of the user
`computer that are allowed and those behaviors that are not
`45 allowed. Examples include: a user may log in to the system
`between the hours of 8 a.m. and 8 p.m.; opening of shared
`network folders is not allowed; and removable devices ( e.g.,
`a USB drive) must be scanned with antivirus software before
`its content is accessible.
`FIG. 4 is a block diagram of central management computer
`20. Shown are software modules in addition to a normal
`hardware and software of the computer. Central management
`computer 20 may be a standalone hardware device arranged
`to run the software within cross-reference module 140, or
`cross-reference module 140 may run on any other suitable
`computer. The purpose of cross-reference module 140 is to
`gather data previously described in the software modules and
`agents of the computers within the system and to correlate this
`information with the known, good information from trusted
`host computer 12. The module 140 will then be in a position
`to issue alerts, recommendations or other actions. Also
`included is a rules database 150 that includes rules to be
`downloaded by each user computer to database 130 laying out
`which are allowed behaviors and which are not.
`Typically, such a management computer also includes an
`administrator domain tree 160 to keep track of the known
`corporate computers within the network.
`
`Palo Alto Networks - Exhibit 1005
`Palo Alto Networks v. Taasera - IPR2023-00704
`Page 13 of 17
`
`

`

`US 9,117,075 Bl
`
`7
`Scenarios
`
`8
`malware. The rules database of the monitoring agent will then
`be able to flag the activities and features of this region as being
`In the below scenarios, an "unknown activity" refers to an
`suspect and it is likely that a malware alert will be generated.
`activity or behavior that existing antivirus software fails to
`An example of system operation is as follows. Consider a
`identify. For example, if a process loads a new DLL or there
`5 malware detection system rule "analyze activity if a * .exe is
`is network activity through an undocumented port, that would
`transferred, originating from a non-trusted computer after 6
`qualify as an unknown activity. Other examples include: an
`pm." Consider that this rule is triggered twice for computer
`increase in UDP packets sent in a short time period; an update
`214: once for file "a.exe" and once for file "b.exe" at different
`to System32 folder files outside of a scheduled or known
`times and to different locations. The cross-reference module
`software patch time; and a non-DHCP server experiencing a 10
`assessment is as follows. Concerning computer 214, since file
`lot of network traffic on port 25. An activity or program that
`a.exe is within region 217, allow the activity but log the
`antivirus software labels definitely as "malware" would not
`incident in an audit log. But, file b.exe is not within region
`fall in the category of"unknown activity" because the antivi(cid:173)
`217; it is in region 219. The decision would then be to gen-
`rus software has been able to conclude that malware is defi(cid:173)
`nitely present. In addition to an unknown activity, there may 15 erate an alert that computer 214 may be compromised by
`rogue machine 216.
`be features of a given computer that are unknown or suspect.
`FIG. 7 is a Venn diagram showing trusted computer 12 and
`For example, features that are logged by each monitoring
`computers 224, 226 and 228. As mentioned above, it appears
`agent for cross-reference to the trusted computer include: port
`that computer 224 and computer 226 are both affected by
`access; URL and domain access; antivirus software pattern
`20 malware because region 225 indicates that both computers
`number; running processes; contents of important registry
`share activities and features that are not in common with the
`keys, contents of important system folders; event log alerts;
`trusted computer. In addition, region 227 indicates that both
`software patches; remote machine access; and system perfor(cid:173)
`mance measures including startup time, program launch time,
`computers 224 and 228 share common activities and features
`and memory footprint of known services and applications. It
`that are not in common with the trusted computer. It is also
`is anticipated that all computers within a system of enterprise
`25 possible that region 227 indicates activities and features that
`will share a certain percentage of behaviors with the trusted
`are caused by malware, although a mitigating factor is that
`computer and will share certain percentage of features with
`computers 224 and 228 have a large percentage in common
`the trusted computer as well. If that percentage becomes too
`with the trusted computer and are therefore partially trusted.
`low or if other factors are present, then it is possible that
`Therefore, in order to avoid false positives, a rule would likely
`malware is present on the computer.
`30 conclude that the features and behaviors of region 227 should
`FIG. 5 is a Venn diagram showin