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.
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.
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.
Besides logging locally to disk, also add a line to /etc/syslog.conf to log to a remote machine.
If syslog can write to a remote machine, then a compromised syslog can overwrite a file on a remote machine. I suspect thats not even remotely close to enough read-only.
As others have suggested, print your logs on a line printer.
There are shills on slashdot. Apparently, I'm one of them.
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 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.
That actually may not be enough.
The systems I've worked with take it a bit further.
Once the syslog gets to the remote machine, it is then frequently dumped to an enclave machine behind the remote machine where it is dumped into a database for analysis and the raw logs are burned to cd or dvd on an autochanger.
The only proprietary piece of the system I saw was the software used to pipe the Windows systems' logs to the syslog server, but there may be open solutions available.
The rest could be handled by GNU/Linux/BSD and postgres (if you want to do the database part). The system I worked with ran on Solaris.
A house divided against itself cannot stand.
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.
But that doesn't really scale very well, and then you have the problem of dealing with retention/storage requirements.
A house divided against itself cannot stand.
The remote machine should preferable save the syslog on a WORM device - for example a CD-R.
Its very hard to tamper with a write once CD-ROM.
Also it cheaper than the paper fed into a line printer option some people proposed in other threads.
Just saying it like it are.
That's all you need
Opus: the Swiss army knife of audio codec
Broadcasting your syslogs across a production network is probably not a very good idea.
Ideally, you have a back-side management network that is separate from your front-side production network. All of your logging/IDS management/network management happens on the management network and none of the sensitive traffic is ever visible on the production network.
A house divided against itself cannot stand.
Sure. but what keeps you from making a copy of the CD-ROM with certain info deleted or altered, and putting that in the archives instead of the original?
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.
i.e. Nothing really.
However, if you have the CD or tapes signed and dated by the ops staff, then shipped to off site security, you've made it harder to falsify.
The interesting issue is that if you are organized enough, what's to stop you from intercepting the messages on the way to the printer / CDR?
The only way I could see around this is some kind of trusted computing style initiative.
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)
Not with a properly configured syslog. You're not supposed to just use a remote logfile, but a remote logging daemon (RFC 3164). That way you can add entries to a remote log, but not change or delete any (unless you make the logfile directly accessible over the network, which I wouldn't recommend).
8 of 13 people found this answer helpful. Did you?
WORM media with HIPPA compliance in mind...
WORM on wiki
- mritunjai
Yes, someone could do that. But of course, all sorts of measures should be taken to mitigate that risk. I'm thinking Nagios or Zabbix installations that guard the fact that logging should come in. Hardened machines, firewalls, Tripwire, et cetera.
But of course, nothing beats a printout on paper.
8 of 13 people found this answer helpful. Did you?
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..
"Little does he know, but there is no 'I' in 'Idiot'!"
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.
Not if you're using some sort of data escrow service like OpenAccess
"I've got more toys than Teruhisa Kitahara."
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.
not if it's in a input stream only capacity... I admittedly don't know the details of syslog.conf and it's capabilities, but once you can send data to another computer, that other computer can control delete access. The uncompromised computer can just act as an append only log storage facility. I don't know quite how syslog.conf ensures that the logging isn't simply stopped or the source falsified. Maybe someone else can weigh in with answers
Gravity Sucks
So... what a special vpn for logging? or a totally separate wired network?
Gravity Sucks
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.
/dev/console be a teletype.
A simpler (and older solution) would be to have the syslog file be a printer or paper tape punch. Even have
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.
This is actually the standard approach recommended in places like "Building Internet Firewalls" and such. It does nicely with the write-once requirement provided that you have also secured the machine from tampering. Unfortunately it does not do very well with the "read many".
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
Commonly known as a backnet, yes.
Some of my company's bigger customers have their own private backend network for internal data (db queries, backups, etc) and only pass necessary data over their public internet pipe. Not a virtual private network, but a truly private network.
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
Hmyeah I agree a line printer is good as an addition, however paper is hardly searchable. I bet one of the requirements would be to have an auditing interface searchable by user, date, et cetera.
8 of 13 people found this answer helpful. Did you?
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.
A house divided against itself cannot stand.
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
Why, just tee it with one copy going to the remote syslogd on the remote secured machine, and the other copy being stored locally for easy access. Use the local insecure copy for day-to-day read-many access, and the remote secure copy for archival and legal purposes.
Yes, this will be write-twice, read-many, but that's much easier to implement than true WORM.
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.
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.
I think you missed the point, the problem is to stop people/programs to tamper with the log once its written...
http://www.intellipool.se/ - Intellipool Network Monitor
Write once thermal magnetic paper tape or digital optical tape
davecb5620@gmail.com
So burn it to CD-Rs (cheap, they have robotic arms for large-scale stuff) when you have enough logs to bother.
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!
That's easy; feed the paper coming out of the printer through some sort of OCR machine.
Take life easy: one bit at a time.
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
There's nothing to stop you from keeping an electronic copy for searching. It could even include page number references
What?
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 |
How do you figure that? There is no provision in the syslog protocol for random file access. It's very simple, you can only log messages.
Health Insurance Portability and Accountability Act, schmuck.
...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.
A dedicated Ethernet cable is also a serial line. Using TCP/IP on it helps ensure the data gets to the other end of the wire. Whether you use direct cabling or a logging-only LAN depends upon your needs, but I rather doubt you have so much logging traffic that it floods a LAN devoted to logging.
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
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.
Write once, read many logs are part of HIPAA compliance? That's news to me.
Agreed, it's rather stupid, actually. Someone sniffing plain text on the network could see failed logins, successful logins (and infer the times of the day logins are allowed) they type of logins (AD, local machine, ssh, console).
The commands they ran and infer the software on the machine, the network layout and machine names and thousands of other things that could be used to gather the information needed to compromise the machines.
Did I mention it's incredibly stupid to broadcast logs?
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.
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.
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.
While we may be able to see endless faults with any proposed solution that doesn't matter. He just needs to implement one that covers him and the suits above him should they be audited.
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!
The remote syslog would have to be compromised for what you suggest; there's no way to seek using the syslog wire protocol -- it's append-only.
But in a more general sense, if you can't trust the log generator and the log host, there's no way to construct this system at all, even with the line printer you suggest. If we're accounting for a compromised syslog on the remote logging host, then it could simply alter or supress the logs in-flight to the printer; a compromised local syslog could do something similar. Or the program generating logs could be altered to not supply certain logging messages.
There's no practical defense against any of those attacks other than trying to ensure general system integrity, and printing to paper doesn't buy you anything you wouldn't get with a generic linear media drive with seek disabled, or (if you can stand the buffering for big sectors) optical write-once media.
Novell Sentinel (formerly eSecurity) should meet your needs.
Wrong. The syslog protocol only allows you to write to send data.
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
I recently attended a SANS Summit on Logging. Its not about making it impossible to overwrite logs... there's basically no way to do that. Every suggestion here pretty much has a reply to it about how to get around it. Its not a technical problem to solve, its a policy one.
Given a non-tiny operation, its fairly simple to reach compliance (IANAL). The group that runs the payment gateway is NOT the group that runs the centralized logging system. Use syslog-ng to send the logs to a central server. The payment gateway guys don't get access to the centralized logging server, at least not write access. If you want, store the logs in a DB, and give them read access. They'll still have local logs for troubleshooting and such anyways, so they don't really need it, unless they need to go farther back then the local server logs are stored. Backup the centralized logs regularly to tape, or whatever your backup setup is. If you're paranoid, store checksums in a separate area, email them out, whatever.
You can't make the logs unalterable. What you do is put policies in place to make sure that they are secure if the infrastructure you are logging is compromised, internally or externally. For example, the systems you are trying to protect don't need full access to your logging servers, port 514 (or whatever you pick) is enough.
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.
I've used NTSyslog with success to pipe Windows event logs to a syslog daemon on a unix box.
If the govt becomes a lawbreaker, it breeds contempt for law, it invites man to become his own law, it invites anarchy
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.
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 misread that as OCD, but it still fits.
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
For the most part I agree with you, but I don't want to downplay that there are some real technical hurdles in the PCIDSS requirements that do require actual creativity or money to solve at this time. To me, the hardest problem to solve is the "command line history of all commands executed as root". Keystroke loggers log too much, as do screen scrape loggers.
One nice thing to see would be a modification of the shell that will log to a specified logfile the command history if the effective UID is the targeted entry, not just the login name. Setting it in an auditable file also allows one to detect when it is bypassed (running a different shell, etc.)
But yes, most of the compliance points in PCI-DSS and in SOX boil down to "follow good security practice" and "have sane policy", making compliance easy if your management is willing to ensure that security is a concern and policy reflects a realistic approach.
"I may disagree with what you say, but I will defend unto the death your right to say it." -- Voltaire
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
To me, the hardest problem to solve is the "command line history of all commands executed as root".
Don't allow any logins as root, period. No keys, the password should be unusable. Then you can log everything done via sudo just as you do with your normal logs.
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.
Who said anything about logging in as root? You need to capture the data even if they log in as themselves and do a `sudo -s` or `su` so that they can do the types of SA work that is rather difficult in single sudo commands, the kind of thing I do literally all the time.
sudo is a good tool, but it has definite limitations.
"I may disagree with what you say, but I will defend unto the death your right to say it." -- Voltaire
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
At no time should anyone be logged in as root, via a key, password, su -, etc.Yes, it can be a PITA at times, but it makes everything trackable. That's the price you have to pay for due diligence.
True, they are getting cheaper too. Infact you can set up one hell of a home piracy operation for 40K, and the only thing tipping people off would be that the Staples van keeps coming to your house and droping off spindles which when empty stack out of your recycling bin.
Not that I'd know for sure or anything....
How much is your data worth? Back it up now.
How in the hell do you get a comprimised syslog?
Just curious, not that I know anything about it, but it seems that that machine could only be compromised by physical access.
How much is your data worth? Back it up now.
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.
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.
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?