Slashdot Mirror


Openness and Security on Campus

djeaux writes "The April issue of Syllabus includes an interview with Jeff Schiller, Network Manager at MIT, about openness and security in academic computing. Schiller has some interesting things to say about product liability for software, including an out for open source software and boils security down to a simple maxim: You must install patches. He also says that what makes security hard is that it's a 'negative deliverable.'"

31 of 145 comments (clear)

  1. Simpler than that by stanmann · · Score: 5, Insightful

    Security is simpler than that. Security requires fences, in the electronic world just as in the physical world.

    those fences can be visible or invisible, incorporated or separated, But they will NEVER stop dis-honest people. No fence will categorically keep out all burglars. No computer security(short of pulling all the plugs) will keep everyone off your computer. Openness and security can co-exist ONLY when everyone is trustworthy.

    --
    Food not Bombs is a nice platitude but it breaks down when you notice that the Bombees are usually well fed
    1. Re:Simpler than that by lukewarmfusion · · Score: 4, Insightful

      Openness and security are mutually exclusive (if I'm understanding your use of 'openness' correctly).

      You don't need security if everyone is trustworthy, and you can't have openness is everyone is not.

      Just quibbling.

    2. Re:Simpler than that by ColonelPanic · · Score: 5, Insightful

      You don't need security if everyone is trustworthy, and you can't have openness is everyone is not.

      The sad truth is that you can't have openness if anyone is untrustworthy.

      --
      "Skill shows through where genius wears thin." -Wittgenstein || Religion: uniting aviation and architecture.
    3. Re:Simpler than that by secolactico · · Score: 2, Insightful

      In meatspace there are ways to with certainty say Joe is Joe

      Actually, in meatspace there are ways to impersonate someone. If you are holding something to be delivered only to Joe, Jake can get ahold of fake ids and a convincing story and make you believe he is Joe (unless you personally know Joe, that is).

      --
      No sig
    4. Re:Simpler than that by Rikus · · Score: 3, Insightful

      ...you can always go over or through the fence

      I emphasize: if the thing behind the [nonexistent] fence is very safe, no "fence" should be necessary. I define the fence as the thing that prevents people from having a chance to interact with the fenced item. In the real world, someone can use their strength to break through a fence or break through a wall within the fence. In the electronic world, there needs to be an actual mistake or problem before a similar thing can happen.

      ...not being able to(YET?) categorically determine that joe is joe.

      That's done with signatures/public-key cryptography and symmetric cryptography. If that's not sufficient to determine that Joe is Joe, then Joe might need to be a bit more careful Someone installed a keystroke-logger and stole his secret key? Someone is holding a gun to Joe's head? Those are the dangers of the physical world.

    5. Re:Simpler than that by stanmann · · Score: 2, Insightful

      You don't want or need bank/military security unless you are a bank or military.


      Banks and military installations are hard targets for a reason and yet are still penetrated occasionally... WHY?

      because there is added value to penetrating those systems. The average person isn't in any direct danger from the people who rob banks or break into military bases.. and a bank isn't in any danger from someone who busts out a car window and steals a radio.

      OTOH if you put up that sort of security around your house you may attract the attention of that sort of person. and unless you have the resources of a bank, you will be penetrated.

      --
      Food not Bombs is a nice platitude but it breaks down when you notice that the Bombees are usually well fed
  2. Defeating security by munging URLs by tcopeland · · Score: 5, Insightful
    From the interview:

    S:Are there any other weaknesses to keep in mind, particularly when accessing data on the Web?
    JS: This gets into engineering implementations. The devil is in the details. Let me give you an example. There's a Web site out there--I won't identify them--that offers survey services. You can set up surveys and revisit them to see the data collected or to edit them. But if you look closely at the actual URL in the little bar at the top of your browser, you will see some long number.

    A few of us wanted to know, "Well, wonder what happens if we go into that title bar there where the URL is and just add one to that number?" And we did so, and all of a sudden we were looking
    at somebody else's survey, and seeing their answers. The devil is in the details.
    Yup. Each HTTP request needs to be checked separately for privilege violations. Not doing so is like opening your internal API to anyone who wants to call it... next thing you know, someone is injecting SQL and your database is executing a "DROP TABLE users". Yikes.
  3. Negative Deliverable by re-Verse · · Score: 5, Insightful

    People have to accept security as a regular part of life. There are LOTS of negative deliverables we subscribe to in our lives, and pay quite handsomly for. Off of the top of my head, I think of auto insurance. I mean - yeah we see nothing making it better.... but we know very well the hell that may arise if we don't have it.

  4. One thing that gives me pause... by Sheetrock · · Score: 4, Insightful
    Anybody that can give an answer about the cryptographic algorithms one should use that quickly without reflecting on the different strengths and weaknesses inherent worries me a bit. Sure, most of the focus should be on making access simpler and easier in practical situations, but who's to say offhand that Triple-DES or AES are better than Blowfish or plain DES?

    Nor would I applaud Automatic Update as a triumph for the end-user -- it delivers more than security fixes and can affect the stability of a machine. But the point about firewalls only being as good as the policy on employee laptops is a good one.

    --

    Try not. Do or do not, there is no try.
    -- Dr. Spock, stardate 2822-3.




  5. Software liability by GillBates0 · · Score: 4, Insightful
    JS:Now, the problem is that if you decide to put liability upon software authors, you destroy open source--because those people can't tolerate any liability. So, if I were king, I would rule that if you're selling software then you bear a certain liability; but if you're giving it away in open source, then you don't.

    But, I fear that the commercial interests in this game, if they felt that Congress was backing them into a situation where they would have to accept liability, my guess is they would strenuously lobby that liability applies to everything, including open source, in an attempt to kill off open source. So that's the conundrum.

    That was a very insightful quotes regarding the worry I've been having off late. Given their way, lawyers, lobbyists, anti-opensource corporations and their political puppets will all rally to impose liability for software on the end-developer.

    If such a development happens, we could very well see software developers forced to buy "malpractice insurance" like doctors/medical professionals - that alone will be enough to kill opensource software, not to mention the plethora of lawsuits and ugly frivoulous lawsuits which've plagued the US medical system and escalated medical costs.

    And ust to play devil's advocate to his suggestion that free software developers not be held liable - since they're "giving away" their stuff: somebody could turn my anology around and make outrageous claims like "exempting voluntary software developers from liability is like encouraging quacks to pursue their medical endeavours".

    --
    An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
    1. Re:Software liability by Mike+Hawk · · Score: 2, Insightful

      Without weighing in on the larger debate, you actually believe this?:

      However, if I make plans for a car, call it a "concept", and give you (for free) the plans for it, and you make a car that then injures you, how much liability would I assume? Very little.

      You actually think you wouldn't get sued by at least one person that tried to build the car? And remember, once that lawsuit starts you've already lost regardless of outcome if you aren't insured. Don't let the way you want the world to be cloud your view of how the world actually is.

    2. Re:Software liability by jadavis · · Score: 3, Insightful

      One interesting point about the liability issue is that proprietary software developers would benefit greatly from liability laws, and consumers would probably suffer.

      It's natural to assume that placing barriers or restrictions would hurt the vendors. Intuitively, anti-drug laws would hurt drug dealers, but in reality they drive the price up, and therefore the dealers' profits.

      It's the same with software vendors. It would take more time to develop a quality product, and so it would eliminate most of the smaller developers. In effect, it would drive the price of software up across the board. Most consumers don't care about security or stability, they really don't. And developers would shy away from some of the most useful features for fear it could be considered a security problem. So the consumers are getting no real benefit, but paying a huge cost.

      In the case of doctors, a patient's body would qualify, in computer terms, as "mission critical", meaning one problem is too many. So the patient loses if they see a quack. But, if a consumer gets bad software they reboot a few times a week, and maybe re-download some mp3s.

      A better solution is if the vendors who actually do provide mission-critical software would provide guarantees. You can get a lot better guarantee from IBM or Oracle than MS, and enterprises recognize that.

      --
      Social scientists are inspired by theories; scientists are humbled by facts.
  6. well, duh! by evenprime · · Score: 4, Insightful

    Of *course* you have to install patches. There is a bored 11 year old out there somewhere who thinks can prove he's "133t" by downloading a sploit off of packetstorm and owning your box.

    It doesn't matter that he has no knowledge of how to code a similar sploit himself, or that he could not admin your university WAN. It doesn't matter that university cut-backs mean you don't have enough money for a test LAN to make sure the latest buggy patches won't break business critical software/services or bring your servers to their knees. All that matters is that he can go on IRC and tell everyone how "k-rad 133t" he is.

    Stupidity wants to be free! :(

    --

    "Weapons should be hardy rather than decorative" - Miyamoto Musashi
    I think that goes for OS's too
  7. Give them a reason to patch by sdjunky · · Score: 5, Insightful

    He also says that what makes security hard is that it's a 'negative deliverable.'"

    I'm certain there are countless flaws in this idea. But hey, you don't post to slashdot without some risk of being shown what a moron you are right?

    How about having DSL/Cable companies give an incentive to customers whose computers do not become infected during the blitz of mass email worms and trojans. Something like a few bucks off of your ISP bill to free software. Some kind of incentive for NOT getting infected besides the fact that you don't have anything on your computer.

    It would benefit them in that it lowers their costs and increases their reliability if hundreds to thousands of their customers aren't sending DOS, etc.

    Of course, there are issues such as privacy implications (how would they know you're infected or not) to hardware costs for the ISP.

    1. Re:Give them a reason to patch by Rikus · · Score: 2, Insightful

      How about having DSL/Cable companies give an incentive to customers whose computers do not become infected during the blitz of mass email worms and trojans.

      Or how about making the ones who _do_ get infected pay an extra fee? After all, it's more fun to punish the people who cause damage than to reward those who don't.

      It would benefit them in that it lowers their costs and increases their reliability if hundreds to thousands of their customers aren't sending DOS, etc.

      Well, if it's against their ToS, they might as well just temporarily cut off the service of those infected customers, or at least send them a letter.

      Of course, there are issuses such as privacy implications

      Maybe monitoring all traffic isn't the solution (uh, to this.. I guess it's already the solution to everything else), but if they receive complaints per-IP-address, then they could keep an eye out for highly suspicious traffic coming from those addresses. I'm sure they already do to a degree.

    2. Re:Give them a reason to patch by Lumpy · · Score: 2, Insightful

      how about Cable and DLS providers simply give away a $29.00 SMC barricade with every connection and avoid 90% of the network crippling viruses and then give away one of the free virus scan programs?? it's a tiny step that would cost almost nothing to them and make a huge difference to their network manageability.

      problem is that many times the "software" that comes with your DSL and Cable modem is riddled with spyware... (comcast's certianly is)

      the cost of a HARDWARE front line NAT box that has all incoming ports closed would be almost nothing to them.

      --
      Do not look at laser with remaining good eye.
    3. Re:Give them a reason to patch by Anonymous Coward · · Score: 1, Insightful

      I think you are misinterpreting his comment. In the artice he states

      "One of the fundamental problems is that security is very hard. And what makes it hard is that it's a negative deliverable. You really don't know when you have it. You only find out belatedly when you've lost it."

      He wasn't stating, as you are suggesting, that there isn't any benifit to come from good security. But r

  8. Play by campus rules by SkiddyRowe · · Score: 2, Insightful

    My stance is that you're essentially playing baseball in your heighbors yard. He won't change the way you play the game, or change the rules necessarily, but he sure is going to limit how far you can hit the ball. Like the green monster at Fenway.

  9. most patches aren't trustworthy by foosballhound · · Score: 4, Insightful

    >> You must install patches.

    in the "real world", when there is a security
    threat, such as a gas leak, you call the repair
    person, who fixes it.

    This is the equivalent of "install patches"

    Note that there is a level of confidence in
    calling the repair person, that they won't
    paste adds all over your living room, or install
    a wire-tap on your phone line, or a spycam
    in your bedroom.

    unfortunately, in the computer world, all too
    often the "patches" are used as trojans.

    they change user settings, put in spyware,
    brake working code, etc

    so, ppl are hesitant to apply patches, with
    good reason.

    1. Re:most patches aren't trustworthy by Entropius · · Score: 4, Insightful

      I don't think anyone objects to installing patches. What I, and others, object to is being railroaded into other things while I install them. If I own a house with a natural gas system, I don't want to sign a contract that says "you must call our technicians to fix any problems with your gas"--especially if I happen to know how to fix such things myself, or know someone else who does.

      This is why the OSS model works better for security. I *can* run urpmi --update and trust that the results will be what I want. I can also look under the hood at exactly what gets updated and how. Or, I can download individual packages... or download things and compile them from source... or, if I want and have the skill and time, I can fix things myself.

      Now, simply because there are alternatives, there is competitive pressure on the people who make autoupdaters to make them efficient, effective, and transparent--because, otherwise, people will stop using them.

  10. Comment removed by account_deleted · · Score: 2, Insightful

    Comment removed based on user account deletion

  11. Re:Patches? by sphealey · · Score: 4, Insightful
    I read in a magazine recently that a Microsoft exec said Windows users would be "much safer" if we all would just download software patches from Windows Update. According to the article, no one took him seriously.
    Well, there's that little problem where Microsoft patches tend to break other applications, particularly competitor's applications. Which makes automatic patching a bit of a concern when mission-critical apps get broken.

    sPh

  12. From the Article by RAMMS+EIN · · Score: 3, Insightful

    ``JS: The reason it doesn't crash all that often is because system software developers took some time and effort to make that the case. If they would take the time and effort to make it be secure, it would be secure.''

    No. More secure, but not secure. For one thing, things will be overlooked. For another, there will always be things that were not known to be security holes at the time, but that will later turn out to be such.

    ``JS: I think Linux is much more secure than a lot of the other stuff that's out there, because so many people look at the source code--not everyone looks at it, but enough people do, so that problems get fixed earlier, rather than later.''

    Many people look at the sources, but do they find the vulnerabilities? See also above.

    In short, nothing is going to give you guaranteed security. Having said that, crackers will only go so far to break a system, so absolute security isn't even required. This makes any security measure useful, including firewalls (which JS argues against).

    As a closing remark, despite these minor points, I found the article a very good read; JS seems to have his heart in the right place. Heh, it makes me frown every time people say "security" and mean "restrictions" (see also MicroSoft and Trusted Computing).

    --
    Please correct me if I got my facts wrong.
  13. Re:I only agree somewhat with this article. by psycho_tinman · · Score: 5, Insightful

    In my experience, there are basically two things that are *MOST* commonly seen in academic networks; one is either internal or external parties trying to take advantage (and misuse) the massive bandwidth that campuses have available, or someone trying to discover and manipulate potentially sensitive documents (such as grades).

    I think firewalls have their place, you're right. But being at the receiving end of a rather draconian installation/firewalling policy for no apparent reason other than just reducing work for the systems operators (and increasing work for students, supervisors in general); I'm thinking that there should at least be a set of carefully monitored, but open machines for people to just mess around with. It's a campus, a seat of learning. Sometimes, when you're trying to learn something, things break. Do you want to be too worried about breaking a piece of "mandated" software and having a risk of getting your ass chewed, instead of experimenting ?

    Campuses have different security requirements and needs from commercial outfits, IMHO. Sometimes, administrators just don't understand that and try to implement the same policies willy nilly. Security isn't just about procedures and blanket firewalling.

  14. Re:All in One Box by SCHecklerX · · Score: 2, Insightful

    'personal firewalls' are the wrong solution. The proper solution is to not run unnecessary services out of the box in the first place. Really, NONE. If a user needs to run a particular service, then they should know how to enable it and how to secure it. But to run things as part of a default install is silly. It's bad enough in the windows world that netbios is always-on (RPC vulns anybody?).

  15. Re:I only agree somewhat with this article. by Entropius · · Score: 2, Insightful

    Mod parent up. Most of the networking people who now implement policies that reduce their workload but cripple students' ability to explore gained their skills from similar exploration years ago.

  16. It's the same old saw by ChiralSoftware · · Score: 4, Insightful
    "Security is about patches." That statement implies the belief that security flaws are inevitable, an inherent part of having software. This simply isn't true. We should not accept such thinking. If a product doesn't have security holes the day it is released, it still won't have security holes a thousand years from now, patches or not. The question is, how do we ship products without holes? The reasons we have security holes in products are not because developers are stupid or careless, or because the business side of the company wants to ship the product now. No, the reason we have holes is because we're still using horrible software development tools which make security problems almost inevitable. Humans just can't think like C compilers and if we write a long enough program in plain old C, we end up with buffer overflows and lack of bounds checking on things. If we used safer tools like Java, which don't have buffers and which store data in structures which know their own size (collections), the vast majority of vulnerabilities would never even be created. If a user sends malicious input to a Java process, we know that no matter how broken the Java is, that malicious input can't stomp on memory and be executed, no matter what, because the JVM and the bytecode verifier don't allow it to. That is the kind of assurance that software should have.

    It is always possible to make security problems at the design level, like forgetting to check an account balance before allowing a withdrawal in bank software, but humans are very good at thinking in those ways, and those kinds of problems are rare.

    ---------
    Create a WAP server

  17. Too Much Reliance On Patches... by pandrijeczko · · Score: 3, Insightful
    Security is just about "effort vs reward".

    You put as many "locked doors" as possible in the way of a potential intruder so that each time the intruder is faced with a new "door", he or she may simply decide your system is no longer worth the effort and give up trying to get in.

    Patches are the "last locked door" - in other words, once you've definitely decided that you need to run a specific application on the Internet, you make sure that it's updated to the latest version.

    However, prior to that, you've already ensured the application is configured correctly, that the box it's running on has security permissions locked down, that the box is behind a firewall and probably a NAT box also for good measure.

    Not to mention some good system logging and alarming going on so you have the best chance of shutting the box down when someone does get in.

    In security, only the paranoid survive...

    --
    Gentoo Linux - another day, another USE flag.
  18. Re:Patches? by Vancorps · · Score: 2, Insightful
    I would seriously home no one uses Windows update to patch a mission-critical server. In such environments you have an onsight SUS server. You apply the patch to your testing server and if its successful you use SUS to push the patch out.

    Windows update does break stuff, but it is not the only option for automatic or manual updates from Microsoft. They even offer a corporate version which doesn't rewrite policy everytime you update which is why most apps break when they do

  19. Re:Patches? by sphealey · · Score: 2, Insightful
    True, but in the long run whats better? Switching over to Linux and have no one to sue if your server gets hacked due to a security flaw?
    OK, now its my turn ;-)

    Please name the last time any organization of any size successfully sued Microsoft over a product liability issue. I'll even take FOAF references to orgs getting under-the-table reimbursments if that's all you have.

    sPh

  20. Which side of the fence is which? by billstewart · · Score: 3, Insightful
    One of the canonical Internet security threats was always "some college student with lots of resources and technical skill and too much time on their hands" attacking your system. If you're running the Internet security for a university, a firewall is not going to keep that kind of threat _out_, because the students are already _inside_. (Ok, it'll discourage students from other colleges from hacking your college, but the most motivated threats are already inside your firewall.) Protecting administration computers is a different problem from protecting student computers, faculty computers, and shared workspace computers. Some of this can be helped by appropriate partitioning, and Schiller's point about keeping all the machines patched and as secure as possible is critical.

    Some university administrations are concerned with protecting the rest of the Net from their students; others think that interferes too much with legitimate research. Some other poster commented that their university's policies are to be "open", but they block incoming Port 80 and Port 25 to student residence networks - meaning that students can't run their own web servers or mail servers, which is distinctly *not* openness.

    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks