SECURITY COMES AS STANDARD · 2020-03-17 · DevOps sees virtualization, cloud technologies, and...

COMES ASSTANDARD

SECURITY

Building security into modern software development

An F-Secure Consulting Whitepaper

1

CONTENTS

INTRODUCTION

WHAT DOES A SECURE SOFTWARE DEVELOPMENT PROGRAM LOOK LIKE?

KEY PEOPLE IN SOFTWARE PRODUCTION

THE IMPACT OF AGILE AND SCRUM ON SECURE DEVELOPMENT

GETTING SECURITY AND DEVELOPMENT TO WORK TOGETHER EARLIER

EMBRACING RAPID CHANGE – DEVOPS AND DEVSECOPS

SECURITY IN THE DEVELOPMENT ENVIRONMENT

TENSIONS AND CHALLENGES

CULTURE CHANGE PLANNING AND MANAGING CHANGE

NINE QUESTIONS TO ASK WHEN ACQUIRING SOFTWARE FROM THIRD PARTIES

KEY FACTORS FOR SUCCESSFUL CHANGE

CHALLENGES IN SECURING LEGACY CODEBASES

POSSIBLE APPROACHES WITH LEGACY SYSTEMS

TRANSITION TO SOFTWARE SECURITY MEASUREMENT

TECHNOLOGY AND TOOLING TOOLING IN VARIOUS PHASES

QUICK WINS

ANALYSIS

2

3

4

6

7

8

9

10

11 11

12

13

14

15

16 17

18 20

21

22

Security comes as standard

2

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.

INTRODUCTION


3

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

WHAT DOES A SECURE SOFTWARE DEVELOPMENT PROGRAM LOOK LIKE?


4

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.

KEY PEOPLE IN SOFTWARE

BUSINESS STAKEHOLDERS

Business stakeholders don’t always

understand security. Their perceptions

are often limited to the mainstream

media and elements promoted by the

internal security teams, such as phishing

awareness training. It’s essential to

bring them up to speed and help

them understand the impact security

has on the early development stages,

where their involvement makes a huge

difference.

It’s also important to align business

objectives with security to get buy-in

from business stakeholders. Without

their backing, the development

team’s unlikely to be able to invest the

necessary time and tooling into security.

Successful strategies prove how

investing in security can improve an

organization’s reputation and set them

apart in the market. They also present

the team and brand as thought leaders

through contributions to open-source

tooling or other public forums.

The goal is to help stakeholders view

security as a business enabler, not a

blocker.

SOFTWARE ENGINEERING TEAM

Software engineers connect business

stakeholders’ requirements to a software

solution, turning business requests into

instructions for developers. They make

pragmatic decisions about frameworks,

languages, architectures, and patterns.

And, at the same time, they consider

other practical factors such as usability

and reliability. Keeping up to date in

these fields is demanding, and requires

a significant investment in time and

training.

For at least some of the engineering

team, software security’s likely to be

somewhat unfamiliar to them. In 2016,

Intel Security found that secure software

development is one of three key skills

in critically short supply . And in their

2017 DevSecOps global skills survey,

Veracode reported less than one in four

developers or IT professionals were

required to take a college course on

security .

Yet the future looks bright. Many

security principles map easily to the

abstract nature of developing


5

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).


6

THE IMPACT OF AGILE AND SCRUM ON SECURE DEVELOPMENTThe 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.


7

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.


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.

EMBRACING RAPID CHANGE DEVOPS AND DEVSECOPS

8


9

SECURITY IN THE DEVELOPMENT ENVIRONMENT

• Collaborative relationships between engineering, security, and operations teams.

• Unifying the tools used by security, development, and operations teams.

• Heavy use of tooling to reduce human effort by doing the easy things quickly.

• Scripting everything, so next time it can just run and is repeatable.

• Expressing as much as possible as code, from configurations through to security testing.

• Use of virtualization technologies.

• Using public/private cloud virtualization to make representative test environments.

• Lowering cost of build/deploy to rapidly adopt newly released patches.

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:


10

TENSIONS AND CHALLENGES

• Business stakeholders perceive security as a ‘blocker’ or additional cost.

• Business stakeholders consider security to be someone else’s problem and shift responsibility to security and/or development.

• Operations and security get involved too late in the process and are unable to influence design decisions.

• Development teams might consider security to be someone else’s problem.

• Development teams could be frustrated by the inflexibility of operations and security teams, and choose to circumvent them through a DevOps model by using external cloud providers.

• Developers are creative, and might perceive security teams to be overly restrictive.

• Security functions worry about the developer computer estate with relaxed restrictions and elevated privileges.

• Security and ops teams could feel left out when a DevOps approach is taken that undermines their investment in well-organized, controlled infrastructure and standardization of platforms. They could also be concerned developers might have full control of the stack. Control of maintenance activities such as patching could now be with the developers.

• Business tends to approve of a DevOps approach because it promises advantages such as faster releases and flexibility. However, this undermines the established investment in technology by security and operations teams.

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:

So it’s important to build effective and sympathetic culture change into a security

program which addresses these issues.


11

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

PLANNING AND MANAGING CHANGE

CULTURE CHANGEThe 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.


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


13

Carrots vs sticksPolicies and rules can be enforced to ensure prescribed patterns are followed, or a voluntary program can be adopted that encourages change with promised rewards. A combination of the two is highly effective; allowing some developers to trail-blaze and lead the way, while others are swept along by the mandatory changes.

GamificationContrary to popular belief, security can be made fun! Turning the adoption of security processes or knowledge into a game can be really effective. To generate enthusiasm and get results quickly, consider competitions challenging teams to write the most secure code or be the first to adopt practices.

Security educationConvincing developers of the importance of security is challenging, but massively beneficial. Security education is far more effective than creating time-intensive rules which may stifle independent thought. Budgetary and time constraints rarely allow all developers to be fully trained in security, but elements of training can help them appreciate the problem and recognize when they need support.

Tying to objectivesTying the results of games or rewarded 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.

Security championsIdentify the developers with an interest and aptitude for security and invest in training them. This allows them to carry out specific security tasks and help support other team members. A network of security champions is also an effective gateway between established security functions and development teams.

Social interaction Involving the security and development teams in shared social events and presentations can build bridges. This should help both teams to understand the constraints the other is facing, as well as providing informal routes for requesting advice or reporting issues.

Software security teamThis can be a great mechanism for empowering developers. It’s important the team includes application security experts from operations and security teams, but can also involve external experts. They act as the known point of escalation for security issues encountered by developers, if local champions cannot resolve them. It’s also responsible for sympathetically setting standards or practices, as developer members will have working knowledge of how security practices are best implemented.

KEY FACTORS FOR SUCCESSFUL CHANGE


14

CHALLENGES IN SECURING LEGACY CODEBASESAdding 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 systemsSupporting 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 consumersThe legacy application may need to support existing consumers of APIs or established functionality that could be insecure. Making changes might break backwards compatibility.

Tight couplingIn tightly coupled systems, changes to support security can have a major impact through many components of the system.

Lack of original design documentationWithout knowledge of the original design intent and the higher-level structure, identifying security issues and introducing structural changes could be difficult.

Out-of-date standardsThe 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 platformDepending on the nature of the application, it might run on a hardware or application server environment with undesirable characteristics.


15

POSSIBLE APPROACHES WITH LEGACY SYSTEMS

• 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.

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:

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.


16

TRANSITION TO SOFTWARE SECURITYA 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:

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.

• Experience

• Product

• Tooling

• Legacy

• Infrastructure

• Geography

• Culture


17

MEASUREMENT

• 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.

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:

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.


18

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.

TECHNOLOGY AND TOOLING


19

EARLY PHASES - INITIATION, REQUIREMENTS AND DESIGN ACTIVITIES

Early in the lifecycle, tooling can support

threat modelling. It captures threats the team

identifies in terms of new system requirements

or by using formulaic mechanisms in specialist

toolsets to evaluate all potential vectors.

Where possible, it’s preferable to use

existing tooling for requirement capture

and refinement. Introducing new systems

to handle a specialist security task can

make security tasks seem to be an external

activity. The true value is in developing

critical security thinking within the teams.

DURING IMPLEMENTATION

Static analysis (also known as SAST) is a widely

used quality and security tooling mechanism. It

allows a tool to detect poor patterns in source

code, which might lead to quality or security

defects. Static analysis is most valuable during

the actual implementation phase, providing

feedback to the developers as code is produced.

Depending on the product, these evaluations

are made in a number of ways, with a varying

focus on how the issues should be resolved –

either by the developers or the security team.

If the latter, it’s crucial the security team is

open and responsive to the developers.

The term static analysis has a wide range of

meanings. It could be as simple as automated

checking of stylistic issues, such as the use of

tabs or spaces or variable naming conventions.

Or it might be able to detect non-sanitized data

or inconsistencies in the way certain routines are

called that could suggest underlying defects.

As modern applications are assembled from

developed code and third-party open-source

packages and frameworks, the development

team must ensure vulnerable components

haven’t been incorporated. A category of

tooling that automates this checking is

known as software composition analysis. It

can also provide guidance on restrictions

governing the software license use.

DURING TESTING

Dynamic analysis (also known as DAST) is a way

to test code that’s running, typically by providing

unusual input. This means this type of tooling can

only detect issues later in the development cycle

when the code can be run.

Dynamic analysis is complementary to static

analysis as it typically highlights different issues.

Enterprise-grade security tooling for commercial

applications typically has a significant cost,

reflecting the R&D in its production.

As with many other forms of software testing,

there are steps that can be taken in the CI/CD

pipeline by applying large numbers of simple

rules to check for issues. Starting points for

this approach can be as straightforward as

using command-line tools to search for the use

of insecure functions. Free and open-source

frameworks exist to assist the implementation of

this type of testing, but much of the test content

has to be developed by the team.

When adopting static and dynamic application

security tooling, it’s important to ‘tune’ the

tooling to minimize false positives, which

waste the team’s time and can cause loss of

trust in the tool. Effective tuning generally

requires significant time, effort, and a broad

understanding of secure coding topics.


20

TOOLING IN VARIOUS PHASES

EARLY PHASES (REQUIREMENTS AND DESIGN)

• Threat modeling tools

IMPLEMENTATION

• Static analysis

TESTING

• Vulnerability scanning tools

• Dynamic analysis

• Software composition analysis

• Domain-specific testing tools

DEPLOYMENT

OPERATION

CONTINUOUS INTEGRATION PIPELINES

Continuous integration pipelines are incredibly

useful places to run a number of verifiers that can

perform analysis against code, including many of

the systems discussed above. Tests can be added

directly at this point, alongside other testing

suites looking explicitly for security issues.

If security professionals have previously tested

the code, it might be possible to represent

their findings in scripts to prevent inadvertent

regressions. This is the same way a disciplined

test engineering regime will prevent quality

regressions.

SPECIFIC SECURITY TESTING

For narrow, well-defined interfaces such as web

services, APIs, or file parsing, a technique called

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.

VULNERABILITY SCANNING TOOLS

Using vulnerability scanning tools on deployed

systems and applications will reduce the risk from

deploying out-of-date or misconfigured systems.

It doesn’t typically analyze the developed

application to any great extent but might identify

generic issues.

These tools are generally used throughout an

operational lifetime to make sure the application

servers and infrastructure remain current in

terms of patching, etc. A development team

can also utilize this tooling as part of a testing

and deployment chain so they’re not promoting

known vulnerable application servers to a

live environment. They have the ability to run

more in-depth analysis than is possible in a live

environment, where availability could be affected.


21

QUICK WINSROLLING 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 SOFTWARE SECURITY TEAM

Ideally the team will be formed of enthusiastic

people from different teams. Together, they’ll

be responsible for deciding and enforcing

appropriate security standards, acting as a

set of expert reviewers, and deep technical

investigators.

AWARENESS TRAINING OF KEY PERSONNEL

he level of awareness and particular skills required

will vary from one team member to the next,

depending on their department and experience.

The appropriate awareness training might

therefore focus on formal training, CBT, book

learning, or internal workshops.

THREAT MODELING UNDERTAKEN AS A PROCESS

Threat modeling can begin with an existing

artifact used to engage everyone from business

stakeholders down to development team

members. It also brings a consideration of

security into the design phase.

ADDING SECURITY INTO REQUIREMENTS

Making sure security issues have equal billing

with usability or performance helps give the

development team a mandate to solve security

problems.

USING AST TOOLING

Software solutions, such as static and dynamic

analysis, can be used to scan either source code

or built applications. This helps to spot potential

security and quality problems earlier in the build

lifecycle. There are additional costs and potential

complexities with deploying new tooling, but

even a trial of a commercial tool could give

an indication of the quality of the developed

application. However, AST tooling will not detect

all implementation mistakes and even fewer

design mistakes.

GAMIFYING THE TESTING

In organizations with an adversarial developer/

tester dynamic, it can help to train existing test

specialists to spot security issues. This, in turn,

challenges developers and designers to write

correct code that ‘beats’ the empowered test-

engineering function.

ACQUIRING TOP-LEVEL SANCTION

Even if the move towards secure software begins

at a technical level, an awareness from the top of

the business will help to spread the message and

increase acceptance. It also helps to break down

barriers within the traditional functional areas.


22

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!

ANALYSIS


SECURITY COMES AS STANDARD · 2020-03-17 · DevOps sees virtualization, cloud technologies, and...

Documents

Transcript of SECURITY COMES AS STANDARD · 2020-03-17 · DevOps sees virtualization, cloud technologies, and...