Table of Contents

1. The Rise of GraphQL
2. An innovative API, needs an innovative DAST .

Bright’s ability to work with modern technology stacks and API security testing now includes full support for GraphQL APIs, enabling our customers to simplify, automate and scale their security testing even further with our solutions, as they embrace new architectures.

Developed internally by Facebook and released publicly in 2015, the rise in popularity of GraphQL has grown exponentially, and we are excited to support our clients who join the many household names that are embracing GraphQL, including Github, Twitter and Airbnb.

Our GraphQL API security testing support exemplifies our dedication to enabling our clients, at the forefront of modern technology, to integrate application security testing across their CI/CD pipelines and to reduce their reliance on manual testing.

The Rise of GraphQL

What has driven this rise in popularity? Advantages of a GraphQL API include:

Microservices Friendly, just like Bright – GraphQL API handles communication between multiple microservices, merging them into one GraphQL schema, great when migrating from a monolithic application to a microservice architecture.

Single API call, with precise data fetching – Whereas REST APIs lack granular control over data, resulting in the over-fetch or under-fetch of data, GraphQL delivers a modern, simple, efficient and flexible way to improve client-server interactions, by enabling the client to make a single API call to obtain the precise data its needs, maximising performance.

Rapid production iterations – with GraphQL, changes in front end code do not require the restructuring of code by the backend engineers, so frontend developers can promptly respond to user feedback and make the changes.

Eliminates versioning – API evolution with REST results in API versions, however GraphQL eliminates versioning by deprecating APIs on a field level, removing them from the schema without impacting the existing queries. This single, evolving version provides applications with continuous access to new features.

API documentation Automation – Documentation updates are synchronised with API changes. As the GraphQL API is closely coupled with code, once a field, type or query changes, so do the docs, meaning developers spend less time documenting an API, always a good thing!

An innovative API, needs an innovative DAST 

You are at the forefront of technology and have invested in GraphQL for automation, accuracy, superior performance and speed. 

Bright is your security partner with a technology that mirrors these deliverables, with innovative AppSec testing automation built from the ground up with a Dev First approach, to test modern WebApps and APIs as part of your CI/CD.

Supercharge your GraphQL (or REST and SOAP) security testing with Bright. 

Key features of our GraphQL testing include:

We Understand
Unlike any other DAST tools, we automatically parse the data types to understand their context, to leverage sophisticated attacks and analyse the responses to evolve the payloads further.

Full depth parsing
Ability to parse varying interaction definitions, such as an XML object inside a GraphQL query, or vice versa

Sophisticated Payloads
Compliance testing to detect the OWASP API Top 10 and more, or carry out API Fuzz testing with Bright.

CI/CD Integration
Integrate via Rest API, our CLI for developers, or with common tools such as CircleCI, Jenkins, Jira or Github to carry out incremental scanning to empower your developers to detect and fix vulnerabilities on every build as part of your CI/CD, leveraging multiple discovery methods to initiative a security test, including:

• Crawler – proprietary and advanced to detect and parse GraphQL
• HAR files
• OpenAPI (Swagger) files 
• Postman Collections

To find out how you can leverage our technology to test your GraphQL, please be in touch or request a demo here.

Table of Contents

1. Top 5 ways WordPress sites get hacked
2. How to stay secure?

WordPress has many advantages and is not without reason the most popular way to build a website, with 60% of pages on the web based on it. Unfortunately, it is this popularity that makes WordPress a juicy target for malicious users. Every year hundreds of thousands of WordPress and ecommerce sites get hacked.

So, is WordPress secure?

Attackers don’t get in thanks to security flaws in WordPress’s latest core software. Rather, most hacks can be easily prevented by taking simple steps like keeping things updated and securing passwords.

Top 5 ways WordPress sites get hacked

According to data, here are the top 5 ways WordPress websites get hacked:

1. Out-Of-Date Core Software
2. Out-Of-Date Themes and Plugins
3. Compromised Login Credentials for WordPress, FTP or Hosting
4. Supply Chain Attacks
5. Poor Hosting Environment and Out-Of-Date Technology

1. Out-of-date Core Software

According to WPScan Vulnerability Database, ~76% of the known vulnerabilities they logged are in the WordPress core software. But if we look at the version of WordPress those vulnerabilities were found, then we can see that 9 out of 10 most vulnerable WordPress versions are WordPress 3.x.x. Unfortunately only 21.5% of websites run on the latest version of WordPress.

2. Out-Of-Date Themes and Plugins

While themes and plugins are great for extending your site, each extension is a new potential gateway for a malicious actor. While most WordPress developers do a good job at following code standards and patching any updates as they become known, there are still a few issues:

–        A plugin or theme has a vulnerability
–        The developer has stopped working on the theme or plugin but people are still using it
–        The developer patches the issue, but people don’t update

3. Compromised Login Credentials for WordPress, FTP or Hosting

A non-trivial percentage of hacks are from malicious actors getting their hands on WordPress, hosting or FTP account credentials.

Once the attacker has the key to your front door, it doesn’t matter how otherwise secure your WordPress site is.

WordPress does a great job mitigating this by generating secure passwords. It’s still up to users to keep those passwords secure.

4. Supply Chain Attack

There are some instances where hackers used a nasty trick to gain access to sites. The malicious actor would:

–        Purchase a previously high-quality plugin listed at WordPress.org
–        Add a backdoor into the plugin’s code
–        Wait for people to update the plugin and inject the backdoor

It’s hard to prevent such attacks as you are doing something you are supposed to do – you are keeping a plugin up-to-date. WordPress.org team usually quickly spots these issues and removes the plugin from the directory.

5. Poor hosting environment and Out-Of-Date Technology

A whopping ~28% of WordPress websites are still using PHP 5.6 or below. The support for PHP 5.6 expired at the end of 2018, and earlier PHP versions haven’t had security support for years. This opens you up to the potential of unpatched PHP security vulnerabilities. Using a secure hosting environment and recent versions of important technologies like PHP helps further ensure that your WordPress site stays safe. Always make sure your website is well maintained.

How to stay secure?

The only way to be completely sure your website is secure is to test it for vulnerabilities. Automated solutions like Bright are easy to deploy and you don’t have to be a security expert to start a scan. Bright is a SaaS solutions and new payloads are added faster than with any other traditional solution. Request a demo and check out how Bright can help you keeping your WordPress site secure.

Table of Contents

1. How do Magecart attacks work
2. Which vulnerabilities get targeted by Magecart attacks.
3. How to protect yourself and your business

Do you know what “skimming” is? It’s a method that hackers use to gather sensitive information in online payment forums. Credit card numbers, email addresses, and user passwords are stolen. Magecart is a form of data skimming. The targets of these attacks are online shopping cart systems, the most common one being Magento. Attackers get a hold of the customers’ payment card information and abuse it for their own gains. The main way of doing this is compromising a third-party piece of software, usually from a VAR. Magecart hackers implant their malicious code into a website. Then they steal credit card information when a user enters their credentials during the checkout phase of shopping.

But why are shopping carts such an alluring target for these hackers? Because shopping carts collect your payment information. Hackers can do a lot of harm if they manage to tap into this data stream. The problem lies with the eCommerce sites. Why? They don’t check open-source (third-party) code for vulnerabilities when they build their eCommerce site. This is a recipe for disaster as sometimes this code comes with vulnerabilities that can easily be exploited. Are these Magecart attacks dangerous just for individual users? Not exactly. Even gigantic businesses like Ticketmaster’s United Kingdom Website, Puma’s Australian website, and even British Airways got attacked as reported by CNCB. As you can see, Magecart attacks are a huge threat for anyone, be it a small business or a large enterprise.

How do Magecart attacks work

As you can see, Magecart hackers are dangerous. They can easily alter the Magento source or redirect the entire shopping cart to a malicious website by using injections. Is it easy to detect these attacks? It is if you’re ready to compare your entire eCommerce code stack one line at a time to see if anything was altered. A particularly nasty way Magecart attacks have been done includes uploading the malicious code to any unused GitHub project. Hackers that manage to take ownership of this project can then publish a new version of the code. One which contains malware. This propels the malware across a countless number of websites, spreading the infection further. Some security tools won’t even scan GitHub code. This way hackers and their malicious websites remain unnoticed, hiding in plain sight. 

Which vulnerabilities get targeted by Magecart attacks

This is the age of open-source development. Source code is publicly available and anyone can study it, change it, and improve it. A lot of websites today are built based on many open-source components (third-party code). You have 20 companies that make and operate the code you’re using for your website. The problem lies within the privileges granted to the 3rd party code. Third-party code usually has the same level of privilege as your own code. Why is this a problem? Because this third-party code is able to exfiltrate sensitive data that is entered by users. It can even redirect the user to another website. Customers aren’t aware of these technical issues. They don’t know what it means for a website that’s built with code that’s hosted by 50 different development groups/organizations. Any vulnerability that comes from an open-source component leaves your website vulnerable as well.

Some Magecart groups are evolving their techniques. An attack on the Shopper Approved website proved that these attacks are a serious threat. This particular attack abused the vendor’s customer scoring plug-in. The plug-in got used to rate all kinds of websites that displayed badges of honor. Shopper Approved quickly removed the malware once it was identified. But the malware managed to spread across many eCommerce sites nonetheless.

Others stick to attacking shopping carts. However, they use a new method to infect advertising banners. These hackers utilize ad servers. By doing this the ad server places the Magecart code into a specific webserver. Any user that views this ad in their browser gets infected. A code gets downloaded to their computer.

Lastly, you have hackers that plan extremely targeted and complex attacks. Instead of the quantity, they focus on quality. These hackers spend a lot of time studying the code and the infrastructure of one target. British Airways happened to be a victim of this particular attack. Hackers exploited the logic flow of internal applications. The infected script targeted their baggage claim information page. Magecart then stole all the data that wasn’t stored on any of the servers that were owned by British Airways. This is how an XSS attack compromised British Airways’ servers. Testing your applications for XSS vulnerabilities is a much easier task when you use solutions like Bright. You can read more about this specific type of attack on one of our blogs.

How to protect yourself and your business

Now we know how Magecart attacks work and what their primary targets are. How does one protect themselves and their business against them? Protecting against attacks like this can be difficult. Just auditing a website every now and then won’t help. Why? The problem comes from third-party tags which are not detected by auditing. An effective prevention technique is a zero-trust approach with JavaScript on a website. A policy that will block access to any sensitive information entered in both stored cookies and web forums by default is a good start. Then only a selected set of vetted script should be allowed to access sensitive data. This approach makes it so skimming code can’t get access to any sensitive information when it gets on a website.

Web browsers don’t offer this option in most cases. Yet, users can make sure they’re not a victim of Magecart attacks in a couple of ways:

• Avoid smaller websites that may not have a high level of security as bigger, more known websites
• Check your credit cards for charges (Hackers make small test charges to make sure the targeted credit card is still active)
• Use secure payment systems like Apple Pay (They generate unique numbers for each transaction so that attackers can’t re-use an obtained number)

Table of Contents

1. What is Static Application Security Testing?
2. Shortcomings of SAST solutions

There are many methodologies you can use to detect application vulnerabilities. One of the most common methodologies is Static Application (or Analysis) Security Testing. Before we dive into the shortcomings of SAST solutions, let’s first outline what Static Application Security Testing is.

What is Static Application Security Testing?

SAST is a set of technologies that analyze the application’s code, byte code, and binaries line by line. As the analyzed code is transparent and available to the tool, Static Application Security Testing is a white-box testing technique.

Learn more in our detailed guide to iast.

Static Application Security Testing offers:

• Accuracy when it comes to recognizing flaws in the code
• Identification of vulnerabilities specific to code
• Identification of weaknesses that can become severe security risks if they aren’t remediated

The ability of SAST solutions to find the exact line of code that needs remediation can reduce remediation time and effort for developers.

To learn more about SAST solutions you can check out these resources:

https://www.gartner.com/en/information-technology/glossary/static-application-security-testing-sast

https://owasp.org/www-community/Source_Code_Analysis_Tools

Shortcomings of SAST solutions

Limitation 1: Inability to scan runtime applications

While SAST solutions can detect many common vulnerabilities like XSS, buffer overflow, and SQL Injection, they are limited to vulnerabilities that occur in the code itself. Unfortunately, many vulnerabilities in a runtime application do not actually exist in the code, but only arise when the application is compiled. If you rely solely on SAST solutions, you may release potentially vulnerable applications.

As an exampleStatic Application Security Testing falls short when it comes to finding issues connected to:

• Authentication (is the code vulnerable to brute force attacks, or is a password reset as effective as it can be, etc.)
• Sensitive data storage and transmission (especially in cases when it can’t tell the difference between sensitive and non-sensitive data)
• Privilege escalation and lack of authorization
• Data privacy (making sure it masks certain sensitive information when it’s displayed)

These issues become even more acute when dealing with a microservices environment where much of the code actually sits between the different services.

Learn more in our detailed guide to shift left testing.

Limitation 2: SAST needs access to source code

Some organizations don’t have access to the application’s source code. This is a big issue as Static Application Security Testing is complex. For it to function properly it needs a semantic understanding of the code. This includes the codes’ dependencies, configuration files, etc. and many of other pieces that are always in motion. Most dependencies aren’t even written in the same programming language. Can SAST understand all these moving pieces? While also being swift, accurate, and have a low false-positives rate? Not exactly.

Limitation 3: The need for a different SAST instance for every coding language

When an organization uses multiple code languages, multiple instances of SAST solutions are needed.

That means all of them require separate maintenance and configuration. This adds significant overhead. 

Limitation 4: Limited coding language support

In addition to requiring a different SAST instance for each coding language used in an organization, SAST is limited to specific coding languages. While SAST providers are constantly adding support for new languages, there are some languages that will never be supported and others where SAST falls short from providing complete coverage.

As examples, the effectiveness of SAST is reduced when JavaScript, Python, and other dynamically typed languages are used.

JavaScript is the standard programming language of the web, and web is the most used computing platform ever built. SAST’s inability to work well with JavaScript represents a significant limitation. There are over 1.6 billion websites in the world. JavaScript is used in 95% of them.

Learn more in our detailed guide to iast.

Limitation 5: Disadvantages in a Microservices environment

Another issue with Static Application Security Testing tools is the Microservices architecture. SAST solutions can’t work in a world of Microservices. That’s a huge problem as most developers today use microservices architecture. Microservices architecture is highly maintainable and organized around business capabilities.

Check out best ways to test Microservices security.

Limitation 6: False Positives

One of the biggest problems with SAST solutions is that they are prone to false positives. Developers can get results that point out a lot of findings. Only it turns out most weren’t actually exploitable, or relevant. These results take time to examine and see if a flaw can damage your application or not.

Stay tuned for our next post that outlines the comparison between SAST & DAST.

Table of Contents

1. Accelerated software development means less time spent on security
2. Software security is more important than ever.
3. Integrate security directly into your work with DevSecOps

Accelerated software development means less time spent on security

Time to market is everything. In today’s industry, many companies bring products to market at a break-neck pace. What does this mean for software developers? They constantly need to release new builds. This significantly limits the amount of time they spend on testing for security vulnerabilities. DevOps is the reason why, as the process between IT teams and software development became automated once this set of practices entered the scene. Naturally, this made the speed of software development skyrocket. But this new practice of software development also came with its own risks, aka “Vulnerable Software”.

Software security is more important than ever

In most cases, standard application security approaches act as a gate throughout most of the software development stages. For developers to continue their work, security tests have to be completed first. Typically, the type of speed that DevOps gives also means that this gated application security approach doesn’t fit well.

The question is, how do we implement application security into the DevOps process to enable DevSecOps?

For starters, full control and visibility should be given to developers and organizations. This way security measures can be fully integrated into their work and software exposure can be mitigated throughout the entire software development life cycle (SDLC).

No more waiting for security professionals to run DAST tools and test for vulnerabilities as was the case in traditional development processes. Instead, empower developers, or QA people to run vulnerability tests as part of their unit testing processes and at the speed of DevOps. As the development processes evolve so should our security processes.

Integrate security directly into your work with DevSecOps

Do you know the best way to make sure software exposure doesn’t mess up everything? You inject security directly into a developer’s work. That way the software engineer has the information he needs right away, he can immediately come up with a solution to a certain problem. That’s the way you match software exposure management with the speed of DevOps efficiently!

A highly efficient method of integrating security during development is using DevSecOps. By making business and security staff cooperate, everyone can contribute to the cause of continuously testing the system during its entire development process. That way any defects can be detected, located, and remediated before a non-cooperative user locates them and exploits them. The earlier a problem is found and fixed, the less its repair costs.

All business processes need a dedicated team that will find flaws, test the system at all times, and communicate with the business operator and gives them all the information they need for further development. DevSecOps is an incredible way of enhancing traditional security testing and secure software development practices, which is a topic we already covered on our blog before, so check it out if you’re interested!

Table of Contents

1. What’s the cause of these data breaches?
2. How can Bright help?

As we wrap up our posts for 2019 we thought we would recap the “joy” of some significant breaches that happened in the past through years. May 2020 see us all secure and have no vulnerabilities exposed.

A massive breach of sensitive personal information in Ecuador is a recent case where there was no hacking involved at all. The owner of the data; an Ecuadorian company named Novaestrat, left an unsecured Elasticsearch database exposed on a publicly accessible server in Miami. The leaked database contained data about 20 million individuals (Ecuador has a population of 16 million, but some records were attributed to deceased individuals).

This is not the first time that a breach happens due to an exposed database, and while Elasticsearch appears to be the most popular platform, there are others. 

Here are a few similar breaches from 2019:

1. Honda Motor Company
Elasticsearch, 134 million rows of data about their employees

2. BioStar 2
Elasticsearch, over 1 million records including face recognition and fingerprint data

3. Orvibo
Elasticsearch, 2 billion device user records

4. Thedatarepo
MongoDB, 188 million personal records

5. Pyramid Hotel Group
Wazuh – Open source intrusion detection system  – 85 GB of security logs including personal data

6. Bejing Jidao Network Technology
Elasticsearch, 33 million job profiles

7. Dow Jones
Elasticsearch, 2.4 million client records

8. Verifications.io
MongoDB, over 800 million email records

9. Rubrik
Elasticsearch, tens of gigabytes of customer data

10. CitiFinancial
Elasticsearch, 24 million mortgage records

What’s the cause of these data breaches?

By default, Elasticsearch connects to a local address, and therefore it doesn’t publicly expose the database. To connect to a public address, Elasticsearch needs a manual configuration.

Until May this year, there were advanced security features available only in the paid version of Elasticsearch. Unfortunately, companies that decided to use a free version and save some money were obligated to secure DB’s on their own, and they failed to do so. In addition, it is important to mention that exposures can still happen anytime if software updates are not applied correctly. As such, the main cause of these data breaches is not technology but a lack of proper security policies in the business. 

Sadly, many believe that if the database is not exposed to the internet, nobody can find it. Others are unable to implement proper security configuration in databases, software, and firewalls. Without a doubt, data breaches are happening and will keep occurring without adequate application security testing performed with correct security testing tools.

How can Bright help?

When it comes to data breaches due to exposed DBs and firewalls the only way to protect the system, data, and yourself is via regular application security testing implemented into the software development lifecycle. This enables for the entire infrastructure to be automatically scanned for vulnerabilities. Manual scans can be performed, but this is not a reliable practice because it doesn’t guarantee complete protection and it consumes a lot of resources. Instead, you can use Bright for web application security testing. With no false positives, Bright is a scalable enterprise solution, that is integrated into your Ci/CD and integrated into your unit testing and QA practices. It provides full automation of your web application scanning, and helps detect unauthenticated and exposed DB’s as well as weak administration panels. The integration into the SDLC enhances DevSecOps and delivers an immediate return of investment to organizations that decide to use it.

Table of Contents

1. Developers and students have to be told to pay attention to security
2. What if the study was conducted with web application developers instead?.
3. Shortcomings of SAST tools / Why is DAST the better choice for integrating application security into the SDLC
4. Shift security left with Bright

Developers and students have to be told to pay attention to security

Recent studies show that developers do not actively pay attention to the security of their code unless directed otherwise. Still, application security is fundamental from the early stages of app development.

All team members, including developers and QA people, involved in the product design stage, should at least be aware of the need for application security.

The University of Bonn researched two groups with 20 Computer Science students each. Researchers gave the students a task to develop a registration program for the university’s social network. One group was explicitly told to store user passwords securely while the other group was not.

The participants who were not told to store user passwords securely didn’t make any effort to implement secure code. In the other group, out of 20 participants, 12 applied some level of security.

What if the study was conducted with web application developers instead?

The team from the University of Bonn did the same research with freelance developers. They posted an advertisement on freelancer.com, pretending to be a start-up company. The researchers specifically asked for the assistance of developers with the registration function of a sample social network website. Forty-three applicants were split into two groups. One of the groups was again told to store user passwords securely, while the other group was not.

Out of 18 participants who failed to include a secure password storage mechanism, 68% belonged to the group that was not instructed to implement secure code.

The study conducted on freelance developers confirms the tendency of developers not to implement security measures for storing user passwords unless otherwise directed.

Specifically requesting developers to write secure code plays a critical role in the design of any application.

Developers have to follow development and news in web security. Otherwise, they will make risky mistakes, like using weak hashing algorithms.

As seen in the research by the University of Bonn, developers often use weak methods. They often use encoding or encryption instead of hashing or use inadequate hashing algorithms. Developers need to examine these terms to find out the meaning, capability, and limits of each.

If we want to have secure web applications by design, we have to educate students and developers about the best, the latest and most secure solutions. A lack of knowledge about handling and securing user data will cause confusion, and worse, open a back door for malicious users.

Shortcomings of SAST tools / Why is DAST the better choice for integrating application security into the SDLC

Despite having access to source code and being able to test code for vulnerabilities, SAST tools have significant limitations. SAST tools can detect many different vulnerabilities in the code, but everything they identify is in the code and may not exist in the compiled application, or may not be relevant in the combined application. As an example, they can detect the absence of access control, but they cannot verify if it is running appropriately in the compiled application based on the actual implementation. 

Another problem with SAST tools is that they produce high numbers of false-positive results. It’s difficult to verify whether or not some identified issues are actual vulnerabilities. This results in developers and security experts spending hours on end trying to distinguish between true vulnerabilities and false ones instead of focusing on resolving true vulnerabilities. Moreover,  If SAST tools don’t find any problems, it does not mean that your code is secure as they only look at the code and not at the compiled application, APIs, etc. Related to this is the fact that most applications today use 3rd party libraries and web-services. SAST tools do not have the ability to test vulnerabilities in web-services, thus leaving your application vulnerable.

The problem with false positives persists with the majority of DAST tools as well.  We are proud to say that Bright is one of the few DAST tools, if not the only one that will not report any false-positive findings. We validate that every vulnerability can actually be exploited before we report it.

Shift security left with Bright

Shift left is a simple term for a challenging task which is at the heart of DevOps. You need to move application deployment, quality and security considerations closer to the developer to ensure that potential issues are detected and resolved sooner as early as possible and at the lowest cost. CI/CD automation technology including CircleCI, Azure DevOps and others certainly makes shift-left easier.

As our previous post about the cost of remediating issues over time shows, the cost associated with bugs and security issues as they move through the delivery chain multiplies several times over at each step.

By addressing issues at the point of origin, shifting left has a clear ROI. In traditional development, dedicated teams are responsible for security and quality assurance. They generally respond to issues, not necessarily preventing them. Once the code is moved to integration or production, it is often too late to take precautionary measures. Also, IT teams are focused on system-level security, which is different than application security, where sneaky issues can be missed without security testing tools. 

Bright seamlessly integrates into your SDLC and enable developers and QA teams to run application security tests throughout the CI/CD process. By choosing Bright’s AIAST ® solutions, organizations are able to test for known and 0-day vulnerabilities and security scans can be run early in the SDLC.

Table of Contents

1. What has changed? – DAST Today
2. DAST & QA Functional Testing
3. Incremental Scans
4. Testing API’s & Web Services
5. Scanning Any Environment
6. Detecting Real-World Issues
7. Shifting Security Left

Dynamic application security testing – DAST is one of the oldest automated application security testing techniques, it has been around since the mid-1990s. DAST solutions interact with live web applications and web services, acting like a hacker-in-a-box. It has always been popular with penetration testers and security auditors looking to save valuable time.

DAST is generally focused on detecting high-risk vulnerabilities. It performs an “end-to-end” test of all the functionality across all layers of an application and provides a proof-of-exploit, making issues much easier to validate and remediate than other techniques, like SAST (code scanning). 

DAST solutions have been around since before Google existed. They continually struggled to find their place in the Software Development Life Cycle (SDLC) processes of most organizations until only a few years ago.

What has changed? – DAST Today

So, what brought on this change?  The answer is simple – DevOps. 

Collaboration between the security team, developers and DevOps is essential for security teams to enable the DevOps process. Through this collaboration, the DevOps process is transformed into DevSecOps.

This removes all the barriers that stood in the way of fully integrating DAST into the SDLC…

The automation of DAST as a part of the DevOps CI/CD pipeline offers a more reliable starting point for applications to be designed and implemented with proper security requirements.

Here are some common use cases in which DAST automation is very beneficial:

DAST & QA Functional Testing

Automating the use of DAST  by leveraging functional test tools such as Selenium provides significant benefits. The purpose of QA automation tools is to test the application’s functionality and provide quality code with proper UX. By integrating DAST tools as part of this process you not only ensure quality code, but you provide secure code as well without any additional work.

Incremental Scans

Modern development practices rely on the delivery of small incremental pieces of code that are deployed faster than ever. 

Developers continuously run unit tests to ensure quality code is deployed. DAST can be seamlessly integrated into these functional tests enabling incremental security scans of new or updated functionality and reducing the time and effort security testing time.  Moreover, enabling developers to detect security vulnerabilities during the development process enables them to resolve issues very quickly, whereas it takes much longer to resolve these issues if they are detected weeks, or months later.

Testing API’s & Web Services

RESTful API’s and web services comprise a large percent of the code used in web applications. Since this code doesn’t have UI/frontend, organizations usually neglect to test it making them more exposed to cyberattacks. Integrating DAST into functional tests enables them to interact with each web service and API calls to detect and validate vulnerabilities.

Scanning Any Environment

One of the major advantages of DAST over SAST  is that it doesn’t care what language is used to write an application. Whether it is Java, .Net, Phyton, C, Cobol, or any other language, or if you use MySql, Microsoft SQL server it doesn’t matter. Our AI-powered DAST solution is able to scan any target including HTTP/HTTPS, web socket, rest API to test the APIs themselves. This even extends to protocols such as Bluetooth, and FIX for financial institutions.

Detecting Real-World Issues

Over the past few years, microservices have become the leading method of application development. Modern apps are made up of multiple systems and components built by multiple teams and often multiple companies.

Since DAST scans applications and services in their running environment it is able to detect real-world vulnerabilities when microservices are used without the need to scan each component individually.

Learn about the top challenges of microservices security:

Shifting Security Left

The value DevSecOps offers is to conduct security testing earlier in the software development lifecycle. It enables to shift of testing left by adding security planning, testing, and monitoring into each phase of the DevOps pipeline.

Developers are under constant pressure to release as quickly as possible.  Organizations can shift security left by integrating DAST into their existing environments, rather than relying on security testing at a later phase when the developer has moved onto something else.

Automating DAST into the process is critical for enabling DevSecOps. Release and scan as early and often as possible and ensure security throughout the entire software development life cycle. This will save both time and money without affecting development velocity.

Table of Contents

1. What is industry 4.0?
2. IoT – Internet of Things
3. Blockchain
4. AI – Artificial Intelligence
5. The Way Forward

In the era referred to as ‘Industry 4.0’ or ‘The Fourth Industrial Revolution,’ two of the pillars of the technology field;  automation and data transfer are closely coupled with concerns regarding cybersecurity.

As organizations own, or use more and more information and assets which become additional nodes in the network, the attack surface area increases exponentially. As a result,  cybersecurity aspects are transforming at an unprecedented rate. The challenges to security are becoming more prominent than ever, with both sides– hackers and security teams – trying to stay ahead of each other. In today’s hyper-connected world, cyberattacks are no longer a matter of “if”, but rather “when”.

As the use of computers and automation led the charge through the last few decades, organizations and governments focused their efforts on investments in the IT infrastructure era, which is referred to as ‘Industry 3.0’.

However, today, the focus has shifted to new technologies such as IoT (Internet of Things), AI (Artificial Intelligence), machine learning and reinforcement learning which are defining the new work culture across almost all industries. Industry 4.0 essentially blends automation with advanced AI to reduce direct human effort and resources. The result is a more efficient utilization of both financial and material resources.

In the era of the Fourth Industrial Revolution, organizations are hyper-connected with smart devices and smart networks. This poses  a very lucrative target for hackers who can try to exploit the significantly higher number of vulnerable entry points into networks and devices. . Cyberattacks on critical infrastructure and in vital industrial sectors have become more frequent and more sophisticated.

Internet of Things describes a world in which smart technologies enable objects within an intelligent network to communicate with each other and interface with humans effortlessly. 

This connected world of accessibility and technology does not come without its consequences, as interconnectivity implies hackability. Most of these devices are designed with little to no built in security mechanisms, making them easy targets for security breaches. This new world of convenience calls for new and revolutionary protection measures and strategies to assure secure networks.

Blockchain

As a concept, blockchain has been around for approximately a decade. It is a well understood and defined concept that forms the backbone of most common cryptocurrencies. Blockchain, as a technology, focusses on the integrity and immutability of transactions. While blockchain as a technology is evolving, it offers solutions that can compete with current centralized offerings in terms of speed, but the blockchain is much more reliable considering capacity and trust. Inevitably, in IoT, blockchains will be used to secure infrastructure while maintaining device interoperability.

Although blockchain holds immense promise and potential, it remains vulnerable to cyber threats and risks. A robust cybersecurity program is therefore crucial for protecting blockchain assets from cyber threats.

Artificial Intelligence is another technology that is rapidly permeating organizations and government departments. It is a branch of  computer science that helps to build solutions with human-like intelligence that can carry out complex tasks independently. 

AI applications are based on heuristics such as neural networks, machine learning, deep learning and natural language processing algorithms. Machines mimic humans only after they are trained to accomplish specific activities by processing vast amounts of data and identifying patterns in that data. The growing interest in these technologies and the value they offer is resulting in their adoption across many aspects of software and IT..

AI has the potential to make cybersecurity more efficient and responsive to ever-increasing threats and improve the cybersecurity posture of an organization

The more industries become connected, the more vulnerable they are to the risk of cyberattacks because there are significantly more entry points for hackers to find and exploit. Hackers can target the connected devices that generate data, the networks that carry the data, the servers that host it, or the information systems that use it. 

AI has the potential to make cybersecurity more efficient and responsive against ever-increasing threats and improve the cybersecurity posture of organizations. Being the world’s first AI-powered Application Security Testing platform, Bright helps innovative companies that are in the forefront of the Industry 4.0 era significantly reduce cybersecurity risks. 

Cybersecurity should never be an obstacle to progress. Bright’s AI powered application security solutions help organizations save time and eliminate the security personnel bottleneck while reducing costs and their exposure window by being secure by design. 

To learn more about how you can adopt these tactics in your organization and embrace the fourth industrial revolution, or you have any questions on how to become secured by design contact us today.