CA DLP headed in the right direction

When CA acquired Orchestria, I said it was a good move. I even wrote a follow-up post about why Identity & Access Management (IAM) and Data Security/Data Leakage Prevention (DLP) fit so well together. 2 weeks ago, CA sent out a fairly lengthy press release with a list of products they've updated. The 2 products that caught my eye were GRC Manager 2.5 and DLP 12.0. This post covers the DLP product.

I spoke with Gijo Mathew, Vice President of Security Management at CA about the DLP announcement to get a better understanding of CA's strategy in the longer term and clear up a few things which confused me with their press release. Here are the "new features" for DLP 12.0 which I've lifted from the release:

• Enhanced Discovery – Provides the ability to scan data locally on endpoints and to scan directly into structured ODBC databases to identify sensitive data.
• Extended Endpoint Control – Leverages existing data protection policies to control of end-user activity such as moving data to writable CDs or DVDs, and taking a screen print of sensitive content.
• Seamless Archive Integration – Integrates with CA Message Manager, a product in CA’s Information Governance Suite, to help deliver end-to-end message surveillance, reporting, and archiving.

The first thing I should point out is that the ability to scan structured databases is a BIG plus. Many DLP vendors out there do quite a lot with either unstructured data (e.g. files on disk, data in memory) or structured data (e.g. databases), but they don't usually handle both. Orchestria fell into the "unstructured data" bucket. Now under the CA banner, they can finally support the ability to scan and classify data sitting in databases. Note however, that the ability to scan/identify/classify data and the ability to enforce controls over access to this data are completely separate things. To be able to properly enforce controls over structured data, a product would need to hook into the low level database security mechanisms. As a result, the enforcement of access controls into databases based on the content being accessed is difficult and very few vendors can actually do this at the moment (CA included).

While we're talking about scanning, CA also improved the way they scan for unstructured data. In previous versions, the scanning had to be performed from a central server. This is not ideal in many cases thanks to all the things that get in the way like firewall rules, security restrictions on machines, desktops not necessarily being available when required for scanning (either by being off the network or turned off) and so on. A more robust scanning strategy should support the ability to have the endpoints scan local data when required. It takes the load off the central server and allows for a more complete view of the environment from a data management standpoint. The new version of CA DLP added this capability. The negative however, is the performance hit taken by the endpoint while the scanning is being done (this is not a CA specific drawback - any endpoint scanner is going to impact performance).

The second point about the additional features around endpoint control (specifically regarding the mention of moving data to CDs, DVDs and controlling screen print events) really confused me. The examples given are supported by just about every single endpoint DLP vendor out there. I was shocked that Orchestria didn't have these capabilities. Alas, this was not the case. Gijo mentioned that they merely enhanced the capabilities around the CA DLP endpoint component and that these were some examples they picked out. The point CA were trying to make was around the fact that they still do the core DLP things expected of any DLP product worth implementing. Apparently after the previous release of DLP, many assumed they were no longer focusing on the core DLP capabilities and going down the "identity aware DLP" road. This is definitely not the case according to Gijo.

While the points mentioned in the press release are interesting in that they show CA are serious about core DLP capabilities, what impressed me most was the longer term vision CA has for the product. In fact, it is this longer term vision that had some accusing CA of neglecting their core DLP capabilities in the previous release.

CA are fortunate in that the natural evolution of products in the DLP space fit nicely with their need to work at integrating DLP with their portfolio of products. It makes product management decisions slightly easier for them instead of having to spend a lot of time trying to balance the need for additional features with being able to sell a cohesive suite of solutions (which is commonly the problem with acquisitions). In other words, adding integration points provides CA DLP with additional capabilities that make sense for most of the other products involved as well. For example:

• The ability to add context to access control is a very powerful thing. Context is very much about information, with data at its core (although it's not everything, because data alone does not tell us what a user is actually doing). What I'm referring to is commonly labelled as content aware access management. A common use case here typically involves integration of access control decisions by a web access management component (Siteminder in CA's case) with data aware mechanisms provided by a data security solution (CA DLP in CA's case). The web access management product can either make decisions based on static tags on the information/resource being accessed or dynamic analysis made in real time by the data aware component (e.g. this data looks like a bunch of credit card numbers so we should not be giving the user access).
  
• The analysis of data usage patterns across different environments allows for additional smarts when trying to manage risk, especially in cases where patterns are outside the norm of a user's peers. The trick here is being able to turn the data gathered into information to feed back to a GRC (Governance, Risk & Compliance) solution or SIEM (Security Information and Event Management) dashboard. Otherwise, you could just point any old reporting engine at the data and achieve the same result (which is far from what one would call proper integration).
  
• Access and data governance are typically silos in organisations today. If you're able to tie the two together, the management overhead is reduced significantly. That's why it's a big deal if an organisation is able to get a single view of both from a management standpoint. This is not to say it cannot be done today. The key point I'm making here is that it's just really hard to do. If a vendor makes it that much easier to achieve, it saves time and money.
• Improving the lifecycle activities around enterprise information and content management by using the data discovery and classification capabilities to provide additional context to the relevant processes.
  

I'll leave it as an exercise for the reader to figure out which CA product/s to slot into each example. The point is, they have something in their product stack to integrate with DLP in each example. What these illustrate however, is the direction CA are headed in with regards to the DLP strategy (even though some of it is a little high level).

Gijo was honest in acknowledging they don't have a lot of the things they want out of the box just yet. At this stage, many of the things I've mentioned (in terms of product strategy) will require a good amount of services work. I'm not going to criticise them for this as they only acquired Orchestria earlier this year and it's unrealistic to expect all the required integration to be built out so quickly, especially with a whole suite of products like CA's. What I do like a lot, is where they're going.

CA's strategy is good. They're on a journey and their DLP product is the jewel in their security suite from a competitive standpoint (against the other big IAM vendors). They also stack up well against their competitors in the data security space; in this case the advantage comes in the form of their IAM suite (and to a certain extent, their ever improving GRC prowess), which other data security vendors do not have. Those familiar with the security space might notice I haven't made any mention of the fact that RSA also have both IAM and DLP capabilities. Don't forget however, that it's a bit of a stretch to call RSA's IAM capabilities a suite (e.g. they don't do provisioning). They also have no real GRC capabilities to speak of (their GRC page is a bit of a joke).

As long as CA don't neglect the core data security capabilities in DLP along the way, they're going to do just fine.

CA continues to round out their security portfolio

Lots of interesting things happened last week in the information security space. This was largely due to the RSA Conference and the number of company announcements that coincide with it each year. Of course, Oracle stole much of the thunder by announcing their acquisition of Sun Microsystems. I've chosen not to comment on it because there's enough speculation out there (some informed, some less so). Also, I would have sounded like a broken record because any analysis on my part would have sounded very similar to my piece on the potential IBM and Sun deal that eventually fell through, but with an Oracle spin.

From a large Identity and Access Management (IAM) vendor standpoint, the most interesting piece of news actually came from CA. In fact, the only bit of IAM vendor news came from CA because the others didn't announce anything at all (I don't count "what the heck is going to happen to the Sun IAM stack" as news because at this point it's all speculation and is very much dependent on what Mr Ellison and his cohorts decide to do once the deal closes and the dust has settled).

I've written about how CA has been running faster than their competitors since late last year and they haven't stopped if the latest announcements are anything to go by. They actually made 3 announcements around RSA; the first was a pointer to Dave Hansen's (Corporate Senior Vice President and General Manager of CA’s Security Management business unit) keynote at RSA (the video of the keynote is here), the second I'll talk about in the next paragraph and the third related to a survey conducted by CA which Dave also referenced in his keynote.

The second announcement was the most interesting as it involved news around their portfolio, where they announced 3 new products:

• Enterprise Log Manager - a brand new, internally developed product
  
• Role & Compliance Manager - from their acquisition of Eurekify
  
• DLP - from their acquisition of Orchestria
  

Note: The DLP acronym generally stands for Data Leakage/Loss Prevention

I spoke to Dave Arbeitel (Vice President of Product Management for the Security Management Business Unit) about the new products late last week and got to find out a little bit more.

I hadn't actually noticed this but Dave pointed out that CA's approach to security management is now solution-focused and grouped as follows:

• Data & Resource Protection
• Identity Lifecycle Management
• Secure Web Business Enablement
• Security Information Management
  

The large IAM vendors are split between being product-focused and solution-focused and the approach taken is very much dependent on the overall company strategy. One thing I should note is that being solution-focused is fine as long as you don't get too smart for your own good and confuse customers (as I've accused IBM of doing on occasion).

Each of the 3 new products fits into one of the solution categories. My interpretation of the solution areas is that CA seems to have grouped what they deem to be the most complementary products together. The most interesting thing to note is that they've grouped CA Access Control together with CA DLP. This makes sense and is evidence that CA gets DLP and are starting to implement a strategy around how IAM and DLP can work together effectively. I'm not saying they get it completely yet, but this is not necessarily a bad thing. The industry as a whole doesn't quite understand the IAM/DLP/Data Security overlap at the moment. At least CA are trying to work it out by putting their money where their mouth is. But I'd caution them against putting too much of a marketing spin on things because people (like me) will call them out when required.

They key thing Dave wanted to get across was that CA has a broader security management strategy and these product announcements are simply steps along the execution path. This has been apparent to those of us following the market over the past couple of months and if CA keeps going, they're going to do just fine as long as they execute well.

I didn't get too much into product features of the Role & Compliance Manager and DLP products with Dave because Eurekify and Orchestria had relatively mature products. There wasn't much point in trying to pick those products apart. The only noteworthy change was that CA combined Eurekify's products into the single product (for those that are unaware, Eurekify had a separate compliance management product that integrated with their role management product). Dave also noted that the new products were not just a re-brand. CA's done additional development work to add functionality and integration points into the existing CA IAM suite.

While we're on the point of integration into the existing IAM suite, I'd like to pinpoint the supposed deep integration and "identity-awareness" of the DLP product. I had a chuckle watching Dave's keynote (and it wasn't from watching the almost cringe-worthy parody of "The Office"). During the demo, they supposedly showed identity management and data security integration. For anyone who hadn't seen a DLP product in action, it looked pretty slick/impressive.

As someone who has demonstrated a DLP product hundreds of times (maybe even thousands - I lost count after a few months) I can tell you that most of the demo only showed the DLP product in action. The solitary identity bit was the de-provisioning of the user (Dave) from a role (which took away access to the SAP application in the demo). Apart from the fact that CA Identity Manager probably has a standard connector into CA DLP to provision and de-provision access for users, they weren't doing anything in the demo that anyone else couldn't do by taking a decent provisioning product and building a connector into a good DLP product. Unfortunately CA, this isn't what I'd call identity-aware-DLP. I realise I may be dismissing other potentially (but unknown to me) nice integration points between DLP and CA's Identity and Access Management suite but I'm going based on the demo and calling it as I see it.

I did try to dig a little deeper into Enterprise Log Manager's features however, mainly because it's brand-spanking new. The only problem with Security Information and Event Management (SIEM) products is that you can't really get a handle on how good a product is until you get your hands on it. Dave assured me that installation is a breeze and that it can even be deployed as a virtual appliance, which I have no reason to doubt. From a technical standpoint, this is not difficult to achieve.

Good SIEM products tend to be measured by the ease of integration, number of standard collectors to other systems and reporting capabilities. The questions I asked Dave were driven by these factors and I gathered that Enterprise Log Manager is still very much a 1.0 product (that is, fairly immature). As an example, Dave mentioned that the product was tightly coupled with their IAM solutions. CA is probably referring to the fact that they can reference policies defined in some of their IAM products (although I'm not sure how deep or wide this integration runs) and have Enterprise Log Manager report on policy violations. But from a customer standpoint, I would expect that this also means I can point Enterprise Log Manager at any CA IAM product and have it be able to collect all relevant user events and report on them without much effort. Unfortunately, this is not the case (I'm sure CA will correct me if I misinterpreted Dave's comments). There needs to be some level of work done to have collectors that can pull information out of the other CA IAM products.

This is not to say there aren't any standard collectors, but I got the impression that this covers the main operating systems and some standard security devices but not much else. The thing about a lack of collectors however, is that the issue fixes itself over time because the more a product is deployed, the longer the list of standard collectors gets. CA needs to build standard collectors for their other IAM products sooner rather than later (I would start with Access Manager, Access Control and DLP). You cannot claim to have tight integration with your own suite of products if you don't at least have these products sorted.

The reporting capabilities seem to be a little more fleshed out. The vision for reporting is that customers use a combination of standard reports, services and new report packs that CA sends out from time to time. The list of standard reports includes many of the usual regulatory suspects, but in my experience these types of standard reports tend to need customisation to meet business needs. For customers that don't feel like using the standard reporting interface, there is a level of integration with SAP BusinessObjects Crystal Reports.

I'm not trying to belittle CA's SIEM efforts. They obviously see SIEM as part of their strategy, but they are a little late to the party on this. It doesn't preclude them from trying however, and at least they have now arrived at the party. I think they knew they weren't going to get a market-leading product at the first attempt. They made the decision to build the product from scratch and they would have been foolish or delusional to expect a world-beater at the first attempt. It does seem a little puzzling why they didn't choose to acquire a leading SIEM player and went with the build approach instead.

As is the norm with these discussions, I tend to ask about things not related to the news at hand as we move past the main items of discussion.

My first unrelated question related to the IDFocus product they acquired and whether any part of that solution made it into the 3 new products. The answer was no because even though it has some level of potential integration with role and compliance efforts, it fits best into the Identity Manager product where it helps to link business processes with provisioning requirements.

My second unrelated question was around the notion of having a central policy management point for all the products (like Symantec and McAfee are trying to do with their own products). The point of this question was to gauge if CA's strategy includes the centralisation of policy management. I didn't expect much because it's actually a VERY difficult thing to do and very few of the large IAM suite vendors have the appetite to invest in this area. I'm not talking about the engineering aspect, which is simple when compared to the actual analysis behind how one would rationalise all the different ways policies could be represented and trying to figure out how to apply an over-arching model to a large portfolio of products. Add DLP to the mix and it gets exponentially more complex because of all the data-centric requirements. For the record, Dave's answer was that the focus shouldn't really be on having a central policy store or management point. It's more about having the right processes occurring between the IAM products to ensure the correct policies are in place at the points where they need to be applied.

Overall, I think CA's got the right idea in terms of strategy. Whether their products are able to deliver remains to be seen. They've got some serious integration work to do so they can get a more coherent story out there and have products that deliver on the promise they are showing. CA does have a trump card to play that their competitors don't have (yet), and that's the DLP product. As I've said before, identity and data security go hand in hand.

Don't give them a reason to fire you

Someone I know is currently being "done" for potential data theft. I should note the potentially biased and subjective view on my part given I know this person but I'll try to maintain some level of objectivity.

This person is currently suspended and under investigation following an incident. What did this person do wrong? Their mistake was simply to be ignorant rather than intentionally do anything malicious.

Those of us in information security know better than to copy and print a bunch of stuff (unless there's a solid business justification to do it) because any organisation with an adequate security team will start wondering what the heck you're doing. Unfortunately, most people are not in the information security profession so it's not as "common sense" as we may all think it is.

This person decided to talk to me because I'm the "security guy". They asked me what they should do. My answer was to just tell the truth because they weren't actually trying to do anything malicious. This person didn't even know how to write files to a DVD a few months ago let alone know what computing-related activities could be deemed as inappropriate.

Consider these points:

1. Most people in the world are not security geeks. Heck, most aren't even technology literate to the standard most of us assume is in place.
2. If employees are simply told what they should not be doing and that they can potentially be monitored, they will be more wary about being perceived as doing the wrong thing. In other words, they will be more vigilant about their behaviour because they've been educated. It also means that companies will have more resources available to catch the people actually trying to do the wrong thing.
   

I won't divulge too much about the incident for obvious reasons (so any specifics regarding the actual incident stops right now) but I do have an opinion on what the root cause of this incident was:

Lack of security awareness training on the part of the organisation in question.

This organisation that this person works for is a large multi-national. I won't mention what industry but it's one where there's copious amounts of sensitive data lying around. So it doesn't surprise me that they have some level of monitoring in place. It is the responsibility of each and every organisation to make sure employees are properly trained in a basic level of information security awareness. It's not good enough that it says what they should not be doing somewhere in the fine print of their employment contract because no one ever reads those things.

In other words, when an employee is being pulled up for a potential security incident, it is the organisation's fault if they did not ensure that all employees were made aware of adequate behaviour when dealing with company data and information. For those wondering, no this person's soon to be ex-employer does not do information security awareness training. I'm guessing it's because employees cannot make the company money while they are being trained in non-core business related activities.

There's actually an additional dimension to this whole episode. Like many organisations in the world today, they are undergoing a round of redundancies. This person was probably already on that list (this is what they tell me), but now it's even worse. They are suspended pending the investigation. And there's no doubt that if this person is cleared, it's "bye bye" anyway.

The problem is that as with any redundancy, there is a severance package to make things slightly easier. But guess what someone dismissed for misconduct gets? That's right, absolutely nothing. So now the situation is worse. Not only is this person being made redundant, they will probably not get their redundancy package because of this so called "misconduct". Way to go big corporation. Turn up the investigations and justify not paying people by saying they attempted to steal a bunch of sensitive information.

When people are scared about being put on the chopping block, what's their first instinct? That's right, they go through their systems and back up all their personal things. We can argue that there should not be any personal things on company assets, but it gets very difficult especially if you have worked for a company for some time.

Ones with more sense don't touch any company material. But there are those who aren't actually trying to steal anything but simply think certain documents are useful to have in their "kit-bag". You know what I'm talking about: "cheat sheets", document templates and the like. This is all too common an occurence and is actually part of the reason there's a so-called "data leakage" industry. It's commonly termed "inadvertant leakage of information". The assumption that it's not harmful to copy certain things if there is no malicious intent is an incorrect assumption on the employee's part, but they don't know any better. Once again, education and awareness.

The more common problem lies with the information where there's a fuzzy line between whether something is work-related or not. Generic education materials are a good example. The company could argue that it's their property even if they did not create it, but individuals typically want all the education they can get their hands on. After all, they're going to potentially need it to find their next job. If you're not sure, just don't take it.

While companies are busy investigating innocent (but rather ignorant) individuals for potential data theft, people with more malicious intents could possibly get off unscathed because there may not be adequate resources to investigate them or even notice they've done anything. In fact, if someone has malicious intent, they probably did some level of planning to make themselves more difficult to catch. So companies don't have any chance of discovering anything's happened if they don't have adequate resources available. And if they are off investigating anyone who printed anything or copied some files to a USB drive, they are going to run out of resources rather quickly.

Doesn't really matter though Mr. CEO, does it? Think of all the money you're saving by not having to pay out these pesky redundancy packages!

As for this person, the investigation is pending. They have told the truth, handed everything over and now just has to wait. Don't make the same mistake because of ignorance.

Identity and data security go hand in hand

I've been meaning to write about this for some time, but CA's acquisition of Orchestria (which I wrote about here) just happened to be the compelling event that kick-started my thought processes.

I don't think anyone's completely worked out how Identity Management (IDM) and Data Leakage Prevention (DLP) or even data security in general should (or will) come together just yet. During my time working in the data security arena, IDM was typically an afterthought in most of the environments I dealt with.

My view for quite a while has been that IDM and DLP go together because in a unified solution, there is a more complete security context with which access control decisions can be made.

DLP products at the moment are VERY data-centric. Policies tend to not cater for identities, roles or access controls but rather what data is being accessed, how people are trying to access it, where they are accessing it from and what they are trying to do with it. Sound familiar? It should if you've had anything to do with IDM or information security in general, but hold that thought. From a data security standpoint however, DLP is about data identification, classification, usage and wrapping controls around it all. Or as a customer's CEO once said during my time at Verdasys, "protect my data but don't get in the way of my business".

IDM on the other hand, is more about controlling access to resources and wrapping it all up with an "accountability" ribbon. I'm over-simplifying of course, because there's all the automation bits and pieces that lead to more efficient processes and so on that I've completely ignored, but bear with me for now because the point here isn't to define IDM to the nth degree.

Allow me to take a step back for a minute and try to distill what it is that information security professionals are trying to solve when we talk about protecting organisational assets. It's not actually that complicated. An organisation has a "bunch of things all over the shop". There are buildings, rooms, offices, applications, databases, file systems, servers, disks, CDs, DVDs, USBs and all sorts of other bits and pieces. There's also bits of paper lying on desks, but technology can't fix that directly. It's more about security awareness and training, but I digress. Back to the point at hand...

The "things all over the shop" are essentially just a means to an end. They are required to house company resources and at the core of these company resources is information. Information in its most basic form is data. This is my long winded way of saying that all we're trying to do is protect access to data and control how it is used. Even all that Governance, Risk and Compliance (GRC) hullabaloo is about making sure data is not misused and if it somehow is, that there is end-to-end traceability, accountability and transparency so you can forensically figure out what happened. Of course, if you had protected that data properly in the first place, there should be no need to go hunting for the smoking gun. But 100% security is a pipe dream, hence the need for a good audit trail (which itself is also data - and can be modified to hide illegal activities if not protected).

So let's recap. You can name all the company assets you like that security tries to protect, but in the end we are trying to protect data and control how it is used. Most things tie back in some way to the "organisational crown jewel" that is information. i.e. data. That's why our profession is usually referred to as "Information Security". What does this mean? IDM tries to protect data. DLP also tries to protect data. The difference is the approach and focus.

IDM attempts to address this by focusing on people and process in a "business centric" manner. DLP or data security (to use a broader term) attempts to address this in a data-centric, "bits and bytes" manner. In some ways, you could view IDM as a top-down approach while DLP is bottom-up. This is the crux of why I've thought for quite some time that IDM and DLP/data security go hand in hand (my obvious self-interests aside): IDM keeps trying to gain additional contextual information to make better access control decisions and DLP keeps trying to make business sense of all this data flying around.

Because IDM focuses on business, people and process, quite often it's the low-level things that are more difficult because there are more unknowns. That is, the things you don't know about that you need to figure out. If there is no automated way to do so, it can take a lot more time. That's why there's a market for products that claim to address risk management, role mining, identity mining and security monitoring. These are some of the typical gaps that need filling whenever you implement an Enterprise Identity and Access Management programme. They need to be filled so you can use them as input to implement proper security policies that are aligned with business and reality instead of the "out of the box" policies you get from the vendor.

One of the most crucial low-level considerations is in trying to figure out what you're trying to protect. Quite often, the consultants will only go as far as the applications. Access controls are more often than not very course-grained. With the advent of all the entitlement management initiatives floating around today, access control is starting to get more fine-grained but they can only go as far as discrete actions people make within the IT environment based on a pre-configured set of policies based on statically defined resources.

In other words, a resource will be defined a certain way until an administrator changes the definition. The blind spot is actually the underlying information or data associated with the resource, which is a key part of this thing we call the security context that's required to make an enforcement decision. Information is dynamic and as such many resources are dynamic by nature. For example, one moment a document might be sensitive but the next moment not because someone deleted all the sensitive information. This dynamic nature of organisational resources is something the IDM software vendors haven't quite solved yet, although Oracle's Adaptive Access Manager is a step in the right direction (I wrote about this here). The reason they have not solved this is largely because much of it is based on information and data being taken into consideration when making access control decisions in real time.

DLP products do a pretty good job of identifying data at rest (e.g. on disk or in databases), data in motion (e.g. across the network or actively being used by people), classifying information and enforcing controls on actions based on security policies. They are typically lacking in the following aspects:

1. Providing an easy way to tie their policies into a central policy management point across multiple systems (which is what Symantec and McAfee are trying to do).
2. Having any notion of identity awareness beyond being able link policies back to distinct user accounts (i.e. personas instead of actual identities) or roles within a particular namespace (e.g. a particular application). For example, in many cases the only notion of identity is someone's Active Directory account and Active Directory role memberships.

The first point is something the large vendors (such as CA) should be able to address given that it's something they should be looking to do with their existing security products.

The second point is important because many DLP customers are starting to include things such as behavioural analysis and more "pro-active security measures" on their wish-lists for product features. The problem is that to be able to do this in a useful manner, the products need to be identity aware.

Information security has always been reactive. Many products come out with "whiz-bang" features that claim to be "intelligent" but the reality is that organisations only fix things once something bad happens. I'm not taking a swipe at operational security in general. All I'm saying is that information security professionals can only be as good as the limits of the tools available will allow them to be. The promise for a long time has been that there would be more products that allow for the operational security teams to be pro-active or better still, have software make decisions adaptively based on real-time threats instead of using static, potentially outdated policies based on assumptions made that could cause issues because of potential "blind spots".

IDM and data security are complementary. Each goes a long way towards addressing the other one's shortcomings and blind spots (although not completely). The key is that we need to figure out how to put it all together so that we can get closer to the reality of pro-active security measures. A data-aware Identity and Access Management infrastracture allows for micro-grained, dynamic, adaptive access controls and more context-aware policies and controls.

CA acquires Orchestria

I noted late last year that CA seems to be sprinting towards 2009. Looks like they haven't stopped and have bolted out of the blocks in 2009 by announcing the acquisition of Orchestria. My Identity Management (IDM) and Data Leakage Prevention (DLP) worlds are colliding here so I felt the need to say something.

I should note that this post focuses on the acquisition. I'll be doing a follow-up post regarding why I think IDM and DLP are complementary solutions and fit well together.

CA are one of the leaders in the Identity and Access Management software marketplace. Most would group them with IBM, Oracle and Sun as the leaders. As I've said recently, they've been going from strength to strength and I probably don't need to say too much more about them at the moment.

Orchestria are a very strong player in the DLP space and well respected. They are a very strong competitor to Symantec (they acquired Vontu, who many considered to be the leader in DLP software) and have the typical DLP components covered off: endpoint controls, network monitoring, data-at-rest capabilities and email server controls. I haven't actually seen their products in action so I can't comment on whether they can do everything they claim, but they tick most of the boxes on a marketing slide and in RFPs. In other words, CA made a good choice in picking Orchestria from a "perception" standpoint. If the technology works as specified, they're on to a winner.

What this means is that CA's got a head-start on everyone else. It'll be interesting to see what they do with it. Early signs are good because they've already stated they see close links with their IDM suite. They may need to watch IBM because IBM ISS offers a data security managed service, but IBM as a whole will never be able to get their act together to compete (if someone wants a combined IDM + DLP solution) unless Tivoli acquires the other vendors mentioned (one of which is Verdasys, who I used to work for). As an aside, the gentleman who runs CA's Identity and Access Management EMEA organisation knows his DLP. How do I know this? Because we used to be colleagues at Verdasys. So there's another "tick in the box" for CA.

I haven't been able to find other commentary on this acquisition (apart from publications spitting out the press release) except for this article from NetworkWorld. Dave Hansen, CA's corporate senior vice president and general manager, CA Security Management is quoted as saying:

"We were not competing in this space, and our two main competitors don't have data-leak prevention."

He's referring to IBM and Oracle if my interpretation of the article is correct (he's mostly right if you don't count the IBM ISS capabilities I mentioned above - I think he's referring to IBM Tivoli Software though so I'll let it pass). In fact, the only Identity and Access Management vendor that sells DLP software is RSA (via their acquisition of Tablus) in the form of their DLP Suite. Unfortunately for RSA, they still don't have a provisioning product, which is why none of the large IDM suite vendors ever thinks of them as being a serious competitor. I should point out that Novell has some data security stuff, but nothing that would make anyone take them seriously.

The article also makes reference to Dave's comment as follows:

"While CA says its primary competitors in the identity and access management market -- IBM and Oracle -- don't have such DLP capabilities, Symantec does."

I don't mean to pick on the article, but what's the point of mentioning Symantec? It might as well have said McAfee...or Trend Micro...or any vendor that has Antivirus products and claims to also do DLP. Kaspersky, Checkpoint, Sophos...I could go on but I won't. I think the writer's referring to the fact that CA and Symantec are competitors in the security market, but we're talking Antivirus products and NOT Identity and Access Management software (where Symantec are not a player).

All things considered, this is a good move for CA.

Update: My post on why I think IDM and DLP are a good fit is here.

The Managed Identity Services brick wall

I've been wondering if each data loss incident is a brick in this wall I'm referring to, so I thought I should take a closer look.

I read about a survey today (I'm all for surveys at the moment) that found at least 80% of the British public don't trust companies to hold their personal details securely. Apparently, 89% also think that repeated incidents should be a criminal offence.

Here are a few tidbits:

• Most think there should be no second chances for data loss offenders.
• Most don't think they'll want to give up any information to a company that has had a data loss incident.
• Half think the single worst offender is the UK Government.
• Most people don't do a thing to protect their information with some not even knowing how to ensure the security of their online transactions.
  

I didn't list all the findings, but basically people don't see it as being their problem. They believe it should be up to companies to ensure security.

This survey is UK centric, so I dare say the same numbers don't apply across the rest of the world (thanks to the UK Government's well publicised, regular data loss incidents in recent times). But I don't think the perceptions will be too different elsewhere, although the figures may be a little be less drastic.

I'm not trying to focus on consumer perception as such. What I'm trying to link up is the fact that decision makers within organisations are also consumers, which means these perceptions matter in the enterprise solution marketplace.

This is one of the things I'm trying to get a better handle on through the Managed Identity Services Survey. What's the big stumbling block stopping people from outsourcing anything where it involves enterprise identity details? Do people automatically equate "identity" with "personal data"? It's a rhetorical question because I think we do. As I've said before in the past, it's mostly psychological but that means everything and makes outsourcing Identity Management a "hard sell".

I should probably cover my bases and mention that there's typically also the concern that external people are able to have access to your enterprise identity information if you outsource any identity-related services, but this is really a moot point. Who's to say your insiders are any more trustworthy than the employees of the service provider (yes I know we could argue this point back and forth and get nowhere - the point is that internal people should not be trusted either, because that's usually how data leaks)? Matt Flynn's also pointed out in the past that whenever you have external consultants working on your internal systems, they too have access to all your precious identity information. In other words, this is a stupid point to be debating. Internal or external, someone is going to look at it and you should assume they are a security risk (even if they don't mean to be)...which is where data security measures come in, but that's a topic for another day.

Now that we've conveniently parked that debate, we can address the other typical concern: the storing of identity information on infrastructure that is not controlled and/or owned by the organisation. Is there actually a good reason to be so concerned about letting enterprise identity details be stored outside of the organisation? Consider the following...

I'm going to pick on the poster-child for Software as a Service (SaaS), SalesForce. I do this because they are the extreme case in that everything is completely hosted and managed by SalesForce. An organisation that uses SalesForce does not own any of the infrastructure. In fact, it's completely exposed to the Internet. How much more of an exposed example can you get? Organisations simply log in and use the software. Also, more often than not when you speak to someone about using SalesForce, the concern over sensitive company details being held in an environment not owned by the organisation and being potentially accessed by external people doesn't come into play. If you ask them, they typically say something along the lines of: "oh but that's all just CRM information".

Think about that statement for a moment. Now, can anyone seriously tell me there's not a S*&%-load of personal data in there? SalesForce is primarily used as a CRM platform, which means that it's full of contact details! Things like: name, job title, employer, business address, phone numbers and email addresses at a minimum. I'm not even including all the other bits and pieces companies might store against each record. For example, the notes may include things like "this guy is an idiot but he signs the contract so be extra nice".

Let's move on to the type of information companies REALLY NEED to be holding in their enterprise identity stores: Unique identifier (usually an email address or employee number), authentication credentials (e.g. encrypted or hashed passwords - if you have passwords in clear text someone should be fired), group (or role) memberships, applications that employees have access to and the corresponding privileges (or entitlements) for each application. You don't even REALLY need someone's name, although most of the time it's stored for display purposes. We could extend this set to include things like manager, department, applicable workflows and so on. A lot of this is dependent on the identity service in question and the business logic involved, which is why on occasion you might see things like salary floating around (although this is not exactly a good thing - you really should be using a third party service that spits out an assertion that "their salary is above $40,000" instead of "salary=$49,890").

I may be over-simplifying here, but this post is long enough as it is so I don't want to put you all right to sleep (or maybe you already are). My point is that at the very basic level, identity stores don't need to contain personal information. They only need to contain information relevant for determining the correct authorisation levels an individual needs to do their job (to be governed by compliance policies which on their own do not store personal details either - at least none that can be tied to an individual). And as far as authentication is concerned, if you're not comfortable having things like credentials stored externally, you could always use Federation (and I don't mean the Star Trek kind).

In short, if you model your identity and access control models correctly, you can do it without personal details. And even if some personal details do creep into the identity stores for legitimate business reasons, it's unlikely to hold more information than one would find in a CRM contact record. What does this boil down to? Your identity stores shouldn't contain more personal data than SalesForce!

Here's where I think the core of the perception problem is:

1. The Media - They link EVERYTHING about personal data to the word "identity", usually throwing the word "identity theft" around as a catch all because they don't understand enough about the subject matter. Those of us in the field know it's a stupid term because you can't steal a person's identity. You just commit fraud by stealing personal data. Of course, even those who know better can't help but be sucked into the whole thing when all we hear about (other than the credit crisis) is data loss and identity theft. When will they understand identity DOES NOT equal personal data?
   
2. Lazy consultants - They look at the HR system and just suck EVERYTHING out of there because it's easier. They make the false assumption that data is safe within an organisation's walls and that some of the information might be required later on so they're saving everyone lots of work by making it available up front. Well, they're not because there's now an additional egress point for data to leak from, which means more work (and cost) is required to secure that information. Because of lazy consultants, you've now got systems all over the place that HAVE personal data. So anytime a person looks at an "identity system", they see personal details all over the place and automatically assume that's the way it has to be.
3. People are self centred, even when they don't mean to be - Employee details aren't typically stored within CRM systems. In other words, the decision maker doesn't care because their own details aren't sitting on SalesForce's infrastructure. When it comes to an identity store however, they immediately think: "hang on a minute, that's my identity information sitting there! There's not a chance in hell I'm letting my details sit within a service provider's environment or let an employee of an outsourcing provider look at them!"
   

To summarise:

• Consumer perception and fear of data loss directly contribute to organisational fears about outsourcing identity management.
• Identity stores do not need to contain personal data (unless authorisation rules dictate - even so, there are other ways like leveraging assertion services).
  
• Identity != Personal Data

Of course, if you aren't even allowed to use outsourced services or software because corporate policies forbid the storage of data on infrastructure not directly owned and under the control of the organisation, then you have a whole other problem. You should probably take the time to question the underlying reasons for this policy however. For example, was it written over 5 years ago and based on fear? Was this fear valid or based on paranoia? Should it be changed? If so, can it be changed or does your organisation submit to the "if it ain't broke don't fix it" mantra?

Are there other factors are play here? Are there "different coloured bricks" in this wall that you're concerned about?

Let me know by completing the survey! Or if that's too difficult, then just leave a comment.

McAfee buys Reconnex - another DLP vendor gets acquired

For those that read this blog for Data Security/DLP reasons, you have good reason to complain that I've been neglecting that area in favour of Identity lately. On the flip side, anyone who doesn't give crap about Data Security or DLP can tune out this time around.

Despite Matt P, Clayton and Nishant jokingly suggesting I should write for sitcoms, I'll put that career on hold for now and get back to business...although if Nishant and Paul Walker continue their thread, I could have more paraphrasing fodder :-)

On to the topic at hand...

McAfee announced late last week that they are acquiring Reconnex for $46 million USD. They acquired a few other companies (Onigma for $20 million USD and Safeboot for $350 million USD) to start themselves along the DLP track and have now filled out the portfolio with assets to address some holes in their offering. What were the holes? Data discovery and network monitoring.

The acquisition wasn't a huge surprise. Symantec have traditionally been McAfee's main competitor and happen to also be their biggest competitor in this space.

Symantec started themselves along the DLP track by acquiring Vontu for $350 million USD. Vontu's strength was in its data discovery and network monitoring capabilities. I should also mention they had lots of customers and were considered to be the market leader in DLP. They've only recently branched out into offering endpoint monitoring and control (I assume this is thanks to Symantec's development budget).

Onigma's technology was an endpoint monitoring and control product. This meant that when McAfee compared itself to Symantec, it found itself sorely lacking from an overall solution standpoint (at least from a marketing perspective). Reconnex fills the void.

Let me take Safeboot out of the picture for a minute because it doesn't compete directly with the Vontu technology. McAfee's only had to pay a fraction ($20+$46 = $66 million USD) of the amount Symantec spent ($350 million USD) to get a comparable set of products. If you do the maths, it's less than one fifth! At face value either McAfee got a steal or Symantec got screwed. To be fair to Symantec, they did have to pay a premium because they were buying "the market leader" and also the set of customers Vontu had. DLP was also a much "hotter" topic at the time (it still is, but the buzz isn't as crazy) and in case you haven't noticed the world economy is in a bit of a slump at the moment. Even after taking these factors into consideration however, I'm not sure that premium should have been 5 times the amount McAfee forked out.

Your move Symantec...which brings me back to Safeboot. Symantec announced their Endpoint Encryption offering earlier this year. In reality, this is an OEM agreement with GuardianEdge and a direct response to McAfee's Safeboot offering. I wonder how long it'll take Symantec to buy GuardianEdge now that McAfee's filled their gaping DLP hole?

HMRC data loss findings

When the UK goverment, more specifically HM Revenue & Customs (HMRC) lost CDs containing 25 million child benefit records last year, it was front page news for a whole week. I wrote about it at the time and gave my usual 2 cents.

They've been on the news again this week for the past couple of days as the findings from the independent investigations into the incident were just released. I've been seeing Prime Minister Gordon Brown and Chancellor Alistair Darling back-pedalling in parliament all week due to attacks by the opposition party on the issue.

It's not too difficult to find the story online, but here (link 1, link 2, link 3) are a few to get you started.

One of the findings stated that:

"Staff found themselves working on a day-to-day basis without adequate support, training or guidance about how to handle sensitive personal data"

While another report stated that there was

"no visible management of data security at any level".

The reports also alluded to the fact that no single person working for HMRC was to blame.

If you don't feel like reading my lengthy post on the incident last year, I'll highlight a section from that post here:

The chances of something like this occurring would have been far less if HMRC had properly implemented the following (in order of importance):

1. Decent security awareness training and education - User awareness will drastically reduce bad practices. People don't want to do the wrong thing. They just don't know when they are doing the wrong things.
2. More security training and education - Keep it fresh and up-to-date. Things change VERY quickly in the IT security game. It also helps to remind people from time to time that security is important. It NEEDS to be part of corporate culture because otherwise, things just fall in a heap.
3. Properly defined identity and resource/data access policies - Know what systems, applications, resources and data you need to protect and who should have access to them. Without this, all the technology in the world will not help.
4. Properly implemented policies supported by relevant technology solutions - Policies alone will not protect you against the bad guys and the "idiot" (too stupid to understand the security policies) or "lazy" (can't be bothered reading the security policies) user. There are also many of us who fall into the "I know I shouldn't be doing this but I'm not doing this as a bad guy - I just want to make my job easier" category.

Looks like I wasn't too far off the mark. At the core of the failure was indeed the age old problem of minimal (or no) security awareness training and education and lack of any management and controls.

Apparently the government have been doing something about it and have in fact finished implementing some of the initiatives. It's not surprising given the amount of publicity the incident generated and the beating they got over it. Hopefully they keep at it and also apply the same controls across other departments (unlikely to happen anytime soon, but one can hope).

Now, if only they could figure out how to stop employing senior officials who are idiots and leave top secret documents on trains (see here and here).

HSBC didn't learn from HMRC

HSBC here in the UK just lost a data disc full of customer details. It wasn't a goof-up of HMRC proportions because 370,000 customer details seem like nothing compared to the 25 million HMRC lost into the postal system. But in light of all the recent incidents, you would have thought they would at least be a little bit more careful about sending things out in the post! From what I can gather, you should only be worried if you have taken out an insurance policy that is somehow connected with HSBC or have insurance related information within HSBC's systems.

A lot of the points I made in commenting about the HMRC incident still apply here so I won't rehash any of it. I'm just very surprised that the bank didn't dive into user security awareness training initiatives to attempt to mitigate the risks in place. I wonder if they also changed some of the procedures and processes around how information is handled.

Or maybe they did both, which brings me to the next point. Assuming they've done a little bit of educating and process re-engineering, the next logical step is to start putting the tools in place to help with the user education (there's nothing better than real-time education of users - how many times have you sat in a security awareness class and come out not remembering a single thing) and information control. Tools which can also protect the information flowing around and even automatically encrypt the information moving to removable media, like a frigging disc that's about to be sent out in the post just in case the person doing it was asleep in class (like the rest of us).

The right approach in my opinion is actually a combination of varying approaches running in parallel. Start small with each aspect and let them evolve and intermingle. For example, you can put in the simple controls using a tool while also conducting user awareness programs and changing information handling processes. It's all iterative.

Of course, whatever they currently have in place isn't working. They claim to have password protection on the disc, but even they admit that it wasn't good enough and that they should have at least encrypted the information.

I know for a fact that this area of security hasn't really been a focus for the bank over the past year. They've been more concerned about PCI...and we know that as long as you are PCI compliant, your customer details are safe right?! Think again (see Rich Mogull's analysis of the Hannaford data loss incident - Hannaford were apparently PCI compliant).

Maybe their priorities will change now? I doubt it...but one can hope.

Not worried about information leakage?

You (link 1) should (link 2) be (link 3).

(Disclosure: I work for a data security infrastructure software vendor - but these are my thoughts and not those of my employer.)

I often talk to organisations about the fact that employees aren't trying to violate security policies. They just don't know what the right thing to do is. In other words, it's about education as much as it is about technology.

If you followed the links above, there's another thing to consider. The altruistic tendencies of human beings. I'm all for free speech and the right for the public to know when unjust or unethical factors are at play. But this is all subjective. Taking a look at information control within organisations from this point of view, you're going to have employees who are doing the wrong thing knowingly but have a greater good in mind.

If I put myself in the shoes of the information security department (the executive board will probably share this view), I don't want anything getting out...especially if it damages the organisation. That includes cases where it can be argued that it's for the greater good. Why? Because people are just doing their job (consider why people work for tobacco companies or gambling organisations). People are also entitled to their own opinions. It is this subjective view that may be prone to error. Regardless of whether the person is right or wrong about the facts, if they happen to violate security policies even if they think it's the right thing to do, they should be stopped. That's why security policies are there in the first place. It may be determined at a later date that the policy is wrong, but that's the fault of the person who created the policy, not the whole security process or the controls in place. Security is there for a reason and it should be enforced.

I realise there is a very fine line here. If something an organisation does is plain wrong, we should all know about it. But at the other end of the scale, if we promote rumour and innuendo, the damage to an organisation may ultimately lead to its downfall.

Security can get rather philosophical at times and I'll be heading that way if I don't stop right here. We should all decide for ourselves what is right and wrong. I'm just pointing out another factor to consider when trying to secure your organisation's information.

UK government loses 25 million identity records

You've probably already heard about this. It was front page news in the UK all of last week. They haven't stopped talking about it and commentators all over the place are taking pleasure in chastising the UK government for the problem. I've been in Seville (Spain) for work and haven't had time to chime in until now.

I'm referring to the fact that HM Revenue & Customs (HMRC) managed to lose 2 CDs filled with 25 million child benefit records in the process of sending them to the National Audit Office (NAO). In short, if you have children and have tax records in the UK, chances are your personal records and bank details were on those CDs.

Of course, being such a high profile incident, the Internet and news channels are already filled with articles and comments. Also, every software vendor and consulting firm is more than likely trying to call on HMRC with the line "have we got a solution and deal for you"! Despite this, the failure is not primarily because of a lack of technology. It is all about the lack of a security culture, lack of education and awareness and badly defined procedures.

In September, they also managed to lose 15,000 records when sending details to Standard Life and an estimated 400 customer records in a separate incident. Here's a time line that summarises the incidents over the past few months if you want a high level view. HMRC's chairman Paul Gray has resigned over this incident. Someone had to fall on his sword over this and I suppose he was the logical first casualty.

This article at Techworld says that the NAO had actually only asked for National Insurance numbers and explicitly asked for the other information to be stripped out. But some bean counter "business manager" at the HRMC instructed that this not be done because they would have to pay their IT provider EDS to do it. Sound familiar to you? Yet another case of the need to save of dollars winning out over good security and privacy practices. It happens all the time because of uneducated "business individuals" with no sense of the need to protect sensitive information. That's why there have been so many incidents over the past few years and this is just the latest and highest profile one this year.

I'm frankly not surprised that this happened. It's a harsh thing to say, but I know a little something about a very small part of HMRC's systems and how EDS manages it. I should point out that I've never had anything to do with the EDS HMRC account or HMRC itself, but I do know some people who work on the account and it's a shambles. Identity controls are practically non-existent. Access controls are practically non-existent. There are also allegedly people working on those systems without a proper security clearance! This is not to say they don't safeguard some of their data. I'm sure they do, but it says something about the general culture and management mentality in place. I know for a fact that internally, BIG security holes are observed and brought to management attention by a lot of the guys on the ground, but their protests fall on deaf ears. It's almost always because dollars speak louder than the need to have good security controls in place. This is just unacceptable and it's not even totally EDS's fault, although they play a part. It's the fact that HMRC seem to have a culture of penny-pinching when it comes to IT and they've now suffered as a result. If you're unwilling to spend money on adequate security, you deserve to be called out as being incompetent and they've shown themselves to be exactly that. Unfortunately, millions of people have had to suffer as a result.

The main thing that strikes me out of all this is that EVERYONE (including British Prime Minister Gordon Brown) is blaming a "junior official" for the gaffe. This deflects from the actual problem. Even if the official was "junior", it was not their fault that this happened. In fact, being "junior" gives them a valid excuse for being stupid. The problem is just bad process and even worse IT management. This incident is inexcusable, especially if you are the Government and are responsible for the security, privacy and protection of your citizens. You CANNOT be losing information because you want to save a few bucks.

The "junior official" shouldn't even have had to think about what they were doing. They should NOT have had access to this information in the first place. And if an official does come along who should have access and is properly given the access, they should NOT be able to copy all this information onto something like a CD and have it sit there unencrypted and unprotected! Security should be put in place to make access to data "idiot proof" because most users are "idiots" when it comes to data protection. Even those of us who should know better violate security policies all the time because it's just easier. We do it without even thinking about implications because we all have the “it won’t happen to be” mentality. It’s even more rare that an incident occurs where there are such massive implications and on such a high profile and scale. In other words, most of us suffer from “she’ll be right mate” (borrowing a term us Aussies like to use) syndrome.

The chances of something like this occurring would have been far less if HMRC had properly implemented the following (in order of importance):

1. Decent security awareness training and education - User awareness will drastically reduce bad practices. People don't want to do the wrong thing. They just don't know when they are doing the wrong things.
2. More security training and education - Keep it fresh and up-to-date. Things change VERY quickly in the IT security game. It also helps to remind people from time to time that security is important. It NEEDS to be part of corporate culture because otherwise, things just fall in a heap.
3. Properly defined identity and resource/data access policies - Know what systems, applications, resources and data you need to protect and who should have access to them. Without this, all the technology in the world will not help.
4. Properly implemented policies supported by relevant technology solutions - Policies alone will not protect you against the bad guys and the "idiot" (too stupid to understand the security policies) or "lazy" (can't be bothered reading the security policies) user. There are also many of us who fall into the "I know I shouldn't be doing this but I'm not doing this as a bad guy - I just want to make my job easier" category.

In other words security awareness, training and education are paramount. It should be noted that this needs to be pushed from top down. If the business stakeholders do not buy into security being important, no one else will. Bottom-up security awareness and culture change NEVER works. Having some semblance of a security function is the next most important thing. Without it, all the best technology in the world will not help. And finally, put in the proper IT solutions to enforce these policies because you need the "virtual traffic police" to ensure that laws are met.

As a simplistic level, technology alone could have prevented this from happening in the first place, but it does not solve the over-arching lack of security that is apparently there for all to see. In fact, many commentators and so called "security experts" are saying they should have put in encryption technologies and it would have solved all their problems! This is just not true. By this I mean that they could have implemented basic stop-gap encryption technology to enforce that everything that gets written to CDs and DVDs gets encrypted. If that was the case, the loss of the CDs would not have caused this much debate and analysis around what went wrong. It would have simply been "oh, we lost some CDs and these things happen sometimes when you post things, but the data was all encrypted". That would have called into question their processes rather than their lack of focus on security and inadequate IT controls. The implications to the public would have been far less severe. If that had been the case, all it would have done was to delay their major incident. If all you do is put stop-gap measures in place rather than a proper identity, access and information security layer and accompanying controls, it is only a matter of time before the "water leaks from another part of the dam" (apologies for the cliché, but I'm too tired to think of a witty and original analogy).

The only positive from all this is that HMRC have now got a compelling reason to act and spend money on a first step towards an adequate security infrastructure. Keep in mind that being the Government, "adequate" is NOT GOOD ENOUGH. But it's a start. Unfortunately, many Governments do not even have adequate security. I dare say many other Governments in the world have similar issues but just haven't had the high profile incident to catch them out yet. Losing 25 million records is going to be very difficult to top however, so I dare say the UK Government's incompetence will be in the spotlight for some time.

I'm not privy to the processes that have been put in place for the scenario that took place so I'm not about to comment on the specifics. They probably have some sort of security awareness and education. Maybe being a "junior official" pushed the person down the list of people who could attend classes and they hadn't been given the requisite training (in which case they shouldn't have been able to access sensitive information at all - sadly this pre-requisite is often overlooked by security policy makers and even more often left unimplemented in security systems). If they had been given the training, then perhaps it was the "idiot" factor. If we give HMRC the benefit of the doubt and assume their education program is great, their operational and security processes are sound and their security policies are well defined, then this should have been prevented by the security measures and IT systems they have in place.

The whole process should have gone something like this:

1. NAO formally requests the 25 million records via the proper channels using the pre-defined and approved process.
2. Process is executed and approved after which the work assigned to an authorised official.
3. Official (who has undergone proper security education and training AND has this fact marked in their user profile to allow for rudimentary access to systems) picks up the task and is authenticated to the environment at a certain clearance level. If official has not undergone security awareness training, they cannot get access to anything sensitive.
4. Official retrieves information and based on credentials and their entitlements is only given the parts of the data they have approval to view. If this does not include the required information (e.g. names and national insurance numbers), the official should be able to request that the relevant entitlements be given to them and have this request approved by the relevant managers or security personnel. Access should not include the ability to retrieve information that is not required (such as bank details). In other words, there should be fine grained access controls in place for access to sensitive data.
5. Once allowed, official retrieves information and saves it to required media for transport to NAO. If the approved and documented process is to burn the information onto DVD or CD, then this is done. Upon the action of burning to CD or DVD, the information should be transparently encrypted without the official having to intervene or know that it is being encrypted. The decision on what to encrypt should be made by the system.
6. DVD/CD is packaged up and securely transported to the NAO securely and properly tracked.
7. The whole end to end process should be digitally audited and tracked in a central location for forensic purposes. Then there would be no need to pay PWC a truck load of money to “investigate” as they have had to do in this instance.

You may still be able to poke holes in the process I’ve outlined (the best processes do not cover off 100% of the potential risks, they just help mitigate the overall risks), but it would still be better than what HMRC currently have in place…and it took me 5 minutes to come up with it. If nothing else, it would have at least shown that they had been pro-active about protecting their data from a process and procedural standpoint. There is obviously more to information security than this and I’m not blind to the fact that implementing what I’ve outlined is no small task. If it was this simple, there would be no need for information security professionals. They need to start with the easiest bits and work their way up from there. Defining the procedures and policies is the first step. Putting in the encryption is an obvious easy win. The identity and access/entitlements part is a little trickier, but they need to think big to start to get somewhere. At this stage, I doubt they even know how to spell “entitlements”.

All I’ve done here is over off a small part of the big picture…but a part that would have potentially prevented the loss of the 25 million records. And even if they somehow managed to lose the CDs, they would only be useful as coasters or Frisbees to anyone who found them. The 25 million record data loss incident would have been averted and we would be talking about something more interesting this week rather than the UK Government’s incompetence.

Symantec announce Vontu acquisition

As usual, my travel schedule for work is really screwing with my blogging habits and keeping up to date with news. Of course, this means I'm blaming it on the market's need for Data Security solutions...which is not such a bad thing.

Symantec finally announced their acquisition of Vontu early last week. More about it on Symantec's website here.

I spoke about Vontu briefly in a previous post and mentioned the whole Symantec acquisition of Vontu here when it was still a rumour. As it turns out, it was true and a very badly kept secret.

I'll post more about my thoughts on what this means for Symantec later when I have a spare moment. Hopefully that's sooner rather than later.

IBM dips its toe into Data Security

IBM made a rather long winded and all encompassing announcement today around a bunch of Risk Management initiatives. In true IBM style, there's too much information for the average person to take in and understand at first glance. They are offering a heck of a lot and very few organisations will need everything they are announcing here. In fact, you probably don't even need half of what they are offering unless you have a HUGE security need and not much of an IT security department. Of course, they'll gladly send out a sales rep to sell it all to you. Don't buy it all. You don't need it all.

Now that I've done my IBM bashing for the day, I want to point out the data security piece:

"To deliver a total data protection solution throughout the information lifecycle, IBM ISS is partnering with leading data security vendors, including Application Security, Inc., Fidelis Security Systems, PGP Corporation, and Verdasys, Inc. By leveraging key technologies from these partners and IBM Tivoli, IBM ISS will offer a comprehensive set of asset-based data security services:

• IBM Data Security Services for Activity Compliance Monitoring and Reporting -new services that help protect companies from insider abuse and enhance audit preparedness by assessing, monitoring, and alerting on malicious and non-compliant database activity and vulnerabilities.
• IBM Data Security Services for Endpoint Data Protection - new services that help clients encrypt and manage data on endpoint devices, such as laptops and PCs.
• IBM Data Security Services for Enterprise Content Protection - new Data Loss Prevention services that monitor and help protect against intentional and inadvertent leakage of critical data."
  

In other words, IBM can offer you a Managed Security Service around data security and leakage prevention (aka DLP). So even though IBM aren't doing anything in terms of acquiring software in the DLP space (yet), they are flexing the might of their services arm in an attempt to service the need. It is worth noting that they need to partner with other vendors because they don't have the software portfolio to do it. Which brings me to my next point.

It would do them a lot of good to have a software solution in this space. The most logical place to slot the acquisition would be in Tivoli, but they could also put it into their Information Management brand. It makes perfect sense to tie data/information monitoring and leakage prevention into Identity Management, Access Controls/Entitlements Management, Compliance Monitoring/Reporting and Security Event Management and Correlation. It's a big hole in their portfolio. Once they get that, they'll need to start looking at the network layer.

I know they got out of that business a long time ago and said they would never go back...but hey, they bought ISS didn't they (incidentally, they could also roll DLP software into ISS). Stranger things have happened.

TrendMicro gets into DLP

I'm a few days late on this as usual. My excuse is that I've been busy working with a huge global organisation on their data security, protection, leakage prevention and PCI requirements.

With the spate of acquisitions in the Data Leakage Prevention space lately, it comes as no surprise that another has just occurred. TrendMicro acquired Provilla earlier this week. This trend will probably continue as all the large vendors try to elbow each other for a position at the front of the pack in this space and attempt to round out their security portfolios. That being said, we're still waiting on the rumoured Symantec acquisition of Vontu.

So you can add TrendMicro to the list of large DLP vendors I mentioned here...with the exception of Symantec (at least for now).

The question remains...what are the REALLY big vendors doing? I'm glad you asked (continued in the next blog entry).

Symantec going DLP?

I go and talk about Vontu and the next thing I read is that there's a rumour flying around about an acquisition. If InfoWorld is right, it will be announced next week that Symantec is acquiring Vontu.

No I don't have any inside information. I don't work for Vontu. I know some have been wondering (based on some of the search referrals that have been coming through - although no one's actually piped up and asked me directly). I wasn't exactly full of praise about Vontu in my last post was I? I didn't think so.

So assuming this moves ahead, we'll have 3 BIG Vendors in the DLP space. McAfee, EMC (they acquired Tablus earlier this year and rolled it into their RSA division) and Symantec.

Looks like DLP's going mainstream very quickly, which is obviously good for the industry and organisations looking at a DLP solution.

DLP vendor race

I'm still in a data security mood, so those of you in the identity world can tune out this time round if you like...or if you want to broaden your horizons, read on :)

Remember when I said to implement a proper data leakage prevention (DLP) solution you need an agent on the endpoint? If you're new to the blog or if you're one of the lazy ones and don't bother reading my posts that go for longer than 2 paragraphs (you know who you are), go read about what I said here (this post somehow managed to get a mention on the Network Sentry blog at IT Business Edge - I don't know how).

Now that you're back, let's get to the point. Vontu are one of the main vendors that always get a mention when you talk DLP, but they've always only had a network based solution. What that meant was that they could only watch data flowing on the network and prevent it from leaving. Once a laptop leaves the corporate network, data could easily escape and no one would be the wiser. This is the main reason you need an agent. An autonomous one that doesn't need to be connected to the network to enforce security policies for information.

As I said, there have typically been 2 types of DLP vendors. Network centric ones, and endpoint centric ones. It seems Vontu agrees with what I said because they've realised they need to be at the endpoint to really get serious about being a DLP solution. In doing so, they are the first (that I know of) to take a serious stab at doing both.

They announced earlier this month that they now have an endpoint agent. I took a look at the functionality and while useful, is still quite a way behind what some of the other endpoint DLP vendors can do in terms of functionality. In other words, they're playing catch-up. The advantage they have is that if an organisation wants to go with a network centric approach (I don't really know why they would - although these tend to be cheaper) with some coverage on the endpoint (but not a lot) then they can go with Vontu.

Where Vontu may win out in the short term is in the marketing stakes. Organisation that are easily sold based on Powerpoint slides may be convinced that Vontu is the way to go. My money's on Vontu going out and saying "we're the only ones that cover all the bases for DLP because we do the network aspects and we cover the endpoint". It's very difficult to sell on feature function unless a customer really has specific requirements that one vendor can meet better than the other. And even then, the only way to prove it is in a bake-off, because everyone's going to say "yes" to most requirements.

I have no doubt Vontu will continue to add functionality to all their products. This can only be good for competition in the high profile space that's come to be known as DLP. The question is how fast can they run? Will they catch up in the endpoint game (unlikely unless they double the size of their development team because they've now got more products to work on)? What about the other vendors? How fast are they running? Do they care that Vontu are in the endpoint DLP space now (rhetorical question)?

Of course I'm just stating the obvious. In any new area of enterprise software, almost all the major players are small to mid-size companies/start-ups. It's usually the ones that run the fastest that will win out in the end. Not always, but it sure helps.

McAfee acquires SafeBoot

McAfee announced earlier this week that they were acquiring SafeBoot for $350 million USD. It's actually a good move, despite what I'm about to say.

It's almost like the McAfee product strategy people have been going through the PCI-DSS standards and acquiring technology to address gaps in their portfolio so they can sell a portfolio that "solves" all of a customer's PCI issues (or so they say):

1. They've had their Anti-virus and Anti-spyware solutions for a long time.
2. They acquired Onigma at the end of 2006 for its data leakage/loss prevention/protection (DLP) capabilities. They also just updated the DLP product with functionality to catch up with its competitors somewhat (although they're still behind in functionality).
3. They've got network access control software.
4. They've got a so called policy engine.
5. And now they've just shored up their encryption capabilities with the SafeBoot acquisition.

The gaps left are:

1. Firewall - but McAfee will probably say they've got that covered with their intrusion prevention solutions working in conjunction with their network access control solution.
2. System passwords and restricting access to information. In other words, Identity and Access Management.
3. Testing and monitoring all accesses to resources and data. Again, more Identity and Access Management - although McAfee will also claim their DLP product working with their network access control product and their policy engine gives them the tick in the box here.

It all looks very nice on a marketing slide of course. They still have to integrate all this technology. The technical integration of acquired products takes time and they usually don't play nicely with each other until the N+2 or N+3 release post acquisition.

Another thing. Their list of products is growing. If they aren't careful, they'll end up like Tivoli's portfolio from a few years ago, where half the products overlapped in functionality with the other half and very few of them worked nicely together. Tivoli have since fixed that, but it took a few years.