WO2020046463A1 - Software supply chain hardening via two-factor application integrity certification and monitoring - Google Patents

Software supply chain hardening via two-factor application integrity certification and monitoring Download PDF

Info

Publication number
WO2020046463A1
WO2020046463A1 PCT/US2019/039953 US2019039953W WO2020046463A1 WO 2020046463 A1 WO2020046463 A1 WO 2020046463A1 US 2019039953 W US2019039953 W US 2019039953W WO 2020046463 A1 WO2020046463 A1 WO 2020046463A1
Authority
WO
WIPO (PCT)
Prior art keywords
manifest
determining
registered
registration agent
monitoring
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/US2019/039953
Other languages
French (fr)
Inventor
Adam Bromwich
Joseph H. CHEN
Eric C. CHIEN
Haik A. MESROPIAN
Joao M. FORCADA
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Gen Digital Inc
Original Assignee
Symantec Corp
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 Symantec Corp filed Critical Symantec Corp
Publication of WO2020046463A1 publication Critical patent/WO2020046463A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55Detecting local intrusion or implementing counter-measures
    • G06F21/56Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/566Dynamic detection, i.e. detection performed at run-time, e.g. emulation, suspicious activities
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12Detection or prevention of fraud
    • H04W12/128Anti-malware arrangements, e.g. protection against SMS fraud or mobile malware

Definitions

  • a method for validating operational behaviors of objects associated with a supply chain is described.
  • at least a portion of the method may be performed by one or more computing devices that include at least one processor.
  • the method may include receiving, at a device, a request to execute an object installed on the device, determining whether a manifest defining one or more aspects of the object is registered with a registration agent installed on the device, executing the object on the device upon determining the manifest is registered with the registration agent, monitoring, via a monitoring agent installed on the device, operational behaviors of the object, and performing a security action upon determining the manifest is unregistered with the registration agent.
  • the one or more security actions include at least one of preventing the object from executing, disabling access to at least a portion of the object, disabling one or more processes associated with the object, scanning the object for malware, quarantining the object, deleting the object from the device, generating a notification indicating the object may be compromised, revoking at least one user’s access to the object, or any combination thereof.
  • the method may include identifying an operation of the object based at least in part on the monitoring and performing at least one of the one or more security actions based at least in part on determining that the identified operation is not specified by the manifest or that the manifest expressly disallows the identified operation.
  • the method may include querying a server external to the device to determine whether the manifest remains valid. In some examples, the method may include performing at least one of the one or more security actions upon determining a response from the server indicates the manifest is no longer valid and continuing to allow the object to execute and to monitor the object upon determining the response from the server indicates the manifest remains valid. In some examples, at least a portion of the content of the manifest is based at least in part on one or more behaviors of the object identified during execution time.
  • determining that the manifest is registered with the registration agent is based at least in part on determining that the manifest indicates the object is to be monitored. In some examples, determining that the manifest is registered with the registration agent includes determining that a hash included in the manifest is registered with the registration agent.
  • the one or more aspects of the object include at least one of operational behaviors, one or more files associated with the object, one or more files used by the object, one or more files the object is permitted to access, one or more processes associated with the object, one or more processes the object is allowed to initiate, one or more internet protocol (IP) addresses that the object may access, one or more network locations that the object may access, one or more cryptographic hashes associated with the object, one or more digital signatures of the object, one or more digital certificates of the object, or any combination thereof.
  • IP internet protocol
  • the monitoring agent and the registration agent operate independently of the object. In some examples, the monitoring agent and the registration agent operate independently of each other or in conjunction with each other. In some examples, the object may include at least one application.
  • the computing device may include one or more processors and memory in electronic communication with the one or more processors.
  • the memory may store computer executable instructions that when executed by the one or more processors cause the one or more processors to perform the steps of receiving, at a device, a request to execute an object installed on the device, determining whether a manifest defining one or more aspects of the object is registered with a registration agent installed on the device, executing the object on the device upon determining the manifest is registered with the registration agent, monitoring, via a monitoring agent installed on the device, operational behaviors of the object, and performing a security action upon determining the manifest is unregistered with the registration agent.
  • the one or more security actions include at least one of preventing the object from executing, disabling access to at least a portion of the object, disabling one or more processes associated with the object, scanning the object for malware, quarantining the object, deleting the object from the device, generating a notification indicating the object may be compromised, revoking at least one user’s access to the object, or any combination thereof.
  • the computing device may perform the steps of identifying an operation of the object based at least in part on the monitoring and performing at least one of the one or more security actions based at least in part on determining that the identified operation is not specified by the manifest or that the manifest expressly disallows the identified operation.
  • the computing device may perform the steps of querying a server external to the device to determine whether the manifest remains valid. In some examples, the computing device may perform the steps of performing at least one of the one or more security actions upon determining a response from the server indicates the manifest is no longer valid and continuing to allow the object to execute and to monitor the object upon determining the response from the server indicates the manifest remains valid.
  • At least a portion of the content of the manifest is based at least in part on one or more behaviors of the object identified during execution time. In some examples, determining that the manifest is registered with the registration agent is based at least in part on determining that the manifest indicates the object is to be monitored. In some examples, determining that the manifest is registered with the registration agent includes determining that a hash included in the manifest is registered with the registration agent.
  • the computer-program product may include a non-transitory computer-readable medium storing instructions thereon.
  • the execution of the instructions may cause the one or more processors to perform the steps of receiving, at a device, a request to execute an object installed on the device, determining whether a manifest defining one or more aspects of the object is registered with a registration agent installed on the device, executing the object on the device upon determining the manifest is registered with the registration agent, monitoring, via a monitoring agent installed on the device, operational behaviors of the object, and performing a security action upon determining the manifest is unregistered with the registration agent.
  • FIG. 1 is a block diagram illustrating one embodiment of an environment in which the present systems and methods may be implemented
  • FIG. 2 is a block diagram illustrating one example of a validation module
  • FIG. 3 is a block diagram illustrating one example of a manifest module
  • FIG. 4 is a swim diagram illustrating one embodiment of a method in accordance with various aspects of this disclosure.
  • FIG. 5 is a flow diagram illustrating one embodiment of a method in accordance with various aspects of this disclosure.
  • FIG. 6 is a flow diagram illustrating one embodiment of a method in accordance with various aspects of this disclosure.
  • FIG. 7 is a flow diagram illustrating one embodiment of a method in accordance with various aspects of this disclosure.
  • FIG.8 depicts a block diagram of a computer system suitable for implementing the present systems and methods.
  • the systems and methods described herein relate to supply chain management. More specifically, the systems and methods described herein relate to validating operational behaviors of objects associated with a supply chain.
  • independent software vendors (IS Vs) and other software publishers and software vendors e.g., mobile application stores, etc.
  • IS Vs Independent software vendors
  • other software publishers and software vendors e.g., mobile application stores, etc.
  • the compromised software may eventually make its way to both individual and corporate customers.
  • vendors may be currently unable to vouch for the behaviors their preinstalled software will have in the field once deployed.
  • a manifest may be assigned to an application that prescribes how the application is intended to work in a respective field. In some cases, the manifest may be manually generated by an administrator, etc.
  • the manifest may be generated by monitoring the behaviors of a software application during execution time, recording the operational behaviors of the software application (e.g., processes initiated, files accessed, internet protocol (IP) addresses accessed, network locations accessed, etc.), and generating the manifest based at least in part on the observed operational behaviors of the software application during execution time.
  • operational behaviors of the software application e.g., processes initiated, files accessed, internet protocol (IP) addresses accessed, network locations accessed, etc.
  • an external component e.g., software or hardware
  • an external component may be installed alongside the“signed” executable that monitors the behavior of the application and blocks any non-intended behaviors.
  • a service that allows the manufacturer of the application to register with the monitor that an application is intended to be monitored may be described. This may be accomplished by registering the particular application with the external monitor using a hash.
  • the manifest’s hash may also be registered with the registrar.
  • the method may include a sub component of the external monitor that prevents the execution of any registered application that does not exhibit the manifest that was registered.
  • a subsystem may perform a cloud lookup on whether a manifest is still valid. Accordingly, the present techniques may provide for the revocation of a particular manifest upon determining the manifest is compromised in one way or another.
  • the aforementioned techniques may allow suppliers to partner with vendors to secure their supply chain. Additionally, the provided techniques provide vendors and end users (and enterprises) that the software shipped behaves as the vendor expects it should. In some cases, certificates may provide a confidence on who wrote/shipped the software. The present techniques add a layer of protection that the certified software would be limited to exhibiting certain behaviors as prescribed by the vendor. Extensions of the present techniques could involve telemetry for both well behaved and poorly behaved applications with notifications to the end user as well as the vendor. Furthermore, integrations could be made beyond verifying the supply chain integrity. Web site hosts could potentially deploy distributed computations applications with the consent of the user if the user had the confidence that the deployed module conformed to the advertised behaviors.
  • FIG. 1 is a block diagram illustrating one embodiment of an environment 100 in which the present systems and methods may be implemented.
  • the systems and methods described herein may be performed via device (e.g device 105).
  • the environment 100 may include a device 105, a computing device 150, server 1 10, and a network 1 15 that allows the device 105, the computing device 150, the server 1 10, and the database 120 to communicate with one another.
  • the environment 100 may include a remote device (e.g., a remote computing device; not shown) in communication with one or more of device 105 and computing device 150.
  • Examples of the device 105 may include any combination of mobile devices, smart phones, personal computing devices, computers, laptops, desktops, servers, media content set top boxes, WiFi routers, Internet of Things (IoT) devices (e.g., a thermostat, home appliance, etc.) or any combination thereof.
  • device 105 may include a validation module 145 integrated within device 105, or may be in communication with a device configuration module via network 1 15.
  • device 105 may be in communication with a remote device (e.g., a remote computing device; not shown).
  • Examples of computing device 150 may include at least one of one or more client machines, one or more mobile computing devices, one or more laptops, one or more desktops, one or more servers, one or more media set top boxes, or any combination thereof.
  • Examples of server 1 10 may include any combination of a data server, a cloud server, proxy server, mail server, web server, application server, database server, communications server, file server, home server, mobile server, name server, or any combination thereof.
  • computing device 150 is depicted as connecting to device 105 via network 1 15, in one embodiment, device 105 may connect directly to computing device 150. In some cases, device 105 may connect or attach to computing device 150 and/or server 1 10 via a wired and/or wireless connection. In some cases, device 105 may attach to any combination of a port, socket, and slot of computing device 150 and/or server 1 10.
  • Examples of server 1 10 may include any combination of a data server, a cloud server, proxy server, mail server, web server, application server, database server, communications server, file server, home server, mobile server, name server, or any combination thereof.
  • a remote computing device may connect to device 105 and/or computing device 150 via network 1 15.
  • a remote computing device may connect directly to device 105 and/or computing device 150.
  • device 105 and/or computing device 150 may connect or attach to a remote computing device and/or server 1 10 via a wired and/or wireless connection.
  • device 105 may attach to any combination of a port, socket, and slot of computing device 150 and/or server 1 10.
  • device 105 may connect and/or communicate with computing device 150 via network 1 15.
  • the device 105 may include a user interface 135, object 140, and validation module 145.
  • object 140 may be installed on one or more computing devices (e.g., device 105, computing device 150, server 1 10, etc.).
  • object 140 may include a user interface that enables a user to interface with a function of device 105, validation module 145, computing device 150, and/or server 1 10.
  • object 140 may include a software application, one or more files, and/or a component or sub-component related to a software application.
  • object 140 may include a mobile software application downloaded over a data network (e.g., from server 1 10 via network 1 15) and installed on device 105.
  • device 105 may communicate with server 1 10 and/or computing device 150 via network 1 15.
  • network 1 15 may include any combination of cloud networks, local area networks (LAN), wide area networks (WAN), virtual private networks (VPN), wireless networks (using 802.1 1 , for example), cellular networks (using 3G and/or LTE, for example), etc.
  • the network 1 15 may include the Internet.
  • Examples of computing device 150 may include a network switch, wired and/or wireless router, firewall, intrusion detection system, ethernet hub, network bridge, bridge router, modem (e.g., cable modem), protocol converter, network repeater, network gateway, network card, network adapter, proxy server, wireless access point, fiber media converter, network address translator, network server, a personal or mobile computing device (e.g., a computing device with a hotspot connection enabled), or any combination thereof.
  • the device 105 may not include validation module 145.
  • device 105 may include object 140 that allows device 105 to interface with a separate device or module via validation module 145 located on another device such as a remote computing device (not shown) and/or server 1 10.
  • device 105, computing device 150, and server 1 10 may include validation module 145 where at least a portion of the functions of validation module 145 are performed separately and/or concurrently on device 105, computing device 150, and/or server 1 10.
  • a user may access the functions of computing device 150 from device 105 (e.g. , directly or through device 105 via validation module 145).
  • a device 105 may include a mobile application that interfaces with one or more functions of computing device 150, validation module 145, and/or server 1 10.
  • server 1 10 may be coupled to database 120.
  • Database 120 may be internal or external to the server 1 10.
  • device 105 and/or computing device 150 may be coupled to database 120.
  • database 120 may be internally or externally connected directly to device 105 and/or computing device 150.
  • database 120 may be internally or externally connected directly to computing device 150 and/or one or more network devices such as a gateway, switch, router, intrusion detection system, etc.
  • Database 120 may include manifest settings 165.
  • a manifest may be stored on device 105 in conjunction with an installation of a software application on device 105.
  • a manifest may be or may refer to a file that contains settings that informs an operating system how to handle an application when it is started.
  • the manifest may be embedded inside the program file (e.g., as a resource) or it may be located in a separate external file (e.g., an Extensible Markup Language (XML) file). If the manifest is placed in a separate file, then the file may be located in the same folder as the executable file and it may have a same filename as the program file, but with a different filename extension added at the end.
  • XML Extensible Markup Language
  • manifests may be used with library files (e.g., DLL files) or executable files (e.g., .exe files). Manifests that are used with programs are may be referred to as application manifests and manifests that are used with DLL files and other library files may be referred to as assembly manifests.
  • the settings in a manifest may be specified by using the XML language.
  • a manifest may include information relating to whether a particular application requires administrator privileges or if standard user privileges are enough.
  • device 105 may download a software application over network 1 15 via server 1 10.
  • the software application may include a manifest.
  • device 105 in conjunction with validation module 145, may install a software application that includes a manifest.
  • the manifest may include metadata for a group of accompanying files that are part of a set or coherent unit of a software application. Lor example, the files of object 140 may be associated with the installed software application.
  • the manifest may describe at least one of the name, unique ID, version number, license, and one or more files of the object 140, or any combination thereof.
  • computing device 150 may connect directly to device 105 between device 105 and network 1 15. Additionally or alternatively, computing device 150 may connect directly to server 1 10 between server 1 10 and network 1 15.
  • validation module 145 may validate operational behaviors of object 140 based on information included in the manifest.
  • validation module 145 may be configured to perform the systems and methods described herein in conjunction with object 140 and/or manifest settings 165.
  • Manifest settings 165 may contain information (e.g., files) relating to a manner in which a software application associated with the manifest is intended to operate (e.g., object 140 installed on device 105).
  • object 140 if object 140 is operating in a manner in which it is not intended to operate, validation module 145 may perform one or more security actions to prohibit the operation of object 140. Further details regarding the validation module 145 are discussed below.
  • FIG. 2 is a block diagram illustrating one example of validation module l45-a.
  • Validation module l45-a may be one example of validation module 145 depicted in FIG. 1.
  • validation module l 45-a may include a manifest module 210, an object execution module 215, an monitor module 220, and a security action module 225.
  • the validation module l45-a may validate one or more operational behaviors of an object (e.g., object 140 as described with reference to FIG. 1 ) associated with a supply chain.
  • object e.g., object 140 as described with reference to FIG. 1
  • Each of manifest module 210, object execution module 215, monitor module 220, and security action module 225 may facilitate validating the operational behaviors of the object.
  • a supply chain e.g., a software distribution service configured to distribute software applications over a data network
  • various individual and/or corporate customers may provide various applications managed by a common vendor.
  • the validation module l45-a may validate one or more operational behaviors of a particular application to ensure that the application runs as intended when downloaded and installed on a user device (e.g., device 105).
  • object execution module 215 may receive a request to execute an object (e.g., object 140 as described with reference to FIG. 1) installed on the device (e.g., device 105 as described with reference to FIG. 1 ), manifest module 210 may determine whether a manifest of the object is registered with a registration agent installed on the device, object execution module 215 may execute the object on the device, monitor module 220 may monitor one or more operational behaviors of the object, and security action module 225 may perform one or more security actions on the device.
  • object e.g., object 140 as described with reference to FIG. 1
  • manifest module 210 may determine whether a manifest of the object is registered with a registration agent installed on the device
  • object execution module 215 may execute the object on the device
  • monitor module 220 may monitor one or more operational behaviors of the object
  • security action module 225 may perform one or more security actions on the device.
  • object execution module 215 may receive a request to execute an object installed on the device.
  • the object may be or may include a file, an application, or a component or sub-component related to an application.
  • one or more aspects of the object may include at least one of operational behaviors, one or more files associated with the object, one or more files used by the object, one or more files the object is permitted to access, one or more processes associated with the object, one or more processes the object is allowed to initiate, one or more internet protocol (IP) addresses that the object may access, one or more network locations that the object may access, one or more cryptographic hashes associated with the object, one or more digital signatures of the object, one or more digital certificates of the object, or any combination thereof.
  • IP internet protocol
  • the object may relate to operational aspects of one or more components and/or files associated with a device (e.g., device 105 as described with reference to FIG. 1 ). Executing the object may thus cause the object (e.g. , the application) to begin running on the device.
  • a device e.g., device 105 as described with reference to FIG. 1 .
  • Executing the object may thus cause the object (e.g. , the application) to begin running on the device.
  • the manifest module 210 may determine whether a manifest of the object is registered with a registration agent installed on the device.
  • the manifest may define one or more aspects of the object.
  • the manifest may define the manner in which the object is intended to run.
  • the manifest may define one or more parameters (e.g., operating characteristics) that the object, when executed, should operate within.
  • the validation module l45-a may communicate with a database (e.g. , database 120 as described with reference to FIG. 1 ) to determine whether the object is operating properly.
  • the validation module l 45-a may communicate with a database to determine whether the object is operating according to the manifest settings (e.g., manifest settings 165 as described with reference to FIG. 1) stored at the database.
  • the manifest settings e.g., manifest settings 165 as described with reference to FIG. 1
  • one or more aspects of the object may include a particular IP address to which the object may access. Accordingly, registering the manifest with the registration agent may indicate to the device which IP address (or IP addresses) the object may access (or is intended to access).
  • the object execution module 215 may execute the object on the device based on determining that the manifest is registered with the registration agent. As described above, executing the object may result in the object running on the device. In some cases, registering the manifest with the registration agent may result in the validation module l45-a determining whether an object (e.g., object 140, a software application executing on device 105, etc.) is operating according to one or more predetermined parameters (e.g., running according to manifest settings 165 as described with reference to FIG. 1 ). In some cases, registering the manifest may occur before executing the object. In one example, one or more aspects of the operational aspects of the object may include a particular IP address to which the object may access and registering the manifest with the registration agent may indicate to the device which IP address the object may access.
  • the monitor module 220 may monitor the operational behaviors of the object installed on the device. In some examples, the monitor module may monitor the operational behaviors of the object via a monitoring agent. As described above, the operational behaviors of the object may be or may be associated with one or more desired or expected operational characteristics. In some examples, the expected operational characteristics may be described by an Internet Service Provider (ISP). For example, the expected operational characteristics may be made available to the general public via a public mechanism (e.g., via a publicly available ledger, etc.) to ensure transparency of the expected operational characteristics. In some examples, the monitor module 220 may monitor which IP address(es) the object accesses.
  • ISP Internet Service Provider
  • the monitor module 220 may monitor which IP address(es) the object accesses.
  • the monitor module 220 may monitor the object and determine, in conjunction with analysis of the registered manifest, whether the actual operational characteristics of the object are operating outside of the desired or expected operational characteristics. If the operational characteristics are operating outside of the desired or expected characteristics, the validation module l45-a may perform one or more security actions to ensure the object ceases to operate in such an undesired manner. For example, if the object accesses one or more unintended IP addresses, a security action may be performed (e.g., preventing the object from accessing any additional IP addresses until the issue is resolved).
  • the security action module 225 may perform one or more security actions based on determining that the manifest is unregistered with the registration agent.
  • the security action may be or may include preventing the object from executing, disabling access to at least a portion of the object, disabling one or more processes associated with the object, scanning the object for malware, quarantining the object, deleting the object from the device, generating a notification indicating the object may be compromised, revoking at least one user’s access to the object.
  • a security action may be performed to prevent the object from accessing any additional IP addresses if the object accesses one or more unintended IP addresses.
  • the security action module 225 may be responsible for revoking privileges of the object if the object operates in an unintended or unexpected manner.
  • FIG. 3 is a block diagram illustrating one example of a manifest module 2l 0-a.
  • Manifest module 2l 0-a may be one example of manifest module 210 as depicted in FIG. 2.
  • manifest module 2l 0-a may include an identification module 305, a determination module 310, a registration module 315, and an external querying module 320.
  • the action(s) performed by the manifest module 210 described above with reference to FIG. 2 may determine whether a manifest of the object is registered with a registration agent installed on the device (e.g., device 105 as described with reference to FIG. 1 ). Accordingly, the identification module 305 may identify an operation of an object associated with a device (e.g., a software application installed on device 105 as described with reference to FIG. 1 ), the determination module 310 may determine whether a manifest of the object is registered with a registration agent installed on the device, the registration module 315 may register the manifest of the object, and the external querying module 320 may query a database to ensure that the object is operating as prescribed.
  • a registration agent installed on the device
  • the registration module 315 may register the manifest of the object
  • the external querying module 320 may query a database to ensure that the object is operating as prescribed.
  • registration module 315 may include one or more registration agents and/or be referred to as a registration agent.
  • manifest module 2l 0-a may facilitate the validation process as described above with reference to FIG. 2. For example, manifest module 2l 0-a may determine whether one or more operations of an object installed on a device (e.g., object 140 installed on device 105 as described with reference to FIG. 1) are valid, or whether one or more operations of an object installed on a device remain valid (e.g., after a predetermined time period).
  • the identification module 305 may identify an operation of an object (e.g., object 140).
  • the object may be or may include a file, an application, or a component or sub-component related to an application. Accordingly, an operation of the object may be or may be related to particular operational behaviors including file access, processes the object is allowed to initiate, IP addresses that the object may access, network locations that the object may access, and the like.
  • the manifest stored at the device may depend on the type of operation of the object identified by the identification module 305.
  • the determination module 310 may determine whether the manifest of the object is registered with a registration agent of the device. More specifically, in some examples the determination module 310 may determine whether the identified operation of the object is registered with the registration agent. As described above, the purpose of the registering the object may be to determine whether the object is operating properly. In one example, registration agent may communicate to the validation module 145 -a whether the object is operating according to the manifest settings (e.g. , manifest settings 165 as described with reference to FIG. 1) stored at the database. For example, if the manifest is associated with a particular IP address that the object is intended and/or allowed to access, then the validation module l45-a may determine whether the actual IP address that the object is accessing is the intended and/or allowed IP address. Thus, the identified operation may be registered with the registration agent validate the operational behaviors of the object. Accordingly, if the identified operation is not registered with the registration agent then registration module 315 may register the identified operation.
  • the manifest settings e.g. , manifest settings 165 as described with reference to FIG. 1
  • the registration module 315 may register a manifest.
  • the manifest may specify one or more allowed operations of a software application and/or may specify one or more operations not allowed by the software application.
  • the registration module 315 may communicate to the validation module l45-a whether an object (e.g., object 140) is operating according to the manifest settings (e.g., a manifest stored on device 105 and/or manifest settings 165, etc.). Accordingly, by registering the manifest, one or more modules may compare the actual behavior a software application to the identified operation of the manifest registered by and/or with the registration module 315.
  • the external querying module 320 may query an external device (e.g., database 120 as described with reference to FIG. 1 ) to determine whether the manifest remains valid.
  • a manifest e.g., one or more aspects of a manifest
  • the external querying module 320 may query the external device to determine if the manifest remains valid. In some examples, if the manifest is invalid (e.g., due to an update as described above), the manifest may be retransmitted to the device.
  • the manifest may be validated (e.g., via validation module l 45-a as described with reference to FIG. 1) without a security action being performed.
  • a security action e.g., preventing an object from accessing a particular IP address
  • the security action may be performed based on a manifest being invalid, and the security action may cease (e.g. , allow the object to begin accessing a particular IP address) based on the manifest being retransmitted to the device.
  • validating operational behaviors e.g., as conducted by validation module 145- a
  • FIG. 4 is a swim diagram illustrating one embodiment of a method 400 that supports validating operational behaviors of objects associated with a supply chain.
  • the method 400 may be implemented by a device l 05-a, computing device l 50-a, and/or database l20-a.
  • device l 05-a may be an example of device 105 as described with respect to FIG. 1
  • computing device l 50-a may be an example of computing device 150 as described with respect to FIG. 1
  • database l20-a may be an example of database 120 as described with respect to FIG. 1.
  • the method 400 may be implemented in conjunction with server 1 10, network 1 15, components thereof, or any combination thereof.
  • device l 05-a may be referred to as a user device and may be associated with a user seeking to validate operational behaviors of one or more objects associated with a supply chain.
  • a manifest may be installed at device l 05-a.
  • a manifest may be or may include information relating to an object. More specifically, in some examples, the manifest may include information about one or more IP addresses that the object is intended and/or allowed to access.
  • the manifest may be installed at device l 05-a by and/or in conjunction with a validation module (e.g., validation module 145).
  • the manifest may be stored at the database l 20-a and may be bundled with a software application that is transmitted to, and subsequently installed on, device l 05-a in conjunction with one or more modules (e.g., validation module 145).
  • the device 105 -a may receive a request to execute an object installed on the device l 05-a.
  • the request may be received from network device l 07-a and in other examples the request may be received from database l20-a.
  • network device l 07-a (or database l20-a) may transmit the request to the device l 05-a.
  • the object may be or may be associated with a particular IP address.
  • device l 05-a may execute the object which may allow the device to access the prescribed IP address.
  • the device l 05-a may optionally identify an operation associated with the object. For example, the device 105 -a may identify the IP address that the object may access.
  • the device l 05-a may determine whether the manifest is registered with a registration agent of the device l 05-a. By registering the manifest with the registration agent, the validation module (e.g., validation module l 45-a as described with reference to FIG. 2) may communicate with a database (e.g., database 120 as described with reference to FIG. 1 ) to determine whether the object is operating properly.
  • a database e.g., database 120 as described with reference to FIG. 1
  • the validation module may communicate with the manifest registration 430 of database l20-a to determine whether the object is operating according to the manifest settings (e.g., manifest settings 165 as described with reference to FIG. 1 ) stored at the database l 20-a.
  • the manifest may include a cryptographic hash. Accordingly, the hash may be registered with the registration agent and stored at the database l20-a, and the registration may be verified by comparing the hash registered with the registration agent to the hash stored at the database l 20-a.
  • the device l 05-a may execute the object based on determining that the manifest is registered with the registration agent. As described above, executing the object may result in the object running on the device. Because registering the manifest with the registration agent may result in the validation module determining whether the object is operating according to one or more predetermined parameters (e.g., running according to manifest settings 165 as described with reference to FIG. 1), registering the manifest is a prerequisite to executing the object.
  • predetermined parameters e.g., running according to manifest settings 165 as described with reference to FIG. 1
  • operational behaviors of the manifest may be optionally monitored.
  • the operational behaviors of the manifest may be associated with one or more desired or expected operational characteristics of the object.
  • the device 105 -a may determine whether the operational characteristics are operating as expected by comparing the actual operational characteristics (e.g., of the object) to a listing of expected operational characteristics (e.g., manifest settings 445 stored at database l20-a).
  • expected operational characteristics e.g., manifest settings 445 stored at database l20-a.
  • the validation module e.g., the validation module l45-a as described with reference to FIG. 1
  • a security action may be performed by the device l 05-a.
  • the security action module e.g., security action module 225 as described with reference to FIG. 2 may perform one or more security actions based on determining that the manifest is unregistered with the registration agent.
  • the security action may be or may include preventing the object from executing, disabling access to at least a portion of the object, disabling one or more processes associated with the object, scanning the object for malware, quarantining the object, deleting the object from the device, generating a notification indicating the object may be compromised, revoking at least one user’s access to the object.
  • a security action may be performed when the object of the device l 05-a is operating unexpectedly or in an unintended manner.
  • the device l 05-a may halt any unexpected or unintended behavior of the previously-executed object.
  • the device l 05-a may optionally transmit a query (e.g. , to database l 20-a) to determine whether the manifest remains valid.
  • a manifest may be updated due to one of many happenings.
  • a manifest may be updated as part of a routine software or security update.
  • the device 105- a may transmit a query to the database l20-a, and may subsequently receive a response (not shown) that contains information related to the operational characteristics of the manifest.
  • the device l 05-a may optionally perform a security action at 460.
  • the device l 05-a may receive information from the database l 20-a indicating that the object is operating as intended or as desired. In such an example, the device l 05-a may continue operating as prescribed without performing a security action.
  • FIG. 5 is a flow diagram illustrating one embodiment of a method 500 that supports software supply chain hardening via two-factor application integrity certification and monitoring.
  • the method 500 may be implemented by the validation module 145 illustrated in FIGs. 1 or 2.
  • the method 500 may be implemented in conjunction with device 105, computing device 150, server 1 10, network 1 15, database 120, components thereof, or any combination thereof.
  • the method 500 may include receiving, at a device, a request to execute an object installed on the device.
  • the method 500 may include determining whether a manifest of the object is registered with a registration agent installed on the device, the manifest defining one or more aspects of the object.
  • the method 500 may include executing the object on the device upon determining the manifest is registered with the registration agent.
  • the method 500 may include monitoring, via a monitoring agent installed on the device, operational behaviors of the object.
  • the method 500 may include performing a security action upon determining the manifest is unregistered with the registration agent.
  • FIG. 6 is a flow diagram illustrating one embodiment of a method 600 that supports software supply chain hardening via two-factor application integrity certification and monitoring.
  • the method 600 may be implemented by the validation module 145 illustrated in FIGs. 1 or 2.
  • the method 600 may be implemented in conjunction with device 105, computing device 150, server 1 10, network 1 15, database 120, components thereof, or any combination thereof.
  • the method 600 may include receiving, at a device, a request to execute an object installed on the device.
  • the method 600 may include determining whether a manifest of the object is registered with a registration agent installed on the device, the manifest defining one or more aspects of the object.
  • the method 600 may include executing the object on the device upon determining the manifest is registered with the registration agent.
  • the method 600 may include monitoring, via a monitoring agent installed on the device, operational behaviors of the object.
  • the method 600 may include performing a security action upon determining the manifest is unregistered with the registration agent.
  • FIG. 7 is a flow diagram illustrating one embodiment of a method 700 that supports software supply chain hardening via two-factor application integrity certification and monitoring.
  • the method 700 may be implemented by the validation module 145 illustrated in FIGs. 1 or 2.
  • the method 700 may be implemented in conjunction with device 105, computing device 150, server 1 10, network 1 15, database 120, components thereof, or any combination thereof.
  • the method 700 may include receiving, at a device, a request to execute an object installed on the device.
  • the method 700 may include determining whether a manifest of the object is registered with a registration agent installed on the device, the manifest defining one or more aspects of the object.
  • the method 700 may include executing the object on the device upon determining the manifest is registered with the registration agent.
  • the method 700 may include monitoring, via a monitoring agent installed on the device, operational behaviors of the object.
  • the method 700 may include performing a security action upon determining the manifest is unregistered with the registration agent.
  • the method 700 may include querying a server external to the device to determine whether the manifest remains valid.
  • FIG. 8 depicts a block diagram of a computing device 800 suitable for implementing the present systems and methods.
  • the computing device 800 may be an example of device 105 and/or server 1 10 illustrated in FIG. 1.
  • computing device 800 includes a bus 805 which interconnects major subsystems of computing device 800, such as a central processor 810, a system memory 815 (typically RAM, but which may also include ROM, flash RAM, or the like), an input/output controller 820, an external audio device, such as a speaker system 825 via an audio output interface 830, an external device, such as a display screen 835 via display adapter 840, an input device 845 (e.g .
  • a bus 805 which interconnects major subsystems of computing device 800, such as a central processor 810, a system memory 815 (typically RAM, but which may also include ROM, flash RAM, or the like), an input/output controller 820, an external audio device, such as a speaker system 825 via an audio output interface 830,
  • Bus 805 allows data communication between central processor 810 and system memory 815, which may include read-only memory (ROM) or flash memory (neither shown), and random access memory (RAM) (not shown), as previously noted.
  • ROM read-only memory
  • RAM random access memory
  • the RAM is generally the main memory into which the operating system and application programs are loaded.
  • the ROM or flash memory can contain, among other code, the Basic Input-Output system (BIOS) which controls basic hardware operation such as the interaction with peripheral components or devices.
  • BIOS Basic Input-Output system
  • the validation module l45-b to implement the present systems and methods may be stored within the system memory 815.
  • Applications e.g ., object 140 resident with computing device 800 are generally stored on and accessed via a non-transitory computer readable medium, such as a hard disk drive (e.g., fixed disk drive 875) or other storage medium. Additionally, applications can be in the form of electronic signals modulated in accordance with the application and data communication technology when accessed via network interface 885.
  • Storage interface 880 can connect to a standard computer readable medium for storage and/or retrieval of information, such as a fixed disk drive 875.
  • Fixed disk drive 875 may be a part of computing device 800 or may be separate and accessed through other interface systems.
  • Network interface 885 may provide a direct connection to a remote server via a direct network link to the Internet via a POP (point of presence).
  • Network interface 885 may provide such connection using wireless techniques, including digital cellular telephone connection, Cellular Digital Packet Data (CDPD) connection, digital satellite data connection, or the like.
  • one or more sensors e.g., motion sensor, smoke sensor, glass break sensor, door sensor, window sensor, carbon monoxide sensor, and the like) connect to computing device 800 wirelessly via network interface 885.
  • the operating system provided on computing device 800 may be iOS ® , ANDROID ® , MS-DOS ® , MS-WINDOWS ® , OS/2 ® , UNIX ® , LINUX ® , or another known operating system.
  • a signal can be directly transmitted from a first block to a second block, or a signal can be modified (e.g., amplified, attenuated, delayed, latched, buffered, inverted, filtered, or otherwise modified) between the blocks.
  • a signal can be directly transmitted from a first block to a second block, or a signal can be modified (e.g., amplified, attenuated, delayed, latched, buffered, inverted, filtered, or otherwise modified) between the blocks.
  • modified signals e.g., amplified, attenuated, delayed, latched, buffered, inverted, filtered, or otherwise modified
  • a signal input at a second block can be conceptualized as a second signal derived from a first signal output from a first block due to physical limitations of the circuitry involved (e.g., there will inevitably be some attenuation and delay). Therefore, as used herein, a second signal derived from a first signal includes the first signal or any modifications to the first signal, whether due to circuit limitations or due to passage through other circuit elements which do not change the informational and/or final functional aspect of the first signal.
  • the signals associated with computing device 800 may include wireless communication signals such as radio frequency, electromagnetics, local area network (LAN), wide area network (WAN), virtual private network (VPN), wireless network (using 802.1 1 , for example), cellular network (using 3G and/or LTE, for example), and/or other signals.
  • the network interface 885 may enable one or more of WWAN (GSM, CDMA, and WCDMA), WLAN (including BLUETOOTH® and Wi-Fi), WMAN (WiMAX) for mobile communications, antennas for Wireless Personal Area Network (WPAN) applications (including RFID and UWB), etc.
  • the I/O controller 820 may operate in conjunction with network interface 885 and/or storage interface 880.
  • the network interface 885 may enable computing device 800 with the ability to communicate with client devices (e.g., device 105 of FIG. 1), and/or other devices over the network 1 15 of FIG. 1.
  • Network interface 885 may provide wired and/or wireless network connections.
  • network interface 885 may include an Ethernet adapter or Fibre Channel adapter.
  • Storage interface 880 may enable computing device 800 to access one or more data storage devices.
  • the one or more data storage devices may include two or more data tiers each.
  • the storage interface 880 may include one or more of an Ethernet adapter, a Fibre Channel adapter, Fibre Channel Protocol (FCP) adapter, a SCSI adapter, and iSCSI protocol adapter.
  • FCP Fibre Channel Protocol
  • the terms“a” or“an,” as used in the specification and claims, are to be construed as meaning“at least one of.”
  • the words “including” and “having,” as used in the specification and claims are interchangeable with and have the same meaning as the word“comprising.”
  • the term“based on” as used in the specification and the claims is to be construed as meaning“based at least upon.”
  • the term“security action” may refer to any number of actions the systems described herein may take after determining that a file likely includes some type of malware.
  • types of security actions may include preventing the file from performing any actions on the computing device, alerting an administrator to the potential maliciousness of the file, quarantine the file, delete the file, block a download of the file, and/or warn a user about the file.
  • the systems described herein may perform a security action on objects other than a file. For example, the systems described herein may blacklist malicious URLs and/or IP addresses.
  • the security actions in conjunction with the methods and systems described herein may improve the security and operating integrity of one or more computing devices by protecting the hardware, firmware, software, or any combination thereof of the one or more computing devices from malicious attack. It should be appreciated that these are not exhaustive lists of the types of security actions which may be performed by the systems described herein. Other security actions are also included in this disclosure.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Virology (AREA)
  • Computer And Data Communications (AREA)

Abstract

A method for validating operational behaviors of objects associated with a supply chain is described. In one embodiment, the method may include receiving, at a device, a request to execute an object installed on the device, determining whether a manifest of the object is registered with a registration agent installed on the device, the manifest defining one or more aspects of the object, upon determining the manifest is registered with the registration agent, executing the object on the device, monitoring, via a monitoring agent installed on the device, operational behaviors of the object, and upon determining the manifest is unregistered with the registration agent, performing a security action.

Description

SOFTWARE SUPPLY CHAIN HARDENING VIA TWO-FACTOR APPLICATION INTEGRITY CERTIFICATION AND MONITORING
CROSS REFERENCE
[0001] The present Application for Patent claims priority to U.S. Patent Application No. 16/115,096 by Bromwich et al., entitled“SOFTWARE SUPPLY CHAIN HARDENING VIA TWO-FACTOR APPLICATION INTEGRITY CERTIFICATION AND MONITORING,” filed August 28, 2018, assigned to the assignee hereof and which is expressly incorporated by reference in its entirety herein.
BACKGROUND
[0002] The use of computer systems and computer-related technologies continues to increase at a rapid pace. The expansive use of computer systems has influenced the advances made to computer-related technologies. Computer systems have increasingly become an integral part of the business world and the activities of individual consumers. Computer systems may be used to carry out several business, industry, and academic endeavors.
[0003] The widespread use of computers and mobile devices has caused an increased presence in malicious behavior including data theft, embedding malware and viruses, and the like. In some cases, computer supply chains may be susceptible to malicious attacks that result in software being compromised. The compromised software may be passed down the chain to individual and/or corporate customers, which may result in widespread errors.
SUMMARY
[0004] According to at least one embodiment, a method for validating operational behaviors of objects associated with a supply chain is described. In some cases, at least a portion of the method may be performed by one or more computing devices that include at least one processor. In one embodiment, the method may include receiving, at a device, a request to execute an object installed on the device, determining whether a manifest defining one or more aspects of the object is registered with a registration agent installed on the device, executing the object on the device upon determining the manifest is registered with the registration agent, monitoring, via a monitoring agent installed on the device, operational behaviors of the object, and performing a security action upon determining the manifest is unregistered with the registration agent.
[0005] In some examples, the one or more security actions include at least one of preventing the object from executing, disabling access to at least a portion of the object, disabling one or more processes associated with the object, scanning the object for malware, quarantining the object, deleting the object from the device, generating a notification indicating the object may be compromised, revoking at least one user’s access to the object, or any combination thereof. In some examples, the method may include identifying an operation of the object based at least in part on the monitoring and performing at least one of the one or more security actions based at least in part on determining that the identified operation is not specified by the manifest or that the manifest expressly disallows the identified operation.
[0006] In some examples, the method may include querying a server external to the device to determine whether the manifest remains valid. In some examples, the method may include performing at least one of the one or more security actions upon determining a response from the server indicates the manifest is no longer valid and continuing to allow the object to execute and to monitor the object upon determining the response from the server indicates the manifest remains valid. In some examples, at least a portion of the content of the manifest is based at least in part on one or more behaviors of the object identified during execution time.
[0007] In some examples, determining that the manifest is registered with the registration agent is based at least in part on determining that the manifest indicates the object is to be monitored. In some examples, determining that the manifest is registered with the registration agent includes determining that a hash included in the manifest is registered with the registration agent. In some examples, the one or more aspects of the object include at least one of operational behaviors, one or more files associated with the object, one or more files used by the object, one or more files the object is permitted to access, one or more processes associated with the object, one or more processes the object is allowed to initiate, one or more internet protocol (IP) addresses that the object may access, one or more network locations that the object may access, one or more cryptographic hashes associated with the object, one or more digital signatures of the object, one or more digital certificates of the object, or any combination thereof.
[0008] In some examples, the monitoring agent and the registration agent operate independently of the object. In some examples, the monitoring agent and the registration agent operate independently of each other or in conjunction with each other. In some examples, the object may include at least one application.
[0009] A computing device for validating operational behaviors of objects associated with a supply chain is described. The computing device may include one or more processors and memory in electronic communication with the one or more processors. The memory may store computer executable instructions that when executed by the one or more processors cause the one or more processors to perform the steps of receiving, at a device, a request to execute an object installed on the device, determining whether a manifest defining one or more aspects of the object is registered with a registration agent installed on the device, executing the object on the device upon determining the manifest is registered with the registration agent, monitoring, via a monitoring agent installed on the device, operational behaviors of the object, and performing a security action upon determining the manifest is unregistered with the registration agent.
[0010] In some examples, the one or more security actions include at least one of preventing the object from executing, disabling access to at least a portion of the object, disabling one or more processes associated with the object, scanning the object for malware, quarantining the object, deleting the object from the device, generating a notification indicating the object may be compromised, revoking at least one user’s access to the object, or any combination thereof. In some examples, the computing device may perform the steps of identifying an operation of the object based at least in part on the monitoring and performing at least one of the one or more security actions based at least in part on determining that the identified operation is not specified by the manifest or that the manifest expressly disallows the identified operation. [0011] In some examples, the computing device may perform the steps of querying a server external to the device to determine whether the manifest remains valid. In some examples, the computing device may perform the steps of performing at least one of the one or more security actions upon determining a response from the server indicates the manifest is no longer valid and continuing to allow the object to execute and to monitor the object upon determining the response from the server indicates the manifest remains valid.
[0012] In some examples, at least a portion of the content of the manifest is based at least in part on one or more behaviors of the object identified during execution time. In some examples, determining that the manifest is registered with the registration agent is based at least in part on determining that the manifest indicates the object is to be monitored. In some examples, determining that the manifest is registered with the registration agent includes determining that a hash included in the manifest is registered with the registration agent.
[0013] A computer-program product for validating operational behaviors of objects associated with a supply chain is described. The computer-program product may include a non-transitory computer-readable medium storing instructions thereon. When the instructions are executed by one or more processors, the execution of the instructions may cause the one or more processors to perform the steps of receiving, at a device, a request to execute an object installed on the device, determining whether a manifest defining one or more aspects of the object is registered with a registration agent installed on the device, executing the object on the device upon determining the manifest is registered with the registration agent, monitoring, via a monitoring agent installed on the device, operational behaviors of the object, and performing a security action upon determining the manifest is unregistered with the registration agent.
[0014] Features from any of the above-mentioned embodiments may be used in combination with one another in accordance with the general principles described herein. These and other embodiments, features, and advantages will be more fully understood upon reading the following detailed description in conjunction with the accompanying drawings and claims. BRIEF DESCRIPTION OF THE DRAWINGS
[0015] The accompanying drawings illustrate a number of exemplary embodiments and are a part of the specification. Together with the following description, these drawings demonstrate and explain various principles of the instant disclosure.
[0016] FIG. 1 is a block diagram illustrating one embodiment of an environment in which the present systems and methods may be implemented;
[0017] FIG. 2 is a block diagram illustrating one example of a validation module;
[0018] FIG. 3 is a block diagram illustrating one example of a manifest module;
[0019] FIG. 4 is a swim diagram illustrating one embodiment of a method in accordance with various aspects of this disclosure;
[0020] FIG. 5 is a flow diagram illustrating one embodiment of a method in accordance with various aspects of this disclosure;
[0021] FIG. 6 is a flow diagram illustrating one embodiment of a method in accordance with various aspects of this disclosure; and
[0022] FIG. 7 is a flow diagram illustrating one embodiment of a method in accordance with various aspects of this disclosure; and
[0023] FIG.8 depicts a block diagram of a computer system suitable for implementing the present systems and methods.
[0024] While the embodiments described herein are susceptible to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and will be described in detail herein. However, the exemplary embodiments described herein are not intended to be limited to the particular forms disclosed. Rather, the instant disclosure covers all modifications, equivalents, and alternatives falling within the scope of the appended claims.
DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS
[0025] The systems and methods described herein relate to supply chain management. More specifically, the systems and methods described herein relate to validating operational behaviors of objects associated with a supply chain. [0026] Independent software vendors (IS Vs) and other software publishers and software vendors (e.g., mobile application stores, etc.) may be susceptible to supply chain attacks by having potentially unwanted or compromised software installed in machine images. The compromised software may eventually make its way to both individual and corporate customers. Additionally, vendors may be currently unable to vouch for the behaviors their preinstalled software will have in the field once deployed. Thus, a manifest may be assigned to an application that prescribes how the application is intended to work in a respective field. In some cases, the manifest may be manually generated by an administrator, etc. In some examples, the manifest may be generated by monitoring the behaviors of a software application during execution time, recording the operational behaviors of the software application (e.g., processes initiated, files accessed, internet protocol (IP) addresses accessed, network locations accessed, etc.), and generating the manifest based at least in part on the observed operational behaviors of the software application during execution time.
[0027] In some examples, an external component (e.g., software or hardware) may be installed alongside the“signed” executable that monitors the behavior of the application and blocks any non-intended behaviors. In some examples, a service that allows the manufacturer of the application to register with the monitor that an application is intended to be monitored may be described. This may be accomplished by registering the particular application with the external monitor using a hash. In some examples, the manifest’s hash may also be registered with the registrar.
[0028] In some examples, the method may include a sub component of the external monitor that prevents the execution of any registered application that does not exhibit the manifest that was registered. In some examples, a subsystem may perform a cloud lookup on whether a manifest is still valid. Accordingly, the present techniques may provide for the revocation of a particular manifest upon determining the manifest is compromised in one way or another.
[0029] The aforementioned techniques may allow suppliers to partner with vendors to secure their supply chain. Additionally, the provided techniques provide vendors and end users (and enterprises) that the software shipped behaves as the vendor expects it should. In some cases, certificates may provide a confidence on who wrote/shipped the software. The present techniques add a layer of protection that the certified software would be limited to exhibiting certain behaviors as prescribed by the vendor. Extensions of the present techniques could involve telemetry for both well behaved and poorly behaved applications with notifications to the end user as well as the vendor. Furthermore, integrations could be made beyond verifying the supply chain integrity. Web site hosts could potentially deploy distributed computations applications with the consent of the user if the user had the confidence that the deployed module conformed to the advertised behaviors.
[0030] FIG. 1 is a block diagram illustrating one embodiment of an environment 100 in which the present systems and methods may be implemented. In some embodiments, the systems and methods described herein may be performed via device ( e.g device 105). As depicted, the environment 100 may include a device 105, a computing device 150, server 1 10, and a network 1 15 that allows the device 105, the computing device 150, the server 1 10, and the database 120 to communicate with one another. In other examples, the environment 100 may include a remote device (e.g., a remote computing device; not shown) in communication with one or more of device 105 and computing device 150.
[0031] Examples of the device 105 may include any combination of mobile devices, smart phones, personal computing devices, computers, laptops, desktops, servers, media content set top boxes, WiFi routers, Internet of Things (IoT) devices (e.g., a thermostat, home appliance, etc.) or any combination thereof. In some cases, device 105 may include a validation module 145 integrated within device 105, or may be in communication with a device configuration module via network 1 15. In some examples, device 105 may be in communication with a remote device (e.g., a remote computing device; not shown).
[0032] Examples of computing device 150 may include at least one of one or more client machines, one or more mobile computing devices, one or more laptops, one or more desktops, one or more servers, one or more media set top boxes, or any combination thereof. Examples of server 1 10 may include any combination of a data server, a cloud server, proxy server, mail server, web server, application server, database server, communications server, file server, home server, mobile server, name server, or any combination thereof. Although computing device 150 is depicted as connecting to device 105 via network 1 15, in one embodiment, device 105 may connect directly to computing device 150. In some cases, device 105 may connect or attach to computing device 150 and/or server 1 10 via a wired and/or wireless connection. In some cases, device 105 may attach to any combination of a port, socket, and slot of computing device 150 and/or server 1 10.
[0033] Examples of server 1 10 may include any combination of a data server, a cloud server, proxy server, mail server, web server, application server, database server, communications server, file server, home server, mobile server, name server, or any combination thereof. In some examples, a remote computing device may connect to device 105 and/or computing device 150 via network 1 15. In other examples, a remote computing device may connect directly to device 105 and/or computing device 150. In some cases, device 105 and/or computing device 150 may connect or attach to a remote computing device and/or server 1 10 via a wired and/or wireless connection. In some cases, device 105 may attach to any combination of a port, socket, and slot of computing device 150 and/or server 1 10. In other examples, device 105 may connect and/or communicate with computing device 150 via network 1 15.
[0034] In some configurations, the device 105 may include a user interface 135, object 140, and validation module 145. Although the components of the device 105 are depicted as being internal to the device 105, it is understood that one or more of the components may be external to the device 105 and connect to device 105 through wired and/or wireless connections. In some embodiments, object 140 may be installed on one or more computing devices (e.g., device 105, computing device 150, server 1 10, etc.). In some cases, object 140 may include a user interface that enables a user to interface with a function of device 105, validation module 145, computing device 150, and/or server 1 10. In some examples, object 140 may include a software application, one or more files, and/or a component or sub-component related to a software application. For example, object 140 may include a mobile software application downloaded over a data network (e.g., from server 1 10 via network 1 15) and installed on device 105.
[0035] In some embodiments, device 105 may communicate with server 1 10 and/or computing device 150 via network 1 15. Examples of network 1 15 may include any combination of cloud networks, local area networks (LAN), wide area networks (WAN), virtual private networks (VPN), wireless networks (using 802.1 1 , for example), cellular networks (using 3G and/or LTE, for example), etc. In some configurations, the network 1 15 may include the Internet. Examples of computing device 150 may include a network switch, wired and/or wireless router, firewall, intrusion detection system, ethernet hub, network bridge, bridge router, modem (e.g., cable modem), protocol converter, network repeater, network gateway, network card, network adapter, proxy server, wireless access point, fiber media converter, network address translator, network server, a personal or mobile computing device (e.g., a computing device with a hotspot connection enabled), or any combination thereof. It is noted that in some embodiments, the device 105 may not include validation module 145. For example, device 105 may include object 140 that allows device 105 to interface with a separate device or module via validation module 145 located on another device such as a remote computing device (not shown) and/or server 1 10.
[0036] In some embodiments, device 105, computing device 150, and server 1 10 may include validation module 145 where at least a portion of the functions of validation module 145 are performed separately and/or concurrently on device 105, computing device 150, and/or server 1 10. Likewise, in some embodiments, a user may access the functions of computing device 150 from device 105 (e.g. , directly or through device 105 via validation module 145). For example, in some embodiments, a device 105 may include a mobile application that interfaces with one or more functions of computing device 150, validation module 145, and/or server 1 10.
[0037] In some embodiments, server 1 10 may be coupled to database 120. Database 120 may be internal or external to the server 1 10. In one example, device 105 and/or computing device 150 may be coupled to database 120. For example, in one embodiment database 120 may be internally or externally connected directly to device 105 and/or computing device 150. Additionally or alternatively, database 120 may be internally or externally connected directly to computing device 150 and/or one or more network devices such as a gateway, switch, router, intrusion detection system, etc. Database 120 may include manifest settings 165. In some examples, a manifest may be stored on device 105 in conjunction with an installation of a software application on device 105.
[0038] In some examples, a manifest may be or may refer to a file that contains settings that informs an operating system how to handle an application when it is started. The manifest may be embedded inside the program file (e.g., as a resource) or it may be located in a separate external file (e.g., an Extensible Markup Language (XML) file). If the manifest is placed in a separate file, then the file may be located in the same folder as the executable file and it may have a same filename as the program file, but with a different filename extension added at the end.
[0039] In some examples, manifests may be used with library files (e.g., DLL files) or executable files (e.g., .exe files). Manifests that are used with programs are may be referred to as application manifests and manifests that are used with DLL files and other library files may be referred to as assembly manifests. The settings in a manifest may be specified by using the XML language. In some examples, a manifest may include information relating to whether a particular application requires administrator privileges or if standard user privileges are enough.
[0040] As one example, device 105 may download a software application over network 1 15 via server 1 10. In some examples, the software application may include a manifest. In one example, device 105, in conjunction with validation module 145, may install a software application that includes a manifest. The manifest may include metadata for a group of accompanying files that are part of a set or coherent unit of a software application. Lor example, the files of object 140 may be associated with the installed software application. In some cases, the manifest may describe at least one of the name, unique ID, version number, license, and one or more files of the object 140, or any combination thereof. Although depicted as connecting to computing device 150 through network 1 15, computing device 150 may connect directly to device 105 between device 105 and network 1 15. Additionally or alternatively, computing device 150 may connect directly to server 1 10 between server 1 10 and network 1 15.
[0041] In some examples, validation module 145 may validate operational behaviors of object 140 based on information included in the manifest. In some embodiments, validation module 145 may be configured to perform the systems and methods described herein in conjunction with object 140 and/or manifest settings 165. Manifest settings 165 may contain information (e.g., files) relating to a manner in which a software application associated with the manifest is intended to operate (e.g., object 140 installed on device 105). In some examples, if object 140 is operating in a manner in which it is not intended to operate, validation module 145 may perform one or more security actions to prohibit the operation of object 140. Further details regarding the validation module 145 are discussed below.
[0042] FIG. 2 is a block diagram illustrating one example of validation module l45-a. Validation module l45-a may be one example of validation module 145 depicted in FIG. 1. As depicted, validation module l 45-a may include a manifest module 210, an object execution module 215, an monitor module 220, and a security action module 225.
[0043] The validation module l45-a may validate one or more operational behaviors of an object (e.g., object 140 as described with reference to FIG. 1 ) associated with a supply chain. Each of manifest module 210, object execution module 215, monitor module 220, and security action module 225 may facilitate validating the operational behaviors of the object. For example, in a supply chain (e.g., a software distribution service configured to distribute software applications over a data network), various individual and/or corporate customers may provide various applications managed by a common vendor. In order for the applications to behave as intended by the vendor, the validation module l45-a may validate one or more operational behaviors of a particular application to ensure that the application runs as intended when downloaded and installed on a user device (e.g., device 105). In some examples, object execution module 215 may receive a request to execute an object (e.g., object 140 as described with reference to FIG. 1) installed on the device (e.g., device 105 as described with reference to FIG. 1 ), manifest module 210 may determine whether a manifest of the object is registered with a registration agent installed on the device, object execution module 215 may execute the object on the device, monitor module 220 may monitor one or more operational behaviors of the object, and security action module 225 may perform one or more security actions on the device.
[0044] In some examples, object execution module 215 may receive a request to execute an object installed on the device. As described above, the object may be or may include a file, an application, or a component or sub-component related to an application. In some examples, one or more aspects of the object may include at least one of operational behaviors, one or more files associated with the object, one or more files used by the object, one or more files the object is permitted to access, one or more processes associated with the object, one or more processes the object is allowed to initiate, one or more internet protocol (IP) addresses that the object may access, one or more network locations that the object may access, one or more cryptographic hashes associated with the object, one or more digital signatures of the object, one or more digital certificates of the object, or any combination thereof. Accordingly, the object may relate to operational aspects of one or more components and/or files associated with a device (e.g., device 105 as described with reference to FIG. 1 ). Executing the object may thus cause the object (e.g. , the application) to begin running on the device.
[0045] In some examples, the manifest module 210 may determine whether a manifest of the object is registered with a registration agent installed on the device. As described above, the manifest may define one or more aspects of the object. For example, the manifest may define the manner in which the object is intended to run. The manifest may define one or more parameters (e.g., operating characteristics) that the object, when executed, should operate within. By registering the manifest with the registration agent, the validation module l45-a may communicate with a database (e.g. , database 120 as described with reference to FIG. 1 ) to determine whether the object is operating properly. In one example, the validation module l 45-a (e.g., via the registration agent) may communicate with a database to determine whether the object is operating according to the manifest settings (e.g., manifest settings 165 as described with reference to FIG. 1) stored at the database. For example, one or more aspects of the object may include a particular IP address to which the object may access. Accordingly, registering the manifest with the registration agent may indicate to the device which IP address (or IP addresses) the object may access (or is intended to access).
[0046] In some examples, the object execution module 215 may execute the object on the device based on determining that the manifest is registered with the registration agent. As described above, executing the object may result in the object running on the device. In some cases, registering the manifest with the registration agent may result in the validation module l45-a determining whether an object (e.g., object 140, a software application executing on device 105, etc.) is operating according to one or more predetermined parameters (e.g., running according to manifest settings 165 as described with reference to FIG. 1 ). In some cases, registering the manifest may occur before executing the object. In one example, one or more aspects of the operational aspects of the object may include a particular IP address to which the object may access and registering the manifest with the registration agent may indicate to the device which IP address the object may access.
[0047] In some examples, the monitor module 220 may monitor the operational behaviors of the object installed on the device. In some examples, the monitor module may monitor the operational behaviors of the object via a monitoring agent. As described above, the operational behaviors of the object may be or may be associated with one or more desired or expected operational characteristics. In some examples, the expected operational characteristics may be described by an Internet Service Provider (ISP). For example, the expected operational characteristics may be made available to the general public via a public mechanism (e.g., via a publicly available ledger, etc.) to ensure transparency of the expected operational characteristics. In some examples, the monitor module 220 may monitor which IP address(es) the object accesses. Thus, the monitor module 220 may monitor the object and determine, in conjunction with analysis of the registered manifest, whether the actual operational characteristics of the object are operating outside of the desired or expected operational characteristics. If the operational characteristics are operating outside of the desired or expected characteristics, the validation module l45-a may perform one or more security actions to ensure the object ceases to operate in such an undesired manner. For example, if the object accesses one or more unintended IP addresses, a security action may be performed (e.g., preventing the object from accessing any additional IP addresses until the issue is resolved).
[0048] In some examples, the security action module 225 may perform one or more security actions based on determining that the manifest is unregistered with the registration agent. For example, the security action may be or may include preventing the object from executing, disabling access to at least a portion of the object, disabling one or more processes associated with the object, scanning the object for malware, quarantining the object, deleting the object from the device, generating a notification indicating the object may be compromised, revoking at least one user’s access to the object. As described above, a security action may be performed to prevent the object from accessing any additional IP addresses if the object accesses one or more unintended IP addresses. Thus, the security action module 225 may be responsible for revoking privileges of the object if the object operates in an unintended or unexpected manner.
[0049] FIG. 3 is a block diagram illustrating one example of a manifest module 2l 0-a. Manifest module 2l 0-a may be one example of manifest module 210 as depicted in FIG. 2. As depicted, manifest module 2l 0-a may include an identification module 305, a determination module 310, a registration module 315, and an external querying module 320.
[0050] In some examples, the action(s) performed by the manifest module 210 described above with reference to FIG. 2 may determine whether a manifest of the object is registered with a registration agent installed on the device (e.g., device 105 as described with reference to FIG. 1 ). Accordingly, the identification module 305 may identify an operation of an object associated with a device (e.g., a software application installed on device 105 as described with reference to FIG. 1 ), the determination module 310 may determine whether a manifest of the object is registered with a registration agent installed on the device, the registration module 315 may register the manifest of the object, and the external querying module 320 may query a database to ensure that the object is operating as prescribed. In some cases, registration module 315 may include one or more registration agents and/or be referred to as a registration agent. In some cases, manifest module 2l 0-a may facilitate the validation process as described above with reference to FIG. 2. For example, manifest module 2l 0-a may determine whether one or more operations of an object installed on a device (e.g., object 140 installed on device 105 as described with reference to FIG. 1) are valid, or whether one or more operations of an object installed on a device remain valid (e.g., after a predetermined time period).
[0051] In some examples, the identification module 305 may identify an operation of an object (e.g., object 140). As described above, the object may be or may include a file, an application, or a component or sub-component related to an application. Accordingly, an operation of the object may be or may be related to particular operational behaviors including file access, processes the object is allowed to initiate, IP addresses that the object may access, network locations that the object may access, and the like. In some examples, the manifest stored at the device may depend on the type of operation of the object identified by the identification module 305.
[0052] In some examples, the determination module 310 may determine whether the manifest of the object is registered with a registration agent of the device. More specifically, in some examples the determination module 310 may determine whether the identified operation of the object is registered with the registration agent. As described above, the purpose of the registering the object may be to determine whether the object is operating properly. In one example, registration agent may communicate to the validation module 145 -a whether the object is operating according to the manifest settings (e.g. , manifest settings 165 as described with reference to FIG. 1) stored at the database. For example, if the manifest is associated with a particular IP address that the object is intended and/or allowed to access, then the validation module l45-a may determine whether the actual IP address that the object is accessing is the intended and/or allowed IP address. Thus, the identified operation may be registered with the registration agent validate the operational behaviors of the object. Accordingly, if the identified operation is not registered with the registration agent then registration module 315 may register the identified operation.
[0053] In some examples, the registration module 315 may register a manifest. In some cases, the manifest may specify one or more allowed operations of a software application and/or may specify one or more operations not allowed by the software application. As described above, the registration module 315 may communicate to the validation module l45-a whether an object (e.g., object 140) is operating according to the manifest settings (e.g., a manifest stored on device 105 and/or manifest settings 165, etc.). Accordingly, by registering the manifest, one or more modules may compare the actual behavior a software application to the identified operation of the manifest registered by and/or with the registration module 315.
[0054] In some examples, the external querying module 320 may query an external device (e.g., database 120 as described with reference to FIG. 1 ) to determine whether the manifest remains valid. In some examples, a manifest (e.g., one or more aspects of a manifest) may be updated due to software updates, security updates, and the like. Accordingly, when such an update occurs, one or more aspects of the manifest may become outdated. Accordingly, to prevent an unwanted or unnecessary security action from being performed, the external querying module 320 may query the external device to determine if the manifest remains valid. In some examples, if the manifest is invalid (e.g., due to an update as described above), the manifest may be retransmitted to the device. By retransmitting the manifest to the device, the manifest may be validated (e.g., via validation module l 45-a as described with reference to FIG. 1) without a security action being performed. In some examples, a security action (e.g., preventing an object from accessing a particular IP address) may be performed based on a manifest being invalid, and the security action may cease (e.g. , allow the object to begin accessing a particular IP address) based on the manifest being retransmitted to the device. In some examples, validating operational behaviors (e.g., as conducted by validation module 145- a) may be conducted by an individual with access to the manifest.
[0055] FIG. 4 is a swim diagram illustrating one embodiment of a method 400 that supports validating operational behaviors of objects associated with a supply chain. In some configurations, the method 400 may be implemented by a device l 05-a, computing device l 50-a, and/or database l20-a. In some examples, device l 05-a may be an example of device 105 as described with respect to FIG. 1 , computing device l 50-a may be an example of computing device 150 as described with respect to FIG. 1 ; and database l20-a may be an example of database 120 as described with respect to FIG. 1. In some configurations, the method 400 may be implemented in conjunction with server 1 10, network 1 15, components thereof, or any combination thereof.
[0056] In some examples, device l 05-a may be referred to as a user device and may be associated with a user seeking to validate operational behaviors of one or more objects associated with a supply chain. At block 405, a manifest may be installed at device l 05-a. As described above, a manifest may be or may include information relating to an object. More specifically, in some examples, the manifest may include information about one or more IP addresses that the object is intended and/or allowed to access. In some examples, the manifest may be installed at device l 05-a by and/or in conjunction with a validation module (e.g., validation module 145). For example, the manifest may be stored at the database l 20-a and may be bundled with a software application that is transmitted to, and subsequently installed on, device l 05-a in conjunction with one or more modules (e.g., validation module 145).
[0057] At 410, the device 105 -a may receive a request to execute an object installed on the device l 05-a. In some examples, the request may be received from network device l 07-a and in other examples the request may be received from database l20-a. In one example, at step 415, network device l 07-a (or database l20-a) may transmit the request to the device l 05-a. As described above, the object may be or may be associated with a particular IP address. Thus by receiving the request, device l 05-a may execute the object which may allow the device to access the prescribed IP address.
[0058] At step 420, the device l 05-a may optionally identify an operation associated with the object. For example, the device 105 -a may identify the IP address that the object may access. At 425, the device l 05-a may determine whether the manifest is registered with a registration agent of the device l 05-a. By registering the manifest with the registration agent, the validation module (e.g., validation module l 45-a as described with reference to FIG. 2) may communicate with a database (e.g., database 120 as described with reference to FIG. 1 ) to determine whether the object is operating properly. In some examples, the validation module (e.g., via the registration agent) may communicate with the manifest registration 430 of database l20-a to determine whether the object is operating according to the manifest settings (e.g., manifest settings 165 as described with reference to FIG. 1 ) stored at the database l 20-a. In some examples, the manifest may include a cryptographic hash. Accordingly, the hash may be registered with the registration agent and stored at the database l20-a, and the registration may be verified by comparing the hash registered with the registration agent to the hash stored at the database l 20-a.
[0059] At 435, the device l 05-a may execute the object based on determining that the manifest is registered with the registration agent. As described above, executing the object may result in the object running on the device. Because registering the manifest with the registration agent may result in the validation module determining whether the object is operating according to one or more predetermined parameters (e.g., running according to manifest settings 165 as described with reference to FIG. 1), registering the manifest is a prerequisite to executing the object.
[0060] At 440, operational behaviors of the manifest may be optionally monitored. As described above, the operational behaviors of the manifest may be associated with one or more desired or expected operational characteristics of the object. For example, the device 105 -a may determine whether the operational characteristics are operating as expected by comparing the actual operational characteristics (e.g., of the object) to a listing of expected operational characteristics (e.g., manifest settings 445 stored at database l20-a). Thus monitoring the operational characteristics may allow for a determination to be made whether the operational characteristics are operating outside of the desired or expected operational characteristics. If the operational characteristics are operating outside of the desired or expected characteristics, the validation module (e.g., the validation module l45-a as described with reference to FIG. 1) may perform one or more security actions to ensure the object ceases to operate in such an undesired manner.
[0061] At 450, a security action may be performed by the device l 05-a. In some examples, the security action module (e.g., security action module 225 as described with reference to FIG. 2) may perform one or more security actions based on determining that the manifest is unregistered with the registration agent. For example, the security action may be or may include preventing the object from executing, disabling access to at least a portion of the object, disabling one or more processes associated with the object, scanning the object for malware, quarantining the object, deleting the object from the device, generating a notification indicating the object may be compromised, revoking at least one user’s access to the object. In some examples, a security action may be performed when the object of the device l 05-a is operating unexpectedly or in an unintended manner. Thus, by performing a security action, the device l 05-a may halt any unexpected or unintended behavior of the previously-executed object.
[0062] At 445, the device l 05-a may optionally transmit a query (e.g. , to database l 20-a) to determine whether the manifest remains valid. In one example, a manifest may be updated due to one of many happenings. For example, a manifest may be updated as part of a routine software or security update. Accordingly, the device 105- a may transmit a query to the database l20-a, and may subsequently receive a response (not shown) that contains information related to the operational characteristics of the manifest. In some examples, if the received information from the database l20-a indicates that the manifest is not operating as intended or as desired, the device l 05-a may optionally perform a security action at 460. In other examples, the device l 05-a may receive information from the database l 20-a indicating that the object is operating as intended or as desired. In such an example, the device l 05-a may continue operating as prescribed without performing a security action.
[0063] FIG. 5 is a flow diagram illustrating one embodiment of a method 500 that supports software supply chain hardening via two-factor application integrity certification and monitoring. In some configurations, the method 500 may be implemented by the validation module 145 illustrated in FIGs. 1 or 2. In some configurations, the method 500 may be implemented in conjunction with device 105, computing device 150, server 1 10, network 1 15, database 120, components thereof, or any combination thereof.
[0064] At block 505, the method 500 may include receiving, at a device, a request to execute an object installed on the device. At block 510, the method 500 may include determining whether a manifest of the object is registered with a registration agent installed on the device, the manifest defining one or more aspects of the object.
[0065] At block 515, the method 500 may include executing the object on the device upon determining the manifest is registered with the registration agent. At block 520, the method 500 may include monitoring, via a monitoring agent installed on the device, operational behaviors of the object. At block 525, the method 500 may include performing a security action upon determining the manifest is unregistered with the registration agent.
[0066] FIG. 6 is a flow diagram illustrating one embodiment of a method 600 that supports software supply chain hardening via two-factor application integrity certification and monitoring. In some configurations, the method 600 may be implemented by the validation module 145 illustrated in FIGs. 1 or 2. In some configurations, the method 600 may be implemented in conjunction with device 105, computing device 150, server 1 10, network 1 15, database 120, components thereof, or any combination thereof.
[0067] At block 605, the method 600 may include receiving, at a device, a request to execute an object installed on the device. At block 610, the method 600 may include determining whether a manifest of the object is registered with a registration agent installed on the device, the manifest defining one or more aspects of the object.
[0068] At block 615, the method 600 may include executing the object on the device upon determining the manifest is registered with the registration agent. At block 620, the method 600 may include monitoring, via a monitoring agent installed on the device, operational behaviors of the object. At block 625, the method 600 may include performing a security action upon determining the manifest is unregistered with the registration agent.
[0069] At block 630, the method 600 may include identifying an operation of the object based at least in part on the monitoring. At block 635, the method 600 may include performing at least one of the one or more security actions based at least in part on determining that the identified operation is not specified by the manifest or that the manifest expressly disallows the identified operation. [0070] FIG. 7 is a flow diagram illustrating one embodiment of a method 700 that supports software supply chain hardening via two-factor application integrity certification and monitoring. In some configurations, the method 700 may be implemented by the validation module 145 illustrated in FIGs. 1 or 2. In some configurations, the method 700 may be implemented in conjunction with device 105, computing device 150, server 1 10, network 1 15, database 120, components thereof, or any combination thereof.
[0071] At block 705, the method 700 may include receiving, at a device, a request to execute an object installed on the device. At block 710, the method 700 may include determining whether a manifest of the object is registered with a registration agent installed on the device, the manifest defining one or more aspects of the object.
[0072] At block 715, the method 700 may include executing the object on the device upon determining the manifest is registered with the registration agent. At block 720, the method 700 may include monitoring, via a monitoring agent installed on the device, operational behaviors of the object. At block 725, the method 700 may include performing a security action upon determining the manifest is unregistered with the registration agent. At block 730, the method 700 may include querying a server external to the device to determine whether the manifest remains valid.
[0073] FIG. 8 depicts a block diagram of a computing device 800 suitable for implementing the present systems and methods. The computing device 800 may be an example of device 105 and/or server 1 10 illustrated in FIG. 1. In one configuration, computing device 800 includes a bus 805 which interconnects major subsystems of computing device 800, such as a central processor 810, a system memory 815 (typically RAM, but which may also include ROM, flash RAM, or the like), an input/output controller 820, an external audio device, such as a speaker system 825 via an audio output interface 830, an external device, such as a display screen 835 via display adapter 840, an input device 845 ( e.g . , remote control device interfaced with an input controller 850), multiple USB devices 865 (interfaced with a USB controller 870), and a storage interface 880. Also included are at least one sensor 855 connected to bus 805 through a sensor controller 860 and a network interface 885 (coupled directly to bus 805). [0074] Bus 805 allows data communication between central processor 810 and system memory 815, which may include read-only memory (ROM) or flash memory (neither shown), and random access memory (RAM) (not shown), as previously noted. The RAM is generally the main memory into which the operating system and application programs are loaded. The ROM or flash memory can contain, among other code, the Basic Input-Output system (BIOS) which controls basic hardware operation such as the interaction with peripheral components or devices. For example, the validation module l45-b to implement the present systems and methods may be stored within the system memory 815. Applications ( e.g ., object 140) resident with computing device 800 are generally stored on and accessed via a non-transitory computer readable medium, such as a hard disk drive (e.g., fixed disk drive 875) or other storage medium. Additionally, applications can be in the form of electronic signals modulated in accordance with the application and data communication technology when accessed via network interface 885.
[0075] Storage interface 880, as with the other storage interfaces of computing device 800, can connect to a standard computer readable medium for storage and/or retrieval of information, such as a fixed disk drive 875. Fixed disk drive 875 may be a part of computing device 800 or may be separate and accessed through other interface systems. Network interface 885 may provide a direct connection to a remote server via a direct network link to the Internet via a POP (point of presence). Network interface 885 may provide such connection using wireless techniques, including digital cellular telephone connection, Cellular Digital Packet Data (CDPD) connection, digital satellite data connection, or the like. In some embodiments, one or more sensors (e.g., motion sensor, smoke sensor, glass break sensor, door sensor, window sensor, carbon monoxide sensor, and the like) connect to computing device 800 wirelessly via network interface 885.
[0076] Many other devices and/or subsystems may be connected in a similar manner (e.g., entertainment system, computing device, remote cameras, wireless key fob, wall mounted user interface device, cell radio module, battery, alarm siren, door lock, lighting system, thermostat, home appliance monitor, utility equipment monitor, and so on). Conversely, all of the devices shown in FIG. 8 need not be present to practice the present systems and methods. The devices and subsystems can be interconnected in different ways from that shown in FIG. 8. The aspect of some operations of a system such as that shown in FIG. 8 are readily known in the art and are not discussed in detail in this application. Code to implement the present disclosure can be stored in a non-transitory computer-readable medium such as one or more of system memory 815 or fixed disk drive 875. The operating system provided on computing device 800 may be iOS®, ANDROID®, MS-DOS®, MS-WINDOWS®, OS/2®, UNIX®, LINUX®, or another known operating system.
[0077] Moreover, regarding the signals described herein, those skilled in the art will recognize that a signal can be directly transmitted from a first block to a second block, or a signal can be modified (e.g., amplified, attenuated, delayed, latched, buffered, inverted, filtered, or otherwise modified) between the blocks. Although the signals of the above described embodiment are characterized as transmitted from one block to the next, other embodiments of the present systems and methods may include modified signals in place of such directly transmitted signals as long as the informational and/or functional aspect of the signal is transmitted between blocks. To some extent, a signal input at a second block can be conceptualized as a second signal derived from a first signal output from a first block due to physical limitations of the circuitry involved (e.g., there will inevitably be some attenuation and delay). Therefore, as used herein, a second signal derived from a first signal includes the first signal or any modifications to the first signal, whether due to circuit limitations or due to passage through other circuit elements which do not change the informational and/or final functional aspect of the first signal.
[0078] The signals associated with computing device 800 may include wireless communication signals such as radio frequency, electromagnetics, local area network (LAN), wide area network (WAN), virtual private network (VPN), wireless network (using 802.1 1 , for example), cellular network (using 3G and/or LTE, for example), and/or other signals. The network interface 885 may enable one or more of WWAN (GSM, CDMA, and WCDMA), WLAN (including BLUETOOTH® and Wi-Fi), WMAN (WiMAX) for mobile communications, antennas for Wireless Personal Area Network (WPAN) applications (including RFID and UWB), etc. [0079] The I/O controller 820 may operate in conjunction with network interface 885 and/or storage interface 880. The network interface 885 may enable computing device 800 with the ability to communicate with client devices (e.g., device 105 of FIG. 1), and/or other devices over the network 1 15 of FIG. 1. Network interface 885 may provide wired and/or wireless network connections. In some cases, network interface 885 may include an Ethernet adapter or Fibre Channel adapter. Storage interface 880 may enable computing device 800 to access one or more data storage devices. The one or more data storage devices may include two or more data tiers each. The storage interface 880 may include one or more of an Ethernet adapter, a Fibre Channel adapter, Fibre Channel Protocol (FCP) adapter, a SCSI adapter, and iSCSI protocol adapter.
[0080] While the foregoing disclosure sets forth various embodiments using specific block diagrams, flowcharts, and examples, each block diagram component, flowchart step, operation, and/or component described and/or illustrated herein may be implemented, individually and/or collectively, using a wide range of hardware, software, or firmware (or any combination thereof) configurations. In addition, any disclosure of components contained within other components should be considered exemplary in nature since many other architectures can be implemented to achieve the same functionality.
[0081] The process parameters and sequence of steps described and/or illustrated herein are given by way of example only and can be varied as desired. For example, while the steps illustrated and/or described herein may be shown or discussed in a particular order, these steps do not necessarily need to be performed in the order illustrated or discussed. The various exemplary methods described and/or illustrated herein may also omit one or more of the steps described or illustrated herein or include additional steps in addition to those disclosed.
[0082] Furthermore, while various embodiments have been described and/or illustrated herein in the context of fully functional computing systems, one or more of these exemplary embodiments may be distributed as a program product in a variety of forms, regardless of the particular type of computer-readable media used to actually carry out the distribution. The embodiments disclosed herein may also be implemented using software modules that perform certain tasks. These software modules may include script, batch, or other executable files that may be stored on a computer-readable storage medium or in a computing system. In some embodiments, these software modules may configure a computing system to perform one or more of the exemplary embodiments disclosed herein.
[0083] The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the present techniques to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described to explain the principles of the present systems and methods and their practical applications, to thereby enable others skilled in the art to best utilize the present systems and methods and various embodiments with various modifications as may be suited to the particular use contemplated.
[0084] Unless otherwise noted, the terms“a” or“an,” as used in the specification and claims, are to be construed as meaning“at least one of.” In addition, for ease of use, the words “including” and “having,” as used in the specification and claims, are interchangeable with and have the same meaning as the word“comprising.” In addition, the term“based on” as used in the specification and the claims is to be construed as meaning“based at least upon.”
[0085] As used herein, the term“security action” may refer to any number of actions the systems described herein may take after determining that a file likely includes some type of malware. For example, types of security actions may include preventing the file from performing any actions on the computing device, alerting an administrator to the potential maliciousness of the file, quarantine the file, delete the file, block a download of the file, and/or warn a user about the file. In addition, the systems described herein may perform a security action on objects other than a file. For example, the systems described herein may blacklist malicious URLs and/or IP addresses. Thus, the security actions in conjunction with the methods and systems described herein may improve the security and operating integrity of one or more computing devices by protecting the hardware, firmware, software, or any combination thereof of the one or more computing devices from malicious attack. It should be appreciated that these are not exhaustive lists of the types of security actions which may be performed by the systems described herein. Other security actions are also included in this disclosure.
[0086] What is claimed is:

Claims

1. A method for validating operational behaviors of objects associated with a supply chain, at least a portion of the method being performed by one or more computing devices comprising at least one processor, the method comprising:
receiving, at a device, a request to execute an object installed on the device; determining whether a manifest of the object is registered with a registration agent installed on the device, the manifest defining one or more aspects of the object;
upon determining the manifest is registered with the registration agent, executing the object on the device;
monitoring, via a monitoring agent installed on the device, operational behaviors of the object; and
upon determining the manifest is unregistered with the registration agent,
performing a security action.
2. The method of claim 1 , wherein the one or more security actions include at least one of preventing the object from executing, disabling access to at least a portion of the object, disabling one or more processes associated with the object, scanning the object for malware, quarantining the object, deleting the object from the device, generating a notification indicating the object may be compromised, revoking at least one user’s access to the object, or any combination thereof.
3. The method of claim 2, further comprising:
identifying an operation of the object based at least in part on the monitoring; and
performing at least one of the one or more security actions based at least in part on determining that the identified operation is not specified by the manifest or that the manifest expressly disallows the identified operation.
4. The method of claim 2, further comprising: querying a server external to the device to determine whether the manifest remains valid.
5. The method of claim 4, further comprising:
performing at least one of the one or more security actions upon determining a response from the server indicates the manifest is no longer valid; and continuing to allow the object to execute and to monitor the object upon
determining the response from the server indicates the manifest remains valid.
6. The method of claim 1 , wherein at least a portion of the content of the manifest is based at least in part on one or more behaviors of the object identified during execution time.
7. The method of claim 1 , wherein determining that the manifest is registered with the registration agent is based at least in part on determining that the manifest indicates the object is to be monitored.
8. The method of claim 1 , wherein determining that the manifest is registered with the registration agent includes determining that a hash included in the manifest is registered with the registration agent.
9. The method of claim 1 , wherein the one or more aspects of the object include at least one of operational behaviors, one or more files associated with the object, one or more files used by the object, one or more files the object is permitted to access, one or more processes associated with the object, one or more processes the object is allowed to initiate, one or more internet protocol (IP) addresses that the object may access, one or more network locations that the object may access, one or more cryptographic hashes associated with the object, one or more digital signatures of the object, one or more digital certificates of the object, or any combination thereof.
10. The method of claim 1, wherein the monitoring agent and the registration agent operate independently of the object, and wherein the monitoring agent and the registration agent operate independently of each other or in conjunction with each other.
11. The method of claim 1, wherein the object comprises at least one application.
12. A computing device for validating operational behaviors of objects associated with a supply chain, comprising:
a processor;
memory in electronic communication with the processor, wherein the memory stores computer executable instructions that when executed by the processor cause the processor to perform the steps of:
receiving, at a device, a request to execute an object installed on the
device;
determining whether a manifest of the object is registered with a registration agent installed on the device, the manifest defining one or more aspects of the object;
upon determining the manifest is registered with the registration agent, executing the object on the device;
monitoring, via a monitoring agent installed on the device, operational behaviors of the object; and
upon determining the manifest is unregistered with the registration agent, performing a security action.
13. The computing device of claim 12, wherein the one or more security actions include at least one of preventing the object from executing, disabling access to at least a portion of the object, disabling one or more processes associated with the object, scanning the object for malware, quarantining the object, deleting the object from the device, generating a notification indicating the object may be compromised, revoking at least one user’s access to the object, or any combination thereof.
14. The computing device of claim 13, further comprising:
identifying an operation of the object based at least in part on the monitoring; and
performing at least one of the one or more security actions based at least in part on determining that the identified operation is not specified by the manifest or that the manifest expressly disallows the identified operation.
15. The computing device of claim 13, further comprising:
querying a server external to the device to determine whether the manifest
remains valid.
16. The computing device of claim 15, further comprising:
performing at least one of the one or more security actions upon determining a response from the server indicates the manifest is no longer valid; and continuing to allow the object to execute and to monitor the object upon
determining the response from the server indicates the manifest remains valid.
17. The computing device of claim 12, wherein at least a portion of the content of the manifest is based at least in part on one or more behaviors of the object identified during execution time.
18. The computing device of claim 12, wherein determining that the manifest is registered with the registration agent is based at least in part on determining that the manifest indicates the object is to be monitored.
19. The computing device of claim 12, wherein determining that the manifest is registered with the registration agent includes determining that a hash included in the manifest is registered with the registration agent.
20. A non-transitory computer-readable storage medium storing computer executable instructions that when executed by a processor cause the processor to perform the steps of:
receiving, at a device, a request to execute an object installed on the device; determining whether a manifest of the object is registered with a registration agent installed on the device, the manifest defining one or more aspects of the object;
upon determining the manifest is registered with the registration agent, executing the object on the device;
monitoring, via a monitoring agent installed on the device, operational behaviors of the object; and
upon determining the manifest is unregistered with the registration agent,
performing a security action.
PCT/US2019/039953 2018-08-28 2019-06-28 Software supply chain hardening via two-factor application integrity certification and monitoring Ceased WO2020046463A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201816115096A 2018-08-28 2018-08-28
US16/115,096 2018-08-28

Publications (1)

Publication Number Publication Date
WO2020046463A1 true WO2020046463A1 (en) 2020-03-05

Family

ID=67439389

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2019/039953 Ceased WO2020046463A1 (en) 2018-08-28 2019-06-28 Software supply chain hardening via two-factor application integrity certification and monitoring

Country Status (1)

Country Link
WO (1) WO2020046463A1 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8281410B1 (en) * 2008-03-31 2012-10-02 Symantec Corporation Methods and systems for providing resource-access information
US20130254880A1 (en) * 2012-03-21 2013-09-26 Mcafee, Inc. System and method for crowdsourcing of mobile application reputations
US20150229673A1 (en) * 2012-09-03 2015-08-13 Ahnlab, Inc. Apparatus and method for diagnosing malicious applications

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8281410B1 (en) * 2008-03-31 2012-10-02 Symantec Corporation Methods and systems for providing resource-access information
US20130254880A1 (en) * 2012-03-21 2013-09-26 Mcafee, Inc. System and method for crowdsourcing of mobile application reputations
US20150229673A1 (en) * 2012-09-03 2015-08-13 Ahnlab, Inc. Apparatus and method for diagnosing malicious applications

Similar Documents

Publication Publication Date Title
US12307239B2 (en) Credential-changing plugin for IoT devices
US8230415B1 (en) On-demand advertising of software packages
US7814543B2 (en) System and method for securing a computer system connected to a network from attacks
US8154987B2 (en) Self-isolating and self-healing networked devices
US7716727B2 (en) Network security device and method for protecting a computing device in a networked environment
US8881284B1 (en) Method and system for secure network access using a virtual machine
US8402528B1 (en) Portable firewall adapter
US20130305340A1 (en) Integrity monitoring to detect changes at network device for use in secure network access
KR20190015273A (en) Hardware-based virtualized security isolation techniques
US10262137B1 (en) Security recommendations based on incidents of malware
US10482250B1 (en) Using a common account to block malware on multiple devices
AU2019206085B2 (en) Inoculator and antibody for computer security
US11283881B1 (en) Management and protection of internet of things devices
US20090217375A1 (en) Mobile Data Handling Device
US11409871B1 (en) Universal tracing of side-channel processes in computing environments
WO2020046463A1 (en) Software supply chain hardening via two-factor application integrity certification and monitoring
US11558383B1 (en) Securing cloud applications via isolation
Wang et al. Research on the principle and analysis of shellshock bug
GB2611756A (en) Apparatus and method for threat detection in a device
GB2612918A (en) Firmware management for IOT devices

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: 19744978

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19744978

Country of ref document: EP

Kind code of ref document: A1