Airlines warn customers of infected ticket invoices

I haven't blogged in a while because work has been unbelievably busy lately but I wanted to pass on an article on Computerworld that falls right into my wheelhouse: information security and airlines. Delta and Northwest have put out warnings regarding malicious ticket invoices that are being emailed to unsuspecting people. The malicious email contains a trojan-packed zip file and instructs the reader to open the zip in order to see the invoice for a $400 ticket. From the article:

Photo by Flickr user: caribb

However, the .zip file format attachment is a Trojan horse that steals information, including keystrokes, from the infected Windows PC and transmits that data to a server hosted in Russia, according to McAfee threat researcher Craig Schmugar. McAfee has pegged the malware as "Spy-Agent.bw," but other security firms have given it different names. For example, Symantec Corp. has labeled the same Trojan horse as "Infostealer.Monstres."

It doesn't appear that the message hasn't been directed at American Airlines yet but I wouldn't bet against seeing them withing a day or two if the spam campain is successful. I'll update this blog if more details become available.

Preaching to the choir

Stuart King wrote an excellent post at computerweekly.com regarding how to reduce the cost of information security. His points are spot on and very similar to things I have been bringing up at work over the past few months. My organization in particular is being hit particularly hard due to current economic conditions so it is imperative that I show value for every dollar I spend, perform thorough risk analysis on new projects, and evaluate existing security projects, services, and infrastructure for cost savings. Of course I have to do all this while maintaining (or improving) the current security posture of the enterprise.

Good times.

NIST releases three new security guidelines

Government Computer News (GCN) reported that the National Institute of Standards and Technology (NIST) recently released three draft guides for public comment before their official publication. From the article:

SP 800-107, titled “Recommendation for Applications Using Approved Hash Algorithms,” is in its second draft release. It provides guidelines for achieving the appropriate level of security when using approved hash functions.

Draft SP 800-121, titled “Guide to Bluetooth Security,” describes the security capabilities of Bluetooth technologies and gives recommendations on securing them effectively.

Draft SP 800-41 Revision 1, titled “Guidelines on Firewalls and Firewall Policy,” updates the original publication released in 2002. It provides recommendations on developing firewall policies and selecting, configuring, testing, deploying and managing firewalls. The publication covers a number of firewall technologies, including packet filtering, stateful inspection, application-proxy gateways, host-based and personal firewalls.

I have begun reading and intend on commenting on the Firewall draft. From my first peek inside it seems very thorough and covers not only firewall policies and requirements but also architecture, rule selection, and life-cycle management.

Are Security Devices Making Us Lazy? : Part 1 : Introduction

Let me clarify before I begin... by "us" I mean IT as a community, not information security specifically. Now that I have that out of the way let's discuss how our reliance on network firewalls, application firewalls, VPNs, encryption, etc. have caused system administrators, architects, programmers, and yes, even us security-type-folk lazy. Let me explain a bit.

Let's pretend for a moment that we didn't have AV, network firewalls, SSL, IDS, or any other security-specific solutions available to us. How would we design our information systems? How would we protect resources? How could we possibly defend our networks against attack? These are the questions I like to ask myself when I have to design a new security architecture, review a proposed design, or audit an existing system.

I am not saying we should design all of our systems with these questions in mind. I understand the fact that we have these wonderful network and system security tools at our disposal. Thus, we can adapt our architectures, designs, and programs to include these solutions. The problem I see is an over-reliance on these tools. As an industry we have moved away from pushing most of the security work to the system administrators and programmers. We have told them (implicitly) "Don't worry about it... we've got it covered."

So how do we fix it? How do IT professionals stop relying on “things” and start building security from the ground-up? How do we do this while increasing functionality, ease-of-use, and speed? In future installments of this series I will attempt to look at where IT professionals can focus their energies to begin “spreading the gospel” to the developers and administrators and have them buy into the idea of secure system from the start.

Should the Airlines be Forced to Fingerprint Passengers?

...and should they have to pay for it?

The Bush Administration and the Department of Homeland Security have told the airline carriers that they will collect biometric information such as fingerprints from foreign travelers on their exit from the United States. I will refrain from discussing the political and social aspects of this request and instead will focus on the financial and technological aspects of such an idea.

The US-based airline carriers are facing record fuel prices, increased competition, price elastic demand, and a volatile customer base. If the administration forces the airlines to also fingerprint passengers, the additional infrastructure, storage, networking, and security costs would kill IT budgets. It could also cause the airlines that are close to the edge financially to either further pull back operations or perhaps file for bankruptcy.

Beside the financial burden this would place on the airlines another question that must be asked is: why? Why should the airlines collect and maintain biometric records of their passengers? We currently have the federal government stopping to check for both citizen/visa status as well as customs inspection at all ports of entry. Why can't we just turn some of those booths around the other way?

The DHS is already collecting fingerprints and taking pictures of people that visit the country. Why should the airlines duplicate the entire infrastructure costs that are associated with this program? The costs would include the purchase of fingerprint scanners, computer systems, programs, databases, and storage as well as an interface into the federal government system. The cost for putting these systems into each international airport will be huge, and will have to be duplicated by each airline.

This is the ultimate "pass the buck" program. The Bush administration and the DHS shouldn't place this undue burden on the airlines who will, in turn, pass the costs onto the consumer... that is, if the airline stays in business and continues to fly internationally.

Reference Links:
http://www.fcw.com/online/news/152938-1.html
http://www.dhs.gov/xtrvlsec/programs/editorial_0525.shtm
http://en.wikipedia.org/wiki/US-VISIT_(United_States_Visitor_and_Immigrant_Status_Indicator_Technology)
http://www.smartbrief.com/news/gtg/storyDetails.jsp?issueid=A917B6BE-4A3A-4AA2-8BA1-CC8DD722D6AB&copyid=3082D538-D0AE-403E-973B-C434F4C20BA3
http://federaltimes.com/index.php?S=3597239
http://www.isn.ethz.ch/news/sw/details.cfm?ID=19140
http://biometrics.gov/

Guest Post at ZDNet Zero Day

For your reading pleasure: a guest op-ed piece in Ryan Nariene's Zero Day blog at ZDNet.

:)

A recent blog proclaiming that Twitter could soon become a rival to PayPal made me shudder in fear. The blog author postulated that Twitter could offer a method to transfer money between users via “tweet.” After reading these posts I thought to myself, “Cool, what a super convenient Web 2.0-ish way to lose my money!”

There are many pitfalls to this but I will start by tackling the obvious concerns. Twitter is extremely user-friendly by allowing users a plethora of interfaces: SMS, IM, third-party apps and Web sites, and, of course, the Twitter site itself. With so many ways to communicate, how do we verify that the person sending money is actually authorized to do so? If a Twitter users’ Facebook, Google Talk, or Netvibes account becomes compromised, their money is instantly at risk. Users of SMS are at even greater risk as there is absolutely no authentication or authorization – the phone number itself is the only way to “prove” you are the sender. Unfortunately, SMS is easily spoofed, and there are multiple Web sitesapplications that allow you to send a text message from any phone number you wish. Nitesh Dhanjani wrote about how Twitter is already vulnerable to this sort of attack; imagine the havoc that would be caused by spoofed test messages that transferred funds.

Since users are limited to 140 characters per tweet, the use of URL redirection sites is a normal (and encouraged) practice. Unfortunately, that opens up users to cross-site scripting attacks that would be crafted to send money between accounts without the user’s knowledge. All a malicious user would need is one hit every once in a while to make it worth the trouble of setting up a bot to send random URLs to users. And while Twitter has said it is cracking down on bots, it is a long way from solving that problem.

Beyond the security issue is stability. What happens to payment messages that get lost when Twitter is down? Do you resend when the site is back up? What if an acknowledgement message is lost during downtime? Twitter users have gotten used to seeing the “Fail Whale” quite often over the past few months and they are vocal with their frustration. Multiply that frustration with the anger one would feel if his or her payment got screwed up. Availability of data is one of the cornerstones of security and until Twitter has a its stability problems fixed, any payment system would be a nightmare.

Many of the issues I bring up have possible solutions. Two-factor authentication is something that has come up as a possible solution to ensure the Twitter user is the actual account holder. But one major issue with a two-factor solution is timing. A one-time code can be attached to a message but if Twitter is down or if the message gets delayed for a period of time then the tweet will eventually get through but the code will no longer be valid. There are many other issues with two-factor authentication such as spoofing, man-in-the-middle attacks, and non-security issues such as deployment and support.

Even if a secure method of tweeting money from one account to another can be worked out and the legal and payment issues are smoothed out, the biggest question that remains is: why bother? If I have to carry a token with me or log into the Web site to send money the benefits of a Twitter payment system goes away and I am left to wonder: “Why don’t we just use PayPal?” Ultimately, that question — not ones of stability or security — is the one that will keep Twitter from joining the online payment industry anytime soon.

Information Security Around The House : Part 3 : Antivirus

Antivirus

From the Wikipedia article on Antivirus:

Antivirus software are computer programs that attempt to identify, neutralize or eliminate malicious software. The term "antivirus" is used because the earliest examples were designed exclusively to combat computer viruses; however most modern antivirus software is now designed to combat a wide range of threats, including worms, phishing attacks, rootkits, trojan horses and other malware. Antivirus software typically uses two different approaches to accomplish this:

• examining (scanning) files to look for known viruses matching definitions in a virus dictionary, and
• identifying suspicious behavior from any computer program which might indicate infection.

The second approach is called heuristic analysis. Such analysis may include data captures, port monitoring and other methods.

Grave Robbers Hit Montgomery Ward For Up To 200K Credit Card Numbers

The AP is reporting that the online-retail store Montgomery Ward was breached back in December with between 51,000 to 200,000 credit card numbers, expiration dates, and CVV2 numbers. Details of the breach aren't widely known and it wasn't reported whether Direct Marketing Services [DMS], the company that purchased the Montgomery Ward name out of bankruptcy, was PCI DSS compliant.

None of that information is that troubling to me however. Breaches happen. We learn from them (hopefully) and move on. What irks me about this one is that DMS didn't notify their customers after the breach occurred. Since the penalties for non-disclosure are far less (non-existent in some cases) than the costs associated with replacing credit cards and monitoring up to 200,000 credit reports DMS did what companies do best: Act in their own self-interest, watch the bottom line, and hope nobody finds out.

Obviously there is no easy solution to this problem. DMS followed guidelines and notified banks of the breach. However, it is not mandated that the bank notify a customer that their information was potentially compromised. Disclosure is left up to the merchant that was originally hit and will ultimately pay for any and all costs associated with replacement of cards and monitoring of accounts.

Unfortunately, this is a case where the private market will not lead to an efficient outcome. Legislation is needed in order to hold companies accountable for the non-disclosure of private and financial information breaches. We will see proper disclosure of breaches when we start walking CIO's and CEO's out of headquarters in handcuffs and making the fines high enough to make full disclosure seem like a bargain. I hope companies start doing the right thing by their customers but I, for one, will hold my breath.

Article Review: Security Features on Switches

InformIT: Security Features on Switches & Securing Layer 2

If you are a switch jockey you know the difficulties in applying security down the stack past layers 3 & 4 and into layer 2.
There are many layer-2 security features available but unfortunately in a large dynamic environment they are typically difficult to deploy. Chapter 2 from Network Security Technologies and Solutions (CCIE Professional Development Series) book by Cisco  Publishing gives the reader a rundown of all the technologies at your disposal (when using a Cisco Catalyst switch of course!).

What did I learn?
Being a former switch jockey myself (and being security conscience of course) I was pretty familiar with most of the topics covered in this chapter. However, that isn't to say I know everything and there were definitely topics that I was either unfamiliar with or learned more about while reading.


The port-level controls is standard fair with a new twist (for me) I hadn't heard of the Protected Ports (PVLAN Edge) feature with basically prevents ports within the same VLAN from communicating with each other. This feature would allow you to forgo VLAN-ACL's if you didn't want any communication between ports to occur.

The section on ACL's was extremely straight forward with a few nice diagrams explaining the concepts thrown in for us visual-learner types. If you don't know ACL's yet I would recommend starting with a book geared toward the CCNA level and not the CCIE as this chapter explores a few advanced concepts (layer 2 and VLAN ACL being a few).

The rest of the chapter is spent on some of the lesser-known security controls available to network and security professionals. DHCP Snooping, Dynamic ARP Inspection, and Control Plane Policing (CoPP) are just a few of the subjects covered. Pretty paranoid stuff and most likely not deployed in most of your larger, non-ISP shops (in my experience, YMMV).

The article also gives us a list of best practices to follow for effective L2 security. I will list a few of these best practices but I recommend you click on the link above and read the article yourself as you will most likely learn something interesting and useful.

• Always use a dedicated VLAN ID for all trunk ports.
• Be skeptical; avoid using VLAN 1 for anything.
• Disable DTP on all non-trunking access ports.
• Use MD5 authentication where applicable.
• Disable CDP where possible.
• Shut down or disable all unused ports on the switch, and put them in a VLAN that is not used for normal operations.

Happy Independence Day