Thompson, Steve wrote:
[...]
Well, it seems that there are some requirements (by Auditors?) to have
data encrypted on DASD. Something about belt-suspenders kinda thing.
Well, we often hear about completely stupid auditor requirements. (Of
course it doesn't mean that all requirements are unreasonable.)
While I might have access to a file, I do not have authority to know its
specific contents. My reason for having access is so that I may delete,
define, etc. the container (DSN), but I am not specifically authorized
to know the contents.
RACF, TSS, and ACF2, to my knowledge, do not give that kind of access.
Yes, they give. For example see DASDVOL class. Last, but not least: if
you really want to see part of file content, i.e. given fields of record
or selected records - then you don't need access to the file. You need
access to *application* which in turn has the access to the file. But
the application filters data you can see.
Think PINs, medical info, SSNs, and other sensitive data that can be
contained in files of, say, Hospital, Court System, Credit Card
Processor, etc.
Sensitivity of data has nothing to do. The methods and techniques
remains the same.
When I teach RACF classes always start with the following "layers" of
security (in a few words):
1. Physical security - devices have to be secured. Even encrypted disk -
when stolen - does not work (think about DOS attack). For unencrypted
media and cable transmission physical security is even more important.
Maybe that's why our datacenters are not wide open... <g>
2. System integrity. Before I use any of the rules provided by RACF I
have to be sure that any program(mer) can bypass these rules by
"hacking" the system.
3. Resource access control. RACF, ACF2, other. Here we decide that
program(mer) who wants access some data is able to do that. Want to
browse SYS1.PAYROLL ? No problem as long as you are authorized to.
4. Encryption.
No RACF rule, no system integrity can prevent tape from being stolen and
read. No method to prohibit out-of-the-building data transmission from
being tapped. The only known way is to make the data unreadable.
And now we can decide what layer will be used for our DASD: 1. or 4.
Is my DASD well protected by physical means ?
If not then encryption is a must. For notebooks it seems obvious. But
for DASD arrays residing in well protected datacenter? I doubt.
One could say "why not combine 1. and 4. - it doesn't hurt".
Unfortunately *it hurts*. It hurts performance. We want our DASD to be
*fast*, so encryption of data stream could be a bottleneck.
There is still issue of DASD withdrawal. Encryotion ...does not help to
much! Encryption means you need at most nnnnn hours of time to decrypt
it using brut-force method, doesn't it? So I would want to wipe out data
from disk platters doesn't matter it is encrypted or not. OK, it does
matter: leaving unencrypted data is a crime, leaving encrypted data is
minor security breach.
Regards
--
Radoslaw Skorupka
Lodz, Poland
--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl
Sd Rejonowy dla m. st. Warszawy
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego,
nr rejestru przedsibiorców KRS 0000025237
NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi
118.642.672 zote i zosta w caoci wpacony.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
