I got my family to watch the ABC special on TV tonight. What an amazing and inspirational story!
My wife and I agree that they should make a Hollywood rendition of his life story and that Jim Carrey (from his more dramatic roles like The Truman Show) should play the part of Prof Pausch. There's an amazing resemblance in both their appearance and facial expressions as well as their desire to have fun.
Prof. Pausch, your memory will live on after you. Thanks for taking the time to share your thoughts. Excellent "head fakes".
It's important to have accurate mileage ratings on cars, and it's hard to understand how the EPA could be so bad at it.
Well, because they're not driving the cars on the road at all when they test for fuel economy. How can any of the numbers be accurate in such an unrealistic testing environment?
I am a security analyst by profession and education [not that it matters, but as a distinction of the previous poster's non-security background].
You are somewhat correct. Sloppy coding techniques do lead to security vulnerabilities which lead to exploit code which eventually lead to websites burning, etc. However, that is only one category of security flaws. If you look at, say the GDI flaws Microsoft had last year (for example), you'll notice that vulnerability is actually a design flaw-- allowing executable code to live embedded in file objects was the problem [the embedded code's trustworthiness had no mechanism to be measured and therefore any user double-clicking on a malicious code-within-an-image file would have their system compromised]. Design flaws are much more tricky to prevent and most experts attempting to solve this problem suggest that development houses should leave the design aspects of their code to people with a background in security principles, or at least have some sort of design-time security review. This is mostly what formalized threat modeling attempts to do.
But you are right... there are vast categories of vulnerabilities that end up compiled in code unnecessarily. And a great place to start for anyone looking to weed these unforgiveable buffer overrun types of issues out of their code is to use a static analyzer on their code. Essentially, static analysis tools attempt to catch these obvious (or sometimes not so obvious) bugs before the code is shipped to customers. Fortify Software is a great place to look for such a tool.
'Responsible disclosure' is a euphemism for 'we can't fix bugs fast enough, so if you keep the vulnerabilities a secret, it'll help us to save face.'
Wrong. Responsible Disclosure is an attempt to curb the greater than linear complexity associated with testing patches.
If a bug is found in product X, then all applications that reside upon product X need to be validated as functional. In an enterprise, that could include applications plus interfaces that are unique to that organization. Most studies on code complexity find that complexity increases at a greater than linear clip. Responsible Disclosure is the opportunity to level the playing field between the "good guys" and the "bad guys" (deliberately avoiding hat color references).
Anyone who claims Full Disclosure is the best for his company is:
A) Not a sysadmin at all
B) A lazy sysadmin who refuses to fully test patches
-OR-
C) A vulnerability pimp (e.g. IDS, AV, Vuln Assessment, etc.)
Wrong. Encryption is only as good as the key. Or in practical cases, only as good as the password that protects the key. And in all likelihood (like most enterprises) they key is probably managed in such a way that dozens of people could have accessed it, especially if it was shared "enterprise" data.
Security people turn to crypto as the answer to everything. It isn't. Even cryptographer Bruce Schneier lamented that mistake in the opening of his book Secrets and Lies. Cryptography should always be a last resort. Encrypted data is not protected forever. At a maximum, the lifespan of its protection is limited by Moore's Law. At a minimum, the key management.
This data should not have resided upon drives that were removable without notice. Period. Forget about crypto.
I have said this before, and I'll say this again: we (the IT industry) created a problem with mobile computing. We allow data to be stored on mobile devices in a distributed computing environment and then years later (after we realize the problem we created), we freak out and throw magic crypto fairy dust at the problem. Encrypted hard drives are only as good as they keys that protect them. Since enterprises need the flexibility of a large support staff, many people will have access to the keys. And since the products are designed to run so that even computer illiterate users will use the software, a shoulder-surfer can backdoor the whole process. The best way to protect this data... and we all know it, most of us just refuse to accept it... is to return to the mainframe days and centralized computing. If that data stayed on a central SAN and the environment was not set up for removable drives, then this would not be news.
What Bruce is saying is that security dollars are being spent on band-aids and duct tape. Those same dollars at the root of the problem are more efficient for everyone.
Assume we can solve the malware problem (which I think we can, it's just a matter of applying default-deny logic that we learned from our early firewall days to our software inventory). So what if there's a new approach created (because, after all, security is a human vs. human problem, not a human vs. machine problem-- you're right on that point). The point is, rather than buying some aftermarket doo-dad for resolving new security problem X, we can simply go back to the original system's design and say "how can I re-engineer this, considering new threat X?".
We (the general IT industry) built and deployed firewalls because we had too many systems in our machine rooms that we didn't understand. It was an attempt to simplify things. Yes, firewalls can serve a purpose, but if we just re-engineered the next generation of systems in our machine rooms, we wouldn't need firewalls.
We built IPSes because we realized that firewalls don't really solve the problem of fixing the bugs in the listening services. Poking a tcp port 80 hole in a firewall still leaves you talking to your http server and whatever applications are running within it. Since we suddenly realized that we don't understand what our application does when you pass it random input (such as 42 "/../" strings), we decided we needed yet-another-band-aid. Instead, if just spent that money making sure the range of allowed input to our http apps was well defined and that the http service and applications were concise enough to handle the predetermined input (resulting in a well-handled error if any other input arrived to the buffer), we wouldn't need IPS.
The list could go on and on and on... The point is, that when the "threat du jour" arrives at your doorstep, do you:
A) Go to the nearest snake-oil salesman and ask him for his anti-threat-du-jour ointment?
-OR-
B) Ask the guy who built your doorstep to re-engineer the doorstep to withstand threat-du-jour in addition to all of the other threats.
Security is all about "Decision Support for Spend" (to quote Dan Geer without a proper reference). Is it more economical to manage your risks with yet-another-component in your environment or to simplify the components you already have to withstand some previously unforeseen threats? Schneier says the latter. [And for that matter, many security people have been saying this for years. This isn't earth shattering.]
Regardless of the student's ethics (or lack thereof), this illustrates a fallacy of trust in computing that often goes overlooked, especially in software security products: transitive (implicit) trust.
Think about it logically for a second... If the administrator (of the University, some enterprise, or even a home network) cannot state anything about the trustworthiness of an unfamiliar computer, how can that same administrator trust the output of some software program designed to assert the trustworthiness of an otherwise untrusted computer?
Trusted input (e.g. Cisco Clean Access)
+ Untrusted computation (unknown host)
!= Trusted output (i.e. an assertion from the CCA that the computer is trustworthy)
The nature of this equation is that the untrusted computer is implicitly trusted to compute its own trustworthiness. What ramifications does that have on the real world analogies?
Banker: Can I trust that you'll repay this loan for $1 Billion?
Some joe off the street: [Hides "will work for food" cardboard sign behind his back.] Uh, sure.
And yet, how many NAC/NAP vendors actually try to challenge the unknown host (java applet, activeX control, native code, etc.)? Answer is: nearly all of them, unfortunately. Even if Cisco fixes this hole, what will happen next? This is not unlike Cisco trying to sell a perpetual motion machine-- this simply defies the "natural laws" of security.
--
NAC is not the answer. How about those good ol' 3270 connections?
We have seen it in firewalls. We have seen it in military-grade physical security. We have seen it in banking. But, why, oh why, do we not see it with malware?
[Analogy warning] About the best analogy I can come up with that describes just exactly how modern anti-[virus, spyware, threat du jour, or just plain "malware"] is this: Enterprises and home users are outsourcing the task of determining the trustworthiness of software applications that reside on their computers. However, they are forcing the outsourcers (the AV companies) to work both backwards and blind. "Blind" in that the outsourcers are not allowed access to see what applications are actually running within the trusted computing environments (or how well those applications play with others (do they run with scissors?)) and "Backwards" in that the outsourcers are not allowed to simply identify trustworthy software applications-- they're forced to identify the good by ruling out everything that is bad. And we all know that "good" and "bad" are in the eyes of the (ahem) beclicker. [End analogy]
What we need instead is a serious set of solutions (and some are starting to crop up, but I won't cite any because I cannot vouch for their quality) that work in the POSITIVE direction, and not the NEGATIVE direction. In other words, we need anti-malware that simply inventories known good applications, comparing all code execution requests against the guest list before letting them get CPU resident. Assuming that code injection techniques (e.g. buffer overruns) can be quelled by other means (microkernels, randomized memory addressing, read only data memory, etc.), then the likelihood of malware infection with a Default-Deny approach (deny all applications except those on the guest-list/inventory) would dramatically approach zero.
The real problem is... economics. Anti-[threat du jour] vendors work on subscriptions because they can check for subscriptions before issuing malware signatures (it's the whole incentive concept we see all over again). But, there is no incentive for the customer to check in with the vendor if their tool is just installed and doesn't need re-configuring until the next time a new application is installed (presumably to update the inventory).
And, like many other comments here have already noted, privilege escalation cannot be overlooked. Supposing a default-deny-anti-malware approach exists (and is worth using), if I operate the computer at the same privilege level of the tool itself [regardless of OS], it is possible for malware to disable the controls. And for the clever readers out there, yes, a set of default deny application inventory controls does seem similar to file system level controls--only execution controls further extend the FS permissions to cover the missing gap.
Who cares about behavioral analysis? What behavior I dislike another will certainly like! Who cares about reputational analysis? What you trust, I may not! But, if we all just stop assuming that we can never speak intelligently about the inventory of "good" applications, then we might finally arrive at a solution that ends malware once and for all (well 99.999% anyway, we'd still have to worry about insider-threat... and at that point it would no longer be a problem (as in a "social problem")).
That makes a good laugh, but in all seriousness, we will likely read headlines like this in the next 5 years or so:
Financial fraud linked to stolen encrypted laptop
In the largest online fraud incident in history, experts linked the Personally Identifiable Information (PII) used in committing the fraudulent acts back to a laptop that was stolen over a year ago. Company X denies the experts' allegations saying "the laptop's hard drive was encrypted." Under this premise, Company X refrained from notifying affected consumers as directed by [insert State Law] because Company X believes disclosed encrypted PII is not the same thing as dislosed unencrypted PII. In a press release yesterday, CEO John Smith said: "We were not obligated to notify consumers of the stolen laptop incident because the sensitive information contained within it was not disclosed. We use state-of-the-art hard drive encryption on all of our laptops, therefore it is impossible that this fraud was related to the stolen laptop." Law Enforcement announced today that they have apprehended the suspect who stole the laptop in question and that the suspect has admitted to stealing the laptop's encryption password as well. Details are expected to follow after the crime ring is completely in custody.
The Top 10 Most Secure Hard Drives in Existence to date:
1. The world's most secure hard drive is the one not used to contain valuable confidential data (experts question its existence). 2. Doesn't exist. 3. Doesn't exist. 4. A hard drive that contains some valuable confidential data, but remains physically within a datacenter. The OS that accesses it does not share its data with other OSes, and runs the full gamut of controls (prevention, detection, correction). 5. Doesn't exist. 6. Doesn't exist. 7. Doesn't exist. 8. Doesn't exist. 9. A hard drive that contains some valuable confidential data, remains physically within a datacenter, but its OS shares data among other systems whose trust is "unknown" or "uncertain".
And tied for 10th place (by virtue of consolation): 10. An encrypted drive in a mobile device relying upon its user for security. 10. An unencrypted drive in a mobile device relying upon its user for security.
If the "laws of physics" of information security were known, we'd likely see a Newtonian-esque law that says something like (in a more scientific form): "any security system that relies upon a person to use the system correctly will fail [miserably]". What Seagate is trying to do is analogous to defying gravity or creating "information security perpetual motion". It just won't improve the situation for anyone (except perhaps the "checklist security" people who can tell their compliance regulation auditors that they can add a point to their useless overall score).
If you really want to see the problem of data exposure reduced to a very tolerable level, the best solution is NOT to fully encrypt the drives of mobile computers, but to change our mobile computing paradigm entirely. Once viable alternatives to general purpose mobile computing are commercially available, we as an industry will finally be able to reduce the events. In other words, once thin-client mobile computing takes off, these full disk encryption products will likely not be needed at all.
Imagine a world where executives, sales people, and most other road-warrior types have a mobile computer that looks like a laptop, but instead of running its own full-blown OS, it simply rides the vast array of mobile carrier networks (like Blackberries currently do) to deliver a virtual desktop hosted in a nice segmented/protected internal network in their employers' data centers (e.g. Citrix, Terminal Servers, or X Windows). Instead of the critical, highly-valuable information floating all over the network and beyond in general purpose computers, we will see a return to the centralized computing paradigm reminiscent of the mainframe days, but with all of the flexibility of the point-and-click user interfaces. Users will interact with their desktops over nice TLS/SSL/IPSEC tunnels over a variety of wireless carrier and 802.11 networks. As long as there's bandwidth, there will be productivity. The thin client hardware will be cheaper and last longer-- another sure foothold that will bring them into the mobile market. And best of all, if one is lost, it will only cost pennies to replace the device since the data does not reside within it. Provisioning will be faster than disk-imaging techniques, and the massive back-end systems can be heavily virtualized with tools like VMWare.
Dan Geer recently said that as Moore's Law for computing power doubles every 18 months, disk space doubles every 12 and bandwidth doubles every 9 months. In our "data in motion" world, the best way for organizations to really protect data is to only "present" it to thin client endpoints. RIM has been wildly successful with introducing us to this concept via its Blackberry product line, it will only be a matter of time before some other company changes the way we think about thin clients as a mobile computing solution.
Before I am blasted by those whose religion is the PC based (decentralized) world, let me be the first to say this will not solve the problem for everybody-- just 99.9% of those cases where laptops are stolen or lost. Thin computing will not necessarily help the end-user market, but it will assist fixing their problems as well.
I'm convinced that the days are numbered on all of these signature-based anti-virus applications. It's what Marcus Ranum refers to as "Enumerating Badness". There is nearly infinitely more malicious code than trustworthy code. Why bother trying to discover them all?
And by definition, signature-based AV requires at least one customer organization getting infected before the signatures can be distributed to customers. How many customers will be dumped on before they wake up and realize that taking an inventory of all legitimate applications and technically enforcing a policy that allows only those to run is a much more effective approach at maintaining an infrastructure? Signature-based AV is the easy-chair of the Windows Admins.
If you really want to know what value AV vendors have added to the IT world it's that IT organizations have effectively "outsourced" the inventory functions of identifying good vs. bad software. Whether Microsoft wipes them off the face of the planet or not, it's really irrelevant: very soon organizations will inventory their legitimate code and implement a "Default Deny" policy where no code can execute except what is explicitly allowed, instead of vice versa. Why will they? Because the Finance guys will finally figure out how it works. Signature-based AV = Lazy Admins. Smart CFOs will drive the end of Symantec and McAfee (or the diversification of their product line).
Microsoft already has a tool that could (with tweaking and better deployment tools) one day put all the AV vendors out of business, if this new SDL delivers as expected (Vista will of course be the first OS under the new SDL) and the number of privileged-service exploits is reduced.
The real topic of interest here in this thread is that slashdot readers/critics like to knock Microsoft whether they they are susceptible to malware OR whether they are making efforts to eradicate it. Funny how the critics don't complain about how Symantec and McAfee have been bumped out of the Mac OSX AV business...
I'd like to see Snap Grades develop the other side of their educational information system experience. They've got the grades portion down in a web interface that is very google/gmail-esque. Now, if they can just create the classroom portion fully integrated...
Just tell Taiwan that the images are three years old and nobody was as certain as to their sovereignty then. That will buy Google a few years time to come up with a good answer!
Let's just say that such a tool compares kernel modules and key system files to a list of approved modules' checksums. A rootkit could easily modify the list with its own checksum, so if this was a totally automated process, it wouldn't work.
The other options include having the user sign/validate the checksum list, but that will increase the complexity of the process to the point that most OSes/distributions will not include such a tool. If the signature is performed by a key that is managed by the OS directly, once again, the root kit could automate this process as well.
On another note, the Windows Security model allows for different rights levels: guest, user, power user, admin, AND System. Administrators can elevate to system (there are tools with the appropriate API calls for this... try psexec from SysInternals). And system is the rights context that is required for access to things like SAM password stores in the registry, etc. Administrators cannot just "navigate" or "browse" to these critical points with the standard toolsets.
I like the idea of using hardware to force read-only critical sections for high security systems, and for items like what F-Secure can offer for normal-security systems.
Electronic voting has been rolled out nationwide without necessary safeguards.
Well, yeah, that is not new...
Quick recap: The goal of the paper validation is not because we want to cut down more trees. In fact, the goal of the electronic voting is for quick tallies and immediate results. Paper tallies are for "trueing" them up in the case of a recount.
The real question is: What will people do with the paper copies once they have them printed out and they believe their vote did not count properly? Are they going to go back into the voting depot and say "Look up my vote, I think you counted it for the other guy!"?
Not likely. The problem is, elections can be stolen whether they are electronic or not. The electioneer's must be trusted. And as long as we want to keep the voter's identity unassociated with the corresponding vote (anonymity), there will be a problem.
Paper trails may help, but who's going to be auditing them, especially if the voters will keep the only copy?
I guess I am glad it's not my decision to make and live with.
Slashdot Mirror
I got my family to watch the ABC special on TV tonight. What an amazing and inspirational story!
My wife and I agree that they should make a Hollywood rendition of his life story and that Jim Carrey (from his more dramatic roles like The Truman Show) should play the part of Prof Pausch. There's an amazing resemblance in both their appearance and facial expressions as well as their desire to have fun.
Prof. Pausch, your memory will live on after you. Thanks for taking the time to share your thoughts. Excellent "head fakes".
Well, because they're not driving the cars on the road at all when they test for fuel economy. How can any of the numbers be accurate in such an unrealistic testing environment?
I am a security analyst by profession and education [not that it matters, but as a distinction of the previous poster's non-security background].
... there are vast categories of vulnerabilities that end up compiled in code unnecessarily. And a great place to start for anyone looking to weed these unforgiveable buffer overrun types of issues out of their code is to use a static analyzer on their code. Essentially, static analysis tools attempt to catch these obvious (or sometimes not so obvious) bugs before the code is shipped to customers. Fortify Software is a great place to look for such a tool.
You are somewhat correct. Sloppy coding techniques do lead to security vulnerabilities which lead to exploit code which eventually lead to websites burning, etc. However, that is only one category of security flaws. If you look at, say the GDI flaws Microsoft had last year (for example), you'll notice that vulnerability is actually a design flaw-- allowing executable code to live embedded in file objects was the problem [the embedded code's trustworthiness had no mechanism to be measured and therefore any user double-clicking on a malicious code-within-an-image file would have their system compromised]. Design flaws are much more tricky to prevent and most experts attempting to solve this problem suggest that development houses should leave the design aspects of their code to people with a background in security principles, or at least have some sort of design-time security review. This is mostly what formalized threat modeling attempts to do.
But you are right
Wrong. Responsible Disclosure is an attempt to curb the greater than linear complexity associated with testing patches.
If a bug is found in product X, then all applications that reside upon product X need to be validated as functional. In an enterprise, that could include applications plus interfaces that are unique to that organization. Most studies on code complexity find that complexity increases at a greater than linear clip. Responsible Disclosure is the opportunity to level the playing field between the "good guys" and the "bad guys" (deliberately avoiding hat color references).
Anyone who claims Full Disclosure is the best for his company is:
A) Not a sysadmin at all
B) A lazy sysadmin who refuses to fully test patches
-OR-
C) A vulnerability pimp (e.g. IDS, AV, Vuln Assessment, etc.)
The problem with your analogy is that "bounty hunters" in the infosec debate would actually be searching for the exploiters, not the exploits.
Wrong. Encryption is only as good as the key. Or in practical cases, only as good as the password that protects the key. And in all likelihood (like most enterprises) they key is probably managed in such a way that dozens of people could have accessed it, especially if it was shared "enterprise" data.
Security people turn to crypto as the answer to everything. It isn't. Even cryptographer Bruce Schneier lamented that mistake in the opening of his book Secrets and Lies. Cryptography should always be a last resort. Encrypted data is not protected forever. At a maximum, the lifespan of its protection is limited by Moore's Law. At a minimum, the key management.
This data should not have resided upon drives that were removable without notice. Period. Forget about crypto.
I have said this before, and I'll say this again: we (the IT industry) created a problem with mobile computing. We allow data to be stored on mobile devices in a distributed computing environment and then years later (after we realize the problem we created), we freak out and throw magic crypto fairy dust at the problem. Encrypted hard drives are only as good as they keys that protect them. Since enterprises need the flexibility of a large support staff, many people will have access to the keys. And since the products are designed to run so that even computer illiterate users will use the software, a shoulder-surfer can backdoor the whole process. The best way to protect this data
I think you're missing the point.
... The point is, that when the "threat du jour" arrives at your doorstep, do you:
What Bruce is saying is that security dollars are being spent on band-aids and duct tape. Those same dollars at the root of the problem are more efficient for everyone.
Assume we can solve the malware problem (which I think we can, it's just a matter of applying default-deny logic that we learned from our early firewall days to our software inventory). So what if there's a new approach created (because, after all, security is a human vs. human problem, not a human vs. machine problem-- you're right on that point). The point is, rather than buying some aftermarket doo-dad for resolving new security problem X, we can simply go back to the original system's design and say "how can I re-engineer this, considering new threat X?".
We (the general IT industry) built and deployed firewalls because we had too many systems in our machine rooms that we didn't understand. It was an attempt to simplify things. Yes, firewalls can serve a purpose, but if we just re-engineered the next generation of systems in our machine rooms, we wouldn't need firewalls.
We built IPSes because we realized that firewalls don't really solve the problem of fixing the bugs in the listening services. Poking a tcp port 80 hole in a firewall still leaves you talking to your http server and whatever applications are running within it. Since we suddenly realized that we don't understand what our application does when you pass it random input (such as 42 "/../" strings), we decided we needed yet-another-band-aid. Instead, if just spent that money making sure the range of allowed input to our http apps was well defined and that the http service and applications were concise enough to handle the predetermined input (resulting in a well-handled error if any other input arrived to the buffer), we wouldn't need IPS.
The list could go on and on and on
A) Go to the nearest snake-oil salesman and ask him for his anti-threat-du-jour ointment?
-OR-
B) Ask the guy who built your doorstep to re-engineer the doorstep to withstand threat-du-jour in addition to all of the other threats.
Security is all about "Decision Support for Spend" (to quote Dan Geer without a proper reference). Is it more economical to manage your risks with yet-another-component in your environment or to simplify the components you already have to withstand some previously unforeseen threats? Schneier says the latter. [And for that matter, many security people have been saying this for years. This isn't earth shattering.]
Regardless of the student's ethics (or lack thereof), this illustrates a fallacy of trust in computing that often goes overlooked, especially in software security products: transitive (implicit) trust.
... If the administrator (of the University, some enterprise, or even a home network) cannot state anything about the trustworthiness of an unfamiliar computer, how can that same administrator trust the output of some software program designed to assert the trustworthiness of an otherwise untrusted computer?
Think about it logically for a second
Trusted input (e.g. Cisco Clean Access)
+ Untrusted computation (unknown host)
!= Trusted output (i.e. an assertion from the CCA that the computer is trustworthy)
The nature of this equation is that the untrusted computer is implicitly trusted to compute its own trustworthiness. What ramifications does that have on the real world analogies?
Banker: Can I trust that you'll repay this loan for $1 Billion?
Some joe off the street: [Hides "will work for food" cardboard sign behind his back.] Uh, sure.
And yet, how many NAC/NAP vendors actually try to challenge the unknown host (java applet, activeX control, native code, etc.)? Answer is: nearly all of them, unfortunately. Even if Cisco fixes this hole, what will happen next? This is not unlike Cisco trying to sell a perpetual motion machine-- this simply defies the "natural laws" of security.
--
NAC is not the answer. How about those good ol' 3270 connections?
And I guess this T-shirt wraps it all up.
Dang. I guess that means I'm preaching abstinence.
... Default Deny.
... economics. Anti-[threat du jour] vendors work on subscriptions because they can check for subscriptions before issuing malware signatures (it's the whole incentive concept we see all over again). But, there is no incentive for the customer to check in with the vendor if their tool is just installed and doesn't need re-configuring until the next time a new application is installed (presumably to update the inventory).
... and at that point it would no longer be a problem (as in a "social problem")).
...
We have seen it in firewalls. We have seen it in military-grade physical security. We have seen it in banking. But, why, oh why, do we not see it with malware?
[Analogy warning] About the best analogy I can come up with that describes just exactly how modern anti-[virus, spyware, threat du jour, or just plain "malware"] is this: Enterprises and home users are outsourcing the task of determining the trustworthiness of software applications that reside on their computers. However, they are forcing the outsourcers (the AV companies) to work both backwards and blind. "Blind" in that the outsourcers are not allowed access to see what applications are actually running within the trusted computing environments (or how well those applications play with others (do they run with scissors?)) and "Backwards" in that the outsourcers are not allowed to simply identify trustworthy software applications-- they're forced to identify the good by ruling out everything that is bad. And we all know that "good" and "bad" are in the eyes of the (ahem) beclicker. [End analogy]
What we need instead is a serious set of solutions (and some are starting to crop up, but I won't cite any because I cannot vouch for their quality) that work in the POSITIVE direction, and not the NEGATIVE direction. In other words, we need anti-malware that simply inventories known good applications, comparing all code execution requests against the guest list before letting them get CPU resident. Assuming that code injection techniques (e.g. buffer overruns) can be quelled by other means (microkernels, randomized memory addressing, read only data memory, etc.), then the likelihood of malware infection with a Default-Deny approach (deny all applications except those on the guest-list/inventory) would dramatically approach zero.
The real problem is
And, like many other comments here have already noted, privilege escalation cannot be overlooked. Supposing a default-deny-anti-malware approach exists (and is worth using), if I operate the computer at the same privilege level of the tool itself [regardless of OS], it is possible for malware to disable the controls. And for the clever readers out there, yes, a set of default deny application inventory controls does seem similar to file system level controls--only execution controls further extend the FS permissions to cover the missing gap.
Who cares about behavioral analysis? What behavior I dislike another will certainly like! Who cares about reputational analysis? What you trust, I may not! But, if we all just stop assuming that we can never speak intelligently about the inventory of "good" applications, then we might finally arrive at a solution that ends malware once and for all (well 99.999% anyway, we'd still have to worry about insider-threat
I guess I went over my two words. Apologies
That makes a good laugh, but in all seriousness, we will likely read headlines like this in the next 5 years or so:
Financial fraud linked to stolen encrypted laptop
In the largest online fraud incident in history, experts linked the Personally Identifiable Information (PII) used in committing the fraudulent acts back to a laptop that was stolen over a year ago. Company X denies the experts' allegations saying "the laptop's hard drive was encrypted." Under this premise, Company X refrained from notifying affected consumers as directed by [insert State Law] because Company X believes disclosed encrypted PII is not the same thing as dislosed unencrypted PII. In a press release yesterday, CEO John Smith said: "We were not obligated to notify consumers of the stolen laptop incident because the sensitive information contained within it was not disclosed. We use state-of-the-art hard drive encryption on all of our laptops, therefore it is impossible that this fraud was related to the stolen laptop." Law Enforcement announced today that they have apprehended the suspect who stole the laptop in question and that the suspect has admitted to stealing the laptop's encryption password as well. Details are expected to follow after the crime ring is completely in custody.
The Top 10 Most Secure Hard Drives in Existence to date:
1. The world's most secure hard drive is the one not used to contain valuable confidential data (experts question its existence).
2. Doesn't exist.
3. Doesn't exist.
4. A hard drive that contains some valuable confidential data, but remains physically within a datacenter. The OS that accesses it does not share its data with other OSes, and runs the full gamut of controls (prevention, detection, correction).
5. Doesn't exist.
6. Doesn't exist.
7. Doesn't exist.
8. Doesn't exist.
9. A hard drive that contains some valuable confidential data, remains physically within a datacenter, but its OS shares data among other systems whose trust is "unknown" or "uncertain".
And tied for 10th place (by virtue of consolation):
10. An encrypted drive in a mobile device relying upon its user for security.
10. An unencrypted drive in a mobile device relying upon its user for security.
If the "laws of physics" of information security were known, we'd likely see a Newtonian-esque law that says something like (in a more scientific form): "any security system that relies upon a person to use the system correctly will fail [miserably]". What Seagate is trying to do is analogous to defying gravity or creating "information security perpetual motion". It just won't improve the situation for anyone (except perhaps the "checklist security" people who can tell their compliance regulation auditors that they can add a point to their useless overall score).
If you really want to see the problem of data exposure reduced to a very tolerable level, the best solution is NOT to fully encrypt the drives of mobile computers, but to change our mobile computing paradigm entirely. Once viable alternatives to general purpose mobile computing are commercially available, we as an industry will finally be able to reduce the events. In other words, once thin-client mobile computing takes off, these full disk encryption products will likely not be needed at all.
Imagine a world where executives, sales people, and most other road-warrior types have a mobile computer that looks like a laptop, but instead of running its own full-blown OS, it simply rides the vast array of mobile carrier networks (like Blackberries currently do) to deliver a virtual desktop hosted in a nice segmented/protected internal network in their employers' data centers (e.g. Citrix, Terminal Servers, or X Windows). Instead of the critical, highly-valuable information floating all over the network and beyond in general purpose computers, we will see a return to the centralized computing paradigm reminiscent of the mainframe days, but with all of the flexibility of the point-and-click user interfaces. Users will interact with their desktops over nice TLS/SSL/IPSEC tunnels over a variety of wireless carrier and 802.11 networks. As long as there's bandwidth, there will be productivity. The thin client hardware will be cheaper and last longer-- another sure foothold that will bring them into the mobile market. And best of all, if one is lost, it will only cost pennies to replace the device since the data does not reside within it. Provisioning will be faster than disk-imaging techniques, and the massive back-end systems can be heavily virtualized with tools like VMWare.
Dan Geer recently said that as Moore's Law for computing power doubles every 18 months, disk space doubles every 12 and bandwidth doubles every 9 months. In our "data in motion" world, the best way for organizations to really protect data is to only "present" it to thin client endpoints. RIM has been wildly successful with introducing us to this concept via its Blackberry product line, it will only be a matter of time before some other company changes the way we think about thin clients as a mobile computing solution.
Before I am blasted by those whose religion is the PC based (decentralized) world, let me be the first to say this will not solve the problem for everybody-- just 99.9% of those cases where laptops are stolen or lost. Thin computing will not necessarily help the end-user market, but it will assist fixing their problems as well.
-Tim
I'm convinced that the days are numbered on all of these signature-based anti-virus applications. It's what Marcus Ranum refers to as "Enumerating Badness". There is nearly infinitely more malicious code than trustworthy code. Why bother trying to discover them all?
...
And by definition, signature-based AV requires at least one customer organization getting infected before the signatures can be distributed to customers. How many customers will be dumped on before they wake up and realize that taking an inventory of all legitimate applications and technically enforcing a policy that allows only those to run is a much more effective approach at maintaining an infrastructure? Signature-based AV is the easy-chair of the Windows Admins.
If you really want to know what value AV vendors have added to the IT world it's that IT organizations have effectively "outsourced" the inventory functions of identifying good vs. bad software. Whether Microsoft wipes them off the face of the planet or not, it's really irrelevant: very soon organizations will inventory their legitimate code and implement a "Default Deny" policy where no code can execute except what is explicitly allowed, instead of vice versa. Why will they? Because the Finance guys will finally figure out how it works. Signature-based AV = Lazy Admins. Smart CFOs will drive the end of Symantec and McAfee (or the diversification of their product line).
Microsoft already has a tool that could (with tweaking and better deployment tools) one day put all the AV vendors out of business, if this new SDL delivers as expected (Vista will of course be the first OS under the new SDL) and the number of privileged-service exploits is reduced.
The real topic of interest here in this thread is that slashdot readers/critics like to knock Microsoft whether they they are susceptible to malware OR whether they are making efforts to eradicate it. Funny how the critics don't complain about how Symantec and McAfee have been bumped out of the Mac OSX AV business
-Tim
Principle of Least Privilege Whitepaper - MalcomVetter
I think MS has come a long way from where they were, but I agree. To the people who claim it can't be done: OpenBSD does it!
I'd like to see Snap Grades develop the other side of their educational information system experience. They've got the grades portion down in a web interface that is very google/gmail-esque. Now, if they can just create the classroom portion fully integrated
Just tell Taiwan that the images are three years old and nobody was as certain as to their sovereignty then. That will buy Google a few years time to come up with a good answer!
Don't you mean ... Googleverse?
Here's your problem with that.
Let's just say that such a tool compares kernel modules and key system files to a list of approved modules' checksums. A rootkit could easily modify the list with its own checksum, so if this was a totally automated process, it wouldn't work.
The other options include having the user sign/validate the checksum list, but that will increase the complexity of the process to the point that most OSes/distributions will not include such a tool. If the signature is performed by a key that is managed by the OS directly, once again, the root kit could automate this process as well.
On another note, the Windows Security model allows for different rights levels: guest, user, power user, admin, AND System. Administrators can elevate to system (there are tools with the appropriate API calls for this
I like the idea of using hardware to force read-only critical sections for high security systems, and for items like what F-Secure can offer for normal-security systems.
You're not going to want to hear this, but anyway
You could have *_avoided_* all of that if you just ran your box as a user, and elevated to admin when needed.
Mor info on the non-admin experience
In case you were interested: BUGMENOT FF Extension
Electronic voting has been rolled out nationwide without necessary safeguards.
Well, yeah, that is not new
Quick recap: The goal of the paper validation is not because we want to cut down more trees. In fact, the goal of the electronic voting is for quick tallies and immediate results. Paper tallies are for "trueing" them up in the case of a recount.
The real question is: What will people do with the paper copies once they have them printed out and they believe their vote did not count properly? Are they going to go back into the voting depot and say "Look up my vote, I think you counted it for the other guy!"?
Not likely. The problem is, elections can be stolen whether they are electronic or not. The electioneer's must be trusted. And as long as we want to keep the voter's identity unassociated with the corresponding vote (anonymity), there will be a problem.
Paper trails may help, but who's going to be auditing them, especially if the voters will keep the only copy?
I guess I am glad it's not my decision to make and live with.
Well, or at least we will have to wait for time to tell. Make's stock buying decisions more difficult, eh?
I'm surprised we have not seen this before.