So you have all the patches from Microsoft applied automatically, Firefox updates itself as well as its extensions... But do you still have vulnerable, outdated software? Last weekend I decided to try the Secunia Personal Software Inspector, which is free for personal use, on my home gaming computer. The Secunia PSI helps find software that falls through the cracks of the auto-update capabilities. I was pleasantly surprised. It has a polished normal interface as well as an informative advanced interface. It ran quickly and found obsolete versions of Adobe Flash installed concurrently with newer ones, and pointed out that Firefox wasn't quite up-to-date as the latest patch hadn't been applied.

When I made the Cassandra system years ago, I was also dreaming of something like this. It is limited to finding vulnerable software by version, not configuration, and giving links to fixes; so it doesn't help hardening a system to the point that some computer security benchmarks can. However, those security benchmarks can decrease the convenience of using a computer, so they require judgment. It can also be time consuming and moderately complex to figure out what you need to do to improve the benchmark results. By contrast, the SPI is so easy to install and use that it should be considered by anyone capable of installing software updates, or anyone managing a family member's computer. The advanced interface also pointed out that there were still issues with Internet Explorer and with Firefox for which no fixes were available. I may use Opera instead until these issues get fixed. It is unfortunate that it runs only on Windows, though.

The Secunia Personal Software Inspector is not endorsed by Purdue University CERIAS; the above are my personal opinions. I do not own any shares or interests in Secunia.
Edit: fixed the link, thanks Brett!

On March 19, I had an opportunity to testify before the Senate Committee on on Commerce, Science, and Transportation. The hearing was entitled Cybersecurity -- Assessing Our Vulnerabilities and Developing An Effective Defense.

I was asked to include information on research problems, educational initiatives, and issues regarding the current state of cyber security in the nation.   As is usual for such things, the time between the invitation and the due date for written testimony was short. Thus, I didn't have the time to delve deeply into the topic areas, but could only address the things that I already had on hand -- including some posts from this blog that I had written before. The result was a little longer than the other statements, but I think I covered more ground.

One hint for people testifying before Congress on such things: you can't depend on how long you will have for spoken remarks, so be sure any points you want to make are in your written testimony. In this case, the hearing was limited to about 75 minutes because there were several votes scheduled on the Senate floor, and the committee needed to adjourn to allow the Senators to attend the votes. And, as is common for too many hearings, there weren't many of the committee members present; I believe the hearing began with only two of the 25 members present, and some movement of members in and out to reach a maximum of four seated at any one time. In this case, the chair (Senator Jay Rockefeller of West Virginia) apologized to us several times for the low turnout. However, many (all?) of the staff and aides were present, so I'm certain the gist of the testimony presented will be considered.

The Senator made a nice introductory statement.

My written testimony is available on my website as well as the committee site. My oral statement was from rough notes that I modified on the fly as I listened to the other testimony (by Jim Lewis, Eric Weiss and Ed Amoroso). That statement, and the whole hearing, are available via the archived hearing webcast (my remarks start at about 46:30 into the webcast). If I get a transcribed version of those remarks, I will post them along with my written testimony on my website in the "US government" section.

Comments by the other speakers were good overall and I think we collectively covered a lot of ground. The questions from the Senators present indicated that they were listening and knew some of the problems in the area. The comments from Senator Nelson about the intrusions into his systems were surprising: several Senate security staff were present at the hearing and indicated to me that his remarks were the first they had heard of the incidents! So, the hearing apparently set off an incident-response exercise -- separate from responding to my presence in the building, that is.

Will this hearing make a difference? I don't know. I've been testifying and saying the same things for over a dozen years (this was my 8th Congressional hearing testimony) and things haven't gotten that much better...and may even be worse. Senator Rockefeller has indicated he intends to introduce legislation supporting more funding for students studying cyber security issues. There was some good news coverage of all this (e.g., FCW and CNet).

I am told that there will be more hearings by this committee. Some House committees have been holding hearings too, and the President's 60 day review continues apace. The added attention is great, but with the sudden interest by so many, the result may be more confusion rather than resolution.

Stay tuned.

---

As a reminder, if you want to know about my occasional postings such as this but don't want to subscribe to the RSS feed,  you can subscribe to the mailing list.

Also as a reminder, there is my tumble blog on security issues, with links to items on the news and WWW of possible interest to those who find my ramblings and rants of interest.

Short answer: " Almost certainly, no."  

Longer answer:

The blogosphere is abuzz with comments on John Markoff's Saturday NT Times piece, Do We Need a New Internet? John got some comments from me about the topic a few weeks back. Unfortunately, I don't think a new Internet will solve the problems we are facing.

David Akin, a journalist/blogger commented on nicely John's post. In it, he quoted one of my posts to Dave Farber's IP list, which I then turned into a longer post in this blog. Basically, I noted that the Internet itself is not the biggest problem. Rather, it is the endpoints, the policies, the economics, and the legal environment that make things so difficult. It is akin to trying to blame the postal service because people manage to break into our houses by slipping their arms through the mailslots or because we leave the door unlocked "just in case" a package is going to be delivered.

Consider that some estimates of losses as a result of computer crime and fraud are in the many billions of $$ per year. (Note my recent post on a part of this.) Consider how much money is repeatedly spent on reissuing credit and debit cards because of loss of card info, restoring systems from backups, trying to remove spyware, bots, viruses, and the like. Consider how much is spent on defensive mechanisms than only work in limited cases -- anti-virus, IDS, firewalls, DLP, and whatever the latest fad might be.

What effect does that play on global finances? It is certainly a major drag on the economy. This was one of the conclusions (albeit, described as "friction") of the CSTB report Towards a Safer and More Secure Cyberspace, which did not seem to get much attention upon release.

Now, think about the solutions being put forward, such as putting all your corporate assets and sensitive records "out in the cloud" somewhere, on servers that are likely less well-protected or isolated than the ones being regularly compromised at the banks and card processors. But it will look cheaper because organizations won't need to maintain resources in-house. And it is already being hyped by companies, and seemingly being promoted by the NSF and CCC as "the future." Who can resist the future?

Next, stir in the economic conditions where any talk is going to be dismissed immediately as "crazy" if it involves replacing infrastructure with something that (initially) costs more, or that needs more than a minor change of business processes. And let's not forget that when the economy goes bad, more criminal behavior is likely as people seek value wherever they can find it.

The institutional responses from government and big vendors will be more of the same: update the patches, and apply another layer of gauze.

I have long argued that we should carefully re-examine some of the assumptions underlying what we do rather than blindly continue doing the same things. People are failing to understand that many important things have changed since we first started building computing artifacts! That means we might have better solutions if we really thought about the underlying problems from first principles.

I recently suggested this rethinking of basic assumptions to a few senior leaders in computing research (who shall remain nameless, at least within this posting) and was derided for not thinking about "new frontiers" for research. There is a belief among some in the research community (especially at the top universities) that the only way we (as a community; or perhaps more pointedly, them and their students) will get more funding for research and that we (again, the royal "we") will get premier publications is by pushing "new" ideas. This is partly a fault of the government agencies and companies, which aren't willing to support revisiting basic ideas and concepts because they want fixes to their existing systems now!

One part that makes sense from Markoff's article is about the research team making something that is effectively "plug compatible" with existing systems. That is roughly where a longer-term solution lies. If we can go back and devise more secure systems and protocols, we don't need to deploy them everywhere at once: we gradually phase them in, exactly as we do periodic refreshes of current systems. There is not necessarily an impassible divide between what we need and what we can afford.

I'm sorry to say that I don't see necessary changes occurring any time soon. It would upset too much of the status quo for too many parties. Thus, the situation isn't going to get better -- it's going to get worse -- probably much worse. When we finally get around to addressing the problems, it will be more expensive and traumatic than it needed to be.

As I noted before:

"Insanity: doing the same thing over and over again expecting different results."

Of course, my continued efforts to make this point could be branded insane.

---

An Aside

Over a decade ago, I gave several talks where I included the idea of having multiple "service network" layers on top of the Internet -- effectively VPNs. One such network would be governed by rules similar to those of the current Internet. A second would use cryptographic means to ensure that every packet was identified. This would be used for commercial transactions. Other such virtual networks would have different ground rules on authentication, anonymity, protocols and content. There would be contractual obligations to be followed to participate, and authorities could revoke keys and access for cause. Gateways would regulate which "networks" organizations could use. The end result would be a set of virtual networks on the Internet at large, similar to channels on a cable service. Some would be free-for-all and allow anonymous posting, but others would be much more regulated, because that is what is needed for some financial and government transactions.

I remember one audience at an early SANS conference at the time was so hostile to the idea that members began shouting objections before I could even finish my talk. I also couldn't find a venue willing to publish a speculative essay on the topic (although I admit I only tried 2-3 places before giving up). The general response was that it would somehow cut out the possibility for anonymous and experimental behavior because no one would want to use the unauthenticated channels. It was reminiscent of the controversy when I was the lead in the Usenet "Great Renamng."   

The problem, of course, is that if we try to support conflicting goals such as absolute anonymity and strong authentication on the same network we will fail at one or the other (or both). We can easily find situations where one or the other property (as simply two examples of properties at stake) is needed. So long as we continue to try to apply patches onto such a situation before reconsidering the basic assumptions, we will continue to have unhappy failures.

But as a bottom line, I simply want to note that there is more than one way to "redesign the Internet" but the biggest problems continue to be the users and their expectations, not the Internet itself.

Yesterday, I posted a long entry on the recent news about how some researchers obtained a “rogue” certificate from one of the Internet Certificate Authorities. There are some points I missed in the original post that should be noted.

 
• The authors of the exploit have a very readable, interesting description of what they did and why it worked. I should have included a link to it in the original posting, but forgot to edit it in. The interested reader should definitely see that article online, include the animations.
 
• There are other ways this attack can be defeated, certainly, but they are stop-gap measures. I didn’t explain them because I don’t view them as other than quick patches. However, if you are forced to continue to use MD5 and you issue certificates, then it is important to randomize the certificate serial number that is issued, and to insert a random delay interval in the validity time field. Both will introduce enough random bits so as to make this particular attack against the CA infeasible given current technology.
 
• I suggested that vendors use another hash algorithm, and have SHA-1 as an example. SHA-2 would be better, as SHA-1 has been shown to have a theoretical weakness similar to MD5, although it has proven more resistant to attack to date. Use of SHA-1 could possible result in a similar problem within a few years (or, as suggested in the final part of my post, within a few weeks if a breakthrough occurs). However, use of SHA-1 would be preferable to MD5!
 
• MD5 is not “broken” in a complete way. There are several properties of a message digest that are valuable, including collision resistance: that it is infeasible to end up with two inputs giving the same hash value. To the best of my knowledge, MD5 has only been shown to be susceptible to “weak collisions”—instances where the attacker can pick one or both inputs so as to produce identical hash values. The stronger form of preimage resistance, where there is an arbitrary hash output H and an attacker cannot form an input that also produces H, still holds for MD5. Thus, applications that depend on this property (including many signing applications and integrity tools) are apparently still okay.
 
• One of our recent PhD grads, William Speirs, worked on defining hash functions for his PhD dissertation. His dissertation, Dynamic Cryptographic Hash Functions, is available online for those interested in seeing it.

I want to reiterate that there are more fundamental issues of trust involved than what hash function is used. The whole nature of certificates is based around how much we trust the certificate authorities that issue the certificates, and the correctness of the software that verifies those certificates then shows us the results. If an authority is careless or rogue, then the certificates may be technically valid but not match our expectations for validity. If our local software (such as a WWW browser) incorrectly validates a certificate, or presents the results incorrectly, we may trust a certificate we shouldn’t. Even such mundane issues as having one’s system at the correct time/date can be important: the authors of this particular hack demonstrated that by backdating their rogue certificate.

My continuing message to the community is to not lose sight of those things we assume. Sometimes, changes in the world around us render those assumptions invalid, and everything built on them becomes open to question. If we forget those assumptions—and our chains of trust built on them—we will continue to be surprised by the outcomes.

That is perhaps fitting to state (again) on the last day of the year. Let me observe that as human beings we sometimes take things for granted in our lives. Spend a few moments today (and frequently, thereafter) to pause and think about the things in your life that you may be taking for granted: family, friends, love, health, and the wonder of the world around you. Then as is your wont, celebrate what you have.

Best wishes for a happy, prosperous, safe—and secure—2009.

---

[12/31/08 Addition]: Steve Bellovin has noted that transition to the SHA-2 hash algorithm in certificates (and other uses) would not be simple or quick. He has written a paper describing the difficulties and that paper is online.

 

There are several news stories now appearing (e.g., Security News) about a serious flaw in how certificates used in online authentication are validated. Ed Felten gives a nice summary of how this affects online WWW site authentication in his Freedom to Tinker blog posting. Brian Krebs also has his usual readable coverage of the problem in his Washington Post article. Steve Bellovin has some interesting commentary, too, about the legal climate.

Is there cause to be concerned? Yes, but not necessarily about what is being covered in the media. There are other lessons to be learned from this.

Short tutorial

First, for the non-geek reader, I’ll briefly explain certificates.

Think about how, online, I can assure myself that the party at the other end of a link is really who they claim to be. What proof can they offer, considering that I don’t have a direct link? Remember that an attacker can send any bits down the wire to me and may access to faster computers than I do.

I can’t base my decision on how the WWW pages appear, or embedded images. Phishing, for instance, succeeds because the phishers set up sites with names and graphics that look like the real banks and merchants, and users trust the visual appearance. This is a standard difficulty for people—understanding the difference between identity (claiming who I am) and authentication (proving who I am).

In the physical world, we do this by using identity tokens that are issued by trusted third parties. Drivers licenses and passports are two of the most common examples. To get one, we need to produce sufficient proof of identity to a third party to meet its standards of proof. Then, the third party issues a document that is very difficult to forge (almost nothing constructed is impossible to forge or duplicate—but some things require so much time and expenditure it isn’t worthwhile). Because the criteria for proof of identity and strength of construction of the document are known, various other parties will accept the document as “proof” of identity. Of course, other problems occur that I’m not going to address—this USACM whitepaper (of which I was principal author) touches on many of them.

Now, in the online world we cannot issue or see physical documents. Instead, we use certificates. We do this by putting together an electronic document that gives the information we want some entity to certify as true about us. The format of this certificate is generally fixed by standards, the most common one being the X.509 suite. This document is sent to an organization known as a Certificate Authority (CA), usually along with a fee. The certificate authority is presumably well-known, and performs a check (to their own standards) that the information in the document is correct, and it has the right form. The CA then calculate a digital hash value of the data, and creates a digital signature of that hash value. This is then added to the certificate and sent back to the user. This is the equivalent of putting a signature on a license and then sealing it in plastic. Any alteration of the data will change the digital hash, and a third party will find that the new hash and the hash value signed with the key of the CA don’t match. The reason this works is that the hash function and encryption algorithm used are presumed to be so computationally difficult to forge that it is basically not possible.

As an example of a certificate , if you visit “https://www.cerias.purdue.edu” you can click on the little padlock icon that appears somewhere in the browser window frame (this is browser dependent) to view details of the CERIAS SSL certificate.

You can get more details on all this by reading the referenced Wikipedia pages, and by reading chapters 5 & 7 in Web Security, Privacy and Commerce.

Back to the hack

In summary, some CAs have been negligent about updating their certificate signing mechanisms in the wake of news that MD5 is weak, published back in 2004. The result is that malicious parties can generate and obtain a certificate “authenticating” them as someone else. What makes it worse is that the root certificate of most of these CAs are “built in” to browser and application trust lists to simplify look-up of new certificates. Thus, most people using standard WWW browsers can be fooled into thinking they have connected to real, valid sites—even through they are connecting to rogue sites.

The approach is simple enough: a party constructs two certificates. One is for the false identity she wishes to claim, and the other is real. She crafts the contents of the certificate so that the MD5 hash of the two, in canonical format, is the same. She submits the real identity certificate to the authority, which verifies her bona fides, and returns the certificate with the MD5 hash signed with the CA private key. Our protagonist then copies that signature to the false certificate, which has the same MD5 hash value and thus the same digital signature, and proceeds with her impersonation!

What makes this worse is that the false key she crafts is for a secondary certificate authority. She can publish this in appropriate places, and is now able to mint as many false keys as she wishes—and they will all have signatures that verify in the chain of trust back to the issuer! She can even issue these new certificates using a stronger hash algorithm than MD5!

What makes this even worse is that it has been known for years that MD5 is weak, yet some CAs have continued to use it! Particularly unfortunate is the realization that Lenstra, Wang and de Weger described how this could be done back in 2005. Methinks that may be grounds for some negligence lawsuits if anyone gets really burned by this….

And adding to the complexity of all this is the issue of certificates in use for other purposes. For example, certificates are used with encrypted S/MIME email to digitally sign messages. Certificates are used to sign ActiveX controls for Microsoft software. Certificates are used to verify the information on many identity cards, including (I believe) government-issued Common Access Cards (CAC). Certificates also provide identification for secured instant messaging sessions (e.g., iChat). There may be many other sensitive uses because certificates are a “known” mechanism. Cloud computing services , software updates, and more may be based on these same assumptions. Some of these services may accept and/or use certificates issued by these deficient CAs.

Fixes

Fixing this is not trivial. Certainly, all CAs need to start issuing certificates based on other message digests, such as SHA-1. However, this will take time and effort, and may not take effect before this problem can be exploited by attackers. Responsible vendors will cease to issue certificates until they get this fixed, but that has an economic impact some many not wish to incur.

We can try to educate end-users about this, but the problem is so complicated with technical details, the average person won’t know how to actually make a determination about valid certificates. It might even cause more harm by leading people to distrust valid certificates by mistake!

It is not possible to simply say that all existing applications will no longer accept certificates rooted at those CAs, or will not accept certificates based on MD5: there are too many extant, valid certificates in place to do that. Eventually, those certificates will expire, and be replaced. That will eventually take care of the problem—perhaps within the space of the next 18 months or so (most certificates are issued for only a year at a time, in part for reasons such as this).

Vendors of applications, and especially WWW browsers, need to give careful thought about updates to their software to flag MD5-based certificates as deserving of special attention. This may or may not be a worthwhile approach, for the reason given above: even with a warning, too few people will be able to know what to do.

Bigger issue

We base a huge amount of trust on certificates and encryption. History has shown how easy it is to get implementations and details wrong. History has also shown how quickly things can be destabilized with advances in technology.

In particular, too many people and organizations take for granted the assumptions on which this vast certificate system is based. For instance, we assume that the hash/digest functions in use are computationally difficult to reverse or cause collisions. We also assume that certain mathematical functions underlying public/private key encryption are too difficult to reverse or “brute force.” However, all it takes is some new insight or analysis, or maybe new, affordable technology (e.g., practical quantum computing, or massively parallel computing) to violate those assumptions.

If you look at the way our systems are constructed, too little thought is given to what happens to existing infrastructure when something breaks. Designs can include compensating and recovery code, but doing so requires some cost in space or time. However, all too often people are willing to avoid the investment by putting off the danger to “if and when that happens.” Thus, we instance such as the Y2K problems and the issues here with potentially rogue CAs.

(I’ll note as an aside, that when I designed the original version of Tripwire and what became the Signacert product, I specifically included simultaneous use of several different message digest functions in different families for this very reason. I knew it was a matter of time before one or two were broken. I still believe that it is beyond reason to find files that will match multiple, different algorithms simultaneously.)

Another issue is the whole question of who we trust, and for what. As noted in the USACM whitepaper, authentication is always relative to a third party. How much do we trust those third parties? How much trust have we invested in the companies and agencies issuing certificates? Are they properly verifying identities? How good is there internal security? How do we know, and how much is at risk from our trust in those entities?

Let me leave you with a final thought. How do we know that this problem has not already been quietly exploited? The basic concept has been in the open literature for years. The general nature of this attack on certificates has been known for well over a decade, if not two. Given the technical and infrastructure resources available to national agencies and organized criminals, and given the motivation to use this hack selectively and quietly, how can we know that it is not already being used?

---

[Added 12/31/2008]: A follow-up post to this one is available in the blog.

 

I have repeatedly pointed out (e.g., this post) to people that sending Word files as attachments is a bad idea. This has been used many, many times to circulate viruses, worms, and more. People continue to push back because (basically) it is convenient for them. How often have we heard that convenience trumps good security (and good sense)?

Now comes this story of yet another attack being spread with Word documents.

There are multiple reasons why I don’t accept Word documents in email. This is simply one of the better reasons.

If you want to establish a sound security posture at your organization, one of the things you should mandate is no circulation of executable formats—either out or in. “.doc” files are in this category. I am unsure if the new “.docx” format is fully immune to these kinds of things but it seems “.rtf” is.

 

This was originally written for Dave Farber’s IP list.

I take some of the blame for helping to spread “no security through obscurity,” first with some talks on COPS (developed with Dan Farmer) in 1990, and then in the first edition of Practical Unix Security (with Simson Garfinkel) in 1991. None of us originated the term, but I know we helped popularize it with those items.

The origin of the phrase is arguably from one of Kerckhoff’s principles for strong cryptography: that there should be no need for the cryptographic algorithm to be secret, and it can be safely disclosed to your enemy. The point there is that the strength of a cryptographic mechanism that depends on the secrecy of the algorithm is poor; to use Schneier’s term, it is brittle: Once the algorithm is discovered, there is no (or minimal) protection left, and once broken it cannot be repaired. Worse, if an attacker manages to discover the algorithm without disclosing that discovery then she can exploit it over time before it can be fixed.

The mapping to OS vulnerabilities is somewhat analogous: if your security depends only (or primarily) on keeping a vulnerability secret, then that security is brittle—once the vulnerability is disclosed, the system becomes more vulnerable. And, analogously, if an attacker knows the vulnerability and hides that discovery, he can exploit it when desired.

However, the usual intent behind the current use of the phrase “security through obscurity” is not correct. One goal of securing a system is to increase the work factor for the opponent, with a secondary goal of increasing the likelihood of detecting when an attack is undertaken. By that definition, obscurity and secrecy do provide some security because they increase the work factor an opponent must expend to successfully attack your system. The obscurity may also help expose an attacker because it will require some probing to penetrate the obscurity, thus allowing some instrumentation and advanced warning.

In point of fact, most of our current systems have “security through obscurity” and it works! Every potential vulnerability in the codebase that has yet to be discovered by (or revealed to) someone who might exploit it is not yet a realized vulnerability. Thus, our security (protection, actually) is better because of that “obscurity”! In many (most?) cases, there is little or no danger to the general public until some yahoo publishes the vulnerability and an exploit far and wide.

Passwords are a form of secret (obscurity) that provide protection. Classifying or obfuscating a codebase can increase the work factor for an attacker, thus providing additional security. This is commonly used in military systems and commercial trade secrets, whereby details are kept hidden to limit access and increase workfactor for an attacker.

The problem occurs when a flaw is discovered and the owners/operators attempt to maintain (indefinitely) the sanctity of the system by stopping disclosure of the flaw. That is not generally going to work for long, especially in the face of determined foes. The owners/operators should realize that there is no (indefinite) security in keeping the flaw secret.

The solution is to design the system from the start so it is highly robust, with multiple levels of protection. That way, a discovered flaw can be tolerated even if it is disclosed, until it is fixed or otherwise protected. Few consumer systems are built this way.

Bottom line: “security through obscurity” actually works in many cases and is not, in itself, a bad thing. Security for the population at large is often damaged by the people who claim to be defending the systems by publishing the flaws and exploits trying to force fixes. But vendors and operators (and lawyers) should not depend on secrecy as primary protection.

 

[tags]interview,certification[/tags]I was recently interviewed by Gary McGraw for his Silver Bullet interview series.  He elicited my comments on a number of topics, including security testing, ethical hacking, and why security is difficult.If you like any of my blog postings, you might find the interview of some interest.  But if not, you might some of the other interviews of interest – mine was #18 in the series.

So, you watch for advisories, deploy countermeasures (e.g., change firewall and IDS rules) or shut down vulnerable services, patch applications, restore services.  You detect compromises, limit damages, assess the damage, repair, recover, and attempt to prevent them again.  Tomorrow you start again, and again, and again.  Is it worth it?  What difference does it make?  Who cares anymore? 

If you’re sick of it, you may just be getting fatigued.

If you don’t bother defending anymore because you think there’s no point to this endless threadmill, you may be suffering from learned helplessness.  Some people even consider that if you only passively wait for patches to be delivered and applied by software update mechanisms, you’re already in the “learned helplessness category”.  On the other hand, tracking every vulnerability in the software you use by reading BugTraq, Full Disclosure, etc…, the moment that they are announced, and running proof of concept code on your systems to test them isn’t for everyone;  there are diminishing returns, and one has to balance risk vs energy expenditure, especially when that energy could produce better returns.  Of course I believe that using Cassandra is an OK middle ground for many, but I’m biased.

The picture may certainly look bleak, with talk of “perpetual zero-days”.  However, there are things you can do (of course, as in all lists not every item applies to everyone):

• Don’t be a victim;  don’t surrender to helplessness.  If you have limited energy to spend on security (and who doesn’t have limits?), budget a little bit of time on a systematic and regular basis to stay informed and make progress on tasks you identify as important;  consider the ones listed below.
• Don’t be a target.  Like or hate Windows, running it on a desktop and connecting to the internet is like having big red circles on your forehead and back.  Alternatives I feel comfortable with for a laptop or desktop system are Ubuntu Linux and MacOS X (for now;  MacOS X may become a greater target in time).  If you’re stuck with Windows, consider upgrading to Vista if you haven’t already;  the security effort poured into Vista should pay off in the long run.  For servers, there is much more choice, and Windows isn’t such a dominant target. 
• Reduce your exposure (attack surface) by:
  • Browsing the web behind a NAT appliance when at home, in a small business, or whenever there’s no other firewall device to protect you.  Don’t rely only on a software firewall;  it can become disabled or get misconfigured by malware or bad software, or be too permissive by default (if you can’t or don’t know how to configure it).
  • Using the NoScript extension for Firefox (if you’re not using Firefox, consider switching, if only for that reason).  JavaScript is a vector of choice for desktop computer attacks (which is why I find the HoneyClient project so interesting, but I digress).  JavaScript can be used to violate your privacy* or take control of your browser away from you, and give it to website authors, advertisers on those sites, or to the people who compromised those sites, and you can bet it’s not always done for your benefit (even though JavaScript enables better things as well).  NoScript gives you a little control over browser plugins, and which sources are allowed to run scripts in your browser, and attempts to prevent XSS exploits.
  • Turning off unneeded features and services (OK, this is old advice, but it’s still good).

• Use the CIS benchmarks, and if evaluation tools are available for your platform, run them.  These tools give you a score, and even as silly as some people may think this score is (reducing the number of holes in a ship from 100 to 10 may still sink the ship!), it gives you positive feedback as you improve the security stance of your computers.  It’s encouraging, and may lift the feeling that you are sinking into helplessness.  If you are a Purdue employee, you have access to CIS Scoring Tools with specialized features (see this news release).  Ask if your organization also has access and if not consider asking for it (note that this is not necessary to use the benchmarks).

• Use the NIST security checklists (hardening guides and templates).  The NIST’s information technology laboratory site has many other interesting security papers to read as well.

• Consider using Thunderbird and the Enigmail plugin for GPG, which make handling signed or encrypted email almost painless.  Do turn on SSL or TLS-only options to connect to your server (both SMTP and either IMAP or POP) if it supports it.  If not, request these features from your provider.  Remember, learned helplessness is not making any requests or any attempts because you believe it’s not ever going to change anything.  If you can login to the server, you also have the option of SSH tunneling, but it’s more hassle.

• Watch CERIAS security seminars on subjects that interest you.

• If you’re a software developer or someone who needs to test software, consider using the ReAssure system as a test facility with configurable network environments and collections of VMware images (disclosure: ReAssure is my baby, with lots of help from other CERIAS people like Ed Cates).

Good luck!  Feel free to add more ideas as comments.

*A small rant about privacy, which tends to be another area of learned helplessness: Why do they need to know?  I tend to consider all information that people gather about me, that they don’t need to know for tasks I want them to do for me, a (perhaps very minor) violation of my privacy, even if it has no measurable effect on my life that I know about (that’s part of the problem—how do I know what effect it has on me?).  I like the “on a need to know basis” principle, because you don’t know which selected (and possibly out of context) or outdated information is going to be used against you later.  It’s one of the lessons of life that knowledge about you isn’t always used in legal ways, and even if it’s legal, not everything that’s legal is “Good” or ethical, and not all agents of good or legal causes are ethical and impartial or have integrity.  I find the “you’ve got nothing to hide, do you?” argument extremely stupid and irritating—and it’s not something that can be explained in a sentence or two to someone saying that to you.  I’m not against volunteering information for a good cause, though, and I have done so in the past, but it’s rude to just take it from me without asking and without any explanation, or to subvert my software and computer to do so. 

[tags]Windows, Office, malware, vulnerabilities[/tags]

This appeared in USA Today yesterday: Cyberspies exploit Microsoft Office.  This is yet more support for my earlier post.

So, are you ready to join the movement—stop sending Word documents in email?

Update 4/28: And here is yet another story of how Word files are being used against victims.

[posted with ecto]