Slashdot Mirror
DSS/HIPPA/SOX Unalterable Audit Logs?
analogrithems writes "Recently I was asked by one of the suits in my company to come up with a method to comply with the new PCI DSS policy that requires companies to have write once, read many logs. In short the requirement is for a secure method to make sure that once a log is written it can never be deleted or changed. So far I've only been able to find commercial and hardware-based solutions. I would prefer to use an open source solution. I know this policy is already part of HIPPA and soon to be part of SOX. It seems like there ought to be a way to do this with cryptography and checksums to ensure authenticity. Has anyone seen or developed such a solution? Or how have you made compliance?"
Optical media are great for write once, read many.
Good old syslog comes to the rescue. Besides logging locally to disk, also add a line to /etc/syslog.conf to log to a remote machine. That's probably enough read-only for you.
Don't thank me until you've seen the bill.
8 of 13 people found this answer helpful. Did you?
What's to stop someone from reading in one of the WORM tapes, modifying the log file data and then writing it back to another blank WORM tape and claiming it's the unaltered tape?
Do all logs have to be encrypted and signed with a seperate super sekret key/cert before being recorded?
Lawyers love paper. (A magistate once asked me if a printout I presented in a case was an "original email". I said it was as close as you could get.) In all likelihood, no one will ever refer to it, so don't worry about that it might take 10 minutes to find a page. Once a month, ship it to a secure storage. For real paranoia, have two printers making two simultaneous copies.
Write them out to a dot matrix printer.
No cryptography necessary!
And you thought there was no use for a USB card punch.
Hard to change punched cards. Just don't trip with your box of cards.
Fight Spammers!
Start tattooing everyone in the office with data. Encode it in some nice optical way (a la barcodes) for easy reading later.
Ontop of the obvious benefits, it provides a good deal of job security, if they get fired, they take away some important data, your employees will be thrilled with their newfound sense of security.
I preface this by saying I know I will get flamed for not recommending Open Source but SOX is a Federal mandate (Federal equals PMITA)
EMC's Centera is my personal favorite, it isn't cheap but it does exactly what you need and is auditable and recognized by all the third party audit compmaies as well as the Federal government.
I have worked in IT for 15 years and 5 of those have been for a LARGE financial institution. When it comes to audit and SOX go with something standard, tested and commercial, unless you want to spend the next 6 months explaining to your auditors how your homegrown solution works and then the next 6 months building something new that your auditors do understand (or worse, like losing your job).
It looks like that commercial offering is a piece of hardware with a network API (web service) that you write to which doesn't provide any network APIs for deleting or modifying records. Presumably it has a read-only view of the data.
Now, assuming that they use harddrives, we all know that someone could extract mount the file system and change records. They could hide their tracks by recalculating cryptographic hashes. So it's simply a lie to say that the only way to modify or indeed delete the data the data is through physically destroying the hardware.
However having a dedicated hardware for a write-only, read-many system is a good idea, but I can't imagine that this would necessarily be more complex than a locked down box running some web scripting language that appends http post data to a log, or a database.
If there is more to it then please could someone elabourate on what exactly one must do?
If so, you could use a hardware solution, e.g. a WORM MOD disk rto store periodic crypto-hashes of your logs. Then any changed would be reasily obvious, even if it would not be obvious what was changed.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
/dev/null?
No altering of the data here.
Nothing is an unalterable as a line printer which lacks reverse-vertical-paging capability. Just make sure it doesn't run out of ink or paper.
--
I don't want to rule the world... I just want to be in charge of mayonnaise.
What you need is a Write Once Read Many (WORM) device. Unless EMC started shipping Open Source hardware (hahaha) I don't think you will be able to find this as Open Source. There may be some software solution, but you would most likely need some certification for it anyway ("no, officer, it _really_ is unalterable, trust me....."). Granted, most "hardware" solutions implement WORM through software, but I know from experience that it is impossible to change the data on WORM.
Technically, a CD-R with some checksumming would work to be compliant - these guys have some more info, but if you need it for formal compliance use, you are better off talking to your friendly neighbourhood storage vendor to save you lots of legal hassle should you ever need the WORM thing for evidence. It is the difference between a lengthy legal process where you have to explain exactly why your homebrew solution is legal and simply saying "talk to NetApp"
People who think they know everything are a great annoyance to those of us who do.
Cryptography, digital signatures, and checksums can only take you so far. They can detect tampering pretty easily. However, crypto can't prevent someone from deleting a file, although by checksumming or signing a whole bunch of files you could at least detect deletion of one of them. Ultimately, if you really want permanence, you need to write it out (as an above poster suggested) to some sort of write-once media. CD-Rs or DVD-Rs would obviously fit the bill here, although one can indeed delete a CD-R by simply throwing it out, of course.
:)
Another cheap write-only medium is paper; I suppose you could purchase a laser printer (or even a line printer), and have it spit out the logs as they occur. If you kept the printer in a locked transparent box, nobody but people with the keys would have access to the output.
You could burn the logs onto PROMs as well, that's pretty permanent
Anything on magnetic or flash media can be erased or tampered with somehow, unless the drive controller hardware itself prohibited overwriting existing data. Even then you're relying on someone not being able to replace the drive controller or take the drive apart and diddle the platters/flash chips directly (although I suppose a decent amount of epoxy could thwart this). Any software-based solution can be tampered with in theory. One hacker favorite (which may be a legend or not) is that people used to get root on other people's boxes and then replace their copy of PGP with an instrumented copy. Thus, even the encryption software became compromised.
For compliance, though, I'm not sure what kind of oversight you have to have. At the end of the day, somebody has to be trusted with these logs, and that person would almost assuredly have the power to destroy them, or at least portions of them.
If a linux machine is storing these logs, just use 'chattr +a filename'. This is append-only, so you can still write to the logs but never alter/delete them.
If you only had a single machine or maybe even a couple lightly used boxes a printer might work. But even that would be near impossible to go back and sort through and if you ever ran out of paper or ink you would be SOL. And trust me the last thing you want is to to be SOL when it comes to SOX. If you have the money don't half ass an audit solution.
I use syslog-ng to relay information from several different datacenters to a centralized and secure location hosting all of the syslog information. Each DC has its own syslog-ng system acting as the local relay, transporting syslog information from local clients using TCP over a VPN to the centralized host. The logs are written on the central syslog sever organized by on date and hostname, and each file that is created is then assigned an 'append-only' bit using chattr. It works really well.
tail -f thelog.txt >> /mnt/cdrom/thelog.txt
FeeBSD supports append only files via the chflags command.
"To those who are overly cautious, everything is impossible. "
Your day to day log checks, like "any errors in last night's backup?" could be done live against the non-firewalled copies. When lawsuits, audits, or questions hit (and at some frequent interval), compare the live logs to the 1-way physically secured ones to make sure your live logs aren't being altered.
At USENIX/EVT06 last year a team from the University of Iowa presented a cheap one-way data cable you could make with off-the-shelf parts from Radio Shack. Total cost is about $5 (for bulk, maybe $10 if you're buying single units) and it is provably, auditably, one-way. It was originally developed for electronic voting, to allow for counting computers to communicate with webservers that post election results. An attacker compromising the webserver cannot attack the counting computer, because there is literally no return path.
It works with very high reliability up to about 9600 baud.
You may be able to use this to your benefit. Have an isolated system air-gapped from the rest of the network which listens for log events on a one-way data cable. While you're no longer guaranteed to be safe (since if a logging PC is compromised, an attacker could send compromised data to the syslog PC and perhaps cause some sort of mayhem), but the lack of a return path makes interactive attacks infeasible.
ObDisclosure: I am a graduate student at UI and know the guy who invented the data cable, although I am not associated with the gadget.
That's all you need
Opus: the Swiss army knife of audio codec
Just my 2 cents ....
Couldn't you add a timestamp to each log entry issued by a certified (and preferably external) time stamp server?
At a company I once worked for, we used a scheme whereby every entry in the audit log (database) had a hash of the entry's contents, which also included the previous entry's hash. This made tampering with the audit log evident when the hashes are recalculated--a change in one entry would throw all subsequent entries' hashes out of whack.
Note that this made the log tamper evident, not tamper proof which is a different ball game entirely.
I would dump it in GIT or the likes.... any change of it will be recorded ;)
Seriously, many version controlling systems already contain the data integrity and authenticity checks that you need
Are there no modifications possible of standard filesystem code, say ext2, to create an append-only filesystem ? You can pass O_CREAT but not O_TRUNC to a open(2) call, and you cannot do lseek(2) (or you can do lseek, but only to EOF, or you can do lseek, but only to read - as soon as you write, your pointer moves to EOF). It could also be a mount option next to read-only and read-write. Then, once a month, under four eyes only, you copy the lot to a tape/DVD/paper/your mom's forehead, remount in read/write mode and wipe, and remount in append mode.
Religion is what happens when nature strikes and groupthink goes wrong.
People have only mentioned hardware solutions so far (apart from a few useless ones like chattr). You can do this with SELinux, in a way so that it requires a reboot with console access to do anything about it. It may not be enough for you, but it's enough for some people.
Finally! A year of moderation! Ready for 2019?
Given sufficient resources, time, and dedication, ANY log can be altered.
If the "unalterable" log is maintained in software, it's a comparatively simple matter of hoisting it up on a VM. Since we're presumably talking about white-collar crime, it's a fair bet they have or can get root access to the machine to install the VM and rootkit to hide it. At that point, the CEO can do anything and the system can't fight back. Capture passwords of people logging in, alter data, you name it.
A hardware system would be more robust, but still vulnerable. I imagine the most likely attack vector would be Man in the Middle - Just take over the box that guards/drives the logger machine.
Some of the work I do may require something like this, so I'm considering implementing Guy Fawkes over syslog.
http://www.cl.cam.ac.uk/~rja14/Papers/fawkes.pdf
From the paper:
6.2 Tamper-evident audit trails
It is a well known problem that an intruder can often acquire root status by using well known operating system weaknesses, and then alter the audit and log information to remove the evidence of the intrusion. In order to prevent this, some Unix systems require that operations on log and audit data other than reads and appends be carried out from the system console. Others do not, and it could be of value to arrange alternative tamper-evidence mechanisms.
A first idea might be to simply sign and timestamp the audit trail at regular intervals, but this is not sufficient as a root intruder will be able to obtain the private signing key and retrospectively forge audit records. In addition, the intervals would have to be small (of the order of a second, or even less) and the computation of RSA or DSA signatures at this frequency could impose a noticeable system overhead.
In this application, the Guy Fawkes protocol appears well suited because of the low computational overhead (two hash function computations per signature) and the fact that all secrets are transient; this second's secret codeword is no use in forging a signature of a second ago.
GIT is the sourcecode management system for the linux kernel and it has a number of advantages for you:
- GIT use a SHA1 hash for checking the integrity of files, so you can be sure that you got the right file into your repository
- a GIT "version tag" is a SHA1 has over the whole history of the repository. Noone will be able to change anything below the "version tag" without changing the hash
- GIT supports signing checkins with PGP signatures, so it's clear who inserted new files into the archive.
Just burn the GIT repository on a CD or tape every week and keep the SHA1 hash tag for every day at a secure site on paper.
http://en.wikipedia.org/wiki/Git_(software)
WORM media with HIPPA compliance in mind...
WORM on wiki
- mritunjai
I honestly don't know about DSS or SOX, but I have had plenty of fun with HIPAA.
Unalterable logs as a matter of compliance does not mean "absolutely unalterable under any circumstances". There should be no way for an end user to modify audit trails. There should be no preconceived way for an administrator to alter audit trails - i.e. no utilities for doing so. That does not mean that an admin can't go directly into the DB and alter the data from behind the application layer.
Under every circumstance when I have run into audit logs involving HIPAA compliance, they have been written by an application directly into a SQL database (oracle, ms sql, informix, and one time db2). It used to be that they were written in a fairly easy to decipher format within a single text column on a per record basis - which made for a fairly-difficult-to-alter audit trail because within that easy to decipher format were non-printable characters that you would at least have to know to look for them. With current implimentations, however, the records are stored in a separate table with a many-to-one relationship with the audit-required records, in varchar fields, as plain text - much easier to alter or get rid of single entries. There is still a level of obfuscation as far as table names and column names but thats really a side effect of other things that are going on.
These systems have been reviewed by auditors and certified as compliant. In the older system, there was no application interface to delete audit records. In the newer system, there is an application interface to delete records in any given application table - and therefore there is one for the audit tables as well. Admin level access is required to delete or alter the records, though.
Personally, I would expect more as far as HIPAA compliance goes - from both a customer standpoint and an auditor standpoint. My experience (and it is pretty extensive across several high profile enterprises) - is that the customer will demand a better system only when the auditors demand a better system. I haven't run into an auditor yet who has even given more than a casual glance at the 'back door' scenario. I suppose it's because there is no true way to keep things absolutely secure and application level audit log security is only one layer of the onion.
Before you get too far into an overly complex and potentially expensive solution, talk with your auditors about the requirements for your specific scenarios. They've seen it before and can tell you exactly what they are looking for from an audit compliance standpoint. They are usually pretty easy to work with and open with their knowledge.
Although it is possible to prevent logs from being modified (using write-once media) or undetectably tampered with (using crypto, possibly with a TPM module for the ultra-paranoid), any log can be 'deleted' by physically destroying the device/media on which it is stored.
Seriously, when it comes to legal requirements, do not skimp!
Go for something that is guarentee'd to fulfill your legal compliance requirements.
Yeah, optical media is great for WORM, but you dont want something your going to have to manage day to day. The legal req's of sox and so forth are beyond that of traditional optical drives in terms of life span in any case. Do not go with optical for compliance unless its something specifically designed for compliance (Again, thats $$$).
As someone suggested, centera is a good option - but all the storage vendors have good options (from emc, netapp, hds, sun, falconstor, mimosa the list is endless) and they'll all tell you how theirs is better than anyone else (and why). At the end of the day, you want a compliance solution with someone's stamp on it, and a throat you can cut when it goes wrong.
If your absolutely determined to go the compliance route on OSS - go with ext3cow (www.ext3cow.com) IMHO, a fully versioning COW fs with a non-erasable past and the best OSS solution for the job - backup on to optical if you like, but dont make optical your only option. If it only had policy-based management (i.e. snapshot whenever user X or group y writes a file) rather then crontab'ing its snapshot agent it would almost be perfect for a start-point solution for compliance. It has a big benifit along with it though, you can show users how to get files "from yesterday".
Keep in mind, WORM means policy-based write-once, not necessarily immutable storage! And almost every compliance worm product out there depends on that fact.
It's already been said in other posts but to summarise:
It's not just Read Only (which can be achieved easily with syslog), it's the ability to return requested data quickly that the critical thing with SOX et al.
If someone says they want to see information on item X, you HAVE to return this imformation in hours not days or weeks.
This is where the commercial products have spent their time, developing fast search capabilities over the data they collect.
Certification is also important. Ie product X has been shown to work and works like this..
Why can no one spell HIPAA properly?
I work for a big pharma company as a sysadmin, and we have to abide by similar rules and laws. Our data recording and data logging has to be proven to be unalterable.
Go with a commercial solution unless you want to battle with the QA and Validation departments for haf a year. And even if you would get the go-ahead (unlikely) you'd get in a hell of a lot of trouble during an audit because auditors a) don't know your solution and b) they will quickly see that it is not certified.
There are specified requirements (don't know the names and numbers by heart) that your solution has to proven to fulfill, and certified by some external party.
Just saying 'Yeah but I know it cannot be altered because it is syslog / ' will not cut it.
And non-compliance can eend up costing your company millions if not hundreds of millions.
Open source or home grown has it's place, but in a regulated environment you go with commercial for certain things because that is the only option where you get certification with your device / software.
ext3cow was written with compliance in mind (i.e. with an untouchable past), and so its AFAIK the ONLY solution that can fit in compliance (keeping in mind that this only covers part of compliance). svn, git, cvs - im sorry, but thats just a non-solution for compliance. It also gives you no-mess management with a very easy interface to make sure you are being compliant (this is important, and its something YOU dont have to be involved in, your lawyers can "look at the past" to make sure "discovery" is going to be consistent).
... which has never been proven or certified by anyone".
The second thing is, compliance is (ridiculously) complex - the compliance vendors have spent many hours with lawyers getting it together, they know the requirements and they know they fullfill them - this is important. It also means their solutions come with an implicit warranty - "hey, your using netapp worm, we know it works" as apposed to "what software is that? how do you know it works?". At the end of the day a lawyer is going to either go "well i cant argue with the compliance solution" when your with a well-known or "your honor, the defendant is using
Compliance is the only time i will say to someone - "get a throat to cut", get a solution you know works, written by people who know what they are doing and its all because compliance req's were written by lawyers for lawyers (i.e. scum) and so their scum is going to make you have to act like scum.
http://sourceforge.net/projects/tolven
A couple of the posts above has already bought up the use of paper printing logs for the purpose. That's really practically used by many companies.
:)
The solution, however, is hardly cheap. You need an expensive 4000-line per minutes line printer with stackers to re-fold and stack the fan-fold papers as they emerged from the printer. Also, you need monitoring tools to monitor the status of the printer and a room with security staff to prevent physical tampering.
(Don't bother using a laser printer, the cost of the ink along would drive your company into bankruptcy
I saw one of those system in IBM before, may be you could approach them for advise.
Comment removed based on user account deletion
Of all the solutions I have the one that would work, and I can't beleave the /. crowd have not mantioned it yet.
Email your logs to gmail
Have gmail automaticaly fwd your logs to hotmail
Have Hotmail automaticaly fwd your logs to Yahoo
You want to put more stuff into the mix, ensure your chain of emailing includes anonymous fwding or whatever other features you want. Every account has a password. If any email is disputed, I can log you in another account to prove its correctness.
You get them time stamped
What else do you want?
G
This functionality was built into Netware's NFS, all the way back to 3.x (maybe even 2.x) There was a bit for "Add" and "Edit". Worked just as the article reads.
Flick that, then put the box under lock and key. Email checksums someplace cheap and remote. gmail is a good one - lots of space, and the date is hard to change, unless you break gmail ? (spread the blame ;)
Also, some bioses allow read only disk access.
Cheap, fast, works :P
as it was quickest. writing: 1. append latest entry as plaintext 2. sign [signature of previous entry + plaintext of latest entry], and append as signature of latest entry
First of all, this is a requirement to satisfy an audit. It would be nice if whatever solution you come up with is actually good, but you only have to satisfy the auditors.
Auditors want processes and records to raise the barrier to someone doing something wrong or unrecorded. They know systems aren't perfect. Nerds all go "but someone could just make a change some other way so this system is no use". If it raises the barrier high enough, it is useful. All accounting books can be cooked, the point of auditing is to make it harder (and to make it require more people).
Some write-once methods are more accepted by auditors than others, because they have seen them before. Of course you can rewrite a WORM disc's contents onto another disc and edit the contents on the way, but most auditors think that is sufficiently difficult that they think WORM media is OK. And you can write several copies and send them to different places, then the person wanting to edit the log has to get to all the discs.
The commercial solutions like those from EMC and Network Appliance aren't foolproof. You could take all the discs and edit the data on the discs if you want. It's harder for you to do that than simply "su root; vi logfile" because you have to work at a lower level. All the EMC or NetApp software is promising the auditors is that it would be hard work to do it undetectably and that is what they are looking for.
An Open Source solution which has no API to change data once it is written would work the same as the EMC or NetApp, but if you are the first to use it then you have to persuade your auditors (and possibly a court down the line) that it really doesn't have any such API.
Usually Open Source is good for your business because you have control of it, can change it, and can see how it works.
Auditable logs are about you not having control of them, not being able to change them.
The easiest way to get your auditors to agree your logs meet the audit requirements is to use some solution that they have seen before. Buy a Netapp (I won't, personally, recommend EMC) or buy a WORM drive. DVD-R is WORM, it's cheap.
"For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled"
One method that would prevent tampering of previous written log data, is to use some kind of hash function, for example SHA1+MD5, to generate a signature of the current log chunk. When the next log chunk is to be written, the hash value of the previous chunk is stored in the current log chunk. This way the hash value of the previous chunk is used as salt when the current chunk is going to be calculated, making it impossible to change the log history unnoticed. Using only MD5 (or even SHA1) is probably not a good solution, as there has been some more or less successful attempts to forge the signature, but by combining SHA1 and MD5 along with file size, it should be reasonably impossible to fake old logs.
No expensive software necessary, it could easily be integrated into programs, or even a small bash/Perl/Python/whatever script could perform the task.
Deletion will always be possible. Even if you don't have a nuke at hand, there's always a sysadmin (or two, playing together) who can do it. If the value of "losing" audit logs is high enough, the solution will be found...
:-) [Can you buy a LP today that is dumb enough not to have such features? :-)]
Most of the line printers have escape sequences to set many things. It's nice to use that to set the line feed distance to 0 points
Also, in most of the cases, you *can* change the logs (video tapes, etc.). Sure, it will be detected. So what? Applying crypto (hashes, HSM signed log entries, etc.) can show you that something was changed, but you'll never know what was the original data. For example: "What IP address did that hacker use, where did he come from? "Well, we don't know, but we do know that it's not what's in the log, as that is corrupt." Cool.
And yes, I'm being theoretical here. On the positive side, although you cannot say "once a log is written it can never be deleted or changed", you can mitigate the risk that this happens to you, down to a point where you (or SOX) find that acceptable.
I remember reading about this several years ago. It was an active area of work in the 2001 to 2003 timeframe.
. html
s log-sign-22.txt
You can read an article about it here:
http://ezine.daemonnews.org/200112/log_protection
There is also a draft in the IETF on how to do this in a standard way:
http://www.ietf.org/internet-drafts/draft-ietf-sy
Good stuff.
Write once thermal magnetic paper tape or digital optical tape
davecb5620@gmail.com
Rather than collecting syslog entries in one place, disseminate them to many collectors. It then becomes a very difficult task for anyone to modify the received logs because they reside in different places under guard by different systems.
syslog-ng will happily do this.
Setup UDP transport for syslog to many destinations for the same data. Each destination will receive a copy of each syslog entry and store/guard it independently. The reliability of the data is specified by the reliability of the stores. These can be commercial data storage centres.
In any dispute, read back all the relevant copies and check for any differences.
100% trust is not achievable. Settle on an acceptible level of risk.
-- Rich
As many other posters have suggested, when it comes to federal audit compliance, commercial reliability should be a serious consideration i.e. EMC Centera.
That being said, you did ask to see if any open source solutions. The only thing I can think of is coming up with some combined use of dnotify (http://linux.die.net/man/1/dnotify), or one of its more modern incarnations such as inotify or I think there is even an lnotify now, and then use that to launch a script to strip user write permissions from a file after it has been created/written in the directory. This would of course be tricky as you would need to be confident the user was done writing to the file before you removed their write permissions, but it is open source and gives you something easy to play with as you evaluate your options.
Best of luck!
This state of "impossible to alter" is quite clearly not possible to achieve. If you use write-once media, just copy the media minus the incriminating logs. If you're using "WORM disk," AKA regular disks with a fancy box in front of it that will refuse to overwrite files, you just have to learn the filesystem and change the files yourself. The whole thing boils down to choosing in which way you would like to delude yourself into believing the problem is solvable.
As far as delusions go, like some people have said, probably the best open-source delusional approach is having some kind of DVD writer in place, but of course you'd have to make it impossible to store your logs somewhere else before they hit the DVD (then copying the logs to the write-once media after you've altered them and/or someone asks for them), or to modify them en-route, or to copy the DVD minus the parts that are incriminating, etc. The whole concept is full of holes even if you prove that the information that actually hit your storage hasn't been changed, or simply assume that it can't be changed because some vendor says it can't.
The absolute best you can hope for is a combination of something technical that is completely breakable (they all are) and administrative controls such as physically signing off on the media, limiting access to the hardware, etc. to make it harder to tamper with things or at least to make it necessary for multiple people to conspire to make a change. In none of the situations I've described is a change impossible, just more difficult.
It has plenty of storage space even by todays standards. The word length is a little non-standard in today's 23 bit and 64 bit archatectures. It includes a drain for when it gets full. The bucket under the drain provides little protection to the contents. This is a serious design flaw for data retention.
"The Signetics Write-Only Memory is a completely interated solid-state device that employs both enhancement and depletion modes. It is organized to store "N" number of words which consist of 9,046 bits each (the term "N" may equal anything to infinity, and then some)"
If you read the original specs, the cooling requirement is a little agressive.
"The 25120 is easily cooled by employment of a six-foot fan, 1/2" from the package. If the device fails, you have exceeded the ratings. In such case, more air is recommended."
If you don't have the catalog from the 1970's, the text without the graphics is here. Enjoy.
http://www.ariplex.com/tina/tsignet1.htm
The truth shall set you free!
Use 5 1/4" floppies. Once the data is written to the disk put some tape over the write tab on the side of the disk. If people claim this is inefficient, double the efficiency buy punching a hole on other side of disk and flip it over.
;)
They want an audit trail, they'll have it. A trail of floppies that no one will ever find the log file for!
i dont know about hippa/sox but i did recently have the "pleasure" of creating a pci-dss v1.1 compliant system from pretty much the ground up on the freebsd platform and have read all 16 (wow!) pages of the pci-dss 1.1 "spec" (if you can call it that, i put that in quotes because it it doesnt "spec"ify anything. at least it is short read albeit a vague one) the following is a rant. however if you read to the bottom (or skip there) there is a reward of a paragraph actually more directly pertinent to the original ask /. question :)
it (pci-dss) eerily reminded me of iso 9001. (i have a little experience in qual. assurance of manufacturing.) basically [pci-dss|iso9001], while its advocates will try and trumpet [security|quality], has nothing to do with either, and more to do with documentation and accountability. (ie whos responsible ie who gets fired/resign (after they've already pocketed enough money so that its actually basically a retirement) so that another scapegoat can be brought in to take his place) sure, documenting your process has always been a cornerstone of [security|quality] but anyone worth their weight in horse-sh^H^Hmanure already knew that and already did that.
[pci-dss|iso9001] seems to me (a small business operator) to mean more about burying the little guy in a mess of paperwork and red tape while letting the big guys pat themselves on the back with another acronym or seal-of-approval that in the end gets so watered down and turns into just another way for fool-hearty consumers/customers to increase their complacency (complacent-fool consumers both a. deserve to be separated from their money quickly and b. are in my opinion one of the major problems w/ american society) rather than study beyond the flashy outter packaging (in a manner of speaking) what they are buying.
and i dont have much experience with SOX but from the whiff of it based on what some colleagues have told me, is roughly the same thing (swap consumers w/ investors in the above text), despite glowing reviews in a recent usa today article on its 5th birthday. (usa today basically credits SOX for all of the US's economic growth since its inception after the post-enron market bomb, not the fact that the fear of being caught still looms in the air like a stench and so would-be corruptees might just be chilling out for the time being, seeing that 5 years is nothing the grand scheme. however my hypothesis is that they in fact aren't chilling out at all, and are going at it just as strong or stronger, because from what i have seen in business, i would tend to think that: just like there is nothing really stopping a iso9001 certified company from producing sh^H^Hpoor quality products, SOX smells like just a better way to bury the real story in cooked-books that are now just that much deeper. i know, i know, now the board is responsible and not just the CEO, and its a legal crime and they can't claim plausible deniability anymore, all good steps in the right direction, but that only matters if you get caught and my point is that SOX is just more paper to hide under so they dont get caught) (ok please label all flame replies telling me i dont know squat about SOX by keeping SOX in your subject while taking PCI-DSS out of your subject line if it no longer has anything to do with pci-dss, and do please enlighten us)
back to pci-dss: as consultants first and developers second, we reviewed handfulls of pci-dss compliant "solutions" before resorting to a custom built system. despite trying to scare those like us out of it, with a little patience and attention to detail we little guys could still implement a pci-dss compliant system that was WAY better than many systems i wont go into bashing here, and all for the cost of some lower priced of the pre-cooked "solutions".
to an experienced developer, the pci-dss "spec" reads like: 1. dont be so stupid, 2. pull yer head out of yer as^H^Hrear-end, 3. dont g
If the logs have to be searchable, don't they also have to remain "online" (i.e. can't move to backup?) Won't this just be a huge boon to storage manufacturers?
stuff |
In win xp all you have to do is right click and set the read only bit.
Health Insurance Portability and Accountability Act, schmuck.
Several posters here seem confused between the requirements for unalterable records and logs with audit trails.
For an unalterable record you need a WORM mechanism which provide a permanent record which can be physically destroyed but not edited.
For an audit requirement, data is logged, access to the logs is restricted, and any change creates an audit trail, ideally indicating who made the change and (typically on paper) who authorised the change.
Clearly the requirements for the former are much more stringent and are generally met in hardware using WORM systems from vendors like EMC & HDS, or on a smaller scale using two or more WORM drives in a dedicated PC with archival software. While, for the latter an open systems solution is feasible.
Just my thoughts,
A.C.
...and a really big box of paper.
Just use a small font and expand the margins a bit.
Having gone through a few PCI audits what they accept for logging is pretty simple, log to local + remote don't let anybody on the remote with rights to delete or change the copies, use selinux or similar to alert on change and backup regularly and ship the tapes off site. For me this general means the daily or weekly off site tape rotation gets a new class of tapes with 7+ year retention holding the logs generally sever copies of the same log since it's a 90 day local retention on the central server and tape is cheap. This means even if I have to pull back a tape I have a nice paper trail as to who touched it and when locally along with an uninterested vendor's log to the same. If we need to get them reviewed by a third party we can get them the next tape from the off site vendor shipped directly to them. This passes the auditors and legal, PCI is pretty weak compared to SOX or Hippa really it's just a way to push blame to the merchant since PCI is written to be vague and open to interpretation.
No sir I dont like it.
AFAIK the only FOSS log analysis tool that does the hashing/signing of all the
i gn
stored logs is ossec: http://www.ossec.net/ .
We switched from logwatch/logsurfer because of it:
http://www.ossec.net/wiki/index.php/Know_How:LogS
There are a lot of fundamental rules in crypto, and one of them is that crypto can only become less secure over time. Time eventually breaks all crypto, and once "the cat's out of the bag" (key compromised etc) it tends to open everything secured with it in the past, assuming you simply kept a copy of it from back when. To lock something from alteration in the future is not a problem that can be solved with crypto. Hardware is about the only way to do it, to write it to a media that cannot be physically altered. I'm sure most of these posts are going to suggest CD-R media, and really that's a good way. Even that fails though, because there is little to prevent someone from reading in the media, altering it, and burning a new copy. Again things like this cannot really be future-proofed.
The only practial approach would be to digitally sign it, and throw away the private key. Keep the public key, and then you can read the data and verify the signature, but you cannot alter the data without resigning it, which is not possible without the private key.
Then how to prevent people from changing the data and changing the public key? The solution to this is to create a chain of keys. Lets say we plan for 20 years of recording. Initially roll up 20 x 12 keys, one for each month from now to then. Use the keys intended for future to sign the keys to be used earlier. This creates a chain of trust rooted in the future. So the key for signing records made in March 2008 are signed with the key made to be used in April 2008. Once signed, lock up the future keys and do not remove them from the vault or whatever until you are ready to use them. Be sure to destroy the private keys after their month of use is over.
In this way, if someone tries to alter a the key for March (which they can do, and just resign everything) then in April when the April key is unlocked, its public key can be used to verify the March key's April signature, which will no longer be correctly signed and you can turn the dogs loose to find out what got altered. Thus the March key cannot be replaced to permit alteration and resigning of older data because it itself cannot be resigned until next month when the key that signed it becomes available.
There would be a period of time in this example, one month, where data could be altered since the public key is still available. This could be mitigated by lowering the interval time to say, one day instead of one month. Then once data becomes a day old, it is very difficult to forge since the older private keys are no longer available and cannot be replaced.
For those of you paying attention, it's possible to get around this by changing all the keys below the current one. This is fixed by signing all older keys with all newer keys, instead of merely signing them with the next newer key. Shouldn't be a problem since signatures are not all that large. As long as you can keep the newer unused keys private, it's impossible to alter the logs without being discovered.
This does not break the rule I started with, the system is still vulnerable to time, but this method allows you to specify the time in the future where it breaks. The last key to be revealed defines the point at which the chain of trust is broken. After that day, ALL prior logs could be altered without detection, since its keys are now exposed. Of course the smart thing would be to never use the last public key, and throw it away the day after it was initially used to sign all the lower keys. Then every 10 years start with a new batch.
I'm no crypto expert but it's an interest of mine. I invite some real crypto experts to critique my idea. (and maybe tell me about how someone has already implemented it?)
I work for the Department of Redundancy Department.
IANAA (I am not a anything!), but from my own personal experiences, if something is technically infeasible for the average half-brained VB consultant, then it's probably above what little technical understanding any court (or its "expert" witness) would have if such technology were to be used as evidence.
On one hand, you've got WORM tapes and optical write-once media. If you have to implement some sort of buffering to make these storage mediums happy, then you simply have to do it and that's the end of it.
The people drafting SOX aren't device driver coders, they're accountants and attorneys and other non-computer folk. If they said you had to tattoo each transaction on a live hamster and shoot them into space, you'd be in the same tight spot. Just like instant WORM logging, it's marginally feasible but terribly impractical using currently available technology.
-Billco, Fnarg.com
Big Disclaimer: I'm a snare developer!
... and a whole bunch of others) can also write data to a remote syslog server (eg: kiwi syslog, syslog-ng) in real-time.
;)
The "Snare Server" software can automatically archive to optical media, and receives data from the snare agents in real time. Unfortunately, it's commercial though.
However, the agents are open source, and we provide a bunch of open source tools that might help you throw your own custom system together to do something similar. The agents (Windows / Solaris / AIX / Irix / Apache / Squid / ISA / IIS
Won't mention the company web site - this is a comment rather than an Ad, but the code's on sourceforge if you'd like to go looking.
Regulatory compliance is a fun process isn't it - whether it's PCI, HIPAA, DCID/DIAM, ACSI33, GLBA, NISPOM... or a whole heap of others that people need to cover these days.
Red.
This isn't FOSS but it is a cryptographically based solution: http://www.surety.com/.
There are likely other solutions available like this one, I just happened to cross path with some of the engineering staff in a former life which is how I knew about this company.
-X
Delete is still easy to do. I have a 1200 watt CD/DVD bulk delete device in my kitchen.
now we need to go OSS in diesel cars
It seems unrelated, but I use PuppyLinux on a rewriteable DVD on a diskless laptop for travel (security of email). I set it up to write some data to DVD each time I exited. The DVD+R (I think don't have it handy at the moment) was much more efficient at writing many small changes to the rewritable DVD. IIRC, the DVD-R rewriteable can handle only a couple hundred rewrites, the +R is almost infinte, until you've filled the disk.
This might be the simplest solution, even simpler than attaching a serial TTY to a serial port to paper log all network accesses.
If you want something that cannot be deleted then you require a hardware solution. Any software "solution" will in some manner or form permit change and deletion. Now, you can come up with a software only solution to detect changes (that's actually not that hard), but that's not the same as preventing changes.
I work in a regulated industry, and this is an ongoing topic at pharmaceuticals.
Basically, you weigh the cost of non-compliance versus compliance, figure out
what that risk is worth to your business, then try to spend as little as possible
to mitigate the risk until the cost is acceptable.
There is no such thing as 100% compliance or security. Oracle makes a big deal out
of their data vault tech, but there's someone out there who can circumvent it. You
need to figure out your comfort level for the risk, and in big corps, this is a
financial decision.
Which leads me to this: there is no "roll your own" compliance software. You do not
want to assume the responsibility of proving to auditors that your software is correct
and fully-functional. That is a difficult process to behold, and it will make your
dev team crazy with paperwork. This is why people buy commercial off-the-shelf (COTS)
software and then configure it, as they can then point to the COTS vendor and say
"He vouches for the software". Auditors already versed in the COTS solution will
then look to see examples of your configuration to see if it's sufficient, then
move on.
Sure, it's a nice intellectual exercise and certainly worthy of development, by a
dedicated team willing to tackle all of the issues around securing the data, providing
secure authentication and controls, proving non-repudiation and temporal consistency,
etc, all of which a one-man show cannot achieve, all of which a half-assed token effort
cannot achieve.
Really, it boils down to this: you wanna roll the dice on your company being under a
consent decree from the DoJ because you were too cheap to buy a system? That cost can
shutter your doors.
-BA
I think Plan 9's Venti probably does what you want. There is a version which runs on Linux; see Plan 9 From Userspace for details.
You obviously don't have much practical experience with PCI-DSS -- There are actual three different docs to look at -- 1. A one-page overview listing the 12 major bullet points to compliance. 2. The 16 page document that you refer to that lists sub-categories under the 12 major bullet-points. 3. The ~50 page auditor guidelines that detail exactly what you need to do. Go read some more, young lad.
Are you referring to HIPAA -- demon spawn which makes health sciences research an exceedingly nasty proposition?
You didn't mention your application. For research, for example, the best way to limit your difficulties with HIPAA is to
get your research subjects to sign away their HIPAA rights for your research data and then to anonymize it as heavily as you can.
Write once, read many logs are part of HIPAA compliance? That's news to me.
Plan9's venti archival filesystem does this, and supports a number of WORM jukeboxes (mostly from HP). It will easily integrate with Win32 or UN*X on the network, as well.
-jcw
Plus when you get that request from legal there's nothing quite like popping down to the warehouse where you store all those things and dumping 6 months of paper logs on someone's desk (Isn't that right, IBM?)
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
The system is write once, and is permanent. (At least, the cavern walls will be around much longer than your company can ever hope to be). If anyone does manage to sneak in to change a record, the monks will hear them and judo-chop-fu their intruding ass.
The system is secure, since you control the only input point. You can add layers of security by working out an authentication code with the monks, posting loyal guards around the tube entrance, etc.
If you did your homework properly and got yourself some of those scrupulous, herb eating monks, the system is reliable has great longevity. Bonus points if you found an co-ed order, because then you have a self-replicating system.
If you ever need to retrieve the records, just reverse the flow of the tube. If you need a full system audit, blast a hole in the ceiling and lower the auditor in. Just seal up the hole afterwards with plenty of concrete. (Removing the auditor is optional)
UTF-8: There and Back Again
Use a version control system like Subversion. You can actually modify or delete files as much as you like, but the full change history will be available for any URL, as will all committed revisions, so even if somebody deletes something you can just request the revision where it still existed and had not been modified.
It's a simple solution that does not required any complicated storage setup. Many developers use it every day.
This problem has already been solved: http://www.proofspace.com/
You'll never roll-your-own for cheaper than SenSage/EMC-Centera.
SenSage is a commercial log storage product/archiver design for Linux clusters and built on open source software (backend: C++/Perl; GUI-client: Java; CLI: Perl; Agents: Perl). Not only can you store gigabytes of log data every day, you can run queries over billions of rows in a minute -- your roll-your-own won't allow that. Any PCI compliance solution must not only store log info but also let you analyze it -- analysis also will lead to better operational monitoring, and better security (if you're worried about being hacked from outside, worry much more about an inside job! -- only archival/analysis will give you proof of past wrongdoing for inside jobs). And when it comes to figuring how best to satisfy specific compliance issues (beyond just storing the log data), they've done all the hard work for you for HIPAA, PCI, SOX, etc. Tracking down and complying with your particular regulations would take a long time on your own.
Added benefit: the back end archives log data to a huge write-once read-many EMC Centera device. You can keep your log data around for ten+ years.
SenSage is such a good DB for log archival, it's been incorporated into offerings by EMC, IBM, HP. See, for example the "HP Compliance Log Warehouse appliance" ( http://compliancehome.com/news/FISMA/10902.html ) -- it's HP's version of SenSage.
Why not use something like SElinux, or my preference RSBAC, with which you can make the file appendable only outside of unix access controls, and if the box is compromised the files can not be changed. Try doing that with OpenBSD or anything else.
You may want to take a look at this paper, my MsC Thesis which builds exactly on the problem you mention:
p hp/2555/pdf/imm2555.pdf
Preserving cybercrime evidence:
http://www2.imm.dtu.dk/pubdb/views/edoc_download.
It is based on a Bruce Schneider paper regarding secure logging and tamper proofing via cryptography.
Best regards
See other comment posted above this one for description of SenSage.
EMC ships their Centera with a very good software package from SenSage built specifically for log storage/analysis and compliance. While SenSage isn't free, it's a good open-source-based software product. It's incorporated into products from EMC, IBM, HP, etc.
See prior posts about SenSage -- it employs a write-once read-many storage device (EMC Centera) and a commercial but open-source-based log archival/analysis engine (SenSage).
If you can't even spell HIPAA then how can you possibly hope to be compliant with it?
Je fume. Tu fumes. Nous fûmes!
I published a virtual disk driver that emulated a WORM (mostly) on a cryptodisk for this purpose in the late 1980s sometime; look on the VMS SIG tapes. The code implements an encrypted virtual disk, but the device driver, above a "fence" block number, will only write to the container if the container has a predefined magic number all over it. Otherwise the write is not done (I don't recall if it pretended to succeed or not). The trick is to set up a filestructure so the index file and directories are below the "fence" and there were a few mods to filesystem calls within the driver to assist there; the disk driver also disallowed delete and I had to supply some code to generate the disks. Intent was to use it for encrypted logs. The driver checked that it ran from system startup ONLY, and a second version of the driver using same key was built (intent was to run it from a floppy) that could allow setup of the thing. This had to do with key management. The encrypted disk was not to block access, but to make it really obvious if someone tampered with the container file and make it useless to just access the container file to read or mess with logs. It worked fine, allowed normal apps to have encrypted logs by just having them write to files on the device. Someone could tweak the truecrypt program which is free and in source to do basically this trick and have a free solution. It is not 100% perfect but covers a lot of the map particularly when you recall that you can access the container exclusively from your driver associated code, so others have a hard time getting to it. Someone CAN tamper, but they have problems tampering undetected. BTW if someone erases index file etc. you have to use filestructure recovery techniques. Blocking delete or directory moves or overwrite in the driver prevents some of the easier attacks so as long as you can ensure by other methods ("take em out in the back and shoot em") that people leave the startup alone this is not too shabby.
Glenn Everhart (see www.gce.com for some other stuff of mine.)
Novell Sentinel (formerly eSecurity) should meet your needs.
chmod 0000 logfile
chmod 0200 logfile
Start syslog
chmod 0004 logfile
That might be enough. Make sure you log roller set perms to read only, and never delete. That should get you odd the hook quickly. Follow up with checking the logs into subversion, at least on a nightly bases, or every 60 seconds if you are like me. It also doesn't hurt to log to syslog host that nobody has network access to.
Enjoy.
-- Prepared at the direction of, or to be sent to Legal Counsel, in anticipation of litigation. Attorney Client Pri
We use a tenix data diode.
Its a truly one way data communication system so our syslog server runs on a network that can receive syslogs without ANY data flow in the other direction. There is no way of remote hackers logging on or compromising the syslog server to modify the logs to hide their trails. It also has a file copy function so log files can be periodically copied to it(again - no reverse path of information) as a secure log archive. The only way logs can be modified is via local access to the machine, and it is locked away tight!
And how about tech and biz processes to destroy all those archives once they're expired?
The US has gone in the opposite direction of the rest of the modern world, requiring data retention by business, healthcare, telecom (but, not ironically, by government). The rest of the world has data retention laws and practices requiring data be destroyed once the original transaction dependent on it has completed, and after any reasonable auditing latency has expired. These archives are piling up. Not only is storing them a waste of space (virtual and physical) and tracking them adding complexity to management. They are also the stuff that privacy invasion is made of.
If the IT industry ensures that archive expiration and data "termination" is always part of the process, built into software and business processes to extend "archive/restore" into "archive/restore/delete", we will make our jobs easier. And we will make protecting our privacy that much easier.
--
make install -not war
For truly unalterable logs, a hardware solution like a printer in a locked room or signed, registered CDROMs is necessary. But even they can be subverted by sufficiently funded opponents.
Ultimately, nothing is unalterable.
Fire.
Rudd-O - http://rudd-o.com/
The logs are permanent, unalterable and accessible to your forensic team.
Just cycle them between the burners and make sure that they get unmounted and stored safely.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
Whatever solution you come up with, you should also create a signed hash of the log file and publish it on your web site and in the local paper every day or every week.
People have been doing that for years. Granted, hash collisions are possible but it makes it all but impossible for someone to tamper with the logs in a way that will do them any good, provided you have reliable backups.
If you can trust that the logs won't be tampered with between the time they are created and the time the signature is published, you don't even need a write-once solution.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
One automated way is to use Modular Syslog's hashed logging function:
. htmlh tml5 0/
http://ezine.daemonnews.org/200112/log_protection
http://www.softpanorama.org/Logs/log_management.s
http://www2.corest.com/files/files/11/PEO.pdf
http://www.linuxsecurity.com/content/view/117280/
Hi,
t ability_and_Accountability_Act.
It's HIPAA not HIPPA.
See Wikipedia, among others:
http://en.wikipedia.org/wiki/Health_Insurance_Por
Peace
Neat.
One thing I'd add: ability to ``restart'' the md5. ie: if someone alters a few records, you don't want that to screw up 99% of the other correct data. Maybe restart your stream every 20 records, and wrap it inside a similar stream?
"If anything can go wrong, it will." - Murphy
And if that means you don't cheap out and go OSS, don't worry about it. If you're in a place subject to these woes ^H^H^H^H regulations, then by all means it's probably not your money you're spending on it. Don't get me wrong, I'm a huge fan of OSS, but when it comes to keeping lawyers and auditors at bay, you take the plunge and buy the real stuff. And you pay the 35% service contract fee too. I had a situation where something we were doing wouldn't pass muster with our SOX auditor. I asked her for if she could tell me what would pass. She could not. Instead, she offered that if I posed the question another way, she could answer. That meant asking "how have you seen other companies meet this or a similar requirement?" And she told me right away a number of things that would work in my particular situation. Applying that logic here, you can't ask an auditor for advice, but they will tell you if you ask the question the correct way. And if they know and have seen Centera, it's a review of the configuration on the frame and you're done. Do you really want to spend all day explaining this custom rig up of Linux syslog server with logfiles on a partition that is mirroring off to CDR drives, how syslog works, how your box is locked down, etc., etc., etc? OSS Fits. But not everything.
For every option you consider, ask yourself this question:
Could Bernie Ebbers hire someone to break my system?
This is one case where I would firmly say stay away from roll-your-own OSS. Buy a commercial product with a contract assigning liability, and get your lawyers to bless it. The company can use OSS if they want, but the responsibility of the system's integrity is NOT something you want to take on. This isn't a technical challenge, it's a legal one. To understand, compare it with backup software.
Case #1) You have been told to come up with a backup scheme for your company's data. After some research you decide on Amanda, writing disk-to-disk-to-tape, which is stored offsite. You write up the exposure document (i.e. the data centre burns down before the current tape is sent offsite, and you lose 48 hours of data) and the execs sign off on it. If you are confident in your technical choices and skills, then this is a fine solution. When the data centre burns down, you go to the vault and recover the data from the last tape, just like the document says.
Case #2) You have been told to come up with an unalterable logging scheme for SOX/HIPAA compliance. After some research you decide on some OSS tools. You write up the risk document (in this case, pointing out how the system could be compromised) and the execs sign off on it. Two years later, your CEO gets called in front of a grand jury for fraud charges. You get called as a subject matter expert, and some very belligerent prosecution lawyer says, "prove to me, the judge, and this jury of 12 random people BEYOND A SHADOW OF A DOUBT that these logs could not have been altered in any way, shape, or form by the CEO or anyone else, including yourself." What if the code is buggy? What if there's a flaw in the logic? What if the jury just doesn't get it, and you aren't given the time to properly explain? It doesn't matter if those logs aren't altered, or even if they're unalterable--what matters is the due diligence, and reasonable belief. If you can say, "We bought this product from NetApp and according to our contract, the federal government certifies this implementation as being unalterable," then your job is done. Your CEO may hang or not, depending partly on his guilt or innocent, but you are off the hook. If you build it yourself, you could end up sharing a cell with the CEO.
Buy a product. Let someone else take the risk, and do the research.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
It ain't perfect (after all, the sysadmin can still mod the thing back to writeability), but it's an often overlooked means to make sure the file contents don't change, and it's easily scriptable.
Just a thought.
Quo usque tandem abutere, Nimbus, patientia nostra?
To guard against alteration, take your log file (rotated at intervals that are reasonable given resources and your security requirements) and generate a cryptographically secure hash. Send that hash over a secure connection to a trusted certifying authority (CA). The CA appends a timestamp to the hash and digitally signs the message using a public-key cryptosystem. They send the signed, timestamped hash back to you, and also retain their own log of the hashes for added security.
Multiple CAs can be used for added security, since all would have to be subverted in order for you to alter a the log file without detection.
Guarding against deletion is simply a backup problem. You must provide physical security for whatever backup media is chosen to the level needed for your specific requirements.
I'm far from an expert on this, but I'm surprised that no one has pointed out: http://www.schneier.com/paper-secure-logs.html A classic paper on how to do just this. IIRC correctly, it describes a scheme to add a digest to each log record/line which includes the digest of the prior record/line. So, in order to tamper with a record you have to tamper with all the following records/lines as well. Security by induction ;)
~rmp
~rmp
It's spelled HIPAA!!!!!! Sorry, that drives me crazy!
-6D
Ok, I am not saying that one shouldn't encrypt. I think one generally should, but here are the requirements and relevant sections paraphrased:
3.1: Store only what you must.
3.2: Do not store sensitive authentication data (CVV, CVV2, magnetic stripe) subsequent to authorization.
3.3: Mask the credit card number when it must be displayed whenever possible
3.4: Render PAN (Credit Card account number) unreadible anywhere it is stored. If this is not possible, see appendix B for acceptable compensating controls.
Note that 3.4 does apply to backup media, logs, etc. The simple approach is don't log credit card numbers. And don't store them in your MySQL database in plain text (as does OSCommerce in at least one configuration).
4.1, cardholder data must be encripted when transmitted across "open, public networks." Presumably corporate intranets are excluded from this requirement but I would just as soon encrypt everywhere.
4.2: Never send credit card numbers via email.
10.1: Establish practices that allow you to track any administrative or root action and associate that with each individual user. In other words, you must be able to show not only what root did, but also which individual did it. I suspect that restricting root to *one* person and giving others access to sudo would be sufficient provided that sudo -s and su are prohibited from being used.
10.5: Protect audit trails against unauthorized modifications. This does not mean write once. It simply requires that the media be "difficult to alter." However, periodically backing recent logs up to optical disks would likely be a good practice.
10.7: log data must be retained for at least one year, and at least three months must be available online.
LedgerSMB: Open source Accounting/ERP
Here's how syslog-ng for centralized logging PHP syslog-ng for a sweet web front end to slice and dice the data when needed. Using syslog-ng filters which are very sophisticated. Send one copy of the data to a mysql DB for php syslog-ng and one to plain old text files. We use dvdtools and to burn the text files once a night to a DVD. you could do so more often if need be we leave the disk as multisession but there seems to be a practical limit of about 99 sessions so we do 90 days. I also have syslog-ng filter setup to send warning and above to a separate file where I parse it with OSSEC HIDS (just on the central log server) for funny business in the logs which get's emailed to a special alert email box I have set up. Also check out campin.net for good open source centralized logging infos
Crypto can take you surprisingly far in this case:
http://lunkwill.org/cv/logcrypt_update.pdf
Abstract: Logcrypt provides strong cryptographic assurances that data stored by a logging facility before a system compromise cannot be modified after the compromise without detection. We build on prior work by showing how log creation can be separated from log verification, and describing several additional performance and convenience features not previously considered.
--Just the place for a snark!
Yes but Hipaa is pretty generic. Most of the Hippa regs are Already state requirements for many states (though not nearly all...)
How much is your data worth? Back it up now.
I work for a software company that has just developed an innovative solution addressing the immutability of logs.
It is not OSS but we are now going through a beta program and if your company qualifies for it, we could certainly solve your problem.
Let me know if you are interested,
Best regards
take the first day's log and get the md5sum for it. use a starter key to encrypt and zip the logfile.
the next day, use the md5sum of the previous day's zipped log as the encryption key for the new logfile.
once this system is in place, and change to any logfile would change the md5sum and then it would be unable to decrypt the next day's log, which means it was tampered with.
every logfile would have to be re-processed to tamper with one log. if the person doing the tampering doesn't know how the system works, there will be a trail of evidence.
or something like that.
You'll never roll-your-own comparable solution for cheaper than SenSage/EMC-Centra.
There, done.
Not everyone needs gigabytes of log data every day, or even hundreds of megs. If you're designing something to meet extremely demanding requirements, you're clearly going to make design decisions which involve more development time and expenditure than if you were designing to target less extensive requirements. On the low end, one can keep logs on random-access media (with offsite backup) and contract with a third party digital notary service such as Surety or DigiStamp to make them tamper evident.
Nearly as capable as the SenSage solution? Of course not. Cheaper? Hell, yes.
/dev/null would be great! And you could use /dev/random to read it! ;-)
/dev/writeonly and pipe it through a socket into a file. That way you could only feed in data. Pass the socket data to a program/driver/something to write the data to a file in which only that single program can write.
;-)
But in all seriousness, would you not be able to create something like
Just a thought.. I have no idea if it would work as I'm at work in a Windows-freaking-only environment. *sigh*
P.S. - And no! I will not get back to work!
Let me first state that I'm a PCI Qualified Security Assessor. That means I am certified by PCI to perform audits and report back to banks whether or not a company is compliant or not. In other words, consider me authoritative on this matter.
When dealing with any PCI requirement the most important thing to think about is the INTENT. Is the intent of the logging requirements in section 10 of the PCI DSS to prevent anyone, anywhere, from EVER being able to modify log files? No! The intent is to prevent a compromised system from altering its own log files--hiding the fact that it has been compromised. As long as your logging solution handles this situation effectively you really don't have anything to worry about.
In my role as auditor I would never fail a syslog host just because it was writing to a standard ext3 volume. I *would* fault a company if their logging solution was poorly configured (insecure: say, running telnetd) or was write-accessible by the same admins that send all their log data to it (unless they were a small company--if you only have one or two admins there's only so much separation of privilege you can get away with). I'd also have problems with a syslog host that wasn't backing itself up on a regular basis (90 days online, 3 year archive).
If I were you I'd be more concerned with your logging system meeting the other requirements of the PCI DSS. If it is inherently insecure or fails to implement proper access controls (say, shared root account) who cares how the logging solution is configured?
Remember: Intent is everything. If in doubt, call your acquirer (i.e. your bank). They're the ones who ultimately have to decide whether or not your implementation is good enough anyway. The auditor just writes a report--the bank has to sign off on it.
-Riskable
"Those who choose proprietary software will pay for their decision!"
You have 2 systems, the system you manage and audit, and a second system that someone else manages. You periodically (daily, hourly, minutely) archive your log files to the second system. The second party can easily make it so that you can read anything you've sent there, write a file only once, but not modify it or delete it. They manage it, not you.
I like to do this in Solaris with syslog files. Those aren't audit files per se, but anything logged by syslogd can easily be sent to a host rather than to a log file, or both. There's nothing that says that other host has to be something you manage. It could easily be a host that your local security officer manages and won't ever let you touch or even get physically near.
For files that the Basic Security Module (BSM) generates, I haven't quite figured out how to have a WORM system, other than archiving them off of the server daily. Once they are archived by the local backup team, they are out of our hands at least...but there's nothing preventing them, other than ethics, from altering their copies.
I think the best you can hope for is a good 2 system setup as I describe above, but in order to check & balance both sides, you keep a checksum of the file before you send it and they checksum it after receipt. The checksums should always match on both sides, and neither party should have access to the other party's system.
My company writes all of the logs we don't want altered to the database, then uses Crystal Reports to pull the data out for display. For our clients that have purchased Crystal to write their own custom reports they access the tables via a read only database login so there's no issue of altering the data. We also maintain a change history of all table edits and keep track of the locations in the system a user touches for HIPPA reporting.
If you want to make sure they logs are read only I'd say you need to use a similar route.
UDF format for DVDR or CDR allows almost arbitrarily small writes. Unfortunately there is no UDF format support for Linux for CDR or DVDR, only CDRW and DVDRW which have a different blocking structure. Can someone tell me why this is the case? Toast and other packages can do it on commercial operating systems.
Don't get me wrong, I completely agree some things should be set in stone with respect to audits and what have you, but let's consider the facts: a company that's under pressure from whomever enforces SOX but has quite a large volume of cash on hand will generally find a way to alter some logs were they keen on doing so. Even using some sort of feedback loop encryption/hashing method might be circumvented, albeit harder.
Smaller companies won't do it, but the big fish can probably bribe the right people when needed.
If you need it kept secret, encrypt it with a really good algorithm. Then seed it through bittorrent/P2P and it won't be possible to change or remove ALL those copies.
"Slashdot requires you to wait between each successful posting of a comment to allow everyone a fair chance at posting a comment.
It's been 43 minutes since you last successfully posted a comment"
PCI-DSS 1.1 requires that cardholder data is encrypted during transport only if the network an open public network (such as the internet or public wireless networks). It also requires that certain information such as the primary account number (cc number) is not stored in a readible format. One may use strong public key encryption, one-way-hashes, and the like. So you can log an md5 hash of the credit card number, but not the number itself.
LedgerSMB: Open source Accounting/ERP
Would someone please mod the parent up? This is the first time I've seen a Slashdot commenter abbreviate "the Health Insurance Portability and Accountability Act" correctly.
(What with all this talk about audit logs eating up tons of disk space, I find myself wanting to play "Hungry Hungry HIPAAs"! *rimshot*)
I'm proud of my Northern Tibetian Heritage
That would be the "Health Insurance Portability and Accountability Act," or "NAMBLA"..?
"Slow down, Cowboy! It has been 3 years, 7 months and 26 days since you last successfully posted a comment."
Another correct Slashdot commentor!
I'm proud of my Northern Tibetian Heritage
You are joking? Ha, ha, ha, good one.
What would one do when a machine in the network goes bananas and generates 1000000 alerts you where not anticipating. I hope you have a warehouse big enough for all that paper.
IANAL but write like a drunk one.
Paper is not searchable, is cumbersome to handle, expensive, and in any machine with a modicum of activity you'll not have enough of it (lets forego ecological considerations, which we shouldn't).
I any moderately sized datacentre the proposition of using printed logs is frankly childish.
IANAL but write like a drunk one.
Unless your computing infrastructure is a sole machine doing pretty much nothing, this "solution" is bullshit.
Once you have a few tens of servers only a mad man would consider this "alternative" seriously.
IANAL but write like a drunk one.
As long as the people administering the CA hosts are not the same administering the log servers and this is demonstrable (password file :-) )
IANAL but write like a drunk one.
There are products out there to secure connections, at the very least one can use an ssh tunnel, but that still leaves the problem of man in the middle attack (there are commercial products that do host authentication by meeans of key repositories, but none free I would know of, although making a key repository should not be beyond the realms of an enterprising Engineering team).
IANAL but write like a drunk one.
And let the crooks run amok again.
What is needed is sensible controls, many of the provisions are unnecessary, but a law like that is needed to make sure the big wigs behave.
IANAL but write like a drunk one.
Backup your log files in a suitable time frame and encrypt those backup logs with the public portion of a gpg key. Ensure that the private portion of the key (ability to decrypt / alter the file) is held by someone other than the resource owner (keep it in a safe, etc...) for which the logs are being generated. Keep an unencrypted instance of logs as needed for other tasks. Refer to the master, encrypted logs as needed in the event of forensics. Retain encrypted files on tape other other medium consistent with other requirements. This should work for PCI DSS 1.1 if the frequency of the backup is within 10.5 guidelines.
What exactly is so unalterable about paper? If you're keeping huge lines of paper with all the tabs unbroken or a single long sheet, maybe. If you're printing out pages, etc, then the easiest way to "alter" a piece of paper would be to just print out a new copy with different data, and replace the old. No, the old copy can't really be changed, but who can tell whether the current copy is in fact the original?
Lawyer: "Yer Honor, I have here a cryptographically signed original document that contains the logs in question"
Me: "I just rerouted DNS and BGP, replaced the CA, set up some cryptostrings, rebuilt the document and backdated my changes. Care to see the new cryptographically signed original logs that say something different?"
Judge: "Huh?"
At some point you have to have a human with a viable reputation involved. That human's testimony weighs more than the testimony of a person of unknown moral character. I know dozens of people who can perfectly fake any logging system you like, because they understand how PKI works and where computing technology stands. Essentially, if I build a system, I can subvert it - if not after the fact, then certainly during the buildout. I get tasked with HIPAA stuff because I have a known reputation - I teach Sunday School at the UU Church, I adopt children even though I am fertile, I have been badly beaten by police for refusing to lie, I follow Kant's "categorical imperative", etc. etc. etc... People know I will not be a party to anything dishonorable.