Feed on

On question that often pops up in my discussions is when to move to Azure. There are many considerations to take into account when it comes to a move to Azure and similar but from a security perspective it is all about the speed of reactions to a threat. If you have a really tight environment with a good detection capability and an excellent reaction speed to threats moving to cloud services will not provide you any bigger benefits. All others should consider it asap. Due to legacy there will be quite some time before a full move can be expedited and if that time is longer than three years I´ll recommend a full set of security services on-prem as well as in cloud. The cost will obviously be higher but the cost of a breach is by a multitude of zeros even higher.

So, if your cloud plan is more than three years, do implement a lot more security services on-prem.

I was engaged in a minor workshop together with a bunch of security architects to work out a problem why it was to challenging to implement a new security architecture. No matter the document, workshops etc. they did nothing stuck. New solutions not following the architecture popped up all over the place and the architects had to spend more time fixing things or bolt on old technology rather than steer the security in the right direction.

We started looking at their processes and they were sound enough following my security architecture lifecycle to the letter with very clear risk analysis and threat modelling going on as it should. We started to look at their security mechanisms and they was lacking a bit in clarity but the list of preferred functions was adequate but a could have had more details in how to implement them. Third point was the reference architectures they used and those was very high level but valid to the environment. Then I found the culprit: patterns. They had not fully understood how to create patterns. Instead of building patterns in the form of authentication pattern, identity usage pattern, secure server etc. they had built lists of mechanisms that was to be implemented but without the technical guidance that must come along it. You cannot provide a list with:
1. You must comply with the password rules defined in document 1.
2. You must authenticate the users according to document 2 using the prescribed protocols.

When coming to the patterns you must define the technology AND have a designer create detailed patterns and preferably ready made building blocks to be used if you are not providing detailed guidance to the development teams.

I helped them create a few patterns so that they grasped the principle and we will have a follow-up in a few months to see if that solved their problem.

Last months I encountered a strange situation at a customer. I did a security review and deployed some simple log analytics tool to identify where Domain Admins logged on as we suspected that an intruder was roaming around in the environment. To my customer´s fear we more or less instantly saw that the Administrator account was used on several servers for logging on, and that account was supposed to be unused. The SOC had not reported it and when I investigated the issue it turned out that the SOC was only looking for network intrusions and malware on clients and servers. This attacker used file-less malware and Credential Theft and as the anti-malware the customer used was not up-to-date it didn´t fully detect some memory functions commonly used by the malware the SOC was blind.

In the aftermath we could conclude that the reason for the SOC not seeing was that the cost for network logging was extensive so they decided to rely on that only as getting the server logs would have been to expensive.

As you know if you work in the field of Credential Theft Tier 0 is the most important thing to protect. With Tier 0 access I pwn a company, to use a security term. The implications from a contractual perspective is seldom considered when a company decides to outsource Tier 0, i.e. their Domain Controllers and PKI.

My challenge here is to understand why the risks aren´t understood either from a customer perspective or a service provider perspective. From a customer perspective the following is what I most hear when meeting customer after they have been compromised: ‘Top managers are deciding to utilise reputable contract security firms to be their security experts’. This means that they don´t understand the consequences of Tier 0 outsourcing and breach of Tier 0. This is all well and good if they write into the contract that Tier 0 must be protected but this seldom happens. Instead there are only quite general statements about security management.

From a service provider perspective they are bound by costs, mainly keeping the cost as low as possible, as the market is very competitive. In the high profile deals a price difference of a simple 2% easily mounts to hundreds k$ or millions of $ meaning that solutions that are not streamlined for all customers will not be implemented. Any service provider with cost conscious customers will sadly not implement the type of security described by Microsoft in SPA Roadmap. Furthermore, ‘reputable contract security firms’ are as any other consultancy company bound by the rules of supply and demand: it can only supply the competence it has and will only supply the competence customers buy. Many consultancy firms are interested in selling as much time as possible with a minimal of training as possible. This means that in the security market they´ll go for complex security products that takes time to implement, as that time can be billed to customers. They´ll also seldom update their skills on a corporate level, meaning that they´ll try to sell their defined security services even if they are outdated if the customers wants to buy them. As long as customers lack the skills needed to understand the risks and the proper mitigations for them less than good security consultants will thrive in selling ineffective security to customers.

During the following months I´ll dive into this a describe different cases I have encountered.

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.

Older Posts »