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.
I always start with a bare-bones framework that has all of that (and more) built in so I can concentrate on the functionality that the users want, not on stuff that has to be there regardless of what they want. Saves a lot of time which you can still estimate for: gives you a butt load of extra contingency.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
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.
Depends on what your platform is. Mine is ASP.NET MVC3/4, where switching security off for testers is just one word in my web.config file. I normally have it off for me as well. For that matter, even your home rolled security should be configurable like that.
-
Depends on what your platform is. Mine is ASP.NET MVC3/4, where switching security off for testers is just one word in my web.config file. I normally have it off for me as well. For that matter, even your home rolled security should be configurable like that.
Good point, but in order for it to be 'configurable like that' it would have to be implemented first right?
-
Good point, but in order for it to be 'configurable like that' it would have to be implemented first right?
Yes, but what I meant was that your colleagues have no argument that implementing it first will interfere with any testing.
-
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.
-
Quote:
So, they just say that and assert that security is the last thing you should implement.
That's against all the wisdom in the security world... I'll try to find some useful links to convince either you or your colleagues :)
best regards.
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..
-
Yes, but what I meant was that your colleagues have no argument that implementing it first will interfere with any testing.
Oh yes, that is really too good an argument to pass up. Thanks!
-
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 must go in right from the start, you need a framework that handles navigation security and content security (I talk from a LOB application POV). Put it in right away, immediately turn it off (GetSecurity => return true;). Then do the development and leave it off till the 2nd round of UAT. The other devs are just worried they are going to have to log in every time they run the app during development.
Never underestimate the power of human stupidity RAH
-
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..
Well, I think the motivation is following. If Security is relevant for your application than you better start thinking about how and where to implement it from start (because for example it can affect other considerations of the system architecture, or it maybe difficult to integrate it in later stages). These are the reasons in my opinion, here are few articles that mention that security as an afterthought is a bad idea, although I guess they don't say anything specific. http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/3/html/Introduction_to_System_Administration/s1-philosophy-security.html[^] http://www.netlib.com/blog/Data-Security-Technology/mobile-data-security-should-not-be-an-afterthought.asp[^] Hope this helps. (But believe me security as an afterthought is really considered a bad idea in security world as I said). ps. Finally, I think for your application you should define what your security requirements are and then start thinking what actions to take
best regards.
-
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:
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.
As stated that is utter nonsense. If your alpha/beta testers participate because they get something from the process. Perhaps just self satisfaction from seeing it first or maybe a new feature. But that has to do with the functionality of the product. So if the product doesn't have enough to entice them them then how is anyone going to sell the final release?
Vaughn Bigham wrote:
what is your opinion?
It depends on what you are selling and what you are protecting (or think you are protecting.) But a simple analogy make it clear - if your bank put up version 2 of their website would it be acceptable that someone could access your account without logging in?
-
Vaughn Bigham wrote:
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.
As stated that is utter nonsense. If your alpha/beta testers participate because they get something from the process. Perhaps just self satisfaction from seeing it first or maybe a new feature. But that has to do with the functionality of the product. So if the product doesn't have enough to entice them them then how is anyone going to sell the final release?
Vaughn Bigham wrote:
what is your opinion?
It depends on what you are selling and what you are protecting (or think you are protecting.) But a simple analogy make it clear - if your bank put up version 2 of their website would it be acceptable that someone could access your account without logging in?
I love your simple analogy! I hope you don't mind if I re-use it in the future ;-)
-
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.
In my experience, cowboy coders rarely listen and will seldom change their habits - no matter how good the argument: following process takes the 'fun' out of coding and there will be a lot of resistance. The only times they do tend to listen is when (1) disaster strikes and they have to explain to higher-ups why something was/was not done or (2) a more senior party (given rank) moves in and "assists" them in changing their habits. Otherwise, frankly, you're fighting a losing battle. Of course, this doesn't help with your argument - disaster won't just strike after deployment due to security being added last. Reading from your list of processes still to be implemented (e.g. you don't have source control yet; seriously!?) you seem to have other urgencies as well! But for the sake of helping your argument... (1) are there contractual risks if someone should gain access to information withing the system that they're not supposed to see? (i.e. what is your company's liability towards leaks due to inadequate security) (2) is security not something that they feel needs to be beta-tested as well? (3) [also countering their argument] unless you have an "all or nothing" model (I assume your needs may be slightly more complex), adding security after earlier rounds of testing would invalidate earlier tests and you are likely to see instances where undiscovered bugs will prevent the use of parts of the live system. Think about it: modules already tested won't get tested in as much detail again.
-
In my experience, cowboy coders rarely listen and will seldom change their habits - no matter how good the argument: following process takes the 'fun' out of coding and there will be a lot of resistance. The only times they do tend to listen is when (1) disaster strikes and they have to explain to higher-ups why something was/was not done or (2) a more senior party (given rank) moves in and "assists" them in changing their habits. Otherwise, frankly, you're fighting a losing battle. Of course, this doesn't help with your argument - disaster won't just strike after deployment due to security being added last. Reading from your list of processes still to be implemented (e.g. you don't have source control yet; seriously!?) you seem to have other urgencies as well! But for the sake of helping your argument... (1) are there contractual risks if someone should gain access to information withing the system that they're not supposed to see? (i.e. what is your company's liability towards leaks due to inadequate security) (2) is security not something that they feel needs to be beta-tested as well? (3) [also countering their argument] unless you have an "all or nothing" model (I assume your needs may be slightly more complex), adding security after earlier rounds of testing would invalidate earlier tests and you are likely to see instances where undiscovered bugs will prevent the use of parts of the live system. Think about it: modules already tested won't get tested in as much detail again.
This is exactly the kind of frank discussion that I was hoping for, thank you. I guess it really sounds bad to say that there is NO source control, since we do have source control (visual source safe). The problem to me is that its not required (not to mention reliability problems with that particular brand of source control). Since it is not required, it is not used effectively (we with-hold projects, or check in infrequently), and to me that might as well be zero source control. You would be accurate in saying that I have 'other urgencies as well' but I don't want to go into long detail about all of that since I am confident that these other problems will be fixed, and soon. This security argument though, it just really baffles me.
-
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 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.
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...