Securosis Blog

It might be obvious by now, but the following charts show which DLP components, integrated with which existing infrastructure, you need based on your priorities. I have broken this out into three different images to make them more readable. Why images? Because I have to dump all this into a white paper later, and building them in a spreadsheet and taking screenshots is a lot easier than mucking with HTML-formatted charts

As I stated in the intro, Database Security Platform (DSP, to save us writing time and piss off the anti-acronym crowd) differs from DAM in a couple ways. Let’s jump right in with a definition of DSP, and then highlight the critical differences between DAM and DSP.

Since Rich is vacationing working hard at a security conference in Mexico, I figure I would write this week’s Friday Summary. I am pretty jazzed about some upcoming white papers I’ll be writing on securing data and applications at scale, understanding and selecting masking technologies, and why log management is not dead! And I am having a good time researching and writing the DAM 2.0 DSP series as well. I originally intended to write about our research agenda but changed my mind. Frankly, I…

We started the Bridging the Mobile Security Gap series by accepting that we can’t control the devices that show up on our networks any more. We followed up with a diatribe on the need for context to build and enforce policies which ensure that (only) the right users get to the right stuff at the right times.

It’s unbelievable how different growing up today is. When I was in elementary school in the late 70s, Pong was state of the art and a handheld Coleco football game would keep a little kid occupied for hours. When they came up with the Head to Head innovation, two kids would be occupied for hours. That was definitely a different type of Occupy movement. We also didn’t have 300 channels on the boob tube. We had 5 channels, and the highlight of the year was Monster Week. At least for me.

One of the coolest things about how we work at Securosis is our Totally Transparent Research approach. We always post our work to the blog first and let you folks have at it. In many cases it gets poked and prodded, ridiculed, and broken down. It’s certainly tough on the ego, but in the end makes the work better.

At this point all planning should be complete. You have determined your incident handling process, started (or finished) cleaning up directory servers, defined your initial data protection priorities, figured out which high-level implementation process to start with, mapped our the environment so you know where to integrate, and performed initial testing and perhaps a proof of concept.

As we discussed in the first post of this series, consumerization and mobility will remain macro drivers of security for the foreseeable future, and force us to stare down network anarchy. We can certainly go back into the security playbook and deal with an onslaught of unwieldy devices by implementing some kind of agentry on the devices to provide a measure of control. But results of this device-centric approach have been mixed. And that’s being kind.

Map Your Environment

No matter which DLP process you select, before you can begin the actual implementation you need to map out your network, storage infrastructure, and/or endpoints. You will use the map to determine where to push out the DLP components.

We love the Totally Transparent Research process. Times like this – where we hit upon new trends, discover unexpected customer uses cases, or discover something going on behind the scenes – are when our open model really shows its value. We started a Database Activity Monitoring 2.0 series last October and suddenly halted because our research showed that platform evolution has changed from convergence to independent visions of database security, with customer requirements splintering.