DB2 Configuration

1. Slide 1:
Hello, I'm Roger Miller, and I'm here to talk to you today about DB2 for z/OS best practices. I'll talk about a number of techniques - what you can do to make your security a little more safe, because there are so many different ranges of needs, so many different objectives. For some situations your basic security is quite adequate. For others, you'll need better or at least standard security techniques
and in still other cases the absolute best security practices are demanded. Our tools range from
very tight system controls to fairly basic techniques applicable even with public information on the web, because you certainly don't want your information to be taken away, changed to embarrass yourself. Application security techniques are absolutely more flexible, but generally they require much more work
by more people so they are generally weaker. So the choices and guidelines will be what we're talking about primarily, talking about how to provide improved security for your situations. The objective here is to help you understand the range of choices, the improvements, and how to make those incremental enhancements. Certainly there are more places and more resources, and you'll see that the notes and some of the slides take you through.
Slide 2:
So let's turn first to slide two and note that we have a couple of disclaimers.
We're going to be talking in some cases about version 10, but indeed we also have a standard pieces, and
a lot of this is judgment calls, not standards and hard facts.
Slide 4:
So let's turn to page four. I'm going to skip over the agenda and talk a little about a security framework, because IBM has changed a lot in the past few years, talking about security and the structure within which we build security. And indeed a security framework and a security blueprint have evolved.
slide 5:
Here on slide five talks about what are we doing
within the blueprint within that framework. And I'm going to be focusing on just
the information security aspect, but we have to remember security has to fit within this broader context. So I encourage you to look at the security frameworks, the security blueprints. We have resources, and particularly the web address at the bottom of the notes on this page is something to help put you in the right context as we talk through security in more detail.
Slide 6:
Let's turn to slide six. Certainly system z has a very solid reputation and a well deserved reputation as a place that has world class security - world class business resiliency. Business resiliency is that
combination of availability with the ability to change and keep your applications running in spite of needing to change some of the definitions underneath them. And so from the

2. 1970s, the 1980s some of that work began with commitments for system integrity, system security,and we've continued building upon that structure with a solid access control identification authentication. And as we've been building over the past decade or two, we've been building in stronger and stronger encryption solutions
for the data and building them into the hardware, building the system software on top of that for both the cryptographic performance acceleration,as well as centralized key management, because in some sense
encryption is not hard. Key management is hard. Then we've been working for a broader picture, because Tivoli is our key brand for a lot of the security across all of the platforms in collaboration with the
enterprise security management. So TIM for identity management, TAM for access management as well as audit pieces like zSecure. Then DB2 integrates deeply into the platform, both the hardware and the software and tries to build that security end to end. And so our history, our experience has really
yielded a well earned reputation as the most secure platform. So we'd like to talk through that.
Slide 8:
Let's go and turn to page 8 and just talk about the kinds of attacks that we face. The attacks that have the highest probability, the ones that we see most of the time, are at the top of the slide.
The ones which have the highest complexity and the lowest probability tend to be at the bottom of the slide. Errors and omissions are absolutely the most common form of problems, and these are often something that you can address with security. Sometimes it is a human outside of our systems.
The second most common problem tends to be the lost back-up, something that was in transit,
and we tend to see reports of these multiple lost backups every week. What has raised in commonality and access problems in the last year or two have been problems at the application user level. A technique called SQL injection hasgrown to be one of the common ways of challenging getting information back that should not be accessible. But, on the other hand, at the very bottom of the screen administrator access
tends to be more and more common as an issue that that we're being asked to address and it's not a very high probability, but it's a big concern today. And as soon as we say it's a low probability, of course we'll see the management article on slide 9.
Slide 9:
And here's a rogue DBA that steals and sells personal information A little bit old in the article, but indeed these don't tend to be very common, but once you see, it certainly needs to be addressed. So
a lot of this presentation has been built up from having a customer call, and they'd ask me something like, "We've decided to grant SYSADM to public. Don't you think that should be a best practice?" That's obviously one of those worst practice situations. But as I worked through, there were certainly some -

3. it's easy to administer! And that's often the contrast: easy to administer vs. least privileged, there is an inherent conflict. To manage tightly generally is going to require more administration. And so
certainly you'll want to avoid the worst practices - the no security kinds of instances unless you don't have data that's worth anything, not even worth your reputation. The basic or low kinds of security may be applicable. This depends on what is needed in different situations. But most customers have a number of needs for standard or medium security, and some of your data probably needs the best practices or high security standards.
Slide 11:
So let's turn to slide 11 and talk over some of the key security tasks, because identification and authentication are generally taken care of by the security subsystems. On system z and z/OS, you'll generally see this with RACF, ACF2, Top Secret, and wherever possible this is done in the security
pieces. Now access control - a part of that is also shared with the security servers, but most of it
for DB2 is within DB2 access control. That's what we'll be spending a fair amount of time on. I'm going to also note that there's a number of other tasks for security that we're not going to deal very much with today - confidentiality and privacy have some work within access control, and we'll talk about some of those techniques. Data integrity - a redbook publication that's a little older talks about data integrity fairly clearly and concisely. We recommend that for a key source. I will be talking about some of the key auditing techniques. although often to work through audit takes some tools that will go beyond the scope of our hour today. And then the security management and intrusion detection - again goes back to the security subsystems, the Tivoli work in almost every situation.
Slide 12:
Now the operational environment here on slide 12 is complex. There's no denying that. And it's inherently complex. Indeed users come from many different environments, and the security in those environments differs greatly. There are a lot of different sources and varieties of user IDs, because we do have a history and a legacy of security that comes from IDs prior to having subsystems take over all of
the work. There are many different security and audit products, and certainly RACF, Tivoli, ACF2, Top Secret, but also in audit, there's another half dozen or dozen products - three or four that comes from IBM in fact. And then some additional complexity comes because there are many different options for security - a number of different exits, a number of different applications that control and access. And
inside DB2, again we do have different kinds of interfaces, different types of access. Utility access control is different from access control for commands. Access from the environments of IMS, CICS, MQ,
a batch, the online access is a little different. And then coming in from a web, whether it's a DB2 Connect or another type of product, whether it's a WebSphere coming across with something coming through with access. Then stored procedures - they've been with us for

4. about a decade. Stored procedures can be written in a variety of languages whether it's Java or COBOL or C or SQL - native SQL procedures and
now utilities even run within those stored procedures. So we've had to mix our varieties and our access controls and techniques across these environment issues. And that leads to some inherent complexity.
Slide 13:
Let's turn again to slide 13 and talk about the subsystem parameters. This is fairly basic. The first question is use protection. Practice safe security. And indeed almost every customer does specify that authorization is turned on, but a fairly basic audit - make sure that this is so. Another set of questions is who are the install SYSADMs, who are the SYSOPRs, are these people groups or are they roles,
and who are the individuals in back of those groups and roles? Rather than using individual users, particularly these administrators, should be groups and roles whenever possible. Then the next level of question is how about the other administrator authority? The DBA is fairly classic - needs to have a fair amount of access, but perhaps a little less than one might imagine. One that we see being passed out
too often is called MONITOR2. MONITOR1 lets you look at your own information. MONITOR2 lets you look at information for others, and if you have data which needs confidentiality, MONITOR2 needs to be carefully controlled. Sometimes we have customers who say well anyone needs to run the performance monitors and
so we'll just have to have MONITOR2 for everyone. And that's an exposure for privacy if you will. SYSCTRL, PACKADM, BINDAGENT security and auditor administrators - making sure you know who can do what
and that the access is appropriate is a very key step Security settings for communication have a couple of keys. Indeed we've seen people trying to use ALREADY VERIFIED in situations that use TCPIP, and that does leave an exposure. The security settings for routines - making sure that they're appropriate, very
carefully controlled routines that can specify security for the user and go back to the end user or in some other situations having the security for the routine come from the binder. You generally want a little more control on what that routine can do in that situation. And once again, you'll want to keep
the security as integrated as possible with other subsystems. Virtually everyone uses identification and authentication from the other subsystems. I'd call that a standard practice. The access control has
a number of options and varieties, and so let's talk about them. First is security exits and interfaces.
There is a wide variety of security exits. There are many security interfaces. And the question will be
which routines are used and how are they used. First I have to make sure that you understand the key and the risk in these routines. These routines work essentially as an extension of DB2, so that if you make a little mistake in one of these exit routines, you could trivially give data errors inside DB2, it could take down DB2. With a little bit more egregious error, DB2 runs as an extension of the operating system, it's APF authorized, and your entire logical partition, the whole MVS machine can come crashing down

5. around your ears if you make a big mistake in these routines. So be very careful. These routines
can bypass security and can cause terrible problems. So who writes your routines, who tests them -
very key questions. We do have some that get provided from IBM that get tested fairly carefully - For example the access control for RACF, other vendors obviously do a lot of work. But if you're having someone provide a routine, making sure you know where that code is running is very important. Next
question on a lot of minds tends to be cryptography. And cryptography can be used for many different tasks. We sometimes have people say "People tell me I need to turn on encryption." If you end up with a general question, the questions that we have to ask right at the beginning help us figure out what kinds of encryption are appropriate and should be used. So the key questions - What do you want to protect? From whom? Those generally tell us the techniques and where to encrypt or decrypt. The last difficult question is who manages the keys? And so I put asterisks by the primary techniques. So let's start from the very bottom of the chart - Protecting retirement repair and loss of disk can be handled very nicely by full disk encryption, and so we see that as a key technique. It's not being used very much. It's been
in existence for about a year now. Tape back up is the second one, and that has become very widely used. Thousands of customers are encrypting their tapes. The technique is general; it is flexible; it is cheap.
The tapes that have been shipped since August of 2006, both the TS1120 and 1130, all include encryption in the controller, so your cost for tape encryption is simply turning it on, doing the management of the passwords. Just above that is on the wire. Now we have one that I will not recommended - DRDA encryption has been available since version 8. It's very lightweight encryption. What you'll want to use the omething stronger today. The lightweight encryption can be cracked far too easily with today's powerful processors. In the days of a one MIP processor, DRDA the single DES encryption was adequate. With one billion instructions in a classic machine running at 4 or 5 gigahertz, you really do need to use triple DES, you need to use AES encryption. So the SSL encryption that was provided with DB2 9, or using IPSec encryption are both strong and solid. And as the data goes out on the wire, you'll want to use those kinds of function. Now let's jump up to the DB2 edit proc. There is an IBM tool that I'll talk about on a subsequent slide. The key is that there are some edit proc restrictions, and the indexes are not encrypted. But this is fairly handy compared with the top two. With the top two, either outside of DB2 or using a field proc, relational range comparisons don't work. Relational range comparisons, that is
greater than, less than, so if your SQL says greater than or less than, it's going to compare on randomized values, the encrypted values. That is to say you're not going to get the answers you
thought you would. So if you're doing equals and not equals comparisons only, then it's very handy to
do the encryption outside of DB2, and indeed there's a number of programs and products, and ICSF is a component of z/OS which can be used to encrypt outside of DB2. There's an instruction built into

6. the z architecture which will let you do your encryption. The key management though is your task,
and that's the hard part as I noted earlier.
Slide 16:
So let's turn the slide to slide 16 and talk just briefly over the encryption at these various levels.
So we have the outside of DB2; we do have encryption and decryption built-in functions - don't generally
recommend that - it can be handy if you've chosen to do your key management yourself but that becomes the task. And you'll note that the more transparency you get as you go lower on the stack, the higher
complexity as you differentiate your security, and of course as you differentiate the task of key management becomes more and more difficult. I'll talk briefly about the security in hardware, because drive-level encryption certainly satisfies the encryption for data at rest, and that tends to be very commonly used. We use it on our PCs today. We can also use it in our enterprise class storage with that continuous real time encryption of the drives. As we've seen it, essentially no performance impact, no application changes. Key management on the disk is Tivoli Key Lifecycle Manager, which uses the key management via ICSF and RACF and actually stores its data in DB2. But then again your SMF standard
audit trail is what's used.
Slide 18:
Turn please to slide 18, and we'll talk because that was an interesting challenge. In 2006, we were able to get our tape management, because the tape controllers and the sequential access let us perform adequately, and it took us until 2009 to get the full disk encryption working with the drives from Seagate and the additional hardware from LSI to take out the performance challenge.
Slide 19:
The key management technique for tapes often uses the earlier programs, but then builds that in for the Tivoli Key Lifecycle Manager here on slide 19. So there's a lot of - key management - it's the hard part, and we certainly do recommend that you get a good key manager, and this one is solid key manager. The predecessor had a couple thousand customers.
Slide 20:
So let's turn to slide 20, and talk about using an edit proc. This is a tool that IBM offers today. And again, the data encryption, the data on disk, data at rest is encrypted. However, the data on the channel - the buffer pools are encrypted, the data to applications and indexes are not encrypted. It does let you keep working with existing authorization controls. It does allow both AES and triple DES encryption. Changes in the last year have improved this to allow both encryption and compression. And so a lot of that work - your copies, your log are all encrypted. That's all handy. We do have some improvements coming fairly soon for this encryption tool as well. So the key question: Is your data

7. encrypted? I sure hope so. Let's talk a little bit about service levels or maintenance, because one of the easiest ways to
have a security problem is to not put service on for a very long time. Basically with system z, we have
a more mature security approach. As I said earlier, we started in system z with commitments to security
in the 1970s, 1980s, and 1990s. And so we've been working at some of that for a long enough time that we've done a pretty good job. The later versions of DB2 certainly do have improved security function,
and I'll be talking very briefly about some of the security enhancements in DB2 9 and DB2 10. But in particular, Version 8 brought in command security in a better way, multi- level security, and some new encryption options. Now you do want to have current fixes on, because indeed some enhanced function
does come in the service stream, and a service for security exposures is shipped in the service stream.
On DB2, it's rare. We generally don't get involved in shipping out a critical patch advisory, because our
PTFs tend to not have anything that's critical.
Slide 24:
I'll skip over to slide 24 and just talk through some of the key concepts to make it effective, make
your security work for you. And the first rule is the KISS rule - keep it simple. You don't want additional complexity. People who want to crack in love the complexity, because in the complexity there's
generally a security exposure. One of these classics is choice of access control. Choose DB2 or choose external security - RACF, ACF2, Top Secret. It is handy that during a transition you can use a mixture
of both, but as soon as you can you'll want to have it all be one or the other. So the key questions -
How many people have administrative access? The number of SYSADM and SYSCTRL users in general should
be ten or fewer, even for very large systems where customers occasionally need the SYSADM, have a process
for occasionally getting that access. Even a person who works as a SYSADM almost every day should probably see if they can have another ID that doesn't have the high security exposure for their every day work. This is simply a putting in practice the least privilege principle - only have the privilege that you really need, make sure that the DB administrators need the access. What we sometimes see is that
many years ago there was one person or a few persons, a small group, who did all of the database administration, and now it's grown, and you have production database administrators, you have test administrators, but everybody has authority to everything even though that's not their current job task. That generally needs to be addressed. Making sure that those who have the SYSOPR, the MONITOR2, package administration, database control, and DBMAINT is also important, because these authorities are a little bit easier to abuse. Now I also do encourage you to use whenever possible system

8. authorities, views, groups and roles - should be the dominant if not the only the access control. At least within my company, the rule tends to be public access only when justified, and you can't justify it. Public access is something that hackers love, because so much of security is built on layers, and the public access means a free pass through this layer - something that is very helpful when a hacker goes through. Be careful with bind agent. A number of customers have a major part of their security built around bind agent.
Bind agent is very weak security It's not that hard for someone who has bind agent to get all of the authority of the person who granted bind agent. There's a lot of techniques possible to deliver EXPLAIN access without access to the data. Use those whenever possible if that's the only access needed. Now we do have a when to look at RACF for access control. I'll encourage you to get the latest of the changes. Our colleagues in RACF make changes for each release of DB2. And we've had a web cast on this, and presentations at SHARE, at GUIDE, at IDUG, IOD, address the work as customers change over. The keys for the most part are people and policy implications. If you have a policy saying that security group should be the definer of authorization, often having the security subsystem do that fits very well, if that centralized security control point can deliver very strong security, very strong audit. What I do encourage is to make sure that you use patterns, not individual access authority - access to user ID point A and then asterisk, asterisk rather than each individual table. As you make a changeover from DB2
security to RACF authority, note that people's roles will change, the authorities change. This isn't
a simple re-implementation of the same authority using something differently. It uses RACF. It is not completely compatible, pretty similar but intentionally different. And so read the documentation carefully. We've seen a number of customers be halfway through an implementation before they
read the fact that there were significant differences that made it very difficult for them. Note
that you need both DB2 and RACF knowledge for implementation and for the administration. We've seen
cases where the security administrators took over without much knowledge of DB2 and made some
interesting mistakes. Then get rid of that mix of RACF and DB2 authorization as soon as you can.
Slide 28:
So let's talk about application security. Indeed, we'll be talking about - so this is slide 28 - and we'll be talking about access control in an application, and indeed that is what is done. I describe that in most cases as fairly basic. It can't be nearly as strong. Using strong system security and views
is certainly better. Thinking static SQL really avoids a couple of classic issues. Your static SQL can never have SQL injection, because your SQL was taken care of at bind time. Static authorization rules - that's standard at least - making sure that the dynamic rules are taken care of by bind. Certainly if you're using dynamics SQL, use host variables for all of the input and then as your last resort input
checking. I really hate to see part of the SQL coming in from the keyed in the input, because the input checking is difficult to do and tends to be an exposure. And finally,

9. connect with a password is basic. It tends to have an issue It's very hard to change that password. Almost everybody who's ever been an application programmer knows how to connect with the password, including those people that you fired
because they were trying to steal from you. Let's be careful out there.
Slide 29:
Slide 29 talks about audit data. Auditing should be done by everybody, because simply said mistakes will be made. Nobody's perfect, including me. We will certainly see errors on this recording today. And since
nobody's perfect, there will be some mistakes made, and if you don't do any auditing, you'll never find and fix those errors. And so start out with the simple information - what's in the catalog? It's easy to query, easy to find the information. You can combine them with views. You can see who can see what fairly quickly on the most sensitive information. There are audit and other traces. Another mistake I've seen fairly common is that customers only do the audit traces; they don't do the additional traces. Doing
some of the key pieces is important, and there's a lot of other information that's highly relevant for auditing. On the next pages I put in a number of detailed notes of what you might want for auditing
and a couple of examples.
Slide 34:
So let's turn now to slide 34 and talk about current authentication in a three tier architecture. The key problem is the application server's user ID and password are used. And so we're doing something on behalf of the client layer, and in the DB2 side, that right hand, we don't know who the user is. All we do
know is that it's on behalf of the application server. Suppose it's SAP. It might have thousands of users, and all we can see is that SAP asked for a, b. and c. Not a very key when you start to say we can check the authorization, we can't do adequate checking on the DB2 side and we can't do adequate
audit.
Slide 35:
So let's turn to DB2 9, slide 35, and suddenly the application server is allowed to pass through who is the client, so authorization checking and the client information is passed on through so your audit and your security can be managed on a better basis.
Slide 38:
Another classic example that we see very commonly on slight 38 is auditing, and someone will say I need to have my DBA audit activities more secure and so we've allowed roles. Roles have a lot more flexibility. You can have the role if you logon in a specific situation or running a specific job
and did not have that role in other situations, so that really lets you use that trusted context.
Now the access is allowed to connect and do the database change and then log on in another situation, the

10. trusted context is not there and the ability to make those changes. It also lets you have an audit trace
that gives you a lot of assurance that the compliance was done as specified rather than in some other way.
Slide 39:
We've also added some work to do some end-to-end auditing - again have folks who do not have RACF
user IDs have worked in a couple of different situations. This is slide thirty nine.
Slide 40:
But I'd like to turn on to slide 40 now and just mention that we're talking about DB2 10. DB2 10 is still in beta, so now that we're in beta we have some other disclosures. It's not a generally available product, and so what I can almost guarantee is there will be changes before this comes out. All I don't know it's what they are. So let's talk about some of the work we've been doing for business security in compliance in DB2 10 and working in the beta. The first is ways to protect the sensitive data from priviledged users and to improve security. We have both security administrators and database administrators have an option not to have data access. It changes the role but if that's what your customers are saying - we need to have administrators who don't have data access, DB2 10 has this option.
It's an incompatible change I'll need to warn you, and it is an interesting one. For usability, having a database administrator for every database in the subsystem. We have customers who might have a thousand,
ten thousand databases, and you wouldn't want to be a database administrator on ten thousand individual databases. You tend to want to be the subsystem database administrator. A new option allows you to say I will want to revoke but I don't want to cascade. That's been a key demand where there's been a technique. It's been ugly. You have to make that person the INSTALL SYSADM, but many other ways. We've also have done a lot more separation of authorities to get different authorities. I'm going to show you that on the next slide. We've done a lot of work in auditing, and we've done some key work in row and column access control, essentially letting people mask the value so that you have one table, and we might give
me the real information while we'll give Paul a line of asterisks and we'll give Kate the last four digits of that number. So the key - minimize the use of SYSADM. So new granular authorities - we have an
INSTALL security administrator and the ability to take the security aspects away from SYSADM so
being able to have different pieces. The GRANT and REVOKE and a lot of the security mechanisms would be
controlled by the security administrator or SECADM rather than the SYSADM having all of that. I noted the system DBADM. And then we've had these other kinds of authorities, access control and data access, so
with data access, without data access would be your choices. Administrators for the SQL to be performance administration if you will or just the EXPLAIN authority so we have a number of more granular authorities

11. and the ability to say there is an install parameter which controls what can be done and if the install parameter allows you can say with or without the cascade revoke.
Slide 43:
Audit policies on side 43 are a key change that's an important one, because auditing has required us to
alter a table. Alter a table would generally invalidate your packages, and that would be too disruptive for a lot of customers. Putting this in with a policy definition provides better flexibility and better function, so you can manage these policies in the catalog. The security administrator will be doing this. You can audit the actions of privilege users. You can audit the SQL activity. And you can audit all of the non-z/OS distributed identities. So a number of key improvements for the auditing. And then the key changes that allow you to have that masking. So there's a lot of controls that can be put in table by table and essentially help you with who's running. Different people can see different pieces. It's
not taking a view. It is a security-only definition that gives this kind of access, which might allow you to open up some of your tables to access to adhoc query tools, because regardless of how people get to the table your access is controlled by this definition if you will. So policies rather than how does
it work.
Slide 45:
So a lot of key security benefits are coming in in 9 or in 10, again working for more flexible
authorization, better separation of duties, policies for audits and security control. So we think
the net of what you can get includes improved productivity and tighter security - what we often call ease of safe use.
Slide 46:
And so that's what we've talked about so far - security, good ways to significantly improve security, indeed with the flexibility that you need to do your business, deep level of integration into the platform, into the operating system, into the security subsystems, and down into the hardware. Again that key thought, our mantra if you will - ease of use for safe security, not ease of use by turning off the security, and a lot of work continues to go into assurance. You might have had a difficult audit lately. The audits for common criteria are a little deeper. We end up paying a vendor a lot of money to come in and check through DB2 in a lot of detail. We did a lot of that work for 8. The work for 9 is proceeding. The good news is they're finding a couple of little problems. Even better news - they've been very minor.
Slide 49:
I do encourage you to get the latest of your books. Get the information center and ask your questions there. We do have a number of keys. Please get the information.

12. Slide 50:
Redbooks continue coming. This one is slide 50. Indeed, you'll see a number of books here that talk about security and how to make those kinds of improvements.
Slide 51:
So I thank you for your time. I hope you have questions. And we'll see you on the web.