ERNW has a new baby, so please say “hello” to the new ERNW SecTools GmbH ;-).
But why another ERNW company? Short answer: Because we want to contribute to changing the way how software is built today: insecure, focused on profit and sometimes made by people who ignore lessons from history. So how can we contribute in this space? Start changing it ;-).
Confucius said: “The man who moves a mountain begins by carrying away small stones” and that’s our way to go. It is not about building error free or unbreakable software, it is about changing the way how software is built today, about improving security and about raising the bar.
Still I think this short answer needs some more details. We at ERNW have been doing security consulting and pentests for decades and we still observe that quite a few new technologies share the same problem: almost no security is built in from scratch. So it doesn’t seem to be possible to learn from past mistakes, but what might be the reasons for that?
Very often the main argument is “time to market” or it’s due to commercial reasons – sometimes a product is sold for a low price and implementing security features would make it more expensive, maybe too expensive, so people will choose other products/vendors.
Based on our experience we believe that it is possible to build secure software and tools, as long as security is on the project agenda and one is taking care of it from the beginning. And it won’t result in a product too expensive for people to buy it as long as you implement reasonable security.
One day the idea popped up to build a quite special security tool that can help to make our customers‘ environments more secure, and quite a few were frequently asking for this kind of tool. So we decided to enter a complete new field of activity: software development. Now we face the challenge to put some of our expertise into a working, functional tool which fulfills the requirements of our customers and of course has build-in all relevant and required security features. Challenge accepted and the ERNW SecTools was born.
As I already mentioned, security should be part of the project from the beginning, so we put it onto the agenda 😉 and we will also publish a number of blog posts about our approaches. This one is the first and it will summarize some steps that from our experience must be implemented right from the start.
Make Security Part of the Project
A product is (at least in some common models) considered to have a typical life cycle that consists of five phases:
1. Analysis, requirements phase (define requirements of the product)
2. Design phase (choose technology stack and components)
3. Coding phase (coding of the product)
4. Testing phase (testing of the product)
5. Production phase (release of the product)
Every phase requires some security tasks that are part of the project; and even before the project starts you have to take care that the developers are trained in secure coding, that they are aware of security and of relevant attacks and that they have required guidelines at hand. The following graph shows the life cycle and the main tasks for the first phase:
In our case these steps are already implemented: we have put into a position a lead architect and security is part of his job description ;-). We also scheduled a regular jour-fix with the developers to make sure that (amongst others) security relevant questions can be discussed and we have identified the security guidelines to follow. It should be noted that we didn’t create them on our own – when choosing commonly used and established concepts for software development there is a good chance that you can use publicly available policies and guidelines!
So sometimes being an early adopter of new concepts might result in additional work to create required guidelines and also in a lack of experience using them. Keep this in mind.
Security Response Process
The term security response process sounds like a lot of organizational stuff to do, especially for a startup. But the new product must be integrated into such a process later on, so there should be an established process established at an early stage already. This process should ensure at least four things:
1. establishing a secure communication channel for users/customers
2. bug/vulnerability management (reproducing, tracking, testing and so forth)
3. update deployment
4. public announcement
Assuming that there will be no vulnerabilities within a product sounds doable for security aware and experienced developers at a first glance, but looking into the past this pretty much never happens ;-). That is the reason why we have to handle and manage vulnerabilities and there must be a procedure to inform us about them. It is also providing confidence for the users, because they notice your awareness that errors might happen and you are prepared to handle and fix them.
The communication channel itself should be easy to find and easy to use, so in our case we have decided to put it onto our website (https:///www.ernw-sectools.de/support/index.html) and to give clear instructions how to proceed.
Our vulnerability management is handled by a bug tracking system and by experienced developers and security testers. The bug tracking system should integrate into your existing workflow and it is also important that every bug (real or fake one) is documented in the bug tracking system, e.g. for identifying duplicates.
Further we have to install and maintain an infrastructure to deploy future updates of our products. The design should ensure that additional servers can be added quite easily and it should mitigate well known attacks against the update process, so implement encryption, integrity protection and authentication functionality. Also keep in mind that your product should include an update mechanism itself to check, if required updates are available and have to be installed. As the ERNW SecTools will provide security tools, it is also a good idea to consider typical customer environments and design an update mechanism that can be used in high security zones, where no direct internet connection is available or even possible as exception. People like tools that don’t make problems or security issues by themselves ;-).
Finally, we recommend to handle information about vulnerabilities in a transparent manner. Your customers need this information to act accordingly and keep their environments secure. Also please don’t blame anyone for identifying & reporting bugs you have made. It is a gift that people share this information with you, so don’t forget to say “thank you” and to treat them well. People won’t complain about errors (at least mostly 😉 ), but they will complain about an unprofessional or ineffective way to handle them. You can provide all necessary information on your web site in security advisories and inform relevant vulnerability mailing lists and, evidently, your customers.
So, that’s it so far ;-), please stay tuned, there will be more posts about our approach of building a tool that tries to contributing to make the world a safer place.
Cheers
Michael