Symantec fixed a local privilege escalation security flaw affecting all Symantec Endpoint Protection software versions prior to 14.2 RU2, and allowing attackers to escalate privileges on compromised devices and execute malicious code using SYSTEM privileges. […] BleepingComputer
Symantec Endpoint Protection is the latest antivirus product found to unsafely load DLLs into a process that runs with SYSTEM privileges.
read more
Metrics — or perhaps more accurately, the right metrics — are crucial for understanding what’s really happening in your AppSec program. They serve a dual purpose: They demonstrate your organization’s current state, and also show what progress it’s making in achieving its objectives.
We typically recommend our customers measure their compliance against their own internal AppSec policy, plus scan activity, flaw prevalence, and time to resolve.
Flaw rate is another metric you might want to consider tracking. Although this would be a secondary metric, unlike the primary ones listed above, flaw rate, which allows you to do a before-and-after flaw comparison for an application, provides insight into how your rate of security findings is improving over time. Veracode analytics allows you to create the flaw rate metric by using a formula and adding it to your chart in order to visualize the rate alongside any other data you are reporting – such as flaw rate per application, first scan vs most recent scan, or flaw rate per an application per severity of the finding.
Keep in mind that this metric, as with flaws per MB, can vary significantly based on the size of the codebase. A monolithic, legacy application is going to have a much different flaw rate (and flaw density as measured by flaws per MB) than a small, new microservice. The value lies in comparing an application’s initial flaw rate to the current flaw rate, or comparing the flaw rate for a team across several applications (again the initial flaw rate vs. the current). This allows users to get a handle on what is working – or not – for that team to help them close out security findings and reduce the number they are introducing in the first place. In this way, you could validate the impact of your AppSec eLearning or other trainings. I would caution against comparing flaw rate (again much like flaws per MB) between teams or between business units as this won’t directly provide much actionable insights beyond which one is doing better.
Note that this metric will not produce an accurate gauge of your program’s success. Since it is applicable only to static analysis, it doesn’t take all testing techniques into account. Policy compliance is ultimately the best metric for measuring and reporting on the overall progress of your program.
But you could use flaw rate as an additional data point, alongside the following metrics, when reporting on the effectiveness or progress of your AppSec program:
Policy compliance: Your application security policy should stem from an analysis of your entire application inventory. From there, you assign groups of applications different risk categories or ratings by asking questions such as:
- Do these applications touch PII?
- Are they Internet-facing?
- What would be the impact of a compromise to this system (i.e., are they business critical)?
Based on those answers, you can determine which scan frequency and testing types are required, as well as which types or severities of flaws to disallow: an Internet-facing application that contains PII will have a different risk categorization from an internal chat service and thus should be held to a different standard for security.
Additionally, this risk rating will determine frequency of scanning requirements. Low-risk functionality that is rarely updated does not need to be scanned every week, but that Internet-facing/PII app may require a scan for every commit.
Average time to resolve: Many application testing solutions focus on scan activity rather than addressing results. While apps need to be scanned, fixing those security findings in a timely manner is a better mechanism for evaluating your application security program. Time to resolve provides visibility into how many days it takes for a finding to be closed after it is first discovered, helping security teams better understand where there may be bottlenecks in the development and security process.
Flaw prevalence: This metric spotlights how common a risk is within a particular industry or business. It helps an organization prioritize threats such as SQL injection, Cross-Site Scripting (XSS), cryptographic issues, and CRLF injection based on real-world impact.
Learn more about flaw rate
For detailed instructions on measuring flaw rate, please see this article in the Veracode Community.
Cisco released security updates for Cisco IOS XE operating system to address a critical vulnerability that could be exploited by a remote attacker to bypass authentication.
Cisco released security updates for
“On August 28th, 2019, Cisco published a Security Advisory titled “Cisco REST API Container for Cisco IOS XE Software Authentication Bypass Vulnerability”, disclosing an internally found
The vulnerability resides in the Cisco REST API container, an attacker could exploit the flaw to submit commands through the REST API that will be executed on the vulnerable device.
The REST API container provides an alternative interface of RESTful APIs that allows managing devices running Cisco IOS-XE Software. The REST API container is located in a virtual services container, which is a
This CVE-2019-12643 flaw was discovered by researchers at Cisco during internal testing, it received a severity score of 10.
Only the following Cisco platforms support
- Cisco 4000 Series Integrated Services Routers
- Cisco ASR 1000 Series Aggregation Services Routers
- Cisco Cloud Services Router 1000V Series
- Cisco Integrated Services Virtual Router
Under specific conditions, an attacker could trigger the flaw by sending specially-crafted HTTP requests to an affected device. If an administrator is authenticated to the REST API interface, an attacker can obtain the ‘
“The vulnerability is due to an improper check performed by the area of code that manages the REST API authentication service. An attacker could exploit this vulnerability by submitting malicious HTTP requests to the targeted device.” reads the advisory published by Cisco. “A successful exploit could allow the attacker to obtain the token-id of an authenticated user. This token-id could be used to bypass authentication and execute privileged actions through the interface of the REST API virtual service container on the affected Cisco IOS XE device.”
Cisco’s advisory pointed out that the REST API interface is not enabled by default and must be installed and activated separately on IOS XE devices.
The exploitation of the issue is possible only if the target device has enabled a vulnerable version of the Cisco REST API virtual service container.
Administrators should install version 16.09.03 of the REST API virtual device container (“
“Cisco has also released a hardened Cisco IOS XE Software release that prevents installation or activation of a vulnerable container on a device. If the device was already configured with an active vulnerable container, the IOS XE Software upgrade will deactivate the container, making the device not vulnerable.”continues
Cisco confirmed that are no workarounds available.
|
|
Pierluigi Paganini
(SecurityAffairs – Cisco IOS XE, CVE-2019-12643)
The post Cisco addresses CVE-2019-12643 critical flaw in virtual Service Container for IOS XE appeared first on Security Affairs.
A critical remote code execution vulnerability discovered by an IBM X-Force researcher allows an unauthenticated attacker to take complete control of some TP-Link Wi-Fi extenders. Firmware updates that should patch the flaw have been made available by the vendor.
read more