Tag Archives: Application Security

What’s New in InsightAppSec and tCell: Q2 2021 in Review

Post Syndicated from Nate Crampton original https://blog.rapid7.com/2021/07/21/whats-new-in-insightappsec-q2-2021-in-review/

What’s New in InsightAppSec and tCell: Q2 2021 in Review

If there’s a theme to InsightAppSec and tCell updates and improvements in the second quarter, it would be “save time by building it into the process.” Building a more efficient process is key in further securing web applications.

Can you get it done faster from home? Or do you get to the win faster with an in-person team? Do those expensive express lanes work? Or are they just as clogged with traffic as the regular lanes? The world is constantly looking for faster, but the question to ask: is the “fast” also smart? Let’s take a look at InsightAppSec Q2 releases that we think will help you be both.

Identify. API. Scan by.

That last one was just to make the entire headline rhyme. However, the new features and functionality below can (mostly) be grouped into these 3 categories.

Simplifying access to complex apps

You can now get into modern applications faster with “Automated Login.” InsightAppSec enhanced the automated authentication process to go beyond simple HTML forms to include applications built with rich user interfaces. To achieve a more accurate and efficient login process into these applications, InsightAppSec interrogates the web application, using javascript to identify login pages, complete credential fields, trigger login action, and return a confidence score.

Plus streamline automated login with the new “Verify Credentials” feature. Save time and reduce configuration friction to the process by verifying you’ve entered the correct username and password during/early in the scan configuration.

Investing in API enhancements

New API features for both tCell and InsightAppSec create additional checks and balances as well as new avenues for integration with other systems in your environment.

  • Configure policies via API in tCell: Exert greater control by enabling, disabling, or blocking various features via API. You can also reset, enable, or disable the defined Content Security Policy (CSP) for a specified application.
  • Manage security programs via API within InsightAppSec: Manage customer-specific issues more efficiently and run search queries easier with newly included tag management.

Making scans smarter

Another scan upgrade you can now take advantage of within InsightAppSec? “Incremental Scanning.” Help your team to achieve more targeted testing and triaging (that’s a lot of alliteration) by scanning only the parts of an application that are new or have changed.    

There’s also a new way to help security admins help you. Now they can catch all subdomains with 1 addition to the allowlist. This is called a “Wildcard,” and an admin can now delegate scan configuration, no longer needing to specify each subdomain explicitly.

Honorable mentions

Find vulnerabilities faster with filters. Within InsightAppSec, you can enter specific criteria to speed up triaging and prioritization and:

  • Create and save unique filters as well as leverage quick filters based on vulnerability statuses.
  • Navigate throughout applications while maintaining search queries for the session.
  • Quickly apply multiple search criteria — the more filters you add in the search bar, the more refined your results.

Now available at the Chrome web store, version 4.0 improves authentication into your web applications. It also:

  • Gives you greater capabilities to determine whether a vulnerability is valid by replaying an attack.
  • Enables tracking of user actions during authentication.
  • Gives you the ability to import and reference a traffic file within an application by sending requests to the front-end application and back-end server.

Enduring improvements

As a quick reminder, now available is the latest release of InsightAppSec’s next-gen scan engine. You can now remove any content security policy defined in the header or response body by using the new “CrawlConfig” option. You’ll also find fresh CWE references for several modules. Plus discover the latest updates aimed at improving the quality and resilience of your tCell experience.

That’s it for our Q2 ‘21 AppSec release review. We hope you have a successful third quarter and a great season, wherever your business takes you. Until next time…    

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

3 Takeaways From The 2021 VDBIR: It’s An Appandemic

Post Syndicated from Nate Crampton original https://blog.rapid7.com/2021/06/25/3-takeaways-from-the-2021-vdbir-its-an-appandemic/

VDBIR Overview

3 Takeaways From The 2021 VDBIR: It’s An Appandemic

“Appandemic” sounds a bit like “appendectomy.” From a societal standpoint, it’s almost as alarming — if not more so — as the surgical procedure is from a personal standpoint. Because in the midst of the global pandemic we’ve all experienced over the past year and a half, web applications have experienced their own version of a massive breach to their immune systems. Unfortunately for web-application security, there is no miraculous universal vaccine for these breaches.    

Over the years, the Verizon Data Breach Investigations Report (VDBIR) has highlighted similar concerns within the application-security ecosystem.

In 2018, Databases were the preferred attack vector, with web applications ranking fourth. But over the next 3 years up to now, we’ve seen a troubling trend in which web applications have shot up the rankings as the preferred method of entry. In 2019, they hovered around 30% compared to other vectors. In 2020, it tripled to nearly 90%, no doubt due in large part to the seismic cultural shift to working remotely and conducting more business online. This year’s VDBIR shows that number is sitting at about the same level today — around 90%.

What else does this year’s report have to say about the state of web-application security as the world begins its road to recovery, with more people getting vaccinated, heading back into offices, and going out and about again? Let’s take a look at 3 symptoms of the web appandemic highlighted in the 2021 VDBIR.

Symptom #1: Web apps processing payments

Attackers usually have to take a number of steps to gain access to a web application when they use a System Intrusion pattern. While they typically deploy malware or ransomware, the increasing share of Magecart-style attacks — those targeting payment card data — within the System Intrusion pattern is concerning.

This year’s report identifies that, within the specific System Intrusion attack pattern, 60% of web servers targeted were found to be sporting shiny new malware to capture information. How many of those incidents involved payment-card data?

65%

It’s clear that attackers will keep coming for card data, forever and always.

  • A vuln is exploited.
  • Stolen credentials are used to gain access.
  • Attackers modify code as they see fit.
  • Card data is captured and quickly used or sold off.  

When an incident is detected, companies can notify customers, who can then easily shut their card down and get their hands on a new one. But that’s also money and reputation lost for companies supposedly protecting those customers. It tends to leave a sour taste in a customer’s mouth, especially if it happens multiple times. Adaptable compliance solutions from Rapid7 are supported by strong institutional knowledge of what it takes to meet regulatory standards across the Payment Card Industry (PCI), no matter the region, which can help protect your customers’ card data and maintain your brand’s reputation.

65% is a big number when it comes to the likelihood that, in a given malware incident, the specific target is payment-card data. However, there is reason to be optimistic when it comes to PCI incidents: Over the past few years, attackers have specifically targeted card data less.

3 Takeaways From The 2021 VDBIR: It’s An Appandemic

*Source: Verizon Data Breach Investigations Report

While promising, that doesn’t mean you should let your defenses down. If anything, now is the time to commit to even more stringent security measures, as those previously mentioned Magecart attacks — targeting PCI in web applications — begin to pull even with overall malware intrusions targeting that same PCI.

Symptom #2: Baddies being basic

In this situation, being basic is a good thing from the baddies’ perspective. This year’s report found that baddies — aka attackers — are increasingly disclosing web-application data via a small number of steps. These are known as Basic Web Application Attack (BWAA) patterns, and they are easy for baddies to replicate in quick volume.

According to the report, attackers “are very focused on direct objectives, which include gaining access to email and web-application data.”

These rapid attacks can have maximum impact and create immediate chaos. Within a BWAA, sub-patterns exist that see attackers looking for easy credential grabs. This low-hanging fruit usually means they’re trying to compromise applications or mail servers through:

  • Using stolen credentials. This might not be happening for the first time. Attackers could be exploiting the unwillingness of many organizations to engage in regular cybersecurity hygiene to gain access to a system using stolen credentials.
  • Brute-force attacks. According to this year’s report, brute-force attacks were attempted between 637 and 3.3 billion times against 95% of companies analyzed in the report’s SIEM dataset. We can all thank the evil bots and worms out there tirelessly looking for these vulns.
  • Exploiting vulnerabilities. While not as prevalent as using stolen credentials and going brute force, vulnerability exploitation still ranked as the third-most popular method of attacking web applications. More on that in the next section.    
3 Takeaways From The 2021 VDBIR: It’s An Appandemic

*Source: Verizon Data Breach Investigations Report

Of note: 96% of compromised mail servers were based in the cloud.

So, you know, cloud security is important. That’s why DivvyCloud by Rapid7 provides unified visibility and monitoring for your cloud environments, especially when your application infrastructure sits mostly, or exclusively, in the cloud.

Symptom #3: Weaponizing vulnerabilities

Whether it’s happened to you and your team before or not, watching the development and/or security team’s work be invaded, exploited, and weaponized is heartbreaking. According to this year’s report, even though attackers are still gaining access via stolen credentials, it is definitely happening less often than web-application vulnerability exploitation.

In both instances however, attackers are more frequently focused on getting in and gaining quick leverage. Via a small number of steps, their intention might be to repurpose your app for malware distribution. Before you know it, they’re in and out with precious customer data, leaving you with lots of explaining to do.

From a solution standpoint, Rapid7 helps organizations hunt vulnerabilities by testing applications to find and remediate vulnerabilities. With powerful Runtime Application Self-Protection (RASP) capabilities, you can automatically apply protection against those attacks.

Application security: We all deserve access

Is there reason to be optimistic that we could be trending away from the current web appandemic, even with these symptoms? Much like the way the number of COVID-19 vaccinations is headed in the right direction in some parts of the world yet staying the same in other areas, it — as always — depends.

Deeper-pocketed and more-established security organizations have the ability to mount more defenses against attacks, quickly remediate incidents, and even spend big to institute a culture of offensive tactics that can ruin an attacker’s day. But solutions like InsightAppSec from Rapid7 can help organizations of all sizes scale with ease, regardless of application portfolio size.

According to this year’s report, small companies have pulled closer to their larger counterparts when bearing the brunt of web-application breaches and are losing ground in the time it takes to discover those breaches. Plus, depending on how many partners or outside contractors a smaller company has — or where that company sits in a larger and more-established partner’s supply chain — it’s in the interest of the industry at large to see that application-security equity spreads far and wide, lest breaches of every stripe proliferate the web appandemic beyond the ability of anyone to control.

Try InsightAppSec for free

Customize requests and responses with AWS WAF

Post Syndicated from Kaustubh Phatak original https://aws.amazon.com/blogs/security/customize-requests-and-responses-with-aws-waf/

In March 2021, AWS introduced support for custom responses and request header insertion with AWS WAF. This blog post will demonstrate how you can use these new features to customize your AWS WAF solution to improve the user experience and security posture of your applications.

HTTP response codes are standard responses sent by a server in response to a client request. When AWS WAF blocks a request, the default response code sent back to the client is HTTP 403 (Forbidden). The HTTP 403 response code is associated with a default error page built by the web server engine. This page is typically generic and not user-friendly. With the Custom Response feature, AWS WAF now allows you to modify the status code from HTTP 403 to HTTP 2xx, 3xx, 4xx, and 5xx, and to return a custom body when the request is blocked by AWS WAF. The custom responses unique to AWS WAF also allow you to differentiate blocked requests generated by AWS WAF or your server.

When inspected HTTP requests are allowed by AWS WAF, the request is passed through to the associated resource. Now you have the ability to insert custom HTTP request headers for each rule inside your web access control list (web ACL) set to allow or count, and you can create additional logic with your application by tagging these requests with the headers.

We will be outlining three different use cases to show how you can use these AWS WAF features.

Use case 1: Custom response code

In this example, you will use the custom response code feature to redirect a viewer request to a different webpage. You use HTTP 3xx response codes to redirect the incoming request, and use the HTTP header Location to specify the website URL for redirection. Figure 1 shows an overview of this workflow.

Figure 1: Overview of using custom response code to redirect the request

Figure 1: Overview of using custom response code to redirect the request

Figure 1 illustrates the following steps:

  1. AWS WAF has a rate-based rule to allow 100 requests every 5 minutes.
  2. A user sends multiple requests and breaches AWS WAF rate-based rules threshold.
  3. AWS WAF blocks any further requests from the user.
  4. The AWS WAF custom response code feature modifies the response code from HTTP 403 to HTTP 302 – Temporary Redirect with a Location header specifying the redirected URL.

Configure the AWS WAF web ACL and rule for custom response code

To create an Application Load Balancer and associate it to AWS WAF

  1. Follow the steps to configure a load balancer and a listener to create an internet-facing load balancer in the N.Virginia AWS Region.
  2. After the load balancer is created, open the AWS WAF console.
  3. In the navigation pane, choose Web ACLs, and then choose Create web ACL in US east (N.Virginia) Region.
  4. For Name, enter the name that you want to use to identify this web ACL.
  5. For Resource type, choose the Application Load Balancer that you created in Step 1 and choose Add.
  6. Choose Next.
  7. Choose Add rules and then choose Add my own rules and rule groups.
  8. For Name, enter the name that you want to use to identify this rule.
  9. For Rule type, choose Rate-based rule.
  10. For Rate limit, enter 100.
  11. Under Actions, keep the default action of Block and enable Custom response.
  12. Enter the response code as 302.
  13. Under Response headers, add a new custom header with Key as Location and Value as example.com
  14. Choose Add rule.
  15. Continue to choose Next to reach the summary page, and then choose Create new web ACL.

After the web ACL is created, you should see the web ACL configuration as shown in Figure 2.

Figure 2: Custom Response - Web ACL configuration

Figure 2: Custom Response – Web ACL configuration

Now, the setup is complete. You have a web ACL with a rate-based rule configured to redirect blocked requests to a different URL. To verify that the setup is working as expected, you can enable and analyze the AWS WAF logs for a test user that is sending more than 100 requests in a period of 5 minutes.

In Figure 3, you can see the custom response code of 302 being sent to the test user instance.

Figure 3: Verifying the AWS WAF logs for custom response

Figure 3: Verifying the AWS WAF logs for custom response

In the example in Figure 3, we tested our configuration by having a user send more than 100 requests from a PC to trigger a block. To verify the Location header, we analyzed the network traffic by using the developer tools of the browser. As you can see in Figure 4, the response includes the custom header Location with the configured redirect URL.

Figure 4: Verifying response in the browser tools for custom response

Figure 4: Verifying response in the browser tools for custom response

Use case 2: Custom error page

In this example, you will use the AWS WAF custom error page to route the request to a different error page, rather than the default web server error pages. As you can see in Figure 5, the workflow is similar to use case 1.

Figure 5: Overview of using custom error page to redirect the request

Figure 5: Overview of using custom error page to redirect the request

Figure 5 shows the following steps:

  1. AWS WAF has a rate-based rule to allow 100 requests every 5 minutes.
  2. A user sends multiple requests and breaches AWS WAF rate-based rules threshold.
  3. AWS WAF blocks any further requests from the user.
  4. AWS WAF custom response code feature modifies the response code to HTTP 307 – Temporary Redirect and responds with a custom error page with the message Too Many Requests.

To configure the AWS WAF web ACL and rule for custom error page

  1. In the AWS WAF console, in the navigation pane, choose Web ACLs, and then choose the web ACL that you created in use case 1.
  2. Click on Rules tab and choose Add rules and then choose Add my own rules and rule groups.
  3. For Name, enter the name that you want to use to identify this rule.
  4. For Rule type, choose Rate-based rule.
  5. For Rate limit, enter 100.
  6. Under Actions, keep the default action of Block and enable Custom response.
  7. For the response code, enter 307.
  8. For Choose how you would like to specify the response body, select Create a custom response body.
  9. A pop-up box will open. Enter a name for the Response body object name.
  10. For Content type, you can select JSON, HTML, or Plain Text. In this example, we select Plain Text.
  11. For Response body, enter any sample text. In this example, we enter This is a sample custom error page. Then choose Save.
  12. Choose Add Rule.
  13. For Set rule priority, move your new rule to the top so that this rule is processed first.

Figure 6 shows a summary of the rate based-rule created for use case 2.

Figure 6: Custom error page - Web ACL configuration

Figure 6: Custom error page – Web ACL configuration

Now, the setup is complete. You have a web ACL with a rate-based rule configured to redirect blocked requests to different URL. To verify the setup is working as expected, you can analyze the AWS WAF logs for a test user that is sending more than 100 requests in a period of 5 minutes. Figure 7 shows the custom response code of 307 being sent to our example test user instance.

Figure 7: Verifying responseCodeSent in the AWS WAF logs

Figure 7: Verifying responseCodeSent in the AWS WAF logs

When you access the load balancer URL from your browser, you should see the custom error page similar to Figure 8.

Figure 8: Verifying response using the browser

Figure 8: Verifying response using the browser

Use case 3: Header insertion for request tagging

This example demonstrates the AWS WAF header insertion capability to route the request based on geolocation. You will use the header country-check to notify the Application Load Balancer to route the request to a different target group, by using the Application Load Balancer advanced routing feature.

Figure 9: Overview of using request header insertion to tag the request to be processed downstream

Figure 9: Overview of using request header insertion to tag the request to be processed downstream

Figure 9 shows the following steps:

  1. User sends request to the Application Load Balancer that is attached with AWS WAF.
  2. AWS WAF applies a geographic location rule that conditionally allows requests from unexpected countries in Count mode.
  3. AWS WAF adds a custom HTTP request header to tag this request.
  4. An Application Load Balancer listener rule is configured to route requests based on this header.
  5. Request tagged by AWS WAF with the custom header is routed to a separate target group.

To add a geographical location rule for request header insertion

  1. In the AWS WAF console, in the navigation pane, choose Web ACLs, and then choose the web ACL that you created in use case 1.
  2. On the Rules tab, choose Add rules and then choose Add my own rules and rule groups.
  3. For Name, enter the name that you want to use to identify this rule.
  4. For Rule type, choose Regular rule.
  5. For If a request, select doesn’t match the statement (NOT).
  6. For Inspect, select Originates from a country in.
  7. In this example, normal traffic originates from United States; so under Country codes, select United States – US.
  8. For IP address to use to determine the country of origin, Choose Source IP Address.
  9. For Action, choose Count. This will allow requests to be logged and tagged while processing other rules that follow.
  10. Expand Custom request, choose Add new custom header. For Key, choose country-check and for Value, choose true.

    Note: custom request headers are prefixed with x-amzn-waf-

  11. Choose Save rule.
  12. Set rule priority, move your new rule to the top to allow this rule to be processed first.
  13. Choose Save.

 

Figure 10: Header insertion - Web ACL configuration

Figure 10: Header insertion – Web ACL configuration

For this use-case, you set up a geographical location rule to check for requests that originate from countries outside of the normal traffic flow of your application (in this example, the United States). You do not want to block the requests right away, but instead tag the requests triggered by this AWS WAF rule for further validation downstream by the application logic. To route the tagged requests differently, you use ALB advanced request routing feature to route AWS WAF tagged traffic to a different target group.

You can verify the header inserted by the rule by enabling AWS WAF full logs and looking at the requestHeadersInserted log field, as shown in Figure 11.

Figure 11: Verifying the AWS WAF logs for header insertion

Figure 11: Verifying the AWS WAF logs for header insertion

Conclusion

AWS WAF provides the ability to create a custom response for blocked requests by changing the status code and response body. The header insertion capability allows you to tag requests allowed by AWS WAF for your application to perform another action.

In this post, we showed you three basic use-cases to demonstrate how you can create a better user experience by redirecting users to another location instead of responding with a denied page. We showed you how you can create custom AWS WAF rules by tagging the request for your application logic to see it has been inspected, and how you can make a decision around this information.

If you’re new to AWS WAF, see Getting started with AWS WAF.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on the AWS WAF forum or contact AWS Support.

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.

Author

Kaustubh Phatak

Kaustubh is a Solutions Architect at AWS. He’s passionate about helping customers build scalable, secure, and cost-effective applications to achieve business outcomes. Outside work, Kaustubh likes to play cricket and spend time with his wife and kid.

Author

EJ Chen

EJ is an Edge Specialist Solutions Architect at AWS.

Securing Your Web App, One Robot at a Time

Post Syndicated from Mark Hamill original https://blog.rapid7.com/2021/02/18/securing-your-web-app-one-robot-at-a-time/

Securing Your Web App, One Robot at a Time

Modern web apps are two things: complex, and under persistent attack. Any publicly accessible web application can receive up to tens of thousands of attacks a month. While that sounds like a reason to immediately pull the plug and find a safe space to hide, these are likely spread across the spectrum of harmless to nefarious. However, that level of exposure cannot be ignored.

According to the Verizon Data Breach Investigations Report (DBIR), in 2020, “67% of all confirmed breaches analyzed in this report came from user credentials being leaked, misconfiguration in cloud assets and web apps, and social engineering attacks.” Of that total, 43% of the breaches came with the primary attack vector being a web application.  

At Rapid7, we are always looking for ways to improve our coverage, and while crawling modern web apps is a tricky business, we thought to ourselves, “If I were a web application, what would I tell my friendly neighborhood Spiderman application security professional about where to look for issues?” This was a trigger for some engaging conversation, where we sought to understand what additional resources were readily available to help guide a DAST scan. What resources does a web application provide that we could hook into in order to discover more links when scanning for vulnerabilities?

With the help of Rapid7’s senior director, chief security data scientist Bob Rudis, we found that robots.txt is in use for about 40% of the Alexa top 1 million sites, and sitemap.xml is in use for about 3% of the same apps (virtually all of which use the uncompressed XML version rather than the *.gz)

Given the popularity and commonplace of these resources, InsightAppSec has just launched the ability to allow users to opt in to searching for links in these files. If the files exist, we simply grab the links and add them to the path we navigate through a web application looking for vulnerabilities.

Securing Your Web App, One Robot at a Time

Now, I know what you are thinking. “Isn’t the point of robots.txt to stop scanners and search engines spidering my sites?” This is a common misconception.  The robots.txt file does tell search engine crawlers not to request certain pages or files from your site—but the point isn’t to keep them out, it’s used to avoid overloading a site with requests. This won’t stop a site froom being indexed by a search engine (and if that’s your aim, have a look at the noindex directive).

Most importantly, it certainly won’t stop an attacker from being nosy if they are doing reconnaissance, either in person or via bots/scrapers/scanners. An attacker won’t respect a friendly request not to attack a page, and just as you need to consider the scope of a public web app as fair game for attack —you should mirror that mindset in your approach to securing web apps.

Worried about your web application security? See InsightAppSec in action for yourself with a free trial, allowing access to scan one of your public web apps.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

What’s New in InsightAppSec and tCell: Q4 2020 in Review

Post Syndicated from Bria Grangard original https://blog.rapid7.com/2021/01/08/whats-new-in-insightappsec-and-tcell-q4-2020-in-review/

What’s New in InsightAppSec and tCell: Q4 2020 in Review

It’s crazy to believe 2020 has come to an end, and we’re sure we’re not alone in our excitement for 2021! Without a doubt, 2020 has presented some challenges for us all in the security world, as many companies quickly adopted a work-from-home model and pivoted from an in-store experience quickly to a digital one. This accelerated digital transformation encouraged us at Rapid7 to create new programs and think about how we can continuously improve the customer experience.

For application security in particular, we saw restaurants creating new apps to facilitate takeout and delivery orders, fast-growing platforms like Instacart and DoorDash developing internal apps to keep in touch with their employees, and small-business owners creating web apps to continue selling their products and services. With the rapid increase in web application development came the need to make sure these applications were as secure as possible.

Here at Rapid7, we view your application security program as a key component of your vulnerability risk management (VRM) program. Considering the challenges of 2020, we wanted to make sure we not only continued to support our existing customers through their challenges, but that we also provided new ways for our customers to get visibility into their application security program while helping them to scale with the pressures of 2020.

We’ve previously recapped some of our product enhancements from this year, such as this blog covering Q2 and this one covering Q3 for 2020, but now we will cover the highlights for Q4. Below, we’ll recap some of the new and exciting features we have released as a part of our application security portfolio (inclusive of our industry-leading testing and monitoring solutions).

Increase your visibility

We continue to hear the desire to gain more visibility into application security programs, which is why we have released:

New ‘All Apps’ report in InsightAppSec

What’s New in InsightAppSec and tCell: Q4 2020 in Review

The New “All Apps” report in InsightAppSec is now available for companies that are looking to get a single view into risk activity across all of their applications and communicate this up to their leadership teams. Want to check it out? Click here to see how you can create your own All Apps report in InsightAppSec today!

New joint ‘All Apps’ and ‘All Assets’ report (between InsightAppSec and InsightVM)

What’s New in InsightAppSec and tCell: Q4 2020 in Review

Are you currently using InsightAppSec and InsightVM and looking for a view into the risk across your vulnerability risk management portfolio? Check out this new joint report, where you can get a single view into your full-stack vulnerability risk management activity across both InsightVM and InsightAppSec. You can find more information about this here!

Scale up with ease

While visibility is a key component to a successful VRM program, many teams were challenged this year with the need to scale their application security programs and activities. We wanted to make it easier on these teams, so we released the following features to help security teams save time and effort when it came to these scaling activities:

Application tagging in InsightAppSec

What’s New in InsightAppSec and tCell: Q4 2020 in Review

You can now easily create and manage tags across one or multiple apps based on what matters to you, such as criticality, tech stack, environment, or business unit. This helps you manage your application portfolio by filtering both apps and vulnerabilities based on these tags.

New pages in InsightAppSec

What’s New in InsightAppSec and tCell: Q4 2020 in Review

We have launched a new global schedule page that allows you to create and manage scan schedules and blackouts in a single view, and we have created a new manage files tab that saves you time when it comes to edits or updates that need to be made to macros for scan authentication (you can now download the macro file and make edits, rather than having to re-record the entire macro!).

What’s New in InsightAppSec and tCell: Q4 2020 in Review

tCell now available in Europe

We understand the importance of data sovereignty, which is why we wanted to make sure we made tCell available globally, with new data centers in Europe and new ones to be added in Q1 of 2021.

AppFirewall filter on IP CIDR ranges and Groups

Looking to reduce the noise and number of events in the AppFirewall dashboard in tCell? We have added filtering on IP Groups and CIDR ranges so you can get faster, more actionable insights.

Keep up with constant change

While we are only highlighting some of our updates above, we recognize application development is ever-changing and we want to be able to support our customers to build secure software. For that reason we wanted to share one more update with you from this quarter:

New Envoy agent in tCell

If you are currently (or looking to explore) leveraging the Envoy Proxy for your cloud-native apps, tCell now has a dedicated Envoy agent that plugs directly into the proxy layer to provide monitoring and protection capabilities for modern architectures. You can find more information on this here!

As always, many of our releases this quarter went through early access programs with our customers, and if you were one of our customers who participated and gave us feedback, we just want to take a moment to say thank you! We appreciate your feedback and always look for ways to incorporate it to make our solutions provide the maximum value to our customers. Want to participate in an on-going or upcoming early access program to have your voice heard on areas where we can continue to improve our products? Reach out to your CSM, who can tell you about ongoing early access programs and get you signed up!

Thank you for your loyalty and support through 2020. We look forward to 2021 and our continued partnership!

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Shifting Security Right: How Cloud-Based SecOps Can Speed Processes While Maintaining Integrity

Post Syndicated from Aaron Wells original https://blog.rapid7.com/2021/01/04/shifting-security-right-how-cloud-based-secops-can-speed-processes-while-maintaining-integrity/

Shifting Security Right: How Cloud-Based SecOps Can Speed Processes While Maintaining Integrity

When it comes to offloading security controls to the cloud, it may seem counterintuitive to the notion of “securing” things. But, when we consider the efficiency to be gained by shifting right with some security controls, it makes sense to send more granular, ground-up responsibilities to a trusted managed services cloud partner. This could help to increase development-and-deployment velocity, without compromising the integrity of your bespoke process.  

Building a true DevSecOps ecosystem is probably a common goal for most teams. However, uncommonality most often enters the picture in the forms of both technical and organizational roadblocks. Let’s take a look at some key insights from a 2020 SANS Institute survey on current industry efforts to more closely integrate DevOps and SecOps—and how you can plot your best path forward.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

The security landscape

In more traditional environments, security teams often feel they’ve been left behind by the pace of DevOps. Vulnerabilities are introduced faster than SecOps can likely find them. The shift is with teams that are building continuous delivery frameworks, with compliance checks at every stage of the game. It becomes a matter of defending the environment as it’s being built.

Currently, about 74% of organizations are deploying changes more than once per month, according to SANS. Often, these are weekly or daily instances. So, velocity is increasing, primarily out of a need to get customers what they need, faster. Traditional change approvals and security controls are becoming more guardrail-style checks. The challenge, however, lies in optimizing the process and keeping it as secure as possible.

Increasing cloud adoption

From a security perspective, transitioning to a cloud provider’s responsibility model can better match the pace of DevOps and increase delivery speed. When both of these velocities are increasing, albeit responsibly, that’s better for business.

  • Cloud-hosted VM platforms allow teams to spin up processes more quickly compared to a traditional setup.
  • Adoption is accelerating for cloud-hosted container services and serverless platforms because providers are doing more provisioning, patching, and upgrading for many existing execution environments.
  • More organizations are running on cloud-hosted VMs versus container services and serverless platforms, but that could change because the latter two options allow you to further reduce your responsibility model.

Multi-cloud motivations

About 92% of organizations run on at least one public cloud provider. But for about 60% of those companies, the main motivations behind spreading services out between multiple providers are not quite as technical as one might imagine.

Mergers and acquisitions can cause obvious complexity, as companies link up and potentially run similar processes in different cloud environments like AWS, Azure, or GCP. There are also decision-makers and teams that prioritize a task-based approach and pick the best environment to get a particular job done. The benefits of a multi-cloud environment could then become drawbacks, as security becomes more difficult to plan for and understand. And no one wants complexity in an approach that is essentially supposed to offload responsibilities and make things easier.

Risk doesn’t translate for SecOps

As more DevOps teams increase their use of JavaScript, traditional security controls don’t support the popular format as well as other legacy languages. In this situation, there is greater risk. However, an older web app that hasn’t been updated in a while could be the tip of the iceberg in terms of the technical debt sitting out there.

Apps built on older languages like Java, .NET, and C++ could leave exposures open as teams roll over to newer languages. So, this situation also presents risk. Security teams may not even be aware they’re in the dark about vulnerabilities those legacy apps present, as they try to keep pace with DevOps.

The future of shifting left

When it comes to security testing phases, there’s still a heavy tendency toward QA. More is being done to integrate those protocols in the process, but the sea change of baking testing into earlier phases largely has yet to occur.  

  • Over the next decade, teams will likely adopt more cloud-based integration tools like AWS CodePipeline, Microsoft Azure DevOps, GitHub Actions, and GitLab CI. In these instances, the cloud provider is managing more for you, minimizing attack surfaces and providing more built-in security. GitHub and GitLab, in particular, are trending toward greater baked-in security.
  • Jenkins has been the continuous integration tool of choice for about the last decade. However, the 24/7 nature of running on-premises or in the cloud to manage builds, releases, and patches can increase the attack surface.
  • When it comes to container orchestration tools, cloud-managed services like AWS Fargate and Azure Container are beginning to pull even with cloud-hosted services like Docker and Kubernetes. It’s becoming more attractive to outsource control-point and hardening responsibilities, so that security can shift further left into containers; it simplifies testing and helps ease deployment.

The future of shifting right

Security-testing responsibility lies with actual security teams about 65% of the time. Yet, managing corrective actions lies with development teams about 63% of the time, according to SANS. These numbers indicate largely siloed actions blocking the path to a true DevSecOps approach.

The biggest success measurement of DevSecOps is the time it takes to fix an issue. Aligning teams to tackle an issue in a speedy manner can make or break. Additionally, identifying post-deployment issues can help to improve shift-left controls to prevent those issues from ever escaping into production.

A 100% cross-functional effort most likely will not be achieved by every organization. However, moving closer to this goal could help strengthen teams, boost morale, and feed back key learnings to ultimately increase the speed of success.

In conclusion

Ironically, the biggest challenge of all isn’t technical in nature. Red tape within organizations can present challenges like lack of buy-in from management, insufficient budget (open-source tools can help here!), and siloed efforts. Additionally, a shortage of skilled workers could reinforce the same old  decision-making patterns at those management levels.  

When it comes to closely aligning teams and getting more time back to innovate, it’s often a cyclical dance of shifting right to improve your efforts in shifting left. For example, can you move further right into the cloud rather than building do-it-yourself, comprehensive solutions to security? Offloading could help to create more controls for enforcing security in tandem with DevOps.

No one wants to compromise the integrity of deploying on time, particularly as it relates to customers and your company’s bottom line. Co-sponsored by Rapid7, this recent SANS webinar presents an in-depth look at key statistics from a recent survey of companies and their advancements—or lack thereof—in DevSecOps.

For more insights, access the full 2020 SANS Institute survey on Extending DevSecOps Security Controls into the Cloud.