Archive: April, 2007

Security management has a lot to do with details — staying on top of the latest threats and patching flaws. But sometimes, it has more to do with the big picture and how you approach security management. Here are the top 10 security mistakes I've seen people make:

1. 1. Trusting people: The biggest threat to your IT security is ALWAYS the trusted employee. This is especially true of executives because poor personal security practices are just as dangerous (or more dangerous) as having a dishonest employee. If you ever need to cite an example, remember that one former CIA director actually accessed "company" files from his unsecured home PC. President Bill Clinton had to give Director John Deutch a Presidential Pardon to prevent prosecution.
2. 2. Thinking your OS/server/Web app/wireless network/whatever is already secure: Having confidence is a wonderful thing in business and life in general, but paranoia is KING in security.
3. 3. Failure to confirm that your disaster recovery plan actually works: Is that backup comprehensive? Is it scheduled (and actually done!) frequently enough? Can you restore your business from those backup tapes? And, most critical of all, is the backup kept physically secure and physically separate from your servers?
4. 4. Incorrectly prioritizing the protection of specific assets: Few of us have the resources to protect everything completely. In the real world, you need to know what the most important things are to your company so you can protect those assets the most. One size does NOT fit all.
5. 5. Failing to convince upper management of the need for security -– especially integrated security: If management doesn't support your measures, you might as well just take your paycheck and ignore real security. You can't have real security if you just add it AFTER designing and developing your network and applications.
6. 6. Forgetting that road warriors WILL use unsecured wireless access points: It doesn't matter what rules you make or how draconian the punishment, road warriors WILL ignore security rules when they feel it hurts their bottom line.
7. 7. Not properly managing passwords: Make them long and easy to remember -– initial letters of words in a favorite quotation are often a good choice; final letters of those words are even better.
   While we are on the subject of passwords, you need to balance the need to re-enter passwords against the fact that the more often users have to key them in, the simpler the passwords they will pick. Once a day is the minimum, but how about after lunch? Or each time a critical application or database is accessed? The answer is that it depends, and it is up to YOU to decide what it depends on.
   Keeping passwords, even strong ones, for too long a time is a major mistake. Not only does this give attackers a lot of time to test your system, but once you're hacked, you'll remain vulnerable for a long time.
8. 8. Supplying help desk support without thoroughly authenticating callers: Social engineering is still a serious threat.
9. 9. Mistaking obscurity for security: People WILL find that Web page you think is hidden -– even if you don't have a search function. Many search engines let people search just a specific URL.
10. 10. Writing down ALL your security measures and failing to properly secure that document: There's nothing like finding a guide to hacking a particular network. While you should write everything down, you have to protect that document better than anything else in your company.

Mistakes 11 through 99 are all the same: "Not being paranoid ENOUGH!"

Perhaps the most important security mistake is the one not on this list — thinking the list doesn't apply to YOU. 

I've left out a few obvious items, such as failure to update security software and not monitoring the need for updates, especially security updates — I presume we are all professionals here. Obviously, this list will need to be adjusted to fit your specific needs, but if you feel I've missed something completely, please add your suggestions in the comments.

In the previous installment of this series, we secured the scene and captured the general state of the crime scene with photographs. We arrived at the point at which we're ready to collect evidence.

The actual collection of evidence is a critical step in the investigative process. Each piece of evidence collected must be handled in a way that preserves its integrity and any trace evidence, and that provides for a detailed record of its whereabouts from the time of collection to the time it arrives in a court room. Failure to pay proper attention to any one of these areas can easily result in one or more pieces of evidence having no value in court or in administrative proceedings.

Once an object is identified as evidence, it must be tagged. Evidence tagging helps identify the collected item. The tag can consist of as little as a sticker with the date, time, control number, and name or initials of the investigator. Using a control number is an easy way to identify a piece of evidence in documentation such as a chain of custody. A tag can also be an actual document that contains general information about the item and the incident under investigation. Photo A is an example of an evidence tag form.

The types of evidence that should be tagged include:

• Removable media
• Cables
• Publications
• All computer equipment, including peripherals
• Items taken from the trash
• Miscellaneous items (e.g., notes or reports)

Once the evidence is tagged, the investigator should photograph it in a way that also displays the tag information. This becomes another way to document what was collected and how it was processed. When taking pictures of computing devices, the investigator should include all interfaces. If a cable is attached to an interface, it should remain connected during the picture taking process. It's a good practice to clearly label each attached cable with the associated peripheral device before taking interface photos.

After photographs are taken, the evidence is bagged. Bagging evidence helps protect and organize items through the assessment, documentation, and presentation steps. Consider the use of Faraday and antistatic bags when magnetic media or handheld communication devices are seized.  A Faraday Bag prevents harmful RF from altering magnetic media. It can also help prevent handheld devices from sending/receiving messages or any other types of data. 

Photo B is an example of a standard sealable evidence bag. Although formal evidence bags are nice, a simple collection of resealable storage bags works just as well.

Photo B (Click here for larger photo.)

When an item is bagged, a chain of custody document must be initiated. It is this document that provides critical information about who handled the evidence, why there was a change of possession, and how each person safeguarded it. A PDF version of the chain of custody document I use is located here. Failure to record any change in possession of a piece of evidence is an open door to having it excluded in legal or administrative proceedings. The chain of custody form should be affixed securely to the evidence. For example, consider stapling the form to the evidence bag. 

Prior to transport to a security vault, it's a good idea to place individual items into a large container. This helps protect the integrity of the evidence and reduces the chance that one or more items might be lost in transit. Here are some things to remember when transporting evidence to the evidence vault:

• Prevent damage caused by evidence moving around in a trunk or by travel over rough roads.
• Do not leave the evidence unattended in the transport vehicle. In addition to damage by environmental conditions, the evidence chain of custody might be broken before the evidence reaches the investigator's office.
• Avoid damaging environmental conditions, such as temperature extremes, humidity, etc.

Once the evidence arrives at the investigator's office, it must be secured in a locked room, safe, cabinet, or vault that has restricted access. The ideal situation, and one that ensures a clean chain of custody, is the presence of a single individual who is responsible for receiving, securing, and signing out evidence. Sometimes known as an evidence custodian, this person has full responsibility for ensuring continuous secure storage for all evidence collected.

In the next installment in this series, we'll start looking at how to acquire evidence from desktop or laptop computers.

In an April 23 article, USA TODAY reported that foreign hackers are using "tainted Microsoft Office files" to compromise the computer networks of select federal agencies as well as nuclear and defense contractors. To the casual reader, the article gives the impression that these attacks are a new phenomenon — wrong. Office macro viruses have been around since the Concept virus was released in 1995. In 1999, the Melissa worm targeted Word 97 and Word 2000, clogging e-mail servers as it spread.

Unfortunately, convincing an unsuspecting person to install a piece of malicious software is still one of the easiest ways to gain unauthorized access to a computer network. Fighting such attacks requires educating end users and effectively using technical countermeasures.

The following PowerPoint presentations can help you with both these tasks:

• Educate your users about e-mail safety with this PowerPoint presentation
• Explain security policies with this presentation

Microsoft has been loudly touting the security improvements in Windows Vista as compared to Windows XP. However, there seems to be some dissention within the software giant's ranks.

According to Mark Russinovich, a technical fellow in Microsoft's Platform and Services Division, hackers will simply adapt their attacks to the Vista environment (Nick Farrell, "Microsoft admits Vista security won't change much," The Inquirer, 24 April 2007). Russinovich predicts that even UAC will be vulnerable. If Vista doesn't provide any additional security, why would an organization go through the painful process of upgrading?

In my opinion, only sound security practices can protect any endpoint device. One of the most important of these practices is implementing accounts using the principle of least privilege. With Vista, Microsoft has moved in the right direction by addressing the need to allow users to log in as local administrators in order to perform minor system administration tasks. Restricting local administrator access to only a restricted group of support/engineering personnel is the best defense against unwanted software installations. This is often easier said than done.

Many vendors have not yet jumped on the Vista bandwagon. Organizations might still find themselves forced to allow local admin access for business users so certain applications function properly. So how can we continue moving in the direction Microsoft is headed?

First, we need to provide only minimal access to endpoint devices. Situations in which elevated privileges are required to execute applications should be treated as exceptions. 

Second, organizations must pressure vendors to write applications that perform tasks without elevated privileges. Some of you have told me that this is a futile effort, but I disagree. When requests for proposal consistently contain requirements for least privilege operation, and when customers start making purchasing decisions based in large part on security features, responsible vendors will listen. 

Finally, educate users. Whether in XP or Vista environments, business users must understand the need to carefully consider any request to install an application on their endpoint devices. Of course, taking this decision-making process away from the end users is the best solution. Used properly, UAC can get us there. But we have some distance to travel before we arrive at a place where technology protects users from themselves.

There are multiple critical remote code execution and DoS vulnerabilities in Macintosh OS X versions 10.3.9, Server 10.3.9, 10.4.9, and Server 10.4.9. The 25 vulnerabilities are a mix of locally and remotely exploitable threats.

Here are links to the updates: 

• 10.3.9 Client 
• 10.3.9 Server 
• Security Update 2007-004 Universal 
• Security Update 2007-004 PCC

SuSE security updates

SuSE has patched some moderate but concerning security vulnerabilities in many versions of SuSE Linux, including (but not limited to) versions 9.3, 10.0, 10.1, openSuSe 10.2, and Enterprise Server 8. See the SuSE.com update site for links. 

The multiple vulnerabilities are due to problems in XFree86 and Xorg. For more details on some of these threats, check out the French Security Incident Response Team advisory #1217.

In what I personally can only describe as OUTRAGEOUS, Research In Motion has refused to disclose any details on the subject of this week's major North American BlackBerry service outage. Canadian reports published today say that the company is not returning media e-mails or phone calls about the outage.

According to a Reuters article on WashingtonPost.com, the outage was caused by a new feature related to temporary message storage and wasn't due to a security breach. The article quotes officials as defending their complete lack of communication as follows:

"RIM's first priority during any service interruption is always to restore service and then establish, monitor, and maintain stability."

"Proper analysis can take several days or longer," it added, "and RIM's commitment is to provide the most accurate and complete information possible in such situations."

Yeah, right! Everyone in marketing and PR who would be putting out press information was co-opted to help the technical people track down the problem.

Pull the other one. 

Even this morning, after some selected (favored?) media outlets reported that there's been an official explanation/statement, the RIM Press Web site remains silent about the problem. Now I'm not complaining about the lack of a full and complete explanation – that obviously can take time. In addition, details could possibly entail the release of proprietary information or too much detail that could lead to security concerns.

BUT TO SAY NOTHING? That smacks of a lack of concern for subscribers and, worse yet, a lack of understanding of how to manage such events. 

What do you consider the most serious part of this whole disaster?

• The mere fact that CrackBerries were unavailable to those who consider them a vital communication tool?
• Or the fact that Research In Motion totally failed in its responsibility to keep in front of this outage by communicating with the press and subscribers?
• Even worse, how many marriages were ruined by this outage that may have caused a number of CrackBerry addicts to look up from their devices and discover that they had a spouse and children?
• Or, is my outrage over the lack of information from RIM your biggest complaint? 

I'm still getting scattered reports of outages, and RIM has failed to respond to my query about whether any messages were lost during the outage.

(Disclaimer: I used to work for Post-Newsweek, but have no current connection with the publications — and, NO, I wasn't fired (GRIN).) 

The vast BlackBerry network is malfunctioning in North America, and the cause is not clear at this time.

The outage may be due to software failure or malicious action, but what is important at this time is that everyone – from press to politicians to IT managers – is currently without e-mail service. Here are some details:

• ABC reports that this is a network-wide outage that began around 8 P.M. EDT time last night. 
• Bloomberg Radio reported at 9:30 A.M. today that some users in New York City are telling Bloomberg that they now have service.
• Cnet's News.com reports that BlackBerry vendor Research In Motion is not giving any timeframe for restoring full service. 
• Scattered reports on the Internet say that service may not have been disrupted in Europe or Asia. However, telephone message at Research In Motion headquarters emphasizes that both incoming and outgoing messages are disabled for some users. 

Perhaps the biggest immediate problem for the company that provides mission-critical e-mail service to upwards of 8 million customers is the fact that there is little or no information coming from the vendor regarding this outage. This fact could lead many users to question the wisdom of relying on BlackBerry messaging for mission-critical services, particularly in IT management.

• At 10 A.M. on April 18 (14 hours into the outage), the last press release on the BlackBerry web page is dated April 2.
• A 9:51 A.M. report on Reuters said that Research In Motion states the service has been restored for most users.
• By 10 A.M., there was still no mention of the outage on the BlackBerry North American Support page.
• Bloomberg Radio reported at 10:05 A.M. that an AT&T spokesperson had told Bloomberg Financial Network that BlackBerry service had been restored, so the outage may be over. 

How about you? Do you rely on BlackBerry service for mission-critical messaging? Did you experience an outage? And, critical for mission-critical services, did you even know your BlackBerry was down? Or were you just happily basking in a brief period without any annoying messages?

I remember when the Internet got started; my former college roommate worked for a little place called BBN, and actually, to be really honest, I'm old enough that I recall when DARPANET started. Back then, the "Net" was not only limited to academics and a few in the government, it was actually considered experimental in exactly the same way the Altair 8800 was when it made the cover of Popular Electronics in January 1975. 

A lot of people today simply weren't around then. They just don't realize that today's Internet is little more than an academic experiment that grew so fast and so uncontrollably that those who rely on it today as the most mission critical of technologies for their business really don't understand why it keeps failing and why it will, by necessity, continue to fail to provide a secure work environment.

Take Microsoft Windows, for example. Sure, the code is pretty sloppy, and security has, until recently, been treated as an afterthought — but stop and think. Just how many of today's Windows vulnerabilities are related to the fact that Windows was invented when the Internet, and the World Wide Web in particular, were still being treated by many institutions as a grand experiment? 

Is it any wonder that Windows is insecure? It was built on MS-DOS, which mainly faced the security challenge of avoiding attacks that came on 5¼-inch floppy disks. But Windows wasn't designed to withstand this sort of constant attack — is it any wonder that it fails to defeat every attacker?

Today we have spam, phishing, and a constant litany of new attack vectors, but all of those are related at their core to the fact that all of today's popular operating systems were created before the WWW became a mission-critical part of business and government operations. The Internet and the WWW were simply too useful for business to ignore, but they were far from ready for prime-time use when business co-opted them into corporate service.

Today, the National Science Foundation wants to recreate the Internet through an experimental research network termed the Global Environment for Network Innovations (GENI), while the EU is backing Future Internet Research and Experimentation (FIRE). Major universities around the world, including CMU (100×100) and Princeton (PlanetLab) here in the United States, are all working on extensions or replacements for today's Web. And those are just a few of the major projects now under way or being proposed. 

But I don't think there is much room for real debate over whether the Internet needs to be overhauled. Like global warming, only by hiding your head in the sand can you fail to see that this is broken. 

I think the real question that faces all of us today is whether we are willing to continue to bet our businesses and personal privacy on a patchwork network that will be extended with some of the better ideas taken from some of these new projects. Or is time to do a cold restart and junk the Internet as it exists today (or, at most, keep it around as a legacy network just for kids to play with)?

For 20 years we've lived through what it's like to have a patchwork system in place — do we really want to put up with that for the next 50 years? Or is it time to bite the bullet and rebuild a universal network from scratch, complete with all the security protocols we can think of?

Although many of us cheered when Microsoft designated a Patch Tuesday regimen for releasing most security patches, hackers quietly cheered also, and we are now beginning to see the unintended consequences of trying to make IT managers' lives easier by having regularly scheduled patch days.

Stop the patching madness by having a designated day each month (or quarter) when we can expect to see new software patches from a vendor — it seems like a great idea. It means we can schedule downtime and overtime to deal with the patches and the testing required before any sane IT security specialist would apply a new patch to all the systems under his or her control.

And for a while it seemed to be working just fine. But recently, a new element has reared its ugly head: Hackers have recognized that the best way to have a long time to exploit newly discovered vulnerabilities is to begin attacking them just a day or two before the scheduled patch release date. It's too late for a vendor to add the new vulnerability to its patch, and it gives hackers a full patch cycle or more to take advantage of the newly developed exploit.

I use Microsoft because it's the most obvious example, but the same logic applies to any vendor that institutes a fixed patch release schedule.

What's your opinion? Should Microsoft abandon the regularly scheduled patch day because it lets the enemy know when it's safest to attack? Or does the convenience for IT managers far outweigh the unintended consequence of giving the bad guys (and gals) the longest possible time to plan and execute attacks? Or do we not have enough data yet to make another change that's likely to result in yet more unintended consequences?

A newly released Microsoft Security Advisory warns that the Redmond-based company is investigating reports of attacks taking place against Windows 2000 Server Service Pack 4 as well as Windows Server 2003 SP1 and Windows Server 2003 SP2.

The Mitre CVE reference for this is CVE-2007-1748. Details are few at this time, but Microsoft's report confirms the existence of the vulnerability, specifically a stack-based buffer overrun in the the Remote Procedure Call (RPC) interface.

The attack can not take place through port 53.

Until a patch is released, one workaround is to disable remote management control over RPC by editing the registry. The advisory provides details.

According to the advisory, another step you can take to protect your system is to "block all unsolicited inbound traffic on ports between 1024 to 5000."

This is breaking news, so please continue to check the security advisory for any details that may change as the situation becomes clearer.

UPDATE 

Microsoft has updated the original security advisory with additional information about mitigation and about the Small Business Server: 

"April 13, 2007: Advisory updated to include additional details about Windows Small Business Server. Mitigations also updated to include additional information regarding the affected network port range and firewall configuration. Additional details also provided for registry key mitigation values."