Containers, Kubernetes, and Red Hat OpenShift Administration I

Today, just completed the training on [DO285] "Containers, Kubernetes, and Red Hat OpenShift Administration I" (Oct 21~25).

The training helps me to build the skills on building local containers, establishing the health of a new OpenShift cluster, and managing access to cluster. One major focus is to troubleshoot the common problems beside configuring the Red Hat OpenShift Container Platform cluster.

The outline for the course:

• Introduction to container technology
• Create containerized services
• Manage containers
• Manage container images lifecycle
• Create custom container images
• Deploy containerized applications on OpenShift
• Deploy multicontainer applications
• Explore Red Hat OpenShift Container Platform
• Verify the health of a cluster
• Configure authentication and authorization
• Configuring application security
• Configure OpenShift networking for applications
• Control pod scheduling
• Scale an OpenShift cluster
• Describe cluster updates
• Manage a cluster with the web console
• Execute a comprehensive review
  

CVE ⊂ Vuln

CVEs are not the ONLY vulnerabilities. In another words, CVE is a subset of vulnerabilities.

CVE stands for Common Vulnerabilities and Exposure. It is used to track security vulnerability. It has the format of CVE-YYYY-XXXXXXX, where YYYY denotes the year, and XXXXXXX is the tracking number.

By definition, a CVE is always equal to a vulnerability. But not every vulnerability has a CVE number. 

For example, password configuration, such as password policy (length, complexity, renewal) has no CVE number assigned but is considered as vulnerability.

Next, mis-configurations, such as default admin credential or well-known login/password, and those ICMP configuration that leak system information, has no CVE number too. But those are always been highlighted by any vulnerability scanning tools.

Weak encryption (can is a kind of mis-configuration) can lead to disclosure of sensitive information, has not been assigned to any CVE number too.

CVSS != Risk

CVSS does not equal risk; CVSS does not equal risk; CVSS does not equal risk. (We should always repeat at least 3 times for an important thing)

Surprisingly nowadays, there are still Cybersecurity people managing vulnerabilities based on CVSS score, and claim that they are doing risk management. (don't laugh, check with your CISO)

Why a CVSS score is not the same as risk?

Because a CVSS score only helps describe the severity of a vulnerability (CVE) from a technical perspective. 

Then what is a CVSS score?

CVSS stands for Common Vulnerability Scoring System. There are 2 versions of CVSS: CVSS 2.0 and CVSS 3.1. CVSS has 3 metric groups: Base Score, Temporal Score, and Environment Score. Each metric group has own set of metric names.

There is a CVSS Scoring calculator at Common Vulnerability Scoring System Version 3.1 Calculator (first.org) 

Here's a sample of CVSS score: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N

And it is common for only the CVSS Base Score to be used to prioritize how quickly those Cybersecurity team are responding to a new vulnerability. 

(Ask your Cybersecurity team when is the last time they are looking at the Temporal and environment scores)

If CVSS != Risk, then why people using it to manage risk?

IMO, it is not their fault. This is all due to regulatory bodies have built CVSS scores into their compliance schemes, and require remediation of all vulnerabilities above certain Base CVSS score in order to remain compliant. (Yes, I'm talking about PCI-DSS)

So, what's wrong with CVSS score as risk management?

First, CVSS score does not take into account the importance of asset. A same vulnerability should have different priority between a domain controller server and a workstation. 

Secondly, not all vulnerability has CVE and CVSS score. There are may vulnerabilities go far beyond CVE/CVSS. If a vulnerability without an assigned CVE/CVSS, does it mean you can skip the remediation?

Third and I think this is most important. Not every vulnerability is exploitable. Instead of remediating all vulnerabilities based on CVSS score, we should focus on those high/critical and exploitable vulnerabilities. Remediation based on CVSS score is not only unfeasible, it is also take up a lot of resource and probably still an unachievable goal. (remember 80/20 rules)

Forth. The CVSS score provides no accounting for other compensating controls, like firewall and antivirus, and thus it doesn't reflect the actual situation.   

In summary, CVSS != Risk, simply because of the following reasons.

1. Lack of asset priority.
2. Only applicable for known vulnerabilities.
3. Waste of vulnerability remediation effort.
4. Not accounting for those compensating controls.

Unlike CVSS and other static scoring methods, KennaSecurity provides the context required to understand the true level of risk that vulnerabilites pose to an organization, using a risk score. The purpose of the score is to provide Cybersecurity, IT and infrastructure teams with an understanding of the relative urgency of the vulnerability so that everyone can prioritize the remediation efforts of some over others based on real-world exploitability. 

References:

•  What You Miss When You Rely on CVSS Scores | Kenna Security
•  A Vulnerability Score On Its Own Is Useless | Kenna Security

CWE/SANS TOP 25 Most Dangerous Software Errors

Below are the list of CWE released by SANS (Jun 27, 2011) to help eliminate the top 25 software errors.

The CWE Top 25 

Rank	ID	Name
1	CWE-119	Improper Restriction of Operations within the Bounds of a Memory Buffer
2	CWE-79	Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
3	CWE-20	Improper Input Validation
4	CWE-200	Information Exposure
5	CWE-125	Out-of-bounds Read
6	CWE-89	Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
7	CWE-416	Use After Free
8	CWE-190	Integer Overflow or Wraparound
9	CWE-352	Cross-Site Request Forgery (CSRF)
10	CWE-22	Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
11	CWE-78	Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
12	CWE-787	Out-of-bounds Write
13	CWE-287	Improper Authentication
14	CWE-476	NULL Pointer Dereference
15	CWE-732	Incorrect Permission Assignment for Critical Resource
16	CWE-434	Unrestricted Upload of File with Dangerous Type
17	CWE-611	Improper Restriction of XML External Entity Reference
18	CWE-94	Improper Control of Generation of Code ('Code Injection')
19	CWE-798	Use of Hard-coded Credentials
20	CWE-400	Uncontrolled Resource Consumption
21	CWE-772	Missing Release of Resource after Effective Lifetime
22	CWE-426	Untrusted Search Path
23	CWE-502	Deserialization of Untrusted Data
24	CWE-269	Improper Privilege Management
25	CWE-295	Improper Certificate Validation

Links:

• Top 25 Software Errors | SANS Institute

Advanced Web App Penetration Testing, Ethical Hacking, and Exploitation Techniques

Completed my training on SEC642 today.

This onDemand training begin by exploring some advanced techniques and attacks to which all modern applications' vulnerabilities, such as new web frameworks, encryption and cryptography, alternate web front ends on mobile apps, HTTP/2 and websocket.

Syllabus:

1. SEC642.1: Advanced Attacks
2. SEC642.2: Web Cryptography
3. SEC642.3: Alternative Interfaces and XML
4. SEC642.4: Modern Web Frameworks, Part 1
5. SEC642.5: Modern Web Frameworks, Part II 

Link: Advanced Web Application Penetration Testing and Exploitation | SANS SEC642