🔑👨🏭 Provide secure IT tools
Picture this. You’re an Engineer working on BAU— debugging apps, tweaking databases and you come across a Base64 string.
A quick search finds you a Base64 decoder website which you use, unveiling a secret contained within. But upon examining the secret you decide it is not relevant to your efforts and return to debugging.
What just happened might be okay in certain scenarios. But did it cross your mind if that decode took place on the client-side or remotely? Was it saved to the websites database or logs? What happens if the site ever suffers a security breach? Or maybe what you actually just used was a phishing site.
Online utility sites are commonly used in organizations because their convenience. Although I am not suggesting they are malicious - it’s just hard to trust which one is genuine.
Developers, engineers and infrastructure teams often use them to provide a long list of utility functions such as; encoding, hashing, parsers, validators, prettifiers, transformers, data sent to them can contain sensitive information like security tokens, passwords, customer PII. It’s crucial it stays within the confines of your organization.
I personally think it’s a slightly overlooked area of Engineering which can do with addressing.
One quick way to solve this is by providing a vetted list of external apps. A feature to consider is ‘in-browser’ or ‘offline’ apps— where data is computed locally and not transmitted remotely.
Examples of ‘local’ apps
- CyberChef (https://gchq.github.io/CyberChef/)
- Recommended (Created by our very own GCHQ)
- DevUtils (https://devutils.com/)
- encoding.tools (https://encoding.tools/)
An approved list of apps might be good enough because they address the biggest concern (external data transmission).
But, external apps can present their own issues regardless of being genuine; supply chain attacks, rogue deployments, change in functionality etc.
What’s the best solution?
Short of developing your own, a pragmatic compromise is to set up your own instance of an open source web application such as IT-Tools — offering 75+ functions, works ’in-browser’ and it’s a static site (which helps limit the attack surface).
Organizations can retain full control over the instance which is probably a second important feature.
Further reading
In another seperate post I will cover how best to deploy IT-Tools in Kubernetes with security hardening techniques.
I will break down my decisions for you to understand, and so you can apply the to any workload in future.
Summarizing
If you still think this is just a nice to have or too much effort than it’s worth. I’d argue it’s an area worth considering in every Engineering teams Security posture.
Working for different clients, I’ve witnessed it take many forms; online regex tools to split production .NET connection strings by ’;’ or PCI DSS compliant environments exposing customer PII to JWT validators etc.
Engineers need these tools sometimes on a daily basis and it’s always been a bit of a wild west with everyone doing things their own way. A poorly equipped engineer may misplace their trust and inadvertently cause a security blunder, emphasizing the importwance for a secure engineering tool-set.