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.

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.

Still running XP? Bad for you...

Last month I wrote that, despite all warnings about the imminent death of Windows XP, until May 13th Windows XP could still be used in a relatively secure way. In fact, the recent off-schedule security patch by Microsoft proved my point. But I also said that from that day on XP is doomed. If you still use an XP system, chances are that the system will be a victim of an attack.

On May 13th, Microsoft publishes some security patches that will not be published publicly for Windows XP systems. Only a few organization, who pay dearly for extended extended support, will enjoy the benefit of keeping their XP systems alive. But for the rest of us, XP will be at risk.

What happens every month: if Microsoft publishes a security patch, criminal minds reverse engineer a vulnerability based on the changes in the patch. They try to figure out ways to penetrate systems that are not (yet) patched. And in many cases within a few days the first exploits are around. Since all Windows generations from NT onwards are very alike, chances are that a vulnerability in a recent Windows version exists in Windows XP too. And if a system is not patched, such an exploit will be a zero-day exploit for ever.

Can you protect XP systems that are not enjoying extended extended support? No, not unless you never connect it to the outside world directly or indirectly. Even anti-malware software may not guard an XP system against exploits.

What should you do? Migrate, migrate, migrate, to whatever more recent operating system that you can think of. If you're in a company: get your management fired asap. They are the next vulnerability that will not be patched.

Don't stop using XP until...

There is a lot of misconception about the security of Windows XP. Microsoft extended support ends today, after publishing the final set of security patches for XP that were developed to tackle security issues that occurred in the last few months. Microsoft has a 1 month patch cyclus, every 2nd tuesday of a month patches are published.
What does ending extended support for us mean:

If Microsoft would still support XP, the next set of security patches would only be published on the 13th of may 2014. Any zero day vulnerability that was discovered today, could, in an ideal world, only be fixed on the 13th of may, thereby leaving your pc vulnerable until the 13th of may. But that is the case for all supported Microsoft operating systems. Your 7, Vista, or 8 system would also be vulnerable until the patches of may 13t. Only in a few instances has Microsoft been pushed to fix earlier, but they keep with their regular scheme.

What does this mean for poor XP?

A fully patched XP system will be no less secure than a fully patched Windows 7, Vista or Windows 8 pc! Only on the 13th of may 2014 will the security be affected negatively because no new patches will be published. Your system will be vulnerable for ever...

Should you migrate?
Yes by all means. You may not be an interesting target for a criminal (you are, but I can probably not convince you today), but your pc is. It will be used as a spambot platform, or for bitcoin mining for others, running porn hubs for criminals, whatever. So migrate: YES


Should we panic?

Yes of course. But not because of today. We should panic because there are still too many XP systems.
Most consumer systems will be fully patched, but I bet that most companies who still run XP have graver problems. Many systems will not even be fully patched. So, consumers, you have one month left to migrate to 7, 8, Apple or Linux. Should you? Yes by all means!
And companies? You are in big trouble. You should fire the responsible management for not preventing this event.


===Update===
Hans Bos from Microsoft Netherlands mentioned that a fully patched XP system is less secure than a fully patched 7/Vista/8 system. He is right of course. Just have a look at Internet Explorer.
But then again, this has always been the case, XP has always been in a minor security league than more current systems. The class difference stays the same...

Facebook and Whatsapp, why worry?

The deal of the year, Facebook buys Whatsapp. And even before the dust settles, the privacy world is screaming murder. The privacy denying company buying a private messaging company spells doom for the privacy of hundreds of millions of users. You are warned to leave Whatsapp if you care for your privacy...

But is your privacy really at stake? Is the merger a new threat?

Facebook knows a lot about you. It knows your friends and relations, your likes, your updates, your whereabouts and it even knows what you would like to post but never really did. Facebook not only has access to your metadat, it has all content as well.
Whatsapp knows a lot about your telephone number. It knows the telephone numbers your phone number connects with and it has an enormous amount of metadata of all connections made.
And since both companies are American, you can bet that the NSA and it's friends have access to these (meta)data too.


But, and it's a big but, as long as a Facebook profile doesn't contain a telephone number, Facebook has no way to connect a profile with all Whatsapp metadata. There is no way to correlate a human profile with a phone profile.
It's a big but, but Facebook and Whatsapp live in different worlds en never the twain shall meet. So in my opinion there is no new privacy risk. If you really care for your privacy surely you would have left Facebook a long time ago?
So as far as I 'm concerned there is no need to dump Whatsapp. There are bigger threats to your privacy.



There's a second but, and that's a bit more tricky. A Facebook app and a Whatsapp app on a smartphone are different apps and they don't share between them, the operating system of the smartphone takes care of separation. Unless the operating system doesn't. I would say, stay away from any Facebook marketed phone...

So, until Facebook asks for your phone number, or you provide your phone number to Facebook, don't worry.

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.