We have written in the past of the dangers of file sharing not so much from copyright prosecution point (although the dangers are real) but so much from having the file sharing software "incidentally" share files located on the networked computer. A high-profile data breach from the Washington, DC area confirms the dangers. The case is about having investment and personal information of high-powered Washington, DC figures, including Supreme Court justices, shared to anybody in the world.
From the article which appeared this morning in the Washington Post:
Sometime late last year, an employee of a McLean investment firm decided to trade some music, or maybe a movie, with like-minded users of the online file-sharing network LimeWire while using a company computer. In doing so, he inadvertently opened the private files of his firm, Wagner Resource Group, to the public.
That exposed the names, dates of birth and Social Security numbers of about 2,000 of the firm’s clients, including a number of high-powered lawyers and Supreme Court Justice Stephen G. Breyer.
It is very difficult to protect against this type of breach, as it is due to human error. Many companies have IT policies which prohibit file sharing software. Many IT departments are successfully able to block "some" of the file sharing P2P traffic. But there are always some who download, install, and run the file sharing software on company hardware containing sensitive information without much regard of the consequences.
Many emails happily reach their final and intended destination. But there are some emails which arrive where they are not intended to. There are two recent stories which suggest not only how people should be careful what the "TO:" field in their email says, but also use some common sense.
The first story is about the "donotreply.com" domain, whose owner admitted that he receives millions of unintended emails each week, many with substantially sensitive information. Many senders of bulk email do not want to have each recipient to be able to hit ‘Reply’ and send a return message. As a result, they just type something that is intended to remind the recipient not to email back, for example, "please@donotreply.com." However, there are people who send emails back, and according to the owner of the donotreply.com domain, there are some very sensitive wayward emails. For example, a bank sent to a donotreply.com email address a PDF with a list of all computers within the bank which are not properly patched with up-to-date security settings.
The second story is about a website promoting Mildenhall, a small town in Suffolk, UK, which owned the domain www.mildenhall.com. However, Mildenhall also hosted a U.S. Air Force base with 2,500 servicemen and women. As a result, the mildenhall.com started receiving hundreds of emails, intended for the US Air Force personnel at Mildenhall. Among the emails received, future flight paths for Air Force One. The domain’s owner tried to warn the US base, but the emails kept coming. Finally, the domain owner decided to shut down the site as to avoid confusion and leak of potentially sensitive information.
These two stories highlight some of the biggest problems with email as a communication tool, especially for sensitive and unencrypted information. First is the trend of domain owners turning on their "catch all" email setting whereby all email directed to a particular domain, even if the email address does not exist, is captured and treated as "received" as opposed to being returned as "undeliverable." The second is the casual approach towards email. There are plenty of stories about major litigation blunders, competitive information disclosures, or simply embarassing personal stories which have been sent to the wrong party and subsequently leaked to the world. Email users, especially users dealing with sensitive information, should create a habit, if not a procedure, of checking every outgoing email for accuracy of the recipient, at the least. Finally, the use of email for transmission of sensitive information without encryption is troubling. What is the appropriate treshold level for encrypting email - that depends on the organization and the documents being transmitted, but the senders of the list of vulnerable PCs on the network or of the flight path of Air Force One should have known better to use encryption.
Personal information on a few thousand ABM Amro Mortgage Group (unit of Citigroup) customers has been leaked out to anybody in the world through a peer-to-peer (P2P) software. The names, Social Security numbers, and mortgage information of some 5,200 people which was stored on an employee laptop was shared via the LimeWire P2P software.
While it is unclear how many times the information has been downloaded over the P2P network, the fact that a computer containing a large amount of personal information was allowed to run P2P software is inexcusable. In all likelihood, Citigroup (or ABM Amro Mortgage) have some sort of restrictions (administrative policy or an IT set of software restrictions) which prohibit P2P sharing in general and in all likelihood the employee who used the laptop in question did so without authorization. Even so, the problem remains at Citi and their IT security personnel for failing to prevent or detect such software earlier. Placing the blame on the individual user is not an excuse as it is Citi’s reputation (and possibly checkbook after claims by these 5,200 affected people are filed) on the line.
According to Pike & Fischer, in testimony at a July House subcommittee hearing on P2P risks, LimeWire Chairman Mark Gorton said that a "small fraction" of users override safe default settings that come with the program, despite the company’s warnings and precautions. The company is working on a "new generation of user interfaces and tools designed with neophyte users in mind," making it "even easier for users to see which files they are sharing and to intuitively understand the controls available to them," he said.
Even if LimeWire is successful in preventing users from ‘inadvertently’ sharing their business documents folders, a company which takes its intellectual property and information security and privacy seriously should, in most cases, take proactive steps to weed out P2P software from its networks.
Many businesses run their own wireless infrastructures and many know well to protect it. But how do you know when it is time to use a stronger encryption algorithm to protect the data sent wirelessly?
Generally, there are two possibilities. One is to wait until hackers break into your network by exploiting the easy-to-break WEP encryption you have on your wireless network and as a result steak millions of customers’ credit card numbers and personal data. Example: the TJX story.
The second, and the better possibility, is to do it before your (or your client’s) organization is prominently featured in the Wall Street Journal. Example: the TJX story.
Here’s a short excerpt of what should make every IT director to think about switching from WEP to WPA or better.
Investigators found that TJX was using a weak encryption protocol to protect its consumer data in July 2005, when hackers first broke into its computer system. The protocol, known as Wired Equivalent Privacy, or WEP, isn’t recommended by securities experts even for wireless home networks because it is so vulnerable to hackers.
TJX decided to upgrade to a more secure Wi-Fi Protected Access encryption protocol at the end of September 2005, Canadian officials said. By then, however, hackers had been able to access the company’s internal transaction database. They did so initially from outside two stores in Miami, the probe found.
- TJX’s Security System Faulted in Canada Probe, Wall Street Journal, September 26, 2007.
A congressional report scheduled to be released on August 3 but reported by the Washington Post alleges that the U.S. government’s main border control system has many security weaknesses, placing at risk of theft or manipulation the data of millions of passengers, including passport, visa, Social Security numbers, and biometrics, such as fingerprints.
The US-VISIT system has been in place for several years and it is considered one of the first lines of defense aimed at stopping terrorists or other unauthorized persons from entering the United States at hundreds of airports, seaports, and land crossings. The system collects passengers’ personal information and stores it in a massive database which can be data-mined for various border control and immigration purposes. The US-VISIT system is said to store facial images and fingerprints of 90 million individuals and is used to vet 54 million border crossings each year. Adding the biometric information on top of the detailed personal information stored in the system, it makes it a pretty attractive target for cyber criminals or hostile foreign governments.
According to the report, "[w]eaknesses existed in all control areas and computing device types reviewed."
"These weaknesses collectively increase the risk that unauthorized individuals could read, copy, delete, add, and modify sensitive information," GAO investigators said in the report.
It is not hard to imagine the possible national security and individual privacy consequences that a breach of this vast system may have. Let’s hope that the vulnerabilities are closed quickly.
We have written about the prevalence of botnets and the fact that they are one of the major causes of modern-day cyberattacks. This is hardly in any dispute today. The debate is what should be done to fight the increasingly powerful botnets and there does not seem to be an easy answer.
Some have suggested that ISPs should be responsible for botnets as they (the ISPs) are the party in the channel of Internet traffic closest to the infected at-home zombie PC that is most capable of stopping the proliferation of malicious Internet traffic either originating from an already infected zombie PC or targeting with the purpose to infect a PC within the ISPs network.
A recent report by the the Internet Security Operations Task Force (ISOTF) suggests that many ISPs not only fail to address a substantial number of botnet complaints, but some ISPs indicated in the report did not address any of the complaints directed at them.
The ISOTF report suggests that many ISPs are slow to react to botnet complaints. This is a troubling fact because the ISP is put on notice of a problem customer or a computer and the ISP fails to do anything to stop an already identified threat. This is not proactive scanning, detection, or prevention which may require sophistication network traffic shaping or detection. This is simple customer relationship management in approaching the complaint and resolving it in a timely fashion. In fairness to ISPs, many of which are small operations, they may not have the manpower and resources to deal with a large-scale botnet attack on their network and respond to all complaints in a timely fashion.
On the other side of the equation is the proactive botnet prevention. There are commercial services which provide real-time monitoring for ISPs. For example (and without any endorsement or personal interest), Arbor Networks offers a service called PeakFlow that continually monitors networks to look for threats such as DoS attacks. Of course such services cost money, but the ISP is in the best position to spread the cost throughout the subscribers. The customers would get at least some assurance that their at-home PCs would work better and be less likely to become botnet zombies. The ISP would free some resources from having to deal reactively with botnet complaints and be able to shift these resources to more productive tasks.
There are other aspects of this debate. For example, some would argue that it is not the ISPs business to filter traffic and determine on its own what kind of traffic should be filtered or not — a modified version of a net neutrality argument. Others argue that it is the end-user’s responsibility to ensure that his or her PC is properly protected and, if infected, to properly clean it up. However, such arguments seem to miss the point. ISPs should be able to protect their own infrastructure by having the sole authority to determine what is malicious traffic and act in appropriate way to stop such traffic. And although individual users should be responsible for their own PCs, the cumulative effect of zombie PCs within an ISPs network is to potentially threaten the ISPs operations and, again, the ISP should be able to act to protect itself.
There is no silver bullet for this problem. But if good technological solutions are available for ISPs to use, and if such solutions are economically feasible, an ISP should deploy them for their own networks’ sake and for the sake of the security of the Internet as a whole.
Despite numerous reports, directives, and promises by the Federal Government that they are making their IT systems more secure, a July 27, 2007, GAO report suggested that the government continues to provide inadequate data security to protect critical operations and personal information maintained by various agencies.
"Significant weaknesses in information security policies and practices threaten the confidentiality, integrity, and availability of critical information and information systems used to support the operations, assets, and personnel of most federal agencies," the GAO concluded. Information security continues to be a governmentwide high-risk issue, GAO said.
According to the GAO report, every one of 24 major federal agencies and departments reviewed had weaknesses in at least one major data security area. The report recommended that agency inspector generals cover in greater detail information security processes such as system testing and evaluation, training, and incident reporting.
Read the full GAO report, "Information Security: Despite Reported Progress, Federal Agencies Need to Address Persistent Weaknesses" (GAO-07-837)
Many information security professionals find it difficult to put a number on the cost of a breach and thus justify requesting more funds in their budget. Here’s a useful piece of information for them - the TJX companies reported that in the first quarter of FY08 (Feb - Apr 2007) the breach cost them $17 million. The main components of the price tag were investigating the incident, upgrading the company’s network security, communicating with its customers, and legal fees.
Note that this cost covers only the three months for the reporting quarter and does exclude lost goodwill which is very hard to estimate but surely the damage to TJX’s reputation is significant. The company estimates that the costs for the next quarter would be similar. But this is not all. In a statement TJX said,
Beyond these costs, TJX does not yet have enough information to reasonably estimate the losses it may incur arising from this intrusion, including exposure to payment card companies and banks, exposure in various legal proceedings that are pending or may arise, and related fees and expenses, and other potential liabilities and other costs and expenses.
With the increasing number of lawsuits against TJX the cost will surely increase.
An interesting article from ComputerWorld shows another angle direction from which an organization may be attacked electronically. It is not enough that security managers and ISOs need to worry about compromised PCs, servers, or smart phones but now they have also to worry about their printers.
At the Black Hat conference in Las Vegas in August, O’Connor delivered a blow-by-blow presentation on how to bypass authentication, inject commands at the root level and create shell code to take over printers in Xerox Corp.’s WorkCentre line of printers, which run on Linux operating systems. He described the kinds of mischief you could do with a compromised printer, including password-catching, password-snarfing (changing passwords), hijacking functions, grabbing print jobs and playing with a billing program.
More at ComputerWorld.
Daniel Miessler has compiled a list of 10 questions that should be asked of a candidate for a security (or even any IT position.) Although not perfect, this list should provide a good starting point for an employer trying to understand whether the candidate has enough basic security understanding
- Where do you get your security news from?
Here I’m looking to see how in tune they are with the security community. Answers I’m looking for include RSS feeds for solid sites like rootsecure, secguru, astalavista, whitedust, internet storm center, etc. The exact sources don’t really matter. What does matter is that he doesn’t respond with, “I go to the CNET website.” (and nothing else). It’s these types of answers that will tell you he’s likely not on top of things.
- If you had to both encrypt and compress data during transmission, which would you do first, and why?
If they don’t know the answer immediately it’s ok. The key is how they react. Do they panic, or do they enjoy the challenge and think through it? I was asked this question during an interview at Cisco. I told the interviewer that I didn’t know the answer but that I needed just a few seconds to figure it out. I thought out loud and within 10 seconds gave him my answer: “Compress then encrypt. If you encrypt first you’ll have nothing but random data to work with, which will destroy any potential benefit from compression.”
- What kind of computers do you run at home?
Good answers here are anything that shows you he’s a computer/technology/security enthusiast and not just someone looking for a paycheck. So if he’s got multiple systems running multiple operating systems you’re probably in good shape. What you don’t want to hear is, “I like to leave my computers at work.” I’ve yet to meet a serious security guy who doesn’t have a considerable home network.
- What port does
pingwork over?
A trick question, to be sure, but an important one. If he starts throwing out port numbers you may want to immediately move to the next candidate. Hint: ICMP is a layer 3 protocol (it doesn’t work over a port) A good variation of this question is to ask whetherpinguses TCP or UDP.
- How exactly does
traceroute/tracertwork?
This is a fairly technical question but it’s an important concept to understand. It’s not natively a “security” question really, but it shows you whether or not they like to understand how things work, which is crucial for an infosec professional. If they get it right you can lighten up and offer extra credit for the difference between Linux and Windows versions.The key point people usually miss is that each packet that’s sent out doesn’t go to a different place.Many people think that it first sends a packet to the first hop, gets a time. Then it sends a packet to the second hop, gets a time, and keeps going until it gets done. That’s incorrect. It actually keeps sending packets to the final destination; the only change is the TTL that’s used. The extra credit is the fact that Windows uses ICMP by default while Linux uses UDP.
- Describe the last program or script that you wrote. What problem did it solve?
This is a trick as well. All we want to see is if the color drains from the guy’s face. If he panics then we not only know he’s not a programmer (not necessarily bad), but that he’s afraid of programming (bad). I know it’s controversial, but I think that any high-level security guy needs some programming skills. They don’t need to be a God at it, but they need to understand the concepts and at least be able to muddle through some scripting when required.
- What are Linux’s strengths and weaknesses vs. Windows?
Look for biases. Does he absolutely hate Windows and refuse to work with it? This is a sign of an immature hobbyist who will cause you problems in the future. Is he a Windows fanboy who hates Linux with a passion? If so just thank him for his time and show him out. Linux is *everywhere* in the security world.
- What’s the difference between a risk and a vulnerability?
As weak as the CISSP is as a security certification it does teach some good concepts. Knowing basics like risk, vulnerability, threat, exposure, etc. (and being able to differentiate them) is important for a security professional.
- What’s the goal of information security within an organization?
This is a big one. What I look for is one of two approaches; the first is the über-lockdown approach, i.e. “To control access to information as much as possible, sir!” While admirable, this again shows a bit of immaturity. Not really in a bad way, just not quite what I’m looking for.A much better answer in my view is something along the lines of, “To help the organization succeed.”
This type of response shows that the individual understands that business is there to make money, and that we are there to help them do that. It is this sort of perspective that I think represents the highest level of security understanding — a realization that security is there for the company and not the other way around.
- Are open-source projects more or less secure than proprietary ones?
The answer to this question is often very telling about a given candidate. It shows 1) whether or not they know what they’re talking about in terms of development, and 2) it really illustrates the maturity of the individual (a common theme among my questions).
My main goal here is to get them to show me pros and cons for each. If I just get the “many eyes” regurgitation then I’ll know he’s read Slashdot and not much else. And if I just get the “people in China can put anything in the kernel” routine then I’ll know he’s not so good at looking at the complete picture.The ideal answer involves the size of the project, how many developers are working on it (and what their backrounds are), and most importantly — quality control. In short, there’s no way to tell the quality of a project simply by knowing that it’s either open-source or proprietary. There are many examples of horribly insecure applications that came from both camps.