Author: Parnashree Saha

Reading Time : 10 minutes

In the world of information technology, change is constant. Technology evolves rapidly, so businesses must adapt to keep up with the latest advancements. One area that often requires attention is the management of digital certificates, which play a vital role in ensuring secure communications and data integrity. If your organization’s Microsoft Certificate Authority (CA) runs on Windows Server 2012 and 2012 R2, it’s time to start thinking about a migration strategy as soon as possible.

Microsoft will stop supporting windows server 2012 and 2012 R2 on 10^th Oct 2023. Microsoft will discontinue offering bug fixing, technical support, or any new problem that can affect the reliability or usability of servers.

How Serious Is the Risk?

Using Windows Server 2012 and 2012 R2 comes with several risks due to the operating systems reaching the end of their supported lifecycle. These risks can have serious implications for organizations, as this risk leads to being subject to compliance issues and cyber attacks. The environment using unsupported servers will be the prime target for the bad guys. Without an upgrade strategy, the organization’s IT parties and management will be responsible for the jeopardy posed by unsupported servers.

Here are some of the key risks associated with using Windows 2012 and 2012 R2:

• Security vulnerabilities

  As operating systems age, security vulnerabilities are discovered, and cybercriminals actively exploit them. Over time, the risk of security breaches and unauthorized access to your systems increases significantly. Without regular security updates and patches from Microsoft, any newly discovered vulnerabilities will remain unaddressed, exposing your system to potential attacks.

• Lack of support

  When an operating system reaches its end of support, Microsoft no longer provides technical support or assistance for issues related to that version. This lack of support means that if you encounter any problems or face challenges with your Windows 2012 or 2012 R2 servers; you won’t be able to rely on Microsoft for help. This can lead to prolonged downtime, increased costs, and difficulty resolving critical issues.

• Compliance violations

  Many industry regulations and standards, such as PCI DSS, HIPAA, and GDPR, require organizations to use supported software and regularly apply security updates. By running unsupported operating systems, you risk non-compliance with these regulations, which can result in penalties, legal liabilities, and damage to your organization’s reputation.

• Limited feature enhancements

  With the end of support, there will be no new feature updates or enhancements for Windows 2012 and 2012 R2. This means you won’t benefit from the latest functionalities, improvements, or performance optimizations available in newer operating systems. Staying on outdated platforms can hinder your ability to leverage modern technologies and advancements that can drive efficiency and productivity.

• Incompatibility with new software and hardware

  As software and hardware vendors release updates and new products, they increasingly focus on compatibility with the latest operating systems. Over time, you may encounter compatibility issues when installing or running newer software or hardware on Windows 2012 or 2012 R2. This can limit your ability to adopt new technologies and take advantage of the latest features and capabilities. For Example: Integration of Windows Hello.

The seriousness of these risks should not be underestimated. Running an unsupported operating system puts your organization’s security, stability, and compliance at significant risk. As time progresses, the risks associated with using Windows 2012 and 2012 R2 will only increase as cyber threats evolve and unsupported systems become more susceptible to attacks.

Planning and executing a migration to a supported operating system version on time is essential to mitigate these risks. This ensures that you can continue to receive security updates, access technical support, and maintain compliance with industry standards, while also taking advantage of the latest features and improvements offered by modern operating systems.

Is this the right time to assess your PKI needs?

Since we are at a forced decision point, it may be the right time for you to assess the current PKI environment and strategies to enhance your overall PKI infrastructure. Asking the right questions will help you understand your PKI environment’s as-it-is and as-to-be state

To understand your organization’s approach to PKI (Public Key Infrastructure), it’s essential to ask the right questions. These questions will help you assess your current PKI architecture and make informed decisions about its future. Consider the following inquiries:

1. Is it advisable to retain your existing PKI architecture, or would it be more beneficial to migrate?
2. Have there been any changes in business use cases since the initial deployment of your PKI?
3. Does your Microsoft PKI adequately support the evolving demands of PKI use cases?
4. Are you familiar with your PKI architecture’s specific components and state, including its infrastructure, certificates, and dependencies
5. Should you explore the adoption of cloud-based PKI or PKI-as-a-Service solutions?
6. Have you conducted thorough testing of your migration plan?
7. Have you developed a contingency plan in the event of issues during the migration process?

By asking these pertinent questions, you’ll gain insights into your organization’s PKI landscape, identify areas for improvement, and make informed decisions regarding the future of your PKI architecture.

Steps to prepare for the migration:

To ensure your organization’s continued security and compliance, it’s crucial to migrate your Microsoft CA from Windows Server 2012 R2 to a supported platform. Here are some steps you can take to prepare for the migration:

1. Assess your current environment

   Begin by evaluating your existing CA infrastructure. Understand the scale of your certificate operations, including the number of certificates issued and the dependencies on the current CA. Identify any custom configurations or integrations that may need to be considered during the migration.

2. Select a target platform

   Determine which version of Windows Server you plan to migrate to. Windows Server 2019 or the latest version available during migration are recommended choices. Evaluate each version’s features, compatibility, and support lifecycle to make an informed decision.

3. Plan the migration process

   Develop a detailed migration plan outlining the steps, potential risks, and timelines. Consider factors such as downtime requirements, certificate validity periods, and communication with stakeholders. To ensure a smooth transition, engage key stakeholders, including IT personnel, security teams, and application owners.

4. Test the migration in a lab environment

   Before performing the actual migration, set up a test environment to simulate the migration process. This allows you to identify and address any potential issues or conflicts before migrating your production CA.

5. Perform the migration

   Once you’ve completed thorough testing, execute the migration plan in your production environment. Follow best practices provided by Microsoft or seek assistance from qualified professionals to ensure a successful migration.

6. Validate and monitor

   After the migration, validate the functionality of your new CA infrastructure. Test certificate issuance, revocation, and renewal processes to ensure everything is functioning.

How Encryption Consulting Can help your PKI Migration Journey  

Migrating your Public Key Infrastructure (PKI) can be complex, requiring careful planning and execution to ensure a smooth transition. In such situations, seeking assistance from a reputable Encryption Consulting firm can greatly benefit your PKI migration journey. Let’s explore how Encryption Consulting can help facilitate a successful migration process:

1. Expertise and Experience

   Encryption Consulting firms specialize in cryptographic solutions, PKI, and encryption technologies. We have extensive experience in designing, implementing, and managing PKI infrastructures. Our expertise allows them to assess your organization’s specific requirements, identify potential challenges, and provide tailored solutions that align with industry best practices.

2. Comprehensive Assessment

   Encryption Consulting can comprehensively assess your existing PKI architecture. We analyze the current state, evaluate its effectiveness, identify any vulnerabilities or inefficiencies, and provide recommendations for improvement. This assessment ensures that your migration plan is based on a thorough understanding of your PKI’s strengths and weaknesses.

3. Migration Strategy and Planning

   Encryption Consulting can assist in formulating a migration strategy and creating a detailed plan tailored to your organization’s unique needs. They consider factors such as infrastructure dependencies, certificate lifecycles, compatibility issues, and downtime requirements. By leveraging their expertise, you can develop a well-structured migration roadmap that minimizes disruptions and ensures a seamless transition.

4. Vendor Evaluation and Selection

   Choosing the right vendors and technologies is critical during PKI migration. Our team can help you evaluate different vendors, assess their solutions, and select the most suitable options for your organization. We have insights into the latest industry trends and can guide you in making informed decisions regarding hardware, software, or cloud-based PKI solutions.

5. Implementation and Configuration

   Encryption Consulting play a vital role in implementing your PKI migration plan. We have the technical expertise to set up and configure the new infrastructure, ensuring compatibility with existing systems and applications. You can avoid common pitfalls and ensure a successful implementation by leveraging our knowledge.

6. Testing and Validation

   Encryption Consulting conducts rigorous testing and validation processes to ensure the migrated PKI infrastructure operates as intended. They verify certificate issuance, revocation, and renewal processes and validate interoperability with various systems and applications. This meticulous testing minimizes the risk of potential issues and ensures the stability and functionality of the new PKI environment.

7. Training and Support

   Encryption Consulting provides training and support services to enable your organization’s IT staff to effectively manage the newly migrated PKI environment. We offer guidance on operational procedures, best practices, and ongoing maintenance tasks. This empowers your internal team to handle day-to-day PKI operations confidently.

8. Continuous Monitoring and Maintenance

   PKI requires ongoing monitoring and maintenance to ensure its optimal performance and security. Encryption Consulting can provide continuous monitoring services to proactively identify and resolve any issues, monitor certificate validity, and implement necessary updates and patches. This helps to maintain the integrity and reliability of your PKI infrastructure.

Conclusion

Encryption Consulting brings invaluable expertise, experience, and specialized knowledge to your PKI migration journey. Their comprehensive assessment, strategic planning, implementation support, and ongoing maintenance services can significantly streamline the migration process and mitigate risks. By partnering with  Encryption Consulting LLC, you can confidently navigate the complexities of PKI migration and achieve a secure and efficient PKI infrastructure for your organization.

FIPS 140-3 is a U.S. government standard specifying security requirements for cryptographic modules, including hardware and software components. These security requirements are designed to ensure that cryptographic modules provide a minimum level of security for protecting sensitive information and transactions.

Some of the key security requirements specified in FIPS 140-3 include the following

1. Cryptographic module specification

   A detailed specification of the cryptographic module, including its physical and logical boundaries, interfaces, and security functions.

2. Roles and services

   A definition of the roles and services provided by the cryptographic module, including key management, encryption, and authentication.

3. Cryptographic algorithms

   A list of approved cryptographic algorithms that can be used by the cryptographic module, along with specific requirements for key length, block size, and other parameters.

4. Key management

   Requirements for generating, storing, and protecting cryptographic keys, including key lifecycle management and destruction.

5. Physical security

   Requirements for physical security measures to protect the cryptographic module from unauthorized access, tampering, and theft.

6. Logical security

   Requirements for logical security measures to protect the cryptographic module from attacks such as malware, side-channel attacks, and unauthorized access.

7. Security testing and validation

   Requirements for testing and validating the security of the cryptographic module, including vulnerability testing, penetration testing, and compliance testing.

General requirements for each level of FIPS 140-3

The below table explains the general requirements for each level of FIPS 140-3

Table 1: General requirements of FIPS 140-3 for each level

These are the general requirements for each level of FIPS 140-3. However, there are many specific requirements for each level, and the requirements for each level are quite detailed. The purpose of the standard is to provide a framework for evaluating and certifying the security of cryptographic modules. The specific requirements for each level are designed to ensure that the module provides a certain level of protection against various attacks.

FIPS 140-3 Security requirements for each level

FIPS 140-3 is a security standard defining the requirements for cryptographic modules that protect sensitive data.

FIPS 140-3 Level 1

Level 1 of FIPS 140-3 provides the lowest level of security and is intended for use in low-risk applications. The security requirements for level 1 are as follows

1. Cryptographic module specification

   The module must have a concise specification describing its cryptographic functions, interfaces, and protocols.

2. Roles, services, and authentication

   The module must define the roles, services, and authentication mechanisms required for secure operation.

3. Physical security

   The module must have physical safeguards to protect against unauthorized access, theft, or tampering

4. Design assurance

   The module must have undergone a comprehensive design process, including security analysis and testing.

5. Mitigation of attacks

   The module must have measures to prevent or mitigate attacks, such as software or hardware countermeasures

6. Self-tests

   The module must perform self-tests to ensure it is functioning correctly and detect tampering attempts

7. Environmental design

   The module must be designed to operate in various environmental conditions, including temperature, humidity, and electromagnetic interference.

8. Cryptographic key management

   The module must have secure key management processes to ensure that cryptographic keys are generated, stored, and used securely.

FIPS 140-3 Level 2

Level 2 of the FIPS 140-3 standard outlines the security requirements for a cryptographic module that provides moderate security assurance. The following are the specific security requirements for a cryptographic module to achieve FIPS 140-3 level 2

1. Physical security

   The module must be physically protected against unauthorized access, tampering, and theft. It should be designed to withstand environmental hazards like fire, water, and electromagnetic interference.

2. Cryptographic key management

   The module must have strong key management mechanisms that ensure cryptographic keys’ confidentiality, integrity, and availability. The module should protect keys against unauthorized access, modification, and destruction

3. Authentication and access control

   The module must authenticate users and restrict access to authorized users only. It should have strong password policies and mechanisms to prevent brute-force attacks.

4. Audit logging and reporting

   The module must log all security-related events and provide reports to authorized users. The module should also have mechanisms to protect audit logs against tampering or destruction.

5. Software security

   The module must be designed with secure software practices that minimize the risk of security vulnerabilities. The software should be tested for security flaws and vulnerabilities and undergo regular security updates and patches.

6. Communication security

   The module must use secure communication protocols and encryption to protect data in transit. The module should also have mechanisms to prevent unauthorized access to data transmitted over networks.

7. Cryptographic algorithms

   The module must use approved cryptographic algorithms and standards that NIST has validated. The module should also have mechanisms to prevent using weak or outdated cryptographic algorithms.

FIPS 140-3 Level 3

Level 3 of the FIPS 140-3 standard protects against unauthorized cryptographic module access and sensitive information. It is also the third-highest level of FIPS 140-3. The following are the security requirements for level 3

1. Physical Security

   The cryptographic module must be physically protected against unauthorized access, tampering, theft, and damage. The module must also be designed to resist physical attacks, such as drilling, cutting, and probing. The module must be in a secure facility with access controls, video surveillance, and intrusion detection systems.

2. Cryptographic Key Management

   The cryptographic module must have a strong key management system that ensures the secure generation, storage, distribution, and destruction of cryptographic keys. The key management system must use strong cryptographic algorithms, such as Advanced Encryption Standard (AES), and have key backup, recovery, and destruction mechanisms.

3. Cryptographic Operations

   The cryptographic module must perform cryptographic operations securely and reliably. The module must use approved cryptographic algorithms and protocols, such as Transport Layer Security (TLS), Secure Sockets Layer (SSL), and IPsec. The module must also have error detection and correction mechanisms and handle cryptographic exceptions and failures.

4. Self-Tests and Tamper Evidence

   The cryptographic module must have self-tests and tamper-evidence mechanisms that detect and prevent unauthorized modifications, tampering, or substitution of the module’s hardware or software. The self-tests must be run periodically and must include checks for the integrity and authenticity of the module’s firmware, hardware, and software.

5. Design Assurance

   The cryptographic module must have a strong design assurance that ensures the module’s security requirements are met throughout the module’s lifecycle. An independent third-party evaluator must review and verify the module’s design. The module must be tested against a set of security requirements defined in the FIPS 140-3 standard. The design assurance also requires using secure coding practices, security testing, and security documentation.

6. Security Management

   The cryptographic module must have a strong security management system that includes policies, procedures, and controls for managing the module’s security risks. The security management system must include mechanisms for auditing, monitoring, reporting security events, and responding to security incidents and vulnerabilities.

   FIPS 140-3 level 3 provides strong protection against physical and logical attacks and requires a high level of key management, cryptographic operations, self-tests, tamper evidence, design assurance, and security management. The security requirements for level 3 are designed to protect sensitive information and maintain the integrity and availability of the cryptographic module.

FIPS 140-3 Level 4

Level 4 is the highest level of security defined in the standard and is intended for applications where the consequences of a security failure are severe. The following are the key security requirements for FIPS 140-3 Level 4

1. Physical Security

   The cryptographic module must be housed in a tamper-evident, ruggedized container designed to resist physical attacks, such as drilling, cutting, or punching. The container must also have sensors to detect unauthorized access and trigger alarms.

2. Cryptographic Key Management

   The module must have a strong, verifiable, and auditable key management system that ensures cryptographic keys’ secure generation, storage, distribution, and destruction. The module must also support key revocation and recovery.

3. User Authentication

   The module must have a robust and secure user authentication mechanism, such as biometric or smart card-based authentication, to ensure only authorized personnel can access the module.

4. Logical Security

   The module must have robust logical security mechanisms to prevent unauthorized access, tampering, or manipulation of the cryptographic module or its data. This includes secure boot, secure firmware updates, and secure communications protocols.

5. Environmental Controls

   The module must operate in various environmental conditions, such as extreme temperatures, humidity, and electromagnetic interference. The module must also be able to withstand power surges and disruptions.

6. Life Cycle Support

   The module must have a comprehensive life cycle support mechanism that includes regular security updates, vulnerability assessments, and secure disposal procedures

   Overall, FIPS 140-3 Level 4 defines the highest level of security for cryptographic modules, and it is intended for applications where the consequences of a security failure are severe. The standard defines strict security requirements in physical security, cryptographic key management, user authentication, logical security, environmental controls, and life cycle support to ensure the highest level of protection for sensitive data and systems.

Requirements of Cryptographic algorithms for each level of FIPS 140-3

The FIPS 140-3 standard outlines four security levels (Level 1-4), each specifying a different set of requirements for cryptographic algorithms

Here are the cryptographic algorithms required for each level

• Level 1

  This is the lowest level of security, requiring only basic encryption and key management functions. The cryptographic algorithms required for this level include AES (128-bit), Triple-DES (112-bit), and SHA-1.

• Level 2

  This level requires additional physical security features to protect against tampering or unauthorized access to the cryptographic module. The cryptographic algorithms required for this level include AES (128-bit and 192-bit), Triple-DES (168-bit), SHA-2 (256-bit), and HMAC.

• Level 3

  This level requires the highest level of physical security to prevent unauthorized access and protect against attacks. The cryptographic algorithms required for this level include AES (256-bit), RSA (2048-bit), ECDSA (224-bit), SHA-2 (384-bit), and HMAC (with keys of at least 128 bits).

• Level 4

  This is the highest level of security, requiring the most stringent physical and logical security features to protect against sophisticated attacks. The cryptographic algorithms required for this level include AES (256-bit), RSA (3072-bit), ECDSA (384-bit), SHA-3 (512-bit), and HMAC (with keys of at least 256 bits).

Conclusion

In summary, FIPS 140-3 has been approved and launched as the latest standard for the security evaluation of cryptographic modules. It covers a large spectrum of threats and vulnerabilities as it defines the security requirements starting from the initial design phase leading towards the final operational deployment of a cryptographic module. FIPS 140-3 requirements are primarily based on the two previously existing international standards ISO/IEC 19790:2012 “Security Requirements for Cryptographic Modules” and ISO 24759:2017 “Test Requirements for Cryptographic Modules”.

The FIPS 140-3 standard provides a framework for ensuring the security of cryptographic modules used in sensitive applications such as banking, healthcare, and government.

To know more about FIPS 140-3 read : Knowing the new FIPS 140-3

Read time: 5 minutes

What is an IoT device?

Before we jump into the issues and challenges, let’s get a better idea of IoT devices. Devices that have a sensor attached to it and transmit data from one object to another or to people with the help of the Internet is known as an IoT device.IoT devices are wireless sensors, software, actuators, and computer devices. An IoT device is any device that connects to a network to access the Internet, so Personal Computers, cellphones, speakers, and even some outlets are considered IoT devices. Today, even cars and airplanes use IoT devices, meaning if these devices are attacked by threat actors, then cars or airplanes could be hijacked or stolen. With such widespread use of IoT devices in place globally, authenticating and authorizing IoT devices within your organization’s network has become vital. Allowing unauthorized IoT devices onto your network can lead to threat actors leveraging these unauthorized devices to perform malware attacks within your organization.

Need for IoT Security

Security breaches in IoT devices can occur anytime, including manufacturing, network deployment, and software updates. These vulnerabilities provide entry points for hackers to introduce malware into the IoT device and corrupt it. In addition, because all the devices are connected to the Internet, for example: through Wi-Fi, a flaw in one device might compromise the entire network, leading other devices to malfunction.Some key requirements for IoT security are:

• Device security, such as device authentication through digital certificates and signatures.
• Data security, including device authentication and data confidentiality and integrity.
• To comply with regulatory requirements and requests to ensure that IoT devices meet the regulations set up by the industry within which they are used.

IoT Security Challenges:

1. Malware and Ransomware

   The number of malware and ransomware used to exploit IoT-connected devices continue to rise in the coming years as the number of connected devices grows. While classic ransomware uses encryption to lock users out of various devices and platforms entirely, hybridization of malware and ransomware strains is on the rise to integrate multiple attacks.

   The ransomware attacks could reduce or disable device functions while stealing user data. For example, a simple IP (Internet Protocol) camera can collect sensitive information from your house, office, etc.

2. Data Security and Privacy

   Data privacy and security are the most critical issues in today’s interconnected world. Large organizations use various IoT devices, such as smart TVs, IP cameras, speakers, lighting systems, printers, etc., to constantly capture, send, store, and process data. All the user data is often shared or even sold to numerous companies, violating privacy and data security rights and creating public distrust.

   Before storing and disassociating IoT data payloads from information that might be used to identify users personally, the organization needs to establish dedicated compliance and privacy guidelines that redact and anonymize sensitive data. Mobile, web, cloud apps, and other services used to access, manage, and process data associated with IoT devices should comply with these guidelines. Data that has been cached but is no longer needed should be safely disposed of. If the data is saved, complying with various legal and regulatory structures will be the most challenging part.

3. Brute Force Attacks

   According to government reports, manufacturers should avoid selling IoT devices with default credentials, as they use “admin” as a username and password. However, these are only guidelines at this point, and there are no legal penalties in place to force manufacturers to stop using this risky approach. In addition, almost all IoT devices are vulnerable to password hacking and brute-forcing because of weak credentials and login details.

   For the same reason, Mirai malware successfully detected vulnerable IoT devices and compromised them using default usernames and passwords.

4. Skill Gap

   Nowadays, organizations face a significant IoT skill gap that stops them from fully utilizing new prospects. As it is not always possible to hire a new team, setting up training programs is necessary. Adequate training workshops and hands-on activities should be set up to hack a specific smart gadget. The more knowledge your team members have in IoT, the more productive and secure your IoT will be.

5. Lack of Updates and Weak Update Mechanism

   IoT products are designed with connectivity and ease of use in mind. They may be secure when purchased, but they become vulnerable when hackers find new security flaws or vulnerabilities. In addition, IoT devices become vulnerable over time if they are not fixed with regular updates.

Top IoT Vulnerabilities

The Open Web Application Security Project (OWASP) has published the IoT vulnerabilities, an excellent resource for manufacturers and users alike.

1. Weak Password Protection

   Use of easily brute-forced, publicly available, or unchangeable credentials, including backdoors in firmware or client software that grants unauthorized access to deployed systems.

   Weak, guessable, default, and hardcoded credentials are the easiest way to hack and attack devices directly and launch further large-scale botnets and other malware.

   In 2018, California’s SB-327 IoT law passed to prohibit the use of default certificates. This law aims to solve the use of weak password vulnerabilities.

2. Insecure network services

   Unnecessary or unsafe network services that run on the devices, particularly those that are exposed to the internet, jeopardize the availability of confidentiality, integrity/authenticity of the information, and open the risk of unauthorized remote control of IoT devices.

   Unsecured networks make it easy for cybercriminals to exploit weaknesses in protocols and services that run on IoT devices. Once they have exploited the network, attackers can compromise confidential or sensitive data transmitted between the user’s device and the server. Unsecured networks are especially vulnerable to Man-in-the-Middle (MITM) attacks, which steal device credentials and authentication as part of broader cyberattacks.

3. Insecure Ecosystem Interfaces

   Insecure web, backend API, cloud, or mobile interfaces in the ecosystem outside of the device that allows compromise of the device or its related components. Common issues include a lack of authentication/authorization, lacking or weak encryption, and a lack of input and output filtering.

   Useful identification tools help the server distinguish legitimate devices from malicious users. Insecure ecosystem interfaces, such as application programming interfaces (APIs), web applications, and mobile devices, allow attackers to compromise devices. Organizations should implement authentication and authorization processes to authenticate users and protect their cloud and mobile interfaces.

4. Insecure or Outdated Components

   Use of deprecated or insecure software components/libraries that could allow the device to be compromised. This includes insecure customization of operating system platforms, and the use of third-party software or hardware components from a compromised supply chain.

   The IoT ecosystem can be compromised by code and software vulnerabilities as well as legacy systems. Using unsafe or outdated components, such as open source or third-party software, can create security vulnerabilities that expand an organization’s attack surface.

5. Lack of Proper Privacy Protection

   User’s personal information stored on the device or in the ecosystem that is used insecurely, improperly, or without permission.

   IoT devices often collect personal data that organizations must securely store and process in order to comply with various data privacy regulations. Failure to protect this data can result in fines, loss of reputation and loss of business. Failure to implement adequate security can lead to data leaks that jeopardize user privacy.

6. Insecure Default Settings

   Devices or systems shipped with insecure default settings or lack the ability to make the system more secure by restricting operators from modifying configurations.

   IoT devices, like personal devices, come with hard-coded, default settings that allow for easy configuration. However, these default settings are very insecure and vulnerable to attackers. Once compromised, hackers can exploit vulnerabilities in a device’s firmware and launch broader attacks aimed at businesses.

7. Lack of Physical Hardening

   Lack of physical hardening measures, allowing potential attackers to gain sensitive information that can help in a future remote attack or take local control of the device.

   The nature of IoT devices suggests that they are deployed in remote environments rather than in easy-to-manage, controlled scenarios. This makes it easy for attackers to target, disrupt, manipulate, or sabotage critical systems within an organization.

8. Lack of secure update mechanisms

   Lack of ability to securely update the device. This includes lack of firmware validation on device, lack of secure delivery (un-encrypted in transit), lack of anti-rollback mechanisms, and lack of notifications of security changes due to updates.

   Unauthorized firmware and software updates pose a great threat to launch attacks against IoT devices.

Conclusion

References

• www.networkworld.com/article/3332032/top-10-iot-vulnerabilities.html
• wiki.owasp.org/index.php/OWASP_Internet_of_Things_Project