The problem

Security for a web startup that handles sensitive data must be a concern from day one.  To think you can deal with security by simply following developing best practices is an utopia. You have to carefully plan and continuously run security tests. But this is not enough: it is the vulnerability detection and analysis methodology that determines the test effectiveness.

Our solution

At Le Cicogne we dealt with the above issue by hiring a consultant who is carrying out a set of well documented penetration tests whose purpose is:
  • Early system vulnerabilities detection;
  • Simulations of a vast array of attacks and site intrusions
This approach has allowed Le Cicogne to reduce overall costs because we have been able to discover design weaknesses early on therefore minimizing the likelihood of costlier later stage architectural reviews. Another very important step is the hosting package: a higher level of security is achieved by managing a dedicated physical server or, at least, a dedicated Virtual Private Server (VPS). This option costs a bit more, but it provides a level of confidence about overall complete control of our environment. A dedicated server and tester should operate open methodologies, like OSSTMM and OWASP, to carry out the planned tests. Open technologies may imply more time, but it results in a wider test coverage. The tools used at Le Cicogne are:
  • nmap: active services discovery and identification;
  • OpenVAS 5: known vulnerabilities identification and classification;
  • WebScarab: web application testing; 
  • BurpSuite: web application analysis and testing;
  • W3af: known web application vulnerabilities identification;
  • Metasploit Framework: vulnerabilities exploitation and post-exploitation
After having carefully planned the activities, tests have been run both on the host and on the web app. After having identified and classified all the detected vulnerabilities , an analysis to take the false positives out has been carried out. An excerpt of the before and after test situation, both on the server and web app, is hereinafter provided: Host server  vulnerabilities: The identified host server vulnerabilities have been easily fixed (most of them by simply updating services running on the server). Web Application vulnerabilities: In this case, detected vulnerabilities were far more critical, because they would have allowed an attack by using malicious code in a specially created URL (cross site scripting) or to access non public reserved folders (directory listings). Other detected vulnerabilities were less critical, nonetheless they would have provided hack info to a potential attacker. One should always keep in mind that vulnerabilities should also be analysed as a whole in order to better understand how they may work together. Finally, in spite of any attempt to minimize the likelihood of security issues, “shit happens” so it is imperative to have a disaster recovery plan whose very core is an effective backup policy. At Le Cicogne, we have a daily backup procedures which take into account any aspect of our system (web app, system logs, service configuration on the server) and store everything on a different cloud from the one hosting the web app. In order to check the backup procedures effectiveness, the system is routinely re-started from the backup files.  


The need to rapidly reach the market might lead a web startup to underestimate the importance of security in designing the software architecture and in the day-by-day system test. This often results in a disaster: if the web app is hacked, the startup might suffer in terms of loss of time, users, clients, money and, ever more important, reputation. Such a risk cannot even be contemplated, as any savvy investor would be scared to put his money in a team that is not managing the most important asset a startup may have: its credibility.