legalxml-courtfiling — archive

Re: [legalxml-courtfiling] EFiling Process Models Subcommittee

From: Allen Jensen
To: [email protected]
Date: Tue, 31 Dec 2002 18:31:00 -0000

MHonArc v2.5.2 -->

legalxml-courtfiling message

Subject: Re: [legalxml-courtfiling] EFiling Process Models Subcommittee

From: Allen Jensen <[email protected]>
To: [email protected], [email protected]
Date: Tue, 31 Dec 2002 15:28:17 -0800

Also.....  EMails are perceived to be secure by many, but in reality,
email can be read depending on whose email server it may be being passed
through.  Trusting EFilings with confidential data to non-encrypted
email should be avoided.  



Allen Jensen
Orange County Superior Court
Internet Development / EFiling
949.472.6946



>>> Dallas Powell <[email protected]> 12/31/02 03:14PM >>>
Here are some thoughts that were generated as I read several threads
such as
the DOS comments....

A denial of service attack can take place on an e-mail address just as
it
can take place on any IP address.  In fact the danger of using an
e-mail
address for an e-filing method is that the email server is frequently
a
central component of other court business and an attack on a central
email
server could hurt other areas of the court.  Also, the e-mail system
generally does not have a sophisticated design that allows the
e-filing
system to deal with hundreds of e-filings being received with 100 Meg
files
attached in a hours time frame.  Just think, 10 filings a minute with
100
Meg files attachments, in one hour, means 600 filings with 60 Gig of
disk
space consumed.  That does not even look like an attack from an e-mail
or an
IP address perspective but could bring a system to a halt.   An
e-filing
system needs to be isolated from other businesses of the court, either
as a
web server or as an isolated e-mail server.

The only way you can stop an attack is to not tell anyone about the IP
address, but that makes no sense.  The best way to defend against an
attack
is to put into place a security model for the EFM which quickly filters
the
bogus filings from the real filings.  The philosophy we support in our
implementation is to prepare for the attack, and stop the unwanted
postings
as fast as possible... the first thing.  The deeper you allow bogus
filings
to enter into your e-filing system the more damage you incur.  We
support
the idea that security is the most critical aspect of an EFM.  Just
think,
if an attacker wanted to be smart he would create valid CourtFiling
1.1
packets, possibly vary the information, and send them.   If the EFM
only
checked to see if the filing validated against a DTD then the bogus
filing
will pass level one of security checking.  Now suppose that you wanted
to
use the attorney's bar number as a second check.  Well, since those
bar
numbers are public information in many states, it will not be a problem
for
a hacker to insert valid information in that field.  And what about
credit
card information... is that a valid security check,,,  no!  There is
nothing
in the current DTD that supports any form of authenticating the
submission.

Can you imagine having thousands of cases submitted each day that
passed the
DTD validation, Bar No., and credit card check.  How soon would it take
for
a Court to shut down when thousands of cases are being entered into a
CMS
each day?  And there is no way a court clerk can afford to research out
each
filing to see if the information is valid because the information in
the
filing represents valid people, it just came from the wrong source.  
The
Court would begin to shut down before the web server even realizes
there is
an attack going on.  A new concept in attack, hide what you are doing
so
that the court you are attacking cannot tell you are attacking.

Now to increase the complexity of the problem, we want an open system
so
that anyone can create software to submit filings.   That is the
concept
between the EFSP and the EFM.  If you only allow one or two EFSP
installations to submit filings then you could use a firewall or a VPN
for
securing who the submissions come from.  In this case a court would
probably
create a contract relationship between a few EFSP installations, and
each
EFSP would be held liable to insure that all users of their system
were
authentic and that the EFSP was responsible for any bogus filings.  But
then
that would not be a very open system.  To me that seems a bit closed! 
More
like very closed, and it forces all attorneys to pay a few EFSP
installations a ransom if they want to file electronically to a court.
(This is a great business model for an EFSP but not very good for an
attorney or other filers.)  Personally I don't think that this is what
an
open standard is about.

To me, the concept of an Open Standard, makes it possible for numerous
EFSP
installations, hundreds or thousands to exist.  This means firewalls
and
VPNs are unrealistic methods of identifying unauthorized submissions.
Firewalls are still needed to protect internal processes and network
security from externally exposed processes, but they do not readily
support
the authentication of submissions that may come from hundreds or
thousands
of installations, especially where there is continuous address changes.
 It
is my impression that the Open Source Code projects have either adopted
the
concept of only a few EFSP installations and use an firewall for
security,
or they have not addressed the security risks.

We struggled in our implementation and design with this very issue. 
For
Utah, in addition to the EFSP service installed at the courts where
all
attorneys to use the service at no cost, Utah also mandated that any
attorney, or other organization such as the attorney general, Dept. of
Corrections, Human Services, etc, that wants to write software to
communicate to the EFM can do so.

---(Note of historical experience from Utah: We have found that for
high
volume filers the idea of installing software at their site allows them
to
automate their internal processes. This is very attractive to them, and
we
anticipate that more filings will come from this type of installation
than
through an attorney logging into an EFSP on the web. As you begin to
evaluate who files and what they file, you will find that frequently a
handful of attorneys file 80% of a given type of filing. For example,
one
attorney can represent a collection agency and initiate 300 to 700
cases per
month. In Utah we identified about 10 attorneys that behave this way.
When
you consider the additional default judgements, and post judgement
remedies
these 10 attorneys file, that accounts on an average of ... 500 cases x
10
attorneys x 12 months + 1000 follow-up filings x 10 attorneys x 12
months
equals 180,000 unique filings per year from 10 attorneys just for one
type
of civil case. If the number of filings is significant it is worth the
money
for an external organization to implement software to automate their
processes.

Utah has implemented more than 5 unique electronic filing solutions.
One
solution allowed the Office of Recovery Services to file documents
electronically to them, but it did not automate the CMS or DMS.
Another
solution was unique to the Tax Commission. Another unique solution was
totally web based, but they found this was too difficult to scale, and
complex cases were even more difficult to support. Another unique
solution
was built for one attorney who filed 500 filings per month for a large
hospital chain. He automated his process and the courts automated
their
process of initiating their CMS.  It used e-mail, and CourtFiling 1.0. 
This
solution updated the CMS but not the DMS. They found that they had no
security model, and the system was not something that other attorneys
or
organizations could readily adopt. In addition, this last system for
the
attorney required follow-up paper work and a special payment process.
)-----


So, how do you publish a security model to the open public that
communicates
to the EFM, and at the same time, when each party writes code to meet
the
security model it does not jeopardized in any way the ability of the
EFM to
recognize and authenticated source or submission from unauthenticated
source
or submissions? That is exactly what we had to deal with.

Now introduce the issues of interoperability...   If you look at the
levels
of interoperability we originally proposed, they go from the easiest to
the
most difficult.   Remember there were 5 proposed levels,

1) Basic validation
2) Communication layer ( protocol and hand shaking)
3) Required elements for case initiation and case updates
4) Required elements for filing fees
5) Security Model

In the Las Vegas meeting rather than just adopting the
interoperability
document that was submitted we reviewed it and before we finished with
level
1 and 2 (which were collapsed together in the document) we found that
there
were many issues that we felt needed more attention.  In light of our
new
EFiling Process Model Subcommittee we could see that we need to begin
to
define models and processes before interoperability could be defined
for
each process.

So, to wrap up, it is my feeling that we often talk in general terms
about
processes and interoperability and skim over the details of how it
might
actually function in a specific business model, or under a given
interoperability level.   As we mature the EFiling Process Models and
the
Layered Interoperability working groups we will develop better methods
to
discuss with more clarity how a process interacts with other processes.
We
have worked too long in general terms and must begin to create a
structure
that helps us in our discussions.  Define business models, define
processes,
and describe how they work within each business model and how they
effect
each level of interoperability.

As I began to approach the description for the statement of work for
the
Layered Interoperability subcommittee, I anticipate there are two
parts, one
is a living document which will be used to collect definitions of
interoperability based on various business models, and then a specific
document that creates a statement of interoperability for CourtFiling
1.1.
In Las Vegas we began to recognize that there was not sufficient
information
in the current concepts of LegalXML architecture to define
interoperability.
I solicit any input on the topic of interoperability and promote
Dwight's
request for participants to describe various business models and
process
definitions.  Then as we begin to discuss issues we can point to
specific
models, and levels of interoperability and make better decisions and
standards.

Dallas