Year: 2003

The Suffering Servant

The assignment given for my New Testament course was to "write a biblical parable."

024 21AWhat I came up with is obviously not a parable in the traditional sense, but I like to think of it as the parable of parables; it is the story of a common theme that runs throughout the literature of the biblical time and that represents a fundamental (or at least well-established) part about how our society tends to work. In that sense it is a story that evokes a deeper meaning from itself when examined closely in relation to our own lives, as does a parable in its purer form.

Once there was a boy born of no great noticeable lineage. When he grew up, he found that he was deeply disturbed by the problems of the world around him and that he was going to devote his life to changing things radically. He found that he was a good speaker and had a knack for communicating with people in direct, powerful ways. He learned a lot about the problems he was facing and he lived and dined among those who contributed to them.

He began to talk, in public and in private, about the problems and about the fundamental causes and possible solutions. He would sometimes end up with large groups of people gathered around him as he talked. Though he had many followers who believed in his cause, he only had a few that he considered his true friends and true believers. Besides, it was becoming dangerous for him and his followers to talk about the problems any more because there were many who opposed his views or said that he had no right in the first place to address the problems because of who he was. After a while, his following and support got so large that it seemed he was actually making a difference. People were actually beginning to catch on to what he was saying, and at the same time becoming less accepting of those who caused the problems or who had oppressed their existence. Finally, his enemies decided that his words were too dangerous because they addressed deeply buried problems that, to face, would shake the very foundations of the world built on top of them.

He was tried and convicted by the attitudes of his time and by the prejudices of his enemies, and so they plotted to kill him as punishment. They did so, quietly and quite normally with the typical sort of lynching. He died, and in a fairly short time, the mission and movement that he had created did not have enough forward motion to sustain itself, and it died fairly soon thereafter.

This is the story of Jesus Christ. This is the story of Martin Luther King, Jr. This is the story of the poor and homeless person who fights daily to find a home and raise a family. This is the story of Medgar Evers, of Malcom X, of any man and woman that has ever stood up for what they believed in because they could do no other. This is the story and the song of the suffering servant.

Passive Entertainment Convergence

Okay, I'm not usually one to gripe, or even talk about, the horrors of keeping up with all my favorite TV shows and movies. But last night was just not fair. UPN was showing two episodes of Star Trek Enterprise (one of the two TV shows I watch), one at 8 and one at 9. The 9 o'clock showing overlapped with the season finale of The West Wing (the second of the two TV shows I watch), which overlapped with my travel and prep-time for the 10 o'clock theater showing of The Matrix Reloaded (one of the few movies I've bothered to see the premiere of). What's a Science-Fiction/Political-Fantasy geek to do? What kind of messed up cosmic forces come up with that kind of timing? Hmmm...the Borg collaborating with the people that kidnapped Zoe, working inside the Matrix? Nah.

Legal Morbid Buckeyes

I went to the Ohio BMV yesterday to get my Indiana driver's license converted to an Ohio driver's license. It went fine, but the "written" test that I had to take was a little bit different than what I remembered from my first time around. For one, the test is now computerized, which, given that I sit in front of a computer for far too many of my waking hours, meant that I picked up on the "subtleties of the interface" quickly.

But the other thing I noticed was how obsessed the test creators seemed to be with death on the roadways. Example: one question displayed a yellow, diamond-shaped sign with a "T" in it. The multiple choice answers were all fairly reasonable except for (D), which said "this sign means that someone was killed by a car at that spot in the road." Ahhh!! Just a few questions later, they displayed another yellow, diamond-shaped sign with a pedestrian crossing symbol on it. Answer (C): "This sign means that someone was killed by a car while crossing the street here." AHHHH! Scary.

Anyway, I passed with a 93 % and got my license. Phew. It makes me wonder if I would have done better on all of those high school Latin tests if they'd been computerized. (And if at least one of the answers could always be eliminated for ludicrous morbidity.) Sona si Latine loqueris.

Computer Security Audit Checklist

This document discusses methods for performing a thorough and effective security audit on a computer system or network. It will not specifically discuss the technical details of prevention on specific computer systems, but will rather provide a general checklist for examining the security on a computer system. (This document has aged somewhat, but the checklist items are still quite applicable. It's too bad that computer security isn't an area seeing more improvement.)

If you're interested in having me speak to your organization about computer security, please see my page on speaking requests. My company, Summersault, is available for certain kinds of security consulting services.

This document is not an authoritative or comprehensive one; you should check with the information management policy of your particular institution for steps to follow to secure your system. The author of this document shall not be liable for any damage, direct or indirect, incurred in the following of this advice. If you have experienced a security breach, you should contact an experienced security professional to evaluate recovery options.

Contents

  1. Physical Security
  2. Network Security
  3. Protocols / Services
  4. User Security
  5. Data Storage Security
  6. Passwords
  7. System Administration

1. Physical Security

Physical security is the MOST important part of maintaining the security of a computer system, and is often overlooked by careless system administrators who assume their occasional proximity to a system is enough protection. This may be sufficient for some systems, but in most cases, there are more factors to be considered before a system can be called physically safe and secure.

  • Is the system located on a sturdy, stable surface as close to the ground as possible?
  • Is the system safe from excessive sunlight, wind, dust, water, or extreme hot/cold temperatures?
  • Is this system located in a monitored, isolated area that sees little human traffic?
  • Is the room/building in which the system is located secured by lock and alarm system to which only a few trusted personnel have access? Are these locks and alarms locked and armed during off-hours?
  • Is the terminal of the system secured to prevent someone from casually walking up to the system and using it (even if just for a few seconds)? Are all users logged out from the terminal?
  • Are the power and reset switches protected or disabled?
  • Are any input devices to the system secured/turned off: are all removable disk drives locked/secured? Are the parallel/serial/infared/USB/SCSI ports secured or removed? Are any attached hard drives physically locked down to the system?

2. Network Security

Network security is the SECOND MOST important part of maintaining a system security. While good physical security can go a long way, if you operate your system in a networked/multi-user environment, the system is many times more susceptible to outside attacks than a standalone system. Network security is also harder to evaluate because it requires a thorough understanding of the various components and layers of your system and all the external services that interact with your system.

  • Physical network: is the network connection a secure "pipe" with no danger of unauthorized rewiring? Do only authorized personnel have physical access to the physical network to which the system is attached? Do you know and trust all of the various points where your physical network connection is managed/administered by another person or entity?
  • Are the other systems on the same network physically and electronically secure? If your system is reasonably secure but another system on the network is not, your system's vulnerability is increased greatly.
  • Approved Network Traffic
    • Do you know the names, functionality, vendor, and nature of the software on your system that participates in any network activity? Have you checked all the vendors for security patches, and do you regularly receive security updates about patches/vulnerabilities to the software you use in a networked environment?
    • Have you thoroughly tested any and all services that interact with the network to insure that they do not, by default, provide any unauthorized users with useful security information that could be used to attack the system?
    • Do you effectively limit your users` abilities to make sensitive information about the system available over the network?
    • Do you only allow trusted users shell/command line access to your system?
    • Are you aware of any security holes created by certain software packages interacting with each other?
    • Do you keep sufficient logs of all approved network activity?
    • Are you aware of all the software that should be interacting with the network, the port numbers they use, the size and location of their binaries, etc.?
    • Do user accounts that are accessible over the network regularly have their passwords changed?
    • Do you encrypt sensitive data that is transferred over the network?
  • Unapproved Network Traffic
    • Do you regularly check for repeated unauthorized attempts to connect to your system over a network? Do you keep sufficient logs of all network activity related to your system?
    • Do you regularly check for unauthorized programs running on your system that could potentially allow a user to connect over the network?
    • Do you monitor for excessive or unusual network activity that comes to your system?

3. Protocols / Services

Once you are past the physical and network layers of your system, the next category of evaluation is perhaps one of the largest; computers are made to compute, and depending the purpose of your system, it will be running many different kinds of software and programs at any point in time. It is likely in most cases that, because all of the software was written by different people with different understandings of security (and because there are always people who know more about security), at least one of those programs has some sort of security hole that could be exploited.

  • While it is generally safe to assume that software that comes pre-installed on a new system is reasonably secure, you should always check with software vendors for security patches, release notes, and other relevant information to your particular configuration.
  • For any software that you install onto a new system, make sure you are fully aware of the credentials of the vendor, any security patches, existing exploits, and release notes that exist. You should make it a habit to check in with vendors every month or so for new releases that may have security fixes. It's also a good idea to subscribe to mailing lists for your software, or general mailing lists, that would announce security holes early.
  • Misconfiguration is probably the most common cause of someone exploiting a security hole. Most software is written to be reasonably secure, but even the most secure software can be used for unintended purposes if it is poorly configured. Always follow the vendor's instructions for installing software, and always take notes on any problems you encounter in the configuration process. If a piece of software requires special privileges to be installed or run (e.g. running setuid on a UNIX system), make sure you understand the full implications of having it do so, and any side-effects created in the process. Test your configuration of the software thoroughly; try to break it, try to hack into it, and see if others can do the same.
  • If a program accesses sensitive data, make sure that it can only be executed by authorized users, and make sure that any logs or temporary information is stored in a safe place and promptly disposed of; people can do amazing things with the simple information found in a system log file.
  • If a piece of software runs as a daemon (i.e. it is constantly running and responds to requests from users locally or over the network), make sure it properly handles buffer overflows, denial of service attacks, and general heavy system load. It's generally a good idea to have as few services as possible running as daemons, as they allow continuous and typically unmonitored access to your system.
  • Be aware of all the services that are supposed to be running on your system, the typical amount of resources (e.g. CPU time, memory, disk space) that they take up. Check for unidentifiable daemons or software, or programs that are unusual in their resource consumption. Remember that most security breaches occur using the existing configuration of a system rather than installing a new one; unless you're careful, an intruder can manipulate the system to their liking and you won't notice anything out of the ordinary.
  • Run process accounting to keep track of typical software usage patterns of your users.

4. User security

The particulars of user security varies widely with the nature of the system you're running. In some cases, a system will be an isolated machine performing mostly server functions with very few users who actually log in to the system and use it directly, most of the users thusly being people interacting with the server functions. In other cases, a system might have hundreds of users directly accessing the system simultaneously. Obviously, the degree to which user security is a concern depends largely on the character of your users, but be aware that one user who attempts to breach security, or who has poor security practices, can affect and possibly endanger an entire system.

  • Develop a standard method for creating and maintaining user accounts. Develop clear and concise acceptable use policies, and publish them well to your users. Don't create user accounts for people or organizations whom you have not previously interacted with in some form, or who have been known to have security problems on other systems.
  • You should set limits on the amount of resources a user can consume, from number of logins to amount of disk space; make sure that the user cannot cause a security breach or take down the system out of pure stupidity (e.g. a recursive script that creates a 10 M file each time)
  • In some cases, you may want to limit the manner in which a user can connect to the system; if you're providing a terminal login, make sure the terminal itself is secure and reasonably maintained. If you provide direct access via protocols such as telnet, consider running services such as tcp_wrappers or identd that verify the user is connecting from the system they claim to be connecting from.
  • Keep accurate logs of user activity; specifically, connection time, connection duration, and the place where they logged in/connected from. In some cases you may want to log more detail with process accounting, user command history, and activity monitoring.
  • You should regularly check for irregular user activity; there are many programs available that constantly "patrol" for failed attempts on the part of users to gain administrator privileges, access files that they shouldn't, or perform other unauthorized tasks.

5. Data storage security

Data and file storage, at first, does not seem to present itself as a security risk; either people have access to files or they don't! In reality, it turns out that there are many and complicated ways to access the same data on a given system, and a good system administrator should be aware of these schemes.

  • Know the file ownership scheme that your system implements; is it group based, user based, role based, or some combination of these? Know the different levels of protection you can apply to files and directories, and be aware of who has access to make changes to these protections.
  • Know the general structure of your filesystems, how much is stored where, and who typically accesses what parts of them. Keep logs of disk activity (e.g. significant changes in disk space used) and of any disk problems.
  • Make sure that users are only able to access the parts of the system relevant to their use of it; your protection scheme should clearly and easily include a logical and conceptual separation of user and data files from system files.
  • Make sure that the file ownership schemes are consistent for various directories (i.e. that the owner of a directory owns all the files in that directory, etc.)
  • Insure that users cannot have access to more disk resources than you intend; often user disk quotes are the best solution to this.
  • If your filesystems are available via any sort of network or sharing protocol., carefully examine the security of these protocols (see the protocols/services section above). Always check your configuration of these services to make sure that only authorized users and hosts are allowed to access shared data; many configurations by default allow for unauthorized access.
  • Always maintain secure backups of a system; the most standard conventional method is to backup files to a tape disk and then to remove that tape from the site to guard against data loss from fire, flooding, etc. In the case of operating systems, it's a good idea to maintain a known good copy of your operating system's configuration on a read-only media such as a CD-ROM.
  • If you maintain any databases, make sure that the database is accessible only to authorized users, both on the client side (via a data querying tool such as SQLnet) and on the server side (i.e. the actual database files stored on the disk drive of your system). As with other services, make sure any network and sharing of databases is done securely.

6. Passwords

Passwords are the central components in most security schemes; user accounts, sensitive websites, system services are all protected by them. If you know the right passwords, you can gain administrative privileges on a system where you may not even be a user or infiltrate an environment you've never even worked with before. They are conventionally accepted as a good way to implement security because they can be incorporated easily into most operating systems and sensitive software, and yet can be made complex enough to be difficult to "crack", while still being remembered by a user. Their downfall as a security scheme are in their power; one password is all you need to have complete access to an entire system, and passwords CAN be cracked. The best you can do is try to make these two events very unlikely.

  • Require unique, complex passwords for all user accounts on your system; it's not acceptable to have "guest" accounts or other accounts that don't require any sort of authentication. If an account is not ever used for connection (i.e. that account will never be accessed), remove its ability to login altogether.
  • Passwords should contain at least 6 characters and have a combination of letters and numbers, uppercase and lowercase. Passwords should not resemble any word, name, idea, or concept that might appear in any dictionary anywhere in the world. A good example: jY2EHxqy
  • Enforce password rotation and expiration; users should never be able to keep a password for more than a few months at a time, as someone could easily (but unnoticeably) brute force hack a password over a long period of time. You should also advise users against using the same password in other places.
  • The password file or similar mechanism for storing the passwords should be encrypted, and should not be available to the average user if possible (e.g. via shadowing). If a user can obtain the password file, they can use another system to try to crack the passwords without you noticing.
  • Never write passwords down or store them in anything but human memory.
  • System passwords should be changed at least once a month, and should not be shared with more people than is necessary.

7. System Administration

Quality system administration techniques can make all the difference in security prevention. There's not a lot required for most modern systems; many do self-checks and keep the system administrator automatically informed of any suspicious changes. But there are still a few general tips to follow:

  • Regularly browse through your system, looking at the contents of system directories, logs, and other files. Note file locations, file sizes. Observe the usage patterns of your machine and your users.
  • Run cracking tools (such as "CRACK" and "Satan" in the Unix environment) regularly to check for vulnerabilities in your system configuration
  • Manually try to break into your system through different means.
  • Be aware of persons or groups who may have intentions of breaking into your system.
  • Keep your users advised of your techniques and what you expect of them to maintain security.

Fighting Spam

Today I had a speaking engagement on combating unsolicited junkmail (spam). It was one of my first opportunities to speak about this topic to a public audience, and I was glad for the chance to share all of the knowledge I've accumulated about what is increasingly the bane of the Internet. A lot of people seem to be content to hit the delete key as they sort through their e-mail, but I think many are realizing that this approach doesn't "scale" well -- insert here numerous statistics about how much it costs and will cost in lost productivity, abused resources, deaths of baby seals, etc. The participants in my seminar were thirsty for details about the phenomenon and how to make it go away. I think the complexity of the issue can be surprising to some, so end-user education is one of the best things one can do to address the problem.

Any way you look at it, spam sucks, and it's not going away. As it becomes more of a problem, folks will look for better solutions, and I'm glad that I'm involved in that effort.

Trying out blogging

I've resisted the weblogging phenomenon as long as I could, mostly because I knew I would obsess over doing it right once I started. You're now reading the initial stages of that obsession: announcing that I'm blogging within a blog. Okay.

Anyway, it's not my intention or desire to spew random and intimate facts about my personal life that might make both of us uncomfortable next time we see each other. Rather, I'm looking forward to using one of the most casual mediums available to publish whatever thoughts I'm tossing around on a given day without committing to writing a formal essay or publishing a whole separate web page on my site. Maybe this is a product of laziness, but I wasn't doing a lot of public writing anyway, so let's see how it goes.

The Grill

I have this problem with impulsiveness. On Sunday, Carrie and I were sitting in the park, soaking up some of the first real sun of the season, and we reflected on how nice it would be to grill out that night. Stating what I thought was a minor detail, I noted that we did not, in fact, possess a grill.

No problem! The Modern American Way dictates that even though it's 6 PM on a Sunday evening, one should still be able to go from soup to nuts, no grill in sight to happily grilling out, with just a few stops at your handy neighborhood megastore.
Continue reading "The Grill" →

On the Nature of Civil Protest

I wrote this in reflection upon a conversation I had with a friend who was heading off for a weekend of protesting against the U.S. Government's "School of the Americas". There was the potential that my friend would be arrested, but there was also the general sense that it would be an exhausting and draining event. I asked her about why she was doing it, and a wonderful conversation ensued. These are some of the thoughts that remain. It's not done yet, thus the weak ending.

In every good conversation, the participants ideally exhibit a mutual desire to communicate their thoughts, share their ideas, and help the other participants to understand what they are trying to say. The conversation takes place because all of the participants recognize the significance and benefit of engaging in conversation with the other participants to communicate but also for the sake of conversation itself. The conversation is able to take place because all of the participants recognize that the other participants share the desire to engage in conversation.

In every good argument or debate, the participants ideally exhibit a mutual desire to convince the other participants that one view on a particular issue or series of issues is more appropriate, suitable, correct, or right than another view on the same issue or series of issues. The participants in an argument attempt to achieve this goal by explaining and detailing the point of view that they support in the context of opposing or refuting the points of view of the other participants, or sometimes affirming some parts and opposing other parts of a generally opposing point of view. Arguments and debates take place because participants recognize the opportunity to gain from discovering or acknowledging a particular point of view as more appropriate, suitable, correct, or right than another, whether it be the gain of personal knowledge, argumentative victory over another participant, or some other form of gain (not necessarily a positive gain).

Arguments are able to take place because participants recognize a need or desire to engage in the process of attempting to determine a more correct or appropriate point of view on a particular issue. This need or desire can arise from external pressures, personal passion about the issue or the argument itself (sometimes leading to physical combat), mechanical process, or any number of other sources. In all cases, participants recognize one or more of the other participants as being worthy of engaging in the argument or debate; they accept that the participants have a valid place in the process of argument, they recognize that the argument or debate has the potential to benefit themselves and possibly the other participants, and acknowledge respect (or present a façade of respect) that the other participants are suitably equipped to engage in the argument.

In every protest or act of civil disobedience, the participants making the protest or committing the act of civil disobedience exhibit a mutual desire to express an opinion about a particular issue or series of issues. The nature of protest and civil disobedience do not necessarily require that the parties holding, authorizing, enacting, or maintaining the views being protested against voluntarily participate in the event or even recognize the event as a valid "conversation" or "argument" as they were defined above. In this sense, it is not a conversation between two or more willing participants, but only an act of expression by participants representing only one point of view, directed at the parties holding, authorizing, enacting, or maintaining the opposing views.

This may be the case for several reasons. The opposing party may have refused the request of the participants to engage in a conversation or debate on a particular issue. The participants may have previously engaged in a conversation or argument that did not reach conclusion satisfactory to one or more of the participants. The protesters may desire to surprise or intimidate the opposing participants by initiating the protest or act of civil disobedience without advance notice. The protestors may not feel that they have available to them appropriate means by which to engage in a conversation or argument with the opposing parties, due to various power structures, logistical concerns such as time and place, or other factors.

By engaging in protest or acts of civil disobedience, these participants do, however, make the opposing parties a part of the conversation or argument, albeit unwillingly, in the following manner:

  1. The protesters imply a degree of responsibility for engaging in a conversation or acting lies with the opposing party;
  2. The protesters acknowledge that the opposing party is the most suited for taking on the role as an authoritative participant in a discussion on the issues in dispute;
  3. The protesters acknowledge the opposing party's authority or right or obligation to deal with the issues in dispute.

There are negative consequences associated with this approach to a conversation or argument. Because the opposing parties may not desire to be unwilling participants, they may react to the acts of protest or civil disobedience unfavorably. The structures (governmental, social, or otherwise) of the location in which the protest takes place may require or facilitate that the protesters` actions be halted or oppressed. Protesters or persons performing acts of civil disobedience may be subject to immediate consequences such as incarceration, injury, and death, or long-term consequences such as social displacement, internal conflict, or others.

In the sense that some participants are brought in unwillingly, protest or civil disobedience happens because the protestors recognize the potential for their actions to directly or indirectly impact the views and actions of the opposing parties. By participating in protest or civil disobedience, the participants exhibit a degree of respect for the opposing party to recognize, process, acknowledge, and act as a result of this impact. While the protesters may not necessarily place all responsibility for such processing and/or action with the opposing party, the notion of expectations between participants (be they willingly so or not) does arise.

Protest or civil disobedience are appropriate, then, when the potential for this impact on opposing parties outweighs the potential negative consequences of action. Protest or civil disobedience is successful when the opposing parties become willing participants in the conversation or argument about the issues at hand because they have recognized the nature or depth of the impact on them.