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 <[email protected]> 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 < > [email protected]> 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
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
