Category Archives: Application Security

Imperva Makes Major Expansion in Application Security

When Imperva announced in 2018 it would acquire the application security solution provider Prevoty, a company I co-founded with Julien Bellanger, I knew it would be a win-win for our industry. Prevoty’s flagship product, Autonomous Application Protection, is the most mature, market-tested runtime application self-protection (RASP) solution (as proof, Prevoty was just named a Silver Winner in the Cybersecurity Excellence Awards). Together, Imperva and Prevoty are creating a consolidated, comprehensive platform for application and data security.

More importantly, this acquisition is a big win for our customers. The combination of Imperva and Autonomous Application Protection extends customers’ visibility into how applications behave and how users interact with sensitive information. With this expanded view across their business assets, customers will have deeper insights to understand and mitigate security risk at the edge, application, and database.

In parallel with product integrations, our teams of security innovators are coming together. I am delighted to join the Imperva team as CTO and to lead a highly accomplished group to radically transform the way our industry thinks about application and data security. In the coming horizon, we will boost data visibility throughout the stack, translate billions of data points into actionable insights, and intelligently automate responses that protect businesses. In fact, we just released two new features that deliver on those goals: Network Activity Protection and Weak Cryptography Protection. Learn more about these at and also in my interview with eWeek.

Network Activity Protection provides organizations with the ability to monitor and prevent unauthorized outbound network communications originating from within their applications, APIs, and microservices — a blind spot for organizations that are undergoing a digital transformation. Organizations now have a clear view into the various endpoints with which their applications communicate.

The new Weak Cryptography Protection feature offers the ability to monitor and protect against the use of specific weak hashing algorithms (including SHA-1, MD5) and cryptographic ciphers (including AES, 3DES/DES, RC4). Applications that leverage Autonomous Application Protection can now monitor and force compliant cryptographic practices.  

Imperva is leading the world’s fight to keep data and applications safe from cyber criminals. Organizations that deploy Imperva will not have to choose between innovation and protecting their customers. The future of application and data security will be smarter,simpler, and we are leading the way there.

Imperva will be at the RSA Conference March 4-8 in San Francisco. Stop by Booth 527 in the South Expo and learn about the New Imperva from me (I’ll be there Tuesday-Thursday) and other executives! We’ve revamped our suite of security solutions under a new license called FlexProtect that makes it simpler for organizations to deploy our security products and services to deliver the agility they need as they digitally transform their businesses.

Start your day or enjoy an afternoon pick-me-up by grabbing a coffee in our booth Tuesday through Thursday 10-2 pm, while:

  • See a demo of our latest products in the areas of cloud app and data security and data risk analytics
  • Learn more about how our suite of security solutions works in AWS environments

Imperva will also be at the AWS booth (1227 in the South Expo hall). There, you can:

  • Hear how one of our cloud customers, an U.S.-based non-profit with nearly 40 million members, uses AAP to detect and mitigate potential application attacks, Tuesday, March 5th from 3:30 – 4:00 pm in the AWS booth
  • See a demo of how our solutions work in cloud environments, Tuesday, March 5th 3:30-5 pm and Wednesday, March 6th, 11:30-2 pm
  • FlexProtect Pro is now on the AWS Marketplace and makes it easy for AWS customers to understand and consume a SaaS-only Imperva offering. Customers who procure FlexProtect Pro in the marketplace will be billed for what they use on a monthly basis by Amazon.

The post Imperva Makes Major Expansion in Application Security appeared first on Blog.

No One is Safe: the Five Most Popular Social Engineering Attacks Against Your Company’s Wi-Fi Network

Your Wi-Fi routers and access points all have strong WPA2 passwords, unique SSIDs, the latest firmware updates, and even MAC address filtering. Good job, networking and cybersecurity teams! However, is your network truly protected? TL;DR: NO!

In this post, I’ll cover the most common social engineering Wi-Fi association techniques that target your employees and other network users. Some of them are very easy to launch, and if your users aren’t aware of and know how to avoid them, it’s only a matter of time until your network is breached.

Attackers only need a Unix computer (which can be as inexpensive and low-powered as a $30 Raspberry Pi), a Wi-Fi adapter with monitor mode enabled, and a 3G modem for remote control. They can also buy ready-made stations with all of the necessary tools and user interface, but where’s the fun in that? 

Figure 1: Wi-Fi hacking tools

1) Evil Twin AP

An effortless and easy technique. All attackers need to do is set up an open AP (Access Point) with the same or similar SSID (name) as the target and wait for someone to connect. Place it far away from the target AP where the signal is low and it’s only a matter of time until some employee connects, especially in big organizations. Alternatively, impatient attackers may follow the next technique.

Figure 2: Evil Twin Demonstration

2. Deauthentication / Disassociation Attack

In the current IEEE 802.11 (Wi-Fi protocol) standards, whenever a wireless station wants to leave the network, it sends a deauthentication or disassociation frame to the AP. These two frames are sent unencrypted and are not authenticated by the AP, which means anyone can spoof those packets.

This technique makes it very easy to sniff the WPA 4-way handshake needed for a Brute Force attack, since a single deauthentication packet is enough to force a client to reconnect.

Even more importantly, attackers can spoof these messages repeatedly and thus disable the communication between Wi-Fi clients and the target AP, which increases the chance your users will connect to the attacker’s twin AP. Combining these 2 techniques works very well, but still depends on the user connecting to the fake AP. The following technique does not, however.

3. Karma Attack

Whenever a user device’s Wi-Fi is turned on but not connected to a network, it openly broadcasts the SSIDs of previously-associated networks in an attempt to connect to one of them. These small packets, called probe requests, are publicly viewable by anyone in the area.

The information gathered from probe requests can be combined with geo-tagged wireless network databases such as to map the physical location of these networks.

If one of the probe requests contains an open Wi-Fi network SSID, then generating the same AP for which the user device is sending probes will cause the user’s laptop, phone or other device to connect to an attacker’s fake AP automatically.

Forcing any connected device to send probe requests is very easy, thanks to the previous technique.

Figure 3: Sniffing Probe Requests

4. Known Beacons

The final attack I’ll discuss that can lead your user to connect to an attacker’s fake AP is “Known Beacons.” This is a random technique where attacker broadcast dozens of beacon frames of common SSIDs that nearby wireless users have likely connected to in the past (like AndroidAP, Linksys, iPhone, etc.). Again, your users will automatically authenticate and connect due to the “Auto-Connect” feature.

An attacker has connected with your user, now what?

Once attackers have access to your user, there’s a variety of stuff they can do: sniff the victim’s traffic, steal login credentials, packet injection, port scan, exploit the user device, etc. But most importantly, the attacker can also get the target AP password by a victim-customized web phishing attack.

Since the victim is using the black hat hacker’s machine as a router, there are many ways to manipulate the phishing page to look convincing. One of them is a captive portal. For example, by DNS hijacking, he can forward all web requests to his local web server, so that his page appears no matter where the victim tries to access it from. Even worse, most operating systems will identify his page as a legitimate captive portal and open it automatically!

Figure 4: Captive Portal Attack

5. Bypassing MAC Address Filtering

As mentioned, your networks may use MAC Filtering, which means only predefined devices can connect to your network and having the password is not enough. How much does that help?

All MAC addresses are hard-coded into a network card and can never be changed. However, attackers can change the MAC address in their operating system and pretend to be one of the allowed devices can be done easily.

Attackers can easily get the MAC address of one of your network’s allowed devices, since every packet sent to and from your employee’s device includes its MAC address unencrypted. Of course, attackers have to force your employee’s device to disconnect (using deauthentication packets) before connecting to your network using the hacked MAC address.

How Can You Mitigate?

Detecting an Evil AP in your area can be done easily by scanning and comparing configurations of nearby access points. However, as with any social engineering attack, the best way to mitigate is by training your users, which is a critical element of security.

Make sure your network users understand the risk of connecting to open access points and are well aware of the techniques mentioned. Running simulations of the above attacks is also recommended.

Finally, while specific techniques will come and go, social engineering will always remain a popular strategy for attackers. So make sure you and your users remain aware!

The post No One is Safe: the Five Most Popular Social Engineering Attacks Against Your Company’s Wi-Fi Network appeared first on Blog.

Threat Actors Impersonate Oil and Gas Companies in Latest Shade Ransomware Attack

Digital criminals tried to impersonate oil and gas companies in a recent attack campaign distributing Shade ransomware.

Between January and February, Yoroi observed an attack campaign leveraging email as an infection vector. Each of the emails came with an attached ZIP file called The name of this file means “Slavneft order” in English, which includes a direct reference to the Russian oil and gas company PAO NGK Slavneft. Building on this disguise, the ZIP file contained a JavaScript file named «ПАО «НГК «Славнефть» подробности заказа, which translates to “PAO NGK Slavneft order details” in English.

Clicking on the JavaScript file activated a downloader that pulls Shade from one of several compromised websites. At that point, the ransomware payload, which had a VirusTotal detection rate of just 24 out of 69 tools at the time of discovery, encrypted all of the infected machine’s files using Advanced Encryption Standard (AES). It then created a ransom note, which included instructions for victims to visit a dark web site so they could receive payment instructions from the attackers.

A Busy 2019 for Shade

Yoroi isn’t the only digital defense company that recently detected a new Shade ransomware campaign. In January 2019, ESET witnessed a large uptick in emails containing malicious JavaScript attachments, including those responsible for downloading Shade. In February, Carbon Black observed a similar campaign also leveraging JavaScript attachments to target primarily Russian speakers.

These attacks come at a time when targeted ransomware remains one of the most prominent threats targeting organizations. Europol said as much in 2018 after it observed threat actors turning to targeted ransomware, not banking Trojans, as their preferred payload in financially motivated cyberattacks. This preference contributed to Cybersecurity Ventures‘ estimate that ransomware damages would surpass $8 billion by the end of 2018.

How to Protect Against Shade Ransomware

Security professionals can help defend their organizations against Shade ransomware and similar malware by making sure their endpoint software is up-to-date and all applications are updated to their most secure versions. Organizations should also make sure to isolate their data backup systems so that attackers can’t encrypt these copies in the event of a successful ransomware infection.

The post Threat Actors Impersonate Oil and Gas Companies in Latest Shade Ransomware Attack appeared first on Security Intelligence.

Web Application Security Poses Greatest Risk

The majority of vulnerabilities in 2018 were associated with network vulnerabilities, while less than 20% were associated with web applications and APIs, according to the fourth annual Vulnerability Stats Report from Edgescan. When

The post Web Application Security Poses Greatest Risk appeared first on The Cyber Security Place.

SaaS spending increasing by 78 percent year-over-year

43% of the average company’s SaaS application stack changed in the last two years, according to the 2019 Annual SaaS Trends report. This is far greater than the typical employee churn rate. Meanwhile, spending has not slowed down – the average SaaS spend per company increased 78 percent year-over-year across organizations in Blissfully’s dataset. This rapid pace of technology change shows that organizations are willing to go to great lengths to increase their teams’ productivity … More

The post SaaS spending increasing by 78 percent year-over-year appeared first on Help Net Security.

Take Your Relationship With DevSecOps to the Next Level

Feb. 14 is Valentine’s Day, a day to express affection and celebrate the significant relationships in our lives. For some, it’s a great excuse to enjoy a gourmet meal with a loved one, or maybe even just a glass of wine on the couch. For others, it is a day to make their relationship permanent — according to Bing, 50 percent of marriage proposals happen on Valentine’s Day.

Like any relationship, DevSecOps works best when there is a solid commitment. How can you do something special this year to move the needle and take your relationship with DevSecOps to the next level?

Commit to Application Security Testing

If you really want DevSecOps to work, application security needs to be more than an item on a checklist on the way to production. If we aren’t careful, running a scan can become a lot like the old practice of running a nightly build, which would reveal that code compiled, linked and could be deployed. That is helpful, but here’s the real question: Did you do anything with that build to test, validate and verify it? And what happened when a new build was done the next night? In many shops, QA teams were left testing builds that were days or weeks old, and when defects were found, they didn’t know to which build or configuration they applied, leading to confusion and lost time. In today’s DevOps world, continuous integration is the norm, yielding much more meaningful impact on speed and quality.

In the same way, if we are running scans as part of our DevSecOps pipeline, we are bound to identify vulnerabilities. But what next? Is application security a gatekeeper or simply a to-do? If a vulnerability is found, how is it examined to determine its severity? If it is found to be severe, does that stop the pipeline? Is there a process in place for feedback about security vulnerabilities to get to development teams quickly and in context? To improve your relationship with DevSecOps, you need to fully understand and embrace the notion that application vulnerabilities are critical to the overall quality and success of what ends up in production.

Communicate the Real Issues

We’ve all been in situations where we either misunderstood what someone else was saying or felt we were not being understood — sometimes both at the same time. Or maybe we didn’t have all the information we needed to make the best decision. We can relate to the famous line from 1967’s “Cool Hand Luke”: “What we’ve got here is failure to communicate.”

Great communication in the DevSecOps world elevates security from obscurity to an essential component of consumer trust. It is also the difference between a culture that values security and one that merely tolerates it. With that in mind, let’s explore some critical communication skills that can take your relationship with DevSecOps to the next level.

First, communicate the real issues. We all know that security scans, particularly static application security testing (SAST), can be noisy. Do your teams spend a lot of time chasing false positives? If so, that is just eroding trust and increasing the likelihood of missing something important. It’s time to build trust by leveraging artificial intelligence (AI) and machine learning to help filter those out.

Second, talk about the elephant in the room. According to a Stack Overflow survey, more than half of all developers are contributing to open-source projects, and a GitHub survey found that 98 percent of developers are using open-source tools. Clearly, open source is everywhere, and it provides a lot of power to add software development efforts. But, as Uncle Ben famously said to his nephew Peter Parker in Spider-Man, “With great power comes great responsibility.” Do you have a reliable software inventory? Does it include open-source tools and usage? Does everyone agree on it, and is it well maintained? If you are working with third-party vendors or outsourcing development, are you validating the code you receive, including open-source code? When it comes to open source, we have to ask the hard questions and be willing to have difficult conversations. Rest assured, it’s worth it in the long term.

Third, get to the root issues and deal with them faster. As much as we would love to think all our released code is perfect and secure, we know that isn’t the case. New vulnerabilities are found and exploited every day, and that application we knew to be secure last week could be suddenly vulnerable today. Finding and fixing your false negatives before the bad guys do is critical to maintaining trust. Is your tooling able to help you identify potential blind spots? For instance, can it alert you to the use of a new framework against which there are no tests? If a new exploit is announced, can you quickly and reliably cross-reference it against your software to see your risk?

Build a Winning Security Culture to Overcome DevSecOps Challenges

If you have been in the DevSecOps space for any reasonable amount of time, you know it can be challenging. Constant market pressure to deliver features and capabilities at speed, coupled with a market that is full of similar options, means that competition is everywhere. In this environment, trust is becoming a form of currency, with security and privacy being the key elements — and customers are prioritizing security more than ever before.

But each time you include and document security requirements in an application during design instead of after coding, you build credibility into your DevSecOps. Each time you identify a significant vulnerability and deal with it before production, you further develop that trust. And each time your efforts to shift left result in more developers embracing security testing as an integral part of their code, you establish DevSecOps stability. All of these elements are crucial to building a winning cybersecurity culture.

We all have relationship goals. With a firm commitment, better communication and perseverance in the face of challenges, you will be well on your way to making DevSecOps your Valentine in 2019.

The post Take Your Relationship With DevSecOps to the Next Level appeared first on Security Intelligence.

Malicious Windows EXE Files Infect macOS Users With Infostealers and Adware

Security researchers discovered several Microsoft Windows EXE files using malicious payloads to infect macOS users with infostealers and adware.

Trend Micro found one adware-bearing sample hiding within an installer for the Windows and Mac firewall app Little Snitch, which is available for download from various torrent websites. The sample was able to bypass Mac’s Gatekeeper, since this built-in protection mechanism doesn’t conduct code signature checks for or otherwise verify EXE files on machines running macOS.

Contained within the ZIP file downloaded from the torrent websites is a DMG file that hosts the Little Snitch installer. This installer hides an EXE file that loads an infostealer. The malware then gathers basic system information, such as Memory, BootROMVersion and SMCVersion, and scans the /Application directory for installed apps, such as App Store, FaceTime and Mail. After completing these steps, the malware sends all its findings to its command-and-control (C&C) server.

Additionally, the executable is capable of downloading several files from the internet. These files, in turn, download adware and other potentially unwanted applications.

Bridging Windows and macOS With Malware

These files don’t constitute the only instance of a digital threat crossing between Windows and macOS. In May 2017, for instance, Fox-IT identified a Mac OS X version of Snake malware, which traditionally targets the Windows platform. Less than a year later, security researcher Patrick Wardle of Objective-See uncovered CrossRat, a versatile threat capable of targeting Windows, macOS and Linux machines.

In a few cases, researchers have even observed attack campaigns distributing separate threats that target Windows and Mac computers. Security researchers at Microsoft came across one such instance in 2011 containing both the Mac-based Olyx backdoor and other Windows malware.

How to Defend Against Malicious EXE Files

Security professionals can help protect against adware-laden EXE files by creating security policies that limit the types of websites from which employees can download applications. They can frame this policy within the context of a larger app approval framework through which security teams follow a logical sequence to upload/review apps and ensure vendor integration. At the same time, security professionals should apply user activity analytics to a long-term data repository to sufficiently protect corporate data against digital threats like infostealers.

The post Malicious Windows EXE Files Infect macOS Users With Infostealers and Adware appeared first on Security Intelligence.

How Imperva’s New Attack Crowdsourcing Secures Your Business’s Applications

Attacks on applications can be divided into two types: targeted attacks and “spray and pray” attacks. Targeted attacks require planning and usually include a reconnaissance phase, where attackers learn all they can about the target organization’s IT stack and application layers. Targeted application attacks are vastly outnumbered by spray and pray attacks. The perpetrators of spray and pray attacks are less discriminating about their victims. Their goal is to find and steal anything that can be leveraged or sold on the dark web. Sometimes spray and pray attacks are used for reconnaissance, and later develop into a targeted attack.

One famous wave of spray and pray attacks took place against Drupal, the popular open-source content management system (CMS). In March 2018, Drupal reported a highly critical vulnerability (CVE-2018-7600) that earned the nickname, Drupalgeddon 2. This vulnerability enables an attacker to run arbitrary code on common Drupal versions, affecting millions of websites. Tools exploiting this weakness became widely available, which caused the number of attacks on Drupal sites to explode.

The ability to identify spray and pray attacks is an important insight for security personnel. It can help them prioritize which attacks to investigate, evaluate the true risk to their application, and/or identify a sniffing attack that could be a precursor to a more serious targeted one.

Identifying Spray and Pray Attacks in Attack Analytics

Attack Analytics, launched in May 2018, aims to crush the maddening pace of alerts that security teams receive. For security analysts unable to triage this alert avalanche, Attack Analytics condenses thousands upon thousands of alerts into a handful of relevant, investigate-able incidents. Powered by artificial intelligence, Attack Analytics automates what would take a team of security analysts days to investigate and cuts that investigation time down to a matter of minutes.

We recently updated Attack Analytics to provide a list of spray and pray attacks that may hit your business as part of a larger campaign. We researched these attacks using crowdsourced attack data gathered with permission from our customers. This insight is now presented in our Attack Analytics dashboard, as can be seen in the red circled portion of Figure 1 below.

Figure 1: Attack Analytics Dashboard

Clicking on the Similar Incidents Insights section shows more detail on the related attacks (Figure 2). An alternative way to get the list of spray and pray incidents potentially affecting the user is to login to the console and use the “How common” filter.

Figure 2: Attack Analytics Many Customers Filter


A closer view of the incidents will tell you the common attributes of the attack affecting other users (Figure 3).

Figure 3: Attack Analytics Incident Insights

How Our Algorithm Works

The algorithm that identifies spray and pray attacks examines incidents across Attack Analytics customers. When there are similar incidents across a large number of customers in a close amount of time, we identify this as a likely spray and pray attack originating from the same source. Determining the similarity of incidents requires domain knowledge, and is based on a combination of factors, such as:

  • The attack source: Network source (IP/Subnet), Geographic location
  • The attack target: URL, Host, Parameters
  • The attack time: Duration, Frequency
  • The attack type: Triggered rule
  • The attack tool: Tool name, type & parameters

In some spray and pray attacks, the origin of the attack is the most valuable piece of information connecting multiple incidents. When it is a distributed attack, the origin of the attack is not relevant, while other factors are relevant. In many cases, a spray and pray attack will be aimed at the same group of URLs.

Another significant common factor is the attack type, in particular, a similar set of rules that were violated in the Web Application Firewall (WAF). Sometimes, the same tools are observed, or the tools belong to the same type of attacks. The time element is also key, especially the duration of the attack or the frequency.

Results and Findings

The Attack Analytics algorithm is designed to identify groups of cross-account incidents. Each group has a set of common features that ties the incidents together. When we reviewed the results and the characteristics of various groupings, we discovered interesting patterns. First, most attacks (83.3%) were common among customers (Figure 4). Second, most attacks (67.4%) belong to groups with single source, meaning the attack came from the same IP address. Third, Bad Bot attacks still have a significant presence (41.1%). In 14.8% of the attacks, a common resource (like a URL) is attacked.

Figure 4: Spray & Pray Incidents Spread

Here’s an interesting example – a spray and pray attack from a single IP that attacked 1,368 customers in the same 3 consecutive days with the same vulnerability scanner, LTX71. We’ve also seen Bad Bots illegally accessing resources, attacking from the same subnet located in Illinois using a Trustwave vulnerability scanner. These bots performed a URLs scan on our customers resources – an attack which was blocked by our Web Application Firewall (WAF). Another attack involved a German IP trying to access the same WordPress-created system files  on more than 50 different customers with a cURL. And the list goes on.

Focusing on single-source spray and pray incidents has shown that these attacks affect a significant percentage of our customers. For example, in Figure 5 we see that the leading attack came from one Ukrainian IP that hit at least 18.49% of our customers. Almost every day, one malicious IP would attack a significant percentage of our customers.

Figure 5: Single Source Spray & Pray Accounts Affected

More Actionable Insights Coming

Identifying spray and pray attacks is a great example of using the intelligence from Imperva’s customer community to create insights that will help speed up your security investigations. Spray and pray attacks are not the only way of adding insights from community knowledge. Using machine-learning algorithms combined with domain knowledge, we plan to add more security insights like these to our Attack Analytics dashboard in the near future.

The post How Imperva’s New Attack Crowdsourcing Secures Your Business’s Applications appeared first on Blog.

Application Security Firm ShiftLeft Raises $20 Million

Application security firm ShiftLeft on Tuesday announced that it raised $20 million in a Series B funding round, which brings the total raised by the company to nearly $30 million.

The funding round was led by Thomvest Ventures, with participation from new investor SineWave Ventures and existing investors Bain Capital Ventures and Mayfield.

read more

Attackers repackage popular Android VPN app with Triout malware

Triout malware was first detected in August 2018 which infected Android applications and had spyware capabilities such as recording phone calls and text messages, and more. Recently, the malware was

The post Attackers repackage popular Android VPN app with Triout malware appeared first on The Cyber Security Place.

The Benefits of Correctly Deploying a PKI Solution

With new threats to data emerging every day, public key infrastructure (PKI) has become an increasingly larger part of enterprises’ information security and risk management strategies. Research has found that 43% of

The post The Benefits of Correctly Deploying a PKI Solution appeared first on The Cyber Security Place.

Moving to the Hybrid Cloud? Make Sure It’s Secure by Design

Many organizations have such a positive first experience with cloud computing that they quickly want to move to a hybrid cloud environment with data and workloads shared between private and public clouds. The flexibility and control that a hybrid cloud provides is why it is expected to be the dominant cloud computing model for the foreseeable future.

However, companies often don’t think about security issues until after they are well along in the process of building a hybrid cloud. This can lead to nasty surprises when they realize this environment introduces some unique security considerations that don’t exist in traditional infrastructure. That’s why a hybrid cloud needs to be secure by design.

Cloud Security Is a Shared Responsibility

Public cloud providers offer enterprise-class security, but that doesn’t absolve customers from responsibility for protecting data, enforcing access controls and educating users. Private cloud security is complicated because private clouds can take many forms. They may be hosted entirely on-site, entirely in the public cloud or some combination. Private cloud infrastructure can also be dedicated to a single tenant or shared across multiple zones with isolation providing dedicated resources. Each environment has different security demands.

The scale and dynamism of cloud computing complicates visibility and control. Many customers incorrectly believe that cloud providers take care of security. In fact, security is a shared responsibility. In my experience, most cloud security failures occur because customers don’t live up to their part of the bargain.

No single cloud security mechanism does the entire job. There is also little consensus about what the ideal cloud security environment should look like. As a result, most product offerings in this market are still evolving. Secure by design starts with assessing risk and building a framework for technology.

A New Way of Computing

Moving to the cloud doesn’t mean relinquishing total control, but it does require embracing a new security mindset based on identity, data and workloads rather than underlying platforms. Security professionals who can reorient themselves around business enablement rather than device protection are particularly well-suited to securing public clouds.

Cloud computing is highly distributed and dynamic, with workloads constantly spinning up and down. Visibility is essential for security. According to Gartner, cloud security should address three core topics that have not traditionally been an IT discipline: multitenancy risk, virtualization security and software-as-a-service (SaaS) control.

Multitenancy risk is inherent to cloud architectures because multiple virtual machines (VMs) share the same physical space. Major public cloud providers go to great lengths to mitigate the possibility that one tenant could access data in another VM, but on-premises infrastructure is susceptible if the servers are not configured properly. Changes made to one hybrid cloud environment may also inadvertently affect another.

Virtualization security refers to the unique risks of virtualized environments. While hypervisors and VMs are in many ways more secure than bare-metal environments because the operating system is isolated from the hardware, the use of shared resources like storage and networking also introduces potential vulnerabilities that don’t exist on dedicated servers.

SaaS environments require greater attention to authentication and access control because the user doesn’t own the network. Governance standards need to be put in place to ensure that users take appropriate precautions with data and that all necessary regulatory and compliance guidelines are met.

Without these new competencies, organizations will struggle to gain visibility into their hybrid cloud environments, making it almost impossible to determine which computing and storage tasks are taking place where, using which data and under whose direction. In that situation, provisioning and enforcement of policy can quickly become impractical. But if organizations practice secure-by-design principles using new cloud-native tools, they can get a single-pane-of-glass view into activity that enables policy enforcement.

Three Keys to Secure Hybrid Cloud Deployments

Three areas merit special attention: encryption, endpoint security and access control.

Encryption is the best form of data protection. Data moving to and from the public cloud should be encrypted at all stages, and sensitive data should never be left unencrypted. All cloud providers support encryption, but not necessarily by default. Customers need to choose the type of encryption that is most appropriate and secure encryption keys.

When public cloud services are accessed over the public internet, special attention needs to be paid to endpoint security to prevent the risk of creating access points for attackers or becoming targets of malware. For example, an attacker who compromises a PC and logs on as an administrator for the company’s public cloud effectively has the keys to the kingdom. Hardware firewalls aren’t protection enough.

Secure web gateways (SWGs) utilize URL filtering, advanced threat defense (ATD) and malware detection to protect organizations and enforce internet policy compliance. SWGs are delivered as both physical and virtual on-premises appliances, cloud-based services or hybrid cloud/on-premises solutions. They provide an additional layer of protection against destructive attacks such as ransomware and enable safer and more efficient adoption of cloud-based services.

Finally, cloud-specific access control is a necessity if employees, contractors and vendors are to use both public and private clouds. Single sign-on (SSO) and federated access controls can minimize inconvenience while maintaining control and security monitoring.

Identity and access management-as-a-service (IDaaS) works in both multitenant and dedicated environments. It provides identity governance and administration, access management, and analytics functions that span the organization’s entire cloud environment. IDaaS can also be integrated with existing access management software to manage access to legacy applications.

The Cloud Security Alliance has an extensive library of resources that cover practices for hybrid cloud security. Organizations should familiarize themselves with these guidelines before beginning the migration process. Building security into hybrid infrastructure from the beginning minimizes the pain and delay of backfilling later.

The post Moving to the Hybrid Cloud? Make Sure It’s Secure by Design appeared first on Security Intelligence.

The Challenges of DIY Botnet Detection – and How to Overcome Them

Network of platforms with bots on top botnet cybersecurity concept 3D illustration

Botnets have been around for over two decades, and with the rise of the Internet of Things (IoT) they have spread further to devices no one imagined they would – printers, webcams, and even toasters and fridges.

Some botnets enlist infected devices to mine cryptocurrency or steal passwords from other devices. But others are, in fact, legions of bot-soldiers waiting for a command to attack a target server. Here at Imperva, we detect botnets and prevent them from harming our customers. Botnet detection isn’t an easy task. In this post I’ll attempt to describe the pitfalls in botnet detection.

Detecting a Botnet

So what’s a botnet? Simply put, it’s a cluster of bots – compromised computers and devices – that perform commands given by the botnet owner. Usually, the botnet owner will dedicate one compromised device as the Command and Control (CnC) server for communication with his bots. Thus, the best way to discover a botnet is by finding its CnC, but that’s usually not a simple task. Let me explain why.

How can we Detect a Botnet

The smoking gun that points to a botnet is its CNC. Obviously, here at Imperva we don’t protect CnCs or bots – we protect against attacks originating from them. We are successful enough that it’s very unlikely any bot or CnC will be able to operate behind our service. Practically speaking, our best option to detect botnets is to examine their attacks on sites we protect.

When looking at exploit attempts, there are a few possible indicators of a botnet. For example, if the same IPs attack the same sites at the same time using the same payloads and attack pattern, there’s a good chance they’re part of the same botnet. This is especially true if many IPs and sites are involved. One common example is a DDoS attempt by a botnet on a web service.

A botnet attempting to DDoS a few sites: as the owner of the sites, during the attack you’ll see a large group of IPs sending many requests to the login page and the shopping cart page.

Reasons for False Positives

Even though I might have made detecting botnets sound quite simple, it really isn’t. Some payloads are so widely used that it’s difficult to distinguish between a truly-concerted botnet attack and a random one-off attack. Attackers can change their IPs by using a VPN or a proxy, making it look like many attackers are involved. Some proxy services even allow a single user to utilize many different IPs.

Hacking Tools can be Deceiving

Hacking tools and vulnerability scanners are similar to botnets as well. These tools generate the same payloads and attack patterns, and many hackers use them, regardless of the color of their hat. While it is an unlikely scenario, if different players conduct a Penetration Test on the same site at the same time, it’ll look like a coordinated botnet attack.

How can we Differentiate?

There are many ways to identify clients, but in this case simply looking at the raw request will do the trick. Luckily for us, because vulnerability scanners are so popular, it is easy to find out if they’re to blame. Sometimes, the user agent header will reveal the name of the tool. In other cases, Googling the payload will lead you straight to the tool.

Bot(net) Or Not?

Grab ‘em by the Payload

To discover botnets, we decided to use two different approaches. The first approach uses a naive back-and-forth algorithm to find botnets.

Any website owner can analyze data from their weblogs and use this technique.

You might want to improve this algorithm, and you can do so in several ways. You can separate the request to parameters and then search for a popular parameter value. Try using Levenshtein Distance, or any other distance algorithms, to find similar payloads. For this research, we decided to simply separate requests into query strings and post bodies.

Any website owner can analyze data from their weblogs and use this technique.

You might want to improve this algorithm, and you can do so in several ways. You can separate the request to parameters and then search for a popular parameter value. Try using Levenshtein Distance, or any other distance algorithms, to find similar payloads. For this research, we decided to simply separate requests into query strings and post bodies.

The following charts plot the daily activity of IP addresses involved in an attack on our websites during a given timeframe. In red, you can see the percentage (left axis) of IPs that participated in an attack on any given day, which is calculated by taking the number of attacking IPs that day and dividing by the highest number of attacking IPs on ANY day during our time frame.

Similarly, the blue line represents the percentage (left axis) of attacked sites on any day, calculated by dividing the number of protected sites attacked that day by the highest number of protected sites attacked during this timeframe. The yellow bars represent the median (right axis) number of days all of the attacking IPs on that day have attacked overall during the studied timeframe. For instance, if 30 IPs attacked on one day and the median number shown is 10, that means 15 IPs have attacked more than 10 days, and 15 IPs have attacked fewer than 10 days.

Attack #1

A Backdoor Uploader. Nearly 1,000 IPs attempted to upload a backdoor to over 1,000 sites. The payload coming from the different IPs was exactly the same, but that’s not the best part. It appears that the payload is a variation of the infamous CKnife webshell. Combined with the low IP turnover rate (i.e. the same IPs are attacking half of the time, as shown by the high median yellow bars), chances are that this is a botnet.

Attack #2

Nearly 4,000 IPs used a payload meant to test for a SQL Injection vulnerability. A search for that payload revealed that the SQLI Dumper tool is behind the attack. Looking at other attacks performed by these IPs revealed attempts at Remote Code Execution (RCE), backdoor upload and other attacks that aren’t in the SQLI Dumper playbook. Also, while the number of attacking IPs grows – the median number of days attacked by the attacking IPs shrinks. Testing for correlation between them revealed a strong negative correlation (-0.84). Combining this data with the medium IP turnover rates (shown by the yellow bars) indicates that this attack is comprised of a few core bots and many temporary IPs. We tested this hypothesis and found that ~50 IPs were involved during the entire attack. This might mean that several different groups are using the same payload, and this is not a single botnet.

Attack #3

A tool that looks like a botnet, but it’s not. Let me explain why. Although nearly 2,000 IPs were involved, it’s easy to see that the median number of days they attacked is pretty low. This means that in most cases hackers used these IPs to attack for a few days, and then stopped using them completely. This pattern isn’t typical of botnets because botnet owners will usually reuse the IPs in their disposal. Googling the payload revealed that a popular hacking tool named AutoexploiterBot is behind this attack. Likely, multiple users used it to attack us which explains why it wasn’t the same attacking IPs.

The payload sent during the attack:

The base64 in the exploit than decodes to a mid-stage code, which decodes to a webshell with a visible link to the tool:

Bringing out the Big Guns

The second algorithm we used for botnet detection has a more sophisticated approach. We utilized our specialized Client Classification abilities to cluster clients that carried out many coordinated attacks.

Out of the hundreds of results we got, we focused on the most interesting ones:

Attack #4

Backdoor Uploader revisited. This is the same backdoor uploader we found using the first approach. This time we caught more of its core IPs as indicated by the low turnover rate (i.e. the high yellow median bars). It’s interesting we found this botnet using both approaches, even though they are inherently different.

Attack #5

Probably the most distinguishable of them all. This botnet has a handful of malicious Remote Code Execution (RCE) payloads. Each RCE embeds the same unique site address somewhere within the victim’s server. Furthermore, its IPs almost never change, as indicated by the very high yellow bars. To recap – we have the same few payloads, advertising the same site, coming from the same IPs. Thus strongly indicating this is a botnet.

Attack #6

A botnet blogpost isn’t complete without a Spambot. This one is aiming at the comment section of a web site, trying to add comments advertising a Chinese gambling site. What’s fascinating is that it allows us to glimpse multiple cycles of spam campaigns. In each cycle, a varying number of IPs attack for a short while and then stop. A possible explanation would be that this Spambot is for hire, and each cycle is a paid spam campaign.


Botnets can be a tricky thing to detect and mitigate, but even analyzing the simplest weblog entries can supply valuable insight, especially against continuous campaigns. All of the botnets we found can cause real damage to your site and customers. Some will take over your site and others will expose private information.

Once you find an IP that belongs to a botnet, you can block it and use it to discover more IPs that are part of the botnet. Some of the payloads we found in this research were a few years old, or new variants of old exploits. So digging into your log history might give you insight to protect your site the next time a botnet comes around.

The post The Challenges of DIY Botnet Detection – and How to Overcome Them appeared first on Blog.

Hey Siri, Get My Coffee, Hold the Malware

With Apple’s introduction of iOS 12 for all their supported mobile devices came a powerful new utility for automation of common tasks called Siri Shortcuts. This new feature can be enabled via third-party developers in their apps, or custom built by users downloading the shortcuts app from the app store. Once downloaded and installed, the Shortcuts app grants the power of scripting to perform complex tasks on users’ personal devices.

But accessing the phone from Siri Shortcuts also presents some potential security risks that were discovered by X-Force IRIS and reported to Apple’s security team. This post gives some insight into potential attack scenarios using Shortcuts and reminds users that keeping a tight lid on app permissions is a critical step to upping security on devices and the way we use them.

Shortcuts Make Life Easier, Right?

Want to turn all your lights to disco, play your favorite soundtrack, and text your friends to come over? Or maybe perform complex mathematical computations with a single voice command? Siri Shortcuts can help do that and facilitate much more in user interaction with their devices, directly from the lock screen or via existing apps they use. These shortcuts can also be shared between users, using the app itself via iCloud, which means they can be passed around rather easily.

Beyond users wishing to automate daily activities, app developers can create shortcuts and present them to their user base from within their apps. The shortcut can then appear on the lock screen or in ‘search’ when it is deemed appropriate to show it to the user based on time, location and context. For example, a user approaches their usual coffee shop, and the relevant app pops up a shortcut on the screen to allow them to order the usual cup of java and pay for it on the app before they even enter the coffee shop.

These shortcuts are a nifty addition to Siri’s functionality, but while allowing extended functionality and personalization of the use of Siri, there are some less favorable scenarios to consider.

Siri Shortcuts Can Also Be Abused by Attackers

Siri Shortcuts can be a useful tool for both users and app developers who wish to enhance the level of interaction users have with their apps. But this access can potentially also be abused by malicious third parties. According to X-Force IRIS research, there are security concerns that should be taken into consideration in using Siri Shortcuts.

Siri Demanding Ransom?

Using Siri for malicious purposes, Shortcuts could be created for scareware, a pseudo ransom campaign to try to scare victims into paying a criminal by making them believe their data is in the hands of a remote attacker.

Using native shortcut functionality, a script could be created to speak the ransom demands to the device’s owner by using Siri’s voice. To lend more credibility to the scheme, attackers can automate data collection from the device and have it send back the user’s current physical address, IP address, contents of the clipboard, stored pictures/videos, contact information and more. This data can be displayed to the user to convince them that an attacker can make use of it unless they pay a ransom.

To move the user to the ransom payment stage, the shortcut could automatically access the Internet, browsing to a URL that contains payment information via cryptocurrency wallets, and demand that the user pay-up or see their data deleted, or exposed on the Internet.

The More the Merrier

To add to this scenario, the malicious shortcut can also be configured to spread to other devices by messaging everyone on the victim’s contact list, prompting them to download and install the same shortcut. This would be a cost effective and hard to detect distribution method, coming from a trusted contact.

In a video we created we show how native functionality can be used to make convincing ransom threats to someone running a malicious Siri Shortcut.

Pay attention to the following steps taking place in the video:

  1. The shortcut is configured to gather personal data from the device:
  • It can collect photos from the camera roll.
  • Grab the contents of the clipboard.
  • Get the physical address of the device’s location.
  • Find the external IP address.
  • Get the device’s model.
  • Get the device’s current mobile carrier
  1. The Siri Shortcut can message the information to an external party; this data can also be sent over SSH to the attacker’s server using native functionality.
  2. The Shortcut can set the brightness and volume of the device to 100%
  3. It can turn the device’s flashlight on and off while vibrating at the same time to get the user’s attention and make them believe their device has been taken over.
  4. The Shortcut can be made to speak a ransom note which can include convincing personal details to make the user believe the attacker. For example, it can indicate the IP address and physical address of the person and demand payment.
  5. The Shortcut can be further programmed to then display the spoken note in a written alert format on the device.
  6. To nudge the user to pay up, the Shortcut can be configured to open a webpage, accessing a URL that contains payment information to a cryptocurrency wallet, or a phishing page demanding payment card/account information[1].
  7. To spread around, and since Siri Shortcuts can be shared among users, the malicious Shortcut could also send a link to everyone in the user’s contact list giving it a “worm like” capability[2] that’s easy to deploy but harder to detect.

Not Only Ransom

In our security research labs, we tested the ransom attack scenario. The shortcut we created was named “Ransom” in the video, but it could easily be named any other name to entice users to run it. Lures, such as game cheats/hacking, unlocking secret functionality in apps, or getting free money, often entice users to tap on a shortcut and see where it leads.

From our researchers’ experience, users may fall prey to social engineering and end up installing and running malicious code or apps on their devices.

Using Siri Shortcuts More Safely

Siri Shortcuts has its merits and some security concerns to be aware of. Yet, it is possible to use this functionality in a safer manner.

  1. Never install a Shortcut from an untrusted source.
  2. Check the permissions that the shortcut is requesting and never give permission to portions of your phone you are not comfortable with. Things like photos, location and camera could be used to obtain sensitive information.

Siri Shortcut on iOS12

  1. Use the show actions button before installing a third-party shortcut to see the underlying actions the shortcut might take. Look for things like messaging data to numbers you don’t recognize, emailing data out, or making SSH server connections to servers.

Checking permissions for Siri Shortcut

Apple Controls Centralized Patch Control

Siri Shortcuts is a native feature of iOS12; however, in order to utilize custom shortcuts, one must download the Shortcuts app from Apple’s app store. This gives Apple the ability to patch/update the functionality of the Shortcuts app without having to update the entire OS version.

Users Should Be Very Selective with App Permissions

It’s also important to note that using the shortcuts is designed for, and therefore requires, a lot of user interaction. First, users must download and install the shortcut from a shared source, and then manually tap it to run. Users must also grant access to photos, contacts or any sensitive data the shortcut wants access too.

A sharp reminder to validate anything you install on your mobile device as Shortcuts allows you to see everything the script is capable of before installing. As tempting as it might be to just scroll past that text and hit accept, users must be more aware of good security practices, which includes reading and understanding anything they authorize to run on their device.

[1] Not shown in this video

[2] Not shown in this video

The post Hey Siri, Get My Coffee, Hold the Malware appeared first on Security Intelligence.

Radware Blog: How Secure Is Your Digital Super Bowl Experience?

Over the last few years I have traveled around the world, researching and watching stadiums digitally evolve from the structures I once knew as a kid. I grew up watching the San Diego Chargers play in what was then called Jack Murphy Stadium and now find myself looking at stadiums from a totally different perspective. […]

The post How Secure Is Your Digital Super Bowl Experience? appeared first on Radware Blog.

Radware Blog

This DDoS Attack Unleashed the Most Packets Per Second Ever. Here’s Why That’s Important.

ddos attack was most packets unleashed ever

DDoS attacks are usually measured by the amount of bandwidth involved, such as the 1.35 Terabits per second (maximum) attack directed at GitHub last year, the largest DDoS attack ever at the time.

However, in DDoS attack mitigation, it’s not the amount of bandwidth that matters – it’s the absolute number of packets directed at a network or web site. Packets per second is the true measure of the attack intensity, and that is what is difficult to block and recover from.

Earlier this month, Imperva’s DDoS Protection Service mitigated a DDoS attack against one of our clients which crossed the 500 million packets per second (Mpps) mark. That’s more than four times the volume of packets sent at GitHub last year and we believe is the largest PPS attack publicly disclosed.

How DDoS Attacks Work

DDoS attacks aim to deplete compute or network resources. When that happens, the service becomes unavailable and an outage occurs. Network resources can be broken down into two categories: capacity and infrastructure.

Network Capacity

Depleting network capacity is fairly easy to achieve. A DDoS attack can be launched within a matter of minutes (just google for stressers or booters) and overwhelm the vast majority of websites or enterprise networks.

Avoiding network pipe congestion requires significant network capacity, which is not a cost-effective strategy for the average business. That’s where DDoS mitigation services come into play.

DDoS mitigation/protection service providers tend to provision network bandwidth far greater than the largest observed DDoS attack, making the sheer volume of the attack a non-issue. Since the DDoS capacity is shared between numerous customers, economy of scale becomes the basis for their operational and financial model.

Network Infrastructure

Once we have passed the network capacity barrier, there is still a ton of traffic to be processed. In the case of DDoS mitigation services, these would be the switches, routers, and mitigation appliances. Network appliances mostly evaluate the headers of the packets (every packet!) and rarely inspect the full payload. Their limiting factor is the packet rate, not the packet size.

For mitigation appliances, the PPS challenge is even greater because mitigation is performed using a wide variety of techniques. This requires far more compute processing power than what traditional network appliances require to route or switch a packet.

For a DDoS protection or mitigation service, mitigating a high PPS attack can be its Achilles heel, while a bandwidth-intensive attack can be much easier to handle, even with hundreds of gigabits per second, if it is composed of a smaller number of large-sized packets.

Using PPS Data to Analyze the Github Attack

At 1.35 Terabits per second, the widely-publicized attack on GitHub in 2018 was considered the largest DDoS attack ever at the time. However, how complex was it to mitigate?

The attack was a memcached amplification attack. Amplification attacks use a compromised server to bounce traffic to the attacked server. In other words, a packet of N bytes will be bounced to the attacked server as a packet of size N times the “amplification factor.”

Popular vectors such as NTP and DNS have an amplification factor of up to 556.9 and 54, respectively. Memcached has a whopping amplification factor of up to 51,000, which means:

  • The generated attack mainly consists of large packets and a relatively low PPS rate. The GItHub report indeed confirms a peak of 129.6 million packets per second.
  • The source port of each of the packets was identical (port 11211), as they all came from the same service (on different servers).

Put these two together, and the attack no longer looks so challenging: since the PPS volume is relatively low, a mitigation appliance could be used. Alternatively, it could be a perfect candidate for traffic filtering (i.e. Access Control List), which blocks any packet whose source port is set to 11211. ACLs are available on any switching appliance, which makes it a less sophisticated, but effective option.

Fast Forward to 2019

At Imperva, we are currently seeing DDoS attacks over 500 Gbps on a weekly basis:

While these huge attacks are the largest by bandwidth mitigated by Imperva to date, that wasn’t what made it a potential challenge. Rather, it was the 500 million packets-per-second torrent directed at our customer – the highest volume ever recorded – that made it so intense, and the real challenge to overcome.

The Jan. 10 attack was a syn flood augmented by a large syn flood (packets of 800-900 bytes). The source ports and addresses of the traffic sent to our customer’s server were highly randomized and probably spoofed. Fortunately for us and the client, the attack was mitigated automatically, with no humans involved.

When we investigated, we realized the attack wasn’t generated using new tools, but two common older ones: one for the syn attack and the other for the large syn attack. Although both tools try to mimic legitimate operating systems, there are some odd, suspicion-raising differences. One tool randomizes various parameters but accidentally malforms the packet. The other tool uses a legitimate, almost identical packet, for the entire attack. One possible hypothesis is that these tools, although used in the same attack, were written by two different individuals and then combined to form an arsenal and launch the most intensive DDoS attack against Network infrastructure in the history of the Internet.

When it comes to DDoS protection, bandwidth is not everything. The most demanding attacks are high-volume PPS attacks, because with more packets to process, you need more network hardware and other resources to mitigate them.

Check out the behemoth 2 blog for a deeper dive of how our technology protects against high-volume PPS attacks, or visit our website’s resource section to learn more about Imperva DDoS Protection.

The post This DDoS Attack Unleashed the Most Packets Per Second Ever. Here’s Why That’s Important. appeared first on Blog.

Meet the New Imperva – Defending Your Business Growth Today and Tomorrow


Today’s Imperva is a champion in the fight to secure data and applications, wherever they reside. The threat landscape is dangerous and ever-changing, but our thousands of customers know they can count on Imperva to protect them. No wonder our solutions are recognized as leaders by analysts such as Gartner and Forrester Research.  

However, security is changing. It’s no longer just about protecting your company’s digital assets. It’s also about protecting your employees, partners, customers, and all of their applications, data, API’s, microservices, and even IoT devices. Millions of interactions occur every day that drive business value – and revenue.

Within this vast new universe, traditional lockdown security approaches just don’t cut it anymore. They’re too rigid, create their own security gaps, and stifle your business. What you need is a security posture that assumes an open exchange between data, applications and users. To do that successfully, you need greater visibility into all your digital systems, whether on-premises or in the cloud, so you can quickly pinpoint the threats that matter. You also need agility to adapt to fast-changing DevOps environments. And you need resilient systems that not only prevent data breaches and DDoS attacks but can also recover quickly, too.

In short, your business’s security needs are evolving. Which is why Imperva is also evolving, in order to remain the defender of your business growth, so you never have to choose between innovating for your customers and protecting what matters.

This year, we’ll be launching major expansions to our data and application security solutions. We’re also boosting the visibility delivered by them, distilling millions of data points so that you have actionable insights and the ability to automate the responses that protect your business.

To make it easier for you to focus on your business, we’re also simplifying how we bring our products to market, from the naming, to the packaging, to the pricing. Through a subscription model we call FlexProtect, enterprises can deploy Imperva solutions how and when you need them, in order to quickly gain the protection you need.

This year, Imperva will also be introducing useful new research and thought leadership to help your organization get smarter and respond to threats faster. Additionally, we are committed to making your experience with our brand and products even better. We are introducing an all-new look and feel, which you can check out today starting with our website, the new!

Doing business today has never been more potentially rewarding – or challenging. Security providers need to be up to the task. That’s why Imperva is evolving. We do more than simply guard your data and apps. We’ll help you anticipate real threats, minimize the business impact of any incidents, and build customer trust – all without overstretching limited resources. As your own business evolves, so does Imperva, so we can remain your defender and help you realize your growth ambitions, today and tomorrow.


Protect the pulse of your business.

The post Meet the New Imperva – Defending Your Business Growth Today and Tomorrow appeared first on Blog.

Facebook opens up on System that ‘protects Billions’

Facebook used a blog post on Friday to describe, in detail, the systems that it uses to secure its vast social network, including custom designed tools and so-called "red team" hacks.

The post Facebook opens up on System that ‘protects Billions’ appeared first on The Security Ledger.

Related Stories

The App Approval Workflow Keeps Enterprise Security in Check Without Disrupting Productivity

Mobile applications have become a part of our everyday lives. We use them to get where we’re going, stay in constant communication with others and get the information we need to be productive. Apps are no longer a novelty for today’s workforce; they’re a necessity. And with that necessity comes risk. Just like any enterprise technology, it’s crucial to take security measures to prevent data loss, threats and breaches.

But in the context of the enterprise, where apps are used to drive business outcomes, increase efficiency and improve worker productivity, how do they impact enterprise security? What can IT and security leaders do to ensure that the apps being pushed out to hundreds or even thousands of corporate devices meet security standards?

Security should always be a top priority in the enterprise, especially in today’s malware landscape. Chief information officers (CIOs) and chief information security officers (CISOs) are already taking proactive approaches to stay safe from attackers and combat exposures. With the help of a unified endpoint management (UEM) solution, mobile app security only takes a few steps, and it’s easier than you think.

Do Your Due Diligence Before App Deployment

Security teams must implement processes to prepare applications for enterprise use. To guarantee that apps follow the proper security protocols, IT must ask the following questions:

  • Were the apps developed with security in mind?
    With the abundance of available apps on the market, IT leaders should ensure the apps they need have been developed with no security flaws that could pose a risk to their critical enterprise security and data.
  • Have the apps been properly vetted? What steps and tools have been implemented to ensure the apps IT pushes to end users are, in fact, safe? This examination process helps IT leaders confirm apps are secure and can be approved for deployment.
  • Are existing tools and technologies being used to scan for malicious code and irregularities? Out of all the available tools for IT teams, it’s best to find and use a solution that offers a built-in approach, rather than trying to make multiple tools communicate in a productive manner.

These questions are important to the enterprise at large because they will help guarantee the overall security of mobile applications before they’re distributed to end users.

Register for the Feb. 7 webinar to learn more

A New Framework for App Review and Approval

To get the most out of your apps while ensuring their predeployment security, your IT teams must follow the app approval workflow. It’s now easier to deploy enterprise apps so that every stakeholder — including security officers, IT administrators and development teams — has an opportunity to engage at the right stage of the process and weigh in to verify that the apps are secure and ready for deployment.

The approval workflow follows a logical sequence to make sure every precaution and test is completed to get the app approved for distribution. Third-party vendors have security and malware checks in place to review private enterprise apps. Working in conjunction with a UEM solution, it is now easier to upload, check and deploy enterprise apps to your fleet of devices.

Once the workflow is completed, IT and security leaders can rest assured that they’ve taken all the necessary steps to secure their apps before users even download them.

Follow These Steps for Total Enterprise Security

The app approval framework is now available to all IBM MaaS360 with Watson administrators to help them securely deploy their enterprise apps while using existing technology.

An example of the app approval workflow follows as such:

  1. App upload: The UEM admin uploads the enterprise app to the portal, but does not yet deploy it. Instead, the admin goes to the app approval menu.
  2. Vendor integration: UEM integration must be completed on the security vendor’s site before any approval workflow can begin.
  3. App review: The admin chooses a security vendor for the application approval and submits the app for review.
  4. Results: An email containing the results of the scan is sent to an app approver, such as a security officer who is a UEM admin, for review. The app approver provides a quality check of the results and shares them with internal stakeholders. If the app doesn’t pass enterprise security criteria, it must be patched or coded and resubmitted for review.
  5. App deployment: Once the app is fully approved, it can be deployed to the entire fleet of devices within the UEM portal.

App Approval Workflow Diagram

By having an all-encompassing solution that focuses on desktop, mobile and web apps, IT and security leaders can save time and resources and get their apps reviewed, approved and deployed in no time. This process can also prevent the headache of a potential security breach, which can be a costly endeavor to fix.

Register for the Feb. 7 webinar to learn more

The post The App Approval Workflow Keeps Enterprise Security in Check Without Disrupting Productivity appeared first on Security Intelligence.

The New Currency for Business is Security Culture

As you are no doubt aware, 2018 was yet another banner year for cybercrime. IBM Security Vice President Caleb Barlow recently reflected on the historic data breaches, widespread vulnerabilities and unprecedented onslaught of data privacy regulations affecting businesses across geographies. In such a fast-paced industry where technology — not to mention the threat landscape — is evolving daily, security culture is now a key determinant of success.

In my own experience, security teams are more likely to succeed when they’re viewed as an integral part of the business. Mature organizations recognize the direct connection between trust, user experience and revenue and place the chief information security officer (CISO) or chief security officer (CSO) on equal footing with other C-level executives.

Don’t Put the Chief Security Officer at the Kids Table

If you’re wondering why it matters who the CSO reports to, picture this: You’ve been invited to a holiday dinner with your extended family of 15 adults, but the dining room table only seats 14, and it’s already a tight squeeze. Ultimately, someone will need to sit at the kids table. And while that may be a lot more fun, the conversations that take place there will surely be very different than at the main table.

The same dynamic exists in organizations that do not consider the CSO to be integral to the company’s success. If security is involved in senior leadership activities on an invite-only basis, the organization is only inviting trouble down the road. Security needs to be a part of the larger, mature conversations that take place around the health and state of the business. For instance, what happens when a vulnerability scan turns up high-risk flaws? Are there processes in place to ensure good communication? Who decides who is responsible for the fix? Who validates it? Is the report seen as crucial to ensure overall quality for a release, or is it considered a nuisance, a necessary evil?

Business success is directly tied to great user experiences and protecting sensitive data. Today, most organizations can see a point-in-time view of their security posture and threat landscape, but they need more real-time information about the risks they face to keep up with the threat landscape in 2019. Customers today expect, demand and even assume security is present in the applications they use. Meeting that demand requires high degrees of collaboration and communication, so don’t make it more difficult by relegating security to an island.

Everyone Plays a Role in Security

In today’s software world, where there is growing, extensive use of devices, microservices, components, containers and open-source tools, the potential for things to go wrong is increasing proportionally. For this reason, every department and executive throughout the organization needs to play a role in securing enterprise data.

One of the main problems is that people don’t really know what they have in their environment. If you walk into a development shop and ask five people how many applications their organization supports, you’ll likely get five different answers. And just see what happens if you ask for a full inventory of the services, libraries and components associated with those applications. Any information developers do have is often inconsistent across different departments. For instance, I’ve seen situations where IT had one list, security had another, and the two were never consolidated or cross-referenced. The impact of such a disconnect can be devastating.

What if your organization is using a lot of open-source components and a critical vulnerability emerges for one of them? If your enterprise is reliant on a central IT team but you have inconsistent departmental software inventories, how can you really be sure you’ve identified all the affected systems? And if you depend on employees to manually initiate patching efforts, how can you confirm they actually happened? Too often, the patch management process is a mix of automated efforts for some systems and an honor system for others. When this happens, inconsistent lists, inaccurate inventories and unclear, unenforced policies can easily leave critical systems exposed.

Today, the critical systems that might be left exposed could be sitting in the pockets of your employees — I’m talking about the personal devices they use every day. How aware are your employees of your organization’s policies and procedures? Are they enforced? Are the devices they use to access enterprise data in hotels, coffee shops and in transit secure? Making the problem worse is the often blurred line between personal and professional use. How can you know that all the apps downloaded to these devices are safe? Do you rely solely on your employees to secure their own devices?

The industry has moved beyond simply enforcing password policies. Today, nontechnical employees must play a critical role in security strategy and act as the first line of defense. Take the time to educate them on your policies and, most importantly, how they impact the business. Then, take the necessary steps to enforce them. The policy you implement and enforce today just might prevent a breach tomorrow.

Security Culture Delivers Real Business Value

Security culture is becoming a sort of currency for organizations. Studies such as IBM Security’s “Future of Identity Report” have shown that consumers are prioritizing security over privacy and convenience for nearly all application types. It’s no longer acceptable to simply add in or account for security during the development life cycle; it must be part of the initial design and conception.

For that to happen, security needs to be ingrained in organizational culture, perceived as critical to the company’s success, and inclusive of all departments and employees across the enterprise. Organizations that do this well will be better positioned to build trust among their user base and provide the exceptional user experience that customers demand.

The post The New Currency for Business is Security Culture appeared first on Security Intelligence.

Imperva Increases Self-Service Capability Fourfold with Custom Security Rules

Back in 2014, we introduced Rules (previously IncapRules) to give our customers advanced control over their application security.

Today we’re putting even more of this custom tuning power in the hands of our customers by quadrupling the number of filters available via self-service.

Rules Basics

Rules are an extensive policy engine developed in response to the emergence of increasingly advanced threats as well as the growing demand to add more logic at the edge. Advanced threats continue to drive the need for adaptive security solutions which enable real-time response and flexible, custom security policy enforcement.

Rules are built using filters, operators, and values. Filters are the core function which helps tune manual policies. Customers use filters for advanced bot protection, security against brute-force attacks, and more. Although about 90% of our customers use our out-of-the-box policies in their default preventative settings, leaving the burden of tuning to the Imperva security experts, there are times when some of our customers need to make specific adjustments to their security policies.

The Existing Filter Set

Traditionally, Imperva has limited to 20 the list of filters exposed to our customers. A set of parameters is available for self-service use when defining Rules.

Filters for Rules are divided into three logical groups:

  1. Clients: Information about the connecting client
  2. Requests: Information about the current request
  3. Counters\rates: A running count of the number of actions performed  

As one example, there’s an existing filter for the ID for the client application.

  • Googlebot (Search bot) (6)
  • cURL (Developer Tool) (47)

When adding or editing a rule in the Management Console, you start entering text in the value field to display a list of available values.

Example: ClientId == 15

The New Filters

Behind the scenes, the Imperva Support team and SOC alone have had much more power up until now in terms of custom tuning upon request, with access to approximately 100 different filters.

But by expanding the set of Rules available via self-service to a total of 48 filters, even more policy customization is possible without ever needing to contact the Support team.  

To complement existing self-service Rules for bot protection, protection against Account Takeover (ATO), application hardening, rate limiting, and Advanced Access Control (ACL), the new filters offer the following and more:

  • Advanced optionality when handling advanced bot scenarios
  • Logic based on popular technologies such as Drupal, PHP, Joomla, WordPress and others
    (the idea here is to simplify complex expressions by encapsulating the tech detection and rates within a single command)
  • Client certificate info such as CN, SHA1 and Serial Number


Here are three examples of new filters unveiled to customers:

(1) session-creation-ip_rate

If you set the value here to, say, 800, you will be able to capture sessions with more than 800 requests from a certain IP in 1 minute – a likely indicator of a DDoS attack.

(2) request-rate-ip_rate

This filter measures the rate of requests per IP over a 1-minute period, and if you expect no more than 100 requests, you can set the action to “block” or “alert” because that could indicate that an attacker is trying to scrape your website.

(3) login-bf-drupal_rate

Though we patch by default from the backend to mitigate known exposures such as the latest critical RCE vulnerabilities affecting Drupal, this filter may be useful for our more advanced customers who wish to add an extra layer of logic and protection.

The filter allows you to measure the rate of requests per IP over a period of time to a Drupal login page, helping in detection and prevention of brute-force attacks on Drupal login pages.

The Demand for Logic at the Edge

The customer policy rule engine has proven to be a powerful tool when you need to perform specialized adjustments for specific use cases. Advanced options for building custom security policies complement the default prevention settings in our cloud WAF for complete protection.  

But as organizations of all sizes shift to the cloud and our enterprise customer list has expanded rapidly in turn, the demand for more edge functionality has also increased. We’ve heard time and again that our customers find it very appealing to be able to add advanced logic rules at the edge.

Last year we announced the rollout of advanced Application Delivery Rules. And while we invested in building and improving the engine which drives both of these rule sets, we honed in on the need to (1) develop advanced filters which can help address emerging threats and exploitation and (2) expose logical parts of our classification engine and bot protection layers previously hidden from customer view.

The Move to More Control and Visibility

The newly visible Rules will provide a much more powerful tool for savvy customers who need to tune their policies in order to handle complex cases. This approach is yet another step we’re taking to put enhanced visibility and extended control in our customers’ hands and to stay ahead of the curve in handling the most sophisticated and automated attacks out there.

The post Imperva Increases Self-Service Capability Fourfold with Custom Security Rules appeared first on Blog.

Dynamic Content Acceleration in Imperva CDN Improves Enterprise Website Performance

Today we introduced a new dynamic content acceleration network enhancement feature designed to improve response times to the origin server by up to 30%.

Clients using the Imperva content delivery network (CDN) service are now able to more fully leverage the high-quality connectivity between PoPs in the Imperva network. The enhancement translates to an even better experience for our clients’ end users and increased conversion rates for e-commerce websites and alike. And it will especially allow clients who have distributed end users to see a boost to their website performance, with zero code changes required on their end.

How Dynamic Content Acceleration Works

The origin PoP is selected based on the network distance (according to latency, not geographic distance) between the client’s origin server and the Imperva PoP.

Origin PoPs have dedicated machines called forwarders, part of a preconfigured setting. The purpose of the forwarder is to serve as an access point to the origin server.

With this enhancement there’s no change to the traffic inspection process, as traffic will continue to be analyzed in the entry PoP (the access point for the end user’s request).


Say is located in a datacenter in New York City and is using the dynamic content acceleration service.

When a request to reaches one of our proxy servers (e.g. Sydney) the proxy decides if the content is static or dynamic (A2).

If the content is dynamic, the proxy routes the traffic to the forwarder server in our New York City PoP (B2).

When the request reaches the forwarder in our New York City PoP, it sends the request forward to the origin server in New York City (C2).

When the origin sends a response, the forwarder receives it and sends it to the relevant proxy, which provides a faster response to the user. See our documentation for more information.

Improved Round-Trip Latency

Our improvements in round-trip latency are fueled by our cloud application security single stack architecture, PoPs strategically located to meet user demands, a broad peering footprint, and the fact that our entire network is tuned for DDoS mitigation, mandating the use of the same T1 transit providers across all our PoPs. A side effect of this IP engineering principle is a high-quality connection between PoPs.

Open connections are maintained between the PoPs which eliminates TCP slow start, an algorithm which balances the speed of a network connection. Connectivity to the origin from a nearby PoP also significantly reduces the latency required for the TLS handshake.

And when a packet moves from one PoP to another, it goes through fewer providers. In most cases it goes through just one provider. As a result, there is less packet loss and better latency.

Effect on Production Environment Analysis

As an additional benefit of dynamic content acceleration, clients utilizing XRAY will be able to have more visibility into requests to their origin and understand if a request passed through an origin PoP or not. This may come in handy in cases where there are potential connectivity improvements to the origin that need to be addressed.

The Development Process

We’ve been developing and testing this feature for about a year prior to release, measuring improvements in round-trip latency, time to first byte, and open connection time to the origin.

We found it takes much less time to open a connection to the origin from the forwarder compared to the origin from a faraway proxy (i.e. New York City <-> Tokyo). The forwarder can take 10 ms while a faraway proxy can take up to 300 ms).

Cedexis Testing

We use Cedexis to test different network optimization features. In the above testing we’ve set up two different networks to be monitored via Cedexis, both with origin servers in the same AWS EU-Central-1 Region in Frankfurt, Germany.

Then we applied dynamic content acceleration to one of the platforms by setting its origin PoP to the our Frankfurt PoP.

Lastly, we compared the latency of both networks as measured by eyeballs around the world.

The above results show an average latency of 308 ms vs 188 ms in the last 24 hours – a 120 ms decrease (which is also better than any other dynamic CDN vendor in Cedexis).

Performance improvement will vary based on the geographic traffic distribution of the site and the origin’s proximity to one of our PoPs. But our tests have shown an average improvement of 30% in round-trip time latency.


It’s important to remember that dynamic content acceleration does add an additional hop, so in some cases if the origin server is not close to the origin proxy (forwarder), clients may not see an improvement in round-trip latency.

And since only a few proxy servers connect to the origin server with dynamic content acceleration, if a client implements rate limiting or load balancing based on IP only, the fact that all traffic reaches the origin from fewer proxies may trigger a rate threshold and result in dropped traffic.

However, in general we expect dynamic content acceleration to have a widespread, positive performance impact. And this enhancement is just one of many benefits to come as we continue to invest in our CDN service.


The post Dynamic Content Acceleration in Imperva CDN Improves Enterprise Website Performance appeared first on Blog.

The State of Web Application Vulnerabilities in 2018

(Jan. 12 update:  Due to a data transfer error, some of the 2017 figures were incorrectly reported; this version of the blog has been corrected. This error did not affect our 2018 statistics, nor our conclusions.)

As a web application firewall provider, part of our job at Imperva is to continually monitor for new security vulnerabilities. To do this, we use internal software that collects information from various data sources such as vulnerability databases, newsletters, forums, social media and more, integrates it into a single repository, and assesses each vulnerability’s priority. Having this kind of data puts us in a unique position to provide an analysis of all web application vulnerabilities throughout the year, view trends, and notice significant changes in the security landscape. As we did last year, we took a look back at 2018 to understand the changes and trends in web application security over the past year.

The bad news is that in 2018, like 2017, we continued to see a trend of increasing number of web application vulnerabilities, particularly vulnerabilities related to injection such as SQL injection, command injection, object injection, etc. On the content management system (CMS) front, WordPress vulnerabilities continue to grow, and they continue to dominate in terms of the number of vulnerabilities published in the CMS category. Although WordPress leads the pack in sheer vulnerabilities numbers, Drupal vulnerabilities had a larger effect and were used in mass attacks that targeted hundreds of thousands of sites during 2018. However, there is some good news for the security industry — the number of Internet of Things (IoT) vulnerabilities declined, as well as the number of vulnerabilities related to weak authentication. In the server side technologies category, the number of PHP vulnerabilities continued to decline. In addition, the growth in API vulnerabilities also slightly declined.

2018 Web Application Vulnerabilities Statistics

The first phase in our yearly analysis was to check the amount of vulnerabilities published in 2018 in comparison to previous years. Figure 1 shows the number of vulnerabilities on a monthly basis over the last three years. We can see that the overall number of new vulnerabilities in 2018 (17,308) increased by 23% compared to 2017 (14,082) and by 162% compared to 2016 (6,615). According to our data, more than half of web application vulnerabilities (54%) have a public exploit available to hackers. In addition, more than a third (38%) of web application vulnerabilities don’t have an available solution, such as a software upgrade workaround or software patch.


Figure 1: Number of web application vulnerabilities in 2016-2018

Vulnerabilities by Category

In Figure 2, you can find 2018 vulnerabilities split into OWASP TOP 10 2017 categories.

Most Common Vulnerability: Injections

The dominant category this year was by far injections, with 19% (3,294) out of the total vulnerabilities of 2018, which is also a 267% increase from last year. When talking about injection vulnerabilities, the first thing that jumps to mind is SQL injections. When drilling down the data, however, we saw remote command execution (RCE) emerge as the bigger issue, with 1,980 vulnerabilities (11.5%), compared to 1,354 vulnerabilities (8%) for SQLi.

Figure 2: Vulnerabilities into categories 2014-2018

No. 2 Vulnerability — Cross-Site Scripting

The number of Cross-site scripting (XSS) vulnerabilities continued to grow and appears to be the second most common vulnerability (14%) among 2018 web application vulnerabilities.

IoT Vulnerabilities Decreased

It appears that the number of IoT vulnerabilities has decreased tremendously. Despite the common belief that all our electronic devices can be easily compromised, it appears that something has changed in this area. Possible explanations include: IoT vendors have finally started to implement better security in IoT devices, or that hackers and researchers found another area to focus on in 2018.

Figure 3: IoT vulnerabilities 2014-2018

API Vulnerabilities: Growing, but Slowing

API (Application Programming Interface) vulnerabilities are becoming more widespread as time goes by. Figure 4 shows the number of API vulnerabilities between 2015-2018. New API vulnerabilities in 2018 (264) increased by 23% over 2017 (214), by 56% compared to 2016 (169), and by 154% compared to 2015 (104).

Figure 4: API vulnerabilities 2015-2018

Although API vulnerabilities continue to grow year-over-year, it appears to be slowing, from 63% between 2015-16 to 27% in 2016-2017 and now 23% between 2017-18. One possible explanation is that since APIs are more popular nowadays, they draw more attention from hackers and security researchers. In turn, organizations spend more time securing their APIs.

Vulnerabilities in Content Management Systems: Attackers Focused on WordPress

The most popular content management system is WordPress, used by over 28% of all websites, and by 59% of all websites using a known content management system, according to market share statistics cited by Wikipedia, followed by Joomla and Drupal. Perhaps unsurprisingly, WordPress also registered the highest number of vulnerabilities (542) last year, which is a 30% increase from 2017 (Figure 5).

Figure 5: Number of vulnerabilities by CMS platform 2016-2018

According to the WordPress official site, the current number of plugins is 55,271. This means that only 1,914 (3%) were added in 2018.

Figure 6: Number of WordPress plugins

Despite the slowed growth in new plugins, the number of WordPress vulnerabilities increased. The explanation for this could either be the code quality of the plugins, or the fact that WordPress is such a popular CMS, which motivate more attackers to develop dedicated attack tools and try their luck searching for holes in the code.

Unsurprisingly, 98% of WordPress vulnerabilities are related to plugins  (see Figure 7 below), which extend the functionality and features of a website or a blog. Anyone can create a plugin and publish it — WordPress is open source, easy to manage, and there is no enforcement or any proper process that mandates minimum security standards (e.g. code analysis). Hence, WordPress plugins are prone to vulnerabilities.

Figure 7: WordPress third party vendor vulnerabilities in 2018

In Figure 8 below, you can find the ten WordPress plugins with the most vulnerabilities discovered in 2018. Note that these are not necessarily the most-attacked plugins as the report refers to the amount of vulnerabilities seen throughout the year – and is based upon the continual aggregation of vulnerabilities from different sources. Our annual report is solely based on statistics from this system, and we listed all vulnerabilities that were published during 2018 in general, in WordPress and WordPress plugins. This indicator solely looks at the most vulnerabilities. There are other measures that are not included in the report – such as ‘top attacked’ or ‘riskiest’ – which do not necessarily correlate with this measurement.

Figure 8: Top 10 vulnerable WordPress plugins in 2018

Server Technologies: PHP Vulnerabilities Fell

Since the most popular server-side programming language for websites continues to be PHP, we expect it to have more vulnerabilities than equivalent languages. And that was true. However, as Figure 9 below shows, new vulnerabilities in PHP fell in 2018 versus 2017, just as they did in the prior year. The lack of PHP updates – only one minor update was released, PHP 7.3, in December – could explain why.

Figure 9: Top server-side technology vulnerabilities 2014-2018

The Year of Drupal

Although Drupal is the third-most popular CMS, two of its vulnerabilities, CVE-2018-7600 (’23-mar’ bar in Figure 10 below), and CVE-2018-7602 (’25-apr’ bar below, also known as Drupalgeddon2 and Drupalgeddon3), were the root cause of many security breaches in hundreds of thousands of web servers in 2018. These vulnerabilities allowed an unauthenticated attacker to remotely inject malicious code and run it on default or common Drupal installations. These vulnerabilities allow attackers to connect to backend databases, scan and infect internal networks, mine cryptocurrencies, infect clients with trojans, and more.

The simplicity of these Drupal vulnerabilities and their catastrophic impact made them a weapon of choice for many attackers. In fact, Imperva detected and blocked more than half a million attacks related to these vulnerabilities during 2018. These attacks were also the basis for a few interesting blogs we wrote this year. There was another risky vulnerability, part of the Drupal security patch sa-core-2018-006, that published in October. However, since it was not easy to exploit, the number of attacks was small.


Figure 10: CVSS Score of Drupal vulnerabilities in 2018

Predictions for 2019

As a security vendor, we’re often asked about our predictions. Here are our vulnerability predictions for 2019:

  • PHP announced that versions 5.5, 5.6 and 7.0 reached their end of life. That means that these versions will no longer receive security updates. Major CMS like WordPress, Drupal, and Joomla are developed in PHP and require newer versions of PHP. However, they still support older versions. The result is that hackers are now motivated to find new security vulnerabilities in unsupported PHP versions since they will not be fixed and impact every application built with these outdated versions. For example, according to Shodan there are currently 34K servers with these unsupported PHP versions
  • Injection vulnerabilities will continue to grow mainly because of the economic implications to attackers (make fast money)
  • More vulnerabilities in APIs will be discovered as DevOps become a crucial factor in IT and their usage and demand for APIs is growing

How to Protect Your Apps and Data

One of the best solutions for protecting against web application vulnerabilities is to deploy a web application firewall (WAF). A WAF may be either on-premises, in the cloud or a combination of both depending on your needs, infrastructure, and more. As organizations are moving more of their apps and data to the cloud, it’s important to think through your security requirements. A solution supported by a dedicated security team is one to add to your selection criteria. Security teams can push timely security updates to a WAF in order to properly defend your assets.



The post The State of Web Application Vulnerabilities in 2018 appeared first on Blog.

Scapy-sploit: Python Network Tool is Vulnerable to Denial of Service (DoS) Attack CVE pending

We recently discovered that the latest version of Scapy, a powerful packet manipulation tool used by cybersecurity researchers and network engineers, is susceptible to a Denial of Service (DoS) vulnerability. Ironically, we found this vulnerability while researching ways to better detect and fight DDoS attacks.

Written in the very popular Python coding language, Scapy uses a heuristic algorithm to determine the type of network packet it is inspecting. Because the algorithm relies on port numbers, the packet type can be easily spoofed. In this case, the vulnerability occurs when Scapy is tricked into thinking a network packet is a RADIUS packet. The vulnerability is due to a lack of input validation when reading the length field in the RADIUS packet’s Attribute Value Pairs (AVP). This can cause an infinite loop in the following code section if a certain byte is set to zero:

When Scapy parses a UDP Radius packet that has an AVP with a length byte equal to zero, the getfield function doesn’t shorten the remain value in the while loop. This causes the loop to continue forever, resulting in a Denial of Service (DoS) to Scapy, causing Scapy to crash. This can potentially affect the health of an enterprise network – for instance, if Scapy is being used by IT to monitor network traffic, the monitoring process will stop functioning.


Although this bug was reported and patched, the current Scapy version 2.4.0 available from the Python pip repositories is susceptible to this attack. We tested for this vulnerability using macOS and Ubuntu Linux with both Python 2.7 and Python 3 and found them all vulnerable.

Here is the remote exploit:

Here is the patch:
The solution: clone and build Scapy directly from the github repo:


The current version of Scapy can be DoSed quite easily. The potential impact is large – Scapy is quite a popular tool, and other libraries that depend on Scapy might be vulnerable as well. Networks relying on Scapy for traffic monitoring or other functions can also be affected.  If you’re using the affected version of Scapy, or any library that depends on Scapy, we advise you to apply the patch as soon as possible. 

Advisory Scapy 2.4.0 – Denial of Services
Authors: Johnathan Azaria and Koby Kilimnik
Vendor url:
Status: Patched (but not released to pip repo)
Tested on: macOS sierra 10.12.6 and Ubuntu Linux 16.04


A partial list of libraries with a Scapy dependency that might be affected as well:

  • IcmpTool-0.1.8
  • jldcmds-0.3
  • mim-0.2.43 – man in the middle proxy
  • ooniprobe-1.3.2 – network analysis tool
  • pyersinia-1.0.5 – another network analysis tool
  • pysap-0.1.8 – python library that communicates with sap
  • scapy-http-1.8



The post Scapy-sploit: Python Network Tool is Vulnerable to Denial of Service (DoS) Attack CVE pending appeared first on Blog.

Pre-Installed Malware Targets Critical System Apps on Mobile Devices

Several new types of pre-installed malware are targeting critical system apps on mobile devices, making them difficult to remove.

Researchers at Malwarebytes came across two instances of pre-installed malware targeting applications in /system/priv-app/, where critical apps such as settings and system UI reside. The first infection occurred on a THL T9 Pro device. The malware repeatedly installed variants of Android/Trojan.HiddenAds, which is known for displaying lock screen advertisements that take up the device’s entire screen. In this particular case, the infection wrapped itself up in the critical system Android app System UI.

The second infection occurred on a UTOK Q55. In that case, the threat came hardcoded in the device’s Settings app. It fit the “monitor” category of potentially unwanted programs (PUP), which are capable of collecting and reporting users’ information.

The Pre-Installed Malware Problem Persists

These two instances of pre-installed malware aren’t the first detected by Malwarebytes. In March 2017, researchers at the security software provider observed mobile devices manufactured by BLU being shipped out with Android/Adware.YeMobi. Then in December of that year, the researchers found an auto-installer known as FWUpgradeProvider pre-installed on devices bought from legitimate phone carriers in the U.K. and elsewhere.

Other security firms have detected pre-installed malware more recently. For instance, Check Point discovered RottenSys disguised as a system Wi-Fi service; the threat targeted nearly 5 million users for fraudulent ad revenues as of March 2018. A few months later, Avast Threat Labs found adware known as Cosiloon pre-installed on hundreds of Android device models.

How to Protect Mobile Devices From Pre-Installed Malware

Security professionals can protect mobile devices from pre-installed malware and other threats by using a unified endpoint management (UEM) solution to monitor how these devices report to the corporate IT environment. They should also use behavioral analysis to help defend mobile devices against zero-day threats.

The post Pre-Installed Malware Targets Critical System Apps on Mobile Devices appeared first on Security Intelligence.

The Year Ahead: Cybersecurity Trends To Look Out for In 2019

A Proven Record Tracking Cybersecurity Trends

This time of the year is always exciting for us, as we get to take a step back, analyze how we did throughout the year, and look ahead at what the coming year will bring. Taking full advantage of our team’s expertise in data and application security, and mining insights from our global customer base, we’ve decided to take a different approach this time around and focus on three key, and overriding trends we see taking center stage in 2019.

2018 brought with it the proliferation of both data and application security events and, as we predicted, data breaches grew in size and frequency and cloud security took center stage globally. With that in mind, let’s take a look at what next year holds.

Data breaches aren’t going away anytime soon, which will bolster regulation and subsequent compliance initiatives

Look, there’ll be breaches, and the result of that is going to be more regulation, and therefore, more compliance, this is a given. In fact, the average cost of a data breach in the US 2018 exceeded $7 million.

Whether it’s GDPR, the Australian Privacy Law, Thailand’s new privacy laws or Turkey’s KVKK; it doesn’t matter where you are, regulation is becoming the standard whether it be a regional, group, or an individual country standard.

Traditionally when we looked at data breaches, the United States lit up the map, but as regulatory frameworks and subsequent compliance measures expand globally, we’re going to see a change.

The annual number of data breaches and exposed records in the United States from 2005 to 2018 (in millions) [Statista]

What you ’ll see in 2019, and certainly, as we move forward, is a red rosy glow covering the entire globe. In 2019 you’ll hear more of “It’s not just the United States. This happens everywhere.”


Let’s unpack this for a second. If you were going to steal private data or credit card details, why would you do it in an environment that has world-class, or even mediocre cybersecurity measures in place? If everyone else is even slightly less protected, that’s where you’re going to find people targeting data, but we hear more about it in regions where regulation and compliance is a major focus.


To that end, we don’t necessarily see 2019 as the year where regulators start hitting companies with massive fines for compliance. Maybe by the end of the year, or if you see outright egregious negligence. But, you’ll find that companies have put in the legwork when it comes to compliance.

Having your head in the cloud(s) when it comes to managing risk… not a bad idea

McKinsey reports that, by 2020, organizations will be spending more than six times on cloud-specific products than they do on general IT services; and according to a survey by LogicMonitor, up to 83% of all enterprise workloads will be in the cloud around that same time.

LogicMonitor’s Future of the Cloud Study [Forbes]

Organizations continue to capitalize on the business benefits of the digital economy and, as such, end up chunking more data into the cloud. Now, we’re not saying that this is being done without some forethought, but are they classifying data as they go along and increasingly open their businesses up to the cloud?


Teams need to recognize that, as they transition their data to the cloud, they transition their awareness of what’s in the cloud; who is using it, when they’re using it, and why they’re using it. 2019 isn’t going be the year that businesses figure out they need to do that. What we will see, however, is increasingly cloud-friendly solutions hit the market to solve these challenges.

Social Engineering and the rise of AI and machine learning in meeting staffing issues

One of 2019’s most critical developments will be how the cybersecurity industry steps up to meet the increasing pressure on security teams to perform. According to the Global Information Security Workforce Study, the shortage of cybersecurity professionals will hit 1.8 million by 2022, but at the same time, a report by ESG shows just nine percent of millennials are interested in a career in cybersecurity.


What we’re going to see is how AI  and machine learning in cybersecurity technology will close the gaps in both numbers and diversity of skills.


Organizations today have to solve the problem of cybersecurity by hiring for a host of specialized competencies; network security, application security, data security, email security and now, cloud security. Whatever it is, underscore security, those skills are crucial to any organization’s security posture.


Here’s the thing, there aren’t a lot of people that claim to know cloud security, database security, application security, data security, or file security. There just isn’t a lot. We know that and we know businesses are trying to solve that problem, often by doing the same old things they’ve always done, which is the most common solution. Do more antimalware, do more antivirus, do more things that don’t work. In some cases, however, they’re doing things around AI and trying to solve the problem by leveraging technology. The latter will lead to a shift where organizations dive into subscription services.


There are two facets driving this behavior: the first is the fact that, yes, they realize that they are not the experts, but that there are experts out there. Unfortunately, they just don’t work for them, they work for the companies that are offering this as a service.


Secondly, companies are recognizing that there’s an advantage in going to the cloud, because, and this is a major determining factor, it’s an OpEx, not CapEx. The same thing is true of subscription services whether that be in the cloud or on-prem, it doesn’t matter. Driven by skills shortages and cost, 2019 will see an upswing in subscription services, where organizations are actually solving cybersecurity problems for you.


We should add here, however, that as more organizations turn to AI and machine learning-based decision making for their security controls, attackers will try to leverage that to overcome those same defenses.

Special mention: The ‘trickledown effect’ of Cyberwarfare

The fact is, cyber attacks between nations do happen, and it’s a give and take situation. This is the world we live in, these are acceptable types of behavior, quite frankly, right now, that won’t necessarily lead to war these days. But someone still stands to gain.


Specifically, they’re attacking third-party business, contractors and financial institutions. That’s why cybersecurity is so important, there needs to be an awareness that somebody might be stealing your data for monetary gain. It might be somebody stealing your data for political gain too, and protecting that data is just as critical, regardless of who’s taking it.


Now, while state-hacking isn’t necessarily an outright declaration of war these days, it doesn’t end there. The trickledown effect of nation-state hacking is particularly concerning, as sophisticated methods used by various governments eventually find their way into the hands of resourceful cybercriminals, typically interested in attacking businesses and individuals.

Repeat offenders

No cybersecurity hit list would be complete without the things that go bump in the night and, while all of them might not necessarily be ballooning, they’ll always be a thorn in security teams’ sides.

  • Following the 2017 Equifax breach, API security made it onto the OWASP Top 10 list and remains there for a good reason. With the expanding use of APIs and challenges in detecting attacks against them, we’ll see attackers continuing to take aim at APIs as a great target for a host of different threats; including brute force attacks, App impersonation, phishing and code injection.
  • Bad actors already understand that crypto mining is the shortest path to making a profit, and continue to hone their techniques to compromise machines in the hope of mining crypto-coins or machines that can access and control crypto-wallets.
  • Low effort, easy money, full anonymity and potentially huge damage to the victim… what’s not to like when it comes to ransomware? It’s unlikely that we’ll see these types of attacks go away anytime soon.


If there’s one overriding theme we’d like to carry with us into 2019 it’s the concept of general threat intelligence, the idea that it’s better to have some understanding of the dangers out there and to do something, rather than nothing at all.


We often talk about the difference between risk and acceptable risk or reasonable risk, and a lot of companies make the mistake of trying to boil the ocean… trying to solve every single problem they can, ultimately leaving teams feeling overwhelmed and short on budget.


Acceptable risk isn’t, “I lost the data because I wasn’t blocking it. I get it. And it wasn’t a huge amount of data because at least I have some controls in place to prevent somebody from taking a million records, because nobody needs to read a million records. Nobody’s going to read a million records. So, why did I let it happen in the first place?”


Acceptable risk is “I know it happened, I accept that it happened, but it’s a reasonable number of events, it’s a reasonable number of records, because the controls I have in place aren’t so specific, aren’t so granular that they solve the whole problem of risk, but they take me to a world of acceptable risk.”


It’s better to begin today, and begin at the size and relevance that you can, even if that only takes you from high to medium risk, or reasonable to acceptable risk.

The post The Year Ahead: Cybersecurity Trends To Look Out for In 2019 appeared first on Blog.

Read: New Attack Analytics Dashboard Streamlines Security Investigations

Attack Analytics, launched this May, aimed to crush the maddening pace of alerts that security teams were receiving. For security analysts unable to triage this avalanche of alerts, Attack Analytics condenses thousands upon thousands of alerts into a handful of relevant, investigable incidents.  Powered by artificial intelligence, Attack Analytics is able to automate what would take a team of security analysts days to investigate and to cut that investigation time down to a matter of minutes.

Building upon the success of our launch, we are now introducing the Attack Analytics Dashboard.  Aimed at SOC (Security Operations Center) analysts, managers, and WAF administrators to provide a high-level summary of the type of security attacks that are hitting their web applications; it helps to speed up security investigations and quickly zoom in on abnormal behaviors.

The WAF admin or the SOC can use the Dashboard to get a high-level summary of the security attacks that have happened over a period of time (the last 24 hours, 7 days, 30 days, 90 days or other customized time range):

  • Attack Trends: Incidents and events
  • Top Geographic Areas: Where attacks have originated
  • Top Attacked Resources
  • Breakdown of Attack Tool Types
  • Top Security Violations (Bad Bots, Illegal Resource Access, SQL injections, Cross-Site Scripting, etc.)

Events vs. incidents

Upon entering the Attack Analytics Dashboard, you can see the Incidents tab, which shows the attack trends across time, classified according to severity (critical, major and minor).  A quick scan allows you to understand if a sudden jump in incidents may deserve immediate attention.

In the Events tab, you can see the number of events vs. incidents which have occurred over a specific period of time. For example – the marked point in the graph shows that on October 4th there were 2,142 alerts that were clustered into 19 security incidents. If you want to understand what happened on this day, you can drill down and investigate these 19 incidents.

Next, you can see the Top Attack Origin countries which have attacked your websites over a specified period of time. This again could help identify any abnormal behavior from a specific country. In the snapshot below, you can see the “Distributed” incidents. This means that this customer experienced 4 distributed attacks, with no dominant country, and could imply the attacks originated from botnets spread across the world.

Top attacked resources

Top Attacked Resources provides a snapshot of your most attacked web resources by percentage of critical incidents and the total number of incidents. In this example, singular assets are examined as well as a distributed attack across the customer’s assets. In the 3rd row, you can see that the customer (in this case, our own platform) experienced 191 distributed attacks. This means that each attack targeted a few hosts under our brand name; for example, it may have been a scanning attack aimed at finding vulnerable hosts.

Attack tool types

A SOC Manager/WAF admin might also want to understand the type of attack tools that are being used.  In the example below, on the left, you see the distribution of incidents according to the tool types and on the right, you see the drill-down into the malicious tools, so you can better understand your attack landscape. Over the last 90 days, there were 2.38K incidents that used malicious tools. On the right we can see the breakdown of the different tools and the number of incidents for each one – for example, there were 279 incidents with a dominant malicious tool called LTX71.

We think you’ll quickly discover the benefits which the new Attack Analytics Dashboard provides as it helps you pinpoint abnormal behaviors and speed up your security investigations. It should also assist you in providing other stakeholders within your company a high-level look at the value of your WAF.

And right now, we have even more dashboard insight enrichments in the works, such as:

  • False Positives Suspects: Incidents our algorithms predict to be highly probable of being false positives.
  • Community Attacks (Spray and Pray Attacks): Provide a list of incidents that are targeting you as part of a larger campaign – based on information gathered from our crowdsourced customer data.

Stay tuned for more!

The post Read: New Attack Analytics Dashboard Streamlines Security Investigations appeared first on Blog.

Headless Chrome: DevOps Love It, So Do Hackers, Here’s Why

Google Chrome is the most popular web browser and has been so for almost a decade. Each new version of Chrome brings new usability, security and performance features.

This article focuses on the “headless mode” feature that Google released more than a year ago; and, since day one has become very popular not only among software engineers and testers but also with attackers.

Off with their heads!

Headless mode is a functionality that allows the execution of a full version of the latest Chrome browser while controlling it programmatically. It can be used on servers without dedicated graphics or display, meaning that it runs without its “head”, the Graphical User Interface (GUI).

In headless mode, it’s possible to run large scale web application tests, navigate from page to page without human intervention, confirm JavaScript functionality and generate reports.

As with benign cases, the same functionality takes place in malicious scenarios, when an attacker needs to evaluate JavaScript or emulate browser functionality.

The practice of web browser automation isn’t new. It’s used in dedicated headless browsers like PhantomJS and NightmareJS, test frameworks like Capybara and Jasmin, and tools like Selenium that can automate different browsers including Chrome.

How popular is Headless Chrome?

The chart below shows the amount of traffic generated by Headless Chrome and other major headless browsers since its release date in June 2017. In comparison to other headless browsers and automation frameworks, Headless Chrome overtook the previous leader, PhantomJS, within a year of its release.

Automated browser trends over the last year

The data collected from our cloud WAF statistics, reinforced by data from Google Trends, highlight how the popularity of PhantomJS fades, while Headless Chrome’s trajectory keeps climbing.

PhantomJS and Headless Chrome: Google search trends

Automated browsers driving increased traffic

Apart from Headless Chrome’s popularity, and the degradation in the popularity of outdated tools, we observed an increase in total traffic generated by automated browsers compared to non-automated web surfing.

The chart below represents the percentage of automated browsers out of total traffic generated by web browsers:

Traffic ratio between automated and non-automated browsers

So, why is Headless Chrome so popular?

There are several reasons for Headless Chrome’s popularity; one being the support for Chrome’s new “out of the box” features, which constantly introduce new trends in web development. Another reason is the support for major desktop, server, and mobile operating systems. Headless Chrome also has convenient development tools and many additional useful features for Devs.


The release of Puppeteer a couple of months after the release of the headless functionality was a decisive push in Headless Chrome’s popularity. Puppeteer is a NodeJs library developed by the Chrome team, which provides a high-level API to control headless and full versions of the latest Chrome.

Enter Puppeteer

Puppeteer is a common and natural way to control Chrome. It provides full access to browser features and, most importantly, can run Chrome in fully headless mode on a remote server, which is very useful for both automation teams and attackers.


Without much difficulty, attackers can put in place an infrastructure with a host of nodes running Headless Chrome and orchestrated by one component (Puppeteer).


Apart from Puppeteer, Chrome can be automated using webdriver and automation frameworks like Selenium or by direct access through Command Line Interface (CLI). In this case, some Chrome functionality will be limited, but it offers the flexibility to write automation in any programing language besides NodeJS and JavaScript.

Just how popular is it among attackers?

By analyzing malicious activity generated by automated browsers, I found that PhantomJS was a leader not only in the amount of traffic it produced but also in malicious activity.

However, nowadays, Chrome occupies the top of the “attackers’ podium,” with half of the malicious traffic divided evenly between execution in headless and non-headless mode.

Taking a closer look at malicious traffic, however, I found that there are no specific trends indicating a preference among attackers for Headless Chrome to exploit vulnerabilities, inject SQL or carry out cross-site scripting attacks (XSS). That said, occasional spikes show attempts at targeting specific sites by using vulnerability scanners, or attempts to exploit newly released vulnerabilities using the “spray and pray” technique.


Using a web browser for vulnerability scanning is crafty, but not a new approach, as it can help to bypass some validation mechanisms based on validation of the legitimacy of the client.

WAF events generated by Headless Chrome

Analyzing traffic from the last year, I didn’t find any DDoS attacks performed from a botnet based on Headless Chrome. Nothing similar to the Headless Android Botnet that was discovered two years ago and since then all but vanished.


Usage of automated browsers in general, and Headless Chrome in particular, for DDoS, is not common practice. The reason for this is the low request rate to the server that browsers can generate. As Chrome receives the response from the server, evaluates it and only then performs the next request, its rate is very low in comparison to a simple script that floods with many requests and doesn’t “care” about the responses.


Having said that, we observe more than 10K unique IP addresses daily performing scraping, sniping, carding, blackhat SEO and other types of malicious activity where JavaScript evaluation is necessary to perform the attack. Distribution among the countries performing these malicious activities is presented in the chart below. While 7% of the traffic is coming from proxies or VPNs to hide the origin of the attack.

Geographical distribution of malicious Headless Chrome traffic

But what about legitimate services?

Headless Chrome isn’t only used by attackers but also by legitimate services. We observe dozens of legitimate well-known web tools that use it to access websites.


  • Search engines use it to render the page, generate dynamic content and index data from single page web applications.
  • SEO tools use it to analyze your website and help promote it better.
  • Monitoring tools use Headless Chrome to measure performance and JavaScript execution time of web applications.
  • Online testing tools render pages and compare it to previous versions to track regression or distortion in the user interface.

Ok, so how do we make sure we’re protected?

At this point, you’re probably asking yourself whether or not to block Headless Chrome or any other automated browsers.


The answer to this question is “yes… and no.”


Using Headless Chrome by itself is not malicious, and as stated earlier, there are legitimate scenarios and services that use this functionality to access websites. Whitelisting all legitimate services is tough work, as it requires constant mapping and maintaining the lists of such services and their IPs.


The decision to block Headless Chrome requests or not should be based on the intent and behavior of each IP and session individually.


Unless the payload is malicious (which is high evidence of malicious activity), it is better to pass some requests to the website, analyze the behavior and only then decide whether to block or not.


The reputation of IPs and their correlation, sophisticated heuristics, and machine learning algorithms can be implemented to make a deliberate decision, which will give better long-term results than aggressive blocking, at least in most cases.


For Imperva Incapsula users, a set of IncapRules can be implemented to block Headless Chrome from accessing your website. Starting from a simple rule based on client classification up to sophisticated rules including rates, tags, and reputation.

The post Headless Chrome: DevOps Love It, So Do Hackers, Here’s Why appeared first on Blog.

DirtyCOW Bug Drives Attackers to A Backdoor in Vulnerable Drupal Web Servers

In this post we’ll unpack a short — but no less serious — attack that affected some Linux-based systems, on October 31. Throughout the campaign, the attacker used a chain of vulnerabilities including the infamous Drupalgeddon2 and DirtyCOW, and system misconfigurations to persistently infect vulnerable Drupal web servers and take over user machines.

In the past, remote code execution (RCE) attacks on web servers were usually once-off security events – attackers would run their malicious code, and that was it. If the process was detected and terminated, or if the administrator restarted the web servers, the attack would stop.

Increasingly, attackers are opting for persistent attacks. Persistency means that the attacker has a technique to easily re-infect a vulnerable server in case the process is terminated or after a server restart, or run an additional malicious code. Persistency is achieved through different techniques and usually depends on the type of operating system.

Exploiting SSH in Linux

In the case of Linux-based systems, one of the favorite techniques used by attackers is opening a communication channel through SSH and transmitting malicious commands. This technique assumes that an SSH service is installed in the target system. But what happens if it isn’t? Well, then the attacker would somehow need to install it themselves.

In our case, the attack surface was the web application. This means that the attacker’s code was running under the user and permissions of the web application. Usually, the web server user (e.g. nobody, www-data etc.) has minimal permissions and can’t install new services. What if the attacker could change its user context and get sufficient permissions? What if the attacker changed the user to ‘root’? This will certainly help…

First, the attacker builds a word list by locating all of Drupal’s settings files and extracting any line with the word “pass” in it.

This technique can be quite useful as many administrators leave ‘root’ as the default user to connect from the web application to the database.

Then, armed with a potential list of passwords, the attacker tries to use the operating system command ‘su root’ to change the user to root.

If the attacker succeeds in changing the user, they can proceed to download the secondary payload ‘sshdstuff’ and execute (more details below).

If the administrator was careful and didn’t leave root passwords in the configuration files, this technique fails, and the attacker tries to exploit the DirtyCOW bug to escalate their privileges to root. The attacker downloads three different implementations of DirtyCOW and runs them one after the other. One of the implementations is downloaded in its raw format (C source code file) and is compiled at runtime. Surprisingly, one of the implementations of this two-year-old bug has zero detection rate in VirusTotal.

Finally, when the attacker switches to the root user and has permissions to install new services, they install SSH, configure it and add their key to the list of authorized keys by the service. Now, as long as the machine is up and running, the attacker can remotely transmit any command as the user root – game over.

Mitigation suggestions

Administrators should make sure that their web application is fully patched as well as the operating system of the host. Alternately, it is possible to use external cybersecurity solution, like a WAF, to block the attack before it reaches the server. Imperva customers are protected out of the box.

The post DirtyCOW Bug Drives Attackers to A Backdoor in Vulnerable Drupal Web Servers appeared first on Blog.

How Safe and Secure are Wearables?

The ‘wearable technology’ market has been exponentially growing in recent years and is expected to exceed 830 million devices by 2020. One of the key drivers pushing this rapid expansion are fitness trackers, namely wristband tech and smartwatch apps which monitors our daily activity and health. But as we integrate wearables devices seamlessly into our everyday lives, what are the privacy and security risks they pose? How should wearable manufacturers and app developers be protecting consumers?

245 million wearables will be sold in 2019

Insurance company Vitality offers customers a heavily discounted Apple Watch to customers in return for their fitness routines and health data, the more activity you do each month, the greater your reward through a monthly discount. While this exchange of information for rewards provides a great incentive for consumers to improve their health, the personal data consumers are sharing in return has a tangible value for the insurance company. However, providing an insurance company with a daily data breakdown of one's health is an unacceptable tradeoff for some, regarding such a practice as an invasion of their privacy. 

As of May 2018, all EU citizen's privacy rights are legally protected by the General Data Protection Regulation (GDPR). GDPR compliance is required by all companies which process EU citizen data, including those based outside of the European Union. The privacy regulation requires wearable device and app providers to obtain each EU citizen's explicit consent before collecting their personal information, they must also clearly explain what types of personal information they intend to collect, how they intend to use the data, and inform consumers about any other organisation they intend to share their data with. If they don’t, wearable tech firms and app providers should brace themselves for heavy fines by European Information Commissioners.

For further details about the GDPR requirements and for Wearables Software Development Security Advice, read my IBM developerWorks 3 part guidance "A developer's guide to the GDPR" and my Combating IoT Cyber Threats

Wearable personal data is also of value to hackers and criminals, for instance, your fitness routine provides a clear picture of the best times to burglarise your home. With personal consumer data potentially at stake, fitness wearable manufacturers should incorporate both default privacy and security standards into the infrastructure of the device, to help ensure personal information remains safeguarded from known and future cyber threats.  ULa global safety science company, has developed testing for cybersecurity threats and offers security verification processes to assist manufacturers in assessing security risks and helping mitigate them before the product even goes to market. If the industry takes these steps, wearable consumers will feel safe and secure as they reap the intended benefits of this new innovation, while the wearables industry will be well positioned to meet the promise of its growth projections.

Cyber Security Roundup for October 2018

Aside from Brexit, Cyber Threats and Cyber Attack accusations against Russia are very much on the centre stage of UK government's international political agenda at the moment. The government publically accused Russia's military 'GRU' intelligence service of being behind four high-profile cyber-attacks, and named 12 cyber groups it said were associated with the GRU. Foreign Secretary Jeremy Hunt said, "the GRU had waged a campaign of indiscriminate and reckless cyber strikes that served no legitimate national security interest".

UK Police firmly believe the two men who carried out the Salisbury poisoning in March 2018 worked for the GRU.

The UK National Cyber Security Centre said it had assessed "with high confidence" that the GRU was "almost certainly responsible" for the cyber-attacks, and also warned UK businesses to be on the alert for indicators of compromise by the Russian APT28 hacking group.  The NCSC said GRU hackers operated under a dozen different names, including Fancy Bear (APT28), had targetted:
  • The systems database of the Montreal-based World Anti-Doping Agency (Wada), using phishing to gain passwords. Athletes' data was later published 
  • The Democratic National Committee in 2016, when emails and chats were obtained and subsequently published online. The US authorities have already linked this to Russia.
  • Ukraine's Kyiv metro and Odessa airport, Russia's central bank, and two privately-owned Russian media outlets - and news agency Interfax - in October 2017. They used ransomware to encrypt the contents of a computer and demand payment 
  • An unnamed small UK-based TV station between July and August 2015, when multiple email accounts were accessed and content stolen

Facebook was fined the maximum amount of £500,000 under pre-GDPR data protection laws by the UK Information Commissioner's Office (ICO) over the Cambridge Analytica Scandal. Facebook could face a new ICO fine after revealing hackers had accessed the contact details of 30 Million users due to a flaw with Facebook profiles. The ICO also revealed a 400% increase in reported Cyber Security Incidents and another report by a legal firm RPC said the average ICO fines had doubled, and to expect higher fines in the future. Heathrow Airport was fined £120,000 by the ICO in October after a staff member lost a USB stick last October containing "sensitive personal data", which was later found by a member of the public.

Notable Significant ICO Security Related Fines

Last month's British Airways website hack was worse than originally reported, as they disclosed a second attack which occurred on 5th September 2018, when the payment page had 22 lines of malicious Javascript code injected in an attack widely attributed to Magecart.  Another airline Cathay Pacific also disclosed it had suffered a major data breach that impacted 9.4 million customer's personal data and some credit card data.

Morrisons has lost a challenge to a High Court ruling which made it liable for a data breach, after an employee, since jailed for 8 years, stole and posted thousands of its employees' details online in 2014.  Morrisons said it would now appeal to the Supreme Court., if that appeal fails, those affected will be able to claim compensation for "upset and distress". 

Interesting article on Bloomberg on "How China Used a Tiny Chip to Infiltrate U.S. Companies". However, there was a counter-narrative to the Bloomberg article on Sky News. But didn't stop Ex-Security Minister Admiral Lord West calling the Chinese when he said Chinese IT Kit 'is putting all of us at risk' if used in 5G.  He raises a valid point, given the US Commerce Department said it would restrict the export of software and technology goods from American firms to Chinese chipmaker Fujian Jinhua BT, which uses Huawei to supply parts for its network, told Sky News that it would "apply the same stringent security measures and controls to 5G when we start to roll it out, in line with continued guidance from government". Recently there have been warnings issued by the MoD and NCSC stating a Chinese espionage group known as APT10 are attacking IT suppliers to target military and intelligence information.

NCSC is seeking feedback on the latest drafts 'knowledge areas' on CyBOK, a Cyber Security body of knowledge which it is supporting along with academics and the general security industry.

Google are finally pulling the plug on Google+, after user personal data was left exposed. Google and the other three major web browser providers in the world said, in what seems like coordinated announcements, businesses must accept TLS Version 1.0 and 1.1 will no longer support after Q1 2018.

So its time to move over to the more secure TLS V1.2 or the more secure & efficient TLS V1.3.


Cyber Security Roundup for September 2018

September 2018 started with a data breach bang, with British Airways disclosing a significant hack and data loss. 380,000 of the airlines' website and mobile app customers had their debit and credit card details lifted via a maliciously injected script.  The breach even caused BA owners, IAG, to drop in value 4%. And to compound matters, there were several claims made that the BA website wasn't PCI DSS compliant, implying if they were PCI DSS compliant, their customer's personal and payment card information would still be safe.  For further details about this breach see my blog posts; British Airways Customer Data Stolen in Website and Mobile App Hack and British Airways Hack Update: Caused by Injected Script & PCI DSS Non-Compliance is Suspected.

Facebook continues to make all the wrong kind of privacy headlines after a massive user data breach was confirmed by the social media giant at the end of the month. Facebook said at least 50 million users’ data was at risk after hackers exploited a vulnerability the Facebook code. Facebook CEO Mark Zuckerberg said he doesn’t know who is behind the cyber attack, however, the FBI are investigating. 

There was a good measure of embarrassment at the Tory Conference after a flaw in the conference App revealed the personal data of senior UK government cabinet ministers, with Boris Johnson, Michael Gove, Gavin Williamson among those whose their personal information and phones numbers made available.

There was a number of large data breach fines handed out in September, Tesco Bank was hit by a whopping £16.4 by the Financial Conduct Authority (FCA), the fine would have been doubled if it weren't for Tesco's good co-operation with the FCA investigation. The FCA said Tesco had security deficiencies which left their bank account holders vulnerable to a cyber attack in November 2016. The attack netted the bad guys, via 34 transactions, a cool £2.26 million. The FCA report said the cyber criminals had exploited weaknesses in the bank's design of its debit card, its financial crime controls and in its financial crime operations team, to carry out the attack over a 48-hour period. 

Equifax was fined the maximum pre-GDPR law amount of £500K by the Information Commissioner's Office (ICO) after the US-based credit reference agency failed to protect the personal data of 15 million UK citizens. The ICO ruled Equifax's UK branch had "failed to take appropriate steps" to protect UK citizens' data. It added that "multiple failures" meant personal information had been kept longer than necessary and left vulnerable.

The ICO also fined Bupa £175K, for not having good enough security to prevent the theft of 547,000 customer records by an employee.  Uber has paid £133m to settle legal claims to customers and drivers, as a result of trying to cover up a huge breach which occurred in 2016 from their regulators. The ride-hailing company admitted to paying off hackers to the tune of $100,000 to delete the data they robbed from Uber's cloud servers. The personal data stolen was from 57 million Uber accounts, also included information about 600,000 driving license numbers. 

Looks like the MoD and GCHQ are looking to beef up Britan's Cyber Offense capabilities, announcing a plan to recruit a 2,000 strong 'cyber force' to take on the Russian threat. Meanwhile across the pond, the Mirai creators have done a deal to keep themselves out of jail in return for helping the FBI catch cybercrooks, which has echoes of the approach the FBI took with con artist and cheque fraud expert Frank Abagnale, the subject of book and movie "Catch me if you Can".

Bristol Airport was impacted by a ransomware attack, which took down their arrival and departure screens for a couple of days, and a Scottish Brewery was also hit by ransomware attack through infected CV it had received through an online job advertisement

Europol warned of 15 ways you could become a Cyber Crime Victim, and there was an excellent article in the New York Times on the Bangladesh’s Central Bank Cyber Theft


Application Development GDPR Compliance Guidance

Last week IBM developerWorks released a three-part guidance series I have written to help 
Application Developers develop GDPR compliant applications.

Developing GDPR Compliant Applications Guidance

The General Data Protection Regulation (GDPR) was created by the European Commission and Council to strengthen and unify Europe's data protection law, replacing the 1995 European Data Protection Directive. Although the GDPR is a European Union (EU) regulation, it applies to any organizations outside of Europe that handle the personal data of EU citizens. This includes the development of applications that are intended to process the personal information of EU citizens. Therefore, organizations that provide web applications, mobile apps, or traditional desktop applications that can indirectly process EU citizen's personal data or allow EU citizens sign in are subject to the GDPR's privacy obligations. Organizations face the prospect of powerful sanctions should applications fail to comply with the GDPR.

Part 1: A Developer's Guide to the GDPR
Part 1 summarizes the GDPR and explains how the privacy regulation impacts and applies to developing and supporting applications that are intended to be used by European Union citizens.

Part 2: Application Privacy by Design
Part 2 provides guidance for developing applications that are compliant with the European Union’s General Data Protection Regulation. 

Part 3: Minimizing Application Privacy Risk

Part 3  provides practical application development techniques that can alleviate an application's privacy risk.