Application Security Protection for the Masses


I’ve always found it entertaining that so many sales pitches are essentially a listing of features for the product or service being sold. The reason I find this entertaining is that for anyone who has worked on the customer side or has ever listened to customers, it is obvious that customers buy solutions, not products. Thus, the notion of showing off how proud you are of your product by rattling off a laundry list of features has always seemed a bit odd to me.

In other words, customers have a number of different problems, issues, and challenges that they are looking to solve. They are not necessarily interested in all of the different things your product or service can do. Rather, they are interested in learning how your solution can help them address their strategic priorities and move forward on the goals they have set for their security and fraud problems. It is incumbent upon vendors to understand that and to make it easy for potential customers to understand that mapping.

Along those lines, improving application security is a common goal customers have. As you might imagine, any solution geared towards improving the security of an application is going to be complex, consisting of many different moving parts. Thus, forcing customers to hunt for the components they need within your product data sheets and overviews is not going to be an effective way to convince those customers that you have a solution they might be in the market for.

So what can vendors do to convince customers that they have a solution worth that customer’s time to evaluate? For starters, they can bundle various features into use cases that can be easily demonstrated to, evaluated, and consumed by customers. Along those lines, what would a bundle around the popular application security protection use case look like?

While not an exhaustive list, here are some thoughts:

  • App Proxy: Putting a proxy in front of applications is perhaps one of the most basic application security requirements, and for good reason. Having an intermediary allows us to inspect and monitor traffic going to and from the application, as well as to block or filter as necessary for security purposes.
  • Rate Limiting and Fast Access Control Lists (ACLs): Flooding a site is an old standby of attackers. It is a primitive, yet effective tactic. Rate limiting is a relatively straightforward way to prevent this type of attack. Similarly, fast-performing Access Control Lists (ACLs) are another effective way to keep unwanted traffic at bay.
  • Path Discovery: Applying machine learning (ML) to traffic transiting the environment allows us to track the rate of requests, the identity of clients accessing applications, the size of the payloads being sent, and other important telemetry elements. Using ML allows us to identify and block nefarious traffic before it becomes a more serious issue – often in minutes as opposed to hours.
  • Web Application Firewall: WAF has become a required technology for application providers and should be included as a part of any application security bundle.
  • L3/L4/L7 DDoS: DDoS protection has also become a requirement for application providers and should also be included as part of any application security bundle.
  • Bot Defense: Advanced bots that know how to get around the defenses listed above can cause application providers monetary loss and reputation damage. As such, bot defense should also be included as part of an application security bundle.
  • Auto-Certificates: Speed of deploying applications is essential for remaining competitive, as is speed of protecting those applications. The ability to auto-issue certificates and to auto-register DNS for resources saves time, allowing application providers to go from no protection to full protection in a matter of minutes.
  • Malicious User Detection: Another great application for machine learning (ML) is quickly understanding which users and patterns appear to be behaving maliciously. This is something that often takes application providers hours or days to identify. With ML, this can be done in minutes, allowing those application providers to quickly take action and block/mitigate.
  • Client-Side Defense: Visibility into the end-user environment is something many application providers lack. The ability to inspect how JavaScript is being called, where requests are going, and what third party scripts are being called gives important insight that is extremely helpful for application security purposes.
  • URI Routing: The ability to quickly and easily control where certain requests are routing gives application providers the ability to block/control specific endpoints (URIs). No application security solution would be complete without this important feature.
  • Service Policies: Quick and easy policy deployment is a must for application security. The ability to chain together service policies as needed based on requirements, along with the ability to generate custom rules for steering traffic or allowing/denying traffic beyond the capabilities of the other defensive capabilities is another essential part of the total application security package.
  • Synthetic Monitors: How are applications performing externally? What are my customers experiencing? These are important questions that synthetic monitors allow a business to answer, which can quickly identify any issues that might affect the application.
  • TLS Fingerprinting and Device Identification: While IP addresses change frequently, TLS fingerprints and device identifiers change much more rarely. Thus, basing policies and rules on them rather than IP address makes a lot of sense when it comes to application security.
  • Cross-Site Request Forgery Protection: Scripts that operate cross-site can cause serious problems for application providers. Thus mitigating the risk they present should be part of any application security bundle as well.

Securing applications is a top priority for nearly all businesses. While there are many routes to application security, bundles that allow security teams to quickly and easily secure applications and affect security posture in a self-service manner are becoming increasingly popular. These bundles inform application providers and allow them to make better, more informed decisions to improve security posture without introducing unnecessary friction to the end-user.

The post Application Security Protection for the Masses appeared first on SecurityWeek.

GitHub Revokes Code Signing Certificates Following Cyberattack


Code hosting platform GitHub on Monday announced the revocation of three digital certificates used for the GitHub Desktop and Atom applications.

The three certificates were stolen on December 6, 2022, after an unauthorized third-party used a compromised Personal Access Token (PAT) for a machine account to clone repositories from Atom, GitHub Desktop, and other deprecated GitHub-owned organizations. GitHub revoked the compromised credentials on December 7. 

“After a thorough investigation, we have concluded there was no risk to services as a result of this unauthorized access and no unauthorized changes were made to these projects,” the company says.

According to GitHub, the cloned repositories did not contain customer data, but several encrypted code signing certificates for use via Actions in GitHub Desktop and Atom release workflows were stored in them.

“The certificates were password-protected and we have no evidence of malicious use. As a preventative measure, we will revoke the exposed certificates used for the GitHub Desktop and Atom applications,” GitHub says.

The Microsoft-owned platform explains that the certificate revocation will invalidate some versions of GitHub Desktop for Mac and Atom, but will have no impact on GitHub Desktop for Windows.

Specifically, GitHub Desktop for Mac versions 3.0.2 to 3.1.2 and Atom versions 1.63.0 and 1.63.1 will stop working. GitHub Desktop for Mac users will need to update to the latest release, while Atom users will need to download a previous Atom version (Atom versions 1.63.0-1.63.1 have already been removed from the releases page).

“On Thursday, February 2, 2023, we will revoke the Mac & Windows signing certificates used to sign Desktop app versions 3.0.2-3.1.2 and Atom versions 1.63.0-1.63.1. Once revoked, all versions signed with these certificates will no longer function,” GitHub announced.

Because the stolen certificates do not appear to have been decrypted by the threat actor, they do not pose a risk to the existing GitHub Desktop and Atom installations but, if decrypted, they could allow the attackers to sign unofficial applications and pretend they were released by GitHub.

The impacted certificates include two Digicert certificates for Windows and one Apple Developer ID certificate. One Digicert certificate expired on January 4, while the other will expire on February 1. The Apple Developer ID certificate is valid until 2027.

“On January 4, 2023, we published a new version of the Desktop app. This version is signed with new certificates that were not exposed to the threat actor,” GitHub notes.

Related: Attackers Can Abuse GitHub Codespaces for Malware Delivery

Related: GitHub Introduces Automatic Vulnerability Scanning Feature

Related: GitHub Announces Free Secret Scanning, Mandatory 2FA

The post GitHub Revokes Code Signing Certificates Following Cyberattack appeared first on SecurityWeek.

Critical Vulnerabilities Patched in OpenText Enterprise Content Management System


Several vulnerabilities described as having critical and high impact, including ones allowing unauthenticated remote code execution, have been found and patched in OpenText’s enterprise content management (ECM) product.

The vulnerabilities were discovered by a researcher at cybersecurity consultancy Sec Consult in OpenText’s Extended ECM, which is designed for managing the distribution and use of information across an organization. Specifically, the flaws impact the product’s Content Server component.

The security firm this week published three different advisories describing its findings.

OpenText was informed about the vulnerabilities in October 2022 and patched them earlier this month with the release of version 22.4, according to Sec Consult.

One of the critical vulnerabilities, tracked as CVE-2022-45923, can allow an unauthenticated attacker to execute arbitrary code using specially crafted requests.

The second critical flaw, CVE-2022-45927, impacts the Java Frontend of the OpenText Content Server component and can allow an attacker to bypass authentication. Exploitation could ultimately lead to remote code execution.

Sec Consult has also identified five types of vulnerabilities in the Content Server component that can be exploited by authenticated attackers.

These issues, rated ‘high impact’, can be exploited to delete arbitrary files on the server, escalate privileges, obtain potentially valuable information, launch server-side request forgery (SSRF) attacks, and execute arbitrary code.

Proof-of-concept (PoC) code is available for the high-impact issues, but the advisories describing the critical flaws do not include PoC code in an effort to prevent malicious exploitation.

Related: Vendor Refuses to Remove Backdoor Account That Can Facilitate Attacks on Industrial Firms

Related: InfiRay Thermal Camera Flaws Can Allow Hackers to Tamper With Industrial Processes

Related: OpenText Acquires Email Security Firm Zix for $860 Million

The post Critical Vulnerabilities Patched in OpenText Enterprise Content Management System appeared first on SecurityWeek.

Credential Leakage Fueling Rise in API Breaches


There is a problem with API security – it isn’t working very well, and it’s largely down to credential leakage. Most security professionals are confident in their own API credential management; but at the same time, most of the same professionals admit to having experienced a breach effected through compromised API credentials.

read more