Table of Contents

1. What is Security Debt?
2. How is Security Debt caused?.
3. When and how often should you be scanning?

With applications driving the global economy, developers are under pressure to deliver software and more features at an unprecedented scale and speed. 

While no developer wants to create insecure products, most software products are pushed into production with vulnerabilities which stay unremediated causing a spiraling technical and security debt and significant risk for the organization.

Application Security scanning frequency really is the key, with development teams that scan for security issues early and often substantially reducing their security debt. 

But what is Security Debt and how early and how often should you be scanning? 

What is Security Debt?

Security debt is the continuing accumulation of security vulnerabilities in your software that compound to make it harder (read: impossible) to catch up with remediation to secure your applications and data from attacks.

Unlike technical debt, which may get in the way of releasing new features for the needs of the business, the growing pile of security vulnerabilities puts your organization at an increased risk of cyber attack. Indeed, in many cases, Medium to High severity vulnerabilities are being deferred, including issues like XSS, SQLi and others in the OWASP Top 10. According to Forrester, the average time to resolve a high vulnerability in production is 4 months. This means that you could be placing your entire business at risk for 4 months. Unfathomable, right? Yet it happens every day!!!

How is Security Debt caused?

Security debt is caused when security testing is not baked across the software development life cycle (SDLC), accumulating when development releases software without testing for or fixing vulnerabilities. 

With most organizations carrying out periodic (monthly, quarterly, annually?) automated, or manual security testing, they make the decision to release now and fix vulnerabilities later.  This results in an increased risk of exposure until the issues are remediated. The main issue is that ‘later’ keeps on getting pushed back and in many cases, ‘later’ becomes ‘never’, making security debt even worse!

When and how often should you be scanning?

Your Security Debt should be treated just like your Credit Card debt – if you keep spending and don’t pay off your monthly balance, eventually it will lead to bankruptcy.

With the sheer volume of iterations to applications and APIs on a daily basis, security testing needs to mirror this cadence, to prevent a security breach and potential bankruptcy too!

Heavy, periodic scanning and quick remediation over a defined limited period to meet a release deadline, forces you to defer issues and add to your security debt.

DevOps and DevSecOps focus on enabling organizations to detect and fix security vulnerabilities as early and as often as possible in the software development life cycle (SDLC). 

This mindset, where everyone is responsible for security, has broken down the barriers between developers, QA and security, facilitated by security champions who know what good looks like in terms of security.

With the increased velocity of development, comes an accelerated introduction of vulnerabilities. Security testing and remediation needs to become a habitual process and part of your accelerated pipelines. Automation of daily security testing is critical to establishing a cadence of secure software

The advantages of daily scanning are clear to see:

With regular testing on every build / commit, or at least daily, everyone can be focused on making better security decisions as part of a unified DevSecOps strategy to deliver software with speed, efficiency and security.

Relying on manual testing simply cannot keep up with accelerated development timelines. The success of this strategy relies on development teams having easy to use, accurate and seamlessly integrated automated testing technology. 

Traditional legacy Dynamic Application Security Testing (DAST) tools are not built for this regular cadence of security testing that demands speed.

Bright’s innovative Bright technology, with no false positives, has been built with a developer first approach, to enable you to effectively integrate security scanning on every build / commit, to enhance DevSecOps and reduce your security debt. Contact us to learn more and request a demo.

Table of Contents

1. So, why is putting the Sec in DevSecOps so important today?
2. How do you Add the Sec to DevSecOps?.

Last week I had the pleasure of presenting at the Pittsburgh Cybersecurity day in partnership with ISACA. It was exciting to see more than 250 cybersecurity and application security professionals interested in discussing and learning how security can be enabled in a world rapidly adopting DevOps practices.

So, why is putting the Sec in DevSecOps so important today?

According to Gartner research, 2020 is the inflection point where more than 50% of organizations will adopt DevOps practices. This adoption is expected to continue at a rate of 20% year over year for the next 5 years. This accelerated DevOps adoption is justified as it offers many advantages including:

• Faster release times
• Higher SW quality
• Reduced failure rates
• Cost savings

However, with all these advantages there are also some disadvantages. First among these is the risk of releasing vulnerable applications and the concern of being hacked. To understand this better, let’s look at an example:

This results in significant vulnerabilities in production as issues are only remediated months after a release is completed!

Now that we understand the problem, where should we focus?

According to the latest Forrester Wave, >70% of security incidents occur at the web layer. With the accelerated adoption of APIs and the less mature threat models for Web Applications and APIs, these risks are continually increasing.

How do you Add the Sec to DevSecOps?

Now that we understand the importance of adding application security into your DevOps environment (adding Sec to DevSecOps), what do you need to do to achieve this?

There are a number of aspects to consider:

• People: Putting the correct organization in place
• Process: Establishing the right processes
• Technology: Implementing solutions that enable you to achieve this

In order to effectively implement DevSecOps an organization needs to share the responsibility (and joy) of security with the development and QA organizations. Due to the increased velocity of development and the ratio between developers and security professionals in the organization (up to 100:1 in many cases), it is impossible to achieve this goal without sharing the ownership for security. You can read more about this in our recent post about security champions and how to create them. 

Once the team is in place you need to make sure you have the correct processes to facilitate effective SecOps. These processes include feedback loops for:

• Defining the correct procedures for ensuring security is timely and effective
• Making sure you have the right coverage
• Identifying vulnerabilities early
• Remediating vulnerabilities when they are identified
• Validating the fixes that were implemented
• Facilitating feedback loops for continuous improvement

To learn more about this, you can follow our blog post about it here: https://brightsec.com/blog/devsecops-tooling-best-practices/

Last but certainly not least, you need to implement the correct technology that will enable the organization to effectively implement DevSecOps. These solutions need to be built from the ground up to enable developers and QA professionals to adopt them and must include these key features:

• Seamless integration into the SDLC
• Making sure scans can complete at the speed of DevOps while effectively identifying vulnerabilities.
• Provide different users with different interfaces that will enable them to adopt solutions as part of their standard workflows and not change their flows.
• Eliminate false positives in an automated manner and don’t delay (and annoy) developers by having them waste hours sifting through false positives. 
• Provide clear and effective remediation guidelines.

Solutions like Bright are specifically built to enable organizations to add the Sec into DevSecOps.

When implemented correctly, organizations can achieve amazing results.

To learn more about effectively implementing DevSecOps please reach out to Bright and speak with our experts

Table of Contents

1. ‘Develop’ a Culture of Security…
2. Empowering your teams to scale security testing, at speed.
3. Security feedback loop
4. Accuracy of and Trust in the Tooling
5. Achieving DevSecOps with Bright

DevOps teams have become successful in releasing code at speed, whether for webapps or APIs, but with the lack of testing automation, are releasing vulnerabilities at speed too.

To achieve DevSecOps, you need to bake security into your rapid-release cycles, requiring the adoption of effective tools and practices, to unify your teams across application development, QA testing, and of course your security teams, under a common DevSecOps methodology.

Below are some key aspects to consider when implementing tooling to your DevSecOps pipelines:

1. ‘Develop’ a Culture of Security…

Not really specific to tooling, but one of the main pillars that is critical to achieving DevSecOps – security culture; once you have management buy-in, it’s about collaboration between your development and security teams, breaking down the silos and creating champions for this change. These champions can serve as the go between that speaks the different languages of the pipeline itself

2. Empowering your teams to scale security testing, at speed

When adopting DevSecOps, you are shifting security testing left, i.e. into the hands of your developers, who need to be the first line of defense, enabling them to detect, prioritise and treat security defects like they do with functional defects, to fix them early.

To do this however, developers need tools they can actually use…not another tool built for security professionals that is going to be disabled and join your other shelfware. For modern development environments, you need a modern DAST with a Dev First security approach, that is simple and intuitive to use where you dont need to be a cyber security expert to configure the tests and understand the output. 

Having a DAST that tests both your WebApps and APIs will give you that single pane of glass, additional buy-in from your teams and longevity, reducing your TCO.

3. Security feedback loop

With scale and speed comes automation, requiring a DAST tool to detect your vulnerabilities early. You need to provide your developers with the ability to scan every build / commit from their dashboard and to then automatically raise tickets with GitHub or Jira for example, into a feedback loop, so that each security player in your team has visibility, from your developers, QA / security team, to the CISO. 

4. Accuracy of and Trust in the Tooling

Having a tool that is easy to use and integrated into your pipeline is great, but if it is setting off false alerts (false positives) and your builds are failing because of these, then your developers will soon make their feelings felt. The results need to be accurate and deliver actionable results with remediation guidelines for your developers to remediate early. The manual validation of vulnerabilities is slow and expensive and so a tool that removes these is essential to maintain the speed of DevOps while delivering security compliance. If you are a CISO, how can you effectively evaluate your risk, on demand, when your results are skewed with these false positives and are draining your internal security team as they scramble to manually validate the findings..?

Achieving DevSecOps with Bright

Bright enhances DevSecOps at its core, with a Dev First approach to test your WebApps and APIs

Key features of our technology include:

• Shallow learning curve: to establish a culture of security testing across your pipelines
• Built for Developers: We empower developers to detect and fix vulnerabilities on every build, enabling them to leverage multiple discovery methods to initiative a scan, including:
  • Crawling – for full automation
  • HAR files – generated per build/commit for scope defined testing or by QA Automation
  • OpenAPI (Swagger) files or Postman Collections – to test APIs or Single Page Applications
• Smart Scanning functionality: leveraging sophisticated algorithms to carry out the right tests against the target, removing complexity for developers whilst ensuring scans are automatically optimised to maximise speed and prevent development drag
• Built for Modern Technologies: Microservices, Single Page Applications, APIs (REST, GraphQL) are all supported 
• 0 (Zero) False Positives: The only tool with fully automated validation of every vulnerability detected, freeing up valuable time for your security team and saving a considerable amount money, to release fast and be secure by design
• Seamless Integration: Rest API, CLI for developers, or with common tools such as CircleCI, Jenkins, Jira, GitLab, Github, AzureDevOps and more

To find out how you can leverage our technology to achieve DevSecOps for your WebApps and APIs, please do get in touch or request a demo here.

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.