Best practice to depoly a MS-DOS application over an MPLS WAN

By doncordaro ·
What security conserns should I have deploying a MS-DOS application in Citrix XEN6 on a MPLS WAN over 23 sites?

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Answers

Collapse -

You can probably answer that better than us

by robo_dev In reply to Best practice to depoly a ...

What does this application do? Is it a game, a bank wire transfer application, a database which holds the nuclear launch codes?

Who uses your network? Is your WAN open to the public, used to host the DEFCON hacking convention, or are there a bunch of poorly paid accountants using it?

Your network architecture: Do you have a firewall, perform some network monitoring, or perhaps require users to login to get access?

Collapse -

Reponse To Answer

by doncordaro In reply to You can probably answer t ...

We are moving off a .NET Oracle based platform. My concern is application performance and database security of a MS-DOS based system.
The MS-DOS application suite built on a 32bit Pervasive database will be a mission critical set of programs that will be the back bone of our company. All import, export and supply chain transactions will be entered and retrieved from it. We have a Citrix Farm s and a 32TB SAN.
The programs will be accessed by 315 users over 23 remote locations via a MPLS network. Each location has a T1 and locations with more than 40 users have a T3(bonded T1) line. The Central data center has a full DS3 data line. Each location has an ASA Firewall

Collapse -

Excellent, so here are my four cents worth

by robo_dev In reply to Best practice to depoly a ...

So let me get this straight, you are moving FROM a .net/oracle solution to a DOS-based solution? Interesting. Be that as it may, let's begin:

Security: Validating the security controls of an application like this is not all that difficult. The key is to understand what threats you are defending against and what assets you are protecting.

Some of the questions I would ask would be:
a) what are the real risks/costs of a system compromise? Downtime, theft of company data, financial fraud?
b) what/who are you defending against?
c) what authentication methods are being used?
d) Are the features and capabilities related to authentication something that is off-the-shelf, or something your programmers wrote?
e) database security is the same regardless of platform, it's mostly a matter of using a hardening checklist, like you would with any server or application. And you make sure you are logging what is important, obviously.

In the past, I've done a lot of work in this area.
The best approach, if you have the time/money, is to do some network simulation/modeling using the QA/Test envionment for the application.

In the past, I've used hardware network latency simulators to give you the 'magic number' which is the most latency the application and/or users will tolerate. So, for example, if you setup a test lab with ten simulated users, using a testing tool like Microfocus QA Load, you start firing off transactions, then start cranking the latency up and up to see where things get nasty.

At the same time, using tool such as WireShark, you can get some understanding of how the application uses (or misuses) the network. By doing network protocol analysis, you answer the questions "what the network does to the app, and what the app does to the network". This testing will show you some flaws, such as unencrypted passwords, or maybe stupid stuff like apps doing SQL queries over the network.

Once you have a good idea of the amount of latency the app will tolerate, and the amount of bandwidth it uses, then you extrapolate that data against your network design.

For example, I worked once on base-lining the performance for an ERP system. The end users were vehicle-mounted (forklift) users in France, and the SAP database queries had to hit a database in the US. With some testing, we determined that the app simply would not work as-written, as the best we could do on undersea fiber was around 90-110ms, regardless of system load. So the developers had to make some changes to create local data stores. Using the latency simulator in the test lab, we were able to validate that the revised app could not only tolerate more than 110 ms of latency, but it could really go off-line and recover.

Collapse -

Reponse To Answer

by doncordaro In reply to Excellent, so here are my ...

Thank you for your fast reply. I will take your advice and perform a network load testing. The database is a flat file and has 777 permissions on it. During a test session one of the data files was deleted and we could not find out what happed to it. The authors do not have an audit mechanism built into the system.

Collapse -

Oh wait, Pervasive bought Btrieve :)

by robo_dev In reply to Best practice to depoly a ...

So really, is what you're looking at simply one huge Btrieve database?

Good old Btrieve; I worked for a company which used Btrieve for it's email system; over 100K people, all in a big flat file. This was back in the early 90s, before Notes and Outlook were scalable enough for a large enterprise.

I hate to sound cynical, but Citrix is a way to bolt-on performance and security to an app with performance and security issues. To me that's a red-flag that the core system architecture is not ideal. Citrix is a way to make an application that won't work as a client-server app, walk and talk like a client-server app.

I assume that you are not the one who selected this, but the one tasked with making it work?

Collapse -

Reponse To Answer

by doncordaro In reply to Oh wait, Pervasive bought ...

Yes I was not on board from the day the system was emonstrated, no technical person in their right mind would deploy 1980's technology in 2011. I told the CEO deploying this system would be the same as buying a new telephone system and using rotary dial equipment. I was told that technology does not matter, the application is what we need to use and you must make it work.

Collapse -


by oldbaritone In reply to Best practice to depoly a ...

this wouldn't happen to be an order-picking system for storage carousels and RF terminals?

I parted ways with a supplier of one of those systems, originally written in DOS, then changed to "run on Windows" (in a DOS box)...

He used Btrieve 6.x database because he had bought an unlimited engine distribution license for that version, and never wanted to spend the money for a dbe. It was really ridiculous, because the software sold for over $20K/station, and all he needed to do was specify what database engine the customer needed, and tell the customer to buy the seats. (MS-SQL would have been an obvious choice...)

But he wanted ALL of the money, and 21st-century purchasers were being sold 1980's technology as new.

I walked away.

Collapse - RUN

by don.w.cole In reply to Best practice to depoly a ...

You are in deep doodoo

Related Discussions

Related Forums