The Times has a nice little article today about why Barack Obama will probably have to give up the use of his Blackberry - and e-mail altogether - when he becomes President:
As his team prepares a final judgment on whether he can keep using e-mail, perhaps even in a read-only fashion, several authorities in presidential communication said they believed it was highly unlikely that he would be able to do so.
Diana Owen, who leads the American Studies program at Georgetown University, said presidents were not advised to use e-mail because of security risks and fear that messages could be intercepted.
“They could come up with some bulletproof way of protecting his e-mail and digital correspondence, but anything can be hacked,” said Ms. Owen, who has studied how presidents communicate in the Internet era. “The nature of the president’s job is that others can use e-mail for him.”
Surely there's some middle ground to keep a President as tech-savvy as Barack Obama from being forced off of e-mail altogether? I mean, this is the guy who announced his VP pick by SMS text message, for crying out loud.
People sometimes ask me how much I think "The Government" is really listening in on our phone calls, e-mail messages, web browsing, text messages, and other forms of communication. I still apparently surprise people with my answer: for the purposes of my day-to-day life, I assume that every communication I send or receive using an electronic medium is monitored and recorded by someone else. And I'm not just talking about watching some rough meta-information go by and trying to deduce what we're up to - I'm talking about full access to the content of every single communication, in real time.
From the "I hope it doesn't happen but wouldn't be surprised if it did" department, I have some predictions and scenarios to throw out there about stuff that could happen sometime in the rest of 2008. I suppose this is mostly just a mental exercise for me, but maybe it'll spark some interesting comments/responses:
The price of a gallon of regular unleaded gasoline in the U.S. will hit $6 a gallon sometime this Summer, and perhaps $10/gallon or more by the end of the year. Measures will be taken by the federal and state governments to temporarily alleviate the financial burden on some people, but nothing sustainable. Some people will not be able to get to work at all, while others will have to carpool more, take the bus, ride their bikes, and walk.
The U.S. will initiate military action against Iran, probably in the form of heavy air-strikes. There will be no clear notion of victory or desired outcome other than to significantly destroy the country's own infrastructure, especially targets related to nuclear facilities. This action might be justified to the American people by...
An apparent attack on one or more U.S. locations, resulting in significant loss of life or infrastructure.
The U.S. airline industry will significantly cut back or even cease flight schedules as we've known them, and air travel will (once again) become a privilege reserved for the rich and famous who can afford private flights. Any frequent flier miles you've accumulated will become worth near nothing.
Most grocery stores will significantly scale back their inventories and restocking schedules, and significantly raise prices on what remains. Obtaining food from non-local sources, even basic staples, will be difficult at best, and most communities will begin to take emergency steps to feed their residents.
Hey, look, I don't like the thought of these things happening any more than the next person, but perhaps there's some value in naming what might be, even if it seems a bit outlandish or gruesome. Maybe if we believe these things are possible, we might feel more prepared to prevent or deal with them if they do happen.
What do you think? Too cynical? Worse? What are some other scenarios?
Having some time to relax also meant lots of time to catch up on reading I've been meaning to do for a while now (though there's plenty more). Here's a quick run-through with my comments:
The Secret Life of Bees by Sue Monk Kidd. A great, compelling story that is so rich and enjoyable. Reminds me of how I felt reading A Prayer for Owen Meany or To Kill a Mockingbird. I can also recommend Monk Kidd's The Dance of the Dissident Daughter.
The Soul Tells A Story: Engaging Creativity With Spirituality In The Writing Life by Vinita Hampton Wright. I couldn't enjoy this one as much, perhaps because it seemed to define spirituality a little too differently than I do, and the resulting instructions/advice just didn't feel as applicable. It also wasn't as tightly structured as I would expect a book on creative writing to be.
Sometimes people forget how much information is being collected about them when they visit a website. It's actually not all that much - what IP address you're visiting from, what kind of operating system and web browser you're running, and perhaps what other website you came from in your visit. The real fun starts when you learn how to interpret the trends in that information, and start to drill down to what it might mean about a visitor.
For example, earlier this week, a user visited my website without any referring URL information. This means they probably entered the address directly in their browser's location bar, but it could also mean they followed a bookmark, or are actively trying to hide where they came from. As soon as they got to my site, they started searching for the word "congress" in my content. When I traced the IP address, it went back to a location in McLean, Virginia, which is the home of the Central Intelligence Agency.
So what can we conclude from this? Obviously, a CIA operative was investigating my website because in my ramblings about politics and the government, I've clearly come too close to the truth about a cover-up related to U.S. energy policy and the War on Terra, and now they're coming to take me away, ha-ha.
Bruce Schneier has saved future bureaucrats some time and written the core text of the 2015 US Congressional report on the impacts of the REAL ID Act. The report will find that the creation of this national ID card back in 2005 introduced unnecessary security risks, compounded existing data privacy issues, incurred extraordinary costs to implement and maintain, represented a troubling power grab by the federal government over state systems for issuing identification, and, perhaps worst of all, was passed without any serious debate in Congress or in public because of its attachment to a bill funding operations in Iraq. The report will also find that the ID card has not substantially met any of the goals its introduction was intended to achieve. Given the above, the report concludes that the REAL ID Act was a shining example of the quality and sensibility that characterizes much of the law-making that went on at the time.
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.
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.
I was actually looking forward to working late tonight. I had a client who'd asked me to do some work on a project related to some software I maintain. Because it's software I maintain outside of my usual duties at my company, I charge an hourly rate directly to the client, instead of going through Summersault. But even more than the higher pay, I was really looking forward to the particular problem space. The client sells real estate forms over the web, and maintains his order information in a database (a system I also helped to work on). He wanted me to design software that would produce a complex sales report against this database. I'd certainly done similar things before, but not ever quite anything like this, and so before I started working on it, I'd been thinking about the best approach. What data structures to use. Whether to do the sorting in the database or in the software. How to abstract the display of the data from the calculation of the data. These are the things that this 22-year-old white male thinks about on his way home from dinner on a Thursday night in Indiana.
I started around 11 PM and finished at 1:30 AM. I was alone but not lonely, the office was quiet, and I had some good techno/house music to keep me company. When I finished, I stepped back and looked at the software I'd created, proud of its design, excited about the satisfaction it might bring the client. I gathered my things with energy in anticipation of a good night's sleep.
As I turned out the lights and locked the door behind me, I noticed how hard it was raining and flipped up my hood. I didn't see the man in the black leather jacket coming around the corner right in front of me, and he gave me a bit of a jump. His hands were tucked in his pockets, his hair and face soaked to the point where he could barely see, and he was stumbling down the sidewalk not seeming to seek out any of the shelter that was available in the alcoves of the office entrances (including the entrance to mine). I had seen many other folks like him, wandering down the same street at the same time of night, some of them looking more dangerous and mean than others, all of them feeling quite distant from the world of databases and programming and websites from which I had just emerged.
I thought how sad it was that this guy was getting so completely soaked with no apparent end in sight. Maybe he was mentally handicapped and didn't know where to go? Maybe he was drunk and didn't know where he was? Maybe he was homeless and didn't really care if he made it to or from anywhere at all. With these thoughts in my mind, I got into my car, turned on the wipers and the heat and the radio and the engine and the lights, and started for home.
But when I came to the end of the block of our office, the man was alongside the car, and waved in at me. He came around to the front of the car and shouted something that I couldn't hear. I powered down my window cautiously, and heard him mumble something about "going to 12th street".
And this is the thought process we go through: His hands were in his tight jean pockets, probably nothing too harmless there. His jacket was bulky but probably didn't contain anything that could be used for beating me too severely - at least if he had a gun, he'd shoot me quickly and be done with it. I wasn't carrying anything with me that would turn my existence into a meaningless void were it to be stolen or damaged. He was stumbling around and looked off balance. I could take him. (I could take him on.) It was raining like hell.
"Get in!" I opened the door and he landed in the passenger seat. "Oh, my god, thank you."
We drove through a run-down part of town that I wasn't too familiar with, and headed out into an even less-familiar residential area that was actually just an industrial area with some homes and trailers scattered around it as a convenience to its workers. It was dark and there was no one around. His name was Herb, and he told me that he had been on his way to try to call his son, and then I saw that he did have something in his hand - two quarters. He said "I gotta pay you for this" and I told him that he didn't. When he insisted further (even nice, nonviolent people can be mean when you don't let them compensate you properly), I told him the quarter he was going to use to call his son would be sufficient. He gave me both quarters, muttering that it wasn't enough, and I put them in my car change drawer where I will probably withdraw them again in the future to cover the cost of an overpriced fast food item.
Confirming my suspicions that he was slightly drunk, he threw out a couple of names and asked me if I knew the guys, telling me that they'd all graduated together. He asked in a manner suggesting that because of this good deed I had done for him, I should know these men that he held in some sort of high regard. I was a little nervous but touched. As he made to leave, I said something stupid like "maybe we'll run across each other again some day and you can do the same for me." He said I was an incredible fellow. And then, after Herb had gotten out of the car, he turned around and looked at me, rain once again drenching his face and jacket, and said "You know what, though, this isn't anything like Vietnam. There, this stuff went on for forty days and more." With that, he tightened his jacket around his chest, closed the door, and walked off towards the house. These are the things a 50-something working-class white male thinks about on his way home from a bar on a rainy night in Indiana.
I drove away quickly, still fighting off wondering "am I safe?" as I headed to known parts of town. I couldn't have NOT picked Herb up from out of the pouring rain unless he displayed some outward sign of intentions to harm me. But beyond that, I'm *glad* I did it. The personal security I gave up was well worth some crystal clear perspective granted to me by the contrast that Herb provided tonight.
