Add monitoring logs (#2140)
* Add: Monitoring tools Signed-off-by: NaveenKumar Namachivayam ⚡ <catch.nkn@gmail.com> * Add: Security Testing Signed-off-by: NaveenKumar Namachivayam ⚡ <catch.nkn@gmail.com> * Add: Security Testing Signed-off-by: NaveenKumar Namachivayam ⚡ <catch.nkn@gmail.com> * Add: Security Testing Signed-off-by: NaveenKumar Namachivayam ⚡ <catch.nkn@gmail.com> * Update 105-data-dog.md * Update 105-data-dog.md * Update 105-data-dog.md Signed-off-by: NaveenKumar Namachivayam ⚡ <catch.nkn@gmail.com>pull/2254/head^2
NaveenKumar Namachivayam ⚡
2 years ago
committed by
GitHub
parent
d14f405595
commit
575e50a8b5
10 changed files with 107 additions and 10 deletions
@ -1 +1,9 @@ |
||||
# Authentication authorization |
||||
|
||||
`Authentication` is the process of verifying that an individual, entity or website is whom it claims to be. Authentication in the context of web applications is commonly performed by submitting a username or ID and one or more items of private information that only a given user should know. |
||||
|
||||
`Authorization` may be defined as "the process of verifying that a requested action or service is approved for a specific entity" (NIST). `Authorization` is distinct from authentication which is the process of verifying an entity's identity. When designing and developing a software solution, it is important to keep these distinctions in mind. A user who has been authenticated (perhaps by providing a username and password) is often not authorized to access every resource and perform every action that is technically possible through a system. |
||||
|
||||
For example, a web app may have both regular users and admins, with the admins being able to perform actions the average user is not privileged to do so, even though they have been authenticated. Additionally, authentication is not always required for accessing resources; an unauthenticated user may be authorized to access certain public resources, such as an image or login page, or even an entire web app. |
||||
|
||||
<BadgeLink colorScheme='blue' badgeText='Framework Website' href='https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html'>OWASP Website</BadgeLink> |
||||
@ -1 +1,19 @@ |
||||
# Vulnerability scanning |
||||
# Vulnerability Scanning |
||||
|
||||
Vulnerability scanning identifies hosts and host attributes |
||||
(e.g., operating systems, applications, open ports), but it also attempts to identify vulnerabilities rather |
||||
than relying on human interpretation of the scanning results. Many vulnerability scanners are equipped to |
||||
accept results from network discovery and network port and service identification, which reduces the |
||||
amount of work needed for vulnerability scanning. |
||||
|
||||
Also, some scanners can perform their own network |
||||
discovery and network port and service identification. Vulnerability scanning can help identify outdated |
||||
software versions, missing patches, and misconfigurations, and validate compliance with or deviations |
||||
from an organization’s security policy. |
||||
|
||||
This is done by identifying the operating systems and major |
||||
software applications running on the hosts and matching them with information on known vulnerabilities |
||||
stored in the scanners’ vulnerability databases. |
||||
|
||||
<ResourceGroupTitle>Free Content</ResourceGroupTitle> |
||||
<BadgeLink colorScheme='blue' badgeText='Framework Website' href='https://csrc.nist.gov/glossary/term/vulnerability_scanning'>NIST Website</BadgeLink> |
||||
@ -1 +1,28 @@ |
||||
# Owasp 10 |
||||
|
||||
The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications. |
||||
|
||||
<p class="callout-mono right">Globally recognized by developers as the first step towards more secure coding.</p> |
||||
|
||||
Companies should adopt this document and start the process of ensuring that their web applications minimize these risks. Using the OWASP Top 10 is perhaps the most effective first step towards changing the software development culture within your organization into one that produces more secure code.<br> |
||||
<br> |
||||
|
||||
## Top 10 Web Application Security Risks |
||||
|
||||
There are three new categories, four categories with naming and scoping changes, and some consolidation in the Top 10 for 2021. |
||||
|
||||
 |
||||
|
||||
- [**A01:2021-Broken Access Control**](https://owasp.org/Top10/A01_2021-Broken_Access_Control/) moves up from the fifth position; 94% of applications were tested for some form of broken access control. The 34 Common Weakness Enumerations (CWEs) mapped to Broken Access Control had more occurrences in applications than any other category. |
||||
- [**A02:2021-Cryptographic Failures**](https://owasp.org/Top10/A02_2021-Cryptographic_Failures/) shifts up one position to #2, previously known as Sensitive Data Exposure, which was broad symptom rather than a root cause. The renewed focus here is on failures related to cryptography which often leads to sensitive data exposure or system compromise. |
||||
- [**A03:2021-Injection**](https://owasp.org/Top10/A03_2021-Injection/) slides down to the third position. 94% of the applications were tested for some form of injection, and the 33 CWEs mapped into this category have the second most occurrences in applications. Cross-site Scripting is now part of this category in this edition. |
||||
- [**A04:2021-Insecure Design**](https://owasp.org/Top10/A04_2021-Insecure_Design/) is a new category for 2021, with a focus on risks related to design flaws. If we genuinely want to "move left" as an industry, it calls for more use of threat modeling, secure design patterns and principles, and reference architectures. |
||||
- [**A05:2021-Security Misconfiguration**](https://owasp.org/Top10/A05_2021-Security_Misconfiguration/) moves up from #6 in the previous edition; 90% of applications were tested for some form of misconfiguration. With more shifts into highly configurable software, it's not surprising to see this category move up. The former category for XML External Entities (XXE) is now part of this category. |
||||
- [**A06:2021-Vulnerable and Outdated Components**](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/) was previously titled Using Components with Known Vulnerabilities and is #2 in the Top 10 community survey, but also had enough data to make the Top 10 via data analysis. This category moves up from #9 in 2017 and is a known issue that we struggle to test and assess risk. It is the only category not to have any Common Vulnerability and Exposures (CVEs) mapped to the included CWEs, so a default exploit and impact weights of 5.0 are factored into their scores. |
||||
- [**A07:2021-Identification and Authentication Failures**](https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/) was previously Broken Authentication and is sliding down from the second position, and now includes CWEs that are more related to identification failures. This category is still an integral part of the Top 10, but the increased availability of standardized frameworks seems to be helping. |
||||
- [**A08:2021-Software and Data Integrity Failures**](https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/) is a new category for 2021, focusing on making assumptions related to software updates, critical data, and CI/CD pipelines without verifying integrity. One of the highest weighted impacts from Common Vulnerability and Exposures/Common Vulnerability Scoring System (CVE/CVSS) data mapped to the 10 CWEs in this category. Insecure Deserialization from 2017 is now a part of this larger category. |
||||
- [**A09:2021-Security Logging and Monitoring Failures**](https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/) was previously Insufficient Logging & Monitoring and is added from the industry survey (#3), moving up from #10 previously. This category is expanded to include more types of failures, is challenging to test for, and isn't well represented in the CVE/CVSS data. However, failures in this category can directly impact visibility, incident alerting, and forensics. |
||||
- [**A10:2021-Server-Side Request Forgery**](https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/) is added from the Top 10 community survey (#1). The data shows a relatively low incidence rate with above average testing coverage, along with above-average ratings for Exploit and Impact potential. This category represents the scenario where the security community members are telling us this is important, even though it's not illustrated in the data at this time. |
||||
|
||||
<ResourceGroupTitle>Free Content</ResourceGroupTitle> |
||||
<BadgeLink colorScheme='blue' badgeText='Framework Website' href='https://owasp.org/www-project-top-ten/'>OWASP Website</BadgeLink> |
||||
@ -1 +1,6 @@ |
||||
# Attack vectors |
||||
|
||||
This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the Base Score) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable component. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater Base Score. |
||||
|
||||
<ResourceGroupTitle>Free Content</ResourceGroupTitle> |
||||
<BadgeLink colorScheme='blue' badgeText='Framework Website' href='https://www.first.org/cvss/v3.1/specification-document'>FIRST.org Website</BadgeLink> |
||||
@ -1 +1,9 @@ |
||||
# Secrets management |
||||
# Secrets Management |
||||
|
||||
Secrets Management is a systematic way of in managing, storing, securing, and retrieving credentials for any systems, database, and other services. |
||||
|
||||
Credentials such as passwords, SSH keys, certificates, API keys, backup codes, and more. |
||||
|
||||
<ResourceGroupTitle>Free Content</ResourceGroupTitle> |
||||
<BadgeLink colorScheme='blue' badgeText='Framework Website' href='https://aws.amazon.com/secrets-manager/'>AWS Secrets Management Website</BadgeLink> |
||||
<BadgeLink colorScheme='blue' badgeText='Framework Website' href='https://www.vaultproject.io/'>Vault Website</BadgeLink> |
||||
@ -1 +1,7 @@ |
||||
# Security testing |
||||
# Security Testing |
||||
|
||||
Security testing is a process intended to reveal flaws in the security mechanisms of an information system that protect data and maintain functionality as intended. Due to the logical limitations of security testing, passing the security testing process is not an indication that no flaws exist or that the system adequately satisfies the security requirements. |
||||
|
||||
Typical security requirements may include specific elements of confidentiality, integrity, authentication, availability, authorization and non-repudiation. Actual security requirements tested depend on the security requirements implemented by the system. Security testing as a term has a number of different meanings and can be completed in a number of different ways. As such, a Security Taxonomy helps us to understand these different approaches and meanings by providing a base level to work from. |
||||
|
||||
<BadgeLink colorScheme='blue' badgeText='Framework Website' href='https://en.wikipedia.org/wiki/Security_testing'>Security Testing Wiki</BadgeLink> |
||||
@ -1 +1,7 @@ |
||||
# New relic |
||||
# New Relic |
||||
|
||||
New Relic is an observability platform that helps you build better software. You can bring in data from any digital source so that you can fully understand your system and how to improve it. |
||||
|
||||
<ResourceGroupTitle>Free Content</ResourceGroupTitle> |
||||
<BadgeLink colorScheme='blue' badgeText='Framework Website' href='https://newrelic.com/'>New Relic Website</BadgeLink> |
||||
<BadgeLink badgeText='Course' colorScheme='green' href='https://learn.newrelic.com/'>Learn New Relic</BadgeLink> |
||||
@ -1 +1,9 @@ |
||||
# Run scope |
||||
|
||||
A Simple Tool for Monitoring Complex APIs. Verify that the structure and content of your API calls meets your expectations. Powerful and flexible assertions give you total control over defining a successful API call. |
||||
|
||||
Create simple monitors with dynamic data for even the most complex use cases. More than simple string matching, build API validations without any code and use them across local dev, staging and production environments. |
||||
|
||||
<ResourceGroupTitle>Free Content</ResourceGroupTitle> |
||||
<BadgeLink colorScheme='blue' badgeText='Framework Website' href='https://www.runscope.com'>Runscope Website</BadgeLink> |
||||
|
||||
|
||||
@ -1 +1,6 @@ |
||||
# Sentry |
||||
|
||||
Sentry tracks your software performance, measuring metrics like throughput and latency, and displaying the impact of errors across multiple systems. Sentry captures distributed traces consisting of transactions and spans, which measure individual services and individual operations within those services. |
||||
|
||||
<ResourceGroupTitle>Free Content</ResourceGroupTitle> |
||||
<BadgeLink colorScheme='blue' badgeText='Framework Website' href='https://sentry.io'>Sentry Website</BadgeLink> |
||||
@ -1 +1,7 @@ |
||||
# Kibana |
||||
|
||||
Kibana is a free and open user interface that lets you visualize your Elasticsearch data and navigate the Elastic Stack. Do anything from tracking query load to understanding the way requests flow through your apps. |
||||
|
||||
<ResourceGroupTitle>Free Content</ResourceGroupTitle> |
||||
<BadgeLink colorScheme='blue' badgeText='Framework Website' href='https://www.elastic.co/kibana/'>Elastic Kibana Website</BadgeLink> |
||||
<BadgeLink badgeText='Course' colorScheme='green' href='https://www.elastic.co/training/free'>Learn Kibana</BadgeLink> |
||||
Loading…
Reference in new issue