Mad Dog 21/21: Something Wiki This Way Comes
January 17, 2011 Hesh Wiener
|
If Bradley Manning had become a quarterback like Peyton Manning or Eli Manning, Julian Assange might never have been accused of having a greater aversion to condoms than the Pope. Instead, Bradley Manning is in the brig, accused of pilfering classified material that ended up in the hands of Wikileaks, which one might want well washed before shaking. From Wikileaks, the fishy secrets ended up in the fish-wrappers produced by the New York Times, the Guardian, der Spiegel, and elsewhere. It’s all enough to make most any IT professional (even you) pay a little more attention to system security.
In the case of the stuff that got to Wikileaks by means that remain (and may always be) obscured, an outside view of the situation based on press accounts and guesswork might suggest that the vulnerabilities that were exploited were more a matter of policies than software. But that kind of explanation risks separating things that in practice are not so easy to separate. System policies are not just about rules and wishes, they are mainly about software and settings. So, when a shop tries to lock down its data, even in computing environments as potentially secure as those on an IBM i box, the effort may fall short. Time and again, here and elsewhere, users have been advised to do double-check a few basic things about their systems. The most common points made by security experts seem to be:
Am I preaching to the choir? Maybe. Security isn’t an easy sell, because if it’s done right there are no dramatic results to show to the suits. There are however, some things that IT personnel can do to bolster a case for investments in protection. Every system that provides Web serves will have logs, and the logs might be pretty dramatic. The data this site’s servers capture in the ordinary course of business show that hacker and robots persistently try to breach security; the hacking issue is almost inexplicable, because our servers exist so we can share our news and information with anyone who is interested. Go figure. But commercial companies are in a different situation. Intruders might be able to reach data that is private and confidential. And insiders bent on mischief? Forget about it. Last month, Wayne Evans published an essay here in which he hit the key issues in security planning. He put policies at the top of his list. “Policies” is a polite way of saying user management. While it can be awkward to set limits on user access, particularly if an IT shop has a history of running in a freewheeling manner, it really is a good idea. If Bradley Manning didn’t have access to so much data he might not have become a poster boy for American ineptitude and Julian Assange might not be starring in Attack of the Killer Groupies.
Evans also said that there are too many ways for IBM i systems to connect with external systems that have to be watched or blocked. He made it clear that most user organizations find managing exit points just plain overwhelming. There are plenty of software products that bring management within the reach of typical user companies, and he provided a pretty good list of vendors. From the tone of the article it’s clear that Evans thinks most i shops don’t do a very good job of managing exit points (or managing other aspects of system security for that matter), and, unfortunately, he’s probably correct. Evans’ two-part essay lists other things he believes are common sources of risk at i installations, and his theme seems to be that user organizations just don’t do an adequate job of protecting their systems, even if they seem to be trying. But it might be wise to take Evans’ advice with a grain of salt. An ex-IBMer, Evans is not inclined to criticize Big Blue for failing to make life easier for users. Others, however, are not so kind to IBM. Several years ago, an Israeli programmer whose position is just about a dead opposite of Evans’ stance began to make himself known as a critic of IBM’s systems software. Shalom Carmel, who is hooked up with a technology company called Venera, set up a Web site called Hacking iSeries that is just what it says on the label. Carmel also wrote a book with that title about five years ago (sold by the site and by Amazon). The book and Web site explain some security flaws dating back to OS/400 and running forward to recent descendants. While Hacking iSeries is no longer fully up-to-date, neither are many i systems, so the material in the 258-page book and the examples on his download page may well apply to your shop. Basically, Carmel points out that, like other systems, IBM i can have potential weak points when it is hooked to the Internet. He provides not just general advice but also specific examples of ways a hacker can attack an i. (Some of these techniques also work on Unix systems that have a lot in common with IBM i when it comes to Internet services like FTP.) Carmel’s site notes that IBM cured some of its longstanding ills with OS/400 V5R2 and subsequent releases, but he also suggests that there are plenty of ways for troublemakers to go after a current i unless the system’s operators have done a pretty careful good job setting up their machines. Despite their dramatically different attitudes, Evans and Carmel share one key attitude: Both believe IBM i can be well protected from intrusion using features built into the operating system. But both also believe that an i box comes out of the box configured for easy setup and that a byproduct of this malleability is diminished security. All this leaves OS/400 and i users in a situation that at the very least demands an ability to review in detail a system’s history if something goes wrong. Basically, this means keeping an extensive collection of logs and journals and making sure they are protected from erasure, corruption and intrusion. Logs have three effects: They enable a user organization to perform extensive analysis of systems activities in the wake of any security breach. They allow an organization that is worried about ongoing activities to inspect and monitor systems. And the very presence of an intensive journaling setup can intimidate and discourage personnel from engaging in unauthorized activity. As Julian Assange probably would not choose to say, journaling can have a prophylactic effect.
|
