| Subcribe via RSS

Considerations Around Application Encryption

December 22nd, 2015 | No Comments | Posted in Data Security, IT Industry, Security, Tools

person-encryption-623x420For years, the use of encryption to protect data-at-rest on computers within the enterprise was solely the responsibility of developers who coded the applications that used or generated the data. Early on, developers had little choice but to “roll their own” encryption implementations. Some of these early implementations were mathematically sound and somewhat secure. Other implementations, while perhaps not mathematically sound, were adequate for the risk developers were attempting to mitigate.

As technology progressed, choices for encryption matured and solidified across development stacks. Callable libraries were born. Algorithms were perfected, significantly strengthened and pushed into the public domain. And beyond application encryption, encryption itself began to offer benefits to the enterprise at an operational level – within turnkey, off-the-shelf solutions that could be aimed at specific enterprise use cases such as end-point data loss prevention (DLP), encrypted backups, and full-disk encryption (FDE) among others.

Today however, when CISOs and senior security, software and enterprise architects think of protecting data-at-rest, their conceptions can sometimes harken back to days of old and they will stipulate encryption solutions as necessarily needing to be implemented at the application layer.

And while it turns out there is actually no extreme fallacy in this thinking and some benefits at this layer remain, there are some considerations and tradeoffs surrounding application encryption that aren’t overtly obvious. These considerations and tradeoffs can get lost when not weighed along with more recent turnkey, transparent solutions that get implemented at a different architectural layer with nearly the same benefit yet with much less risk and cost association.

Let’s look at and consider some of the ins and outs of application encryption. Hopefully the following thoughts and considerations will help those who are deep in the throes of needing to make a decision around encryption of data-at-rest.
More »

Tags: , , , , ,

SailPoint IIQ Security Best Practices

October 15th, 2012 | No Comments | 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. :-)
More »

Tags: , , , , , ,