Ransomware incident analysis

- Lets start with a disclaimer... I wrote this post a while back, but forgot to publish it, sorry...-

Ransomware encrypted all of the New Jersey Spine Center's electronic health records of patients of the practise. That's interesting news. And I don't believe the explanations in the press release. They were not the victim of some advanced malware sample, I my opinion they did not apply the correct basic security controls.

Ransomware typically encrypts documents, like word, excel, powerpoint. Reading between the lines of the press release, it seems that the practise doesn't use a document management system, a content management system, or an electronic health records system, the practise stores all data in files.
Managing files is a big problem. Ransomware is just one of the problems: if your account is compromised, the ransomware software acts on your behalf and encrypts the documents that you have access to. This is an even bigger problem when using shared folders on a filesystem: the ransomware software not only encrypt your documents, but also all other documents that you can edit. The more permissions you have, the bigger the risk. And if your account is privileged, the problem may even lead to a catastrophe.

In this case there are more strange phenomena. According to the press release the malware would have used passwords that are stored in a file. Do I believe this? No way, the ransomware we know is not actively searching for documents with passwords and when found decrypt the passwords in order to be able to login. No, ransomware makes use of naivity of people by making them activate the ransomware. The only way passwords can be reused by criminals is by criminals remotely hijacking sessions. That's a different problem.

The press release suggests that all of a sudden the virus protection software blocked the malware. That's not how it works. The more logical explanation is that the malware has been active for a while, without anyone noticing. After an update of the antivirus signatures the notifications of the antivirus software showed the presence of the malware and the malware protectoin software may have blocked instances of the ransomware from staying active. The longterm presence of the malware can be assumed by the fact that even the backups of the data were encrypted. In my opinion the backup software has backuped the encrypted files on the backup drive, thereby overwriting possible older original files. And that must have been a while... Or there is not a backup system, but the files have been copied to another filesystem, on which the victims had too many permissions.

Why did I make this analysis? A while back I wrote a blog about ditching documents. It may have been a creative way of solving the problem, but I feel that it may well be a valuable advice.
In electronic healthcare systems and content management systems you don't manage documents, but the content is stored in a database. Malware cannot encrypt data in the database: it would require system authorizations in order to abuse the database management system to be able to encrypt the data. And no, I don't believe that ransomware is able to crack the system password. It would require knowledge of the system used and of the infrastructure the system is running on.

And by the way, ransomware doesn't happen all of a sudden. It requires user interaction. Users visiting infected links, websites or users opening malicious documents.
The hospital paid the ransom fee in order to get the keys to decrypt the data. Waiting for the next instance of malware infecting more data.

Parts 3 and 4 of the blog series from RBAC to ABAC

This year I joined the new Dutch subsidiary of Nixu Oyj, the Finnish cybersecurity company, as a security and IAM consultant. Nixu employs over 50 IAM consultants, so it feels like a great place to have conversations about digital identity, access control and to share knowledge. What better place to post my blogs?

Parts 3 and 4 of my blog series about migrating from RBAC to ABAC have been published at the nixu site:

Part 3 About the need for dynamic access rules

Part 4 Using roles as attributes

Enjoy these reads and feel free to contribute to the discussions!

Migrating from RBAC to ABAC, part 2: Access control fundamentals

Down with the role! That's actually been my motto for quite a while. But getting rid of the role cannot be done overnight. Especially since we are rolling out roles in great numbers. And that, by itself, is not all wrong. Just the pursuit of greater control of authorizations is good. However, as explained in my previous blog, a role is not the most logical, most efficient or most flexible way of managing authorizations. A role is basically just a concept developed to make a translation of business functions to technical permissions. And that requires some quantum leaps.

One of the leaps is that we look at what a person must do and not what authorizations a person needs: When someone has the position of an ‘accounts receivable administrator’, he or she gets the authorization to manage debtors. But that's really a huge mental leap. Actually you should argue just in the opposite way: what tasks have to be done, and then evaluate what access is needed: both for a person and an authorization. That seems trivial, but it is a fundamental reversal of the authorization model.

Access Control in Reverse

Access should really work out this way:

Records of Accounts Receivable should be managed within the finances process. The process owner of this process is accountable for managing this process. The requirements for performing a certain task in that process, as defined by the process owner, are: relevant education, experience, organization (department), location, time of day, device. And perhaps even some extra quality requirements defined by the process owner to ensure that the processing is carried out correctly. For example: that the person executing a task cannot manage his own customer records and that no two critical consecutive tasks in the same process may be performed by the same person. And the process owner defines these rules to prevent fraude and misuse of controls. Yes, this is Separation of Duties. This is where SoD comes from!

If a process owner already captures such a lot of quality criteria, for the process owner it is completely irrelevant to define who may perform the task, provided that the person performing the task meets all criteria. A process owner doesn’t have to define who should receive the authorization, he just needs to be able to verify that someone who performs the job meets all the criteria defined.

Fundamentally different

This in fact is a fundamentally different way of thinking about authorizations. We no longer assume that the user of an information system has the correct role, but that he has to meet the defined criteria, competences and context. And those are the attributes of a person's identity or context. If those attributes correspond to the required quality standard that have been defined in the form of measurable criteria, then there is a match and only then this person may perform the task. And as a bonus… the calculated access permissions can even differ per session, or moment, based on context or whatever dynamic criteria were defined…

So, yes, it looks very logical to adopt such a model. But then other questions emerge:

Where do these attributes come from? And how do we know if these attributes are correct? We will discuss this matter in a future post. And it will imply some serious changes to migrate from RBAC to ABAC. But based on the old Role Model we can imagine a migration scenario from RBAC to ABAC.

As I wrote in the first blog, RBAC is aimed at providing authorizations to people to perform certain tasks. If we can assume that the person who has to perform the tasks effectively meets the quality criteria as defined by the process owner, then we *could* say that this person’s role *implicitly* has the right attributes. That means that we could consider this role as all required attributes… And if so, migration of RBAC to ABAC only is a technical migration:

Instead of logging into the application with a username and password, the user now just connects to a business function through a federated protocol, using a SAML message containing an indication of the identity and the role in the form of attributes. One does, of course, need to adapt the application to allow for access using a federative SAML protocol…

The migration of an application from traditional RBAC (=through provisioning of account and authorizations) means that we just need to change the login facility, because the authorization model in itself does not change. The application needs an interface to be able to parse the SAML message and to map the attributes to the RBAC model of the application. That’s all: Since we still use the Role metaphor, the authorization model and the permissions don’t change.

And of course we need to add an 'Identity Provider', because such specific component must generate the SAML message that contains the ‘traditional’ user identity (account) and role (as an attribute). In a future blog I will expand on this, since this may be the most important migration aspect.

Hybrid ABAC model

The new access control model, using a traditional Role in the form of an Attribute, can be regarded as a hybrid ABAC model. Hybrid in the sense that authorizations are still linked to roles, but that modern federation technology is applied. Hybrid means that an RBAC authorization model is used, but that the underlying technology for ABAC, ie federation, is deployed. We no longer provide accounts and authorizations to target applications, we use federation techniques. Real ABAC would mean that we no longer use Roles but just rely on attributes. But this full (dynamic) ABAC model requires some more fundamental changes to access management and ICT infrastructure, ABAC requires a new architecture.

The hybrid model is a pragmatic solution to switch from the traditional IAM technology to the modern technology.

In the next part in this series I will explore more about attributes and information security.

Migrating from RBAC to ABAC (Part 1)

A long time ago I wrote the following statement on my LinkedIn profile: "RBAC is EOL". And in my not so youthful overconfidence I mentioned this during an intake with a potential customer, who asked me how they could introduce Role Based Access Control (RBAC) as conveniently as possible. That talk never materialized into an assignment…

‘RBAC is EOL’ clearly was a premature statement. I must admit Role Based Access Control is far from End-Of-Life. Rather, in practice, we see RBAC becoming more popular and we see more and more organizations starting RBAC projects. Following on the heels of financials and government, other industries are becoming aware of the need to address authorization management. IAM projects and RBAC solutions are increasingly embraced and most of the major information systems, such as SAP, Oracle EBS, CODA, EPIC, Salesforce, Chipsoft, have been built in such a way that RBAC is the de facto authorization model. RBAC is a well-known, but not well understood, way to think about authorizations and access control. Surely I can help customers with that, of course ;)

Why on earth do we use RBAC?

RBAC promises to be a simple access control model, but it’s very difficult in theory, here’s a link to the original NIST publication: http://csrc.nist.gov/rbac/ferraiolo-kuhn-92.pdf

But also in real life RBAC is very complex. Let me explain why RBAC should be EOL.

First let me explain why we use RBAC: Ease of operation.

Yes, really, that's really the only reason that we use RBAC. It is an easy understandable method to grant access to read a file, a record or to allow access to a location for a person. It’s also easy to control access: you can find out if a person has access, you may well be able to explain why that is the case and whether the granted access is correct.

Because of use of the concept of a 'role', we can disconnect an 'authorization' from a 'someone'. That saves a lot of administration. If two employees have to perform the same tasks, they need to have the same authorizations. If we give both persons the same ‘role’, then they have the same permissions, at least if the permissions that are required for execution of those tasks are bound to that same role. If someone else is assigned the same role, that person will also get the same permissions. So it's really a lot easier to grant permission by assigning roles than to provide the individual authorizations to everyone separately. We start having problems when there are roles within roles, nested roles: In that case it’s getting foggy what authorizations a person effectively has. The best thing about direct assignment of authorizations is that it’s much easier to show what permissions someone has effectively. You can tell right away after all. Not that we gain much insight because after all, we still have to interpret all these granted permissions once again for every individual assignment of authorizations. Role management does make life easier.

But by just managing roles we’re not done yet. On the contrary. There is not one single type of role, there are different kinds of roles and different levels of roles and of course there are nested roles. There are roles in an organization and there are roles in applications. No, these are not the same!

There are lots of roles in an organization. And there are also positions in an organization. Positions in an organization result in a view of an organization for providing a wage to employees and it a position is created in the hierarchy of an organization. But roles are a view on combined activities within an organization, our way of organizing authorizations. It may look like a position, but it is not.

And here the difficulties start. Is there a relation between a position and a role. Is there a hierarchy? Can people have more than one position and more than one role? Can roles be shared between departments? And do all identical positions result in the identical roles? So, as you can see, the easy concept is getting a bit less easy.

In RBAC, roles are assigned in order to grant authorizations to perform certain tasks. Roles are in fact a set of tasks carried out by a person. A credit manager uses the financial system (the debt management part of course), Office365 (the share of his or her department perhaps?), the intranet, perhaps a module in a CRM system. In addition, a credit manager must have access to the sales administration, e-banking environment, the general ledger. But there are other roles with overlapping authorizations, roles for people that have an almost similar set of applications, but with different access within. That means that an authorization cannot be related to a single person. Here the perceived advantage of RBAC disappears.

Tasks

Now, who decides which tasks our staff with the role credit management has to execute? The hierarchical manager of our employee. And perhaps there’s also a process owner. But these managers have a different focus… the line manager obviously wants optimal performance within his department, but the process owner has different requirements, such as competent, capable and high-quality staff and separation of duties within the process. This can result in conflicting interests. A line manager wants to perform as many operations with a full occupancy, but the process owner wants a high-quality high governance process.

However, there is still another important player: the system owner. The line manager may well want an employee to perform various tasks, but that collection of tasks should be supported in the information system in the same way. What if the role model developed in an information system conflicts with the organization roles and process roles? This is not a theoretical issue, this happens every day in every organization.

Authorizations

Last but not least: what effective authorizations are there in a role? Employees in AGSAPAX-IAM-DEB-Linux-WS seems to get access to GRXACZP-LEDG02Q-File Transfer-RW. Is this? Who knows if this access rule (the kind you see in a lot of Excel sheets) is permitted? And is this authorization granted explicitly or implicitly? Who's in that group? Is that correct? Is that authorization still accurate and up to date? Is the authorization not too broad? How much do these rights cost? Who granted such access rights? Who linked these authorizations to the role? Has this been approved?

In my experience there are dozens more of these question. And they all lead to the same conclusion: the RBAC model may look like a practical access management method, but it is not. There are so many complications that have to be managed, that it’s hard to be in control.

Done with complaining. What are we going to do about it?

In part 2 in this series we start migrating from roles to attributes, my holy grail and I’ll introduce a hybrid ABAC model.

(this blog first appeared in Dutch at https://www.cqure.nl/kennisplatform/van-rbac-naar-abac-deel-1)

That was the EIC16 that was

Each year, the German security consultancy firm KuppingerCole in Munich is organizing a multi-day conference on the theme of identity and access management.

The KC conference was well organized. Nice location for both sessions and the inevitable vendor marketplace. Lovely brochures, event app, fine catering and a lot of famous people. We'll get back to that later. KC is a large company, has many expert analysts and these are actively present. They moderate panels, are chairing different tracks and give presentations.

The conference lasts three days, long days ... the first keynote generally starts at half past eight and the day closing somewhere between 19 and 20. But that's not all, there are also pre- and post-conference workshops. I decided to join a preconf day this year, namely the workshop on the theme blockchain. I cannot give a full overview of the conference, but I will point to a few highlights.

The hype of this moment is Blockchain. The pre-conference workshop lasted a whole day and treated the backgrounds and ideas around Blockchain and also bitcoin. Also on the third day there was extensive attention given to blockchain in one of the four parallel tracks. Briefly: Blockchain is a promising technology (immutable storage of transactions, transparent, fast and cheap), but so far it’s little used (not really an anonymous platform, ‘bitcoin image’ is not very positive). But biggest problem is the issue of trust. Can you trust the blockchain, do you trust the longevity and continuity? But the advice is: go play with it, within a year or three there are business cases and apps to make use of blockchain technology.

Second hype: CIAM, customer Identity & Access Management. And yet, actually not quite a hype, we have already know,  implement and use it. More importantly is the underlying mechanism, namely federation.

More or less the same applies to IoT and Big Data. These developments also look at federated solutions to preserve both the business benefits and guarantees regarding privacy.

Federation was not only reflected in many presentations. There was a separate track in which the OpenID Foundation presented the many developments. Of course there was OpenID Connect (yes, we really should implement this as often and as broad as possible) and OIX (OpenId Exchange, it so looks like the implementation of what I wished for in my old blogs - http://id-use.blogspot.com/2008/06/trust-model-for-identity-providers.html ), but also a number of working groups on the themes of health (the OpenID Heart working group led by Eve Maler of Forgerock) and the Financial Services API WG.

But not everything topic at EIC16 was about IAM technology, unquestionable the most impressive presentation was by Mia Harbitz of the World Bank. She described identity management in a world where a birth certificate is already a challenge. Children with a birth certificate get a vaccination three times as often as children without a birth certificate. She had more shocking numbers of people without a formal identity, without access to life saving services because of it.

Providing an identity to refugees is also a hot topic (especially in Germany, with 800,000 refugees in the past year). This was discussed in a separate track with an interesting panel discussion. It soon turned out that we give refugees an identity because we want to avoid them actually abusing the services paid by us. Not because we want to offer our refugees just enough identity to survive. Sad really ...

An interesting development was an initiative by Ian Glazer (Salesforce). He and Kantara (for example known for User Managed Access – we should make this a default way of customer access control) took the initiative to investigate whether the Identity professionals can unite. The "Keepers of Identity" are increasingly more import, cooperation is essential. More info: https://kantarainitiative.org/digital_identity_professional/

And for those of us who are in despair… there are still use cases for on premise use of Active Directory. Kim Cameron (Microsoft) sees a shift to Azure AD, but an on premise AD will still remain for the coming years.

These were intense days. I finally met with many digital friends. And I advise you to look up the hashtag #eic16 on twitter. Lots of nice tweets, many photos and video’s and links to interesting articles.

And do yourself a pleasure and visit the blog of my good friend Alessandro Festa...