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.
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.
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.
I’ve previous written about encryption and hashing and why things like customer passwords should never be encrypted. Sometimes, though, you need encryption because you need to get the raw data back. Now you can apply encryption at different layers. Some are easy; some are hard. What you need to be aware of, though, is what they protect against. There is no one-size-fits-all solution A standard app In a common scenario we may have an application that writes data to a database; that database persists data to disk.
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).
One of the major threats that companies are concerned about is “insider threat”. According to some Data Breach Incident Response (DBIR) analyses, insider threat may be the 2nd or 3rd major reason for data loss. It’s interesting to note that the insider threat is way down in the actual number of incidents, but they count for a larger number of successful data loss incidents because the insider knows where the data is, may have legitimate access to the data, and may know the controls that need to be bypassed to exfiltrate it.
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?
