Slashdot Mirror


Michal Zalewski On Security's Broken Promises

Lipton-Arena writes "In a thought-provoking guest editorial on ZDNet, Google security guru Michal Zalewski laments the IT security industry's broken promises and argues that little has been done over the years to improve the situation. From the article: 'We have in essence completely failed to come up with even the most rudimentary, usable frameworks for understanding and assessing the security of modern software; and spare for several brilliant treatises and limited-scale experiments, we do not even have any real-world success stories to share. The focus is almost exclusively on reactive, secondary security measures: vulnerability management, malware and attack detection, sandboxing, and so forth; and perhaps on selectively pointing out flaws in somebody else's code. The frustrating, jealously guarded secret is that when it comes to actually enabling others to develop secure systems, we deliver far less value than could be expected.'"

18 of 125 comments (clear)

  1. It's true. by Securityemo · · Score: 2, Informative

    Computer security will kill itself.

    --
    Emotions! In your brain!
  2. So let me get this straight by Monkeedude1212 · · Score: 5, Insightful

    When Virtual Security mirrors Physical Security - people should expect more from virtual security? How is a Night watchmen not a form of "vulnerability management" and "attack detection"?

    All security in general is reactive. You can't proactively solve every problem - this philosophy goes beyond security. The proactive solution is to plan on how to handle the situation when a vulnerability gets exploited, something I think virtual security has managed to handle a lot better than physical security.

    1. Re:So let me get this straight by fuzzyfuzzyfungus · · Score: 3, Informative

      Probably because, at least in theory, the rules of Virtual security are more favorable?

      In the real world, security is hard because matter is malleable. When an armored vehicle gets blown up, we don't say that it "failed to validate its inputs". It just didn't have enough armor. Even in cases where it survives, all it would have taken is larger projectile, or one moving a bit faster... When somebody pulls an SQL injection or something, though, it is because the targeted program did something wrong, not because of the inescapable limitations of matter.

      The only real class of security issues that mirror real-world attacks are DOS attacks and the like, because computational capacity, memory, and bandwidth are finite.

    2. Re:So let me get this straight by fuzzyfuzzyfungus · · Score: 2, Insightful

      The difference is that programs are mathematical constructs and thus(if you are willing to take the time, and possibly constrain the set of programs it is possible for you to write) you can prove their behavior.

    3. Re:So let me get this straight by melikamp · · Score: 2, Insightful

      When Virtual Security mirrors Physical Security - people should expect more from virtual security? How is a Night watchmen not a form of "vulnerability management" and "attack detection"?

      I agree about the physical security: with software, we are confronted with a very similar set of problems.

      All security in general is reactive.

      I am not sure what that means. If I have a safe, for example, as a solution to my policy of restricting access, then I have something that is both proactive and reactive. The safe is proactive because it make unauthorized access via a blowtorch much more expensive than authorized access via a combination. It is reactive because it makes undetectable unauthorized access prohibitively expensive. I don't see why software security is different.

      I am not a professional security specialist, but, with all due respect, I think that I have a clearer understanding of security philosophy than the author of TFA. At times, he seems to be completely lost.

      He spends a lot of time attacking strawmen. He analyzes some definitions, for example: "A system is secure if it behaves precisely in the manner intended - and does nothing more." I would not dignify this with a comment, because this is the definition of bug-free software, nothing else. "A system is secure if and only if it starts in a secure state and cannot enter an insecure state." Does this even mean anything, unless we define "secure state"? He is right about one thing: these are bad definitions. In fact, they are so bad, I can hardly see what they have to do with the software security.

      The focus is almost exclusively on reactive, secondary security measures: vulnerability management, malware and attack detection, sandboxing

      He disses the reactive approach, even though it is one of the cornerstones of the physical security. A system that cannot be compromised surreptitiously is often a less attractive target than the one that can, making it more secure in practice. And why is sandboxing in this list? Correct me, but it is the poster child of proactive approach. If your hypervisor or interpreter or whatever sandbox you are using is bug-free and is effective at enforcing your security policy, then the entire process is completely secure.

      Which brings me to my next point. I'll go ahead and try to give a reasonable definition of software security. The software is secure if it is effective at enforcing the given security policy. I don't have to say that it is bug-free: it's an underlying assumption, because if the software has a bug which allows for violation of your policy, then the software is not effective at enforcing it.

      I am perplexed by the omission of the policy notion from TFA. How can we start talking about security if we did not define what we are trying to secure ourselves from? Let's take one very popular policy, say, restriction of access to data. Despite of all of complaints in TFA, the problem is largely solved. To be more specific, let us imagine that we have a policy as follows:

      (1) Data has to reside on a networked host (otherwise the problem would be trivial).

      (2) Data has to be available upon an authorized request over the network.

      (3) Data has to be available upon an authorized local request.

      (4) Data should not be even detectable by an unauthorized agent.

      (5) The same networked host has to be able to service unrelated public requests (e.g., HTTP).

      I am not a professional, but even I can probably slam together a system, over a weekend, to implement this policy. OpenBSD, one restricted account apache to serve public requests, another restricted account apache with SSL to serve the data, reasonable file permissions. Good luck compromising me without social engineering.

      I guess what I am trying to say is, there is nothing wrong with our understanding of software security. The reason the field looks so bad is because people design overly complicated, contradictory, or outright brain-dead security policies.

  3. Security is hard by moderatorrater · · Score: 2, Insightful

    Computer security is roughly equivalent to real-world security, only the malicious agents are extremely fast, can copy themselves at will, and can hit as many targets as they want simultaneously. When considered from the point of view of real-life security, our software security problems seem almost inevitable.

    The central insecurity of software stems from the fact that security requires time and effort, which makes it hard to get management to fully commit to it, and there's nothing in the world that can make a bad or ignorant programmer churn out secure code. There have been solid steps taken that have helped a lot, and programmers are getting more educated, but at the end of the day security requires a lot of effort.

  4. Motivation by 99BottlesOfBeerInMyF · · Score: 2, Interesting

    Security can be widely deployed by enterprise IT, OS vendors, and possibly some hardware OEMs. The larger the footprint, the easier it is for such real security to be rolled out. The thing is, while some IT departments have very good security, just as many have terrible. Hardware vendors are unlikely to have the expertise and are unlikely to be able to profit using an integrated security platform as a differentiator. This pretty much leaves OS vendors. MS has a monopoly so they don't have much financial motivation to dump money into it. Apple doesn't really have a malware problem, with most users never seeing any malware let alone making a purchasing decision based upon the fear of OS insecurity. Linux is fragmented, has little in the way of malware problems, and has niche versions for those worried about it.

    I'm convinced malware is largely solvable. It will never be completely eliminated by the vast majority could be filtered out if we implemented some of the cool new security schemes used in high security environments. But who's going to do it? Maybe Apple or a Linux vendor if somehow they grow large enough or their platform is targeted enough. Maybe if MS were broken up into multiple companies with the IP rights to Windows, they're start competing to make a more secure product than their new rival. Other than that, we just have to sit in the mess we've made.

    1. Re:Motivation by 99BottlesOfBeerInMyF · · Score: 3, Insightful

      A big part of social engineering is that users don't have the patience for the sorts of full explanations required to implement that.

      Why would they need patience if you provide them with immediate verification of who they're talking to, if they're affiliated with who they claim, and if what they are doing is a normal procedure or something strange?

      Consider Microsoft's new UAC system, for example—that's close to what you described,

      No, not really.

      but users tend to either just hit "yes" as quickly as possible to get on with their work

      UAC is a study in how operant conditioning can be used to undermine the purpose of a user interface. It's a classic example of the OK/Cancel pitfall documented in numerous UI design books. If you force users to click a button, the same button, in the same place, over and over and over again when there is no real need to do so, all you do is condition them to click a button and ignore the useless UI. Dialogue boxes should be for the very rare occasion when default security settings are being overridden, otherwise the false positive rate undermines the usefulness. Dialogue boxes should be fairly unique and the buttons should change based upon the action being taken. If your dialogue box says "yes" or anything other than an action verb, you've already failed. Further UAC is still a failure of control. Users don't want to authorize a program to either have complete control of their computer or not run. Those are shitastic options. They need to be told how much trust to put in an application and want the option to run a program but not let it screw up their computer. Where's the "this program is from an untrusted source and has not been screened: (run it in a sandbox and don't let it see my personal data)(don't run it)(view advanced options)" dialogue box?

  5. Re:It'll Never Happen by fuzzyfuzzyfungus · · Score: 4, Insightful

    Do you actually think that all IT and PC security companies have a giant cartel going, where they all secretly agree to suck? Somehow including all the "independent security researchers", which includes anybody with a computer, a clue, and some free software?

    Seriously? If there were some magic bullet, the temptation for one cartel member to make a giant pile of cash on it would be overwhelming.

    Much more troublesome, for security, is the fact that there are no known methods of secure computing that are economically competitive with insecure ones, not to mention the issue of legacy systems.

    You can buy a lot of low end sysadmins re-imaging infected machines for what it would cost to write a fully proven OS and application collection that matches people's expectations.

  6. Too Expensive by bill_mcgonigle · · Score: 2, Interesting

    It may be that a secure and convenient system is possible, but it's too expensive for anybody to sit down and write.

    Rather, we're slowly and incrementally making improvements. There's quite a bit of momentum to overcome (witness the uproar when somebody suggests replacing Unix DAC with SELinux MAC) in any installed base, but that's where the change needs to come from, since it's too expensive to do otherwise.

    If time and money were no object, everything would be different. More efficient allocation of the available time and money is happening as a result of Internet collaboration.

    So, 'we're getting there' seems to be as good an answer as any.

    --
    My God, it's Full of Source!
    OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    1. Re:Too Expensive by 0xABADC0DA · · Score: 2, Insightful

      witness the uproar when somebody suggests replacing Unix DAC with SELinux MAC

      The uproar is because SELinux is a complete pain and tons of work to set up correctly and completely. The SELinux policy for Fedora is ~10mb compiled. Although it does work pretty well at preventing escalation.

      But finally you get the system locked down with SELinux and still it does nothing to prevent BadAddOn.js from reading mydiary.txt if it's owned by the current user.

      What's really needed is:

      - A hardware device to authenticate the user. Put it on your keychain, shoe, watch, whatever.

      - OS that grant permissions for specific objects based on user input, not to processes. If the user selected mydiary.txt from the trusted input dialog then the browser can read it. Otherwise it can't, or it has to ask permission to do so (OS puts up a dialog).

      These two things could reliably cover the vast, vast majority all actual security needs, without hassles to the user, and without remote automated attacks. It wouldn't be perfect still, but it would be magnitudes better than what we have now. Unfortunately there's no mass market to provide a general purpose hardware device like that, and software would have to be modified slightly.

  7. Re:Wrong approach? by mrnobo1024 · · Score: 2, Informative

    The underlying architecture is fine. Ever since the 286 it's been possible to run code while limiting it to accessing only a specified set of memory addresses. What more is it supposed to do? It's not the CPUs' fault that OSes are failing so hard at the principle of least privilege.

    They're just "executing code they're told to execute"? Well, of course - do you want them to refuse to execute "bad" code? If so, please show me an implementation of an IsCodeBad() function.

  8. Re:It'll Never Happen by maxwell+demon · · Score: 3, Funny

    I think normal bullets are sufficient for that. Unless some of the users are wizards, of course.

    --
    The Tao of math: The numbers you can count are not the real numbers.
  9. Attacks are cheap by ballwall · · Score: 2, Insightful

    I think the issue is not that we're bad at security, it's just that attacks are cheap, so you need the virtual equivalent of fort knox security on every webserver. That sort of thing isn't feasible.

    The lock on my house isn't 100% secure, but a random script kiddie isn't pounding on it 24/7, so it's good enough.

  10. Re:Not so much in ix and ux environments by lgw · · Score: 3, Interesting

    Modern Microsoft OSs aren't really any more "inherently vulnerable" than anyone else that might be viable in the consumer space. At this point it's more about getting the apps onboard with the security model. In the server space, Win2008 r2 gets most things right - just about everything is off by default, the kernel itself is quite secure, there's a good model for running as a non-admin and escalating when needed.

    The biggest problems with Windows right now are apps that pointlessly need to run as admin, and apps that don't sandbox even narrower than "all the current user's data". All OSs are equally vulnerable to social engineering trojans - if you can trick the user into giving you the root password, you win - but outside of that Windows itself is only particularly weak in that a lot of the code is still new.

    The real trick for security - for Windows and everyone else - is to adopt a model more like SE Linux where you just agressively limit what each app has access to. SE Linux is too hard to configure for the broad market, but a simpler approach where each app is sandboxed in a VM with just the resources it needs will shut down the "drive by" attacks involving flash, PDF, and similar apps. You can't do much about social engineering trojans, but you can fix the rest with sandboxing/jailing that doesn't require the end user to configure stuff.

    The Web browser shouldn't be special in this regard - every app should be jailed automatically, requiring effort from app developers to broaden an app's scope, instead of the current model where app developers are asked to do extra work to narrow an app's scope.

    --
    Socialism: a lie told by totalitarians and believed by fools.
  11. Security is NP hard? by istartedi · · Score: 2

    If you define security as being able to determine whether or not a program will reach an undesired state given arbitrary input, isn't that equivalent to the halting problem? Isn't that NP hard? I know that I generally force programs to halt when they're behaving badly, if they don't halt on their own.

    --
    For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
  12. jail+fine the execs by dltaylor · · Score: 2, Insightful

    Until there are negative consequences for the execs, there will never be IT security because it costs money. If the execs of companies that have IT breaches were jailed for a couple of years (hard time, not some R&R farm) and personally fined millions of dollars, they would insist on proper security, rather than blowing it off. 'Course, these are the same guys who schmooze with, and pay bribes to, "our" elected representatives, so that's never gonna happen.

    "Security is not a product, it's a process", and, since there's no easily calculated ROI on the time spent on securing IT, even when there's a paper process, it is so frequently bypassed that it might as well not exist.

  13. Re Cabsec - Capability Based Security by ka9dgx · · Score: 2, Informative

    I've read through all the comments, and this is the only sane one that stands out. The principle of least privilege, as I see it, is the idea of letting the user give privileges to a program at run time, and they would chose the least possible set of resources to get the job done.

    The main thing is that with cabsec, you NEVER trust a program with the full resources of a user, and thus it never has enough resources to take out your system.

    Consider if Outlook were only allowed to talk to a mail server, and a datastore, and use the console IO. It wouldn't be possible for an email to take out anything else, as it would be out of the scope of allowed actions. Everyone could manage profiles for things to automate the normal routine stuff, and use a nice GUI for the tricky bits... saving the settings if the results were favorable.

    The big plus of cabsec (CApability Based SECurity) is that it would allow pretty much anyone to manage their own system, and to NEVER worry about virii again.

    It can be done, but for many good reasons most users have never heard of it.