Many models and perspectives describe the complexity of an organization. In the end, it all boils down to people interacting with technology using processes. Sociologist Dr. Ron Westrum provided a typology of organizational cultures, including a generative type. Key characteristics for a generative culture include:

• Oriented to performance
• High cooperation
• Failure leads to inquiry
• Share risks

Encouraging these characteristics in the culture of an organization allows capacity, quality and innovation to grow. A CI/CD pipeline aids in facilitating the tools and processes to make these characteristics possible. A CI/CD pipeline is often perceived as a way to bundle and distribute software. It is the modern way to deploy software using automation instead of doing it manually. From a technical perspective, this is valid. Yet, the key concept of a CI/CD pipeline is to provide consistent quality and early feedback. By continuously monitoring the existing (quality) performance, you gain insights & data on how to improve deployments and the controls being applied.

Using the triad of people, process and technology, let us see what a CI/CD pipeline means for an organization and how it impacts the quality of the software delivery process.

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.

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 →

In information security we have a saying: ‘never waste a good crisis’. As grim as this may sound, there are valuable lessons to be learned from situations like the recent corona outbreak. As seen in the news a lot of companies close down their offices to limit the transmission of the virus. However, this can impact your efficiency or introduce new risks. What can you do to assess this?

This is my fifth and last part of my blog series about Being an Agile Officer

In the previous parts I showed how Security Officers can align with the Agile process and let security become a standard considered quality attribute again. Unfortunately many teams not only need to be made aware of security requirements, but also need technical advise and guidance in designing and implementing them. As an Agile Security Officer you therefor need not only to act as a Stakeholder, but also as a Domain Expert for Security.

Read more →

This is the fourth part of my ‘Being an Agile Security Officer series’. In this blog post I will go deeper into the details of how user stories are created and what role security stakeholders should play in that.

Read more →

This is the third part of my ‘Being an Agile Security Officer series’. As mentioned in my previous blog, in the Agile world the Product Owner is the person who translates business and customer desires into work items for the teams. To do this, product owners have several techniques and means at their disposal. In this blog I will focus on the backlog and the definition of done. As a security officer it’s important to understand their purpose and to learn how they can help you achieve your goals.

Read more →

This is the second part in my blog series about ‘being an agile security officer’. In this blog I will focus on the mindset of security stakeholdership in Agile and DevOps environments.

In the Agile world the Product Owner is the person who translates business and customer desires into work items (user stories) for the teams. The actual desires and requirements however are provided by stakeholders. Stakeholders are usually representatives of the business and end-users; in the new world security officers should start taking up the role of security stakeholders. The Product Owner usually has multiple stakeholders to take into consideration. As a security stakeholder you have to ‘compete’ with other stakeholders for the most valuable changes. It has become, more than ever, important to be able to translate your requirements into actual value.

Read more →

Whenever I give a presentation, training, or just talk to security teams, it becomes clear that over the years a gap has been created between application security and development. A gap we created consciously and with intent and that became painfully visible with the introduction of Agile and DevOps. Suddenly exhaustive information security policies with checklists and penetration tests became serious impediments. The challenge we are facing now is how to bridge this gap again.

Fortunately this challenge is easier to solve as it appears to be. The key to success is to split the security officer function more Agile minded roles with different responsibilities and duties. In the coming blogs I will dive deeper into the different aspects of these roles and the differences in the responsibilities and duties. But first we need to take a little trip down to memory lane to understand how we ended up in this situation.

Read more →