Secure networked environments may be subject to a myriad of attempts to authenticate to, access, and use their resources and assets without proper credentials. Such networked environments are difficult to monitor and unauthorized attempts to access are difficult to detect. Further, even if an unauthorized access attempt is detected, it may only be classified as a “failed” attempt, which provides little information concerning, e.g., the source of the attempt, whether the attempt originates with an authorized or an unauthorized user, etc.
One practical problem is that security professionals must review activity logs and perform additional analysis to determine if unauthorized authentication attempts were made on an asset. Such techniques may rely, for example, on a denied parties list, domain information for known “bad” actors, or repeated attempts to authenticate without the proper credentials.
With regard to tracing, for networks having multiple assets there may be different accounts active on each asset. Further, assets from different networks can be communicably linked to assets in other networks, each asset having different active accounts. Some of these different accounts may in fact be associated with each other, such as when they are associated with the same user. A user may authenticate using account “X” on a first network asset and then through machine-to-machine authentication authenticate using account “Y” on a second network asset. Machine-to-machine authentication may purposefully or incidentally obfuscate the identity of the account or the user through account switching.
Activity at a network asset may be monitored at an account level using various techniques, including event logs. The logged information may include the identity of the asset and the information for the account associated with the logged event. Presently, the typical process for reviewing event information is for a security professional to manually gather information from various event logs, after the fact, and piece together authentication attempts and correlate accounts. This is a time consuming process and prone to error. Further, these techniques do not leverage the information gathered about the accounts to improve or update network or asset policies, nor enable active network monitoring.
Activity on a network may be monitored at a device level using “honeypot” virtual appliances. The virtual appliances may be installed on network assets, and are used, for example, on corporate servers. Honeypot devices may act as decoys—attracting access attempts or other activity by unauthorized users. However, existing “honeypot” tools require set up and configuration. The tool configuration settings, such as open ports, whitelists, and health status, are typically managed in isolation and require access to the individual honeypots for changing their settings. This process can be cumbersome and time consuming if an administrator desires to deploy a large number of honeypots across one or more monitored networks.
Accordingly, there is a need for robust systems and methods that detect security threats, unauthorized activity, and trace account usage by tracking and correlating machine-to-machine authentication and mapping accounts across network assets, including across multiple assets, in such a way as to describe how a user or account utilizes various assets on a network. There is also a need for systems and methods that will facilitate improvements and updates to policy enforcement for account usage at a network and an asset level, as part of a security and management ecosystem. Finally, there is a need for a honeypot virtual appliance that is easily deployable, configurable, and manageable from a remote central console.
USPTO Backgrounds
USPTO Backgrounds