SECURITY MYTHS by Eugene Volokh, VESOFT Published by SUPERGROUP Magazine, July 1988. Published in "Thoughts & Discourses on HP3000 Software", 4th ed. Everybody wants system security; everybody agrees that it's a good thing. The trick, as usual, is to turn good intentions into good results (a worthwhile point to remember in this election year). Sometimes an apparently sound security system turns out to have a fatal flaw that not only leaves your system insecure, but lulls you into a false sense of security. Often these flaws are not visible until it's too late; often they are obscured by some common myths which everybody believes but which are very badly mistaken. MYTH #1: I HAVE MPE PASSWORDS, I'M OK Passwords are the tried and true way of securing computer systems. Someday, perhaps, fingerprints and retina scans will take over, and a computer will be able to identify with 100% accuracy who is trying to access; until then, we have to live with "knowledge security" -- identifying a person by whether or not he knows a password. HOWEVER -- and this is a big however -- a password only works if the fundamental assumption of knowledge security holds true. This assumption is that ONLY USER X KNOWS USER X'S PASSWORD. Seems obvious? Well, answer honestly: does this assumption hold true on your system? Is each password known only to the person who's authorized to know it (or, perhaps, also to the system manager, though even that is not so good)? There are four major possible problems with passwords, any one of which may render your entire password system useless. I'd guess that 75% of all HP3000 sites suffer (without realizing it!) from at least one of the following problems: A. PASSWORDS THAT SHOULD BE THERE -- BUT AREN'T. B. PASSWORDS THAT ARE KNOWN TO MANY PEOPLE (even if all of them are supposedly authorized to know them). C. PASSWORDS THAT REMAIN UNCHANGED FOR A LONG TIME. D. PASSWORDS THAT ARE EMBEDDED IN JOB STREAMS, PROGRAMS, ETC. Problem A seems to be the most obvious one; but are you sure that all your users really DO have passwords? How do you know? When was the last time you looked at a LISTDIR5 >LISTUSER @.@;PASS listing? Problem B refers to the common practice of having many people share the same password (e.g. 20 people who sign on as CLERK.PAYROLL). It's an elementary principle of security (in real life just as surely as in computers) that the more people there are who know a secret, the more "leaks" there will be. You might be able to get one person to keep his password a secret; get twenty people to keep a secret? -- not a chance! To remain valuable, passwords must be changed periodically (perhaps as often as once every 30 days, according to some auditing standards). How often do you change yours? Finally, embedded passwords (which MPE's :STREAM command REQUIRES you to keep in all your job streams!) hurt you in two ways. First, they make passwords easier to figure out (one accidentally :RELEASEd job stream or misplaced printout and the secret's out); moreover, they make it virtually impossible to change passwords, since this would involve changing hundreds of places in which the passwords are embedded, some of which you might have forgotten about! Do all your MPE users have passwords? Is each password known to only one person (i.e. no shared passwords)? Are all passwords changed frequently? Have you eliminated all your embedded passwords? If you can't answer YES to all four of these questions, then your password security is strictly MYTHICAL. MYTH #2: MY DATABASE IS PROTECTED BY IMAGE PASSWORDS Most people's IMAGE databases are the repositories of their most valuable data -- payroll, accounting, customer information, etc. Fortunately, IMAGE has a very sophisticated security system to protect it -- up to 60-odd different levels of security, with individual read and write security imposable on each item. More than enough to protect your precious data. Or is it? To open an IMAGE database, you must pass the database password to DBOPEN. This is what IMAGE security rests on. Unfortunately, it is the PROGRAM -- not the USER -- that must supply the password; typically, the password ends up being embedded in the program. What does this mean? For almost all IMAGE applications (except for the few that prompt the user for the IMAGE password -- more about them later), it means that: * Database passwords are virtually NEVER changed (since this would force a recompilation of all the programs and perhaps changes to any QUERY/QUIZ/SUPRTOOL/etc. job streams). * Database passwords are known to every programmer who's ever had to work on a program that accesses the database. * Database passwords can be easily read by anybody who has read access to source files, to database-accessing job streams, or even (though somewhat less easily) to the program files themselves (which have the passwords stored in them in clear text). When was the last time you changed your database passwords? If the answered is measured in years (as it is for most people), how can you expect them to be really protecting your data? Just as MPE passwords embedded in job streams are bad, so are IMAGE passwords embedded in programs. This problem is even worse for users of vendor-supplied packages. The typical application package includes both programs and databases; the vendor writes the programs expecting the databases to have particular passwords, and the user can't change those passwords for fear of the programs aborting. The result is that ALL THE USERS OF THE PACKAGE HAVE THE SAME PASSWORDS. A person who's worked with the package in one company can go to a different company and know the database passwords. Some people (a small minority) try to avoid the problem of embedded database passwords by prompting the user for the database passwords. This seems good in some respects; however, practically, it has its problems. The typical program is designed with only one (or perhaps a few) IMAGE user classes in mind. If your program does a DBPUT with an "@" list to a dataset, it expects to have full write access -- if the program's user class does not allow this sort of access, bad things will happen. Therefore, all users of the program will have to share one user class, and thus one password. The passwords may no longer be embedded, but they'll have to be shared among fifty or a hundred users -- how long are they likely to remain secret? A related issue is protecting a database against QUERY access -- presumably your programs have appropriate security and audit trail features built in to them, but QUERY can let a user (who knows the right password) modify any field in any set, without leaving a trace. Some people put a lockword on QUERY; others run DBUTIL and do a >>SET SUBSYSTEMS=OFF (or >>SET SUBSYSTEMS=READ). The trouble is that -- no matter how much you protect QUERY -- an ingenious programmer can easily write a program that does its own DBOPEN and its own DBPUTs, DBDELETEs, and DBUPDATEs. The >>SET SUBSYSTEMS won't help you, since it only works against programs that actually check the SUBSYSTEMS flag. The only way to really protect your database is by keeping your IMAGE passwords secret. In reality, securing your IMAGE database is a lot harder than it looks. What you'd really like to do is to control access not by the PASSWORD, but by the USER ID of the user trying to access it and/or by the PROGRAM doing the access; for instance, you might want to say "the user MGR.AP running AP010.PUB.AP can have access in user class 10" or "only MANAGER.SYS can use QUERY.PUB.SYS to write to this database". For this, you'd really need your own home-grown IMAGE security procedure (or a third-party one like VESOFT's VEOPEN); unfortunately, if you don't do this, you'll have to reconcile yourself to not having any special security on your IMAGE databases. MYTH #3: I HAVE APPLICATION SECURITY AND THAT'S ENOUGH Most good application systems have "application security" -- security checks built in to the program that make sure that, say, only MGR.PAYROLL can write checks or only MARY.AP or JACK.AP can add new vendors to the accounts payable system. Application security is vital because the computer has no way of differentiating, say, writing checks and adding employees (the two operations might actually update exactly the same datasets); only you can tell who should be able to use one option of your system and who should be able to use another. However, a security system is only as strong as its weakest link. Say that your accounting systems calls the WHO intrinsic, gets the user id, and uses it to determine which features of the system the person is entitled to use; how do you know that the user id is really correct? If you only allow MARY.AP to add a vendor, how do you know that it's really Mary who's signing on that way? This kind of application security system relies on the logon security system -- it relies on "user id integrity" to guarantee that a user id really corresponds to a particular person. Only good logon security, with private, frequently changed passwords can provide this sort of guarantee. Note also that if you use a user's logon id for audit trail purposes, you MUST make sure that the logon id really corresponds to one and only one person. What's the use of seeing that a "ghost employee" was added by PETE.AP when anybody might have known Pete's password? In fact, if you ever have to prosecute an embezzler using audit trails, those audit trails will be worthless if you don't keep your logon security airtight -- it would be very easy to claim that somebody else simply logged on under his user id. MYTH #4: THE PEOPLE TO REALLY FEAR ARE THE DIAL-IN "HACKERS" There's been a lot of publicity recently about dial-in "hackers", often high school students who break into people's computer systems and wreak havoc. However, it's been estimated that 90% of all security violations are "inside jobs" (though, of course, it's hard to get an exact figure). In our own experience, we've seen no break-ins by strangers; instead, we've encountered (among other things): * Several time bombs planted in a program by a disgruntled employee. * In three separate cases, malicious encryption of source code by employees on their way out, resulting in perhaps tens of thousands of dollars of lost software investment. * Embezzling of over $1 million by the chief financial officer of a small company. (This same person, when earlier approached by his DP people with a budget request for security software, replied that "we don't need any more security".) It's very natural to fear the stranger more than the people you work with every day; unfortunately, it's those inside people who are most likely to sabotage or steal (or even -- with the best of intentions -- do something very stupid using capabilities that they should never have been granted). Protecting the system against an outsider is easy (just make sure you have plenty of passwords and perhaps even special passwords on dial-up lines); protecting against an insider is much harder. Once a person is already authorized to use the system, what can you do to protect yourself against him? * You can make sure that he doesn't do more than he was actually authorized for. The best way of assuring this is by DENYING HIM ACCESS TO THE COMMAND INTERPRETER -- when he signs on, he should immediately (with a logon UDC) be dropped into the application he needs to use or, if there's more than one such application, into a logon menu. After he's done, the logon UDC should sign him off -- all this time, he'd only be able to do what he was explicitly authorized to do. In general, remember that once a person gets access to the CI, to the editor, to QUERY, to the compilers, etc., he's a lot harder to contain than when he only has application access. At a typical site, there are many possible holes in security (unneeded capabilities, :RELEASEd files, etc.) that can be exploited by a person with CI access. * You can keep track of everything he does by using MPE and/or IMAGE logging. Better yet, let all your users know that you're keeping track of them. This way, they'll know that even if they manage to do something nasty, there'll be thorough and damning evidence of what they were up to. IMAGE logging is particularly good for this -- it can keep track of every change made to the database (through an application program, through QUERY, or what have you). Robelle Consulting's DBAUDIT can analyze these log files for you and let you know exactly who did what, where, and when. MYTH #5: ENCRYPTION PROGRAMS ARE GOOD FOR YOU The INTEREX Contributed Library has several programs that let you encrypt files -- you supply a key, and the file gets encrypted; nobody will be able to decrypt it unless they can supply exactly the same key. At first glance, this seems to be a very useful security tool -- protect all your sensitive files against EVERYBODY (even the system manager). In reality, this turns out to be a possible "Trojan horse" that, in our experience alone, has cost our customers tens of thousands of dollars in lost software. In the span of less than a year, we encountered three completely different sites with the same story. One day the company fires a programmer (or perhaps even the DP Manager) and the next day they discover that many of their source files have been encrypted! Without the fired person (with whom they naturally want nothing to do), the sources are completely useless. In all three cases the backups were no help; the files may have been encrypted long before, or perhaps even decrypted every morning and re-encrypted every night before the backup! In one case, the company managed to recover its files (after paying me some non-trivial consulting fees to crack the encryption algorithm!); in the other cases, the companies had to choose between rewriting the programs from scratch (or redeveloping them from a very old version that they still had un-encrypted) or taking expensive (and possibly fruitless) legal action against the saboteur. The ironic thing is that if the saboteur were accused (either civilly or criminally), he could claim that he did nothing wrong -- in fact, he could say that he was actually trying to IMPROVE system security by encrypting the sources to protect them against unauthorized readers. My legal sources tell me that unless you could prove malice (which would be very difficult), a criminal prosecution would be almost certainly impossible. The first moral to draw from this is NOT TO ALLOW ENCRYPTION PROGRAMS ON YOUR SYSTEM. This is especially true because very few sites actually have data so sensitive that it must be encrypted. MPE file security can do a pretty good job against anybody who doesn't have SM capability; and usually, the system manager should really be allowed to read everything in the system (if only to protect against people leaving the company and leaving their files encrypted). The second, and more interesting, moral is THINGS ARE OFTEN NOT WHAT THEY SEEM (actually, that's the moral of very many stories). Something that at first glance appears to be a powerful security tool can actually prove to be a great danger to your system. Let's be careful out there. MYTH #6: MY USERS ARE TOO DUMB TO DO ANYTHING NASTY It's a sad irony of the world that, just as the people who you most count on to be smart end up disappointing you, so the people who you count on to be dumb end up being much smarter than you'd like them to be. The guy who put several time bombs into his programs before being fired -- and brought a coast-to-coast application system down for several days -- was actually fired for incompetence. He was certainly an incompetent programmer, but you don't have to be really smart to be really nasty. It is true that no security system is perfect; somebody smart enough and experienced enough can probably break into any computer. We don't expect our computers to be KGB-proof. However, it doesn't take that much smarts for a user to come up to unattended terminal and try a :LISTACCT just to see if it works; for an operator to look at the printout of a job stream and see the MANAGER.SYS passwords embedded inside it; or even for an accountant (who is, after all trained in juggling numbers) to see a gaping hole in the system security and find temptation too hard to resist. Though there's a limit to how much you ought to invest in your system security -- going from 99% security to 99.5% may not be cost-effective -- there are a lot of inexpensive things you can do protect your system from very common security threats. THE WORST MYTH OF ALL -- "IT ONLY HAPPENS TO THE OTHER GUY" The most pernicious myth about system security is also the hardest to deal with, because it's psychological rather than technical. Nobody wants to think of themselves as a possible victim; nobody wants to think of their co-workers as possible thieves or saboteurs. Many people don't realize the importance of security until it's too late, until tens or hundreds of thousands of dollars have been spent on recovery when a couple of thousand dollars worth of prevention could have avoided the whole mess. All because of the myth of "it can't happen here". We've seen too many sites fall under the spell of this myth -- don't let it happen to you!
Go to Adager's index of technical papers