ElevenPaths discovers the Popcorn ransomware passwords: no need to infect other people to decrypt for free

Wednesday, December 14, 2016

MalwareHunterTeam has discovered a new variant of ransomware that is quite curious. At ElevenPaths we have been able to download and analyze the new improved versions that make several interesting mistakes, for example one that reveals your decryption password. This sample draws attention because, in theory, it offers two formulas to decrypt the files: either by paying, or if the infected succeeds in infecting two or more people who pay the ransom.

The "easy" way and… the "nasty" way

Apart from what has already been commented on this new version, we focus on the most interesting aspects of the evolution that we, at ElevenPaths, have analyzed. The basic functionality is as usual: a lot of files are encrypted depending on their extension, and a ransom of 1 bitcoin is requested (above the average that is usually demanded). What this ransomware does for the first time is to offer two ways to decrypt the content: the "normal" way, in which a ransom is paid, and the "nasty" way (so they call it), in which if a link to an executable is sent to two people and they get infected and pay, you will be given a "free" code to decrypt your content. A diffusion "Refer-a-friend plan" in which the attacker "ensures" two infections for the price of one, and a more effective dissemination method, since the victims chosen by the infected user will always be more predisposed to execute the link from an acquaintance. Another option is to pay (alleged condition for the "discount"). It is also important to note that the ransomware appeals to the sensitivity of the victim, stating that the money will go to a good cause: alleviate the effects of the Syrian war. It is called "popcorn" because the first version used the popcorn-time-free.net domain, although the latest versions do not.

Appealing to the sensitivity of the victim.
They also lie when they say that there is nothing to do and that only they can decrypt the data.

Technical aspects

How does this ransomware work at a technical level? It has been developed by an independent group without following the guidelines of the "known" families, and therefore, is not very developed yet. Apart from the versions analyzed by MalwareHunterTeam, at ElevenPaths we have had access to the new samples. These are some interesting aspects that we have noticed.

The program is written in C# and needs .NET4 to run. The executable is created "on the fly" for each infected user, with a unique ID code inserted for each victim. Interestingly enough, all variables are "embedded" in the code, and it is created on the server side. In addition, it does not follow the usual pattern of professional ransomware in which each file is encrypted with a different symmetric key and then this key is encrypted with asymmetric cryptography. On the contrary, all files are encrypted with the same symmetric key. From here, knowing the password is a matter of analyzing the code of the executable. 

The password

If we disassemble the code with, for example, ILSpy we can see the line containing the password in base64. A quick decode will allow us to get the password and the data back. We have not created a specific tool to do this, as it is more than likely that the attacker quickly changes the strategy and also, for now, this malware does not seem to be very advanced or widespread (if someone is infected, please contact us). In fact, the day before the password of its first versions was always "123456".

As mentioned, the password is supposed to be (along with all other variables) embedded by the server at the time the executable is created. After the analysis we have conducted, it turns out it is an MD5 hash of which we still do not know what it responds to. The MD5 hash is triply encoded with base64 in the code.

Partof the code where the password appears and how to decode it in base64. Click to enlarge

The result of the decoding is the password that can be entered in the corresponding dialog to decrypt the data without having to pay at all.

The rest of the code is sometimes messy, although it seems they are working day by day to improve it. For example, the salt in the cryptographic function is not random. This, which in any other circumstance would allow a precomputed dictionary attack, really does not have much effect here (the password is not in a dictionary, it is a hash), but it gives us an idea of the little cryptographic value that this ransomware has.

A not very useful salt (12345678), although it is not very important here.

HTML code

The HTML code that is displayed to the victim forms a very important part of this malware. It is also embedded encoded in base64 in the code. In it we can see that a verification is conducted using the APIs of the Blockchain.info (misused, it encloses the wallet in quotation marks) in order to know if the payment has been made and if it is validated in the blockchain. It uses Satoshis, which are a fraction of a bitcoin.

They misuse the API of Blockchain.info, although later they correct it

If so, they display some URLs hidden in JavaScript that are supposed to give access to the decryption code, and hosted in the Tor network. This protection (using a "hide" class) is ridiculous. When we access the URLs, the truth is we cannot see any decryption code (we guess that because they are still in the trial stage).

They are supposed to provide you with the decryption code when you pay and visit those URLs, but it does not look like it.

Refer-a-friend plan

What stands out the most about this is the "nasty way" to decrypt the files. Allegedly, if you send the executable link to two acquaintances and they pay, you will be given the unlock code. It is a very smart way to get a fast diffusion, but we think it is not true. The code does not contain any instructions to verify that this happens automatically. Unless all intelligence runs from the server side (which we doubt), we cannot guarantee (nor have we technically proven that it happens) that this is so and, therefore, this is more likely to be just a hoax to spread more malware. In fact, the generated executables do not contain information about who has recommended them, only the fact that they have been created under a URL that does indeed contain the ID of the initial victim. But looking at the entire system, its poor programming, unfulfilled promises, threatening countdowns that in the end do not erase a thing and the unstable infrastructure and "craftsmanship" in general, Occam's razor makes us lean to think that everything is false and that there is no mechanism to control this.

Remember that we have a tool with an approximation of proactive protection against ransomware that you can (soon) download from our laboratory.

Sergio de los Santos

Latch Plugins Contest 2016 is over

Monday, December 12, 2016

Today, Monday, December 12 at 1 pm (CET), was the deadline for the submission of plugin applications to the Latch Plugins Contest, the Latch contest that looks for innovative and handy plugins for the Latch service. Any project submitted after this deadline will be invalid and will not enter the contest.

Now it is the turn of our jury, a top-level jury, composed of Chema Alonso, CEO CDO; José Palazón, CTO CDO; Pedro Pablo Pérez, VP Global Security; Alberto Sempere, Security Global Product Director, and Olvido Nicolás, CMO Global Security.

As you know, the jury of ElevenPaths will acknowledge:
  • Creativity, we are sure that you are inventive! 
  • Utility of the solution, simplicity and usability are very important. 
  • Effort, which is always rewarded. 
  • Thoroughness of the solution, the more complete the better. 
  • Clarity of documentation. 
  • Compliance with the submission date of the candidature.
After the deliberation phase, you will know if you have won one of our juicy prizes: up to $5,000 (in bitcoins).

Stay tuned! Winners will be notified by email during the 14 days following the closing date of the contest. You will then have 10 days to accept the prize.

Follow all the details in our blog and in the #LatchPluginsContest hashtag.

You can still win 5000 dollars. Send your Latch plugins over!

Friday, December 2, 2016

Remember that on Monday, December 12 at 1pm (CET), the deadline for the submission of applications for our Latch plugins competition ends. You’ve had almost two months to think of a breakthrough idea and to develop it, but don’t worry; you still have a few more days to round it off.

However, if you still don’t know what you want to do, you still have time to register and, to help you, we will give you some ideas.

How about this Latch integration for the protection of payments developed by our collegues in Equinox (in just 23.5 hours!)? A great project that combines creativity, security and utility!
The idea is to be able to issue a token that gives access to a service or device. This token is printed on paper (which I have) and is only valid when the token Issuer authorizes its use from the Latch application (second authorization factor).

Or how about the integration of ElevenPaths’ Latch+Antiransomeware in the AntiRansomWare tool? It is the winning combination to address a problem as worrying and common nowadays as Randsomeware. It is a tool that adds an authorization layer on Windows systems for “protected” folders, in addition to the existing permissions of the operating system, so that any type of write or delete operation of the files is denied. The authorization in this case lays on Latch instances for each folder, and files in those folders cannot be modified or deleted if the associated Latch is closed.

Aren’t you inspired yet? How about you try the new Latch Cloud TOTP functionality? This functionality allows you to use Latch as an application to generate TOTPs that you can easily use with websites like Facebook, Dropbox or Google.

Get involved and enter the competition! Register in the Latch Plugins Contest. A prize of up to 5000 $ is waiting for you.

May the luck be with you!

Take part in Latch Plugins Contest with such hacks as Paper Key. Are you game?

Thursday, November 24, 2016

At Elevenpaths there is a tradition of developing innovation and training the ability to transform an idea into something tangible, as you might know that in development process, projects often have “asymptotic” completion times

Every six months we are challenged to develop an idea for 24 hours in a row, put it into practice and then present it in public. It can be anything, but the important thing is that it works. We call it Equinox.

In the Equinox of Fall of 2016, a group of colleagues (Jorge Rivera, Pedro Martínez, Alberto Sánchez and Félix Gómez) wanted to unite the abstract, the logical security, with the specific, something that you could touch. And we thought that, at the same time, we could use the technology of Latch and the new API developed this year (the “operation instances”- Latch SDK).

From there, the Paper Key project was created, with which we wanted to unite different technological pieces, prioritizing the security of the whole process, and abstracting the technology, so that the use is simple and intuitive.

The idea is to be able to issue a token that gives access to a service or device. This token is printed on paper (which I have) and is only valid when the token Issuer authorizes its use from the Latch application (second authorization factor).

In our real example, a person can print a ticket with an associated amount of money, and after authorizing the operation in Latch from their mobile, a second person exchanges the ticket in an automatic wallet, which will deliver the indicated amount of coins.

The whole process involves two people (the Issuer and the Recipient) and four technology blocks: the web application, the ticket printer, the API Python server, and the ticket reader + wallet.

The Issuer, from a web application, generates a ticket with an operation identifier and an amount of money. The operation is associated with the Issuer’s Latch account, and the ticket is sent to the Recipient by physical means, or with the printer that is in their environment.

When the Recipient wants to consume the ticket (in this case, get an amount of euros from an automated wallet), they approach a ticket reader, which will check the status of the authorization in Latch. As long as the ticket Issuer does not authorize the operation, the service cannot be accessed or consumed, and a notification will also be sent to their Latch app that someone is attempting to use the ticket (which is the standard behavior).

The architecture used in this proof of concept could be optimized, but since we had to finish all developments in 24 hours, we needed to share the work among the four of us. (This approach also allows the server, printer and ticket reader to be distributed in different locations, since they communicate with each other via the Internet).

Taking into account the premises of Equinox (24 hours, that it works and that it can be explained!), we describe the different components in more detail.

The WebApp
It is a simple application in PHP with an interface in liquid HTML that allows to adapt the forms to the different sizes or orientations of the screen of mobile telephones.

The application runs on a WAMP server and communicates with an API in Python to interface with the printer and the ticket reader. It is a standard PHP application, where users are authenticated by user and password against a MySQL generating a session token. You can find a lot of examples on how to do this on the website.

The WebApp allows the user to browse, and after being validated, to select an amount of money and write a free text to identify the operation. This information is sent via a POST to a Python server, which will generate a request for the printer.

The response of the server with the API in Python is a JSON that we parse in the PHP server to return the response to the WebApp:
status: [Ok/NOK]
money: [amount of money – to inform the WebApp]
id: [Identifier returned by the server – for the WebApp]

In the response of the POST we receive the status of the operation and the ID generated to enter it on the screen of the Issuer’s phone.

The ticket printer
This subsystem consists of a Raspberry Pi and a thermal ticket printer. The printer (Brother QL-570) was kindly lent to us by the Secretariat team, and we got the Raspberry from the IoT Security lab, which has enough hardware to play with.

The Raspberry is connected to the Internet via Wi-Fi, and it waits in a port for a REST request with the contents it has to print ( “generateID” operation.)

instanceId: [Latch instance ID]
money: [amount of money in Euros]

A two-dimensional QR code is generated with the libqrencode library, and with the Image Magic’s libraries, the code is superimposed over a pre-established background with the “Equinox” logo. Then, the text is added to the request, in this case the value of the generated ticket.

The final ticket will be printed with the Raspberry PI thanks to the printing pseudo-driver for this printer, available in Git-Hub.

The QR code is an operation identifier encoded in Base32, and will allow the QR code reader to check the authorization status of the operation before providing money (1 Internet Point goes to the one that tells us why we had to use Base32 instead of Base64).

The Python API server
On this server we can find the API in Python for Latch (interface between the WebApp, the printer, the ticket reader and the Latch server) and the WAMP server.

The server is invoked by the WebApp, using a POST to port 1338, with the fields:

money: [amount of money in euros]
text: [string of text that will appear in the Latch app]

Two operations are now executed sequentially:
1. The server creates a request via the API to request the “operation instance” to the Latch system of Elevenpaths, so that in the Latch app associated with the user, a new line will appear with the text identifier of the operation. This operation is now subject to the authorization of the user, is “latched”.

And in the interface of the phone app ... we find, within the PaperKey service, a new “operation instance” with the entered text “Equinox Demo 2016”.

2. The server invokes the ticket printer (IP and port of the Raspberry associated with the printer) so that the ticket is printed with the QR code associated with the operation. At this moment, the Issuer has generated an operation in Latch, and also has printed a paper ticket with a QR code that identifies said operation.

If the Recipient of the operation (that person who physically takes the ticket) would like to use it, they must wait for the Issuer to authorize such operation.

Ticket reader + money bank This system is composed of another Raspberry Pi (in the cardboard box), a laser QR code reader, like those in supermarkets and a colorful coin dispenser (we told you they have a lot of toys).

The laser reader is presented by USB as a standard HID keyboard, so that to transmit information to the operating system it simulates keystrokes corresponding to the scanned code (digits or characters).

This posed an interesting problem with the terminal. In order to be able to capture keystrokes without the STDIN of the process - since this would be in its console, not being available from a process launched in a pseudo terminal - we used a wrapper programmed in C that intercepts the events of the device that presents the Linux kernel in user space /dev/input/event5.

And this caused us a second problem, since the operation identifier we use has alphanumeric characters with uppercase and lowercase, and the keyboard emulation of the scanner is always with characters that do not require simultaneous keystrokes (e.g. [SHIFT] + Letter.) So we had to do a code conversion to Base32 (which collaterally increases the size of the string, so the density of the QR code must be increased as well.) If you have read this, we will not give you that Internet Point. After all the twists and bumps, we have an operation identifier. From the Raspberry, we build a JSON request, and launch it against the API Python server as operation “checkID.”

Id: [Operation identifier]

The server sends a query to Latch, providing the operation ID associated with the user. If the operation is “latched” (“Latch ON”), the system will return an error.

If the operation has been unlatched (“Latch OFF”), the system will consider the operation as authorized and will proceed to provide the amount of money indicated in the automatic wallet. The wallet is connected to the Raspberry Pi by USB, and it receives the amount of coins to dispense with a code of 4 digits.

Taking part in Latch Plugin Contest
Paper Key, as proof of concept, allowed us to prove that it is simple (we did it in 23.5 hours!) to integrate different technologies to achieve a secure and user friendly system with many use cases, depending on the imagination of each person.

For example, lockers containing a product provided by the Issuer and that can only be opened by the Recipient, upon confirmation of payment received by the Issuer via their Latch. Or one could issue tickets for a free bar: only when the party responsible (to pay) decides so via their Latch, the tickets can be validated in exchange for drinks. One can also give one-time access (OTA) to a facility, for example, give free trial days of access to a gym.

As you can see, a lot of things can be done with relatively simple integrations.

We would like to take this opportunity to remind you that a few weeks ago ElevenPaths convened a new edition of the competition Latch Plugins Contest. In this contest you can win up to $ 5,000; remember that what is rewarded is the imagination, talent, creativity and solution provided. If you want to know all the steps to follow to register, visit our Community, where we explain how to participate and where you can find tricks, tips, and also join the conversation about the Latch Plugins Contest. In addition, if you want to know all the mechanics of the contest, you will also be able to check the legal terms and conditions.

Remember that the deadline of the contest is December 12, 2016, show your hack side and participate now!

*Related content:
Latch Plugins Contest: the plugins and hacks contest in which you can win up to 5,000 USD
Latch Plugins Contest: Remember the story!

ElevenPaths and Etisalat Digital announce their collaboration for Mobile Security R&D

Monday, November 21, 2016

Madrid, November 21 2016.- ElevenPaths, Telefónica Cyber Security Unit, and Etisalat Digital, two of the world’s leading providers of communications services and solutions, announced today their collaboration in the field Mobile Security research & development (R&D) to conduct extensive research in monitoring and analysing mobile threats for applications and devices. The collaboration was announced at the recent RSA Conference 2016 held at Abu Dhabi. This is an expansion of their alliance beyond their existing shared portfolio of Managed Security and Cyber Security Services. The agreement in Security Services is part of the broader collaboration existing between both companies in multiple areas, under the framework of the Strategic Partnership Agreement originally signed in June 2011.

Francisco Salcedo, Senior Vice President Etisalat Digital said “today’s announcement is significant as mobility has moved beyond devices, apps and online transactions to a connected ecosystem. This transformation has made mobile platforms vulnerable and an easy target for cybercriminals. The collaboration and the deployment at Etisalat Digital’s Cyber Security Operating Centres will enable both partners to provide a solution for enterprises to control fraudulent activity which directly impacts its services, brand or reputation.”

The tools and knowledge used for prevention of PC malware is completely different to mobile malware. A mobile ecosystem is extremely dynamic and cybercriminals are constantly evolving the tools and techniques used for such activities. They look for sustainable, scalable business models that generate revenue through fraud while defeating security enhancements introduced by Mobile App Markets on a regular basis.

Both companies will work with Tacyt, a cyber intelligence mobile threat tool developed by ElevenPaths for mobile threats monitoring and analysis. Tacyt uses a big data approach for mobile app environment research and an enterprise-grade service to conduct full investigations, including mobile malware classification, attribution, categorization, monitoring and in-depth analysis of mobile malware need multiple approaches:

  • Mobile ecosystem is extremely dynamic and cybercriminals look for sustainable, scalable business models that generate revenue through fraud while defeating security enhancements introduced by Mobile App Markets. 
  • Attribution and malware family categorization reveals trends in the cybercriminal community. 
  • Malware risk categorization is vital for mobile threat defense in Bring Your Own Device (BYOD) deployments. If an employee installs aggressive adware on a device, would that be enough to block access to corporate email on its own? What if the adware roots and places a backdoor? Categorization will help in such deployments.

Pedro Pablo Pérez, ElevenPaths CEO and Telefónica Global Security Managing Director, said “we are pleased to collaborate with Etisalat Digital to conduct this in-depth research and analysis on mobile threats. Cyber analysts can use Tacyt for manual or automated search, matching, and investigation of different parameters (metadata) within iOS and Android apps. This allows the identification of potential ‘singularities’, a concept which refers to whatever data (dates, size, images, digital certificates) – technical or circumstantial –makes the app or its developer – as a person – singular or unique from others.”

Cryptographic Security in IoT (III)

Friday, November 4, 2016

The proliferation of IoT services platforms and devices is occurring much faster than the adoption of security measures in its field. In the face of the urgent need for mechanisms that guarantee the authentication, integrity and confidentiality, of both communications and the devices themselves, the trend is to transfer cryptographic solutions contrasted in traditional IT, such as public key digital certificates over SSL/TLS protocols. We are moving forward in the state-of-the-art of cryptography solutions for IoT.

HMAC Calculation
Execution of the HMAC command, as with other ATSHA204A commands, must precede execution of the Nonce command.

The aim of the Nonce command is to populate the 32-byte internal register, called TempKey, by generating or loading a challenge, which will then be used in later commands.

The Nonce command has three operating modes. 0x00 and 0x01 are the most common modes. In these modes, the Nonce command is invoked, providing it with a number of 20 bytes as an entry, to which it responds by returning a random number of 32 bytes that are generated internally as a challenge.

The 20 received bytes are linked to the random number of 32 bytes, along with three more bytes: 0x16, the mode and 0x00. And based on the set of 55 bytes, the SHA-256 summary, which is stored in the TempKey, is calculated. Additionally, two binary registers are modified:
  • TempKey.SourceFlag to 0, meaning random origin. 
  • TempKey.Valid, to 1, meaning that the TempKey is usable.
The difference between the 0x00 and 0x01 mode is that in the second case the seed of the random number generator does not update, something that Atmel does not recommend.

In 0x03 mode it is used to directly populate the TempKey, without generating a random number, or the SHA-256 calculation in bypass mode.

If the Nonce command has finished satisfactorily, setting the TempKey.Valid bit to value 1, it is then possible to invoke the HMAC command.

The call to the HMAC command is performed by providing as entry parameters only its mode of operation, and the slot number that contain the key to be used in the HMAC calculation. The response to this command will be the resulting number of 32 bytes from the HMAC-256 computation over a total of 88 bytes made up of:
  • Set of 0x00 value 32 bytes. 
  • Content of 32 bytes from the TempKey. 
  • Base of 24 bytes determined by the mode of operation. 
The HMAC command presents multiple modes of operation, which will determine the content of the OPT zone and the series number (SN) for the device incorporated into the base. It is possible that none of these elements are incorporated, establishing the last 20 bytes of the base at 0x00.

The base of the HMAC calculation will always begin by the 0x11 byte, followed by the mode byte, and two more bytes indicating the slot which is occupied by the key that will perform the HMAC-SHA-256 calculation.

The third least significant bit of the byte mode must coincide with the TempKey.SourceFlag value previously established by the Nonce command.

For all communication with the ATSHA204A device, both incoming and outgoing, two CRC cyclical redundancy check bytes will be added to guarantee the integrity of both the command invocation and its response.

Web PoC
Although the literal description of the authentication commands may appear confusing, their use becomes very simple once implemented within a code library, as can be seen below:

As a simple proof of concept (PoC), we have implemented the practical use case of an IoT device that must be robustly authenticated by a web service, using cryptographic hardware.

For the example to be extended towards the general public, Arduino is used as development environment on an ESP8266 platform that facilitates web access through its WIFI interface.

Any ESP8266 module could be used; a NodeMCU v0.9 has been used in this case, loading a sketch generated from the ESP8266 core for Arduino. An Atmel SHA204A Cryto-Authenticator externally connected to the NodeMCU module has been chosen as the cryptographic hardware.

From the different libraries available for managing the SHA204A, the best adapted for this in general, and the most worked on, was the work of Nusku in 2013. However, it apparently did not work uniformly on different devices and presented some important shortcomings. We have solved these problems by publishing our own fork in Github.

The authentication in the web service is done by inserting an authentication token in the HTTP request (GET request). This is a very common and widespread practice among the most important web authentication services. The "Authorization” header, together with the adequate parameters, has been added for this purpose.

These should include the "11PATHS-HMAC-256” type token, together with the corresponding encoded values in Base64 format. To simplify the process, in addition to the “id” of the device, the header also includes the "nonce" (challenge) and the "base", used to calculate the verification "signature", although the protocol supports the challenge provided by the server.

Captured requests could be re-utilized by sending all this data in the request. In order to avoid this weakness, the timestamp is added in unix-time format as part of the request to be signed.

GET /?timestamp=1458647701 HTTP/1.1\r\n

In order to sign the HTTP request with the Atmel SHA204A, it is summarized to 20 bytes with the SHA-1 algorithm. The Arduino core for ESP8266 includes this function in the "Hash.h” library, but it can be added from the Arduino Crytosuite if another platform is used.

The SHA204A Nonce command is invoked with the obtained 20 bytes, obtaining the 32 resulting bytes as the challenge, and they are stored.

The HMAC command is then invoked, indicating the slot number that contains the key with which the HMAC-SHA-256 will be calculated, together with the execution mode. Once these values (mode and slot) are known, the 24 byte base added to the calculation can be deduced. The result of this command will be the 32 bytes corresponding to the signature of the request.

These values, together with the "id" we assign to the device, will be the base64 parameters that will be included in the header. The base64 encoding is done using the Adam Rudd library.

Authorization: 11PATHS-HMAC-256
nonce="LmzzEpRnXvqmvnbOSobGp1VysR/wEpWoMNaY2Miew5g=", base="EQACAAAAAAAAAAAAAAAA7gAAAAABIwAA", signature="4qnOa5ZGecdzC+DscOSuOhJ64LeB1jTieJATUWPoIZE="

The web service will be able to verify the authenticity of the IoT device that makes the request, performing the same calculations and comparing the results. To that end, it only needs to know the 32 byte key assigned to the device by its “id”.

The example web service has been published in the following url as part of the demonstration: http://sha204a.cf

This web service will respond with a JSON that contains information related to the authentication if it is valid, and failing this, with the details of the error that has occurred. It can be freely used for testing, because it answers to any id that has signed with the example key:


A reciprocal authentication does not occur in this example; in other words, the web service’s answer does not contain any parameter aimed at verifying its own legitimacy, though incorporating it would have been easy. This condition is usually delegated by establishing a secure SSL (https) connection where the web service certificate is verified.

The code of the Arduino sketch is very simple. It manages the connection to the Internet with the "WiFiManager.h" library, which presents an AP with a captive portal from which to configure the Wifi network if the SSID has not been configured or is not available, or if its credential is not valid. Once the Internet connection is established, the current time is established through an NTP server.

An SHA204A authenticated request to the configured web service is made each time the FLASH button is pressed.

A simple Script in BASH can be used to test the connection to the web service; this simple script simulates the calculation of the signature the same way as the ATSHA204A would, and makes the web request.

The Shell Script, the Arduino code for the IoT module, and the PHP code of the web service are published in this Github space: https://github.com/latchdevel/crypto-iot

*Related Content:
Cryptographic Security in IoT (I)
Cryptographic Security in IoT (II)

New tool: PinPatrol for Chrome. Something more than a plugin, a forensics tool

Tuesday, November 1, 2016

Back in July, we created a new tool for improving the experience using HSTS and HPKP in Firefox. Now it's time for Chrome. It shows this information in a human readable way. PinPatrol for Chrome is very easy to use and it can provide useful information about the HSTS and HPKP data stored by your browser... or any other. Porting it to Chrome, it has become not just a Chrome extension, but a simple forensic tool for interpreting HPKP and HSTS data from any Chrome’s user.

Just as Firefox, Chrome stores HPKP and HSTS information in a clear text file. But their strategies are quite different. The main ones are that:
  • Chrome stores the information in a Json file.
  • Instead of storing it in cleartext, it hashes the domains in a standard format, so there is some "privacy" for the users.
  • It uses report_uri from HPKP protocol (Firefox does not yet).

The way the domains are hashed is documented. An example is here. This is the way a raw Json looks like:

Chrome offers an integrated way (chrome://net-internals/#hsts) to check some HSTS and HPKP values, but definitely it is not the best way to watch your domains.

There is another difference in the way Chrome works. Chrome does not allow extensions to get to your profile files, so you have to drag and drop yourself the file where the information is stored (%localappdata%\Google\Chrome\User Data\Default\TransportSecurity in the case of Windows). We can think of this as an advantage to use this extension as a forensic tool.

Another interesting thing the tool tries, is to "un-hash" the domains. If there is a domain in your HSTS and HPKP domains repository, it means you have visited it. So it should be in your History files. What the tool tries is get to your history of domains visited and hash them. If this hash matches with some of the hashes in HSTS/HPKP, the tool "translates" it so it is un-hashed.

PinPatrol takes history domains visited, hashes and compares them against HSTS and HPKP hashed domains

But, why are there so many domains that are not un-hashed? Some reasons:
  • Your history has been deleted and the domain is not there, but still in the HSTS/HPKP repository.
  • Some visits to some domains with HSTS and HPKP are done "in the background" of a webpage, as part of its APIs, advertising system, etc. And these are not stored in the History. 
Here is a very short video about how to use the tool.

The tool is available from the official Chrome Extensions Store:

We hope you find it useful.

ElevenPaths and Symantec plan a joint offer Security Solutions for IoT environments

Monday, October 31, 2016

ElevenPaths collaborates with Symantec as technology provider for its Security certificate service for IoT.

Madrid, October 31 2016.- ElevenPaths, Telefónica Cyber Security Unit, announce our intends to collaborate with Symantec, as a global cybersecurity leader, on integrating Symantec Managed PKI Service in order to protect IoT environments against cyberattacks.

In the Internet of Things millions of different devices are interconnected in an open digital environment and need to communicate securely at all times in order to preserve the trustworthiness of the IoT applications. Identity and Authentication is a cornerstone of building such trust, therefore Telefonica is developing ways to securely and indisputably identify those devices and secure the data transmitted among them.

That is, as in the physical world our ID card or passport identify us as people, in the context of the IoT Telefónica is in the process of developing its Trusted Public Key Infrastructure service, and will be relying on best- in-class Symantec Managed PKI Certificate Technology to ensure that the connected devices are exactly what they claim to be and that code running on IoT devices is authorized.

The high-volume, high-performance managed certificate service Symantec offers will allow Telefónica to embed certificates on hardware or issue them in real time as required for their specific use case. These code signing certificates and cloud based signing-as-a-service will be part of Telefonica’s comprehensive offer for IoT environment.

With the new technology incorporated by Telefónica companies that require large-scale IoT deployments will be able to manage certificates’ lifecycle for auto enrollment, renew and revoke the certificates to secure the communication and provide mutual identification, encrypt communications end-to-end and guarantee the integrity and traceability of the transactions.

Trusted Public Key infrastructure service is integrated with other security and IoT managed connecting as smart M2M and is part of  IoT Security solutions currently on offer by Telefónica: such CyberThreats, capable of detecting and identifying the modus operandi of the cybercriminals and the methods used in attacks against IoT infrastructure; and Faast IoT technology specialised in detecting and analyzing vulnerabilities in IoT ecosystems.

ElevenPaths and Symantec intend their future collaboration to deliver on 4 key cornerstones that are drivers for the IoT and its security: the protection of communications, securing the identity and authentication of the IoT devices, the protection of devices themselves, including host-based protection and reputation based security, the management of the devices including OTA management, and the understanding of the IoT environment, through security analytics helping flag any anomaly.

More information:

Now you can use Latch with Dropbox, Facebook and others digital services

Saturday, October 29, 2016

Many of you have asked us which services you can use Latch with, regretting that so far it could not be used in the more common services, such as Dropbox, Facebook or even Google itself. Well, the new version of Latch comes with a new functionality that will allow you to use Latch to protect your accounts in these and many other services. Now available for Android and Windows Phone, and coming soon the iPhone version.

What is this functionality about?
This new feature implements the TOTP protocol (Time-Based One Time Password), which generates a password valid for a period of time. This password may be requested to users by the services that support it (including the above) as a second factor authentication if the user specified so in the configuration. Thus, users of these services will receive this temporary code in the Latch application installed on their mobile phone, and use it as a second factor authentication (after having been authenticated with their user name and password) to access the services.

What’s new?
Apps already existing in the market for this purpose generate TOTPs associated with the mobile device so that if the user has a problem with it, such as loss or theft, or if they simply have to reset factory data for some reason, they will need to match the services protected with this second factor authentication with the application they use.

In Latch, we have created what we call Cloud TOTP, which consists in, instead of associating the TOTPs with the mobile device, associating them with the Latch account, thus simplifying the recovery process in case of loss of the device.

How can I use it?
To start using this new functionality, you just need to follow these steps:
  • First, create a Latch account and install the Latch app on your mobile device.
  • Then, go to the configuration of the service you want to protect with second factor authentication and enable it. If we take Dropbox as an example, you have to go to the Settings -> Security section, look for the “Two-step verification”, and enable it as shown below, after which you will be guided through a series of screens. When asked how you want to receive security codes, select “Use a mobile app”. 
Image 1. Enabling the two-step verification in Dropbox

Finally, add the new service to Latch capturing the QR code provided by Dropbox following the steps in the Latch app, as shown below.

Image 2. Dropbox QR Code
Image 3. Capturing the QR code with Latch

>>Stay tuned! We´ll post video tutorials using Cloud TOTP with services as Dropbox, GitHub, Facebook, Google, etc.

Find out much more about Latch!

Cryptographic Security in IoT (II)

Thursday, October 27, 2016

The proliferation of IoT services platforms and devices is occurring much faster than the adoption of security measures in its field. In the face of the urgent need for mechanisms that guarantee the authentication, integrity and confidentiality, of both communications and the devices themselves, the trend is to transfer cryptographic solutions contrasted in traditional IT, such as public key digital certificates over SSL/TLS protocols. We are moving forward in the state-of-the-art of cryptography solutions for IoT.

Given Atmel’s long history of developing security elements with cryptographic abilities, such as TPM modules, microcontrollers for SmartCards, cryptographic accelerators, crypto-memories, comparators, etc. it is only natural that the IoT ecosystem begin to integrate its Crypto-Authenticators to add cryptographic abilities. These have three different available variants:
  • SHA204A: simple authenticator based on MAC/HMAC-SHA-256.
  • AES132A: authenticator and cipher based on the AES/CCM symmetric algorithm with 128-bit keys.
  • ECCx08A: authenticator and cipher based on ECDSA and ECDH elliptic curve asymmetric algorithms, with 256-bit keys.
Their physical characteristics are practically identical and are therefore compatible and interchangeable. Choosing one or the other will be determined by the needs of the device storing them, and though they incorporate numerous characteristics of some complexity, it is possible to use their  basic functions easily.

They can be used as highly versatile cryptographic security elements: from simple device authentication, mutual or reciprocal authentication, session key negotiation for integral encryption of a communication, code or data authenticity verification during secure start-up (SecureBoot) or remote firmware updating (OTA), etc. All this for less than 1 euro. If we meet the program’s requirements for “samples”, Atmel sends free samples at no extra cost.

I2C Bus
Different small sized formats are produced, all of which are surface-mounted. Though there is a version with only three pins that uses an SWI communication protocol, which for a time was sold by Sparkfun on a mini board, the 8-pin encapsulations are the most common, with SOIC-8 being the most manageable. For the evaluation and testing stages, using a DIP-8 adaptor is advised; there are different types, including the most popular GROVE modules, and you can even make your own.

Only four of its pins are in use. Two for its flexible power supply, of extremely low consumption, which can vary from 2.0 to 5.5 watts; two for the I2C bus, which enables connection to microcontrollers such as the popular Arduino, and even desktop systems and servers by means of adaptors, generally USB types.

The I2C bus is a standard for serial communication, widely used in the industry to interconnect integrated circuits. It uses two lines to transmit information: a data line (SDA) and a clock line (SCL), both with ground reference (GND).

In systems such as BeagleBone and Raspberry PI, the I2C is easily accessible both physically, as it is exposed, and logically, through numerous tools available in GNU/Linux.
If we want to use a conventional system, either Windows, Linux or Mac, that does not have an accessible I2C bus, the most simple option is to use an I2C USB adaptor. There are commercial ones, however it is possible to build your own thanks to the i2c-tiny-usb standard driver, which allows any system to use an Atmel ATtiny 45/85 microcontroller by way of interface USB to I2C. Only a few brave people dare to use the I2C bus present in the connector of video cards, even though it is technically possible. Although it doesn’t provide the same functionality, it is also possible to use firmware that uses the LUFA library in any compatible Atmel microcontroller, for example the ATmega32u4 from Arduino Leonardo, creating a "Serial to I2C" interface, which is accessible from Python, for example. With the USB adaptors included in the official Atmel development kits, the Microsoft Word tools that are included for free can be used.

Communication in the I2C bus is conducted in a “master-slave” manner. The master initiates the dialogue, obtaining a response from the slaves that are identified by their 7-bit I2C address. This address comes factory ready, though many devices have mechanisms to modify it, allowing several similar devices to connect to the same I2C bus.

The “host” systems can only be masters of the I2C bus, with the majority of I2C devices being slaves. Some microcontrollers, for example those used in Arduino, can be programmed to behave as masters or as slaves, though it is most common for them to act as masters.

Through the "i2cdetect" command in Linux, or with a simple sketch in Arduino, the I2C bus can be scanned to detect connected slave devices.

In this scanning example, performed in either Linux, with an "i2c-tiny-usb” adaptor, or in Arduino, the real I2C addresses (in 7-bit format) for the crypto-devices connected to the bus can be obtained. Many manufacturers, Atmel included, usually indicate the I2C addresses in 8-bit format in their specifications, which can result in some confusion.

Open Source libraries
Together with detailed documentation, Atmel facilitates open source libraries for cryptographic device management from their line of micro-controllers and SoCs.

From these libraries, adaptations to different environments began to appear, once again emphasising Josh Datko’s work which, from Cryptotronix, facilitates numerous examples for both Linux and Arduino.

The Atmel SHA204A Linux driver, called Hashlet, particularly stands out, and has served as a starting point for many other developments.

There are different adaptations for the Arduino platform, each of which has its pros and cons, so a choice must be made to find the one that adapts best to each particular need.

Atmel SHA204A
The Atmel SHA204A is one of the simplest and most easy to use cryptographic devices, though it has a wide variety of functions in relation to its relative complexity.

Its functioning is based on the computing of SHA-256 summaries, used to generate MAC/HMAC (Message Authentication Code) from internally stored keys. It has 16 slots to store keys that are 256 bits (32 bytes) in length, and can, in turn, have different access and usage configurations, defined when personalising the device. Together with an 88 byte configuration zone and an OTP (One Time Programmable) zone that is 64 bytes in length.

It has a random number generator, with which it implements challenge-response operations without exposing keys (MAC, CheckMac, GenDig). Supporting "Key Rolling” mechanisms (DeriveKey). It is unequivocally identified by an unmodifiable, factory-defined 72 bit serial number (SN).

It has an abundance of official documentation which is available on the internet, as well as a large number of examples developed by the Open Source community. Though it implements 14 commands, it is possible to make complete functional use of it with only two of them, as we will see next.

Before being able to use any cryptographic device, it is necessary to establish its unique keys and configuration options, and to lock the configuration and OTP zones. This process is known as "personalisation", and is irreversible; once this has been performed, there is no possibility of turning back, the established parameters will remain unchangeable.

ATSHA204A personalisation is easily performed through Linux by using the Cryptotronix “hashlet”, as described in the documentation. Once the personalisation command has been executed, the unique keys will be defined and configured in the following manner:

If you have an official Atmel development kit, it is possible to perform the personalisation process from the incorporated tools, but, in any event, it is essential to follow the manufacturer’s indications.

Stay tuned! In the following post about Cryptographic security in IoT, we will take a look at how the HMAC calculation works in technical terms in ATSHA204A. And as a proof of concept (PoC), we will implement the practical use case of an IoT device that must be robustly authenticated by a web service and using cryptographic hardware.

*Related Content:
Cryptographic Security in IoT (I)
Cryptographic Security in IoT (III)

ElevenPaths acquires Shadow technology from Gradiant

Wednesday, October 26, 2016

Chema Alonso (Chief Data Officer of Telefónica and Chairman of ElevenPaths) announced during Security Innovation Day 2016, the purchase of the Gradiant's solution for document security, SHADOW.
The acquisition is one of the first derivatives of the recent agreement signed between Gradiant and ElevenPaths, the cybersecurity division of Telefonica worldwide. Both parties also stated that this acquisition is only the first step in what they hope will be a long history of mutual successes.

What is SHADOW?

More than half of the companies worldwide (54%, according to data from 2013 Nielsen Report) have had at some point losses or leaks of sensitive information. Despite the security measures currently available (DMS, access control mechanisms, firewalls), there are still security holes.
The strongest chain always break at the weakest link. And in documents security, that weak link is -very often- equal to the human factor.
The leaks of confidential documents, depending on their origin, leads to sensationalist or damaging public disclosures for companies victims of such leaks. In other cases, such information although not made public, ends up getting to competitors, or even worse, criminals.
The damages caused by leaks of documents are very visible, and almost always very serious. They can be financial, reputational or in competitiveness.
SHADOW is an automated tool that allows the traceability of documents by using techniques of digital watermarking. Shadow provides evidences in the event that confidential information leaks happen, helping to identify those responsible for the infringements. Converts each copy of a document through the insertion of invisible water marks. In this way, SHADOW ensures that each copy is unique and at the same time, virtually identical to the original document. This watermark -hidden information that identifies the owner or the recipient of the document- is resistant to distortions, such as those produced in the printing process or the scanning of documents.
It works as a deterrent against information leaks: it is perfect for hiding information on the origin and destination of confidential documents in order to identify those responsible if a leak occurs, once the documents are outside the trusted area for which they were created.
It also provides automatic classification of scanned documents: adding information about the contents of the documents, SHADOW can perform automatic classification.
It is a 100% compatible software solution with any printer or scanner devices. Ensures traceability in text documents, both digital and printed formats. The information associated with the watermark is fully configurable, being possible to establish a link to the document owner, to its receptor, or to the date and time when the document was printed. To retrieve that information afterwards, it is not necessary to be in possession of the original document.
In addition, SHADOW is resistant to distortions, printing and scanning, and is able to recover all the hidden information even from incomplete, broken, wrinkled or stained documents.
SHADOW family
SHADOW FILES: web platform that allows secure sharing fo documents. The platform allows sending documents to recipients previously registered in the system. Each recipient receives a single copy of the document containing hidden information that links the copy to the intended recipient.
SHADOW PRINT: Virtual Print Driver for Windows that allows automatic watermarking as soon as a document is sent to any printer. The printed document includes hidden information about the user account from which it is printed.
SHADOW READER: Tool for extracting information from the document’s watermark.

SHADOW MOBILE: Mobile application for extracting information from the document’s watermark.(available for iOS and Android).

“State-of-the-art” Partners to tackle the new NIS and GDPR legislation

Friday, October 21, 2016

With a continued rise in cybercrime, and considering our global economy is dependent on data driven decision-making, the EU has published new legislation that will have an impact on every business: the new Network and Information Security (NIS) Directive and General Data Protection Regulation (GDPR).

The NIS Directive is focused purely on security, to promote a culture of risk management and ensure that the most serious incidents are reported, and applies to (i) “operators of essential services”- organisations that provide elements of a country’s critical national infrastructure – i.e. operators in energy, transport, health, banking …; and (ii) “digital service providers” - Cloud providers, internet exchanges, online marketplaces, which are not micro- and small enterprises.

The GDPR is focused on data privacy, aiming to bring data protection legislation up-to-date and into the modern age, and applies to all companies that process EU citizen data, except organisations with fewer than 250 employees with regard to record-keeping, and some exceptions that relate to national security.

By the end of May 2018, the NIS Directive (as it is an EU directive, rather than a regulation, needs to be implemented as local legislation before 9th May 2018 in each EU member state) and the GDPR will have entered into force in the European Union, giving organisations covered by these pieces of legislation until this date to establish compliance. Till then, organizations need urgently to plan and improve its overall security strategy to comply or potentially, in the event of a breach (NIS has notification requirements around security incidents, whereas GDPR on personal data breaches) an entity will likely have to defend its use — or lack of use — of a range of technologies and procedures.

The penalties for non-compliance are substantial, the primary effect of which will be to raise network information security and data protection as a business risk attention directly into the boardroom. No board member will want to have to explain to shareholders why profits and stock price have fallen due to a security or data breach resulting in a substantial fine. In the case of the NIS Directive, it is the responsibility of each EU member state to determine penalties, but the Directive does specify that penalties must be “effective, proportionate and dissuasive”. NIS grants authorities the power to initiate audits of private industry for suspected non-compliance. Enforcement will be combined with related regulations, in particular the penalties and fine included in the GDPR: dependant of the type of infringement, the fine will reach up to €10m or 2% of global turnover; or up to €20m or 4% of its annual worldwide turnover.

Security Requirements: “State of the Art”
NIS and GDPR have different rules and scope, but regarding their respective security requirements stated for the operators of essential services, digital services providers, data controller or data processors, both pieces of legislation require public or private entities to “have regard to1  and “take into account2  state of the art (NIS and GDPR, respectively) for their cybersecurity. Organisations must therefore take into account technologies and practices that are state of the art in security in deciding how to invest in mitigating risks associated with the protection of essential services that have a dependency on network and information systems (in the case of the NIS directive), and with data protection (in the case of GDPR).

However, neither piece of legislation defines clearly the term or explicitly requires use of specific technologies. Surely the reason is because security capabilities and IT evolve and mature relatively quickly, while legislation is typically long term.

As the NIS Directive requires each EU member state to implement it locally, maybe we could expect greater precision in future legislation. The NIS Directive indicates3  that member states shall encourage the use of European or internationally accepted standards and specifications relevant to the security of network and information systems, and that ENISA, in collaboration with member states, shall draw up advice and guidelines regarding the technical and security requirements. In the case of GDPR4 , associations and other bodies representing categories of controllers or processors may prepare codes of conduct, or amend or extend such codes, for the purpose of specifying the application of this Regulation. It seems you would need to continuously monitor such standards and codes of conduct, or to follow ISO standards, PCI DSS…, to obtain some kind of guidance and be compliant.

Companies must therefore have a view on what “state of the art” means to them and be prepared to conclude that they don't need to deploy it based on an assessment of risk, or to defend that view in the event of a breach, aiming to avoid the penalties and fine, and more importantly, not to harm your customers and Brand Reputation.

This is what IDC and Palo Alto Networks have recently called the “State of the Art Paradox”, a research on how businesses in Europe perceive the upcoming EU requirements of “state of the art” cybersecurity. The study found that many companies don’t have a clear understanding of the concept of state of the art, have no processes or metrics in place to measure their alignment with it, and lack a form of review of their position on it with sufficient frequency. IDC conducted research into companies with more than 250 employees based in France, Germany, Italy, Spain and the United Kingdom.

Moreover, if you don’t know how to tackle the security requirements of GDPR, so do as well the 82 percent of global IT and business professionals responsible for data security at both SMBs and enterprises, according to Dell global survey on the European Union’s new General Data Protection Regulation (GDPR), revealing that organizations ‒ both SMBs and large enterprises ‒ lack general awareness of the requirements of the new regulation, how to prepare for it, and the impact of non-compliance on data security and business outcomes. 97% said their companies didn’t have a plan in place to implement the new privacy law.

Be prepared and know how to address “state of the art” at your organization is critical: in any post-breach investigation a company will have to defend its use — or lack of use — of a range of technologies or procedures. You need to have a view on what “state of the art” means to your organisation, and be prepared to defend that viewpoint.

Boardroom issue: what should CEOs, CIOs, CISOs, CDOs, CPOs or DPOs do to incorporate “state of the art” into your cybersecurity/data privacy strategy?
Urgently build a Readiness Plan in order to address this knowledge gap, asking some fundamental questions about your companies’ readiness for NIS Directive and/or GDPR, as suggested by IDC/Palo Alto Networks Call to Action recommendations – Download the full report from IDC.

Basically, as recommended also by Palo Alto Networks Executive Advisory Report, ask your CISO and Chief Privacy Officer (or Digital Protection Officer (DPO)5 - new data-focused post required by GDPR) these questions:
  • Does GDPR or the NIS Directive, or both, apply to our company? Who in the business is accountable for these legislative requirements?
  • What is the company view on state-of-the-art security? How did we define it, and who advised us on this?
  • What is the timescale for us to reach compliance, and what actions need to be taken now in order to achieve compliance by the deadlines?
  • How will the business continue to maintain compliance, and what metrics will the business use to validate this to itself and, when required, to any third parties?

This new regulation provides uniform data protection rights across the EU, and, to be in compliance, both European organizations and those outside of Europe that do business there must adopt an adaptive, user-centric, layered security model approach around the tenets of predict, prevent, detect and respond. To be NIS and GDPR-compliant, you will need “state of the art” security solutions and Partners that enable you to predict and prevent attacks, detect a potentially dangerous presence in your networks, respond quickly to that threat, and analyze and report on the health of your networks in real time. By 2020, 60% of digital businesses will suffer major service failures due to the inability of IT security teams to manage digital risk – Gartner, June 2016.

Additionally, every organisation should consider taking out a cyber-security insurance policy. GDPR introduces the concept of continuous compliance, in which an organization must regularly carry out audits of compliance. This means not once a year, or even once every six months, but arguably on a weekly or even daily basis. At any point an auditor can ask your company to demonstrate compliance, and your company must be able to do that more or less immediately. Insurers will demand a certain standard of security and may be unable to quote you properly if you cannot demonstrate the greater consistency of your security framework. A £5 million indemnity limit is common and it is yet to be seen if the insurance industry increases it to cover the potential €20 million fines, which data protection regulators will be able to impose from 2018.

In summary, you will need to launch a Readiness Plan, be sure you have the most modern (state of the art) technology and processes to address the NIS Directive and GDPR legislation, work with the best (state of the art) Partners, and take out a cyber-security insurance policy, so that it can be proven to whomever needs to know that your organization is doing it all correctly.

ElevenPaths Partners Program: State of the Art Partners
We have recently announced during our Security Innovation Day 2016 the launch of our ElevenPaths Partners Program, as we believe in the idea that “together we are stronger", aiming to continue and to innovate together in the fields of security and privacy. We have defined five Type of Partners, and we are continuously evaluating the market to partner with those ones that better will help us to integrate our experienced security services with your security strategies, in order to help you to keep your critical information safe and your business resilient while you focus on your business.

At ElevenPaths we strive to partner with state-of the art technologic and start-ups companies, aiming to develop and combine together modern, innovative and disruptive security products, helping you to ensure the security of your network and information systems, to report your incidents, and to manage your data privacy, as required by NIS Directive and GDPR respectively. This is what we call our Paths, on which we work every day to offer security today and in the future for these challenges:
  1. Identity and Privacy: To give people control over their personal information and privacy in their digital lives. Identity and access management (IAM) is an important category of technology in the delivery of GDPR compliance, because through effective IAM an organization is able to show who has or had access to what, why, when, and what they did with that access; it is a core principle of defense of important data;
  2. Data Protection: A data protection solution which achieves compliance with GDPR and covers the lifecycle of your company’s information, both in cloud and hybrid or private environments, helping to protect the most valuable asset: information;
  3. Mobility: A secure mobility solution designed to help companies manage and secure access to corporate information from anywhere, at any time and from any device;
  4. Risks and Security Management: A comprehensive and efficient managed security solution for security governance from strategic business units, to help you address the GDPR concept of continuous compliance, in which an organization must regularly carry out audits of compliance;
  5. AntiFraud: A comprehensive, convergent and adaptive solution based on the application of intelligence to detect digital fraud, both in advance and at the moment it is being committed;
  6. CyberThreats:  A solution which helps you continuously prevent, detect and respond to potential cyber-threats that can have a major impact on your organizations' business model, addressing therefore the adaptive security approach suggested by the NIS Directive;
  7. Vamps: A Persistent Vulnerability Assessment & Management solution to help you identify security threats and potential attack methods against your network and systems and allowing a quick management of their correction;
  8. Sandas: A behavioural analysis solution which categorizes and reports incidents and allows you to visualize that information, providing you with automatic responses in real time; and
  9. Sandas GRC: A Government, Risks and Compliance solution which helps you to support your business strategy, to increase your visibility of risk assessment and improve your operational performance, reduce operational risks and ensure regulatory compliance with NIS Directive and GDPR.

As the NIS Directive and GDPR will enter into force soon, time is running out to get your house in order. The timescale for achieving compliance is tight, and we think that organizations of any sizeable scale and complexity will struggle with even the first steps in compliance, such as understanding what information security technologies and procedures should be implemented, and what data they have and its sensitivity. Don't put off early consideration of NIS Directive and GDPR by the less than two-year implementation period. The scale, complexity, cost and business criticality of both legislation means that it will take (at least) two years for most companies to achieve full compliance. You need to start now.

Although both laws may require substantial investments for companies to reach compliance, both the NIS Directive and GDPR represent an opportunity for your Boardroom to re-build your security capabilities with a focus on better mitigating cyber risks, become cyber-resilience, and together create a safer digital world.

Pablo Alarcón Padellano, Alliances & Partnerships

1Arts. 14.1 and 16.1 of NIS Directive
2Arts. 25.1 and 32.1 GDPR
3Standardisation Art.19.1 NIS Directive
4Codes of Conduct Art. 40.2 h) GDPR
5The DPO is responsible for conducting regular audits of GDPR compliance, which means that firms will have to demonstrate their compliance on a regular basis. The DPO's job will be to watch over in an independent manner how data is stored, used and shared and to advise their organisation on data protection issues.