I was asked about today’s Crowdstrike issues on Windows. Naturally I have some thoughts… What went wrong? What I know. Crowdstrike is an EDR (Endpoint Detection and Response) tool. (Well, they claim “XDR”, but that’s marketing). It has an agent component and a set of rule sets (called “channel file”). The agent has both user space and kernel space components to better give visibility into what is happening on the machine, and to be able to block bad things.
When it comes to talking about API Security there are many facets and paths the conversation can take. We might want to talk about from an AppDev security perspective; after all, an API is just code, so your SAST/DAST type processes apply. We might want to talk about it in terms of authentication; after all, you need credentials to access an API and there’s many different ways this can be done (Basic Auth, mutual TLS, Oauth, HMAC…); this would also include when anonymous APIs are OK!
I got asked another question. I’m going to paraphrase the question for this blog entry. Given the Russian invasion of Ukraine and the response of other nations (sanctions, asset confiscation, withdrawal of services, isolation of the Russian banking system…) there is a chance of enhanced cyber attacks against Western banking infrastructure in retaliation. How can we be 100% sure our cloud environments are secure from this? Firstly, I want to dispel the “100%” myth.
I got asked a question… this gives me a chance to write an opinion. I have lots of them! If I redirect my port 80 traffic to another site, do I need to get a TLS cert? The question here is related to if a bank (or other service) has changed their name, then do they still need to maintain a TLS site for the old name? Can’t they just have http://mybank.
Working in Cyber Security I’m frequently reminded that the reason we do all the things we do is, ultimately, to protect the data. After all, apps are there to process data, servers (and clouds) are there to run apps and store data. So the whole of cyber security is there to protect the data. It may be Identity and Access Management (restrict access to data to those people who should have access to it).
As I was rebuilding my network I came across a problem. In my basement I had previous run a cable from my core switch around the room to the other side, where I had a small 100baseT switch to handle the equipment on that table. I’d also run another cable across the ceiling to the back of the house, where I had the Powerline network. Everything seemed to be working fine, and it had been doing so for years.
I was asked a question around the Capital One breach. It seems that, in some areas, fingers are being pointed at Amazon, and they should be held (at least partly) to blame for this. It also seems as if Senator Wyden is also asking Amazon questions around this. There’s also a question around Paige Thompson, the hacker, and her previous relationship as an Amazon employee. If she used any insider knowledge to break into Capital One then this would erode a lot of trust in Amazon’s Web Services, and the public cloud in general.
Every day we hear of yet another data breach. One common reason is because of password compromise. The problem may be because of successfully phishing; it may be due to password re-use; it may be due to brute force attacks; it may just be weak passwords. So it is now considered best practice to use some form of Multi Factor Authentication. To quickly summarise, MFA is 2-or-more of the following factors:
I’ve spent the past far-too-many years working in the finance industry, in mega-banks and card processors. These companies are traditionally very worried about information security. It’s not to say they always do it well (everyone makes a mistake), but it leads to a conservative attitude. These types of companies end up creating a massive set of standards and procedures to protect themselves. “Thou MUST do this. Thou MUST do that.
Whenever a new “critical” vulnerability is found, the cry goes out across the land; Patch! Patch! Patch! Whenever a major incident is caused by known vulnerabilities the question is always Why didn’t they patch? We’ve known about this for months! They should have patched! Sometimes this is valid criticism, and learning why the organisation wasn’t patched can lead to some insights into failure modes.
Unless you’ve been living under a rock, you may have heard of two panic panic panic bugs, known as Meltdown and Spectre. People are panicking about them because they are CPU level issues that may impact almost every modern CPU around. Meltdown is Intel specific, but Spectre affects Intel, AMD, and potentially others (Redhat claims POWER and zSeries is impacted). What is the problem? In short, modern CPUs may execute instructions out of order, especially when the order doesn’t matter.
“To summarise the summary of the summary; people are a problem” - Douglas Adams, The Restaurant At The End Of The Universe The above quote is one of my favourite jokes (I’ve used it in a previous post); it highlights how people can complicate any situation. We can try to avoid this by automating as much as possible but, at the end of the day, there’s always a human involved somewhere; even if it’s the team that manages the automation!
A couple of weeks ago I was asked a question around the disposal of SSDs. The question went along the lines of “In the old days we could just overwrite the disk many times (eg with DBAN). What should we do, now, with SSDs?” Recently, a bunch of Infineon TPMs were found to have a flaw that generated weak RSA keys. This could have lots of impact, including Bitlocker disk encryption.
Unless you’ve been living in a cave for the past couple of months, you’ll have heard that Equifax, one of the ‘big three’ credit reporting agencies, suffered a massive breach leaking privileged data on over 143 million US people (and millions outside the US as well). The story went from bad to worse as the company completely failed to handle the response properly, with poor communication, staff giving out the URL to phishing sites, web site failures and the story that three executives sold millions of dollars of shares before the leak notification was made.
“Those who cannot remember the past are condemned to repeat it.” – George Santayana Default broken I was reminded, last week, of how old issues repeat. Back in the 90s it was a truism that if you put an “Out Of The Box” RedHat 4 (not RedHat Enterprise; the original freeware version) server on the internet then it would be compromised within hours. And so we learned; our default builds didn’t have telnet, didn’t have every possible service installed, didn’t have vulnerable configurations.
If you’ve ever built any enterprise level system you’ll be aware of the needs of performance and resiliency. You may do performance testing on your application; you may have a backup server in a second data center; you may even do regular “Disaster Recovery tests”. And yet, despite all these efforts, your application fails in unexpected ways or isn’t as resilient as you planned. Your primary server dies, the DR server doesn’t work properly.
One of the golden rules of IT security is that you need to maintain an accurate inventory of your assets. After all, if you don’t know what you have then how you can secure it? This may cover a list of physical devices (servers, routers, firewalls), virtual machines, software… An “asset” is an extremely flexible term and you need to look at it from various viewpoints to ensure you have good knowledge of your environment.
Over on Twitter, @TinkerSec live tweeted a pentest and created a moment thread of it. It’s fascinating reading, and well worth reading. Even non-technical people should be able to get something out of this. I like that it’s a form of insider attack (industrial espionage by a newly hired employee? disgruntled employee? vendor allowed unaccompanied access?) rather than an external attack. One of the things that typically comes out of an event like this is a series of action items.
Part of any good backup strategy is to ensure a copy of your backup is stored in a secondary location, so that if there is a major outage (datacenter failure, office burns down, whatever) there is a copy of your data stored elsewhere. After all, what use is a backup if it gets destroyed at the same time as the original? A large enterprise may do cross-datacenter backups, or stream them to a “bunker”; smaller business may physically transfer media to a storage location (in my first job mumble years ago, the finance director would take the weekly full-backup tapes to her house so we had at most 1 week of data loss).
A typical cloud engagement has a dual responsibility model. There’s stuff that can be considered “below the line” and is the responsibility of the cloud service provider (CSP) and there’s stuff above the line, which is the responsibility of the customer. Amazon have a good example for their IaaS: Where the line lives will depend on the type of engagement; the higher up the abstraction tree (IaaS->PaaS->SaaS) the more the CSP has responsibility.
The Siphonaptera has various versions. The version I learned as a kid goes: Big bugs have little bugs, Upon their backs to bite 'em, And little bugs have lesser bugs, and so, ad infinitum. We make use of this fact a lot in computer security; a breach of the OS can impact the security of the application. We could even build a simple dependency list: The security of the application depends on The security of the operating system depends on The security of the hypervisor depends on The security of the virtualisation environment depends on The security of the automation tool.
Recently we heard news that the police had requested Alexa recordings to assist with a murder enquiry. The victim had an Amazon Echo and the police feel there’s useful data to be obtained. This leads to speculation about what sort of information is recorded by these devices, and how secure are they? What type of devices are we talking about? There are a number of devices out there these days which you can talk to, to request things.
Have you tested your backups recently? I’m sure you’ve heard that phrase before. And then thought “Hmm, yeah, I should do that”. If you remember, you’ll stick a tape in the drive and fire up your software, and restore a dozen files to a temporary location. Success! You’ve proven your backups can be recovered. Or have you? What would you do if your server was destroyed? Do you require specialist software to recover that backup?
In my previous post I wrote about some automation of static and dynamic scanning as part of the software delivery pipeline. However nothing stays the same; we find new vulnerabilities or configurations are broken or stuff previously considered secure is now weak (64bit ciphers can be broken, for example). So as well as doing your scans during the development cycle we also need to do repeated scans of deployed infrastructure; espcially if it’s externally facing (but internal facing services may still be at risk from the tens of thousands of desktops in your organisation).
In many organisations an automated scan of an application is done before it’s allowed to “go live”, especially if the app is external facing. There are typically two types of scan: Static Scan Dynamic Scan Static scan A static scan is commonly a source code scan. It will analyse code for many common failure modes. If you’re writing C code then it’ll flag on common buffer overflow patterns.
A fair number of security advisories mention Man In The Middle (MITM) attacks. It’s quite an evocative phrase, but it’s a phrase meant mainly for the infosec community; it doesn’t help your typical end user understand the risks. So what is a MITM attack, and how can I avoid becoming a victim? Before we get into technology let’s look at something we all know about; the boring snail mail postal system.
The core problem with a public cloud is “untrusted infrastructure”. We could get a VM from Amazon; that’s easy. What now? The hypervisor isn’t trusted (non company staff access it and could use this to bypass OS controls). The storage isn’t trusted (non company staff could access it). The network isn’t trusted (non company…). So could we store Personal Identifying Information in the cloud? Could a bank store your account data in a public cloud?
“To summarise the summary of the summary; people are a problem” - Douglas Adams, The Restaurant At The End Of The Universe In a traditional compute environment we may have a lot of controls. There may be a lot of audit regulations. Organisations create a lot of processes and procedures. Want to login to a Unix machine? Better have an approved account, with the right authorisations. DMZ machines may require 2FA.
From Twitter came this gem: This is a cute way of helping people understand the difference between the three concepts. It also helps start to drive conversation around remediation activities and risk assessment. (Let’s not get too tied down with interpretation; all analogies have holes :-)) What if the door was a bedroom door, rather than a house front door? How does this change the probability of a bear getting in and thus getting mauled?
