Bit Discovery has been tracking the attack surface maps for hundreds of companies for a few years now. In the process we’ve found an interesting use-case. Companies will have assets in their inventory that they were once interested in, then they’ll suddenly say, “these assets no longer belong to us,” or “we no longer care about these assets.” As we might expect, there’s a variety of reasons why, that we’ll explore.
Briefly, let’s first appreciate that the attack surface map for a company is a living, breathing, and constantly evolving thing. The bigger the attack surface map, the more likely assets are to change — day to day and hour to hour. Hosts may be added or removed. Listen ports/services may be open and closed. Software may be added, removed, and updated. Clearly, there is no other way to keep an attack surface map up-to-date, other than through fierce automation. Then, of course, if any of these aforementioned changes are unknown or uncontrolled, we can safely refer to them as shadow assets, shadow services, and shadow software respectively.
So, let’s touch on some of the many reasons why an asset needs to be removed from an attack surface map.
1) Domain name(s) was purposely or mistakenly expired
2) Hostname / asset was decommissioned or IP-filtered by a perimeter firewall
3) Listen port / service was disabled or IP-filtered by a perimeter firewall
4) Ownership of the asset was transferred to another company (i.e. M&A)
5) Management and responsibility of the asset was transferred to a third-party (i.e. vendors / cloud provider)
6) Asset is no longer important enough to pay attention to (i.e. campaign is over)
7) Someone registered the wrong domain name (i.e. keyword / typo)
I’m sure there are more reasons, but these are the most common.
As we can see, attack surface management must be more than just adding assets to an inventory. It also requires smartly removing them as well. Otherwise, there will eventually be a lot of garbage data to contend with, and the map will be anything but useful and up to date.
