One Article Review
| Source |  AlienVault Blog |
|---|---|
| Identifiant | 1796396 |
| Date de publication | 2020-07-08 08:07:00 (vue: 2020-07-08 09:13:07) |
| Titre | Vulnerability assessment steps, process explained |
| Texte | This blog was written by a third party author What is a vulnerability assessment? Vulnerability assessment is the process of defining, identifying, classifying, and prioritizing vulnerabilities in systems, applications, and networks. It provides an organization with the needed visibility into the risks that exist concerning external threats designed to take advantage of vulnerabilities. At a tactical level, the vulnerability assessment process can help organizations identify potential methods of unauthorized access by which threats can gain entry to the organization’s network. Assessments (and fixes based on the results) need to be performed before the vulnerabilities found can be exploited. Every organization faces the risk of cyberattacks—regardless of organization size—so it’s beneficial to perform some form of vulnerability assessment regularly. Larger enterprises and those organizations experiencing ongoing attacks may benefit most. Assessments can be performed by internal IT security teams or outsourced to third parties that focus on security services. 4 steps to a vulnerability assessment Assessing the current state of vulnerabilities is a bit more involved than installing vulnerability scanner software and hitting the “Scan” button. Vulnerability assessments are the foundational element of your organization when putting proper security controls in place. It requires some proper planning, prioritizing, and reporting. The process of performing a vulnerability assessment can be broken down into the following 4 high-level steps. Step 1: Initial assessment The goal here is to understand the importance of devices on your network and the risk associated with each. Risk can be determined using several factors, including but not limited to: Whether a given device is accessible to the internet (whether via internal or external IP addresses) Whether the device is publicly accessible to anyone (such as a kiosk machine) Whether a device’s users have low-level or elevated permissions (such as administrators) The device’s role in business processes The determined risk can be used to prioritize the remainder of the assessment and establish the proper order for the vulnerability assessment scans. It can also be used as input for a business impact analysis that is a part of an enterprise risk management initiative. Step 2: Define a system baseline For each given device to be assessed for vulnerabilities, it’s necessary to understand whether its configuration meets basic security best practices. Some of the configuration factors that should be a part of a baseline include: Operating system (OS), version, and service pack or build, if applicable Approved software Installed services and required ports Any unnecessary open ports Any special security configuration, if applicable Approach each device as if you were an malicious actor; when you perform a scan in the next step, you want to see what an internal or external threat actor can access, and be able to compare that against known vulnerabilities and insecure configurations so you can interpret the results of the scan properly. In addition to the configuration factors, gathering up any additional detail known about the system (such as log data pushed into a SIEM solution), and any already-known vulnerabilities for the specific OS and version, any installed applications or any enabled services, will be useful. Step 3: Perform a vulnerability scan There are a few options available when it comes to vulnerability scans. Each one provides a bit of different context to the results. In general, vulnerability scans are performed either via unauthenticated or authenticated means. In an unauthenticated scan, a system is assessed from the network perimeter, looking |
| Envoyé | Oui |
| Condensat | able about accepting access accessible accountability act actionable actions actor actor; actors addition additional addressed addresses adherence administrators advantage again against already also analysis and/or any anyone applicable application applications approach approved are assessed assessing assessment assessments associated attacks authenticated author automatic available based baseline basic because been before beneficial benefit best bit blog both broken build business businesses but button can card cards classifying comes common compare compliance concerning configuration configurations confirm consider context controls correct creation credentialed credit critical current cve cyberattacks—regardless data database date define defining designed detail detailed details determined device device’s devices different discovered discovery done down dss each either element elevated enabled enterprise enterprises entry establish every example exist experiencing explained exploited exploits exposure external faces factors fix fixes focus following form found foundational from full future gain gathering gdpr general given goal good happening have having health help here high hipaa hitting identify identifying immediately impact importance important include include: including including: industries industry initial initiative input insecure installed installing insurance internal internet interpret involved issue it’s its keep kiosk known larger laws level like likewise limited list log look looking low machine malicious malware management mandates may means medium meet meets met methods misconfigurations missing mitigate mitigation more most necessary need needed network networks next not one ongoing only open operating options order organization organization’s organizations others outlines outsourced pack part parties party passwords patches patching payment pci perform performed performing perimeter permissions perspective pertinent place planning portability ports posture potential practices prioritize prioritizing process processes proper properly protection provide provides publicly purely pushed putting reconfiguration reference regularly regulated regulation regulations remainder report reporting required requirements requires respond results risk risks role said same scan scanned scanner scanning scans score score; section security see service services several should siem size—so software solution some source special specific standard state step steps subject such system systems tactical take taken teams testing than third those threat threats to: type unauthenticated unauthorized understand understanding unnecessary updates use used useful users using valuable version visibility vulnerabilities vulnerability vulnerable want weak what when whether which will work written your |
| Tags | Threat Patching Vulnerability |
| Stories | |
| Notes | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.