Re: E-Signatures

[Sarah Stevens <sarah () STEVENS-TECHNOLOGIES COM>]

Mr. Paez,
 
Thank you for the reply.  Very interesting perspective that you present.  However, I have a dissenting opinion.  Anyone 
whom knows me also knows that I always enjoy a great debate.  With that in mind, I would argue that a properly managed 
risk-based approach to information security covers not only compliance, but also security.  Compliance laws provide 
incentive to investigate appropriate solutions to information security issues.  Regulations drive corporations, 
academia, and government organizations to respond to the threats that you speak about.  Effective information security 
initiates at the top of an organization and flows down.  I don't believe that any of the guidance that I recommend 
(i.e. NIST 800-53) says that you must implement a specific technology or even deal with a threat in a specific manner.  
Rather, the purpose of compliance is to be prepared with a plan for the challenges that your organization could face.  
For the "major threat event" that you reference below, an organization that had implemented compliance driven policy 
and procedure correctly would have an immediate action plan to respond to the incident (NIST 800-53 IR-1).  Key team 
members would have been identified and trained in their response (IR-2, IR-3), key evidence would be preserved and 
individuals that need to know about the incident would quickly be involved in resolution (IR-4, IR-5, IR-6).
 
However, the organization that has ignored compliance, and complained that auditors are finding problems on legacy 
systems may not respond to legacy system vulnerabilities and could end up with a "major threat event" as a result of 
complaining instead of complying.  In addition to helping with compliance, our organization has had to gather evidence, 
testify, and report on incidents.  Believe me, I would much rather see a complete risk-based information system 
security plan that considers each regulation as an additional risk than deal with the disaster of cleaning up after a 
major threat event.
 
We describe the risk of threat impacts in accordance with FIPS 199, namely as:  "The level of adverse effect on 
organizational operations, assets, or individuals that the loss of confidentiality, integrity, or availability" could 
cause.  For the example of incident response, I may develop the following analysis:
 
"IR-1:  The organization develops, disseminates, and periodically reviews/updates: (i) a formal, documented, incident 
response policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among 
organizational entities, and compliance; and (ii) formal, documented procedures to facilitate the implementation of the 
incident response policy and associated incident response controls."
 
Risk:  If an incident occurs without a plan in place, individuals may not know how to respond to an incident.
 
Impact:  Organizational assets could be destroyed and may not be able to be recovered.
             Organizational operations may not be able to continue due to compromised data, system unavailability, and 
the confidence of the public.
             Funding for program could be lost due to loss of integrity of the organization.
             Key data that must be kept for investigational purposes by law enforcement personnel could be lost.
 
Level of Impact:  Based upon how serious the consequences of some of the identified impacts (listed above) would be to 
the particular information system being reviewed.
 
In conclusion, a proper risk-based approach to compliance with information security objectives considers laws, 
regulations, threats, and vulnerabilities unique to the environment of the system in question.
 
Respectfully,
 
Sarah Stevens
President
Stevens Technologies, Inc.
 
 

________________________________

From: Ozzie Paez [mailto:ozpaez () SPRYNET COM]
Sent: Fri 1/11/2008 10:22 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] E-Signatures



Sara,
This is very interesting and timely, given the challenging and too often
frustrating environment out there.  One thing for all to remember is that
compliance does not equal security, something often lost on companies after
they spend a great deal of money on regulation driven security compliance.
Just consider that regulations generally change slowly and incrementally,
while new security threats can quickly manifest themselves, evolve and
change their threat profile based on organizational and technology changes.
I have been involved in more than one case where compliance was assumed to
take care of the underlying need, i.e. quality, security, privacy, etc.,
only to have a major threat event compromise an aspect of a regulated
process and ultimately bring the wrath of the regulators.  My experience has
been that those who manage most organizations have such different
backgrounds from us who deal with threats, that they are often at a
disadvantage trying to appreciate these nuances.  But then again, the people
component is always the most challenging link in the chain.

Warm regards,

Ozzie Paez
SSE/CISSP
SDS
303-332-5363

-----Original Message-----
From: Sarah Stevens [mailto:sarah () STEVENS-TECHNOLOGIES COM]
Sent: Thursday, January 10, 2008 11:07 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] E-Signatures


As a company, we do a lot of 21 CFR Part 11 compliance.  21 CFR Part 11
requires organizations that submit electronic signatures to the FDA to meet
certain requirements.  Pharmaceutical research entities (or any other
entity) are subject to the regulation only when electronic signatures are
submitted to the FDA.  Many labs and research institutions are now asking
software vendors to ensure that appropriate controls are available within
COTS software solutions to allow for 21 CFR Part 11 compliance.  What is
very interesting about this regulation is that most of the requirements of
the regulation are in regards to information security controls protecting
the systems that store and transmit electronic signatures, rather than the
"E-Signature" itself, thus research labs must ultimately protect their
information system environments.  (Sound familiar with other high profile
legislation?)

I won't get on my infamous soapbox about managing all regulations in respect
to a properly instituted risk management plan, but that is how we approach
compliance.  Many of our customers whom must be 21 CFR Part 11 compliant
have already been through FISMA, HIPAA, FERPA, SOX, or other such
documentation exercises.  Thus, when we start to review how to handle
compliance with yet another regulation, we take a risk-based approach.  We
assess which information security controls are already in place on the
systems storing the Electronic Signatures.  From this assessment, we
recommend further controls, or refer to the previous regulation
documentation to prove compliance.  Incidentally, NIST 800 series is a
TERRIFIC place to start for 21 CFR Part 11 compliance.  We actually took the
time to take each of the major components of 21 CFR Part 11 compliance and
map it to the appropriate NIST 800-53 control to show compliance for
organizations that already had C&A packages assembled for the systems
processing E-Signatures.  This was a really neat exercise and an eye opener
for some because labs have not been submitting information electronically in
order to avoid this regulation.  Now, as more and more labs are becoming
compliant with more high profile legislation, they are extending their
compliance to systems housing electronic signatures for submittal to the
FDA.

Anyway, very interesting topic and a lot of fun to look at!

Sarah Stevens
President
Stevens Technologies, Inc.

  _____ 

From: Faith Mcgrath [mailto:faith.mcgrath () YALE EDU]
Sent: Thu 1/10/2008 2:09 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] E-Signatures



I am also interested in what people are using for electronic signatures
if they need to certify that they are in compliance with FDA Electronic
Records; Electronic Signatures regs -- 21 CFR Part 11
( http://www.fda.gov/ora/compliance_ref/part11/
<http://www.fda.gov/ora/compliance_ref/part11/> ). I am just being to do
some background reading on the requirements, but we are beginning to see
this requirement related to pharmaceutical research protocols. Thanks. -fm

Harrold Ahole wrote:
> > Is anyone doing any work with e-signatures within their applications?
> > I'm not talking about crypto-based digital signatures.  Rather, we
> > need something that is the equivalent of someone signing a piece of
> > paper to attest that the contents are correct.  Some applications
> > we've seen just have something like "type your name in this field to
> > sign this form".  A campus customer is looking for something more
> > comprehensive than that.  What are other people doing short of
> > implementing PKI or using login credentials as a signature?
>
> Well, the first thing to decide is what you want to accomplish.  The US
> Esign law allows "type your name" as a form of electronic signature
> simply because it's very natural to show consent (willful action).
> The first consideration is how do you authenticate the user at the time
> they take this action?  Depending on the application, it could be very
> little, such as if they are requesting the purchase of a transcript, in
> which authentication may not be too high provided they also pay by
> credit card.  If the user is logged into a campus application, you can
> certainly use that as a credential for authentication.
>
> The next consideration is to create a reliable electronic record, one
> that can be shared with all parties involved.  This is typically done
> with digital signatures, but of course other methods are likely
> acceptable if they can be shown to reflect the agreed upon document and
> are stored in a manner suitable to show non-modifiable archived storage
> (such as when paper docs are scanned to microfilm, it's generally
> assumed that the microfilm version is accurate as it's hard to tamper
> with).
>
> Harry


--
Faith McGrath, Associate Director
Yale University ITS - Information Security
faith.mcgrath () yale edu
voice: 203.737.4087 telefax: 203.737.2859
security () yale edu || security.yale.edu

Please be aware that email communication can be intercepted in
transmission or misdirected. Please consider communicating any sensitive
information by telephone, fax or mail. The information contained in this
message may be privileged and confidential. If you are NOT the intended
recipient, please notify the sender immediately and destroy this
message. If you wish to confirm the content of this message and/or the
identity of the sender please contact me at the phone number given above.