Re: [OPSAWG] Kathleen Moriarty's Discuss on draft-ietf-opsawg-coman-use-cases-04: (with DISCUSS)

[Kathleen Moriarty <[e-mail]>]

Hello,

Thank you for taking to time to add in the additional text, this hits the
points needed and addresses my discuss.  One of the sections has a run-on
sentence, so I'll try to help fix that below.  Please let me know when the
updates are made and I will clear my discuss.

On Tue, Feb 24, 2015 at 8:51 AM, Sehgal, Anuj <[e-mail]>
wrote:

> Hi,
>
> The following inline comments are an overview of the actions taken
> to resolve the issues raised by Kathleen and Ted.
>
> > On 19 Feb 2015, at 4:43 pm, ext Kathleen Moriarty <
> [e-mail]> wrote:
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > Thanks for your work on this draft, I just have some security stuff I'd
> > like to discuss that should be easy to resolve as some text is provided.
> >
> > In section 4.5, it is critical to also include a statement on security in
> > addition to privacy.  Medical devices with network attachments could be
> > used to kill someone.
> >
> http://abcnews.go.com/Health/dick-cheneys-fear-heart-device-hacks-justified-experts/story?id=20633284
> >
> > Suggest changing this text from:
> >   In both cases, however,
> >   it is crucial to protect the privacy of the people to which medical
> >   devices are attached.  Even though the data collected by a heart beat
> >   monitor might be protected, the pure fact that someone carries such a
> >   device may need protection.  As such, certain medical appliances may
> >   not want to participate in discovery and self-configuration protocols
> >   in order to remain invisible.
> > To:
> >   In both cases, however,
> >   it is crucial to protect the safety and privacy of the people to which
> > medical
> >   devices are attached.  Security precautions to protect access
> > (authentication, encryption, integrity protections, etc.) to such devices
> > may be critical to protecting the safety of the individual. Even though
> > the data collected by a heart beat
> >   monitor might be protected, the pure fact that someone carries such a
> >   device may need protection.  As such, certain medical appliances may
> >   not want to participate in discovery and self-configuration protocols
> >   in order to remain invisible.
>
> Adopted text in Section 4.5 - Medical Applications.
>
> > General statement:
> > Many of the other use case scenarios also have safety as a concern,
> > requiring security protections (Confidentiality, Integrity,
> > Availability).  Sensors used to control environmental settings is another
> > example where air regulation might include detection of harmful things in
> > the air (carbon monoxide).  I'm sure there are other safety concerns that
> > motivate security protections in each of the use cases, it's not just
> > privacy (which is important).  What if a sensor was tampered with to
> > report or not report something detected?  That's not covered in the
> > discussion on availability related problems in 4.6, but does represent
> > another set of security considerations that could lead to safety issues.
> > More text on access control considerations for NMS may help.
>
> I propose adding the following text to the respective sections.
>
> Section 4.1 - Environmental Monitoring
>
> Since many applications of environmental monitoring sensors are likely
> to be in areas that are important to safety (flood monitoring, nuclear
> radiation monitoring, etc.) it is important for management protocols
> and network management systems (NMS) to ensure appropriate security
> protections.

These protections include

>  not only access control, integrity and
> availability of data, but also provide appropriate mechanisms that can
> deal with situations that might be categorized as emergencies or when
> tampering with sensors/data might be detected.
>
> Section 4.2 - Infrastructure Monitoring
>
> Since infrastructure monitoring is closely related to ensuring safety,
> management protocols and systems must provide appropriate security
> protections to ensure confidentiality, integrity and availability of
> data.
>
> Section 4.3 - Industrial Applications
>
> Management protocols and NMSs must ensure appropriate access control
> since different users of industrial control systems will have varying
> levels of permissions.  E.g., while supervisors might be allowed to
> change production parameters, they should not be allowed to modify the
> functional configuration of devices like a technician should.  It is
> also important to ensure integrity and availability of data since
> malfunctions can potentially become safety issues.  This also implies
> that management systems must be able to react to situations that may
> pose dangers to worker safety.
>
> Section 4.5 - Medical Applications
>
> In both cases, however, it is crucial to protect the safety and
> privacy of the people to which medical devices are attached. Security
> precautions to protect access (authentication, encryption, integrity
> protections, etc.) to such devices may be critical to safeguarding the
> individual. The level of access granted to different users also may
> need to be regulated. For example, an authorized surgeon or doctor
> must be allowed to configure all necessary options on the devices,
> however, a nurse or technician may only be allowed to retrieve data
> that can assist in diagnosis. Even though the data collected by a
> heart beat monitor might be protected, the pure fact that someone
> carries such a device may need protection. As such, certain medical
> appliances may not want to participate in discovery and
> self-configuration protocols in order to remain invisible.
>
> Section 4.6 - Building Automation
>
> It is also important for a building automation NMS to take safety and
> security into account.  Ensuring privacy and confidentiality of data,
> such that unauthorized parties do not get access to it, is likely to
> be important since users' individual behaviors could be potentially
> understood via their settings.  Appropriate security considerations
> for authorization and access control to the NMS is also important
> since different users are likely to have varied levels of operational
> permissions in the system.  E.g., while end users should be able to
> control lighting systems, HVACs, etc., only qualified technicians
> should be able to configure parameters that change the fundamental
> operation of a device.  It is also important for devices and the NMS
> to be able to detect and report any tampering they might detect, since
> these could lead to potential user safety concerns, e.g., if sensors
> controlling air quality are tampered with such that the levels of
> Carbon Monoxide become life threatening.  This implies that a NMS
> should also be able to deal with and appropriately prioritize
> situations that might potentially lead to safety concerns.
>
> Section 4.8 - Transport Applications
>
> Since transport applications of the constrained devices and networks
> deal with automotive vehicles, malfunctions and misuse can potentially
> lead to safety concerns as well.  As such, besides access control,
> privacy of user data and timeliness management systems should also be
> able to detect situations that are potentially hazardous to safety.
> Some of these situations could be automatically mitigated, e.g.,
> traffic lights with incorrect timing, but others might require human
> intervention, e.g., failed traffic lights.  The management system
> should take appropriate actions in these situations.  Maintaining data
> confidentiality and integrity is also an important security aspect of
> a management system since tampering (or malfunction) can also lead to
> potentially dangerous situations.
>
>
>
> Hopefully this text is enough to resolve these issues.
>

Yes, thank you!
Kathleen

>
> Regards,
> Anuj
>
>


-- 

Best regards,
Kathleen