WO2020046463A1 - Renforcement d'une chaîne d'approvisionnement de logiciel au moyen d'une certification et d'une surveillance d'intégrité d'application à deux facteurs - Google Patents

Renforcement d'une chaîne d'approvisionnement de logiciel au moyen d'une certification et d'une surveillance d'intégrité d'application à deux facteurs 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
Application number
PCT/US2019/039953
Other languages
English (en)
Inventor
Adam Bromwich
Joseph H. CHEN
Eric C. CHIEN
Haik A. MESROPIAN
Joao M. FORCADA
Original Assignee
Symantec Corporation
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 Corporation filed Critical Symantec Corporation
Publication of WO2020046463A1 publication Critical patent/WO2020046463A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/566—Dynamic detection, i.e. detection performed at run-time, e.g. emulation, suspicious activities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud
    • H04W12/128—Anti-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

L'invention concerne un procédé permettant de valider des comportements opérationnels d'objets associés à une chaîne logistique. Dans un mode de réalisation, le procédé peut consister à : recevoir, sur un dispositif, une demande d'exécution d'un objet installé sur le dispositif ; déterminer si un manifeste de l'objet est enregistré auprès d'un agent d'enregistrement installé sur le dispositif, le manifeste définissant un ou plusieurs aspects de l'objet ; lorsqu'il est déterminé que le manifeste est enregistré auprès de l'agent d'enregistrement, exécuter l'objet sur le dispositif ; surveiller, au moyen d'un agent de surveillance installé sur le dispositif, les comportements opérationnels de l'objet ; et lorsqu'il est déterminé que le manifeste n'est pas enregistré auprès de l'agent d'enregistrement, exécuter une action de sécurité.
PCT/US2019/039953 2018-08-28 2019-06-28 Renforcement d'une chaîne d'approvisionnement de logiciel au moyen d'une certification et d'une surveillance d'intégrité d'application à deux facteurs WO2020046463A1 (fr)

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 (fr) 2020-03-05

Family

ID=67439389

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2019/039953 WO2020046463A1 (fr) 2018-08-28 2019-06-28 Renforcement d'une chaîne d'approvisionnement de logiciel au moyen d'une certification et d'une surveillance d'intégrité d'application à deux facteurs

Country Status (1)

Country Link
WO (1) WO2020046463A1 (fr)

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
Simpson et al. Securing vulnerable home IoT devices with an in-hub security manager
US11886866B2 (en) Credential management for IoT devices
US8230415B1 (en) On-demand advertising of software packages
US8154987B2 (en) Self-isolating and self-healing networked devices
US7814543B2 (en) System and method for securing a computer system connected to a network from attacks
US8881284B1 (en) Method and system for secure network access using a virtual machine
US7716727B2 (en) Network security device and method for protecting a computing device in a networked environment
US8997201B2 (en) Integrity monitoring to detect changes at network device for use in secure network access
KR20190015273A (ko) 하드웨어 기반의 가상화된 보안 격리 기법
US8402528B1 (en) Portable firewall adapter
US20110209222A1 (en) System and method for providing transactional security for an end-user device
US9349009B2 (en) Method and apparatus for firmware based system security, integrity, and restoration
WO2009094371A1 (fr) Bureau sécurisé de confiance
US10262137B1 (en) Security recommendations based on incidents of malware
US20090217375A1 (en) Mobile Data Handling Device
US11558365B1 (en) Multi-second factor authentication
WO2012061319A1 (fr) Inoculateur et anticorps pour une sécurité informatique
US11409871B1 (en) Universal tracing of side-channel processes in computing environments
KR102034934B1 (ko) Tpm 하드웨어 보안칩을 사용하여 로컬 기기의 네트워크 접속을 제어하는 방법
WO2020046463A1 (fr) Renforcement d'une chaîne d'approvisionnement de logiciel au moyen d'une certification et d'une surveillance d'intégrité d'application à deux facteurs
US11283881B1 (en) Management and protection of internet of things devices
US20230131132A1 (en) Securing containerized applications
Wang et al. Research on the principle and analysis of shellshock bug
GB2611756A (en) Apparatus and method for threat detection in a device
Xu Security enhancement of secure USB debugging in Android system

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