Know what you're protecting against

You know that advertisement where the CEO (Todd Davis) gives out his social security number and tells you how secure it is because he uses his company's product to protect his identity information? Well, there have been 20 people who used his social security number to get a drivers license. And there was one "guy in Texas who duped an online payday loan operation last year into giving him $500 using Davis' Social Security number".

Today, I read a few articles (including this one and this one) that suggest that LifeLock should be chastised because it doesn't protect you against everything that one might think it should. My first reaction was to agree with the writers. I always knew there was no way for a product to protect your SSN against any or all unwanted uses. And they shouldn't claim it does. And ha ha for Mr. Davis' identity being compromised.

But, then I read Davis' rebuttal, "There's nothing on my actual credit report about uncollected funds, no outstanding tickets or warrants or anything" and I realized that this isn't really a case of a product not doing what it claims to do. It's a case of mis-aligned expectations about what a product can (or should) do.

It reminded me of all the times I've heard that some strong authentication technique isn't effective because it's susceptible to man-in-the-middle techniques. Sure it is, but that's the wrong problem. SSL was developed to solve that problem. There are certainly issues with SSL (mostly around user experience and education about how it works), but strong authentication is not the answer.

In the same way, there are problems with relying on SSN as authentication. And LifeLock won't protect against that. But, if it keeps your credit report clean, then maybe it's doing what it's supposed to. I haven't really followed the ads and I have no idea what the company promises its customers, but I thought I'd use this opportunity to remind you of the old cliche – there is no silver bullet. Analyze your risks and know which types of threats a security solution will be effective at protecting you against.

Correctly aligned expectations yield happy customers.

PCI Compliance and Network Segmentation

I spoke at a CSO Executive Seminar on PCI Compliance in January. During my talk, I put up a slide showing a PCI reference architecture and went through many of the various security components that could help lock down an infrastructure and mapped each to the related PCI requirements. I covered topics like authentication, access control, IDS/IPS, anti-virus, encryption, key management, policy management, change management, rights audit, user monitoring, and a few others.

Before I began with that slide, I gave a disclaimer that there are a few key techniques that I would not include in the reference. One was network segmentation. I hadn't heard others mention it before in reference to PCI, but as I was thinking about my talk and building the reference architecture, it occurred to me that segmentation would be a really useful way to reduce risk in an environment where credit cards are accepted. So, I mentioned it in passing as something that companies should think about in addition to what I had on the screen.

Today, I read this article, by Stephen Cobb, in which he discusses PCI compliance and pays specific attention to the topic of network segmentation. I thought it would be a nice supplement to my talk back in January. In retrospect, I might have spent a bit more time on that topic, but I really tried to cover a ton in a short time. So, if anyone from that audience is reading this... Or if you're looking to improve your security or your PCI compliance posture...

The SecurID Killer

I'm a fan of RSA's SecurID product. It's got a highly secure approach, nearly indestructible hardware form factor, lots of form factor options, tons of partners and coverage for apps, servers and devices, and a flawless track record. But the competition has been creeping up.

Some try a similar approach to RSA with key fobs displaying numbers or other hardware tokens:

ActivIdentity
Aladdin Knowledge Systems
EnTrust
CryptoCard
MyPW
SecureComputing
Vasco

Others have a software only approach:

AdmitOne (formerly BioPassword) - uses keystroke dynamics
Arcot - uses PKI
PassFaces - uses user's ability to remember human faces
PhoneFactor - uses mobile phone as the device

Some are biometric:

DigitalPersona
L-1

And they all have redeeming qualities. But many are susceptible to keystroke logger attacks (which are getting more and more sophisticated). Others are cheaply made hardware. Some just lack partnerships and market penetration.

But there's a new kid on the block. And it seems to be a very cool solution that may quickly become a force to be reckoned with. It's a very small form factor, seemingly very secure, extremely easy to use, requires no client software, inexpensive, and works on any platform.

Welcome YubiKey to the arena.

I'll let you figure out the details for yourself.

It won't allow you to converge a single credential for physical and logical access and it won't work across multiple systems (unless it's used with OpenID or something like that) and it won't serve as a single form factor for multiple uses (like signed email and remote VPN). But, it's a pretty cool new entrant to this arena. And that's a feat in itself.

Let me know if I missed your company and you'd like to be added to the list.

File System Audit

Anton Chuvakin of LogLogic posted today on some of the intricacies of Windows native file system audit. If you have a need for monitoring access or changes to files, beware of the do-it-yourself method. Chuvakin provides insight on some of the challenges.

One of the things that NetVision engineers brought to market long before I joined is a very slick file system monitoring solution. Slick mostly because you have extreme control over which events you want to capture. You can filter on server, folder, file, person acting, event type (read, create, modify, delete, ACL or attribute changes) – you can even specify times of day to activate a particular policy. And you can have different policies for different files or folders. You can also choose what to do when an event occurs. For some events, write it to a database or file. For others, send an email too or kick off another process. None of it relies on system logs and the reports are delivered in a nice web UI running on Crystal Reports. So the business people get relevant results without having to understand the tech stuff.

Some of our customers even use our filtering to narrow down the events that are then fed into an enterprise security event management or log management system (like LogLogic). It's File System audit made easy.

Improved Security on the Identity Infrastructure

I wanted to expand on my earlier post about Extending the ROI of Provisioning. Here's a visual aide to help the discussion:

There's nothing new in this illustration. It simply shows that the provisioning engine connects to multiple identity data stores. As we know, provisioning systems have the potential to do a very good job at providing work flow and business rules around creation and management of user accounts across multiple systems. They may even have some additional capabilities around Separation of Duties enforcement, user attestation, user self-service password management, reporting on rights (based on its view), and more.

The Gap

What it doesn't do, however, is protect the connected data stores against direct access. For example, the DBA still has direct access to the database and the Directory Administrator still has direct access to the directory. They can create new accounts, view information, and change permissions. The system may be able to see when new user accounts are created during its next scheduled run, but that capability isn't always enough. I'll give an example.

One of these LDAPs is not like the other

I purposely shaded the Network Directory so that it stands out from the others. That's because it is different. Since the market for the Network Directory consists almost entirely of just two vendors (Microsoft and Novell) and one has a much larger percentage of the market (Microsoft), I'll just use Microsoft's Active Directory (AD) as the example.

Now, back to the gaps:

• Scheduling: When provisioning systems connect to AD, the connection and sync processes are often scheduled. And AD has a time lag in replication (usually 15 minutes). S0, if the sync is done hourly against a particular DC, the total time that a new account may be in existence on a different DC without being noticed by the provisioning system is a little more than an hour. Can you do damage in an hour? I could create an account, make it a domain admin, log onto servers, change rights, access files, and remove my trail from the logs within an hour.


• Coverage Scope: The connection may be made to a particular portion of the AD tree. So, if you created an account in a portion of the tree that isn't monitored by the provisioning system, it wouldn't get picked up.


• Source: Some provisioning systems use AD as the source. So, in that scenario a new account in AD would potentially create accounts and/or rights across multiple other systems. So, by specifying rights or group memberships, an AD administrator could grant himself rights to other connected systems (perhaps in between attestation cycles).


• Account Type: Provisioning systems generally only look at user accounts based on object type. So, you could create an iNetOrgPerson instead of a User object.


• Activity Scope: Provisioning systems don't even try to monitor failed logon attempts or failed user creates at the local systems. They also don't watch file open activity or file changes. What if the provisioning system pulls a feed from a text file and someone modifies that file? There's no knowledge of activity other than a particular type of account being created.

All of these can be applied to other connected data stores as well. For example, scope is an issue for relational database tables. The provisioning system may only watch specific tables or may completely ignore local accounts in the RDBMS itself. Likewise, if AD is not the source, the HR database is likely the source which yields the same issue for the HR DBA.

Conclusion

My point isn't that provisioning systems are weak. They do what they do very well. But, you can improve the overall security posture of the environment by including localized protection on the connected data stores as well. Encrypt the database. Monitor DBA activity and Directory Administrator activity. Watch directories for failed attempts to create or modify accounts. Watch for failed authentication attempts. In a nutshell, ensure that accounts and permissions are being managed through the provisioning system into which you've built the business rules and work flow to ensure that rights are being managed effectively.

And if you have to respond to auditors for compliance reasons, you can say you're certain that accounts are only being created according to policy; instead of you hope that to be the case.

I've heard the argument that this might be overkill (admittedly an over-simplified characterization of the argument). OK. In some scenarios, maybe you don't need tighter security. You only care about work flow efficiency and cost cutting. Or you're OK with the level of improvement in your security posture that traditional user provisioning systems provide. I'm not saying that anyone should ignore the risk analysis process. But, if compliance is an issue and you want to prove compliance beyond reasonable doubt or just simplify the audit process, solutions that locally monitor the connected systems may provide value.

And if you can demonstrate that 100% of your user and rights management processes are funneled through the provisioning system with appropriate work flows, I think you could justify claiming a much improved ROI on the overall solution with minimal additional investment.

Disclaimer? Yes, NetVision can help with reporting and monitoring on your Network Directories (both major vendors) and related file systems. But that's no reason for me not to talk about it!

SAP Identity Management Consultant

Matt's back! Matt is an Identity Management consultant who had the pleasure of working with me at MaXware. (oops - should I have said that the other way around?) Matt has since went into the consulting world and MaXware has since been sold to SAP. SAP has a short white paper describing their SAP NetWeaver Identity Management capabilities. Matt is now focusing on providing Identity Management services to SAP customers. That sounds like a good place to be. If you're an SAP customer or an SAP consultancy looking for expertise in the old MaXware identity stack, you might want to introduce yourself to Mr. Pollicove and start reading his blog for interesting info on SAP identity issues (no pressure Matt). You can also look back in my archives (most of 2006) for more info and interesting uses of SAP's metadirectory, virtual directory and provisioning technologies.

I've spoken to at least two IdM consultancies who are considering building an SAP practice. I think it makes a lot of sense. If you're in this space or building an SAP identity practice, feel free to leave a comment here and let us know about it.