4 ms·

Most of the companies I've worked with had absolutely no security considerations. They've expected it to work out of the box, with, say, RoR and Apache. Needle

Most of the companies I've worked with had absolutely no security considerations. They've expected it to work out of the box, with, say, RoR and Apache. Needless to say, it didn't work. Also to be noted, there were no noticed service disruptions caused by any 3rd party. We were small fish. Which leads me to the following - security is a scaling issue. Sure, your prototype even though ready for going live, need not really be secured in most use cases. But once you start to grow, especially rapidly, things can easily spin out of control. You need some time to get a proper certificate, your database looks like development version on your local machine, you've handed out few ssh keys via e-mail and it's on few USB sticks lying around for root admin on deployment server (since someone has to take care of it while you sleep), you login on public networks to get company resources you need asap, etc. What I'm really interested is - how does one scale it? What are the priorities?

danielh 14y ago
"Security is a scaling issue" is a dangerous assumption to make. While a small site might not be targeted directly, you might still get hit by an automatic attack if you use any off the shelf software. It's not fun when Google marks your site as harmful because your OpenX-Ad-Server suddenly serves malicious ads.
- dsirijus 14y ago
  Ok, so then first priority is to get secured from "automatic attacks on off-the-shelf software".
corford 14y ago
I'm not sure if it's unconventional or not but I'm a big believer in doing as much as possible correctly from the start i.e. having a dev -> staging -> production setup, clearly documenting everything, devising and sticking to a set of procedures and guidelines (for deployment, security, coding style etc.), not taking "bah it will work for now" shortcuts with fundamental design choices, using a proper bug tracker. And so on. This adds a bit more up front planning pain to any project and also slightly slows down the daily dev routine BUT it pays dividends further down the line when you suddenly start getting noticed and your usage figures begin multiplying every 24 hours. In that situation there isn't time to re-work production dbms schemas, change the app code to deal with bcrypt'd password hashes, change the deployment script to make it more secure so you don't end up accidentally dropping a dev version of the site on your public servers etc. etc. Better to pay the up front cost of getting the basics correct at the beginning of the project rather than dealing with an un-contained explosion later on just as you hit the limelight. Also, the up-front pain of doing this diminishes with every additional project you do as a lot of the concepts, approaches and procedures are re-usable.
- dsirijus 14y ago
  That may work for clearly defined product and very loose development timeline, but what when you need to make a social network based app with deadline 3 days from order, which may well be spiraling virally the day of the launch? Your security is then clearly post scriptum. Disclaiming though, I clearly state to such clients that security will not be really up to challenge on those timelines. They usually don't care, even to a point that I don't really bother anyone with it, since I get blank stares when I discuss security with them.
  - corford 14y ago
    I suppose some apps will be different but a lot share the same basic security concerns. So just figure it out once and apply the best practices you've come up with to all future projects as a matter of course. It takes time to initially figure it all out but after that there's not too much extra effort required to code securely VS just smashing stuff together to meet a deadline.
  - route66 14y ago
    > I get blank stares when I discuss security with them. I can assure you that the blank stares go away completely when there is a breach. You will probably learn by then that your customers just expect you to handle it professionally. They might not be able to think beyond their deadline and their first business goal, but leaking passwords or losing user data will be your fault eventually. I will not pretend that all my past work is bulletproof, but it should be not so difficult to make sure your tools and code handle all incoming data like hot grenades. You might skip some big-upfront-user-import in the beginning as you control the data chain, but $_POST or params[:model] or what else is flying in your face should be met with a standard treatment. Think of it this way: right now you do not want to have your CV say "2012: developed user login module for LinkedIn. Finished within the deadline"
- dhyasama 14y ago
  The idea of doing a little work up front to save yourself trouble later on is good in theory, but the reality of the early stage startup world is if you don't move fast enough you won't be around to experience that trouble later on. Sometimes it makes sense, sometimes it doesn't. The trick is to find a happy medium that works for your situation. Totally agree on that last part. The pain rapidly diminishes as you come up with simpler ways to do things in a reusable way. Also, the tools to do it are getting better and better as more and more people are feeling the same pain.

danielh 14y ago

"Security is a scaling issue" is a dangerous assumption to make. While a small site might not be targeted directly, you might still get hit by an automatic attack if you use any off the shelf software. It's not fun when Google marks your site as harmful because your OpenX-Ad-Server suddenly serves malicious ads.

dsirijus 14y ago
Ok, so then first priority is to get secured from "automatic attacks on off-the-shelf software".

corford 14y ago

I'm not sure if it's unconventional or not but I'm a big believer in doing as much as possible correctly from the start i.e. having a dev -> staging -> production setup, clearly documenting everything, devising and sticking to a set of procedures and guidelines (for deployment, security, coding style etc.), not taking "bah it will work for now" shortcuts with fundamental design choices, using a proper bug tracker. And so on. This adds a bit more up front planning pain to any project and also slightly slows down the daily dev routine BUT it pays dividends further down the line when you suddenly start getting noticed and your usage figures begin multiplying every 24 hours. In that situation there isn't time to re-work production dbms schemas, change the app code to deal with bcrypt'd password hashes, change the deployment script to make it more secure so you don't end up accidentally dropping a dev version of the site on your public servers etc. etc. Better to pay the up front cost of getting the basics correct at the beginning of the project rather than dealing with an un-contained explosion later on just as you hit the limelight. Also, the up-front pain of doing this diminishes with every additional project you do as a lot of the concepts, approaches and procedures are re-usable.

dsirijus 14y ago
That may work for clearly defined product and very loose development timeline, but what when you need to make a social network based app with deadline 3 days from order, which may well be spiraling virally the day of the launch? Your security is then clearly post scriptum. Disclaiming though, I clearly state to such clients that security will not be really up to challenge on those timelines. They usually don't care, even to a point that I don't really bother anyone with it, since I get blank stares when I discuss security with them.
- corford 14y ago
  I suppose some apps will be different but a lot share the same basic security concerns. So just figure it out once and apply the best practices you've come up with to all future projects as a matter of course. It takes time to initially figure it all out but after that there's not too much extra effort required to code securely VS just smashing stuff together to meet a deadline.
- route66 14y ago
  > I get blank stares when I discuss security with them. I can assure you that the blank stares go away completely when there is a breach. You will probably learn by then that your customers just expect you to handle it professionally. They might not be able to think beyond their deadline and their first business goal, but leaking passwords or losing user data will be your fault eventually. I will not pretend that all my past work is bulletproof, but it should be not so difficult to make sure your tools and code handle all incoming data like hot grenades. You might skip some big-upfront-user-import in the beginning as you control the data chain, but $_POST or params[:model] or what else is flying in your face should be met with a standard treatment. Think of it this way: right now you do not want to have your CV say "2012: developed user login module for LinkedIn. Finished within the deadline"
dhyasama 14y ago
The idea of doing a little work up front to save yourself trouble later on is good in theory, but the reality of the early stage startup world is if you don't move fast enough you won't be around to experience that trouble later on. Sometimes it makes sense, sometimes it doesn't. The trick is to find a happy medium that works for your situation. Totally agree on that last part. The pain rapidly diminishes as you come up with simpler ways to do things in a reusable way. Also, the tools to do it are getting better and better as more and more people are feeling the same pain.