[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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]