One of the key challenges in what we do, and I believe this applies pretty much to anyone doing anything new or non-standard, is to translate the actual benefit of it. I know it sounds like something trivial but in my experience just because you see things in a certain way it does not necessarily mean that other people see them the same. In fact, anything that does not fit into the status quo will have significant obstacles ahead to get even mildly adopted although once it does it has more leverage due to the first mover advantage.
Why am I bringing this up? Our grand mission is to take as many security tools as we can on to our platform and to make them open, free to use as much as it makes sense economically and of course readily available. This has been my driving force for a number of years now and we just start getting traction. But how do these tools work and what are the advantages for you and for us as makers of this platform?
Delivering security tools packaged as modern web applications have numerous benefits form providing security services quicker and more consistently than ever before, to enabling people to educate and promote better security practice and of course take advantage of the power of the community through social interactions using a common platform. But traditional web applications have server-side interactive components. This is literally how everyone is thought how to build web applications today - you start with a web server and server-side scripting language of some sort. When it comes to understanding how these new security web-based tools work, it is obvious that most people will think that they are written like any other SaaS product out there and as a result subject to the same disadvantages present in existing tools in the same category. This is not how we do things at SecApps and there is a lot of novelty going on underneath.
Building a security solution that is delivered as a traditional web application with server-side components is challenging in many ways. We want to allow users to test whatever they want whenever they want without asking for permission but that also means that we will be open to abuse of our server-side components. A minority of users will find ways to test things they are not supposed to test and then who is to blame? To prevent this behaviour other vendors have implemented a strict validation policy which pushes users into verifying the ownership of the thing they are testing. Furthermore, because these web apps are not sitting in your local network, it also means that without clever hacking or using some reverse proxies and TCP tunnels you will not be able to test internal applications which are either not meant for public consumption or not available online yet.
This is why in these situations, a desktop-based alternative is considered to be better. With a desktop security tool, mind the licensing restrictions, you can certainly test what you want and whenever you want but that is not without its challenges. For a start, most of these tools are either too expensive or too restrictive. Moreover, issuing patches and making changes is stuck in the 90s era of software development and distribution. What about cross-platform? What about not using specialist equipment that is purpose-built for the task (a.k.a dirty laptops) because no one is trusting the software on them. It does not feel modern anymore.
If we can only converge the power of desktop tools, with the delivery and interaction channels of the web platform, we will achieve equilibrium in the sense that we can lift the restrictions disadvantages of both platforms while at the same time increasing the flexibility and drive the cost down.
This is what we build. This is all possible thanks to browser technological improvements which we leverage in every single tool we put up online. This why we ask the users to install our web extension, which provides a thin integration layer between the tools and the browser technology that sits underneath. Once the extension is installed you can test without restrictions, without verifications and with complex setups and dirty laptops. It is just the browser and the channel of delivery is the web.
If you explore the blog you will find a lot of examples of how we do this but here is a mental step-by-step process how it feels. First, we open our scanner which can be found at the launchpad. Now if you have the extension installed, then you can type the target you want to test. So let's say that the target is a local web application you are developing at the moment. We type in the address, which is http://127.0.0.1:8080 and click on the start button. We start getting results as soon as the test kicks in. No additional software packages were installed. You can test stuff that no other SaaS security vendor can test due to the fact that the resource you are testing is local. There are no license restrictions. The best part is that if we deploy a change to the scanner, it will be transparent so we can improve the technology as we go without making it inconvenient. You security testing laptop could be even a locked down ChromeOS machine. It is no longer a dirty laptop.
I want to finish covering something I mentioned earlier, which is that this method of development drives the overall cost down. Let me explain. To make anything even when open-source, it takes time and resources which do not come for free. The web platform over time allows faster and smarter delivery of the same stack of technology and as a result, these performance improvements will cut down the cost of support and development which only means that over time it will be not only better but a lot less expensive. We can see a lot of examples of this phenomenon. We are not the only ones involved. In fact, that model is well understood and adopted even by the biggest tech companies in the world.
I know this is not a deep technical paper on how the extension works and how we build each individual tool to use the extension while we base everything on a common development standard, and so on. This blog post will come soon enough, I promise. I hope I managed to interest you even for a bit about what we are building and I really hope you will spend a couple of minutes as soon as you finish to explore what we have done so far and send us some feedback, which we will appreciate very much.