Abstract: A device may receive a file that has been downloaded, or is to be downloaded, to a user device, and that is to be subject to a malware detection procedure. The device may obtain, based on one or more file identification properties of the file, metadata identifying user interactions associated with the file. The metadata may include a first group of user interactions performed when the file was accessed on the user device or a second group of user interactions performed when the file was accessed on one or more other user devices. The device may test the file in a sandbox environment to obtain a result by performing the user interactions identified by the metadata and executing the malware detection procedure to determine whether the file is malware. The device may provide a notification to cause the user device to perform actions when the file is malware.

Abstract: Events of a calendar are identified and evaluated for confidentiality due to an explicit tag, location, participants, or subject matter. In response, permissions of applications on a device are dynamically reduced. Permissions may include permissions to access sensors such as a microphone and camera. Sensors of other devices such as a voice-processing device or Bluetooth device may be disabled. The risk associated with applications on a device may be evaluated based on permissions, usage, collected data, cloud service provider, location, permissions and usage of other users of the application, and other attributes of the application. The risk may be represented as a risk score used to determine whether to perform a mitigation action.

Abstract: A device may receive a file that has been downloaded, or is to be downloaded, to a user device, and that is to be subject to a malware detection procedure. The device may obtain, based on one or more file identification properties of the file, metadata identifying user interactions associated with the file. The metadata may include a first group of user interactions performed when the file was accessed on the user device or a second group of user interactions performed when the file was accessed on one or more other user devices. The device may test the file in a sandbox environment to obtain a result by performing the user interactions identified by the metadata and executing the malware detection procedure to determine whether the file is malware. The device may provide a notification to cause the user device to perform actions when the file is malware.

Abstract: A device may receive a file that has been downloaded, or is to be downloaded, to a user device, and that is to be subject to a malware detection procedure. The device may obtain, based on one or more file identification properties of the file, metadata identifying user interactions associated with the file. The metadata may include a first group of user interactions performed when the file was accessed on the user device or a second group of user interactions performed when the file was accessed on one or more other user devices. The device may test the file in a sandbox environment to obtain a result by performing the user interactions identified by the metadata and executing the malware detection procedure to determine whether the file is malware. The device may provide a notification to cause the user device to perform actions when the file is malware.

Abstract: A device may receive a file that has been downloaded, or is to be downloaded, to a user device, and that is to be subject to a malware detection procedure. The device may obtain, based on one or more file identification properties of the file, metadata identifying user interactions associated with the file. The metadata may include a first group of user interactions performed when the file was accessed on the user device or a second group of user interactions performed when the file was accessed on one or more other user devices. The device may test the file in a sandbox environment to obtain a result by performing the user interactions identified by the metadata and executing the malware detection procedure to determine whether the file is malware. The device may provide a notification to cause the user device to perform actions when the file is malware.

Abstract: A device may receive a file that has been downloaded, or is to be downloaded, to a user device, and that is to be subject to a malware detection procedure. The device may obtain, based on one or more file identification properties of the file, metadata identifying user interactions associated with the file. The metadata may include a first group of user interactions performed when the file was accessed on the user device or a second group of user interactions performed when the file was accessed on one or more other user devices. The device may test the file in a sandbox environment to obtain a result by performing the user interactions identified by the metadata and executing the malware detection procedure to determine whether the file is malware. The device may provide a notification to cause the user device to perform actions when the file is malware.

Abstract: Methods and systems have been provided for removing dead Access Control Entries (ACEs) in an Access Control List (ACL). In one embodiment, the dead ACEs can be detected for an egress as well as an ingress ACL. The ACEs that have a hit count above a user-specified hit count are checked for their validity. The validity of the ACE is checked, using the information based on a Forwarding Information Base (FIB). If an ACE is found to be invalid, it is considered dead. The dead ACEs are referred as candidates for removal from the ACL. If the ACE is found to be a candidate for removal, a system administrator can either warn the network administrator about the candidate for removal or delete the ACE from the ACL after a pre-defined time limit.

Abstract: Methods and systems have been provided for removing dead Access Control Entries (ACEs) in an Access Control List (ACL). In one embodiment, the dead ACEs can be detected for an egress as well as an ingress ACL. The ACEs that have a hit count above a user-specified hit count are checked for their validity. The validity of the ACE is checked, using the information based on a Forwarding Information Base (FIB). If an ACE is found to be invalid, it is considered dead. The dead ACEs are referred as candidates for removal from the ACL. If the ACE is found to be a candidate for removal, a system administrator can either warn the network administrator about the candidate for removal or delete the ACE from the ACL after a pre-defined time limit.

Abstract: In one embodiment of the invention, a method for automating collateral configuration in a network is provided. A service is configured on a network device (termed as service providing device). The service providing device sends a Collateral Configuration Request Protocol (CCRP) message to other network devices (termed as service accessing devices). The service accessing devices process the CCRP message for their automatic collateral configuration in order to access the configured service on the service providing device.

Abstract: Methods and systems have been provided for removing dead Access Control Entries (ACEs) in an Access Control List (ACL). In one embodiment, the dead ACEs can be detected for an egress as well as an ingress ACL. The ACEs that have a hit count above a user-specified hit count are checked for their validity. The validity of the ACE is checked, using the information based on a Forwarding Information Base (FIB). If an ACE is found to be invalid, it is considered dead. The dead ACEs are referred as candidates for removal from the ACL. If the ACE is found to be a candidate for removal, a system administrator can either warn the network administrator about the candidate for removal or delete the ACE from the ACL after a pre-defined time limit.

Abstract: A method, system, and apparatus are provided for testing a service in a network. A simulated interface is created on a network device by a Network Management Station (NMS). Thereafter, an instruction is received at the simulated interface from the NMS. The instruction comprises a source address, a destination address and other information to test a service. The service is tested on the network device based on the received instruction. A response is generated from the test. The response indicates whether the service is working as intended between the source address and the destination address. The response is sent from the simulated interface to the NMS.

Abstract: In one embodiment of the invention, a method for automating collateral configuration in a network is provided. A service is configured on a network device (termed as service providing device). The service providing device sends a Collateral Configuration Request Protocol (CCRP) message to other network devices (termed as service accessing devices). The service accessing devices process the CCRP message for their automatic collateral configuration in order to access the configured service on the service providing device.

Abstract: Methods and systems have been provided for removing dead Access Control Entries (ACEs) in an Access Control List (ACL). In one embodiment, the dead ACEs can be detected for an egress as well as an ingress ACL. The ACEs that have a hit count above a user-specified hit count are checked for their validity. The validity of the ACE is checked, using the information based on a Forwarding Information Base (FIB). If an ACE is found to be invalid, it is considered dead. The dead ACEs are referred as candidates for removal from the ACL. If the ACE is found to be a candidate for removal, a system administrator can either warn the network administrator about the candidate for removal or delete the ACE from the ACL after a pre-defined time limit.

Abstract: A method, system, and apparatus are provided for testing a service in a network. A simulated interface is created on a network device by a Network Management Station (NMS). Thereafter, an instruction is received at the simulated interface from the NMS. The instruction comprises a source address, a destination address and other information to test a service. The service is tested on the network device based on the received instruction. A response is generated from the test. The response indicates whether the service is Working as intended between the source address and the destination address. The response is sent from the simulated interface to the NMS.