In our previous blog, we shortly touched upon security challenges that we can come upon when working with Terraform on AWS. In this blog we want to dig a little deeper into IAM by explaining 10 pitfalls you should look out for when you configure AWS IAM. Let’s start our journey and tackle them one by one.

So, you want to build your infrastructure in AWS and use Terraform for your Infrastructure as Code? And you want to do it securely? In this blog we highlight three things you should pay attention to from a security perspective: your IAM roles and trust relationships, your Terraform state, and your detection & monitoring. Of course, each of these topics deserve their own in-depth blog, but we’ll start highlighting three key touchpoints.

I am done with the whole shift left storyline.

In a previous blog we talked about secure deployment. Secrets management is an important part of that. So what does that mean? In this blog we’ll give some pointers on how to do secrets management well in the perspective of a secure deployment. It’s easy to start saying “use tool X to store the secret” or “have all these detection tools in place!”, but that would lead to blind spots. Instead, let’s take a look at some pointers that would help you increase secret security holistically.

We all know that the hardening of a system or implementing 2FA does not magically improves the security of an organisation. For a successful implementation of IAM, PKI a holistic approach is needed. Also for the successful improvement of security in your organisation, a holistic approach is needed. Implementing and improving security demands your approach to cover both people, process and technology.

This blog provides you with a mental model on how to change behavior of people and how to change the culture of an organisation. To change the culture of your organisation you need to change the structures and lead by example. And there is more to it, why this works in changing the behavior of individual persons. 

I also highlight material to facilitate a workshop that helps you in making the mental models behind the behavior of people explicit.

Most threat model approaches (like e.g. STRIDE) assume you have a technical overview like a Data Flow Diagram. An interesting question therefore is; can you threat model when there is no such thing available? A common situation would be when your are forming an epic, but as an exercise let’s take a legal contract or service level agreement; can you threat model that? Let us find out….

At first sight this might be a stretch or weird thing to do as there are no assets to protect or technical risks to identify, but I will show you can still get interesting results by tweaking the process and making a translation first.

Our experience with resources on secure deployment

Have you ever searched for resources on “Secure Software Deployment”? Most of the results revolve around the pentesting or putting security tools in your CI/CD pipeline. It would be the same as researching how to improve your cake baking skills, but end up with manuals of kitchen appliances. We want to address this gap: in this blog, we want to give you key pointers for a secure deployment.

So, what should you think of? We’ll start with a few aspects that we believe are important to think of when you work on a secure deployment. After that, we will touch upon the areas that you need to work on to actually achieve it. Finally, we’ll advise where to go from here.

Agile teams often use the concept of personas to create more tailored user stories, so could you use evil personas to describe malicious behavior?

Personas are “synthetic biographies of fictitious users of the future product” and “a powerful technique to describe the users and customers of a product in order to make the right product decisions“. The purpose of using personas is to “understand who the beneficiaries of the product are and what the goals they pursue”.

In essence, personas help teams understand if the designed functionality actually fits the end-user desires. This makes it a powerful approach to also identify possible risks by introducing malicious users or ‘evil personas’.

Security is about making risks visible and mitigating the impact of possible incidents to an acceptable level. The ‘security by design’ philosophy aims for every application or system to be at an acceptable risk level, all the time.

When starting with a ‘secure by design’ approach, often existing security processes are simply bolted onto the development life-cycle. One of the major pitfalls of this approach is requiring teams to do a YAPWAV. YAPWAV stand for the developer’s hell called: Yet Another Process Without Added Value. A YAPWAV is an activity a team solely has to do to please a stakeholder, without noticeably improving the product they’re building.

A classic example of a YAPWAV is the mandatory risk assessment for each software deployment, just for the purpose of satisfying a documentation process. These kinds of security processes are bound to fail as they add no (visible) value to the product the team is building. In the agile philosophy, every action or activity should contribute to the value of the product. The moment an activity is introduced that doesn’t add visible value, teams will decide it’s not worth the effort and stop doing it.

Read more →

Likely, a lot of the code you run is not code you wrote. But what does that mean in terms of security? In this post, we will discuss how long it takes to detect a malicious package, what happens if you include one of these packages, and what you can do about it.