Vulnerabilities in Systems: Management, Defense and Intelligence

Module 3 of Assets, Threats and Vulnerabilities is all about asset security, how assets are vulnerable to exploitation, and how to understand that threat actors are always looking for ways to break into systems using those weak points. This writeup covers the following:

Vulnerability management

Vulnerabilities of CI/CD

Defense in Depth

Common vulnerabilities and exposures

The OWASP Top 10

Open-Source Intelligence (OSINT)

1- Vulnerability management:

What is a Vulnerability?

"A vulnerability is a weakness that a threat can exploit."

If we look at a real-world asset, an important document, for instance, we can identify and think of the things that it is vulnerable to. It can be stolen, burnt, or torn apart.

An asset is exposed to a threat through a vulnerability. An exploit is the method or script an attacker uses to take advantage of that vulnerability.

There are ways to protect the assets and manage vulnerabilities. Some of them are:

1- Identify vulnerabilities

2- Think of potential exploits

3-Defend the assets from threats

4- Evaluate those defenses

It is a cyclic process because many exploits are being created every day. Security researchers and teams constantly look for new vulnerabilities in the system. Not every vulnerability can be found though, that's where a zero-day exploit comes in.

The zero-day exploit:

It is defined as an exploit previously unknown to the security team, so no measures were taken to patch or protect that area of the system.

2- Vulnerabilities of CI/CD:

Just as any system can be vulnerable to threats, so are CI/CD Pipelines.

In the software engineering process, in Continuous Integration and Continuous Delivery/Deployment, security risks are common and should be handled accordingly.

As the systems are automated, the security checks are, too.

Before looking at the vulnerabilities, let's talk about what CI/CD really is.

CI (Continuous Integration):

Automating CI means that whenever different developers in the team write their part of the code, they have to integrate it to a centralized place, a repository, mostly to keep the system running as they add new features or new code into the existing system. It also helps in testing the system in a sandbox environment to check for QA testing, integration testing, etc.

CD(Continuous Delivery):

CD means that the code you just wrote is ready to be released in the form of some application to the users. It is continuous because, after passing through types of testing, it gets automatically deployed. A manual approval is still needed, hence the human factor in CI/CD.

Continuous Deployment automates the whole process, speedily and efficiently. So, the system is deployed.

Some of the main security checks that are implemented in the CI/CD pipeline are:

SAST (Static Application Security Testing):

Scans the raw source code for bugs before it runs.

DAST (Dynamic Application Security Testing):

Checks for vulnerabilities in running applications before the actual deployment to users; it happens in a staged environment.

SCA (Software Composition Analysis):

Specifically scans open-source third-party dependencies for known CVEs.

Security Compliance Checks:

Compliance checks are about whether the current security controls meet the organization's security policies.

Infrastructure Security Validations:

Systems that host all the infrastructure must be secure too.

Although CI/CD Automation takes care of things like Secure Automation, Improved Code Quality Via Security Checks, Faster Time to Market for Security Updates, Enhanced Collaboration and Feedback with Safety Focus, Reduced Risk, developers have to watch out for the following vulnerabilities in the automation process:

Insecure Dependencies (third party code):

Since most of the code that the developers write is imported from libraries that already have solved that problem, an efficient engineering process, those libraries can also have some Common Vulnerabilities and Exposures, which can indirectly be inserted into the system being built, making it insecure as well.

So, making sure that the versions the developers are using in their code are secure and up to date.

Misconfigured Permissions:

Managing permissions and authorization is very important in the CI/CD pipelines as it makes sure that no external actors are allowed to configure a certain part of the system or have access to files and directories. Misconfigured Permissions can pose a great security risk, and the Principle of Least Privilege must be implemented here.

Lack of Automated Security Testing:

Not all bugs can be identified by humans, so it is necessary to automate the security testing of the software using tools like DAST (discussed above); otherwise, the software that is being deployed will have critical bugs and potential vulnerabilities.

Exposed Secrets:

The code must not have any secrets, because if the code is hacked, the secrets like APIs or any tokens can also be accessed easily by unauthorized users. There must be a separate tool only for managing these types of sensitive information.

Unsecured Build Environments:

If the environment (in which the pipeline is being run) itself is not protected, attackers will easily exploit it and have access to the system as it is being built; they can even put malware in there, or a virus that can create a domino effect if not tackled early on. The ways to protect this are to use containers or VMs that are secure and can be destroyed, if need be, ensuring that backup is safe somewhere.

3- Defense in Depth:

"A layered approach to manage vulnerabilities and reduce the risk of the system getting penetrated or compromised."

Think of it as securing a castle in the times of war, where not only the archers are lined up across the castle walls, but many traps are also laid for the enemy that is closing in on the place.

Defense in depth means defending or setting up a secure environment for the software in such a way that every decision (possible) you make is considered from a security point of view. Of course, there are many tradeoffs because you cannot have a fully secure system that can also run fast. Otherwise, that would be the Nirvana Fallacy.

Some of the ways to ensure that the system is secure in every possible way are embracing the DevSecOps mindset, where development, security testing, and deployment go hand in hand, and no window or way is open for any sneaky malware or exploit.

The following are some of the layers of the DID approach:

Perimeter layer:

The perimeter consists of external network boundaries: Firewalls, Web Application Firewalls (WAF), and DDoS protection.

Network Layer:

The primary purpose of the Network Layer in Defense in Depth is Network Segmentation, VLANs, and Traffic Filtering (stopping lateral movement if an attacker breaches the outer edge).

Endpoint layer:

The physical devices that have a connection to the network come under the endpoint layer, such as laptops, servers, etc.

Application layer:

Application Layer security includes input sanitization, secure coding, session timeout enforcement, and API security. (Note: IAM controls like MFA/Passkeys span across Application and Identity layers).

Data layer:

Data is the element that must be protected. It can be of two forms, PII and SPII, like passwords, credit information, social security numbers, etc.

4- Common vulnerabilities and exposures:

While vulnerabilities are prone to exploitation, there is another term known as Exposures.

The CVE list:

The Common Vulnerabilities and Exposures List is a list that maintains the number of known vulnerabilities in a system. It is openly accessible. Independent researchers, security researchers, ethical hackers, or anyone can submit a known discovered CVE. CVE has criteria for the vulnerability that is going to be submitted to them:

1- Independent of other issues

2- Recognized as a potential security risk

3- Submitted with supporting evidence

Once they meet the criteria, they are assigned a CVE-ID.

They can be found in the CVE databases, like the NIST National Vulnerability Database, which uses the CVSS, also called the Common Vulnerability Scoring System. According to the CVSS Base score:

• 0.1–3.9: Low
• 4.0–6.9: Medium
• 7.0–8.9: High
• 9.0–10.0: Critical

Not all CVEs are meant to be for all businesses, though. So, every organization must have its own policy of which exploit to deal with first.

5- The OWASP Top 10:

Besides the CVE list, there are many other tools to which the security community contributes; one of them is OWASP.

OWASP (Open Worldwide Application Security Project®) is a non-profit foundation that helps security teams and businesses set up security policies and controls for them, and where developers from around the world can share resources, tools, and events.

As technology is ever evolving, they update it occasionally, for web application technology is also dynamic and new exploits are being invented every single day, focused on compromising websites. The following are the Top 10 vulnerabilities that are referenced when building a web app or website.

1) Broken access control:

Broken access control refers to those elements or features that users should have access to. If it is a simple static portfolio page, the users must not be able to change the data on that page; on a dynamic page, they can comment but not delete any other comment.

2) Cryptographic failures:

The GDPR (General Data Protection Regulation) requires that the privacy of users must be protected by any means; one of them is by encrypting the information. Whether it is end-to-end encryption in applications or securing a password in a database using Hashing, those Cryptos mustn't be bypassed. Controls must be updated regularly.

3) Injection:

Injection means entering a malicious piece of code into the application. Injection is when untrusted user input is passed directly to an interpreter (like SQL or Bash commands) and executed as code (e.g., ' OR '1'='1).

4) Insecure design:

Measure Twice, Cut once is a common practice in software engineering which ensures that before even touching the code or an IDE, the design of the system must be so flawless that there is no tsunami waiting at the end of the deployment. Insecure Design refers to architectural design flaws created before writing code (e.g., forgetting to design password-reset rate limits or lacking threat modeling).

5) Security misconfiguration:

While writing secure code is important, security settings and configurations also play a key role in the overall secure app. If those configurations are poorly set up, the system is insecure and vulnerable to attacks. When a firewall uses its default settings, not knowing the objectives and goals of the company, it can be more of a nuisance than a defender. So, it is very important to know the organization's goals and policies, rather than blindly trusting a default device.

6) Vulnerable and outdated components:

Again, using outdated components or libraries in your current code can automatically give attackers access to your system.

7) Identification and authentication failures:

Weaknesses in confirming a user's identity — such as allowing weak passwords, lacking Multi-Factor Authentication (MFA), or failing to protect session tokens — which allow attackers to hijack accounts.

8) Software and data integrity failures:

This is also a point to focus on during the CI/CD pipelines. Because the software is borrowed from third-party vendors and implemented on one's own business, the company is at risk of the good old Supply Chain Attack. There have been many supply chain attacks in the past; it is the most dangerous one because even government organizations and agencies use third-party software. For example, the SolarWinds attack lasted many months before it was even discovered.

9) Security logging and monitoring failures:

If we look at the defensive and incident response side of the attack, logs are the main element that security analysts refer to to see the traffic or any activity that was detected by the system, mostly centralized by a SIEM tool. If the tools themselves fail, or a serious event is ignored or labelled as a false alarm, viruses can easily enter the system without the SOC teams batting an eye on it.

10) Server-side request forgery:

When requesting data or webpages from a web server, for example, if the server itself is not secure, the hacker manipulates the server in such a way that the server gives private information and internal resources.

6- Open-Source Intelligence (OSINT):

Open-Source intelligence is mainly defined as using publicly available data to make decisions and generate intelligence; it is used by a broad number of professions like Cybersecurity Researchers, Hackers, Pen-testers, journalists, and government agencies.

The information gathered by OSINT is then converted to Intelligence, after thorough analysis of the acquired information, which helps in decision-making and can be helpful to businesses.

OSINT and InfoSec:

OSINT is widely used by the Information Security teams to look out for and research any new exploits in the software used by the company, mainly to prevent a supply-chain attack. This is done by browsing hacker forums, intelligence feeds, and many cybersecurity forums and reports on the internet, but it must be double checked and verified. Some of the most popular tools used to gather intel are listed below:

• VirusTotal
• OSINT Framework
• Have I Been Pwned
• Shodan
• Maltego
• Google Dorks

This was a deep dive into the Vulnerabilities and how to manage them, and overall, how to protect the systems.

Based on Google's Cybersecurity Certificate: Assets, Threats, and Vulnerabilities, Module 3.