Executivesummary

From code
to customer:
The roadto making ourproducts secure
Learn more on kaspersky.com#bringonthefutureAs the world becomes more and more interconnected, global reliance on safe, trustworthy technology
intensifies and the security of products themselves becomes increasingly important. The evolution ofsecurity products takes place in parallel with the growth of the vulnerabilities research industry, and as thethreat landscape develops, the structure and nature of our products become more complex too.
Software development is a multifaceted process, with many stages in the road from code to customer.
Unlike most other software, security products consist of numerous components, some deeply integrated
into the OS and this makes solving security issues even more important – not doing so could take an entire
system down.
One of the biggest challenges in software development is avoiding what developers refer to as ‘whack-amole’, an ongoing situation where the same problems keep reoccurring, again and again. This is inefficient –and dangerous.
When the architecture of software components is done right, this situation can be avoided. And combinedwith a collaborative software development lifecycle that puts security front and center of every
single step in the development process, it’s even safer. This is what Kaspersky does – we’ve adopted
a fundamental, strategic approach involving cross-team collaboration, diverse internal and external
information sources and ongoing education.
We’ve refined the entire process and the result is hands-down the best way to embed safety into ourproducts – and deliver the same to our customers. Continue reading to find out how we do this.

From code to customer:
The road to making our products secure
We at Kaspersky take our role as a leading security vendor seriously. In the process of developing ourproducts, we are guided every step of the way by the core principles that make them secure. Unlike othersoftware, security products consist of many components, some integrated deeply into the OS, which iswhy solving security issues in our products is so important.
It’s been over two decades since we developed our first antivirus solution, and over this time we’ve gainedunique, first-hand experience in how to respond quickly and effectively to the new and evolving challengesof the cybersecurity industry. The evolution of security products – as well as other software – occurs
in parallel with the growth of the vulnerabilities research industry. As the threat landscape continues todevelop, the structure and nature of our products become more complex, with enhancements and newfeatures in every release.
We understand the direct link between making a product more complex and the number of potential
vulnerabilities to be found in it. Our specialist product teams and our entire development process are
geared towards ensuring that our software engineering processes are as safe as possible. Building thehighest levels of security into our products is at the heart of what we do.

It’s all in the foundation
When the architecture of software components is done right, a‘whack-a-mole’ scenario – where problems keep recurring – canbe avoided, and the same applies to fixing vulnerabilities. Ourproduct teams work closely with our product security team toensure that our architecture is secure.

Vulnerability Response

This approach has allowed us to avoid the problems highlightedby Google ‘Security Princess’ Parisa Tabriz in her keynote atBlack Hat USA 2018. In her address, Tabriz discussed an issue
that all developers are familiar with – the frustration of receiving
reports about security vulnerabilities that have been previously
fixed, or are a trivial variant of a known bug or even a symptom ofan underlying condition or process failing that was known about
but wasn’t addressed.

Security Risk Assessments

Planning

MaintenanceRequirements

Product
Security

PentestWhack-A-Mole
Elimination

Analysis,
DesignTestingFuzzing

Security Requirements

Development

Attack Surface Analysis

Securing the development process. The first three steps in particular – planning, requirements and analysis and design –help to avoid a ‘whack a mole’ situation.

At Kaspersky, this is where the Secure Development Lifecycle
comes in, an approach which involves making security a priority
during the development process of a product. Eliminating thelikelihood of a ‘whack-a-mole’ scenario during architecturedevelopment not only eradicates ongoing problems withthe same vulnerabilities, it also frees up resources that canbe redeployed to work on developing other products andmaintaining already released products. The net result is secure
product architecture that has numerous advantages, including:

Our product security team is the entry point for R&D for
all issues relating to the security risks of products andinfrastructure. The team is responsible for a number of criticaltasks, including preparing the initial requirements, code auditing,vulnerabilities response, risks analysis, vulnerabilities assessment,
providing mitigations, fuzzing processes integration, penetration
testing, and more. Our Anti-Malware Research Team (AMR) also
provides crucial input during these steps.

• Minimizes vulnerabilities that can lead to serious architecturechanges at core components during the maintenance step ofdevelopment• Frees-up resources during maintenance• Reduces the amount of security updates necessary.

Product Team 1

Product Team 1

Product Team 1

Security Champion

Security Champion

Security Champion

Product Security
How the product and product security teams interact. The security champion is an additional layer that ensures thatinformation from product security is correctly applied.

Sources of vulnerability information
Even after the product team has invested significant time andeffort into writing software according to security standards, anattacker can find a weak spot inside the product or its environment (OS), which can be compromised. For this reason, we use
diverse sources of information about vulnerabilities to optimize
our product security.

We recognize various sources of information for security risks andvulnerabilities: Publicly disclosed vulnerabilities in an OS that may
be affecting our products in some way, vulnerabilities inthird-party libraries or software which we use in our products,
public vulnerabilities reports from researchers, reports from ourBug Bounty program portal, reports which hackers send to ourvulnerabilities mailbox (vulnerabilities@kaspersky.com), reports
which researchers submit to our online form and privately
reported vulnerabilities from our security researchers, architects
and penetration testers.

Vulnerability in OS that
affects a product

Vulnerability in 3rd party
that affects a productPublic vulnerability
into a product

Vulnerability report fromHackerOne

Vulnerability report fromvulnerabilities@kaspersky.com

Vulnerability report fromat website

Product Security

Product TeamPrivate vulnerability reportinside the company

Product TeamThe different sources of vulnerabilities intelligence that Kaspersky receives

Publicly disclosed unpatched vulnerabilities in ourproducts are critical because by their nature, attackers canuse them to attack our customers. Depending on the CVSS
(Common Vulnerability Scoring System) score and the potential
impact level on customers, fixing these vulnerabilities is our toppriority. Fixing publicly disclosed vulnerabilities into operating
systems and third-party software that affect our products isalso a high-priority scenario.
The HackerOne vulnerabilities reporting platform gives
us a flexible and regulated way of accepting reports fromresearchers. The platform’s workflow for vulnerabilities reports
processing begins from triage and includes compensating ‘bug

bounty’ to researchers and addressing around the disclosure ofsensitive information about a particular vulnerability. (A hacker
can request complete or partial information disclosure about avulnerability after its fixed and the fix has been released to thepublic.)
Some vulnerability reporters prefer to submit their discoveries
directly to us via our dedicated vulnerability reporting
mailbox at vulnerabilities@kaspersky.com. We recommend
using encryption to submit this sensitive information using ourpublic PGP key, a common practice in the industry to secure thistype of process.

Sources of vulnerability reporting

Responding to reports
Responding to vulnerabilities reports is a separate processwith a special workflow. The response process starts when we
receive information about a potential vulnerability that may
affect our products. Sometimes, we receive a report that’s
supposedly about a vulnerability in one of our products but isin fact a vulnerability or weak spot inside an OS. In such cases,
we also provided an update to mitigate this situation.

Kaspersky involvement with the Bug Bounty program at
HackerOne is in response to the evolving challenges ofthe security industry. Of course, we have our own highly
specialized security researchers and architects in-house,
but we also recognize that external, independent security
researchers can bring their own points of view and thinking to
the process, and by letting these external researchers pentest
our products, it makes them even stronger and more secure.

We also believe that paying hackers to report vulnerabilities
is right as well as smart – not doing so may see them being
tempted to sell their information to cybercriminals instead.
Their qualified reports must fulfil stringent guidelines,including a detailed explanation of the vulnerability they’rereporting together with technical details and an example of areliable working exploit or proof of concept.

• User mode (Ring 3) is where the antivirus service and GUI
processes execute – the antivirus service is a high priority
process, while GUI is low priority.
• Antivirus drivers execute into Kernel mode (Ring 0) andobtain access to the Windows kernel and all processesin VM (virtual memory). This kind of exploitation is highly
dangerous because Ring 0 has the most privileges and a

Reportsubmitting

BountypayoutReportconfirmation

A patchreleasingResponse toresearcher

Vulnerability
assessment
Vulnerability processing workflow in a bug bounty scenario

The scope of our Bug Bounty program currently includes
Kaspersky Internet Security 2019 Beta and Kaspersky Endpoint
Security 11. Vulnerability exploitations should apply to Windows
8.1+, and we compensate researchers for discovering Remote
Code Execution (RCE) vulnerabilities, Local Privilege Escalation(LPE) and Information Disclosure (ID) – the latter being
limited to sensitive user data like passwords, payment data
and authentication tokens. For a detailed report and working
exploit example of the <<unicorn>> vulnerability, which allows
an attacker to remotely execute malicious code inside ourhigh-privilege process using the ‘man-in-the-middle’ vector, thepay-out can be as high as $100k.

successful exploitation here can lead to the entire systembeing compromised.
• Some antivirus products contain special componentsthat work at the hypervisor level (known as Ring -1). These
components control cross-VM (virtual memory) operations
and provide protection from screenshotting. Exploiting avulnerability at this level compromises virtual machines andcan also bypass built-in security measures (such as Device
Guard and Credential Guard).

Ring 3(low privileges)

Ring 3(highprivileges)

Ring 0Ring -1

AV bypass
Information Disclosure (ID)
Local Privilege Escalation (LPE)(Escalation of Privilege)
Remote Code Execution (RCE) vulnerabilities

Types of vulnerabilities found in antivirus products. Attackers use ‘AV bypass’ to circumvent major parts of a product’s protection.
The darker the cube, the more serious the level of danger

Never stop learning
As we continue to integrate secure practices into our softwaredevelopment lifecycle, we also encourage our developers andarchitects to learn about them. We combine our knowledge ofsecure development from our existing R&D experience with

How to use
code analysis

Importance ofvulnerability fixing

Importance ofcryptography

insights from our product security team who continuously
update their knowledge and skills with new and emerging
practices. The result is the implementation of the following major
vectors into our product security training:

Introduction toapp security

Secure coding
practiceThreatmodeling

Security training for developers, engineers
and architects

This approach is highly beneficial to our developers and tothe company as a whole – please refer to the image below for
more information. It not only encourages developers to think

about different areas of computer security that they may nototherwise consider and it also helps reduce the total cost of
software maintenance and boosts our reputation.
Advantages

Сode analysis• Lower expenses for security
updates issue• Freeng human resources forproducts support• Improving the reputation of thecompany• Improving developer’s skills

Secure coding

СryptoThreat modeling

Advantages of ongoing developer training

Putting security front and center of everything we do
The process of creating secure software isn’t easy, especiallywhen it comes to complex products and solutions. To deliver
optimum security levels, security should be front and centerof every stage in the software development and maintenanceprocess, including writing security requirements, risks
assessments, attack surface analysis, fuzzing, pentesting,vulnerability response and developer education. And atKaspersky, this is exactly what we do. The result? The world’s
most tested, most awarded security.

www.kaspersky.com

2021 AO KASPERSKY LAB. REGISTERED TRADEMARKS AND SERVICE MARKS ARE THE PROPERTY OF THEIR RESPECTIVE OWNERS.

Cyber Threats News: www.securelist.com
IT Security News: business.kaspersky.com