And you Thought SOX was a Nightmare

[Dave La Mar]

Just when we thought we were done, along comes PCI compliance.
If you haven't addressed this yet, you are in for a real treat.

I would greatly appreciate any input regarding the compliance
as addressed by you in the below areas.

(Note: All points will be assigned when the thread is closed.)



What are some things you are doing/using for the following:

1. "Data at rest" EVA 5000
2. Offsite tape. Veritas with LTO
3. All unix at 11.11 v1
4. Oracle 9i db.

Additionally if you have these environments:

1. "Data at rest" VSAM/SAM [KSDS/ESDS/SAM] on 9394 B23 RAMAC
2. Offsite tape. IBM 3480 Parallel channel attached.
3. VM 4.3.0 VSE 2.5.2
4. DL/I db.

TIA

-dl

[A. Clay Stephenson]

Thankfully my organization doesn't have to deal with credit card transactions but given all the breaches (some of them state-of-the-art stupid) that have occurred clearly some auditing is warranted.

Having learned my lessons from the SOX adventure, the very first thing that I would determine is who the auditors will be and what are the standards. With the standards coming from a non-governmental body, they are likely to be better defined than those of SOX -- but with any luck, the standards will be written around WindowsXXX and the auditors will be PC experts who are unable to spell UNIX.

From a real security standpoint, I suspect that some of the things that might buy you something are encrypted file systems (EVFS) and being able to demonstrate that your backup media are encrypted as well as securely stored off site. Alas, EVFS is only available as 11.23 and up. You could probably make a strong case for setting up a very attractive honey-pot and that could be a valuable tool to look for real-world methods of attack.

[Denver Osborn]

1. Testing EVFS (min 11i v2) and researching hw encryption appliances.

2. using DP and encryption w/ it.. maybe veritas can do the same.

3. ditto... so if we decide EVFS is the way to go, means we need to upgrade several boxes.

4. No DB, but Oracle 9i should have something out there to allow you to encrypt the data.


I'm leaning towards an inline encryption device -vs- a software solution. Minimal impact to the node/application and it wouldn't take as much to implement. Down side is the cost.

-denver

[Heironimus]

I think my work in the financial industry predates the official PCI standard, but here are the practices I saw.

First the easy stuff, most of which you should have already done. Disable telnet, ftp, and the r* commands (plus anything else you're not using). SSH or SSL for all your connections. Disable direct root logins from the network and strictly control access to the consoles. Lock the passwords for all application accounts and have the admins use sudo (or another product with similar functionality) to get a shell. Put heavy restrictions on any network install points, like an Ignite or NFS server.

If you're storing confidential information in the database you should look in to encrypting the data in those columns. But what I remember of the PCI document seemed to make it very inconvenient to use software encryption keys, and hardware security modules get expensive pretty fast. Plus you need support for that at the application level.

I remember seeing that Oracle can encrypt the traffic on the wire between the client and server, but I never saw that implemented. It was on the to-do list, though.

[Robert Fritz]

Hi there,

Just to dovetail on what Heironimus suggests for implementing overall lockdown best-practice, you may consider trying HP-UX Bastille, an automated tool to do that: http://www.hp.com/go/bastille.

Also, for security-bulletin compliance, also an important part of regulatory compliance, I'd suggest using Software Assistant: http://www.hp.com/go/swa

[Olivier Masse]

Securing a production system is not an easy task, since many things can break. One thing that these darn security auditors thought me, is that when installing from the ground up, always have security in mind -- the best time to test your security is with a brand new system which isn't in production. Keep this in mind when you'll update to a newer version of HP-UX. Bastille can be very useful but be careful when in production.

I couldn't say for Oracle and DP, but for your HP-UX servers one thing I suggest you try is running Nessus against all your servers, including your Windows EVA storage server. Nessus is available on Internet Express for HP-UX, but you might prefer just grabbing the lastest 2.x version for Windows. Be sure to update the plugins tree before your scan. Your security auditors will most probably use a network scanner like this to find out easy holes such as old OpenSSL versions and useless anonymous ftp or telnet/rlogin services.

IP Filter can be VERY USEFUL against network scanners, I use it very efficently now but it took quite some work. The advantage of IP Filter is that with this tool, you won't need to have to mess with inetd.sec, TCP Wrappers, Oracle filters and application-specific filters ever again.

If they ask for a valid, non priviledged login on your system to try to hack it, chances are they'll scan it for setuid files or known exploits. In that case, be sure to have every updated security patch available on your systems (use SWA or security_patch_check). Be sure you have no setuid or 777 files/directories. You can use my tool available here: http://www.mayoxide.com/ncops if it can be of any help. Also check if you have any NFS-exported diectories, and disable root or read/write acces if possible. They might also run crack on your password database, if they can. With 11.11 you don't have shadow passwords so you'll need to convert to a trusted system, that's also a big step (I prefer shadow password). If you can't do this, at least disable all useless accounts and be sure that passwords are hard to guess. A password like AFgT%13$!; is the kind you'll need to consider.

Good luck

[John Payne_2]

Well, we have been working on this for some time. The funny thing about PCI compliance is that people tend to have differing opinions about what it means...

We are nearing the end of a fairly large server readdressing project. A number of our servers no longer have direct accessibility to anyone, even on our intranet.

We did a lot of work with role based access, host based firewalls, and all that sort of stuff.

We are currently working on doing encyrption (Oracle 9i) for the DB that contains the credit card info.

Yes, it's an absolute mess. We are nearly done, I hope to be able to go back and do real work again... (Just Kidding, sort of.)

John

[Heironimus]

In principle I like host-based firewalls. In practice it requires that your OS admins become firewall admins too. I can do that, but many admins I've worked with would have a great deal of difficulty with it.

In truth, I'm not sure that PCI really says much about the OS layer beyond general high-level best practices for security and user management. But securing the database and application layers without also securing the underlying OS is pointless.

That being said, I'm not a PCI auditor and I'm no longer working in the financial industry. It's all a question of what your auditors will look at, which seems to be dictated by generic checklists rather than a real inspection of your environment. The sad truth is that IT auditing today is more a game than anything else.

[John Payne_2]

Yeah, it really does seem to be something that means different things to different people. I guess you need to see what it means to you. The PCI Security Standards Council has a document that lists their standard. (It's called 'Payment Card Industry (PCI) Data Security Standard') They don't give solutions, just lots and lots of sound bites.

John

[Jan van den Ende]

Well,

it has been a couple of years that we had a (full-week) security checkup.

I will not bore you with the Weendoze issues they came up with, but they widely surpassed even my wildest fears. (amongs other things, the passwords of ALL IT staff - without the matching usernames, but I believe them - my password was on that display, and several of my collegues admitted to the same thing.)

On the Unix side (Tru64) it was MUCH less fearfull, but, still several issues still.

After 2 days of trying, they asked if they could have a VMS account, because they could not get in, and still wanted to have an inside look. We gave them an account with command line access (which is more than standard users have).
After 2 more days, all they had to report on VMS was, that they DID have read access to several TCPIP files. But that is just because that ported Unix code is unable to understand the concept of execute-only access....

fwiw

Proost.

Have one on me.

jpe

[Geoff Wild]

Interesting - our PCI audit is based around access to the systems (physical but for the most part via application/software connections). We ran Vunerability Assesments on the servers and locked them down.

For example, we have users who are allowed to scp files from the prod servers to QA - but not vice versa.

For the "physical" bits like tape it's just following a process and proving who has access to the media.

Other things we do - the person who orders something for these systems is not allowed to receive the item - someone else has to sign off on it. Speaking of sign off - all user id request require 3 signatures - and they can't be the same person in all 3. (IE Applicant, Manager, and Application or Service Owner).

Course some obivious things like - root access via su only, daily access logs sent to a central system - which admins like me do NOT have access to.

Rgds...Geoff

[Dave La Mar]

Just to update all as to my query.
We have met PCI compliance as far as the network and server access is concerned.
The real issues reside with "data at rest" and offsite tape data.
The data of concern IS credit card data. The variance of our infrastructure, being both mainframe and HP-UX with differring databases.
There are many products we have looked at that address 1-2 items, but none so far that address all 4. The last product we looked at performed data encryption at the disk level which made tape backup encryption moot. What we are looking into further is how the product decrypts the data when authorzed access is presented.
Some good responses here.
Hope to see more prior to closing the thread.

Thanks.

-dl

[Dave La Mar]

I appreciate all the input provided. At this point we are still evaluating third party products that can service all environments here, mainframe, HP-UX and Windows. I hate the thought of separate products for each. Tape encryption on the mainframe and for Unix/Windows [Veritas] are covered. It is this "data at rest" that is still the issue for which a third party product will be investigated.

I tried assigning points equally, thus not all responses received the full 7, but did as an aggregate.

Thanks again for the input.

Regards,

-dl