Posts tonen met het label cloud. Alle posts tonen
Posts tonen met het label cloud. Alle posts tonen

zondag 8 december 2013

Stepping up cybersecurity

We love hypes and in our profession cybersecurity is a hype that doesn't stop to be a hype. The #ditchcyber campaign is started to help busting the hype. Well, allright, let's just add to the hype.

Here are some links to documents that may help you deal with cybersecurity.

Confused? Just pick the 9 steps ebook (by Dejan Kosutic). He clearly shows that cybersecurity is just a subset of Information security.

Enjoy.

dinsdag 25 september 2012

Your Twitter ID as a source for Twitter spam

I'm getting more and more spam in my Twitter timeline or in my twitter direct message mailbox. And these tweets come from my own twitter friends. And I'm not alone in this. Many others mention this as well.
Tweets like this: “GET MORE FOLLOWERS MY BEST FRIENDS? I WILL FOLLOW YOU BACK IF YOU FOLLOW ME” or direct messages like “lol ur famous now [link]” will in most cases link to malware infected sites.
And now and then a twitter friend reports that his twitter account was hacked.

I don't believe that this is the case. Accounts don't get hacked easily. Of course a pc could be infected with malware, with keyboard sniffers and password stealers, but apart from that, hacking an account is not that easy. Proof? Even security professionals became the source of twitter spam messages.

If your account was not hacked, how can this spam flood happen?
Tweets defininately come from a trusted person. But since there is no way that you can create a tweet with a faked sender address, these spam messages really come from your friends.
On his blog (http://nakedsecurity.sophos.com/2011/06/23/beware-shortcuts-for-getting-more-followers-on-twitter/) Graham Cluley from Sophos explains how these tweets happen. These tweets come from services that you(!) allowed access your twitter account. And these services may well do other things than you wanted them to.
Twitter can be used as an identity provider. It uses the underlying oauth protocol to authenticate twitter users for different services on the internet. And this feature is not only available on pc's but also on mobile phones. Very practical: if you use your twitter account you don't have to login using a user name and a password. All that is required is that you tell twitter to allow access for the external service. And in fact you allow the external service to post messages on your behalf.
Through this link ( https://twitter.com/settings/applications ) you can check what apps you trust to post on your behalf.

Do you really trust all these apps? My advise: You better revoke all unknown or unused apps. And btw: if I receive a strange tweet from your twitter account, I will use a second channel (like LinkedIn, or mail) to advise you to clean your twitter trusted app list.

dinsdag 26 juni 2012

Let's kill the IAM acronym!

In the information security industry, the IAM acronym is well known, it's the acronym for Identity and Access Management. IAM is used in blogs and tweets, consultants manage IAM projects and vendors sell IAM tools and suites. But I am feeling less and less at home with this acronym: it feels like a false acronym.
Identity Management (IDM) and Access Management do not exist together. These terms point to different processes and responsibilities. Let me explore and explain this some more.

Identity Management is a process for managing the lifecycle of identities within a trusted domain, be it a real or virtual organisation or an Internet resource like a mailserver. Identity Management is responsible for managing digital identities and user accounts. It is about 'who', it's a process for managing 'subjects'.

Access Control is a whole different ballgame. It's got nothing to do with 'who'. It's all about defining 'what' and 'why' for accessing 'objects'. Access Control is about defining the access policy for managed objects and resources. And it's about the person responsible for defining these policies. Access Control is a shared responsibility for a process owner, who in turn should define access rules for realising Seggregation of Duties, and a Data Owner, who is responsible for data governance and who should define access rules based on all kinds of laws and regulations.
The process owner and the data owner have to decide what kind of permissions should be available under what conditions. A process owner should not be interested in managing the accounts accessing his resources, but he should be interested in why accounts might be able to access his resources. And he must be interested in the audit trail: who did what.

Of course there is a link between the two processes. And that's simple because Who can do What and because of Why. The link is the digital identity, in most cases addressed as a Role of User Group.

Identity Management can largely be supported by tools. IDM is responsible for synchronising user accounts, roles/groups and passwords between systems and for provisioning attributes towards all kinds of related systems. The business case for IDM is in lowering costs. A single point of administration lowers operational costs and results in better data quality because of it. IDM can be implemented in an IT project.

Access Control is a business process. There's not a lot of technique in this process. Of course the rules have to be implemented in systems, but it's not an IT responsibility. The business case is not in lowering operational costs, but in delivering better transparancy and governance.

IAM projects tend to result in either an IDM implementation or in nothing at all. So why call it IAM after all? We better start calling it Identity Management and Access Control, or, as I tend to do, IDM/AC.

With the growing acceptance of Identity Management services in the cloud, separating IDM from AC is a logical consequence. The next step will probably be delivering Access Control in the cloud, in the form of Policy decision engines using SAML and XACML. And this process is better of by not managing Identities at the same time, so that it can be re-used regardles of the process that requires this kind of functionality.

woensdag 4 mei 2011

Continuity as a service

(this post is not really about Identity, just a translation of my article from november 2009)

Nowadays everything is turning AAS: software, infrastructure, platform, security, identity, storage. More and more the traditional IT gets more foggy, we are more and more in the clouds. What remains of the old IT profession is to design and manage new things that have not yet been migrated to the cloud. That is no fiction: many companies transfer their legacy applications to the cloud. Even 'legacy' processes occur in the cloud, just think of HR and CRM processes. The cloud reminds me of that old Blob, the science fiction movie, cloud is becoming so pervasive that it seems to take control of everything. And just admit it, we find that exciting, scary and fun at the same time. But if everything disappears in the fog, how do we know that business is as usual?

The critical reader will, however, say that cloud is nothing new. It is nothing less than what we used to call ASP or Grid computing and so far we could reasonably well cope with that. Actually, cloud computing is a form of outsourcing and hence we do have a lot of experiences, both in a technical and a functional way. We know about the definition of requirements, managing contracts and we know how to deal with risks. We are in control.

In my opinion however, that is too simplified a representation of the problem. There is more to the cloud than just to call it a form of outsourcing. Let's make a distinction between between the cloud and the cloud. Not everything is opaque.

There are cloud variants that resemble regular ASP or outsourcing solutions. If you arrange with a provider to host specific services, that is just outsourcing, although not via leased lines, but via the Internet and that is not very exciting. It only becomes exciting if the same provider does the same for other parties and even more exciting if that provider in turn will outsource part of his business to yet another cloud provider. And that happens as we speak. Already CRM providers offer CRM services, hosted somewhere in the cloud on third party hosted cloud platforms. Just think of Amazon's Elastic Computing (EC2). Who knows where the real iron is? It seems so simple, you use a CRM service but the only specific part of the service is your personalized bill.

There are many security related questions. How about privacy, access control, change management procedures of the application, operation?
Fortunately, most of these questions are similar to the traditional outsourcing environments. Most of the problems are handled in contracts: agreements relating to ISO certifications, audits, SAS70's and TPMs are common.

But the core of the AAS problem is that contract partners are not always the parties who offers the actual service. You can try to mitigate risks in contracts, but the fact of the matter is that you want to move to the cloud, because of the positive price / performance ratio of multi-tenancy and the (re)use of standard applications. Long term subcontractor relations in the real world don't exits in the Cloud. If one platform provider is too expensive, our service provider just moves to another. This means that we are victims of the arbitrariness of our providers.

Back to the risks. Most risks are well known. Using standard operating procedures, access control and audits we can identify and mitigate problems relatively easy. And already there is a lot of information about security in the cloud. But one area of risk is not yet completely clear, the risks of business continuity.

The cloud is in many cases seen as a solution for business continuity. The cloud consists of virtualized, web based services in environments that are accessible via the Internet. This means in turn that the availability of iron is no problem (simply moving images), and scalability and performance are just issues of more iron and the availability of the Internet is the limitation of accessibility of the service. All fine. But the Cloud is not just a solution for business continuity. There are specific problems and there are no solutions to these problems yet. Indeed, even parties like Gartner have no ready-made opinion.

In this article I will briefly introduce some some specific cloud related security problems and indicate solutions to address the problems. I would like to stress that this is not a scientifically sound enumeration. It is astonishing how little is published about Cloud (SAAS) and BCM.

  • The service provider drops out: can we address this as a regular contract deal, like ASP outsourcing? Unfortunately no. In a regular ASP outsourcing deal we are aware of the underlying application landscape and the underlying data models. You can for example, create a periodic copy of the environment and information and rebuild the landscape if needed. In many cases it once was your own... This is not possible in SAAS. If the provider fails, all knowledge about the apps and landscape may fall away. Apps and data structures belong to the SAAS provider and you can´t uses these if the provider fails. The minimal solution is to periodically dump data (both transactions and management and data logging) in an understandable file format. You should make this a contractual right.
  • Traditionally Escow is a business continuity measure, but since changes on SAAS applications landscape may be so frequent, Escrow is not a real option anymore. At this moment there is no ´Cloud Escrow as a service´, this should be considered as a giant gap in the market.
    Gartner indicates the interesting idea to ask the cloud provider to open source the application code in case of a bankruptcy...
    An other alternative is the contractual agreement whereby you have the right to run the application in your own environment in the event of a disaster at the cloud provider's.
  • It is not the SAAS service provider, but the underlying infrastructure or the platform supplier that drops out.
    Can you rely on the traditional subcontractor relations to help you into operation again? Is it enough to trust your SAAS provider to abide the contract? No way, it would take too much time to transfer the application landscape. In the cloud-epoch we also need cloud measures. Securing both data and code is vital, so it should at least be contractually arranged that a fallback in case of the SAAS failure can take place. It is not enough to claim responsibility of the SAAS provider. A switch to another SAAS provider, as a preventive measure, should legally be a realistic option.
  • You need to define what can be called an incident or an emergency up front, in order to create a contractually sound escalation path.
  • Of course your employees must always able to access your own application. You should therefore take care for a reliable Internet connection and thus a reliable connection to your cloud environment for your own employees. Availability is not expensive, but make sure that the coworkers can connect to the right cloud environments. Arranging for alternative connections, such as UMTS-like channels, has to be considered.
  • Availability outside the regular network mean that you not only have to take technical measures, but you also need to realize functional measures. And that brings a management burden entail. Especially Identity Management in the cloud is at least as important as it is in the physical world. Identity 2.0 and federation will be very important. Ensure that these processes work as well.
  • The latter does give rise to ensuring that SAAS solutions are not embedded in a chain of business processes. If such a SAAS process solution collapses, the whole chain of business processes may fail. There is more than this reason not to integrate Saas in your process chain: until today, there are still no industry standards to enable parts of business processes to make side steps to other processes and back again, like to Saas solutions in the cloud. So far, cloud solutions are point solutions. From the perspective of continuity that need not be bad at all.
  • And of course all standard management security measures apply. Think of sound purchasing procedures, performing penetration testing and requiring SAS 70 Type 2 statements.

The uncertainty surrounding continuity is high at this moment. The question is whether for business-critical applications sensible solutions in the cloud exist today. An assessment around the continuity and security risks and safeguards in place seems to be appropriate. The issues described in this article should help to answer the question.

dinsdag 31 maart 2009

European Identity Conference

Just a short update:
from 5th till the 7th of may I will attend the European Identity Conference in Munich. I will be presenting a few thoughts about Access Control in the Cloud, covering Claims Based Access Control and Identity Provisioning (in the fog...). My talk will follow Martin Kuppinger's in Stuart Boardman's forum. I'm looking forward to meeting lots of experts in the field.
Munich, twice within a year: last year I presented a similar story at The Open Group's architecture practitioners conference. I like this city :)