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

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

India
  • Information Technology Act

Austalia
  • 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 6 april 2016

How to manage non personal (system) accounts



Customer often ask me for best practices regarding management of non-personal or highly privileged accounts in the process of implementing an Identity and Access Management (IAM) solution. This is an interesting question, because in an IAM project, we try to manage all kinds of accounts, but this type of account is different from accounts that are owned by end users. This type of accounts can’t directly be related to a uniquely identifiable person, nor are they the result of the 'joiner – mover - leaver' HR processes in an organization. So, how do you manage the existence of such an account?

Types of non personal accounts
There are Non Personal Accounts (NPA’s) and Non-personal System Accounts: (NPSA’s). We can identify:
-       Admin or root account
The admin or root account of Windows and Linux or Unix servers is highly privileged system account on the respective platforms.
o   It is authorized at the highest level
o   It has access to every file and process running on a platform.
o   The ‘root’ or 'Admin' has the permissions to change the behavior of their component;
o   Commands can be run from it as well as react to responses of the system.
o   Operational use of the account needs to be monitored continuously.
-       Superuser account
It's a business information system or application account, that looks a lot like ‘root’. It is there when the system is installed, it’s a system account. The Superuser has permission to modify, making it a risk critical account in an information system. Like Sap* in a Sap environment.
-       Service account
Accounts for middleware processes like DBMS’s, ESB’s or other ICT components that run on top of the Windows or Linux operating systems. A special form of a non-personal account is an application account in a DBMS to give database access to an application.
-       Batch user account
An account used by a batch job process, it is most commonly used for scheduled batch jobs, like nightly file transfers.

NPA characteristics
NPSA’s have a few characteristics in common. They are non-personal and they are not directly connected to a person. Login with the account doesn’t leave an audit trace showing which person is actually using it. And, of course, NPSA's are very powerful and so use of them should be tightly controlled.

Service and batch accounts also have a specific similarity: one typically doesn't login with such an account, these accounts are not used interactively. In most cases such an account is only used as a placeholder with some permissions to perform specific tasks, like running a webserver with the limited capability to process https-requests and write log files.

Modern IAM solutions can be implemented to facilitate provisioning of personal accounts for specific user functionality. Since non-personal accounts are not an attribute of an identity, there is not a sole user that can be connected to an NPA, so an IAM solution is not suitable to manage them.

If not an IAM problem, then what?
These accounts belong to the component that they manage. The Windows operating system comes with the Administrator account, Linux comes with root. You cannot install Linux without a root account. You may not by default be able to login with it (as on Ubuntu), but the account is there. So by installing an OS, you automatically get the 'God'‑account. There is no choice, it is the result of the change process that leads to the implementation of the OS. Such an NPSA should only be used in a controlled manner from specific processes, like an incident management process (admin may be needed to assist in a catastrophe), or the change management process (the admin permissions may be required to perform an infrastructural change).

The same is true for service accounts: when installing a middleware component, like a database management system, the account is created to enable the service, hence the name service account. Again, you have no choice. You might install the service using a 'root' – type account, but that will result in a security violation, Thou shalt not run any service as root!

And again, for batch account the same is true again: a batch process is created as the result of a change request. The batch tasks are created to support an information system, or a business process. The batch job is created to make it possible to schedule the automatic execution of the tasks. A batch account is created to make it possible to use resources on the system.

This leads to the following conclusion:
Non-personal accounts have to be managed in the change management process.

This has the following implications:
  • The account has to be registered in the configuration management database, it is an attribute of the component that it belongs to. Admin belongs to the Active Directory. Root belongs to a linux server. The account named 'Oracle' probably belongs to an Oracle dbms instance: the dbms is a managed component and the account name is Oracle.
  • The account has an owner, who is accountable for the use of the account. Admin and root belong to the manager of the ICT department. The SAP account is owned by the system owner of the SAP system
  • The interactive accounts should only be used for infrastructural changes or calamities.
  • The non-personal system accounts should never be used interactively for operational tasks.
  • The passwords of these accounts must remain secret. They should be secured by means of an envelope procedure, a password vault, or by using a Privileged Account Management system (PAM, like CyberArk, Hitachi PAM, Thycotic or CA PAM to name just a few). Any use has to be related to a service management ticket (an incident or a change). 
So, there you have it. Non-personal accounts must not be managed in an IAM solution, they have to be managed by the Change Management processes in an organization. Either they are owned by ICT or by the system owner who owns the information system that the account is used for. You should not manage privileged accounts in an IAM solution. And if you have to execute tasks with one of these accounts: use a Privileged Account Management system to secure it.


woensdag 28 mei 2014

All your passwords are belong to criminals

Again a few issues with password being copied by criminals. This week alone saw mentions of ebay, avast (forums) and spotify. In all cases the managed passwords were said to be hashed, so criminals have to brute force the passwords. But that is just a matter of time. And since Moore's law extends to password crackers, chances are that the copied passwords will be guessed shortly.

What does this mean? The Avast case looks not very critical. As I wrote earlier, many people create account with little security, just for the purpose of connecting to services that are not very critical. But the ebay case is a severe incident.
ebay is not just any website, it's a site that allows you to make transactions and it keeps lots of files and records about you. It's like a digital identity and they know your behavior. And the criminals not only stole the password and userid, but other sensitive data as well.

Of course you should change your ebay password. But: since your ebay account is important for you, you may well use the same account information for other sites too.

If by any chance you use the same ebay password with any account that is connected to the same email address that you registered at ebay, you should change the password for those accounts too!

donderdag 14 november 2013

Adobe lesson learned: do not use complex passwords!


By now we all learned about yet another password leak, this time at Adobe. Not just some incident, no, it's a big one, with some 130 million passwords in the open. A big scandal too. And of course we are amazed at the large number of too obvious passwords chosen by the Adobe customers. Passwords like '123456' and 'secret' are amongst the most frequently chosen passwords. Are we really surprised? No of course not. We already knew that people are not very aware about the security risks involved.

Who are those customers? They are people like you and me, consuming services anywhere on the internet, Services like those offered by Adobe. And for most of those services the provider wants to know who you are by asking you to register an account. So, many of us did.

Accounts

Let me tell you about the way I create accounts. In order to protect my privacy I have to protect both my identity and my behavior. So I try to separate my digital life from my real life as much as possible. And I bet that I'm not alone in this. My preferred method is to create an account using an alias. And since providers want to reach my alias, I need to provide an email address. If possible I use a disposable, or a fake email address. Next I have to pick a password. '123456' will do just fine. Why?
This password is not there to authenticate, it's there because the provider wants me to provide a password to ensure my permission to use a service. But I didn't use a real digital identity, I just claimed some capacity to download whatever I want from the provider. I don't care about protecting it, because in real life it just doesn't exist, and in all fairness, it's worthless. In fact I may have created an Adobe account a long time ago, but I don’t even remember it. And if I don't care, it's just not relevant how secure it is or how complex the password is. The only thing that I need to take care of is to NOT use one of my regular identities and passwords.

That's my real protection. As long as a provider or a hacker for that matter, cannot link the non-existing identity with a real identity, there is no danger for my real privacy if the provider or hackers publish '123456'. I couldn't care less. So, lousy providers like Adobe are not really a risk for me. I was right in not trusting them.
A far better way for providers to connect to customers would be to let them use an external identity, that way you don't need to register an account with the provider and the provider doesn’t need to protect it, there is no password... If you are free to pick an external identity like facebook, Twitter or LinkedIn, then the risks of data leakage are far less. There's another privacy issue, because those identity providers know your interests because of the federation stuff. I will not elaborate on this issue, but if you have enough digital identities, every identity provider only knows part of your interests, part of your activities and thus part of your identity. Divide et Impera.

Threats

The Adobe leak led to a lot of noise in the security community. There were two main comments: Adobe is stupid by not enforcing better security, I agree. And: users are stupid for using simple passwords, well, I don't fully agree. And I will explain this:
Account and identity management is tricky. There are two risks:
1) Someone knows you and tries to steal your identity.
2) Someone knows your password and your login name and tries to find out your real identity and reuse that information

The first risk can be real, but it need not be that big, provided that you think about a few best practices. Protect your behavior. If someone doesn't know to relate your real identity to a digital identity, not a lot of harm can be done in the digital world, in Cyberspace.

As I mentioned, the second risk can be neglected as well, if you understand it and act upon it. I hope/believe that most of the Adobe top 20 passwords are used by people who knew this. In my opinion most of the accounts used are disposable accounts. And preferably accounts that cannot be linked to real identities.

Password complexity

Both reactions to the Adobe leak came down to one issue: password complexity. Fact was that Adobe didn't enforce password complexity, not in the user space, not by using good practices for cryptography. Second fact: lots of users didn't use complex passwords.

Password complexity is difficult. A password needs to be complex for a few reasons:
- You don't want it to be easily guessed by someone who knows your digital identity.
- You don't want it to be easily cracked by someone who has access to your encrypted password.
Yet at the same time you want it to be easily remembered, by yourself.

The first risk is in fact the risk that we need to manage to mitigate the threat of someone who knows you to steal your digital identity, that's the first identity risk. It's the risk of someone retrieving an identity => password combination based on known identity information.

The second risk is more difficult to manage. The enormous amounts of processing power makes this risk hard to mitigate, password cracking isn't that hard to do anymore. This risk works the other way around: someone tries to retrieve a password => account combination based on known password information. Encryption of the password in transit and in storage does help safeguarding the password information, but it will probably only help temporarily. So we are trying to use one measure, password complexity, to tackle different risks. This may seem efficient, but in fact it's not what we need to do.

In order to prevent identity => password retrieval, we need password complexity. No one should be able to retrieve a password based on identity knowledge alone.
One example is Phishing: an attacker tries to retrieve secret information from a known identity. That means that the real, or physical identity => digital identity => password trail needs to be protected. And since the password is the valuable item, the password needs to be secured. That means using complex passwords (and to fight phishing: educate users to not hand over secret information!).

To prevent retrieval of a valuable identity based on a found password, another mechanism is required. If someone retrieved a password, he may be able to retrieve the digital identity, but he should not be able to retrieve the real identity behind the digital identity. Why?
This might lead to misuse of the identity => password risk!

If the password => identity trail can be found, an attacker might gain knowledge to intercept other identity => password combinations. The identity is the valuable resource, so you need to protect your identity. And the best way is to use disposable identities or external identities in those cases that you have to trust providers.

This leads to an interesting conclusion


Adobe user accounts with complex passwords, may well be more at risk than accounts with easy to guess passwords: customers using a complex password may well have used a valuable identity, expecting the complex password to protect it. How about that?

In my next post I will introduce a real simple complex password method.