MHonArc v2.5.0b2 -->
legalxml-ms message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: OXCI documents
If the goal of the OXCI design is to just specify the functionality of
the EFSP to EFM communication, and leave network security, virus
checking, and webserver vulnerability protection to the implementers,
then I think the specifications should state that.
Reading over the OXCI documents, I am very concerned about the design
showing that the EFSPs will have direct access to the EFM server INSIDE
the court's internal network. This is in direct conflict with Network
Security Norms.
So, if the expectation or understanding of the reader of the OXCI
specifications is that the EFSP and/or public would in any way have
direct access to the EFM server INSIDE the court's network, then the
following are my concerns:
EFM Design Document:
1 - Even though there is a User ID and Password on the EFM server for
each EFSP, how will the EFSPs be able to communicate with that EFM
server? Exhibit I, in the EFM Software Requirements document, shows the
OXCI EFM server being located inside the court's network, behind the
firewall.
2 - The diagram shows the public and EFSPs being able to Q/R directly
to the CMS. This is also very dangerous. With what I am reading, the
public could launch mass Query/Response GETs, as a dDos denial of
service against the Production systems. Do we trust that all the EFSPs
and Attorney firms' systems will not inundate the EFM or Q/R servers?
Network Security Administrators are not going to let anyone on the
Internet come through the firewall(s), into the court's internal
network, unless via secure VPNs or other formal security structure.
There has to be something outside the firewall to handle the security.
Even if a Network Security Administrator or CIO accepts allowing
pre-defined EFSPs through the Firewall, they should require at a minimum
a list of EFSP IP addresses to authorize inside the firewall, either by
ACL or VPN, and then only to the EFM server itself.
This is still risky. For example: Imagine an EFSP's server with a
virus that scans for vulnerabilities on webservers, such as Nimda and
Code Red did. If their EFSP server is not heavily protected, and
updated for vulnerabilities daily, it could catch one of those network
scanning viruses, then scan to the IP address of the court's EFM server.
If the court's EFM server is not also heavily virus protected with
daily updates for all Windows or Apache Security Updates, it would
become infected by that EFSP. Once infected, that EFM server inside
your network would start scanning all servers inside your network.
Would this ever really happen? Yes. Last year I watched one of our
webservers receive thousands of vulnerability scans per minute as
unprotected servers at our ISP scanned and infected servers at 6 other
agencies. Fortunately our webservers were updated daily.
For the Goal that some people have of allowing any EFSP to Query the
EFiling Rules from Q/R, and start EFiling with the court, there would
need to be a Q/R and Front End EFM function out on the portion of the
network that those Internet users and EFSP's can access (Public DMZ).
Even with that stated, certain assumptions that data will just be
available may not prove to be available at time of implemenetation. For
example, if the specification states that anything pushes data inside
the firewalls from the outside Internet, Security Administrators will
not allow that. The specification should then state something to the
effect of Standard Internet Network security requires communication to
be initiated from INSIDE the network to items outside.
Please do not take these comments as a critique of the plan. I bring
these items up from a network design perspective, and because I would
hate to see roadblocks to implementation hinder all the work being
performed to build the specifications.
One Option:
When we set up our EFM server, we addressed these security items by
dividing the EFM function into 2 servers, EFM1 on the Public DMZ, and
EFM2 inside the court network, with the following configurations:
1 - The Internet facing Firewall has an ACL (Access Control List) which
limits access to EFM1 from the EFSP(s) that we allow to communicate with
it. That prevents the public from even touching the box.
2 - EFSP(s) transmit Filings to EFM1 via SOAP, WSDL, and MSMQ (for
messaging reliability).
3 - EFM1 queues all Filings sent from the EFSP and sends
acknowledgement back to EFSP of Filing Received.
4 - EFM2, inside the court's network, periodically initiates a PULL
from EFM1, to fetch and pending Filings inside the court's network.
5 - The Filing Envelope is extracted, the data is placed into a
database on EFM2, and the PDF attachments in the BLOB are placed into
folders on EFM2 for further processing.
Attached is a diagram showing a sample of what I am trying to explain.
Allen Jensen
Orange County Superior Court
Internet Development / EFiling
949.472.6946 Tel.
714.647.4805 Fax
All statements contained herein are the
statements of the individual user and do
not constitute or express the official opinion
of the Orange County Superior Court. In
addition, any statement contained herein
should not be taken as official legal advice
or ruling.
OXCI_Network_Security.pdf
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]