The Agile RAMSS lifecycle for the future

Thor Myklebust
SINTEF Digital, Norway. E-mail: thor.myklebust@sintef.no

Per Håkon Meland

SINTEF Digital, Norway. E-mail: per.h.meland@sintef.no

Tor Stålhane
NTNU Norway. E-mail: stalhane@ntnu.no

Geir K. Hanssen
SINTEF Digital, Norway. E-mail: geir.k.hanssen@sintef.no

In recent years, there has been an increasing interest and growing use of agile development methods when
developing safety-critical systems. This interest is motivated by the need to shorten time-to-market, reduce costs,
improve quality, and to support the paradigm of continuous development and deployment.
This paper presents an agile lifecycle approach to Reliability, Availability, Maintainability, Safety and Security
(RAMSS) engineering and management. The current trend for cyber physical systems is more connectivity over
insecure networks, and as a consequence of emerging security threats, we suggest a systematic addition of security
in this area, complementing safety. Depending on the domain, it is not just the software itself that must be updated
due to security issues, but also safety cases and accompanying evidence.
The Agile RAMSS approach covers all phases of the development process, including improvements due to
modifications and safe patching during operation. These improvements have to be performed based on strict safety
standard requirements. The lifecycle is aimed at manufacturers of High Integrity Systems, like Industrial
Automation and Control Systems and Safety Instrumented Systems. We have used our in-depth knowledge of
security standards, like the IEC62443 series and the software safety standards IEC61508-3 and EN 50128, to
establish a risk-based approach that is combined with a fast track solution of the SafeScrum method including
DevOps.

Keywords: Agile, RAMS, SafeScrum, Safety, Security, DevOps.

1. Introduction certified in a changing threat landscape, where

shorter time-to-market and faster response to
There has been an increasing interest and growing security threats becomes more important.
use of agile development methods when Developers and users of safety critical systems
developing safety-critical systems in both face three important problems; (1) the need to
transport domains and the process industry react quickly to any challenges due to changes in
Myklebust et al (2017). the system’s usage or operating environment, (2)
This paper presents an agile lifecycle approach to the need to use available experiences to improve
Reliability, Availability, Maintainability, Safety the system and (3) the need to keep the system
and Security (RAMSS) engineering and certified by the relevant authorities each time
management. Due to the increased connectivity something is changed. The first two of these
over insecure networks and emerging security problems can be handled efficiently, given the
threats, we recommend a systematic analysis and right development environment, while the last one
handling of security in this area, complementing is, at least partly, outside the developers’ control.
RAMS. Depending on the domain, it is not just As pointed out by Sun et al. (2009), safety and
the software itself that must be updated due to security goals interact synergistically or
security issues, but also safety cases and conflictingly, and should therefore be evaluated
accompanying evidence. These tasks can take together. If not, conflicts can result in either (a)
several months before a modification or patch overly secure systems that compromise the
rollout can begin, which can be a risk by itself. reliability of critical operations or (b) create
This creates a tension between release cycles and insecure systems where back-doors are easily
safety assurance. The industry, regulators and found. They both share a risk-driven approach,
certification bodies have to rethink how safety- where risks should be continuously identified,
critical software systems should be developed and monitored and treated throughout the system
Proceedings of the 29th European Safety and Reliability Conference.
Edited by Michael Beer and Enrico Zio
Copyright ©2019 by ESREL2019 Organizers. Published by Research Publishing, Singapore
ISBN: 981-973-0000-00-0 :: doi: 10.3850/981-973-0000-00-0 esrel2019-paper
2 Thor Myklebust, Per Håkon Meland, Tor Stålhane and Geir K. Hanssen
lifecycle. However, the focus of safety risk
analysis is more on how system failure events can
harm health and the physical environment in
which it operates, while security risks typically
have an external origin that attacks the system.
Safety events follow a stochastic probability
distribution due to physical wear and tear and
human mistakes, while security attacks are driven
by human intentions and the presence of
exploitable vulnerabilities. The latter leads to a
heavier reliance on trend analysis and knowledge
about attackers rather than historical data when
making probability predictions. An exploratory
research process using observations, reviews and
documentation conducted at three companies and
interviews was conducted with three certification
bodies.
2. Background
2.1 Safety and security standards
There are several standards related to safety and
security.
Figure 1: Different safety standards and their references to
relevant security standards
The following four standards are representative
subset for ongoing standardization efforts in the
area: IEC 61508:2010 and EN 50128:2011, EN
50128: draft 2018, IEC 62443-4-1:2018, IEC TR
62443-2-3:2015 and ISO/IEC 27001:2013. This
is enough to give an idea of the state of the
standardization. IEC 61508 is a generic standard
for safety critical systems. Its relationship with
security is made clear in part 1: “In particular, this
standard does not specify the requirements for the
development, implementation, maintenance
and/or operation of security policies or security
services needed to meet a security policy that may
be required by the E/E/PE safety-related system.”
Even though the standard does not have any
requirements for security, it states, “If the hazard
analysis identifies that malevolent or
unauthorized action, constituting a security threat,
as being reasonably foreseeable, then a security
threats analysis should be carried out.” Patching,
which may be important when needing a quick fix
for a security problem, is not mentioned in this
standard.
The IEC TR 62443-2-3 is only concerned with
patching of industrial automation and control
systems (IACS), not e.g. SIS (Safety
Instrumented Systems). The main point is that:
“Asset owners have an implied obligation to
uphold the safety, reliability, operability, security
and quality of their operations. Achieving cyber
security assurance, through patching IACS assets,
is a critical part of that obligation.”
EN 50128:2011 do not refer to security standards
and does not even mention the term "security".
Just as IEC 61508 just refers to security concerns,
IEC 62443-4-1 just refers to safety concerns –
mostly to IEC 61508. Safety is only mentioned in
section 11.2: Security update qualification. Here,
the standard states that a process shall be
employed for verifying that security updates
created by the product developer address the
intended security vulnerabilities and do not
introduce regressions. In addition, this standard
has a lot of text related to patches – defined as the
“management area of systems management that
involves acquiring, testing and installing software
patches (code changes) to a product.” Last but not
least, the standard states: “The process should
include a confirmation that update is not
contradicting other operational, safety or legal
constraints.”
ISO/IEC 27001:2013 is a pure information
security management standard and do not mention
safety at all. The standard has four main parts,
covering all the important aspects of information
security management – understanding the
organization, planning, support, operations and
improvement. Improvement includes
identification of non-conformities and corrective
action. The standard has requirements both on
security risk assessment and on how to deal with
it.
2.2 RAMS
Reliability is mentioned in the security standard
IEC 62443-2-3 but only related to patch
management – “The objective of patch
qualification is to build confidence with technical
validation that the patch will not negatively affect
the performance, safety or reliability of the
IACS”. IEC 62443-4-1 only mention reliability as
part of definitions. Availability in the system
sense is mentioned in IEC 62443-4-1 but only as
a characteristic that must be considered during
patching – no advice or requirements are inserted.

Reliability does not get much attention in IEC
61508 except for a recommendation for reliability
block diagrams. In addition, reliability is
mentioned in two notes as follows: “Although
systematic safety integrity is usually unquantified,
quantified statistical evidence (e.g. statistical
testing, reliability growth) is acceptable if all the
relevant conditions for statistically valid evidence
are satisfied.” IEC 61508 does not mention
maintainability or availability as software quality
characteristics at all.
We have also analysed the railroad standards –
IEC 5012x. The results confirm what we have
seen in the other relevant standards – while
“safety” is mentioned more than a 1000 times,
reliability, availability and maintainability are
each mentioned less than 50 times.
Based on the examples cited above, it is fair to say
that most of the RAMS focus in all the quoted
safety-relevant standards is on safety.
2.3 DevOps and the relation to safety and
security
DevOps Laukkarinnen et al (2018) has emerged
from the agile community as a way of closing the
gap between software development and
operations and allow rapid and dependable release
cycles. This is accomplished using technical
measures such as automated toolchains, but just
as important is an encouragement for
collaboration and communication between
various stakeholders within an organization.
DevOps is meant to take care of the need to react
quickly to any challenges due to changes in the
system’s usage or operating environment and the
need to use available experiences to improve the
system. However, there are several challenges to
the use of DevOps. Lwakatare et al. (2016) have
summed it up nicely as four important issues –
hardware dependency, limited visibility of
customer environments, lack of technology
needed for deployment in customer-specific
environment and absence of feature usage data.
For safety-critical systems a fifth and sixth issue
should be added – safety evidence and safety
certification. Based on this, part of the solution
seems to be more knowledge and data on how our
systems are used.
Since safety – and thus security – are our main
concerns, it is important to collect data on near
misses and security breaches. This will allow us
to collect information on which types of barriers
work and which do not. This information should
then be fed back to the developers and used to
develop the next, improved version. In addition,
each time the environment or the system’s usage
change, we need to repeat the risk assessment
3
process. This might create needs for new safety or
security requirements.
2.4 SafeScrum
The SafeScrum process was developed through
collaboration between research and industry,
involving leading Norwegian providers of safety-
critical systems. All the main components of the
Scrum process are kept. See Hanssen et al, (2018).
SafeScrum extends the basic Scrum model in
order to make the process applicable for
development and certification of safety-critical
software. This is done by including the SRS, as
this is required by the safety standards. In
addition, practices like safety stories Myklebust
and Stålhane (2016) and the backlog are included
to ensure that the software engineers fully
understands the requirements. In addition, all
development and change of requirements and
code are traced.
We have also included internal quality assurance
within the SafeScrum process. The QA
responsible is part of the Scrum team and will
verify that all quality assurance tasks have been
performed Hanssen et al (2016). When existing
code is being changed, the team must do a change
impact analysis – see Myklebust et al 2014 – to
evaluate whether the change will affect the safety
of the system. Short iterations enable frequent
evaluation of the detailed design and of the safety
function of the system. It also forms a basis for
frequent communication, both within the team,
with the product owner (e.g. the customer), and
with the assessor. The key principle is to uncover
and correct problems as early as possible in the
development process. Knowledge regarding the
status of the development can be communicated
by incremental issue of an Agile Safety Case – see
Myklebust and Stålhane (2018).
In order to add security to the SafeScrum process,
we have used two concepts – alongside
engineering – a set of supporting activities
running in parallel with the Scrum process – and
the security case, similar to the safety case,
suggested by Patu and Yamamoto (2013). The
alongside engineering concept fits quite well with
the ideas from Howard and Lipner (2006).
Howard and Lipner also states that “Microsofts
experience is that the security team must be
available for frequent interactions during software
design and development, and must be trusted with
sensitive technical and business information. For
these reasons, the preferred solution is to build a
security team within the software development
organization (although it may be appropriate to
engage consultants to help build and train the
members of the team).”
SMEs will not have the resources needed to have
a dedicated security team, but should nevertheless
4 Thor Myklebust, Per Håkon Meland, Tor Stålhane and Geir K. Hanssen
have a security advisor to assist the Scrum team.
A security team or a security advisor is a sensible
approach to the security part of RAMSS. The
security-enhanced process is as shown in the
figure below. As stated previously, the outmost
set of activities belong to “alongside
engineering”. Thus, e.g., “Safety and Security
analysis” are done by the safety expert and the
security expert respectively.
Figure 2: The SafeScrum process threat intelligence and safety
Since new security threats can surface at any time,
it will be useful to combine the change impact
analysis with an attack-tree analysis to get a better
understanding of possible new attacks.
3. Patching and certification
In many cases, a correction or changes in
functionality can wait until the next release.
However, every now and then a problem surfaces
that needs to be taken care of right away – for
instance problems that are security-related. As
computer systems become more and more
connected to other computer systems – e.g.,
through the internet, the opportunities for break-
in will increase and the longer such an opportunity
exists, the more probable it will be that someone
will take advantage of it. Thus, the need for quick
fixes. Depending on the domain and the practice
by the relevant certification bodies, the changed
system will need to be recertified. This is for
instance a requirement in the railway domain. A
recertification may take anything from one week
to half a year after the change.
This is an unfortunate situation, which needs to be
fixed. In order to evaluate our opportunities, we
presented the following scenario to three global
certification authorities, which certify safety
critical system, e.g., for the offshore industry:
“Our system of interest is safety critical, reads a
set of sensors and thereafter sets a set of actuators.
The system communicates with its sensors and
actuators over a dedicated Ethernet. A year ago,
the sensor network was extended with several
wireless sensors. The new system software was
certified by the assessor and then set into
operation. The company that uses the system has
discovered several break-in attempts, using a
vulnerability in the system’s communication part.
The company responsible for the communication
part of the system has been informed of the
problem and came up with a patch that will solve
the problem.”
Based on the scenario above, we put two
questions to the certification companies:
1. What need to be re-certified (1) the
whole system, (2) the changes or (3) the
subsystem affected by the changes – in our case,
the communication.
2. Would it be possible to make an
agreement with the certifier so that we only certify
the change process and report the change to the
certifying company?
Answer from company 1:
• "An impact analysis – the effects of the
changes to the overall system should be described
together with the verification and validation
activities to be repeated in order to show that the
changes done to the system have no adverse effect
to the safety of the overall system. A re-
certification of the overall updated system should
focus just on the performed changes and their
impact to the system”.
• “Certified change or development
process will not necessarily lead to a certifiable
solution. Thus, reporting changes in conjunction
with a certified change process will not be
sufficient. I would always also assess the actual
performed changes and check that I agree with the
impact analysis results”.
Answer from company 2: The extent of re-
assessment depends on the system’s SIL.
• SIL 2 system => the changes and the
affected subsystems shall be revalidated. SIL 4
system => the complete system shall be
revalidated.
• It is possible to certify the change
process in terms of a “functional safety
management system”
Answer from company 3:
• “As a minimum, an impact analysis and
a complete reverification of affected modules is
necessary and a solid software configuration
procedure must be in place. In addition,
regression validation is highly recommended”

• “For higher SIL values (3 – 4) a
complete system validation may be necessary”
To sum up: according to the assessors, a
revalidation of the changed parts of the system,
together with recertification is needed. When it
comes to relying only on a certified change
process, the opinions are divided. One of the
companies says “No way”, one says “Only for
functional safety” while the third company did not
answer this part of our question.
First and foremost, the problem is real and will not
go away. If anything, it will only get worse. At the
present, this is solved by applying the patches
while not telling anybody – sorry, no references
here. The patches are officially inserted into the
system and certified when a new version is
released. This is, however, not the optimal
solution since the certifying authorities are left
totally out of the loop.
We suggest the following solution:
• The developing company should define
a patching process. As a minimum, it should
contain change impact analysis and retesting of all
parts affected by the change.
• The assessor should have access to proof
of compliance for the patching process, including
the test logs.
• The patch acceptance should only be
valid for a defined length of time – e.g. six
months. After this, the patch should be included
in the system update and the new, revised system
should be certified as usual.
4. The RAMSS lifecycle
RAMS (Reliability, Availability,
Maintainability and Safety) EN 50126-1:1999 has
traditionally been the important concerns and is
the lifecycle for the railway EN 50126 standard
series. A similar lifecycle is presented in the
generic IEC 61508 series. The idea of the agile
RAMSS is to add security to the process in a clear,
agile and distinct manner. All the RAMSS parts
should be based on an agile approach but keeping
relevant and required parts of the safety and
security standards. Security should be part of our
concern, right from the overall scope definition
and hazard analysis to operation, maintenance and
repair. This again, implies that security will also
be part of the verification and validation
processes. For many safety-critical systems, the
environment and the users’ needs will change
over time and create needs for system changes –
some small and other quite dramatic. For changes
related to security, the time from observed needs
to implemented change is important. The longer
the security threat is open, the larger the
5
probability that someone will take advantage of it.
After an update, part of the system will need re-
certification.
Thus, we do not just need to use ideas from
DevOps – we also need to make assessors rethink
their approach to certification after security-
related changes. We already know that assessors
will not accept a certified change process and
leave it with that – see discussion in section 3.
The IEC 62443 series includes a security
lifecycle based on SDL (Security Development
Lifecyle) developed by Howard and Lipner
(2006). This lifecycle also includes a description
for agile development.
In the figure below we have shown an agile
lifecycle, the IEC 61508 lifecycle, DevOps
lifecycle including necessary planning and the
security lifecycle. The security part should be
included in the alongside engineering together
with safety but in some projects two teams are
necessary i.e. both a safety and security team.
New technology has made it simpler to monitor
the operation of safety systems. It has also
become more important to move towards a
process with more frequent updates and upgrades
(see definitions for update and upgrade in e.g. IEC
62443-4-2:draft 2018) of the safety software, after
the product/system has been developed, due to
e.g., improved operational feedback, technology
improvements and security issues, including safe
patching. The Agile Safety Case Approach,
Myklebust and Stålhane (2018), can be an enabler
for future DevOps processes that unifies software
development (Dev) and software operation (Ops).
Figure 3: Different lifecycles that are relevant when
developing safety-critical systems.
6 Thor Myklebust, Per Håkon Meland, Tor Stålhane and Geir K. Hanssen
Although there exists both several safety and
security standards, they are not part of a safety and
security framework. As a result, the developers
must interpret how to combine the standards
(cooperation, integrated or separate system).
Communication with the assessors and safety and
security experts are of crucial importance. The
draft technical report IEC 63069:draft 2018 tries
to solve some of these challenges. Several
challenges remain like e.g. safe patching. Safe
patching is not defined. A safe patch must satisfy
the safety requirements and include e.g. an agile
safety case. In addition, there are a need for
improved safety and security awareness and
communication between the different experts.
In the figure above we have included the main
elements to consider when a manufacturer shall
develop and continuously improve a safety
critical product or system. How to apply the
correct RAMSS lifecycle depends on different
factors as e.g. SILx, SLy, product, system and the
actual domain.
5. Conclusion
The new, Agile RAMSS approach covers all
phases of the development lifecycle, including
improvements due to modifications, updates,
upgrades or safe patching during operation. The
improvements, including an agile approach and
including security, have to be performed based on
strict safety standard requirements when doing
modifications or upgrades. The proposed lifecycle
is aimed at manufacturers of High Integrity
Systems, such as Industrial Automation and
Control Systems and Safety Instrumented
Systems. We have used our in-depth knowledge
of security standards, like the IEC62443 series
and the software safety standards IEC61508-
3:2010 and EN 50128:2011, to establish a risk-
based approach that is combined with a fast track
solution of the SafeScrum method, including
DevOps and issuing of an Agile Safety Case. Both
Sprints (software development, see figure 1) are
used alongside (in parallel) with a Safety &
Security engineering team to facilitate
incremental modifications throughout the whole
lifecycle of the safety system.
T. Myklebust and T. Stålhane. The Agile Safety
Case. ISBN 9783319702643 Springer
International Publishing AG, February 2018.
G. K. Hanssen, T. Stålhane and T. Myklebust.
SafeScrum – Agile Development of Safety-
Critical Software. ISBN 9783319993348
Springer International Publishing AG,
December 2018.
HOWARD, Michael and LIPNER, Steve, The
Security Development Life-cycle; SOL A
Process for Developing Demonstrably More
Secure Software, 2006, Microsoft Press,
Redmond, Washington
N. Patu and S. Yamamoto. A new approach to
develop a dependable security case by
combining real life security experiences
(lessons learned) with D-Case development
process. CD-ARES 2013 workshop, LNCS
8128, pp 457-464, 2013. IFIP International
Federation for information processing.
Sun, M., Mohan, S., Sha, L., Gunter, C.:
Addressing safety and security contradictions
in cyber-physical systems. In: Proceedings of
the 1st Workshop on Future Directions in
Cyber-Physical Systems Security (CPSSW09)
(2009)
Lucy Ellen Lwakatare, Teemu Karvonen, Tanja
Sauvola1, Pasi Kuvaja, Helena Holmström
Olsson, Jan Bosch and Markku Oivo.
Towards DevOps in the Embedded Systems
Domain: Why is It so Hard? 2016 49th Hawaii
International Conference on System Sciences.

References
T. Myklebust, G. K. Hanssen and N. Lyngby. A
survey of the software and safety case
development practice in the railway signalling
sector. ESREL Portoroz Slovenia 2017
T. Laukkarinen, K. Kuusinen and T. Mikkonen.
Regulated software meets DevOps.
Information and Software Technology 97
(2018) 176-178