Re: [SC-L] Mobile phone OS security changing?
Michael Silk wrote: > The last thing I want is my mobile phone updating itself. I imagine > that sort of operation would take up battery power, and possibly cause > other interruptions ... (can you be on a call and have it update > itself?) A larger issue for me (though I'm straying a bit from SC) is that phone vendors tend to show a strong desire for lock-in, and I would fear auto-update mostly because of loss of features, DRM, etc... Ryan [Ed. Let's either stay on topic or let this thread die, please. KRvW]
Re: [SC-L] Application Insecurity --- Who is at Fault?
On Apr 7, 2005 12:43 PM, Blue Boar <[EMAIL PROTECTED]> wrote: > Michael Silk wrote: > > See, you are considering 'security' as something extra again. This is > > not right. > > It is extra. It's extra time and effort. And extra testing. And extra > backtracking and schedule slipping when you realize you blew something. > All before it hits beta. All of this is part of _programming_ though. To me it should be on the same level as, say, using an 'Array' at an appropriate point in a program. You won't say to management: "Oh, I didn't use an array there because you didn't ask me to.". It's ridiculous to even consider. And so it should be with so-called 'Security' that is added to applications. Consider the bridge example brought up earlier. If your bridge builder finished the job but said: "ohh, the bridge isn't secure though. If someone tries to push it at a certain angle, it will fall". You would be panic stricken. Fear would overcome you, and you might either run for the hills, or attempt to strangle the builder... either way, you have a right to be incredibly upset by the lack of 'security' in your bridge. You WONT (as is the case now) sit back and go: "Oh well, fair enough. I didn't ask you to implement that, I just said 'build a bridge'. Next time i'll ask. Or make sure the public specifically requests resistence to that angle of pushing". Hopefully my point is obvious... -- Michael > Any solution that ends up with us having "secure" software will > neccessarily need to address this step as well as all others. The > "right" answer just might end up being "suck it up, and take the > resource hit." It might be "switch to the language that lends itself to > you coding securly at 75% the productivity rate of sloppy coding." I > don't know enough about the languages involved to participate in that > debate. > > Strangely enough, for the last year and a half or so, I've been sitting > here being QA at a security product company. Doing software right takes > extra resources. I are one. > >Ryan >
Re: [SC-L] Application Insecurity --- Who is at Fault?
Michael Silk wrote: > See, you are considering 'security' as something extra again. This is > not right. It is extra. It's extra time and effort. And extra testing. And extra backtracking and schedule slipping when you realize you blew something. All before it hits beta. Any solution that ends up with us having "secure" software will neccessarily need to address this step as well as all others. The "right" answer just might end up being "suck it up, and take the resource hit." It might be "switch to the language that lends itself to you coding securly at 75% the productivity rate of sloppy coding." I don't know enough about the languages involved to participate in that debate. Strangely enough, for the last year and a half or so, I've been sitting here being QA at a security product company. Doing software right takes extra resources. I are one. Ryan
Re: [SC-L] Application Insecurity --- Who is at Fault?
Michael Silk wrote: Consider the bridge example brought up earlier. If your bridge builder finished the job but said: "ohh, the bridge isn't secure though. If someone tries to push it at a certain angle, it will fall". All bridges have certain limits. There is difference between a footbridge and bridge that can be driven over with a tank. The difference is also reflected in cost. You are advocating always building "tank" bridge. Which is understandable attitude - this way you are mostly safe. However, in some cases it is *economically feasible* to just build a simpler bridge and accept the fact that it will break under some conditions. Ultimately it is a matter of economics. Sometimes releasing something earlier is worth more than the cost of later patches. And managers/customers are aware of it. -- Margus
Re: [SC-L] Application Insecurity --- Who is at Fault?
Michael Silk wrote: [...] Consider the bridge example brought up earlier. If your bridge builder finished the job but said: "ohh, the bridge isn't secure though. If someone tries to push it at a certain angle, it will fall". You would be panic stricken. Fear would overcome you, and you might either run for the hills, or attempt to strangle the builder... either way, you have a right to be incredibly upset by the lack of 'security' in your bridge. You WONT (as is the case now) sit back and go: "Oh well, fair enough. I didn't ask you to implement that, I just said 'build a bridge'. Next time i'll ask. Or make sure the public specifically requests resistence to that angle of pushing". Hopefully my point is obvious... [...] Actually, it's obvious - but I still can't agree with it. Using the bridge example, it's fairly trivial for the ironworker to realize there should be guesset plate where one wasn't called for. It's a small piece, fairly quickly and easily fabricated and attached - so the ironworker puts it in. No, it wasn't part of the specification - but the ironworker has built enough bridges and can explain away the extra half-day and slight cost it took to add the appropriate guessets. On the other hand, the ironworker has worked on enough bridges to realize that will lead to a functional, but flawed bridge. It won't fall down, but it won't be as robust as a bridge should be. The bridge was specified to support 10 tons. Five years from now, the road traffic will have 15 ton trucks and the bridge may fail. What you're proposing is that the ironworker should reengineer the bridge in-situ (as if he even has the authority!), causing weeks of delay, cost overruns, and possibly lead to his employer never getting a bridge contract again. Somehow, that just doesn't hold water. Kind Regards, -dsp
Re: [SC-L] Application Insecurity --- Who is at Fault?
Dave, > What you're proposing is that the ironworker should reengineer the > bridge in-situ (as if he even has the authority!), causing weeks of > delay, cost overruns, and possibly lead to his employer never getting a > bridge contract again. That's not at all what I'm suggesting... guess my point wasn't so obvious :) I'm not saying the programmer should totally redesign the application if it's not secure. I am saying that they _SHOULD_ do the simple, 'trivial' things within the context of their current job. Validating input, handling errors properly, ensuring ownership of various id's, etc. All of these things fall in this category. Yet these days, when programmers actually _DO_ do these things, they call these things 'security features' and themselves 'secure programmers' (or whatever). And that's what I think is ridiculous. Other things, like designing a secure protocol/management of your encryption system can be though of as 'something extra' but these types of problems aren't the _MAJOR_ problems (they are big problems, however) that we deal with. There are, of course, design concepts that shouldn't really be billed as 'extra' either [like appropriate user management/access systems, etc]. And back to the main point of this discussion, is that lack of these things in application shouldn't be blamed on consumers (or even management) for not asking. These things should be assumed... -- Michael > > Somehow, that just doesn't hold water. > Kind Regards, > -dsp
Re: [SC-L] Application Insecurity --- Who is at Fault?
Blue Boar <[EMAIL PROTECTED]> wrote: > [Security] is extra. It's extra time and effort. And extra > testing. And extra backtracking and schedule slipping when > you realize you blew something. All before it hits beta. ...if you're lucky. (Or if you're doing development right, but IME that's damn rare too.) -Dave
Re: [SC-L] Application Insecurity --- Who is at Fault?
At 7:44 AM -0400 4/7/05, Dave Paris wrote: > What you're proposing is that the ironworker should reengineer the > bridge in-situ (as if he even has the authority!) or the expertise. -- Larry Kilgallen
[SC-L] (fwd) New mailing list announced -- MobileBugtraq
FYI, this seems kind of topical -- a new bugtraq list specifically for discussing vulnerabilities in mobile terminals. See message below, forwarded from the Full-Disclosure list. Cheers, Ken van Wyk -- KRvW Associates, LLC http://www.KRvW.com == snip === [Full-disclosure] MobileBugtraq Mailing List From: "Franckl - MobileBugtraq" <[EMAIL PROTECTED]> (MobileBugtraq) To: full-disclosure@lists.grok.org.uk Date: Today 07:25:14 MobileBugtraq is a new discussion mailing list about security of mobile terminals systems including all sorts of platforms. Topics of discussion might be related to hacking, protecting against break-ins, system bugs and exploits, etc. The postings in this list may be written either in English. To subscribe to the MobileBugtraq list, one should send an e-mail to: [EMAIL PROTECTED] (just including in the main message body (no subject is needed): subscription) After having subscribed, one might send messages to the MobileBugtraq List at the address: [EMAIL PROTECTED] See you soon to talk about mobile security and share your knowledge. Regards, Franckl - http://www.mobilebugtraq.com - Symbian, 3G, Drm, Bluetooth, Java, Windows Mobile, and a lot of fun.
