Security, compromised

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.