Executive

summary From code

to customer:
The road
to making our
products 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 of
security products takes place in parallel with the growth of the vulnerabilities research industry, and as the
threat 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-a-
mole’, 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 combined
with 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 our
products – 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 our
products, we are guided every step of the way by the core principles that make them secure. Unlike other
software, security products consist of many components, some integrated deeply into the OS, which is
why 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 gained
unique, first-hand experience in how to respond quickly and effectively to the new and evolving challenges
of 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 to
develop, the structure and nature of our products become more complex, with enhancements and new
features 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 the
highest 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 This approach has allowed us to avoid the problems highlighted
‘whack-a-mole’ scenario – where problems keep recurring – can by Google ‘Security Princess’ Parisa Tabriz in her keynote at
be avoided, and the same applies to fixing vulnerabilities. Our Black Hat USA 2018. In her address, Tabriz discussed an issue
product teams work closely with our product security team to that all developers are familiar with – the frustration of receiving
ensure that our architecture is secure. reports about security vulnerabilities that have been previously
fixed, or are a trivial variant of a known bug or even a symptom of
an underlying condition or process failing that was known about
but wasn’t addressed.

Vulnerability Response Security Risk Assessments

Planning

Maintenance Requirements

Pentest Product Security Requirements Whack-A-Mole

Security Elimination

Analysis,
Testing
Design

Development
Fuzzing 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 Our product security team is the entry point for R&D for
comes in, an approach which involves making security a priority all issues relating to the security risks of products and
during the development process of a product. Eliminating the infrastructure. The team is responsible for a number of critical
likelihood of a ‘whack-a-mole’ scenario during architecture tasks, including preparing the initial requirements, code auditing,
development not only eradicates ongoing problems with vulnerabilities response, risks analysis, vulnerabilities assessment,
the same vulnerabilities, it also frees up resources that can providing mitigations, fuzzing processes integration, penetration
be redeployed to work on developing other products and testing, and more. Our Anti-Malware Research Team (AMR) also
maintaining already released products. The net result is secure provides crucial input during these steps.
product architecture that has numerous advantages, including:

• Minimizes vulnerabilities that can lead to serious architecture

changes at core components during the maintenance step of
development
• 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 that
information from product security is correctly applied.

Sources of vulnerability information

Even after the product team has invested significant time and We recognize various sources of information for security risks and
effort into writing software according to security standards, an vulnerabilities: Publicly disclosed vulnerabilities in an OS that may
attacker can find a weak spot inside the product or its environ- be affecting our products in some way, vulnerabilities in
ment (OS), which can be compromised. For this reason, we use third-party libraries or software which we use in our products,
diverse sources of information about vulnerabilities to optimize public vulnerabilities reports from researchers, reports from our
our product security. Bug Bounty program portal, reports which hackers send to our
vulnerabilities mailbox (vulnerabilities@kaspersky.com), reports
which researchers submit to our online form and privately
reported vulnerabilities from our security researchers, architects
and penetration testers.

Product Team

Vulnerability in OS that Vulnerability in 3rd party

affects a product that affects a product
Product Security

Public vulnerability Vulnerability report from Private vulnerability report

into a product HackerOne inside the company

Vulnerability report from Vulnerability report from

vulnerabilities@kaspersky.com at website

Product Team

The different sources of vulnerabilities intelligence that Kaspersky receives

Publicly disclosed unpatched vulnerabilities in our bounty’ to researchers and addressing around the disclosure of
products are critical because by their nature, attackers can sensitive information about a particular vulnerability. (A hacker
use them to attack our customers. Depending on the CVSS can request complete or partial information disclosure about a
(Common Vulnerability Scoring System) score and the potential vulnerability after its fixed and the fix has been released to the
impact level on customers, fixing these vulnerabilities is our top public.)
priority. Fixing publicly disclosed vulnerabilities into operating
systems and third-party software that affect our products is Some vulnerability reporters prefer to submit their discoveries
also a high-priority scenario. directly to us via our dedicated vulnerability reporting
mailbox at vulnerabilities@kaspersky.com. We recommend
The HackerOne vulnerabilities reporting platform gives using encryption to submit this sensitive information using our
us a flexible and regulated way of accepting reports from public PGP key, a common practice in the industry to secure this
researchers. The platform’s workflow for vulnerabilities reports type of process.
processing begins from triage and includes compensating ‘bug

Sources of vulnerability reporting

Responding to reports
Responding to vulnerabilities reports is a separate process Kaspersky involvement with the Bug Bounty program at
with a special workflow. The response process starts when we HackerOne is in response to the evolving challenges of
receive information about a potential vulnerability that may the security industry. Of course, we have our own highly
affect our products. Sometimes, we receive a report that’s specialized security researchers and architects in-house,
supposedly about a vulnerability in one of our products but is but we also recognize that external, independent security
in fact a vulnerability or weak spot inside an OS. In such cases, researchers can bring their own points of view and thinking to
we also provided an update to mitigate this situation. 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 • User mode (Ring 3) is where the antivirus service and GUI
is right as well as smart – not doing so may see them being processes execute – the antivirus service is a high priority
tempted to sell their information to cybercriminals instead. process, while GUI is low priority.
Their qualified reports must fulfil stringent guidelines, • Antivirus drivers execute into Kernel mode (Ring 0) and
including a detailed explanation of the vulnerability they’re obtain access to the Windows kernel and all processes
reporting together with technical details and an example of a in VM (virtual memory). This kind of exploitation is highly
reliable working exploit or proof of concept. dangerous because Ring 0 has the most privileges and a

Report
submitting

Bounty Report
payout confirmation

A patch Response to
releasing researcher

Vulnerability
assessment

Vulnerability processing workflow in a bug bounty scenario

The scope of our Bug Bounty program currently includes successful exploitation here can lead to the entire system
Kaspersky Internet Security 2019 Beta and Kaspersky Endpoint being compromised.
Security 11. Vulnerability exploitations should apply to Windows • Some antivirus products contain special components
8.1+, and we compensate researchers for discovering Remote that work at the hypervisor level (known as Ring -1). These
Code Execution (RCE) vulnerabilities, Local Privilege Escalation components control cross-VM (virtual memory) operations
(LPE) and Information Disclosure (ID) – the latter being and provide protection from screenshotting. Exploiting a
limited to sensitive user data like passwords, payment data vulnerability at this level compromises virtual machines and
and authentication tokens. For a detailed report and working can also bypass built-in security measures (such as Device
exploit example of the <<unicorn>> vulnerability, which allows Guard and Credential Guard).
an attacker to remotely execute malicious code inside our
high-privilege process using the ‘man-in-the-middle’ vector, the
pay-out can be as high as $100k.

Ring 3
Ring 3 (high Ring 0 Ring -1
(low privileges) privileges)

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 software insights from our product security team who continuously
development lifecycle, we also encourage our developers and update their knowledge and skills with new and emerging
architects to learn about them. We combine our knowledge of practices. The result is the implementation of the following major
secure development from our existing R&D experience with vectors into our product security training:

How to use Introduction to

code analysis app security

Importance of Secure coding

vulnerability fixing practice

Importance of Threat
cryptography modeling

Security training for developers, engineers

and architects

This approach is highly beneficial to our developers and to about different areas of computer security that they may not
the company as a whole – please refer to the image below for otherwise consider and it also helps reduce the total cost of
more information. It not only encourages developers to think software maintenance and boosts our reputation.

Advantages
Сode analysis
• Lower expenses for security
updates issue
• Freeng human resources for
Secure coding products support
• Improving the reputation of the
company
• Improving developer’s skills
Сrypto

Threat modeling

Advantages of ongoing developer training

Putting security front and center of everything we do

The process of creating secure software isn’t easy, especially process, including writing security requirements, risks
when it comes to complex products and solutions. To deliver assessments, attack surface analysis, fuzzing, pentesting,
optimum security levels, security should be front and center vulnerability response and developer education. And at
of every stage in the software development and maintenance Kaspersky, this is exactly what we do. The result? The world’s
most tested, most awarded security.
 www.kaspersky.com
Cyber Threats News: www.securelist.com
IT Security News: business.kaspersky.com
2021 AO KASPERSKY LAB. REGISTERED TRADEMARKS AND SERVICE MARKS ARE THE PROPERTY OF THEIR RESPECTIVE OWNERS.