Security, compromised

Hi all,
We are having a problem, and I hope some of you may give me pointers on how to solve this :-)

A client of us, has an EXE (VB5) provided by us. This exe uses ODBC to connect to our SQL Servers.
Basically what they did is to gain access to our SQL servers, decrypt some stored procedures, and access directly to our sql servers to perform business operations. They are not doing 'bad' things, but they may bypass business validations that are being performed by our front end app. And basically, we do not want other people to access our servers.

Our application uses a generic user to connect to the sql server (with very restrictive permissions). Then, the fully authorised username and pass is retrieved from the db in an encrypted form and then the app reconnects with this user. This user, however, is not the dbo, and it cannot create stored procedures, access most of the tables, it may only use the stored procedures, which are encrypted.

We understand they used a sniffer to detect the fully operational user/pass used to connect to the SQL Servers. We used CAIN to reproduce this. The infrastructure guys installed a certificate in the SQL Server, so the connection is now encrypted. After this, CAIN can't tell us the user and pass any longer.

Now, I took cards into the matter, and I decided to attack our own systems to detect the flaws. First I used a debugger (WKTVBDE - found at http://exetools.com/debuggers.htm) and I could see what the exe was doing, and even though the certificate was installed and the connection was now encrypted, I could see the connection string while it was built. To solve this, I thought of some things. First, to compile the exe without Pseudo Code, directly to native. Second, I think I can encrypt the exe (though I didn't do this in the past, I think it shouldn't be that hard - any hints are welcomed). And third to store the strings encrypted in memory; this I don't know yet how to accomplish. I think that though all of these solutions may only delay their attempts to crack our system, these things must be done.

What I couldn't figure out so far is how to decrypt the stored procedures. We think they may have had access to some SQL Server with a dbo user. However, I want to be absolutely certain that without that kind of access they can not decrypt the stored procedures. I found a bunch of things on this, and here (http://www.sql-shield.com/decrypt-stored-procedure.html) I found a way to decrypt them, but I need sa access or 'create procedure' permissions.

Well... I think that's all. Btw, the SQL Server version is 2000 and most of our servers have SP4 installed.

Any and all the help is certainly welcomed.

Thanks guys!!

Hi yogurtu,

First of all welcome to AO.

1. For the connection string, make sure no passwords are *in* it.
2. For the stored procedure, you can implement your own extened stored procedure
(a dynamic link library actually)which could do a industrial strenght encrytion or decryption
using algorithms like RSA or DES.

Hi Warl0ck7,
Thanks for replying to my message, and for welcoming me to AO.
Both of your suggestions are great :)
I'll change the way it's currently connecting, I didn't know that the password may be sent other way than inside the connection string (we're using ODBC).

Also I didn't consider the possibility of having extended sps.

Once again, thank you :D

Actually if you wish to completely take everything to
the server i recommend you make a web interface instead of a VB application.
Any how for the problem in hand
the only solution is too ask the user for id and password, see
here.

This is a legacy application the company developed several years ago (in the Client Server era with two layers, fat client and stored procedures).

This issue came across our atention when we detected unauthorized people getting into our sql servers.

There are several problems, including the fact that we MUST let the users know the user + pwd to connect (otherwise we may not test the odbc data source). We have a very restricted user account for this, but the sole fact that the we give the login information (even with very limited permissions), allows the attacker to open a query analyzer and run scripts on the server. I saw an incredible amount of things that can be done, including port scanning, brute force attack to retrieve the sa pwd, buffer overflows (new vulnerabilities may arise), sql injection into system stored procedures or extended stored procedures, all of this, using the sql server's resources.

We determined we cannot avoid this at this moment.

To prevent the attacker from knowing a less restricted login, we installed a certificate at the server, so the connection string 'travels' the network encrypted, and decided to recompile to native (instead of PCODE), and to encrypt the exe file (see http://www.softpedia.com/get/Program...-Stealth.shtml) to prevent debugging.

We also decided to implement Intruders Detection, and how to react to intrussions. To this, I am new. I will have to research a lot on this.

After this, we are all commited to develop a new web based version.

Thanks a lot.

It is nice to see you have planned to shift over too web based solution. do take
a look at the following resources

www.sqlsecurity.com
www.oswap.org
of course www.google.com :rolleyes:

Quote:

---

Basically what they did is to gain access to our SQL servers, decrypt some stored procedures, and access directly to our sql servers to perform business operations.

---

Quote:

---

We understand they used a sniffer to detect the fully operational user/pass used to connect to the SQL Servers

---

Quote:

---

They are not doing 'bad' things, but they may bypass business validations that are being performed by our front end app

---

I shudder to think what you would actually describe as "bad things" :eek:

I presume that you have a contract with these people and that there is an AUP in force that has been agreed by you both??????

Have you consulted your corporate lawyers? Are your CEO and CFO aware of this? Is this activity even legal where you are?

This is totally unprofessional and unacceptable behaviour by a business partner. Is their CEO aware of what has been going on?

This isn't an issue of applications or database security, this is a matter of dealing with people you can trust. I presume that you have more than one client............well I can assure you that the others will not be impressed if you don't deal with this.

Just my view



;)

EDIT: To make myself a little clearer. You have customers who have employees.........perhaps these employees are not trustworthy? What they have done is unacceptable, but may well have been done without the knowledge and approval of their management.

They may well be attempting to defraud you, their employer, or both. I would strongly recommend that you escalate this within your organisation, as life is complicated enough without having to deal with people who obviously cannot be trusted.

This is not some little high school or college game with the students trying to outsmart the administrators. This is business...............there are standards to be observed.

Why do I have the horrible, horrible feeling that you aren't entirely aware of what these people are/have been doing?

If they could carry out their "business operations" after a valid login with your existing system why would they go to all the trouble they have in order to to so?

If they couldn't carry out those "business operations" did they _ever_ request the ability to do so through proper channels and if they did how did the proper channels respond?

People simply don't go through the amount of effort required to do what they have done for no reason. I can understand if they needed to do something that your system did not easily provide them and your company would not alter things - but then you would be aware of this partner's needs. It seems to me that you aren't and therefore it further seems to me that there is no pressing reason for this activity. That being the case this is malicious, probably criminal and I would block all access to your servers until further notice.

The issue here is the use of a two-tiered application.
Basically, the flaw here is that you're trusting your client application, which is by definition NOT thrustworthy.
This is much the same as trying to do web app validation in client side javascript.

Ultimately, I see two possibilities for you:
1- Implement some accountablitity in your system: drop the generic users and assign private database user accounts to all clients.

2- Make sure all validation logic in the client app is replicated in your stored procedures.

All efforts at securing the system at the client app layer is mear obfuscation and are bound to fail sooner or later. You will never be able to trust the client app since it runs on an untrusted machine and network.


Ammo

Quote:

---

I shudder to think what you would actually describe as "bad things" :eek:

---

Well... The sole fact that they are performing unauthorized actions in our servers is a bad thing... But they are not performing DOS attacks nor using our SPs to sell on behalf of inexistent agencies, etc... At least, not yet.

Quote:

---

I presume that you have a contract with these people and that there is an AUP in force that has been agreed by you both??????
Have you consulted your corporate lawyers? Are your CEO and CFO aware of this? Is this activity even legal where you are?
This is totally unprofessional and unacceptable behaviour by a business partner. Is their CEO aware of what has been going on?

---

Well, there is a commercial contract, but not AUP. After detection, our CEO consulted the lawyers and it was determined that this is an illegal intrusion, abuse of trust and probably violation of copyright. I agree this is totally unacceptable. Their CEO is aware of this, this is not just 'some of their guys'.

Quote:

---

This isn't an issue of applications or database security, this is a matter of dealing with people you can trust. I presume that you have more than one client............well I can assure you that the others will not be impressed if you don't deal with this.

---

Well... I agree that this is a matter of trust, or abuse of trust. However they did irrupt into our systems, they did capture information on how to connect to our servers, and they did decrypted our stored procedures (among other things). I am not in a position to defend legal matters for the firm. The only thing I can do is try to protect our servers, so they cannot do any of these things anymore.

Quote:

---

EDIT: To make myself a little clearer. You have customers who have employees.........perhaps these employees are not trustworthy? What they have done is unacceptable, but may well have been done without the knowledge and approval of their management.

---

As I said before, their management was aware of this, and presumably, they even engouraged these actions. Personally, I think that they were trying to put ourselves out of business.

Our management decided that it was better if we kept this quiet, so other clients don't think of our systems as 'not secure'.

I was asked to secure the systems, because if our managment decides to launch legal action, we have to be certain that we can defend ourselves from a full scale attack.

Thanks

Quote:

---

Why do I have the horrible, horrible feeling that you aren't entirely aware of what these people are/have been doing?

---

You just hit in the nail. We don't have an IT Security department. We detected them because they committed the error of asking the wrong questions, so made us wonder whay would they ask that, and we went through the logs, and found that they were using our systems in an unappropriate manner.

Quote:

---

If they could carry out their "business operations" after a valid login with your existing system why would they go to all the trouble they have in order to to so?

If they couldn't carry out those "business operations" did they _ever_ request the ability to do so through proper channels and if they did how did the proper channels respond?

---

Basically this is the scenario. We have EXE files distributed to every desktop, and a web interface. They have their own web interface, so they requested us to provide them with Web Services, which we did. They said these WS were not responsive enough. Unfortunately they were right; we had an array of problems (mostly connectivity and firewall issues) which ultimately led to unresponsiveness of our Web Services.

Quote:

---

People simply don't go through the amount of effort required to do what they have done for no reason. I can understand if they needed to do something that your system did not easily provide them and your company would not alter things - but then you would be aware of this partner's needs. It seems to me that you aren't and therefore it further seems to me that there is no pressing reason for this activity. That being the case this is malicious, probably criminal and I would block all access to your servers until further notice.

---

Well, they did presented complains about our services, and for some reason, everyone here was saying something like 'oh, this is not _my_ problem'; when I came across this thing, it was already burning, and they were already using our servers.

Since I was asked to 'solve' this, I was able to diagnose the problems and to perform corrective actions so our web services were up and running. Last friday near COB we received an email from them that stated that our web services were now reliable and they said the will use the proper channels from then on.

I myself don't trust them. I think that once they had the 'intention' of cracking our systems, they are not to be trusted, so I still have to think of ways of protect our systems, and I have to implement some Intrusion Detection System.

Also this was a very 'nice' warning that our systems are very insecure, and that we have to think seriously on how to secure our servers.

Thanks

Thank you yogurtu

I am very glad to hear all that. Please allow me to explain, I come from a finance and auditing background, so I do tend to "spit my dummy" when I hear of such goings on :D

Quote:

---

Our management decided that it was better if we kept this quiet, so other clients don't think of our systems as 'not secure'.

---

Yes, that was one of my concerns also. It is also a good idea to keep it quiet, as publicity may damage your case in court.

Quote:

---

I was asked to secure the systems, because if our managment decides to launch legal action, we have to be certain that we can defend ourselves from a full scale attack.

---

I agree; you need to do this anyway. It is not my area, but there are people on this forum who I am sure will be able to help you.

I will keep an eye on this thread and add any ideas I might have on "fringe security" such as audit and exception reports (transaction data), audit trails, control accounts and checks and balances.

I am sure that you appreciate that securing your computer systems is only a part of your corporate security model.

Good luck! :D

Quote:

---

The issue here is the use of a two-tiered application.
Basically, the flaw here is that you're trusting your client application, which is by definition NOT thrustworthy.
This is much the same as trying to do web app validation in client side javascript.

---

Yes, I tried to explain my self to management in terms of 'as long as the client runs an executable file, they would be able to see what the exe is doing, and the location of our db servers'.

Quote:

---

Ultimately, I see two possibilities for you:
1- Implement some accountablitity in your system: drop the generic users and assign private database user accounts to all clients.

---

Well, though this is a good idea, this would be very hard to do, because the application is installed in about 6000 workstations.

Quote:

---

2- Make sure all validation logic in the client app is replicated in your stored procedures.

---

This is the very first thing we tought of. We found that this is not doable in the short term. There is a huge amount of validations, and to do this we may spend several months. In that time we could complete the development of the new version.

Quote:

---

All efforts at securing the system at the client app layer is mear obfuscation and are bound to fail sooner or later. You will never be able to trust the client app since it runs on an untrusted machine and network.

---

I totally agree with you. For instance, we decided to use Exestealth (http://www.webtoolmaster.com/) to encrypt the exe. But, once they figure out how did we encrypt the file, they may locate this (http://www.cobans.net/unstealth.php) to decrypt it.

For us, the final solution is to develop the application entirely web based. We have decided to protect our systems the best we can in one or two weeks and then put all of our guns into the new development.

Thanks

Ouch.... You are in one of those touchy situations that is probably all controlled by your contract. This means you are somewhat between a rock and a hard place. You contracted to provide services, for whatever reason you failed to provide them as stated, they, (will tell you), used only authorized logins and passwords to gain access to the functionality they needed. See, because you had the secondary login packaged in an executable that you placed on their systems that login was authorized and was only placed there for their convenience.... ;) Any decent lawyer will make your position untenable and will probably actually shred your arguments in a courtroom.

I don't know the exact situation there between your company and the offending client but, were it an "appropriate" relationship I would seriously consider a meeting between yourself and the people that effected this "non-standard functionality improvement" ;) and see if between the two of you you can't help eachother... In the long run it may benefit both of you and it would certainly do wonders for the level of trust, (or lack of), between you right now.

Quote:

---

www.sqlsecurity.com

---

Great place!

Quote:

---

www.oswap.org

---

I couldn't get to this site.

I googled a lot, and I saw an awfull amount of things that may be done with a simple login. We cannot continue to provide everyone with the connection information (server + user + pwd). It is unacceptable from now on (I mean for the new versions).

We can't do much at this time. All we can do to provide a final solution is to build the web based app and once it is complete, the db servers will not be required to be public anymore.

Thanks heaps!

Thank you nihil!!

Quote:

---

I am sure that you appreciate that securing your computer systems is only a part of your corporate security model.

---

Well.... Er..... I will elevate this idea to management. I don't think that they are thorough on the security matters when designing the contracts. There is much space for improvement here, so your suggestions will surely have repercussions from now on.

Once again, thanks.

Thanks Tiger Shark,

Quote:

---

Ouch.... You are in one of those touchy situations that is probably all controlled by your contract. This means you are somewhat between a rock and a hard place. You contracted to provide services, for whatever reason you failed to provide them as stated, they, (will tell you), used only authorized logins and passwords to gain access to the functionality they needed. See, because you had the secondary login packaged in an executable that you placed on their systems that login was authorized and was only placed there for their convenience.... ;)

---

Well, yes! It is a very difficult situation, because unless we initiate legal action, we are bound to provide the service. We cannot just shut them down. Not unless we are in a position to defend ourselves legally and technically.

Quote:

---

Any decent lawyer will make your position untenable and will probably actually shred your arguments in a courtroom.

---

The law here is very incomplete in these matters. And trials lasts somewhere between 2 and 10 years. We don't want to go in there. One possiblity is to wait for the contract to end (I think that should happen sometime in the next three months).

Quote:

---

I don't know the exact situation there between your company and the offending client but, were it an "appropriate" relationship I would seriously consider a meeting between yourself and the people that effected this "non-standard functionality improvement" ;) and see if between the two of you you can't help eachother... In the long run it may benefit both of you and it would certainly do wonders for the level of trust, (or lack of), between you right now.

---

Well, we did, I wasn't invited to that meeting, but it was more like a 'show intention of good behaviour' thing. They had reasons to criticize our systems. I don't excuse their actions, but they had grounds to state that we were not providing responsive services.

Late last week, we solved the issues they complied about, and since last friday COB they said they would continue to use the proper channels. I don't know, because now I don't trust them. Anyway this is a reminder of the fact that our systems can be cracked, our servers can be accessed, and we are more vulnerable than what we would like to admit.

Thanks a lot.

Quote:

---

Well, we did, I wasn't invited to that meeting, but it was more like a 'show intention of good behaviour' thing.

---

I was referring to a geek-to-geek meeting not a fuzzybrained manager-to-fuzzybrained manager meeting..... They were thinking corporate liability, contract law etc. You need to glean what you can from their geek(s) that did this, (it wasn't one of the fuzzybrained managers - that's for sure), about how they did it and what else they did that you haven't seen. Ask for their advice and encourage their participation in assisting you in better securing your system packaged as your attempt to therefore better secure their data from others ;).

PS. You will need the OK from your top guy on this - do not do it on your own.... No telling what passes through those fuzzy brains when they smell lawyers in the water..... :rolleyes:

Thanks Tiger Shark,

Quote:

---

I was referring to a geek-to-geek meeting not a fuzzybrained manager-to-fuzzybrained manager meeting..... They were thinking corporate liability, contract law etc. You need to glean what you can from their geek(s) that did this, (it wasn't one of the fuzzybrained managers - that's for sure), about how they did it and what else they did that you haven't seen. Ask for their advice and encourage their participation in assisting you in better securing your system packaged as your attempt to therefore better secure their data from others ;).

PS. You will need the OK from your top guy on this - do not do it on your own.... No telling what passes through those fuzzy brains when they smell lawyers in the water..... :rolleyes:

---

Well, as our software has errors, so has our company :(
This is a very small company (less than 50 employees).
Formally, I hold a position of some importance here, but some things are not handled correctly. I am probably the most technically skilled (I'm not saying that I am that good, just around here), but my bosses think in a 'bossy manner' (sorry!). My direct boss has some technical knowledge, which makes this worst. He went to this meeting and he confronted the author of this, without having the possibility of arriving to conclussions (that we could not reach by our own), and without asking for his help. As a result of this meeting, reluctantly they agreed that they would collaborate in giving us more time to make our web services more reliable. This they did.

I will ask my boss to have a peer to peer meeting with the guy who did this. I don't think he'll agree, but I don't loose by trying.

I believe in making friends, not enemies, and in building alliances, not wars.

Thanks again!

I usually lurk but thought that a critical item has been overlooked. Were you able to determine what information has been accessed that shouldn't have been? Depending upon which state your company resides may dictate whether you may remain quiet about the breach of security or not. It is great you have taken steps to harden your systems but you should talk with legal about existing liability for the breach and verify that you are not in state or federal disclosure violation. Having a security breach is bad enough; being fined for not disclosing when appropriate is worse PR. If it was my personal information compromised, I would want to be notified SOONER that later. Nuff said, I'll go back to lurking now....

Hello Judgement!

Quote:

---

Were you able to determine what information has been accessed that shouldn't have been?

---

Yes we were. They did not accessed our SQL tables. They only used the proper stored procedures to perform their business operations. They did not perform any incorrect operations.
The thing was that they accessed directly our SQL Servers, without going through the proper channels.

Quote:

---

Depending upon which state your company resides may dictate whether you may remain quiet about the breach of security or not.

---

One of the things I learned from this thread was to also consider the legal aspects of the intrusion. So far, I had a very narrow vision of things, and I just saw only the technical aspects.

I don't know what the law says here about that, I will ask for legal advice.

Thanks!

Quote:

---

One of the things I learned from this thread was to also consider the legal aspects of the intrusion. So far, I had a very narrow vision of things, and I just saw only the technical aspects.

---

Disclaimer: I'm not a lawyer..... :D

If you are absolutely happy that the data tables have not been accessed other than those that the user(s) are authorized to and that the compromise of your system used only the proper stored procedures without altering their functionality in order to gain access to the data tables in a fashion that allowed them access to data they are not authorised to access then it is my understanding that none of the state laws regarding disclosure will apply. Why? Because that data has not been accessed outside your access controls therefore there is no compromised data. As long as you are sure of your facts this is almost certainly a perfect opportunity to keep quiet..... ;)

Hi all,
For all of you that are following this thread, I wanted to let you know what has been decided technically.

We are going to replace our executable files in all of the workstations, with the following modifications:
- It will be compiled to native (as opposed to P-Code).
- We will use sql server's application roles.
- We will eliminate generic users currently used to create and test ODBC connections. These connections will be created from the installer.
- The exe file will be encrypted with Exe stealth. This tool prevents the file from being debugged with softice and other tools. (I know this will only delay them, until they figure out how did we encrypt the file).

We are also begin a rudimentary Intrusion Detection System at the SQL Servers level:
- If any of our sql users login with the query analyzer, means intrusion.
- Any permission denied within the sql server means instrusion.
- We will detect brute force attacks to retrieve passwords.
- We will detect if a process is using the CPU at 100% for more than five minutes.
- We will give the application a key that if is not passed as optional parameter during operation, means intrusion.
- We still have people thinking in ways of detecting intrussion, so more things may be found.

That is all for now. And thank you all :)

Yogurtu

Snort has a nice set of MS-SQL IDS rules:-

Thanks Tiger Shark!

Quote:

---

Snort has a nice set of MS-SQL IDS rules:-

---

Because of ignorance, I thought that SNORT 'only' scanned network traffic, and I didn't consider implementing it.
Thanks to your suggestion we will study how to implement SNORT.

Once again, thanks a lot. :D

Unless you can implement Snort-Inline it does only "scan" - But, it Alerts you and logs too. There was the ability to "sort of drop" connections based on content but with the advent of Snort-Inline I seem to remember that the function has been dropped itself - but I could be wrong. The trouble with actually reacting to attacks is that the attacker can very easily DoS you by faking the sending IP address.

Quote:

---

Unless you can implement Snort-Inline it does only "scan" - But, it Alerts you and logs too

---

Well, first of all, please accept my apologies. English is my second language, and I didn't explain myself correctly.
I should have said 'I thought that SNORT scans only network traffic'. I didn't know it has the ability to scan SQL Server's activities. All I want is an IDS, and for what I have seen SNORT does that job quite well.
I stopped considering SNORT on the false knowledge that it didn't checked SQL Server's activities.
Now that you showed me that it does detect intrusion on the sql servers, I will do some research and try to implement it.

Once again, thank you :)

Cheers!

Hey, No problem... If you need any help with Snort PM me.... I use it a lot.

Mmm... the legal situation has been mentioned in a couple of threads.

The law varies widely according to the country you are in, and state-by-state in the US. However, one thing that you need to make sure is that you and your company are in the clear legally..

..for example, if confidential data was breached then you may be required to take further steps in law. Failure to do so may land you and your company in trouble. You need to keep in close contact with your legal advisor on this.

You also have to consider the balance between securing your systems against collecting evidence. If you want to determine the exact scope of the instrusion then you may well need to leave the door open to them. Again, take legal advice.

It does sound like your overall approach is good though - you need to look at the issue from a "whole business" perspective which is what you are doing.

Mmm... the legal situation has been mentioned in a couple of threads.

The law varies widely according to the country you are in, and state-by-state in the US. However, one thing that you need to make sure is that you and your company are in the clear legally..

..for example, if confidential data was breached then you may be required to take further steps in law. Failure to do so may land you and your company in trouble. You need to keep in close contact with your legal advisor on this.

You also have to consider the balance between securing your systems against collecting evidence. If you want to determine the exact scope of the instrusion then you may well need to leave the door open to them. Again, take legal advice.

It does sound like your overall approach is good though - you need to look at the issue from a "whole business" perspective which is what you are doing.

Hi Tiger,

Quote:

---

Hey, No problem... If you need any help with Snort PM me.... I use it a lot.

---

Thanks a lot :cool:
I will keep in touch.

Cheers

Hi Tiger,

Quote:

---

Hey, No problem... If you need any help with Snort PM me.... I use it a lot.

---

Thanks a lot :cool:
I will keep in touch.

Cheers

Hello Dynamoo!

Quote:

---

It does sound like your overall approach is good though - you need to look at the issue from a "whole business" perspective which is what you are doing.

---

The latest news I received on this, was that we were being advised by a very strong law firm in the IT area. I heard they were going to collect evidence of the intrusion. This I don't know if they actually did it, but I think they should have done it by the time I write this.

As I mentioned before, the intruders did not gain access to system tables. All they did is figure out how to call our stored procedures, with proper parameters to perform their business operations. They could (but they didn't) stop performing some validations that our front end apps do. However we cannot allow them anymore to do this. Also, there is some economical interest on our side, because if they don't use our front ends, they are not required to pay for some licenses.

They did show us that there is a big open door to enter our systems. Some malicious people may get in, and that would be a disaster.

Personally, I did enlarge my vision, because, when I was first assigned to this, I looked only at the technical aspects. Now everything must be balanced, and the most important things for us are to continue to operate, not to loose any customers, secure our systems, implement intrusion detection systems, and always be in the clear legally. Only that! lol :D

Thank you!

Hello Dynamoo!

Quote:

---

It does sound like your overall approach is good though - you need to look at the issue from a "whole business" perspective which is what you are doing.

---

The latest news I received on this, was that we were being advised by a very strong law firm in the IT area. I heard they were going to collect evidence of the intrusion. This I don't know if they actually did it, but I think they should have done it by the time I write this.

As I mentioned before, the intruders did not gain access to system tables. All they did is figure out how to call our stored procedures, with proper parameters to perform their business operations. They could (but they didn't) stop performing some validations that our front end apps do. However we cannot allow them anymore to do this. Also, there is some economical interest on our side, because if they don't use our front ends, they are not required to pay for some licenses.

They did show us that there is a big open door to enter our systems. Some malicious people may get in, and that would be a disaster.

Personally, I did enlarge my vision, because, when I was first assigned to this, I looked only at the technical aspects. Now everything must be balanced, and the most important things for us are to continue to operate, not to loose any customers, secure our systems, implement intrusion detection systems, and always be in the clear legally. Only that! lol :D

Thank you!