When to add security
-
This is NOT a programming question, more of an opinion question. I work with a small but awesome group of guys. We are in the habit of 'cowboy coding' and since we are small this has been working fine. I am in the process of trying to move our practices more towards some of the newer (for us) industry standards (source control, continuous integration, etc) without becoming overly bureaucratic. Now, before you get hung up on that (its just some background), the opinion question is about when you should ideally implement security (user credentials, logins, etc) in your applications. My argument is that you should implement security first thing, right along with the error logging and other good foundation type things for your app/api. I argue that you can add 'fake' credentials for testing since their main comeback is 'we can't get the alpha and beta testers in if its all locked down first.' So, they just say that and assert that security is the last thing you should implement. I am the lowest on the totem pole, so its impossible to get them to listen to me sometimes. Still, I would love to send them some information that backs up my point of view. Maybe its not that big a deal though, what is your opinion? And, can you link me to any articles that can back it up? EDIT - Added some extra spaces.
If security is a consideration for the application, it should be designed in from the start, like everything else which is a functional consideration. Hacking it on at the end never works, with security or anything else. And for any web-visible application, security must be a major consideration because people will try to hack it and, if you let them in through poor security, any data you collect might be leaked – and you might be in violation of data protection law if you were negligent in your protection, even. If your security process is so annoying that you can't get the testers to use the app with it in place, then you're doing something wrong (for example not preserving credentials throughout a session) – the security is part of the application and they should be testing that as well as everything else.
-
This is NOT a programming question, more of an opinion question. I work with a small but awesome group of guys. We are in the habit of 'cowboy coding' and since we are small this has been working fine. I am in the process of trying to move our practices more towards some of the newer (for us) industry standards (source control, continuous integration, etc) without becoming overly bureaucratic. Now, before you get hung up on that (its just some background), the opinion question is about when you should ideally implement security (user credentials, logins, etc) in your applications. My argument is that you should implement security first thing, right along with the error logging and other good foundation type things for your app/api. I argue that you can add 'fake' credentials for testing since their main comeback is 'we can't get the alpha and beta testers in if its all locked down first.' So, they just say that and assert that security is the last thing you should implement. I am the lowest on the totem pole, so its impossible to get them to listen to me sometimes. Still, I would love to send them some information that backs up my point of view. Maybe its not that big a deal though, what is your opinion? And, can you link me to any articles that can back it up? EDIT - Added some extra spaces.
Add it from the beginning. There are lots of good comments on why earlier. It sounds like you are using MS development tools. They have a whole site devoted to how to integrate it into your process (once you have a process). http://www.microsoft.com/security/sdl/default.aspx[^]
-
This is NOT a programming question, more of an opinion question. I work with a small but awesome group of guys. We are in the habit of 'cowboy coding' and since we are small this has been working fine. I am in the process of trying to move our practices more towards some of the newer (for us) industry standards (source control, continuous integration, etc) without becoming overly bureaucratic. Now, before you get hung up on that (its just some background), the opinion question is about when you should ideally implement security (user credentials, logins, etc) in your applications. My argument is that you should implement security first thing, right along with the error logging and other good foundation type things for your app/api. I argue that you can add 'fake' credentials for testing since their main comeback is 'we can't get the alpha and beta testers in if its all locked down first.' So, they just say that and assert that security is the last thing you should implement. I am the lowest on the totem pole, so its impossible to get them to listen to me sometimes. Still, I would love to send them some information that backs up my point of view. Maybe its not that big a deal though, what is your opinion? And, can you link me to any articles that can back it up? EDIT - Added some extra spaces.
I also workin a small group that used no source control until my arrival (and advocacy). Instead of pestering boss-man, I researched the major source-control packages and presented him a report explaining my recommendation. The other developers were neither enthusiastic nor opposed. My boss had me set up the server and clients, train the dev team, and administer the system. The increased quality of our team's output speaks volumes. Let your boss know why your proposal is valuable (sorry: I know I'm not really addressing your original question) and that you will be happy to become the in-house expert on security. You will code in parallel with the rest of the team, writing the security system at the beginning of each project while the rest of the team works on functionality. Learn all you can about the field (not just authentication and such, but buffer overruns and other security flaws). You will earn yourself mastery of a highly valued specialty and your boss will notice that you have the courage of your convictions. Good luck! Big opportunity for you!
-
I'm really hoping to find some blog posts or articles that outline some best practices in this area. But considering that I've been looking and not finding anything yet, I'm wondering if its time for me to start doing some writing..
You should check out securityblog.howellsonline.ca - I am working on my next series of posts when it comes to security. I ma interesting to know what the OP really meant about security. There is much much more to security then just authentication, passwords and forms. Have you considered security vulnerabilities in your code ? Have you considered doing security testing/penetration testing ? What about threat modeling ? These are all part of security that is often over looked. If security was all forms and authentication then nobody would ever be hacked.
-
If security is a consideration for the application, it should be designed in from the start, like everything else which is a functional consideration. Hacking it on at the end never works, with security or anything else. And for any web-visible application, security must be a major consideration because people will try to hack it and, if you let them in through poor security, any data you collect might be leaked – and you might be in violation of data protection law if you were negligent in your protection, even. If your security process is so annoying that you can't get the testers to use the app with it in place, then you're doing something wrong (for example not preserving credentials throughout a session) – the security is part of the application and they should be testing that as well as everything else.
I would say that if it's a requirement it must be in the foundations of the application (web or otherwise), and that means that it must be either developed or at least fully planned before doing anything else.
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
I also workin a small group that used no source control until my arrival (and advocacy). Instead of pestering boss-man, I researched the major source-control packages and presented him a report explaining my recommendation. The other developers were neither enthusiastic nor opposed. My boss had me set up the server and clients, train the dev team, and administer the system. The increased quality of our team's output speaks volumes. Let your boss know why your proposal is valuable (sorry: I know I'm not really addressing your original question) and that you will be happy to become the in-house expert on security. You will code in parallel with the rest of the team, writing the security system at the beginning of each project while the rest of the team works on functionality. Learn all you can about the field (not just authentication and such, but buffer overruns and other security flaws). You will earn yourself mastery of a highly valued specialty and your boss will notice that you have the courage of your convictions. Good luck! Big opportunity for you!
That's a really nice advice. :)
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
I say: add security last of all. Reason? I don't want you as competition, and the above is rock-solid way to fail.
Probably the most concise argument so far, and a really good one! Thank you sir.
-
I also workin a small group that used no source control until my arrival (and advocacy). Instead of pestering boss-man, I researched the major source-control packages and presented him a report explaining my recommendation. The other developers were neither enthusiastic nor opposed. My boss had me set up the server and clients, train the dev team, and administer the system. The increased quality of our team's output speaks volumes. Let your boss know why your proposal is valuable (sorry: I know I'm not really addressing your original question) and that you will be happy to become the in-house expert on security. You will code in parallel with the rest of the team, writing the security system at the beginning of each project while the rest of the team works on functionality. Learn all you can about the field (not just authentication and such, but buffer overruns and other security flaws). You will earn yourself mastery of a highly valued specialty and your boss will notice that you have the courage of your convictions. Good luck! Big opportunity for you!
Thanks for this, it is generally what I was thinking. I'm responsible for setting up a source control / continuous integration / build server because that is almost exactly what I did. I am extremely grateful to these guys for giving me an apprenticeship, and training me up in many aspects. But I feel like its time that we move into the 20th century now (and soon hopefully the 21st).. ;-)
-
I say: add security last of all. Reason? I don't want you as competition, and the above is rock-solid way to fail.
-
This is NOT a programming question, more of an opinion question. I work with a small but awesome group of guys. We are in the habit of 'cowboy coding' and since we are small this has been working fine. I am in the process of trying to move our practices more towards some of the newer (for us) industry standards (source control, continuous integration, etc) without becoming overly bureaucratic. Now, before you get hung up on that (its just some background), the opinion question is about when you should ideally implement security (user credentials, logins, etc) in your applications. My argument is that you should implement security first thing, right along with the error logging and other good foundation type things for your app/api. I argue that you can add 'fake' credentials for testing since their main comeback is 'we can't get the alpha and beta testers in if its all locked down first.' So, they just say that and assert that security is the last thing you should implement. I am the lowest on the totem pole, so its impossible to get them to listen to me sometimes. Still, I would love to send them some information that backs up my point of view. Maybe its not that big a deal though, what is your opinion? And, can you link me to any articles that can back it up? EDIT - Added some extra spaces.
It is not an opinion question, it is an architecture question. Solid security is built into an architecture, not stapled on later. Ideally you design a system to be secure from the inside out, rather than enhance a unsecure system towards security from the outside in. The challenge of developing and getting "alpha and beta testers" into a system is a nonsensical / straw man argument. You want your testers testing the system as it is intended to be used when deployed. Trying to add security (or any major / important feature) after initial testing just means you will have to go thru (at best) one more round of intensive testing. Put the security in from day one, and configure the testers properly as users; initial security concerns such as authentication and administration is then among the first tests. Further development _must_ take the security already in place into account / consideration avoiding the oops factor of forgetting to remember that security will "be added later {wink wink nudge nudge}" resulting in busted api's or hidden vulnerabilities. Security is intrinsically inconvenient (in fact security vs convenience is a classic polarity...generally the more secure something is the less convenient it is). It can also get esoteric and / or academic when taken to extremes. For most development projects its an irritating pro forma necessity rather than a "fun" thing to develop. Thus there's a lot of friction and a tendency to want to procrastinate and put it off until the last possible moment and instead focus on the exciting aspects of a project. But like any chore, putting it off until later often comes back to bite you in the end. As to your team, even if you are the junior person, if you feel strongly that security (or any consideration) should be done now rather than later put your money where your mouth is. Take charge of the situation. Make it happen. If the group does not want to tackle security (or whatever it is) and your initial foray is shot down don't get locked into a contentious back and forth with the team. Instead take the initiative and state that you will focusing on the security up front and take ownership of it. Get out in front of it. Put together a small working initial implementation, document it, and apply it. If your cowboy coding colleagues add unsecure code, check it out and make it compatible with your security system, adding features as necessary to accommodate any new security considerations you encounter. Become the "security expert" (or whatever) for
-
It is not an opinion question, it is an architecture question. Solid security is built into an architecture, not stapled on later. Ideally you design a system to be secure from the inside out, rather than enhance a unsecure system towards security from the outside in. The challenge of developing and getting "alpha and beta testers" into a system is a nonsensical / straw man argument. You want your testers testing the system as it is intended to be used when deployed. Trying to add security (or any major / important feature) after initial testing just means you will have to go thru (at best) one more round of intensive testing. Put the security in from day one, and configure the testers properly as users; initial security concerns such as authentication and administration is then among the first tests. Further development _must_ take the security already in place into account / consideration avoiding the oops factor of forgetting to remember that security will "be added later {wink wink nudge nudge}" resulting in busted api's or hidden vulnerabilities. Security is intrinsically inconvenient (in fact security vs convenience is a classic polarity...generally the more secure something is the less convenient it is). It can also get esoteric and / or academic when taken to extremes. For most development projects its an irritating pro forma necessity rather than a "fun" thing to develop. Thus there's a lot of friction and a tendency to want to procrastinate and put it off until the last possible moment and instead focus on the exciting aspects of a project. But like any chore, putting it off until later often comes back to bite you in the end. As to your team, even if you are the junior person, if you feel strongly that security (or any consideration) should be done now rather than later put your money where your mouth is. Take charge of the situation. Make it happen. If the group does not want to tackle security (or whatever it is) and your initial foray is shot down don't get locked into a contentious back and forth with the team. Instead take the initiative and state that you will focusing on the security up front and take ownership of it. Get out in front of it. Put together a small working initial implementation, document it, and apply it. If your cowboy coding colleagues add unsecure code, check it out and make it compatible with your security system, adding features as necessary to accommodate any new security considerations you encounter. Become the "security expert" (or whatever) for
I can't thank you enough for such a well-thought and well-spoken reply. I am hoping that they will be willing to focus on architecture in the future. If they are not, I will be looking for a programming job where there is much more of an emphasis on architecture, and much less focus on egocentrism.
-
This is NOT a programming question, more of an opinion question. I work with a small but awesome group of guys. We are in the habit of 'cowboy coding' and since we are small this has been working fine. I am in the process of trying to move our practices more towards some of the newer (for us) industry standards (source control, continuous integration, etc) without becoming overly bureaucratic. Now, before you get hung up on that (its just some background), the opinion question is about when you should ideally implement security (user credentials, logins, etc) in your applications. My argument is that you should implement security first thing, right along with the error logging and other good foundation type things for your app/api. I argue that you can add 'fake' credentials for testing since their main comeback is 'we can't get the alpha and beta testers in if its all locked down first.' So, they just say that and assert that security is the last thing you should implement. I am the lowest on the totem pole, so its impossible to get them to listen to me sometimes. Still, I would love to send them some information that backs up my point of view. Maybe its not that big a deal though, what is your opinion? And, can you link me to any articles that can back it up? EDIT - Added some extra spaces.
Vaughn Bigham wrote:
'we can't get the alpha and beta testers in if its all locked down first.'
If the security isn't in the system by the time alpha or beta testing is being conducted, then that testing is hardly valid, is it? :doh: Assuming that your quote is an accurate representation of your colleagues concerns, the following thoughts may be helpful... Unless you've also got gamma, delta and a whole Greek alphabet of testing stages, then you and your team likely share (an approximation of) the following sense of what alpha and beta testing are about: * beta is it really should be ready for release, but we know there are (likely to be) bugs and/or usability problems that real use will shake out, and * alpha is it's basically done; we know it's real shaky and there are some features we're not sure whether to polish up or kill, but it's enough like the real deal that real-world evaluation will be valuable Going by those definitions (or even something close to them), without a functioning security infrastructure the product is just not complete and you're not ready for alpha, let alone beta, testing. So the rest of the team (if they even come close to those definitions) need to rethink their justification for holding off on security. Going back to the quote:
Vaughn Bigham wrote:
'we can't get the alpha and beta testers in if its all locked down first.'
A finished, released, product needs to be able to add the first user - so the experience of "it's all locked down" can never be a condition that applies to a finished product. If security is present and you can't add testers to the system, perhaps you need to ask "what is the intended means of adding the first administrative user in the finished product?" and then redefine the scope of "security" so that adding the first user to the system is a security issue, not a content issue. Once the ability to add the first admin user is defined to be a security behaviour, not a 'content' behaviour, then the first round of (unit) testing would be to verify that the security architecture is valid and complete ... and all subsequent rounds of unit, integration and alpha and beta testing build upon it (instead of requiring it to be delayed until the last minute).