(LinuxWorld) — Is there room for open source in the U.S. government's forthcoming cybersecurity plan? A recent draft of the plan, which will eventually outline the government's computer-security strategy, mentioned open-source software only once. But in the last few months, Congressman Adam Smith (D-Wash.) has been lobbying to have the plan explicitly reject the use of the GPL, and he has circulated a letter around Washington calling for the authors of the plan to do just that on the grounds that the GPL license is bad for computer security.

LinuxWorld recently caught up with Marc Sachs, Director for Communication Infrastructure Protection at the White House Cyberspace Security Office, to ask what he thought of this argument and to get a better sense of what his team sees as the role of open-source software in government.

Sachs is no neophyte when it comes to open-source software. He got his first look at Linux in 1994, when a computer hobbyist with the 101st Airborne Division was using it for tactical e-mail. After spending a few years building IP-based tactical networks to connect tanks, helicopters, and artillery pieces, Sachs joined the Joint Task Force — Computer Network Operations, which was set up to defend the Department of Defense's computer networks. In February 2002, he was hired by the White House to help craft the nation's cybersecurity plan.

LinuxWorld: As far as I can tell, your first draft of the Cyberspace Security Plan mentions open-source technologies exactly one time.

Sachs: Yeah. The government's take on open source — just so we know everything up-front here — is that we are not particular to either solution being the best. We recognize that there's room for both [proprietary and open-source technologies]. We actually need both, because there are applications for both. It would be irresponsible for the government, or for any company for that matter, to embed themselves purely proprietary or purely open-source. That's lunacy. Knowing that, you have to figure out what's the right balance. Then it comes down to a question for the world we live in, which is the security side: Which ones are secure or can be secured? Then we can certify that security.

That then introduces a whole new challenge, because the government is leaning toward the NIAP [National Information Assurance Partnership] process. You get things certified through NIAP with different assurance levels, the EALs [Evaluation Assurance Levels]. To do that, though, costs quite a bit of money to run through these certification labs. The lower EALs can be certified by private labs, the upper ones have to be done by government labs. Regardless, there's a large cost to get it through the certification process. Big vendors with deep pockets, like Microsoft or Sun, can certainly get their products through the process fairly easily, because they have the dollars to pay for it. If you get an open-source pure-play like Apache, which doesn't have a vendor associated with it, who pays for the cost of doing Apache? That means, if it's important to the Apache community, they need to get a consortium of Apache users that have some dollars, and they can get the thing through the process.

LW: What do you see as security issues for open-source software?

Marc Sachs: The thing I have to make clear up-front is that the government's not going to say that open source is better than proprietary. There's no argument either way. What we do want of open source — particularly the programmers and those who are reviewing code — is this mindset of not applying security as an add-on, but to build it in. Pervasive things like buffer overflows and other types of coding violations continue to hamper the open community, just as they do the proprietary community, and we have to ask the crazy question, "Why?"

We've understood that phenomenon since the '50s. It's not new. But why do we still do it? If the open community wants to make a huge difference in security, well let's start cleaning up some of these well-known, well-published vulnerabilities and get some clean code.

I guess a problem that the open community faces is there are maybe half a dozen types of software that are very popular, like the BSDs, Apache, Linux and such. A nice community of eyes has grown around it. But you've got countless thousands of other packages, other software that — other than the developer — may only have one or two other sets of eyes looking at the code. The rest of them, they're only interested in this because they can download it and compile it for free. They're not going to do this exhaustive code review. If there's a feature they want, they might go in and tinker with it. But it's somewhat of a myth to say that all open source gets viewed by many, many eyes and you can find vulnerabilities real quick. That's not that true, because there are just not that many people with the coding skills or the time to go through millions of lines of code looking for problems — unless you're a security researcher or somebody bent on causing trouble, who can take the latest build of BIND when it gets released and diff it against the previous version to go find what they've fixed. You've got this window of a few days, that you can now go exploit the security vulnerability until people upgrade. The people who are doing that are generally up to no good.

LW: What kind of an impact will your document have on computer use, first of all in the Federal Government, and secondly in America?

Sachs: We hope that it's going to work across all sectors. Within the Federal Government, we recognize that the biggest thing we can do is show leadership. There's a general trend toward not wanting to have new laws and regulations, and we concur with that. Trying to regulate the Internet would slow down the rapid development that we've had.

On the other hand, the general public would like to have the government secure the Internet. If you want to do that right, if you want to provide that government level of security, then there has to be a government level of regulation. We're caught, in that we don't want to regulate, but we want security. The best thing the government can do is lead by example. We secure our own stuff according to the way we would like everybody else to do it, experiment with it, work out the bugs, use those public dollars to validate that the new procedures actually do work and then encourage industry partners to follow that lead.

LW: Will the recommendations that you make eventually become Federal Government policy?

Sachs: Yes. One of the things that OMB (Office of Management and Budget) has come to grips with over the last couple of years is that this free-wheeling spending on IT products needs to get a little more focused. The Department of Treasury just spends what they want to. Agriculture just spends what they want to. Over the last couple of years, as each year's budget request has come in, they've asked the departments to highlight in there "How much specifically are you spending on IT, and in that, how much is going toward security products?"

Based on that input, OMB has now prepared in future budgets to start mandating a certain spending level on security. If that money's not being spent according to the way OMB wants it spent, then they can withhold funding. That doesn't require any new regulations or laws for the Internet. What it winds up doing is forcing government to practice what it preaches.

Open source's role in the Federal Government

Sachs: It clearly has a place. There is a lot of popularity there. Many government employees have spouses who work in the industry, or they have second jobs or other personal interest in different products. People tend to use at work the things they're familiar with from previous jobs. There's no way to prevent open-source software from coming into the government, no more than it's possible to prevent it from any large enterprise. What then needs to come from that — and this is where we're leaning heavily on the NIAP — is a way of knowing, regardless of the source of the software, can we certify some security level. Long-term cost — total cost of ownership, return on investment — is not something our office is looking at.

LW: You expect all open-source software in the government will be NIAP-certified?

Sachs: At some point, yes. We've made the agreement that this is the direction that the government needs to go and that we need to certify the software as being secure. NIAP is the process.

LW: What does this mean for R&D? There has been some talk about the types of licenses that should be explicitly excluded by your plan from R&D.

Sachs: Yeah, that's a real political hot potato. You have a lot of companies that think the GPL or the GNU licenses are appropriate, and you have other companies that say that they destroy the ability to capitalize on R&D investments. We're a security office. We're looking more at how secure can these products be, versus what are their intellectual property rights. It's not a real fair question to ask of us, except that nobody else is in this space, other than the DOJ.

LW: From your perspective, do licenses have anything to do with security?

Sachs: Licensing is more of an intellectual property issue versus a security issue. If something is GPL'd or GNU licensed and it's open software, it can still be inspected by both friendlies and unfriendlies. There's no difference there. It purely comes down to "Can you commercialize that software. And under what restriction?"

LW: The recent letter written by Representative Adam Smith seemed to imply that if you can't commercialize software, it's bad for security because you won't have the same level of software development.

Sachs: I think the jury is still out on that one. I don't know that there's really a proper stand. We got a copy of that, and we're still trying to figure out what is the proper way to look at that. There's no way I could give you a quotable response.

LW: IBM and Red Hat have been very clear that they didn't think any changes should be made with respect to the GPL.

Sachs: I find it a curious debate. I hadn't even thought of it as being a problem until I saw this letter come up. We're all very aware of many instances where publicly licensed software has a commercial wrapper put on it, and it works just fine. People profit from it and still stay within the limits of the GPL. There are others who would like to make the argument — and maybe there is an argument — that it hampers development.

I don't know what's really behind it — if it's really an issue or if it's companies that are just posturing for language to go into the strategy. You know the deal here in Washington; there's just tons of politicking.

LW: It sounds like there will not be legislation coming from your report that will influence people outside of the Federal Government.

Sachs: Our intent is to not have that, and that's guidance pretty much from the President. He says, "Leave it alone; let market forces determine where this thing goes." On the other hand, we are getting a small of noise now from industry and the private sector that says a little bit of regulation wouldn't be a bad thing.

LW: When your report comes out, who in the government will be affected? Are there going to be people running little Linux-based e-mail systems that are suddenly going to have to unplug them because they're not using a NIAP-approved version of Linux?

Sachs: It's up to the departments to make that call. The Defense Department is the only one so far that's put its foot down. I think June or July [of 2002] was their drop-dead date. Any new procurements after that point had to be NIAP-certified or you would have to put in for an exception to policy. But that affected new procurement, if I remember the language right.

LW: After your report comes out, won't that become government policy, and won't everyone be affected?

Sachs: Not necessarily, because right now it's still a draft. Again, it's a strategy, not a mandate. It may generate language that could become government policy, but right now it's just a strategy. I think it's a little early to say that once the strategy is ultimately signed by the President and issued, [the report] will mandate certain behavior.