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.

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?

Read more →

There are 2 systems in any company that are critical: the payroll system, and the CI/CD system. Why? You may ask…
If the payroll system doesn’t work, people will leave the company and the company (may) face legal problems; the CI/CD system is the gateway to production. If it is down and there is a bug in production, it will affect your business; loss of revenue, loss of customers, loss of money, just to name a few.

Usually, I find these problems regarding the CI/CD tooling:

• Poor Software Lifecycle Management, with outdated software, containing critical vulnerabilities
• Ancient capabilities in the build agents. In extreme cases, frameworks and tools that are no longer supported by the vendors
• Drifting agents. It means that teams had to do some sorcery to get the software build
• Lack of proper isolation between different builds. It means that a build could access to another build files
• Lead teams to upgrade or install a new framework
• Outdated and strict rules mandated by a operations team. Usually from people that outdated heuristics on how software should be developed

Read more →

During our work as penetration testers, we found that there are lots of vulnerabilities being introduced in applications. Vulnerabilities that could have been prevented in an early stage of development. Sadly these are often the same vulnerabilities over and over again.

Luckily the IT development landscape is changing.

Read more →

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 →

When you work with containers (Docker) you are not only packaging your application but also part of the OS. Therefore it is crucial to know what kind of libraries might be vulnerable in you container. One way to find this information is to use and look at the Docker Hub or Quay.io security scan. The problem whit these scans is that they are only showing you the information but are not part of your CI/CD that actually blocks your container when it contains vulnerabilities.
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 →