Security and Honesty

  • Comments posted to this topic are about the item Security and Honesty

  • Should not the companies want to be secure and there for invest in security? Is it not immature companies that does not?

    To force companies to do things, like informing the public about these things would probably be very problematic to enforce. All thou it would be neat. Most companies would probably feel ashamed to go out with this information all thou there is nothing strange about getting hacked, it happens to a lot of companies. Thou some hacks are more humiliating than others.

    Many companies, like banks, do get hacked and most people knows about this. They themselves however often calculates on it, how much it costs to fix the security compared to losing some information or money to the hacks of various sorts. If they however knew their IT it should not have to be all that expensive to secure but nothing is free and when you lack knowledge and it's a cost involved as well, I guess it's easier to push the investment in security aside or on the future...

  • I think you have to get some perspective about this - if we reported every time we actually got some kind of attack, we would be registering reports approximately every minute - we can see logs of (mostly very incompetent!) SQL injection feelers etc all the time. Sometimes even when an attack has some limited success you can just re-assemble a VM or something and change an account - cyber attacks sound exciting but are essentially mundane in the web development game.

    Certainly though where data is compromised then it would be nice to think this might be put out into the open - nice to think if probably fairly unrealistic. Where I am now I believe this would be the case however I have worke at companies where such information is held down very tightly.

  • It's a tough call. Exposing information about attacks may help the general ecosystem but it can increase (at least temporarily) vulnerability of the companies involved. The more information that is out there about attacks (failed, successful and undetermined) can aid attackers. For example if an attacker is unaware that his attack has been detected, revealing that information even indirectly can interfere with attempts to identify the attacker and intrusion path.

    ...

    -- FORTRAN manual for Xerox Computers --

  • I see two aspects to this.

    1. It could be very difficult for a company to report problems, vulnerabilities involved and mitigation measures taken without revealing important details about their internal architecture. Yes, security by obscurity is not security, but if internal architecture is known, anybody attacking doesn't have to go through the step of determining what type of architecture and thus what type of vulnerabilities they can try to exploit.

    2. I can see value in reporting so that the IT community can pool it's knowledge similar to how the hacker community pools its knowledge. Since this is the defensive side, there is reason for keeping details disconnected from the company that has been attacked. I could see some sort of partnership between "security firms" where publicly known vulnerabilities and attack patterns are fully documented for public consumption. Then in terms of reporting, companies could report another occurrence of a known attack pattern against a known vulnerability to partner security firm who would update anonymous statistics. If a new attack pattern or vulnerability has been observed, then they could report that to one of the partner security firms who would add it to the database assuming it didn't involve a non-public vulnerability that needed to be reported to a vendor first.

  • Kelly Schlueter (7/2/2012)


    I see two aspects to this.

    1. ... Yes, security by obscurity is not security, but if internal architecture is known, anybody attacking doesn't have to go through the step of determining what type of architecture and thus what type of vulnerabilities they can try to exploit.

    ...

    This phrase gets repeated incessantly and while technically true, obscurity DOES have significant value (that's why burying your laptop in your car trunk is a lot safer then leaving it on the front seat). Obscurity does reduce the number of potential attackers.

    ...

    -- FORTRAN manual for Xerox Computers --

  • 1) Good security is more expensive, and increases how long all work takes, and increases how difficult it is.

    1a) Your competitors have less security than you... and thus lower costs and faster turnaround times. While you can wait for them to have a major security breach and go out of business, you might go out of business in the meantime, too.

    2) Some industries already have such report requirements in many countries; these tend to define what kind of data loss has to occur to be reported, how fast the report has to be done, and come with fines for failure to do so.

    3) Per 1a), a major security breach often drives companies out of business. Reporting it only increases the chance of going out of business, as at least some customers reasonably look elsewhere (and perhaps unreasonably think somewhere that hasn't reported a breach is more secure - the ostrich security technique is quite popular).

  • call.copse (7/2/2012)


    I think you have to get some perspective about this - if we reported every time we actually got some kind of attack, we would be registering reports approximately every minute - we can see logs of (mostly very incompetent!) SQL injection feelers etc all the time. Sometimes even when an attack has some limited success you can just re-assemble a VM or something and change an account - cyber attacks sound exciting but are essentially mundane in the web development game.

    Certainly though where data is compromised then it would be nice to think this might be put out into the open - nice to think if probably fairly unrealistic. Where I am now I believe this would be the case however I have worke at companies where such information is held down very tightly.

    My thoughts exactly....Companies I have worked for in the past don't tend to advertise that a successful cyber attack happened to them. 😀

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

  • Good points jay-h, many people tend to forget the simple ways to protect yourself and your belongings. If people don't know you have something of value they are less likely to come looking for it.

    Crooks are looking for easy money...they are, after all, crooks and want to get something by not working to get it. If you don't leave your laptop out in the open, they'll keep looking elsewhere for something easy. It also goes without saying that if you really want to safeguard your laptop, don't leave it in the car.

    Obscurity may not technically be "security" because it does not stop someone from doing something. However, it does play an important role in the overall security strategy. Obviously, it is not something you would rely on wholly but not to be discounted either. Remember the old saying "Loose lips sink ships!" And now we have "Information is power." This power can be used to sink ships just as it may be used to save them.

  • Obscurity definitely helps. After all, security isn't a set process. People don't do A, then B, then C. Some do A and B, some B and C, some A and D. We all have holes and they don't correspond to any hierarchy.

    However I'm not asking for immediate release of a breach, other than notification to affected parties. For the technical details, give people some time, maybe 4-6 months, to remedy the issue and then they need to disclose some technical analysis. Not necessarily your architecture though some disclosure is unavoidable, but definitely some technical details that would enable others to check their systems for issues.

    I know this might cause more attacks, but it would also force companies (or maybe insurance companies would force them) to spend time and $$ to clean up poorly configured or architected systems. Maybe SQL Injection would be less of an issue because poor coding practices using dynamic SQL and implicit parameters, would be eliminated.

Viewing 10 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic. Login to reply