Re: [funsec] More bad news for risk management
What you describe is not risk management, but the Externality problem. The solution is to have the banks bear the costs caused by breaches, then they will adopt the correct risk calculation. > -Original Message- > From: Jeffrey Walton [mailto:noloa...@gmail.com] > Sent: Sunday, August 19, 2012 9:35 AM > To: valdis.kletni...@vt.edu > Cc: Tomas L. Byrnes; funsec@linuxbox.org; infose...@yahoogroups.com > Subject: Re: [funsec] More bad news for risk management > > Hi Valdis, > > I understand you and Tom. > > On Sun, Aug 19, 2012 at 11:29 AM, wrote: > > On Sat, 18 Aug 2012 12:17:40 -0400, Jeffrey Walton said: > >> On Fri, Aug 17, 2012 at 12:43 AM, Tomas L. Byrnes > wrote: > >> > Ignoring risk is a perfectly valid way of managing it, if the > >> > return of putting the resources into the risky endeavor exceed the > >> > costs of putting them into managing the risk. > >> I know its common practice, but I respectfully disagree. Its been my > >> experience that most problems can be solved correctly from an > >> engineering standpoint. > > > > Reading comprehension fail. Tomas's point is that yes, often there > > *is* an engineering solution. But if you invest $250K in an > > engineering solution for a problem that only risks $100K loss, you're > > being stupid. At that point, just making a note that you have a > > potential $100K liability and getting on with your life *is* the proper way > > to > manage that risk. > I agree that's the way its done in practice. > > Here's my "devil's advocate" view (from experience). A software > development team drives requirements and design for an account > management package, and comes up with a crummy, insecure solution. > (Developer driven software is some of the worst software I have ever seen). > > Now, say a bank uses the solution. They send it through a security review > and find its full of holes and should not be used. The bank will say: on one > hand, it will cost us 10's of thousands of dollars and months of time to > design > and implement this server software correctly. In the months that pass, we > will loose 100's of thaousands per month because we lack the feature > (customers will go to another bank). However, it will cost us 50 cents per > customer to send out the data breach letter if something goes wrong. > > Later, the server software is breached and 1,000,000 customers have their > names, addresses, and social security numbers stolen. It costs the bank > 500,000 to mail letters. Meanwhile, 1,000,000 people could endure a lifetime > of msery because it was cheaper for the bank to allow the breach to happen. > > I work in this area (security architectures and reviews), and I'm the guy who > points out the defects in the systems. When I fail a system, it goes on to > risk > acceptance. > > As I said, risk acceptance is a pervision to justify use of unfit and > defective > systems. It only benefits the folks who want to to use the system, often in > the persuit of money; and sacrifices the folks who are part of a system. > Often, the unsuspecting souls don't realize they are even part of a defective > system. > > Jeff ___ Fun and Misc security discussion for OT posts. https://linuxbox.org/cgi-bin/mailman/listinfo/funsec Note: funsec is a public and open mailing list.
Re: [funsec] More bad news for risk management
On Sun, Aug 19, 2012 at 12:25 PM, Stephanie Daugherty wrote: > > >> >> Reading comprehension fail. Tomas's point is that yes, often there *is* >> an >> engineering solution. But if you invest $250K in an engineering solution >> for a >> problem that only risks $100K loss, you're being stupid. At that point, >> just >> making a note that you have a potential $100K liability and getting on >> with >> your life *is* the proper way to manage that risk. >> >> (Of course, if the engineering solution only costs $10K, then yes it >> should be >> pursued. But only when it costs less than just ignoring the risk). >> > > This is still oversimplification though. The remaining factor is what the > likelihood of that risk actually happening is. A $10K solution to a $200K > problem that will "probably never happen" is still often seen as money being > thrown away. > > > > IMHO, Some of the most effective cyber-security regulation efforts basically > fix this through little more than amplifying the cost of failure to where it > can't be ignored - case in point, HIPPA and PCI. Both are designed to > potentially be open ended money pits for companies that get breached - > hopefully restoring fear of risk to where it needs to be, while trying to > spell out a set of good practices that if followed, might let companies off > the hook for the sort of failures they can't reasonably defend against. > Allowing corporations to "do nothing" has not worked in the past. Most of these corporations and businesses cannot be trusted to do "the right thing." Its unfortunate that VISA and Mastercard are writing the rules, since the rules will benefit them and not consumers and users. Perhaps I should not complain since consumers and users are enjoying a small benefit (but they also pay the extortion-like rates when losses are passed down). Consumers and users need legislation with teeth, and not something watered down after corporate america purchases congressman and representatives to reduce the effectiveness of legislation. http://www.mail-archive.com/sc-l@securecoding.org/msg03619.html. Jeff ___ Fun and Misc security discussion for OT posts. https://linuxbox.org/cgi-bin/mailman/listinfo/funsec Note: funsec is a public and open mailing list.
Re: [funsec] Gmail Forwarding Logins to YouTube?
On Sat, Aug 18, 2012 at 10:22 PM, Nick FitzGerald wrote: > Jeff wrote: > >> It appears GMail is forwarding logins to YouTube. ... > > That's news? > > And it's not so much forwarding as SSO. > >> > >> ... and I would like to supress forwarding my credentials >> (or obtaining tokens through frameworks such as OAuth). >> >> Is it possible to stop the sharing and leakage? > > Simple -- delete your Google account(s) and don't use any of their > services that depend on Google account logins. I think you are right (i've been in denial for far too long). Arg. ___ Fun and Misc security discussion for OT posts. https://linuxbox.org/cgi-bin/mailman/listinfo/funsec Note: funsec is a public and open mailing list.
Re: [funsec] More bad news for risk management
Hi Valdis, I understand you and Tom. On Sun, Aug 19, 2012 at 11:29 AM, wrote: > On Sat, 18 Aug 2012 12:17:40 -0400, Jeffrey Walton said: >> On Fri, Aug 17, 2012 at 12:43 AM, Tomas L. Byrnes wrote: >> > Ignoring risk is a perfectly valid way of managing it, if the return of >> > putting the resources into the risky endeavor exceed the costs of >> > putting them into managing the risk. >> I know its common practice, but I respectfully disagree. Its been my >> experience that most problems can be solved correctly from an >> engineering standpoint. > > Reading comprehension fail. Tomas's point is that yes, often there *is* an > engineering solution. But if you invest $250K in an engineering solution for > a > problem that only risks $100K loss, you're being stupid. At that point, just > making a note that you have a potential $100K liability and getting on with > your life *is* the proper way to manage that risk. I agree that's the way its done in practice. Here's my "devil's advocate" view (from experience). A software development team drives requirements and design for an account management package, and comes up with a crummy, insecure solution. (Developer driven software is some of the worst software I have ever seen). Now, say a bank uses the solution. They send it through a security review and find its full of holes and should not be used. The bank will say: on one hand, it will cost us 10's of thousands of dollars and months of time to design and implement this server software correctly. In the months that pass, we will loose 100's of thaousands per month because we lack the feature (customers will go to another bank). However, it will cost us 50 cents per customer to send out the data breach letter if something goes wrong. Later, the server software is breached and 1,000,000 customers have their names, addresses, and social security numbers stolen. It costs the bank 500,000 to mail letters. Meanwhile, 1,000,000 people could endure a lifetime of msery because it was cheaper for the bank to allow the breach to happen. I work in this area (security architectures and reviews), and I'm the guy who points out the defects in the systems. When I fail a system, it goes on to risk acceptance. As I said, risk acceptance is a pervision to justify use of unfit and defective systems. It only benefits the folks who want to to use the system, often in the persuit of money; and sacrifices the folks who are part of a system. Often, the unsuspecting souls don't realize they are even part of a defective system. Jeff ___ Fun and Misc security discussion for OT posts. https://linuxbox.org/cgi-bin/mailman/listinfo/funsec Note: funsec is a public and open mailing list.
Re: [funsec] More bad news for risk management
> Reading comprehension fail. Tomas's point is that yes, often there *is* an > engineering solution. But if you invest $250K in an engineering solution > for a > problem that only risks $100K loss, you're being stupid. At that point, > just > making a note that you have a potential $100K liability and getting on with > your life *is* the proper way to manage that risk. > > (Of course, if the engineering solution only costs $10K, then yes it > should be > pursued. But only when it costs less than just ignoring the risk). > > This is still oversimplification though. The remaining factor is what the likelihood of that risk actually happening is. A $10K solution to a $200K problem that will "probably never happen" is still often seen as money being thrown away. Even If a serious risk analysis and quantification actually takes place (1 in 1 chance per year over 20 year service lifetime, blah blah blah) , it may still be seen as not worth fixing. Nevermind the fact that the risks evolve through legislation, an a 1 in 1 security event before everything was connected to the internet is now closer to a 1 in 100 or even 1 in 10. IMHO, Some of the most effective cyber-security regulation efforts basically fix this through little more than amplifying the cost of failure to where it can't be ignored - case in point, HIPPA and PCI. Both are designed to potentially be open ended money pits for companies that get breached - hopefully restoring fear of risk to where it needs to be, while trying to spell out a set of good practices that if followed, might let companies off the hook for the sort of failures they can't reasonably defend against. These aren't perfect rules, but they are a good general direction as far as making companies take risks seriously. ___ Fun and Misc security discussion for OT posts. https://linuxbox.org/cgi-bin/mailman/listinfo/funsec Note: funsec is a public and open mailing list.
Re: [funsec] More bad news for risk management
On Sat, 18 Aug 2012 12:17:40 -0400, Jeffrey Walton said: > On Fri, Aug 17, 2012 at 12:43 AM, Tomas L. Byrnes wrote: > > Ignoring risk is a perfectly valid way of managing it, if the return of > > putting the resources into the risky endeavor exceed the costs of > > putting them into managing the risk. > I know its common practice, but I respectfully disagree. Its been my > experience that most problems can be solved correctly from an > engineering standpoint. Reading comprehension fail. Tomas's point is that yes, often there *is* an engineering solution. But if you invest $250K in an engineering solution for a problem that only risks $100K loss, you're being stupid. At that point, just making a note that you have a potential $100K liability and getting on with your life *is* the proper way to manage that risk. (Of course, if the engineering solution only costs $10K, then yes it should be pursued. But only when it costs less than just ignoring the risk). pgpXz9Srq2tLh.pgp Description: PGP signature ___ Fun and Misc security discussion for OT posts. https://linuxbox.org/cgi-bin/mailman/listinfo/funsec Note: funsec is a public and open mailing list.
