Application Security – Page 3 – CyberSecurity Confabulation

Application Security From Code to Cloud – An Interview with Lotem Guy at Cycode

Posted 2 years ago by cyberinsiders

In a recent interview with Lotem Guy, VP of Product at Cycode, providing an innovative Application Security Posture Management (ASPM) platform for code to cloud, we discussed the rapidly evolving landscape of application security. In recent years, application security has quickly expanded beyond mere code security, broadening the definition of modern application security.

“I think we see that the application security landscape has been getting wider and wider in the last couple of years. It’s not just about code security anymore, which is more of the historical application security definition,” Lotem added. The focus has shifted from just securing application code to embracing what Lotem refers to as “code to cloud”, encompassing everything from the code itself to the development pipeline and the deployment and runtime in the cloud.

Gaps in Security and the Rise of Modern Attacks

One of the most potent points in the interview revolves around the unaddressed areas of modern application security. While code and cloud appsec solutions have evolved, the areas in between remain a significant gap.

“But everything in between is really not covered, and when we see modern attacks today, they’re targeting exactly that, the non-covered areas of your software supply chain.”

The areas “in between code to cloud” refer to the entire software development lifecycle, encompassing all the stages and processes that code goes through from being written by developers to being deployed and run in a cloud environment.

Here’s a breakdown of those areas from a code and development point of view:

Source Code Management (SCM): This includes the repositories where code is stored, versioned, and managed. Secure handling of code at this stage is essential to prevent unauthorized access and code manipulation.
Continuous Integration/Continuous Deployment (CI/CD): CI/CD pipelines automate the building, testing, and deployment of code. This includes build automation, automated testing, integration with other parts of the software, and preparation for deployment. The Solarwinds and CodeCove attacks mentioned in the interview targeted the build process within this stage.
Third-Party and Open Source Code Integration: Modern development often relies heavily on third-party libraries and open-source components. Vulnerabilities in these components can introduce security risks.
Secrets Management: This refers to the handling of sensitive information like API keys, tokens, passwords, etc. If mishandled (such as hardcoded secrets), this can create significant vulnerabilities.
Configuration Management: Ensuring that all configurations across development, testing, and production environments are consistent and secure is crucial. This involves server configurations, network settings, and access controls.
Containerization and Orchestration: Many modern applications are containerized (using technologies like Docker) and orchestrated (using tools like Kubernetes). Misconfiguration at this stage can lead to vulnerabilities.
Cloud Deployment and Runtime Security: Once deployed to the cloud, applications need to be continuously monitored and secured against potential runtime vulnerabilities. This includes access control, encryption, monitoring, and logging.
Software Composition Analysis: Analyzing the components of the software, including third-party and open-source code, to identify potential vulnerabilities.
Collaboration and Productivity Tools Integration: The interview also touched on how secrets might be mishandled in tools like Confluence, Slack, and S3 buckets, which are often used to collaborate and share information across development teams.

The challenges highlighted in the interview emphasize that while there are distinct solutions for code security and cloud security, the “in between” areas encompassing these various stages and aspects of the development lifecycle are often less well-covered and protected.

These areas represent a broad and complex landscape with numerous potential weak points that malicious actors might target. Cycode’s approach aims to address these challenges by providing a comprehensive solution that spans these areas, offering a unified platform for managing and enhancing the security posture across the entire software supply chain.

Lotem brings up well-known examples like Solarwinds and ColdCove, where attackers exploited unsecured parts of the build process to plant backdoors, illustrating the need to secure the entire software supply chain.

Addressing Hardcoded Secrets

Cycode’s approach to resolving the issue of hardcoded secrets in cloud-based workspaces reveals a strong response to a common vulnerability: “So in this uncovered or area of the software supply chain, stealing secrets for attackers and using them to get inside an organization or just to get inside their services – it’s kind of the easiest and quickest win.”

Hard-coded secrets, such as passwords and API keys embedded directly into the source code, present significant security risks, including vulnerability to attacks, management complexity, and compliance issues. Lotem emphasized the importance of avoiding hard-coded secrets through the use of secret management tools, automated scanning for detection, collaboration and education among development and security teams, and, in some cases, encryption. These measures align with a broader shift towards integrating security early in the development cycle, mitigating the risks associated with this common yet critical vulnerability.

Cycode’s expanded detection capabilities, including integration with Confluence, AWS S3 buckets, and Azure, represent a proactive measure to identify and remediate those hidden risks.

Cycode’s Unified Platform and Client Impact

Lotem further highlights Cycode’s ASPM (application security posture management) platform, showcasing its breadth of capabilities. From code security and software composition analysis to CI/CD pipeline security and cloud security, Cycode integrates with various Software Development Lifecycle Tools, providing continuous analysis.

One particular success story he shares involves a large enterprise client that was able to prioritize risk management and remediation through Cycode’s platform, leading to significant time savings compared to traditional approaches. The enterprise has approximately 100,000 repositories across thousands of organizations within the company. This company previously struggled with a long-term development project that ultimately failed. With Cycode, they were able to scan and prioritize security issues across all repositories swiftly, implementing a comprehensive posture management system for code security. The integration enabled early risk identification, quick remediation, and unified management, significantly reducing their time to value and demonstrating Cycode’s capability to streamline security processes in complex environments.

Emphasizing Collaboration and “Controlled Shift Left”

An interesting concept discussed by Lotem is the “controlled shift left.” This concept in software development refers to a systematic integration of security practices early in the software development lifecycle. By embedding security during coding and design stages, this approach aims to identify and mitigate vulnerabilities earlier, reducing risks and potential costs. The “controlled” aspect emphasizes a balanced and tailored approach, fostering collaboration between development and security teams, continuous monitoring, and alignment with compliance requirements. This method allows for a blend of rapid development without compromising security and is part of Cycode’s emphasis on bridging the gap between code and cloud security.

Conclusion: Lotem’s Top 3 Best Practices

Lotem concluded the interview with three valuable pieces of advice for organizations that create cloud applications:

Coverage and Understanding Risks: Lotem emphasizes the importance of understanding the areas where an organization is not covered from a security perspective. By identifying the highest risks and the areas where attackers may have an advantage, organizations can prioritize and implement proper security measures. The goal is to ensure comprehensive protection across the development landscape, including previously neglected or overlooked areas.
Choosing the Right Tools: This piece of advice highlights the need for choosing security tools that are both effective and easy to operate. Every tool has an operational cost, so it’s essential to select tools that not only cover the vulnerabilities but also don’t create operational headaches. Ideally, these tools should also solve other operational challenges, providing a seamless integration within the development process.
Shifting Left and Collaboration: Lotem’s final advice underscores the importance of the “shift left” approach in application security, emphasizing the need for collaboration between security and R&D or development teams. By integrating security considerations early in the development cycle, and doing so in a controlled manner, organizations can be more effective in remediating risks. The key is to foster a culture where both developers and security professionals work together, ensuring that security becomes an integral part of the development process, rather than an afterthought or a hindrance.

The insights shared by Lotem Guy emphasized both the gaps and the solutions that are shaping modern application security. His perspective illuminates Cycode’s holistic approach to security, encompassing everything from hardcoded secrets to continuous scanning and the importance of controlled collaboration. The future of application security is in this integrated approach, where risks are not just identified but effectively managed and remediated across the entire development life cycle. For more information about Cycode, visit https://cycode.com

The post Application Security From Code to Cloud – An Interview with Lotem Guy at Cycode appeared first on Cybersecurity Insiders.

InsightAppSec Advanced Authentication Settings: Token Replacement

Posted 2 years ago by Shane Queeney

There are many different ways to use InsightAppSec to authenticate to web apps, but sometimes you need to go deeper into the advanced settings to fully automate your logins, especially with API scanning. Today, we’ll cover one of those advanced settings: Token Replacement.

InsightAppSec Token Replacement can be used to capture and replay Bearer Authentication tokens, JWT Authentication tokens, or any other type of session token.

The token replacement values are under your scan configs in the following location: Custom Options > Advanced > AuthConfig > TokenReplacementList

When you press Add, the following values can be set.

Name	Description	Possible Values
ExtractionTokenLocation	Where the token you want to extract is located.	Request HeaderRequest BodyRequest URLResponse HeadersResponse Body
ExtractionTokenRegex	Regex used to extract the token. Anything placed in brackets can be returned in the InjectionTokenRegex using @token@.	Any regex, such as:"token": ?"([^"])"access_token": ?"([-a-f0-9]+)"[?]sessionId=([^&])
InjectionTokenLocation	Where the captured token should be injected.	Request URLRequest HeadersRequest Body
InjectionTokenRegex	The format in which the token should be sent to the web app. @token@ is replaced with the value captured by ExtractionTokenLocation.	Any string. @token@ is replaced with the captured value. Such as:Authorization: Bearer @token@Authorization: Token @token@&sessionId=@token@

Why Token Replacement?

Under Custom Options > HTTP Headers > Extra Header, you can manually pass an authentication token to your web app. While this is the easiest way to set up this form of authentication, unless you generate a token that will not expire, you will have to replace this token every scan. Automating this process using token replacement will save you time and effort in the long run, especially if you have multiple apps you need to generate tokens for.

For this example, we will be using the Rapid7 Hackazon web app. If you want to configure your own Hackazon instance, details around installation and setup can be found here.

Alternatively, there are free public test sites you can use instead, such as this one.

The main difference you’ll encounter when using the Hackazon web app is the API authentication does not have a UI, therefore we must record and pass a traffic file for InsightAppSec to authenticate.

We will use Postman to send the API request to the web app and Burp Suite to record the traffic. You could alternately use the Rapid7 Insight AppSec Toolkit, to record the traffic as well. Here is a video running through setup using the InsightAppSec Toolkit.

The first step is to set up your proxy settings. In Postman, you can go to Settings by clicking the gear icon in the upper right, and then clicking into the proxy settings. We’re going to set the proxy server to “localhost” and change the port to “5000”.

After setting the proxy in Postman, you must set it up in Burp Suite. In Burp, go to the Proxy tab, then click on Proxy Settings. Next, add a proxy listener, specifying port 5000 to match the setting in Postman. Then, set the interface to Loopback Only.

Go back to Postman, add your basic authentication, and then send the traffic. In Burp, click on the HTTP History tab, right click on the captured traffic, then click “Save Item”. Make sure you save the traffic as an xml file.

You can also record the traffic using the Rapid7 Insight AppSec Plugin, or from within the Chrome browser. Instructions for how to do this are located under Traffic Authentication or can be found here.

When recording using the Rapid7 Appsec Plugin, make sure that the recording includes the Bearer Auth or Token in the recorded details.

After recording the login, upload the traffic file to Site Authentication. Make sure you adjust the Logged-In Regex as well to make sure the scan doesn’t fail.

After authenticating to your web app and grabbing the token, the next step is to configure a regex to ensure the token is able to be extracted. There are a wide variety of ways to test the regex, but we will be using https://regex101.com/ for this example.

We will then grab the web app response containing the token info, paste it into the website, and configure a regular expression to ensure only the token is selected. In this use case, the expression "token": ?"([^"]*) was successful in only highlighting the info we want to extract. We can ensure that only the token is selected in capture Group 1 as that will be returned when we specify @token@ under the InjectionTokenRegex.

Next, we want to configure the TokenReplacementList.

Name	Value	Reason
ExtractionTokenLocation	Response Body	The token appeared in the body after authenticating
ExtractionTokenRegex	"token": ?"([^"]*)	This successfully isolated the auth token
InjectionTokenLocation	Request Header	Where the web app is expecting the token
InjectionTokenRegex	Authorization: Token @token@	The header format the web app is expecting

Make sure you upload the swagger API file. You can either upload the file or point InsightAppSec to the specific URL. You can optionally restrict the scan to just the swagger file for more targeted scanning.

To ensure we were successful, click Download Additional Logs from the Scan Logs page after the scan is complete and open the Operation log file. You are looking for the log entry “[good]: Added imported token from response body”. Once you see this, you know the taken was imported into the scan properly and we were able to use it to log in to the API.

For further testing, you can look in the vulnerability traffic requests to ensure the Authorization: Token header has been passed successfully.

To detect if the token has expired, you can modify the sessionLossRegex and sessionLossHeaderRegex under Authentication > Additional Settings, or by using a CanaryPage if that has been set up. When configured correctly, the token replacement will grab the token again, ensuring we stay logged in to your API.

Further information on configuring Scan Authentication can be found here. When in doubt, please reach out to your web app developers and/or Rapid7 support for assistance.

Data Loss Prevention in an API-Driven World

Posted 2 years ago by cyberinsiders

By Sudeep Padiyar, Senior Director, Product Management at Traceable AI

Preventing data loss has become incredibly challenging in an application programming interface (API)-driven world. Companies lockdown sensitive data internally with access controls, encryption, data classification and data loss prevention (DLP) platforms. They typically safeguard web applications with application security tooling or Web Application Firewalls (WAF). Cloud Security is often implemented with dedicated secure access service edge (SASE) architectures, including cloud access security brokers (CASBs).

However, sensitive data is transmitted freely across internal and external APIs, increasing the risk of accidental or malicious exposure of different sensitive data types. And hackers that exploit APIs don’t just steal sensitive data, they also gain access to systems, infrastructures, and other key surfaces, potentially causing massive operational downtime. Data loss at the API layer needs to be high on the list of priorities for security and privacy teams in addition to protecting sensitive data with SASE, CASB solutions and NextGen firewalls.

Leading analysts and research firms have sounded the alarm about growing data security risks via API. Gartner has predicted that APIs will be the top attack vector this year, and that by 2025, more than half of all data thefts from enterprise web applications will be due to unsecure APIs. The OWASP API Security Project ranks excessive data exposure as the third most important API security risk. And recent data breaches also serve to warn peers of these issues. A single API hack on T-Mobile resulted in the data exposure of 37 million customers. Meanwhile, a Twitter API hack resulted in the release of personal data for 235 million users. The cost to remediate these attacks will far outpace the investment it would have taken to secure these APIs from the start.

Protect the Business by Securing APIs

Most enterprises use thousands of APIs to share data with applications and partners, and provide a seamless user experience for their customers. A phenomenon known as API sprawl, makes it difficult to gain visibility and control over these connections, in addition, frequent updates create versioning and documentation issues that further complicate API security.

APIs are now the universal attack vector, and they’re also a uniform protection layer if secured properly. Enterprises that deploy API security platforms gain fit-for-purpose tools that bring holistic visibility, monitoring, management, and remediation tools to bear on securing APIs and reducing risks.

Only context-aware API security platforms can accurately inventory APIs and detect behavioral anomalies that outwit traditional security tools such as WAFs and traditional DLP platforms. As an example, a grad student’s efforts to scrape millions of Venmo users’ financial transactions appeared as normal API traffic. Similarly, Coinbase’s improper API validation process enabled users to make unlimited cryptocurrency trades between accounts without being detected.

API security solutions should provide discovery and security posture management, threat protection, and threat management, enabling organizations to minimize risks and maximize the value that APIs provide. Tracking sensitive data usage across authenticated and unauthenticated APIs, and ensuring compliance requirements are met, has become an important aspect for Infosec teams.

Specifically, these capabilities prevent sensitive data exfiltration by:

Discovering all APIs: Leading API security platforms automatically and continuously discover all APIs, building a living inventory of all internal, private, public, externally exposed, rogue, shadow, partner, and third-party APIs. They catalog every API and its associated data and sensitive data flows, even as an enterprise’s environment changes constantly.
Improving API security posture management: Building on visibility gains, a next-generation API security platform creates a security risk profile for every API. Teams can use these insights to determine which APIs are most vulnerable to attacks and abuse, so that they can remediate them first.These platforms further reduce risks by identifying API endpoints that handle sensitive data but lack appropriate authentication or zero-trust API access policies. Teams can use this information to prioritize which APIs need greater security controls to protect the enterprise systems and data from threats and abuse.
Real-time threat protection: With detailed and contextual knowledge, leading API security platforms are well-equipped to automatically detect and remediate API and business logic use attacks, as well as API abuse, fraud, and sensitive data exfiltration from production environments.These innovative platforms establish a baseline of normal and abnormal behavior, quickly detecting any anomalies that could pose a security risk, such as a flood of incoming API calls from a foreign internet protocol (IP) address. They also correlate suspected incidents across multiple dimensions, such as endpoint, network, and application and API behavior, providing security teams with a holistic view of how attacks are distributed, organized, and progress over time. By doing so, leading API security platforms can create a unique fingerprint for each user that can be used to improve anomaly detection and fraud ring clustering.
Data Loss Prevention:

Data loss prevention software and tools monitor and control endpoint activities, filter data streams at API layer, and monitor data in the cloud to protect data at rest, in motion, and in use. API DLP needs to provide reporting to meet compliance and auditing requirements and identify areas of weakness and anomalies for forensics and incident response. This means all sensitive data transfer at the API layer needs to be monitored on a continuous basis to detect excessive data exposure based on multiple attributes like volume of sensitive data, source of traffic – BOT, Residential proxies, Geo location, connection types, IP reputation, etc.

Enhancing threat management: Modern API security platforms provide a rich set of security and application flow analytics that enable teams to reveal potentially unknown API threats and visualize user behavior analytics to uncover fraud and abuse. These tools and data empower teams, from security operations professionals, to incident responders, threat hunters, and red and blue teams, to improve processes. These individuals gain insights they can use to optimize APIs and security behaviors to prevent data breaches, ransomware attacks, API abuse, and data exfiltration.

Start Securing APIs Today with a Best-in-Class Platform

The best time to begin securing APIs is today, before malicious individuals or groups gain control over these vital connections and use them to harm your business. Only modern API security platforms can provide holistic visibility and tools to monitor and mitigate these risks in real-time. These solutions enable you to discover all APIs, improve security posture management, protect against threats, protect your critical data, enhance threat management, and build a culture of continuous improvement.

It is vital for any business to continue fueling business growth by securely deploying and managing APIs with a fit-for-purpose API security platform, while protecting your business and customers from debilitating attacks and data theft.

The post Data Loss Prevention in an API-Driven World appeared first on Cybersecurity Insiders.

OWASP TOP 10 API Security Risks: 2023!

Posted 2 years ago by Ray Cochrane

The OWASP Top 10 API Security Risks 2023 has arrived! OWASP's API Top 10 is always a highly anticipated release and can be a key component of API security preparedness for the year. As we discussed in API Security Best Practices for a Changing Attack Surface, API usage continues to skyrocket. As a result, API security coverage must be more advanced than ever.

What are the OWASP Top 10 API Security Risks?

The OWASP Top 10 API Security Risks is a list of the highest priority API based threats in 2023. Let’s dig a little deeper into each item on the OWASP Top 10 API Security Risks list to outline the type of threats you may encounter and appropriate responses to curtail each threat.

1. Broken object level authorization

Object level authorization is a control method that restricts access to objects to minimize system exposures. All API endpoints that handle objects should perform authorization checks utilizing user group policies.

We recommend using this authorization mechanism in every function that receives client input to access objects from a data store. As an additional means for hardening, it is recommended to use cryptographically secure random GUID values for object reference IDs.

2. Broken authentication

Authentication relates to all endpoints and data flows that handle the identity of users or entities accessing an API. This includes credentials, keys, tokens, and even password reset functionality. Broken authentication can lead to many issues such as credential stuffing, brute force attacks, weak unsigned keys, and expired tokens.

Authentication covers a wide range of functionality and requires strict scrutiny and strong practices. Detailed threat modeling should be performed against all authentication functionality to understand data flows, entities, and risks involved in an API. Multi-factor authentication should be enforced where possible to mitigate the risk of compromised credentials.

To prevent brute force and other automated password attacks, rate-limitation should be implemented with a reasonable threshold. Weak and expired credentials should not be accepted, this includes JWTs, passwords, and keys. Integrity checks should be performed against all tokens as well, ensuring signature algorithms and values are valid to prevent tampering attacks.

3. Broken object property level authorization

Related to object level authorization, object property level authorization is another control method to restrict access to specific properties or fields of an object. This category combines aspects of 2019 OWASP API Security’s “excessive data exposure” and “mass assignment”. If an API endpoint is exposing sensitive object properties that should not be read or modified by an unauthorized user it is considered vulnerable.

The overall mitigation strategy for this is to validate user permissions in all API endpoints that handle object properties. Access to properties and fields should be kept to a bare minimum at an as-needed basis scoped to the functionality of a given endpoint.

4. Unrestricted resource consumption

API resource consumption pertains to CPU, memory, storage, network, and service provider usage for an API. Denial of service attacks result from overconsumption of these resources leading to downtime and racked up service charges.

Setting minimum and maximum limits relative to business functional needs is the overall strategy to mitigating resource consumption risks. API endpoints should limit the rate and maximum number of calls at a per-client basis. For API infrastructure, using containers and serverless code with defined resource limits will mitigate the risk of server resource consumption.

Coding practices that limit resource consumption need to be in place, as well. Limit the number of records returned in API responses with careful use of paging, as appropriate. File uploads should also have size limits enforced to prevent overuse of storage. Additionally, regular expressions and other data-processing means must be carefully evaluated for performance in order to avoid high CPU and memory consumption.

5. Broken function level authorization

Lack of authorization checks in controllers or functions behind API endpoints are covered under broken function level authorization. This vulnerability class allows attackers to access unauthorized functionality; whether they are changing an HTTP method from a `GET` to a `PUT` to modify data that is not expected to be modified, or changing a URL string from `user` to `admin`. Proper authorization checks can be difficult due to controller complexities and the numbers of user groups and roles.

Comprehensive threat modeling against an API architecture and design is paramount in preventing these vulnerabilities. Ensure that API functionality is carefully structured and corresponding controllers are performing authentication checks. For example, all functionality under an `/api/v1/admin` endpoint should be handled by an admin controller class that performs strict authentication checks. When in doubt, access should be denied by default and grants should be given on a as needed basis.

6. Unrestricted Access to Sensitive Business Flows

Automated threats are becoming increasingly more difficult to combat and must be addressed on a case-by-case basis. An API is vulnerable if sensitive functionality is exposed in such a way that harm could occur if excessive automated use occurs. There may not be a specific implementation bug, but rather an exposure of business flow that can be abused in an automated fashion.

Threat modeling exercises are important as an overall mitigation strategy. Business functionality and all dataflows must be carefully considered, and the excessive automated use threat scenario must be discussed. From an implementation perspective, device fingerprinting, human detection, irregular API flow and sequencing pattern detection, and IP blocking can be implemented on a case-by-case basis.

7. Server side request forgery

Server side request forgery (SSRF) vulnerabilities happen when a client provides a URL or other remote resource as data to an API. The result is a crafted outbound request to that URL on behalf of the API. These are common in redirect URL parameters, webhooks, file fetching functionality, and URL previews.

SSRF can be leveraged by attackers in many ways. Modern usage of cloud providers and containers exposes instance metadata URLs and internal management consoles that can be targeted to leak credentials and abuse privileged functionality. Internal network calls such as backend service-to-service requests, even when protected by service meshes and mTLS, can be exploited for unexpected results. Internal repositories, build tools, and other internal resources can all be targeted with SSRF attacks.

We recommend validating and sanitizing all client provided data to mitigate SSRF vulnerabilities. Strict allow-listing must be enforced when implementing resource-fetching functionality. Allow lists should be granular, restricting all but specified services, URLs, schemes, ports, and media types. If possible, isolate this functionality within a controlled network environment with careful monitoring to prevent probing of internal resources.

8. Security misconfiguration

Misconfigurations in any part of the API stack can result in weakened security. This can be the result of incomplete or inconsistent patching, enabling unnecessary features, or improperly configuring permissions. Attackers will enumerate the entire surface area of an API to discover these misconfigurations, which could be exploited to leak data, abuse extra functionality, or find additional vulnerabilities in out of date components.

Having a robust, fast, and repeatable hardening process is paramount to mitigating the risk of misconfiguration issues. Security updates must be regularly applied and tracked with a patch management process. Configurations across the entire API stack should be regularly reviewed. Asset Management and Vulnerability Management solutions should be considered to automate this hardening process.

9. Improper inventory management

Complex services with multiple interconnected APIs present a difficult inventory management problem and introduces more exposure to risk. Having multiple versions of APIs across various environments further increases the challenge. Improper inventory management can lead to running unpatched systems and exposing data to attackers. With modern microservices making it easier than ever to deploy many applications, it is important to have strong inventory management practices.

Documentation for all assets including hosts, applications, environments, and users should be carefully collected and managed in an asset management solution. All third-party integrations need to be vetted and documented, as well, to have visibility into any risk exposure. API documentation should be standardized and available to those authorized to use the API. Careful controls over access to and changes of environments, plus what's shared externally vs. internally, and data protection measures must be in place to ensure that production data does not fall into other environments.

10. Unsafe consumption of APIs

Data consumed from other APIs must be handled with caution to prevent unexpected behavior. Third-party APIs could be compromised and leveraged to attack other API services. Attacks such as SQL injection, XML External Entity injection, deserialization attacks, and more, should be considered when handling data from other APIs.

Careful development practices must be in place to ensure all data is validated and properly sanitized. Evaluate third-party integrations and service providers’ security posture. Ensure all API communications occur over a secure channel such as TLS. Mutual authentication should also be enforced when connections between services are established.

What's next?

The OWASP Top 10 API Security Risks template is now ready and available for use within InsightAppSec, mapping each of Rapid7’s API attack modules to their corresponding OWASP categories for ease of reference and enhanced API threat coverage.

Make sure to utilize the new template to ensure best in class coverage against API security threats today! And of course, as is always the case, ensure you are following Rapid7’s best practices for securing your APIs.

The Rush to SaaS Modernization Can Result in Reputational Damage

Posted 2 years ago by cyberinsiders

By Hananel Livneh, Head of Product Marketing, Adaptive Shield

Successful cyberattacks tend to hit companies with the force of an 80-foot wave. The initial damage is quickly apparent. Like ships that lose railings and experience instability, businesses are immediately faced with lost data, ransom payments, and revenue losses, depending on the nature of the attack.

It isn’t until later that the real damage can be assessed. Structural damage to the bow, aft, and bottom of the boat can render the ship unusable. Likewise, the damage to a company’s reputation can be severe.

Trust is one of the key elements in the customer relationship. When cyberattacks lead to data breaches and the publication of personal information, trust is eroded, resulting in additional fallout from the attack – the loss of customers.

These breaches can be a big deal. According to IBM’s Cost of a Data Breach Report 2022, the average company sees a $1.42M drop in business as a result of a breach. This lost business, ascribed to reputational damage, is often unrecoverable as customers move on to competitors who appear to be more careful with their data.

Most businesses understand that loss of confidence leads to eroding trust which turns into a loss of customers. What they fail to understand is that without proper security measures in place, the SaaS stack can be the target of an attack.

Breaching the SaaS App

SaaS applications are the darlings of the business world. They promise – and deliver – low-cost technology solutions that don’t require maintenance and can be used by anyone, anywhere. That’s why the SaaS market is projected to grow from $251 billion in 2022 to $883 billion by 2029.

However, there is a dark side to SaaS applications. The anytime, anywhere nature of SaaS apps coupled with collaborative tools makes them accessible to threat attackers and vulnerable to breaches.

There are a myriad of ways threat actors can access a SaaS application. Sophisticated phishing attacks on employees, keylogger malware on devices with poor hygiene, stealing session tokens from authenticated endpoints, and attempted entry via brute force attacks, to name just a few. Threat actors are constantly looking for new ways to gain access to the SaaS stack.

Malicious third-party applications can provide access to everything stored on the organization’s cloud-storage drive. Even non-malicious SaaS-to-SaaS access can be weaponized and provide threat actors with access.

Reputational Damage Impacts Every Vertical

Once SaaS applications are breached and data has been compromised, it is only a matter of time before the story hits the media because often, government mandates require disclosure. HIPAA laws require US healthcare facilities to notify prominent media outlets when breaches impact more than 500 patients. Financial Institutions are required to report certain data breaches within 36-72 hours. Proposed legislation would require publicly traded tech companies to disclose breaches within 4 business days.

The impact these disclosures have on companies is severe. Patients lose faith that their protected health information (PHI) is safe, while bank customers question their financial institution’s ability to secure their funds and tech stockholders invest their money in more reliable companies.

Customers often churn away from companies that are incapable of securing their data, leading to drops in market share and revenue. Vendors and partners tend to shy away from victimized companies, afraid to be associated with companies that are now notoriously poor with securing data and holding onto their secrets. Optus, Australia’s second largest telecom provider, saw 10% of their customers churn in the month after the attack, and surveys showed that 56% were considering changing their service provider in response to the attack.

Preventing a SaaS Disaster

Attempted SaaS breaches don’t have to end catastrophically. Most breaches are fully preventable. SaaS applications are remarkably secure, with an array of security settings fully capable of denying access to threat actors, but their security measures are only effective when deployed correctly.

Solutions like SaaS Security Posture Management (SSPM) platforms can prevent data breaches by identifying high-risk settings and alerting security teams when they need to be updated. They also review third-party connected apps, and detect threats before they become full-blown breaches. These automated platforms oversee the entire SaaS stack, rather than just a handful of top-priority SaaS apps.

While there are some activities that may limit the damage caused by a cyberattack, investing in SaaS security tools is the first step. SSPMs protect data as they detect threats, identify high-risk misconfigurations, and monitor risk from third party applications.

The post The Rush to SaaS Modernization Can Result in Reputational Damage appeared first on Cybersecurity Insiders.

Lessons From the Fortune 100 About Cloud-Native Application Security

Posted 2 years ago by cyberinsiders

By Ratan Tipirneni, President and CEO, Tigera

While cloud-native technologies are relatively new to many businesses, Global 2,000 companies have run containers and distributed applications at scale for over a decade. Although these household-name companies are high-profile targets for hackers, they have avoided devastating security incidents. This is evidence of their holistic security strategies and advanced tactics.

Based on our work with them, here are a few lessons other businesses can apply to cloud-native application security.

Take a zero-trust approach

First and foremost, these companies have adopted a zero-trust approach. Choosing zero trust as the foundational pillar is one way Fortune 100 companies keep their environments secure. In a zero-trust model, everything is denied access by default except the things that need to be able to communicate. Zero trust is crucial in securing distributed applications and containers, as it prevents threats from sneaking in as they are deployed and maintained. It is nearly impossible to secure these environments without a zero-trust foundation.

The concept of zero trust has existed for many years, long before it was named or widely adopted. Zero trust exemplifies the importance of returning to the basics and learning from successful companies rather than chasing after new solutions that often overpromise and underdeliver.

Address infrastructure and security holistically

In addition to a zero-trust approach, companies that have secured their cloud-native environments take a holistic approach to security. Hackers and bad actors do not always target the most obvious entry points and can find–and exploit–vulnerabilities in any open door or window. Therefore, it is crucial to secure all potential attack vectors. This requires a comprehensive approach to security rather than focusing on just a few key areas.

Treat security as code

Another key lesson from these leading companies is the importance of treating security as code. Unless security and IT leaders treat security as code, they initially configure security to secure all their doors and windows, but once they get into the day-to-day operations, it is only a matter of time before one of those points of entry flips open.

With a security-as-code approach, security is programmed in along with the software so that the security controls move wherever the software goes. Incorporating security into the development process and treating it as an integral part of the software makes it much easier to ensure that security controls are consistently applied. This is particularly important in cloud-native environments, where applications and infrastructure constantly evolve and change.

Strip down infrastructure and rebuild it

We work with a customer who completely strips down their entire infrastructure and rebuilds it regularly. They clean their entire stack every three weeks and reinstall through automated scripts. Stripping down their infrastructure flushes out potential threats that may have infiltrated the application or infrastructure. However, doing this on a large scale requires a high degree of automation and underscores the need to treat everything as code. Without treating security as code, the highly advantageous ability to rebuild that stack on an ongoing basis would be infeasible.

Democratizing this level of security

Fortune 100 companies have been running cloud-native apps at scale for years; they started long before the current array of cloud-native security solutions was available. These companies had the monetary resources and talent pool to build their own solutions and processes. Now, cloud-native technology adoption has exploded, and smaller teams and companies are using cloud-native solutions for daily operations.

The same level of security the Fortune 100 has achieved should be available to companies across the globe. The next step in cloud-native security solution development should be taking what these leading companies have done, codifying it, packaging it into a repeatable solution, and rolling it out as a service so that smaller organizations can use it to secure their environments.

Security is an ongoing process

As the threat landscape changes and evolves, businesses must constantly re-evaluate and adapt their security measures to stay ahead of potential threats. Security is not a one-time effort; it’s an ongoing process that organizations of all sizes must prioritize. By learning from the successes of Fortune 100 companies, businesses can adopt best practices and build a secure foundation for their cloud-native environments.

Author Bio

Ratan Tipirneni is President & CEO at Tigera, where he is responsible for defining strategy, leading execution, and scaling revenues. Ratan is an entrepreneurial executive with extensive experience incubating, building, and scaling software businesses from early stage to hundreds of millions of dollars in revenue. He is a proven leader with a track record of building world-class teams.

The post Lessons From the Fortune 100 About Cloud-Native Application Security appeared first on Cybersecurity Insiders.

API Security Takes Center Stage: Key Insights from RSA 2023

Posted 2 years ago by cyberinsiders

The RSA Conference 2023 witnessed a surge of interest in API security, with experts and industry leaders focusing on the increasing need to secure APIs and address vulnerabilities. As APIs continue to play a crucial role in connecting applications and data sources, especially in cloud environments, protecting them has become a top priority.

The Cloud Security Alliance (CSA) reported that “Insecure Interfaces and APIs” ranked second among the top threats to cloud computing, as cited in a recent survey of 700 security professionals. This marks a significant rise from its seventh-place position in a similar 2019 survey. The findings echo a report by Aimpoint Group, W2 Research, and CISO Connect, which revealed that 42% of 400 chief information security officers (CISOs) identified API security as their primary concern.

Several vendors showcased their API security solutions at the conference. Cequence Security, a leading company in the field, launched API Spyder, a cutting-edge tool that assesses the vulnerability of a customer’s APIs from an attacker’s viewpoint. The firm has experienced considerable growth in recent years, with many businesses investing heavily in API security following high-profile breaches at organizations like Peloton, Clubhouse, and John Deere.

Another participant, Noname Security, introduced version 3.0 of its API Security Platform, which offers a suite of features aimed at helping security teams manage APIs with the highest security standards. Meanwhile, Salt Security, a competitor in the space, highlighted its API Protection Platform’s new advanced threat detection capabilities and enhanced API discovery features. The company’s platform has gained recognition in the industry, earning it the coveted tech unicorn status after securing $140 million in Series D funding in February 2022.

Emerging startups like Traceable AI are also making waves in the sector, with the two-year-old company recently securing $60 million in Series B funding for its API security tracking solution. As the demand for robust API protection grows, investors are expected to show continued interest in API security startups.

The RSA Conference 2023 highlighted the industry’s mounting focus on API security as organizations strive to protect their applications and data from increasingly sophisticated cyber threats.

Notable API Security Vendors

In today’s digital landscape, APIs have become crucial components of modern applications, facilitating seamless integration and communication between various services. As a result, securing APIs has emerged as a critical aspect of ensuring data privacy and system stability. To help you navigate the API security space, we’ve compiled a list of notable API security vendors, each offering unique solutions to protect your organization’s APIs.

Cequence Security
Cequence Security offers an AI-powered Unified API Protection (UAP) solution, which helps organizations discover all APIs and ensure compliance with industry and government regulations while detecting and preventing automated attacks in real-time. Cequence Security’s approach to API security has garnered significant attention, including strategic investments from Hewlett Packard Enterprise and Prosperity7 Ventures. Website: https://www.cequence.ai/
Noname Security
Noname Security’s API Security Platform provides organizations with a comprehensive solution to protect their APIs. Its platform includes a range of features that help security teams manage APIs while ensuring top security. Version 3.0 of the platform brings added functionality to secure APIs effectively. Website: https://www.nonamesecurity.com/
Salt Security
Salt Security’s API Protection Platform leverages patented AI algorithms to provide advanced threat detection capabilities and improved API discovery. The platform focuses on delivering insights that distinguish API changes from API attacks, reducing false positives and accurately identifying true positives. Website: https://salt.security/
Traceable AI
Traceable AI is an emerging startup that offers an API security tracking solution. The company’s platform helps businesses monitor their API usage and detect potential security vulnerabilities, attracting significant investor interest, including $60 million in Series B funding. Website: https://traceable.ai/
Akamai
Akamai is a global content delivery network, cybersecurity, and cloud service company that provides API Gateway services. Their API Gateway secures, manages, and scales APIs with features like caching, logging, request/response transformation, and authentication. Website: https://www.akamai.com/
Okta
Okta is an identity and access management company that offers API Access Management, enabling organizations to securely manage access to APIs. Okta’s platform helps developers build secure, scalable, and user-friendly applications by providing centralized access control and management for APIs. Website: https://www.okta.com/
42Crunch
42Crunch offers an API security platform focused on securing APIs throughout the entire API lifecycle. The platform provides features like auditing, compliance monitoring, and threat protection. It allows organizations to implement security measures during the development process and maintain security across their API ecosystem. Website: https://www.42crunch.com/
Imperva
Imperva is a cybersecurity company that provides API security solutions through its API Security product. Imperva’s solution secures APIs with features such as API discovery, threat protection, and compliance monitoring. The platform integrates with existing DevOps workflows and protects against various API attacks. Website: https://www.imperva.com/
Data Theorem
Data Theorem offers API security solutions that focus on protecting mobile, web, and API-based applications. The company’s API Discover and API Inspect products help organizations discover, analyze, and secure their APIs in real-time. Data Theorem’s platform is designed to identify and remediate potential security risks. Website: https://www.datatheorem.com/
APIsec
APIsec offers an innovative API security testing platform designed to identify vulnerabilities and ensure compliance with industry and government regulations. Their solution focuses on automating security testing, integrating seamlessly into the development process, and continuously monitoring APIs in production. With a robust range of features and advanced analytics, APIsec enables organizations to detect and prevent potential security breaches effectively. Learn more about APIsec’s unique approach to API security at https://www.apisec.ai/.
Neosec
Neosec is an API security provider specializing in discovering, securing, and monitoring APIs throughout their lifecycle. Their platform uses machine learning and artificial intelligence to analyze API traffic, identify vulnerabilities, and detect potential threats in real-time. Neosec’s solution emphasizes the importance of visibility and control, allowing security teams to manage and protect APIs with ease. To find out how Neosec is redefining API security, visit their website at https://www.neosec.ai/
Wallarm
Wallarm is a leading API security vendor that offers a comprehensive platform for protecting APIs from a wide range of threats. Their solution leverages machine learning and advanced algorithms to automatically detect vulnerabilities and secure API endpoints. With a focus on real-time monitoring, automated threat detection, and seamless integration into existing infrastructure, Wallarm enables organizations to strengthen their API security posture effectively. Discover more about Wallarm’s innovative approach to API protection at https://www.wallarm.com/.
Apigee
Apigee, a part of Google Cloud, is a well-established API management and security platform that helps organizations design, secure, and scale APIs. Apigee provides a range of tools and features to ensure secure API development, deployment, and monitoring. With robust security measures, including API authentication, access control, and threat protection, Apigee empowers businesses to build and maintain secure APIs in an ever-evolving digital landscape. Learn more about Apigee’s comprehensive API security offerings at https://cloud.google.com/apigee/.

In conclusion, the growing prominence of API security in the industry, as demonstrated by the recent announcements and developments at RSA 2023, highlights the urgent need for businesses to prioritize protecting their APIs. As cyber threats evolve and become more sophisticated, investing in robust API security solutions will be essential for organizations to safeguard their applications and sensitive data. By staying informed about the latest API security trends and leveraging the expertise of leading vendors in the space, businesses can proactively fortify their defenses and navigate the digital landscape with confidence.

The post API Security Takes Center Stage: Key Insights from RSA 2023 appeared first on Cybersecurity Insiders.

Troubleshooting InsightAppSec Authentication Issues

Posted 2 years ago by Shane Queeney

For complete visibility into the vulnerabilities in your environment, proper authentication to web apps in InsightAppSec is essential. In this article, we’ll look at issues you might encounter with macro, traffic, and selenium authentication and how to troubleshoot them. Additionally, you’ll get practical and actionable tips on using InsightAppSec to its full potential.

The first step to troubleshooting InsightAppSec authentication is to look over the scan logs. The scan logs can be located under the scan in the upper left hand corner. The logs can give you useful information such as if the authentication fails, the website is unavailable, or if any other problems arose during the scan.

Event log will give you information about the scan itself.
Platform event log will give you information about the scan engine and if it encountered any issues during the scan.
Download additional logs: If you wanted to dive even deeper into what happened during the scan, you can to to look into the full scan logs.

Let’s look at some of the specific issues you might encounter with the different types of authentication noted above.

Macro Authentication

When a macro fails, the logs will give you the specific step where the macro had trouble. For example, in the image below, we can see that the macro failed on step 4, where it could not click on the specific object on the page. This could be caused by the page not loading quick enough, the name or ID of the element path changing, or the web app UI being different.

If you determine that the macro failed because the page isn’t loading fast enough, there are two ways you can slow the macro down.

The first way is to manually add a delay between the steps that are running too quickly. You can copy any of the delays that are currently in the macro, paste them into the spot that you want to slow down, and then change the step numbers. This way you can also set the specific duration for any delays you add into your macro.

The second way is to add additional delays throughout the macro, and change the Min Duration so the delays last longer. This is controlled via the export settings menu on the right. The default minimum duration is set to 3,000 milliseconds (3 seconds). Increasing the duration or adding delays will cause the macro to take longer to authenticate, but when running a scan overnight an extra few minutes to ensure the login works is a good tradeoff.

One other potential problem when recording a macro is when you have a password manager autofill the username and password. Anything that is automatically filled in will not be recorded by the macro. It is recommended to either turn off any password managers when recording a macro, or recording in Incognito/private browsing with all other plugins disabled to ensure nothing can modify or mess with the recording.

Lastly, if you have any events on your web app, such as a prompt to join a mailing list, that does not happen every time, you can mark that macro event as optional. If the event is not marked optional, then the macro will fail as it is unable to see the element on the page. Simply change the optional flag in the macro recording from 0 to 1 and you’re all set.

Traffic Authentication

While traffic authentication is usually successful when the login is working, there could still be some problems with playback. When traffic authentication fails, the scan logs don’t give you specific information like with macro authentication. Instead, the traffic authentication fails with the LoggedInRegex did not detect logged in state error. If you can’t get the traffic authentication working in the Rapid7 Appsec Plugin, you can always record the authentication within your browser.

For Chrome:

Click on the hamburger menu in the upper right.
Go to More Tools → Developer Options
Click on Network in the top tab
Make sure the dot in the upper left is red to signify you are recording.
Log in to your web app and when complete, right click on the recorded traffic and click Save all as HAR with content.

This will download the same .HAR file that the Appsec Plugin records, allowing you to use it for scanning.

Depending on how your web app responds, you might need to change the Use agent setting for how InsightAppsec interacts with your app.

Under your scan configuration, if you go to advanced options → HTTP Headers → User agent, you can then change what user agent is used to reach out to your web app. The latest version of Chrome should be fine for most modern web apps, but if you’re scanning a mobile app or an app that hasn’t been updated in a few years it might benefit from being changed.

Additional information can be found here.

Selenium Authentication

The third primary type of authentication is selenium. Selenium is similar to the macro authentication where you record all the actions to log in to your web app. Selenium is similar to traffic authentication where you will usually receive the LoggedInRegex did not detect logged in state error in the scan logs rather than specific information about the failure.

If the Selenium script could not find specific elements on the web page, you could also receive the Could not execute Selenium script error. This means there’s a problem with the script itself, the page didn’t load fast enough, or it couldn’t find the specific element on the web page. If this happens, try re-recording the script or adding a delay.

Using the plugin to record selenium scripts:

Click on the selenium plugin and Record a new test in a new project.
Give the project a name and enter in the base URL where you want recording to start.
In the new window that appears, log in to your web app. Once complete, close out of the window.
Before saving, you can click on the play icon to replay and test your selenium script.
Review the recording and then click on the save button in the upper right. You can then upload the .side file into InsightAppSec.

Just like macro authentication, if your website takes a while to load and the selenium script is running too fast, you can add additional delays to slow it down. There are implicit waits built into the IDE commands but if those don’t work for you, after running the authentication, you can add in wait for element commands to your selenium script.

Right click on the selenium recording and click insert new command
Set the command to wait for element visible
Set the target to the element you want to wait for. In this case, we’re waiting for id=email
By default the value is set to wait for 30,000 milliseconds (30 seconds)

Alternatively, you can use the pause command and set the value to how long you want the script to pause for. However, it is recommended to use the wait for element visible command if the web app responds at different times.

Additional information can be found here.

Logged-In Regex Errors

After ensuring the macro, traffic, and selenium files are working correctly, the next step in the authentication process is the logged-in regex. After the login is complete, InsightAppSec will look at the web page to find a logout button or look at the browser header for a session cookie. This can be modified by clicking into the scan configuration, navigating to the Authentication tab, and clicking on Additional Settings on the left.

Logged-in Regex

By default, the logged-in regex looks for sign out, sign off, log out and log off, with and without spaces between the words, on the web page.

One common problem is logged-in regex not seeing the logout button on the page before ending the authentication recording. If the logout button is on another page, or sometimes under a dropdown menu, the logged-in regex won’t detect it on the page, causing the authentication to fail.

Another common issue is if the logout button is an image or otherwise can’t be detected on the page. As the field is looking for a regular expression, you can use other words on the page to determine that the login was successful. You have to ensure that the word only appears on the page after logging in, such as the username. Otherwise the login might not actually be successful.

Logged-in Header Regex

Depending on how your web app is structured, you might need to use the logged-in header regex instead. For example, if there is no logout button, or if you have a single page web app that calls javascript files, the logged-in regex is more likely to fail. What you can do instead is grab the session ID cookie from the web browser, and if that is detected, then the regex will be successful.

In Chrome:

Click on the three dots in the upper right corner
Then go to more tools and then developer options.
Click on the application tab at the top, then cookies on the left, and finally the web app cookie.
From there you want to find the session information cookie that only appears after logging in to the web app. Grab the name of the cookie and place that in the logged-in header regex.

The logged-in regex and logged-in header regex use AND logic, so if you put information in both fields, it will then need both to be successful in order for the login to work. Alternatively, if you remove the regex from both fields, it won’t run any post authentication checks, assuming the login is successful. It is recommended to do that as a last resort, you won't be alerted if the login does start failing or if there are any other problems.

Other common issues and tricks

One issue you might encounter is where you start the authentication recording. For example, starting the recording after a page redirect. If your web app redirects to another page or SSO, and you start the authentication recording after the redirect, InsightAppSec won’t have the session information to properly redirect back to the target web app when it gets replayed during the scan. It is recommended to always start your recording on the root web app directory wherever possible.

You can also choose specific directories for scanning versus the entire web app. You want to remove the URL from the app Target URLs, and add it in specifically under the scan config. You can then set the target directory in the crawl and attack configs as literal, and then add a /* wildcard to hit any subdirectories.

Lastly, there is a way to restrict certain elements on a web page from being scanned. Under advanced options → CrawlConfig and AttackerConfig, there’s an option called ScopeConstraintList. This is where you can explicitly include or exclude specific pages from being scanned. You can take it a step further by adding a httpParameterList to explicitly exclude certain elements on the page from being scanned. For example, if you have a contact us page and you don't want the scanner to hit the submit button, you can add it to the httpParameterList so it won’t be touched.

Below is an example of what the fields look like in the web page source code, and how it can be configured in IAS.

Email field source code: input type="email" name="contact_email"

Submit button source code: <button id="form-submit"

The entire site is in scope, and we are telling IAS not to hit the submit button or the email field.

You can find the Selenium and AppSec plugins below:

The Four Keys to Achieving an Optimal Application Experience

Posted 2 years ago by cyberinsiders

By Larry Goldman, Senior Manager of Product Marketing, Progress

To this point, many businesses have failed to look at application experience (AX) management holistically, as its own challenge with its own set of distinct––and interlocking––solutions. This oversight has been to their detriment.

The fact is that every second of lag time on an online banking app risks alienating the consumer. Every glitch on an e-commerce app risks sending the consumer to a competitor. Multiplied out over thousands or millions of touchpoints and interactions, interruptions like these can lead to incalculable losses in both revenue and reputation. Skimping on any one aspect of AX management inevitably leaves businesses open to both financial and reputational harm.

Managing AX the right way means knowing precisely what’s happening in your infrastructure and network at all times. It means having a firm, real-time grasp of how your applications are performing. It means, crucially, being hyper-prepared for potential threats––ready to intervene at any sign of an anomaly.

These four quadrants––infrastructure monitoring and network visibility; security and app performance––intersect and overlap. Without careful attention to all four, no application can hope to compete in today’s marketplace.

Infrastructure monitoring and network visibility

Before you set off in a car, you’re going to want to make sure that the engine works and the brakes are intact. That’s infrastructure monitoring. Run an application on a faulty infrastructure and it’s likely to crash and burn. Proper infrastructure monitoring means knowing precisely how your hardware’s running at all times––your servers, your virtual machines, your routers, and your switches. How’s your memory looking? Is the performance of a certain server running slow? When questions like these are answered instantaneously––and anomalies are automatically flagged and reported––you greatly minimize the odds of disruption or disaster.

Of course, many application performance problems can’t be explained by infrastructure alone. On those occasions, you’re going to need to know what’s happening with your network traffic.

Network visibility is precisely what it sounds like: granular insight into precisely what’s happening on your network. When network visibility is inadequate or partial, routine application problems can quickly spiral. IT scrambles to find the source of the problem as customers get frustrated (best-case scenario) or bad actors worm deeper and deeper into your system (worst-case scenario). Addressing issues on a case-by-case basis is untenable in today’s digital environment: you need total network visibility, 24/7.

Network visibility accounts for the information of everyone who interacts with your servers––from their IP address and protocol to the amount of time they’ve spent on your network. When network visibility is comprehensive, there are no surprises: IT can be made aware of suspicious activity before it becomes a real problem. Your application experience, accordingly, stays fast, reliable, secure and seamless.

Why it all matters: security and application performance

It’s essential to drive home the two main reasons that infrastructure visibility and network monitoring are so important for seamless AX: security and application performance.

Let’s start with security. In the last few years, fueled partly by the pandemic, internet traffic has exploded, growing at an annual rate of 30% between 2018 and 2022. Meanwhile, bad actors are more prevalent than ever––global cyberattacks increased by 28% in the third quarter of this year alone.

Not every house needs a state-of-the-art surveillance system. But if your house is under continual attack by bad actors, you’re going to want to be prepared. And if you run any kind of business in 2022, it’s important to remember: you are always a target. As far as the application experience goes, comprehensive preparedness is the only answer: all it takes is one small breach to lose a non-negligible percentage of your user base.

And then there’s performance. In general, businesses have no room for error here. Just take a look at these stats: according to one survey, a negative mobile experience can make a customer 62% less likely to purchase from a brand in the future, while 90% of users have reported that they stopped using an app because of poor performance. The markets are simply too competitive to risk inconveniencing the consumer in any way.

Of course, when application experience management is done correctly, it is invisible to consumers: the experience on their end is seamless. But this kind of flawless AX is only possible with comprehensive infrastructure monitoring and network visibility, a proactive stance towards potential threats, and a true sense of how your app is performing. You can keep on plugging away in the dark, only half-aware of the trouble awaiting you––or you can make sure, through holistic AX management, that the trouble is turned away at the door.

About the Author

Larry Goldman is the Senior Manager of Product Marketing for Progress. He is an accomplished marketing leader with over 20 years of experience in enterprise software, SaaS, services, and technical B2B marketing.

The post The Four Keys to Achieving an Optimal Application Experience appeared first on Cybersecurity Insiders.

Rapid7 Takes Home 2 Awards and a Highly Commended Recognition at the 2022 Belfast Telegraph IT Awards

Posted 2 years ago by Rapid7

Rapid7 was honored at the Belfast Telegraph's annual IT Awards, Friday, taking home a pair of awards including the coveted “Best Place to Work in IT” in the large company category award, and the “Cyber Security Project of the Year” award, for groundbreaking machine learning research in application security. That research was conducted in collaboration with The Centre for Secure Information Technologies (CSIT) at Queen's University Belfast.

The team also took home a Highly Commended recognition for Best Use of Cloud services at the event.

The ability to work on meaningful projects that positively impact customers, being supported by a range of professional development opportunities, a culture rooted in connection and collaboration, and the invitation to explore new ways of thinking all came together in the submission to help earn them the “Best Place to Work” title.

Belfast has been regarded as one of the UK's fastest growing technology hubs. There are now more than 300,000 people working in the technology sector of Northern Ireland, according to the Telegraph. For Rapid7, an impressive business environment and the work being done in IT Security at the local universities were significant factors in the decision to join the Belfast community in 2014. This move was in line with Rapid7's goal of creating exceptional career experiences for their people and expanding operations to address a growing global customer base. In 2021, Rapid7 relocated to their newest office space and announced the addition of more than 200 new roles to the region.

Rapid7's win for Cybersecurity Project of the Year focused on the cutting-edge area of machine learning in application security. Their research sought to reduce the high level of false positives generated by vulnerability scanners — a pain point that has become all too common in today's digital environment. Rapid7's multi-disciplinary Machine Learning (ML) team in Belfast was able to create a way to automatically prioritize real vulnerabilities and reduce false positive friction for customers. Their work has been peer-reviewed by industry experts, published in academic journals, and accepted for presentation at AISEC's November 2022 event — where it was recognized with their “Best Paper Award.” AISEC is the leading venue for ML cybersecurity innovations.

Rounding out the evening was a Highly Commended recognition from the Telegraph for “Best Use of Cloud Services.” The scale and speed of cloud adoption over the last number of years has caused an exponential growth in complex security challenges. Rapid7 showcased how their team in Belfast partnered with global colleagues to create an innovative and multi-faceted solution to manage Cloud Identity Risk across three major Cloud Service Providers (CSPs) — AWS, Azure and GCP. Their work has created a positive impact on Rapid7 customers by enabling secure cloud adoption faster than ever before.

Rapid7 is a company that is firmly rooted in their company values. Employees are encouraged to challenge conventional ways of thinking, work together to create impact, be advocates for customers, bring their authentic selves and experiences to the table, and embrace the spirit of continuous learning and growth. The work represented in these awards is a testament to the incredible opportunities and experiences that are possible when these values are clearly modeled, celebrated and practiced in pursuit of a shared mission — creating a safer digital future for all.

For more information about working at Rapid7, check out rapid7.careers.com

For more information on the Belfast Telegraph IT Awards and other winners, click here.