Academy_Positive
Ë
By The SafeStack Team • September 28, 2021

Secure development: Top ten security training topics for your team

At SafeStack Academy we believe weaving cyber security throughout the entire software development life cycle is essential.

When we teach secure development, our goal is to help development teams build a set of vital skills that supports them to collaborate on security early and often, making it a shared responsibility that everyone has a solid understanding of.



Security is essentially a process of removing or reducing the risk posed by danger or threat. As security is built around fundamental topics, understanding them and the language used to communicate them can help you move from technical knowledge to practical management.

While the technology and approaches we use to build our applications changes frequently, security is a constant requirement, and it’s relevant to everyone working in software development team.

If you’re brand new to secure development, it can be hard to know where to start.

To help point you in the right direction, we’ve rounded up our top 10 security topics to include in your development team’s training programme.

SafeStack Academy mascots looking at laptop screen and talking about secure development

#1: Understanding vulnerability and impact, and calculating risk

Covered in Security Fundamentals for Software Development

Application security is all about understanding the vulnerabilities, measuring the impacts, and calculating the risks that our systems face. Once we’ve done that, we can work out how to best protect our people, data and systems.

Being vulnerable means being open to the possibility of being attacked or harmed, either emotionally, physically, or electronically. Understanding the impact of vulnerabilities helps us evaluate what could happen if a vulnerability is exploited, and how that might affect our organisations.

Then, there’s risk — the possibility that something bad will happen.

When we talk about risk in the context of information security, we’re thinking about how incidents can impact the confidentiality, integrity, and availability of our systems and data within our organisation.

We calculate risk by multiplying three factors:

  • Vulnerability
  • Likelihood
  • Impact

From there, we look at how critical this risk is, and what actions we need to take to minimise the risk.

We'll always be faced with risks, and the goal isn't getting them down to zero. Instead, we're aiming to get to a level where we've mitigated the risks that concern us the most, and we're aware of the ones we're accepting and living with.

#2: Understanding threat actor motivations and the value of a system

Covered in Security Fundamentals for Software Development

If we want to protect our people, our data, and our systems, finding vulnerabilities is only half the battle. Our data and systems are valuable, and we need to consider the other people outside our organisations who might want access to them.

We also need to understand who the potential threat actors are and how they might exploit these vulnerabilities. The more we learn about the threats to our system and the motivation behind them, the more effectively we can prioritise our defences.

Understanding threat actor motivations

Threat actors are groups or individuals who pose a risk to a system, organisation, or individual. In our Security Fundamentals for Software Development course, we cover five common groups of threat actors to be aware of.

Once we know how to identify these groups, we can start understanding their motivations and resources, and the skills they may have that could make an attack more successful.

Different threat actor groups execute different types of attacks, and it’s important for development teams to have an understanding of these.

The value of a system

All organisations have value and something to protect, whether that’s money, data, or resources.

The data we keep in our organisations can include commercial information, intellectual property, and sensitive information. All of these are attractive to different types of groups and individuals for various purposes.

Resources in an organisation can include physical equipment, computing, facilities, and people — again, all of which may be valuable to a threat actor.

It’s important to remember our organisations are part of an interconnected ecosystem. Even companies with little value or interest for attackers may be targeted because of the relationships they have to other organisations. Smaller companies buying software from big companies may be “softer” targets. On the other hand, larger organisations may use small companies as part of their supply chain, so by disrupting big players, attackers can impact many small organisations all at once.

For all these reasons, we always encourage development teams to include understanding the value of a system as part of their secure development training.

SafeStack Academy Secure Development Free Trial CTA

#3: Being a security champion

Covered in Security Fundamentals for Software Development

Firstly, what’s a security champion? We use this term to describe someone who advocates for application security in development teams.

Security champions are important because as we scale up our security practices, we need to find ways of involving the entire development team in making sure we have all our security principles covered.

When our organisation is small, we might not have a dedicated security person or security team. As we grow, we might be in the fortunate position of having a security person who can provide dedicated support to our development team. But as our development teams grow, it’s unlikely we’ll be able to scale up the security support to match — there just aren’t enough security specialists around.

As development teams grow, which they often do, our security people can quickly become overwhelmed. This is where security champions come into their own, acting as a bridge between the security team and the development team. Application security specialists might have a background in other security areas, like network security or governance and risk management. A security champion has experience in software development, so they’re able to apply their security knowledge to their existing development expertise. Bring those two together and you have a powerful combination.

In the Why Security Matters module of our Security Fundamentals for Software Development course, we go through what makes a good security champion and how to become one in your organisation.

#4: Understanding your system using Data Flow Diagrams

Covered in Threat Assessment for Software Development

Before we can prioritise or plan for different security controls, we need to understand what our system is made of and what it does with our data. To do that, we need to take a systems thinking approach.

Systems thinking is a holistic way of looking at things that keeps us from getting caught up in the details. This kind of thinking can be tough, as we often want to get down to the nitty-gritty of how things work.

But for the purposes of threat assessment and systems thinking, we have to go up a level.

As part of our systems thinking, we need to model our systems so we can understand how they fit together, and this starts with Data Flow Diagrams (DFDs). A DFD is a map of how data flows through a system and where it’s processed, stored, and shared between systems. You can then use your DFD for threat modelling — another essential security topic for your development team (skip ahead to number 6 if you just can’t wait).

#5: Creating security personas

Covered in Threat Assessment for Software Development

Personas have been used in development for quite some time to help drive our user experience and product validation efforts. Security personas are very similar.

Security personas identify the motivations, expectations, and goals of users that drive bad behaviour, and bring these negative characters to life. They also make abstract issues concrete, which helps us to better understand those issues.

We recommend looking at the three elements that make up security personas: motivation, access, and skills.

In the Introduction to Security Personas module of our Threat Assessment for Software Development course, we go into more detail about how to create these personas and share examples of how you might use them.

Building on your personas over time — as your organisation, audience, and environment changes — is a great practice.

Security personas are a great tool for communication. They help us think in human terms, bridge technical and non-technical aspects of the system, and address risks that span across processes and into the technical platform itself.

#6: Applying threat modelling frameworks

Covered in Threat Assessment for Software Development

Threat modelling or assessment is a repeatable and structured approach to identifying threats to a designed or existing software architecture. Applying a threat model consistently as a collaborative tool allows teams to discover threats and then work towards their mitigation.

In our Threat Assessment for Software Development course, we go through Microsoft STRIDE, which is one of many frameworks for threat modelling. We use STRIDE (which stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Escalation of Privilege) because it’s an open-source threat assessment framework and it’s well-documented as part of Microsoft Secure Development approaches.

Threat assessment methodologies like STRIDE can be powerful, reusable collaboration tools for development teams.

In the Applying a Threat Model section of our Threat Assessment course, we break down STRIDE in much more detail (a module for each letter of the acronym, even) and step through how to apply it.

#7: Using attack trees

Covered in Threat Assessment for Software Development

We’ve all had those days where everything’s going wrong and you don’t know what you should fix first. Attack plans and trees are incredibly useful in this kind of situation.

Attack plans are made up of important questions that help you get to the heart of an attack — questions like “Who and why?”, “What would they do?”, and “How?”

Once you have these plans, you can use them to build attack trees.

Threat assessments let us identify possible attacks, while attack trees allow us to gather these attacks, group them by overall target or motivation, and prioritise our response.

Using threat assessment and attack trees together lets us constructively manage what can otherwise become an overwhelming mass of problems. No surprise then that it’s earned a place on this list as a worthwhile training topic for any development team.

#8: Applying controls and reducing risks

Covered in Threat Assessment for Software Development

Once your team gets familiar with threat assessments and attack trees, they’ll be ready to move on to applying defensive controls and reducing risk. Neat!

Defensive controls are the controls we put in place to prevent, detect, and respond to the risks we’re faced with. We need to understand how defensive controls relate to software systems, as no single control or mitigation can stop all threats.

It’s important to understand that defending applications and architectures is a balance between what we can control and what we can plan for.

Reviewing controls for each attack plan or threat and applying them, and mixing preventative, detective, and responsive controls gives us the assurance that we’re stopping as many attacks as we can, spotting the ones we don’t stop, and responding quickly.

The Applying Controls and Risks module in our Threat Assessment course looks at what controls we can use in our software systems and how we can balance them to prevent or reduce our risks.

#9: Understanding types of security testing and methodologies

Covered in Security Foundations for Software Testing

Security testing is a type of software testing that allows us to uncover potential vulnerabilities or weaknesses. These weaknesses lead to security risks — which could impact the system, data, or users.

Just like we do software testing to check that the software is working as expected; we do security testing to tell if the software can be misused or exploited to make it do something it shouldn’t — like give you more data or access than you should have, or make the systems unreliable or unavailable.

The types of security testing used and the processes followed can change depending on the nature of the application being tested. To test all aspects of the application, different types of security testing are used across the entire software development life cycle.

Understanding common types of security testing, as well as why we do security testing, who does it, and when it takes place in the software development life cycle, is important for development teams.

Learning about the advantages and disadvantages of certain types of security testing and comparing a few security tests that can seem very similar also helps development teams with the broader software testing process.

Security system methodologies are approaches for testing how secure an application is. The three most common methodologies are static, dynamic, and interactive. We can apply different methodologies in our testing practice, but first, we need to understand how they differ. For more on this, check out the module on types of security testing in our Security Foundations for Software Testing course.

#10: Planning security test cases and actioning the outcomes

Covered in Security Foundations for Software Testing

Every tester has their own style when it comes to test cases. Some of us like structured and documented test cases and some of us prefer to go freestyle, only documenting our findings. Some of us use spreadsheets, and some of us use online tools. There’s no right or wrong approach.

Whatever camp you fall into, it’s important for your development team to be familiar with planning and thinking about test cases.

You might be thinking: “What types of security testing should I plan for?”. There are several types, including vulnerability scanning, risk assessment, security auditing, functional security testing, penetration testing, and red team testing.

In the Planning Test Cases module of our Security Foundations for Software Testing course, we break down functional security testing in more detail, as well as looking more closely at exploratory testing.

Once we finish testing, we need to record and action the results. It’s worth discussing how your team can best record, communicate, and help resolve those security findings. It’s also important to understand what makes security testing different and how to record your findings in a way that makes issues easier to replicate, remediate, and carry out regression testing — all of which we cover in our Security Foundations for Software Testing course.



Take the next step in your secure development journey

Whether your team is new to secure development or you already have security champions in place, weaving cyber security into your software development life cycle doesn’t have to be a complicated process.

SafeStack Academy gives developers, testers, analysts, and architects the skills they need to build high quality, secure software at speed. Wherever your team is in their application security journey, the expert-created content in our Secure Development online training programme will help them take their knowledge to the next level.

Join us by signing your team up for a free 14 day trial today. You’ll get full access to our high quality interactive learning, hands-on labs, and monthly seminars where you can connect with our community.

We love to hear from you

If you enjoyed reading this blog post or if something sparked an interest, please share it with us. Drop us a line at support@safestack.io and let us know what you think.