SIEM – it’s not mainly about tools

09.10.2011 by Martin Kuppinger

Last week, IBM announced the acquisition of Q1 Labs. The same day, McAfee acquired its plans to buy NitroSecurity. Not that long ago, HP bought ArcSight. Obviously, SIEM vendors seem to be very attractive to the large players in IT. SIEM, the acronym of Security Information and Event Management, consists of two disciplines. One is about managing the security information from different sources, the other is about real-time analysis of that information to identity events.

Given the increasing security threats (no, it aren’t just challenges anymore), having approaches in place which help in identifying security issues in time, is essential. Relevant data is found in a large number of sources. Collecting, aggregating, correlating, and analyzing  that data is supported by SIEM tools. However, with incredible masses of data, two issues become evident:

  • SIEM requires a strong knowledge about security to be able to understand security information from different systems and their relationship.
  • The art of SIEM is to – at best- identify exactly the critical situations which need to be handled. Not more, not less.

Given that real IT security experts are a rare species (at least compared to the demand), it isn’t easy to address the first point. Working with MSSPs (Managed Security Service Providers) might be one option. However, IT security has to play a much more prominent role in education, even while that will close the gap between supply and demand only slowly, if at all.

The other point is that SIEM is not mainly about tools. SIEM tools are only as good as they are used. If you end up with too many events you have to analyze manually, you haven’t won anything. If you end up with a situation in which some critical events aren’t detected, you have lost. Configuring SIEM tools optimally is an endeavour which takes its time and which requires a lot of up-front thinking. It is about identifying the controls you should have in place, it’s about understanding your security risks and the potential attacks, it is about understanding the relationship of different steps of more elaborated attacks like APTs (Advanced Persistent Threats).

So, as popular as SIEM might be: SIEM tools are nothing else than tools, until someone configures them right. So moving towards SIEM is not mainly about buying a tool, but about the controls, the configuration, the use of these tools. So don’t feel save once you’ve bought a SIEM tool – feel a little saver once you’ve done your work around that tool. But never feel save!

How to deal with Data Sprawl? Could a sticky policy standard help?

21.07.2011 by Martin Kuppinger

Data Sprawl appears to me to be one of the biggest challenges in information security. And, by the way, Data Sprawl is not an issue that is specific to Cloud Computing. It is a problem organizations are facing day by day.

What happens when data is extracted from a SAP system? One example: a CSV (flat) file is created with some data from the HR system. This file is delivered to another system, in best case using some secure file transfer. But what happens then? That other systems processes the file in some way or another. It might export some or all of the data, which then ends up in yet another system. And so on…

The point is: Once data leaves a system, data is out of control.

The problem is that this might happen not only with one CSV file but with 100’s of them. And dozens of systems exporting and importing that data. Governance is difficult to implement. You can define a process for allowing exports. You might defined even rules for the use of exported data. You might review the exports regularly – are they still needed? However, reviewing what happens with the data at the target systems (are the rules enforced?) is pretty complex. But there is, up to now, no technical solution to solve that problem.

Things become even worse with Data Warehouse and Business Analytics. Data frequently ends up in large data stores and is analyzed. That means that data is combined, sometimes exported again, and so on. How do you keep control? Implementing Access and Data Governance for Business Analytics systems is a big challenge, and auditors frequently identify severe risks in that area – which is no surprise at all.

Another scenario is PII in the Internet. If we give some PII to some provider for some reason, how could we ensure that he doesn’t give that PII away? No way, I’d say. We might use special eMail addresses or faked information to track back some abuse of PII, but that’s not really a solution.

So what to do? Short term, it is about implementing processes which at least try to minimize Data Sprawl and the associated risk, like mentioned above. These processes and policies are far from perfect. That helps internally, but not for PII.

We might use (very) long-term technical solutions like homomorphic encryption and other technologies which are developed around the “minimal disclosure” approaches to address some of the issues. We then might use an approach like Information Rights Management which works not no a document basis but on an attribute basis. But most of these things will help us sometimes in the future, if ever.

But what about defining a policy standard which is sticky to the data? A standard which describes how data could be used? If systems support this standard, they could enforce it. That would be about having such a standard and allowing exports at least of sensitive data only to systems which support the standard and enforce the policies. If data is split up, the policy has to be sticky to all parts (as long as it applies to all parts). If data is combined, policies have to be combined – the intersection of the policies applies then.

Such an approach has limitations, because it will first of all need some people to define the standard. And, like with all standards, it is about the critical mass. On the other hand: Virtually every organization has the problem of Data Sprawl and lacks a valid answer to the questions which are asked in the context of Data and Access Governance. Thus, there is a real need for such a standard. From my perspective, the large vendors in the markets of Business Applications (e.g. ERP, CRM, and related systems), of Business Analytics, and of all the ETL and EAI applications are the ones who should work on such a standard, because they are the ones who have to support it in their systems. And they should start quickly, because their customers are increasingly under pressure from the auditors.

Android attacks – you shouldn’t be surprised

04.03.2011 by Martin Kuppinger

The news about a significant number of malicious apps for the Android platform on mobile phones hit the news yesterday. Many comments still sounded a little surprised. However there is no reason for being surprised. Today’s mobile phones are insecure by design. The vendors haven’t understood that security is mandatory for long term success and they are still selling devices which are as secure as a PC in the mid ’80s of last century. Unfortunately these devices are connected and have far more capabilities than the PCs of the early days.

The vendors (and developers of OSes) are just ignoring the need for built-in security. A PIN code is a ridiculous mechanism to protect a device which can hold that much sensitive data and which can be used to access sensitive corporate information. How about biometrics or other types of strong authentication? There are many potential solutions out there for mobile devices which are secure by design and still user-friendly.

In addition to the insecure devices and OSes, the concept of apps itself is insecure. How to manage apps for your corporate users? How to do DLP (Data Leakage Prevention) for apps? The concept of apps is as well insecure by design. Unfortunately, it is a good example for the wrong design principle “function follows form” – it should be “form follows function”. But the concept of apps is about markets and money, about a “cool” concept and not well-thought, because it isn’t secure (enough).

For organizations, the only consequence can be to review the policies for using mobile devices and massively restrict the professional use of devices which are insecure and have too many capabilities. That requires an analysis of which platforms are allowed for which use cases. You might argue that this won’t work because even the managers want to use their gadgets. Correct, it isn’t a simple task to do. However, in virtually every country there are laws which require that the board enforces an adequate risk management. Using insecure gadgets with access to sensitive corporate information (starting with eMail) is a risk which has to be mitigated by restricting the use of gadgets or more secure ways to use them. By not doing so (or even using insecure devices as a board member), legal requirements are ignored. I’d bet that the next hot topic for auditors will become mobile security…

For vendors, these new attacks hopefully are an alert which helps them to understand that security is a key requirement for long term success in the market. That might lead to invest more in security which is easy to use.

In the meantime we will see masses of point solutions and services to better protect mobile communication. Be careful with that – some might deliver a real value, others will turn out to be sort of placebos. But in any case, you first should have a strategy and policies for the secure use of mobile devices, before you invest in such point solutions and services.

It will be interesting to observe what happens in the next months. Will vendors wake up? Or will it need more and even more severe incidents for that?

Data Leakage Prevention and the Acting of the German Government

31.01.2010 by Martin Kuppinger

In Germany, there is these days (again) a discussion about whether the German State shall buy data about fiscal fraud. There is someone from Switzerland who offers illegaly obtained data about German citizens who have transferred illegal earnings to bank accounts in Switzerland, not paying taxes for this. Germany some months ago has bought such data about bank accounts in Liechtenstein, to identify fiscal fraud and to penaltize this.

That leads to some highly interesting questions, and there is a political debate about whether to do that or not. It is obviously illegal to buy stolen goods in the knowledge, that they have been stolen. Data is amongst these goods, for sure. It is highly questionnable whether actions of the attorneys based on such data are legal – I doubt this and I’d expect that the German Federal Constitutional Court will accept this once the first law suits about this are brought to him. Thus it might end up with that any penalties against this fiscal fraud aren’t permittable being based on invalid evidence (or evidence derived from invalid evidence, because the data will allow the attorneys to request the account detail from the swiss banks – it just provides a list of accounts as a foundation for follow-up queries). It might also occur that several of these accounts aren’t about fraud – and again, that it might show up to be illegal to do such mass queries based on too little evidence. And: Buying stolen goods (in case you know that they have been stolen or that you have to assume that they were stolen) is under penalty. Thus, the people deciding on doing that are definitely acting against the law and might be penaltized. That will be up to the courts to decide about.

Read the rest of this entry »

Vendors might sell even in immature markets

16.07.2009 by Martin Kuppinger

These days I had a discussion with a vendor who sells different security tools which make up sort of an Endpoint Security “suite” about my and his view on that market. He was sort of offended by my critical view on today’s endpoint security market and claimed that his company and many of his competitors are selling large amounts of licenses to customers. Thus I must be wrong when telling people that the market isn’t really mature today.

My view on endpoint security is, by the way, not as sceptic as the one I have on the DLP market (Data Leakage Protection/Prevention). I think that well integrated, feature-rich endpoint security solutions are an important element within security strategies. But the bar is set high. Endpoint Security solutions have to fully protect different types of endpoints. That includes AV, local firewalls, WLAN security, encryption, device control, and other elements. All these features have to be well managed. And well managed means centrally managed, integrated with existing and potential other new elements of the overall strategy. Active Directory integration is key in Windows environments. Integration with SIEM tools or at least open interfaces are a required feature. For sure, there needs to be one set of policies for all security features of the endpoint. Existing system-level features should be as well integrated, starting with Bitlocker on new Windows versions and for sure as well including interfaces to Windows Group Policies. To name just a few of the expectations I have on Endpoint Security Suites.

Endpoint Security thus goes well beyond the point solutions in the DLP market which I see even more critical.

Unfortunately, no vendor today fully supports all requirements I have on Endpoint Security solutions. That might change over time. But even then, Endpoint Security will be only one element within a security strategy, which has to be combined with IAM (Identity and Access Management) as the foundation for most parts of security, with more advanced information protection solutions (shielding information not only at rest, but as well on move and on use), centralized solutions (which might even overlap with endpoint security to some degree – look at what Finjan provides) and so on.

Thus this mean that you shouldn’t invest in Endpoint Security tools? No, for sure not. But a customer should be aware of the shortcomings of today’s offerings. And he should understand that he addresses only part of the overall problem (even while Endpoint Security at least might address a larger part of the problem, compared to many of the point solutions offered under the label of DLP). And vendors might use the bar I have set as sort of benchmark for their solutions and sort of advice for their product management instead of complaining that the bar is set to high. The fact that they are selling their products only proves that there is a strong demand for endpoint security solutions and that customers are even willing to buy immature solutions – it doesn’t prove that their solutions are mature.

My advice for customers: Understand the strengths and shortcomings of today’s offering in endpoint security, understand endpoint security as part of a larger IT security initiative, and define your selection criteria according to that.

My advice for vendors: Don’t rest on your current success but go a step back and think about what will be needed tomorrow and in some years from now. The Endpoint Security market will evolve, there will be significant changes. And it will be more and more understood as part of a bigger IT security approach.

Data leakage prevention

09.01.2008 by Martin Kuppinger

I’ve observed an increase in discussion around data leakage prevention – finally. This discussion is overdue, given the fact that data leaks are common in most corporations. Internal documents, eMails, blueprints aren’t under control in most cases.

The need for data leakage prevention automatically leads to two topics: Information Rights Management (IRM) and Identity and Access Management (IAM). Both are tightly coupled. Identity Management is about managing the identities. Access Management is about controlling access, but mainly to defined “information silos”. Information Rights Management is about controlling access to information in the flow. But, in fact, IRM is nothing else than a specific for of Access Management – isn’t it?

If you look at Microsoft’s advances in IRM with Windows Server 2008, the central role Identity Management has for IRM becomes obvious. The most important improvement is the integration of Identity Federation and IRM, with the result of Federated Rights Management Services. This isn’t surprising, because IRM requires the knowledge of the users, groups, and roles which shall have access to information. That is easy within an enterprise, but it becomes a quite complex issue in the communication with more or less tightly coupled business partners. Federation is the obvious answer to this.

Thus, IAM and IRM will grow together over time, with IRM as a specific application of IAM. Companies which face the data leakage problem – virtually every company – have to define their strategy for IRM in the context of IAM. This context is necessary because IRM requires reliable identity information and because IRM is just another form of Access Management. And a major topic at our European Identity Conference.

The good news is that this dependency is seen by some vendors as well. The bad news for Data Leakage Prevention is that there are neither standards nor implementation which will cover the entire breadth of (electronic) corporate information, e.g. from Microsoft Word to CATIA to Lotus Notes. But the growing demand for solutions might change this over the next two or three years.

© 2015 Martin Kuppinger, KuppingerCole