What are the Challenges of IoT Security? IoT has many of the same security challenges that other systems have. There are, however, some challenges that are unique to IoT. 1. Embedded Passwords. Embedding passwords in IoT devices make it easy for remote support technicians to access devices for troubleshooting and simplifies the installation of multiple devices. Of course, it also simplifies access to devices for malicious purposes. 2. Lack of device authentication. Allowing IoT devices access to the network without authenticating opens the network to unknown and unauthorized devices. Rogue devices can serve as an entry point for attacks or even as a source of attacks. 3. Patching and upgrading. Some IoT devices do not provide a simple (or any) means to patch or upgrade software. This results in many IoT devices with vulnerabilities continuing to be in use. 4. Physical hardening. Physical access to IoT devices can introduce risk if those devices are not hardened against physical attack. Such an attack may not be intended to damage the device, but rather to extract information. Simply removing a microSD memory card to read its contents can give an attacker private data, as well as information such as embedded passwords that may allow access to other devices. 5. Outdated components. When vulnerabilities are discovered in hardware or software components of IoT devices, it can be difficult and expensive for manufacturers or users to update or replace them. As with patches, this results in many IoT devices with vulnerabilities continuing to be used. 6. Device monitoring and management. IoT devices do not always have a unique identifier that facilitates asset tracking, monitoring, and management. IT personnel do not necessarily consider IoT devices among the hosts that they monitor and manage. Asset tracking systems sometimes neglect to include IoT devices, so they sit on the network without being managed or monitored. Most of these issues can be attributed to security being an afterthought (if a thought at all) in the design and manufacturing of IoT devices. Even those IoT developers who consider security in the design process struggle with implementation. Most IoT devices are limited by minimal processing power, memory, and data transfer speeds. This is a necessary evil in order to keep the size and cost of the devices small. Accordingly, security controls must be implemented to compensate for these inherent weaknesses. The first step to implementing security controls is to determine where those controls are needed. This is another challenge for protecting IoT devices. Since IoT devices are often not recognized as network devices, they get overlooked when inventorying or mapping the network. If you do not know it is there, you cannot protect it. Fortunately, IoT device manufacturers are beginning to address these issues, but organizations that are planning or currently using IoT cannot sit back and wait for that to happen. There are measures that.

1. What are the Challenges of IoT Security?
IoT has many of the same security challenges that other systems
have. There are, however, some challenges that are unique to
IoT.
1. Embedded Passwords. Embedding passwords in IoT devices
make it easy for remote support technicians to access devices
for troubleshooting and simplifies the installation of multiple
devices. Of course, it also simplifies access to devices for
malicious purposes.
2. Lack of device authentication. Allowing IoT devices access
to the network without authenticating opens the network to
unknown and unauthorized devices. Rogue devices can serve as
an entry point for attacks or even as a source of attacks.
3. Patching and upgrading. Some IoT devices do not provide a
simple (or any) means to patch or upgrade software. This results
in many IoT devices with vulnerabilities continuing to be in
use.
4. Physical hardening. Physical access to IoT devices can
introduce risk if those devices are not hardened against physical
attack. Such an attack may not be intended to damage the
device, but rather to extract information. Simply removing a
microSD memory card to read its contents can give an attacker
private data, as well as information such as embedded
passwords that may allow access to other devices.
5. Outdated components. When vulnerabilities are discovered in
hardware or software components of IoT devices, it can be
difficult and expensive for manufacturers or users to update or
replace them. As with patches, this results in many IoT devices
with vulnerabilities continuing to be used.
6. Device monitoring and management. IoT devices do not
always have a unique identifier that facilitates asset tracking,
monitoring, and management. IT personnel do not necessarily
consider IoT devices among the hosts that they monitor and
manage. Asset tracking systems sometimes neglect to include
IoT devices, so they sit on the network without being managed

2. or monitored.
Most of these issues can be attributed to security being an
afterthought (if a thought at all) in the design and
manufacturing of IoT devices. Even those IoT developers who
consider security in the design process struggle with
implementation. Most IoT devices are limited by minimal
processing power, memory, and data transfer speeds. This is a
necessary evil in order to keep the size and cost of the devices
small. Accordingly, security controls must be implemented to
compensate for these inherent weaknesses.
The first step to implementing security controls is to determine
where those controls are needed. This is another challenge for
protecting IoT devices. Since IoT devices are often not
recognized as network devices, they get overlooked when
inventorying or mapping the network. If you do not know it is
there, you cannot protect it.
Fortunately, IoT device manufacturers are beginning to address
these issues, but organizations that are planning or currently
using IoT cannot sit back and wait for that to happen. There are
measures that organizations can take right now to protect their
IoT devices and networks from attacks.Security Requirements
of IoT
Manufacturers and implementers must implement security
practices to mitigate IoT risks. Steps can be taken to better
secure IoT and address known risks.
Security Challenge
Solution
Embedded passwords
Rather than embedding passwords in their products,

3. manufacturers should require users to create a strong password
during device setup.
Lack of device authentication
Manufacturers should provide a means for their devices to
authenticate to the network. IT personnel should require devices
to authenticate before joining the network.
Patching and upgrading
Manufacturers need to make it easy for devices to be upgraded
or patched. Ideally, this would be an automatic or one-click
process.
Physical hardening
IoT devices should be made tamper-proof. Devices should be
monitored to detect time offline and inspected after
unexpectedly dropping offline.
Outdated components
Vulnerable devices should be updated or replaced. This can be
difficult to remedy, especially in environments that have many
IoT devices in remote locations. In those cases, tighter security
controls and more vigilant monitoring should be implemented.
Device monitoring and management
Ensure that all IoT devices are included in asset tracking,
monitoring, and management systems. Manufacturers should
provide a unique identifier for each device.
Clearly, many of these security issues can only be resolved by

4. the manufacturer. One that organizations’ security, IT, and OT
teams can address is device management. It is up to those
planning and/or implementing the rollout of IoT devices to
ensure that they are accounted for in asset management, systems
monitoring, security monitoring, and incident response systems.
Breaches and Hacks
There are two broad categories of attacks that involve IoT
devices: those in which the IoT devices themselves are the end
target of the attack, and those that use IoT devices to attack
other targets. We have seen both types of attacks used in the
real world and by security researchers as a proof of concept.
In October of 2016, an attack against Dyn, a company that
provides DNS services, made much of the internet inaccessible.
Twitter, Spotify, Github, Netflix, The New York Times, Paypal
and other major websites were down for hours.
The attack used the Mirai IoT Botnet, taking control of over
600,000 IoT devices to flood Dyn with traffic in a massive
DDoS attack. The devices seemed to be mostly routers and IP
cameras. IP cameras are frequently targeted IoT devices.
In a scary example of an attack where the IoT device was the
target, the “device” was a car. Fortunately, this was a controlled
demonstration by security researchers Charlie Miller and Chris
Valasek. They demonstrated the attack for Wired writer Andy
Greenberg, who was driving a Jeep Cherokee.
Miller and Valasek, from miles away over a cellular internet

5. connection, remotely turned on the A/C, radio, and windshield
wipers. That was just the beginning. Next, they caused the Jeep
to slow, remotely rendering the accelerator useless.How to
Secure IoT Systems and Devices
It is clear that IoT attacks can have serious consequences.
Securing IoT systems and devices must be done by both the
manufacturers and the organizations using them. The security
controls that organizations can put in place are similar to the
controls they already use on their network. The key to securing
IoT is to know what IoT devices are on your network and where
they are in your network topology. Until you know that, you are
flying blind. You cannot protect what you cannot see.
One way to identify IoT devices on your network is to require
all hosts and devices to authenticate when joining the network.
Devices that fail authentication can then be identified. If they
belong on the network, authentication can then be configured
for that device. If they do not belong on the network, you have
discovered a rogue device.
You can further secure IoT devices by segmenting the network
and dedicating one segment to IoT. This will allow you to
firewall that segment and apply IoT-specific rules. It would also
allow you to quickly block traffic from that segment in the
event that an IoT device is compromised.
Once you have IoT devices authenticated, you can then gain
visibility into their activity using a cloud-native security

6. monitoring and analytics platform like Sumo Logic. The Sumo
Logic platform helps you make data-driven decisions and reduce
the time to investigate security and operational issues so you
can free up resources for more important activities. For even
greater visibility into security events, integrated threat
intelligence from Crowdstrike is included for up-to-date IOC
data that can be quickly cross-correlated to identify threats in
your environment.
Reference: https://www.sumologic.com/blog/iot-security/
C19 07/14/2011 11:18:53 Page 187
19CHAPTER NINETEEN
Project Reviews
Subbu Murthy
T
HE PURPOSE OF PROJECT reviews depends on the project life
cycle (see
Figure 19.1). Understanding the purpose of a review is as
important as the

7. review itself. In the early stages of the project, reviews are
typically held to
assess the project impact across the portfolio of other projects,
evaluate alternatives,
and make decisions to continue the project or abandon them.
In the planning stages, reviews are held to assess the project
costs, schedule, and
risks. They are also held to establish the high-level scope and
interfaces with other
projects and to evaluate resource allocations. The reviews in the
early stage and the
planning phase play a key role in prioritizing and sequencing
the project.
In the execution stage, reviews are focused on understanding
the project specifica-
tions (requirements, design, etc.), assessing the progress of the

8. project, and assessing
project quality.
Postimplementation reviews are also crucial as they serve to
assess overall
performance and review the key lessons learned. They also help
understand the true
causes of variance. In a majority of IT projects, poor
specifications and scope creep are
the two strong determinants of cost and schedule variances.
Project reviews share four characteristics: (1) They are
measurable, (2) they have
specific goals, (3) they deliver direct or indirect benefits to
customers or stakeholders,
and (4) they are triggered by a specific milestone or a
preestablished schedule.
187

9. C
o
p
y
r
i
g
h
t
2
0
1
1
.
W
i
l
e
y
.
A

10. l
l
r
i
g
h
t
s
r
e
s
e
r
v
e
d
.
M
a
y
n

11. o
t
b
e
r
e
p
r
o
d
u
c
e
d
i
n
a
n
y
f

12. o
r
m
w
i
t
h
o
u
t
p
e
r
m
i
s
s
i
o
n
f
r

13. o
m
t
h
e
p
u
b
l
i
s
h
e
r
,
e
x
c
e
p
t

14. f
a
i
r
u
s
e
s
p
e
r
m
i
t
t
e
d
u
n
d
e
r

15. U
.
S
.
o
r
a
p
p
l
i
c
a
b
l
e
c
o
p
y
r

16. i
g
h
t
l
a
w
.
EBSCO Publishing : eBook Collection (EBSCOhost) - printed
on 5/3/2020 12:29 PM via STRAYER UNIVERSITY
AN: 391434 ; Lane, Dean.; The Chief Information Officer's
Body of Knowledge : People, Process, and Technology
Account: strayer.main.eds-live
C19 07/14/2011 11:18:53 Page 188
CONCEPTS
Every review must have a purpose, and the purpose must be
aligned to the specific

17. project needs. In addition to identifying the purpose of the
review, some of the
fundamental aspects of a project review to consider are the
frequency of the review
(weekly versus monthly or quarterly), granularity (detailed
versus high level), and
whether reviews are scheduled (weekly, monthly, quarterly) or
event driven (such as
completion of a project milestone). The audience for the project
review depends on the
purpose of the review. Management, technical architects,
developers, quality assurance
personnel, users, finance, and other functions may have to be
involved, depending on
the type of review.
While the frequency of review and granularity of reviews
depends on the type of

18. project and the maturity of the team working on the project, it is
helpful to recognize
that projects that are unstructured (not very well defined) and
more critical to the
enterprise will require more scrutiny. Weekly meetings as
opposed to monthly reviews
may be required. The flip side of the equation is the cost
entailed in organizing and
conducting the reviews.
It is a very common myth that project reviews always require
face-to-face meetings
and are formal. Informal reviews, online project dashboards,
and other communication
mechanisms are also part of the project review process and very
critical to ensuring
overall success of the project. Formal project reviews are

19. generally planned as milestone
events, but reviews for very complex projects can have mini–
life cycles of their own. This
is true for reviews where a critical decision, such as deployment
readiness, has to be
assessed. The phrase ‘‘review phase’’ is quite common when
reviews are complex and
time consuming.
In addition to compliance with project requirements, the review
focus is a
combination of assessing the costs, schedule, quality, and risk
of a project. Project
risk can be defined in terms of criticality, degree of clarity in
the specifications, and costs.
Projects that are critical, lack clarity of specifications, and are
costly to implement are

20. high-risk projects. In contrast, projects that are not mission
critical, cost less, and are
well specified tend to have the least risk.
In general, smaller, mission-critical projects have a schedule
focus (see Figure 19.2);
that is, the review focuses on schedule variance since the costs
are relatively low and the
schedule of when the projects get completed assumes more
importance. However, for
Early Stage Planning Execution Post-
implementation
• Assess Impact
• Evaluate
Alternatives
• Make Go/No-
Go Decisions
• Assess Cost,
Schedule,

21. Risk
• Review
Resource
Allocations
• Review Scope
• Review
Design
• Review
Progress
• Assess
Quality
• Assess
Performance
• Lessons
Learned
FIGURE 19.1 Project Life Cycle
188 & Process
EBSCOhost - printed on 5/3/2020 12:29 PM via STRAYER
UNIVERSITY. All use subject to https://www.ebsco.com/terms-
of-use

22. C19 07/14/2011 11:18:54 Page 189
larger, less mission-critical projects, in addition to schedule
reviews, cost variance
reviews are also important. For smaller but mission-critical
projects, reviews tend to
focus more on mitigating risk; for mission-critical large
projects, the review focus is on all
of the four attributes mentioned.
TYPES OF PROJECT REVIEWS
Some of the common project reviews include:
& Project go/no-go review. The purpose of this review is to
assess the project need;
the desired benefits; the fit within the project portfolio with
reference to costs,

23. schedule, and risks; and, most important, how the project aligns
to business needs.
The desired outcome is a go/no-decision and project
prioritization within the
portfolio of projects. In reality, decisions are not made in one
review meeting,
and different levels of granularity of project scope may need to
be reviewed,
depending on the audience. For example, finance may be more
concerned about
return on investment (cost and tangible benefits) whereas users
may be more
concerned about features and prioritization.
& Plan review. The purpose of this review is to review the
project plan. (Note: For
very small projects that are better treated as tasks, the project
plan and review

24. process may be less formal.) For most projects, the master plan
for a project is
usually formally documented in a project plan. The key goals of
this review are to
ensure that:
& Project governance provides adequate visibility and is in
compliance with IT
governance practices.
Schedule
Focus
Cost and
Schedule
Focus
Cost,
Schedule,
Risk, and

25. Quality Focus
Risk and
Quality Focus
Small
Projects
Large
Projects
Less Mission
Critical
More Mission
Critical
FIGURE 19.2 Review Focus
Project Reviews & 189
EBSCOhost - printed on 5/3/2020 12:29 PM via STRAYER
UNIVERSITY. All use subject to https://www.ebsco.com/terms-
of-use

26. C19 07/14/2011 11:18:54 Page 190
& The project addresses the critical business, user, and
technical requirements.
& The project vision is understood and shared by all team
members.
& Project costs, schedules, and resources are realistic.
& Project success criteria are clearly established.
& Interfaces with other projects and external and internal
entities are clearly
identified.
& Project quality assurance and reviews are well planned.
& Project risks are appropriately identified, and mitigation
strategies are proposed.
& Project organization has experience in delivering projects.
Note examples of what to look out for to determine if you are
going in the right
or wrong direction.
& Progress reviews. The purpose of the progress reviews is to
review the status of

27. the project. These reviews address not only the progress to date
but the plan for the
remainder of the project and any necessary adjustments. The
key goals of this
review are to ensure that:
& Project progress (costs, schedules, and resource utilization) is
per the plan.
Variance in terms of costs and schedule are tracked. If variances
exceed
established thresholds, replanning may be required. It should be
noted that
extensive replanning is tantamount to canceling the existing
project and
initiating a new one.
& Project success criteria are met. An absolute measure is
nearly impossible to
achieve. Criteria such as on a scale of 1 to 5 help provide a

28. degree of success of
the project.
& Interfaces with other projects and external and internal
entities are assessed.
& Project technical progress is as per the plan.
Progress reviews address the technical aspects at a milestone
level. Some of the
more common progress reviews include preliminary design
review, test readiness
review, and deployment review.
The preliminary design review is a key review in the early
stages for reviewing
implications to the project scope, schedule, and costs, based on
design alternatives
that meet requirements.
The test readiness review assesses the completion of the
development and the

29. readiness to proceed with the testing. One of the key
considerations is the quality of
the test plans and the adequacy of both technical resources and
users available for
testing.
Deployment reviews help determine whether the developed and
tested product
(or service) is ready for use.
The goal of progress reviews is to ensure that mistakes are
caught early in the
project life cycle. While there is general agreement that
mistakes detected earlier in
the project life cycle are far less expensive than those detected
in the later stages of
the project life cycle, there is no uniform data to quantify the
costs. Generally it is an

30. order of magnitude more expensive to correct a mistake during
testing as opposed to
detecting it during early stages of the design and a further order
of magnitude more
expensive to address postdeployment (see Figure 19.3).
190 & Process
EBSCOhost - printed on 5/3/2020 12:29 PM via STRAYER
UNIVERSITY. All use subject to https://www.ebsco.com/terms-
of-use
C19 07/14/2011 11:18:54 Page 191
& Detailed technical reviews. The purpose of these reviews is to
ensure com-
pleteness, accuracy, appropriateness, and overall quality of the
project. The

31. reviews depend on the type of project and are typically staged
to match the
project life cycle. Software projects, for example, typically
include requirements
reviews, design reviews, development (code) reviews, and test
reviews. The
quality of the delivered project depends heavily on the quality
of the technical
reviews. While the technical collaterals and checklists depend
on the nature of
the review (e.g., test reviews should include a mapping to the
requirements
specification to ensure that all requirements are tested), they all
have a few
common characteristics:
& Informal technical reviews should be held frequently to
ensure that errors,

32. omissions, and other issues are caught early in the project life
cycle.
& In general, detailed technical reviews should not be combined
with project
progress reviews. Although cost and schedule considerations are
important, the
primary purpose of technical reviews is to ensure overall system
quality.
& In addition to development teams, users and members of the
quality staff are
actively involved in the technical reviews to ensure that the
project implemen-
tation meets the stakeholder expectations.
& Project sunset review (aka postmortem review). The purpose
of this review is
to capture project successes, difficulties, and resulting lessons
learned and com-
municate these to the project team and relevant management
peers. A common

33. myth is that project sunset reviews are needed only for projects
that were not
deemed successful. These reviews provide very valuable
insights and evidential data
to improve existing processes, metrics, and often serve as a
baseline for future
projects. Project sunset reviews for successful projects are
valuable in that they
reinforce what worked and best practices. Such reviews are
arguably more valu-
able for failed projects in that they show what did not work so
as to avoid
making similar mistakes in the future. In either case, such
reviews provide an
excellent opportunity to reflect and learn.
1X

34. 10X
Preliminary
Design Review
Test Readiness
Review
Postdeployment
100X
FIGURE 19.3 Cost of Mistakes/Defects
Project Reviews & 191
EBSCOhost - printed on 5/3/2020 12:29 PM via STRAYER
UNIVERSITY. All use subject to https://www.ebsco.com/terms-
of-use
C19 07/14/2011 11:18:54 Page 192

35. PROJECT REVIEW PROCESS
In the past, reviews were almost always conducted face-to-face.
Recent advances
in technology have facilitated Web meetings, with tools such as
WebEx and
GoToMeeting enabling geographically dispersed teams to
collaborate as if they
were sitting next to one another. A few institutions also use
social networks to
facilitate project reviews where some of the participants provide
‘‘informal’’ feedback,
such as wikis and tweets. While face-to-face meetings are more
common, these newer
forms of collaborating are gaining momentum. Independent of
the review modality,
formal project reviews have a mini–life cycle of their own and
should be treated in the

36. context of the project.
The three key stages are preparation, meeting/review, and
postmeeting follow-up:
1. The preparation stage is crucial to ensure success of the
review. Careful prepara-
tion results in maximum benefits from the review. The review
collaterals, review
checklists, audience, review agenda, schedule, and location are
critical to a success-
ful review. Typically the review collaterals are sent ahead of
time to the reviewers
with instructions and road maps for reviewing. This method is
particularly useful
when reviewing large documents. When preparing for the
review, the aim is to
ensure that the review goals are met with buy-in from all

37. participants. Review-
meeting planning checklists help facilitate the reviewing
planning process. While
checklists and preestablished templates facilitate reviews, they
should always be
viewed in the context of the project.
2. Each review should have a review coordinator who conducts
the meeting. Also
consider designating a note taker and timekeeper. The assigned
note taker is
responsible for taking meeting notes. The note taker records
action items that are
then reported in the meeting minutes and any follow-on reviews.
The review
coordinator is responsible for leading the meeting, setting the
agenda, and creating

38. the role rotation. On occasion, the review coordinator may be
assisted by a
timekeeper to ensure adherence to the meeting agenda. The
review agenda may
be modified by the review coordinator as warranted. The note
taker will ensure that
all comments and new and open issues are recorded as part of
the meeting minutes.
3. During the review or postreview, the action items are
reviewed and assigned to
responsible individuals. Any issues/concerns raised during the
review are discussed
and adjudicated. Accepted issues will have a corrective action
plan and rejected
issues are documented with the appropriate rationale for
rejection. All these items
become part of the meeting minutes, which are sent to the

39. reviewers and other
stakeholders as appropriate.
SUMMARY
Project reviews are an essential component of project
management. They should
be planned taking into account the nature of the project, culture
of the enterprise,
192 & Process
EBSCOhost - printed on 5/3/2020 12:29 PM via STRAYER
UNIVERSITY. All use subject to https://www.ebsco.com/terms-
of-use
C19 07/14/2011 11:18:54 Page 193
and project stage. Reviews should be planned to help assess
project progress,

40. technology, and other key variables to ensure that the project is
proceeding as
planned. However, care should be taken to ensure that the
review process does not
become onerous and dilute the overall purpose of the project.
To be successful, all
reviews must be planned, conducted according to preestablished
agenda, and have
a follow-up to ensure that they have achieved the desired
outcome.
Project Reviews & 193
EBSCOhost - printed on 5/3/2020 12:29 PM via STRAYER
UNIVERSITY. All use subject to https://www.ebsco.com/terms-
of-use
C19 07/14/2011 11:18:54 Page 194

41. EBSCOhost - printed on 5/3/2020 12:29 PM via STRAYER
UNIVERSITY. All use subject to https://www.ebsco.com/terms-
of-use
IoT References:
https://www.techrepublic.com/article/how-to-secure-your-iot-
devices-from-botnets-and-other-threats/
https://www.peerbits.com/blog/biggest-iot-security-
challenges.html
https://www.bankinfosecurity.asia/securing-iot-devices-
challenges-a-11138
https://www.sumologic.com/blog/iot-security/
https://news.ihsmarkit.com/press-release/number-connected-iot-
devices-will-surge-125-billion-2030-ihs-markit-says
https://cdn.ihs.com/www/pdf/IoT_ebook.pdf
https://go.armis.com/hubfs/Buyers%E2%80%99%20Guide%20to
%20IoT%20Security%20-Final.pdf
https://www.techrepublic.com/article/smart-farming-how-iot-
robotics-and-ai-are-tackling-one-of-the-biggest-problems-of-
the-century/
Video Resources:What is the Internet of Things (IoT) and how
can we secure it?
https://www.youtube.com/watch?v=H_X6IP1-NDc
What is the problem with IoT security? - Gary explains

42. https://www.youtube.com/watch?v=D3yrk4TaIQQ
Final Research Project - Securing IoT Devices: What are the
Challenges?
Internet security, in general, is a challenge that we have been
dealing with for decades. It is a regular topic of discussion and
concern, but a relatively new segment of internet security is
getting most attention—internet of things (IoT). So why is
internet of things security so important?
The high growth rate of IoT should get the attention of
cybersecurity professionals. The rate at which new technology
goes to market is inversely proportional to the amount of
security that gets designed into the product. According to IHS
Markit, “The number of connected IoT devices worldwide will
jump 12 percent on average annually, from nearly 27 billion in
2017 to 125 billion in 2030.”
IoT devices are quite a bit different from other internet-
connected devices such as laptops and servers. They are
designed with a single purpose in mind, usually running
minimal software with minimal resources to serve that purpose.
Adding the capability to run and update security software is
often not taken into consideration.
Due to the lack of security integrated into IoT devices, they
present significant risks that must be addressed. IoT security is
the practice of understanding and mitigating these risks. Let’s

43. consider the challenges of IoT security and how we can address
them.
Some security practitioners suggest that key IoT security steps
include:
1. Make people aware that there is a threat to security;
2. Design a technical solution to reduce security vulnerabilities;
3. Align the legal and regulatory frameworks; and
4. Develop a workforce with the skills to handle IoT security.
Final Assignment - Project Plan (Deliverables):
1) Address each of the FOURIoT security steps listed above in
terms of IoT devices.
2) Explain in detail, in a step-by-step guide, how to make
people more aware of the problems associated with the use of
IoT devices.
Bottom of Form
Top of Form
Bottom of Form