crowmoor.se

One of my core mantras when I discuss security is to do the right things first. So how do you know that you are doing the right thing, isn´t that what the risk analysis is for? Correct! Five points to Gryffindor! There is however a better way to move forward. Imagine that someone has already done a very thorough risk analysis on a technical level that you could reuse. Say hi to MITRE Att@ck .

This framework points to a very important part in my campaign for better security globally: Do the right things first! This means that you should make sure that you block all known attacks using the tools available to you so that you then can spend time on the more challenging attacks. Not a hacker in the world will bother about using Spectre-attacks if your admins will click on a link on a workstation the use for both mail and domain admin tasks. MITRE Att@ck lists a number of attacks, attack play books, that you need to protect against. This framework is also used to evaluate the effectiveness of different security tools.

So take a good look at MITRE Att@ck and start using it today.

In the aftermath of the pentester´s failed attempt to get hold of Active Directory we started to discuss the long lead time of getting a pentester onsite. Sure, it´s mainly a question of resources and money but there is an underlying challenge seldom thought of. Today security functions is not static or passive. They have active components, they are updated, they work in conjunction with humans and are a lot more fluid in their functions than before. The standard pentest is normally just some person coming in testing a solution not taking the active defenses into account. The deliverable is a report explaining the identified flaws and we are sitting there with a long (or short) list of actions to take.

This isn´t good enough. You would want to have something more similar to the real world attacks. Entering the red and blue team. So, what is that in reality? Well the blue team is your Cyber Defence Centre doing it´s daily work and the red team is bunch of pentesters trying to find ways into the environment. The strength is the mutual learning when the red team explains how they did attacks and the blue team explains how they responded. With an ongoing campaign you will end up with a security level far surpassing anything you have today. And by the way, drop that IDS project, will you?

Sure, I´m not to fond of pentesters. Not that they don´t do a good work, making sure a solution is secure is important and there is always the possibility that I have assumed something that´s wrong. So testing is a good thing. It´s just that some are really cocky and view themselves as state of the art security consultants. Well…when we had the pentest done on the ESAE I told you about last time I was the one that could be cocky.

It didn’t start out good. The pentester arrived in the stereotype black long coat and with the typical set of gear that any pentester need. With a bit superior voice he told me that: ‘He´ll be delighted to become domain admin again. It´s just a Microsoft Active Directory.’ He managed to intimidate the CISO so I quietly told him: ‘Let him try. We´ll go have a coffee and I promise you that he´ll be here within two hours and ask for a user account’.

So we went down to the cafeteria and started to discuss Tier 1 security. After 1 h and 53 minutes the pentester came down and, with a lot less confidence in his voice, told us that he is now ready to use a user account to move forward because we passed the first tests. He left and I became a bit cocky and told the CISO that he´ll be here within an hour asking for a domain admin account. I was wrong with 15 minutes. It actually only took him 45 minutes to give up.

‘Apparently you have done a decent job in security against standard user access but getting to be a domain admin is easy so I´ll go for the hashes now. But I would also ask for the domain admin account to test the rough admin scenario.’ I knew that he hadn´t found any domain admin hashes because I had reports from Azure ATP the whole time.

If you give them a domain admin account, your are bound to lose but I told the CISO to have faith in me. He´ll be here just before lunch. We continued discussing Tier 1 and Azure and the pentester came down again, with wild eyes and asked me: ‘How on earth can you give me a domain admin and still be secure?’

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.