Feed on

I was wrapping up an ESAE implementation at a customer the other day where my team had done a tremendous work, as always, in building a secure forest for managing their AD. One of the last tasks was to order a pentest of the solution. I´m perfectly fine with that, I´m even eager to let them have a go, as it´s a way to learn about weaknesses that we could fix.

We were scheduled to go live in about two weeks and I was quite a bit surprised to learn that we have to postpone the go live-date with six months due to that the resident pentester didn´t have the time. Talk about a security function becoming a blocker for modern security. My customer became very frustrated and there was a lot of yelling until we actually got the management to priorities this as we are to provide a critical security service for them.

I think I dare to say that pentesting in its current form here died today and I´m holding the gun.

How do you evaluate your security functions and how do you decide what security to invest in? Is an IDS the way to move forward or implementing the recommendations from NIST Digital Identity? Better stick with the IDS because it´s a thing you can implement so it is easier to measure the progress of the number of IDS flows you could integrate into the SOC. They might be encrypted and useless but at least they cost a lot of money and it is measurable. Who would care about better credential hygiene? How do you measure the effectiveness of a password of 16 characters instead of 8?

This is where attack playbooks join the match. An attack playbook is a description of how an attack works. There are a number of those that can be used to measure if an security mechanism actually does its work.

The simple theorem is this:
Break all known attack playbooks and add monitoring and response functions. After that you can invest in what ever security you have but don´t spend a single penny before you have managed all attack playbooks. Do reach out to you resident security architect for tips how to do this.

One of my core skills is conducting risk analysis, to be more precise, I tell my customer to quit fiddling with esoteric attacks and focus on the real challenges, like good passwords, MFA and credential hygiene. One common question I get is: Who would like to attack us? We have no money reserves like a bank, we don´t take credit cards like retail, we are not a government entity so why would someone bother (and why should we pay good money for security).

First of all, before answering the question, I must make my position clear here: You should never spend money on a security consultant doing risk analysis if you havn´t done the homework, meaning following the vendors best practices.

So why should you bother? Well, it´s quite easy: You can never control how someone might make money on your data, your computers or your environment. The obvious is ransomware: they encrypt you pay for access. Not so obvious is the cryptocurrency miners that utilize your computers for cryptocurrency mining. Less obvious is speculation in raw material. Just imagine if a company would produce iron or aluminum, a hacker got access and plants a ransomware on the servers and then buys a lot of the resource that is produced. The ransomware would then be activated removing a few producers creating a deficiency and that would rise the price. Or what if someone is speculating in that your stock price would fall?

You can never know how they make money on your downfall but it might be in a way you cannot control so make sure that you protect yourself in the first place.

I meet with many security departments in my line of work. One thing that has been showing it´s ugly face during the last two years is the reference to ‘The network group’, often spoken with a bit of fear. Anytime that I present Credential Theft Mitigation or Identity Security it is unavoidable that someone reference that ‘network group’ just like they are the deciding force for security. No matter if it´s the CISO, the CIO or any other, apparently the firewall administrator is the king and god when it comes to security.

I have spent some time helping a customer managing this and what we concluded was the following:
-network security seldom solves modern security problems
-network security normally has the privilege of problem definition for security due to history
-network security is normally backed by strong vendors with a large number of three-letter-acronyms to cloud the discussion
-network security points at Cloud act as a reason to keep the resources on-prem.

Did I mention that the pentester got domain admin for the fifth year in a row within a few hours? But that is of course the serverpeople fault.

To be frank, a lot of resources are spent on network security projects that has little to no validity in a modern world. Network security has played it´s role but is now to a large extent obsolete and should be regarded as legacy.

Moving forward, network security should first of all be mandated to use domain user accounts, no network management should be allowed to use local accounts. Second is to use privilege access workstations. There are so many vulnerabilities and flaws built in to the management of networks, despite the number of mechanisms they have, that having dedicated management workstation should be a no-brainer. Third, network security should be second to identity security, or even better, part of the security department.

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.

« Newer Posts - Older Posts »