I agree with your assessment of the misconceptions: If you search their database you will see that most of vulnerabilities they are pointing to are for contributed modules. That said, this is the explanation we received. There seems to be no room to argue in this case due to deadlines for the project. The Database: http://nvd.nist.gov/ For future projects we could definitely argue to have these misconceptions clarified in the governments eyes. Thanks Jon On Tue, Sep 30, 2008 at 9:24 AM, <matt@mattfarina.com> wrote:

Jon,

Thanks for your interest in this. I'm interested in this as well.

Some of their concerns seem to be over some misconceptions that might help to be cleared up.

Someone correct me if I'm wrong but drupal 4.0 was 10 major releases ago. 100 + advisories over 10 major releases isn't as many as the 3 which the numbering might look like. Before drupal 5 the major releases were point releases and not full number releases. On top of that, the security advisories cover contributed modules and have included other libraries used by drupal modules, such as getID3.

The security team handles things in a tight way. When something is reported it's not opened up to the world. If the issue is valid it's handled behind closed doors until a fix and advisory is sent out. Those advisories come out on Wednesdays so they can immediately be acted on.

I would be very curious as to what it would take to certification as well as their concerns.

Matt

Quoting Jon Saints <saintsjd@gmail.com>:

On a recent project for the US government, half way through the

...

development process, our work was stopped by a government security review which said that Drupal (and open source software in general) is not suitable for use in government projects that house personal information due to security concerns.

Because our project had been approved by higher ups within the department, we were paid for our work up to that point and asked to stop. Now, its up to the tax payers to foot a much larger bill for other developers to implement a proprietary and more "secure" (or secretive) solution.

The "transparency" of the Drupal project was one of the government's big objections. In their eyes, disclosing and fixing securit holes in a timely manner, is not the same thing as security. They pointed out the 100+ security disclosures since drupal 4.0 as a reason that the system could not be used. We noted that all these disclosures where quickly addressed, but that did not seem to matter.

I notice other governments around the world are using Drupal with great success and savings to citizens: http://buytaert.net/new-zealand-government-using-drupal

The standards we would need to meet with drupal are: http://csrc.nist.gov/groups/SMA/fisma/index.html

My questions are the following: - Have any other developers run into this cerfication problem before? - Is anyone in the drupal community currently working to get Drupal certified for use in US Government projects? - Does anyone know exactly what cerfication would require from a development standpoint?

If there is interest in investigating this type of certification further, let me know. NIST, the department that certifies software, is just down the road from me. I could go investigate further.

Thanks Jon

On Wed, Oct 1, 2008 at 12:40 AM, Drupal Developer <lapurd@gmail.com> wrote:

Wow, I would like everybody to notice something right here.

In the message I reply to, Matt Farina said:

"The security team handles things in a tight way. When something is reported it's not opened up to the world. If the issue is valid it's handled behind closed doors until a fix and advisory is sent out." /end of citation/

I thought that Drupal is an open community of open source developers working under GPL license. Does it mean that ALL issues have to be openly reported to all community for everybody to review? Don't you all think that handling security issues behind closed doors until a fix and advisory will be sent out is sound more like corporate way of thinking on a way to develop something proprietary?

It's a GPL license, that's why I am sure the security team is open to anyone who is interested in helping out on that very important front. But GPL doesn't mean that we have to be stupid as a community, and advertise exploits before a fix can be made and people given a chance to have a security fix to use. Just as the corporate world, as we are finding out all over the world these days, certainly has no "monopoly over intelligence", or over doing what's best for all, open source communities can be smart too. There's nothing proprietary about that. Quite the opposite, in fact: defending ourselves against conspiracies to wreak havoc certainly has to be the right of open source communities, Victor Kane http://awebfactory.com.ar

I'm very concern about that and invite everybody to collaborate on this one.

Does Matt represent a real situation at this matter in Drupal development community? If not, then I'm sure that many people would like to know exactly what the process is for handling security issues from the moment they have been reported?

Thanks in advance, Alex

matt@mattfarina.com wrote:

...

Jon,

Thanks for your interest in this. I'm interested in this as well.

Some of their concerns seem to be over some misconceptions that might help to be cleared up.

Someone correct me if I'm wrong but drupal 4.0 was 10 major releases ago. 100 + advisories over 10 major releases isn't as many as the 3 which the numbering might look like. Before drupal 5 the major releases were point releases and not full number releases. On top of that, the security advisories cover contributed modules and have included other libraries used by drupal modules, such as getID3.

The security team handles things in a tight way. When something is reported it's not opened up to the world. If the issue is valid it's handled behind closed doors until a fix and advisory is sent out. Those advisories come out on Wednesdays so they can immediately be acted on.

I would be very curious as to what it would take to certification as well as their concerns.

Matt

Quoting Jon Saints <saintsjd@gmail.com>:

...

On a recent project for the US government, half way through the development process, our work was stopped by a government security review which said that Drupal (and open source software in general) is not suitable for use in government projects that house personal information due to security concerns.

Because our project had been approved by higher ups within the department, we were paid for our work up to that point and asked to stop. Now, its up to the tax payers to foot a much larger bill for other developers to implement a proprietary and more "secure" (or secretive) solution.

The "transparency" of the Drupal project was one of the government's big objections. In their eyes, disclosing and fixing securit holes in a timely manner, is not the same thing as security. They pointed out the 100+ security disclosures since drupal 4.0 as a reason that the system could not be used. We noted that all these disclosures where quickly addressed, but that did not seem to matter.

I notice other governments around the world are using Drupal with great success and savings to citizens: http://buytaert.net/new-zealand-government-using-drupal

The standards we would need to meet with drupal are: http://csrc.nist.gov/groups/SMA/fisma/index.html

My questions are the following: - Have any other developers run into this cerfication problem before? - Is anyone in the drupal community currently working to get Drupal certified for use in US Government projects? - Does anyone know exactly what cerfication would require from a development standpoint?

If there is interest in investigating this type of certification further, let me know. NIST, the department that certifies software, is just down the road from me. I could go investigate further.

Thanks Jon

I'm not talking about detail explanation of what and how reported security issue can harm Drupal site. But may be some clue in order to deal with it.

Our public SAs don't give details of how to exploit vulnerabilities, while of course the commit logs are there (but it's not always obvious from them either) - this is by design so that we're not simply giving out instructions to people on how to hack sites which don't upgrade in a timely fashion (of which there are many). However, to fix an issue, you need to know how to exploit it, so I'm not really sure what you're asking for here. If a contributed module is extremly insecure and there's not an immediate fix for it, we unpublish the module until an SA can be released for it (and you'll be informed that the module has been 'revoked' by update status).

Or may be we need some special procedure to subscribe to such information.

You can get SAs as soon as they're published via e-mail or RSS from http://drupal.org/security.

But I'm sure that many of us would like to know what is going on with fresh security discoveries.

Those who want to help fix new discoveries can offer to join the security team, I don't think 'would like to know what's going on' is sufficient though. Nat

Victor Kane wrote:

On Wed, Oct 1, 2008 at 12:40 AM, Drupal Developer <lapurd@gmail.com> <lapurd@gmail.com> wrote:

Wow, I would like everybody to notice something right here.

In the message I reply to, Matt Farina said:

"The security team handles things in a tight way. When something is reported it's not opened up to the world. If the issue is valid it's handled behind closed doors until a fix and advisory is sent out." /end of citation/

I thought that Drupal is an open community of open source developers working under GPL license. Does it mean that ALL issues have to be openly reported to all community for everybody to review? Don't you all think that handling security issues behind closed doors until a fix and advisory will be sent out is sound more like corporate way of thinking on a way to develop something proprietary?

It's a GPL license, that's why I am sure the security team is open to anyone who is interested in helping out on that very important front.

But GPL doesn't mean that we have to be stupid as a community, and advertise exploits before a fix can be made and people given a chance to have a security fix to use.

Just as the corporate world, as we are finding out all over the world these days, certainly has no "monopoly over intelligence", or over doing what's best for all, open source communities can be smart too.

There's nothing proprietary about that. Quite the opposite, in fact: defending ourselves against conspiracies to wreak havoc certainly has to be the right of open source communities,

Victor Kanehttp://awebfactory.com.ar

I'm very concern about that and invite everybody to collaborate on this one.

Does Matt represent a real situation at this matter in Drupal development community? If not, then I'm sure that many people would like to know exactly what the process is for handling security issues from the moment they have been reported?

Thanks in advance, Alex

matt@mattfarina.com wrote:

Jon,

Thanks for your interest in this. I'm interested in this as well.

Some of their concerns seem to be over some misconceptions that might help to be cleared up.

Someone correct me if I'm wrong but drupal 4.0 was 10 major releases ago. 100 + advisories over 10 major releases isn't as many as the 3 which the numbering might look like. Before drupal 5 the major releases were point releases and not full number releases. On top of that, the security advisories cover contributed modules and have included other libraries used by drupal modules, such as getID3.

The security team handles things in a tight way. When something is reported it's not opened up to the world. If the issue is valid it's handled behind closed doors until a fix and advisory is sent out. Those advisories come out on Wednesdays so they can immediately be acted on.

I would be very curious as to what it would take to certification as well as their concerns.

Matt

Quoting Jon Saints <saintsjd@gmail.com> <saintsjd@gmail.com>:

On a recent project for the US government, half way through the development process, our work was stopped by a government security review which said that Drupal (and open source software in general) is not suitable for use in government projects that house personal information due to security concerns.

Because our project had been approved by higher ups within the department, we were paid for our work up to that point and asked to stop. Now, its up to the tax payers to foot a much larger bill for other developers to implement a proprietary and more "secure" (or secretive) solution.

The "transparency" of the Drupal project was one of the government's big objections. In their eyes, disclosing and fixing securit holes in a timely manner, is not the same thing as security. They pointed out the 100+ security disclosures since drupal 4.0 as a reason that the system could not be used. We noted that all these disclosures where quickly addressed, but that did not seem to matter.

I notice other governments around the world are using Drupal with great success and savings to citizens:http://buytaert.net/new-zealand-government-using-drupal

The standards we would need to meet with drupal are:http://csrc.nist.gov/groups/SMA/fisma/index.html

My questions are the following: - Have any other developers run into this cerfication problem before? - Is anyone in the drupal community currently working to get Drupal certified for use in US Government projects? - Does anyone know exactly what cerfication would require from a development standpoint?

If there is interest in investigating this type of certification further, let me know. NIST, the department that certifies software, is just down the road from me. I could go investigate further.

Thanks Jon

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Drupal Developer schrieb:

Okay, what is procedure then in order to join security forces here? If that is the only way to get information necessary to get the picture about latest security issues.

Based on your comments I'll veto you joining the team. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI40oRfg6TFvELooQRAnI8AJ0Znjj7GuEqtjwVQmFUXp1c4PLqRACeM202 jt0q7PeW1EdnQgz3qdBIV3s= =m+Mo -----END PGP SIGNATURE-----

On Wed, Oct 1, 2008 at 12:12 PM, Drupal Developer <lapurd@gmail.com> wrote:

In my view it is just demonstration of corporate nature of your thinking. BTW, if somebody in the open community got power to veto somebody out from doing something good, then how do you think it is reflecting on image of this community as "open" one? It is not the way to operate in the open community of developers. If I have some different opinion on something like how vulnerabilities have to be reported to community before they got fixed, it does not mean that I can not help security team to fix it.

"Corporate nature" of Gerhard? You are so funny. First, let me point out that "Drupal Developer" is not that good a name for sending emails to a community mailing list (that, or your mother was really angry when she named you). You are not applying to yourself the transparency principles that you are promoting. Then, our community (and most other opensource communities) values action and contribution against anything else. That's why Gerhard speak has a lot of value here. Damien Tournoud

On Oct 1, 2008, at 2:29 AM, Drupal Developer wrote:

Okay, what is procedure then in order to join security forces here? If that is the only way to get information necessary to get the picture about latest security issues.

Nat's email already told you this: On Oct 1, 2008, at 1:44 AM, Nathaniel Catchpole wrote:

Those who want to help fix new discoveries can offer to join the security team, I don't think 'would like to know what's going on' is sufficient though.

As a member of the (overworked and understaffed) security team, I can tell you right now that we'd reject your application on these grounds. And not because we're demonstrating a "corporate" thinking process. We're trying to protect the very openness of the developer community you're trying to be so concerned with. If you said "I'm really interested in security and want to help fix vulnerabilities, here are my skills I'm bringing to the table, references that prove [sic] I'm not malicious, etc", we'd strongly consider it. But, based on the motivation you've already put forward in this thread -- "I wanna be the first to know so I can try to protect my sites" -- is not going to fly. On Oct 1, 2008, at 1:19 AM, Drupal Developer wrote:

All what I meant is all developers in the community would like to have at least a clue about what security issues are discovered.

http://drupal.org/security

And deal with them on temporary basis on they own sites until final solution will be published. I'm not talking about detail explanation of what and how reported security issue can harm Drupal site. But may be some clue in order to deal with it.

Again, the only way to give a "clue in order to deal with it" is to "give a clue how to exploit it". I'm sure the hackers reading that information will be much better suited to act on these clues than the average site admins who aren't well versed in security exploits.

Or may be we need some special procedure to subscribe to such information.

Any "special procedure to subscribe to such information" that scales to a group of people larger than the security team can't possibly keep the "bad" people out and only let in "good" people. It's already a risk we take letting new forces join the security team itself. No way could we have any reasonable hope of keeping the "initial clue about possible vulnerabilities" list secure. Malicious users *will* read that information, and use it to harm Drupal sites.

But I'm sure that many of us would like to know what is going on with fresh security discoveries.

Indeed, especially hackers. ;) Drupal follows a long established policy of "Responsible disclosure"[1] of discovered vulnerabilities. Nothing about this contradicts the GPL or the openness of the Drupal community in general. In fact, if we did what you suggest, I'm sure far fewer people would be using Drupal (rightfully so). Cheers, -Derek (dww) [1] http://www.sans.org/reading_room/whitepapers/threats/932.php

On Oct 1, 2008, at 3:37 AM, Web Developer wrote:

It is just sad that the only thing you see in my notes is intention to get this kind of information at soon as possible.

It is just sad that you're not paying attention to what we're saying. Another reason you probably wouldn't be a good fit for the security team. ;) I explicitly wrote:

...

If you said "I'm really interested in security and want to help fix vulnerabilities, here are my skills I'm bringing to the table, references that prove [sic] I'm not malicious, etc", we'd strongly consider it.

You *never* said *anything* like that in this entire thread. All you've said can be summarized with these 3 quotes: 1) "I thought that Drupal is an open community of open source developers working under GPL license. Does it mean that ALL issues have to be openly reported to all community for everybody to review? Don't you all think that handling security issues behind closed doors until a fix and advisory will be sent out is sound more like corporate way of thinking on a way to develop something proprietary?" 2) "All what I meant is all developers in the community would like to have at least a clue about what security issues are discovered. And deal with them on temporary basis on they own sites until final solution will be published." 3) "Okay, what is procedure then in order to join security forces here? If that is the only way to get information necessary to get the picture about latest security issues." Many of us have tried to point out the weaknesses in the logic of #1 and #2, and tried to explain why #3 is not a sufficient reason to join the security team. You've just kept coming back saying that the security team is closed (true), corporate (false), and that no one is reading between the lines of your messages that what you *really* mean is "I'd love to help fix vulnerabilities because I'm a security expert and I have an established track record of closing exploits through careful audits, thorough testing, and responsible disclosure." Please. I'm glad you raised your concern (we are an open development community, and discussing concerns like this is part of that), but the overwhelming response has been: "NO, that'd be crazy, we prefer a closed security team and responsible disclosure". It's ok to be outvoted, just be honest and graceful about it and no one will think poorly of you... -Derek (dww)

If more of Drupal community members will know about newest vulnerabilities, then faster these vulnerabilities will be resolved. As I have mention in my previous message - it is not necessary to expose exploit info. Some might say that hacker will then make more damage. Well let me inform you - hacker can exploit problems on your server on they own even without any problem description. You can be your own "hacker" by simply evaluating your web applications and web sites with many vulnerabilities assessment and testing tools available on a market (many of them is open source). The only issue here that I see is security team is not trust to Drupal community own members. May be some solution is possible here like a member certification program. Which can be considered as transitional from "non-trusted" (simple Drupal user) to trusted developer who can help in his spare time without be under pressure of security team bosses. Alex Mikkel Høgh wrote:

On 01/10/2008, at 13.00, Derek Wright wrote:

...

I'm glad you raised your concern (we are an open development community, and discussing concerns like this is part of that), but the overwhelming response has been: "NO, that'd be crazy, we prefer a closed security team and responsible disclosure".

I'd just like to say that Derek is completely and absolutely right here. Responsible disclosure is the only way we can reasonably handle security vulnerabilities, and were it not for that policy, I would not be using Drupal for anything remotely important, because the chance of some guy being quicker than me and hitting me with a zero-day exploit would be unreasonably high.

So while you might disagree, I think the great majority of Drupal developers are quite happy about this policy, and I don't think it'll change in the near future.

-- Kind regards,

Mikkel Høgh <mikkel@hoegh.org>

If you think that oldest BugTraq "full disclosure" listing has a weak logic behind, then you are mistaken (http://www.securityfocus.com). BugTraq as well expose vulnerabilities that does not have solutions yet. All what I have tried to explain that it does not mean that exploit information has to be exposed. But detail description of the problem can help on its own even before solution come out. For me as for open source developer it is kind of natural to associate limited disclosure or after solution disclosure with corporations like a Microsoft and such but not with open source community. Another good reason well explained on <http://en.wikipedia.org/wiki/Vulnerability_(computer_science)>: "Analysis and risk rating ensure the quality of the disclosed information. The analysis must include enough details to allow a concerned user of the software to assess his individual risk or take immediate action to protect his assets." Which is, btw, is very well mentioned in NIST Special Publication 800-51 "Use of the Common Vulnerabilities and Exposures (CVE) Vulnerability Naming Scheme" <http://csrc.nist.gov/publications/nistpubs/800-51/sp800-51.pdf>. If Drupal security team made a decision to follow another path, its okay. But you should not judge another people in this matter so quick. Anyway, I have tried to be polite but since I have receive such a suspicious in bad intentions and arrogant perception here (at least that is what I feel now), I think I will standout for now in my true intentions to help and let you enjoy status of "overworked and understaffed" security team. Alex Derek Wright wrote:

On Oct 1, 2008, at 3:37 AM, Web Developer wrote:

...

It is just sad that the only thing you see in my notes is intention to get this kind of information at soon as possible.

It is just sad that you're not paying attention to what we're saying. Another reason you probably wouldn't be a good fit for the security team. ;)

I explicitly wrote:

...

...

If you said "I'm really interested in security and want to help fix vulnerabilities, here are my skills I'm bringing to the table, references that prove [sic] I'm not malicious, etc", we'd strongly consider it.

You *never* said *anything* like that in this entire thread. All you've said can be summarized with these 3 quotes:

1) "I thought that Drupal is an open community of open source developers working under GPL license. Does it mean that ALL issues have to be openly reported to all community for everybody to review? Don't you all think that handling security issues behind closed doors until a fix and advisory will be sent out is sound more like corporate way of thinking on a way to develop something proprietary?"

2) "All what I meant is all developers in the community would like to have at least a clue about what security issues are discovered. And deal with them on temporary basis on they own sites until final solution will be published."

3) "Okay, what is procedure then in order to join security forces here? If that is the only way to get information necessary to get the picture about latest security issues."

Many of us have tried to point out the weaknesses in the logic of #1 and #2, and tried to explain why #3 is not a sufficient reason to join the security team. You've just kept coming back saying that the security team is closed (true), corporate (false), and that no one is reading between the lines of your messages that what you *really* mean is "I'd love to help fix vulnerabilities because I'm a security expert and I have an established track record of closing exploits through careful audits, thorough testing, and responsible disclosure." Please.

I'm glad you raised your concern (we are an open development community, and discussing concerns like this is part of that), but the overwhelming response has been: "NO, that'd be crazy, we prefer a closed security team and responsible disclosure". It's ok to be outvoted, just be honest and graceful about it and no one will think poorly of you...

-Derek (dww)

Is it everybody here so quick to see another person logic flaw, where in fact you just have to think a little further? I did not suggest that you have to give such detail description that will expose exploit right away. But I'm sure in most cases experienced developer/tester can come up with explanatory description without exposing too much. I agree that some problem could be so obvious so any explanation will expose exploit info. Okay, but it is only one case. There are many problems that are not so obvious. Alex Patrick Teglia wrote:

it does not mean that exploit information has to be exposed. But detail description of the problem can help on its own even before solution come out.

I am sorry, but even a guy with a Security+ certification (in other words, me :) ) can see the flawed logic in this statement. A detailed description of the problem is a description of the vulnerability that attackers would EXACTLY be looking for.

Patrick Teglia

On Wed, Oct 1, 2008 at 7:19 AM, Web Developer <lapurd@gmail.com> wrote:

...

it does not mean that exploit information has to be exposed. But detail description of the problem can help on its own even before solution come out.

Back to topic:

The security review and resolution process at drupal is one of the things that has allowed my company to use drupal as a part of systems that handle ePHI (electronic protected health information) which have been successfully audited as HIPAA (Health Insurance Portability and Accountability Act) compliant.

--Eric

This sounds like a handbook page about certifications, policies, and auditions of Drupal is in order? Maybe we can add consultants/agencies/shops who managed to achieve or approve them for each entry as a reference. That list might also contain revoked attempts, and would fit best in the "About Drupal" handbook, of course. Cross-posting this to consulting list. Daniel

On Wed, Oct 1, 2008 at 4:08 PM, Web Developer <lapurd@gmail.com> wrote:

I did not suggest that you have to give such detail description that will expose exploit right away. But I'm sure in most cases experienced developer/tester can come up with explanatory description without exposing too much. I agree that some problem could be so obvious so any explanation will expose exploit info. Okay, but it is only one case. There are many problems that are not so obvious.

Our security process can be thought as complying with "responsible disclosure", as described for example in the RFPolicy [1]. Close cooperation between security researchers and vendors (ie. us, the Drupal community) in private before the security vulnerability has been disclosed has largely proven to be the good way to deal with this kind of issues. Our community is open. Discussing issues "inside" the community means nothing more than discussing those publicly. Damien Tournoud [1] http://www.wiretrip.net/rfp/policy.html

All what I have tried to explain that it does not mean that exploit information has to be exposed.

This is what actually happens already: Security team receives a security report, does deep analysis of the potential problem, and if the report turns out to be valid, the security team aids the corresponding module maintainer to fix the vulnerability. The exploit information is made public when a fix for all users is available.

"Analysis and risk rating ensure the quality of the disclosed information. The analysis must include enough details to allow a concerned user of the software to assess his individual risk or take immediate action to protect his assets."

This, too, is what happens: All subscribers of the security announcements newsletter receive a mail for each and every fixed vulnerability throughout Drupal core AND contributed modules.

If Drupal security team made a decision to follow another path, its okay. But you should not judge another people in this matter so quick. Anyway, I have tried to be polite but since I have receive such a suspicious in bad intentions and arrogant perception here (at least that is what I feel now), I think I will standout for now in my true intentions to help and let you enjoy status of "overworked and understaffed" security team.

Alex

Look, I do not belong to the security team either (albeit I considered to join for helping out already). However, I /feel/ very safe knowing that we have top-notch contributors in this team, doing an excellent job on reviewing and solving all security issues. To be honest, I would not like to see an arbitrary "Web Developer" (ex. "Drupal Developer") there either. As a regular Drupal contributor and user, I know the contributions of /each/ security team member, which makes me believe that they are experts in all Drupal areas - and friends I can trust. I would recommend you to contribute more to Drupal, get some kudos for your valuable contributions, and then ask again. Thanks, Daniel

Drupal Developer wrote:

Wow, I would like everybody to notice something right here. Please stop feeding the troll. Those of us who pay attention all understand and agree with the existing security infrastructure and appreciate the hardwork and thankless job that is managing exploits in a timely fashion. There isn't a debate to be found here, only a waste of time. -- Michael Favia

The names of Citizens are collected on the website along with some personal contact information. We were told that our application required the Medium level security certification. For collecting more sensitive information, certification becomes nearly impossible. Thanks Jon On Tue, Sep 30, 2008 at 9:35 AM, Gerhard Killesreiter < gerhard@killesreiter.de> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Jon Saints schrieb:

...

On a recent project for the US government, half way through the development process, our work was stopped by a government security review which said that Drupal (and open source software in general) is not suitable for use in government projects that house personal information due to security concerns.

Just out of interest: What kind of information are we talking about? Tax numbers, bank accounts?

[...]

...

I notice other governments around the world are using Drupal with great success and savings to citizens: http://buytaert.net/new-zealand-government-using-drupal

Seems like a showcase site only.

Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFI4kdWfg6TFvELooQRArp1AKCdXFYZDMztJ7wrhhiOJOFG4q3/lACfbsXK BX1vLaioeWG348yH/V/ufKs= =yFhK -----END PGP SIGNATURE-----

I've read all the messages in this thread, but I want to build on what Steven has to say here. Please allow one disclaimer so I don't get myself in trouble. Although I work for the federal government, I do not speak for the federal government nor from my position in the federal government. I'm simply a Drupal fan. Steven is right about the number of competing standards/programs and levels of reviews/audits/and certification that go on in the federal government. In many of the cases with FISMA (one of the standards Joe links to in his first message), the certification that takes place in most agencies are for systems and not in particular a single application such as Drupal. In many respects this is a bottom-up certification where each person in the chain certifies to their supervisor that a system follows agency rules, guidelines and federal laws in making sure the system is secure, properly patched, and all risks have been identified/minimized. It is a very difficult and laborious process in trying to policy put into practice. My agency utilizes a mix of Unix, Linux, and Windows systems. On our administrative PCs we run a mix of propriety and open source software (we've used Thunderbird as our official email client for years). On our operational systems all our applications and OS are open source or built in-house applications (utilizing Java, Tcl, Python, and variations of C). Federal agencies can and do adopt open source for their applications. In fact, I've seen the certification process knock out more propriety systems than open source systems especially if they're aging systems with little in the way of user access control granted. Every year, I have to have one necessary propriety system given an exception since it doesn't quite meet the requirements...and this system can't even be networked into the office LAN. Here is my guess as to why Drupal wasn't accepted, without getting deep into the policy. As I said at the start, from the system owner all the way up through the agency's management up to the CIO...EVERYONE has to certify that the system is secure and risks have been identified/minimized. This is especially true when it comes to personally identifiable information (PII) and/or if the system is outside the firewall. In order for all those people to sign on to the certification, they each have to have an understanding of the system. My guess is that someone was not comfortable with their own understanding of Drupal or open source to know whether the system would meet all the requirements (especially if they're racing to complete budgets/certifications during the final hours of the fiscal year. The fact is some agencies or managers in those agencies just don't have an understanding of the open source model and are very cautious in moving away from what they know. Eventually, we'll have to educate them. Joe, what strikes me as odd though is that before a project is approved these days the security requirements are understood. It sounds to me as if someone on the federal side didn't do their job in working with and informing the IT Security Officer about what this project was all about. Very interesting and I hope it never happens to me. BryanSD Steven Peck wrote:

Which government security review/standard?

There are dozens if not hundreds of competing standards/programs and levels of auditing and determination depending on which department you are dealing with. For example just one program was formerly known as DITSCAP and is now DIACAP.

Many of these have more to do with procedures and policies then code.

Steven

On Tue, Sep 30, 2008 at 8:40 AM, Jon Saints <saintsjd@gmail.com> wrote:

...

The names of Citizens are collected on the website along with some personal contact information. We were told that our application required the Medium level security certification.

For collecting more sensitive information, certification becomes nearly impossible.

Thanks Jon

On Tue, Sep 30, 2008 at 9:35 AM, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Jon Saints schrieb:

...

On a recent project for the US government, half way through the development process, our work was stopped by a government security review which said that Drupal (and open source software in general) is not suitable for use in government projects that house personal information due to security concerns.

Just out of interest: What kind of information are we talking about? Tax numbers, bank accounts?

[...]

...

I notice other governments around the world are using Drupal with great success and savings to citizens: http://buytaert.net/new-zealand-government-using-drupal

Seems like a showcase site only.

Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFI4kdWfg6TFvELooQRArp1AKCdXFYZDMztJ7wrhhiOJOFG4q3/lACfbsXK BX1vLaioeWG348yH/V/ufKs= =yFhK -----END PGP SIGNATURE-----

Chris Johnson wrote:

The Dept. of Defense is likely the single largest spender in the Drupal market;

Just think if the DOD contributed 1% of 1% of its budget to OSS, the market would be booming with products. Nancy E. Wichmann, PMP Internal Virus Database is out of date. Checked by AVG - http://www.avg.com Version: 8.0.169 / Virus Database: 270.7.0/1685 - Release Date: 9/22/2008 4:08 PM

Indeed. In the article I provided the first link to, there is also this quote: "Not everyone has been pleased with how the bill calls out open-source software by name, though. Analysts at the Business Software Alliance met with members of the committee to voice their concern that the bill unfavorably offers open-source software products an unfair competitive advantage over other commercial software, according to a BSA spokesperson who declined to be named." I think we all know who the BSA is, and who they represent. Clearly the proprietary software vendors are upset and lobbying against FOSS. On Tue, Sep 30, 2008 at 3:55 PM, Laura Scott <pinglaura@gmail.com> wrote:

Consider that one big difference between proprietary and open source is lobbying and existing contract relationships. Chris DiBona I believe spoke about how a defense contractor tried to get OSS banned from military systems, but after an internal audit of such systems revealed that a huge % of such systems (30%? More? I confess I don't recall) depended upon OSS, the DOD rejected the proposal. There is more to this than simple perceptions about FOSS.

Laura

On Sep 30, 2008, at 9:14 AM, Jon Saints wrote:

On a recent project for the US government, half way through the development process, our work was stopped by a government security review which said that Drupal (and open source software in general) is not suitable for use in government projects that house personal information due to security concerns.

Because our project had been approved by higher ups within the department, we were paid for our work up to that point and asked to stop. Now, its up to the tax payers to foot a much larger bill for other developers to implement a proprietary and more "secure" (or secretive) solution.

The "transparency" of the Drupal project was one of the government's big objections. In their eyes, disclosing and fixing securit holes in a timely manner, is not the same thing as security. They pointed out the 100+ security disclosures since drupal 4.0 as a reason that the system could not be used. We noted that all these disclosures where quickly addressed, but that did not seem to matter.

I notice other governments around the world are using Drupal with great success and savings to citizens: http://buytaert.net/new-zealand-government-using-drupal

The standards we would need to meet with drupal are: http://csrc.nist.gov/groups/SMA/fisma/index.html

My questions are the following: - Have any other developers run into this cerfication problem before? - Is anyone in the drupal community currently working to get Drupal certified for use in US Government projects? - Does anyone know exactly what cerfication would require from a development standpoint?

If there is interest in investigating this type of certification further, let me know. NIST, the department that certifies software, is just down the road from me. I could go investigate further.

Thanks Jon