Peter Drucker said “What gets measured, gets managed”. When I turned up at Old Trafford, home of Manchester’s red team (it’s a security conference, geddit) for The Future of Cyber, I certainly was measurably impressed by the setting even though I’m usually found more on the blue spectrum of infosec. But let’s get into the talks! Measure, measure, measure First, Greg Notch talked about the importance of using metrics in communication.

About two months ago I stumbled across a great YouTube video of a talk by Charity Majors called Compliance standards should be modern development practices. Now let’s step back for a minute. Am I seriously suggesting that anything with the word “compliance” is going to be a riveting watch? Why, yes I am. And with good reason. I’m a fan of good security and I like agile. And I think one of the major stumbling blocks about putting Sec into DevOps is to forget the agile origins of DevOps culture.

I describe myself as an Agile Fundamentalist because I really like the ideas of the Agile manifesto, and I also confidently state that I am an AppSec snooper, because in my day job I tend to look at other people’s code, logs and systems and break them. I happen to think that agile and application security go together rather well! I had two different Slack conversations recently. One was on the UK cross-governmental #security Slack channel and the other one was on the Equal Experts #securit-ee Slack channel (yes I’m a consultant, and our Slack channels have hilariously got ee in their names).

After BSides Lancs and Leeds, Newcastle was my third BSides, both of the year and ever. I got up early in the morning for a road trip from Preston to Newcastle, and setting off at 5:30 on Saturday turned out to be atmospheric and straightforward. So I was a bit early and got a glimpse of the chaos that is putting together a BSides. Later I found out that BSides Newcastle was traditionally more chaotic than some of the other BSides.

The question of automatic dependency updates came up in our Slack channel the other day. There was a lot of nodding on how it is a good thing. Tools like Dependabot and Renovate were mentioned. Yet I was a dissenting voice. Why? The case for automatic dependency updates is simple and seductive: A bot would automatically scan your dependencies in your source code and create pull requests to update your libraries to the latest versions, sometimes even automatically merging it in.

From a security point of view, application logs are two-sided. On the one hand, it is really important to have good observability, to find out what is happening and what has happened. On the other hand, we don’t want to leak sensitive information. In this post I am going to look at the kinds of things you might find in your logs. The juicy bits are Personal Identifying Information (PII) or security credentials.

Let me tell you a story about Application Security (AppSec). It contains heroes and villains, and I’m not necessarily thinking about the defenders and attackers here. It contains lots of interesting technology that is often overemphasised. We’ve got whole industries that work on letting us know how scary it is out there, vulnerabilities that are marketed like rock stars and terminology that makes you quiver in your boots: who would want to fall victim to an Advanced Persistent Threat (APT)?

There’s a metaphor about the fight between attackers and defenders in the Denial of Service cybersecurity game. It’s an “arms race” between ever bigger attacks throwing huge amounts of traffic at ever more sophisticated defenses (e.g. AWS shield). Incidentally, I’ve just demonstrated an easy mistake: I’m not describing a Denial of Service (DoS) attack, it’s a Distributed Denial of Service (DDoS) attack. The aim is to overwhelm the infrastructure, either the networking infrastructure or the application by sending more requests than can be handled.

In this post, I am going to look at an increasingly important part of securing applications: Your supply chain. This includes every library, tool or service that you are using to build, run and monitor your service. When the log4shell vulnerability hit, it wasn’t just a matter of looking at the dependencies that your source code pulls in, but also at the infrastructure you’re using and the build pipeline. Have you had a look at the vulnerability reports of your dependencies lately?