I'm a very security conscious (bordering paranoia) freelance web developer and I place a lot of emphasis on security with my clients, alas I've found this doesn't seem to be the case for the average web developer.

Something that's been bothering me lately is the thought that the people I usually hand projects over to most likely wouldn't notice if the server got compromised unless the attackers defaced something or did some other "LOOK AT ME!" gesture. But if the attackers quietly snuck in and out, nabbing all customer data they'd be none the wiser. So, my question is are there ways to detect if customer data has been leaked whilst no longer being involved in the project? (no IDS, access to logs etc.)

What I've done so far is placed orders on a few of these sites with unique strings in the address and order note fields, and used a separate e-mail address – I've set up Google Alerts to search for these unique strings and e-mail address.

5 Answers
5

Monitoring for records from the DB to be posted are really all you can do without direct access to the server. You could try penetration testing the site yourself to look for holes, but that is probably unwise and possibly illegal depending on jurisdiction and the Terms of Use of the site and any contractual obligations you might have from when you wrote it.

If you are really concerned, you could simply ask permission to do periodic penetration testing on the sites of former clients to help ensure their sites remain secure. If you find a vulnerability being exposed on one of them, you could then report it to them so they could either fix it or have you come in to fix it.

While I haven't done it - haven't been contracting as much as I used to - I was planning to get a bunch of small $25 - $50 prepaid visa cards and use them on sites I was involved with. One card per site.

Keep the card number and if it gets used you know with reasonable certainty that there has been a breach on their system.

Those cards typically expire after a year or two (I believe), so this might work in the short term, but you might need to keep repeating it every year or two. That might make this a bit of a pain.
–
D.W.Mar 22 '13 at 10:15

@D.W. - I saw a three year term for one of the vendors I looked at. Thought about actually marketing doing this as a support feature with a 1, 2, or 3 year term.
–
Tim BrighamMar 22 '13 at 11:15

You need to have a few things set up in advance to detect data exfiltration.

Firewall egress filtering

Netflow/snmp bandwidth monitoring

Log monitoring

The log monitoring is particularly important because your firewall and potentially netflow as well will log traffic. Has there been a lot of traffic to a particular url from a particular IP? Maybe they are draining out info via sql injection or trying to. Did someone try to copy data out to some external machine on port 22? Egress filtering will catch/block that. Did you end up having port 53 udp open for whatever reason and having found scp blocked they tunneled out over that port? Massive traffic over udp 53 will be picked up by netflow. This is all part of simply keeping an eye on your network.

OK. Sometimes feeling too safe is other side of the coin. A little paranoia is not actually a bad thing.

Coming to your question, if I was in your place i would take the following steps to reduce the level of risk:-

Do a 'need analysis' for a *Data Loss Prevention*considering its not the webapp front end users who have access to the data, but privilege users who can abuse the trust can leak sensitive / private info of individuals. Based upon Data Loss Prevention. Excerpt says:-

..."detective control alone is not sufficient. While detective control
would provide visibility, preventive control is a necessity to lessen
data leaks by both accidentally and intentionally."

Identify controls ; keeping in view the basic principal that any control either detective or corrective should be built with the concept of 'prevention'.E.g a detective control that is smart enough to quickly detect the wrong doing and sms the administrator as it happens. Consider use of integrity checking software such as tripwire or ossec.

Define strict access control policy to limit to abuse or attack surface of the attackers.

Perform manual code reviews or through use of automated code testing tools like appscan perform dynamic analysis of code as well. Necessary checks and balances should be applied that detects unauthorized access , exceptions and logs forensic related fields for law enforcement. Also at code level you can check for integrity through operational controls such as input / output controls.

The CGI and underlying application is also subject to input attacks. They are subject to HTML Malicious Tags if they rewrite web
pages based in user input and to the variants (cross-site scripting,
buffer overflows and shell attacks) if they do not have adequate input
controls.

The most commonly cited examples of CGI security breaches involve
manipulating a shell program into performing something unexpected. The
form below lets a user e-mail a message to a specified person. For
example, the HTML form page below:

The next step in the process is to execute a script that writes the
message to a temporary file and then e-mails that file to the selected
address. In Perl, this could be done with the command:

System("/usr/lib/sendmail -t $send_to < $temp_file");

As long as the user selects from the addresses that are given,
everything will work fine. There is however no way to be sure. Because
the HTML form itself has been transferred to the user's client
machine, it can be edited to read:

As soon as this is sent, the original sendmail call will stop at the
semicolon, and the system will execute the next command. The next
command would mail the password file to the user, who could then
decrypt it and use it to gain login access to the server.

SANS strategy on detecting such attacks

This attack(input controls) is unfortunately immune to signature based network intrusion detection systems (IDS) because it looks like normal web surfing traffic.

Host based IDS may be able to detect this attack
using application error logs, developing signatures for these logs would be an interesting project.

Once again asadz - how does this answer the question "How would you detect whether customer data has been leaked?"
–
Rory Alsop♦Mar 20 '13 at 0:23

@RoryAlsop How does it not relates to the question in hand? A quick answer on how is what i call something as experience; i work in the organization which deals with this issue on daily basis. Its how we do it and its how it should be done. The organization I speak of handles not just the data of all country telcos users but also the entire population of my country. There is no silver bullet, its the 360 perspective what is required, you can lower the horizontals growth but the verticals (all 7 are pretty much the same)Have you looked at option (2) it specifically deals with the issue in hand.
–
SaladinMar 20 '13 at 5:28

@RoryAlsop as an authoritative source on this topic let me bring ISC(2) over ; it said in its CISSP manual related to 'access control' all security controls should be built with the concept of preventive security
–
SaladinMar 20 '13 at 5:31

This is where i tried NOT to emphasize on the just single dimension but controls like access control that can perform prevention as well. Detection alone is not enough therefore, all three types(detective,corrective and preventive work together) You are right I can stick to exact words which is related to 'detection' but the words has far reaching implications and should not be analyzed in isolation.
–
SaladinMar 20 '13 at 5:42

the point (4) of my points is related in a way that for a sensitive application , necessary checks and balances should be applied that detects unauthorized access , exceptions and logs forensic related fields for law enforcement. Also at code level you can check for integrity through operational controls such as input / output controls.
–
SaladinMar 20 '13 at 6:05

Searching for some of the data stored in the database is the easier way to detect a data leak. You can also search for events caused by the data leak (some transactions in a credit card, or some email receiving spam, for example).

To make this easier, you can:

Add dummy records to the database. You can tag them (or not) as fake so the application doesn't use them. They can be created by the application or they can be entered manually. They can be a few or a lot.

Watermark the records in the database. Adding or changing some data on some (or all) records (real or fake) regularly (for example, weekly), so that if you discover a record in the wild, you'll know when happened.

For exporting operations (if your application includes export or backup functions or even full-listing reports) you can add fingerprints to the data. Those are one-time items (strings added to some columns, whole columns or whole records) added on-the-fly for that user only for that time only, so that you can discover a traitor (a legitimate user with access to the data who then leaked it).

For example, let's say your application creates a dummy record per-thousand of real records, and each record has an email address. Also, your application appends a fake surname to random records using a list of fake surnames (Obviously your application should ignore them when found at the expected string position). To simplify, let's say you have a bunch of domains with catch-all email accounts. Your application changes the email addresses of those dummy records monthly, using your domains. You monitor those email addresses and you do automated web searches to find the content of those dummy records. If you find the names and email addresses on the web or receive spam in any of those addresses, you'll know the data has been leaked.

(You should be really careful when using a search engine if you feed real customers/patient/whatever data, as you may be breaching some privacy laws, but if the data is fake, or real but yours then it's ok).

If you have enough resources, you can also request real credit/debit cards, include them in your dummy records and then monitor any activity on them.

This is for detecting a full data breach (the attacker have the whole database).

For smaller data leaks (from some employee getting some information from some records) the solution would be different. Adding the fingerprints to the data would be more useful.

Personally, I have implemented the fingerprinting for several applications (as there were multiple administrators, all having access to the whole database from the application), and adding dummy records to a couple of applications with customer data (however I don't do the monitoring, I hope my clients are doing it).