[development] development Digest, Vol 70, Issue 1
Micah Tapman
m.tapman at questconsultantsllc.com
Wed Oct 1 06:19:00 UTC 2008
I'm coming in a bit late to the U.S. government discussion but as it's
an area of expertise for me I'll weigh in with some thoughts that may
(or may not) be of some help.
===Warning, these are my thoughts. They are not your thoughts. They are
given for free. Take them for what they are worth. Question them and do
some research before taking my word for things!!!===
Software Certification
Software certification in the U.S. federal government is handled under
either the Common Criteria program or the Cryptographic Module
Validation Program. Generally, software is (generally) certified under
Common Criteria at level 2 or 4, and that software uses cryptographic
modules that were/are certified under the Cryptographic Module
Validation Program. For example, Drupal would qualify for a Common
Criteria certification. The PHP cryptographic module used in Drupal
would be certified under the Cryptographic Module Validation Program.
Separating these two pieces is very important in order to assure
security (the old adage about never writing "new" cryptographic
functions yourself) and to make sure the government security reviewers
understand what was reviewed and how it was reviewed.
FISMA and NIST
The Federal Information Security Management Act of 2002 consolidated
most of the U.S. federal government's information security requirements
and specifically tasked the U.S. National Institutes of Standards and
Technology (NIST) with developing information security guidelines for
all U.S. government programs. These guidelines are published in Special
Publications, the most important of which is 800-53, Recommended
Security Controls for Federal Information Systems. This Special
Publication provides the baseline security guidance for all federal
information systems, and one of those requirements is for the
certification and accreditation of systems prior to deployment.
Enterprise Architecture
Another aspect of U.S. federal information systems is the recent (last
10 years) move to a standardized enterprise architecture. Unfortunately,
the "architecture" term tends to deceive people. What enterprise
architecture normally focuses on is not "architecture" as an information
architect might envision it, rather it's the selection of products,
software and hardware, to be used throughout an organization. For
example, an agency's enterprise architecture will state which content
management systems are authorized for use within the organization. This
list is maintained by the agency's chief information officer and updated
on a semi-regular basis.
Drupal and Uncle Sam
Using Drupal on a federal task requires a couple of specific steps.
First, the cryptographic modules used in the system, including those
used by Drupal, must be approved by the Cryptographic Module Validation
Program. This is the first and most critical security hurdle, and it
should be the first question the government's independent security
analyst asks when they are vetting the program. Second, if Drupal is not
Common Criteria certified (at least level 2), then the program needs to
include security testing to ensure the product meets or exceeds the
stated claims. What's this mean? It means checking to make sure Drupal
performs the functions that it claims to be able to handle, such as
session management or access control. Without a Common Criteria
certification this testing falls on the development/program office for
the new project trying to use Drupal. Third, the actual development
effort must meet all of the requirements as dictated by NIST under
FISMA, i.e., Special Publication 800-53. These requirements are scaled
according to the security level of the system being built, from low
(that means standard) to moderate (that means enhanced) to high (that
means critical to the nation). All government systems must be secure,
obviously, so even low (standard) security requirements are fairly
onerous. High (critical) systems true enterprise class efforts with very
robust security requirements. Unfortunately, the inclusion of any
personally identifiable information, such as names and addresses,
elevates a system to moderate (enhanced) security right off the bat.
This makes development of even small systems quite complex. Fourth, the
development office needs to expand on the NIST security requirements to
include functional security requirements, and any other areas specific
to the application being developed. Fifth, the application must be
scanned and/or tested for vulnerabilities prior to deployment. Sixth,
the application must be accredited (this is the second half of
certification and accreditation) prior to deployment. Typically, a
certification official, independent from the development office,
provides an executive (the accrediting authority) with a report on the
application's security posture and any deficiencies. This report is the
basis for the executive's decision about whether or not to approve
deployment.
Deploying Drupal
My recommendation for anyone trying to deploy Drupal on a federal task
is to first and foremost get it on the agency's list of approved
products, i.e., the enterprise architecture. This is a time consuming
task but it will pay dividends. Second, standardize on a Drupal version
and document exactly what cryptographic functions will be used.
Cryptography is a complex and touchy subject, probably because most of
us (me included) can't really understand it directly, so using an
approved cryptographic module is the only way to go. If you don't, and
someone asks about it, your entire project may come to a screeching
halt. I'd also take the time to go through all of the requirements for
the system, whether it's low, moderate, or high, in NIST Special
Publication 800-53. Doing that will allow you to interact with the
certification and accreditation team on their level and you'll already
know all of their questions, it's also a halfway decent security
requirements reference. And don't forget to also document and work to
fulfill all of your application's specific security requirements!
Finally, plan on doing some actual scanning testing of the application
and providing this report to the accrediting authority prior to their
decision about deploying the application. <self serving
promotion>Penetration testing of web applications is really helpful when
it comes time to answer the question, "Is this application secure enough
to put out on the Internet?"</self serving promotion>.
I guess that's a lot of info, to the point of being a TLDR post :-).
Sorry for rambling a bit but it's a complex subject and one I've spent
more time with than I care to admit. If anyone's interested in more
information (you must be crazy!) feel free to drop me a line.
Oh, and all this stuff only applies to normal government tasks,
sensitive but unclassified stuff, not to national security efforts,
those are governed under Department of Defense guidelines, not by NIST.
Micah Tapman
Principal
Quest Consultants LLC
240-297-1014
development-request at drupal.org wrote:
> Send development mailing list submissions to
> development at drupal.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.drupal.org/listinfo/development
> or, via email, send a message with subject or body 'help' to
> development-request at drupal.org
>
> You can reach the person managing the list at
> development-owner at drupal.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of development digest..."
>
>
> Today's Topics:
>
> 1. Re: Certify Drupal for use in Government (US) Projects
> (Piermaria Maraziti)
> 2. Re: Certify Drupal for use in Government (US) Projects
> (Bryan Ruby)
> 3. Re: Certify Drupal for use in Government (US) Projects
> (Jon Saints)
> 4. Announcing DRUPAL-7-0-UNSTABLE-1 (Angela Byron)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 01 Oct 2008 01:02:15 +0200
> From: Piermaria Maraziti <piermaria at maraziti.it>
> Subject: Re: [development] Certify Drupal for use in Government (US)
> Projects
> To: development at drupal.org
> Message-ID: <20080930230359.675E31440B8 at polimnia.eridia.it>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
>
> At 17.14 30/09/2008, you wrote:
>
>
>> The "transparency" of the Drupal project was one of the government's
>> big objections.
>>
>
> Just as a quick note by a lurker: various organs of the Italian
> government (Finance Ministery but not only) judged the "open" is OS
> projects to be a very good element for the usual reasons addressed by
> OS evangelists, also about security issues. It's a priority, to them,
> also the active participation in community: giving help when they can
> to receive help when they need (yep: most utilitary, not so
> idealistic - but pragmatic and correct).
>
> Ciao!
>
>
> --8<-----------------------------------fnord-----
> Piermaria Maraziti piermaria at maraziti.it KALLISTI
> ICQ744473 MSN:kallisti at hotmail.it +3934735GILDA
> www.gilda.it www.eridia.it www.hovistocose.it
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 30 Sep 2008 21:47:44 -0500
> From: Bryan Ruby <bryan at cmsreport.com>
> Subject: Re: [development] Certify Drupal for use in Government (US)
> Projects
> To: development at drupal.org
> Message-ID: <48E2E4D0.9060502 at cmsreport.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> 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 at 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 at 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-----
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 30 Sep 2008 23:27:17 -0600
> From: "Jon Saints" <saintsjd at gmail.com>
> Subject: Re: [development] Certify Drupal for use in Government (US)
> Projects
> To: development at drupal.org
> Message-ID:
> <8e779d5d0809302227y6a2d6f41q4bf6f728a496dd9a at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Thanks for all the informative comments. The discussion has been most
> helpful.
>
> Its does appear that our case was the result of a decision of an individual
> (who maybe is not familiar with Drupal), and not a sign of general
> opposition by the government to Open Source software.
>
> That is good to know.
>
> Reading through NIST's documentation it seems that certification for
> software to meet the FISMA standards usually takes years. As others have
> pointed out, this is just one of many different standards that the
> government has for software. Its unclear to me where we could even start to
> certify Drupal for government use.
>
> The lesson here... approval of open source tools seems to happen on a case
> by case and department by department basis. Even if your project is
> approved by a Department heads, ask for a review of the proposal by the
> Security Officer in charge before work begins. In our case, I am not sure
> why that did not happen until half way through the project. We are just
> learning to work for the government. So this is a lesson we will take
> carefully into all our work from here on.
>
> I have contacted NIST to see if I could sit down and chat with someone to
> bring up some of our questions posted in this thread. If I do get a
> conversation, I will be sure to post the comments back to the group here. I
> have also asked them for alist of the approved content management systems so
> we can get an idea of which companies/projects have achieved certification.
>
> Thanks
> Jon
>
> On Tue, Sep 30, 2008 at 8:47 PM, Bryan Ruby <bryan at cmsreport.com> wrote:
>
>
>> 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 at 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 at 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-----
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.drupal.org/pipermail/development/attachments/20080930/1f9a91d6/attachment-0001.htm
>
> ------------------------------
>
> Message: 4
> Date: Wed, 01 Oct 2008 01:29:45 -0400
> From: Angela Byron <drupal-devel at webchick.net>
> Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-1
> To: development at drupal.org
> Message-ID: <48E30AC9.7090705 at webchick.net>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Please see http://drupal.org/node/311949 for back-story.
>
> Summary:
> "Unstable" releases are going to be periodic (probably bi-weekly-ish or
> as otherwise needed) "snap-shots" of what's in HEAD, intended for
> pre-alpha testers who want to provide very preliminary feedback, core
> developers rolling "epic" HEAD patches who want something that doesn't
> change every hour to roll against, and/or contributed module developers
> who want to get the jump on porting their modules against something
> that's not a constantly moving target. Drupal 7 is currently being
> developed heavily, and what is in these unstable releases bears very
> little resemblance to what the final release of Drupal 7 will look like;
> this is merely a tool for contributors to do their work more efficiently.
>
> Please note that these are called "unstable" releases for a reason. They
> are intended for developers only, or testers comfortable with things
> randomly exploding in their face. Do NOT upgrade your production sites
> to unstable releases. Do NOT expect APIs to remain frozen in any way
> between unstable releases until code freeze. I'm not going to even
> include instructions on how to get it, because honestly, if you can't
> figure it out, you really shouldn't be using it. ;)
>
> Now, that said, here's a summary of things that are included in
> UNSTABLE-1. For the full list, see
> http://cvs.drupal.org/viewvc.py/drupal/drupal/CHANGELOG.txt?revision=1.280&view=markup&pathrev=DRUPAL-7-0-UNSTABLE-1
> which I will try to make a point of actually remembering to update next
> time I roll an unstable release. :P
>
> For developers:
> ===============
> - SimpleTest module, an automated code tester, is now in core, along
> with a bazillion tests. These (should) now all pass, so you can use this
> as a guideline to know whether your patches / modules have broken
> anything. See documentation at http://drupal.org/simpletest.
> http://acquia.com/files/test-results/index.html for an idea of how our
> overall test coverage is coming along.
>
> - A completely new database API, known as "Database: The Next
> Generation" (DBTNG). This involves a lot of changes, so please see the
> docs at http://drupal.org/node/310069.
>
> - A "code registry" which is a set of database tables holding all of the
> functions in all of the modules, allowing files to be lazy-loaded. This
> requires changes to your .info files. See
> http://drupal.org/node/224333#registry for more details.
>
> - WYSIWYG editors now have a hope and prayer of integrating with
> textareas given the new #input_format property on textareas.
>
> - Image toolkits can now be supplied by modules. This is nice, so you
> don't have to do awkward copying of 'image.imagemagick.inc' into the
> includes folder.
>
> For users:
> ==========
> - Core now offers two install profiles: a basic one that sets up stuff
> like an "Article" and "Page" content type, some Taxonomy vocabularies,
> etc. The installer requirements check also got a nice makeover and looks
> more like the status report page.
>
> - Removed several modules and extraneous features: Throttle module's
> gone, Ping module's gone, access rules are gone, that horrible wall of
> comment settings is gone, etc.
>
> - Added drag-and-drop to a bunch of areas (poll results, languages,
> etc.) that missed them in D6.
>
> - Permissions now have descriptions, and node permissions are now sorted
> by content type rather than by verb.
>
> Known Bugs:
> ===========
> Plenty, but the most critical one is that you can't currently upgrade
> 6.x => 7.x: http://drupal.org/node/303889. Actually, I suppose this
> could also be considered a "feature" of unstable releases, depending on
> your point of view. ;)
>
> Over the next couple weeks, let's continue to hammer on
> http://groups.drupal.org/patch-spotlight and try and have some new
> exciting patches in for UNSTABLE-2. :)
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5281 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.drupal.org/pipermail/development/attachments/20081001/90917c23/attachment-0001.bin
More information about the development
mailing list