JPMorgan Discovers Further Cyber Security Issues

> isn't it fairly easy to make it nearly impossible to find evidence that any particular piece of information has been compromised?

This is where digital forensics comes in. Just because an attacker has root or admin access doesn't mean all indicators of a compromise can be cleaned up.

A business like JPMorgan will have a large number of systems, with different segments of their data copied around, synchronized (sometimes poorly), partial data dumps to the marketing department, etc. I imagine that the systems containing sensitive data were better protected than the ones that are known to be compromised, with no known vector of attack from the compromised system to the one containing the information.

For example, at a small financial institution where I worked we had a mainframe doing the important financial calculations, and then we had a bunch more data in MySQL for doing reporting and analysis.

Theoretically yes, but practically no, especially if the breach is discovered within at least a few weeks of it happening. If you're looking at it 6 months later, it may be a different story.

There is security software which can restrict even root access to files. One such example is CA ControlMinder.

It can protect files/programs/processes at the kernel level and redirect authorization attempts through its own authorization engine and then back through the original syscall (if permitted). So, you shouldn't, but you could chmod a file to have world-read/world-write access and then set default access to the file to 'none' via this authorization engine and it would still be inaccessible to all users (even root).

You can form more granular controls, such as 'this file can only be accessed by the process launched by program with device/inode xx/yy', and 'this program cannot be launched if any of these 8 attribute checks show as being modified'..

By the same interception mechanism, auditing can be performed which records when specified files are accessed, by whom, and which server they had originally connected from when they did it. An audit only mode can simply monitor activity without performing any denials. Add in a keylogger that targets terminals of specific users, or just specific surrogate accounts (eg, when any user su's to root) and you can get a closer inspection of all activity performed (and not just activity to specific protected files/resources).

So, it's possible to tell what's been compromised, but one would need to be running such security software and have it properly configured for auditing the right resources. This isn't a trivial task to perform across environments with tens of thousands of servers.

That's what I meant (see the second sentence). The first sentence of my post was, however, originally missing a "not" (now added), so I see the confusion.