DOD Compliance

PierCed_3

ADSM.ORG Member
Joined
Jul 30, 2007
Messages
120
Reaction score
0
Points
0
Location
Brigham, UT
PREDATAR Control23

I need to find out what kind of tools or what TSM has built into it to ensure DOD compliance should "sensative" data hit backup or archive. How would I go about removing the data and being DOD compliant?

Anyone ever had to do this?
 
PREDATAR Control23

You have a number of options. You can look at built in encryption for TSM at layer 7; you can look at VPN for layer 3 encryption which works with layer 7, and you can look at 3rd party encryption which is executed via pre/post scheduled command or at the file system level.

TSM authentication is encrypted, rotating, does not pass a password across the network for authentication and is mutually suspicious. There is a good article written regarding this at MIT. This ensures the two endpoints; client and server are encrypted and secure with rotating encrypted passwords. In addition to endpoints you need to secure the data stream at the network level and the data storage on the storage device itself; namely the tape or disk upon which the data is stored.

As part of security you will need to ensure successful backups and that failures don't exceed a certain threshold in order to meet compliance standards. To achieve this you can use a number of 3rd party reporting tools to make sure your backups meet certain standards which are advertised on this website (Servergraph, ******** etc). These standards include:
Sarbanes Oxley (known as SOX) - http://en.wikipedia.org/wiki/Sarbanes-Oxley_Act
HIPPA, which is more geared to health sciences. http://en.wikipedia.org/wiki/HIPAA

Etc.

There's a few of them that monitor your compliance to all 4 major standards.

If you achieve the levels dictated by these standards (the reporting and monitoring will let you know this, or how close you are to it) coupled with a secure network (either dedicated private network to network (point to point) or VPN) with application layer security (either built in to TSM or 3rd party invoked, file system level or otherwise), end point security, facility security etc, you should meet any criteria out there from a TSM perspective.

Removing the data would be done by expiration policy, or you can simply delete filespaces which are TSM containers (volumes) which hold file system data. If you tried to view the tape manually you would see file spaces; inside these file spaces would be encrypted gobblygoup and only the proper decryption could make sense of the mess after a TSM restore.

The end points would be secure, the network segment (VPN) would also be encrypted so sniffing or 'packet sequencing' would also produce indecipherable garbage and be useless.

Consult with a Cisco engineer to determine a strong VPN encryption method which measures up to DOD standards but be aware encryption adds cycles and will slow down the speed of your backups.

I hope that helps.
 
PREDATAR Control23

I can't buy any 3rd party type of software for encryption and I can shred the data but it does it per tape not per filespace. I would just be in the same postion I am right now where I have 18 tapes out of my library and now my reclaimation will not run because those volumes are required for the reclaimation.

I just need to know if there is a way in TSM to erase/delete just the data that meets DOD criteria. The point behind this is I have had some sensative data hit my tape library, it is a quantum p700 with 555 slots and 4 drives. I would like to be able to give a better solution should something like this happen again rather than pulling the tapes and handing them to security. I want to say "TSM has this feature which does X" and this way I don't have to pull tapes and have reclaimation fail until I can delete the volumes per our retention setting.

Any ideas?
 
PREDATAR Control23

I have one library for backups (Quantum P7000) with physical tapes and I have 2 EMC 310 CDL units with virtual tapes. The 310 has a feature to shred the data but it does it per volume, not filespace. This is my problem :).

Thanks again.
 
PREDATAR Control23

If you're lucky enough that it's exclusively segregated by filespace,
delete filespace node filespace.
If it's not
select OBJECT_ID from BACKUPS where LL_NAME='file name' and HL_NAME='path under filespace leading to the file' and FILESPACE_NAME='filespace name' and NODE_NAME='node name'
Then delete the object.

Ideally, though, grant backdel to the node and have the person who knows what shouldn't be backed up run
dsmc delete backup
with appropriate options, including "-ALL" to go back and get inactive versions.
Also have your security people provide the appropriate patterns to let you exclude such objects in the future... whether it's specific locations, or file extensions.
You might need to have each node generate a "q backup / -su=y" every day, and repeated with "-inact" once a week, to verify compliance.

As far as satisfying the letter of the law, I don't know. Would those techniques satisfy your superiors?
 
PREDATAR Control23

FYI: I never was able to successfully complete a query on the BACKUP table; it's just gets too big. You can try it, but unless you have a really small tsm server, I wouldn't give it much chance of succeeding.

This is another thing that I am hoping will get 'fixed' when they cut over to DB2 for the TSM database.
 
PREDATAR Control23

yeah, Dan. If you don't limit it, a select on BACKUPS is huge. I once did a "select count() from BACKUPS" - no reads, just a count (I learned from a DBA, never select "count(*)"), and it took multiple days.
My DBAs are cleaning up their RMAN backups, and the contractor doing the work is greatly averse to doing the part of the cleanup where RMAN contacts TSM and deletes the objects, so I had to generate a list of all RMAN objects to compare with the ones they now consider the only valid ones:
bash-3.00$ cat getallrmanobjs
#!/bin/sh
{
date
tsmout "select NODE_NAME,FILESPACE_NAME,HL_NAME,LL_NAME,OBJECT_ID,BACKUP_DATE from BACKUPS where NODE_NAME like '%_RMAN' > /tsm/insmedia/sql/rmanbackupobjs"
date
} >$0.log 2>&1 </dev/null &
bash-3.00$ cat getallrmanobjs.log
Tue Jul 1 13:12:42 MDT 2008
Wed Jul 2 04:38:39 MDT 2008
bash-3.00$ wc -l /tsm/insmedia/sql/rmanbackupobjs
338664 /tsm/insmedia/sql/rmanbackupobjs
bash-3.00$

So, my point is, get your security people to as much as possible specify what shouldn't be in TSM. Surely they're not such <insert insult here> that they demand you go the other way. Even if it's as general as "all .doc and .xls files", it'll help. If they go demanding to examine all content, not just object names and locations, they're smoking crack.
 
Top