A coworker made these assertions about security. I think they’re worth repeating:
- The purpose of security is to establish accountability of an individual.
- The purpose of auditing is to verify the trust that has been placed in an individual.
A coworker made these assertions about security. I think they’re worth repeating:
One of my past professors, Phil Windley, posted some principles of reputation:
Here’s a thought provoking article about the problems of large-scale data mining by
governments. It’s written by a person living in the UK.
“Data-mining is complicated, and the more data you are mining, the more
false positives your software will throw up. If you act upon a false
positive for a motoring offence, it’s an inconvenience for the motorist,
but for an alleged case of child abuse, it can rip the family apart and
ruin the child’s life.”
“Furthermore, gathering large amounts of data is inherently dangerous.
Whatever information governments find interesting will also draw the
attention of criminals. Databases can be hard to keep secure, and it’s
not necessarily hackers that we should be worried about, but
unauthorised access by employees of the agencies that use these
databases. Equally, the more data you have, the more difficult it is to
maintain accuracy. In 2000, an audit of the Police National Computer
found that 86% of records contained errors, 85% of those errors were
serious, and some were libellous.”
“Technology can be a very powerful tool, but what it can’t do is replace
real human beings or traditional investigative work. Designed badly or
used poorly, databases are the technological equivalent of fools gold.”
Crash-only software: More than meets the eye
by Valerie Henson July 12, 2006:
http://lwn.net/Articles/191059/
Properly implemented, crash-only software produces higher quality, more
reliable code; poorly understood it results in lazy programming. Probably
the most common misconception is the idea that writing crash-only software
is that it allows you to take shortcuts when writing and designing your
code. Wake up, Sleeping Beauty, there ain’t no such thing as a free lunch.
But you can get a more reliable, easier to debug system if you rigorously
apply the principles of crash-only design.
Apple explains how to controll Symbol Visibility in GCC 4.x. The benefits and drawbacks of hiding symbols are outlined. Has example code and compiler switches.
Bruce Perens tells us that patents impede innovation his article, The Monster Arrives: Software Patent Lawsuits Against Open Source Developers:
Patents were created as a means to get inventors to disclose their inventions, rather than keep them secret. The disclosure of an invention was supposed to allow others to more easily build on that invention, thus creating more inventions. But the patent system has evolved into something useless for the purpose of disclosure, and engineers are now instructed to avoid looking at other companies’ patents because if the victim of a patent lawsuit can be shown to have known of a patent, the award to the patent holder is tripled. There have been no reliable studies that show software patenting to have encouraged innovation, and there is much evidence that they actually impede it.
Here’s an interview with Zed Shaw, the author of the Mongrel web server — a web server for the Ruby programming language that is good for use in combination with Ruby on Rails and other Ruby-based web-app frameworks. It’s interesting in that it’s fast, secure, cross-platform, and it’s not a heavyweight solution (compared to Apache). Why is it more secure than Apache at the HTTP protocol level? Mongrel utilizes the Ragel State Machine Compiler
to generate the protocol parser, “and that is very strict and seems to block a huge number of attack attempts simply because it is so exacting.”
“Identity Theft” is societies catchy phrase for impersonation and fraud. Recently, my bank and other financial insututions have mailed advice on how to help prevent fraud, but they don’t ofen explain how to recover from it. This link has useful, step-by-step advice: HOW TO: Get through having your identity stolen.
Why encrypt a hard drive? It makes it safer to dispose of an old hard disk… your data won’t fall into the wrong hands. This only matters if you want data to remain confidential. Laptop owners should consider using hard disk encryption.
When is it a bad idea to encrypt a hard drive? First, if you have a dual-boot computer (Linux and Windows), and you want Linux to be able to access all of the data on the Windows drive. Second, when the data confidentiality is of low concern and the data availability is of high importance.
Bruce Schneier writes about Microsoft BitLocker, which will be available in Windows Vista:
BitLocker Drive Encryption is a new security feature in Windows Vista, designed to work with the Trusted Platform Module (TPM). Basically, it encrypts the C drive with a computer-generated key. In its basic mode, an attacker can still access the data on the drive by guessing the user’s password, but would not be able to get at the drive by booting the disk up using another operating system, or removing the drive and attaching it to another computer.
PGP Disk is a current solution — no need to wait for Vista. On Linux, there are many solutions. The most current is LUKS and dm-crypt:
Apparently, HAL in Fedora recognizes LUKS volumes. It’s also possible to encrypt only your home directory with LUKS.
Update 5 June 2006
See also http://www.truecrypt.org/ and Wikipedia’s guide to disk encryption software.
Professor Eugene Spafford “is one of the most senior and recognized leaders in the field of computing.” Here’s what he has to say about password security.
http://www.cerias.purdue.edu/weblogs/spaf/general/post-30
In the practice of security we have accumulated a number of “rules of thumb” that many people accept without careful consideration. Some of these get included in policies, and thus may get propagated to environments they were not meant to address. It is also the case that as technology changes, the underlying (and unstated) assumptions underlying these bits of conventional wisdom also change. The result is a stale policy that may no longer be effective…or possibly even dangerous.
Policies requiring regular password changes (e.g., monthly) are an example of exactly this form of infosec folk wisdom.
Read the article for more details.