BeyondTrust

Security in Context: The BeyondTrust Blog

Welcome to Security in Context

Bringing you news and commentary on solutions and strategies for protecting critical IT infrastructure in the context of your business.

Rogue Asset Detection

Posted March 3, 2011    Morey Haber

A few weeks ago in my blog, I mentioned a critique regarding targeted vulnerability assessment and its ability to not identify rogue devices.  Anytime you have definitive host list (by host name or from Active Directory for example), or a fixed set of IP addresses (versus ranges) you can potentially miss devices connected to your network for vulnerability assessment. Whether those devices are authorized or not becomes the primary point for rogue asset detection. The hardest part of rogue asset detection is performing an initial assessment of everything on a given network and determining what is authorized and what is not. Many times just pulling back the host name, operating system, and domain is sufficient to determine this. The example below is from Retina CS and shows how to do this for Windows devices:

This simple rule will automatically build a logical group of machines where the domain name is not “eEye”. The default domain for Windows can be everything from MSHome to Workgroup and if the host is not registered to the domain (most rogue devices for Windows are not since the user should / would not have permissions to join the domain) the asset would be listed in the group.

Just as easily, if your organization uses a standardized NetBIOS naming convention, a simple rule like this could group machines that do not follow the correct syntax and could be potentially rogues regardless of the operating system:

This would group all assets (in an IP range, not shown) that would not contain a string USPHX for devices potentially located in the United States and Phoenix.  If the standard naming convention is not followed, they would be grouped for further investigation.

Retina CS allows for a large variety of rules to be created that can capture traits from a host that do not conform to your deployment policies and group them for reference. These can be used to isolate rogue devices based on anything from the operating system, asset name, and even to ports and services available on the asset. For example, “this subnet should never have any webservers running”, would be an example of a potential rogue application. It only takes a little standardization to build a rule to capture the devices that do not comply.

Next,  once we have established a baseline for what is legitimately on the network, we need to capture unauthorized changes that could be rogue devices.  Many organizations only perform a single quarterly vulnerability assessment due to regulatory compliance or  a lack of resources. For these businesses, I would strongly encourage using a VA solution to discover (not necessarily assess) your network at least once a week to identify and document any changes that may occur. Using a discovery scan frequently (even daily), can identify any changes. Consider the rule below:

This will build a group (and even send email alerts) for newly discovered devices that are less than one day old, or for any devices that have not been detected or updated within 8 days. Therefore, if I am scanning once a week,  I can capture new devices (possible rogues) and any devices that may have been taken off the network in appropriately.

Rogue asset detection can be tricky when assessment or discovery scans do not occur on a frequent basis. In addition, if an organization does not have any standardization for naming, operating systems, or policies for change control, the problem is compounded.  This can lead to improper mappings when creating rules because policies are not being used as a point of reference to identify deviations.  In order to perform any type of rogue asset detection, you must first establish a baseline. Then you can determine if any changes that occur are acceptable and if they do occur, which systems should be investigated further. Ask your team members two questions:

- Do you know all of the devices on your network?

- Are they all authorized?

If the answer is “no” to either of these questions, you should consider using your vulnerability assessment to help with rogue asset detection.

Leave a Reply

Additional articles

PBPS-screenshot-blog aug2014

Failing the Security Basics: Backoff Point-of-Sale Malware

Posted August 22, 2014    Marc Maiffret

At the beginning of this month, US-CERT issued a security alert relating to a string of breaches that had been targeting Point of Sale (POS) systems. The alert details that attackers were leveraging brute forcing tools to target common remote desktop applications such as Microsoft’s Remote Desktop, Apple Remote Desktop, Splashtop and LogMeIn among others….

Tags:
, , , , , ,

Troubleshooting Windows Privilege Management Rules with Policy Monitor

Posted August 21, 2014    Jason Silva

When defining and testing PowerBroker for Windows rules for production or pilots, customers sometimes tell us, “I don’t think this policy / program is working.” This is usually a case of the policy not properly triggering because of the way the rule was created. A unique feature of PowerBroker for Windows compared to other solutions is a client-side…

Tags:
, , ,
darren-mar-elia

BeyondTrust Webcast: Darren Mar-Elia’s 4 Active Directory Change Scenarios to Track

Posted August 20, 2014    Chris Burd

In our latest webcast, we joined Darren Mar-Elia, CTO at SDM Software, to discuss best practices for Active Directory (AD) change management. Here are some key takeaways from the presentation, followed by a link to a full-length video of the presentation. Mar-Elia kicks things off with a critical insight: that the best AD change management…

Tags:
, , , , , , ,