Entries Tagged "computer security"
Page 23 of 33
Faking Hardware Memory Access
[Joanna] Rutkowksa will show how an attacker could prevent forensics investigators from getting a real image of the memory where the malware resides. “Even if they somehow find out that the system is compromised, they will be unable to get the real image of memory containing the malware, and consequently, they will be unable to analyze it,” says Rutkowska, senior security researcher for COSEINC.
"One Laptop per Child" Security System
It’s called “Bitfrost,” and it’s interesting:
We have set out to create a system that is both drastically more secure and provides drastically more usable security than any mainstream system currently on the market. One result of the dedication to usability is that there is only one protection provided by the Bitfrost platform that requires user response, and even then, it’s a simple ‘yes or no’ question understandable even by young children. The remainder of the security is provided behind the scenes. But pushing the envelope on both security and usability is a tall order, and it’s important to note that we have neither tried to create, nor do we believe we have created, a “perfectly secure” system. Notions of perfect security in the real world are foolish, and we distance ourselves up front from any such claims.
Read the design principles and design goals. And there’s an article on the Wired website, and there’s a Slashdot thread.
What they propose to do is radical, and different—just like the whole One Laptop Per Child program. Definitely worth paying attention to, and supporting if possible.
Security Analysis of Windows Vista
Symantec has published a good analysis of Windows Vista security.
Information Security and Externalities
Information insecurity is costing us billions. There are many different ways in which we pay for information insecurity. We pay for it in theft, such as information theft, financial theft and theft of service. We pay for it in productivity loss, both when networks stop functioning and in the dozens of minor security inconveniences we all have to endure on a daily basis. We pay for it when we have to buy security products and services to reduce those other two losses. We pay for the lack of security, year after year.
Fundamentally, the issue is insecure software. It is a result of bad design, poorly implemented features, inadequate testing and security vulnerabilities from software bugs. The money we spend on security is to deal with the myriad effects of insecure software. Unfortunately, the money spent does not improve the security of that software. We are paying to mitigate the risk rather than fix the problem.
The only way to fix the problem is for vendors to improve their software. They need to design security in their products from the start and not as an add-on feature. Software vendors need also to institute good security practices and improve the overall quality of their products. But they will not do this until it is in their financial best interests to do so. And so far, it is not.
The reason is easy to explain. In a capitalist society, businesses are profit-making ventures, so they make decisions based on both short- and long-term profitability. This holds true for decisions about product features and sale prices, but it also holds true for software. Vendors try to balance the costs of more secure software—extra developers, fewer features, longer time to market—against the costs of insecure software: expense to patch, occasional bad press, potential loss of sales.
So far, so good. But what the vendors do not look at is the total costs of insecure software; they only look at what insecure software costs them. And because of that, they miss a lot of the costs: all the money we, the software product buyers, are spending on security. In economics, this is known as an externality: the cost of a decision that is borne by people other than those taking the decision.
Normally, you would expect users to respond by favouring secure products over insecure products—after all, users are also making their buying decisions based on the same capitalist model. Unfortunately, that is not generally possible. In some cases software monopolies limit the available product choice; in other cases, the ‘lock-in effect’ created by proprietary file formats or existing infrastructure or compatibility requirements makes it harder to switch; and in still other cases, none of the competing companies have made security a differentiating characteristic. In all cases, it is hard for an average buyer to distinguish a truly secure product from an insecure product with a ‘trust us’ marketing campaign.
Because of all these factors, there are no real consequences to the vendors for having insecure or low-quality software. Even worse, the marketplace often rewards low quality. More precisely, it rewards additional features and timely release dates, even if they come at the expense of quality. The result is what we have all witnessed: insecure software. Companies find that it is cheaper to weather the occasional press storm, spend money on PR campaigns touting good security and fix public problems after the fact, than to design security in from the beginning.
And so the externality remains…
If we expect software vendors to reduce features, lengthen development cycles and invest in secure software development processes, it needs to be in their financial best interests to do so. If we expect corporations to spend significant resources on their own network security—especially the security of their customers—it also needs to be in their financial best interests.
Liability law is one way to make it in those organisations’ best interests. If end users could sue software manufacturers for product defects, then the cost of those defects to the software manufacturers would rise. Manufacturers would then pay the true economic cost for poor software, and not just a piece of it. So when they balance the cost of making their software secure versus the cost of leaving their software insecure, there would be more costs on the latter side. This would provide an incentive for them to make their software more secure.
Basically, we have to tweak the risk equation in such a way that the Chief Executive Officer (CEO) of a company cares about actually fixing the problem—and putting pressure on the balance sheet is the best way to do that. Security is risk management; liability fiddles with the risk equation.
Clearly, liability is not all or nothing. There are many parties involved in a typical software attack. The list includes:
- the company that sold the software with the vulnerability in the first place
- the person who wrote the attack tool
- the attacker himself, who used the tool to break into a network
- and finally, the owner of the network, who was entrusted with defending that network.
100% of the liability should not fall on the shoulders of the software vendor, just as 100% should not fall on the attacker or the network owner. But today, 100% of the cost falls directly on the network owner, and that just has to stop.
Certainly, making software more secure will cost money, and manufacturers will have to pass those costs on to users in the form of higher prices. But users are already paying extra costs for insecure software: costs of third-party security products, costs of consultants and security services companies, direct and indirect costs of losses. But as long as one is going to pay anyway, it would be better to pay to fix the problem. Forcing the software vendor to pay to fix the problem and then passing those costs on to users means that the actual problem might get fixed.
Liability changes everything. Currently, there is no reason for a software company not to offer feature after feature after feature, without any regard to security. Liability forces software companies to think twice before changing something. Liability forces companies to protect the data they are entrusted with. Liability means that those in the best position to fix the problem are actually responsible for the problem.
Information security is not a technological problem. It is an economics problem. And the way to improve information security is to fix the economics problem. If this is done, companies will come up with the right technological solutions that vendors will happily implement. Fail to solve the economics problem, and vendors will not bother implementing or researching any security technologies, regardless of how effective they are.
This essay previously appeared in the European Network and Information Security Agency quarterly newsletter, and is an update to a 2004 essay I wrote for Computerworld.
NSA Helps Microsoft with Windows Vista
Is this a good idea or not?
For the first time, the giant software maker is acknowledging the help of the secretive agency, better known for eavesdropping on foreign officials and, more recently, U.S. citizens as part of the Bush administration’s effort to combat terrorism. The agency said it has helped in the development of the security of Microsoft’s new operating system—the brains of a computer—to protect it from worms, Trojan horses and other insidious computer attackers.
[…]
The NSA declined to comment on its security work with other software firms, but Sager said Microsoft is the only one “with this kind of relationship at this point where there’s an acknowledgment publicly.”
The NSA, which provided its service free, said it was Microsoft’s idea to acknowledge the spy agency’s role.
It’s called the “equities issue.” Basically, the NSA has two roles: eavesdrop on their stuff, and protect our stuff. When both sides use the same stuff—Windows Vista, for example—the agency has to decide whether to exploit vulnerabilities to eavesdrop on their stuff or close the same vulnerabilities to protect our stuff. In its partnership with Microsoft, it could have decided to go either way: to deliberately introduce vulnerabilities that it could exploit, or deliberately harden the OS to protect its own interests.
A few years ago I was ready to believe the NSA recognized we’re all safer with more secure general-purpose computers and networks, but in the post-9/11 take-the-gloves-off eavesdrop-on-everybody environment, I simply don’t trust the NSA to do the right thing.
“I kind of call it a Good Housekeeping seal” of approval, said Michael Cherry, a former Windows program manager who now analyzes the product for Directions on Microsoft, a firm that tracks the software maker.
Cherry says the NSA’s involvement can help counter the perception that Windows is not entirely secure and help create a perception that Microsoft has solved the security problems that have plagued it in the past. “Microsoft also wants to make the case that [the new Windows] more secure than its earlier versions,” he said.
For some of us, the result is the exact opposite.
EDITED TO ADD (1/11): Another opinion.
Why Management Doesn't Get IT Security
At the request of the Department of Homeland Security, a group called The Conference Board completed a study about senior management and their perceptions of IT security. The results aren’t very surprising.
Most C-level executives view security as an operational issue—kind of like facilities management—and not as a strategic review. As such, they don’t have direct responsibility for security.
Such attitudes about security have caused many organizations to distance their security teams from other parts of the business as well. “Security directors appear to be politically isolated within their companies,” Cavanagh says. Security pros often do not talk to business managers or other departments, he notes, so they don’t have many allies in getting their message across to upper management.
What to do? The report has some suggestions, the same ones you can hear at any security conference anywhere.
Security managers need to reach out more aggressively to other areas of the business to help them make their case, Cavanagh says. “Risk managers are among the best potential allies,” he observes, because they are usually tasked with measuring the financial impact of various threats and correlating them with the likelihood that those threats will happen.
“That can be tricky, because most risk managers come from a financial background, and they don’t speak the same language as the security people,” Cavanagh notes. “It’s also difficult because security presents some unusual risk scenarios. There are some franchise events that could destroy the company’s business, but have a very low likelihood of occurrence, so it’s very hard to gauge the risk.”
Getting attention (and budget) from top executives such as risk managers, CFOs, and CEOs, means creating metrics that help measure the value of the security effort, Cavanagh says. In the study, The Conference Board found that the cost of business interruption was the most helpful metric, cited by almost 64 percent of respondents. That metric was followed by vulnerability assessments (60 percent), benchmarks against industry standards (49 percent), the value of the facilities (43.5 percent), and the level of insurance premiums (39 percent).
Face time is another important way to gain attention in mahogany row, the report says. In industries where there are critical infrastructure issues, such as financial services, about 66 percent of top executives meet at least once a month with their security director, according to the study. That figure dropped to around 44 percent in industries without critical infrastructure issues.
I guess it’s more confirmation of the conventional wisdom.
The full report is available, but it costs $125 if you’re something called a Conference Board associate, and $495 if you’re not. But my guess is that you’ve already heard everything that’s in it.
The Zotob Worm and the DHS
On August 18 of last year, the Zotob worm badly infected computers at the Department of Homeland Security, particularly the 1,300 workstations running the US-VISIT application at border crossings. Wired News filed a Freedom of Information Act request for details, which was denied.
After we sued, CBP released three internal documents, totaling five pages, and a copy of Microsoft’s security bulletin on the plug-and-play vulnerability. Though heavily redacted, the documents were enough to establish that Zotob had infiltrated US-VISIT after CBP made the strategic decision to leave the workstations unpatched. Virtually every other detail was blacked out. In the ensuing court proceedings, CBP claimed the redactions were necessary to protect the security of its computers, and acknowledged it had an additional 12 documents, totaling hundreds of pages, which it withheld entirely on the same grounds.
U.S. District Judge Susan Illston reviewed all the documents in chambers, and ordered an additional four documents to be released last month. The court also directed DHS to reveal much of what it had previously hidden beneath thick black pen strokes in the original five pages.
“Although defendant repeatedly asserts that this information would render the CBP computer system vulnerable, defendant has not articulated how this general information would do so,” Illston wrote in her ruling (emphasis is lllston’s).
The details say nothing about the technical details of the computer systems, and only point to the incompetence of the DHS in handling the incident.
Details are in the Wired News article.
Hacker-Controlled Computers Hiding Better
If you have control of a network of computers—by infecting them with some sort of malware—the hard part is controlling that network. Traditionally, these computers (called zombies) are controlled via IRC. But IRC can be detected and blocked, so the hackers have adapted:
Instead of connecting to an IRC server, newly compromised PCs connect to one or more Web sites to check in with the hackers and get their commands. These Web sites are typically hosted on hacked servers or computers that have been online for a long time. Attackers upload the instructions for download by their bots.
As a result, protection mechanisms, such as blocking IRC traffic, will fail. This could mean that zombies, which so far have mostly been broadband-connected home computers, will be created using systems on business networks.
The trick here is to not let the computer’s legitimate owner know that someone else is controlling it. It’s an arms race between attacker and defender.
Dying with your Passwords
Interesting story on the risks of dying without telling anyone your computer passwords.
Sidebar photo of Bruce Schneier by Joe MacInnis.