A couple weeks ago, three technical support personnel, our lead developer, and I worked late to make some changes to the core architecture of the SpamStopsHere service. One saturday night, unbeknownst to any SpamStopsHere customers, a well planned system upgrade was performed. No announcement was made, because system maintenance was a regular part of managing the service, and no downtime has ever resulted from system maintenance due to redundant systems.

The system upgrade involved replacing every single node in the filter clusters to more powerful hardware that could process 10 times as many messages per minute. After several weeks of testing out the new configuration, we switched the nodes from the mostly dual-core CPUs running 32 bit operating systems on 4GB of memory and SATA drives to dual quad-core CPUs running 64 bit operating systems on 12GB of memory and solid state drives (SSD).

Replacing the hardware of approximately 100 servers in one night with zero downtime was made painless due to triply redundant systems, well documented installation instructions, well documented upgrade procedures, a shared google docs spreadsheet for coordination, and some pizza.

The satisfaction of replacing every single node, the core of the SpamStopsHere system, without a single glitch was enlightening. In the past, we had simply added more nodes to the clusters when more capacity was needed. The nodes were all of differing hardware because they were slowly added, and different hardware was available almost every time we added a node.  Some hardware performed better than others. This was the first time that we did a full replacement of every single node, rather than just adding more nodes.

Knowing that we have a well established procedure to basically build the entire system from scratch in under 12 hours is quite exciting. Should we ever experience a catastrophic failure of all four data centers, we know that we can have the service restored in just a few hours, and back at 100% capacity in under 12 hours. We also have the satisfaction of knowing that we don’t need to rely on any vendor. Should one of our data center vendors offer a service that we’re not completely satisfied with, we can very quickly move to another data center. Many hosted services are able to keep customers simply due to the imagined difficulty of switching vendors, and may provide shoddy customer service as a result. SpamStopsHere doesn’t need to worry about that. We have proven how quickly and easily we can reorganize our entire architecture, when needed.

Replacing aging hardware with brand new systems with brand new life cycle clocks is also very satisfying. SpamStopsHere expects to spend fewer hours doing system maintenance for awhile, and those hours can instead be invested in improving our service.

Although I would typically be hesitant about recycling this much hardware, when it’s still usable and not ready for the landfill, all of the hardware that was taken out of service was leased equipment that our data center vendors will recycle and offer to other customers. Although some of it is rather old, most of it will be reformatted and offered at special rates to new customers. The benefits are significant for our company’s carbon footprint. Our power consumption has dropped significantly, running at 40% of our previous usage.

If you don’t have redundant systems, or haven’t tested your redundancy, we urge you to give it a try. You’ll have many more restful nights after you’ve done a complete test of your redundant systems. The confidence in new hardware versus aging systems is also a satisfying experience that I recommend you take advantage of when the timing is right. Redundancy isn’t just for failures, it’s for doing software upgrades, hardware upgrades, and even complete hardware replacement, without service interruption.

Authoritative nameservers

When you register a domain under a Top Level Domain (TLD), the administrator of that TLD (i.e. “com”, “net”, or “org”) will ask you for the authoritative namservers for your domain. For example, if you register the domain “example.com” your domain name registrar will ask you for the authoritative namservers for “example.com”, and you might indicate these to be:

ns1.example.com
ns2.example.com

With the names of these authoritative nameservers on hand, whenever someone makes a public DNS query for resource records in your domain, the top level domain will refer the query maker to these authoritative nameservers. The top level domaind does this with “NS” type resource records.

Usually you will then manage the zone for your domain on these nameservers. You will also put “NS” type resource records in the zone for your domain, but these will be authoritative instead of delegating authority. when people want to resolve a resource record like “www.example.com”, they will consult the nameservers at ns1.example.com and ns2.example.com. This is how that query would play out:

Requestor: “Hey .com, what is the IP address of www.example.com?”

Dot Com Nameservers: “I don’t know, but ask ns1.example.com or ns2.example.com. By the way, here are the IP addresses of ns1.example.com and ns2.example.com.”

Requestor: “Hey ns1.example.com, what is the IP address of www.example.com?”

ns1.example.com: “I know the answer to that. The IP address is 1.2.3.4. By the way, the authoritative nameservers for example.com are ns1.example.com and ns2.example.com in case you have any other questions about my domain example.com.”

DNS caching

DNS caching allows us to temporarily store DNS information from a previous DNS query in our virtual rolodex, so that we can save the time of having to do a full search the next time we need the IP address of the hostname ”www.example.com”. However, to allow a DNS administrator to change records in their zone when they need, the owner of the zone is able to specify how long someone should temporarily store this information without doing a full search again. This length of time for caching an entry is is called the Time To Live (TTL) and the value is specified in seconds.

To illustrate this setting, here is the previous example including the TTL:

Requestor: “Hey .com, what is the IP address of www.example.com?”

Dot Com Nameservers: “I don’t know, but ask ns1.example.com or ns2.example.com. By the way, here are the IP addresses of ns1.example.com and ns2.example.com. When you write these down, make sure and discard this information after 172800 seconds because it may no longer be correct after that.”

Requestor: “Hey ns1.example.com, what is the IP address of www.example.com?”

ns1.example.com: “I know the answer to that. The IP address is 1.2.3.4. If you write this down, make sure and discard this information after 60 seconds because it may no longer be correct after that. By the way, the authoritative nameservers for example.com are ns1.example.com and ns2.example.com in case you have any other questions about my domain example.com. When you write that second part down, make sure and discard this information after 172800 seconds because it may no longer be correct after that.”

Our rolodex card would then say:

www.example.com = 1.2.3.4 (discard after 60 seconds)
ns1.example.com is authoritative for example.com (discard after 172800 seconds)
ns2.example.com is authoritative for example.com (discard after 172800 seconds)

One second later, our rolodex card should say:

www.example.com = 1.2.3.4 (discard after 59 seconds)
ns1.example.com is authoritative for example.com (discard after 172799 seconds)
ns2.example.com is authoritative for example.com (discard after 172799 seconds)

For 59 more seconds, we wouldn’t need to search the Internet when we wanted the IP address of “www.example.com”. However, after 59 more seconds had passed, we would discard the cached information for “www.example.com” and our rolodex card would only contain:

ns1.example.com is authoritative for example.com (discard after 172740 seconds)
ns2.example.com is authoritative for example.com (discard after 172740 seconds)

At this point, if we wanted to get the IP address of ”www.example.com”, we would need to do an Internet search, but we wouldn’t need to start at the nameservers for the “com” TLD because we know the authoritative nameservers for example.com. The query would skip an unneeded question and go like this:

Requestor: “Hey .com, what is the IP address of www.example.com?”

Requestor: “Hey ns1.example.com, what is the IP address of www.example.com?”

ns1.example.com: “I know the answer to that. The IP address is 1.2.3.4. If you write this down, make sure and discard this information after 60 seconds because it may no longer be correct after that. By the way, the authoritative nameservers for example.com are ns1.example.com and ns2.example.com in case you have any other questions about my domain example.com. When you write that second part down, make sure and discard this information after 172800 seconds because it may no longer be correct after that.”

Changing nameservers

Due to DNS caching, the proper steps to change nameservers for a domain are:

1. Set up the zone on the new nameservers.
2. Update the NS records on the old nameservers
3. Update the NS records on the TLD nameservers.
4. Wait the TTL of the old NS records (or a week).
5. Remove the zone from the old nameservers.

A common mistake

Step 2 and 4 is required because the DNS protocol allows old nameservers to continue controlling the domain due to DNS caching behavior. DNS caches are under no obligation to ask TLD nameservers when they have the authoritative nameservers for a domain cached.

If you skip steps 2 and 4, but perform the rest of the steps, your domain will be unresolvable to anyone using a DNS caching server that has the old nameservers cached until one or more of the following occurs:

1. The cache on the DNS caching server is flushed
2. The TTL of the old nameservers passes before another DNS query is made to those old nameservers (this may never happen, depending on how often queries to the old nameservers are made)

For example, we may be trying to change the nameservers from “ns1.example.com” and “ns2.example.com” to “ns3.example.com” and “ns4.example.com” and due to caching our rolodex card might read:

ns1.example.com is authoritative for example.com (discard after 1 seconds)
ns2.example.com is authoritative for example.com (discard after 1 seconds)

Then at the last second, before these expire, we need the IP address of “www.example.com” so we make this query:

Requestor: “Hey ns1.example.com, what is the IP address of www.example.com?”

ns1.example.com: “I know the answer to that. The IP address is 1.2.3.4. If you write this down, make sure and discard this information after 60 seconds because it may no longer be correct after that. By the way, the authoritative nameservers for example.com are ns1.example.com and ns2.example.com in case you have any other questions about my domain example.com. When you write that second part down, make sure and discard this information after 172800 seconds because it may no longer be correct after that.”

Our rolodex card would be back to reading:

www.example.com = 1.2.3.4 (discard after 60 seconds)
ns1.example.com is authoritative for example.com (discard after 172800 seconds)
ns2.example.com is authoritative for example.com (discard after 172800 seconds)

Although the nameservers for “com” may now be referring queries for “example.com” to “ns3.example.com” and “ns4.example.com”, we will never ask for that information until our old data has expired or the cache is flushed.

Whether or not someone qualifies as a computer nerd can be defined by the number of O’Reilley Media books owned. For those not in the know, O’Reilley Media publishes technology related non-fiction books. These books are written on information technology topics by experts in the field and these books are often considered the unequivocal resource on the topic covered.

Section 24.5 of Backup & Recovery, 1st Edition by W. Curtis Preston and published by O’Reilley Media in January of 2007 contains the following text:

“Beyond backing up data, organizations must also develop a strategy for archiving data. Both are integral components of an effective data protection strategy and necessitate a clear understanding of the business value of data (archiving maybe even more so than backup).

When executed correctly, archiving not only can save organizations money but it can also be a lifesaver, especially for those requiring access to historical information for regulatory compliance or audit purposes. Conversely, when archiving is performed incorrectly, it can cost a company dearly in terms of lost revenue, fines, and other penalties.”

Backups

A backup is basically a secondary copy of your primary data stored at another location in case the original is damaged. The backup is usually done daily to prevent losing more than 24 hours worth of work. The backup is usually stored offsite, to protect against a large disaster at the original site. Additionally, most sites only keep at most two backup copies of data, which are often overwritten after audting has occured.

If the primary data is damaged, deleted, or corrupted, it can be restored if the problem is found before the backup of the damaged, deleted, or corrupted data is destroyed.

If your e-mail server fails or the building that it is located in is destroyed, most organizations can use their backup of that e-mail server to restore the server on different hardware at a different location. Because the backup will usually be at least 24 hours old, some data will have been lost.

Additionally, a backup can usually be used to restore specific files that were accidentally deleted or corrupted, provided that the files are restored prior to the backup containing those files are overwritten or destroyed due to lack of storage space available for backing up data.

Archives

Archives are not copies of the primary data, but rather are the primary data itself, offloaded to a secondary site for storage. The system where the data was offloaded then becomes a secondary storage of the current working set of data. Most archiving systems will catalogue the data for easy retrieval of specific files.

Once a plan for data archiving is implemented, an organization decides what is archived, and for how long. Then data that is tagged to be archived can not be deleted, through policy enforcement against both accidental and intential deletion.

Additionally, archives are backed up.

E-mail archiving benefits

Performing e-mail archiving of all e-mail would mean that your e-mail server no longer stores the primary copy of data. If the e-mail server is lost, no e-mail data is lost.

If your users want to delete e-mail from their inboxes, they’re no longer deleting company data, but rather just a current working copy.

E-mail servers typically contain a wide variety of data stored in many different types of stores. Your e-mail server administrator likely doesn’t have the capability to quickly find a specific e-mail message without access to the recipient’s inbox. If the recipient is unknown, this makes it difficult to locate an e-mail message by subject. Due to the cataloguing done by e-mail archiving systems, e-mail can be quickly located.

SpamStopsHere’s Spool & Suspend feature

SpamStopsHere has offered E-mail continuity since September of 2008 through it’s Spool & Suspend feature. This feature allowed customer’s to access their queued e-mail while their e-mail server was unavailable to accept the e-mail. There were significant disadvantages however.

SpamStopsHere uses virtual clusters of e-mail servers to process a customer’s incoming e-mail. If a customer’s e-mail server was unavailable, the e-mail for one customer’s domain was typically queued in multiple locations. In order to allow customers to access the e-mail, the only copies of the queued e-mail had to be delivered to one e-mail store first, by enabling the Spool & Suspend feature. The e-mail store of queued messages could then be accessed, but only by a single e-mail administrator. Additionally, there was no way to respond to e-mail messages. This e-mail store was backed up every hour, to ensure against loss, which was a greater risk due to the e-mail all being in one location.

SpamStopsHere’s RestorEmail

In the first week of March in 2009, SpamStopsHere rolled out the e-mail continuity portion of it’s new RestorEmail product. This product archived incoming e-mail for a domain for up to 7 days. Unlike the Spool & Suspend feature, this new product does complete e-mail archiving of e-mail and leaves the storage in the cloud computing infrastructure which maintains reliability and accessibility. Each e-mail message that is archived is stored in at least three different locations and an array of administrative servers provides global access to these messages. Additionally, end-user access was added, and messages could be replied to, as e-mail sending features were added.

In June of 2009, SpamStopsHere rolled out the full e-mail archiving product, with more import and export options to get e-mail messages into and out of the cloud computing infrastructure. Additionally, messages could now be stored indefinitely, allowing SpamStopsHere to manage the integrity of your domain’s e-mail data archives through it’s fully managed system.

With hurricane season starting for many geographic areas, and with recent events possibly impacting your local infrastructure, can your organization afford to not have an e-mail archiving solution like RestorEmail to ensure business e-mail continuity?

The Internet standards for SMTP indicate that a single line of an e-mail message can be no longer than 1000 characters. If sendmail encounters a longer line, it wraps it and adds an exclamation point (!) at the end of the line as an indicator of its behavior.

I couldn’t find any good reason for this behavior. I would expect Sendmail to simply reject the e-mail message instead. I couldn’t find an RFC or Internet standard that indicated that an line length limit indicator was required.

To resolve the problem, you should probably ensure that your not sending an e-mail message with lines over 1000 characters. Try inserting a line break every once in awhile.

553 5.0.0 .com<TMPF<TMPF>… Unbalanced ‘<’

Then you likely compiled with mailertable support but don’t have a mailertable.db file. The solution is to just create your mailertable file. Usually like this:

makemap hash /etc/mail/mailertable.db < /dev/null

Why is credit card information not secure?

Credit card information prior to Windows 95 was relatively secure. A credit card number was provided to few people, and there were fewer ways in which it could be stolen. Once Windows 95 came, the average personal computer user had a TCP/IP compatible system, and millions of users poured onto the Internet and Web. Internet commerce became widely available, credit card information started being transmitted through many more computers, and the technology used to transmit credit card information became standard.

In previous years, the following were the most common methods used by criminals to steal credit card information:

• Digging through the trash at stores, a.k.a. dumpster diving
• Purchasing information from colleagues that worked at stores that could get receipts

Today, it is now a violation of Visa and MasterCard rules and regulations to print the full credit card number on a receipt. Additionally, most credit cards now have an additional three or four digit number that isn’t even allowed to be stored by a merchant, for added security. The current most common ways for criminals to get working credit card account numbers are:

• Social engineering and phishing 
• Purchasing information from colleagues that deal with credit card information for work
• Hacking into computers and networks that deal with credit card information
• Looking at the credit card of the person next in line at a store’s checkout counter
• Opening credit card accounts in other people’s names through identify theft

Unfortunately, all the precautions in the world won’t stop someone from becoming a victim. The whole credit card system is based on a promise to pay. It’s just too simple for someone to make a promise that someone else will pay, since at most times the security is simply posession of a an account number, with no real authentication mechanism in place.

For face to face transactions, the fear of a security camera and the security features on the credit card itself are supposed to protect the account holder. In telephone and Internet transactions, the shipping of a product only to the account holder’s address and the three to four digit security code are supposed to protect the account holder. For both types of transactions, the valid expiration month and year offers a little protection.

However, credit cards are being counterfeited in order to use stolen credit card numbers, for face to face transactions. Most cashiers at stores are not trained to look for the security features on a credit card and rather improperly concentrate on shopper profiling.

Merchants are incorrectly storing  the three to four digit security number when they’re not supposed to, resulting in successful electronic thievery of all information needed to purchase a service or product online or on the telephone. Additionally, merchants are more often offering to ship goods to addresses other than those on the credit card account in order to keep in business by taking the financial risk in a buyer’s market.

Today it’s also easy to purchase a disposable cell phone or a virtual telephone system in order for the criminals to provide telphone numbers to merchants for “telephone verification”. Telephone verification hasn’t been a good way to rule out credit card fraud for the past couple of years when dealing with even the most basic criminal.

What can be done?

The credit card banks expected the lack in security of the credit card account information. An individual’s credit card usage isn’t safe because criminals don’t have the account information. Credit card usage is safe due to agreements in place between the credit card issuing banks and the merchants that accept those credit cards for payment.

Even though many merchants simply aren’t playing it safe, and not following the rules, it’s these merchants that are taking the financial risk by not ensuring that they are dealing with the account holder. Most credit card account holders are completely protected from criminals purchasing products and services on the victim’s account. Simply reporting any suspiscious activity or the loss of possession of a card completely relieves the card holder of any financial responsibility. Even if the card or card number isn’t reported lost or stolen, the financial responsibility of the card holder is usually limited to only $50.

I recommend that all credit card holders demand that stores verify the signature and check the security features of the card before accepting it for payment. If a store clerk doesn’t do these things, ask why, and then ask for a manager. If a merchant is suspicious, don’t let them ask for identification (ID), which really proves nothing, especially if they haven’t checked the security features of the card or verified the signature. It’s against all of the major card issuer’s rules and regulations that a merchant require ID to accept a credit card for payment, as it leads to lax security and to customer profiling. Having an unsigned card presented for payment is the only time that a merchant should ask for identification and then ask the card holder to sign the card. If a merchant is suspicious, the merchant should call the credit card issuer for further instructions, but never ask for identification.

It’s a common misconception that one can simply write “See ID” on the signature panel of a credit card to ensure that the merchant checks for ID. In theory, this should only work once, since a card presented without a signature can’t be accepted until it’s signed.

Additionally, don’t let a merchant copy down or store the three to four digit security code on the back or front of the credit card.

If someone calls and asks for your credit card information to pay a bill, ask if you can call them back at the number printed on your invoice to pay.

However, most of all, don’t worry. If a criminal gets your credit card information, most likely it won’t be because you weren’t cautious enough. Using a credit card is safe and offers protections not offered by using cash. The fact that credit card theft is on the rise is nothing to lose sleep over, for a card holder. On the other hand, if you’re a merchant, you should call your credit card processor and ask what precautions you can be taking to help prevent fraud.

Wow, it’s been nearly a month since I have blogged. I’d like to apologize, and I have no excuses other than things are busy here at SpamStospHere with a new e-mail archiving and e-mail business continuity product. Additionally, I’m trying to get used to working a new shift and there were some holidays in there. I was mostly surprised at how much time had flown. In any case, there has been revealing SSL research, the findings of which were presented at the Chaos Computer Congress in Berlin.

SSL and the the Chain of Trust

Secure Sockets Layer, also known as SSL, is a public and private key encryption method. Additionally, public keys can be digitally signed by an entity, turning them into a certificate. This certificate then can be used to encrypt data, but the signing can also be used for identity purposes. This ensures that you’re not only encrypting your data, but you’re also sending it to the proper entity, for decryption.

At the top of the chain of trust is the certificate authority, also known as a CA. A CA certificate is used by a certificate authority to sign the certificate of another entity, showing in some way that the certificate authority trusts that entity’s certificate. By default, most web browsers and other applications that use SSL have a dozen or so locally trusted certificates, that recognize these certificate authorities as trusted. When establishing an SSL connection with a remote computer, if the remote computer is using a certificate that is signed by one of these trusted CAs, and as long as the hostname of the remote computer matches the name in the certficate, the remote computer is going to be trusted with accepting encrypted data without any warnings or security alarms going off.

In addition, if a CA certificate is signed by a trusted CA certificate, this establishes a longer chain of trust where certificates signed by the secondary CA would also be trusted by the browser or other SSL implementation.

The vulnerabilty

For many years, computer research has shown the weakness of using MD5 for hashing. The 128 bits used by MD5 hash lead to a high number of collisions. A collision is when two different sets of data are processed that result in the same hash. However, MD5 was superior to the 56 bits of Digitial Encryption Standard, also known as DES, which it had generally replaced. The MD5 hashing was also exportable outside the U.S., where DES was not. Additionally, MD5 was still very computationally fast for computers available at the time.

In 2005, some researchers at the Technische Universiteit Eindhoven (University of Technology) in the Netherlands, had published a paper on how MD5 collisions made it possible to have two certificates with the same signature, although the same owner name. In this case, the certificates are being signed with an MD5 hash function, which some CAs use to sign certificates.

In 2007, the same research team published a paper showing how an MD5 collision allowed two certificates with different common names and organization.The researchers used different sized keys for each of the two certificates, the only way to get the math to work out so that both certificates have the same signature.

In December of 2008, at the Chaos Computer Conference, the Technische Universiteit Eindhoven research team spoke on their latest research. Using new attack methods on the MD5 cryptographic hash function, the team was able to create a CA certificate that is signed by a CA that most Web browsers trust by default. This allows them to sign any certficate and have it trusted by web browsers. They did this by having a CA sign a non-CA certificate that had a collision with their rogue CA certificate. Once the non-CA certificate was signed, they then applied the signature to their rogue CA certificate.

Interestingly, the research team used a cluster of 200 Sony Playstation 3s to do the math computations. The PS3s did the hardest part of the math in only 18 hours.

The implications

In the past, you could be sure that you were actually providing your SSL encrypted data to the computer listed in the location bar in your Web browser, as long as you didn’t receive any warnings from your Web browser. Now, you can’t be sure. It’s as simple as that. Are you really connected to your bank’s Web site, or are you connected to a computer posing as your bank’s Web site? There’s no way to be sure.

Although not all CAs are still signing certificates with MD5 hashes, it was easy to target one that was. The research team said that they won’t release the more scientific information for a few months, in order to allow the affected certificate authorities to remedy the vulnerability. Like the DNS research from last year, it may not be long before many other researchers start reverse engineering the limited information and making fairly accurate guesses as how this might be accomplished. Surely exploits will be available in a few months after the more detailed paper is available.

Who is involved and how to solve?

RapidSSL, FreeSSL, TC TrustCenterAG, RSA Data Security, Thawte, and Verisign all had issued certificates in 2008 that had been signed with MD5. In theory, these CAs would need to revoke their certificates and issue new ones to resolve the issue, as well as offer resigning of all certificates previously signed. However, this problem will likely simply fall in the hands of the average user and the SSL implementation developer. Web browsers will likely simply stop trusting all certificates signed by MD5, requiring many web site owners to get their certificates resigned. Older browsers, like Internet Explorer 6, are unlikely to be patched.

This problem is similar to the DNS vulnerabilities researched last year, that had people unable to trust where they were sending their unencrypted data for several months. Due to the limited number of vulnerable recursive DNS servers, this possible nightmare was resolved rather quickly, and likely only cost hundreds of thousands of dollars and hundreds of thousands of man hours.

The damage caused by these CAs continuing to use a known insecure hashing functions will have people unable to trust where they’re sending their encrypted data for many years. The likely cost will be in the millions of dollars and it will take millions of man hours to make SSL secure again for the average computer user.

I had heard about green power supply units (PSUs) for computers back when I was building a “silent pc” using the information from SPCR. It only made sense that in order to have a quiet computer, you needed to get rid of the moving parts such as constantly running fans. In order to get rid of the constantly running fan on the PSU, it was necessary to have a PSU that didn’t run hot. In order to accomplish this, the power supply had to be efficient. Most power supply units only convert AC to DC power with 70% efficiency. The other 30% is lost and primarily converted directly into heat. Most fanless power supplies use heatsinks to deal with the heat, but they’re also typically more efficient, by converting 80% of the AC power into DC power. Depending on how many watts your power supply is pulling, a 80% efficient unit put out half the heat as a 70% efficient unit. There are some fanless power supply units that are marketed as being 89% efficient.

Besides the obvious cost savings in electricity used by the device, using more efficient power supplies can also offer the following benefits:

• Less heat generated also means less electricity used to cool the server room
• Not having a fan in the computer’s power supply can help lower the amount of dust in the computer, increasing the life of the system
• The cooler the system is, the better it is likely to operate under load
• A cooler system will likely increase the life of the system
• Less electrictiy means a greener earth, and lower carbon footprint for your company

There are a lot of eight port gigabit port switches to chose from, but I could only find one that was advertised as being “green”. The DGS-2208 from D-Link is a 8 port gigabit switch that only sends power to the ports that are being used, unlike most switches that will send power to all ports regardless. Additionally, it determines the cable length and uses less power to transmit signals over shorter cables. The DGS-2208 uses the least power when using cables under 20 meters, which is longer than most home users require. The switch also offers a 144KByte buffer per port and jumbo frames up to 9600 bytes, which are quite acceptable. When I touch this switch after it’s been running for weeks, it’s just slightly warmer than room temperature, and I no longer worry about extra cooling.

A new study by GreenFactor, an ongoing global technology and environmental research initiative, found that consumers are getting savvy about green and are demanding that electronics brands provide more clear information about their products’ engery savings.

The GreenFactor study found that saving energy is the most important reason why consumers are considering green electronics, but that the barriers to purchasing green are primarily from manufacturers not providing information, from the additional cost of green products, and from lack of availability. I recommend reading the rest of the results of the study at GreenFactor’s Web site.

I definitely am having a difficult time finding network security products that are advertised as being green. Although I can highly recommend that everyone start going green with their next hardware purchases, I’m not sure that there are that many options out there. If anyone knows of any, please contact me.

Of course there is no substitution for energy savings when it comes to turning systems off when not in use. An Internet server that is shut off when not in use is also generally more secure. Don’t forget that some extras steps are needed to monitor a system that is turned off, in order to detect when the server goes missing.

It’s a fact that whomever wants to gain access to your systems or data can accomplish this if enough resources are put to the task. The amount of resources that your company spends on protecting your systems and data is typically the only factor that determines whether or when your company experiences its first or next security compromise and also whether that security compromise is even detected.

The first step at avoiding a security compromise is determining your company’s risk, the value of your data or systems, the amount of damage caused by any compromise, and then using that as a basis on determining the resources spent at protecting against a security compromise. How many security professionals does your company want to hire? How much freedom will they be given to interrupt business processes to improve security? How much money and time will they be given to accomplish their goals? How much time will be spent continuously improving the system and training personnel? I know that many company members are reading this article right now that know that their company hasn’t spent anything on information security. There is no perfect security, and no company has limitless resources to throw at it. Your company must simply pick a reasonable plan for the situation at hand.

Hind sight is 20/20. After something goes wrong, it’s going to be easy to see where your company’s plan wasn’t perfect. Or if the plan was sufficient, perhaps the plan was improperly executed, or perhaps the proper amount of resources hadn’t been utilized to execute the plan. Whatever you do, don’t blame the plan, as long as it was reasonable given the information available at the time. It’s time to assess how the plan needs to be adjusted.

Don’t pick a scape goat. It’s unfortunately easy for a company’s executives to decide to fire the security personnel after the company suffers a financial loss due to security compromise. In my opinion, that is the worst thing to do. When a company has a security compromise, the company has found that it did not put sufficient resources on the task. It’s time to hire more security personnel, not fire the ones that it has. It is extremely rare for a company to have a security compromise that was caused by the negligence of security personnel. Usually, compromises are the result of short sightedness and apathy by the company to establish a plan, or to execute it. Usually the security peronnel knew what needed to be done, but the company was hesitant to put the resources into accomplishing those things that were needed. Again, hindsight is 20/20. As long as your security personnel did what the company told them to do and gave them the resources to do, they can’t be blamed for a security compromise that was unexpected. All security compromises are going to be unexpected. A compromise will never show where your protections against them were sufficient, but rather only where they were not sufficient. If you weren’t ready to fire the security personnel before the compromise due to the lack of a reasonable plan given the information at hand, then they shouldn’t be fired just because there is new information.

When an organization has a security compromise, it’s time to hire a security consulting firm and probably some lawyers. It’s time to adjust the plan and to keep moving onward with the mission. It’s not time to have a blamestorming meeting.

However, it’s never too late or too soon to put more resources toward preventing your first or next security compromise.

ISACA released the survey results for “Shopping on the Job: Online Holiday Shopping and Workplace Internet Safety” on November 13. Although I didn’t read the full survey, I don’t understand how five hours costs $3000 for most businesses.

The survey also indicates that older Americans are less likely to do their online shopping at work. The group aged 18 to 24, dubbed the “Millennials” are described as being more tech-savvy, but also more concerned about a balance of work and life and are less loyal to their employers than other age groups.

The Millennials are also described as being less concerned about the vulnerability of their computer at work, with 49% paying more attention to security on their home computer than their work computer. Almost two-thirds of workers in other age groups are evenly concerned about security with both their home and work computer.

The best thing to take away from these survey results is that companies may be smart to invest an hour or two of their IT management team’s time into clearly communicating their expectations to employees regarding the use of company resources and time while shopping online. Besides the obvious loss of productivity, there are other issues often overlooked by the average employee. Non-work related web surfing, online transactions, and work e-mail use, can exponentially increase the exposure of the company to malware and other information security problems.

The press release from ISACA includes some detailed tips for holiday shoppers and for IT administrators, and I recommend checking them out.

Identitytruth released a press release today titled “Avoid Getting Caught with Gifts You Didn’t Plan on Buying”. This press release also has some good tips for shoppers, such as using a credit card instead of a debit/check card, and being careful when using ATMs and generally being wary of your personal and information security this season.

IdentityTruth does include one tip that is a bad idea. I recommendthat you do not write “SEE ID” on the signature panels of your credit cards. Visa and MasterCard regulations don’t allow merchants to accept unsigned cards. If you write “SEE ID” on your credit card instead of signing it, a properly trained merchant will ask you for your identification, but then will ask you to sign the card in front of them, before it can be accepted for payment. If your card is signed, Visa and MasterCard regulations don’t allow the merchant to ask for identification before accepting payment. The merchant must simply compare the signatures before accepting the card as payment.

IdentityTruth’s press release indicates that you have no legal protection when using a debit/check card for purchases. The EFTA limits your liability under federal law when using these items. However, there are many protections offered directly by American Express, Visa, and MasterCard that only a credit card can offer. These credit card issuers can help you get a refund if a merchant refuses to honor a return policy, and some issuing banks offer benefits that go as far as extending the warranty on items purchased, or even price protection should the price of an item drop within 30 days after purchase.