Archive for March 2010

« Previous Entries

Secunia PSI and Adobe Reader.

March 31, 2010, 1:33 pm

Since Adobe Reader 9.3.1 came out, Secunia Personal Software Inspector has been reporting that I’m running a vulnerable version of Adobe Reader whenever a full scan is performed. When I select rescan, the detection goes away.
The detected file is C:\Program Files\Adobe\Reader 9.0\Reader\AcroRd32.exe . But 9.3.1 didn’t update that file. Adobe unfortunately only updates a file version when they change a file, so you can only look at add/remove programs or find the specific file that changed.
I searched on the Secunia Community forum and found a relevant thread. A “Secunia Official” says”

“This is a know (sic) bug, and is in the hands of our developers. The problem is caused by old versions of Acrobat/Reader on other drives, and the PSI using version info from files in their subdirs instead of the version that belongs to the detected instance. Thank you for reporting it, and sorry for the trouble. In the mean time, using the local rescan should produce accurate results.”


I dont see any old versions of Adobe Reader on other drives, but I did find that under windows.old I had a duplicate program files directory with an old Adobe Reader. I have an ignore rule for the windows.old directory so that shouldn’t be the problem. But at least I know they have acknowledged this behavior as a bug.
Normally when they find a vulnerable file version in some odd place they list that as the vulnerable file. In this case there is nothing wrong with the file they are reporting on.

Tags: , ,
Category: General  |  1 Comment

BitLocker vs Third Party FDE

March 30, 2010, 9:59 am

Like many organizations, we skipped Vista. So with Windows 7 we are facing the question “is Windows 7 good enough” or do we still need to pay for a third-party full disk encryption (FDE) product.

This question was asked back in 2006 at the SANS Desktop Encryption Summit. The FDE vender’s felt their product was better because:
1. Better Management tools
2. Mature product
3. Multiple OS support
4. No requirement for TPM.

BitLocker is no longer a first gen product. Let’s look at today’s reasons for purchasing or continuing to use a third-party FDE product.
BitLocker Minimum Requirements
“BitLocker stores its own encryption and decryption key in a hardware device that is separate from your hard disk, so you must have either a computer with a Trusted Platform Module (TPM) or a removable USB memory device.”
USB memory devices would tend to be stored in the laptop bag, so that isn’t a secure solution.
TPMs are an additional thing to manage. Perhaps it’s not as difficult as I envision. When I did a WAVE eval, I had to go into the BIOS to enable the TPM and set a master TPM password. That doesn’t scale.
“The computer must have been configured with an additional separate active partition to be used as a system partition.”
This extra step now happens automatically, so I don’t think that is a big deal.
“The BIOS must be compatible with TPM and/or support usb devices during computer startup”
It may be necessary to upgrade the BIOS. While probably not an issue on the newer computers we would be using, this could be an issue on upgrades in place.
None of these prerequisite requirements is particularly burdensome. However it leaves out one key minimum requirement: Vista or Windows 7 Enterprise. Our XP systems would still be on the current FDE product requiring two management methods.

OTHER BitLocker Considerations
1. Provable Encryption
With the current FDE product, if a computer is lost I would be able to tell that it was actually encrypted when it was last seen on $date $time. Can BitLocker say the same? I don’t know.
Many states have an encryption safe harbor. Meaning if the lost system was provably encrypted, breach notification provisions do not apply.
2. Usability
The current FDE product syncs the domain password to the pre-boot environment. The user does not need to know a second password. The normal password requirements apply.
With BitLocker the PIN is just that. An enhanced PIN can be required but it is possible that some system BIOS will not support alphanumeric entry in the pre-boot environment. Does this PIN ever expire? It doesn’t seem like it.
3. Recoverability
The standard recovery method is to use a recovery password. This is a 48 digit number backed up to Active Directory. Enjoy typing that in when the user forgets their password.
This method is not FIPS compliant and must be disabled. Instead there are other two options
A recovery key is a 256 bit key that is saved to a flash drive. This method must be done by the end-user and they need to store the key securely. Obviously that isn’t enterprise ready.
The third option is a data recovery agent. A public key is distributed to all BitLocker protected devices. Someone with the matching private key (e.g. me) would need to be physically present at the computer. Apparently even then the OS drive must be installed on another computer running Windows 7 as a data drive.
So basically no recovery options work for us.
4. Standby
BitLocker protection is in effect only when the computer is turned off or in hibernation.
Our current FDE product protects in standby, hibernation or when the computer is off.
Update:This is is no longer true.   a preboot authentication in standby is a false sense of security.
5. Enterprise Manageability
While BitLocker has caught up with third-party encryption products in its ability to encrypt USB drives there are still other areas where FDE vender’s shine. Many FDE vender’s can also encrypt phones and managed hardware based encryption products. It’s a lot more convenient to manage these devices through one vendor.
From my limited reading it seems that there are still a number of items that argue for the continued use of a non-Microsoft FDE product.

Tags: , , , ,
Category: FDE, Microsoft  |  4 Comments

Protecting Sensitive Data in Email

March 29, 2010, 11:25 am

State laws, company/client policy and common sense mandate the encryption of some forms of data. Whether its company secrets, PII (personally identifying information that isn’t already considered public), or ePHI (Electronic Protected Health Information) it is required that users encrypt this data when sent outside of the company, and it is on the IT Department to provide the right tools so this can occur. Bonus points for making it occur seamlessly and automatically.
This post looks at methods for protecting this data in transit via email.
1. S/MIME Encryption using Digital Certificates
S/MIME is built into most email clients. Once the certificate is installed, it is relatively easy to use if both sides have a digital certificate. When the otherside doesn’t have a digital certificate, unless you’re the 800 pound gorilla, good luck getting them to purchase a certificate and learning how to use it.
Most web mail clients do not support S/MIME. One exception is Outlook Web Access.
Cost and the difficulty getting the external user to use a digital certificate make this solution difficult.
2. PGP
PGP is another standards based email encryption solution. While there are free versions, they didn’t work well with Outlook the last time I used them.
This has the same problem as S/MIME in that the external person needs to be running PGP. Again good luck getting your external contact to change their ways.
3. A phone call
In a lot of cases we aren’t talking about moving a Excel spreadsheet of Social Security Numbers. We’re talking just one. A phone call (not leaving a voice mail) could be a lot more secure than email.
4. Encrypted Zip File
Encrypted ZIP files are easy to use, and use software already on many computers.
There are also many problems with Encrypted Zip files. The external mail server may be configured to block encrypted archives. It may not allow zip files at all.
You must pick a password that is good. Then communicate that password to the recipient over a separate channel (not email). If the user wants to use that file at a later date, they are probably going to go back to the original email. They wont have the decryption password anymore, and most likely neither will you. There isn’t a enterprise recovery option.
Encryption in zip files last time I checked was not really a standard. Winzip encryption at AES strength wouldn’t open in other zip clients. That may or may not be the case anymore.
5. Password protected Office document
You could password protect the Office document themselves. I haven’t checked if there are issues with password protected files between Microsoft Office versus Open Office. I do believe to get the best protection you need to use the current version of Office and then earlier versions of Office will have issues.
The same password lifecycle issues that occur with Encrypted Zip files also occur with Office documents.
6. Secure File Transfer Server
Products like Accellion can be used to transfer sensitive documents. These systems work most securely when you set up an account for the external person and communicate the password to them out-of-band. If the system automatically sends a link to the external user when a file is uploaded for them, anyone reading the email who gets there first can snag the file. At least it should be obvious that this has occurred. But the idea is moving files more securely.
7. Mandatory TLS to customer Site
TLS/SSL is what you are most likely using when accessing your bank site with a HTTPS://. It is possible to work with your customer/clients and set up mandatory routes that require TLS on all messages between the two domains.
The main drawback of this is it would need to be done for every customer domain that you deal with. It also encrypts all mail. TLS requires a bit more processing power. Shouldn’t be a problem for well spec’ed servers.
The mail is only encrypted in transport and is stored in the clear on the recipient and sender mailbox.
8. Opportunistic TLS
Opportunistic TLS attempts to use TLS on every mail connection. If it is not supported it sends the email in the clear.
While this means you only have to configure your mail server, you never know for sure that sensitive email is encrypted.
9. Hold for pickup
There are some mail systems that detect sensitive data in transport an then transparently act like the Server File Transfer Server. They notify the recipient that they have a message to pickup. The message is then picked up over SSL.
There are issues with each method of moving sensitive data via Email. But there are many options.

Tags: , ,
Category: General  |  4 Comments

Symantec Password Survey

March 26, 2010, 8:12 pm

Symantec published the results of a survey regarding password habits of people who read their Security Response Weblog. Nearly 450 readers responded. As you readers of a security blog, their responses probably are far from the norm.
Links: http://www.symantec.com/connect/blogs/password-survey-results
Not surprisingly, the respondents have a lot of passwords. 66 percent report having more than 10 passwords. Its hard to keep track of that many passwords. This leads people to do dumb things.
23 percent of respondent let the browser keep track of their passwords. While Firefox can use a master password to secure these stored passwords, I suspect most people dont use that feature. Browser password caches are merely obfuscated and are not a secure place for your passwords.
7% have a note near their computer. This is ok if your office is secured from outside visitors. But even the home office of a hermit occasionally has workman visiting.
11% use a Word document on the computer. Word or Excel documents can be lost if the computer isn’t backed up. It is also not a secure way to store the passwords. If you’re putting all your financial passwords in one place, wouldn’t it be a good idea to secure them. Perhaps they are in Word and password protected. But that wasn’t specified in the survey.
59% rely on memory. Passwords for work should never be in memory only. If you are hit by the proverbial truck how much productivity will be lost regaining access. For more personal accounts, memory indicates possible password reuse at worse or use of a password scheme at best.
33% use a password manager. That’s great but I found out in 2009 that you need to make sure your backups work if you’re relying on this method.
Check out the link for the rest of the results of this Symantec survey.

Tags: , , ,
Category: General  |  Comment

Telecommuting Security

March 25, 2010, 9:09 pm

After the February snow storms in the DC area there was a plethora of articles advocating the expansion of telecommuting in the Federal Government. The contractors that support the government didn’t close doors. They continued to work because many of their employees already work remotely in structured and unstructured telecommuting. Telecommuting brings new security risks.
Joan Goodchild writes about Four Telecommuting Security Mistakes in ItWorld and CSOOnline. That s the starting point for this post.
1. Careless use of wifi and accessing unsecured networks
I don’t think people understand the security implications of “borrowing” someone else’s wifi or even using the free wifi hotspot at Panero/Wegmans/local shop.
Wireless is a shared medium. You don’t know who is listening in or even potentially hijacking your connection.
2. Letting family and friends use work issued devices.
We’ve seen laptops destroyed by letting the kids use them. (Although we could wonder if the user didn’t want to fess up that they were the one dumping the drink on the laptop repeatedly).
The kids violate security policy by installing P2P software, potentially sharing out all company data on the laptop. My favorite was the time the VP who signed the memo banning P2P was caught with P2P on the computer. Must be the kids.
If you allow your users to use USB thumb drives and the drive is shared with the kids, the data could easily be formatted or stolen.
3. Altering security settings to view blocked sites
Sadly this isn’t an issue for us because there is no filtering when you’re not at work.
People are apt to disable any security control that keeps them from their goal.
4. Leaving work issued devices in an insecure location
This is the standard problem. What is a secure location. Laptops are stolen at work. Laptops are stolen from the trunks of cars. You’ll recall the Veterans Affairs case where a laptop was stolen from home.
When you’re at the Starbucks, do you leave the computer on the table while refilling your drink, or hitting the restroom. People are far too trusting. Particularly when its not their property that will be stolen.
5. “Backing up” corporate data to a home computer or NAS
This should be against your companies policy. Proper enterprise backups don’t occur by copying files to what is probably an insecure location. Its just bad.
6. Emailing corporate data to your personal email account
Corporate and customer data have no place in personal email.
7. Secure disposal of papers
While at work its easy enough to put documents in the document destruction bin (which is pulped). At home if you’re lucky the data is shredded. Then again, dumpster diving at the CEOs house might turn up a lot of corporate data.
8. Incident Response
Was incident response built into your telecommuting program. Do users know who to call?

Tags: , ,
Category: General  |  1 Comment

Infosec Career Planning

March 22, 2010, 12:18 am

I’ve been thinking a lot about career path and career planning lately. Because of that I’ve noticed a lot of reblogging about the Information Security Career Survey by infosecleaders.com. A number of conclusions have been drawn from that survey. What sticks with me is that most Infosec pros don’t have a career plan.
My issue is that I’ve reached the goals that I had set early in my career and now I’m just drifting. To reach that goal I followed an old article, I think it was in ComputerWorld titled pillars of an Information security career. I worked to gain experience, I got an advanced degree and I got certs. That along with waiting got me where I wanted to be.
So I sit and think, what is it I want to do next. Perhaps I already have my dream job. Good people. Better than average benefits. Telecommuting (note to boss, two days telecommuting would be nice).
That’s when I ran across a video from Louisville Infosec. Lee Kushner spoke on The Seven Habits of a Successful Information Security Career Manager. (Lee is one of the authors of the study). The video seems to be shot from the crowd and who knows what the audience was doing instead of listening. If you can tolerate the audio quality, I found the presentation well done.
Dont let your career just happen to you. Getting to a good place often requires more than luck and waiting for someone else to recognize your talents. Infosec continues to be a popular career choice. You must be able to differentiate yourself. While we still hear of Infosec worker shortages, there is still a lot of competition for the GOOD Infosec jobs. Talent, Networking, and planning are key.

Tags:
Category: General  |  Comment

Messege Encoding and Blackberry

March 20, 2010, 3:12 pm

Last week a user reported trouble reading a message on his blackberry. He would get an error “This S\MIME message was formatted using an encoding that is not supported on handheld.” He could still read the message correctly in Outlook 2007 and in Outlook Web Access.
It turned out the commonality to the problem was him. On this Blackberry, he couldn’t read S/MIME signed messages where people were replying to him. Others couldn’t read his S/MIME signed messages on their Blackberry.
Since the error referred to the encoding of the message, I wanted to see what the encoding was. The headers in Outlook didn’t seem to include that so I opened the message in Thunderbird. In there, it was clear that the message body encoding was Cyrillic. Kind of weird that the Blackberry reads the message just fine if its not digitally signed but gets the error above when it is digitally signed.
RIM wasn’t much help. Their support gave the same answer found in a knowledge base article. Their choices are

    ,li>Do not sign and encrypt the message.

  • In Microsoft Outlook, go to Tools > Options > Mail Format > International Options and select Auto select encoding for outgoing message.
  • In Microsoft Outlook, go to Tools > Options > Mail Format > International Options > Preferred encoding for outgoing message and select Unicode UTF-8 encoding.

Not signing the email isn’t much of a solution. I worry that changing the encoding options in Outlook would effect the readability of email in other situations.
Microsoft has an article on configuring message encoding options in Outlook 2007. There we read that “Outlook uses automatic message encoding by default, scanning the entire text of the outgoing message to determine a minimal popular encoding for the message. Outlook selects an encoding that is capable of representing all of the characters and that is optimized so the majority of the receiving e-mail programs can interpret and render the content properly.” The KB has a table showing supported encodings and whether they are considered for autoselection by Outlook. The article does not state whether we could remove an encoding option however.
Through some trial and error, I found that the problem was in the signature (footer not the digital signature) of the person reporting the problem. He had used what looked like a pipe to separate portions of the signature (like Title and Company). It wasn’t a pipe, it was actually a character inserted through the Symbol key. If I replaced this symbol with a standard pipe character the problem went away completely.
While this was a quick fix for this user, its not very satisfying. Most likely this user saw someone else’s signature and copied it for his own use. I doubt this user was using ASCII codes or hitting the symbol button. If others did the same they would have the same issue. I prefer a better solution than put it in our KB for next time it gets reported.

Tags: , ,
Category: Microsoft  |  2 Comments

Now you’re getting it

March 17, 2010, 8:53 pm

In December I set up a rule on our outbound email to let me know when people are sending Social Security Numbers in outbound email. Once I was satisfied with the accuracy of the rules, we set up some education for our physical security and HR Recruiters so they would understand why its a bad idea to send SSNs and what some alternative choices are . Once our big offenders had been notified I enabled a notification to the sender to let them know why emailing SSNs in plaintext is a bad idea. After about a month of that I reconfigured the rule so it blocked the email and notifies the sender.
One person who I believe is a finance manager got blocked while attempting to email papers for a personal mortgage refinance. A hilarious rant was sent to the helpdesk saying that if that people can read non-encrypted emails then non-encrypted email cant be used for business mail such as emailing a credit card number to enroll in a conference or when sending resumes that include SSNs.
Its so nice when the user gets it. Although I would have appreciated a ‘thanks for stopping me from shooting myself in the foot” tone instead of misplaced moral outrage.
I replied that she’s absolutely right. She should never be sending credit card numbers by email either. Some of the project/customer related data’s secrecy is dependent on the requirements of the customer and talking to the project lead about how to handle customer data would be appropriate. Unfortunately the company can’t allow emailing of SSNs.

Tags:
Category: Awareness  |  3 Comments

Say that Again

March 15, 2010, 5:21 am

In an episode of Community a couple of week ago Brita was laughed at for pronouncing bagel with with two Gs. (bag- gle) As in, rhymes with “haggle.”
I found it hard to believe that anyone could possibly pronounce it that way and think it was right. (although I’ve sense read a NY Mag recap of the episode and that actually happens in New York.
Read more: Community Recap: Pool Party — Vulture http://nymag.com/daily/entertainment/2010/03/community_recap.html#ixzz0iDAkjftM
Bringing this post back to Information Security, over the years I’ve found that I have words that I can’t say right. But when you generally only see a word on paper you can easily make up your own pronunciation. Then later get embarrassed at the trade shows.
Retina. You’d think since the product is from eEye I’d be able to pronounce it. I always say it Ret-tina.
Ethereal – i always said it ether-real. You know like ethernet. Apparently everyone else says it like the word “lacking in material substance”. Of course now we all pronounce it “Wireshark” so its not such an issue anymore.

Category: Uncategorized  |  2 Comments

The Mentalist and Iris Readers

March 14, 2010, 12:20 am

Eric Cole he told a story of an engagement where a security bigwig was showing off on a tour of their facility. The bigwig was very proud of his biometric iris readers that protected access to the data center. That is until Eric put his eye up to the reader and was provided access. It seems the Iris readers had a troubleshooting mode where any eye was accepted. In their implementation, no one had ever verified that the Iris reader correctly denied access. If they had they would have investigated this problem and turned off the troubleshooting mode.
I was reminded of this story this week as I watched CBS’ The Mentalist. A bored Jane put his eye in front of the reader and suddently the door that shouldn’t be opened was opened.
I blogged about Eric’s story once before in a post about a airport security

Category: Uncategorized  |  Comment
« Previous Entries