woensdag 22 mei 2019

Password non-compliancy

Google reported that for 14 years passwords for G Suite have been stored in a less than secure way: "We made an error when implementing this functionality back in 2005". Interesting. Now how about compliancy?

Below a less than complete overview of laws and regulations defining policies with regards to authentication practices, like password storage. It looks like Google and G Suite users are non-compliant...

·       International
  •  ISO 27001 / 27002 ch9
  • ISO 27017 ch9
·       EU
  • GDPR Appropriate controls Article 32, ‘security of processing’
  • ENISA IAF 6, R-11 SO11
  • PSD2 – Strong Customer Authentication
  • eIDAS safeguard S 2.11
·       France
  • SecNumCloud 9.5.a
·       Germany
  • BSI C5 IDM-11
·       US
  • SOX 404
  • NIST SP 800-53 R3
  • NIST SP 800-63b
  • US DoD Instruction 8500.2
  • Army Regulation 25-2
  • GLBA - Gramm-Leach-Bliley Act
  • CJIS Criminal Justice Information Services
  • COPPA 312
·                California
  • Information Privacy: Connected Devices (SB-327)
·       Canada
  • Pipeda Section 5
·               Ontario
  • GO-ITS 25 3.1

  • Information Technology Act

  • Protective Security Policy Framework

New Zealand 
  • NZISM 5.2.3 and 16.1

·       Industry specific regulations
  • PCI DSS 3, 7, 8, 12
  • HIPAA 45CFR164
  • NERC - North American Electric Reliability -CIP-007-3
·       Best Practices
  • OWASP Password Storage Cheat Sheet
  • SANS Password Construction Guidelines
  • CSA CCM IS07
  • AICPA SOC2SM S3.2.0
  • BITS AUP & SIG v6
  • COBIT DS05
  • HiTrust 01a
  • ITAR CFR 120.17, EAR 15 CFR 736.2
  • xkcd 936

woensdag 7 december 2016

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!

maandag 12 september 2016

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.

zondag 28 augustus 2016

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.

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.

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)