Being An Agile Security Officer: Spread Your Knowledge

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 →

Top 5 Ingredients for developing Cloud Native Applications

Introduction

Cloud Native Applications is a trend in IT that promises to develop and deploy applications at scale fast and cost-efficient by leveraging cloud services to get run-time platform capabilities such as performance, scalability and security out of the box. Teams are able to focus on delivering functionality to increase the pace of innovation.  Everything aimed to stay ahead of the competition. Companies such as Netflix and Uber disrupt their markets by leveraging cloud native capabilities to quickly introduce their products at a global scale. Adapt or die.

This article serves as the start of a serie of articles. The goal of this initial article is to explain the why and how of cloud native applications by defining the top 5 ingredients and their rationale. In follow-up articles, I will explain the ingredients in more detail.Read more →

Being an Agile Security Officer: pwn the process

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 →

Being An Agile Security Officer: Security Stakeholdership mindset

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 →

Being An Agile Security Officer

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 →

Kanban should be the default choice for DevOps teams

We had a successful workshop on DevOpsDays 2014. Our main point was that Kanban should be the default choice for DevOps teams. The presentation can be downloaded here.

DevOpsDays 2014 was a success

On the 19th, 20th & 21st of June 2014 the second edition of DevOpsDays Amsterdam was held in Pakhuis De Zwijger in Amsterdam. This year I was asked to teach a course there on Kanban for DevOps. At the 2013 edition I also gave a presentation about this subject and it was nice to be invited back to this great event.

With the Open Source mindset in mind I teamed up with Maarten Hoppen en Bas van Oudenaarde. Our message: Kanban should be the default choice for DevOps teams. 

Read more →

Tutorial - Using Deployit Cloud Pack with Amazon EC2 – Part 1

Deployit's Cloud Pack provides you with the ability to create and destroy environments on virtualized infrastructure from Deployit. It supports both EC2 and vSphere. In this first part of the tutorial, I am going to show you how to setup Amazon AWS and populate the Deployit repository in such a way that you can create and destroy virtual machines  from the Deployit console.
Read more →

Continuous Delivery Essentials : Autonomous Systems

complex_systemAs the complexity of your IT architecture grows, it becomes increasingly difficult to implement a change by changing a single system. The dependencies may even grow so strong, that a single request requires changes in multiple interdependent systems. To make sure that individual changes on different systems will work correctly together, you need to test all new versions of the  systems working together in an integrated acceptance  environment.   After an extensive test period, you need to release all new versions of the systems to production at the same time. The integrated acceptance environment become a bottleneck for the individual teams, as each team wants to  to test there changes in isolation.   It is clear that the complexity of the IT landscape reduces the time to market of changes.

How did this turn out this way and how can this be avoided?

Read more →