SECURITY

COMES AS
STANDARD
Building security into
modern software development
An F-Secure Consulting Whitepaper
 Security comes as standard

CONTENTS
INTRODUCTION 2
WHAT DOES A SECURE SOFTWARE DEVELOPMENT 3
PROGRAM LOOK LIKE?
KEY PEOPLE IN SOFTWARE PRODUCTION 4
THE IMPACT OF AGILE AND SCRUM ON SECURE 6
DEVELOPMENT
GETTING SECURITY AND DEVELOPMENT TO WORK 7
TOGETHER EARLIER
EMBRACING RAPID CHANGE – DEVOPS AND DEVSECOPS 8
SECURITY IN THE DEVELOPMENT ENVIRONMENT 9
TENSIONS AND CHALLENGES 10
CULTURE CHANGE 11
PLANNING AND MANAGING CHANGE 11
NINE QUESTIONS TO ASK WHEN ACQUIRING SOFTWARE 12
FROM THIRD PARTIES
KEY FACTORS FOR SUCCESSFUL CHANGE 13
CHALLENGES IN SECURING LEGACY CODEBASES 14
POSSIBLE APPROACHES WITH LEGACY SYSTEMS 15
TRANSITION TO SOFTWARE SECURITY 16
MEASUREMENT 17
TECHNOLOGY AND TOOLING 18
TOOLING IN VARIOUS PHASES 20
QUICK WINS 21
ANALYSIS 22

1
 Security comes as standard

INTRODUCTION
Over the years, there’s been a quiet revolution in
software development. Software engineers now create
working products that are more secure than ever.
This comes as organizations have had to rethink their
priorities, due to increasing malicious threats and tighter
data protection laws.

As well as releasing new features and delivering business

value, it’s also important to incorporate security
measures with the potential to limit innovation and delay
time-to-market. However, embedding security and rapid
development doesn’t always come naturally to teams.

Although engineering teams and IT security haven’t

traditionally worked together, a positive relationship
between these two teams is very beneficial. It reduces
risk and increases product quality, while allowing security
to act as a business-enabler itself.

Achieving secure software development requires a shift

in mindset by everyone in the organization, including the
business owners. Ultimately, a successful secure software
development program requires careful management of
three key elements: people, process, and technology.

2
 Security comes as standard

WHAT DOES A SECURE

SOFTWARE DEVELOPMENT
PROGRAM LOOK LIKE?
The cyber threat landscape has changed dramatically. Probably
because the traditional practice of late-stage testing has proven
to be expensive and complex. So, to identify issues earlier and
reduce costs, security must be integrated into every step of the
software development lifecycle (SDLC).

Here’s what a typical security plan for a secure SDLC might

look like:

Requirements stage
• Establishing the software security team, security champions,
and other team structures
• Training and education for the development team
• Ensuring security standards and guidelines are widely available
• Establishing processes to support delivery of the requirements
• Choosing and starting provision of secure development
environment and tooling
Design stage
• Identifying security requirements for the business context
• Threat modelling to understand how an attacker would look
at the system
• Reviewing designs from a security perspective
• Initial design of security testing
Implementation and development stage
• Reviewing code for implementation mistakes
• Security testing the various elements of the system, both
independently and as a system
• Automated testing as part of the continuous integration (CI)
development model
• Regression testing against threats or earlier known test
findings
Deployment stage
• Building incident playbooks
Maintenance
• Ongoing testing
• Monitoring

3
 Security comes as standard

KEY PEOPLE
IN SOFTWARE
In software production there are three key groups of people - the business
stakeholders, software engineering team, and the IT operations and security
functions. They often have different goals when it comes to security, so understanding
each group’s priorities is important.

BUSINESS STAKEHOLDERS SOFTWARE ENGINEERING TEAM

Business stakeholders don’t always Software engineers connect business
understand security. Their perceptions stakeholders’ requirements to a software
are often limited to the mainstream solution, turning business requests into
media and elements promoted by the instructions for developers. They make
internal security teams, such as phishing pragmatic decisions about frameworks,
awareness training. It’s essential to languages, architectures, and patterns.
bring them up to speed and help And, at the same time, they consider
them understand the impact security other practical factors such as usability
has on the early development stages, and reliability. Keeping up to date in
where their involvement makes a huge these fields is demanding, and requires
difference. a significant investment in time and
training.
It’s also important to align business
objectives with security to get buy-in For at least some of the engineering
from business stakeholders. Without team, software security’s likely to be
their backing, the development somewhat unfamiliar to them. In 2016,
team’s unlikely to be able to invest the Intel Security found that secure software
necessary time and tooling into security. development is one of three key skills
in critically short supply . And in their
Successful strategies prove how 2017 DevSecOps global skills survey,
investing in security can improve an Veracode reported less than one in four
organization’s reputation and set them developers or IT professionals were
apart in the market. They also present required to take a college course on
the team and brand as thought leaders security .
through contributions to open-source
tooling or other public forums. Yet the future looks bright. Many
security principles map easily to the
The goal is to help stakeholders view abstract nature of developing
security as a business enabler, not a
blocker.

4
 Security comes as standard

In software production there are three key groups of people -

the business stakeholders, software engineering team, and the
IT operations and security functions. They often have different
goals when it comes to security, so understanding each group’s
priorities is important.

IT OPERATIONS AND SECURITY FUNCTIONS

Today’s security functions often fall under the IT operations
umbrella due to the department becoming responsible for
hardware and network controls, such as firewalls.

The focus for IT operations is:

• Maintaining business as usual, continuity, and disaster

planning
• Managing procurement and provisioning for infrastructure
• Patching, monitoring, and securing devices
• Providing stability and standardization of platforms across
the business.

Although IT security teams may perform discrete security

assurance activities like penetration tests, development is
currently moving quicker than the traditional IT operations
function. Customer demands for faster releases have led many
development teams to adopt a DevOps model (sometimes by
stealth, as a means to get around latency imposed by inflexible
operations teams).

5
 Security comes as standard

THE IMPACT OF AGILE AND SCRUM

ON SECURE DEVELOPMENT
The popularization of the Agile manifesto and Scrum in
the early ’00s has affected most development teams to
some degree. The focus on faster, incremental software
production is changing the way we look at security.

Although some activities, like threat modeling, are

effective when carried out on a large-scale overview,
many aspects of security now focus on smaller
increments and faster releases. So it’s necessary to either
embed security skills within the software engineering
team or make security SMEs (Subject Matter Experts)
available at appropriate intervals. Many software
development teams using test-driven development
and continuous integration have the ability to integrate
security testing into their pipeline through tooling.

From a security perspective, the ability to react quickly is

a key advantage. There’s no longer a six-week lead time
on a critical security fix. If a change is required urgently
because a vulnerability’s been found, it can be actioned
rapidly and efficiently.

6
 Security comes as standard

GETTING SECURITY AND

DEVELOPMENT TO WORK
TOGETHER EARLIER
TO MAKE SURE PRODUCTS ARE DEVELOPED WITH ADEQUATE
DEFENSE AND NO DELAYS, IT’S ESSENTIAL SECURITY AND
DEVELOPMENT WORK TOGETHER FROM AN EARLY STAGE.

Historically, security functions would get involved in development

projects shortly before release. For example, they might be
required for a pre-release black box penetration test. This
process often comes with problems – the later lifecycle defects
are revealed, the more complex they are to resolve. As a result,
organizations face higher costs and longer delays to release.

Late-stage involvement also puts the security testing team under

immense pressure to evaluate all the security properties of a
potentially complex product in a very limited timeframe. And, even
if issues are addressed, there’s still a risk from the lack of built-in
layers of defense.

If security’s involved from the start, penetration tests are simply

an extra stage of assurance and unlikely to throw up major security
flaws. A positive way to ignite the security/developer discussion
is collaboration over integration between the SOC and the new
software application.

7
 Security comes as standard

EMBRACING RAPID CHANGE

DEVOPS AND DEVSECOPS
DevOps sees infrastructure as code. This is broken down into
three key areas:

• The files that define the virtual networking and configurations

• The scripts that build and harden the application servers
• The applications that run on them

Along with the DevOps movement, many organizations are on

a journey to faster releases and better response to customers.
DevOps sees virtualization, cloud technologies, and automation
tools now under the control of a multi-disciplined development
team. This allows the development team to make releases quickly
and scale dynamically.

This creates situations where tens or even hundreds of small

changes are made to a production environment every day.
Clearly, this won’t work alongside traditional security team
models that want to manually test every change before its
release. Which is where continuous response can come into play...
It provides real-time testing, so security teams are instantly aware
of potential vulnerabilities with any updates the dev team release.

8
 Security comes as standard

SECURITY IN THE
DEVELOPMENT ENVIRONMENT
The developer environment is a prime target for a cyber attack. Not only is the
source code itself likely to be at risk of theft, an attacker may modify it to add
a back door.

PREVENTION, OR AT THE VERY LEAST DETECTION, IS CRUCIAL

Engineering teams often have their own distinct practices in the

use of IT equipment and the management of resources, with
responsibility frequently delegated. It’s not unusual for them
to install their own software, self-manage their workstation
builds, and take responsibility for patching their own systems.
These engineers may spin up their own servers to test code or
prototype systems outside corporate hardening guidelines, and
they’re likely to have more privileges than regular users.

Not only does this threaten the security of the development

environment, it can also lead to their machines not being
‘standard enough’ to detect anomalies (such as an attacker’s
foothold). This makes them an easier target for more advanced
attackers. And due to the engineers’ unique privileged status and
access to sensitive Intellectual Property, attackers often target
them specifically.

Typical characteristics for a successful modern security

culture include:

• Collaborative relationships between • Expressing as much as possible as

engineering, security, and operations code, from configurations through to
teams. security testing.
• Unifying the tools used by security, • Use of virtualization technologies.
development, and operations teams.
• Using public/private cloud
• Heavy use of tooling to reduce virtualization to make representative
human effort by doing the easy things test environments.
quickly.
• Lowering cost of build/deploy
• Scripting everything, so next time it to rapidly adopt newly released
can just run and is repeatable. patches.

9
 Security comes as standard

TENSIONS AND CHALLENGES

Implementing secure development doesn’t mean throwing away an existing SDLC
and learning software production from scratch. That being said, it does require
some change. Organizations should be realistic about the rate of change in light of
business-as-usual pressures and budgetary constraints.

Here are some typical tensions that could occur:

• Business stakeholders perceive • Security functions worry about the

security as a ‘blocker’ or additional developer computer estate with
cost. relaxed restrictions and elevated
privileges.
• Business stakeholders consider
security to be someone else’s • Security and ops teams could feel
problem and shift responsibility to left out when a DevOps approach
security and/or development. is taken that undermines their
investment in well-organized,
• Operations and security get controlled infrastructure and
involved too late in the process standardization of platforms. They
and are unable to influence design could also be concerned developers
decisions. might have full control of the stack.
• Development teams might consider Control of maintenance activities
security to be someone else’s such as patching could now be with
problem. the developers.

• Development teams could be • Business tends to approve of a

frustrated by the inflexibility of DevOps approach because it
operations and security teams, and promises advantages such as faster
choose to circumvent them through releases and flexibility. However,
a DevOps model by using external this undermines the established
cloud providers. investment in technology by
security and operations teams.
• Developers are creative, and might
perceive security teams to be overly
restrictive.

So it’s important to build effective and sympathetic culture change into a security
program which addresses these issues.

10
 Security comes as standard

CULTURE CHANGE
The most successful organizations encourage a quiet background theme of
security at all levels of the business. They also tend to be more agile in the
marketplace and faster at releasing new software products. On the other
hand, organizations that don’t embrace security are not only facing greater
risks, they’re generally more procedurally restricted, conservative, and
slower to develop solutions.

Depending on the make-up and culture of the organization, culture change

may come directly from the top or have grass-roots origins. The latter
helps those involved feel they’re leading and defining the change, and
company-wide involvement should be actively encouraged. Support from
the top helps to validate the change and break down barriers between
development, operations, IT security, and business functions.

PLANNING AND
MANAGING CHANGE
Organizations must decide early-on whether to pursue a formal change
methodology or an informal adoption of best practice. Best-practice
activities are openly available and some organizations find adopting these
independently can be effective.

For larger organizations, formal maturity models offer a level of control

and assurance. Frameworks like OWASP SAMM allow organizations to
benchmark where they are as a whole – or against individual teams/
products – and then make choices to focus their improvement program.

Advantages of using formal methodology and maturity models:.

• Consistency
• Support from elsewhere in the industry
• Quantifiable metrics
Advantages of an independent implementation of best practice:
• Less upfront effort
• Quicker to get results
• Lighter-weight management of the process
• More customizable

11
 Security comes as standard

NINE QUESTIONS TO ASK

WHEN ACQUIRING SOFTWARE
FROM THIRD PARTIES

Over the years, there’s been a quiet revolution in software development. Software
engineers now create working products that are more secure than ever. This comes
as organizations have had to rethink their priorities, due to increasing malicious
threats and tighter data protection laws.

1. Do you specifically mention security in your requirements and are the relevant
contractual terms watertight? If security isn’t specified, it’s likely to be left out
or rushed.
2. Does the code match your standards? Take steps to inspect source code and
any design artifacts.
3. Do they use the frameworks, languages, and libraries you’re familiar with? You
don’t want to have to develop specific procedures to patch or maintain it.
4. If you’re not familiar with the languages or frameworks, will they allow a third
party inspection? Insist on this if you don’t understand their code.
5. Will you have access to the source code? This is important as future security
discoveries may require changes to the software. Consider escrow solutions if
necessary.
6. Do they match (or exceed) your organizational standards? For example, how is
your source code secured and kept separate from other client organizations?
7. Are the staff writing the code trained, permanent, vetted members of staff?
8. Have you used a software composition analysis tool? Inspect the software
supply chain and included libraries with respect to licensing and disclosed
vulnerabilities.
9. Do you have assurance that the development environments are secure? Have
they any evidence of review by a security specialist or have they achieved a
relevant accreditation?

12
 Security comes as standard

KEY FACTORS FOR

SUCCESSFUL CHANGE
Carrots vs sticks Security champions
Policies and rules can be enforced to Identify the developers with an interest
ensure prescribed patterns are followed, or and aptitude for security and invest in
a voluntary program can be adopted that training them. This allows them to carry
encourages change with promised rewards. out specific security tasks and help support
A combination of the two is highly effective; other team members. A network of security
allowing some developers to trail-blaze and champions is also an effective gateway
lead the way, while others are swept along between established security functions and
by the mandatory changes. development teams.
Gamification Social interaction
Contrary to popular belief, security can be Involving the security and development
made fun! Turning the adoption of security teams in shared social events and
processes or knowledge into a game can be presentations can build bridges. This
really effective. To generate enthusiasm and should help both teams to understand the
get results quickly, consider competitions constraints the other is facing, as well as
challenging teams to write the most secure providing informal routes for requesting
code or be the first to adopt practices. advice or reporting issues.
Security education Software security team
Convincing developers of the importance This can be a great mechanism for
of security is challenging, but massively empowering developers. It’s important the
beneficial. Security education is far more team includes application security experts
effective than creating time-intensive rules from operations and security teams, but
which may stifle independent thought. can also involve external experts. They
Budgetary and time constraints rarely allow act as the known point of escalation for
all developers to be fully trained in security, security issues encountered by developers,
but elements of training can help them if local champions cannot resolve them.
appreciate the problem and recognize when It’s also responsible for sympathetically
they need support. setting standards or practices, as developer
members will have working knowledge
Tying to objectives of how security practices are best
Tying the results of games or rewarded implemented.
behavior to team/personal objectives inside
the HR appraisal model demonstrates the
organization’s commitment to security.
It can also incentivize more reluctant
individuals, helping them to accept the new
security message.

13
 Security comes as standard

CHALLENGES IN
SECURING LEGACY CODEBASES
Adding security to an existing legacy development brings more
challenges than implementing security in a new development. A thorough
job will probably involve a level of change similar to extensive refactoring
or even rewriting. While complete refactoring might not be feasible, there
could be many smaller changes which enhance the security properties of
the application.

Key considerations are:

Implementation language
The choice of language might not be ideal from a security
viewpoint. Either the language or version of frameworks could
have known security issues.
Supporting systems
Supporting systems with poor security properties may need to be
maintained and connected. This could be due to either being out
of scope or too critical to be modified.
Existing consumers
The legacy application may need to support existing consumers
of APIs or established functionality that could be insecure. Making
changes might break backwards compatibility.
Tight coupling
In tightly coupled systems, changes to support security can have a
major impact through many components of the system.
Lack of original design documentation
Without knowledge of the original design intent and the higher-
level structure, identifying security issues and introducing
structural changes could be difficult.
Out-of-date standards
The application might rely on previous security choices that are
no longer appropriate – for example, MD5 password hashing
without salt.
Out-of-date hardware and server platform
Depending on the nature of the application, it might run on a
hardware or application server environment with undesirable
characteristics.

14
 Security comes as standard

POSSIBLE APPROACHES
WITH LEGACY SYSTEMS
A common approach is to focus on new systems and treat the existing
system as an unsalvageable black box, using additive controls around its
perimeter (such as firewalls). However, there are some low-cost approaches
that can improve the security of the legacy system to extend its effective life.

Some steps to consider:

• For standalone applications, it might be possible to use newer

compilers and flags. These allow operating system protections that
prevent some types of runtime exploitation of some aspects of the
code, especially in C/C++. For other languages and platforms, the
latest possible version of frameworks and supporting libraries is likely
to remove many possible attack vectors.
• Develop monitoring processes or mediation layers that check data
flows in runtime between systems. By sanitizing data flows and
detecting deviation, they can treat the protected systems as a black
box. However, they may later prove to be the foundation of rigorous
component tests if any of the systems are independently redeveloped.
• Use AST tooling to spot implementation issues in the application and
patch them.
• Instigate a design review to make sure patterns are appropriate, such
as authentication/authorization, session management, and use of
cryptography.
• Deploy RASP (runtime application self-protection) to detect
unexpected behavior.
• Selectively re-implement parts of the application, targeting only
specific areas or critical functionality.
• Take steps to understand whether the existing functionality is best
served in the legacy app or in a safer, more featured framework.
• Employ an expert skilled in software exploitation techniques to
investigate practical vulnerabilities.

An unexpected benefit of some older development languages is the relative

scarcity of publicized exploits and malicious skills (consider COBOL vs. PHP). While
a determined threat actor will invest the necessary time and effort, it does mean
any attacks detected on the application are likely to be worthy of attention.

15
 Security comes as standard

TRANSITION TO
SOFTWARE SECURITY
A positive transition will help to prevent any potential case
setbacks for software security. A heavy focus on education creates
positive momentum around a security project. And sitting security
personnel side-by-side with developers can help break down
barriers between the teams.

Rolling out benchmarked standards can work well with

appropriate gamification, links to personal development
objectives, incentivizing developers to improve their team –
perhaps even with the lure of financial gain!

However, security activities and tooling must proceed at a

measured pace to make sure business as usual is maintained.
Where transition revolves around tooling changes, enough time
needs to be given to selecting, acquiring, deploying, and tuning
the right tooling. Appropriate training and support is also required
while the new tooling’s adopted into each team’s build pipeline.

When managing transition, bear in mind no two software teams

are the same. They vary by:

• Experience • Infrastructure
• Product • Geography
• Tooling • Culture
• Legacy

Resistance to change can be minimized by careful consideration

of the right way to evolve their existing processes.

Transition takes time. It’s better to plan the journey to fit with the
existing rhythm of the team, while finding ways to readily report
progress. Both of these are key to retaining management support
and investment in the program.

16
 Security comes as standard

MEASUREMENT
Demonstrating a return on investment can help justify an
ongoing software security program. Measuring success isn’t as
straightforward as looking for a reduction in the breaches. Here
are some alternatives:

• Measuring the number of issues found in penetration testing.

An application development team should ask penetration
testers by getting them to test an application in which they can
find no vulnerabilities.
• Measure the number of on-time releases or reductions
in project overruns. These could be due to last-minute
refactoring, leading in turn to associated cost reductions.

When issues are discovered, it’s often helpful to track down

the origin of the issue as a learning experience. Opportunities
to improve a process or educate a specific team/individual are
incredibly valuable, as are tracking changes in the origin of defects
over time. It can provide a measure of how security awareness is
affecting the business. If a maturity model’s been adopted, the
metrics generated are a useful indication of increased capability
and can provide good visibility of security activities throughout
the lifecycle.

17
 Security comes as standard

TECHNOLOGY AND TOOLING

Demonstrating a return on investment can help justify an
ongoing software security program. Measuring success isn’t as
straightforward as looking for a reduction in the breaches.
Here are some alternatives:

• Integrated environments
• Frameworks and tooling to support unit testing
• Continuous integration
• Code coverage

These richer tools support complex applications that rely

increasingly on third-party libraries for their functionality, with
security activities more reliant on tooling.

Although tooling has no inherent intelligence, it can perform

a large number of sophisticated, tedious checks. These can
potentially be done every time the codebase is built, far faster than
a human could manage which scales the capability of the team.

Heavy reliance on tooling is a fundamental part of the DevOps

approach. By carefully using this and human security experts,
coupled with a wide general awareness of security in the
development team, successful teams achieve frequent, fast release
cycles with a reasonable assurance of secure code.

18
 Security comes as standard

EARLY PHASES - INITIATION, As modern applications are assembled from

REQUIREMENTS AND DESIGN ACTIVITIES developed code and third-party open-source
Early in the lifecycle, tooling can support packages and frameworks, the development
threat modelling. It captures threats the team team must ensure vulnerable components
identifies in terms of new system requirements haven’t been incorporated. A category of
or by using formulaic mechanisms in specialist tooling that automates this checking is
toolsets to evaluate all potential vectors. known as software composition analysis. It
can also provide guidance on restrictions
Where possible, it’s preferable to use governing the software license use.
existing tooling for requirement capture
and refinement. Introducing new systems DURING TESTING
to handle a specialist security task can Dynamic analysis (also known as DAST) is a way
make security tasks seem to be an external to test code that’s running, typically by providing
activity. The true value is in developing unusual input. This means this type of tooling can
critical security thinking within the teams. only detect issues later in the development cycle
when the code can be run.
DURING IMPLEMENTATION
Static analysis (also known as SAST) is a widely Dynamic analysis is complementary to static
used quality and security tooling mechanism. It analysis as it typically highlights different issues.
allows a tool to detect poor patterns in source Enterprise-grade security tooling for commercial
code, which might lead to quality or security applications typically has a significant cost,
defects. Static analysis is most valuable during reflecting the R&D in its production.
the actual implementation phase, providing
feedback to the developers as code is produced. As with many other forms of software testing,
there are steps that can be taken in the CI/CD
Depending on the product, these evaluations pipeline by applying large numbers of simple
are made in a number of ways, with a varying rules to check for issues. Starting points for
focus on how the issues should be resolved – this approach can be as straightforward as
either by the developers or the security team. using command-line tools to search for the use
If the latter, it’s crucial the security team is of insecure functions. Free and open-source
open and responsive to the developers. frameworks exist to assist the implementation of
this type of testing, but much of the test content
The term static analysis has a wide range of has to be developed by the team.
meanings. It could be as simple as automated
checking of stylistic issues, such as the use of When adopting static and dynamic application
tabs or spaces or variable naming conventions. security tooling, it’s important to ‘tune’ the
Or it might be able to detect non-sanitized data tooling to minimize false positives, which
or inconsistencies in the way certain routines are waste the team’s time and can cause loss of
called that could suggest underlying defects. trust in the tool. Effective tuning generally
requires significant time, effort, and a broad
understanding of secure coding topics.

19
 Security comes as standard

CONTINUOUS INTEGRATION PIPELINES VULNERABILITY SCANNING TOOLS

Continuous integration pipelines are incredibly Using vulnerability scanning tools on deployed
useful places to run a number of verifiers that can systems and applications will reduce the risk from
perform analysis against code, including many of deploying out-of-date or misconfigured systems.
the systems discussed above. Tests can be added It doesn’t typically analyze the developed
directly at this point, alongside other testing application to any great extent but might identify
suites looking explicitly for security issues. generic issues.

If security professionals have previously tested These tools are generally used throughout an
the code, it might be possible to represent operational lifetime to make sure the application
their findings in scripts to prevent inadvertent servers and infrastructure remain current in
regressions. This is the same way a disciplined terms of patching, etc. A development team
test engineering regime will prevent quality can also utilize this tooling as part of a testing
regressions. and deployment chain so they’re not promoting
known vulnerable application servers to a
SPECIFIC SECURITY TESTING live environment. They have the ability to run
For narrow, well-defined interfaces such as web more in-depth analysis than is possible in a live
services, APIs, or file parsing, a technique called environment, where availability could be affected.
fuzzing or fuzz testing can yield effective results.
This involves subjecting an application to a wide
range of inputs and checking for unexpected
behavior, such as crashes. A wide variety of
inputs will typically be tried, each modified either
randomly or with heuristics that have some
understanding of formats or context.

TOOLING IN EARLY PHASES (REQUIREMENTS AND DESIGN)

VARIOUS PHASES • Threat modeling tools

IMPLEMENTATION
• Static analysis

TESTING
• Vulnerability scanning tools
• Dynamic analysis
• Software composition analysis
• Domain-specific testing tools

DEPLOYMENT
OPERATION
20
 Security comes as standard

QUICK WINS
ROLLING OUT SECURITY THROUGH THE LIFECYCLE IS COMPLEX AND
TAKES TIME. SOME ACTIVITIES CAN PROVIDE QUICK WINS AND SET
THE STAGE FOR MORE COMPLEX CHANGES AT A LATER DATE.
HERE ARE SOME EXAMPLES OF STEPS YOU CAN TAKE TO GET RESULTS:

FORMING AND EMPOWERING A USING AST TOOLING

SOFTWARE SECURITY TEAM Software solutions, such as static and dynamic
Ideally the team will be formed of enthusiastic analysis, can be used to scan either source code
people from different teams. Together, they’ll or built applications. This helps to spot potential
be responsible for deciding and enforcing security and quality problems earlier in the build
appropriate security standards, acting as a lifecycle. There are additional costs and potential
set of expert reviewers, and deep technical complexities with deploying new tooling, but
investigators. even a trial of a commercial tool could give
an indication of the quality of the developed
AWARENESS TRAINING OF KEY application. However, AST tooling will not detect
PERSONNEL
all implementation mistakes and even fewer
he level of awareness and particular skills required design mistakes.
will vary from one team member to the next,
depending on their department and experience. GAMIFYING THE TESTING
The appropriate awareness training might In organizations with an adversarial developer/
therefore focus on formal training, CBT, book tester dynamic, it can help to train existing test
learning, or internal workshops. specialists to spot security issues. This, in turn,
challenges developers and designers to write
THREAT MODELING UNDERTAKEN AS A
correct code that ‘beats’ the empowered test-
PROCESS
engineering function.
Threat modeling can begin with an existing
artifact used to engage everyone from business ACQUIRING TOP-LEVEL SANCTION
stakeholders down to development team Even if the move towards secure software begins
members. It also brings a consideration of at a technical level, an awareness from the top of
security into the design phase. the business will help to spread the message and
increase acceptance. It also helps to break down
ADDING SECURITY INTO REQUIREMENTS
barriers within the traditional functional areas.
Making sure security issues have equal billing
with usability or performance helps give the
development team a mandate to solve security
problems.

21
 Security comes as standard

ANALYSIS
Now is an exciting time to be involved in software development. In the
modern economy, software provides digital platforms to run companies
and channels to reach customers. It falls to software engineering teams
to keep the next generation of applications safe from the ever- advancing
skills of threat actors.

With more organizations embracing software security and the number

of resources increasing, it’s easier than ever to embark on this kind of
program. However, managing the journey can still be fraught with risk and
there’s no single approach that works for all teams.

Pushing processes from the top down could undermine some of the
positive changes an agile approach allows, inhibiting velocity and
threatening business value. But if the case for moving to a secure
development model isn’t made successfully, internal resistance could
delay its adoption for a number of years, extending the organizations
exposure to risk.

Security tooling is maturing, and there’s been an evolution of rapid

development and deployment models. For example, DevOps and
DevSecOps are bringing an empowering concept of security firmly to the
engineering teams. A more positive image of software security is starting
to reach all areas of the business, enabling new business models and
practices.

Breaking down established internal walls between teams can provide real
business value, far beyond the obvious security benefits.

If your current processes aren’t working for you, or you’d like to discover
the key areas of security you should focus on, contact us.
We’d love to help!

22