K8s security - Episode 4: Managing third parties

K8s security - Episode 4: Managing third parties Deploy • Emmanuelle Demompion • 09/03/21 • 7 min read

As you secured your Kubernetes cluster, you defined users, roles, and permissions, making it safer one restriction after the other. Along with user accesses, you also need to control what is being authorized by the services you did not create yourself, and that you depend on: third parties.

State of the art

Focus personae

While they are often left unnoticed and do not attract much attention, third parties are considered as top 10 security risks.

According to the latest studies, 76% of today's applications contain at least one security flaw, and more than 23% contain high severity flaws.

Flaw prevalence by median flaw density for CWE categories (source Veracode11)

CWE: Common Weakness Enumeration

Top 5 application vulnerabilities

When working in Information Technology, security issues are something we often don't want to deal with, mainly because we don't exactly understand what can happen and why.

Let's try to learn, understand, and briefly demystify the five more common security flaws that are found in today's software.

n°1 - Information Leakage ( CWE-200 )

When information is unintentionally available to end-users, this information can then be used to breach the security of an application. This information is not leaked during transfer on the network, but really openly accessible by anyone, even if it shouldn't.

It could expose information about the organization, the software's design, the deployment process, and much more. Such sensitive data can be credential information, configurations, database structure, authentication tokens, and much more.

n°2 - CRLF Injection ( CWE-93 )

When reading CRLF , developers automatically think of the characters Carriage Return and Line Feed ( \r\n ) used as an End Of Line ( EOL ) sequence, and it's exactly what this is about.

By injecting a CRLF sequence into an HTTP parameter or an URL for instance, an attacker could then inject a read method to the destination file, leading to content being written on screen, or logging modification.

n°3 - Cryptographic Issues ( CWE-310 )

Data confidentiality and integrity is key in today's businesses. This matter is addressed through encoding techniques, encryption, and hashing algorithms.

As we think we all encrypt our data and hash our critical keys, this category of security weaknesses remains in third position , meaning that it might not be addressed everywhere as it should be, or not in the right way; leading to data quality degradation or data corruption.

n°4 - Code Quality ( CWE-398 )

The 4th weakness is purely human , since it incriminates our own coding habits and the quality of our processes and deliveries. Obviously, these weaknesses are not meant to exist as their existence is not intentional, but it reveals a lack of rigour during the development or the maintenance phase of a software. To be honest, deadline rushes might also have their part of responsibility here.

If a code has a poor level of quality, it can obviously lead to unexpected behaviours, opening breaches into any software or application.

n°5 - Credential Management ( CWE-255 )

Credential management determines the scope of information users can access from an application. It's only logical that it represents one of the most common vulnerabilities that can be found in software development.

This weakness can regroup a lot of different issues such as:

unprotected storage

password storage

password in configuration files

weak password and weak password encoding

passwords and keys with no expiration dates or very long ones

bad password recovery strategy

unprotected transport of credentials

...and more

Even if credential management is known as a major issue and often addressed seriously by software companies and developers, they often rely on "on-the-shelf" solution. Developers put their trust into the default behaviours of such software, without really digging into the details of its operation and the options that may be available.

Fortunately, today that might be one of the simplest weakness to address.

Other security weaknesses

As we only looked into the top five software vulnerabilities , here is the list of the vulnerabilities and their frequency, from the latest Veracode study (11).

Percentage of application with specific CWE types (source Veracode11)

As we can see, there is a very large scope of security issues, and they are widely present in most application and software.

Should we not use third parties then?

We could imagine that relying on external sources is a risk not worth taking, but that is not true at all.

In fact, not relying on third parties would be a very bad idea for any business.

Focus personae

Not using third parties would mean a few things:

you are willing to lose a enormous amount of time to re-code all libraries and software you need

you think your code will have less vulnerability than the one everyone has been using for years/months (and often written by a large community of developers)

the time lost on the 90% of software you could choose from is time you won't spend on the 10% of value you bring

slower go-to-market

delay on your competition

slower development of new features

You need third parties, even if they are flawed, because we cannot, should not, and do not want to reinvent the wheel.

You need to assess that your code is going to be flawed, and so will be the software and libraries you use. By knowing the risks, knowing the libraries your third parties needs, acknowledging you'll need time for fixing security issues, you prepare yourself for whatever may happen.

By knowing the risks, you will be able to answer your customers and communicate clearly on your security policies and how you adapt to them.

On-the-shelf services and applications allow us to move faster. Businesses use third parties for the purpose they serve: monitoring, logging, storage, caching, analytics, and much more, focusing their principal effort on the value they want to bring to their own customers

Granting special authorization and accesses

Using open-source libraries, we cannot do much more than know what we use and assess the risks of our technical choices. An acknowledged and measured security risk is worth taking, as a no risk policy is inevitable.

When it comes to containers, it's a different story,…