Ignoring assets

Some of the bigger clients have infrastructure of which they only want to monitor a subset. For domains with many subdomains this has been available for a while. It wasn't really the most usable or logical solution, but it worked. And then a new problem surfaced.

ShadowTrackr picked up about 1400 docker containers on a particular subdomain. These were not really important to the client and messages about the docker instances started crowding out the important ones on the timeline. Ignoring this meant clicking 1400 checkboxes to start, and then manually tracking all new hosts as the are generated. The client of course requested a feature to ignore an entire subdomain.

I took the opportunity to redesign the ignore filter. The new version will give you a better overview, is available for all domains (including those with only a few subdomains or hosts) and supports automatically ignoring anything found on a subdomain. If, for instance, you want to ignore all hosts under docker.shadowtrackr.com, you:

• add the subdomain under assets
• click on the + sign after adding
• click on the filter link right next to it
• tick the box to ignore subdomains for it
• save the new settings

You will be able to see all newly found urls for the subdomain under ignored assets, but no messages about these will appear on your timeline. Be careful to only ignore assets that do not create risks for you. If you do ignore something your business partners or clients consider yours, this might blow up in your face when you miss a security warning.

Ignoring not only urls but also ips is still on the todo list. This will be added next.

Threat intelligence

If you just ticked the intel box for messages on your timeline it has been a bit empty lately. This is because I had to remove some boring stuff. The interesting events that remained under intel did not occur very often. This weeks update includes an attempt to improve that.

I find myself checking multiple security blogs regularly to see if there are any new reports available on particular APTs. As often when browsing the internet, I found a lot of other news as well and only hours later I'm back to work. I figured more people have this problem and I should automate it in ShadowTrackr.

Under traps you'll see a new tab: Intel. You can select which APTs you're interested in and when there is new information available it will appear on your timeline. Alerts to your email address or smartphone are also possible of course, and you'll notice something new there too.

In bigger organizations you'll have more specialized functions and some (the threat intel people) will likely want alerts pushed. The other security people might not. So, you can now set alerts just for yourself or for all ShadowTrackr users on your account. I'm guessing that this is very useful for other traps as well and I'll start working on implementing this feature for all traps.

Port change notifications

Last month has seen lost of small changes in existing notifications. The goal is to cleanup the timeline and make it more useful. Some messages are more concise, some are grouped, and some contain more context so you don't have to look things up manually (what was on that ip?).

The biggest one of these changes is in the way port notifications are handled. Each port was a separate event and only showed the port number and ip. Only when showing the timeline where these event grouped, which unnecessarily slowed down the page buildup. And this didn't really work well when scrolling. Port events are now grouped when the event is generated and nicely formatted with proper context. Much better than it was, except for ports that are actively checked (like those with STARTTLS). Active checks produce a lot more information than just checking if a port is open. I still have to figure out a way to integrate those without messing up a nice timeline.

Another problem solved is the different lists of bad ports and advice on what to do. These where different lists on the nodes where the events are generated and on the webservers. Multiple lists are cumbersome to maintain and error prone. If some attacks are spotted more often you want to change the message of the corresponding notification on the bad port list, and maybe the level too. The list is now centrally maintained on the server and automatically pushed to all nodes. From now on you'll get consistent advice on port changes.