Security Awareness of MQTT

How secure is MQTT Protocol?

Abstract

The internet of things (IoT) has become a converging point for new developments in a variety of markets, such as transportation, home automation or even health. Such applications, are now the target for exploiting the weakness of many devices and protocols. For quote a few examples; recently, WikiLeaks disclose some documents which stated the use of TV for spy premises using audio and video in a fake standby mode; another dramatic example, is to control remotely a car with obscure intentions, including disable brakes, adjust sea belt or steering the wheels. In addition, there are evidence of using IoT devices as part of a DDos attack in October 2016, affecting big companies such as Twitter or Github.

On the other hand, there is a trend in the IoT development. The use of different of protocols, such as MQTT, CoAP, AMQP, LWM2M and XMPP are the most relevant at the moment. Consequently, is crucial to have an insight of the main protocol, weakness and strengths, and review the main drawbacks for future developments.

This document is intended to review the MQTT protocol as part of the new trend of the internet of things, analyse the architecture, uses cases, implementations and security insights.

I.     INTRODUCTION

The internet of things has been in development for decades, with different approaches for industrial automation, avionics and robotics, that have been focusing in similar targets, such as communication between machines, remote control and telemetry. Nowadays, such implementations are no longer just for the big companies’ domain; technology and embedded devices are more reachable for individuals than never before. Thus, engineers, scientists and enthusiastic people are developing new applications to solve daily common problems, using a number of protocols, techniques and approaches for M2M (machine to machine) solutions.

Reviewing several implementations of the internet of things, is possible to identify common scenarios and communication protocols used. The most relevant protocols by the date of issue this document are:

  • XMPP (Extensible Messaging and Presence Protocol) [1]
  • CoAp (Constraint Application Protocol) [2]
  • AMQP (Advanced Message Queuing Protocol) [3]
  • LWM2M(Light Weight Machine to Machine) [4]
  • MQTT (Message Queuing Telemetry Transport) [5]

As shown in the following figure, the interest since 2004 have changed. Is quite obvious the new trend within the IoT  ecosystem. MQTT has been rising up since 2010, point in time where it became royalty free, after being developed by Arlen Nipper and Andy Sandford-Clark at IBM in 1999 [6]. Documentation [7] states that MQTT was develop to reduce battery consumption, provide quality of end to end communication, real time delivery of data, light weight and simplicity for implementation.

Figure 1 Interest Over Time  IoT Protocols [8]

Due the simplicity of MQTT and well documented samples, the implementation is quite easy and straight forward. However, general public usually skip recommendations or specifications regarding security; consequently, there are implementations on the real market highly unsecure and poorly designed.

In the following chapters, there is a brief explanation of MQTT functionality, risk assessment and possible approaches for reduce the risk of security treats.

II.     LITERATURE REVIEW

The market has plenty of implementations based on MQTT, the most relies their own security following documentation guidelines [6] or using the technical documentation of the protocol [5].Both recognized vulnerabilities within the system, for instance, compromised devices, access to the servers, denial of service, man in the middle or spoofed packets. Depending of the context, where the implementation might be used, [5] it should be wise to recognize the need to use, mechanisms to enforce device authentication, access control to the server, integrity of packets and encryption for the messages transmitted. For instance, Advanced Encryption Standard (AES) and Data Encryption Standard (DES) are well accepted within the protocol, however there is a constraint for fully apply encryption to devices with low processing power. ISO29192 [9] have strong recommendation for implementing encryption techniques on constrain devices. In addition [5] provides full documentation for implement TLS/SSL , VPN and web sockets as measures for secure connections, having in mind possible overhead.

In contrast,  [10] recognize the overhead and proposed a light weight elliptic curve cryptography model, in order to be implemented in MQTT, showing positive outcome compared with similar implementations.

In terms of security, [11] exposed weakness of light weight protocols and real scenarios. Strongly recommending revise the configuration of the protocols , for authentication and the use of encryption, However, the drawback is the decrease od lifetime battery and process power.

III.     BACKGROUND

In July 2016 the International Organization for Standardization (ISO) , has released the final document for MQTT : ISO/IEC 20922:2016  [12]. The document specifies all details behind the protocol version 3.1.1 based on Oasis Standard [5].

In contrast to client server model, MQTT follows a particular pattern, called publish-subscribe pattern, namely the end point that is sending a message (Publisher) and the end point(s) receiving the message (Subscriber) are separated; thus, the publisher doesn’t know about the existence of one or more subscribers. In addition to the model, the management of the messages and the connection specs are covered by the Broker (server) as shown in the following figure.

 

Figure 2 MQTT model [6]

Due the decoupling of publisher and subscriber, there is no need that both are running at the same time, no need to know each other and no synchronization involved.

Regarding the message, it is possible to filter the content using “subject-based filtering”. Basically, the subject (topic) is a string expression with a hierarchical structure; hence, publisher can publish on that topic, and consequently subscriber will receive the content of the message related to this topic. Also, there are some other ways to filter such as content based and type filtering [5].

In terms of real implementation, it is needed a broker (server) and some clients(publisher-subscriber). MQTT client is usually referred as small devices with some limited micro processing capabilities (e.g. Arduino, Raspberry pi, ESP 8266, android), connected wired or wireless to the network. Such devices usually need to use additional libraries supported in the most used programming languages such as C,C++ ,Java, . NET etc.

In terms of the broker, is basically the core of the protocol. The entity responsible of dealing with publishers, subscribers, topics, authentication and manage quality and errors. There are plenty of open source options in the market [13], with some differences in terms of scalability and security. Note that it is possible to run private broker, but also is possible to use public brokers.

In general, is mandatory that broker and clients has TCP/IP stack in order to establish a connection. Each client (publisher/subscriber) should send a request to the broker (MQTT CONNECT);then, the broker will answer with a CONNACK and connection status.

The following figure, presents a sample of the connection message. Note, some of the fields are optional , it let the user to be more flexible in terms of the implementation, for example the authentication might be optional for simplicity.

Figure 3 MQTT CONNECT MESSAGE [6]

In response, the broker will maintain the connection if is successful. It sends back a packet with some result of the request and the status:

Table 1MQTT response

Return CodeReturn Code Response
0Connection Accepted
1Connection Refused, unacceptable version
2Connection Refused, identifier rejected
3Connection Refused, server unavailable
4Connection Refused, bad name\password
5Connection Refused, not authorized

Despite the freedom for implementation, there are some guidelines for naming the topics. As stated before, it is just a chain of characters. However, it is vital to know that topics, are case sensitive. Also, the documentation suggests naming devices in a logical order and hierarchy. For instance, due the protocol is intended for managing multiple sensors and actuators, probably related in term of location area. Thus, if there are temperature, humidity, light , CO2 sensors at kitchen, the right way to name them is:

Home/kitchen/sensor/temperature

Home/kitchen/sensor/humidity

Home/kitchen/sensor/light

Home/kitchen/sensor/CO2

Note, how logically organized could be, and scalable in term of massive implementation. In addition, could be possible to use “wildcards”. Basically for subscribing can be used symbols like plus sign“+” or sharp symbol “#”, for concatenate subscribed topics, or for subscribe all topics in the same section(/), respectively. The following sample, represent the usability of the wildcards, for subscribe topics easily.

 

Figure 4 Wildcards Sample [6]

 As agreement between the publisher and the subscriber, there are three possible way to deal with the quality of the service (QoS): at most One, at least one and exactly one. In terms of reliability, is noteworthy to analyse deeply the conditions of each QoS. QoS 0 (at most once) is basically send the message no matter if is received for some client or not, also it will not be stored in the broker or device for later delivery .QoS 1(at least one),it will guarantee that the message will be received at least one time but if there are more subscribers it will be delivered as well, the system will provide a notification message that the message has been delivered. QoS 2 (exactly once) it assure that the message will be delivered , even if the subscriber is not online, the broker will keep the data until subscriber is connected.

A.     MQTT APPLICATIONS

It is vital to refer to real uses cases to infer the applicability of a protocol. As follows, there are some samples of real implementation from well know companies to experimental implementations.

  • IBM Applications:

From 1999 to 2010 IBM had the royalty of MQTT, thus through this years, the company stated the use of MQTT in applications on several sciences including, automated metering (oil, petroleum), retails distribution chain(tracking),waste management, aerospace, defence and also banking. [14]

  • Facebook Messenger:

Back in 2012, Facebook changed all the messaging application, introducing the new Facebook messenger. The new app was intended to reduce battery consumption and optimize the use of the bandwidth, all done due the new implementation of MQTT as foundation of the app [15].

  • Home Automation:

Maximus IoT, is a prototype for sense and control appliances at home. Basically, was designed for supporting and help elderly users when accidents occur [16].

Figure 5General Model MAX IOT [16]

The system had sensors, interfaces and actuators in order to monitor and control the house. Some of the sensors where connected to the MQTT broker using wireless gateways (ESP8266). In addition, deploying a universal windows platform application (UWP), a single piece of software was replicated on several interfaces, such as tablets, mobile or wall interfaces; all connected to the MQTT broker.

 

Figure 6 MQTT monitor Elderly accidents [16]

 All the units have the capabilities of listening commands; thus, if the user fall down and was not able to reach some device, the user speak to the device for call and ambulance, also sending alert emails and twits. In summary, the protocol lets the system group several devices using topics, for sending and receiving data out of the premises and process data locally.

  • Location Services:

One of the most used cases is tracking objects using GPS (Global Positioning System). Usually the GPS is connected to a processor with network capabilities. The following figure shows how a mobile device can send location via MQTT, in order to be presented in device map.

 

Figure 7GPS over MQTT

  • Telemetry Implementations:

The following pictures are the prototype for a remote weather station unit. The unit provides a touch screen interface, that represent real time measurements sent to the MQTT broker for be processed.

Figure 8Telemetry Station (interface)

The device has GSM network module that give to the unit the possibility to send and receive data from the MQTT broker.

Figure 9 Telemetry Station (GPS, GSM Network)

The unit is capable to attach several sensors and devices, such as GPS or  CO2 and temperature sensors.

  • Arduino – Mobile Control:

The following figure is a prototype, for controlling high voltages devices (240VAC), the design is based on a processor with wireless capabilities (ESP8266). Such processor can be programmed as any other Arduino hardware; thus, it is possible implement an MQTT client, which is subscribed to four topics. Every output of the module is digital, consequently the ESP8266 will be able to trigger the relay module, and turn on – off devices, such as lights , heaters, blinds, fan etc.

Figure 10 Relays 220VAC – Control  over MQTT

With 32-bit processor, and 64KB of RAM, is powerful enough for maintain connection and perform some process. However, for complex process the performance might not be so sharp.

IV.     RISK ASSESMENT

The baseline scenario for review, is quite generic but the purpose is clear, find some of the noticeable weakness for implement MQTT protocol.

Scenario Description:

Based in the background specs and some guidelines for implementation. The scenario is described by public brokers [17] :

  1. hivemq.com (port 1883).
  2. mqttdashboard.com (port 1883).
  3. eclipse.org (port 1883).
  4. mosca.io (port 1883).

In addition, the assumption of having access to the local area network will be advantage, for the second part of the exploit (Case 2). The configuration is the basic one, with no authentication or encryption.

It is worth to state, that public brokers suggest to the users, avoid publishing sensitive information:

“Testing and usage is for free but please do not use it for sensitive information because everybody is allowed to subscribe to every topic, including wildcard…” [18]

  

Target:

 

  1. Catch topic information, and details, including the message payload.
  2. Catch local area network packets, related to MQTT, and reveal the payload, for subscribers and publisher.

A.     CASE 1:

Tool:

After reviewing and trying several times public brokers, it is quite obvious to think, the possibility of more than one user of the system at the same time. Thus, it is needed to revise the documentation for a secure connection. [19].

The following python script , describes a basic connection to the broker: “test.mosca.io”, using the standard port 1883; in addition the client is subscribed to (#) all the topic in the root of the broker. Consequently, the script will be able to print into console all the running topics, no matter user id, QoS.

Figure 11 Python script sample

Additional to the script, it is needed another client for subscribe to interesting topics, and gather some data, one of the best tools available is a plugin of Google Chrome: MQTTLens [20], which is reliable and easy to use.

Findings:

The result is an endless list of topics, usually using hierarchy(/). Therefore, is easier to use wildcard on the interesting ones and catch some information.

As follows, there are a few samples of the findings.

  1. Topic: tms/#

Message Payload: it is interesting how can users send plain data, without encryption. Thus, information such as location could be cached easily, and using similar techniques map information with real scenarios.

 

Figure 12JSON response at msg payload

For example, the user send a detail location, in this case it seems a government building as testing, but could be and house of a singular user.

Figure 13 Real Location

  1. Topic: tchblinds/blinds/#

Probably this the common use of MQTT protocol. Read and update status of some object, as shown in the following figure.

Figure 14 Topic WildCards #

Using wildcard is really easy to catch, all the topics of the user, such as “command” and “state”. The user is sending a command “open” and reading some sensor, as real state of the object. At this point, is relevant to thinks about how can the user might be affected if the topic payload change to “close”.It will change the state of a real blind at some home? Who will be affected? Etc.

  1. Topic: com.amgadiot.mqtt

The topic name might be call the attention because “EEPROM” basically is a memory usually registering useful data for industrial applications; in addition to the name might describe an “organization”.

Figure 15 MQTT response

After be subscribed to the topic, the first received message might define a username and password for some serial communication (amgad,amgadiot,9600), or maybe other MQTT authentication.

It is interesting, how easy can be to locate the user. It seems there is a company with the same name located in Egypt with a profile in Linkdin and a website with an email :

Street 270, El-Basatin Sharkeya Al Maadi Al Maadi, Cairo Egypt

 

Figure 16 https://www.linkedin.com/company/amgad-iot

  1. Topic: com.amgadiot.mqtt

Relieved knowing that is just a test. However, if the user is testing, might suggest that real implementation could be the next step. Note, again how a wrong design might compromise client sensitive information.

  1. Topic: user/home/config

The following sample, describes a Json response of the topic. External user might not know the architecture of the design. But if the user send a complete structure of the data, will compromise all the system. Note, two of the topics are thermostats, in a real scenario of an attacker could play with the value, and might cause real damage in a property or even affect people safety.

 

Figure 18 JSon Script Payload

  1. Interesting topic names:

Analysing the list of topics, can be shocking to think about the power of such information: For instance:

  • feed/broker/ctrader-bitcoin-kawase-1
  • /30c216b0ed/1/door
  • /Eerip/heartbeat
  • /cc3200/Motor3/Volt
  • /Garage2/Relay1/Switch
  • $SYS/broker/connection/lobang.net.public/state
  • /madarco-casa/sensor/motor/temp
  • tchblinds/blinds/command
  • tchblinds/blinds/state
  • client_info
  • satya@satya.com/Temperature
  • tms/loc/clients/WhgycSddGMjyxrDPEh

Note, that some users just choose topics as exploit clues, such as bitcoin, client_info, garage, heartbeat, door etc.

B.     CASE 2:

In terms of publishing and subscribing within a LAN, using a comoon tool for catching packages (wireshark) was possible to verify the content of each of the publisher/subscriber packages.

The followin figure describes the pakage of a subscription outside the LAN, notice how simple is to reach the data; in plain text is possible to gather the topic and the message.As well is possible to gather data from a publisher client, very similar human readable with no extra efforts.

In a real scenario, maybe a big company or industry;the flow of data would be easy to get and understand, for exploiting sending wrong information, copy the useful data or promote a malfunction of the system.

Figure 19 Wireshark packets

V.     RECOMMENDATIONS

The main concern of information security is to enforce the triad: confidentiality, integrity and availability of all asset within a system. Therefore, it is noteworthy to follow frameworks [21] [22] that involves the ecosystem of MQTT.

Note, before the assessment of the scenario, it is important to understand the context, where there are no details for individual implementations, therefore the recommendation will be generic, based on the exploit findings and MQTT documentation [22], rather than present the output of such recommendations.

The framework [21] used, promotes the assessment in five steps: Identify, Protect, Detect, Respond, and Recover. All disclosed as follows.

A.     Identify:

1)     Asset Management:

For every use case or scenario, it should be listed every piece of hardware used to perform certain task, analyse the network structure, and understand the data flow and lifecycle of the information.

For instance in our scenario, must describe the broker, the network specs (gateway, LAN, firewall, filters), the client assets (IoT devices).

2)     Risk Management

Vital to define the threats and vulnerabilities for each asset, thus is conceivable a well-defined risk tolerance, risk identification, and assess the alternatives.

3)     Compliance

It is imperative to review the business model with the business requirements; thus, changes in the system will not affect negatively the operation and any other requirement or regulation such as contractual, legislative or even ethical.

A good example of this compliance identification step, is to carefully manage the privacy rights and confidentiality of the data involved in the process. The contract should clarify, how the data will be used or stored and the reason to do it.

4)      Information Sharing and Communication

At this stage, the flow of the information and the asset that manage it should be reviewed.

For instance, in the scenario, the public broker is not suitable for privacy data flow, it is accessible for multiple users without notice. In addition, regarding private brokers, it should be considered monitoring not expected  remote and local access to the network, because is possible the man in the middle attacks.

5)     Environmental Awareness

Server and client side locations should be revised, as well as all the facilities including gateways, wiring. Assessing the vulnerabilities of the entire ecosystem will underline the possible risks.

Usually, IoT devices are not designed to protect the data, in contrast those are designed to be cheap and reliable with some sort of connectivity. Thus, the vulnerability might be wide open for attack. It should be a “must” to protect the serial port of each one of this devices (debugging port) , otherwise the attack could start by connecting a serial console to the device read the code, and easily exploit the entire system.

Likewise, the broker (server) should be protected. Assuming the system is password protected, nowadays there are techniques that involve a usb port for exploit the machine. Basically, the usb dongle mocks a keyboard (USB Rubber Ducky), hence simulating it is a real keyboard, then accessing to the console, and inject payload as a “write” commands for install remote access , or create user etc.

B.     Protect:

1)     Security Awareness

Is well know for security professionals [23] ,the weakest point within an organization: people. The importance of training is remarkable. Formal training, simulation and evaluation should be active part of the security plans.

2)     Identify, credential and Access management

Technical support is essential for success at this stage. Implementation plans for new secure approaches, such as encryption, certificates, tokens generators, authentication and new communication channels such as secure web sockets and VPN. Note, that every changed should be revised against business model and constraints of the devices.

3)     Information Protection

Revise the protection of the packages sent and received, as well the integrity of the broker.

Evaluate the store procedures for all databases.

4)     Server Side Protection

Revise compliance with ISO2922 specification and procedures, best practices for encrypt messages and maintain secure links between client and broker.

The broker should have suspicious behaviour, block remote access, and negotiate safely new connections (availability).

5)     Client Side Protection

The key management should be the priority, for storage accordingly to the standards .

C.     Detect:

Detection plays a main role to enforce the information security of the system. Mainly focused in performer activities to identify incidents that might affect the security of the entire organisation.

1)     Network ,Physical, Intrusion Monitoring:

The system should be able to monitor repeated attempts to connect to the broker, smart revising for logs and fail connections packets; also, reviewing unexpected and irregular end of connections.

D.     Respond :

Within the risk assessment, prioritized activities should be reviewed, in order to proceed correctly when the event of a data breach or any other attack kind occurs.

1)     Response Planning:

Locate all compromised assets within the system, should be the priority, in addition to protect the un compromised ones. Hence, revoke clients, users, certificates and suspicions connections, blocking all the channels that might be compromised. If is needed shut down the broker and servers for corrective maintenance.

Document all the failure, revise the entire policy accordingly, for investigate and deliver all compliance policies, with the security board or law enforcement organizations.

E.     Recover:

Within the risk assessment, it should be revised, strategic plan to restore the system to the normal state, after an attack.

1)     Recover planning:

The system recovery need to be done programmatically, organized hierarchy to guarantee a fully functional system as outcome. Full inspection of all assets, review of firewall and any other instance that could be compromised, including the back up. Reissue authentication procedures.

After a functional system, it should be revised and update all the procedures and recovery strategy.

VI.     CONCLUSION AND FUTURE WORK

The outcome of revising a system from a different perspective such as researcher, technological or penetrator tester, is a rich insight of the importance of documentation within a technology, as well as how vital is to development an accurate information security policy using adequate frameworks, in order to cover the full picture of the system.

MQTT has remarkable potential, with multiple applications within internet technologies. Hence, the market is showing the importance for such protocols, that enable constraint devices to be connected using simple structures in a cost-effective way. Therefore, is a responsibility for researchers and enthusiast to address the need of the market, applying MQTT as main use case for improving the weak points for the new internet of things.

VII.     References

[1]Xmpp.org, “An Overview of XMPP,” Xmpp.org, 2017. [Online]. Available: https://xmpp.org/about/technology-overview.html. [Accessed 09 05 2017].
[2]C. Bormann, “CoAP RFC 7252 Constrained Application Protocol,” TZI, 2014. [Online]. Available: http://coap.technology/. [Accessed 09 05 2017].
[3]D. I. S. Robert Godfrey, “OASIS Advanced Message Queuing Protocol,” 29 10 2012. [Online]. Available: http://docs.oasis-open.org/amqp/core /v1.0/amqp-core-complete-v1.0.pdf. [Accessed 09 05 2017].
[4]O. M. Alliance, “Light Weight M2M,” OPEN MOBILE ALLIANCE, 2017. [Online]. Available: http://openmobilealliance.org/iot/lightweight-m2m-lwm2m/. [Accessed 09 05 2017].
[5]R. G. Andrew Banks, “MQTT Version 3.1.1,” 18 05 2014. [Online]. Available: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/csprd01/mqtt-v3.1.1-csprd01.pdf. [Accessed 09 05 2017].
[6]HIVEMQ, “MQTT Essentials: Part 1 – Introducing MQTT,” 2015. [Online]. Available: http://www.hivemq.com/blog/mqtt-essentials-part-1-introducing-mqtt. [Accessed 09 05 2017].
[7]IBM, “#9 Extending the reach of business agility – connecting people, places and things,” [Online]. Available: https://www-01.ibm.com/software/websphere/ connectivity/integration/podcasts/. [Accessed 09 05 2017].
[8]Google, “Google Trends: Interest Over time,” 09 05 2017. [Online]. Available: https://trends.google.co.uk. [Accessed 09 05 2017].
[9]I. O. f. Standardization, “ISO/IEC 29192-1:2012,” International Organization for Standardization, 2012.
[10]R. M. ,. S. V. ,. B. P. Meena Singh, “Secure MQTT for Internet of Things (IoT),” in Fifth International Conference on Communication Systems and Network Technologies, 2015.
[11]L. Lundgren, “Light Weight Protocol Critical Implications,” 13 02 2017. [Online]. Available: https://www.rsaconference.com/writable/presentations /file_upload/ hta-r03-light- weight-protocol-serious- equipment-critical-implications.pdf. [Accessed 09 05 2017].
[12]I. O. f. S. ISO, “ISO/IEC 20922 : 2016 Information technology Message Queuing Telemetry Transport (MQTT) v3.1.1,” 06 2016. [Online]. Available: https://www.iso.org/standard/69466.html. [Accessed 09 05 2017].
[13]MQTT.org, “brokers,” 23 03 2017. [Online]. Available: https://github.com/mqtt/mqtt.github.io/wiki/brokers. [Accessed 09 05 2017].
[14]J. G. P. R. V. D. G. G. K. Bryan Boyd, “Building Real-time Mobile Solutions,” International Business Machines Corporation , 2014.
[15]L. Zhang, “Building Facebook Messenger,” 12 08 2011. [Online]. Available: Building Facebook Messenger. [Accessed 09 05 2017].
[16]M. Silva, “Modular Home Smart Assistant for Elderly People “MAXIMUS IoT”,” Glyndŵr University, London, 2016.
[17]S. Mauricio, “LIST FREE MQTT PUBLIC BROKER,” redmaurosilva.com, 06 11 2016. [Online]. Available: http://redmaurosilva.com/list-mqtt-public-broker/. [Accessed 09 05 2017].
[18]HiveMQ, “MQTT Dashboard,” HIVEMQ, [Online]. Available: http://www.mqtt-dashboard.com/. [Accessed 09 05 2017].
[19]R. Light, “paho-mqtt 1.1,” http://eclipse.org/paho, [Online]. Available: https://pypi.python.org/pypi/paho-mqtt/1.1. [Accessed 09 05 2017].
[20]Sandro-k, “MQTTLens Chrome App,” Sandro-k, 03 08 2016. [Online]. Available: https://github.com/sandro -k/MQTTLensChromeApp. [Accessed 09 05 2017].
[21]N. I. o. S. a. Technology, “Framework for Improving Critical Infrastructure Cybersecurity,” National Institute of Standards and Technology , 2014.
[22]R. J. C. B. Raphael J Cohn, “MQTT and the NIST Cybersecurity Framework Version 1.0,” OASIS Open, 2014.
[23]E. Savitz, “Forbes,” 03 11 2011. [Online]. Available: https://www.forbes.com/sites/ciocentral/2011/11/03/ humans-the-weakest-link-in-information- security/#1ba128bede87. [Accessed 09 05 2017].

Mauricio Silva

Leave a Reply