We’re all familiar with the story of Goldilocks and the Three Bears. Goldilocks starts a new job as a security specialist on the security team at Three Bears’ Porridge, Inc. and is given access to their application security platform.
At first, the access she’s given is far too broad. It causes problems, and she has access to more data than she needs to do her job. By the end of the day, it’s impacted the entire system. The next day, she’s given too little access, preventing her from fully completing her tasks and creating more work for Hansel, Gretel, and the rest of the security team. Finally, after several rounds of granting and restricting permissions, they eventually land on an access level that’s just right.
Does this famous yarn hit a little too close to home?
Getting access control just right
Providing the right access levels to different teams and individual team members is a critical component of managing any security program, but it can be time-consuming, cumbersome, and rife with constant back-and-forth.
That’s why we’re excited to announce a new feature standard for InsightAppSec called Role-Based Access Control (RBAC). Our RBAC system gives you the flexibility to provide the right levels of access to the InsightAppSec platform needed for each role on your security team. By identifying users through groups, you can grant access and permissions quickly and easily, reducing back-and-forth setting up access that may have caused your team more than one porridge hangover.
The InsightAppSec RBAC feature works under a simple premise: scalability. RBAC allows you to create groups with bespoke levels of access based on what they need to actually do their jobs. The role a user is given will govern what they can see in the product in terms of features — for example, can they see the scan configs or vulnerabilities areas? — but their data access will define if they can actually see any data within those areas.
It doesn’t matter if you have a department of 10 or 20 — everyone assigned to designated groups will have the right access parameters to successfully carry out their tasks. Those parameters are easily updated to roll with changes as needed, and they’re fully customizable. With a few clicks, RBAC lets you set the access levels your entire security team needs to operate.
Go for the Goldilocks zone
So, why is this so important? Well, on day one, Goldilocks had far too much access and nearly brought the operation to a screeching halt. Having too many team members with unneeded access invites risk, and cleaning up that mess can be time-consuming and difficult. Similarly, day 2 wasn’t much better. Goldilocks didn’t have the permissions she needed and couldn’t contribute to the team (through no fault of her own). That meant the slack needed to be picked up somewhere, putting stress on the entire team and slowing the operation down.
If Three Bears’ Porridge, Inc. had the new RBAC, Goldilocks and the other members of her team or in her group would have had the permissions they needed from day 1, saving time, headaches, and money.
But the conveniences go further than that. InsightAppSec’s RBAC feature allows you to better partner with the dev team, providing them direct access to their application vulnerability details and context. That means less back-and-forth, less time lost, and a system that will scale with your business.
The RBAC feature allows you to do more than create custom roles. You can control access to applications in bulk with just a few clicks — and with our prebuilt roles, you can use the feature right out of the proverbial box (and customize from there).
This is one of the many features we’ve been working on this year to make your life at work just a little bit safer, more streamlined, and efficient. Current InsightAppSec customers will see that they may already have access to RBAC, and it will be rolled out for other parts of the Insight platform in the coming months. If you’d like to learn more, check out this handy video:
As for Goldilocks, she’s been promoted to security administrator and is dreaming of becoming a CISO. And they lived happily ever after.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
In case you missed it, injection claimed the number 3 spot in OWASP’s updated Top 10 application security risks for 2021. Today, I’m going to highlight some of the reasons why injection is such a formidable threat, despite it falling two spaces from the number 1 slot on OWASP’s 2017 list.
But before we begin, I’d like to start off with a short but true story of how I got here.
The 3 letters that changed my life
A few decades ago, back in my web development days, I was working on a community-type website. This was post-MySpace and pre-Facebook — so yeah, that long ago. Back then, CMSs like WordPress and Joomla were just taking off but still all the rage. So with the LAMP stack complete and the CMS deployed, it was time to install the community component for the website. There weren’t many third-party solutions available back then — so when I found a component that offered individual profiles, message boards, picture uploads, AND a chat, I jumped on it.
A few days into getting the website configured and running, I noticed another admin user in the DB. My first thought was, “I don’t remember creating a second admin account,” and my second thought was, “Oh no, I’ve been hacked”.
Turns out the latter was true. Not even a week into building the website, it was hacked.
Now, any sane developer would have immediately torn down the server, scrambled for backups, searched for a different hosting provider, and started over. But not me — I needed to know how this happened. So I went straight to the horse’s mouth: I asked the person who hacked my site.
Remember when I mentioned the community component had a chat function? I used it to send the hacker a message: “How did you get in here?” Sure enough, a day later I received a reply of 3 simple letters that I will never forget: “SQL.”
From that day on, I knew what I wanted to do for the rest of my life. So to the hacker, whoever and wherever you are out there, thank you.
Which brings me to OWASP’s new top 10 for 2021 and our focus for this post: A03, aka injection.
What is injection, and how are attackers using it today?
I like to think of injection as a family of vulnerabilities. It can include everything from SQL and XSS — the rock stars of injection — to improper control of resource identifiers, which basically cover anything with the ability to significantly change the flow of a given process. In some cases, injection can even include the execution of arbitrary code. It should come as no surprise, then, that there are currently over 32 mapped CWEs for injection.
Many things have changed since my web developer days, but a lot has stayed the same. One would like to think the days of SQL injection, or any injection for that matter, are long gone. Sadly, that isn’t the case. While injection has been dethroned from first to third place on the new OWASP 2021 Top 10 list, it’s still very much alive in today’s web applications.
The good news is that the majority of injection issues I see today are a bit more benign than those from the past. They tend to be less likely to yield the fruitful database dumps, auth bypass, or occasional defacement we’ve all come to know so well. Don’t get me wrong — there are plenty of apps out there that are eager to give up their sensitive data because of unexpected and improperly handled input, though it does seem those numbers are on the decline. But for the apps that are a little more reluctant to share sensitive information via injection, they do so in another way: stack traces.
Stack traces sometimes do stack up
Developers have a love-hate relationship with stack traces. On the one hand, they’re helpful in spotting errors in the code they write. On the other hand, they point out the errors in the code they write.
To those that are new to the phrase “stack trace,” it refers to an error in the code that was last run by the application before it crashed. Basically, when something happens that the code isn’t prepared to handle, it spits out a bunch of technical information onto the screen so the developer can spot the issue and correct it. Stack traces have been around since the dawn of programming, and they remain a popular method of debugging an application.
For our conversation, let’s focus on the production environment of an application and highlight why stack traces in this scenario are bad for two main reasons.
First, they look terrible and are a bad user experience. When browsing an e-commerce product site, “NullPointerException” should not be one of the results. And I don’t recall “/var/www/” being part of my search string when looking for a new pair of sunglasses.
Second, most stack traces tend to divulge more sensitive information than they need to. This is by design — and while it might be helpful to the developer, it can also be all too helpful to an attacker.
So how does one “inject” something into a web application — and what role do stack traces play in this process? Well for the most part, and to keep things simple, GET and POST methods are a great place to start.
Say you come across a URL that ends with this path:
/search_get_by_id.php?id=3
Replace the 3 with a single tick so it looks like this:
/search_get_by_id=’
Now, instead of showing the results for an item with the ID of 3, the application gets confused by the single tick and throws a stack trace like this:
Invalid ProductError 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ”’ at line 1 of SELECT * FROM inventory WHERE id = ‘
Or maybe you’re updating some personal information on a website, but instead of entering in your email address, you enter “<script>alert(document.cookie)</script>” or 1,000 letter As into the parameter instead.
All these examples are forms of injection, and if done correctly, they can do some serious damage to an application. And the best-worst-case scenario for an attacker is that the application yields a stack trace instead of doing whatever it was they were initially trying to do. Either way, it’s a win-win scenario for the attacker.
How stack traces make hackers’ jobs easier
The average person who encounters a stack trace when visiting a website may not think anything other than, “Yikes, I don’t know what this is, so I’m going to hit the back button or try re-entering in my information.” However, an attacker will have a much different reaction — probably something like “YES!” or “FINALLY!”
You see, attackers love stack traces because of the information they yield. They spend hours or even days trying to get an application to throw a stack trace. While the untrained eye sees a mess of gobbledygook on the page, an attacker sees very valuable information that brings them another step closer to their goal.
In the following examples, I’ll give an overview of how an attacker views these stack traces.
*The images depicted below are entirely made up but do contain real snippets from actual stack traces. They’ve also been exaggerated for educational purposes.
Example 1: MySql
Things we know:
The application is running on a Windows machine, possibly a 32bit OS like XP or NT, judging from the file path.
The app is running an outdated and vulnerable version of MySQL.
There are multiple critical CVEs for this version of MySQL, everything from Denial of Service attacks to privilege escalation and remote code execution.
Example 2: Laravel PHP
Things we know:
The application is running on a Windows machine, based on the file path.
It’s running XAMPP (multiple known vulnerabilities).
It’s also running MySQL (multiple known vulnerabilities).
In addition, it’s running a vulnerable version of the PHP Laravel Framework 5.5 CVE-2018-15133.
This version of Laravel is susceptible to remote code execution, among other exploits.
Example 3: Apache
Things we know:
The application is running on a Linux box based on the file path.
It’s running Apache Struts (multiple known critical vulnerabilities).
It’s also running Apache Tomcat (multiple known critical vulnerabilities).
In addition, it’s running a vulnerable version of Apache web server.
This version of Apache is susceptible to multiple critical CVEs ranging from Denial of Service attacks to privilege escalation and remote code execution.
Example 4: Java
Things we know:
The application is running on a Linux box based on the file path.
It’s running Spring Framework (multiple known vulnerabilities).
It’s also running a vulnerable version of Java.
This version of Java is so vulnerable Oracle won’t even give you a specific vulnerability, only that it contains multiple critical CVEs ranging from remote access to self-destruction. I am exaggerating… only slightly, but you get the point.
So while injection went from gold to bronze on the new OWASP Top 10 list for 2021, attackers can and do still use it to produce a treasure trove of information — stack traces being one of those tried-and-true methods.
That said, I’m happy to see that injection has been knocked down a few pegs — this shows that the web industry has managed to move the needle forward by way of security. With the rise of even more popular frameworks that have some security baked in, and the ever-increasing concern for secure apps, developers are seeing security injected into their day-to-day (no pun intended). Whether it be SAST or DAST scanning hooked into their CI/CD, RASPs or WAFs deployed to detect attacks, or even the occasional pen test, security is becoming more and more part of the software development life cycle, and that is awesome.
Who knows? Maybe in another 4 years, injection won’t even make the top 10. If it does, you can bet I’ll write another blog about it.
Stay tuned for future installments in our series of deep dives into OWASP’s updated Top 10 list of application security threats for 2021.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
Summer has come to an end. The backyard barbecues are behind us, the hot dogs have all been eaten, and we’re all gearing up for some awesome autumn leaf peeping. But before we fall into another season (see what we did there?), we wanted to take a moment to look back on all of the improvements we’ve made to InsightAppSec and tCell over the last 3 months.
At Rapid7, we’re obsessed with making your lives easier, so it’s no surprise that most of our biggest improvements to the platform help our customers do more in less time and with less stress. We took a look at authentication, validation, remediation, and auditing. We’ve punched up our tCell API capabilities, and we’ve rolled these out this summer to give you more time to focus on the important work of securing your applications (and hopefully having a few well-deserved drinks with those little umbrellas in them). In short, we worked hard all summer so that you can sleep easier this fall.
So, let’s make like a backyard pool and dive in.
InsightAppSec improvements
Here are the most noteworthy updates we made to InsightAppSec in Q3:
Automated authentication
Most modern web applications and APIs leverage credentials to improve security. That’s great! But for the security professional doing scan after scan day in and day out to find vulnerabilities, this could mean constant toggling back and forth to put in the right credentials on the right screens at the right times to make sure the scans run properly.
No more! We’ve automated authentication, streamlining the entire configuration process. When you run a new application scan, the authentication page has the automated option as default, saving you and your team tons of time and confusion. You always have the option to create macros, but once you see how smooth the automated process is now, we doubt you’ll ever go back.
Validation scanning
We’ve added a new capability that allows security teams to scan for previously discovered vulnerabilities and be sure they’ve been remediated. Prior to this update, security teams had to open individual vulnerabilities, manually run an attack replay, and if the vuln was remediated, mark it that way. With our new validation scanning feature, you can target all vulnerabilities within a scan and see if they have been remediated or not. It targets existing vulnerabilities and tells your team whether you are good to go.
No more running attack replays for each vulnerability — now, you can check that the work was done in bulk, saving your team time and probably more than a few headaches. What’s more, it can help you identify other unknown vulnerabilities that may have been introduced between full scans.
Prioritizing remediations
Not all vulnerabilities are created equal, and knowing which ones to prioritize remediating first is an important part of a security team’s workflow. InsightAppSec now supports CVSS 3.1 to give security teams the the granularity and context they need to properly triage and prioritize app vulnerabilities.
This industry standard will help you understand which vulns to patch first and which ones can wait, even if they have the same level of severity within the InsightAppSec platform scan. The deeper you can dive into the nature of the vulnerability, the safer your application will ultimately be.
Platform auditing comes to InsightAppSec
If you’re one of the thousands of companies that use more than one Rapid7 product — first of all, thanks — we’ve created a centralized auditing platform that works across multiple R7 solutions. This makes it easier to investigate user activities or share activity with auditors as you meet your compliance obligations.
In other words, we’re making your auditing of tasks easier. InsightAppSec sends auditing logs directly to the Insight platform showing events such as applications, targets, scan configurations, and files.
tCell Improvements
Now, let’s roll the highlight reel of our Q3 updates to tCell:
Sending events through the Insight Connector
Not every organization has the same security requirements, and for those that are using tCell, that can mean needing a single outbound connection from their environment into the Insight platform. Now you can send those events through the Insight Connector in one stream of data as a proxy removing multiple streams and reducing points of vulnerability.
Improving the API experience
Getting the right information to the right place at the right time is key to maintaining a strong security infrastructure. We’ve improved tCell’s API to set alert preferences and allow alerts to be sent to other platforms like Slack. For organizations with multiple security teams working in tandem, this can help keep everyone on the same page and ensure that the right alerts are seen by the right people.
But that’s not the only improvement we’ve made to tCell’s API. Customers can now configure and copy policies. Those tasks can be automated at scale, so no need to manually update via the UI.
These are just a few of the improvements we’ve made to InsightAppSec and tCell over the last few months and we promise there are even more on the way this fall. If you’d like to learn more about our automated authentication feature, we’ve got a handy blog post for you here.
Now go and grab a pumpkin-spiced latte — you’ve earned it.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
Late last week, the Open Web Application Security Project (OWASP) released its top 10 list of critical web application security risks. The last OWASP Top 10 came out in 2017, and in the intervening 4 years, we’ve seen a fundamental shift in application security that includes greater emphasis on securing web applications during the ever-evolving development process.
In this post, we’re going to discuss the 2021 OWASP Top 10, how the list is evolving alongside the web application security discussion, and what you should take away from this year’s Top 10. And if you want to learn more, stay tuned in the coming weeks for deeper dives into several of the main recommendations this year’s OWASP team has identified.
What is the OWASP Top 10?
The OWASP Top 10 is an awareness document that highlights the top 10 most critical web application security risks. The risks are in a ranked order based on frequency, severity, and magnitude for impact.
OWASP has maintained this list since 2003, and every few years, they update the list based on advancements in both application development and application security. Many organizations look to the OWASP Top 10 as a guide for minimizing risk.
So, what’s changed?
As mentioned above, OWASP and their Top 10 have evolved to focus more on helping developers build secure applications and work with security teams. After partnering with organizations and once again taking into consideration frequency, severity, and magnitude for risk that these vulnerabilities introduce, OWASP recently released their new OWASP Top 10 for 2021. Check out the changes below:
Some of the notable changes include the introduction of new categories, consolidation, and scope changes to categories. Examples of these changes include:
The introduction of insecure design — We’ve seen this repeatedly highlighted as an area to watch, as the pressure mounts to continuously deliver new apps and features. An application’s architecture must take thoughtful security principles into account from the very beginning of the design process.
Broadened focus of injections — The new injection vulnerability category now includes 33 CWEs and many common injection types, such as SQL and NoSQL. The notable consolidation that took place this year was the inclusion of Cross-Site Scripting (XSS) into the injection category.
Vulnerable and outdated components replace “using components with known vulnerabilities” — This is an example of an expanded scope of category to include using outdated open-source libraries and their associated vulnerabilities.
What do these changes mean?
The changes to the OWASP Top 10 reflect the shifts we’ve witnessed in application development and security. As the pressure mounts for teams to deliver high-quality products faster than ever, and we see the introduction of many cloud-native technologies to facilitate the acceleration of development cycles, developers must focus on scalable security from the start.
The 2021 OWASP Top 10 highlights a strategic approach to security that includes the architecture that supports the application, as well as the APIs, data, and so much more. The methodologies for testing and monitoring your applications through development to production are also critical in this framework. The 2021 OWASP Top 10 highlights many of these changes with the adoption of best-in-class tools and practices such as shifting left, DevSecOps, and a focus on preventing risk through a combination of both testing and monitoring.
Want to learn more? Stay tuned for our follow-up blogs, where we’ll take a deeper dive into some of the OWASP Top 10 to discuss what’s changed and why these updates are important.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
At Rapid7, we know the most powerful tools in your security portfolio are the ones that help you understand your risks quickly. With our new automated login for InsightAppSec, you can access and scan even the most complex, modern applications quickly and easily. That means you’ll spend less time worrying about whether your scans are authenticating and more time assessing and responding to vulnerabilities.
In the world before automated login — we’ll call these the dark ages — security professionals needed to write scripts and rely on macros to navigate more complex applications with their many layers of authentication. This has always been a time-consuming process that takes resources away from the work of identifying and remediating vulnerabilities.
InsightAppSec with automated authentication analyzes and identifies the login pages, enters the credentials, and logs in to the app automatically. Then, it provides you with a confidence score so you’re sure it’s been logged in successfully. Fewer confusing steps, fewer macros — just more understanding of risk from the restricted parts of your web applications.
A look inside
So, what’s different? Well, for starters, the look and feel of the scan will be intuitive and easy to use. We’ve taken great pains to maximize your efficiency at every turn so when you start a new application scan and select authentication, automated authentication will be the default.
We’ve also improved secondary navigation to include new, more logical groupings, making settings easier to find.
The process couldn’t be easier. Simply choose the application you wish to scan from the InsightAppSec All Apps page, open Scan Config, and select Automated Authentication from the Authentication’s page. Enter your credentials once, and you’re good to save for later or start the scan now.
Moving to automated login is more than just a single new feature — it opens the door to more innovations. Automated login uses a new architecture that allows InsightAppSec to interact with web apps in the same way a user and their browser would behave. This is critical as applications become more complex, which in turn presents new challenges to automating certain processes. Automated login is just the first feature we’re rolling out based on this new, more innovative architecture.
As web applications become more complex, the solutions you employ to secure them should become more powerful. Automated authentication provides your security team with the ability to efficiently and accurately scan even the most complex applications quickly and in an intuitive way right out of the box. It flattens the learning curve for setting up and running scans, giving any member of your security team the ability to run scans and identify vulnerabilities.
We are including automated login through InsightAppSec for existing and new customers right away. If you want to learn more, click here for more resources.
DevSecOps is the concept and practice of integrating security into the DevOps cycle. The idea is to bring the different phases of security into the DevOps model and try to automate the entire process, so security is integrated directly into the initial application builds.
In this post, we’ll take a closer look at how to integrate security tools into the various phases of the DevSecOps cycle. We’ll focus here on Rapid7 tools like InsightVM, InsightAppSec, and InsightOps; the same principles apply to integrating other open-source security tools into the process.
In this simple, three-step setup, we’ll use Gitlab as the Version Control System and Jenkins as the build automation server. (Before getting started, you’ll need to have the integration between Gitlab and Jenkins completed.)
We’ll be using a simple declarative script in our pipeline, as follows:
pipeline {
agent any
stages {
stage("build") {
steps {
echo "This is a build step"
}
}
stage("test") {
steps {
echo "This is a test step"
}
}
stage("release") {
steps {
echo "This is an integration step"
sh "exit 1"
Step 1: Integrate InsightAppSec
First, we’ll include the InsightAppSec Scan in the pipeline. Ideally, this would be in the DAST stage.
To get started, we’ll install the InsightAppSec Plugin. We’ll need a few more details on hand, like the Scan Configuration ID and the InsightAPI key, which you can fetch from the InsightAppSec platform. We can then set up the scan on the InsightAppSec platform or use the InsightAppSec APIs to create a scan. Once we have the required details, we can kick-start the scan in our pipeline.
Here, we’ve used python script to add an app and create a scan configuration on the InsightAppSec platform.
Now, with the App Name and Scan Configuration ID, we can set up the scan in the pipeline with the following code:
We’ve replaced the “scanConfigId” and “appId” details ― we just need to replace the “insightCredentialsId” with the InsightAppSec API key. Setting the “enableScanResults” option to “true” will show results of the scan as a new option on the Jenkins Build page, with the label InsightAppSec Scan Results.
Step 2: Integrate the InsightVM Container Scanner
Next, we’ll integrate the InsightVM Container Scanner in the pipeline. In this step, we’ll build our Docker Image and scan it using InsightVM Container Scanner before pushing it into our registry to host apps in our staging or production environment.
We’ll be building our Docker container using a Dockerfile, which we have to add to our Gitlab repository. After building the Docker container, we’ll scan it using the InsightVM Scanner.
We can set up the InsightVM Scanner in our pipeline with the following code:
The results of the pipeline should appear as a new option on the build page, with the label Rapid7 Assessment. Alternatively, the results are also available on the Builds tab of the Containers option within the InsightVM platform.
Step 3: Integrate InsightOps
In the final step, we’ll integrate InsightOps, Rapid7’s log management solution, into the pipeline. This integration will forward all the logs to the InsightOps platform.
To get started, we have to install the Logstash plugin on our Jenkins server. Then, to set up InsightOps, we’ll have to configure a collection source on our InsightOps platform.
Simply log into the InsightOps platform, then click on Add Data > Select Webhook — you’ll find this option under System data. Then, name the log set as Jenkins-Console and copy the URL for the log entries.
On the Jenkins Server, head to the Configuration page and scroll down to the Logstash option. Click on “Enable sending logs to an Indexer,” and select the Indexer type as Elastic Search. Finally, paste the log-entries URL that was copied from InsightVM. Remember to append the InsightAPI key to the URL.
To send the logs, we can either select the Enable Globally option or add the Logstash option to the pipeline, as shown in the following code:
pipeline {
agent any
stages {
stage("build") {
steps {
echo "This is a build step"
}
}
stage("test") {
steps {
echo "This is a test step"
}
}
stage("release") {
steps {
echo "This is an integration step"
sh "exit 1"
}
}
}
stage("deploy") {
steps {
input "Deploy to production?"
echo "This is a deploy step."
}
}
}
}
After editing the pipeline, we can run the build again and look at the logs data on our InsightVM dashboard.
Lastly, we’ve embedded some other open-source tools to complete our DevSecOps pipeline. The final pipeline looks something like this:
This three-step process is an intuitive way to integrate Rapid7 products into a DevSecOps pipeline, but it’s just one way to approach the task. Because our products support APIs, you can set up the integration according to your environment, so you have the flexibility to build the DevSecOps pipeline you need.
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.
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.
“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.
*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 attackswere 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.
*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 InsightAppSecfrom 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.
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 illustrates the following steps:
AWS WAF has a rate-based rule to allow 100 requests every 5 minutes.
A user sends multiple requests and breaches AWS WAF rate-based rules threshold.
AWS WAF blocks any further requests from the user.
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
In the navigation pane, choose Web ACLs, and then choose Create web ACL in US east (N.Virginia) Region.
For Name, enter the name that you want to use to identify this web ACL.
For Resource type, choose the Application Load Balancer that you created in Step 1 and choose Add.
Choose Next.
Choose Add rules and then choose Add my own rules and rule groups.
For Name, enter the name that you want to use to identify this rule.
For Rule type, choose Rate-based rule.
For Rate limit, enter 100.
Under Actions, keep the default action of Block andenable Custom response.
Enter the response code as 302.
Under Response headers, add a new custom header with Key as Location and Value as example.com
Choose Add rule.
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
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
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
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 shows the following steps:
AWS WAF has a rate-based rule to allow 100 requests every 5 minutes.
A user sends multiple requests and breaches AWS WAF rate-based rules threshold.
AWS WAF blocks any further requests from the user.
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
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.
Click on Rules tab and choose Add rules and then choose Add my own rules and rule groups.
For Name, enter the name that you want to use to identify this rule.
For Rule type, choose Rate-based rule.
For Rate limit, enter 100.
Under Actions, keep the default action of Block and enable Custom response.
For the response code, enter 307.
For Choose how you would like to specify the response body, select Create a custom response body.
A pop-up box will open. Enter a name for the Response body object name.
For Content type, you can select JSON, HTML, or Plain Text. In this example, we select Plain Text.
For Response body, enter any sample text. In this example, we enter This is a sample custom error page. Then choose Save.
Choose Add Rule.
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
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
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
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 shows the following steps:
User sends request to the Application Load Balancer that is attached with AWS WAF.
AWS WAF applies a geographic location rule that conditionally allows requests from unexpected countries in Count mode.
AWS WAF adds a custom HTTP request header to tag this request.
An Application Load Balancer listener rule is configured to route requests based on this header.
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
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.
On the Rules tab, choose Add rules and then choose Add my own rules and rule groups.
For Name, enter the name that you want to use to identify this rule.
For Rule type, choose Regularrule.
For If a request, select doesn’t match the statement (NOT).
For Inspect, select Originates from a country in.
In this example, normal traffic originates from United States; so under Country codes, select United States – US.
For IP address to use to determine the country of origin, Choose Source IP Address.
For Action, choose Count. This will allow requests to be logged and tagged while processing other rules that follow.
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-
Choose Save rule.
Set rule priority, move your new rule to the top to allow this rule to be processed first.
Choose Save.
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
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 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.
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.
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.
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
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)
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
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
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!).
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.
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.
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.
By continuing to use the site, you agree to the use of cookies. more information
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.
