Posts

Delivering secure software in an agile way

/in

 

Agile Software Development: Why It’s Better

Traditional development methodologies, such as the Waterfall model, struggle to keep up with the need for quick iterations, frequent releases, and adaptability to changing requirements.

Agile software development addresses these challenges by emphasizing flexibility, collaboration, and continuous delivery. Agile methodologies break down the development process into smaller, manageable chunks, allowing teams to rapidly deliver working software while remaining responsive to feedback and changes.

Among the various Agile frameworks, Scrum stands out as one of the most widely adopted and effective methods for managing software development. It provides a simple, yet powerful framework, that helps teams continuously deliver high-quality products, adapt to dynamic customer needs.

Using Scrum for software development

Scrum is a lightweight agile framework designed to manage complex product development through iterative and incremental processes. It focuses on delivering working software in short cycles known as Sprints and emphasizes collaboration, accountability, and continuous improvement. This structure makes Scrum particularly well-suited for dynamic environments like software development, where requirements often change throughout the project lifecycle.

Scrum offers several key advantages that make it ideal for software development:

  1. Rapid Iteration and Feedback: Scrum’s short sprints allow teams to deliver working software frequently, which gives stakeholders the chance to review progress, provide feedback, and make necessary adjustments after each sprint.
  2. Adaptability to Change: In Scrum, the Product Backlog is continuously updated and reprioritized, enabling teams to adapt to changing business needs or customer demands without disrupting the overall workflow.
  3. Focus on Delivering Value: Scrum emphasizes delivering the highest business value early by prioritizing the most critical features. This ensures that the product development effort aligns with the business objectives.
  4. Cross-Functional Teams and Collaboration: Scrum fosters collaboration between cross-functional teams, which enables them to tackle complex problems and deliver complete product increments without relying on external resources.
  5. Simplicity and Structure: Scrum’s structured roles, artifacts, and ceremonies create a clear framework for managing work, making it easier for teams to stay organized, focused, and accountable.

With these features, Scrum empowers software development teams to build high-quality products faster and with greater alignment to customer needs. The framework’s flexibility and focus on delivering continuous value make it the ideal choice for modern software development.

Non-Functional features in Scrum

Non-functional features, or non-functional requirements (NFRs), refer to critical system attributes like security, usability, and resource consumption that ensure the software performs optimally and meets quality standards. Unlike functional features, which are visible to users, non-functional features define how the system behaves under specific conditions and are essential to the system’s overall success.

Examples of Non-Functional Features

  1. Security: Protecting the system from unauthorized access and vulnerabilities.
  2. Usability: Ensuring that the system is user-friendly and easy to navigate.
  3. Resource Consumption: Optimizing the system’s use of resources, such as memory, CPU, and bandwidth, to ensure efficient operation.

Though non-functional features are not always visible to users, they are crucial to the long-term stability and security of the product. Managing these features properly within the Scrum process is essential to ensure the product meets both user and business expectations.

Incorporating Non-Functional Features in the Scrum Backlog

Non-functional features can be added to the Product Backlog similarly to functional ones, ensuring that they are prioritized, addressed, and tested throughout the development cycle.

Here’s how:

  1. Create explicit user stories for non-functional features

Define clear user stories for non-functional aspects like security or performance. For instance:

    • “As a user, I want my personal data to be encrypted, ensuring my privacy and security.”
    • “As a system administrator, I want the application to scale seamlessly for up to 10,000 concurrent users.”
      For security in particular, these user stories are usually called “security user stories”.
  2. Prioritize based on business impact
    Work with stakeholders and the Product Owner to prioritize non-functional features that have the greatest impact on the system’s overall performance and security.
  3. Define Acceptance Criteria
    Ensure that non-functional user stories include measurable acceptance criteria, such as performance benchmarks or security requirements, so they can be properly tested.
  4. Integrate NFRs into the Definition of Done
    Non-functional features should be part of the team’s Definition of Done (DoD), ensuring that each sprint delivers not only functional but also secure, performant, and stable increments.
  5. Define a certain ratio between functional and non-functional requirements in the backlog
    Ensure that the non-functional user stories like security user stories have always a reserved space in the backlog. For example, you can have 60% functional u.s., 20% non-functional u.s., 20% bug fixes u.s.

Security in Software Development

Security is one of the most critical non-functional features in software development. It involves protecting systems, data, and users from potential cyber threats and vulnerabilities.

As software becomes more complex, the attack surface increases, making robust security measures essential.

Failing to integrate security into the development process can lead to severe consequences such as data breaches, loss of customer trust, and regulatory penalties.

The challenge of adding security user stories to the backlog

One of the main challenges of integrating security into the Scrum backlog is that security requirements are often non-functional and may not be directly tied to a specific feature.

Security is also a broad area, encompassing various elements (authentication, encryption, vulnerability management), which can make it difficult for the Product Owner to prioritize and create detailed security user stories.

Another challenge is balancing security tasks with feature development. Development teams (especially the product owner) may be tempted to focus on customer-facing features, leaving security tasks to the end, which increases the risk of vulnerabilities slipping through.

 

How to add security to the Scrum backlog

1. Create security user stories

Translate security requirements into actionable user stories that fit into the Scrum process. These stories should describe the security needs from a user’s perspective. Examples include:

  • “As a user, I want my password to be hashed and stored securely, ensuring the safety of my account.”
  • “As a system administrator, I want the application to implement multi-factor authentication for increased security.”

By creating security user stories, the development team can directly address specific security needs in each sprint.

2. Prioritize security based on risk

Work with security experts and stakeholders to prioritize security tasks based on the potential risk they mitigate. Security stories that address high-risk areas, such as vulnerabilities in authentication or data handling, should be prioritized over less critical tasks.

3. Define clear acceptance criteria for security stories

Ensure that each security user story has measurable acceptance criteria. These criteria should be specific and testable, such as:

  • “Passwords must be hashed using a minimum of SHA-256 encryption.”
  • “The system must reject any user input that contains SQL injection attempts.”

Clear acceptance criteria help the development team understand what is required to achieve “done” for a security story.

4. Integrate security into the Definition of Done

Security tasks should be part of the Definition of Done for every sprint. This ensures that security checks, such as code reviews and penetration testing, are performed before a feature is considered complete. By making security a core part of the development process, teams can prevent security from being treated as an afterthought.

5. Conduct Security Spikes

If security requirements are complex, consider using spikes to explore potential solutions or gather more information. For example, a spike could involve researching encryption libraries or conducting a security audit to identify vulnerabilities. Spikes help teams plan and implement security features more effectively in future sprints.

6. Regularly Review and Update Security Stories

As security threats evolve, new vulnerabilities may emerge that need to be addressed. Regularly review and update the backlog to ensure that the most current security threats are covered. This could involve adding new security stories or reprioritizing existing ones based on changing risk assessments.

7. Define a fixed ratio for security user stories

As mentioned above for non-functional requirements, it is usually a very good practice to have fixed percentages of non-functional user stories. Since security user stories are non-functional user stories, you can enforce this way that security topics don’t get forgotten.

 

Conclusions

Agile development provides the flexibility and adaptability needed to keep up with today’s dynamic software environments, and Scrum stands out as probably the best framework for delivering software quickly while ensuring continuous feedback and improvement.

By incorporating both functional and non-functional features into the Scrum backlog, teams can ensure that they are delivering a product that is not only feature-rich but also secure, performant, and user-friendly.

Security, in particular, is an essential non-functional requirement that must be treated as a priority throughout the development lifecycle. By integrating security user stories into the backlog, prioritizing based on risk, and ensuring security is part of the Definition of Done, software development teams can create resilient, secure systems without sacrificing agility or speed.

The post Delivering secure software in an agile way first appeared on Sorin Mustaca on Cybersecurity.

The Automotive industry’s inadequate approach towards software (in the cars)

/in

Introduction

The automotive industry has witnessed a paradigm shift with the increasing integration of software in vehicles.

Modern cars are no longer just mechanical devices with a motor, wheels and steering; they are now sophisticated machines having dozens of CPUs (called ECU), entire computers, high speed network to connect them (called CAN-bus) and relying on complex highly distributed software systems.

In my opinion, the industry fails to adapt to this new reality and fully embrace the concept of cars as hardware running software has significant consequences.

This may sound contradictory at first, on one side they have these complex systems, on the other side they fail to adapt to this reality.

In this article, I will explore how the automotive industry is not dealing correctly with this transformation and its potential implications.

 

Limited Focus on Software Development and Updates

Traditionally, the automotive industry has primarily focused on hardware design and manufacturing, treating software as a necessary mean to make the hardware work.

This approach results in a lack of emphasis on software development practices and updates capabilities.

While cars are becoming more connected and dependent on software for various functionalities, manufacturers often overlook the importance of continuous software improvements and security updates.

How often do you update the software of your car? Maybe once a year in the best case, usually once every several years or not at all.

It’s not all bad, but think of how many times does Open SSL get updated in a year. Theoretically you should see an update every few months.

 

Insufficient Over-the-Air (OTA) Update Capabilities

Related to updates, Over-the-Air (OTA) updates have gained prominence in the software industry as an efficient means of delivering software fixes, updates, and new features directly to users.

However, the automotive industry has been slow to adopt OTA capabilities on a widespread scale out of their own will.

Limited OTA functionality not only hampers the ability to address software vulnerabilities promptly but also restricts the potential for delivering new features and enhancements to vehicles post-purchase.

Fortunately, there are many initiatives to solve this and even legislation (UNECE R 155 and R 156) that started to make software updates mandatory for releasing new car types.

 

Slow Adoption of Agile SW Development Processes

Agile software development methodologies have become the norm in the software industry due to their flexibility and iterative nature.

However, the automotive industry lags behind in adopting these practices. And this is politically correct formulated.

The OEMs are still working with the V-Model, despite the fact that you hear them talking about sprints, iterations, Scrum, XP programming. All these are actually implemented with small V runs and have little to nothing to do with agility.

The slow pace of development and release cycles in the automotive sector hinders the quick implementation of software fixes and feature enhancements.

This delay not only frustrates customers but also puts their safety at risk by keeping potentially critical issues unresolved for extended periods.

Lack of Consumer Education and Awareness

The general public’s understanding of cars as hardware running software is limited. First when TESLA became an important OEM, the entire world  started to understand how important software is in a car.

Immediately after has the automotive industry started to feel threatened by it and they started to invest more in software, more particularly, in improving the user experience of their cars.

If I make a comparison with the mobile phones in the early 2000, the TESLA is the iPhone while the other OEMs were Nokia and the others. We all know what happened to Nokia because they did not move faster.

Consumers must continue to push the OEMs to enhance the software of their cars, but this is a slow process, because the cars with good software are expensive, and people with money usually don’t look first at the software capabilities of their cars.

 

Inadequate Cybersecurity Measures

As cars become increasingly connected and autonomous, they become vulnerable to cyber threats.

Unfortunately, the automotive industry has been sluggish in implementing robust cybersecurity measures to protect vehicles from potential attacks.

Insufficient attention to software security leaves vehicles open to hacking, which can lead to unauthorized access, data breaches, or even physical harm.

The industry must prioritize cybersecurity and invest in proactive measures to safeguard vehicles and their occupants.

Because cybersecurity is hard to implement, very expensive and requires specialized personnel, no OEM was willing improving their cybersecurity.

This is the reason why the UNECE R155 requires now a Cybersecurity Management System (CSMS) audit in order to allow new vehicle types.

 

If you are an OEM or subcontractor (Tier 1-N) then you may want to know that Endpoint Cybersecurity is offering consulting on how to implement such a CSMS and make it auditable.

Lack of standards

Same as for computers, the IT industry started to exponentially increase only after there were good reasons to use computers. Only after the Internet became main stream have businesses, regular people and families started to buy computers.  So communication or inter-communication was and still is a main factor to buy hardware.

The same is happening with cars: people start to see the need for software in cars and now they start asking for better software. This can only happen if there is a market for software, but to create a market you need standards.

Android Auto and  Apple Car are standards that allow 3rd parties to create apps for the cars, but the offer is extremely small and not really relevant.

In my opinion, only when cars can exchange data either directly (Vehicle to Vehicle communication – V2V) or through some infrastructure (V2I) on a large scale will we see a significant increase in software demand.
Unfortunately, the lack of standards for communication between vehicles is making this process extremely slow.

 

Conclusion

The automotive industry’s failure to fully embrace the concept of cars as hardware running very complex software has far-reaching consequences on the long term.

By neglecting software development, cybersecurity, and collaboration with software experts, OEMs put customer safety and satisfaction at risk. Classical OEMs have started to see too late that better software means more sales and more satisfied customers and reacted too slow to find solutions.

The limited adoption of agile development processes and inadequate OTA update capabilities further hinder progress in this domain.

To address these challenges, the industry must prioritize software as an integral part of vehicle design and manufacturing, invest in cybersecurity measures, foster collaboration with software experts, and educate consumers about the software-driven nature of modern cars.

Only through a comprehensive and proactive approach can the automotive industry truly unlock the potential of cars as hardware running software.

The post The Automotive industry’s inadequate approach towards software (in the cars) first appeared on Sorin Mustaca on Cybersecurity.

Portfolio Items