EY Cybersecurity ReportDanish Chapter

May 2020

Executive summaryIn the recent years, many organizations have adopted development-operations (commonly known as dev.ops) model for their daily IT development. However, organizations must put greater emphasis on cybersecurity interests within the dev.ops process. Therefore, secure development (sec.dev.ops) is a commonly used term and strategy these days, recognizing that security and development go hand in hand and cannot be looked at separately.

In any development process — IT or non-IT — it is important to ensure the involvement of the security function, i.e., the cybersecurity professionals and practitioners, as they need to consider dev.ops in a security and/or cybersecurity context. A combined effort of developers and security professionals will result in greater and more secure development of any IT-related product and give insights into the purpose of the respective team’s work incentive.

For many organizations within the cyber arena, the National Institute for Science and Technology (NIST) framework provides a strong guideline for effectively tackling cybersecurity concerns. The key stages of this framework are:

• Identify

• Prevent

• Detect

• Respond to cyberattacks

A combination of developers and security professionals will result in greater and more secure development of any IT-related product and

give insights into each other’s purpose of work incentive. The NIST framework can not only work as a great guideline in the development life cycle but also help in understanding the importance of a secure development life cycle and increasing the knowledge of the steps in a security mindset.

Finally, various security breaches can be prevented with secure dev.ops, by restricting malicious actors from taking advantage of poor security design resulting from the development, delivery and deployment processes.

This technique was used in the case of Equifax where once the attackers breached the data security, they were able to compromise more than 30 servers. This enabled the attackers to access personally identifiable information (PII) of more than 140 million consumers, including social security numbers, drivers’ license records and date of birth, among others. Attackers scanned the web for vulnerable systems where the server without critical patches became the target. The attackers then identified the weak dispute resolution servers. From there, the attackers could locate additional targets.

Cybersecurity often comes with a retrospective approach seeking an already designed mechanism, forcing the security function to be reactive. However, involving the security function from the beginning of the security process will be a proactive approach that will help the organization stay ahead of attackers.

2 EY Cybersecurity Report

Adam Sandenholt Executive Director Cybersecurity Team Ernst & Young P/S

3EY Cybersecurity Report

Introduction

Dev.ops combines software development with information technology/information systems (IT/IS) operations with the aim to condense the process of software development, yet also provide the continuous delivery of software. In the 2019–20 world quality report from Micro Focus (among others), it has been found that 99% of the surveyed firms across the world have implemented dev.ops to some extent.1 Thus, cybersecurity practitioners must place cybersecurity goals and interests at the core of the dev.ops process. Likewise, the world quality report also highlights the multiple security challenges that arise from dev.ops.

Succeeding the previous paradigm of agile development and the waterfall development model, dev.ops has been rapidly implemented in a myriad of firms, which are increasingly reaping the benefits of the previously segmented development and operation efforts. A significant reason behind this is the adoption of Software-as-a-Service (SaaS) products. IT professionals can update applications and databases frequently in case of SaaS, as it largely does not require the end users to download or acquire new components — these can be browser-based applications.

Evidently, these dev.ops methodologies have impacted both far-flung applications and business-critical resources alike. Consequently, it becomes imperative to ensure the vitality of such applications, where cybersecurity professionals and practitioners need to consider dev.ops in a cybersecurity context. In many firms and organizations, dev.ops is manifested in a continuous integration — continuous delivery — continuous deployment development architecture, commonly abbreviated as CI-CD. Ultimately, dev.ops and CI-CD allows for a process of continuous (1) planning, (2) coding, (3) building, (4) testing, (5) releasing, (6) deploying, (7) operating and (8) monitoring of software — this can be identified within figure A1 (dev.ops stages). With dev.ops, a single dev.ops team will own the entire process. However, with the accelerated development

and deployment of software, firms and organizations tend to focus on building functionalities and features first, while worrying about the security aspects at a later stage. This has led to grave vulnerabilities, security flaws and an unforeseen downtime for potentially critical resources in the production environment. Within the dev.ops cycle, then cybersecurity tends to be only considered during (6) deployment, (7) operations and (8) monitoring stages. However, with the advent of secure dev.ops, cybersecurity is to be considered during all stages of the dev.ops cycle. A common understanding and alignment between security and development, back-end and the business needs is vital for any successfully sec.dev.ops process to ensure mutual adjustment and secure design from the starting point. This also ensures proper ownership from all the collaborating parties — enabling business needs are prioritized, secure and developed and thought through from end to end.

Test

Monito

r

BuildDeploy

Release

DevelopCode

Plan

Dev

Ops

Securely operation dev.ops

1 https//www.microfocus.com/en-us/marketing/world-quality-report-2019-20

4 EY Cybersecurity Report

Theme of the month: dev.ops and secure dev.ops

Within the CI-CD pipeline of dev.ops, the continuous integration (CI) refers to how developers can assimilate (or push) their new resources, code or libraries into a common repository. This is in contrast from the earlier method of developing each feature in isolation before submitting each of them during the conclusion of a development cycle. Instead, with CI, developers can promote components to a common repository multiple times on a given day. This has inherent benefits; for instance, developers can continuously test, modify and adapt their work with a common up-to-date repository, thus creating continuous integration. Likewise, developers can also identify defects, system inconsistencies and other issues at a much earlier stage, thus considerably reducing development efforts. Therefore, CI is much more contingent for frequent iterative builds and constant adaptations that are undertaken to tackle defects and issues at an early stage. To achieve this, CI builds its foundation on tools such as source control version management to identify and communicate the conflicts that emerge when multiple developers work on the same codebase, build automation tools to aid in compiling or packing into binary code and set up sound organizational processes around CI principles.

Nevertheless, within CI, secure dev.ops along with the dev.ops team can integrate security into the pipeline of development by considering security goals, security gates and security architecture into CI requirements, user stories or epics. Likewise, threat modelling can be performed to actively identify objectives and vulnerabilities before exerting efforts to counteract and mitigate such threats. Likewise, secure code-scanning tools can be implemented in the CI pipeline to proactively identify security vulnerabilities, while license scanning tools can ensure compliance with third-

party software vendors. The cybersecurity benefits are immense, much in line with how CI enables developers to identify and fix issues early on to reduce development costs. These cybersecurity efforts in CI can enable the organization to consider cybersecurity at an early stage to prevent possible vulnerabilities entering the production environment. As a result, these combined efforts in CI can implement security in the dev.ops stages such as (1) planning, (2) coding and (3) building. Why has sec.dev.ops become an independent title in developing IT, applications or other digital business enabling products? For decades, developing IT has had its own leg in the organization, not directly interacting with security. Security was seen as the “gate keeper” for any new business digital initiatives with little value-add. However, recent studies show security outlook in the software development from the beginning. This not only mitigates any design vulnerability flaws but also ensures stability in its operations when put into production.

Within dev.ops, continuous delivery (CD) extends CI. CD refers to the process of promoting CI builds into the production environment. If implemented correctly, CD can enable the given codebase to be instantly deployable, which implies that software releases can be executed as if it were a routine task. To achieve this, CD depends on effective yet sound testing. Consequently, CD truly depends on processes whereby software can be appropriately tested, leveraging as much automation as the situation allows. Cybersecurity practitioners and professionals can extend the CD pipeline to include penetration testing, security testing and further vulnerabilities assessment. Subsequently, one can implement security principles in the dev.ops stages (4) testing and (5) releasing.

5EY Cybersecurity Report

Following continuous delivery, dev.ops’ continuous deployment will seek to deploy the tested and delivered software. Continuous deployment will thus automatically deploy the delivered software without an actual person acting as a gatekeeper. This allows for features, functionalities and fixes to reach end users quickly. Issues that might arise can then quickly be escalated into the development effort — thus enabling a seamless transition between the development of software and the operations of IT/IS. In secure dev.ops, production penetration testing is to be performed. Then, security considerations are implemented in the deployment stage.

Within cybersecurity, the NIST framework has gained significant recognition in the immediate past. This framework intends to be a guideline on how organizations can effectively prevent, detect and respond to cyberattacks. This is similar to the traditional cybersecurity preventive, detective and corrective actions. With the advent of secure dev.ops, organizations and firms can increase their preventive efforts against any type of cybersecurity threats. When including the security aspect in the dev.ops process, the NIST framework also supports a rapid detection a possible breach or attack that has occurred or could occur.

Still, transitioning from dev.ops to secure dev.ops is not merely about the procurement of new tools or implementation of controls and new processes. On the contrary, deploying these security initiatives without human considerations can be detrimental to the performance and motivation of the dev.ops teams. Instead, secure dev.ops requires a fundamental change of the entire development effort, including a cultural shift, a change in software design philosophy and solid management support. However, when implemented appropriately, secure dev.ops can greatly enhance the cybersecurity capabilities of an organization, as security considerations will be represented in all areas of software design, architecture, development and operations. This will inherently lead to security becoming an integral part of the software delivery, leading to a considerably reduced number of vulnerabilities and consequently a reduced exposure to security incidents such as costly data breaches, costly system incapacitations or debilitating application processing inconsistencies.

6 EY Cybersecurity Report

Dev.ops in a NIST context

NIST highlights five essential efforts for cybersecurity in which firms and organizations are to partake. It begins with NIST’s cybersecurity framework for critical infrastructure and then stresses on how organizations should use a five-pronged approach to cybersecurity — (1) identify, (2) protect, (3) detect, (4) respond and (5) recover.

• Identify: Secure dev.ops can implement tools, protocols and processes to identify security weaknesses and vulnerabilities as early in the development stage as possible. For instance, by designing and integrating security considerations in the forefront continuous integration pipeline, code and software architecture can be designed around security. Applying the NIST framework as part of the sec.dev.cycle will enable developers to systematically take the framework into account when designing IT products and use the identify stage for understanding what possible vulnerabilities the product has or could have if the security measures are not taken into account when building it.

• Protect: By implementing secure code scanning within the CI phase of the CI-CD pipeline, secure dev.ops can provide greater confidence that the cybersecurity hygiene is intact.

• Detect: In the phase of continuous delivery, cybersecurity practitioners and professionals can implement penetration testing in the later stages of CD. This security gateway is largely by contrast with many existing practices, where penetration

testing is conducted within the final production environment, whereby any cybersecurity remediations will be much costlier, as it implies unscheduled downtime, potential forensic activities and enhanced operating risks.

• Respond: By implementing various gateways in secure dev.ops, the security vulnerabilities and critical flaws can be intercepted as early as possible. Likewise, by detecting these cybersecurity threats early on, one will incur far less costs in remediating these threats.

• Recover: The breakdown of the traditional developments and operations in dev.ops means that any security vulnerabilities in the production environment can be fixed by the same team. Likewise, as the same dev.ops team owns the CI-CD pipeline, security flaws identified can quickly be reconciled.

Overall, secure dev.ops is a powerful all-round measure within cybersecurity. A key way is that secure dev.ops can identify and remediate vulnerabilities as early in the CI-CD pipeline as possible, thereby incepting potential security flaws as far from the final production environment as possible.

7EY Cybersecurity Report

2 https://hbr.org/2017/09/equifax-the-credit-reporting-industry-and-what-congress-should-do-next3 https//www.ftc.gov/news-events/press-releases/2017/03/ftc-releases-annual-summary-consumer-complaints

Numerous security breaches can be mitigated with secure dev.ops, where malicious parties leverage poor security hygiene during the development, delivery and deployment phases. Some common poor security hygiene include using default passwords on critical gatekeepers, using hardcoded security credentials within the production environment and using untested libraries to perform critical services. Once these have been released to the production environment, then the organization will inherently own the risk of these potentially unknown vulnerabilities.

Naturally, penetration and security testing performed by the organization or a third party can reveal such issues. However, these will be provided only after an attack or incident has already happened. This can lead to a data breach, unforeseen downtime or an alternation of critical databases. Ultimately, these can cause irrevocable reputation damages, permanent loss of business relationships, regulatory fines, regulatory scrutiny and costly litigation. All of these are evident from the 2017 data breach that took place at Equifax.

Equifax is an American credit reporting agency. In the 2017 breach of Equifax, attackers were able to compromise more than 30 servers in 20+ countries. This enabled the attackers to access personally identifiable information (PII) of more than 140 million consumers, some including social security numbers, drivers’ license records, date of birth, among others. Attackers have a great incentive to extract such information, as these can be used to commit identity theft.2 This information can be sold to identity theft perpetrators. In fact, in 2016, one year prior to the attack, the United States Federal Trade Commission (FTC) reported almost 400,000 cases of identity theft in 2016 alone. This cost the United States approximately $15.4 billion.3

Up till the data breach, Equifax used third-party software services, including Apache Struts. In the case of Equifax, a critical patch was released prior to the breach, yet Equifax failed to implement it. Attackers scan the web for vulnerable systems, where the server without critical patches can become a target. The attackers then identify the weak dispute resolution servers. From there, the attackers locate additional targets.

Equifax used unencrypted servers to store PII and exercised weak password protection of its servers, where “admin” admin was used as the username and password for sensitive data. Such lacking cybersecurity hygiene with long outstanding critical patches, unencrypted servers and weak credentials in the Equifax production environment meant that the exploit became relatively easy. These did indeed lead to costly litigations, as multiple class-action lawsuits have been filed against Equifax, harrowing reputational damages and a media storm.

Today, the web scanning tools used by Equifax’s attackers have become far more sophisticated and automated. These no longer merely seek the high-profile information assets, but instead information assets of any time. Secure dev.ops will mitigate the risk of weaknesses being promoted into the production environment for attackers to exploit. Contemporary attackers are increasingly organized, resourceful and widespread. For firms and organizations, security must thus be an integral part of information system delivery.

Equifax breach of 2017

8 EY Cybersecurity Report

Integrating security into the security pipeline involves multiple processes, as displayed in the image below.

Integrating security in the life cycleIntegration of security activities throughout the development life cycle helps enable timely, risk-based identification and remediation of security vulnerabilities.

Security goals integrated

in requirements

Security architecture risk analysis is

performed

Secure code scanning tools integrated to

proactively identify flaws

Design Integrate Test Deploy MaintainDevelop

Vulnerability assessment performed

Production penetration

testing performedContinuous monitoring

Advanced threat analytics

Change control implemented

Secure coding standards applied

Secure third-party open-source components selected

Risk assessment and profiles

Governance structure

Training and metrics

Implemented security xxxxxxxxx

Requirement

EY has long been operating a cybersecurity service to offer advisory and assurance related services to a myriad of firms, thereby helping mitigate the risks within information systems development, security designs and cybersecurity hygiene. Secure dev.ops is a proactive tool within cybersecurity, where EY has highlighted multiple aspects that can be integrated within dev.ops. These are (1) attack and penetration testing, (2) compliance requirement and continuous review, (3) assess secure software development process, (4) assess legal aspects and (5) develop or integrate security into existing systems development life cycle.

EY secure dev.ops framework and services

Attach and penetration testing

Simulate real attacks into the software to identify weaknesses and security flaws in the software. Pen testing can help organizations prioritize and solve critical issues in applications.

Compliance requirement and continuous review

Support ongoing development efforts in the planning, development and deployment to help ensure that privacy and security requirements are considered before the design of an application as well as throughout the development by having compliance check-points.Assess secure software development process

By assessing the existing security practices against EY methodologies and industry-leading secure development practices.

Source code reviews

Review of the software source code to identity security flaws in critical components. EY advises to conduct source code reviews for the critical components before releasing applications to production.

Assess legal aspects

Assess and support the organization in multiple areas such as tax, audit and fraud as well as law services. A thorough review of a wide range of legal aspects should be done through dedicated EY Law services.

Develop or integrate security into existing Systems Development Life Cycle (SDLC)

Integrate security into software development life cycle or help establish agile, waterfall or DevOps software development process with security and privacy leading practices into the SDLC using EY knowledge, compliance requirements and industry leading practices.

EY Proactive security services

9EY Cybersecurity Report

Based on our hands-on industry experience, EY identifies the theme in the context of our heatmap with two dimensions — the impact of an attack and the likelihood of an exploit. If an organization or firm exposes its information assets due to poor cybersecurity hygiene resulting from a weak dev.ops process, then it doesn’t take much resources from an attacker to exploit that weakness. With the advent of web scanners and dark web, the opportunity and probability to exploit such vulnerabilities is immense. Therefore, dev.ops scores high on the Capacity and intention to exploit axis.

Additionally, the impact of a potential attack can be great, whether the incident is caused by an outside attacker, an inside employee or merely a human error. Thus, dev.ops also scores high on the Impact of an attack axis.

In addition, Y scores each theme on a scale of risk severity with categories such as minor, moderate, severe or critical. Here, dev.ops can be considered to be under severe, as dev.ops has already won prevalence across industries.

Capa

city

and

inte

ntio

n to

exp

loit

Impact of an attack

Dev.ops

The state of dev.ops in 2020

EY severity categories

Level 1: Minor This category stands for a very low likelihood of exploit or impact of a potential attack. There is not any recognized capacity or intention to use the probable threat as an attack vector.

Level 2: Moderate This category refers to general threats with corresponding capacity and intention to cause harm to the firm or organization. Executive management needs to consider this topic in their cybersecurity effort.

Level 3: Severe This category constitutes a recognized threat, with both considerable capacity and intention to cause significant harm to the organization.

Level 4: Critical Firms and organizations must pay great care to the threat. This level is reserved for threats that form the cornerstones for any cybersecurity effort.

Authors and contacts

Adam Sandenholt Executive Director Cybersecurity team Tel: +45 2529 3379 Email: adam.sandenholt@dk.ey.com Ernst & Young P/S

Claus Thaudahl Hansen Partner Cybersecurity team Tel: +45 2529 3639 Email: claus.t.hansen@dk.ey.com Ernst & Young P/S

Jonathan Kwok Advisory Services Cybersecurity team Tel: +45 2529 4287 Email: jonathan.kwok@dk.ey.com Ernst & Young P/S

EY | Assurance | Tax | Transactions | Advisory

About EYEY is a global leader in assurance, tax, transaction and advisoryservices. The insights and quality services we deliver help build trust and confidence in the capital markets and in economies the world over. We develop outstanding leaders who team to deliver on our promises to all of our stakeholders. In so doing, we play a critical role in building a better working world for our people, for our clients and for our communities.

EY refers to the global organization, and may refer to one or more, of the member firms of Ernst & Young Global Limited, each of which is a separate legal entity. Ernst & Young Global Limited, a UK company limited by guarantee, does not provide services to clients. Information about how EY collects and uses personal data and a description of the rights individuals have under data protection legislation is available via ey.com/privacy. For more information about our organization, please visit ey.com.

EY member firms do not practice law where not permitted by local law and regulations.

© 2020 EYGM Limited. All Rights Reserved.

EYG no. 002987-20Gbl

ED None

This material has been prepared for general informational purposes only and is not intended to be relied upon as accounting, tax or other professional advice. Please refer to your advisors for specific advice.

ey.com