Feed on

I might be a bit naïve when it comes to Service Provider but, normally, I would expect contracts to contain just a bit of clauses regarding intrusions and loss of data but apparently this is seldom the case. Only thing that is measured is uptime in the SLA and with todays very efficient malware and hacks an infrastructure will continue working, quite often undisturbed, until the hackers decides that it´s time for a ransomware.

It is very seldom that Service Providers add the extra cost of protecting against Credential Theft, with my full understanding as it can be quite costly for the first projects, but at the same time they are digging their grave at the same time. With smaller Service Providers having to compete with cloud based services their incentive to invest in security should be higher as a way to keep the customers but when the customers don´t understand the need what are you to do?

The most common scenario I see is that the customer understands the need for Credential Theft Mitigation (CTM) and asks their Service Provider how to manage this and either gets a ‘That´s not in the contract’ or, even worse, just a blanc stare of not understanding.

In those cases most of my customers decides to take matters in their own hands and move the critical servers (Tier 0) into another datacenter (preferably their own) and either run it by themselves or give it to a trusted Service Provider that have the needed protections for CTM.

I just hope that Service providers will understand the risks they are exposing their customers for with their unwilling to implement CTM.

Following the previous post about consequences when you deploy the identity control plane we will now focus on the security that you need to apply. The security is to be divided in three parts: Identity management, Device and Identity.

The identity is the full definition of the identity to the level you need to be sure that the right person is logging on to your system. Verification of this determines the level of trust you put on an identity and hence what you allow within your system. You might want to allow a blogger to post on your website with username and password only but require Multi factor authentication for managing your bank account.

The device is the tool that you use to logon and conduct your tasks with. The more trust you can give the device the less security you can apply to the identity. Trusting the device means that you monitor the health using Device Management software, monitor geographical travel, protects and detects malware etc.

Identity management is the most crucial as it governs the level of trust you can put the identity and the device. Protecting the identity management is key to any identity as a control plane solution. You must be able to trust the identity management system to the maximum possible. You do this by compartmentalisation between identity management and other functionality and deploy secure management of the system using dedicated verified devices with no internet access using encrypted and dedicated network channels. Failing to deploy such protection means that you eventually with lose the identity management and by that your whole infrastructure.

What does it mean to use identity as the control plane? First: this is nothing new. Identity has been used for many years in conjunction with physical and network control plane. The difference is what emphasis that has been put on the different control planes.

With physical control plane, the emphasis lies on the security of the lock, the thickness of the walls and less on the verification of the identity. The old ‘lock and key’ states that anyone with the right key can open the lock. Very little effort is put to secure the access to the key.

With network control plane the emphasis lies on the firewall and limiting access to the network. It is quite common to combine it with some type of authentication but often the identity function is not protected, the focus is on creating new rules in the firewall or segment the network in even smaller parts.

With identity as the control plane you combine it with a good encryption of the data. With todays available encryption methods most data can be sufficiently encrypted quite easily. But the challenge lies in protecting the identity. As identity as the control plane means that the identity most probably is exposed to the internet it must rely on very hardened services. It must be strong in itself, meaning that passwords must be combined with other factors like certificates, device security, authenticator app and similar.

This is a big change for many companies that have trained its users that a password of 8 characters or less is secure enough. Suddenly they must provide multi factor authentication where one of the factors is a password with 16 characters.

One of the buzzwords you commonly encounter is ‘Identity is the new control plane’ but what does it mean? The term refers to where you manage access to a resource. In the case of identity it is where you manage identities and their access, in our case Active Directory. But to make it more understandable let’s take a look at this picture:

The physical control plane was the first versions of security, still commonly used in data centers, for managing access to data. Only way to get access was to either have the key to the room or be able to be let in through the door by someone with access. Same goes for paper documents in the bank vault and similar.

With the evolution of computers came the network control plane. Suddenly we had the possibility to connect computers to a network and let the network manage our access. With access to the network we got access to the data. This is still commonly used to day in many security functions and have shown to be successful for quite some time.

But with evolvement of new technologies, new requirements of mobility etc. we have moved to open networks where we are always connected. The network control plane tried to manage this by using VPN but still many of us within the consultancy industry needs to be outside the office. Hence the arise of identity control plane. The identity control plane means that you get access to the data if you have the right credentials. Meaning that your data could reside anywhere and still you would be the only one who could access the data as long as your identity is secured.

This means that the target for the security you implement must shift focus.

I love doing presentations and I had the opportunity in southern Europe to present for a few customers my view on how to administer on-prem services. What I presented was Microsoft Secure Privilege Access Roadmap. If you havn´t read it please do. It gives to quite some details how you should manage the administration tasks in your environment. Focus is of course on credential theft as that is account is the new perimeter for information.

Credential theft is interesting as it comprises of many different things but one of the more important is stealing of the hash and how to prevent it. I explained how it works and the number of ways you could mitigate it. Halfway through the presentation one person in the public, CISSP-certified and known to me to have worked within the field for 15 years, raised the hand and asked with a bit annoyed voice: “This credential theft you are talking about. Is it something you recently invented? I have never heard of if before.” The room fell silent and I was stunned a few seconds trying to comprehend what was just said. Gladly the person sitting next started to whisper and within a few seconds a heard a faint. “Sorry!”

There was a bit of a laugh in the auditorium but it opened up an opportunity for me to discuss the importance of using the correct terminology when discussing security and even more important, making sure that your customer understood. I was very sure that credential theft was a known terminology but apparently not. This phrase is common in the literature but if you are spending your studying to maintain your CISSP on just a limited amount of sites you might miss the latest for 15 years. ?

SOC for clouds

During a workshop at a customer we started to discuss their SOC. Today it fully manages their onprem servers and clients but when asking about their cloud data center (Azure) it turned out that it was not managed at all beside that the security functions was activated but not used.

Getting the security functions in Azure joined with your current SOC is very important as attacks have started to emerge on Azure as well. Even if you have a good security in Azure as default there is still the possibility to be hacked if you are not careful with the management and deployment of solutions. Activating Log Analytics and have that data sent to your SOC will enable them to manage your Azure environment as well and give you better insight in your whole environment and the threats against it.

Azure is a very extensive cloud service that provides several functions and a very short ramp up-time. This is all well and good and it is possible to get a very extensive security in place quickly if you get the right licenses and services. What many companies forget is that Azure is not a fabulous simple cloud service. It is simply another datacenter with some cool functions for you to start utilising. You´ll have to treat it as a datacenter with the same control mechanisms regarding access, resource management, change etc. The full ITIL is applicable even here.

Just take a simple function as access control. Would you allow a technician at your company to manage your whole order system for new servers in your existing datacenter through a simple logon with her or his personal email with a week password? Even worse, using an unmanaged computer on an internet café somewhere ridden with trojans? Most probably not but this is the reality for many companies starting out with Azure.
When first starting with Azure, give it a few minutes thinking on how to manage the subscriptions and mimic the security model you have on prem. Trust me, it makes life a lot easier for you!

IAM is a very strong tool to get in control of your accounts. With an IAM system for all standard users you will quickly protect all standard access and manage all access control. On top of that comes the protection of your privileged accounts and that means more advanced solutions like PAW or ESAE. In essence you cannot protect a privileged account if you allow it to logon to a workstation where you access internet or check your mail no matter what protection you have.

Should IAM be used to provisioning privileged users? Yes, to some extent it could be useful, like for Tier 1 system operators, database admins etc. But for Tier 0 users (in essence Domain Administrators) you should not use an IAM as you would like to be in very tight control of your Domain Admins and also because you don’t want your IAM-system to be part of Tier 0.

You have all heard about the layered security approach and probably understood it. Sometimes it just becomes very visible how it works. I recently visited a client in southern Europe where we are delivering a high security project and as part of that project we are working in a secure room, a locked and secured room.

In the endeavors to secure the area the client decided to exchange the lock and key we currently were using to the central keycard solution with logging to make sure that we knew who was going in and out of the room. Of course, the owner of the solution was trusted to enter the room even before this. As a precaution I decided to review how the current solution was administered. This turned out to be a laugh for all of us, one of those laughs you have when you realise you should had stayed in bed instead. The administration terminal was a simple laptop standing wide open in the reception, no password and only a two-character password to log in to the system. Furthermore, the server was a desktop standing on the floor with no protection on the database, no backups and no physical protection what so ever. The computers were never patched and was running old operating systems.

Two hours later the vendor was there and received an order to replace the system the day after.

I had a chat with a friend of mine, who is an enterprise architect and a damn good one as well, regarding integration architecture vs security architecture and where the cross section. While his stand point is that integration architecture is imperative to understand how business unites should work together my viewpoint is that from an information perspective, adding a layer of information classification and collusion issues, I need to understand what information the different business units actually use to be able to apply a correct classification on the information. You who have followed me for some time know that my view on classification is that it is only an accelerator on what type of protection you should apply and the type of authentication that should be used.

I had a case a few years back regarding access control and how visitors was to be registered before being allowed into a secure building. It turned out that there was an automated approval flow that moved from classification level 3 to classification level 2 (lower classification) without anyone understanding the consequences. In this specific case this was the enablement of a social engineering and technical attack that in the end enabled me to enter the facility with a full access card as a consultant.

« Newer Posts - Older Posts »