| Subcribe via RSS

SailPoint IIQ Security Best Practices

October 15th, 2012 Posted in IAM Development, IAM Engagement, IdM Engagement

Over the last several weeks I’ve been building out an entire Sailpoint IIQ development infrastructure on ESXi — every major version of Sailpoint IIQ since v5.2 on CentOS 6 (essentially RHEL 6), available over a number of major app server platforms for customer and development testing (eg. Tomcat, JBoss, perhaps WebLogic, etc.), including Windows Server 2K8 Active Directory, LDAP and other outlying systems. Today, as I considered the small data center I’ve been building out, I had “on-site flashbacks,” and I thought it would be a good time to talk about Sailpoint IIQ security best practices.

Easy To Forget!

We all get busy and it’s easy to forget — we’re supposed to be security professionals. A lot of you out there have a couple of forensics cases waiting in the wings, there’s that big virus scare Bob in Accounting let loose on the network on “Bring Your Son To Work Day” (yep, he plugged his son’s laptop into the network, didn’t he?! :-(), there’s the perimeter pen testing you and Jane are supposed to be doing on the 15 new apps destined this week for external rollout, there’s the latest audit report due (again!), and… oh yeah, there are these SailPoint consultants on-site the next two weeks helping you __________ your (new) IdM infrastructure, starting in dev (fill in the blank with “rollout”, “upgrade”, “assess”, “shakeout”, “test”, “customize”, or “all of the above” as it suits.)

As you may have noticed with barely concealed glee, Sailpoint IIQ is your new magnifying glass for IAG in the enterprise; it’s really good about going after the details at a minimum (based on RO connections to all your outlying systems), to say nothing of what you may be doing for certifications, reporting, provisioning and workflows — full LCM (if you’re on your way to IAG nirvana!) You’re going to nail non-compliance with this tool.

But what about the tool itself!? Have you stopped to consider the following best practices around secure Sailpoint IIQ deployment? It doesn’t do anything to fully amorize the front of the barn if other individuals in your enterprise can sneak in the back door!

What is your “threat footprint” for Sailpoint IIQ as “an enterprise application” itself?! (That’s the funny thing about Sailpoint IIQ — it audits apps, but it’s an app itself, when you think about it.) I’m not going to say a WORD about what I’ve seen anyone do. :-) Just make sure you are doing the following at some point when you’ve got Bob in Accounting up to sped on network policy and at least one of those audit reports done before your CISO has that meeting with HIS boss, the CEO. :-)

Change That spadmin Password!

C’mon now… This is Security 101. :-) Almost every application, layered product, operating system and any other OTS-ware has a default username/password that it ships with. If you are reading this blog, I’m going to assume you know what Sailpoint IIQ‘s is. You say “no one in the enterprise is going to know this!” and that may be only slightly true. Certainly Wendy the office assistant down the hall has no idea. (You have to help her login every day, right?!) But what about others?

“No one knows what URL we’re running IIQ on!” Oh yeah?! “Security by obscurity,” eh?! What about that DBA you’ve been working with on this Sailpoint IIQ deployment?! He knows you’re working on “something”?! What about the 2 guys on the Linux team and Sally on the Windows team you’ve been working with?! They know “something”?! You think the guy in network engineering that helped you with load balancing your Sailpoint IIQ servers doesn’t know the URL?! :-) These are people who have no business getting inside your IAG data safehouse.

So change that Sailpoint IIQ default password at least as soon as you have come RO connectors up and running and you’ve seeded your authoritative data. Good night, even a lot of “test” HR data is based on real people in the enterprise. So if you’re running any kind of production data anywhere — yes, even in dev! — you really should change that spadmin password!

Limit spadmin Exposure

I’m not going to talk a lot about this one, but as you move up in your environments from development to production, you want to limit who has access to the spadmin account. So you’ve changed the password for spadmin. Good job. (It’s not “BobAcctIsAJerk” is it?!) Now consider a different password for spadmin all the way up your environment stack, as your data gets more and more vitale and real. Maybe everyone in IT Security knows the spadmin password in dev. But not for production.

Lockdown DB Access!

Now, this one I can give you a free pass on. It doesn’t come to mind as readily. You’re busy getting Sailpoint IIQ up and running, you’re leaning on Sailpoint or a SailPoint Partner to help you ___________ (see list above… :-)). You’ve got (or had at the time) Installation manuals to follow and issues with the Unix team, Windows team and DBA teams on infrastructure delivery coordination, external stakeholders screaming in your ear about why they have to get on board with “your boss’ IdM initiative,” etc. (IdM is 80% people and processes and 20% technology. Your IdM solution partner advocated this, and you are seeing the reality of it right about… implementation time, whaddaya know!?) I know… I know… Details that aren’t strictly technology related but more PM related. Been there.

Remember that part about how Sailpoint IIQ is an application too?! Whoops… For some reason, the application that audtis other applications isn’t seen as an application…

When you’re done herding all the cats on all the other delivery teams and you’ve just reassured that caller #5 stakeholder… go ahead and seal up Sailpoint IIQ‘s backend database access. :-) Again, the configuration files ship with a default configuration for backend database access. You’re going to come up with your own secure DB creds, right?! Your enterprise has not only a procedure but a requirement for creating secure service account username/passwords, right?! (Usually the DBA team will be after you for this, but we can’t and shouldn’t assume. You’re the IT Security professional here. Be the head, not the tail. :-))

Implementing Strong Passwords for IIQ Setup

Let’s talk a little about one way you could actually implement secure creds in IIQ setup, assuming you are left to this on your own. Your enterprise may have other tools, processes and procedures available:

(1) Generate a STRONG, random password for your DB connection. When I say “strong” I’m saying at least 16 gen’d characters. More is better. I’m assuming you have IPS and other tools which are monitoring someone trying to brute-force your database and other servers.

There are a number of tools for generating good, secure cleartext passwords on the web. My favorite is here: http://www.pctools.com/guides/password

Here are the settings I use:

Another easy tool not everyone seems to know about can be readily found on many Unix/Linux command lines:

chris@linux:~> pwgen 16 1
Ogh1YusuHahbepho 

Wow, that was easy. And Bob doesn’t have to be a part of all your security-related service account passwords after all. :-)

(2) Use IIQ to encrypt your new secure password. Use IIQ console to encrypt your new secure password for inclusion in iiq.properties where the database connection for Sailpoint IIQ is setup:

chris@linux:.../identityiq/WEB-INF/bin> ./iiq encrypt Ogh1YusuHahbepho
1:hjtBxM3ekruH7/h3COCTYQQO0Eec3V9eSHaQwFHsNR4=

Now include that encrypted password in iiq.properties for the dataSource.password key. (You’re not going to use my example verbatim, are you?! :-))

   :
   :
##### Data Source Properties #####
dataSource.maxWait=10000
dataSource.maxActive=50
dataSource.minIdle=5
#dataSource.minEvictableIdleTimeMillis=300000
#dataSource.maxOpenPreparedStatements=-1

dataSource.username=identityiq
dataSource.password=1:hjtBxM3ekruH7/h3COCTYQQO0Eec3V9eSHaQwFHsNR4=
   :
   :

Finally…

Ideally, Use Different Passwords

Yeah, I know it’s a pain, but my recommendation is to use a different password for every Sailpoint IIQ DB connection that you make. That may translate to a different password for each environment (eg. development, UAT, QA, Production, however many you have.) But it’s worth it. And my recommendation is to do it for development as well. Why? Because (1) as an Sailpoint IIQ implementer this isn’t something you need to know on a daily basis anyway (it’s not like you have to enter the DB username/password all the time), and (2) because more often than not, some production-like data is going to sit in your lower environments. It happens all the time!

(I mean, who are we kidding here?! Between the audit team, your CISO trying to find a way to get a good night’s rest, and Bob down in Accounting, you’ve had no time to put together a good test bed of security testing data, right?! So you’re going to use production-mirrored or production-like data. There’s only 24 hours in a day, last you checked. This happens all the time.)

Implement For ALL Environments

I’ve already kinda covered it above, but my recommendation for reasons stated above is, do these things for every environment. So to recap:

(1) Change the default password for spadmin!
(2) Limit spadmin exposure.
(2) Batten down the backdoor hatch into your IIQ database!

Do not use defaults for either of these!

And now for the bonus round, now that you’ve got Bob in Accounting straightened out and you just discovered that last incident your CISO was asking you to look into was a false alarm… Transparent data-at-rest encryption for your IIQ data. (Your DBAs for one can still get to your cleartext IIQ data.)

Another time, maybe. :-) Okay, back to that ESXi build out I was doing…

Cheers from the Twin Cities!

(PS. More technical, Sailpoint IIQ customization, “how it works internally” and rule-writing articles coming soon… promise!)

Comments are closed.