Do you have a firewall? Maybe it's not as useful as you think it is. I was surprised to discover that IPv6 was enabled on several hosts with default firewall policies of ACCEPT and no rules. This allowed IPv6 traffic to completely bypass the numerous IPv4 rules!

IPv6 makes me queasy security-wise due to features such as making all IPv6 hosts into routers that obey source routing, as well as the excessively eager and accepting autoconfiguration. More recent doesn't imply more secure, especially if it's unmanaged because you don't realize it's ON. The issue is IPv6 being enabled by default in a fully open mode. Not everyone realizes this is happening, as we're very much still thinking in terms of IPv4. Even auditing tools such as Lynis (for Linux/UNIX systems) don't report this; it only checks if the IPv4 ruleset is empty. There are going to be a lot of security problems because of this. I know it's been so for some time, but awareness lags. I'm not the only one who thinks it's going to be a bumpy ride, as pointed out elsewhere.

You can mitigate this issue in several ways, besides learning how to secure IPv6 (which you'll have to do sometime) and using your plentiful spare time to do so enterprise-wide. Changing all the default IPv6 policies to DROP without adding any ACCEPT rules breaks things. For example, Java applications try IPv6 first by default and take several minutes to finally switch over to IPv4; this can be perceived as broken. If you have Ubuntu on your desktop, you can use ufw, the Uncomplicated FireWall, to configure your firewall with a click of the mouse. When "turned on", it changes the default policy to DROP but also adds rules accepting local traffic on the INPUT and OUTPUT chains (well done and thanks, Canonical and Gufw developers). This allows Java applications to contact local services, for example. You can also disable IPv6 in sysctl.conf (and have Java still work) if you have a recent kernel (e.g., Ubuntu 10):

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

followed by a reboot. You can also do this immediately, which will be good only until you reboot (note: sudo alone doesn't work, you need to do "sudo su -"):

echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6
echo 1 > /proc/sys/net/ipv6/conf/default/disable_ipv6
echo 1 > /proc/sys/net/ipv6/conf/lo/disable_ipv6

This removes the IPv6 addresses assigned to your network interfaces, and then Java ignores IPv6. If you have an "old" kernel (e.g., the most recent Debian) and need to support Java applications, the above kernel configurations are not available at this time. However, there are other ways to disable IPv6 for Debian, well documented elsewhere. You can also manually add firewall rules like those done by ufw, as described above.

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.

[A portion of this essay appeared in the October 2008 issue of Information Security magazine. My thanks to Dave Farber for a conversation that spurred me to post this expanded version.]

[Small typos corrected in April 2010.]

I’d like to repeat (portions of) a theme I have been speaking about for over a decade. I’ll start by taking a long view of computing.

Fifty years ago, IBM introduced the first all-transistor computer (the 7000 series). Transistors were approximately $60 apiece (in current dollars). Secondary storage was about 10 cents per byte (also in current dollars) and had a density of approximately 2000 bits per cubic inch. According to Wikipedia, a working IBM 7090 system with a full 32K of memory (the capacity of the machine) cost about $3,000,000 to purchase—over $21,000,000 in current dollars. Software, peripherals, and maintenance all cost more. Rental of a system (maintenance included) could be well over $500,000 per month (in 1958 dollars). Other vendors soon brought their own transistorized systems to market, at similar costs.

These early computing systems came without an operating system. However, the costs of having such a system sit idle between jobs (and during I/O) led the field to develop operating systems that supported sharing of hardware to maximize utilization. It also led to the development of user accounts for cost accounting. And all of these soon led to development of security features to ensure that the sharing didn’t go too far, and that accounting was not disabled or corrupted. As the hardware evolved and became more capable, the software also evolved and took on new features.

Costs and capabilities of computing hardware have changed by a factor of tens of millions in five decades. Currently, transistors cost less than 1/7800 of a cent apiece in modern CPU chips (Intel Itanium). Assuming I didn’t drop a decimal place, that is a drop in price by 7 orders of magnitude.  Ed Lazowska made a presentation a few years ago where he indicated that the number of grains of rice harvested worldwide in 2004 was ten quintillion—10 raised to the 18th power. But in 2004, there were also ten quintillion transistors manufactured, and that number has increased faster than the rice harvest ever since. We have more transistors being produced and fielded each year than all the grains of rice harvested in all the countries of the world. Isn’t that amazing?

Storage also changed drastically. We have gone from core memory to semiconductor memory. And in secondary storage we have gone from drum memory to disks to SSDs. If we look at consumer disk storage, it is now common to get storage density of better than 500Gb per cubic inch at a cost of less than $.20 per Gb (including enclosure and controller)—a price drop of nearly 8 orders of magnitude. Of course, weight, size, speed, noise, heat, power, and other factors have all also undergone major changes. To think of it another way, that same presentation by Professor Lazowska, noted that the computerized greeting cards you can buy at the store to record and play back a message to music have more computing power and memory in them than some of those multi-million $ computers of the 1950s, all for under $10.

Yet, despite these incredible transformations, the operating systems, databases, languages, and more that we use are still basically the designs we came up with in the 1960s to make the best use of limited, expensive, shared equipment. More to the theme of this blog, overall information security is almost certainly worse now than it was in the 1960s. We’re still suffering from problems known for decades, and systems are still being built with intrinsic weaknesses, yet now we have more to lose with more valuable information coming online every week.

Why have we failed to make appreciable progress with the software? In part, it is because we’ve been busy trying to advance on every front. Partially, it is because it is simpler to replace the underlying hardware with something faster, thus getting a visible performance gain. This helps mask the ongoing lack of quality and progression to really new ideas. As well, the speed with which the field of computing (development and application) moves is incredible, and few have the time or inclination to step back and re-examine first principles. This includes old habits such as the sense of importance in making code “small” even to the point of leaving out internal consistency checks and error handling. (Y2K was not a one-time fluke—it’s an instance of an institutional bad habit.)

Another such habit is that of trying to build every system to have the capability to perform every task. There is a general lack of awareness that security needs are different for different applications and environments; instead, people seek uniformity of OS, hardware architecture, programming languages and beyond, all with maximal flexibility and capacity. Ostensibly, this uniformity is to reduce purchase, training, and maintenance costs, but fails to take into account risks and operational needs. Such attitudes are clearly nonsensical when applied to almost any other area of technology, so it is perplexing they are still rampant in IT.   

For instance, imagine buying a single model of commercial speedboat and assuming it will be adequate for bass fishing, auto ferries, arctic icebreakers, Coast Guard rescues, oil tankers, and deep water naval interdiction—so long as we add on a few aftermarket items and enable a few options. Fundamentally, we understand that this is untenable and that we need to architect a vessel from the keel upwards to tailor it for specific needs, and to harden it against specific dangers. Why cannot we see the same is true for computing? Why do we not understand that the commercial platform used at home to store Aunt Bee’s pie recipes is NOT equally suitable for weapons control, health care records management, real-time utility management, storage of financial transactions, and more? Trying to support everything in one system results in huge, unwieldy software on incredibly complex hardware chips, all requiring dozens of external packages to attempt to shore up the inherent problems introduced by the complexity. Meanwhile, we require more complex hardware to support all the software, and this drives complexity, cost and power issues.

The situation is unlikely to improve until we, as a society, start valuing good security and quality over the lifetime of our IT products. We need to design systems to enforce behavior within each specific configuration, not continually tinker with general systems to stop each new threat. Firewalls, IDS, antivirus, DLP and even virtual machine “must-have” products are used because the underlying systems aren’t trustworthy—as we keep discovering with increasing pain. A better approach would be to determine exactly what we want supported in each environment, build systems to those more minimal specifications only, and then ensure they are not used for anything beyond those limitations. By having a defined, crafted set of applications we want to run, it will be easier to deny execution to anything we don’t want; To use some current terminology, that’s “whitelisting” as opposed to “blacklisting.” This approach to design is also craftsmanship—using the right tools for each task at hand, as opposed to treating all problems the same because all we have is a single tool, no matter how good that tool may be. After all, you may have the finest quality multitool money can buy, with dozens of blades and screwdrivers and pliers. But you would never dream of building a house (or a government agency) using that multitool. Sure, it does a lot of things passably, but it is far from ideal for expertly doing most complex tasks.

Managers will make the argument that using a single, standard component means it can be produced, acquired and operated more cheaply than if there are many different versions. That is often correct insofar as direct costs are concerned. However, it fails to include secondary costs such as reducing the costs of total failure and exposure, and reducing the cost of “bridge” and “add-on” components to make items suitable. Smaller and more directed systems need to be patched and upgraded far less often than large, all-inclusive systems because they have less to go wrong and don’t change as often. There is also a defensive benefit to the resulting diversity: attackers need to work harder to penetrate a given system because they don’t know what is running. Taken to an extreme, having a single solution also reduces or eliminates real innovation as there is no incentive for radical new approaches; with a single platform, the only viable approach is to make small, incremental changes built to the common format. This introduces a hidden burden on progress that is well understood in historical terms—radical new improvements seldom result from staying with the masses in the mainstream.

Therein lies the challenge, for researchers and policy-makers. The current cyber security landscape is a major battlefield. We are under constant attack from criminals, vandals, and professional agents of governments. There is such an urgent, large-scale need to simply bring current systems up to some bare minimum that it could soak up way more resources than we have to throw at the problems. The result is that there is a huge sense of urgency to find ways to “fix” the current infrastructure. Not only is this where the bulk of the resources is going, but this flow of resources and attention also fixes the focus of our research establishment on these issues, But when this happens, there is great pressure to direct research towards the current environment, and towards projects with tangible results. Program managers are encouraged to go this way because they want to show they are good stewards of the public trust by helping solve major problems. CIOs and CTOs are less willing to try outlandish ideas, and cringe at even the notion of replacing their current infrastructure, broken as it may be. So, researchers go where the money is—tried and true, incremental, “safe” research.

We have crippled our research community as a result. There are too few resources devoted to far-ranging ideas that may not have immediate results. Even if the program managers encourage vision, review panels are quick to quash it. The recent history of DARPA is one that has shifted towards immediate results from industry and away from vision, at least in computing. NSF, DOE, NIST and other agencies have also shortened their horizons, despite claims to the contrary. Recommendations for action (including the recent CSIS Commission report to the President) continue this by posing the problem as how to secure the current infrastructure rather than asking how we can build and maintain a trustable infrastructure to replace what is currently there.

Some of us see how knowledge of the past combined with future research can help us have more secure systems. The challenge continues to be convincing enough people that “cheap” is not the same as “best,” and that we can afford to do better. Let’s see some real innovation in building and deploying new systems, languages, and even networks. After all, we no longer need to fit in 32K of memory on a $21 million computer. Let’s stop optimizing the wrong things, and start focusing on discovering and building the right solutions to problems rather than continuing to try to answer the same tired (and wrong) questions. We need a major sustained effort in research into new operating systems and architectures, new software engineering methods, new programming languages and systems, and more, some with a (nearly) clean-slate starting point. Small failures should be encouraged, because they indicate people are trying risky ideas. Then we need a sustained effort to transition good ideas into practice.

I’ll conclude with s quote that many people attribute to Albert Einstein, but I have seen multiple citations to its use by John Dryden in the 1600s in his play “The Spanish Friar”:

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

What we have been doing in cyber security has been insane. It is past time to do something different.

[Added 12/17: I was reminded that I made a post last year that touches on some of the same themes; it is here.]

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]security marketplace, firewalls, IDS, security practices, RSA conference[/tags]
As I’ve written here before, I believe that most of what is being marketed for system security is misguided and less than sufficient.  This has been the theme of several of my invited lectures over the last couple of years, too.  Unless we come to realize that current “defenses” are really attempts to patch fundamentally faulty designs, we will continue to fail and suffer losses.  Unfortunately, the business community is too fixated on the idea that there are quick fixes to really investigate (or support) the kinds of long-term, systemic R&D that is needed to really address the problems.

Thus, I found the RSA conference and exhibition earlier this month to be (again) discouraging this year.  The speakers basically kept to a theme that (their) current solutions would work if they were consistently applied.  The exhibition had hundreds of companies displaying wares that were often indistinguishable except for the color of their T-shirts—anti-virus, firewalls (wireless or wired), authentication and access control, IDS/IPS, and vulnerability scanning.  There were a couple of companies that had software testing tools, but only 3 of those, and none marketing suites of software engineering tools.  A few companies had more novel solutions—I was particular impressed by a few that I saw, such as the policy and measurement-based offerings by CoreTrace, ProofSpace, and SignaCert. (In the interest of full disclosure, SignaCert is based around one of my research ideas and I am an advisor to the company.)  There were also a few companies with some slick packaging of older ideas (Yoggie being one such example) that still don’t fix underlying problems, but that make it simpler to apply some of the older, known technologies.

I wasn’t the only one who felt that RSA didn’t have much new to offer this year, either.

When there is a vendor-oriented conference that has several companies marketing secure software development suites that other companies are using (not merely programs to find flaws in C and Java code), when there are booths dedicated to secured mini-OS systems for dedicated tasks, and when there are talks scheduled about how to think about limiting functionality of future offerings so as to minimize new threats, then I will have a sense that the market is beginning to move in the direction of maturity.  Until then, there are too many companies selling snake oil and talismans—and too many consumers who will continue to buy those solutions because they don’t want to give up their comfortable but dangerous behaviors.  And any “security” conference that has Bill Gates as keynote speaker—renowned security expert that he is—should be a clue about what is more important for the conference attendees: real security, or marketing.

Think I am too cynical?  Watch the rush into VoIP technologies continue, and a few years from now look at the amount of phishing, fraud, extortion and voice-spam we will have over VoIP, and how the market will support VoIP-enabled versions of some of the same solutions that were in Moscone Center this year.  Or count the number of people who will continue to mail around Word documents, despite the growing number of zero-day and unpatched exploits in Word.  Or any of several dozen current and predictable dangers that aren’t “glitches”—they are the norm.  if you really pay attention to what happens, then maybe you’ll become cynical, too. 

If not, there’s always next year’s RSA Conference.

I haven’t posted an update lately of new content on our site, so here’s a bit of a make-up post:

CERIAS Reports & Papers

• "Rights Protection for Categorical Data"
  17 January 2007, 11:00 pm
• "Privacy-Preserving Credit Checking"
  17 January 2007, 11:00 pm
• "Security in Wireless Sensor Networks - A Layer based Classification"
  22 January 2007, 11:00 pm

CERIAS Hotlist

• Plynt Penetration Testing Learning Center
  31 January 2007, 7:09 am
• FireMon by Secure Passage - Firewall and security device change control, auditing and optimization.
  29 January 2007, 9:10 am

CERIAS News

• Biometrics Lab: Brown Bag Lunches Highlight Recent Research
  25 January 2007, 9:32 am
• Call for Presentations: Midwest Security Workshop at Purdue
  8 February 2007, 10:22 am
• Registration Open: Columbus Incident Response Workshop (CCIR)
  15 February 2007, 2:40 pm
• Purdue Partners with LPD in Cyber Forensics
  19 February 2007, 1:09 pm

CERIAS Security Seminar Podcast

• Vipin Swarup, "Research Challenges in Assured Information Sharing"
  17 January 2007, 3:30 pm
• Wojciech Szpankowski, "WHAT IS INFORMATION?"
  24 January 2007, 3:30 pm
• Chris Clifton, "Mathematically Defining Privacy"
  31 January 2007, 3:30 pm