User Getting Bored in VI Editor

 

:help UserGettingBored

Shrubbery in VI Editor

 

:Ni!

OVAL and CVRF

Open Vulnerability and Assessment Language (OVAL)

An OVAL is a definition file that is designed for use by automated test tools to determine the patch state of a machine. It is developed by NIST.

CVRF is not designed as being a way to determine the patch state of a machine, but it can provide an alternative machine-reacable version of security advisories.

 

Common Vulnerability Reporting Framework (CVRF)

The goal of CVRF is to share information about security updates (security advisories) in an XML machine-readable format. It is developed by ICASI (and is integrated to FIRST in Jun 2021).

CVRF has been transitioned to the OASIS Common Security Advisory Framework (CSAF) Technical Committee.

The most common supported CVRF is v1.1 today.

What are the differences between OVAL and CVRF?

OVAL is a definition file that used by scanning tools to perform assessment, and CVRF is security advisories documents.

OVAL is available as a roll up definition file for OS version, such as Ubuntu Focal. It contains all the patch info since day 1.

CVRF document is usually provided by OS vendor at a regular basis. For example, Microsoft provides a monthly security advisories in CVRF format, and can be retrieved via API call with the parameter 2021-apr.

Think of OVAL is for security scanning (with OpenSCAP), and CVRF is just the security advisories (not for assessment) that used for communicating security information to customers.

Both are in XML format that machine-readable.

Vendor Supports

Most OS vendors support OVAL and provide OVAL download for free. For example, RedHat starts provide OVAL definition since 2006, and starts providing CVRF documents for all RedHat security advisories across all products since 2012.

So far, Microsoft only provide CVRF documents and an API call to access the documents based on the YYYY-mmm.

Links:

• Red Hat and CVRF compatibility
• GitHub OVAL Sandbox
• GitHub CVRF Sandbox
• CVRF GitHub Wedsite 
• MSRC CVRF API
  

Global Cyber Conflict

With the increase of Cyber conflict at the global level, we should expect increasing risks of cybersecurity attacks and incidents.

Be prepare to face the types of attacks like:

• Malware infection
• DDoS
• Phishing attacks
• Brute-force attacks
• Defacement
• Ransonware

 

Be prepared for:

• Evaluate asset and application configurations to ensure resilience
•  Double-check visibility into the functioning of business-cirtical assets
• Assess incident response processes in the case of an incident

 

Mitigation and remediation:

1. Continuous monitoring
2. Incident response plan
3. Back up data
4. Reduce opportunities for attackers
5. Stay informed 

 

Containerless on Kubernetes

WebAssembly (Wasm) is one of the most exciting and underestimated software technologies invented in recent times. It's a binary instruction format for a stack-based virtual machine that aims to execute at native speeds with a memory-safe and secure sandbox. 

Wasm is portable, cross-platform, and language-agnostic—designed as a compilation target for languages. Though originally part of the open web platform, it has found use cases beyond the web. WebAssembly is now used in browsers, Node.js, Deno, Kubernetes, and IoT platforms.

WebAssembly on Kubernetes

Though initially designed for the web, WebAssembly proved to be an ideal format for writing platform and language-agnostic applications. 

You may be aware of something similar in the container world—Docker containers. 

People, including Docker co-founder Solomon Hykes, recognized the similarity and acknowledged that WebAssembly is even more efficient (than Docker) since it's fast, portable, and secure, running at native speeds. This means that you can use WebAssembly alongside containers as workloads on Kubernetes. 

Another WebAssembly initiative known as WebAssembly System Interface (WASI) along with the Wasmtime project make this possible.

    If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope WASI is up to the task! twitter.com/linclark/statu…
    20:39 PM - 27 Mar 2019
    Lin Clark @linclark
    

WebAssembly on Kubernetes is relatively new, but it's already proving to be revolutionary. Wasm workloads can be extremely fast as they can execute faster than a container takes to start. The workloads are sandboxed and hence much more secure than containers; they are way smaller in size due to the binary format than containers.

If you want to learn more about WASI, check out the original announcement from Mozilla.

Links:

• Learn more about WebAssembly (WASM) at WebAssembly.org.
• https://dev.to/oktadev/containerless-how-to-run-webassembly-workloads-on-kubernetes-with-rust-2j8f