https://wiki.owasp.org/api.php?action=feedcontributions&feedformat=atom&user=Tonimir+Kisasondi 2026-04-29T19:28:38Z User contributions MediaWiki 1.27.2 https://wiki.owasp.org/index.php?title=Croatia&diff=256226 2019-12-03T08:00:29Z

<p>Tonimir Kisasondi: </p> <hr /> <div>{{Chapter Template|chaptername=Croatia|extra=The chapter leaders are [mailto:tonimir.kisasondi@owasp.org Tonimir Kisasondi] and [mailto:vlatko.kosturjak@owasp.org Vlatko Kosturjak] |mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Croatia|emailarchives=http://lists.owasp.org/pipermail/owasp-croatia/}}<br /> <br /> If you are interested in helping, organising or holding OWASP meetups, do not hesitate to contact us, Croatia has a very small infosec community and we are very inclusive. If you are interested to be even more active in this area, we are happy to have co-leads. <br /> <br /> <br /> ==== Local News ====<br /> <br /> Welcome. Since our start, we agreed we will have regular meetings in Varaždin and Zagreb in order to make it more attractive. You're invited to subscribe to the mailing list for up2date news and also if you want help in <br /> organising local chapter. Everyone is welcome to join us at our chapter meetings.<br /> <br /> ==== Chapter Meetings ====<br /> '''Regular Meeting Location''': FOI, Pavlinska 2, 42000 Varaždin, Hrvatska at the scene of any FSec Underground meet ([https://www.facebook.com/fsec2017/ Page])<br /> <br /> '''Next Planned meetups:'''<br /> * 27th of February 2019 at [https://www.meetup.com/Kubernetes-Croatia/events/258931456/ Cloud Native meetup - Kino Europa]<br /> * At the DORS/CLUC 2019 (Zagreb) 18.04.2019 - https://2019.dorscluc.org/<br /> * At BSidesVarazdin.org - 18.9.2019<br /> * At Kubernetes and Cloud Native meetup Zagreb 5.12.2019 - https://www.meetup.com/Kubernetes-Croatia/events/266384582/<br /> <br /> '''Previous meetups:'''<br /> OWASP meetup at the IoT Hacking School of 2018 |([https://hack.foi.hr Info])<br /> OWASP meetup at the FSec 2017 ([https://www.flickr.com/photos/58943051@N07/sets/72157667605653398 Photos]) | ([https://fsec.foi.hr Info])<br /> OWASP meetup at FSec 2016 ([https://www.flickr.com/photos/58943051@N07/sets/72157673516643570 Photos]) | ([https://fsec.foi.hr Info])<br /> [http://www.foi.unizg.hr/Ljetna-skola-aplikacijske-sigurnost-na-FOI-ju OWASP application security summer school] from 23th to 26th of September, 2014 @ FOI ([https://www.flickr.com/photos/58943051@N07/sets/72157648047647530/ Photos])<br /> OWASP round table/meetup on 14.9.2015 @ [http://fsec.foi.hr/ FOI/FSEC]<br /> OWASP regular/meeting on 26.2.2016 at 18:00 (FOI Infoclub, Basement) | [https://www.facebook.com/events/1840212762872033/ Link to FB Event] [http://www.foi.unizg.hr/hr/novosti/razmjena-vjestina-owasp-croatia-meetup Link to Web]<br /> OWASP Croatia meeting 11.5.2016 at 17:00 (FER Zagreb, Hall B2) | [https://www.facebook.com/events/475076512695702/ Link to FB Event] | [http://lists.owasp.org/pipermail/owasp-croatia/2016-May/000013.html Event details] | [http://lists.owasp.org/pipermail/owasp-croatia/2016-April/000012.html Email CFP] | [[Croatia/presentations]]<br /> <br /> <br /> ==== Croatia OWASP Chapter Leaders ====<br /> The chapter leaders are [mailto:tonimir.kisasondi@owasp.org Tonimir Kisasondi] and [mailto:vlatko.kosturjak@owasp.org Vlatko Kosturjak]<br /> <br /> __NOTOC__<br /> &lt;headertabs /&gt;<br /> [[Category:OWASP Chapter]]<br /> [[Category:Europe]]</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=Croatia&diff=253001 2019-07-14T20:14:42Z

<p>Tonimir Kisasondi: </p> <hr /> <div>{{Chapter Template|chaptername=Croatia|extra=The chapter leaders are [mailto:tonimir.kisasondi@owasp.org Tonimir Kisasondi] and [mailto:vlatko.kosturjak@owasp.org Vlatko Kosturjak] |mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Croatia|emailarchives=http://lists.owasp.org/pipermail/owasp-croatia/}}<br /> <br /> If you are interested in helping, organising or holding OWASP meetups, do not hesitate to contact us, Croatia has a very small infosec community and we are very inclusive. If you are interested to be even more active in this area, we are happy to have co-leads. <br /> <br /> <br /> ==== Local News ====<br /> <br /> Welcome. Since our start, we agreed we will have regular meetings in Varaždin and Zagreb in order to make it more attractive. You're invited to subscribe to the mailing list for up2date news and also if you want help in <br /> organising local chapter. Everyone is welcome to join us at our chapter meetings.<br /> <br /> ==== Chapter Meetings ====<br /> '''Regular Meeting Location''': FOI, Pavlinska 2, 42000 Varaždin, Hrvatska at the scene of any FSec Underground meet ([https://www.facebook.com/fsec2017/ Page])<br /> <br /> '''Next Planned meetups:'''<br /> * 27th of February 2019 at [https://www.meetup.com/Kubernetes-Croatia/events/258931456/ Cloud Native meetup - Kino Europa]<br /> * At the DORS/CLUC 2019 (Zagreb) 18.04.2019 - https://2019.dorscluc.org/<br /> * At BSidesVarazdin - 18.9.2019<br /> <br /> '''Previous meetups:'''<br /> OWASP meetup at the IoT Hacking School of 2018 |([https://hack.foi.hr Info])<br /> OWASP meetup at the FSec 2017 ([https://www.flickr.com/photos/58943051@N07/sets/72157667605653398 Photos]) | ([https://fsec.foi.hr Info])<br /> OWASP meetup at FSec 2016 ([https://www.flickr.com/photos/58943051@N07/sets/72157673516643570 Photos]) | ([https://fsec.foi.hr Info])<br /> [http://www.foi.unizg.hr/Ljetna-skola-aplikacijske-sigurnost-na-FOI-ju OWASP application security summer school] from 23th to 26th of September, 2014 @ FOI ([https://www.flickr.com/photos/58943051@N07/sets/72157648047647530/ Photos])<br /> OWASP round table/meetup on 14.9.2015 @ [http://fsec.foi.hr/ FOI/FSEC]<br /> OWASP regular/meeting on 26.2.2016 at 18:00 (FOI Infoclub, Basement) | [https://www.facebook.com/events/1840212762872033/ Link to FB Event] [http://www.foi.unizg.hr/hr/novosti/razmjena-vjestina-owasp-croatia-meetup Link to Web]<br /> OWASP Croatia meeting 11.5.2016 at 17:00 (FER Zagreb, Hall B2) | [https://www.facebook.com/events/475076512695702/ Link to FB Event] | [http://lists.owasp.org/pipermail/owasp-croatia/2016-May/000013.html Event details] | [http://lists.owasp.org/pipermail/owasp-croatia/2016-April/000012.html Email CFP] | [[Croatia/presentations]]<br /> <br /> <br /> ==== Croatia OWASP Chapter Leaders ====<br /> The chapter leaders are [mailto:tonimir.kisasondi@owasp.org Tonimir Kisasondi] and [mailto:vlatko.kosturjak@owasp.org Vlatko Kosturjak]<br /> <br /> __NOTOC__<br /> &lt;headertabs /&gt;<br /> [[Category:OWASP Chapter]]<br /> [[Category:Europe]]</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=Croatia&diff=247552 2019-02-15T23:17:46Z

<p>Tonimir Kisasondi: </p> <hr /> <div>{{Chapter Template|chaptername=Croatia|extra=The chapter leaders are [mailto:tonimir.kisasondi@owasp.org Tonimir Kisasondi] and [mailto:vlatko.kosturjak@owasp.org Vlatko Kosturjak] |mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Croatia|emailarchives=http://lists.owasp.org/pipermail/owasp-croatia/}}<br /> <br /> If you are interested in helping, organising or holding OWASP meetups, do not hesitate to contact us, Croatia has a very small infosec community and we are very inclusive. If you are interested to be even more active in this area, we are happy to have co-leads. <br /> <br /> <br /> ==== Local News ====<br /> <br /> Welcome. Since our start, we agreed we will have regular meetings in Varaždin and Zagreb in order to make it more attractive. You're invited to subscribe to the mailing list for up2date news and also if you want help in <br /> organising local chapter. Everyone is welcome to join us at our chapter meetings.<br /> <br /> ==== Chapter Meetings ====<br /> '''Regular Meeting Location''': FOI, Pavlinska 2, 42000 Varaždin, Hrvatska at the scene of any FSec Underground meet ([https://www.facebook.com/fsec2017/ Page])<br /> <br /> '''Next Planned meetups:'''<br /> * 27th of February 2019 at [https://www.meetup.com/Kubernetes-Croatia/events/258931456/ Cloud Native meetup - Kino Europa]<br /> * At the DORS/CLUC 2019 (Zagreb) 18.04.2019 - https://2019.dorscluc.org/<br /> * At Sept 2019 (TBD)<br /> <br /> '''Previous meetups:'''<br /> OWASP meetup at the IoT Hacking School of 2018 |([https://hack.foi.hr Info])<br /> OWASP meetup at the FSec 2017 ([https://www.flickr.com/photos/58943051@N07/sets/72157667605653398 Photos]) | ([https://fsec.foi.hr Info])<br /> OWASP meetup at FSec 2016 ([https://www.flickr.com/photos/58943051@N07/sets/72157673516643570 Photos]) | ([https://fsec.foi.hr Info])<br /> [http://www.foi.unizg.hr/Ljetna-skola-aplikacijske-sigurnost-na-FOI-ju OWASP application security summer school] from 23th to 26th of September, 2014 @ FOI ([https://www.flickr.com/photos/58943051@N07/sets/72157648047647530/ Photos])<br /> OWASP round table/meetup on 14.9.2015 @ [http://fsec.foi.hr/ FOI/FSEC]<br /> OWASP regular/meeting on 26.2.2016 at 18:00 (FOI Infoclub, Basement) | [https://www.facebook.com/events/1840212762872033/ Link to FB Event] [http://www.foi.unizg.hr/hr/novosti/razmjena-vjestina-owasp-croatia-meetup Link to Web]<br /> OWASP Croatia meeting 11.5.2016 at 17:00 (FER Zagreb, Hall B2) | [https://www.facebook.com/events/475076512695702/ Link to FB Event] | [http://lists.owasp.org/pipermail/owasp-croatia/2016-May/000013.html Event details] | [http://lists.owasp.org/pipermail/owasp-croatia/2016-April/000012.html Email CFP] | [[Croatia/presentations]]<br /> <br /> <br /> ==== Croatia OWASP Chapter Leaders ====<br /> The chapter leaders are [mailto:tonimir.kisasondi@owasp.org Tonimir Kisasondi] and [mailto:vlatko.kosturjak@owasp.org Vlatko Kosturjak]<br /> <br /> __NOTOC__<br /> &lt;headertabs /&gt;<br /> [[Category:OWASP Chapter]]<br /> [[Category:Europe]]</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=Croatia&diff=246129 2018-12-18T21:36:44Z

<p>Tonimir Kisasondi: Patched to fix inaccuracies</p> <hr /> <div>{{Chapter Template|chaptername=Croatia|extra=The chapter leaders are [mailto:tonimir.kisasondi@owasp.org Tonimir Kisasondi] and [mailto:vlatko.kosturjak@owasp.org Vlatko Kosturjak] |mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Croatia|emailarchives=http://lists.owasp.org/pipermail/owasp-croatia/}}<br /> <br /> If you are interested in helping, organising or holding OWASP meetups, do not hesitate to contact us, Croatia has a very small infosec community and we are very inclusive. If you are interested to be even more active in this area, we are happy to have co-leads. <br /> <br /> <br /> ==== Local News ====<br /> <br /> Welcome. Since our start, we agreed we will have regular meetings in Varaždin and Zagreb in order to make it more attractive. You're invited to subscribe to the mailing list for up2date news and also if you want help in <br /> organising local chapter. Everyone is welcome to join us at our chapter meetings.<br /> <br /> ==== Chapter Meetings ====<br /> '''Regular Meeting Location''': FOI, Pavlinska 2, 42000 Varaždin, Hrvatska at the scene of any FSec Underground meet ([https://www.facebook.com/fsec2017/ Page])<br /> <br /> Next Planned meetups:<br /> * Last Friday of February 2019 (22.2) in Varaždin @ FOI<br /> * At the DORS/CLUC 2019 (Zagreb) - https://2019.dorscluc.org/<br /> * At Sept 2019 (TBD)<br /> '''Previous event''': OWASP meetup at the IoT Hacking School of 2018 |([https://hack.foi.hr Info])<br /> '''Previous event''': OWASP meetup at the FSec 2017 ([https://www.flickr.com/photos/58943051@N07/sets/72157667605653398 Photos]) | ([https://fsec.foi.hr Info])<br /> '''Previous event''': OWASP meetup at FSec 2016 ([https://www.flickr.com/photos/58943051@N07/sets/72157673516643570 Photos]) | ([https://fsec.foi.hr Info])<br /> '''Previous event''': [http://www.foi.unizg.hr/Ljetna-skola-aplikacijske-sigurnost-na-FOI-ju OWASP application security summer school] from 23th to 26th of September, 2014 @ FOI ([https://www.flickr.com/photos/58943051@N07/sets/72157648047647530/ Photos])<br /> '''Previous meetup''': OWASP round table/meetup on 14.9.2015 @ [http://fsec.foi.hr/ FOI/FSEC]<br /> '''Previous meetings''': OWASP regular/meeting on 26.2.2016 at 18:00 (FOI Infoclub, Basement) | [https://www.facebook.com/events/1840212762872033/ Link to FB Event] [http://www.foi.unizg.hr/hr/novosti/razmjena-vjestina-owasp-croatia-meetup Link to Web]<br /> '''Previous meeting''': OWASP Croatia meeting 11.5.2016 at 17:00 (FER Zagreb, Hall B2) | [https://www.facebook.com/events/475076512695702/ Link to FB Event] | [http://lists.owasp.org/pipermail/owasp-croatia/2016-May/000013.html Event details] | [http://lists.owasp.org/pipermail/owasp-croatia/2016-April/000012.html Email CFP] | [[Croatia/presentations]]<br /> <br /> <br /> ==== Croatia OWASP Chapter Leaders ====<br /> The chapter leaders are [mailto:tonimir.kisasondi@owasp.org Tonimir Kisasondi] and [mailto:vlatko.kosturjak@owasp.org Vlatko Kosturjak]<br /> <br /> __NOTOC__<br /> &lt;headertabs /&gt;<br /> [[Category:OWASP Chapter]]<br /> [[Category:Europe]]</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=Croatia&diff=245190 2018-11-16T14:13:57Z

<p>Tonimir Kisasondi: </p> <hr /> <div>{{Chapter Template|chaptername=Croatia|extra=The chapter leaders are [mailto:tonimir.kisasondi@owasp.org Tonimir Kisasondi] and [mailto:vlatko.kosturjak@owasp.org Vlatko Kosturjak] |mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Croatia|emailarchives=http://lists.owasp.org/pipermail/owasp-croatia/}}<br /> <br /> If you are interested in helping, organising or holding OWASP meetups, do not hesitate to contact us, Croatia has a very small infosec community and we are very inclusive. If you are interested to be even more active in this area, we are happy to have co-leads. <br /> <br /> <br /> ==== Local News ====<br /> <br /> Welcome. Since our start, we agreed we will have regular meetings in Varaždin and Zagreb in order to make it more attractive. You're invited to subscribe to the mailing list for up2date news and also if you want help in <br /> organising local chapter. Everyone is welcome to join us at our chapter meetings.<br /> <br /> ==== Chapter Meetings ====<br /> '''Regular Meeting Location''': FOI, Pavlinska 2, 42000 Varaždin, Hrvatska at the scene of any FSec Underground meet ([https://www.facebook.com/fsec2017/ Page])<br /> <br /> Next Planned meetups:<br /> * Last Friday of February 2018 (22.2) in Varaždin / FOI<br /> * At the DORS/CLUC 2019 (Zagreb)<br /> * At Sept 2019 (TBD)<br /> <br /> '''Previous event''': OWASP meetup at the IoT Hacking School of 2018 |([https://hack.foi.hr Info])<br /> '''Previous event''': OWASP meetup at the FSec 2017 ([https://www.flickr.com/photos/58943051@N07/sets/72157667605653398 Photos]) | ([https://fsec.foi.hr Info])<br /> '''Previous event''': OWASP meetup at FSec 2016 ([https://www.flickr.com/photos/58943051@N07/sets/72157673516643570 Photos]) | ([https://fsec.foi.hr Info])<br /> '''Previous event''': [http://www.foi.unizg.hr/Ljetna-skola-aplikacijske-sigurnost-na-FOI-ju OWASP application security summer school ] from 23th to 26th of September, 2014 @ FOI ([https://www.flickr.com/photos/58943051@N07/sets/72157648047647530/ Photos])<br /> '''Previous meetup''': OWASP round table/meetup on 14.9.2015 @ [http://fsec.foi.hr/ FOI/FSEC]<br /> '''Previous meetings''': OWASP regular/meeting on 26.2.2016 at 18:00 (FOI Infoclub, Basement) | [https://www.facebook.com/events/1840212762872033/ Link to FB Event] [http://www.foi.unizg.hr/hr/novosti/razmjena-vjestina-owasp-croatia-meetup Link to Web]<br /> '''Previous meeting''': OWASP Croatia meeting 11.5.2016 at 17:00 (FER Zagreb, Hall B2) | [https://www.facebook.com/events/475076512695702/ Link to FB Event] | [http://lists.owasp.org/pipermail/owasp-croatia/2016-May/000013.html Event details] | [http://lists.owasp.org/pipermail/owasp-croatia/2016-April/000012.html Email CFP] | [[Croatia/presentations]]<br /> <br /> <br /> ==== Croatia OWASP Chapter Leaders ====<br /> The chapter leaders are [mailto:tonimir.kisasondi@owasp.org Tonimir Kisasondi] and [mailto:vlatko.kosturjak@owasp.org Vlatko Kosturjak]<br /> __NOTOC__<br /> &lt;headertabs/&gt;<br /> [[Category:OWASP Chapter]]<br /> [[Category:Europe]]</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=Croatia&diff=245189 2018-11-16T14:11:38Z

<p>Tonimir Kisasondi: </p> <hr /> <div>{{Chapter Template|chaptername=Croatia|extra=The chapter leaders are [mailto:tonimir.kisasondi@owasp.org Tonimir Kisasondi] and [mailto:vlatko.kosturjak@owasp.org Vlatko Kosturjak] |mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Croatia|emailarchives=http://lists.owasp.org/pipermail/owasp-croatia/}}<br /> <br /> If you are interested in helping, organising or holding OWASP meetups, do not hesitate to contact us, Croatia has a very small infosec community and we are very inclusive. If you are interested to be even more active in this area, we are happy to have co-leads. <br /> <br /> <br /> ==== Local News ====<br /> <br /> Welcome. Since our start, we agreed we will have regular meetings in Varaždin and Zagreb in order to make it more attractive. You're invited to subscribe to the mailing list for up2date news and also if you want help in <br /> organising local chapter. Everyone is welcome to join us at our chapter meetings.<br /> <br /> ==== Chapter Meetings ====<br /> '''Regular Meeting Location''': FOI, Pavlinska 2, 42000 Varaždin, Hrvatska at the scene of any FSec Underground meet ([https://www.facebook.com/fsec2017/ Page])<br /> <br /> <br /> '''Previous event''': OWASP meetup at the IoT Hacking School of 2018 |([https://hack.foi.hr Info])<br /> '''Previous event''': OWASP meetup at the FSec 2017 ([https://www.flickr.com/photos/58943051@N07/sets/72157667605653398 Photos]) | ([https://fsec.foi.hr Info])<br /> '''Previous event''': OWASP meetup at FSec 2016 ([https://www.flickr.com/photos/58943051@N07/sets/72157673516643570 Photos]) | ([https://fsec.foi.hr Info])<br /> '''Previous event''': [http://www.foi.unizg.hr/Ljetna-skola-aplikacijske-sigurnost-na-FOI-ju OWASP application security summer school ] from 23th to 26th of September, 2014 @ FOI ([https://www.flickr.com/photos/58943051@N07/sets/72157648047647530/ Photos])<br /> ''' Previous meetup''': OWASP round table/meetup on 14.9.2015 @ [http://fsec.foi.hr/ FOI/FSEC]<br /> '''Previous meetings''': OWASP regular/meeting on 26.2.2016 at 18:00 (FOI Infoclub, Basement) | [https://www.facebook.com/events/1840212762872033/ Link to FB Event] [http://www.foi.unizg.hr/hr/novosti/razmjena-vjestina-owasp-croatia-meetup Link to Web]<br /> '''Previous meeting''': OWASP Croatia meeting 11.5.2016 at 17:00 (FER Zagreb, Hall B2) | [https://www.facebook.com/events/475076512695702/ Link to FB Event] | [http://lists.owasp.org/pipermail/owasp-croatia/2016-May/000013.html Event details] | [http://lists.owasp.org/pipermail/owasp-croatia/2016-April/000012.html Email CFP] | [[Croatia/presentations]]<br /> <br /> <br /> ==== Croatia OWASP Chapter Leaders ====<br /> The chapter leaders are [mailto:tonimir.kisasondi@owasp.org Tonimir Kisasondi] and [mailto:vlatko.kosturjak@owasp.org Vlatko Kosturjak]<br /> __NOTOC__<br /> &lt;headertabs/&gt;<br /> [[Category:OWASP Chapter]]<br /> [[Category:Europe]]</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=Croatia&diff=245188 2018-11-16T13:52:13Z

<p>Tonimir Kisasondi: </p> <hr /> <div>{{Chapter Template|chaptername=Croatia|extra=The chapter leaders are [mailto:tonimir.kisasondi@owasp.org Tonimir Kisasondi] and [mailto:vlatko.kosturjak@owasp.org Vlatko Kosturjak] |mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Croatia|emailarchives=http://lists.owasp.org/pipermail/owasp-croatia/}}<br /> <br /> If you are interested in helping, organising or holding OWASP meetups, do not hesitate to contact us, Croatia has a very small infosec community and we are very inclusive. If you are interested to be even more active in this area, we are happy to have co-leads. <br /> <br /> <br /> ==== Local News ====<br /> <br /> Welcome. Since our start, we agreed we will have regular meetings in Varaždin and Zagreb in order to make it more attractive. You're invited to subscribe to the mailing list for up2date news and also if you want help in <br /> organising local chapter. Everyone is welcome to join us at our chapter meetings.<br /> <br /> ==== Chapter Meetings ====<br /> '''Regular Meeting Location''': FOI, Pavlinska 2, 42000 Varaždin, Hrvatska at the scene of any FSec Underground meet ([https://www.facebook.com/fsec2017/ Page])<br /> <br /> <br /> '''Previous event''': OWASP meetup at the IoT Hacking School of 2018 |([https://hack.foi.hr Info])<br /> '''Previous event''': OWASP meetup at the FSec 2017 ([https://www.flickr.com/photos/58943051@N07/sets/72157667605653398 Photos]) | ([https://fsec.foi.hr Info])<br /> '''Previous event''': OWASP meetup at FSec 2016 ([https://www.flickr.com/photos/58943051@N07/sets/72157673516643570 Photos]) | ([https://fsec.foi.hr Info])<br /> '''Previous event''': [http://www.foi.unizg.hr/Ljetna-skola-aplikacijske-sigurnost-na-FOI-ju OWASP application security summer school ] from 23th to 26th of September, 2014 @ FOI ([https://www.flickr.com/photos/58943051@N07/sets/72157648047647530/ Photos])<br /> ''' Previous meetup''': OWASP round table/meetup on 14.9.2015 @ [http://fsec.foi.hr/ FOI/FSEC]<br /> '''Previous meetings''': OWASP regular/meeting on 26.2.2016 at 18:00 (FOI Infoclub, Basement) | [https://www.facebook.com/events/1840212762872033/ Link to FB Event] [http://www.foi.unizg.hr/hr/novosti/razmjena-vjestina-owasp-croatia-meetup Link to Web]<br /> '''Previous meeting''': OWASP Croatia meeting 11.5.2016 at 17:00 (FER Zagreb, Hall B2) | [https://www.facebook.com/events/475076512695702/ Link to FB Event] | [http://lists.owasp.org/pipermail/owasp-croatia/2016-May/000013.html Event details] | [http://lists.owasp.org/pipermail/owasp-croatia/2016-April/000012.html Email CFP] | [[Croatia/presentations]]<br /> <br /> <br /> ==== Croatia OWASP Chapter Leaders ====<br /> The chapter leaders are [mailto:tonimir.kisasondi@owasp.org Tonimir Kisasondi] and [mailto:vlatko.kosturjak@owasp.org Vlatko Kosturjak]<br /> __NOTOC__<br /> &lt;headertabs/&gt;<br /> [[Category:OWASP Chapter]]<br /> [[Category:Europe]]</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=ASVS_V13_Malicious_Code&diff=244905 2018-11-06T00:11:51Z

<p>Tonimir Kisasondi: Fixed table, made the content readable</p> <hr /> <div>== V13: Malicious Code Verification Requirements ==<br /> '''Control Objective'''<br /> <br /> Ensure that a verified application satisfies the following high level requirements:<br /> <br /> * Malicious activity is handled securely and properly as to not affect the rest of the application.<br /> * Do not have time bombs or other time based attacks built into them<br /> * Do not “phone home” to malicious or unauthorized destinations<br /> * Applications do not have back doors, Easter eggs, salami attacks, or logic flaws that can be controlled by an attacker<br /> <br /> Malicious code is extremely rare, and is difficult to detect. Manual line by line code review can assist looking for logic bombs, but even the most experienced code reviewer will struggle to find malicious code even if they know it exists. This section is not possible to complete without access to source code, including as many third party libraries as possible.<br /> <br /> <br /> '''Security Verification Requirements:'''<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! # !! Description !! L1 !! L2 !! L3 !! Since |<br /> |-<br /> | 13.1 || Verify all malicious activity is adequately sandboxed, containerized or isolated to delay and deter attackers from attacking other applications. || ✓ || ✓ || ✓ || 2.0<br /> |-<br /> | 13.2 || Verify that the application source code, and as many third party libraries as possible, does not contain back doors, Easter eggs, and logic flaws in authentication, access control, input validation, and the business logic of high value transactions. || ✓ || ✓ || ✓ || 3.0.1<br /> |}<br /> <br /> '''References:'''</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=ASVS_V13_Malicious_Code&diff=244904 2018-11-06T00:11:22Z

<p>Tonimir Kisasondi: </p> <hr /> <div>V13: Malicious Code Verification Requirements<br /> <br /> Control Objective<br /> <br /> Ensure that a verified application satisfies the following high level requirements:<br /> <br /> * Malicious activity is handled securely and properly as to not affect the rest of the application.<br /> * Do not have time bombs or other time based attacks built into them<br /> * Do not “phone home” to malicious or unauthorized destinations<br /> * Applications do not have back doors, Easter eggs, salami attacks, or logic flaws that can be controlled by an attacker<br /> <br /> Malicious code is extremely rare, and is difficult to detect. Manual line by line code review can assist looking for logic bombs, but even the most experienced code reviewer will struggle to find malicious code even if they know it exists. This section is not possible to complete without access to source code, including as many third party libraries as possible.<br /> <br /> <br /> Security Verification Requirements<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! # !! Description !! L1 !! L2 !! L3 !! Since |<br /> |-<br /> | 13.1 || Verify all malicious activity is adequately sandboxed, containerized or isolated to delay and deter attackers from attacking other applications. || ✓ || ✓ || ✓ || 2.0<br /> |-<br /> | 13.2 || Verify that the application source code, and as many third party libraries as possible, does not contain back doors, Easter eggs, and logic flaws in authentication, access control, input validation, and the business logic of high value transactions. || ✓ || ✓ || ✓ || 3.0.1<br /> |}<br /> <br /> References</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=User:Tonimir_Kisasondi&diff=244903 2018-11-06T00:10:37Z

<p>Tonimir Kisasondi: </p> <hr /> <div>Tonimir Kišasondi, PhD<br /> <br /> CEO @ Oru, a boutique information security consultancy from Varaždin, Croatia. <br /> <br /> web: www.oru.hr<br /> <br /> twitter: @kisasondi<br /> <br /> wire: @kisasondi <br /> <br /> pgp: 0x00C68442<br /> <br /> pgpid: 77FCA8315CE34BCFB1C01B0CF1D9B3A200C68442</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=ASVS_V13_Malicious_Code&diff=244902 2018-11-06T00:08:42Z

<p>Tonimir Kisasondi: Fixed table, made the content readable.</p> <hr /> <div>== V13: Malicious Code Verification Requirements ==<br /> '''Control Objective:'''<br /> <br /> Ensure that a verified application satisfies the following high level requirements:<br /> <br /> * Malicious activity is handled securely and properly as to not affect the rest of the application.<br /> * Do not have time bombs or other time based attacks built into them<br /> * Do not “phone home” to malicious or unauthorized destinations<br /> * Applications do not have back doors, Easter eggs, salami attacks, or logic flaws that can be controlled by an attacker<br /> <br /> Malicious code is extremely rare, and is difficult to detect. Manual line by line code review can assist looking for logic bombs, but even the most experienced code reviewer will struggle to find malicious code even if they know it exists. This section is not possible to complete without access to source code, including as many third party libraries as possible.<br /> <br /> <br /> '''Security Verification Requirements:'''<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! # !! Description !! L1 !! L2 !! L3 !! Since |<br /> |-<br /> | 13.1 || Verify all malicious activity is adequately sandboxed, containerized or isolated to delay and deter attackers from attacking other applications. || ✓ || ✓ || ✓ || 2.0<br /> |-<br /> | 13.2 || Verify that the application source code, and as many third party libraries as possible, does not contain back doors, Easter eggs, and logic flaws in authentication, access control, input validation, and the business logic of high value transactions. || ✓ || ✓ || ✓ || 3.0.1<br /> |}<br /> <br /> '''References:'''</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=ASVS_V13_Malicious_Code&diff=244901 2018-11-06T00:08:08Z

<p>Tonimir Kisasondi: </p> <hr /> <div>V13: Malicious Code Verification Requirements<br /> <br /> Control Objective<br /> <br /> Ensure that a verified application satisfies the following high level requirements:<br /> <br /> * Malicious activity is handled securely and properly as to not affect the rest of the application.<br /> * Do not have time bombs or other time based attacks built into them<br /> * Do not “phone home” to malicious or unauthorized destinations<br /> * Applications do not have back doors, Easter eggs, salami attacks, or logic flaws that can be controlled by an attacker<br /> <br /> Malicious code is extremely rare, and is difficult to detect. Manual line by line code review can assist looking for logic bombs, but even the most experienced code reviewer will struggle to find malicious code even if they know it exists. This section is not possible to complete without access to source code, including as many third party libraries as possible.<br /> <br /> <br /> Security Verification Requirements<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! # !! Description !! L1 !! L2 !! L3 !! Since |<br /> |-<br /> | 13.1 || Verify all malicious activity is adequately sandboxed, containerized or isolated to delay and deter attackers from attacking other applications. || ✓ || ✓ || ✓ || 2.0<br /> |-<br /> | 13.2 || Verify that the application source code, and as many third party libraries as possible, does not contain back doors, Easter eggs, and logic flaws in authentication, access control, input validation, and the business logic of high value transactions. || ✓ || ✓ || ✓ || 3.0.1<br /> |}<br /> <br /> <br /> References</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=ASVS_V15_Business_Logic_Flaws&diff=244900 2018-11-06T00:07:31Z

<p>Tonimir Kisasondi: Fixed table, made the content readable.</p> <hr /> <div>== V15: Business Logic Verification Requirements ==<br /> '''Control Objective:'''<br /> <br /> Ensure that a verified application satisfies the following high level requirements:<br /> <br /> * The business logic flow is sequential and in order<br /> * Business logic includes limits to detect and prevent automated attacks, such as continuous small funds transfers, or adding a million friends one at a time, and so on.<br /> * High value business logic flows have considered abuse cases and malicious actors, and have protections against spoofing, tampering, repudiation, information disclosure, and elevation of privilege attacks.<br /> <br /> <br /> '''Security Verification Requirements:'''<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! # !! Description !! L1 !! L2 !! L3 !! Since |<br /> |-<br /> | 15.1 || Verify the application will only process business logic flows in sequential step order, with all steps being processed in realistic human time, and not process out of order, skipped steps, process steps from another user, or too quickly submitted transactions. || || ✓ || ✓ || 2.0<br /> |-<br /> | 15.2 || Verify the application has business limits and correctly enforces on a per user basis, with configurable alerting and automated reactions to automated or unusual attack. || || ✓ || ✓ || 2.0<br /> |}<br /> <br /> '''References:'''<br /> <br /> For more information, see also:<br /> <br /> * [OWASP Testing Guide 4.0: Business Logic Testing ](https://www.owasp.org/index.php/Testing_for_business_logic)<br /> * [OWASP Cheat Sheet](https://www.owasp.org/index.php/Business_Logic_Security_Cheat_Sheet)</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=ASVS_V15_Business_Logic_Flaws&diff=244899 2018-11-06T00:07:04Z

<p>Tonimir Kisasondi: </p> <hr /> <div>V15: Business Logic Verification Requirements<br /> <br /> Control Objective<br /> <br /> Ensure that a verified application satisfies the following high level requirements:<br /> <br /> * The business logic flow is sequential and in order<br /> * Business logic includes limits to detect and prevent automated attacks, such as continuous small funds transfers, or adding a million friends one at a time, and so on.<br /> * High value business logic flows have considered abuse cases and malicious actors, and have protections against spoofing, tampering, repudiation, information disclosure, and elevation of privilege attacks.<br /> <br /> <br /> Security Verification Requirements<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! # !! Description !! L1 !! L2 !! L3 !! Since |<br /> |-<br /> | 15.1 || Verify the application will only process business logic flows in sequential step order, with all steps being processed in realistic human time, and not process out of order, skipped steps, process steps from another user, or too quickly submitted transactions. || || ✓ || ✓ || 2.0<br /> |-<br /> | 15.2 || Verify the application has business limits and correctly enforces on a per user basis, with configurable alerting and automated reactions to automated or unusual attack. || || ✓ || ✓ || 2.0<br /> |}<br /> <br /> <br /> References<br /> <br /> For more information, see also:<br /> <br /> * [OWASP Testing Guide 4.0: Business Logic Testing ](https://www.owasp.org/index.php/Testing_for_business_logic)<br /> * [OWASP Cheat Sheet](https://www.owasp.org/index.php/Business_Logic_Security_Cheat_Sheet)</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=ASVS_V16_Files_and_Resources&diff=244898 2018-11-06T00:05:21Z

<p>Tonimir Kisasondi: Fixed table, made the content readable.</p> <hr /> <div>== V16: File and Resources Verification Requirements ==<br /> '''Control Objective'''<br /> <br /> Ensure that a verified application satisfies the following high level requirements:<br /> <br /> * Untrusted file data should be handled accordingly and in a secure manner<br /> * Obtained from untrusted sources are stored outside the webroot and limited permissions.<br /> <br /> <br /> '''Security Verification Requirements:'''<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! # !! Description !! L1 !! L2 !! L3 !! Since |<br /> |-<br /> | 16.1 || Verify that URL redirects and forwards only allow whitelisted destinations, or show a warning when redirecting to potentially untrusted content. || ✓ || ✓ || ✓ || 2.0<br /> |-<br /> | 16.2 || Verify that untrusted file data submitted to the application is not used directly with file I/O commands, particularly to protect against path traversal, local file include, file mime type, reflective file download, and OS command injection vulnerabilities. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 16.3 || Verify that files obtained from untrusted sources are validated to be of expected type and scanned by antivirus scanners to prevent upload of known malicious content. || ✓ || ✓ || ✓ || 2.0<br /> |-<br /> | 16.4 || Verify that untrusted data is not used within inclusion, class loader, or reflection capabilities to prevent remote/local code execution vulnerabilities. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 16.5 || Verify that untrusted data is not used within cross-domain resource sharing (CORS) to protect against arbitrary remote content. || ✓ || ✓ || ✓ || 2.0<br /> |-<br /> | 16.6 || Verify that files obtained from untrusted sources are stored outside the webroot, with limited permissions, preferably with strong validation. || || ✓ || ✓ || 3.0<br /> |-<br /> | 16.7 || Verify that the web or application server is configured by default to deny access to remote resources or systems outside the web or application server. || || ✓ || ✓ || 2.0<br /> |-<br /> | 16.8 || Verify the application code does not execute uploaded data obtained from untrusted sources. || ✓ || ✓ || ✓ || 3.0<br /> |-<br /> | 16.9 || Verify that unsupported, insecure or deprecated client-side technologies are not used, such as NSAPI plugins, Flash, Shockwave, Active-X, Silverlight, NACL, or client-side Java applets. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 16.10 || Verify that the cross-domain resource sharing (CORS) Access-Control-Allow-Origin header does not simply reflect the request's origin header or support the &quot;null&quot; origin. || ✓ || ✓ || ✓ || 3.1<br /> |}<br /> <br /> '''References:'''<br /> <br /> For more information, see also:<br /> <br /> * [File Extension Handling for Sensitive Information](https://www.owasp.org/index.php/Unrestricted_File_Upload)<br /> * [Reflective file download by Oren Hatif](https://www.trustwave.com/Resources/SpiderLabs-Blog/Reflected-File-Download---A-New-Web-Attack-Vector/)</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=ASVS_V16_Files_and_Resources&diff=244897 2018-11-06T00:04:54Z

<p>Tonimir Kisasondi: </p> <hr /> <div>V16: File and Resources Verification Requirements<br /> <br /> Control Objective<br /> <br /> Ensure that a verified application satisfies the following high level requirements:<br /> <br /> * Untrusted file data should be handled accordingly and in a secure manner<br /> * Obtained from untrusted sources are stored outside the webroot and limited permissions.<br /> <br /> <br /> Security Verification Requirements<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! # !! Description !! L1 !! L2 !! L3 !! Since |<br /> |-<br /> | 16.1 || Verify that URL redirects and forwards only allow whitelisted destinations, or show a warning when redirecting to potentially untrusted content. || ✓ || ✓ || ✓ || 2.0<br /> |-<br /> | 16.2 || Verify that untrusted file data submitted to the application is not used directly with file I/O commands, particularly to protect against path traversal, local file include, file mime type, reflective file download, and OS command injection vulnerabilities. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 16.3 || Verify that files obtained from untrusted sources are validated to be of expected type and scanned by antivirus scanners to prevent upload of known malicious content. || ✓ || ✓ || ✓ || 2.0<br /> |-<br /> | 16.4 || Verify that untrusted data is not used within inclusion, class loader, or reflection capabilities to prevent remote/local code execution vulnerabilities. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 16.5 || Verify that untrusted data is not used within cross-domain resource sharing (CORS) to protect against arbitrary remote content. || ✓ || ✓ || ✓ || 2.0<br /> |-<br /> | 16.6 || Verify that files obtained from untrusted sources are stored outside the webroot, with limited permissions, preferably with strong validation. || || ✓ || ✓ || 3.0<br /> |-<br /> | 16.7 || Verify that the web or application server is configured by default to deny access to remote resources or systems outside the web or application server. || || ✓ || ✓ || 2.0<br /> |-<br /> | 16.8 || Verify the application code does not execute uploaded data obtained from untrusted sources. || ✓ || ✓ || ✓ || 3.0<br /> |-<br /> | 16.9 || Verify that unsupported, insecure or deprecated client-side technologies are not used, such as NSAPI plugins, Flash, Shockwave, Active-X, Silverlight, NACL, or client-side Java applets. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 16.10 || Verify that the cross-domain resource sharing (CORS) Access-Control-Allow-Origin header does not simply reflect the request's origin header or support the &quot;null&quot; origin. || ✓ || ✓ || ✓ || 3.1<br /> |}<br /> <br /> <br /> References<br /> <br /> For more information, see also:<br /> <br /> * [File Extension Handling for Sensitive Information](https://www.owasp.org/index.php/Unrestricted_File_Upload)<br /> * [Reflective file download by Oren Hatif](https://www.trustwave.com/Resources/SpiderLabs-Blog/Reflected-File-Download---A-New-Web-Attack-Vector/)</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=ASVS_V18_API&diff=244896 2018-11-06T00:03:57Z

<p>Tonimir Kisasondi: Fixed table, made the content readable.</p> <hr /> <div>== V18: API and Web Service Verification Requirements ==<br /> '''Control Objective'''<br /> <br /> Ensure that a verified application that uses RESTful or SOAP based web services has:<br /> <br /> * Adequate authentication, session management and authorization of all web services<br /> * Input validation of all parameters that transit from a lower to higher trust level<br /> * Basic interoperability of SOAP web services layer to promote API use<br /> <br /> <br /> '''Security Verification Requirements:'''<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! # !! Description !! L1 !! L2 !! L3 !! Since |<br /> |-<br /> | 18.1 || Verify that the same encoding style is used between the client and the server. || ✓ || ✓ || ✓ || 3.0<br /> |-<br /> | 18.2 || Verify that access to administration and management functions within the Web Service Application is limited to web service administrators. || ✓ || ✓ || ✓ || 3.0<br /> |-<br /> | 18.3 || Verify that XML or JSON schema is in place and verified before accepting input. || ✓ || ✓ || ✓ || 3.0<br /> |-<br /> | 18.4 || Verify that all input is limited to an appropriate size limit. || ✓ || ✓ || ✓ || 3.0<br /> |-<br /> | 18.5 || Verify that SOAP based web services are compliant with Web Services-Interoperability (WS-I) Basic Profile at minimum. This essentially means TLS encryption. || ✓ || ✓ || ✓ || 3.0.1<br /> |-<br /> | 18.7 || Verify that the REST service is protected from Cross-Site Request Forgery via the use of at least one or more of the following: double submit cookie pattern, CSRF nonces, ORIGIN request header checks, and referrer request header checks. || ✓ || ✓ || ✓ || 3.0.1<br /> |-<br /> | 18.8 || Verify the REST service explicitly check the incoming Content-Type to be the expected one, such as application/xml or application/json. || || ✓ || ✓ || 3.0<br /> |-<br /> | 18.9 || Verify that the message payload is signed to ensure reliable transport between client and service, using JSON Web Signing or WS-Security for SOAP requests. || || ✓ || ✓ || 3.0.1<br /> |-<br /> | 18.10 || Verify that alternative and less secure access paths do not exist. || || ✓ || ✓ || 3.0<br /> |}<br /> <br /> '''References:'''<br /> <br /> For more information, see also:<br /> <br /> * [OWASP Testing Guide 4.0: Configuration and Deployment Management Testing](https://www.owasp.org/index.php/Testing_for_configuration_management)<br /> * [OWASP Cross-Site Request Forgery cheat sheet](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet)<br /> * [JSON Web Tokens (and Signing)](https://jwt.io/)</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=ASVS_V18_API&diff=244895 2018-11-06T00:03:32Z

<p>Tonimir Kisasondi: </p> <hr /> <div>V18: API and Web Service Verification Requirements<br /> <br /> Control Objective<br /> <br /> Ensure that a verified application that uses RESTful or SOAP based web services has:<br /> <br /> * Adequate authentication, session management and authorization of all web services<br /> * Input validation of all parameters that transit from a lower to higher trust level<br /> * Basic interoperability of SOAP web services layer to promote API use<br /> <br /> <br /> Security Verification Requirements<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! # !! Description !! L1 !! L2 !! L3 !! Since |<br /> |-<br /> | 18.1 || Verify that the same encoding style is used between the client and the server. || ✓ || ✓ || ✓ || 3.0<br /> |-<br /> | 18.2 || Verify that access to administration and management functions within the Web Service Application is limited to web service administrators. || ✓ || ✓ || ✓ || 3.0<br /> |-<br /> | 18.3 || Verify that XML or JSON schema is in place and verified before accepting input. || ✓ || ✓ || ✓ || 3.0<br /> |-<br /> | 18.4 || Verify that all input is limited to an appropriate size limit. || ✓ || ✓ || ✓ || 3.0<br /> |-<br /> | 18.5 || Verify that SOAP based web services are compliant with Web Services-Interoperability (WS-I) Basic Profile at minimum. This essentially means TLS encryption. || ✓ || ✓ || ✓ || 3.0.1<br /> |-<br /> | 18.7 || Verify that the REST service is protected from Cross-Site Request Forgery via the use of at least one or more of the following: double submit cookie pattern, CSRF nonces, ORIGIN request header checks, and referrer request header checks. || ✓ || ✓ || ✓ || 3.0.1<br /> |-<br /> | 18.8 || Verify the REST service explicitly check the incoming Content-Type to be the expected one, such as application/xml or application/json. || || ✓ || ✓ || 3.0<br /> |-<br /> | 18.9 || Verify that the message payload is signed to ensure reliable transport between client and service, using JSON Web Signing or WS-Security for SOAP requests. || || ✓ || ✓ || 3.0.1<br /> |-<br /> | 18.10 || Verify that alternative and less secure access paths do not exist. || || ✓ || ✓ || 3.0<br /> |}<br /> <br /> <br /> References<br /> <br /> For more information, see also:<br /> <br /> * [OWASP Testing Guide 4.0: Configuration and Deployment Management Testing](https://www.owasp.org/index.php/Testing_for_configuration_management)<br /> * [OWASP Cross-Site Request Forgery cheat sheet](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet)<br /> * [JSON Web Tokens (and Signing)](https://jwt.io/)</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=ASVS_V19_Configuration&diff=244894 2018-11-06T00:02:55Z

<p>Tonimir Kisasondi: Fixed table, made the content readable.</p> <hr /> <div>== V19: Configuration Verification Requirements ==<br /> '''Control Objective:'''<br /> <br /> Ensure that a verified application has:<br /> <br /> * Up to date libraries and platform(s).<br /> * A secure by default configuration.<br /> * Sufficient hardening that user initiated changes to default configuration do not unnecessarily expose or create security weaknesses or flaws to underlying systems.<br /> <br /> '''Security Verification Requirements:'''<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! # !! Description !! L1 !! L2 !! L3 !! Since |<br /> |-<br /> | 19.1 || Verify that all components are up to date with proper security configuration(s) and version(s). This should include removal of unneeded configurations and folders such as sample applications, platform documentation, and default or example users. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 19.2 || Verify that communications between components, such as between the application server and the database server, are encrypted, particularly when the components are in different containers or on different systems. || || ✓ || ✓ || 3.1<br /> |-<br /> | 19.3 || Verify that communications between components, such as between the application server and the database server, is authenticated using an account with the least necessary privileges. || || ✓ || ✓ || 3.1<br /> |-<br /> | 19.4 || Verify application deployments are adequately sandboxed, containerized or isolated to delay and deter attackers from attacking other applications. || || ✓ || ✓ || 3.0<br /> |-<br /> | 19.5 || Verify that the application build and deployment processes are performed in a secure and repeatable method, such as CI / CD automation and automated configuration management. || || ✓ || ✓ || 3.1<br /> |-<br /> | 19.6 || Verify that authorised administrators have the capability to verify the integrity of all security-relevant configurations to detect tampering. || || || ✓ || 3.1<br /> |-<br /> | 19.7 || Verify that all application components are signed. || || || ✓ || 3.0<br /> |-<br /> | 19.8 || Verify that third party components come from trusted repositories. || || || ✓ || 3.0<br /> |-<br /> | 19.9 || Verify that build processes for system level languages have all security flags enabled, such as ASLR, DEP, and security checks. || || || ✓ || 3.0<br /> |-<br /> | 19.10 || Verify that all application assets are hosted by the application, such as JavaScript libraries, CSS stylesheets and web fonts are hosted by the application rather than rely on a CDN or external provider. || || || ✓ || 3.0.1<br /> |-<br /> | 19.11 || Verify that all application components, services, and servers each use their own low privilege service account, that is not shared between applications nor used by administrators. || || ✓ || ✓ || 3.1<br /> |}<br /> <br /> '''References:'''<br /> <br /> For more information, see also:<br /> <br /> * [OWASP Testing Guide 4.0: Configuration and Deployment Management Testing](https://www.owasp.org/index.php/Testing_for_configuration_management)</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=ASVS_V19_Configuration&diff=244893 2018-11-06T00:02:22Z

<p>Tonimir Kisasondi: </p> <hr /> <div>V19: Configuration Verification Requirements<br /> <br /> Control Objective<br /> <br /> Ensure that a verified application has:<br /> <br /> * Up to date libraries and platform(s).<br /> * A secure by default configuration.<br /> * Sufficient hardening that user initiated changes to default configuration do not unnecessarily expose or create security weaknesses or flaws to underlying systems.<br /> <br /> <br /> Security Verification Requirements:<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! # !! Description !! L1 !! L2 !! L3 !! Since |<br /> |-<br /> | 19.1 || Verify that all components are up to date with proper security configuration(s) and version(s). This should include removal of unneeded configurations and folders such as sample applications, platform documentation, and default or example users. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 19.2 || Verify that communications between components, such as between the application server and the database server, are encrypted, particularly when the components are in different containers or on different systems. || || ✓ || ✓ || 3.1<br /> |-<br /> | 19.3 || Verify that communications between components, such as between the application server and the database server, is authenticated using an account with the least necessary privileges. || || ✓ || ✓ || 3.1<br /> |-<br /> | 19.4 || Verify application deployments are adequately sandboxed, containerized or isolated to delay and deter attackers from attacking other applications. || || ✓ || ✓ || 3.0<br /> |-<br /> | 19.5 || Verify that the application build and deployment processes are performed in a secure and repeatable method, such as CI / CD automation and automated configuration management. || || ✓ || ✓ || 3.1<br /> |-<br /> | 19.6 || Verify that authorised administrators have the capability to verify the integrity of all security-relevant configurations to detect tampering. || || || ✓ || 3.1<br /> |-<br /> | 19.7 || Verify that all application components are signed. || || || ✓ || 3.0<br /> |-<br /> | 19.8 || Verify that third party components come from trusted repositories. || || || ✓ || 3.0<br /> |-<br /> | 19.9 || Verify that build processes for system level languages have all security flags enabled, such as ASLR, DEP, and security checks. || || || ✓ || 3.0<br /> |-<br /> | 19.10 || Verify that all application assets are hosted by the application, such as JavaScript libraries, CSS stylesheets and web fonts are hosted by the application rather than rely on a CDN or external provider. || || || ✓ || 3.0.1<br /> |-<br /> | 19.11 || Verify that all application components, services, and servers each use their own low privilege service account, that is not shared between applications nor used by administrators. || || ✓ || ✓ || 3.1<br /> |}<br /> <br /> <br /> References:<br /> <br /> For more information, see also:<br /> <br /> * [OWASP Testing Guide 4.0: Configuration and Deployment Management Testing](https://www.owasp.org/index.php/Testing_for_configuration_management)</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=ASVS_V20_Internet_of_Things&diff=244892 2018-11-06T00:01:20Z

<p>Tonimir Kisasondi: </p> <hr /> <div>=== V20: Internet of Things Verification Requirements ===<br /> This section contains controls that are Embedded/IoT device specific. These controls must be taken in conjunction with all other sections of the relevant ASVS Verification Level.<br /> <br /> '''Control Objective:'''<br /> <br /> Embedded/IoT devices should:<br /> <br /> * Have the same level of security controls within the device as found in the server, by enforcing security controls in a trusted environment.<br /> * Sensitive data stored on the device should be done so in a secure manner.<br /> * All sensitive data transmitted from the device should utilize transport layer security.<br /> <br /> <br /> '''Security Verification Requirements:'''<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! # !! Description !! L1 !! L2 !! L3 !! Since |<br /> |-<br /> | 20.1 || Verify that application layer debugging interfaces such USB or serial are disabled. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that cryptographic keys are unique to each individual device. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that memory protection controls such as ASLR and DEP are enabled by the embedded/IoT operating system, if applicable. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that on-chip debugging interfaces such as JTAG or SWD are disabled or that available protection mechanism is enabled and configured appropriately. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that physical debug headers are not present on the device. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that sensitive data is not stored unencrypted on the device. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that the device prevents leaking of sensitive information. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that the firmware apps protect data-in-transit using transport security. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that the firmware apps validate the digital signature of server connections. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that wireless communications are mutually authenticated. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that wireless communications are sent over an encrypted channel. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that the firmware apps pin the digital signature to a trusted server(s). || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify the presence of physical tamper resistance and/or tamper detection features, including epoxy. || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that identifying markings on chips have been removed. || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that any available Intellectual Property protection technologies provided by the chip manufacturer are enabled. || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify security controls are in place to hinder firmware reverse engineering (e.g., removal of verbose debugging strings). || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify the device validates the boot image signature before loading. || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that the firmware update process is not vulnerable to time-of-check vs time-of-use attacks. || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify the device uses code signing and validates firmware upgrade files before installing. || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that the device cannot be downgraded to old versions of valid firmware. || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify usage of cryptographically secure pseudo-random number generator on embedded device (e.g., using chip-provided random number generators). || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that the device wipes firmware and sensitive data upon detection of tampering or receipt of invalid message. || || || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that only microcontrollers that support disabling debugging interfaces (e.g. JTAG, SWD) are used. || || || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that only microcontrollers that provide substantial protection from de-capping and side channel attacks are used. || || || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that sensitive traces are not exposed to outer layers of the printed circuit board. || || || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that inter-chip communication is encrypted. || || || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify the device uses code signing and validates code before execution. || || || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that sensitive information maintained in memory is overwritten with zeros as soon as it is no longer required. || || || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that the firmware apps utilize kernel containers for isolation between apps. || || || ✓ || 3.1<br /> |}<br /> <br /> '''References:'''<br /> <br /> For more information, see also:<br /> <br /> * [OWASP Internet of Things Top 10](https://www.owasp.org/images/7/71/Internet_of_Things_Top_Ten_2014-OWASP.pdf)<br /> * [OWASP Internet of Things Project](https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project)<br /> * [Trudy TCP Proxy Tool](https://github.com/praetorian-inc/trudy)</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=ASVS_V20_Internet_of_Things&diff=244891 2018-11-06T00:01:09Z

<p>Tonimir Kisasondi: Fixed table, made the text readable.</p> <hr /> <div>{{taggedDocument<br /> }}<br /> <br /> === V20: Internet of Things Verification Requirements ===<br /> This section contains controls that are Embedded/IoT device specific. These controls must be taken in conjunction with all other sections of the relevant ASVS Verification Level.<br /> <br /> '''Control Objective:'''<br /> <br /> Embedded/IoT devices should:<br /> <br /> * Have the same level of security controls within the device as found in the server, by enforcing security controls in a trusted environment.<br /> * Sensitive data stored on the device should be done so in a secure manner.<br /> * All sensitive data transmitted from the device should utilize transport layer security.<br /> <br /> <br /> '''Security Verification Requirements:'''<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! # !! Description !! L1 !! L2 !! L3 !! Since |<br /> |-<br /> | 20.1 || Verify that application layer debugging interfaces such USB or serial are disabled. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that cryptographic keys are unique to each individual device. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that memory protection controls such as ASLR and DEP are enabled by the embedded/IoT operating system, if applicable. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that on-chip debugging interfaces such as JTAG or SWD are disabled or that available protection mechanism is enabled and configured appropriately. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that physical debug headers are not present on the device. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that sensitive data is not stored unencrypted on the device. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that the device prevents leaking of sensitive information. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that the firmware apps protect data-in-transit using transport security. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that the firmware apps validate the digital signature of server connections. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that wireless communications are mutually authenticated. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that wireless communications are sent over an encrypted channel. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that the firmware apps pin the digital signature to a trusted server(s). || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify the presence of physical tamper resistance and/or tamper detection features, including epoxy. || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that identifying markings on chips have been removed. || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that any available Intellectual Property protection technologies provided by the chip manufacturer are enabled. || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify security controls are in place to hinder firmware reverse engineering (e.g., removal of verbose debugging strings). || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify the device validates the boot image signature before loading. || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that the firmware update process is not vulnerable to time-of-check vs time-of-use attacks. || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify the device uses code signing and validates firmware upgrade files before installing. || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that the device cannot be downgraded to old versions of valid firmware. || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify usage of cryptographically secure pseudo-random number generator on embedded device (e.g., using chip-provided random number generators). || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that the device wipes firmware and sensitive data upon detection of tampering or receipt of invalid message. || || || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that only microcontrollers that support disabling debugging interfaces (e.g. JTAG, SWD) are used. || || || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that only microcontrollers that provide substantial protection from de-capping and side channel attacks are used. || || || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that sensitive traces are not exposed to outer layers of the printed circuit board. || || || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that inter-chip communication is encrypted. || || || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify the device uses code signing and validates code before execution. || || || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that sensitive information maintained in memory is overwritten with zeros as soon as it is no longer required. || || || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that the firmware apps utilize kernel containers for isolation between apps. || || || ✓ || 3.1<br /> |}<br /> <br /> '''References:'''<br /> <br /> For more information, see also:<br /> <br /> * [OWASP Internet of Things Top 10](https://www.owasp.org/images/7/71/Internet_of_Things_Top_Ten_2014-OWASP.pdf)<br /> * [OWASP Internet of Things Project](https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project)<br /> * [Trudy TCP Proxy Tool](https://github.com/praetorian-inc/trudy)</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=ASVS_V20_Internet_of_Things&diff=244890 2018-11-06T00:00:12Z

<p>Tonimir Kisasondi: </p> <hr /> <div>{{taggedDocument<br /> | type=design<br /> }}<br /> <br /> V20: Internet of Things Verification Requirements<br /> This section contains controls that are Embedded/IoT device specific. These controls must be taken in conjunction with all other sections of the relevant ASVS Verification Level.<br /> <br /> Control Objective<br /> <br /> Embedded/IoT devices should:<br /> <br /> * Have the same level of security controls within the device as found in the server, by enforcing security controls in a trusted environment.<br /> * Sensitive data stored on the device should be done so in a secure manner.<br /> * All sensitive data transmitted from the device should utilize transport layer security.<br /> <br /> <br /> Security Verification Requirements<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! # !! Description !! L1 !! L2 !! L3 !! Since |<br /> |-<br /> | 20.1 || Verify that application layer debugging interfaces such USB or serial are disabled. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that cryptographic keys are unique to each individual device. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that memory protection controls such as ASLR and DEP are enabled by the embedded/IoT operating system, if applicable. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that on-chip debugging interfaces such as JTAG or SWD are disabled or that available protection mechanism is enabled and configured appropriately. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that physical debug headers are not present on the device. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that sensitive data is not stored unencrypted on the device. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that the device prevents leaking of sensitive information. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that the firmware apps protect data-in-transit using transport security. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that the firmware apps validate the digital signature of server connections. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that wireless communications are mutually authenticated. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that wireless communications are sent over an encrypted channel. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that the firmware apps pin the digital signature to a trusted server(s). || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify the presence of physical tamper resistance and/or tamper detection features, including epoxy. || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that identifying markings on chips have been removed. || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that any available Intellectual Property protection technologies provided by the chip manufacturer are enabled. || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify security controls are in place to hinder firmware reverse engineering (e.g., removal of verbose debugging strings). || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify the device validates the boot image signature before loading. || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that the firmware update process is not vulnerable to time-of-check vs time-of-use attacks. || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify the device uses code signing and validates firmware upgrade files before installing. || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that the device cannot be downgraded to old versions of valid firmware. || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify usage of cryptographically secure pseudo-random number generator on embedded device (e.g., using chip-provided random number generators). || || ✓ || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that the device wipes firmware and sensitive data upon detection of tampering or receipt of invalid message. || || || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that only microcontrollers that support disabling debugging interfaces (e.g. JTAG, SWD) are used. || || || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that only microcontrollers that provide substantial protection from de-capping and side channel attacks are used. || || || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that sensitive traces are not exposed to outer layers of the printed circuit board. || || || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that inter-chip communication is encrypted. || || || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify the device uses code signing and validates code before execution. || || || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that sensitive information maintained in memory is overwritten with zeros as soon as it is no longer required. || || || ✓ || 3.1<br /> |-<br /> | 20.1 || Verify that the firmware apps utilize kernel containers for isolation between apps. || || || ✓ || 3.1<br /> |}<br /> <br /> <br /> References:<br /> <br /> For more information, see also:<br /> <br /> * [OWASP Internet of Things Top 10](https://www.owasp.org/images/7/71/Internet_of_Things_Top_Ten_2014-OWASP.pdf)<br /> * [OWASP Internet of Things Project](https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project)<br /> * [Trudy TCP Proxy Tool](https://github.com/praetorian-inc/trudy)</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=ASVS_V10_Communications&diff=244889 2018-11-05T23:58:21Z

<p>Tonimir Kisasondi: Fixed table, made the content readable</p> <hr /> <div>== V10: Communications Verification Requirements ==<br /> '''Control Objective:'''<br /> <br /> Ensure that a verified application satisfies the following high level requirements:<br /> <br /> * That TLS is used where sensitive data is transmitted.<br /> * That strong algorithms and ciphers are used at all times.<br /> <br /> '''Security Verification Requirements:'''<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! # !! Description !! L1 !! L2 !! L3 !! Since |<br /> |-<br /> | 10.1 || Verify that a path can be built from a trusted CA to each Transport Layer Security (TLS) server certificate, and that each server certificate is valid. || ✓ || ✓ || ✓ || 1.0<br /> |-<br /> | 10.1 || Verify that TLS is used for all connections (including both external and backend connections) that are authenticated or that involve sensitive data or functions, and does not fall back to insecure or unencrypted protocols. Ensure the strongest alternative is the preferred algorithm. || ✓ || ✓ || ✓ || 3.0<br /> |-<br /> | 10.1 || Verify that backend TLS connection failures are logged. || || || ✓ || 1.0<br /> |-<br /> | 10.1 || Verify that certificate paths are built and verified for all client certificates using configured trust anchors and revocation information. || || || ✓ || 1.0<br /> |-<br /> | 10.1 || Verify that all connections to external systems that involve sensitive information or functions are authenticated. || || ✓ || ✓ || 1.0<br /> |-<br /> | 10.1 || Verify that there is a single standard TLS implementation that is used by the application that is configured to operate in an approved mode of operation. || || || ✓ || 1.0<br /> |-<br /> | 10.1 || Verify that TLS certificate public key pinning (HPKP) is implemented with production and backup public keys. For more information, please see the references below. || || ✓ || ✓ || 3.0.1<br /> |-<br /> | 10.1 || Verify that HTTP Strict Transport Security headers are included on all requests and for all subdomains, such as Strict-Transport-Security: max-age=15724800; includeSubdomains || ✓ || ✓ || ✓ || 3.0<br /> |-<br /> | 10.1 || Verify that production website URL has been submitted to preloaded list of Strict Transport Security domains maintained by web browser vendors. Please see the references below. || || || ✓ || 3.0<br /> |-<br /> | 10.1 || Verify that perfect forward secrecy is configured to mitigate passive attackers recording traffic. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 10.1 || Verify that proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled and configured. || ✓ || ✓ || ✓ || 3.0<br /> |-<br /> | 10.1 || Verify that only strong algorithms, ciphers, and protocols are used, through all the certificate hierarchy, including root and intermediary certificates of your selected certifying authority. || ✓ || ✓ || ✓ || 3.0<br /> |-<br /> | 10.1 || Verify that the TLS settings are in line with current leading practice, particularly as common configurations, ciphers, and algorithms become insecure. || ✓ || ✓ || ✓ || 3.0<br /> |}<br /> <br /> '''References:'''<br /> <br /> For more information, see also:<br /> <br /> * [OWASP – TLS Cheat Sheet. ](https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet)<br /> * [Notes on “Approved modes of TLS”. In the past, the ASVS referred to the US standard FIPS 140-2, but as a global standard, applying US standards this can be difficult, contradictory, or confusing to apply. A better method of achieving compliance with 10.8 would be to review guides such as (https://wiki.mozilla.org/Security/Server_Side_TLS), generate known good configurations (https://mozilla.github.io/server-side-tls/ssl-config-generator/), and use known TLS evaluation tools, such as sslyze, various vulnerability scanners or trusted TLS online assessment services to obtain a desired level of security. In general, we see non-compliance for this section being the use of outdated or insecure ciphers and algorithms, the lack of perfect forward secrecy, outdated or insecure SSL protocols, weak preferred ciphers, and so on.]<br /> * [Certificate pinning. For more information please review ](https://tools.ietf.org/html/rfc7469.)The rationale behind certificate pinning for production and backup keys is business continuity - see (https://noncombatant.org/2015/05/01/about-http-public-key-pinning/)<br /> * [OWASP Certificate Pinning Cheat Sheet](https://www.owasp.org/index.php/Pinning_Cheat_Sheet)<br /> * [OWASP Certificate and Public Key Pinning](https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning)<br /> * [Time of first use (TOFU) Pinning](https://developer.mozilla.org/en/docs/Web/Security/Public_Key_Pinning)<br /> * [Pre-loading HTTP Strict Transport Security](https://www.chromium.org/hsts)</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=ASVS_V10_Communications&diff=244888 2018-11-05T23:57:51Z

<p>Tonimir Kisasondi: </p> <hr /> <div>V10: Communications Verification Requirements<br /> <br /> Control Objective<br /> <br /> Ensure that a verified application satisfies the following high level requirements:<br /> <br /> * That TLS is used where sensitive data is transmitted.<br /> * That strong algorithms and ciphers are used at all times.<br /> <br /> Security Verification Requirements:<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! # !! Description !! L1 !! L2 !! L3 !! Since |<br /> |-<br /> | 10.1 || Verify that a path can be built from a trusted CA to each Transport Layer Security (TLS) server certificate, and that each server certificate is valid. || ✓ || ✓ || ✓ || 1.0<br /> |-<br /> | 10.1 || Verify that TLS is used for all connections (including both external and backend connections) that are authenticated or that involve sensitive data or functions, and does not fall back to insecure or unencrypted protocols. Ensure the strongest alternative is the preferred algorithm. || ✓ || ✓ || ✓ || 3.0<br /> |-<br /> | 10.1 || Verify that backend TLS connection failures are logged. || || || ✓ || 1.0<br /> |-<br /> | 10.1 || Verify that certificate paths are built and verified for all client certificates using configured trust anchors and revocation information. || || || ✓ || 1.0<br /> |-<br /> | 10.1 || Verify that all connections to external systems that involve sensitive information or functions are authenticated. || || ✓ || ✓ || 1.0<br /> |-<br /> | 10.1 || Verify that there is a single standard TLS implementation that is used by the application that is configured to operate in an approved mode of operation. || || || ✓ || 1.0<br /> |-<br /> | 10.1 || Verify that TLS certificate public key pinning (HPKP) is implemented with production and backup public keys. For more information, please see the references below. || || ✓ || ✓ || 3.0.1<br /> |-<br /> | 10.1 || Verify that HTTP Strict Transport Security headers are included on all requests and for all subdomains, such as Strict-Transport-Security: max-age=15724800; includeSubdomains || ✓ || ✓ || ✓ || 3.0<br /> |-<br /> | 10.1 || Verify that production website URL has been submitted to preloaded list of Strict Transport Security domains maintained by web browser vendors. Please see the references below. || || || ✓ || 3.0<br /> |-<br /> | 10.1 || Verify that perfect forward secrecy is configured to mitigate passive attackers recording traffic. || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 10.1 || Verify that proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled and configured. || ✓ || ✓ || ✓ || 3.0<br /> |-<br /> | 10.1 || Verify that only strong algorithms, ciphers, and protocols are used, through all the certificate hierarchy, including root and intermediary certificates of your selected certifying authority. || ✓ || ✓ || ✓ || 3.0<br /> |-<br /> | 10.1 || Verify that the TLS settings are in line with current leading practice, particularly as common configurations, ciphers, and algorithms become insecure. || ✓ || ✓ || ✓ || 3.0<br /> |}<br /> <br /> <br /> References:<br /> <br /> For more information, see also:<br /> <br /> * [OWASP – TLS Cheat Sheet. ](https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet)<br /> * [Notes on “Approved modes of TLS”. In the past, the ASVS referred to the US standard FIPS 140-2, but as a global standard, applying US standards this can be difficult, contradictory, or confusing to apply. A better method of achieving compliance with 10.8 would be to review guides such as (https://wiki.mozilla.org/Security/Server_Side_TLS), generate known good configurations (https://mozilla.github.io/server-side-tls/ssl-config-generator/), and use known TLS evaluation tools, such as sslyze, various vulnerability scanners or trusted TLS online assessment services to obtain a desired level of security. In general, we see non-compliance for this section being the use of outdated or insecure ciphers and algorithms, the lack of perfect forward secrecy, outdated or insecure SSL protocols, weak preferred ciphers, and so on.]<br /> * [Certificate pinning. For more information please review ](https://tools.ietf.org/html/rfc7469.)The rationale behind certificate pinning for production and backup keys is business continuity - see (https://noncombatant.org/2015/05/01/about-http-public-key-pinning/)<br /> * [OWASP Certificate Pinning Cheat Sheet](https://www.owasp.org/index.php/Pinning_Cheat_Sheet)<br /> * [OWASP Certificate and Public Key Pinning](https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning)<br /> * [Time of first use (TOFU) Pinning](https://developer.mozilla.org/en/docs/Web/Security/Public_Key_Pinning)<br /> * [Pre-loading HTTP Strict Transport Security](https://www.chromium.org/hsts)</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=ASVS_V9_Data_Protection&diff=244884 2018-11-05T23:33:38Z

<p>Tonimir Kisasondi: Fixed the page, made it readable.</p> <hr /> <div>== V9: Data Protection Verification Requirements ==<br /> '''Control Objective:'''<br /> <br /> There are three key elements to sound data protection: Confidentiality, Integrity and Availability (CIA). This standard assumes that data protection is enforced on a trusted system, such as a server, which has been hardened and has sufficient protections.<br /> <br /> Applications have to assume that all user devices are compromised in some way. Where an application transmits or stores sensitive information on insecure devices, such as shared computers, phones and tablets, the application is responsible for ensuring data stored on these devices is encrypted and cannot be easily illicitly obtained, altered or disclosed.<br /> <br /> Ensure that a verified application satisfies the following high level data protection requirements:<br /> <br /> * Confidentiality: Data should be protected from unauthorised observation or disclosure both in transit and when stored.<br /> * Integrity: Data should be protected being maliciously created, altered or deleted by unauthorized attackers.<br /> * Availability: Data should be available to authorized users as required<br /> <br /> '''Security Verification Requirements:'''<br /> {| class=&quot;wikitable&quot;<br /> ! # !! Description !! L1 !! L2 !! L3 !! Since<br /> |-<br /> | 9.1 || Verify that all forms containing sensitive information have disabled client side caching, including autocomplete features. || ✓ || ✓ || ✓ || 1.0<br /> |-<br /> | 9.2 || Verify that the list of sensitive data processed by the application is identified, and that there is an explicit policy for how access to this data must be controlled, encrypted and enforced under relevant data protection directives. || || || ✓ || 3.0<br /> |-<br /> | 9.3 || Verify that all sensitive data is sent to the server in the HTTP message body or headers (i.e., URL parameters are never used to send sensitive data). || ✓ || ✓ || ✓ || 1.0<br /> |-<br /> | 9.4 || Verify that the application sets sufficient anti-caching headers such that any sensitive and personal information displayed by the application or entered by the user should not be cached on disk by mainstream modern browsers (e.g. visit about:cache to review disk cache). || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 9.5 || Verify that on the server, all cached or temporary copies of sensitive data stored are protected from unauthorized access or purged/invalidated after the authorized user accesses the sensitive data. || || ✓ || ✓ || 1.0<br /> |-<br /> | 9.6 || Verify that there is a method to remove each type of sensitive data from the application at the end of the required retention policy. || || || ✓ || 1.0<br /> |-<br /> | 9.7 || Verify the application minimizes the number of parameters in a request, such as hidden fields, Ajax variables, cookies and header values. || || ✓ || ✓ || 2.0<br /> |-<br /> | 9.8 || Verify the application has the ability to detect and alert on abnormal numbers of requests for data harvesting for an example screen scraping. || || || ✓ || 2.0<br /> |-<br /> | 9.9 || Verify that data stored in client side storage (such as HTML5 local storage, session storage, IndexedDB, regular cookies or Flash cookies) does not contain sensitive data or PII. || ✓ || ✓ || ✓ || 3.0.1<br /> |-<br /> | 9.10 || Verify accessing sensitive data is logged, if the data is collected under relevant data protection directives or where logging of accesses is required. || || ✓ || ✓ || 3.0<br /> |-<br /> | 9.11 || Verify that sensitive information maintained in memory is overwritten with zeros as soon as it is no longer required, to mitigate memory dumping attacks. || || ✓ || ✓ || 3.0.1<br /> |-<br /> | 9.12 || Placeholder for GDPR || ✓ || ✓ || ✓ || 3.0.1<br /> |-<br /> | 9.13 || Placeholder for GDPR || ✓ || ✓ || ✓ || 3.0.1<br /> |-<br /> | 9.14 || Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated. || || ✓ || ✓ || 3.0<br /> |}<br /> <br /> '''References:'''<br /> <br /> For more information, see also:<br /> <br /> * [Consider using Security Headers website to check security and anti-caching headers](https://securityheaders.io)<br /> * [OWASP Secure Headers project](https://www.owasp.org/index.php/OWASP_Secure_Headers_Project)<br /> * [User Privacy Protection Cheat Sheet](https://www.owasp.org/index.php/User_Privacy_Protection_Cheat_Sheet)</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=ASVS_V9_Data_Protection&diff=244883 2018-11-05T23:33:02Z

<p>Tonimir Kisasondi: </p> <hr /> <div>V9: Data Protection Verification Requirements<br /> <br /> Control Objective<br /> <br /> There are three key elements to sound data protection: Confidentiality, Integrity and Availability (CIA). This standard assumes that data protection is enforced on a trusted system, such as a server, which has been hardened and has sufficient protections.<br /> <br /> Applications have to assume that all user devices are compromised in some way. Where an application transmits or stores sensitive information on insecure devices, such as shared computers, phones and tablets, the application is responsible for ensuring data stored on these devices is encrypted and cannot be easily illicitly obtained, altered or disclosed.<br /> <br /> Ensure that a verified application satisfies the following high level data protection requirements:<br /> <br /> * Confidentiality: Data should be protected from unauthorised observation or disclosure both in transit and when stored.<br /> * Integrity: Data should be protected being maliciously created, altered or deleted by unauthorized attackers.<br /> * Availability: Data should be available to authorized users as required<br /> <br /> <br /> ## Security Verification Requirements<br /> {| class=&quot;wikitable&quot;<br /> ! # !! Description !! L1 !! L2 !! L3 !! Since<br /> |-<br /> | 9.1 || Verify that all forms containing sensitive information have disabled client side caching, including autocomplete features. || ✓ || ✓ || ✓ || 1.0<br /> |-<br /> | 9.2 || Verify that the list of sensitive data processed by the application is identified, and that there is an explicit policy for how access to this data must be controlled, encrypted and enforced under relevant data protection directives. || || || ✓ || 3.0<br /> |-<br /> | 9.3 || Verify that all sensitive data is sent to the server in the HTTP message body or headers (i.e., URL parameters are never used to send sensitive data). || ✓ || ✓ || ✓ || 1.0<br /> |-<br /> | 9.4 || Verify that the application sets sufficient anti-caching headers such that any sensitive and personal information displayed by the application or entered by the user should not be cached on disk by mainstream modern browsers (e.g. visit about:cache to review disk cache). || ✓ || ✓ || ✓ || 3.1<br /> |-<br /> | 9.5 || Verify that on the server, all cached or temporary copies of sensitive data stored are protected from unauthorized access or purged/invalidated after the authorized user accesses the sensitive data. || || ✓ || ✓ || 1.0<br /> |-<br /> | 9.6 || Verify that there is a method to remove each type of sensitive data from the application at the end of the required retention policy. || || || ✓ || 1.0<br /> |-<br /> | 9.7 || Verify the application minimizes the number of parameters in a request, such as hidden fields, Ajax variables, cookies and header values. || || ✓ || ✓ || 2.0<br /> |-<br /> | 9.8 || Verify the application has the ability to detect and alert on abnormal numbers of requests for data harvesting for an example screen scraping. || || || ✓ || 2.0<br /> |-<br /> | 9.9 || Verify that data stored in client side storage (such as HTML5 local storage, session storage, IndexedDB, regular cookies or Flash cookies) does not contain sensitive data or PII. || ✓ || ✓ || ✓ || 3.0.1<br /> |-<br /> | 9.10 || Verify accessing sensitive data is logged, if the data is collected under relevant data protection directives or where logging of accesses is required. || || ✓ || ✓ || 3.0<br /> |-<br /> | 9.11 || Verify that sensitive information maintained in memory is overwritten with zeros as soon as it is no longer required, to mitigate memory dumping attacks. || || ✓ || ✓ || 3.0.1<br /> |-<br /> | 9.12 || Placeholder for GDPR || ✓ || ✓ || ✓ || 3.0.1<br /> |-<br /> | 9.13 || Placeholder for GDPR || ✓ || ✓ || ✓ || 3.0.1<br /> |-<br /> | 9.14 || Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated. || || ✓ || ✓ || 3.0<br /> |}<br /> <br /> References:<br /> <br /> For more information, see also:<br /> <br /> * [Consider using Security Headers website to check security and anti-caching headers](https://securityheaders.io)<br /> * [OWASP Secure Headers project](https://www.owasp.org/index.php/OWASP_Secure_Headers_Project)<br /> * [User Privacy Protection Cheat Sheet](https://www.owasp.org/index.php/User_Privacy_Protection_Cheat_Sheet)</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=ASVS_V8_Error_Handling&diff=244882 2018-11-05T23:29:37Z

<p>Tonimir Kisasondi: Fixed the page, fixed the table, everything is readable.</p> <hr /> <div>== V8: Error Handling and Logging Verification Requirements ==<br /> <br /> '''Control Objective:'''<br /> <br /> The primary objective of error handling and logging is to provide a useful reaction by the user, administrators, and incident response teams. The objective is not to create massive amounts of logs, but high quality logs, with more signal than discarded noise.<br /> <br /> High quality logs will often contain sensitive data, and must be protected as per local data privacy laws or directives. This should include:<br /> <br /> * Not collecting or logging sensitive information if not specifically required.<br /> * Ensuring all logged information is handled securely and protected as per its data classification.<br /> * Ensuring that logs are not forever, but have an absolute lifetime that is as short as possible.<br /> <br /> If logs contain private or sensitive data, the definition of which varies from country to country, the logs become some of the most sensitive information held by the application and thus very attractive to attackers in their own right.<br /> <br /> '''Security Verification Requirements:'''<br /> {| class=&quot;wikitable&quot;<br /> ! # !! Description !! L1 !! L2 !! L3 !! Since<br /> |-<br /> | 8.1 || Verify that the application does not output error messages or stack traces containing sensitive data that could assist an attacker, including session id, software/framework versions and personal information. || ✓ || ✓ || ✓ || 1.0<br /> |-<br /> | 8.1 || Verify that error handling logic in security controls denies access by default. || || ✓ || ✓ || 1.0<br /> |-<br /> | 8.1 || Verify security logging controls provide the ability to log success and particularly failure events that are identified as security-relevant. || || ✓ || ✓ || 1.0<br /> |-<br /> | 8.1 || Verify that each log event includes necessary information that would allow for a detailed investigation of the timeline when an event happens. || || ✓ || ✓ || 1.0<br /> |-<br /> | 8.1 || Verify that all events that include untrusted data will not execute as code in the intended log viewing software. || || ✓ || ✓ || 1.0<br /> |-<br /> | 8.1 || Verify that security logs are protected from unauthorized access and modification. || || ✓ || ✓ || 1.0<br /> |-<br /> | 8.1 || Verify that the application does not log sensitive data as defined under local privacy laws or regulations, organizational sensitive data as defined by a risk assessment, or sensitive authentication data that could assist an attacker, including user’s session identifiers, passwords, hashes, or API tokens. || || ✓ || ✓ || 3.0<br /> |-<br /> | 8.1 || Verify that all non-printable symbols and field separators are properly encoded in log entries, to prevent log injection. || || || ✓ || 2.0<br /> |-<br /> | 8.1 || Verify that log fields from trusted and untrusted sources are distinguishable in log entries. || || || ✓ || 2.0<br /> |-<br /> | 8.1 || Verify that an audit log or similar allows for non-repudiation of key transactions. || ✓ || ✓ || ✓ || 3.0<br /> |-<br /> | 8.1 || Verify that security logs have some form of integrity checking or controls to prevent unauthorized modification. || || || ✓ || 3.0<br /> |-<br /> | 8.1 || Verify that logs are stored on a different partition than the application is running with proper log rotation. || || || ✓ || 3.1<br /> |-<br /> | 8.1 || Verify that time sources are synchronized to the correct time and time zone. || ✓ || ✓ || ✓ || 3.1<br /> |}<br /> <br /> '''References:'''<br /> <br /> For more information, see also:<br /> <br /> * [OWASP Testing Guide 4.0 content: Testing for Error Handling](https://www.owasp.org/index.php/Testing_for_Error_Handling)</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=ASVS_V8_Error_Handling&diff=244881 2018-11-05T23:28:40Z

<p>Tonimir Kisasondi: Fixed the table.</p> <hr /> <div># V8: Error Handling and Logging Verification Requirements<br /> <br /> ## Control Objective<br /> <br /> The primary objective of error handling and logging is to provide a useful reaction by the user, administrators, and incident response teams. The objective is not to create massive amounts of logs, but high quality logs, with more signal than discarded noise.<br /> <br /> High quality logs will often contain sensitive data, and must be protected as per local data privacy laws or directives. This should include:<br /> <br /> * Not collecting or logging sensitive information if not specifically required.<br /> * Ensuring all logged information is handled securely and protected as per its data classification.<br /> * Ensuring that logs are not forever, but have an absolute lifetime that is as short as possible.<br /> <br /> If logs contain private or sensitive data, the definition of which varies from country to country, the logs become some of the most sensitive information held by the application and thus very attractive to attackers in their own right.<br /> <br /> <br /> ## Security Verification Requirements<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! # !! Description !! L1 !! L2 !! L3 !! Since<br /> |-<br /> | 8.1 || Verify that the application does not output error messages or stack traces containing sensitive data that could assist an attacker, including session id, software/framework versions and personal information. || ✓ || ✓ || ✓ || 1.0<br /> |-<br /> | 8.1 || Verify that error handling logic in security controls denies access by default. || || ✓ || ✓ || 1.0<br /> |-<br /> | 8.1 || Verify security logging controls provide the ability to log success and particularly failure events that are identified as security-relevant. || || ✓ || ✓ || 1.0<br /> |-<br /> | 8.1 || Verify that each log event includes necessary information that would allow for a detailed investigation of the timeline when an event happens. || || ✓ || ✓ || 1.0<br /> |-<br /> | 8.1 || Verify that all events that include untrusted data will not execute as code in the intended log viewing software. || || ✓ || ✓ || 1.0<br /> |-<br /> | 8.1 || Verify that security logs are protected from unauthorized access and modification. || || ✓ || ✓ || 1.0<br /> |-<br /> | 8.1 || Verify that the application does not log sensitive data as defined under local privacy laws or regulations, organizational sensitive data as defined by a risk assessment, or sensitive authentication data that could assist an attacker, including user’s session identifiers, passwords, hashes, or API tokens. || || ✓ || ✓ || 3.0<br /> |-<br /> | 8.1 || Verify that all non-printable symbols and field separators are properly encoded in log entries, to prevent log injection. || || || ✓ || 2.0<br /> |-<br /> | 8.1 || Verify that log fields from trusted and untrusted sources are distinguishable in log entries. || || || ✓ || 2.0<br /> |-<br /> | 8.1 || Verify that an audit log or similar allows for non-repudiation of key transactions. || ✓ || ✓ || ✓ || 3.0<br /> |-<br /> | 8.1 || Verify that security logs have some form of integrity checking or controls to prevent unauthorized modification. || || || ✓ || 3.0<br /> |-<br /> | 8.1 || Verify that logs are stored on a different partition than the application is running with proper log rotation. || || || ✓ || 3.1<br /> |-<br /> | 8.1 || Verify that time sources are synchronized to the correct time and time zone. || ✓ || ✓ || ✓ || 3.1<br /> |}<br /> <br /> <br /> ## References<br /> <br /> For more information, see also:<br /> <br /> * [OWASP Testing Guide 4.0 content: Testing for Error Handling](https://www.owasp.org/index.php/Testing_for_Error_Handling)</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=ASVS_V7_Cryptography&diff=244880 2018-11-05T23:26:05Z

<p>Tonimir Kisasondi: Fixed broken numbering.</p> <hr /> <div>== V7: Cryptography Verification Requirements ==<br /> '''Control Objective:'''<br /> <br /> Ensure that a verified application satisfies the following high level requirements:<br /> <br /> * That all cryptographic modules fail in a secure manner and that errors are handled correctly.<br /> * That a suitable random number generator is used when randomness is required.<br /> * That access to keys is managed in a secure way.<br /> <br /> '''Security Verification Requirements:'''<br /> {| class=&quot;wikitable&quot;<br /> ! # !! Description !! L1 !! L2 !! L3 !! Since<br /> |-<br /> | 7.2 || Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle. || ✓ || ✓ || ✓ || 1.0<br /> |-<br /> | 7.6 || Verify that all random numbers, random file names, random GUIDs, and random strings are generated using the cryptographic module’s approved random number generator when these random values are intended to be not guessable by an attacker. || || ✓ || ✓ || 1.0<br /> |-<br /> | 7.7 || Verify that cryptographic algorithms used by the application have been validated against FIPS 140-2 or an equivalent standard. || ✓ || ✓ || ✓ || 1.0<br /> |-<br /> | 7.8 || Verify that cryptographic modules operate in their approved mode according to their published security policies. || || || ✓ || 1.0<br /> |-<br /> | 7.9 || Verify that there is an explicit policy for how cryptographic keys are managed (e.g., generated, distributed, revoked, and expired). Verify that this key lifecycle is properly enforced. || || ✓ || ✓ || 1.0<br /> |-<br /> | 7.11 || Verify that all consumers of cryptographic services do not have direct access to key material. Isolate cryptographic processes, including master secrets and consider the use of a virtualized or physical hardware key vault (HSM). || || || ✓ || 3.0.1<br /> |-<br /> | 7.12 || Verify that Personally Identifiable Information (PII) and other sensitive data is stored encrypted while at rest. || || ✓ || ✓ || 3.1<br /> |-<br /> | 7.13 || Verify that sensitive passwords or key material maintained in memory is overwritten with zeros as soon as it is no longer required, to mitigate memory dumping attacks. || || ✓ || ✓ || 3.1<br /> |-<br /> | 7.14 || Verify that all keys and passwords are replaceable, and are generated or replaced at installation time. || || ✓ || ✓ || 3.0<br /> |-<br /> | 7.15 || Verify that random numbers are created with proper entropy even when the application is under heavy load, or that the application degrades gracefully in such circumstances. || || || ✓ ||3.0<br /> |}<br /> <br /> '''References:'''<br /> <br /> For more information, see also:<br /> <br /> * [OWASP Testing Guide 4.0: Testing for weak Cryptography](https://www.owasp.org/index.php/Testing_for_weak_Cryptography)<br /> * [OWASP Cheat Sheet: Cryptographic Storage](https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet)</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=ASVS_V7_Cryptography&diff=244879 2018-11-05T23:25:36Z

<p>Tonimir Kisasondi: Fixed the broken table, tidyed up the content for it to be presentable.</p> <hr /> <div>== V7: Cryptography Verification Requirements ==<br /> '''Control Objective:'''<br /> <br /> Ensure that a verified application satisfies the following high level requirements:<br /> <br /> * That all cryptographic modules fail in a secure manner and that errors are handled correctly.<br /> * That a suitable random number generator is used when randomness is required.<br /> * That access to keys is managed in a secure way.<br /> <br /> '''Security Verification Requirements:'''<br /> {| class=&quot;wikitable&quot;<br /> ! # !! Description !! L1 !! L2 !! L3 !! Since<br /> |-<br /> | 7.2 || Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle. || ✓ || ✓ || ✓ || 1.0<br /> |-<br /> | 7.6 || Verify that all random numbers, random file names, random GUIDs, and random strings are generated using the cryptographic module’s approved random number generator when these random values are intended to be not guessable by an attacker. || || ✓ || ✓ || 1.0<br /> |-<br /> | 7.7 || Verify that cryptographic algorithms used by the application have been validated against FIPS 140-2 or an equivalent standard. || ✓ || ✓ || ✓ || 1.0<br /> |-<br /> | 7.8 || Verify that cryptographic modules operate in their approved mode according to their published security policies. || || || ✓ || 1.0<br /> |-<br /> | 7.9 || Verify that there is an explicit policy for how cryptographic keys are managed (e.g., generated, distributed, revoked, and expired). Verify that this key lifecycle is properly enforced. || || ✓ || ✓ || 1.0<br /> |-<br /> | 7.11 || Verify that all consumers of cryptographic services do not have direct access to key material. Isolate cryptographic processes, including master secrets and consider the use of a virtualized or physical hardware key vault (HSM). || || || ✓ || 3.0.1<br /> |-<br /> | 7.12 || Verify that Personally Identifiable Information (PII) and other sensitive data is stored encrypted while at rest. || || ✓ || ✓ || 3.1<br /> |-<br /> | 7.13 || Verify that sensitive passwords or key material maintained in memory is overwritten with zeros as soon as it is no longer required, to mitigate memory dumping attacks. || || ✓ || ✓ || 3.1<br /> |-<br /> | 7.14 || Verify that all keys and passwords are replaceable, and are generated or replaced at installation time. || || ✓ || ✓ || 3.0<br /> |-<br /> | 7.15 || Verify that random numbers are created with proper entropy even when the application is under heavy load, or that the application degrades gracefully in such circumstances. || || || ✓ ||<br /> |}<br /> <br /> '''References:'''<br /> <br /> For more information, see also:<br /> <br /> * [OWASP Testing Guide 4.0: Testing for weak Cryptography](https://www.owasp.org/index.php/Testing_for_weak_Cryptography)<br /> * [OWASP Cheat Sheet: Cryptographic Storage](https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet)</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=ASVS_V7_Cryptography&diff=244878 2018-11-05T23:23:36Z

<p>Tonimir Kisasondi: </p> <hr /> <div># V7: Cryptography Verification Requirements<br /> <br /> ## Control Objective<br /> <br /> Ensure that a verified application satisfies the following high level requirements:<br /> <br /> * That all cryptographic modules fail in a secure manner and that errors are handled correctly.<br /> * That a suitable random number generator is used when randomness is required.<br /> * That access to keys is managed in a secure way.<br /> <br /> <br /> ## Security Verification Requirements<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! # !! Description !! L1 !! L2 !! L3 !! Since<br /> |-<br /> | 7.2 || Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle. || ✓ || ✓ || ✓ || 1.0<br /> |-<br /> | 7.6 || Verify that all random numbers, random file names, random GUIDs, and random strings are generated using the cryptographic module’s approved random number generator when these random values are intended to be not guessable by an attacker. || || ✓ || ✓ || 1.0<br /> |-<br /> | 7.7 || Verify that cryptographic algorithms used by the application have been validated against FIPS 140-2 or an equivalent standard. || ✓ || ✓ || ✓ || 1.0<br /> |-<br /> | 7.8 || Verify that cryptographic modules operate in their approved mode according to their published security policies. || || || ✓ || 1.0<br /> |-<br /> | 7.9 || Verify that there is an explicit policy for how cryptographic keys are managed (e.g., generated, distributed, revoked, and expired). Verify that this key lifecycle is properly enforced. || || ✓ || ✓ || 1.0<br /> |-<br /> | 7.11 || Verify that all consumers of cryptographic services do not have direct access to key material. Isolate cryptographic processes, including master secrets and consider the use of a virtualized or physical hardware key vault (HSM). || || || ✓ || 3.0.1<br /> |-<br /> | 7.12 || Verify that Personally Identifiable Information (PII) and other sensitive data is stored encrypted while at rest. || || ✓ || ✓ || 3.1<br /> |-<br /> | 7.13 || Verify that sensitive passwords or key material maintained in memory is overwritten with zeros as soon as it is no longer required, to mitigate memory dumping attacks. || || ✓ || ✓ || 3.1<br /> |-<br /> | 7.14 || Verify that all keys and passwords are replaceable, and are generated or replaced at installation time. || || ✓ || ✓ || 3.0<br /> |-<br /> | 7.15 || Verify that random numbers are created with proper entropy even when the application is under heavy load, or that the application degrades gracefully in such circumstances. || || || ✓ || 3.0<br /> |}<br /> <br /> <br /> ## References<br /> <br /> For more information, see also:<br /> <br /> * [OWASP Testing Guide 4.0: Testing for weak Cryptography](https://www.owasp.org/index.php/Testing_for_weak_Cryptography)<br /> * [OWASP Cheat Sheet: Cryptographic Storage](https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet)</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=Smart_Contract_Top_10&diff=237875 2018-02-18T22:16:47Z

<p>Tonimir Kisasondi: </p> <hr /> <div>== OWASP Smart Contract Top 10 ==<br /> <br /> Work in progress / Placeholder page for the Smart Contract Top 10 vulnerabilities. <br /> <br /> <br /> '''Insufficient bounding'''<br /> [ERC20SA]<br /> [Fallback]<br /> [Reentrancy]<br /> <br /> <br /> '''Bad cryptographic practices:'''<br /> [Random]<br /> <br /> <br /> References:<br /> <br /> <br /> <br /> <br /> <br /> [Random] https://blog.positive.com/predicting-random-numbers-in-ethereum-smart-contracts-e5358c6b8620<br /> <br /> [Fallback] https://solidity.readthedocs.io/en/latest/contracts.html#fallback-function<br /> <br /> [Reentrancy] https://solidity.readthedocs.io/en/develop/security-considerations.html<br /> <br /> [ERC20SA] http://vessenes.com/the-erc20-short-address-attack-explained/<br /> <br /> [UncheckedSend] http://hackingdistributed.com/2016/06/16/scanning-live-ethereum-contracts-for-bugs/</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=Smart_Contract_Top_10&diff=237874 2018-02-18T22:00:48Z

<p>Tonimir Kisasondi: Created page with &quot;== OWASP Smart Contract Top 10 == Work in progress / Placeholder page for the Smart Contract Top 10 vulnerabilities. '''Insufficient bounding''' [ERC20SA] [Fallback] [Reen...&quot;</p> <hr /> <div>== OWASP Smart Contract Top 10 ==<br /> <br /> Work in progress / Placeholder page for the Smart Contract Top 10 vulnerabilities. <br /> <br /> <br /> '''Insufficient bounding'''<br /> [ERC20SA]<br /> [Fallback]<br /> [Reentrancy]<br /> <br /> <br /> '''Bad cryptographic practices:'''<br /> [Random]<br /> <br /> <br /> References:<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> [Random] https://blog.positive.com/predicting-random-numbers-in-ethereum-smart-contracts-e5358c6b8620<br /> <br /> [Fallback] https://solidity.readthedocs.io/en/latest/contracts.html#fallback-function<br /> <br /> [Reentrancy] https://solidity.readthedocs.io/en/develop/security-considerations.html<br /> <br /> [ERC20SA] http://vessenes.com/the-erc20-short-address-attack-explained/</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=OWASP_Internet_of_Things_Project&diff=227652 2017-03-20T10:20:09Z

<p>Tonimir Kisasondi: Improvements in vulnerabilities and attack surface areas</p> <hr /> <div>= Main =<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> ==OWASP Internet of Things (IoT) Project==<br /> <br /> Oxford defines the Internet of Things as: “A proposed development of the Internet in which everyday objects have network connectivity, allowing them to send and receive data.”<br /> <br /> ''The OWASP Internet of Things Project is designed to help manufacturers, developers, and consumers better understand the security issues associated with the Internet of Things, and to enable users in any context to make better security decisions when building, deploying, or assessing IoT technologies''. <br /> <br /> The project looks to define a structure for various IoT sub-projects such as Attack Surface Areas, Testing Guides and Top Vulnerabilities.<br /> <br /> [[File:iot-project.png|400px|thumb|center]]<br /> <br /> ==Licensing==<br /> The OWASP Internet of Things Project is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.<br /> <br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == What is the OWASP Internet of Things Project? ==<br /> <br /> The OWASP Internet of Things Project provides information on:<br /> <br /> * [https://www.owasp.org/index.php/IoT_Attack_Surface_Areas IoT Attack Surface Areas]<br /> * IoT Vulnerabilities<br /> * Firmware Analysis<br /> * ICS/SCADA Software Weaknesses<br /> * Community Information<br /> * [https://www.owasp.org/index.php/IoT_Testing_Guides IoT Testing Guides]<br /> * [https://www.owasp.org/index.php/IoT_Security_Guidance IoT Security Guidance]<br /> * [https://www.owasp.org/index.php/Principles_of_IoT_Security Principles of IoT Security]<br /> * [https://www.owasp.org/index.php/IoT_Framework_Assessment IoT Framework Assessment]<br /> * Developer, Consumer and Manufacturer Guidance<br /> * Design Principles<br /> <br /> == Project Leaders ==<br /> <br /> * Daniel Miessler<br /> * Craig Smith<br /> <br /> == Contributors ==<br /> * [https://www.owasp.org/index.php/User:Justin_C._Klein_Keane Justin Klein Keane]<br /> * Saša Zdjelar<br /> <br /> == Related Projects ==<br /> <br /> * [[OWASP_Project|OWASP Project Repository]]<br /> * [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]<br /> * [[OWASP_Top_Ten_Project|OWASP Web Top 10]]<br /> * [[OWASP_.NET_Project|OWASP .NET]]<br /> * [[Java|OWASP Java and JVM]]<br /> * [[C/C++|OWASP C/C++]]<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:200px;&quot; |<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Quick Download ==<br /> [https://www.owasp.org/images/3/36/IoTTestingMethodology.pdf IoT Attack Surface Mapping DEFCON 23]<br /> <br /> [https://www.owasp.org/images/2/2d/Iot_testing_methodology.JPG IoT Testing Guidance Handout]<br /> <br /> [https://www.owasp.org/images/7/71/Internet_of_Things_Top_Ten_2014-OWASP.pdf OWASP IoT Top Ten PDF]<br /> <br /> [https://www.owasp.org/images/8/8e/Infographic-v1.jpg OWASP IoT Top Ten Infographic]<br /> <br /> [https://www.owasp.org/images/0/01/Internet_of_Things_Top_Ten_2014-OWASP-ppt.pptx OWASP IoT Top Ten PPT]<br /> <br /> [https://www.owasp.org/images/5/51/RSAC2015-OWASP-IoT-Miessler.pdf OWASP IoT Top Ten-RSA 2015]<br /> <br /> [https://www.owasp.org/images/b/bd/OWASP-IoT.pptx OWASP IoT Project Overview]<br /> <br /> == News and Events ==<br /> * Added a [https://owasp-iot-security.slack.com/ Slack channel]<br /> * Added a sub-project; [https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=IoT_Security_Policy_Project IoT Security Policy Project]<br /> * Daniel Miessler gave his [https://www.youtube.com/watch?v=RhxHHD790nw IoT talk at DEFCON 23]<br /> * Migrating the IoT Top Ten to be under the IoT Project<br /> * HP Study Reveals 70 Percent of Internet of Things Devices Vulnerable to Attack<br /> <br /> ==Classifications==<br /> <br /> {| width=&quot;200&quot; cellpadding=&quot;2&quot;<br /> |-<br /> | rowspan=&quot;2&quot; align=&quot;center&quot; valign=&quot;top&quot; width=&quot;50%&quot; | [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]<br /> | align=&quot;center&quot; valign=&quot;top&quot; width=&quot;50%&quot; | [[File:Owasp-builders-small.png|link=]] <br /> |-<br /> | align=&quot;center&quot; valign=&quot;top&quot; width=&quot;50%&quot; | [[File:Owasp-defenders-small.png|link=]]<br /> |-<br /> | colspan=&quot;2&quot; align=&quot;center&quot; | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]<br /> |-<br /> | colspan=&quot;2&quot; align=&quot;center&quot; | [[File:Project_Type_Files_DOC.jpg|link=]]<br /> |}<br /> <br /> |}<br /> <br /> = IoT Attack Surface Areas =<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == IoT Attack Surface Areas Project ==<br /> <br /> The OWASP IoT Attack Surface Areas (DRAFT) are as follows:<br /> <br /> {| class=&quot;wikitable&quot; border=&quot;1&quot; style=&quot;text-align: left&quot;<br /> ! Attack Surface<br /> ! Vulnerability<br /> |- <br /> | '''Ecosystem (general)'''<br /> |<br /> * Interoperability standards<br /> * Data governance<br /> * System wide failure<br /> * Individual stakeholder risks<br /> * Implicit trust between components<br /> * Enrollment security<br /> * Decommissioning system<br /> * Lost access procedures<br /> |- <br /> | '''Device Memory'''<br /> |<br /> * Sensitive data<br /> ** Cleartext usernames<br /> ** Cleartext passwords<br /> ** Third-party credentials<br /> ** Encryption keys<br /> |- <br /> | '''Device Physical Interfaces'''<br /> |<br /> * Firmware extraction<br /> * User CLI<br /> * Admin CLI<br /> * Privilege escalation<br /> * Reset to insecure state<br /> * Removal of storage media<br /> * Tamper resistance<br /> * Debug port<br /> ** UART (Serial)<br /> ** JTAG / SWD<br /> * Device ID/Serial number exposure<br /> |-<br /> | '''Device Web Interface'''<br /> |<br /> * Standard set of web application vulnerabilities, see:<br /> ** [[:Category:OWASP Top Ten Project|OWASP Web Top 10]]<br /> ** [[:Category:OWASP Application Security Verification Standard Project|OWASP ASVS]]<br /> ** [[:Category:OWASP Testing Project|OWASP Testing guide]]<br /> * Credential management vulnerabilities:<br /> ** Username enumeration<br /> ** Weak passwords<br /> ** Account lockout<br /> ** Known default credentials<br /> ** Insecure password recovery mechanism<br /> |- <br /> | '''Device Firmware'''<br /> |<br /> * Sensitive data exposure ([[Top 10 2013-A6-Sensitive Data Exposure|See OWASP Top 10 - A6 Sensitive data exposure]]):<br /> ** Backdoor accounts<br /> ** Hardcoded credentials<br /> ** Encryption keys<br /> ** Encryption (Symmetric, Asymmetric)<br /> ** Sensitive information<br /> ** Sensitive URL disclosure<br /> * Firmware version display and/or last update date<br /> * Vulnerable services (web, ssh, tftp, etc.)<br /> ** Verify for old sw versions and possible attacks (Heartbleed, Shellshock, old PHP versions etc)<br /> * Security related function API exposure<br /> * Firmware downgrade possibility<br /> |- <br /> | '''Device Network Services'''<br /> |<br /> * Information disclosure<br /> * User CLI<br /> * Administrative CLI<br /> * Injection<br /> * Denial of Service<br /> * Unencrypted Services<br /> * Poorly implemented encryption<br /> * Test/Development Services<br /> * Buffer Overflow<br /> * UPnP<br /> * Vulnerable UDP Services<br /> * DoS<br /> * Device Firmware OTA update block<br /> * Firmware loaded over insecure channel (no TLS)<br /> * Replay attack<br /> * Lack of payload verification<br /> * Lack of message integrity check<br /> * Credential management vulnerabilities:<br /> ** Username enumeration<br /> ** Weak passwords<br /> ** Account lockout<br /> ** Known default credentials<br /> ** Insecure password recovery mechanism<br /> |- <br /> | '''Administrative Interface'''<br /> |<br /> * Standard set of web application vulnerabilities, see:<br /> ** [[:Category:OWASP Top Ten Project|OWASP Web Top 10]]<br /> ** [[:Category:OWASP Application Security Verification Standard Project|OWASP ASVS]]<br /> ** [[:Category:OWASP Testing Project|OWASP Testing guide]]<br /> * Credential management vulnerabilities:<br /> ** Username enumeration<br /> ** Weak passwords<br /> ** Account lockout<br /> ** Known default credentials<br /> ** Insecure password recovery mechanism<br /> * Security/encryption options<br /> * Logging options<br /> * Two-factor authentication<br /> * Check for insecure direct object references<br /> * Inability to wipe device<br /> |- <br /> | '''Local Data Storage'''<br /> |<br /> * Unencrypted data<br /> * Data encrypted with discovered keys<br /> * Lack of data integrity checks<br /> * Use of static same enc/dec key<br /> |- <br /> | '''Cloud Web Interface'''<br /> |<br /> <br /> * Standard set of web application vulnerabilities, see:<br /> ** [[:Category:OWASP Top Ten Project|OWASP Web Top 10]]<br /> ** [[:Category:OWASP Application Security Verification Standard Project|OWASP ASVS]]<br /> ** [[:Category:OWASP Testing Project|OWASP Testing guide]]<br /> * Credential management vulnerabilities:<br /> ** Username enumeration<br /> ** Weak passwords<br /> ** Account lockout<br /> ** Known default credentials<br /> ** Insecure password recovery mechanism<br /> * Transport encryption<br /> * Two-factor authentication<br /> |- <br /> | '''Third-party Backend APIs'''<br /> |<br /> * Unencrypted PII sent<br /> * Encrypted PII sent<br /> * Device information leaked<br /> * Location leaked<br /> |- <br /> | '''Update Mechanism'''<br /> |<br /> * Update sent without encryption<br /> * Updates not signed<br /> * Update location writable<br /> * Update verification<br /> * Update authentication<br /> * Malicious update<br /> * Missing update mechanism<br /> * No manual update mechanism<br /> |- <br /> | '''Mobile Application'''<br /> |<br /> * Implicitly trusted by device or cloud<br /> * Username enumeration<br /> * Account lockout<br /> * Known default credentials<br /> * Weak passwords<br /> * Insecure data storage<br /> * Transport encryption<br /> * Insecure password recovery mechanism<br /> * Two-factor authentication<br /> |- <br /> | '''Vendor Backend APIs'''<br /> |<br /> * Inherent trust of cloud or mobile application<br /> * Weak authentication<br /> * Weak access controls<br /> * Injection attacks<br /> * Hidden services<br /> |- <br /> | '''Ecosystem Communication'''<br /> |<br /> * Health checks<br /> * Heartbeats<br /> * Ecosystem commands<br /> * Deprovisioning<br /> * Pushing updates<br /> |- <br /> | '''Network Traffic'''<br /> |<br /> * LAN<br /> * LAN to Internet<br /> * Short range<br /> * Non-standard<br /> * Wireless (WiFi, Z-wave, XBee, Zigbee, Bluetooth, LoRA)<br /> * Protocol fuzzing<br /> |- <br /> | '''Authentication/Authorization'''<br /> |<br /> * Authentication/Authorization related values (session key, token, cookie, etc.) disclosure<br /> * Reusing of session key, token, etc.<br /> * Device to device authentication<br /> * Device to mobile Application authentication<br /> * Device to cloud system authentication<br /> * Mobile application to cloud system authentication<br /> * Web application to cloud system authentication<br /> * Lack of dynamic authentication<br /> |-<br /> | '''Privacy'''<br /> |<br /> * User data disclosure<br /> * User/device location disclosure<br /> * Differential privacy<br /> |-<br /> | '''Hardware (Sensors)'''<br /> |<br /> * Sensing Environment Manipulation<br /> * Tampering (Physically)<br /> * Damage (Physicall)<br /> <br /> |-<br /> |}<br /> <br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == What is the IoT Attack Surface Areas Project? ==<br /> <br /> The IoT Attack Surface Areas Project provides a list of attack surfaces that should be understood by manufacturers, developers, security researchers, and those looking to deploy or implement IoT technologies within their organizations.<br /> <br /> == Project Leaders ==<br /> <br /> * Daniel Miessler<br /> * Craig Smith<br /> <br /> == Related Projects ==<br /> <br /> * [https://www.owasp.org/index.php/OWASP_Mobile_Security_Project The OWASP Mobile Top 10 Project]<br /> * [https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project The OWASP Web Top 10 Project]<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Quick Download ==<br /> * Coming Soon<br /> <br /> == News and Events ==<br /> * Coming Soon<br /> <br /> |}<br /> <br /> = IoT Vulnerabilities =<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == IoT Vulnerabilities Project ==<br /> <br /> {| class=&quot;wikitable&quot; border=&quot;1&quot; style=&quot;text-align: left&quot;<br /> ! Vulnerability<br /> ! Attack Surface<br /> ! Summary<br /> |-<br /> | '''Username Enumeration'''<br /> |<br /> * Administrative Interface<br /> * Device Web Interface<br /> * Cloud Interface<br /> * Mobile Application<br /> |<br /> * Ability to collect a set of valid usernames by interacting with the authentication mechanism<br /> |-<br /> | '''Weak Passwords'''<br /> |<br /> * Administrative Interface<br /> * Device Web Interface<br /> * Cloud Interface<br /> * Mobile Application<br /> |<br /> * Ability to set account passwords to '1234' or '123456' for example.<br /> * Usage of pre-programmed default passwords<br /> |-<br /> | '''Account Lockout'''<br /> |<br /> * Administrative Interface<br /> * Device Web Interface<br /> * Cloud Interface<br /> * Mobile Application<br /> |<br /> * Ability to continue sending authentication attempts after 3 - 5 failed login attempts<br /> |-<br /> | '''Unencrypted Services'''<br /> |<br /> * Device Network Services<br /> |<br /> * Network services are not properly encrypted to prevent eavesdropping or tampering by attackers<br /> |-<br /> | '''Two-factor Authentication'''<br /> |<br /> * Administrative Interface<br /> * Cloud Web Interface<br /> * Mobile Application<br /> |<br /> * Lack of two-factor authentication mechanisms such as a security token or fingerprint scanner<br /> |-<br /> | '''Poorly Implemented Encryption'''<br /> |<br /> * Device Network Services<br /> |<br /> * Encryption is implemented however it is improperly configured or is not being properly updated, e.g. using SSL v2 <br /> |-<br /> | '''Update Sent Without Encryption'''<br /> |<br /> * Update Mechanism<br /> |<br /> * Updates are transmitted over the network without using TLS or encrypting the update file itself<br /> |-<br /> | '''Update Location Writable'''<br /> |<br /> * Update Mechanism<br /> |<br /> * Storage location for update files is world writable potentially allowing firmware to be modified and distributed to all users<br /> |-<br /> | '''Denial of Service'''<br /> |<br /> * Device Network Services<br /> |<br /> * Service can be attacked in a way that denies service to that service or the entire device<br /> |-<br /> | '''Removal of Storage Media'''<br /> |<br /> * Device Physical Interfaces<br /> |<br /> * Ability to physically remove the storage media from the device<br /> |-<br /> | '''No Manual Update Mechanism'''<br /> |<br /> * Update Mechanism<br /> |<br /> * No ability to manually force an update check for the device<br /> |-<br /> | '''Missing Update Mechanism'''<br /> |<br /> * Update Mechanism<br /> |<br /> * No ability to update device<br /> |-<br /> | '''Firmware Version Display and/or Last Update Date'''<br /> |<br /> * Device Firmware<br /> |<br /> * Current firmware version is not displayed and/or the last update date is not displayed<br /> |-<br /> | '''Firmware and storage extraction'''<br /> |<br /> * JTAG / SWD interface<br /> * [https://www.flashrom.org/Flashrom In-Situ dumping]<br /> * Intercepting a OTA update<br /> * Downloading from the manufacturers web page<br /> * [https://www.exploitee.rs/index.php/Exploitee.rs_Low_Voltage_e-MMC_Adapter eMMC tapping]<br /> * Unsoldering the SPI Flash / eMMC chip and reading it in a adapter<br /> |<br /> * Firmware contains a lot of useful information, like source code and binaries of running services, pre-set passwords, ssh keys etc. <br /> |-<br /> | '''Manipulating the code execution flow of the device'''<br /> |<br /> * JTAG / SWD interface<br /> * [https://wiki.newae.com/Main_Page Side channel attacks like glitching]<br /> |<br /> * With the help of a JTAG adapter and gdb we can modify the execution of firmware in the device and bypass almost all software based security controls.<br /> * Side channel attacks can also modify the execution flow or can be used to leak interesting information from the device<br /> |-<br /> | '''Obtaining console access'''<br /> |<br /> * Serial interfaces (SPI / UART)<br /> |<br /> * By connecting to a serial interface, we will obtain full console access to a device<br /> * Usually security measures include custom bootloaders that prevent the attacker from entering single user mode, but that can also be bypassed.<br /> <br /> |-<br /> <br /> |}<br /> <br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == What is the IoT Vulnerabilities Project? ==<br /> <br /> The IoT Vulnerabilities Project provides:<br /> <br /> * Information on the top IoT vulnerabilities<br /> * The attack surface associated with the vulnerability<br /> * A summary of the vulnerability<br /> <br /> == Project Leaders ==<br /> <br /> * Daniel Miessler<br /> * Craig Smith<br /> <br /> == Related Projects ==<br /> <br /> * [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]<br /> * [[OWASP_Top_Ten_Project|OWASP Web Top 10]]<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Resources ==<br /> * [https://www.owasp.org/index.php/Top_IoT_Vulnerabilities Top 10 IoT Vulnerabilities from 2014]<br /> <br /> == News and Events ==<br /> * Coming Soon<br /> <br /> |}<br /> <br /> = Medical Devices =<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == Medical Device Testing ==<br /> <br /> The Medical Device Testing project is intended to provide some basic attack surface considerations that should be evaluated before shipping Medical Device equipment.<br /> <br /> {| class=&quot;wikitable&quot; border=&quot;1&quot; style=&quot;text-align: left&quot;<br /> ! Attack Surface<br /> ! Vulnerability<br /> |- <br /> | '''Ecosystem (general)'''<br /> |<br /> * Interoperability standards<br /> * Data governance<br /> * System wide failure<br /> * Individual stakeholder risks<br /> * Implicit trust between components<br /> * Enrollment security<br /> * Decommissioning system<br /> * Lost access procedures<br /> |- <br /> | '''HL7'''<br /> |<br /> * XML Parsing<br /> ** XSS<br /> * Information Disclosure<br /> |- <br /> | '''Device Memory'''<br /> |<br /> * Sensitive data<br /> ** Cleartext usernames<br /> ** Cleartext passwords<br /> ** Third-party credentials<br /> ** Encryption keys<br /> |- <br /> | '''Device Physical Interfaces'''<br /> |<br /> * Firmware extraction<br /> * User CLI<br /> * Admin CLI<br /> * Privilege escalation<br /> * Reset to insecure state<br /> * Removal of storage media<br /> * Tamper resistance<br /> * Debug port<br /> * Device ID/Serial number exposure<br /> |-<br /> | '''Device Web Interface'''<br /> |<br /> * Standard set of web vulnerabilities:<br /> ** SQL injection<br /> ** Cross-site scripting<br /> ** Cross-site Request Forgery<br /> ** Username enumeration<br /> * Credential management vulnerabilities:<br /> ** Username enumeration<br /> ** Weak passwords<br /> ** Account lockout<br /> ** Known default credentials<br /> ** Insecure password recovery mechanism<br /> |- <br /> | '''Device Firmware'''<br /> |<br /> * Sensitive data exposure:<br /> ** Backdoor accounts<br /> ** Hardcoded credentials<br /> ** Encryption keys<br /> ** Encryption (Symmetric, Asymmetric)<br /> ** Sensitive information<br /> ** Sensitive URL disclosure<br /> * Firmware version display and/or last update date<br /> * Vulnerable services (web, ssh, tftp, etc.)<br /> * Security related function API exposure<br /> * Firmware downgrade<br /> |- <br /> | '''Device Network Services'''<br /> |<br /> * Information disclosure<br /> * User CLI<br /> * Administrative CLI<br /> * Injection<br /> * Denial of Service<br /> * Unencrypted Services<br /> * Poorly implemented encryption<br /> * Test/Development Services<br /> * Buffer Overflow<br /> * UPnP<br /> * Vulnerable UDP Services<br /> * DoS<br /> * Device Firmware OTA update block<br /> * Replay attack<br /> * Lack of payload verification<br /> * Lack of message integrity check<br /> * Credential management vulnerabilities:<br /> ** Username enumeration<br /> ** Weak passwords<br /> ** Account lockout<br /> ** Known default credentials<br /> ** Insecure password recovery mechanism<br /> |- <br /> | '''Administrative Interface'''<br /> |<br /> * Standard web vulnerabilities:<br /> ** SQL injection<br /> ** Cross-site scripting<br /> ** Cross-site Request Forgery<br /> ** Username enumeration<br /> * Credential management vulnerabilities:<br /> ** Username enumeration<br /> ** Weak passwords<br /> ** Account lockout<br /> ** Known default credentials<br /> ** Insecure password recovery mechanism<br /> * Security/encryption options<br /> * Logging options<br /> * Two-factor authentication<br /> * Inability to wipe device<br /> |- <br /> | '''Local Data Storage'''<br /> |<br /> * Unencrypted data<br /> * Data encrypted with discovered keys<br /> * Lack of data integrity checks<br /> * Use of static same enc/dec key<br /> |- <br /> | '''Cloud Web Interface'''<br /> |<br /> * Standard set of web vulnerabilities:<br /> ** SQL injection<br /> ** Cross-site scripting<br /> ** Cross-site Request Forgery<br /> * Credential management vulnerabilities:<br /> ** Username enumeration<br /> ** Weak passwords<br /> ** Account lockout<br /> ** Known default credentials<br /> ** Insecure password recovery mechanism<br /> * Transport encryption<br /> * Two-factor authentication<br /> |- <br /> | '''Third-party Backend APIs'''<br /> |<br /> * Unencrypted PII sent<br /> * Encrypted PII sent<br /> * Device information leaked<br /> * Location leaked<br /> |- <br /> | '''Update Mechanism'''<br /> |<br /> * Update sent without encryption<br /> * Updates not signed<br /> * Update location writable<br /> * Update verification<br /> * Update authentication<br /> * Malicious update<br /> * Missing update mechanism<br /> * No manual update mechanism<br /> |- <br /> | '''Mobile Application'''<br /> |<br /> * Implicitly trusted by device or cloud<br /> * Username enumeration<br /> * Account lockout<br /> * Known default credentials<br /> * Weak passwords<br /> * Insecure data storage<br /> * Transport encryption<br /> * Insecure password recovery mechanism<br /> * Two-factor authentication<br /> |- <br /> | '''Vendor Backend APIs'''<br /> |<br /> * Inherent trust of cloud or mobile application<br /> * Weak authentication<br /> * Weak access controls<br /> * Injection attacks<br /> * Hidden services<br /> |- <br /> | '''Ecosystem Communication'''<br /> |<br /> * Health checks<br /> * Heartbeats<br /> * Ecosystem commands<br /> * Deprovisioning<br /> * Pushing updates<br /> |- <br /> | '''Network Traffic'''<br /> |<br /> * LAN<br /> * LAN to Internet<br /> * Short range<br /> * Non-standard<br /> * Wireless (WiFi, Z-wave, XBee, Zigbee, Bluetooth, LoRA)<br /> * Protocol fuzzing<br /> |- <br /> | '''Authentication/Authorization'''<br /> |<br /> * Authentication/Authorization related values (session key, token, cookie, etc.) disclosure<br /> * Reusing of session key, token, etc.<br /> * Device to device authentication<br /> * Device to mobile Application authentication<br /> * Device to cloud system authentication<br /> * Mobile application to cloud system authentication<br /> * Web application to cloud system authentication<br /> * Lack of dynamic authentication<br /> |-<br /> | '''Data Flow'''<br /> |<br /> * What data is being captured?<br /> * How does it move within the ecosystem?<br /> * How is it protected in transit?<br /> * How is it protected at rest?<br /> * Who is that data shared with?<br /> |-<br /> | '''Hardware (Sensors)'''<br /> |<br /> * Sensing Environment Manipulation<br /> * Tampering (Physically)<br /> * Damaging (Physically)<br /> * Failure state analysis<br /> |-<br /> |}<br /> <br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == What is the Medical Attack Surfaces project? ==<br /> <br /> The Medical Attack Surfaces project provides:<br /> <br /> * A simple way for testers, manufacturers, developers, and users to get an understanding of the complexity of a modern medical environment<br /> * Allows people to visualize the numerous attack surfaces that need to be defended within medical equipment ecosystems<br /> <br /> == Project Leaders ==<br /> <br /> * Daniel Miessler<br /> <br /> == Related Projects ==<br /> <br /> * [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]<br /> * [[OWASP_Top_Ten_Project|OWASP Web Top 10]]<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Resources ==<br /> * [https://www.owasp.org/index.php/IoT_Firmware_Analysis IoT Firmware Analysis Primer]<br /> * [https://otalliance.org/initiatives/internet-things Online Trust Alliance - Internet of Things]<br /> * [https://people.debian.org/~aurel32/qemu/ Pre-compiled QEMU images]<br /> * [https://code.google.com/archive/p/firmware-mod-kit/ Firmware Modification Kit]<br /> * [https://craigsmith.net/episode-11-1-firmware-extraction/ Short Firmware Extraction Video]<br /> * [https://craigsmith.net/episode-12-1-firmware-emulation-with-qemu/ Firmware Emulation with QEMU]<br /> * [https://craigsmith.net/episode-18-1-file-extraction-from-network-capture/ File Extraction from Network Capture]<br /> <br /> == News and Events ==<br /> * Daniel Miessler presented on using Adaptive Testing Methodologies to evaluate the security of medical devices at RSA 2017.<br /> <br /> |}<br /> <br /> = Firmware Analysis =<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == Firmware Analysis Project ==<br /> <br /> The Firmware Analysis Project is intended to provide security testing guidance for the IoT Attack Surface &quot;Device Firmware&quot;:<br /> <br /> {| class=&quot;wikitable&quot; border=&quot;1&quot; style=&quot;text-align: left&quot;<br /> ! Section<br /> ! <br /> |- <br /> |<br /> Device Firmware Vulnerabilties<br /> |<br /> * Out-of-date core components<br /> * Unsupported core components<br /> * Expired and/or self-signed certificates<br /> * Same certificate used on multiple devices<br /> * Admin web interface concerns<br /> * Hardcoded or easy to guess credentials<br /> * Sensitive information disclosure<br /> * Sensitive URL disclosure<br /> * Encryption key exposure<br /> * Backdoor accounts<br /> * Vulnerable services (web, ssh, tftp, etc.)<br /> |-<br /> |<br /> Manufacturer Recommendations<br /> |<br /> * Ensure that supported and up-to-date software is used by developers<br /> * Ensure that robust update mechanisms are in place for devices<br /> * Ensure that certificates are not duplicated across devices and product lines.<br /> * Ensure supported and up-to-date software is used by developers<br /> * Develop a mechanism to ensure a new certificate is installed when old ones expire<br /> * Disable deprecated SSL versions<br /> * Ensure developers do not code in easy to guess or common admin passwords<br /> * Ensure services such as SSH have a secure password created<br /> * Develop a mechanism that requires the user to create a secure admin password during initial device setup<br /> * Ensure developers do not hard code passwords or hashes<br /> * Have source code reviewed by a third party before releasing device to production<br /> * Ensure industry standard encryption or strong hashing is used<br /> |-<br /> |<br /> Device Firmware Guidance and Instruction<br /> |<br /> * Firmware file analysis<br /> * Firmware extraction<br /> * Dynamic binary analysis<br /> * Static binary analysis<br /> * Static code analysis<br /> * Firmware emulation<br /> * File system analysis<br /> |-<br /> |<br /> Device Firmware Tools<br /> |<br /> * [https://github.com/craigz28/firmwalker Firmwalker] <br /> * [https://code.google.com/archive/p/firmware-mod-kit/ Firmware Modification Kit]<br /> * [https://github.com/angr/angr Angr binary analysis framework]<br /> * [http://binwalk.org/ Binwalk firmware analysis tool]<br /> * [http://www.binaryanalysis.org/en/home Binary Analysis Tool]<br /> * [https://github.com/firmadyne/firmadyne Firmadyne]<br /> |-<br /> |<br /> Vulnerable Firmware<br /> |<br /> * [https://github.com/praetorian-inc/DVRF Damn Vulnerable Router Firmware]<br /> |-<br /> |}<br /> <br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == What is the Firmware Analysis Project? ==<br /> <br /> The Firmware Analysis Project provides:<br /> <br /> * Security testing guidance for vulnerabilities in the &quot;Device Firmware&quot; attack surface<br /> * Steps for extracting file systems from various firmware files<br /> * Guidance on searching a file systems for sensitive of interesting data<br /> * Information on static analysis of firmware contents<br /> * Information on dynamic analysis of emulated services (e.g. web admin interface)<br /> * Testing tool links<br /> * A site for pulling together existing information on firmware analysis<br /> <br /> == Project Leaders ==<br /> <br /> * Craig Smith<br /> <br /> == Related Projects ==<br /> <br /> * [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]<br /> * [[OWASP_Top_Ten_Project|OWASP Web Top 10]]<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Resources ==<br /> * [https://www.owasp.org/index.php/IoT_Firmware_Analysis IoT Firmware Analysis Primer]<br /> * [https://otalliance.org/initiatives/internet-things Online Trust Alliance - Internet of Things]<br /> * [https://people.debian.org/~aurel32/qemu/ Pre-compiled QEMU images]<br /> * [https://code.google.com/archive/p/firmware-mod-kit/ Firmware Modification Kit]<br /> * [https://craigsmith.net/episode-11-1-firmware-extraction/ Short Firmware Extraction Video]<br /> * [https://craigsmith.net/episode-12-1-firmware-emulation-with-qemu/ Firmware Emulation with QEMU]<br /> * [https://craigsmith.net/episode-18-1-file-extraction-from-network-capture/ File Extraction from Network Capture]<br /> <br /> == News and Events ==<br /> * Coming Soon<br /> <br /> |}<br /> <br /> = IoT Event Logging Project=<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File: OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == IoT Logging Events==<br /> <br /> This is a working draft of the recommended minimum IoT Device logging events. This includes many different types of devices, including consumer IoT, enterprise IoT, and ICS/SCADA type devices.<br /> <br /> {| class=&quot;wikitable&quot; border=&quot;1&quot; style=&quot;text-align: left&quot;<br /> ! Event Category<br /> ! Events<br /> |-<br /> | '''Request Exceptions'''<br /> |<br /> * Attempt to Invoke Unsupported HTTP Method<br /> * Unexpected Quantity of Characters in Parameter<br /> * Unexpected Type of Characters in Parameter<br /> |-<br /> | '''Authentication Exceptions'''<br /> |<br /> * Multiple Failed Passwords<br /> * High Rate of Login Attempts<br /> * Additional POST Variable<br /> * Deviation from Normal GEO Location<br /> |-<br /> | '''Session Exceptions'''<br /> |<br /> * Modifying the Existing Cookie<br /> * Substituting Another User's Valid SessionID or Cookie<br /> * Source Location Changes During Session<br /> |-<br /> | '''Access Control Exceptions'''<br /> |<br /> * Modifying URL Argument Within a GET for Direct Object Access Attempt<br /> * Modifying Parameter Within a POST for Direct Object Access Attempt<br /> * Forced Browsing Attempt<br /> |-<br /> | '''Ecosystem Membership Exceptions'''<br /> |<br /> * Traffic Seen from Disenrolled System<br /> * Traffic Seen from Unenrolled System<br /> * Failed Attempt to Enroll in Ecosystem<br /> * Multiple Attempts to Enroll in Ecosystem<br /> |-<br /> | '''Device Access Events'''<br /> |<br /> * Device Case Tampering Detected<br /> * Device Logic Board Tampering Detected<br /> |-<br /> | '''Administrative Mode Events'''<br /> |<br /> * Device Entered Administrative Mode<br /> * Device Accessed Using Default Administrative Credentials<br /> |-<br /> | '''Input Exceptions'''<br /> |<br /> * Double Encoded Character<br /> * Unexpected Encoding Used<br /> |-<br /> | '''Command Injection Exceptions'''<br /> |<br /> * Blacklist Inspection for Common SQL Injection Values<br /> * Abnormal Quantity of Returned Records<br /> |-<br /> | '''Honey Trap Exceptions'''<br /> |<br /> * Honey Trap Resource Requested<br /> * Honey Trap Data Used<br /> |-<br /> | '''Reputation Exceptions'''<br /> |<br /> * Suspicious or Disallowed User Source Location<br /> <br /> |-<br /> |}<br /> <br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right: 25px;&quot; |<br /> <br /> == What is the IoT Security Logging Project? ==<br /> <br /> The IoT Secure Logging Project provides a list of core events that should be logged in any IoT-related system. The project exists because IoT systems in general are not logging nearly enough events to constitute input for a solid detection and response program around IoT devices, and for companies that want to do this there are not many good resources for what should be logged.<br /> <br /> == Project Leaders ==<br /> <br /> * Daniel Miessler<br /> <br /> == Related Projects ==<br /> <br /> * [https://www.owasp.org/index.php/OWASP_AppSensor_Project The OWASP AppSensor Project]<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Quick Download ==<br /> * Coming Soon<br /> <br /> == News and Events ==<br /> * Coming Soon<br /> <br /> |}<br /> <br /> = ICS/SCADA =<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == ICS/SCADA Project ==<br /> <br /> The OWASP ICS/SCADA Top 10 software weaknesses are as follows:<br /> <br /> {| class=&quot;wikitable&quot; border=&quot;1&quot; style=&quot;text-align: left&quot;<br /> ! Rank and ID<br /> ! Title<br /> |- <br /> | '''1 - CWE-119'''<br /> |<br /> * Improper Restriction of Operations within the Bounds of a Memory Buffer<br /> |- <br /> | '''2 - CWE-20'''<br /> |<br /> * Improper Input Validation<br /> |- <br /> | '''3 - CWE-22'''<br /> |<br /> * Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')<br /> |-<br /> | '''4 - CWE-264'''<br /> |<br /> * Permissions, Privileges, and Access Controls<br /> |- <br /> | '''5 - CWE-200'''<br /> |<br /> * Information Exposure<br /> |- <br /> | '''6 - CWE-255'''<br /> |<br /> * Credentials Management<br /> |- <br /> | '''7 - CWE-287'''<br /> |<br /> * Improper Authentication<br /> |- <br /> | '''8 - CWE-399'''<br /> |<br /> * Resource Management Errors<br /> |- <br /> | '''9 - CWE-79'''<br /> |<br /> * Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')<br /> |- <br /> | '''10 - CWE-189'''<br /> |<br /> * Numeric Errors<br /> |- <br /> |}<br /> <br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == What is the ICS/SCADA Project? ==<br /> <br /> The ICS/SCADA Project provides:<br /> <br /> * A list of the Top 10 most dangerous software weaknesses<br /> <br /> == Project Leaders ==<br /> <br /> * NJ Ouchn<br /> <br /> == Related Projects ==<br /> <br /> * [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]<br /> * [[OWASP_Top_Ten_Project|OWASP Web Top 10]]<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Quick Download ==<br /> * Coming Soon<br /> <br /> == News and Events ==<br /> * Coming Soon<br /> <br /> |}<br /> <br /> = IoT Security Policy Project =<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == IoT Security Policy Project ==<br /> <br /> The OWASP IoT Security Policy Project provides:<br /> <br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == What is the IoT Security Policies Project? ==<br /> <br /> The IoT Security Policy Project provides:<br /> <br /> == Project Leaders ==<br /> <br /> * Saša Zdjelar<br /> <br /> == Related Projects ==<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Quick Download ==<br /> * Coming Soon<br /> <br /> == News and Events ==<br /> * Coming Soon<br /> <br /> |}<br /> <br /> = Community =<br /> <br /> [https://www.iamthecavalry.org/ I Am The Cavalry] <br /> <br /> A global grassroots organization that is focused on issues where computer security intersects public safety and human life.<br /> <br /> Their areas of focus include:<br /> * Medical devices<br /> * Automobiles<br /> * Home Electronics<br /> * Public Infrastructure<br /> <br /> [http://builditsecure.ly BuildItSecure.ly]<br /> <br /> A project focused on helping small business connect with security researchers to aid in securing their IoT-based products before going market.<br /> <br /> Their goals include:<br /> * Focus effort towards small business<br /> * Build partnerships<br /> * Coordinate efforts<br /> * Curate informational resources<br /> * Present research<br /> <br /> [https://otalliance.org Online Trust Alliance]<br /> <br /> Formed as an informal industry working group in 2005, today OTA is an Internal Revenue Service (IRS) approved 501c3 charitable organization with the mission to enhance online trust and empower users, while promoting innovation and the vitality of the internet. OTA is global organization supported by over 100 organizations headquartered in Bellevue, Washington with offices in Washington DC.<br /> <br /> Addressing the mounting concerns, in January 2015 the Online Trust Alliance, established the [https://otalliance.org/initiatives/internet-things IoT Trustworthy Working Group (ITWG)], a multi-stakeholder initiative. The group recognizes “security and privacy by design” must be a priority from the onset of product development and be addressed holistically. The framework focuses on privacy, security sustainability. The sustainability pillar is critical as it looks at the life-cycle issues related to long- term supportability and transfers of ownership of devices and the data collected.<br /> <br /> [https://allseenalliance.org/framework AllSeen Alliance]<br /> <br /> The AllSeen Alliance is a Linux Foundation collaborative project. They're a cross-industry consortium dedicated to enabling the interoperability of billions of devices, services and apps that comprise the Internet of Things. The Alliance supports the AllJoyn Framework, an open source software framework that makes it easy for devices and apps to discover and communicate with each other. Developers can write applications for interoperability regardless of transport layer, manufacturer, and without the need for Internet access. The software has been and will continue to be openly available for developers to download, and runs on popular platforms such as Linux and Linux-based Android, iOS, and Windows, including many other lightweight real-time operating systems.<br /> <br /> [http://www.iiconsortium.org/ The Industrial Internet Consortium (IIC)]<br /> <br /> The Industrial Internet Consortium is the open membership, international not-for-profit consortium that is setting the architectural framework and direction for the Industrial Internet. Founded by AT&amp;T, Cisco, GE, IBM and Intel in March 2014, the consortium’s mission is to coordinate vast ecosystem initiatives to connect and integrate objects with people, processes and data using common architectures, interoperability and open standards.<br /> <br /> [http://securingsmartcities.org/ Securing Smart Cities]<br /> <br /> Securing Smart Cities is a not-for-profit global initiative that aims to solve the existing and future cybersecurity problems of smart cities through collaboration between companies, governments, media outlets, other not-for-profit initiatives and individuals across the world.<br /> <br /> ===Talks===<br /> <br /> RSA Conference San Francisco &lt;br&gt; <br /> [https://www.owasp.org/images/5/51/RSAC2015-OWASP-IoT-Miessler.pdf Securing the Internet of Things: Mapping IoT Attack Surface Areas with the OWASP IoT Top 10 Project] &lt;br&gt;<br /> Daniel Miessler, Practice Principal &lt;br&gt;<br /> April 21, 2015 &lt;br&gt;<br /> --- &lt;br&gt;<br /> Defcon 23 &lt;br&gt;<br /> [https://www.owasp.org/images/3/36/IoTTestingMethodology.pdf IoT Attack Surface Mapping] &lt;br&gt;<br /> Daniel Miessler &lt;br&gt;<br /> August 6-9, 2015<br /> <br /> ===Podcasts===<br /> <br /> * [http://iotpodcast.com/ The Internet of Things Podcast]<br /> * [http://www.iot-inc.com/ IoT Inc]<br /> * [https://craigsmith.net/category/podcast/ IoT This Week]<br /> * [http://farstuff.com/ Farstuff: The Internet of Things Podcast]<br /> <br /> ===IoT Conferences===<br /> <br /> * [http://www.iotevents.org Internet of Things Events]<br /> <br /> Conference Call for Papers<br /> * [http://www.wikicfp.com/cfp/servlet/tool.search?q=internet+of+things&amp;year=t WikiCFP - Internet of Things]<br /> * [http://www.wikicfp.com/cfp/servlet/tool.search?q=iot&amp;year=t WikiCFP - IoT]<br /> <br /> <br /> <br /> <br /> <br /> =Project About=<br /> <br /> {{Template:Project About<br /> | project_name =OWASP Internet of Things Project<br /> | project_description = <br /> | project_license =CC-BY 3.0 for documentation and GPLv3 for code. <br /> | leader_name1 = Daniel Miessler<br /> | leader_email1 = <br /> | leader_username1 = <br /> | leader_name2 =Craig Smith<br /> | leader_email2 = <br /> | leader_username2 = <br /> | contributor_name1 = Justin Klein Keane]<br /> | contributor_email1 = <br /> | contributor_username1 = Justin_C._Klein_Keane<br /> | contributor_name2 = Yunsoul<br /> | contributor_email2 = <br /> | contributor_username2 = Yunsoul<br /> | mailing_list_name = <br /> | links_url1 = <br /> | links_name1 =<br /> }} <br /> <br /> <br /> <br /> <br /> <br /> __NOTOC__ &lt;headertabs&gt;&lt;/headertabs&gt;<br /> <br /> [[Category:OWASP_Project]] <br /> [[Category:OWASP_Document]] <br /> [[Category:OWASP_Download]] <br /> [[Category:OWASP_Release_Quality_Document]]</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=OWASP_Internet_of_Things_Project&diff=226190 2017-02-09T15:39:54Z

<p>Tonimir Kisasondi: </p> <hr /> <div>= Main =<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> ==OWASP Internet of Things (IoT) Project==<br /> <br /> Oxford defines the Internet of Things as: “A proposed development of the Internet in which everyday objects have network connectivity, allowing them to send and receive data.”<br /> <br /> ''The OWASP Internet of Things Project is designed to help manufacturers, developers, and consumers better understand the security issues associated with the Internet of Things, and to enable users in any context to make better security decisions when building, deploying, or assessing IoT technologies''. <br /> <br /> The project looks to define a structure for various IoT sub-projects such as Attack Surface Areas, Testing Guides and Top Vulnerabilities.<br /> <br /> [[File:iot-project.png|400px|thumb|center]]<br /> <br /> ==Licensing==<br /> The OWASP Internet of Things Project is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.<br /> <br /> == ==<br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == What is the OWASP Internet of Things Project? ==<br /> <br /> The OWASP Internet of Things Project provides information on:<br /> <br /> * [https://www.owasp.org/index.php/IoT_Attack_Surface_Areas IoT Attack Surface Areas]<br /> * IoT Vulnerabilities<br /> * Firmware Analysis<br /> * ICS/SCADA Software Weaknesses<br /> * Community Information<br /> * [https://www.owasp.org/index.php/IoT_Testing_Guides IoT Testing Guides]<br /> * [https://www.owasp.org/index.php/IoT_Security_Guidance IoT Security Guidance]<br /> * [https://www.owasp.org/index.php/Principles_of_IoT_Security Principles of IoT Security]<br /> * [https://www.owasp.org/index.php/IoT_Framework_Assessment IoT Framework Assessment]<br /> * Developer, Consumer and Manufacturer Guidance<br /> * Design Principles<br /> <br /> == Project Leaders ==<br /> <br /> * Daniel Miessler<br /> * Craig Smith<br /> <br /> == Contributors ==<br /> * [https://www.owasp.org/index.php/User:Justin_C._Klein_Keane Justin Klein Keane]<br /> * Saša Zdjelar<br /> <br /> == Related Projects ==<br /> <br /> * [[OWASP_Project|OWASP Project Repository]]<br /> * [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]<br /> * [[OWASP_Top_Ten_Project|OWASP Web Top 10]]<br /> * [[OWASP_.NET_Project|OWASP .NET]]<br /> * [[Java|OWASP Java and JVM]]<br /> * [[C/C++|OWASP C/C++]]<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:200px;&quot; |<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Quick Download ==<br /> [https://www.owasp.org/images/3/36/IoTTestingMethodology.pdf IoT Attack Surface Mapping DEFCON 23]<br /> <br /> [https://www.owasp.org/images/2/2d/Iot_testing_methodology.JPG IoT Testing Guidance Handout]<br /> <br /> [https://www.owasp.org/images/7/71/Internet_of_Things_Top_Ten_2014-OWASP.pdf OWASP IoT Top Ten PDF]<br /> <br /> [https://www.owasp.org/images/8/8e/Infographic-v1.jpg OWASP IoT Top Ten Infographic]<br /> <br /> [https://www.owasp.org/images/0/01/Internet_of_Things_Top_Ten_2014-OWASP-ppt.pptx OWASP IoT Top Ten PPT]<br /> <br /> [https://www.owasp.org/images/5/51/RSAC2015-OWASP-IoT-Miessler.pdf OWASP IoT Top Ten-RSA 2015]<br /> <br /> [https://www.owasp.org/images/b/bd/OWASP-IoT.pptx OWASP IoT Project Overview]<br /> <br /> == News and Events ==<br /> * Added a [https://owasp-iot-security.slack.com/ Slack channel]<br /> * Added a sub-project; [https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=IoT_Security_Policy_Project IoT Security Policy Project]<br /> * Daniel Miessler gave his [https://www.youtube.com/watch?v=RhxHHD790nw IoT talk at DEFCON 23]<br /> * Migrating the IoT Top Ten to be under the IoT Project<br /> * HP Study Reveals 70 Percent of Internet of Things Devices Vulnerable to Attack<br /> <br /> ==Classifications==<br /> <br /> {| width=&quot;200&quot; cellpadding=&quot;2&quot;<br /> |-<br /> | align=&quot;center&quot; valign=&quot;top&quot; width=&quot;50%&quot; rowspan=&quot;2&quot;| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]<br /> | align=&quot;center&quot; valign=&quot;top&quot; width=&quot;50%&quot;| [[File:Owasp-builders-small.png|link=]] <br /> |-<br /> | align=&quot;center&quot; valign=&quot;top&quot; width=&quot;50%&quot;| [[File:Owasp-defenders-small.png|link=]]<br /> |-<br /> | colspan=&quot;2&quot; align=&quot;center&quot; | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]<br /> |-<br /> | colspan=&quot;2&quot; align=&quot;center&quot; | [[File:Project_Type_Files_DOC.jpg|link=]]<br /> |}<br /> <br /> |}<br /> <br /> = IoT Attack Surface Areas =<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == IoT Attack Surface Areas Project ==<br /> <br /> The OWASP IoT Attack Surface Areas (DRAFT) are as follows:<br /> <br /> {| border=&quot;1&quot; class=&quot;wikitable&quot; style=&quot;text-align: left&quot;<br /> ! Attack Surface<br /> ! Vulnerability<br /> |- <br /> | '''Ecosystem (general)'''<br /> |<br /> * Interoperability standards<br /> * Data governance<br /> * System wide failure<br /> * Individual stakeholder risks<br /> * Implicit trust between components<br /> * Enrollment security<br /> * Decommissioning system<br /> * Lost access procedures<br /> |- <br /> | '''Device Memory'''<br /> |<br /> * Sensitive data<br /> ** Cleartext usernames<br /> ** Cleartext passwords<br /> ** Third-party credentials<br /> ** Encryption keys<br /> |- <br /> | '''Device Physical Interfaces'''<br /> |<br /> * Firmware extraction<br /> * User CLI<br /> * Admin CLI<br /> * Privilege escalation<br /> * Reset to insecure state<br /> * Removal of storage media<br /> * Tamper resistance<br /> * Debug port<br /> * Device ID/Serial number exposure<br /> |-<br /> | '''Device Web Interface'''<br /> |<br /> * Standard set of web vulnerabilities:<br /> ** SQL injection<br /> ** Cross-site scripting<br /> ** Cross-site Request Forgery<br /> ** Username enumeration<br /> * Credential management vulnerabilities:<br /> ** Username enumeration<br /> ** Weak passwords<br /> ** Account lockout<br /> ** Known default credentials<br /> ** Insecure password recovery mechanism<br /> |- <br /> | '''Device Firmware'''<br /> |<br /> * Sensitive data exposure:<br /> ** Backdoor accounts<br /> ** Hardcoded credentials<br /> ** Encryption keys<br /> ** Encryption (Symmetric, Asymmetric)<br /> ** Sensitive information<br /> ** Sensitive URL disclosure<br /> * Firmware version display and/or last update date<br /> * Vulnerable services (web, ssh, tftp, etc.)<br /> * Security related function API exposure<br /> * Firmware downgrade<br /> |- <br /> | '''Device Network Services'''<br /> |<br /> * Information disclosure<br /> * User CLI<br /> * Administrative CLI<br /> * Injection<br /> * Denial of Service<br /> * Unencrypted Services<br /> * Poorly implemented encryption<br /> * Test/Development Services<br /> * Buffer Overflow<br /> * UPnP<br /> * Vulnerable UDP Services<br /> * DoS<br /> * Device Firmware OTA update block<br /> * Replay attack<br /> * Lack of payload verification<br /> * Lack of message integrity check<br /> * Credential management vulnerabilities:<br /> ** Username enumeration<br /> ** Weak passwords<br /> ** Account lockout<br /> ** Known default credentials<br /> ** Insecure password recovery mechanism<br /> |- <br /> | '''Administrative Interface'''<br /> |<br /> * Standard web vulnerabilities:<br /> ** SQL injection<br /> ** Cross-site scripting<br /> ** Cross-site Request Forgery<br /> ** Username enumeration<br /> * Credential management vulnerabilities:<br /> ** Username enumeration<br /> ** Weak passwords<br /> ** Account lockout<br /> ** Known default credentials<br /> ** Insecure password recovery mechanism<br /> * Security/encryption options<br /> * Logging options<br /> * Two-factor authentication<br /> * Inability to wipe device<br /> |- <br /> | '''Local Data Storage'''<br /> |<br /> * Unencrypted data<br /> * Data encrypted with discovered keys<br /> * Lack of data integrity checks<br /> * Use of static same enc/dec key<br /> |- <br /> | '''Cloud Web Interface'''<br /> |<br /> <br /> * Standard set of web vulnerabilities:<br /> ** SQL injection<br /> ** Cross-site scripting<br /> ** Cross-site Request Forgery<br /> * Credential management vulnerabilities:<br /> ** Username enumeration<br /> ** Weak passwords<br /> ** Account lockout<br /> ** Known default credentials<br /> ** Insecure password recovery mechanism<br /> * Transport encryption<br /> * Two-factor authentication<br /> |- <br /> | '''Third-party Backend APIs'''<br /> |<br /> * Unencrypted PII sent<br /> * Encrypted PII sent<br /> * Device information leaked<br /> * Location leaked<br /> |- <br /> | '''Update Mechanism'''<br /> |<br /> * Update sent without encryption<br /> * Updates not signed<br /> * Update location writable<br /> * Update verification<br /> * Update authentication<br /> * Malicious update<br /> * Missing update mechanism<br /> * No manual update mechanism<br /> |- <br /> | '''Mobile Application'''<br /> |<br /> * Implicitly trusted by device or cloud<br /> * Username enumeration<br /> * Account lockout<br /> * Known default credentials<br /> * Weak passwords<br /> * Insecure data storage<br /> * Transport encryption<br /> * Insecure password recovery mechanism<br /> * Two-factor authentication<br /> |- <br /> | '''Vendor Backend APIs'''<br /> |<br /> * Inherent trust of cloud or mobile application<br /> * Weak authentication<br /> * Weak access controls<br /> * Injection attacks<br /> * Hidden services<br /> |- <br /> | '''Ecosystem Communication'''<br /> |<br /> * Health checks<br /> * Heartbeats<br /> * Ecosystem commands<br /> * Deprovisioning<br /> * Pushing updates<br /> |- <br /> | '''Network Traffic'''<br /> |<br /> * LAN<br /> * LAN to Internet<br /> * Short range<br /> * Non-standard<br /> * Wireless (WiFi, Z-wave, XBee, Zigbee, Bluetooth, LoRA)<br /> * Protocol fuzzing<br /> |- <br /> | '''Authentication/Authorization'''<br /> |<br /> * Authentication/Authorization related values (session key, token, cookie, etc.) disclosure<br /> * Reusing of session key, token, etc.<br /> * Device to device authentication<br /> * Device to mobile Application authentication<br /> * Device to cloud system authentication<br /> * Mobile application to cloud system authentication<br /> * Web application to cloud system authentication<br /> * Lack of dynamic authentication<br /> |-<br /> | '''Privacy'''<br /> |<br /> * User data disclosure<br /> * User/device location disclosure<br /> * Differential privacy<br /> |-<br /> | '''Hardware (Sensors)'''<br /> |<br /> * Sensing Environment Manipulation<br /> * Tampering (Physically)<br /> * Damaging (Physically)<br /> <br /> |-<br /> |}<br /> <br /> == ==<br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == What is the IoT Attack Surface Areas Project? ==<br /> <br /> The IoT Attack Surface Areas Project provides a list of attack surfaces that should be understood by manufacturers, developers, security researchers, and those looking to deploy or implement IoT technologies within their organizations.<br /> <br /> == Project Leaders ==<br /> <br /> * Daniel Miessler<br /> * Craig Smith<br /> <br /> == Related Projects ==<br /> <br /> * [https://www.owasp.org/index.php/OWASP_Mobile_Security_Project The OWASP Mobile Top 10 Project]<br /> * [https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project The OWASP Web Top 10 Project]<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Quick Download ==<br /> * Coming Soon<br /> <br /> == News and Events ==<br /> * Coming Soon<br /> <br /> |}<br /> <br /> = IoT Vulnerabilities =<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == IoT Vulnerabilities Project ==<br /> <br /> {| border=&quot;1&quot; class=&quot;wikitable&quot; style=&quot;text-align: left&quot;<br /> ! Vulnerability<br /> ! Attack Surface<br /> ! Summary<br /> |-<br /> | '''Username Enumeration'''<br /> |<br /> * Administrative Interface<br /> * Device Web Interface<br /> * Cloud Interface<br /> * Mobile Application<br /> |<br /> * Ability to collect a set of valid usernames by interacting with the authentication mechanism<br /> |-<br /> | '''Weak Passwords'''<br /> |<br /> * Administrative Interface<br /> * Device Web Interface<br /> * Cloud Interface<br /> * Mobile Application<br /> |<br /> * Ability to set account passwords to '1234' or '123456' for example.<br /> |-<br /> | '''Account Lockout'''<br /> |<br /> * Administrative Interface<br /> * Device Web Interface<br /> * Cloud Interface<br /> * Mobile Application<br /> |<br /> * Ability to continue sending authentication attempts after 3 - 5 failed login attempts<br /> |-<br /> | '''Unencrypted Services'''<br /> |<br /> * Device Network Services<br /> |<br /> * Network services are not properly encrypted to prevent eavesdropping by attackers<br /> |-<br /> | '''Two-factor Authentication'''<br /> |<br /> * Administrative Interface<br /> * Cloud Web Interface<br /> * Mobile Application<br /> |<br /> * Lack of two-factor authentication mechanisms such as a security token or fingerprint scanner<br /> |-<br /> | '''Poorly Implemented Encryption'''<br /> |<br /> * Device Network Services<br /> |<br /> * Encryption is implemented however it is improperly configured or is not being properly updated, e.g. using SSL v2 <br /> |-<br /> | '''Update Sent Without Encryption'''<br /> |<br /> * Update Mechanism<br /> |<br /> * Updates are transmitted over the network without using TLS or encrypting the update file itself<br /> |-<br /> | '''Update Location Writable'''<br /> |<br /> * Update Mechanism<br /> |<br /> * Storage location for update files is world writable potentially allowing firmware to be modified and distributed to all users<br /> |-<br /> | '''Denial of Service'''<br /> |<br /> * Device Network Services<br /> |<br /> * Service can be attacked in a way that denies service to that service or the entire device<br /> |-<br /> | '''Removal of Storage Media'''<br /> |<br /> * Device Physical Interfaces<br /> |<br /> * Ability to physically remove the storage media from the device<br /> |-<br /> | '''No Manual Update Mechanism'''<br /> |<br /> * Update Mechanism<br /> |<br /> * No ability to manually force an update check for the device<br /> |-<br /> | '''Missing Update Mechanism'''<br /> |<br /> * Update Mechanism<br /> |<br /> * No ability to update device<br /> |-<br /> | '''Firmware Version Display and/or Last Update Date'''<br /> |<br /> * Device Firmware<br /> |<br /> * Current firmware version is not displayed and/or the last update date is not displayed<br /> |-<br /> | '''Firmware and storage extraction'''<br /> |<br /> * JTAG / SWD interface<br /> * [https://www.flashrom.org/Flashrom In-Situ dumping]<br /> * Intercepting a OTA update<br /> * Downloading from the manufacturers web page<br /> * [https://www.exploitee.rs/index.php/Exploitee.rs_Low_Voltage_e-MMC_Adapter eMMC tapping]<br /> * Unsoldering the SPI Flash / eMMC chip and reading it in a adapter<br /> |<br /> * Firmware contains a lot of useful information, like source code and binaries of running services, pre-set passwords, ssh keys etc. <br /> |-<br /> | '''Manipulating the code execution flow of the device'''<br /> |<br /> * JTAG / SWD interface<br /> * [https://wiki.newae.com/Main_Page Side channel attacks like glitching]<br /> |<br /> * With the help of a JTAG adapter and gdb we can modify the execution of firmware in the device and bypass almost all software based security controls.<br /> * Side channel attacks can also modify the execution flow or can be used to leak interesting information from the device<br /> |-<br /> | '''Obtaining console access'''<br /> |<br /> * Serial interfaces (SPI / UART)<br /> |<br /> * By connecting to a serial interface, we will obtain full console access to a device<br /> * Usually security measures include custom bootloaders that prevent the attacker from entering single user mode, but that can also be bypassed.<br /> <br /> <br /> |-<br /> <br /> <br /> <br /> <br /> |}<br /> <br /> == ==<br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == What is the IoT Vulnerabilities Project? ==<br /> <br /> The IoT Vulnerabilities Project provides:<br /> <br /> * Information on the top IoT vulnerabilities<br /> * The attack surface associated with the vulnerability<br /> * A summary of the vulnerability<br /> <br /> == Project Leaders ==<br /> <br /> * Daniel Miessler<br /> * Craig Smith<br /> <br /> == Related Projects ==<br /> <br /> * [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]<br /> * [[OWASP_Top_Ten_Project|OWASP Web Top 10]]<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Resources ==<br /> * [https://www.owasp.org/index.php/Top_IoT_Vulnerabilities Top 10 IoT Vulnerabilities from 2014]<br /> <br /> == News and Events ==<br /> * Coming Soon<br /> <br /> |}<br /> <br /> = Firmware Analysis =<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == Firmware Analysis Project ==<br /> <br /> The Firmware Analysis Project is intended to provide security testing guidance for the IoT Attack Surface &quot;Device Firmware&quot;:<br /> <br /> {| border=&quot;1&quot; class=&quot;wikitable&quot; style=&quot;text-align: left&quot;<br /> ! Section<br /> ! <br /> |- <br /> |<br /> Device Firmware Vulnerabilties<br /> |<br /> * Out-of-date core components<br /> * Unsupported core components<br /> * Expired and/or self-signed certificates<br /> * Same certificate used on multiple devices<br /> * Admin web interface concerns<br /> * Hardcoded or easy to guess credentials<br /> * Sensitive information disclosure<br /> * Sensitive URL disclosure<br /> * Encryption key exposure<br /> * Backdoor accounts<br /> * Vulnerable services (web, ssh, tftp, etc.)<br /> |-<br /> |<br /> Manufacturer Recommendations<br /> |<br /> * Ensure that supported and up-to-date software is used by developers<br /> * Ensure that robust update mechanisms are in place for devices<br /> * Ensure that certificates are not duplicated across devices and product lines.<br /> * Ensure supported and up-to-date software is used by developers<br /> * Develop a mechanism to ensure a new certificate is installed when old ones expire<br /> * Disable deprecated SSL versions<br /> * Ensure developers do not code in easy to guess or common admin passwords<br /> * Ensure services such as SSH have a secure password created<br /> * Develop a mechanism that requires the user to create a secure admin password during initial device setup<br /> * Ensure developers do not hard code passwords or hashes<br /> * Have source code reviewed by a third party before releasing device to production<br /> * Ensure industry standard encryption or strong hashing is used<br /> |-<br /> |<br /> Device Firmware Guidance and Instruction<br /> |<br /> * Firmware file analysis<br /> * Firmware extraction<br /> * Dynamic binary analysis<br /> * Static binary analysis<br /> * Static code analysis<br /> * Firmware emulation<br /> * File system analysis<br /> |-<br /> |<br /> Device Firmware Tools<br /> |<br /> * [https://github.com/craigz28/firmwalker Firmwalker] <br /> * [https://code.google.com/archive/p/firmware-mod-kit/ Firmware Modification Kit]<br /> * [https://github.com/angr/angr Angr binary analysis framework]<br /> * [http://binwalk.org/ Binwalk firmware analysis tool]<br /> * [http://www.binaryanalysis.org/en/home Binary Analysis Tool]<br /> * [https://github.com/firmadyne/firmadyne Firmadyne]<br /> |-<br /> |<br /> Vulnerable Firmware<br /> |<br /> * [https://github.com/praetorian-inc/DVRF Damn Vulnerable Router Firmware]<br /> |-<br /> |}<br /> <br /> == ==<br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == What is the Firmware Analysis Project? ==<br /> <br /> The Firmware Analysis Project provides:<br /> <br /> * Security testing guidance for vulnerabilities in the &quot;Device Firmware&quot; attack surface<br /> * Steps for extracting file systems from various firmware files<br /> * Guidance on searching a file systems for sensitive of interesting data<br /> * Information on static analysis of firmware contents<br /> * Information on dynamic analysis of emulated services (e.g. web admin interface)<br /> * Testing tool links<br /> * A site for pulling together existing information on firmware analysis<br /> <br /> == Project Leaders ==<br /> <br /> * Craig Smith<br /> <br /> == Related Projects ==<br /> <br /> * [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]<br /> * [[OWASP_Top_Ten_Project|OWASP Web Top 10]]<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Resources ==<br /> * [https://www.owasp.org/index.php/IoT_Firmware_Analysis IoT Firmware Analysis Primer]<br /> * [https://otalliance.org/initiatives/internet-things Online Trust Alliance - Internet of Things]<br /> * [https://people.debian.org/~aurel32/qemu/ Pre-compiled QEMU images]<br /> * [https://code.google.com/archive/p/firmware-mod-kit/ Firmware Modification Kit]<br /> * [https://craigsmith.net/episode-11-1-firmware-extraction/ Short Firmware Extraction Video]<br /> * [https://craigsmith.net/episode-12-1-firmware-emulation-with-qemu/ Firmware Emulation with QEMU]<br /> * [https://craigsmith.net/episode-18-1-file-extraction-from-network-capture/ File Extraction from Network Capture]<br /> <br /> == News and Events ==<br /> * Coming Soon<br /> <br /> |}<br /> <br /> = IoT Event Logging Project=<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File: OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == IoT Logging Events==<br /> <br /> This is a working draft of the recommended minimum IoT Device logging events. This includes many different types of devices, including consumer IoT, enterprise IoT, and ICS/SCADA type devices.<br /> <br /> {| border=&quot;1&quot; class=&quot;wikitable&quot; style=&quot;text-align: left&quot;<br /> ! Event Category<br /> ! Events<br /> |-<br /> | '''Request Exceptions'''<br /> |<br /> * Attempt to Invoke Unsupported HTTP Method<br /> * Unexpected Quantity of Characters in Parameter<br /> * Unexpected Type of Characters in Parameter<br /> |-<br /> | '''Authentication Exceptions'''<br /> |<br /> * Multiple Failed Passwords<br /> * High Rate of Login Attempts<br /> * Additional POST Variable<br /> * Deviation from Normal GEO Location<br /> |-<br /> | '''Session Exceptions'''<br /> |<br /> * Modifying the Existing Cookie<br /> * Substituting Another User's Valid SessionID or Cookie<br /> * Source Location Changes During Session<br /> |-<br /> | '''Access Control Exceptions'''<br /> |<br /> * Modifying URL Argument Within a GET for Direct Object Access Attempt<br /> * Modifying Parameter Within a POST for Direct Object Access Attempt<br /> * Forced Browsing Attempt<br /> |-<br /> | '''Ecosystem Membership Exceptions'''<br /> |<br /> * Traffic Seen from Disenrolled System<br /> * Traffic Seen from Unenrolled System<br /> * Failed Attempt to Enroll in Ecosystem<br /> * Multiple Attempts to Enroll in Ecosystem<br /> |-<br /> | '''Device Access Events'''<br /> |<br /> * Device Case Tampering Detected<br /> * Device Logic Board Tampering Detected<br /> |-<br /> | '''Administrative Mode Events'''<br /> |<br /> * Device Entered Administrative Mode<br /> * Device Accessed Using Default Administrative Credentials<br /> |-<br /> | '''Input Exceptions'''<br /> |<br /> * Double Encoded Character<br /> * Unexpected Encoding Used<br /> |-<br /> | '''Command Injection Exceptions'''<br /> |<br /> * Blacklist Inspection for Common SQL Injection Values<br /> * Abnormal Quantity of Returned Records<br /> |-<br /> | '''Honey Trap Exceptions'''<br /> |<br /> * Honey Trap Resource Requested<br /> * Honey Trap Data Used<br /> |-<br /> | '''Reputation Exceptions'''<br /> |<br /> * Suspicious or Disallowed User Source Location<br /> <br /> |-<br /> |}<br /> <br /> == ==<br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right: 25px;&quot; |<br /> <br /> == What is the IoT Security Logging Project? ==<br /> <br /> The IoT Secure Logging Project provides a list of core events that should be logged in any IoT-related system. The project exists because IoT systems in general are not logging nearly enough events to constitute input for a solid detection and response program around IoT devices, and for companies that want to do this there are not many good resources for what should be logged.<br /> <br /> == Project Leaders ==<br /> <br /> * Daniel Miessler<br /> <br /> == Related Projects ==<br /> <br /> * [https://www.owasp.org/index.php/OWASP_AppSensor_Project The OWASP AppSensor Project]<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Quick Download ==<br /> * Coming Soon<br /> <br /> == News and Events ==<br /> * Coming Soon<br /> <br /> |}<br /> <br /> = ICS/SCADA =<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == ICS/SCADA Project ==<br /> <br /> The OWASP ICS/SCADA Top 10 software weaknesses are as follows:<br /> <br /> {| border=&quot;1&quot; class=&quot;wikitable&quot; style=&quot;text-align: left&quot;<br /> ! Rank and ID<br /> ! Title<br /> |- <br /> | '''1 - CWE-119'''<br /> |<br /> * Improper Restriction of Operations within the Bounds of a Memory Buffer<br /> |- <br /> | '''2 - CWE-20'''<br /> |<br /> * Improper Input Validation<br /> |- <br /> | '''3 - CWE-22'''<br /> |<br /> * Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')<br /> |-<br /> | '''4 - CWE-264'''<br /> |<br /> * Permissions, Privileges, and Access Controls<br /> |- <br /> | '''5 - CWE-200'''<br /> |<br /> * Information Exposure<br /> |- <br /> | '''6 - CWE-255'''<br /> |<br /> * Credentials Management<br /> |- <br /> | '''7 - CWE-287'''<br /> |<br /> * Improper Authentication<br /> |- <br /> | '''8 - CWE-399'''<br /> |<br /> * Resource Management Errors<br /> |- <br /> | '''9 - CWE-79'''<br /> |<br /> * Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')<br /> |- <br /> | '''10 - CWE-189'''<br /> |<br /> * Numeric Errors<br /> |- <br /> |}<br /> <br /> == ==<br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == What is the ICS/SCADA Project? ==<br /> <br /> The ICS/SCADA Project provides:<br /> <br /> * A list of the Top 10 most dangerous software weaknesses<br /> <br /> == Project Leaders ==<br /> <br /> * NJ Ouchn<br /> <br /> == Related Projects ==<br /> <br /> * [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]<br /> * [[OWASP_Top_Ten_Project|OWASP Web Top 10]]<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Quick Download ==<br /> * Coming Soon<br /> <br /> == News and Events ==<br /> * Coming Soon<br /> <br /> |}<br /> <br /> = IoT Security Policy Project =<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == IoT Security Policy Project ==<br /> <br /> The OWASP IoT Security Policy Project provides:<br /> <br /> == ==<br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == What is the IoT Security Policies Project? ==<br /> <br /> The IoT Security Policy Project provides:<br /> <br /> == Project Leaders ==<br /> <br /> * Saša Zdjelar<br /> <br /> == Related Projects ==<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Quick Download ==<br /> * Coming Soon<br /> <br /> == News and Events ==<br /> * Coming Soon<br /> <br /> |}<br /> <br /> <br /> <br /> = Community =<br /> <br /> [https://www.iamthecavalry.org/ I Am The Cavalry] <br /> <br /> A global grassroots organization that is focused on issues where computer security intersects public safety and human life.<br /> <br /> Their areas of focus include:<br /> * Medical devices<br /> * Automobiles<br /> * Home Electronics<br /> * Public Infrastructure<br /> == ==<br /> [http://builditsecure.ly BuildItSecure.ly]<br /> <br /> A project focused on helping small business connect with security researchers to aid in securing their IoT-based products before going market.<br /> <br /> Their goals include:<br /> * Focus effort towards small business<br /> * Build partnerships<br /> * Coordinate efforts<br /> * Curate informational resources<br /> * Present research<br /> == ==<br /> [https://otalliance.org Online Trust Alliance]<br /> <br /> Formed as an informal industry working group in 2005, today OTA is an Internal Revenue Service (IRS) approved 501c3 charitable organization with the mission to enhance online trust and empower users, while promoting innovation and the vitality of the internet. OTA is global organization supported by over 100 organizations headquartered in Bellevue, Washington with offices in Washington DC.<br /> <br /> Addressing the mounting concerns, in January 2015 the Online Trust Alliance, established the [https://otalliance.org/initiatives/internet-things IoT Trustworthy Working Group (ITWG)], a multi-stakeholder initiative. The group recognizes “security and privacy by design” must be a priority from the onset of product development and be addressed holistically. The framework focuses on privacy, security sustainability. The sustainability pillar is critical as it looks at the life-cycle issues related to long- term supportability and transfers of ownership of devices and the data collected.<br /> == ==<br /> [https://allseenalliance.org/framework AllSeen Alliance]<br /> <br /> The AllSeen Alliance is a Linux Foundation collaborative project. They're a cross-industry consortium dedicated to enabling the interoperability of billions of devices, services and apps that comprise the Internet of Things. The Alliance supports the AllJoyn Framework, an open source software framework that makes it easy for devices and apps to discover and communicate with each other. Developers can write applications for interoperability regardless of transport layer, manufacturer, and without the need for Internet access. The software has been and will continue to be openly available for developers to download, and runs on popular platforms such as Linux and Linux-based Android, iOS, and Windows, including many other lightweight real-time operating systems.<br /> == ==<br /> [http://www.iiconsortium.org/ The Industrial Internet Consortium (IIC)]<br /> <br /> The Industrial Internet Consortium is the open membership, international not-for-profit consortium that is setting the architectural framework and direction for the Industrial Internet. Founded by AT&amp;T, Cisco, GE, IBM and Intel in March 2014, the consortium’s mission is to coordinate vast ecosystem initiatives to connect and integrate objects with people, processes and data using common architectures, interoperability and open standards.<br /> == ==<br /> [http://securingsmartcities.org/ Securing Smart Cities]<br /> <br /> Securing Smart Cities is a not-for-profit global initiative that aims to solve the existing and future cybersecurity problems of smart cities through collaboration between companies, governments, media outlets, other not-for-profit initiatives and individuals across the world.<br /> <br /> ===Talks===<br /> <br /> RSA Conference San Francisco &lt;br&gt; <br /> [https://www.owasp.org/images/5/51/RSAC2015-OWASP-IoT-Miessler.pdf Securing the Internet of Things: Mapping IoT Attack Surface Areas with the OWASP IoT Top 10 Project] &lt;br&gt;<br /> Daniel Miessler, Practice Principal &lt;br&gt;<br /> April 21, 2015 &lt;br&gt;<br /> --- &lt;br&gt;<br /> Defcon 23 &lt;br&gt;<br /> [https://www.owasp.org/images/3/36/IoTTestingMethodology.pdf IoT Attack Surface Mapping] &lt;br&gt;<br /> Daniel Miessler &lt;br&gt;<br /> August 6-9, 2015<br /> <br /> ===Podcasts===<br /> <br /> * [http://iotpodcast.com/ The Internet of Things Podcast]<br /> * [http://www.iot-inc.com/ IoT Inc]<br /> * [https://craigsmith.net/category/podcast/ IoT This Week]<br /> * [http://farstuff.com/ Farstuff: The Internet of Things Podcast]<br /> <br /> ===IoT Conferences===<br /> <br /> * [http://www.iotevents.org Internet of Things Events]<br /> <br /> Conference Call for Papers<br /> * [http://www.wikicfp.com/cfp/servlet/tool.search?q=internet+of+things&amp;year=t WikiCFP - Internet of Things]<br /> * [http://www.wikicfp.com/cfp/servlet/tool.search?q=iot&amp;year=t WikiCFP - IoT]<br /> <br /> <br /> <br /> <br /> <br /> <br /> =Project About=<br /> <br /> {{Template:Project About<br /> | project_name =OWASP Internet of Things Project<br /> | project_description = <br /> | project_license =CC-BY 3.0 for documentation and GPLv3 for code. <br /> | leader_name1 = Daniel Miessler<br /> | leader_email1 = <br /> | leader_username1 = <br /> | leader_name2 =Craig Smith<br /> | leader_email2 = <br /> | leader_username2 = <br /> | contributor_name1 = Justin Klein Keane]<br /> | contributor_email1 = <br /> | contributor_username1 = Justin_C._Klein_Keane<br /> | contributor_name2 = Yunsoul<br /> | contributor_email2 = <br /> | contributor_username2 = Yunsoul<br /> | mailing_list_name = <br /> | links_url1 = <br /> | links_name1 =<br /> | links_url1 = <br /> | links_name1 = <br /> }} <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> __NOTOC__ &lt;headertabs /&gt;<br /> <br /> [[Category:OWASP_Project]] [[Category:OWASP_Document]] [[Category:OWASP_Download]] [[Category:OWASP_Release_Quality_Document]]</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=OWASP_Internet_of_Things_Project&diff=226189 2017-02-09T15:13:50Z

<p>Tonimir Kisasondi: </p> <hr /> <div>= Main =<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> ==OWASP Internet of Things (IoT) Project==<br /> <br /> Oxford defines the Internet of Things as: “A proposed development of the Internet in which everyday objects have network connectivity, allowing them to send and receive data.”<br /> <br /> ''The OWASP Internet of Things Project is designed to help manufacturers, developers, and consumers better understand the security issues associated with the Internet of Things, and to enable users in any context to make better security decisions when building, deploying, or assessing IoT technologies''. <br /> <br /> The project looks to define a structure for various IoT sub-projects such as Attack Surface Areas, Testing Guides and Top Vulnerabilities.<br /> <br /> [[File:iot-project.png|400px|thumb|center]]<br /> <br /> ==Licensing==<br /> The OWASP Internet of Things Project is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.<br /> <br /> == ==<br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == What is the OWASP Internet of Things Project? ==<br /> <br /> The OWASP Internet of Things Project provides information on:<br /> <br /> * [https://www.owasp.org/index.php/IoT_Attack_Surface_Areas IoT Attack Surface Areas]<br /> * IoT Vulnerabilities<br /> * Firmware Analysis<br /> * ICS/SCADA Software Weaknesses<br /> * Community Information<br /> * [https://www.owasp.org/index.php/IoT_Testing_Guides IoT Testing Guides]<br /> * [https://www.owasp.org/index.php/IoT_Security_Guidance IoT Security Guidance]<br /> * [https://www.owasp.org/index.php/Principles_of_IoT_Security Principles of IoT Security]<br /> * [https://www.owasp.org/index.php/IoT_Framework_Assessment IoT Framework Assessment]<br /> * Developer, Consumer and Manufacturer Guidance<br /> * Design Principles<br /> <br /> == Project Leaders ==<br /> <br /> * Daniel Miessler<br /> * Craig Smith<br /> <br /> == Contributors ==<br /> * [https://www.owasp.org/index.php/User:Justin_C._Klein_Keane Justin Klein Keane]<br /> * Saša Zdjelar<br /> <br /> == Related Projects ==<br /> <br /> * [[OWASP_Project|OWASP Project Repository]]<br /> * [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]<br /> * [[OWASP_Top_Ten_Project|OWASP Web Top 10]]<br /> * [[OWASP_.NET_Project|OWASP .NET]]<br /> * [[Java|OWASP Java and JVM]]<br /> * [[C/C++|OWASP C/C++]]<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:200px;&quot; |<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Quick Download ==<br /> [https://www.owasp.org/images/3/36/IoTTestingMethodology.pdf IoT Attack Surface Mapping DEFCON 23]<br /> <br /> [https://www.owasp.org/images/2/2d/Iot_testing_methodology.JPG IoT Testing Guidance Handout]<br /> <br /> [https://www.owasp.org/images/7/71/Internet_of_Things_Top_Ten_2014-OWASP.pdf OWASP IoT Top Ten PDF]<br /> <br /> [https://www.owasp.org/images/8/8e/Infographic-v1.jpg OWASP IoT Top Ten Infographic]<br /> <br /> [https://www.owasp.org/images/0/01/Internet_of_Things_Top_Ten_2014-OWASP-ppt.pptx OWASP IoT Top Ten PPT]<br /> <br /> [https://www.owasp.org/images/5/51/RSAC2015-OWASP-IoT-Miessler.pdf OWASP IoT Top Ten-RSA 2015]<br /> <br /> [https://www.owasp.org/images/b/bd/OWASP-IoT.pptx OWASP IoT Project Overview]<br /> <br /> == News and Events ==<br /> * Added a [https://owasp-iot-security.slack.com/ Slack channel]<br /> * Added a sub-project; [https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=IoT_Security_Policy_Project IoT Security Policy Project]<br /> * Daniel Miessler gave his [https://www.youtube.com/watch?v=RhxHHD790nw IoT talk at DEFCON 23]<br /> * Migrating the IoT Top Ten to be under the IoT Project<br /> * HP Study Reveals 70 Percent of Internet of Things Devices Vulnerable to Attack<br /> <br /> ==Classifications==<br /> <br /> {| width=&quot;200&quot; cellpadding=&quot;2&quot;<br /> |-<br /> | align=&quot;center&quot; valign=&quot;top&quot; width=&quot;50%&quot; rowspan=&quot;2&quot;| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]<br /> | align=&quot;center&quot; valign=&quot;top&quot; width=&quot;50%&quot;| [[File:Owasp-builders-small.png|link=]] <br /> |-<br /> | align=&quot;center&quot; valign=&quot;top&quot; width=&quot;50%&quot;| [[File:Owasp-defenders-small.png|link=]]<br /> |-<br /> | colspan=&quot;2&quot; align=&quot;center&quot; | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]<br /> |-<br /> | colspan=&quot;2&quot; align=&quot;center&quot; | [[File:Project_Type_Files_DOC.jpg|link=]]<br /> |}<br /> <br /> |}<br /> <br /> = IoT Attack Surface Areas =<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == IoT Attack Surface Areas Project ==<br /> <br /> The OWASP IoT Attack Surface Areas (DRAFT) are as follows:<br /> <br /> {| border=&quot;1&quot; class=&quot;wikitable&quot; style=&quot;text-align: left&quot;<br /> ! Attack Surface<br /> ! Vulnerability<br /> |- <br /> | '''Ecosystem (general)'''<br /> |<br /> * Interoperability standards<br /> * Data governance<br /> * System wide failure<br /> * Individual stakeholder risks<br /> * Implicit trust between components<br /> * Enrollment security<br /> * Decommissioning system<br /> * Lost access procedures<br /> |- <br /> | '''Device Memory'''<br /> |<br /> * Sensitive data<br /> ** Cleartext usernames<br /> ** Cleartext passwords<br /> ** Third-party credentials<br /> ** Encryption keys<br /> |- <br /> | '''Device Physical Interfaces'''<br /> |<br /> * Firmware extraction<br /> * User CLI<br /> * Admin CLI<br /> * Privilege escalation<br /> * Reset to insecure state<br /> * Removal of storage media<br /> * Tamper resistance<br /> * Debug port<br /> * Device ID/Serial number exposure<br /> |-<br /> | '''Device Web Interface'''<br /> |<br /> * Standard set of web vulnerabilities:<br /> ** SQL injection<br /> ** Cross-site scripting<br /> ** Cross-site Request Forgery<br /> ** Username enumeration<br /> * Credential management vulnerabilities:<br /> ** Username enumeration<br /> ** Weak passwords<br /> ** Account lockout<br /> ** Known default credentials<br /> ** Insecure password recovery mechanism<br /> |- <br /> | '''Device Firmware'''<br /> |<br /> * Sensitive data exposure:<br /> ** Backdoor accounts<br /> ** Hardcoded credentials<br /> ** Encryption keys<br /> ** Encryption (Symmetric, Asymmetric)<br /> ** Sensitive information<br /> ** Sensitive URL disclosure<br /> * Firmware version display and/or last update date<br /> * Vulnerable services (web, ssh, tftp, etc.)<br /> * Security related function API exposure<br /> * Firmware downgrade<br /> |- <br /> | '''Device Network Services'''<br /> |<br /> * Information disclosure<br /> * User CLI<br /> * Administrative CLI<br /> * Injection<br /> * Denial of Service<br /> * Unencrypted Services<br /> * Poorly implemented encryption<br /> * Test/Development Services<br /> * Buffer Overflow<br /> * UPnP<br /> * Vulnerable UDP Services<br /> * DoS<br /> * Device Firmware OTA update block<br /> * Replay attack<br /> * Lack of payload verification<br /> * Lack of message integrity check<br /> * Credential management vulnerabilities:<br /> ** Username enumeration<br /> ** Weak passwords<br /> ** Account lockout<br /> ** Known default credentials<br /> ** Insecure password recovery mechanism<br /> |- <br /> | '''Administrative Interface'''<br /> |<br /> * Standard web vulnerabilities:<br /> ** SQL injection<br /> ** Cross-site scripting<br /> ** Cross-site Request Forgery<br /> ** Username enumeration<br /> * Credential management vulnerabilities:<br /> ** Username enumeration<br /> ** Weak passwords<br /> ** Account lockout<br /> ** Known default credentials<br /> ** Insecure password recovery mechanism<br /> * Security/encryption options<br /> * Logging options<br /> * Two-factor authentication<br /> * Inability to wipe device<br /> |- <br /> | '''Local Data Storage'''<br /> |<br /> * Unencrypted data<br /> * Data encrypted with discovered keys<br /> * Lack of data integrity checks<br /> * Use of static same enc/dec key<br /> |- <br /> | '''Cloud Web Interface'''<br /> |<br /> <br /> * Standard set of web vulnerabilities:<br /> ** SQL injection<br /> ** Cross-site scripting<br /> ** Cross-site Request Forgery<br /> * Credential management vulnerabilities:<br /> ** Username enumeration<br /> ** Weak passwords<br /> ** Account lockout<br /> ** Known default credentials<br /> ** Insecure password recovery mechanism<br /> * Transport encryption<br /> * Two-factor authentication<br /> |- <br /> | '''Third-party Backend APIs'''<br /> |<br /> * Unencrypted PII sent<br /> * Encrypted PII sent<br /> * Device information leaked<br /> * Location leaked<br /> |- <br /> | '''Update Mechanism'''<br /> |<br /> * Update sent without encryption<br /> * Updates not signed<br /> * Update location writable<br /> * Update verification<br /> * Update authentication<br /> * Malicious update<br /> * Missing update mechanism<br /> * No manual update mechanism<br /> |- <br /> | '''Mobile Application'''<br /> |<br /> * Implicitly trusted by device or cloud<br /> * Username enumeration<br /> * Account lockout<br /> * Known default credentials<br /> * Weak passwords<br /> * Insecure data storage<br /> * Transport encryption<br /> * Insecure password recovery mechanism<br /> * Two-factor authentication<br /> |- <br /> | '''Vendor Backend APIs'''<br /> |<br /> * Inherent trust of cloud or mobile application<br /> * Weak authentication<br /> * Weak access controls<br /> * Injection attacks<br /> * Hidden services<br /> |- <br /> | '''Ecosystem Communication'''<br /> |<br /> * Health checks<br /> * Heartbeats<br /> * Ecosystem commands<br /> * Deprovisioning<br /> * Pushing updates<br /> |- <br /> | '''Network Traffic'''<br /> |<br /> * LAN<br /> * LAN to Internet<br /> * Short range<br /> * Non-standard<br /> * Wireless (WiFi, Z-wave, XBee, Zigbee, Bluetooth, LoRA)<br /> * Protocol fuzzing<br /> |- <br /> | '''Authentication/Authorization'''<br /> |<br /> * Authentication/Authorization related values (session key, token, cookie, etc.) disclosure<br /> * Reusing of session key, token, etc.<br /> * Device to device authentication<br /> * Device to mobile Application authentication<br /> * Device to cloud system authentication<br /> * Mobile application to cloud system authentication<br /> * Web application to cloud system authentication<br /> * Lack of dynamic authentication<br /> |-<br /> | '''Privacy'''<br /> |<br /> * User data disclosure<br /> * User/device location disclosure<br /> * Differential privacy<br /> |-<br /> | '''Hardware (Sensors)'''<br /> |<br /> * Sensing Environment Manipulation<br /> * Tampering (Physically)<br /> * Damaging (Physically)<br /> <br /> |-<br /> |}<br /> <br /> == ==<br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == What is the IoT Attack Surface Areas Project? ==<br /> <br /> The IoT Attack Surface Areas Project provides a list of attack surfaces that should be understood by manufacturers, developers, security researchers, and those looking to deploy or implement IoT technologies within their organizations.<br /> <br /> == Project Leaders ==<br /> <br /> * Daniel Miessler<br /> * Craig Smith<br /> <br /> == Related Projects ==<br /> <br /> * [https://www.owasp.org/index.php/OWASP_Mobile_Security_Project The OWASP Mobile Top 10 Project]<br /> * [https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project The OWASP Web Top 10 Project]<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Quick Download ==<br /> * Coming Soon<br /> <br /> == News and Events ==<br /> * Coming Soon<br /> <br /> |}<br /> <br /> = IoT Vulnerabilities =<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == IoT Vulnerabilities Project ==<br /> <br /> {| border=&quot;1&quot; class=&quot;wikitable&quot; style=&quot;text-align: left&quot;<br /> ! Vulnerability<br /> ! Attack Surface<br /> ! Summary<br /> |-<br /> | '''Username Enumeration'''<br /> |<br /> * Administrative Interface<br /> * Device Web Interface<br /> * Cloud Interface<br /> * Mobile Application<br /> |<br /> * Ability to collect a set of valid usernames by interacting with the authentication mechanism<br /> |-<br /> | '''Weak Passwords'''<br /> |<br /> * Administrative Interface<br /> * Device Web Interface<br /> * Cloud Interface<br /> * Mobile Application<br /> |<br /> * Ability to set account passwords to '1234' or '123456' for example.<br /> |-<br /> | '''Account Lockout'''<br /> |<br /> * Administrative Interface<br /> * Device Web Interface<br /> * Cloud Interface<br /> * Mobile Application<br /> |<br /> * Ability to continue sending authentication attempts after 3 - 5 failed login attempts<br /> |-<br /> | '''Unencrypted Services'''<br /> |<br /> * Device Network Services<br /> |<br /> * Network services are not properly encrypted to prevent eavesdropping by attackers<br /> |-<br /> | '''Two-factor Authentication'''<br /> |<br /> * Administrative Interface<br /> * Cloud Web Interface<br /> * Mobile Application<br /> |<br /> * Lack of two-factor authentication mechanisms such as a security token or fingerprint scanner<br /> |-<br /> | '''Poorly Implemented Encryption'''<br /> |<br /> * Device Network Services<br /> |<br /> * Encryption is implemented however it is improperly configured or is not being properly updated, e.g. using SSL v2 <br /> |-<br /> | '''Update Sent Without Encryption'''<br /> |<br /> * Update Mechanism<br /> |<br /> * Updates are transmitted over the network without using TLS or encrypting the update file itself<br /> |-<br /> | '''Update Location Writable'''<br /> |<br /> * Update Mechanism<br /> |<br /> * Storage location for update files is world writable potentially allowing firmware to be modified and distributed to all users<br /> |-<br /> | '''Denial of Service'''<br /> |<br /> * Device Network Services<br /> |<br /> * Service can be attacked in a way that denies service to that service or the entire device<br /> |-<br /> | '''Removal of Storage Media'''<br /> |<br /> * Device Physical Interfaces<br /> |<br /> * Ability to physically remove the storage media from the device<br /> |-<br /> | '''No Manual Update Mechanism'''<br /> |<br /> * Update Mechanism<br /> |<br /> * No ability to manually force an update check for the device<br /> |-<br /> | '''Missing Update Mechanism'''<br /> |<br /> * Update Mechanism<br /> |<br /> * No ability to update device<br /> |-<br /> | '''Firmware Version Display and/or Last Update Date'''<br /> |<br /> * Device Firmware<br /> |<br /> * Current firmware version is not displayed and/or the last update date is not displayed<br /> |-<br /> |}<br /> <br /> == ==<br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == What is the IoT Vulnerabilities Project? ==<br /> <br /> The IoT Vulnerabilities Project provides:<br /> <br /> * Information on the top IoT vulnerabilities<br /> * The attack surface associated with the vulnerability<br /> * A summary of the vulnerability<br /> <br /> == Project Leaders ==<br /> <br /> * Daniel Miessler<br /> * Craig Smith<br /> <br /> == Related Projects ==<br /> <br /> * [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]<br /> * [[OWASP_Top_Ten_Project|OWASP Web Top 10]]<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Resources ==<br /> * [https://www.owasp.org/index.php/Top_IoT_Vulnerabilities Top 10 IoT Vulnerabilities from 2014]<br /> <br /> == News and Events ==<br /> * Coming Soon<br /> <br /> |}<br /> <br /> = Firmware Analysis =<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == Firmware Analysis Project ==<br /> <br /> The Firmware Analysis Project is intended to provide security testing guidance for the IoT Attack Surface &quot;Device Firmware&quot;:<br /> <br /> {| border=&quot;1&quot; class=&quot;wikitable&quot; style=&quot;text-align: left&quot;<br /> ! Section<br /> ! <br /> |- <br /> |<br /> Device Firmware Vulnerabilties<br /> |<br /> * Out-of-date core components<br /> * Unsupported core components<br /> * Expired and/or self-signed certificates<br /> * Same certificate used on multiple devices<br /> * Admin web interface concerns<br /> * Hardcoded or easy to guess credentials<br /> * Sensitive information disclosure<br /> * Sensitive URL disclosure<br /> * Encryption key exposure<br /> * Backdoor accounts<br /> * Vulnerable services (web, ssh, tftp, etc.)<br /> |-<br /> |<br /> Manufacturer Recommendations<br /> |<br /> * Ensure that supported and up-to-date software is used by developers<br /> * Ensure that robust update mechanisms are in place for devices<br /> * Ensure that certificates are not duplicated across devices and product lines.<br /> * Ensure supported and up-to-date software is used by developers<br /> * Develop a mechanism to ensure a new certificate is installed when old ones expire<br /> * Disable deprecated SSL versions<br /> * Ensure developers do not code in easy to guess or common admin passwords<br /> * Ensure services such as SSH have a secure password created<br /> * Develop a mechanism that requires the user to create a secure admin password during initial device setup<br /> * Ensure developers do not hard code passwords or hashes<br /> * Have source code reviewed by a third party before releasing device to production<br /> * Ensure industry standard encryption or strong hashing is used<br /> |-<br /> |<br /> Device Firmware Guidance and Instruction<br /> |<br /> * Firmware file analysis<br /> * Firmware extraction<br /> * Dynamic binary analysis<br /> * Static binary analysis<br /> * Static code analysis<br /> * Firmware emulation<br /> * File system analysis<br /> |-<br /> |<br /> Device Firmware Tools<br /> |<br /> * [https://github.com/craigz28/firmwalker Firmwalker] <br /> * [https://code.google.com/archive/p/firmware-mod-kit/ Firmware Modification Kit]<br /> * [https://github.com/angr/angr Angr binary analysis framework]<br /> * [http://binwalk.org/ Binwalk firmware analysis tool]<br /> * [http://www.binaryanalysis.org/en/home Binary Analysis Tool]<br /> * [https://github.com/firmadyne/firmadyne Firmadyne]<br /> |-<br /> |<br /> Vulnerable Firmware<br /> |<br /> * [https://github.com/praetorian-inc/DVRF Damn Vulnerable Router Firmware]<br /> |-<br /> |}<br /> <br /> == ==<br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == What is the Firmware Analysis Project? ==<br /> <br /> The Firmware Analysis Project provides:<br /> <br /> * Security testing guidance for vulnerabilities in the &quot;Device Firmware&quot; attack surface<br /> * Steps for extracting file systems from various firmware files<br /> * Guidance on searching a file systems for sensitive of interesting data<br /> * Information on static analysis of firmware contents<br /> * Information on dynamic analysis of emulated services (e.g. web admin interface)<br /> * Testing tool links<br /> * A site for pulling together existing information on firmware analysis<br /> <br /> == Project Leaders ==<br /> <br /> * Craig Smith<br /> <br /> == Related Projects ==<br /> <br /> * [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]<br /> * [[OWASP_Top_Ten_Project|OWASP Web Top 10]]<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Resources ==<br /> * [https://www.owasp.org/index.php/IoT_Firmware_Analysis IoT Firmware Analysis Primer]<br /> * [https://otalliance.org/initiatives/internet-things Online Trust Alliance - Internet of Things]<br /> * [https://people.debian.org/~aurel32/qemu/ Pre-compiled QEMU images]<br /> * [https://code.google.com/archive/p/firmware-mod-kit/ Firmware Modification Kit]<br /> * [https://craigsmith.net/episode-11-1-firmware-extraction/ Short Firmware Extraction Video]<br /> * [https://craigsmith.net/episode-12-1-firmware-emulation-with-qemu/ Firmware Emulation with QEMU]<br /> * [https://craigsmith.net/episode-18-1-file-extraction-from-network-capture/ File Extraction from Network Capture]<br /> <br /> == News and Events ==<br /> * Coming Soon<br /> <br /> |}<br /> <br /> = IoT Event Logging Project=<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File: OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == IoT Logging Events==<br /> <br /> This is a working draft of the recommended minimum IoT Device logging events. This includes many different types of devices, including consumer IoT, enterprise IoT, and ICS/SCADA type devices.<br /> <br /> {| border=&quot;1&quot; class=&quot;wikitable&quot; style=&quot;text-align: left&quot;<br /> ! Event Category<br /> ! Events<br /> |-<br /> | '''Request Exceptions'''<br /> |<br /> * Attempt to Invoke Unsupported HTTP Method<br /> * Unexpected Quantity of Characters in Parameter<br /> * Unexpected Type of Characters in Parameter<br /> |-<br /> | '''Authentication Exceptions'''<br /> |<br /> * Multiple Failed Passwords<br /> * High Rate of Login Attempts<br /> * Additional POST Variable<br /> * Deviation from Normal GEO Location<br /> |-<br /> | '''Session Exceptions'''<br /> |<br /> * Modifying the Existing Cookie<br /> * Substituting Another User's Valid SessionID or Cookie<br /> * Source Location Changes During Session<br /> |-<br /> | '''Access Control Exceptions'''<br /> |<br /> * Modifying URL Argument Within a GET for Direct Object Access Attempt<br /> * Modifying Parameter Within a POST for Direct Object Access Attempt<br /> * Forced Browsing Attempt<br /> |-<br /> | '''Ecosystem Membership Exceptions'''<br /> |<br /> * Traffic Seen from Disenrolled System<br /> * Traffic Seen from Unenrolled System<br /> * Failed Attempt to Enroll in Ecosystem<br /> * Multiple Attempts to Enroll in Ecosystem<br /> |-<br /> | '''Device Access Events'''<br /> |<br /> * Device Case Tampering Detected<br /> * Device Logic Board Tampering Detected<br /> |-<br /> | '''Administrative Mode Events'''<br /> |<br /> * Device Entered Administrative Mode<br /> * Device Accessed Using Default Administrative Credentials<br /> |-<br /> | '''Input Exceptions'''<br /> |<br /> * Double Encoded Character<br /> * Unexpected Encoding Used<br /> |-<br /> | '''Command Injection Exceptions'''<br /> |<br /> * Blacklist Inspection for Common SQL Injection Values<br /> * Abnormal Quantity of Returned Records<br /> |-<br /> | '''Honey Trap Exceptions'''<br /> |<br /> * Honey Trap Resource Requested<br /> * Honey Trap Data Used<br /> |-<br /> | '''Reputation Exceptions'''<br /> |<br /> * Suspicious or Disallowed User Source Location<br /> <br /> |-<br /> |}<br /> <br /> == ==<br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right: 25px;&quot; |<br /> <br /> == What is the IoT Security Logging Project? ==<br /> <br /> The IoT Secure Logging Project provides a list of core events that should be logged in any IoT-related system. The project exists because IoT systems in general are not logging nearly enough events to constitute input for a solid detection and response program around IoT devices, and for companies that want to do this there are not many good resources for what should be logged.<br /> <br /> == Project Leaders ==<br /> <br /> * Daniel Miessler<br /> <br /> == Related Projects ==<br /> <br /> * [https://www.owasp.org/index.php/OWASP_AppSensor_Project The OWASP AppSensor Project]<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Quick Download ==<br /> * Coming Soon<br /> <br /> == News and Events ==<br /> * Coming Soon<br /> <br /> |}<br /> <br /> = ICS/SCADA =<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == ICS/SCADA Project ==<br /> <br /> The OWASP ICS/SCADA Top 10 software weaknesses are as follows:<br /> <br /> {| border=&quot;1&quot; class=&quot;wikitable&quot; style=&quot;text-align: left&quot;<br /> ! Rank and ID<br /> ! Title<br /> |- <br /> | '''1 - CWE-119'''<br /> |<br /> * Improper Restriction of Operations within the Bounds of a Memory Buffer<br /> |- <br /> | '''2 - CWE-20'''<br /> |<br /> * Improper Input Validation<br /> |- <br /> | '''3 - CWE-22'''<br /> |<br /> * Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')<br /> |-<br /> | '''4 - CWE-264'''<br /> |<br /> * Permissions, Privileges, and Access Controls<br /> |- <br /> | '''5 - CWE-200'''<br /> |<br /> * Information Exposure<br /> |- <br /> | '''6 - CWE-255'''<br /> |<br /> * Credentials Management<br /> |- <br /> | '''7 - CWE-287'''<br /> |<br /> * Improper Authentication<br /> |- <br /> | '''8 - CWE-399'''<br /> |<br /> * Resource Management Errors<br /> |- <br /> | '''9 - CWE-79'''<br /> |<br /> * Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')<br /> |- <br /> | '''10 - CWE-189'''<br /> |<br /> * Numeric Errors<br /> |- <br /> |}<br /> <br /> == ==<br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == What is the ICS/SCADA Project? ==<br /> <br /> The ICS/SCADA Project provides:<br /> <br /> * A list of the Top 10 most dangerous software weaknesses<br /> <br /> == Project Leaders ==<br /> <br /> * NJ Ouchn<br /> <br /> == Related Projects ==<br /> <br /> * [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]<br /> * [[OWASP_Top_Ten_Project|OWASP Web Top 10]]<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Quick Download ==<br /> * Coming Soon<br /> <br /> == News and Events ==<br /> * Coming Soon<br /> <br /> |}<br /> <br /> = IoT Security Policy Project =<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == IoT Security Policy Project ==<br /> <br /> The OWASP IoT Security Policy Project provides:<br /> <br /> == ==<br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == What is the IoT Security Policies Project? ==<br /> <br /> The IoT Security Policy Project provides:<br /> <br /> == Project Leaders ==<br /> <br /> * Saša Zdjelar<br /> <br /> == Related Projects ==<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Quick Download ==<br /> * Coming Soon<br /> <br /> == News and Events ==<br /> * Coming Soon<br /> <br /> |}<br /> <br /> <br /> <br /> = Community =<br /> <br /> [https://www.iamthecavalry.org/ I Am The Cavalry] <br /> <br /> A global grassroots organization that is focused on issues where computer security intersects public safety and human life.<br /> <br /> Their areas of focus include:<br /> * Medical devices<br /> * Automobiles<br /> * Home Electronics<br /> * Public Infrastructure<br /> == ==<br /> [http://builditsecure.ly BuildItSecure.ly]<br /> <br /> A project focused on helping small business connect with security researchers to aid in securing their IoT-based products before going market.<br /> <br /> Their goals include:<br /> * Focus effort towards small business<br /> * Build partnerships<br /> * Coordinate efforts<br /> * Curate informational resources<br /> * Present research<br /> == ==<br /> [https://otalliance.org Online Trust Alliance]<br /> <br /> Formed as an informal industry working group in 2005, today OTA is an Internal Revenue Service (IRS) approved 501c3 charitable organization with the mission to enhance online trust and empower users, while promoting innovation and the vitality of the internet. OTA is global organization supported by over 100 organizations headquartered in Bellevue, Washington with offices in Washington DC.<br /> <br /> Addressing the mounting concerns, in January 2015 the Online Trust Alliance, established the [https://otalliance.org/initiatives/internet-things IoT Trustworthy Working Group (ITWG)], a multi-stakeholder initiative. The group recognizes “security and privacy by design” must be a priority from the onset of product development and be addressed holistically. The framework focuses on privacy, security sustainability. The sustainability pillar is critical as it looks at the life-cycle issues related to long- term supportability and transfers of ownership of devices and the data collected.<br /> == ==<br /> [https://allseenalliance.org/framework AllSeen Alliance]<br /> <br /> The AllSeen Alliance is a Linux Foundation collaborative project. They're a cross-industry consortium dedicated to enabling the interoperability of billions of devices, services and apps that comprise the Internet of Things. The Alliance supports the AllJoyn Framework, an open source software framework that makes it easy for devices and apps to discover and communicate with each other. Developers can write applications for interoperability regardless of transport layer, manufacturer, and without the need for Internet access. The software has been and will continue to be openly available for developers to download, and runs on popular platforms such as Linux and Linux-based Android, iOS, and Windows, including many other lightweight real-time operating systems.<br /> == ==<br /> [http://www.iiconsortium.org/ The Industrial Internet Consortium (IIC)]<br /> <br /> The Industrial Internet Consortium is the open membership, international not-for-profit consortium that is setting the architectural framework and direction for the Industrial Internet. Founded by AT&amp;T, Cisco, GE, IBM and Intel in March 2014, the consortium’s mission is to coordinate vast ecosystem initiatives to connect and integrate objects with people, processes and data using common architectures, interoperability and open standards.<br /> == ==<br /> [http://securingsmartcities.org/ Securing Smart Cities]<br /> <br /> Securing Smart Cities is a not-for-profit global initiative that aims to solve the existing and future cybersecurity problems of smart cities through collaboration between companies, governments, media outlets, other not-for-profit initiatives and individuals across the world.<br /> <br /> ===Talks===<br /> <br /> RSA Conference San Francisco &lt;br&gt; <br /> [https://www.owasp.org/images/5/51/RSAC2015-OWASP-IoT-Miessler.pdf Securing the Internet of Things: Mapping IoT Attack Surface Areas with the OWASP IoT Top 10 Project] &lt;br&gt;<br /> Daniel Miessler, Practice Principal &lt;br&gt;<br /> April 21, 2015 &lt;br&gt;<br /> --- &lt;br&gt;<br /> Defcon 23 &lt;br&gt;<br /> [https://www.owasp.org/images/3/36/IoTTestingMethodology.pdf IoT Attack Surface Mapping] &lt;br&gt;<br /> Daniel Miessler &lt;br&gt;<br /> August 6-9, 2015<br /> <br /> ===Podcasts===<br /> <br /> * [http://iotpodcast.com/ The Internet of Things Podcast]<br /> * [http://www.iot-inc.com/ IoT Inc]<br /> * [https://craigsmith.net/category/podcast/ IoT This Week]<br /> * [http://farstuff.com/ Farstuff: The Internet of Things Podcast]<br /> <br /> ===IoT Conferences===<br /> <br /> * [http://www.iotevents.org Internet of Things Events]<br /> <br /> Conference Call for Papers<br /> * [http://www.wikicfp.com/cfp/servlet/tool.search?q=internet+of+things&amp;year=t WikiCFP - Internet of Things]<br /> * [http://www.wikicfp.com/cfp/servlet/tool.search?q=iot&amp;year=t WikiCFP - IoT]<br /> <br /> <br /> <br /> <br /> <br /> <br /> =Project About=<br /> <br /> {{Template:Project About<br /> | project_name =OWASP Internet of Things Project<br /> | project_description = <br /> | project_license =CC-BY 3.0 for documentation and GPLv3 for code. <br /> | leader_name1 = Daniel Miessler<br /> | leader_email1 = <br /> | leader_username1 = <br /> | leader_name2 =Craig Smith<br /> | leader_email2 = <br /> | leader_username2 = <br /> | contributor_name1 = Justin Klein Keane]<br /> | contributor_email1 = <br /> | contributor_username1 = Justin_C._Klein_Keane<br /> | contributor_name2 = Yunsoul<br /> | contributor_email2 = <br /> | contributor_username2 = Yunsoul<br /> | mailing_list_name = <br /> | links_url1 = <br /> | links_name1 =<br /> | links_url1 = <br /> | links_name1 = <br /> }} <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> __NOTOC__ &lt;headertabs /&gt;<br /> <br /> [[Category:OWASP_Project]] [[Category:OWASP_Document]] [[Category:OWASP_Download]] [[Category:OWASP_Release_Quality_Document]]</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=OWASP_Internet_of_Things_Project&diff=225342 2017-01-18T20:57:17Z

<p>Tonimir Kisasondi: </p> <hr /> <div>= Main =<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> ==OWASP Internet of Things (IoT) Project==<br /> <br /> Oxford defines the Internet of Things as: “A proposed development of the Internet in which everyday objects have network connectivity, allowing them to send and receive data.”<br /> <br /> ''The OWASP Internet of Things Project is designed to help manufacturers, developers, and consumers better understand the security issues associated with the Internet of Things, and to enable users in any context to make better security decisions when building, deploying, or assessing IoT technologies''. <br /> <br /> The project looks to define a structure for various IoT sub-projects such as Attack Surface Areas, Testing Guides and Top Vulnerabilities.<br /> <br /> [[File:iot-project.png|400px|thumb|center]]<br /> <br /> ==Licensing==<br /> The OWASP Internet of Things Project is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.<br /> <br /> == ==<br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == What is the OWASP Internet of Things Project? ==<br /> <br /> The OWASP Internet of Things Project provides information on:<br /> <br /> * [https://www.owasp.org/index.php/IoT_Attack_Surface_Areas IoT Attack Surface Areas]<br /> * IoT Vulnerabilities<br /> * Firmware Analysis<br /> * ICS/SCADA Software Weaknesses<br /> * Community Information<br /> * [https://www.owasp.org/index.php/IoT_Testing_Guides IoT Testing Guides]<br /> * [https://www.owasp.org/index.php/IoT_Security_Guidance IoT Security Guidance]<br /> * [https://www.owasp.org/index.php/Principles_of_IoT_Security Principles of IoT Security]<br /> * [https://www.owasp.org/index.php/IoT_Framework_Assessment IoT Framework Assessment]<br /> * Developer, Consumer and Manufacturer Guidance<br /> * Design Principles<br /> <br /> == Project Leaders ==<br /> <br /> * Daniel Miessler<br /> * Craig Smith<br /> <br /> == Contributors ==<br /> * [https://www.owasp.org/index.php/User:Justin_C._Klein_Keane Justin Klein Keane]<br /> * Saša Zdjelar<br /> <br /> == Related Projects ==<br /> <br /> * [[OWASP_Project|OWASP Project Repository]]<br /> * [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]<br /> * [[OWASP_Top_Ten_Project|OWASP Web Top 10]]<br /> * [[OWASP_.NET_Project|OWASP .NET]]<br /> * [[Java|OWASP Java and JVM]]<br /> * [[C/C++|OWASP C/C++]]<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:200px;&quot; |<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Quick Download ==<br /> [https://www.owasp.org/images/3/36/IoTTestingMethodology.pdf IoT Attack Surface Mapping DEFCON 23]<br /> <br /> [https://www.owasp.org/images/2/2d/Iot_testing_methodology.JPG IoT Testing Guidance Handout]<br /> <br /> [https://www.owasp.org/images/7/71/Internet_of_Things_Top_Ten_2014-OWASP.pdf OWASP IoT Top Ten PDF]<br /> <br /> [https://www.owasp.org/images/8/8e/Infographic-v1.jpg OWASP IoT Top Ten Infographic]<br /> <br /> [https://www.owasp.org/images/0/01/Internet_of_Things_Top_Ten_2014-OWASP-ppt.pptx OWASP IoT Top Ten PPT]<br /> <br /> [https://www.owasp.org/images/5/51/RSAC2015-OWASP-IoT-Miessler.pdf OWASP IoT Top Ten-RSA 2015]<br /> <br /> [https://www.owasp.org/images/b/bd/OWASP-IoT.pptx OWASP IoT Project Overview]<br /> <br /> == News and Events ==<br /> * Added a [https://owasp-iot-security.slack.com/ Slack channel]<br /> * Added a sub-project; [https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=IoT_Security_Policy_Project IoT Security Policy Project]<br /> * Daniel Miessler gave his [https://www.youtube.com/watch?v=RhxHHD790nw IoT talk at DEFCON 23]<br /> * Migrating the IoT Top Ten to be under the IoT Project<br /> * HP Study Reveals 70 Percent of Internet of Things Devices Vulnerable to Attack<br /> <br /> ==Classifications==<br /> <br /> {| width=&quot;200&quot; cellpadding=&quot;2&quot;<br /> |-<br /> | align=&quot;center&quot; valign=&quot;top&quot; width=&quot;50%&quot; rowspan=&quot;2&quot;| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]<br /> | align=&quot;center&quot; valign=&quot;top&quot; width=&quot;50%&quot;| [[File:Owasp-builders-small.png|link=]] <br /> |-<br /> | align=&quot;center&quot; valign=&quot;top&quot; width=&quot;50%&quot;| [[File:Owasp-defenders-small.png|link=]]<br /> |-<br /> | colspan=&quot;2&quot; align=&quot;center&quot; | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]<br /> |-<br /> | colspan=&quot;2&quot; align=&quot;center&quot; | [[File:Project_Type_Files_DOC.jpg|link=]]<br /> |}<br /> <br /> |}<br /> <br /> = IoT Attack Surface Areas =<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == IoT Attack Surface Areas Project ==<br /> <br /> The OWASP IoT Attack Surface Areas (DRAFT) are as follows:<br /> <br /> {| border=&quot;1&quot; class=&quot;wikitable&quot; style=&quot;text-align: left&quot;<br /> ! Attack Surface<br /> ! Vulnerability<br /> |- <br /> | '''Ecosystem (general)'''<br /> |<br /> * Interoperability standards<br /> * Data governance<br /> * System wide failure<br /> * Individual stakeholder risks<br /> |- <br /> | '''Ecosystem Access Control'''<br /> |<br /> * Implicit trust between components<br /> * Enrollment security<br /> * Decommissioning system<br /> * Lost access procedures<br /> |- <br /> | '''Device Memory'''<br /> |<br /> * Sensitive data<br /> ** Cleartext usernames<br /> ** Cleartext passwords<br /> ** Third-party credentials<br /> ** Encryption keys<br /> |- <br /> | '''Device Physical Interfaces'''<br /> |<br /> * Firmware extraction<br /> * User CLI<br /> * Admin CLI<br /> * Privilege escalation<br /> * Reset to insecure state<br /> * Removal of storage media<br /> * Tamper resistance<br /> * Debug port<br /> * Device ID/Serial number exposure<br /> |-<br /> | '''Device Web Interface'''<br /> |<br /> * Standard set of web vulnerabilities:<br /> ** SQL injection<br /> ** Cross-site scripting<br /> ** Cross-site Request Forgery<br /> ** Username enumeration<br /> * Credential management vulnerabilities:<br /> ** Username enumeration<br /> ** Weak passwords<br /> ** Account lockout<br /> ** Known default credentials<br /> ** Insecure password recovery mechanism<br /> |- <br /> | '''Device Firmware'''<br /> |<br /> * Sensitive data exposure:<br /> ** Backdoor accounts<br /> ** Hardcoded credentials<br /> ** Encryption keys<br /> ** Encryption (Symmetric, Asymmetric)<br /> ** Sensitive information<br /> ** Sensitive URL disclosure<br /> * Firmware version display and/or last update date<br /> * Vulnerable services (web, ssh, tftp, etc.)<br /> * Security related function API exposure<br /> * Firmware downgrade<br /> |- <br /> | '''Device Network Services'''<br /> |<br /> * Information disclosure<br /> * User CLI<br /> * Administrative CLI<br /> * Injection<br /> * Denial of Service<br /> * Unencrypted Services<br /> * Poorly implemented encryption<br /> * Test/Development Services<br /> * Buffer Overflow<br /> * UPnP<br /> * Vulnerable UDP Services<br /> * DoS<br /> * Device Firmware OTA update block<br /> * Replay attack<br /> * Lack of payload verification<br /> * Lack of message integrity check<br /> * Credential management vulnerabilities:<br /> ** Username enumeration<br /> ** Weak passwords<br /> ** Account lockout<br /> ** Known default credentials<br /> ** Insecure password recovery mechanism<br /> |- <br /> | '''Administrative Interface'''<br /> |<br /> * Standard web vulnerabilities:<br /> ** SQL injection<br /> ** Cross-site scripting<br /> ** Cross-site Request Forgery<br /> ** Username enumeration<br /> * Credential management vulnerabilities:<br /> ** Username enumeration<br /> ** Weak passwords<br /> ** Account lockout<br /> ** Known default credentials<br /> ** Insecure password recovery mechanism<br /> * Security/encryption options<br /> * Logging options<br /> * Two-factor authentication<br /> * Inability to wipe device<br /> |- <br /> | '''Local Data Storage'''<br /> |<br /> * Unencrypted data<br /> * Data encrypted with discovered keys<br /> * Lack of data integrity checks<br /> * Use of static same enc/dec key<br /> |- <br /> | '''Cloud Web Interface'''<br /> |<br /> <br /> * Standard set of web vulnerabilities:<br /> ** SQL injection<br /> ** Cross-site scripting<br /> ** Cross-site Request Forgery<br /> * Credential management vulnerabilities:<br /> ** Username enumeration<br /> ** Weak passwords<br /> ** Account lockout<br /> ** Known default credentials<br /> ** Insecure password recovery mechanism<br /> * Transport encryption<br /> * Two-factor authentication<br /> |- <br /> | '''Third-party Backend APIs'''<br /> |<br /> * Unencrypted PII sent<br /> * Encrypted PII sent<br /> * Device information leaked<br /> * Location leaked<br /> |- <br /> | '''Update Mechanism'''<br /> |<br /> * Update sent without encryption<br /> * Updates not signed<br /> * Update location writable<br /> * Update verification<br /> * Update authentication<br /> * Malicious update<br /> * Missing update mechanism<br /> * No manual update mechanism<br /> |- <br /> | '''Mobile Application'''<br /> |<br /> * Implicitly trusted by device or cloud<br /> * Username enumeration<br /> * Account lockout<br /> * Known default credentials<br /> * Weak passwords<br /> * Insecure data storage<br /> * Transport encryption<br /> * Insecure password recovery mechanism<br /> * Two-factor authentication<br /> |- <br /> | '''Vendor Backend APIs'''<br /> |<br /> * Inherent trust of cloud or mobile application<br /> * Weak authentication<br /> * Weak access controls<br /> * Injection attacks<br /> * Hidden services<br /> |- <br /> | '''Ecosystem Communication'''<br /> |<br /> * Health checks<br /> * Heartbeats<br /> * Ecosystem commands<br /> * Deprovisioning<br /> * Pushing updates<br /> |- <br /> | '''Network Traffic'''<br /> |<br /> * LAN<br /> * LAN to Internet<br /> * Short range<br /> * Non-standard<br /> * Wireless (WiFi, Z-wave, XBee, Zigbee, Bluetooth, LoRA)<br /> * Protocol fuzzing<br /> |- <br /> | '''Authentication/Authorization'''<br /> |<br /> * Authentication/Authorization related values (session key, token, cookie, etc.) disclosure<br /> * Reusing of session key, token, etc.<br /> * Device to device authentication<br /> * Device to mobile Application authentication<br /> * Device to cloud system authentication<br /> * Mobile application to cloud system authentication<br /> * Web application to cloud system authentication<br /> * Lack of dynamic authentication<br /> |-<br /> | '''Privacy'''<br /> |<br /> * User data disclosure<br /> * User/device location disclosure<br /> * Differential privacy<br /> |-<br /> | '''Hardware (Sensors)'''<br /> |<br /> * Sensing Environment Manipulation<br /> * Tampering (Physically)<br /> * Damaging (Physically)<br /> <br /> |-<br /> |}<br /> <br /> == ==<br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == What is the IoT Attack Surface Areas Project? ==<br /> <br /> The IoT Attack Surface Areas Project provides a list of attack surfaces that should be understood by manufacturers, developers, security researchers, and those looking to deploy or implement IoT technologies within their organizations.<br /> <br /> == Project Leaders ==<br /> <br /> * Daniel Miessler<br /> * Craig Smith<br /> <br /> == Related Projects ==<br /> <br /> * [https://www.owasp.org/index.php/OWASP_Mobile_Security_Project The OWASP Mobile Top 10 Project]<br /> * [https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project The OWASP Web Top 10 Project]<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Quick Download ==<br /> * Coming Soon<br /> <br /> == News and Events ==<br /> * Coming Soon<br /> <br /> |}<br /> <br /> = IoT Vulnerabilities =<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == IoT Vulnerabilities Project ==<br /> <br /> {| border=&quot;1&quot; class=&quot;wikitable&quot; style=&quot;text-align: left&quot;<br /> ! Vulnerability<br /> ! Attack Surface<br /> ! Summary<br /> |-<br /> | '''Username Enumeration'''<br /> |<br /> * Administrative Interface<br /> * Device Web Interface<br /> * Cloud Interface<br /> * Mobile Application<br /> |<br /> * Ability to collect a set of valid usernames by interacting with the authentication mechanism<br /> |-<br /> | '''Weak Passwords'''<br /> |<br /> * Administrative Interface<br /> * Device Web Interface<br /> * Cloud Interface<br /> * Mobile Application<br /> |<br /> * Ability to set account passwords to '1234' or '123456' for example.<br /> |-<br /> | '''Account Lockout'''<br /> |<br /> * Administrative Interface<br /> * Device Web Interface<br /> * Cloud Interface<br /> * Mobile Application<br /> |<br /> * Ability to continue sending authentication attempts after 3 - 5 failed login attempts<br /> |-<br /> | '''Unencrypted Services'''<br /> |<br /> * Device Network Services<br /> |<br /> * Network services are not properly encrypted to prevent eavesdropping by attackers<br /> |-<br /> | '''Two-factor Authentication'''<br /> |<br /> * Administrative Interface<br /> * Cloud Web Interface<br /> * Mobile Application<br /> |<br /> * Lack of two-factor authentication mechanisms such as a security token or fingerprint scanner<br /> |-<br /> | '''Poorly Implemented Encryption'''<br /> |<br /> * Device Network Services<br /> |<br /> * Encryption is implemented however it is improperly configured or is not being properly updated, e.g. using SSL v2 <br /> |-<br /> | '''Update Sent Without Encryption'''<br /> |<br /> * Update Mechanism<br /> |<br /> * Updates are transmitted over the network without using TLS or encrypting the update file itself<br /> |-<br /> | '''Update Location Writable'''<br /> |<br /> * Update Mechanism<br /> |<br /> * Storage location for update files is world writable potentially allowing firmware to be modified and distributed to all users<br /> |-<br /> | '''Denial of Service'''<br /> |<br /> * Device Network Services<br /> |<br /> * Service can be attacked in a way that denies service to that service or the entire device<br /> |-<br /> | '''Removal of Storage Media'''<br /> |<br /> * Device Physical Interfaces<br /> |<br /> * Ability to physically remove the storage media from the device<br /> |-<br /> | '''No Manual Update Mechanism'''<br /> |<br /> * Update Mechanism<br /> |<br /> * No ability to manually force an update check for the device<br /> |-<br /> | '''Missing Update Mechanism'''<br /> |<br /> * Update Mechanism<br /> |<br /> * No ability to update device<br /> |-<br /> | '''Firmware Version Display and/or Last Update Date'''<br /> |<br /> * Device Firmware<br /> |<br /> * Current firmware version is not displayed and/or the last update date is not displayed<br /> |-<br /> |}<br /> <br /> == ==<br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == What is the IoT Vulnerabilities Project? ==<br /> <br /> The IoT Vulnerabilities Project provides:<br /> <br /> * Information on the top IoT vulnerabilities<br /> * The attack surface associated with the vulnerability<br /> * A summary of the vulnerability<br /> <br /> == Project Leaders ==<br /> <br /> * Daniel Miessler<br /> * Craig Smith<br /> <br /> == Related Projects ==<br /> <br /> * [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]<br /> * [[OWASP_Top_Ten_Project|OWASP Web Top 10]]<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Resources ==<br /> * [https://www.owasp.org/index.php/Top_IoT_Vulnerabilities Top 10 IoT Vulnerabilities from 2014]<br /> <br /> == News and Events ==<br /> * Coming Soon<br /> <br /> |}<br /> <br /> = Firmware Analysis =<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == Firmware Analysis Project ==<br /> <br /> The Firmware Analysis Project is intended to provide security testing guidance for the IoT Attack Surface &quot;Device Firmware&quot;:<br /> <br /> {| border=&quot;1&quot; class=&quot;wikitable&quot; style=&quot;text-align: left&quot;<br /> ! Section<br /> ! <br /> |- <br /> |<br /> Device Firmware Vulnerabilties<br /> |<br /> * Out-of-date core components<br /> * Unsupported core components<br /> * Expired and/or self-signed certificates<br /> * Same certificate used on multiple devices<br /> * Admin web interface concerns<br /> * Hardcoded or easy to guess credentials<br /> * Sensitive information disclosure<br /> * Sensitive URL disclosure<br /> * Encryption key exposure<br /> * Backdoor accounts<br /> * Vulnerable services (web, ssh, tftp, etc.)<br /> |-<br /> |<br /> Manufacturer Recommendations<br /> |<br /> * Ensure that supported and up-to-date software is used by developers<br /> * Ensure that robust update mechanisms are in place for devices<br /> * Ensure that certificates are not duplicated across devices and product lines.<br /> * Ensure supported and up-to-date software is used by developers<br /> * Develop a mechanism to ensure a new certificate is installed when old ones expire<br /> * Disable deprecated SSL versions<br /> * Ensure developers do not code in easy to guess or common admin passwords<br /> * Ensure services such as SSH have a secure password created<br /> * Develop a mechanism that requires the user to create a secure admin password during initial device setup<br /> * Ensure developers do not hard code passwords or hashes<br /> * Have source code reviewed by a third party before releasing device to production<br /> * Ensure industry standard encryption or strong hashing is used<br /> |-<br /> |<br /> Device Firmware Guidance and Instruction<br /> |<br /> * Firmware file analysis<br /> * Firmware extraction<br /> * Dynamic binary analysis<br /> * Static binary analysis<br /> * Static code analysis<br /> * Firmware emulation<br /> * File system analysis<br /> |-<br /> |<br /> Device Firmware Tools<br /> |<br /> * [https://github.com/craigz28/firmwalker Firmwalker] <br /> * [https://code.google.com/archive/p/firmware-mod-kit/ Firmware Modification Kit]<br /> * [https://github.com/angr/angr Angr binary analysis framework]<br /> * [http://binwalk.org/ Binwalk firmware analysis tool]<br /> * [http://www.binaryanalysis.org/en/home Binary Analysis Tool]<br /> * [https://github.com/firmadyne/firmadyne Firmadyne]<br /> |-<br /> |<br /> Vulnerable Firmware<br /> |<br /> * [https://github.com/praetorian-inc/DVRF Damn Vulnerable Router Firmware]<br /> |-<br /> |}<br /> <br /> == ==<br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == What is the Firmware Analysis Project? ==<br /> <br /> The Firmware Analysis Project provides:<br /> <br /> * Security testing guidance for vulnerabilities in the &quot;Device Firmware&quot; attack surface<br /> * Steps for extracting file systems from various firmware files<br /> * Guidance on searching a file systems for sensitive of interesting data<br /> * Information on static analysis of firmware contents<br /> * Information on dynamic analysis of emulated services (e.g. web admin interface)<br /> * Testing tool links<br /> * A site for pulling together existing information on firmware analysis<br /> <br /> == Project Leaders ==<br /> <br /> * Craig Smith<br /> <br /> == Related Projects ==<br /> <br /> * [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]<br /> * [[OWASP_Top_Ten_Project|OWASP Web Top 10]]<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Resources ==<br /> * [https://www.owasp.org/index.php/IoT_Firmware_Analysis IoT Firmware Analysis Primer]<br /> * [https://otalliance.org/initiatives/internet-things Online Trust Alliance - Internet of Things]<br /> * [https://people.debian.org/~aurel32/qemu/ Pre-compiled QEMU images]<br /> * [https://code.google.com/archive/p/firmware-mod-kit/ Firmware Modification Kit]<br /> * [https://craigsmith.net/episode-11-1-firmware-extraction/ Short Firmware Extraction Video]<br /> * [https://craigsmith.net/episode-12-1-firmware-emulation-with-qemu/ Firmware Emulation with QEMU]<br /> * [https://craigsmith.net/episode-18-1-file-extraction-from-network-capture/ File Extraction from Network Capture]<br /> <br /> == News and Events ==<br /> * Coming Soon<br /> <br /> |}<br /> <br /> = IoT Event Logging Project=<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File: OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == IoT Logging Events==<br /> <br /> This is a working draft of the recommended minimum IoT Device logging events. This includes many different types of devices, including consumer IoT, enterprise IoT, and ICS/SCADA type devices.<br /> <br /> {| border=&quot;1&quot; class=&quot;wikitable&quot; style=&quot;text-align: left&quot;<br /> ! Event Category<br /> ! Events<br /> |-<br /> | '''Request Exceptions'''<br /> |<br /> * Attempt to Invoke Unsupported HTTP Method<br /> * Unexpected Quantity of Characters in Parameter<br /> * Unexpected Type of Characters in Parameter<br /> |-<br /> | '''Authentication Exceptions'''<br /> |<br /> * Multiple Failed Passwords<br /> * High Rate of Login Attempts<br /> * Additional POST Variable<br /> * Deviation from Normal GEO Location<br /> |-<br /> | '''Session Exceptions'''<br /> |<br /> * Modifying the Existing Cookie<br /> * Substituting Another User's Valid SessionID or Cookie<br /> * Source Location Changes During Session<br /> |-<br /> | '''Access Control Exceptions'''<br /> |<br /> * Modifying URL Argument Within a GET for Direct Object Access Attempt<br /> * Modifying Parameter Within a POST for Direct Object Access Attempt<br /> * Forced Browsing Attempt<br /> |-<br /> | '''Ecosystem Membership Exceptions'''<br /> |<br /> * Traffic Seen from Disenrolled System<br /> * Traffic Seen from Unenrolled System<br /> * Failed Attempt to Enroll in Ecosystem<br /> * Multiple Attempts to Enroll in Ecosystem<br /> |-<br /> | '''Device Access Events'''<br /> |<br /> * Device Case Tampering Detected<br /> * Device Logic Board Tampering Detected<br /> |-<br /> | '''Administrative Mode Events'''<br /> |<br /> * Device Entered Administrative Mode<br /> * Device Accessed Using Default Administrative Credentials<br /> |-<br /> | '''Input Exceptions'''<br /> |<br /> * Double Encoded Character<br /> * Unexpected Encoding Used<br /> |-<br /> | '''Command Injection Exceptions'''<br /> |<br /> * Blacklist Inspection for Common SQL Injection Values<br /> * Abnormal Quantity of Returned Records<br /> |-<br /> | '''Honey Trap Exceptions'''<br /> |<br /> * Honey Trap Resource Requested<br /> * Honey Trap Data Used<br /> |-<br /> | '''Reputation Exceptions'''<br /> |<br /> * Suspicious or Disallowed User Source Location<br /> <br /> |-<br /> |}<br /> <br /> == ==<br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right: 25px;&quot; |<br /> <br /> == What is the IoT Security Logging Project? ==<br /> <br /> The IoT Secure Logging Project provides a list of core events that should be logged in any IoT-related system. The project exists because IoT systems in general are not logging nearly enough events to constitute input for a solid detection and response program around IoT devices, and for companies that want to do this there are not many good resources for what should be logged.<br /> <br /> == Project Leaders ==<br /> <br /> * Daniel Miessler<br /> <br /> == Related Projects ==<br /> <br /> * [https://www.owasp.org/index.php/OWASP_AppSensor_Project The OWASP AppSensor Project]<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Quick Download ==<br /> * Coming Soon<br /> <br /> == News and Events ==<br /> * Coming Soon<br /> <br /> |}<br /> <br /> = ICS/SCADA =<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == ICS/SCADA Project ==<br /> <br /> The OWASP ICS/SCADA Top 10 software weaknesses are as follows:<br /> <br /> {| border=&quot;1&quot; class=&quot;wikitable&quot; style=&quot;text-align: left&quot;<br /> ! Rank and ID<br /> ! Title<br /> |- <br /> | '''1 - CWE-119'''<br /> |<br /> * Improper Restriction of Operations within the Bounds of a Memory Buffer<br /> |- <br /> | '''2 - CWE-20'''<br /> |<br /> * Improper Input Validation<br /> |- <br /> | '''3 - CWE-22'''<br /> |<br /> * Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')<br /> |-<br /> | '''4 - CWE-264'''<br /> |<br /> * Permissions, Privileges, and Access Controls<br /> |- <br /> | '''5 - CWE-200'''<br /> |<br /> * Information Exposure<br /> |- <br /> | '''6 - CWE-255'''<br /> |<br /> * Credentials Management<br /> |- <br /> | '''7 - CWE-287'''<br /> |<br /> * Improper Authentication<br /> |- <br /> | '''8 - CWE-399'''<br /> |<br /> * Resource Management Errors<br /> |- <br /> | '''9 - CWE-79'''<br /> |<br /> * Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')<br /> |- <br /> | '''10 - CWE-189'''<br /> |<br /> * Numeric Errors<br /> |- <br /> |}<br /> <br /> == ==<br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == What is the ICS/SCADA Project? ==<br /> <br /> The ICS/SCADA Project provides:<br /> <br /> * A list of the Top 10 most dangerous software weaknesses<br /> <br /> == Project Leaders ==<br /> <br /> * NJ Ouchn<br /> <br /> == Related Projects ==<br /> <br /> * [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]<br /> * [[OWASP_Top_Ten_Project|OWASP Web Top 10]]<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Quick Download ==<br /> * Coming Soon<br /> <br /> == News and Events ==<br /> * Coming Soon<br /> <br /> |}<br /> <br /> = IoT Security Policy Project =<br /> <br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:OWASP_Project_Header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == IoT Security Policy Project ==<br /> <br /> The OWASP IoT Security Policy Project provides:<br /> <br /> == ==<br /> {{Social Media Links}}<br /> <br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == What is the IoT Security Policies Project? ==<br /> <br /> The IoT Security Policy Project provides:<br /> <br /> == Project Leaders ==<br /> <br /> * Saša Zdjelar<br /> <br /> == Related Projects ==<br /> <br /> == Collaboration ==<br /> [https://owasp-iot-security.slack.com The Slack Channel]<br /> <br /> == Quick Download ==<br /> * Coming Soon<br /> <br /> == News and Events ==<br /> * Coming Soon<br /> <br /> |}<br /> <br /> <br /> <br /> = Community =<br /> <br /> [https://www.iamthecavalry.org/ I Am The Cavalry] <br /> <br /> A global grassroots organization that is focused on issues where computer security intersects public safety and human life.<br /> <br /> Their areas of focus include:<br /> * Medical devices<br /> * Automobiles<br /> * Home Electronics<br /> * Public Infrastructure<br /> == ==<br /> [http://builditsecure.ly BuildItSecure.ly]<br /> <br /> A project focused on helping small business connect with security researchers to aid in securing their IoT-based products before going market.<br /> <br /> Their goals include:<br /> * Focus effort towards small business<br /> * Build partnerships<br /> * Coordinate efforts<br /> * Curate informational resources<br /> * Present research<br /> == ==<br /> [https://otalliance.org Online Trust Alliance]<br /> <br /> Formed as an informal industry working group in 2005, today OTA is an Internal Revenue Service (IRS) approved 501c3 charitable organization with the mission to enhance online trust and empower users, while promoting innovation and the vitality of the internet. OTA is global organization supported by over 100 organizations headquartered in Bellevue, Washington with offices in Washington DC.<br /> <br /> Addressing the mounting concerns, in January 2015 the Online Trust Alliance, established the [https://otalliance.org/initiatives/internet-things IoT Trustworthy Working Group (ITWG)], a multi-stakeholder initiative. The group recognizes “security and privacy by design” must be a priority from the onset of product development and be addressed holistically. The framework focuses on privacy, security sustainability. The sustainability pillar is critical as it looks at the life-cycle issues related to long- term supportability and transfers of ownership of devices and the data collected.<br /> == ==<br /> [https://allseenalliance.org/framework AllSeen Alliance]<br /> <br /> The AllSeen Alliance is a Linux Foundation collaborative project. They're a cross-industry consortium dedicated to enabling the interoperability of billions of devices, services and apps that comprise the Internet of Things. The Alliance supports the AllJoyn Framework, an open source software framework that makes it easy for devices and apps to discover and communicate with each other. Developers can write applications for interoperability regardless of transport layer, manufacturer, and without the need for Internet access. The software has been and will continue to be openly available for developers to download, and runs on popular platforms such as Linux and Linux-based Android, iOS, and Windows, including many other lightweight real-time operating systems.<br /> == ==<br /> [http://www.iiconsortium.org/ The Industrial Internet Consortium (IIC)]<br /> <br /> The Industrial Internet Consortium is the open membership, international not-for-profit consortium that is setting the architectural framework and direction for the Industrial Internet. Founded by AT&amp;T, Cisco, GE, IBM and Intel in March 2014, the consortium’s mission is to coordinate vast ecosystem initiatives to connect and integrate objects with people, processes and data using common architectures, interoperability and open standards.<br /> == ==<br /> [http://securingsmartcities.org/ Securing Smart Cities]<br /> <br /> Securing Smart Cities is a not-for-profit global initiative that aims to solve the existing and future cybersecurity problems of smart cities through collaboration between companies, governments, media outlets, other not-for-profit initiatives and individuals across the world.<br /> <br /> ===Talks===<br /> <br /> RSA Conference San Francisco &lt;br&gt; <br /> [https://www.owasp.org/images/5/51/RSAC2015-OWASP-IoT-Miessler.pdf Securing the Internet of Things: Mapping IoT Attack Surface Areas with the OWASP IoT Top 10 Project] &lt;br&gt;<br /> Daniel Miessler, Practice Principal &lt;br&gt;<br /> April 21, 2015 &lt;br&gt;<br /> --- &lt;br&gt;<br /> Defcon 23 &lt;br&gt;<br /> [https://www.owasp.org/images/3/36/IoTTestingMethodology.pdf IoT Attack Surface Mapping] &lt;br&gt;<br /> Daniel Miessler &lt;br&gt;<br /> August 6-9, 2015<br /> <br /> ===Podcasts===<br /> <br /> * [http://iotpodcast.com/ The Internet of Things Podcast]<br /> * [http://www.iot-inc.com/ IoT Inc]<br /> * [https://craigsmith.net/category/podcast/ IoT This Week]<br /> * [http://farstuff.com/ Farstuff: The Internet of Things Podcast]<br /> <br /> ===IoT Conferences===<br /> <br /> * [http://www.iotevents.org Internet of Things Events]<br /> <br /> Conference Call for Papers<br /> * [http://www.wikicfp.com/cfp/servlet/tool.search?q=internet+of+things&amp;year=t WikiCFP - Internet of Things]<br /> * [http://www.wikicfp.com/cfp/servlet/tool.search?q=iot&amp;year=t WikiCFP - IoT]<br /> <br /> <br /> <br /> <br /> <br /> <br /> =Project About=<br /> <br /> {{Template:Project About<br /> | project_name =OWASP Internet of Things Project<br /> | project_description = <br /> | project_license =CC-BY 3.0 for documentation and GPLv3 for code. <br /> | leader_name1 = Daniel Miessler<br /> | leader_email1 = <br /> | leader_username1 = <br /> | leader_name2 =Craig Smith<br /> | leader_email2 = <br /> | leader_username2 = <br /> | contributor_name1 = Justin Klein Keane]<br /> | contributor_email1 = <br /> | contributor_username1 = Justin_C._Klein_Keane<br /> | contributor_name2 = Yunsoul<br /> | contributor_email2 = <br /> | contributor_username2 = Yunsoul<br /> | mailing_list_name = <br /> | links_url1 = <br /> | links_name1 =<br /> | links_url1 = <br /> | links_name1 = <br /> }} <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> __NOTOC__ &lt;headertabs /&gt;<br /> <br /> [[Category:OWASP_Project]] [[Category:OWASP_Document]] [[Category:OWASP_Download]] [[Category:OWASP_Release_Quality_Document]]</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=Croatia&diff=208960 2016-02-15T17:14:28Z

<p>Tonimir Kisasondi: </p> <hr /> <div>{{Chapter Template|chaptername=Croatia|extra=The chapter leaders are [mailto:vlatko.kosturjak@owasp.org Vlatko Kosturjak] and [mailto:tonimir.kisasondi@owasp.org Tonimir Kisasondi]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Croatia|emailarchives=http://lists.owasp.org/pipermail/owasp-croatia/}}<br /> ==== Local News ====<br /> &lt;paypal&gt;Croatia&lt;/paypal&gt;<br /> <br /> Welcome. We're just starting organizing things here. You're invited to subscribe to the mailing list for up2date news and also if you want help in <br /> organizing local chapter. Everyone is welcome to join us at our chapter meetings. <br /> <br /> ==== Chapter Meetings ====<br /> '''Regular Meeting Location''': FOI, Pavlinska 2, 42000 Varaždin, Hrvatska<br /> <br /> '''Previous event''': [http://www.foi.unizg.hr/Ljetna-skola-aplikacijske-sigurnost-na-FOI-ju OWASP application security summer school ] from 23th to 26th of September, 2014 @ FOI ([https://www.flickr.com/photos/58943051@N07/sets/72157648047647530/ Photos])<br /> <br /> '''Previous meeting''': OWASP round table/meetup on 14.9.2015 @ [http://fsec.foi.hr/ FOI/FSEC]<br /> <br /> '''Next meeting''': OWASP regular/meeting on 26.2.2016 at 18:00 (FOI Infoclub, Basement) | [https://www.facebook.com/events/1840212762872033/ Link to FB Event] [http://www.foi.unizg.hr/hr/novosti/razmjena-vjestina-owasp-croatia-meetup Link to Web]<br /> <br /> ==== Croatia OWASP Chapter Leaders ====<br /> The chapter leaders are [mailto:vlatko.kosturjak@owasp.org Vlatko Kosturjak] and [mailto:tonimir.kisasondi@owasp.org Tonimir Kisasondi]<br /> __NOTOC__<br /> &lt;headertabs/&gt;<br /> [[Category:OWASP Chapter]]<br /> [[Category:Europe]]</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=Croatia&diff=207729 2016-01-30T16:29:03Z

<p>Tonimir Kisasondi: </p> <hr /> <div>{{Chapter Template|chaptername=Croatia|extra=The chapter leaders are [mailto:vlatko.kosturjak@owasp.org Vlatko Kosturjak] and [mailto:tonimir.kisasondi@owasp.org Tonimir Kisasondi]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Croatia|emailarchives=http://lists.owasp.org/pipermail/owasp-croatia/}}<br /> ==== Local News ====<br /> &lt;paypal&gt;Croatia&lt;/paypal&gt;<br /> <br /> Welcome. We're just starting organizing things here. You're invited to subscribe to the mailing list for up2date news and also if you want help in <br /> organizing local chapter. Everyone is welcome to join us at our chapter meetings. <br /> <br /> ==== Chapter Meetings ====<br /> '''Regular Meeting Location''': FOI, Pavlinska 2, 42000 Varaždin, Hrvatska<br /> <br /> '''Previous event''': [http://www.foi.unizg.hr/Ljetna-skola-aplikacijske-sigurnost-na-FOI-ju OWASP application security summer school ] from 23th to 26th of September, 2014 @ FOI ([https://www.flickr.com/photos/58943051@N07/sets/72157648047647530/ Photos])<br /> <br /> '''Previous meeting''': OWASP round table/meetup on 14.9.2015 @ [http://fsec.foi.hr/ FOI/FSEC]<br /> <br /> '''Next meeting''': OWASP regular/meeting on 26.2.2016 at 18:00 (FOI Infoclub, Basement) | [https://www.facebook.com/events/1840212762872033/ Link to FB Event]<br /> <br /> ==== Croatia OWASP Chapter Leaders ====<br /> The chapter leaders are [mailto:vlatko.kosturjak@owasp.org Vlatko Kosturjak] and [mailto:tonimir.kisasondi@owasp.org Tonimir Kisasondi]<br /> __NOTOC__<br /> &lt;headertabs/&gt;<br /> [[Category:OWASP Chapter]]<br /> [[Category:Europe]]</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=OWASP_Secure_Software_Contract_Annex/hr&diff=184556 2014-11-02T16:53:16Z

<p>Tonimir Kisasondi: </p> <hr /> <div>Prijevod: [https://www.owasp.org/index.php/User:Tonimir_Kisasondi Tonimir Kišasondi], Laboratorij za otvorene sustave i sigurnost, Fakultet organizacije i informatike, Varaždin<br /> <br /> ===Temeljne pretpostavke:===<br /> <br /> 1. Odluke o potrebnoj razini sigurnosti temelje se na razumijevanju rizika koji su vezani uz sustav koji se razvija.<br /> <br /> 2. Pristup osiguravanju sigurnosti mora se temeljiti na pristupu analize i implementacije potrebne razine sigurnosti kroz cijeli životni ciklus proizvoda ili sustava.<br /> <br /> 3. Kontrole tj. mjere zaštite nisu poseban, dodatni dio sustava već integrirani dio u svim elementima sustava. Kontrole ne smiju biti poseban ili dodatan dio razvoja sustava.<br /> <br /> 4. Dokumentacija sustava mora sadržavati opise svih primijenjenih kontrola u sustavu.<br /> <br /> 5. Dokumentacija mora biti jasna, korisna i transparentna te mora opisivati dizajn integriranog, cjelovitog sustava sigurnosti, procjenu rizika koja je provedena u sklopu razvoja i moguće probleme. <br /> <br /> 6. Ranjivosti u sustavu nisu neočekivane ali u procesu razvoja i u ranim fazama životnog ciklusa sustava treba pokušati identificirati sigurnosne manjkavosti. <br /> <br /> 7. Informacije o sigurnosti, rizicima i ranjivostima potrebno je otvoreno razmjenjivati između strane koja razvija sustav i koja je korisnik sustava, čim se navedene informacije otkrije jedna strana, mora obavijestiti drugu stranu u cijelosti i bez ustručavanja.<br /> <br /> ===Aktivnosti životnog ciklusa:===<br /> <br /> 1. Rizici moraju biti identificirani u odnosu na imovinu ili elemente sustava, dokumentirani i obje strane moraju razumjeti rizike koji su u kontekstu sustava.<br /> <br /> 2. Razvoj detaljnih sigurnosnih zahtjeva za sustav mora se temeljiti na identificiranim rizicima, gdje su sigurnosni zahtjevi dio specifikacije sustava koji se razvija. Sigurnosne zahtjeve moguće je realizirati dodatnim prilagođenim razvojem ili dodatnim sigurnosnim elementima u sustavu. <br /> <br /> 3. Svaki sigurnosni zahtjev mora biti razmotren i odluka mora biti donesena o načinu obrade rizika. Izvođač i naručitelj sustava moraju biti suglasni oko svih opisanih sigurnosnih zahtjeva i kontrola. Odluke moraju dokumentirane, te dokumentacija mora sadržavati informaciju zašto je konkretna kontrola prikladna i na koji način odgovara u cjelokupnom sustavu uz sva njegova ograničenja. Bitno je navesti da li se kontrola temelji na ugrađenom elementu koji je dio sustava ili je kontrola element koji razvija treća strana. Svaki sigurnosni zahtjev mora biti formiran na način da je moguće provjeriti da li je ispunjen. <br /> <br /> 4. Razvoj sustava mora se temeljiti na elementima koji su sigurni i odgovaraju zahtjevima sigurnosti.<br /> <br /> 5. Svi elementi sustava moraju proći provjeru od druge strane koja nije razvijala konkretni element sustava. Cijeli sustav mora odgovarati dogovorenoj normi verifikacije mjera sigurnosti kao što je OWASP ASVS ili nekoj drugoj. Rezultati verifikacije moraju biti dokumentirani prema zahtjevima norme za verifikaciju.<br /> <br /> 6. Sustav mora sadržavati opis postavki i njihove implikacije za sigurnost sustava. Opis mora sadržavati i opis zavisnosti kao što je potrebna inačica operacijskog sustava, web poslužitelja, sustava za upravljanje bazom podataka i način na koji isti moraju biti podešeni da odgovaraju zahtjevima sigurnosti cijelog sustava. Početna konfiguracija sustava u trenutku isporuke mora biti sigurna. <br /> <br /> ===Zahtjevi sigurnosti:===<br /> <br /> Prilikom procjene rizika i definiranja sigurnosnih zahtjeva potrebno je uzeti u obzir sljedeće zahtjeve sigurnosti koji moraju uključivati:<br /> <br /> 1. Pravila za provjeru unosa i kodiranje svakog ulaza u aplikaciju, bez obzira da li je unos od korisnika, baze podataka ili vanjskih sustava. Početna pretpostavka je da su svi unosi nevaljani osim ako ne odgovaraju specifikaciji točnog unosa. Zahtjevi moraju sadržavati postupak što uraditi sa unosom koji nije valjan. Sustavi ne bi smjeli biti podložni napadima umetanja znakova, prelijevanja spremnika, neovlaštenom promjenom i ostale napade koji mijenjaju stanje sustava.<br /> <br /> 2. Mjere kako će se štiti sesija korisnika te podatci kojima se identificira sesija i prijavljeni korisnik. Zahtjevi moraju uključivati mjere za sve povezane funkcije kao što su: vraćanje zaboravljene lozinke, promjene lozinke, odjave, višestruke prijave i druge. <br /> <br /> 3. Detaljan opis načina realizacije kontrole pristupa te uloge, grupe, privilegije i autorizacije koje se koriste u aplikaciji vezane uz imovinu i funkcije koje su unutar sustava, gdje se povezuju specifična prava pristupa za svaku imovinu ili funkciju po svakoj ulozi. Predlaže se uporaba matrice kontrole pristupa za opis uloga i razine prava pristupa. <br /> <br /> 4. Način ponašanja sustava prilikom greške u radu. U nekim slučajevima najbolje je pružiti korisniku najbolji pokušaj u slučaju greške a nekada je najbolje prekinuti izvršavanje odmah. Navedene situacije i način baratanja greškama mora biti definiran prije izgradnje sustava. <br /> <br /> 5. Način bilježenja događaja u sustavu kao što su uspješne i neuspješne prijave, uočeni napadi ili pokušaji zaobilaženja autorizacije. Zahtjevi moraju sadržavati i podatke koji se moraju bilježiti kao što je vrijeme, datum, detalji aplikacije i sve ostale podatke koji omogućavaju forenzičku analizu. <br /> <br /> 6. Oblik autentikacije i zaštite komunikacije kao što je kriptiranje komunikacije i veze sa drugim elementima sustava kao što su baze podataka ili drugi web servisi. Vjerodajnice za uspostavu komunikacije moraju biti također zaštićene na primjeren način. <br /> <br /> 7. Odluku koje podatke treba kriptirati, na koji način kriptirati te kako će se postupati sa certifikatima i vjerodajnicama. Sustav mora koristiti standardne preporučene algoritme i biblioteke koje su sigurnosno provjerene. <br /> <br /> 8. Način zaštite sustava od napada uskraćenjem usluge (DoS ili DDoS), u obzir treba uzeti razne vrste napada kao što je zaključavanje autentikacije nakon većeg broja neuspješnih pokušaja, iscrpljivanja broja konekcija i ostale napade iscrpljivanjem resursa.<br /> <br /> 9. Početne vrijednosti konfiguracije moraju biti fokusirane prema sigurnim postavkama. Sustav mora omogućiti lagani pregled svih relevantnih opcija i postavljene vrijednosti za provjeru sigurnosti.<br /> <br /> 10. Popis ranjivosti koje su uklonjene tijekom razvoja i kontrole koje su postavljene.<br /> <br /> ===Osoblje i organizacija:===<br /> <br /> 1. Uz razvoj, dodatna verifikacija sigurnosti trebala bi se provoditi kroz arhitekte sigurnosti koji razumiju problematiku razvoja sigurnih elemenata sustava.<br /> <br /> 2. Članovi tima za razvoj moraju biti obučeni i educirani u najboljoj praksi izgradnje sigurnih sustava vezanih uz njihove uloge.<br /> <br /> 3. U slučaju razvoja povjerljivih sustava treba razmotriti primjerenost provjere sigurnosti i prijašnje iskustvo razvojnog tima uz dodatne ugovore o povjerljivosti. <br /> <br /> ===Razvojno okruženje:===<br /> <br /> 1. Razvojni tim mora koristiti sustav za upravljanje izvornim tj. programskim kodom sa označivanjem promjena koje je napravio koji član razvojnog tima nad konfiguracijskim datotekama, datotekama izvornog koda i postavkama sigurnosti.<br /> <br /> 2. Razvojni tim mora koristiti način izgradnje softvera iz izvornog koda koji omogućuje provjeru integriteta softvera koji je isporučen klijentu. <br /> <br /> ===Biblioteke, okviri i proizvodi:===<br /> <br /> 1. Svi elementi sustava koji nisu razvijeni u sklopu projekta, već ih je razvila treća strana moraju biti poznati klijentu uz navođenje da li su komercijalni, besplatni, otvorenog koda ili zatvorenog koda. <br /> <br /> 2. Izvođač mora uložiti razuman trud da osigura da elementi koje je razvila treća strana odgovaraju zahtjevima sigurnosti projekta.<br /> <br /> ===Provjera sigurnosti:===<br /> <br /> 1. Klijent ima pravo provjeriti sigurnost sustava u svojem trošku u roku 60 dana od isporuke. Razvojni tim mora omogućiti razumnu podršku timu koji provodi provjeru sigurnosti davajući uvid u izvorni kod i testne okoline. <br /> <br /> 2. Provjera sigurnosti mora uključivati i pokrivati sve elemente sustava uključujući i prilagođene elemente sustava, komponente, proizvode i konfiguraciju.<br /> <br /> 3. Provjera sigurnosti mora minimalno uključivati provjeru za poznatim, čestim ranjivostima. Provjera može uključivati kombinaciju provjere ranjivosti, penetracijskog testa, statičke analize izvornog koda i pregled elemenata sustava od strane eksperta.<br /> <br /> 4. Sigurnosni nedostatci koji se otkriju u sklopu provjere moraju biti preneseni i klijentu i razvojnom timu. <br /> <br /> ===Upravljanje sigurnosnim nedostacima:===<br /> <br /> 1. Sigurnosne nedostatke treba pratiti i uklanjati kroz cijeli životni ciklus sustava, bilo da su dio sigurnosnih zahtjeva, dizajna, implementacije, testiranja, isporuke ili da su operativni problem. Rizik vezan uz svaki sigurnosni nedostatak mora biti evaluiran, dokumentiran i klijent mora biti izviješten o nedostatku i riziku čim se isti otkrije. <br /> <br /> 2. Razvojni tim će primijeniti razumne mjere zaštite informacija veznih us sigurnosne nedostatke i dokumentaciju o istima zbog zaštite klijenta. <br /> <br /> 3. Svi sigurnosni nedostatci koji su pronađeni prije isporuke biti će ispravljeni od strane razvojnog tima. Postupanje sa sigurnosnim nedostatcima otkrivenima nakon isporuke određuje se ugovorom a isti se smatraju kao bilo koja druga manjkavost u softveru. <br /> <br /> ===Osiguravanje kvalitete:===<br /> <br /> 1. Razvojni tim će uz dokumentaciju projekta predati i sigurnosnu dokumentaciju koja uključuje sve sigurnosne zahtjeve, dizajn sustava sigurnosti, implementaciju kontrola, rezultate testiranja te potvrdu da su svi sigurnosni nedostatci uklonjeni prije isporuke softvera. <br /> <br /> 2. Arhitekt sigurnost mora potvrditi da sustav zadovoljava zahtjeve sigurnosti i da su sve aktivnosti u pogledu obrade rizika provedene. Sve iznimke moraju biti dokumentirane i evidentne u isporuci i dokumentaciji. <br /> <br /> 3. Razvojni tim jamči da sustav nema elemenata koji oslabljuju sigurnost a nisu dio zahtjeva klijenta kao što su virusi, crvi, zaobilaženja autentikacije tj. “stražnja vrata”, trojanski konji i ostali oblici malicioznog koda<br /> <br /> ===Održavanje sustava i prihvaćanje:===<br /> <br /> 1. Sustav ne može biti prihvaćen prije nego što su uklonjeni svi sigurnosni nedostatci i rezultati provjere sigurnosti prihvaćeni od strane klijenta.<br /> <br /> 2. Nakon prihvaćanja sustava, ukoliko se pronađu ili se sumnja na dodatne sigurnosne manjkavosti, Izvođač će pomoći klijentu u istraživanju manjkavosti. Ukoliko klasa manjkavosti nije pokrivena sigurnosnim zahtjevima i nalazi se izvan opsega sigurnosnog testiranja, manjkavost se smatra dodatnim razvojnim zahtjevom. Takvi dodani zahtjevi biti će obrađivani dogovorom i odlukom između izvođača i klijenta. <br /> <br /> 3. Izvođač mora primijeniti razumne mjere, koje uključuju razvoj sustava prema najboljim praksama koje uključuju način uklanjanja sigurnosnih manjkavosti prema razini rizika u cilju čim prije obrade rizika u suglasnosti sa klijentom. <br /> <br /> <br /> <br /> [[Category:OWASP Legal Project]]<br /> <br /> __NOTOC__</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=OWASP_Secure_Software_Contract_Annex/hr&diff=184555 2014-11-02T16:37:00Z

<p>Tonimir Kisasondi: </p> <hr /> <div>Prijevod: [Tonimir Kišasondi https://www.owasp.org/index.php/User:Tonimir_Kisasondi], Laboratorij za otvorene sustave i sigurnost, Fakultet organizacije i informatike, Varaždin<br /> <br /> ===Temeljne pretpostavke:===<br /> <br /> 1. Odluke o potrebnoj razini sigurnosti temelje se na razumijevanju rizika koji su vezani uz sustav koji se razvija.<br /> <br /> 2. Pristup osiguravanju sigurnosti mora se temeljiti na pristupu analize i implementacije potrebne razine sigurnosti kroz cijeli životni ciklus proizvoda ili sustava.<br /> <br /> 3. Kontrole tj. mjere zaštite nisu poseban, dodatni dio sustava već integrirani dio u svim elementima sustava. Kontrole ne smiju biti poseban ili dodatan dio razvoja sustava.<br /> <br /> 4. Dokumentacija sustava mora sadržavati opise svih primijenjenih kontrola u sustavu.<br /> <br /> 5. Dokumentacija mora biti jasna, korisna i transparentna te mora opisivati dizajn integriranog, cjelovitog sustava sigurnosti, procjenu rizika koja je provedena u sklopu razvoja i moguće probleme. <br /> <br /> 6. Ranjivosti u sustavu nisu neočekivane ali u procesu razvoja i u ranim fazama životnog ciklusa sustava treba pokušati identificirati sigurnosne manjkavosti. <br /> <br /> 7. Informacije o sigurnosti, rizicima i ranjivostima potrebno je otvoreno razmjenjivati između strane koja razvija sustav i koja je korisnik sustava, čim se navedene informacije otkrije jedna strana, mora obavijestiti drugu stranu u cijelosti i bez ustručavanja.<br /> <br /> ===Aktivnosti životnog ciklusa:===<br /> <br /> 1. Rizici moraju biti identificirani u odnosu na imovinu ili elemente sustava, dokumentirani i obje strane moraju razumjeti rizike koji su u kontekstu sustava.<br /> <br /> 2. Razvoj detaljnih sigurnosnih zahtjeva za sustav mora se temeljiti na identificiranim rizicima, gdje su sigurnosni zahtjevi dio specifikacije sustava koji se razvija. Sigurnosne zahtjeve moguće je realizirati dodatnim prilagođenim razvojem ili dodatnim sigurnosnim elementima u sustavu. <br /> <br /> 3. Svaki sigurnosni zahtjev mora biti razmotren i odluka mora biti donesena o načinu obrade rizika. Izvođač i naručitelj sustava moraju biti suglasni oko svih opisanih sigurnosnih zahtjeva i kontrola. Odluke moraju dokumentirane, te dokumentacija mora sadržavati informaciju zašto je konkretna kontrola prikladna i na koji način odgovara u cjelokupnom sustavu uz sva njegova ograničenja. Bitno je navesti da li se kontrola temelji na ugrađenom elementu koji je dio sustava ili je kontrola element koji razvija treća strana. Svaki sigurnosni zahtjev mora biti formiran na način da je moguće provjeriti da li je ispunjen. <br /> <br /> 4. Razvoj sustava mora se temeljiti na elementima koji su sigurni i odgovaraju zahtjevima sigurnosti.<br /> <br /> 5. Svi elementi sustava moraju proći provjeru od druge strane koja nije razvijala konkretni element sustava. Cijeli sustav mora odgovarati dogovorenoj normi verifikacije mjera sigurnosti kao što je OWASP ASVS ili nekoj drugoj. Rezultati verifikacije moraju biti dokumentirani prema zahtjevima norme za verifikaciju.<br /> <br /> 6. Sustav mora sadržavati opis postavki i njihove implikacije za sigurnost sustava. Opis mora sadržavati i opis zavisnosti kao što je potrebna inačica operacijskog sustava, web poslužitelja, sustava za upravljanje bazom podataka i način na koji isti moraju biti podešeni da odgovaraju zahtjevima sigurnosti cijelog sustava. Početna konfiguracija sustava u trenutku isporuke mora biti sigurna. <br /> <br /> ===Zahtjevi sigurnosti:===<br /> <br /> Prilikom procjene rizika i definiranja sigurnosnih zahtjeva potrebno je uzeti u obzir sljedeće zahtjeve sigurnosti koji moraju uključivati:<br /> <br /> 1. Pravila za provjeru unosa i kodiranje svakog ulaza u aplikaciju, bez obzira da li je unos od korisnika, baze podataka ili vanjskih sustava. Početna pretpostavka je da su svi unosi nevaljani osim ako ne odgovaraju specifikaciji točnog unosa. Zahtjevi moraju sadržavati postupak što uraditi sa unosom koji nije valjan. Sustavi ne bi smjeli biti podložni napadima umetanja znakova, prelijevanja spremnika, neovlaštenom promjenom i ostale napade koji mijenjaju stanje sustava.<br /> <br /> 2. Mjere kako će se štiti sesija korisnika te podatci kojima se identificira sesija i prijavljeni korisnik. Zahtjevi moraju uključivati mjere za sve povezane funkcije kao što su: vraćanje zaboravljene lozinke, promjene lozinke, odjave, višestruke prijave i druge. <br /> <br /> 3. Detaljan opis načina realizacije kontrole pristupa te uloge, grupe, privilegije i autorizacije koje se koriste u aplikaciji vezane uz imovinu i funkcije koje su unutar sustava, gdje se povezuju specifična prava pristupa za svaku imovinu ili funkciju po svakoj ulozi. Predlaže se uporaba matrice kontrole pristupa za opis uloga i razine prava pristupa. <br /> <br /> 4. Način ponašanja sustava prilikom greške u radu. U nekim slučajevima najbolje je pružiti korisniku najbolji pokušaj u slučaju greške a nekada je najbolje prekinuti izvršavanje odmah. Navedene situacije i način baratanja greškama mora biti definiran prije izgradnje sustava. <br /> <br /> 5. Način bilježenja događaja u sustavu kao što su uspješne i neuspješne prijave, uočeni napadi ili pokušaji zaobilaženja autorizacije. Zahtjevi moraju sadržavati i podatke koji se moraju bilježiti kao što je vrijeme, datum, detalji aplikacije i sve ostale podatke koji omogućavaju forenzičku analizu. <br /> <br /> 6. Oblik autentikacije i zaštite komunikacije kao što je kriptiranje komunikacije i veze sa drugim elementima sustava kao što su baze podataka ili drugi web servisi. Vjerodajnice za uspostavu komunikacije moraju biti također zaštićene na primjeren način. <br /> <br /> 7. Odluku koje podatke treba kriptirati, na koji način kriptirati te kako će se postupati sa certifikatima i vjerodajnicama. Sustav mora koristiti standardne preporučene algoritme i biblioteke koje su sigurnosno provjerene. <br /> <br /> 8. Način zaštite sustava od napada uskraćenjem usluge (DoS ili DDoS), u obzir treba uzeti razne vrste napada kao što je zaključavanje autentikacije nakon većeg broja neuspješnih pokušaja, iscrpljivanja broja konekcija i ostale napade iscrpljivanjem resursa.<br /> <br /> 9. Početne vrijednosti konfiguracije moraju biti fokusirane prema sigurnim postavkama. Sustav mora omogućiti lagani pregled svih relevantnih opcija i postavljene vrijednosti za provjeru sigurnosti.<br /> <br /> 10. Popis ranjivosti koje su uklonjene tijekom razvoja i kontrole koje su postavljene.<br /> <br /> ===Osoblje i organizacija:===<br /> <br /> 1. Uz razvoj, dodatna verifikacija sigurnosti trebala bi se provoditi kroz arhitekte sigurnosti koji razumiju problematiku razvoja sigurnih elemenata sustava.<br /> <br /> 2. Članovi tima za razvoj moraju biti obučeni i educirani u najboljoj praksi izgradnje sigurnih sustava vezanih uz njihove uloge.<br /> <br /> 3. U slučaju razvoja povjerljivih sustava treba razmotriti primjerenost provjere sigurnosti i prijašnje iskustvo razvojnog tima uz dodatne ugovore o povjerljivosti. <br /> <br /> ===Razvojno okruženje:===<br /> <br /> 1. Razvojni tim mora koristiti sustav za upravljanje izvornim tj. programskim kodom sa označivanjem promjena koje je napravio koji član razvojnog tima nad konfiguracijskim datotekama, datotekama izvornog koda i postavkama sigurnosti.<br /> <br /> 2. Razvojni tim mora koristiti način izgradnje softvera iz izvornog koda koji omogućuje provjeru integriteta softvera koji je isporučen klijentu. <br /> <br /> ===Biblioteke, okviri i proizvodi:===<br /> <br /> 1. Svi elementi sustava koji nisu razvijeni u sklopu projekta, već ih je razvila treća strana moraju biti poznati klijentu uz navođenje da li su komercijalni, besplatni, otvorenog koda ili zatvorenog koda. <br /> <br /> 2. Izvođač mora uložiti razuman trud da osigura da elementi koje je razvila treća strana odgovaraju zahtjevima sigurnosti projekta.<br /> <br /> ===Provjera sigurnosti:===<br /> <br /> 1. Klijent ima pravo provjeriti sigurnost sustava u svojem trošku u roku 60 dana od isporuke. Razvojni tim mora omogućiti razumnu podršku timu koji provodi provjeru sigurnosti davajući uvid u izvorni kod i testne okoline. <br /> <br /> 2. Provjera sigurnosti mora uključivati i pokrivati sve elemente sustava uključujući i prilagođene elemente sustava, komponente, proizvode i konfiguraciju.<br /> <br /> 3. Provjera sigurnosti mora minimalno uključivati provjeru za poznatim, čestim ranjivostima. Provjera može uključivati kombinaciju provjere ranjivosti, penetracijskog testa, statičke analize izvornog koda i pregled elemenata sustava od strane eksperta.<br /> <br /> 4. Sigurnosni nedostatci koji se otkriju u sklopu provjere moraju biti preneseni i klijentu i razvojnom timu. <br /> <br /> ===Upravljanje sigurnosnim nedostacima:===<br /> <br /> 1. Sigurnosne nedostatke treba pratiti i uklanjati kroz cijeli životni ciklus sustava, bilo da su dio sigurnosnih zahtjeva, dizajna, implementacije, testiranja, isporuke ili da su operativni problem. Rizik vezan uz svaki sigurnosni nedostatak mora biti evaluiran, dokumentiran i klijent mora biti izviješten o nedostatku i riziku čim se isti otkrije. <br /> <br /> 2. Razvojni tim će primijeniti razumne mjere zaštite informacija veznih us sigurnosne nedostatke i dokumentaciju o istima zbog zaštite klijenta. <br /> <br /> 3. Svi sigurnosni nedostatci koji su pronađeni prije isporuke biti će ispravljeni od strane razvojnog tima. Postupanje sa sigurnosnim nedostatcima otkrivenima nakon isporuke određuje se ugovorom a isti se smatraju kao bilo koja druga manjkavost u softveru. <br /> <br /> ===Osiguravanje kvalitete:===<br /> <br /> 1. Razvojni tim će uz dokumentaciju projekta predati i sigurnosnu dokumentaciju koja uključuje sve sigurnosne zahtjeve, dizajn sustava sigurnosti, implementaciju kontrola, rezultate testiranja te potvrdu da su svi sigurnosni nedostatci uklonjeni prije isporuke softvera. <br /> <br /> 2. Arhitekt sigurnost mora potvrditi da sustav zadovoljava zahtjeve sigurnosti i da su sve aktivnosti u pogledu obrade rizika provedene. Sve iznimke moraju biti dokumentirane i evidentne u isporuci i dokumentaciji. <br /> <br /> 3. Razvojni tim jamči da sustav nema elemenata koji oslabljuju sigurnost a nisu dio zahtjeva klijenta kao što su virusi, crvi, zaobilaženja autentikacije tj. “stražnja vrata”, trojanski konji i ostali oblici malicioznog koda<br /> <br /> ===Održavanje sustava i prihvaćanje:===<br /> <br /> 1. Sustav ne može biti prihvaćen prije nego što su uklonjeni svi sigurnosni nedostatci i rezultati provjere sigurnosti prihvaćeni od strane klijenta.<br /> <br /> 2. Nakon prihvaćanja sustava, ukoliko se pronađu ili se sumnja na dodatne sigurnosne manjkavosti, Izvođač će pomoći klijentu u istraživanju manjkavosti. Ukoliko klasa manjkavosti nije pokrivena sigurnosnim zahtjevima i nalazi se izvan opsega sigurnosnog testiranja, manjkavost se smatra dodatnim razvojnim zahtjevom. Takvi dodani zahtjevi biti će obrađivani dogovorom i odlukom između izvođača i klijenta. <br /> <br /> 3. Izvođač mora primijeniti razumne mjere, koje uključuju razvoj sustava prema najboljim praksama koje uključuju način uklanjanja sigurnosnih manjkavosti prema razini rizika u cilju čim prije obrade rizika u suglasnosti sa klijentom. <br /> <br /> <br /> <br /> [[Category:OWASP Legal Project]]<br /> <br /> __NOTOC__</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=OWASP_Secure_Software_Contract_Annex/hr&diff=184554 2014-11-02T16:35:45Z

<p>Tonimir Kisasondi: </p> <hr /> <div>Prijevod: [Tonimir Kišasondi https://www.owasp.org/index.php/User:Tonimir_Kisasondi], Laboratorij za otvorene sustave i sigurnost, Fakultet organizacije i informatike, Varaždin<br /> <br /> ===Temeljne pretpostavke:===<br /> <br /> 1. Odluke o potrebnoj razini sigurnosti temelje se na razumijevanju rizika koji su vezani uz sustav koji se razvija.<br /> <br /> 2. Pristup osiguravanju sigurnosti mora se temeljiti na pristupu analize i implementacije potrebne razine sigurnosti kroz cijeli životni ciklus proizvoda ili sustava.<br /> <br /> 3. Kontrole tj. mjere zaštite nisu poseban, dodatni dio sustava već integrirani dio u svim elementima sustava. Kontrole ne smiju biti poseban ili dodatan dio razvoja sustava.<br /> <br /> 4. Dokumentacija sustava mora sadržavati opise svih primijenjenih kontrola u sustavu.<br /> <br /> 5. Dokumentacija mora biti jasna, korisna i transparentna te mora opisivati dizajn integriranog, cjelovitog sustava sigurnosti, procjenu rizika koja je provedena u sklopu razvoja i moguće probleme. <br /> <br /> 6. Ranjivosti u sustavu nisu neočekivane ali u procesu razvoja i u ranim fazama životnog ciklusa sustava treba pokušati identificirati sigurnosne manjkavosti. <br /> <br /> 7. Informacije o sigurnosti, rizicima i ranjivostima potrebno je otvoreno razmjenjivati između strane koja razvija sustav i koja je korisnik sustava, čim se navedene informacije otkrije jedna strana, mora obavijestiti drugu stranu u cijelosti i bez ustručavanja.<br /> <br /> ===Aktivnosti životnog ciklusa:===<br /> <br /> 1. Rizici moraju biti identificirani u odnosu na imovinu ili elemente sustava, dokumentirani i obje strane moraju razumjeti rizike koji su u kontekstu sustava.<br /> <br /> 2. Razvoj detaljnih sigurnosnih zahtjeva za sustav mora se temeljiti na identificiranim rizicima, gdje su sigurnosni zahtjevi dio specifikacije sustava koji se razvija. Sigurnosne zahtjeve moguće je realizirati dodatnim prilagođenim razvojem ili dodatnim sigurnosnim elementima u sustavu. <br /> <br /> 3. Svaki sigurnosni zahtjev mora biti razmotren i odluka mora biti donesena o načinu obrade rizika. Izvođač i naručitelj sustava moraju biti suglasni oko svih opisanih sigurnosnih zahtjeva i kontrola. Odluke moraju dokumentirane, te dokumentacija mora sadržavati informaciju zašto je konkretna kontrola prikladna i na koji način odgovara u cjelokupnom sustavu uz sva njegova ograničenja. Bitno je navesti da li se kontrola temelji na ugrađenom elementu koji je dio sustava ili je kontrola element koji razvija treća strana. Svaki sigurnosni zahtjev mora biti formiran na način da je moguće provjeriti da li je ispunjen. <br /> <br /> 4. Razvoj sustava mora se temeljiti na elementima koji su sigurni i odgovaraju zahtjevima sigurnosti.<br /> <br /> 5. Svi elementi sustava moraju proći provjeru od druge strane koja nije razvijala konkretni element sustava. Cijeli sustav mora odgovarati dogovorenoj normi verifikacije mjera sigurnosti kao što je OWASP ASVS ili nekoj drugoj. Rezultati verifikacije moraju biti dokumentirani prema zahtjevima norme za verifikaciju.<br /> <br /> 6. Sustav mora sadržavati opis postavki i njihove implikacije za sigurnost sustava. Opis mora sadržavati i opis zavisnosti kao što je potrebna inačica operacijskog sustava, web poslužitelja, sustava za upravljanje bazom podataka i način na koji isti moraju biti podešeni da odgovaraju zahtjevima sigurnosti cijelog sustava. Početna konfiguracija sustava u trenutku isporuke mora biti sigurna. <br /> <br /> ===Zahtjevi sigurnosti:===<br /> <br /> Prilikom procjene rizika i definiranja sigurnosnih zahtjeva potrebno je uzeti u obzir sljedeće zahtjeve sigurnosti koji moraju uključivati:<br /> <br /> 1. Pravila za provjeru unosa i kodiranje svakog ulaza u aplikaciju, bez obzira da li je unos od korisnika, baze podataka ili vanjskih sustava. Početna pretpostavka je da su svi unosi nevaljani osim ako ne odgovaraju specifikaciji točnog unosa. Zahtjevi moraju sadržavati postupak što uraditi sa unosom koji nije valjan. Sustavi ne bi smjeli biti podložni napadima umetanja znakova, prelijevanja spremnika, neovlaštenom promjenom i ostale napade koji mijenjaju stanje sustava.<br /> <br /> 2. Mjere kako će se štiti sesija korisnika te podatci kojima se identificira sesija i prijavljeni korisnik. Zahtjevi moraju uključivati mjere za sve povezane funkcije kao što su: vraćanje zaboravljene lozinke, promjene lozinke, odjave, višestruke prijave i druge. <br /> <br /> 3. Detaljan opis načina realizacije kontrole pristupa te uloge, grupe, privilegije i autorizacije koje se koriste u aplikaciji vezane uz imovinu i funkcije koje su unutar sustava, gdje se povezuju specifična prava pristupa za svaku imovinu ili funkciju po svakoj ulozi. Predlaže se uporaba matrice kontrole pristupa za opis uloga i razine prava pristupa. <br /> <br /> 4. Način ponašanja sustava prilikom greške u radu. U nekim slučajevima najbolje je pružiti korisniku najbolji pokušaj u slučaju greške a nekada je najbolje prekinuti izvršavanje odmah. Navedene situacije i način baratanja greškama mora biti definiran prije izgradnje sustava. <br /> <br /> 5. Način bilježenja događaja u sustavu kao što su uspješne i neuspješne prijave, uočeni napadi ili pokušaji zaobilaženja autorizacije. Zahtjevi moraju sadržavati i podatke koji se moraju bilježiti kao što je vrijeme, datum, detalji aplikacije i sve ostale podatke koji omogućavaju forenzičku analizu. <br /> <br /> 6. Oblik autentikacije i zaštite komunikacije kao što je kriptiranje komunikacije i veze sa drugim elementima sustava kao što su baze podataka ili drugi web servisi. Vjerodajnice za uspostavu komunikacije moraju biti također zaštićene na primjeren način. <br /> <br /> 7. Odluku koje podatke treba kriptirati, na koji način kriptirati te kako će se postupati sa certifikatima i vjerodajnicama. Sustav mora koristiti standardne preporučene algoritme i biblioteke koje su sigurnosno provjerene. <br /> <br /> 8. Način zaštite sustava od napada uskraćenjem usluge (DoS ili DDoS), u obzir treba uzeti razne vrste napada kao što je zaključavanje autentikacije nakon većeg broja neuspješnih pokušaja, iscrpljivanja broja konekcija i ostale napade iscrpljivanjem resursa.<br /> <br /> 9. Početne vrijednosti konfiguracije moraju biti fokusirane prema sigurnim postavkama. Sustav mora omogućiti lagani pregled svih relevantnih opcija i postavljene vrijednosti za provjeru sigurnosti.<br /> <br /> 10. Popis ranjivosti koje su uklonjene tijekom razvoja i kontrole koje su postavljene.<br /> <br /> ===Osoblje i organizacija:===<br /> <br /> 1. Uz razvoj, dodatna verifikacija sigurnosti trebala bi se provoditi kroz arhitekte sigurnosti koji razumiju problematiku razvoja sigurnih elemenata sustava.<br /> <br /> 2. Članovi tima za razvoj moraju biti obučeni i educirani u najboljoj praksi izgradnje sigurnih sustava vezanih uz njihove uloge.<br /> <br /> 3. U slučaju razvoja povjerljivih sustava treba razmotriti primjerenost provjere sigurnosti i prijašnje iskustvo razvojnog tima uz dodatne ugovore o povjerljivosti. <br /> <br /> ===Razvojno okruženje:===<br /> <br /> 1. Razvojni tim mora koristiti sustav za upravljanje izvornim tj. programskim kodom sa označivanjem promjena koje je napravio koji član razvojnog tima nad konfiguracijskim datotekama, datotekama izvornog koda i postavkama sigurnosti.<br /> <br /> 2. Razvojni tim mora koristiti način izgradnje softvera iz izvornog koda koji omogućuje provjeru integriteta softvera koji je isporučen klijentu. <br /> <br /> ===Biblioteke, okviri i proizvodi:===<br /> <br /> 1. Svi elementi sustava koji nisu razvijeni u sklopu projekta, već ih je razvila treća strana moraju biti poznati klijentu uz navođenje da li su komercijalni, besplatni, otvorenog koda ili zatvorenog koda. <br /> <br /> 2. Izvođač mora uložiti razuman trud da osigura da elementi koje je razvila treća strana odgovaraju zahtjevima sigurnosti projekta.<br /> <br /> ===Provjera sigurnosti:===<br /> <br /> 1. Klijent ima pravo provjeriti sigurnost sustava u svojem trošku u roku 60 dana od isporuke. Razvojni tim mora omogućiti razumnu podršku timu koji provodi provjeru sigurnosti davajući uvid u izvorni kod i testne okoline. <br /> <br /> 2. Provjera sigurnosti mora uključivati i pokrivati sve elemente sustava uključujući i prilagođene elemente sustava, komponente, proizvode i konfiguraciju.<br /> <br /> 3. Provjera sigurnosti mora minimalno uključivati provjeru za poznatim, čestim ranjivostima. Provjera može uključivati kombinaciju provjere ranjivosti, penetracijskog testa, statičke analize izvornog koda i pregled elemenata sustava od strane eksperta.<br /> <br /> 4. Sigurnosni nedostatci koji se otkriju u sklopu provjere moraju biti preneseni i klijentu i razvojnom timu. <br /> <br /> ===Upravljanje sigurnosnim nedostacima:===<br /> <br /> 1. Sigurnosne nedostatke treba pratiti i uklanjati kroz cijeli životni ciklus sustava, bilo da su dio sigurnosnih zahtjeva, dizajna, implementacije, testiranja, isporuke ili da su operativni problem. Rizik vezan uz svaki sigurnosni nedostatak mora biti evaluiran, dokumentiran i klijent mora biti izviješten o nedostatku i riziku čim se isti otkrije. <br /> <br /> 2. Razvojni tim će primijeniti razumne mjere zaštite informacija veznih us sigurnosne nedostatke i dokumentaciju o istima zbog zaštite klijenta. <br /> <br /> 3. Svi sigurnosni nedostatci koji su pronađeni prije isporuke biti će ispravljeni od strane razvojnog tima. Postupanje sa sigurnosnim nedostatcima otkrivenima nakon isporuke određuje se ugovorom a isti se smatraju kao bilo koja druga manjkavost u softveru. <br /> <br /> <br /> ===Osiguravanje kvalitete:===<br /> <br /> 1. Razvojni tim će uz dokumentaciju projekta predati i sigurnosnu dokumentaciju koja uključuje sve sigurnosne zahtjeve, dizajn sustava sigurnosti, implementaciju kontrola, rezultate testiranja te potvrdu da su svi sigurnosni nedostatci uklonjeni prije isporuke softvera. <br /> <br /> 2. Arhitekt sigurnost mora potvrditi da sustav zadovoljava zahtjeve sigurnosti i da su sve aktivnosti u pogledu obrade rizika provedene. Sve iznimke moraju biti dokumentirane i evidentne u isporuci i dokumentaciji. <br /> <br /> 3. Razvojni tim jamči da sustav nema elemenata koji oslabljuju sigurnost a nisu dio zahtjeva klijenta kao što su virusi, crvi, zaobilaženja autentikacije tj. “stražnja vrata”, trojanski konji i ostali oblici malicioznog koda<br /> <br /> <br /> ===Održavanje sustava i prihvaćanje:===<br /> <br /> 1. Sustav ne može biti prihvaćen prije nego što su uklonjeni svi sigurnosni nedostatci i rezultati provjere sigurnosti prihvaćeni od strane klijenta.<br /> <br /> 2. Nakon prihvaćanja sustava, ukoliko se pronađu ili se sumnja na dodatne sigurnosne manjkavosti, Izvođač će pomoći klijentu u istraživanju manjkavosti. Ukoliko klasa manjkavosti nije pokrivena sigurnosnim zahtjevima i nalazi se izvan opsega sigurnosnog testiranja, manjkavost se smatra dodatnim razvojnim zahtjevom. Takvi dodani zahtjevi biti će obrađivani dogovorom i odlukom između izvođača i klijenta. <br /> <br /> 3. Izvođač mora primijeniti razumne mjere, koje uključuju razvoj sustava prema najboljim praksama koje uključuju način uklanjanja sigurnosnih manjkavosti prema razini rizika u cilju čim prije obrade rizika u suglasnosti sa klijentom. <br /> <br /> <br /> <br /> [[Category:OWASP Legal Project]]<br /> <br /> __NOTOC__</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=OWASP_Secure_Software_Contract_Annex/hr&diff=184553 2014-11-02T16:34:10Z

<p>Tonimir Kisasondi: Created page with &quot; ===Temeljne pretpostavke:=== 1. Odluke o potrebnoj razini sigurnosti temelje se na razumijevanju rizika koji su vezani uz sustav koji se razvija. 2. Pristup osiguravanju s...&quot;</p> <hr /> <div><br /> <br /> ===Temeljne pretpostavke:===<br /> <br /> 1. Odluke o potrebnoj razini sigurnosti temelje se na razumijevanju rizika koji su vezani uz sustav koji se razvija.<br /> <br /> 2. Pristup osiguravanju sigurnosti mora se temeljiti na pristupu analize i implementacije potrebne razine sigurnosti kroz cijeli životni ciklus proizvoda ili sustava.<br /> <br /> 3. Kontrole tj. mjere zaštite nisu poseban, dodatni dio sustava već integrirani dio u svim elementima sustava. Kontrole ne smiju biti poseban ili dodatan dio razvoja sustava.<br /> <br /> 4. Dokumentacija sustava mora sadržavati opise svih primijenjenih kontrola u sustavu.<br /> <br /> 5. Dokumentacija mora biti jasna, korisna i transparentna te mora opisivati dizajn integriranog, cjelovitog sustava sigurnosti, procjenu rizika koja je provedena u sklopu razvoja i moguće probleme. <br /> <br /> 6. Ranjivosti u sustavu nisu neočekivane ali u procesu razvoja i u ranim fazama životnog ciklusa sustava treba pokušati identificirati sigurnosne manjkavosti. <br /> <br /> 7. Informacije o sigurnosti, rizicima i ranjivostima potrebno je otvoreno razmjenjivati između strane koja razvija sustav i koja je korisnik sustava, čim se navedene informacije otkrije jedna strana, mora obavijestiti drugu stranu u cijelosti i bez ustručavanja.<br /> <br /> <br /> ===Aktivnosti životnog ciklusa===<br /> <br /> 1. Rizici moraju biti identificirani u odnosu na imovinu ili elemente sustava, dokumentirani i obje strane moraju razumjeti rizike koji su u kontekstu sustava.<br /> <br /> 2. Razvoj detaljnih sigurnosnih zahtjeva za sustav mora se temeljiti na identificiranim rizicima, gdje su sigurnosni zahtjevi dio specifikacije sustava koji se razvija. Sigurnosne zahtjeve moguće je realizirati dodatnim prilagođenim razvojem ili dodatnim sigurnosnim elementima u sustavu. <br /> <br /> 3. Svaki sigurnosni zahtjev mora biti razmotren i odluka mora biti donesena o načinu obrade rizika. Izvođač i naručitelj sustava moraju biti suglasni oko svih opisanih sigurnosnih zahtjeva i kontrola. Odluke moraju dokumentirane, te dokumentacija mora sadržavati informaciju zašto je konkretna kontrola prikladna i na koji način odgovara u cjelokupnom sustavu uz sva njegova ograničenja. Bitno je navesti da li se kontrola temelji na ugrađenom elementu koji je dio sustava ili je kontrola element koji razvija treća strana. Svaki sigurnosni zahtjev mora biti formiran na način da je moguće provjeriti da li je ispunjen. <br /> <br /> 4. Razvoj sustava mora se temeljiti na elementima koji su sigurni i odgovaraju zahtjevima sigurnosti.<br /> <br /> 5. Svi elementi sustava moraju proći provjeru od druge strane koja nije razvijala konkretni element sustava. Cijeli sustav mora odgovarati dogovorenoj normi verifikacije mjera sigurnosti kao što je OWASP ASVS ili nekoj drugoj. Rezultati verifikacije moraju biti dokumentirani prema zahtjevima norme za verifikaciju.<br /> <br /> 6. Sustav mora sadržavati opis postavki i njihove implikacije za sigurnost sustava. Opis mora sadržavati i opis zavisnosti kao što je potrebna inačica operacijskog sustava, web poslužitelja, sustava za upravljanje bazom podataka i način na koji isti moraju biti podešeni da odgovaraju zahtjevima sigurnosti cijelog sustava. Početna konfiguracija sustava u trenutku isporuke mora biti sigurna. <br /> <br /> <br /> ===Zahtjevi sigurnosti:===<br /> <br /> Prilikom procjene rizika i definiranja sigurnosnih zahtjeva potrebno je uzeti u obzir sljedeće zahtjeve sigurnosti koji moraju uključivati:<br /> <br /> 1. Pravila za provjeru unosa i kodiranje svakog ulaza u aplikaciju, bez obzira da li je unos od korisnika, baze podataka ili vanjskih sustava. Početna pretpostavka je da su svi unosi nevaljani osim ako ne odgovaraju specifikaciji točnog unosa. Zahtjevi moraju sadržavati postupak što uraditi sa unosom koji nije valjan. Sustavi ne bi smjeli biti podložni napadima umetanja znakova, prelijevanja spremnika, neovlaštenom promjenom i ostale napade koji mijenjaju stanje sustava.<br /> <br /> 2. Mjere kako će se štiti sesija korisnika te podatci kojima se identificira sesija i prijavljeni korisnik. Zahtjevi moraju uključivati mjere za sve povezane funkcije kao što su: vraćanje zaboravljene lozinke, promjene lozinke, odjave, višestruke prijave i druge. <br /> <br /> 3. Detaljan opis načina realizacije kontrole pristupa te uloge, grupe, privilegije i autorizacije koje se koriste u aplikaciji vezane uz imovinu i funkcije koje su unutar sustava, gdje se povezuju specifična prava pristupa za svaku imovinu ili funkciju po svakoj ulozi. Predlaže se uporaba matrice kontrole pristupa za opis uloga i razine prava pristupa. <br /> <br /> 4. Način ponašanja sustava prilikom greške u radu. U nekim slučajevima najbolje je pružiti korisniku najbolji pokušaj u slučaju greške a nekada je najbolje prekinuti izvršavanje odmah. Navedene situacije i način baratanja greškama mora biti definiran prije izgradnje sustava. <br /> <br /> 5. Način bilježenja događaja u sustavu kao što su uspješne i neuspješne prijave, uočeni napadi ili pokušaji zaobilaženja autorizacije. Zahtjevi moraju sadržavati i podatke koji se moraju bilježiti kao što je vrijeme, datum, detalji aplikacije i sve ostale podatke koji omogućavaju forenzičku analizu. <br /> <br /> 6. Oblik autentikacije i zaštite komunikacije kao što je kriptiranje komunikacije i veze sa drugim elementima sustava kao što su baze podataka ili drugi web servisi. Vjerodajnice za uspostavu komunikacije moraju biti također zaštićene na primjeren način. <br /> <br /> 7. Odluku koje podatke treba kriptirati, na koji način kriptirati te kako će se postupati sa certifikatima i vjerodajnicama. Sustav mora koristiti standardne preporučene algoritme i biblioteke koje su sigurnosno provjerene. <br /> <br /> 8. Način zaštite sustava od napada uskraćenjem usluge (DoS ili DDoS), u obzir treba uzeti razne vrste napada kao što je zaključavanje autentikacije nakon većeg broja neuspješnih pokušaja, iscrpljivanja broja konekcija i ostale napade iscrpljivanjem resursa.<br /> <br /> 9. Početne vrijednosti konfiguracije moraju biti fokusirane prema sigurnim postavkama. Sustav mora omogućiti lagani pregled svih relevantnih opcija i postavljene vrijednosti za provjeru sigurnosti.<br /> <br /> 10. Popis ranjivosti koje su uklonjene tijekom razvoja i kontrole koje su postavljene.<br /> <br /> ===Osoblje i organizacija:===<br /> <br /> 1. Uz razvoj, dodatna verifikacija sigurnosti trebala bi se provoditi kroz arhitekte sigurnosti koji razumiju problematiku razvoja sigurnih elemenata sustava.<br /> <br /> 2. Članovi tima za razvoj moraju biti obučeni i educirani u najboljoj praksi izgradnje sigurnih sustava vezanih uz njihove uloge.<br /> <br /> 3. U slučaju razvoja povjerljivih sustava treba razmotriti primjerenost provjere sigurnosti i prijašnje iskustvo razvojnog tima uz dodatne ugovore o povjerljivosti. <br /> <br /> <br /> ===Razvojno okruženje:===<br /> <br /> 1. Razvojni tim mora koristiti sustav za upravljanje izvornim tj. programskim kodom sa označivanjem promjena koje je napravio koji član razvojnog tima nad konfiguracijskim datotekama, datotekama izvornog koda i postavkama sigurnosti.<br /> <br /> 2. Razvojni tim mora koristiti način izgradnje softvera iz izvornog koda koji omogućuje provjeru integriteta softvera koji je isporučen klijentu. <br /> <br /> <br /> ===Biblioteke, okviri i proizvodi:===<br /> <br /> 1. Svi elementi sustava koji nisu razvijeni u sklopu projekta, već ih je razvila treća strana moraju biti poznati klijentu uz navođenje da li su komercijalni, besplatni, otvorenog koda ili zatvorenog koda. <br /> <br /> 2. Izvođač mora uložiti razuman trud da osigura da elementi koje je razvila treća strana odgovaraju zahtjevima sigurnosti projekta.<br /> <br /> <br /> ===Provjera sigurnosti:===<br /> <br /> 1. Klijent ima pravo provjeriti sigurnost sustava u svojem trošku u roku 60 dana od isporuke. Razvojni tim mora omogućiti razumnu podršku timu koji provodi provjeru sigurnosti davajući uvid u izvorni kod i testne okoline. <br /> <br /> 2. Provjera sigurnosti mora uključivati i pokrivati sve elemente sustava uključujući i prilagođene elemente sustava, komponente, proizvode i konfiguraciju.<br /> <br /> 3. Provjera sigurnosti mora minimalno uključivati provjeru za poznatim, čestim ranjivostima. Provjera može uključivati kombinaciju provjere ranjivosti, penetracijskog testa, statičke analize izvornog koda i pregled elemenata sustava od strane eksperta.<br /> <br /> 4. Sigurnosni nedostatci koji se otkriju u sklopu provjere moraju biti preneseni i klijentu i razvojnom timu. <br /> <br /> <br /> ===Upravljanje sigurnosnim nedostacima:===<br /> <br /> <br /> 1. Sigurnosne nedostatke treba pratiti i uklanjati kroz cijeli životni ciklus sustava, bilo da su dio sigurnosnih zahtjeva, dizajna, implementacije, testiranja, isporuke ili da su operativni problem. Rizik vezan uz svaki sigurnosni nedostatak mora biti evaluiran, dokumentiran i klijent mora biti izviješten o nedostatku i riziku čim se isti otkrije. <br /> <br /> 2. Razvojni tim će primijeniti razumne mjere zaštite informacija veznih us sigurnosne nedostatke i dokumentaciju o istima zbog zaštite klijenta. <br /> <br /> 3. Svi sigurnosni nedostatci koji su pronađeni prije isporuke biti će ispravljeni od strane razvojnog tima. Postupanje sa sigurnosnim nedostatcima otkrivenima nakon isporuke određuje se ugovorom a isti se smatraju kao bilo koja druga manjkavost u softveru. <br /> <br /> <br /> ===Osiguravanje kvalitete:===<br /> <br /> 1. Razvojni tim će uz dokumentaciju projekta predati i sigurnosnu dokumentaciju koja uključuje sve sigurnosne zahtjeve, dizajn sustava sigurnosti, implementaciju kontrola, rezultate testiranja te potvrdu da su svi sigurnosni nedostatci uklonjeni prije isporuke softvera. <br /> <br /> 2. Arhitekt sigurnost mora potvrditi da sustav zadovoljava zahtjeve sigurnosti i da su sve aktivnosti u pogledu obrade rizika provedene. Sve iznimke moraju biti dokumentirane i evidentne u isporuci i dokumentaciji. <br /> <br /> 3. Razvojni tim jamči da sustav nema elemenata koji oslabljuju sigurnost a nisu dio zahtjeva klijenta kao što su virusi, crvi, zaobilaženja autentikacije tj. “stražnja vrata”, trojanski konji i ostali oblici malicioznog koda<br /> <br /> <br /> ===Održavanje sustava i prihvaćanje:===<br /> <br /> 1. Sustav ne može biti prihvaćen prije nego što su uklonjeni svi sigurnosni nedostatci i rezultati provjere sigurnosti prihvaćeni od strane klijenta.<br /> <br /> 2. Nakon prihvaćanja sustava, ukoliko se pronađu ili se sumnja na dodatne sigurnosne manjkavosti, Izvođač će pomoći klijentu u istraživanju manjkavosti. Ukoliko klasa manjkavosti nije pokrivena sigurnosnim zahtjevima i nalazi se izvan opsega sigurnosnog testiranja, manjkavost se smatra dodatnim razvojnim zahtjevom. Takvi dodani zahtjevi biti će obrađivani dogovorom i odlukom između izvođača i klijenta. <br /> <br /> 3. Izvođač mora primijeniti razumne mjere, koje uključuju razvoj sustava prema najboljim praksama koje uključuju način uklanjanja sigurnosnih manjkavosti prema razini rizika u cilju čim prije obrade rizika u suglasnosti sa klijentom. <br /> <br /> <br /> <br /> [[Category:OWASP Legal Project]]<br /> <br /> __NOTOC__</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=OWASP_Security_Shepherd&diff=182925 2014-09-26T19:14:39Z

<p>Tonimir Kisasondi: </p> <hr /> <div>[[Image:Shepherd-Injection-Lesson.JPG|thumb|300px|right|Detailed vulnerability explainations]][[Image:Shepherd-Scoreboard.JPG|thumb|300px|right|Competitive Learning Environment]]<br /> '''Security Shepherd''' is a computer based training application for web and mobile application security vulnerabilities. This project strives to herd the lost sheep of the technological world back to the safe and sound ways of secure practices. Security Shepherd can be deployed as a CTF (Capture the Flag) game or as an open floor educational server.<br /> <br /> == Overview ==<br /> [[Image:Shepherd-CTF-Level-One.JPG|thumb|300px|right|Easy configuration to suit every use]]<br /> Security Shepherd has been implemented with the aim of fostering and improving security awareness among a varied skill-set demographic. This project enables users to learn or to improve upon existing manual penetration testing skills. This is accomplished through lesson and challenge techniques. A lesson provides a user with a lot of help in completing that module, where a challenge puts what the user learned in the lesson to use. Utilizing the OWASP top ten as a challenge test bed, common security vulnerabilities can be explored and their impact on a system understood. The by-product of this challenge game is the acquired skill to harden a player's own environment from OWASP top ten security risks. The modules have been crafted to provide not only a challenge for a security novice, but security professionals as well.<br /> <br /> Security Shepherd's vulnerabilities are not simulated, and are instead delivered through hardened real security vulnerabilities that can not be abused to compromise the application or its environment. Many of these levels include insufficient protections to these vulnerabilities, such as black list filters and poor security configuration.<br /> <br /> ===CTF Mode===<br /> Security Shepherd can be morphed into a CTF server by an administrator with the click of a button. This presents users with one module at a time. They must complete their current level before they can continue. Administrators can also set a &quot;Module Block&quot; that prevents users from progressing past a certain level. It is also possible to run a CTF in a Tournament mode where a user can complete any module in any order they wish. When either of these modes are enabled, the scoreboard is then available. The scoreboard updates automatically and reflects the bonus points users achieve by completing a module first, second or third.<br /> <br /> ===User Management===<br /> Security Shepherd includes a user friendly method of creating many users at a time for administrators, as well as an optional open registry system. Users' activities are logged allowing an administrator to gather real time data on who is connected to Security Shepherd and what their module progress is. This data can be mined to gather information on who was online, at what time and how much time has been actively spent on a challenge.<br /> <br /> ===Topic Coverage===<br /> The Security Shepherd project covers the following web application security topics;<br /> <br /> *[[Top_10_2010-A1|SQL Injection]]<br /> *[[Top_10_2010-A2|Cross Site Scripting]]<br /> *[[Top_10_2010-A3|Broken Authetication and Session Management]]<br /> *[[Top_10_2010-A5|Cross Site Rrequest Forgery]]<br /> *[[Top_10_2010-A4|Insecure Direct Object Reference]]<br /> *[[Top_10_2010-A7|Insecure Cryptographic Storage]]<br /> *[[Top_10_2010-A8|Failure to Restrict URL Access]]<br /> *[[Top_10_2010-A10|Unvalidated Redirects and Forwards]]<br /> *[[Top_10_2010-A9|Insufficient Transport Layer Security]]<br /> *[[Mobile_Top_10_2014-M2|Insecure Data Storage]]<br /> *[[Mobile_Top_10_2014-M7|Client Side Injection]]<br /> *[[Mobile_Top_10_2014-M10|Lack Of Binary Protections]]<br /> *[[Mobile_Top_10_2014-M4|Unintended Data Leakage]] <br /> *[[Mobile_Top_10_2014-M6|Broken crypto]]<br /> <br /> ==Download==<br /> <br /> You can download the Security Shepherd VM or Manual Installation Pack from [https://sourceforge.net/projects/owaspshepherd/files/ Source Forge].<br /> <br /> ==Releases==<br /> <br /> Security Shepherd has been designed with expansion in mind. The application's underlying architecture is composed of a secure core application and database server that depicts how the application runs. There is also an exposed application and database service that runs all of the server side vulnerability examples. If these services are compromised, the core service can continue to run unaffected.<br /> <br /> Security Shepherd is written in Java and is compiled in a web application archive (WAR) and therefore can be run on any platform with a Java virtual machine and a web application server like Tomcat. To eliminate tedious environment configuration; there is a Security Shepherd Virtual Machine. This environment includes Tomcat/MySQL servers pre-loaded with Security Shepherd. For those that prefer the path of higher resistance or want to build a dedicated Security Shepherd server, a manual pack is available for download as well.<br /> <br /> ===Security Shepherd v2.0 VM Setup:===<br /> To get a Security Shepherd VM ready to rock, follow these steps;<br /> <br /> Setting up your instance of Security Shepherd with the VM: In Steps!<br /> <br /> * Import the VM to your hyper visor (Eg: Virtual Box)<br /> * Make sure the VM has a bridged adapter<br /> * Boot the VM<br /> * Sign in with securityshepherd / owaspSecurityShepherd<br /> * Change the user password with the passwd command<br /> * In the VM, run &quot;ifconfig&quot; to find the IP address. Make note of this<br /> * On your host machine, open http://&lt;VM IP Address&gt;/<br /> * Sign in with admin / password<br /> * Change the admin password (cannot be password again)<br /> * Use the configuration menu in the home page to change the application address from http://127.0.0.1/ to http://&lt;VM IP Address&gt;/<br /> * Time to play!<br /> <br /> ===Security Shepherd v2.0 Manual Pack:===<br /> The manual release is a single download, unrar, and follow the steps release. <br /> * Download the Security Shepherd Manual Pack<br /> * Install Apache Tomcat 7<br /> * Install MySql, using the default password (Contained in readme.txt) to skip future steps, if you prefer your own password go ahead and set-up MySql with that instead!<br /> * Extract the Security Shepherd Manual Pack<br /> * Copy the sql files extracted from the pack to the bin directory of MySql<br /> * Open MySql from the command line (eg: mySqlBinDirectory/mysql -u root -p ) <br /> * Type the following commands to execute the Shepherd Manual Pack SQL files;<br /> <br /> source core.sql<br /> source exposedSchema.sql<br /> <br /> * Open the webapps directory of your Tomcat instance<br /> * Delete any directories that are there already<br /> * Move the WAR files from the Shepherd Manual Pack into the webapps folder of Tomcat<br /> * Start Tomcat<br /> * Open the temp directory of Tomcat<br /> * If you chose the default when configuring MySql as your DB password, you are running MySql on the same machine as Tomcat and you are using port 3306 for MySql, you can skip this step. Otherwise, in the temp directory, in both the ROOT and Exposed directories in the temp folder, modify the /WEB-INF/site.properties to point at your local DB with your MySql settings. Leave the Driver alone!<br /> * If you have more than one ROOT or Exposed folder in your temp folder, visit your Tomcat instance with your browser and then check the Tomcat logs for a line that reads &quot;Servlet root =&quot; to find which directory is the correct one to modify the MySql settings of.<br /> * Open your the root context of your Tomcat server (eg: http://127.0.0.1:8080/ )<br /> * Sign into Security Shepherd with the default admin credentials (admin / password)<br /> * Change the admin password<br /> * Follow in application prompts for further configuration<br /> <br /> == Future Development ==<br /> <br /> New levels or level ideas are wanted in the highest degree and there is development is in progress to fork the Security Shepherd platform into a CTF framework. If you wish to contribute a level or even an idea; contact Mark Denihan on mark.denihan@owasp.org.<br /> <br /> The aim of Security Shepherd's future development is to create a comprehensive platform for web and mobile application pen testing training / security risk education.<br /> Check out the project [https://www.owasp.org/index.php/Projects/OWASP_Security_Shepherd/Roadmap roadmap] and find some tasks that you can help with right away..<br /> <br /> To contribute right away, pull the source from [http://bit.ly/securityShepherdGithub GitHub]<br /> <br /> == Events with Security Shepherd ==<br /> [[Image:Shepherd-CTF-In-Play.JPG|thumb|300px|right|Over 60 people playing the CTF at [[HackDub2012]]]]<br /> <br /> The Security Shepherd application has been tried and tested across a number of Beta runs in venues like Facebook and the IRISScon CTF. Since these events Security Shepherd has been knocking on security doors trying to be recognized as the new platform for web application security training. <br /> <br /> * Security Shepherd was used as the [[HackDub2012|OWASP Dublin Hackathon 2012]]<br /> * Security Shepherd's platform was used be used to manage the [[AppSecIreland2012| OWASP Ireland AppSec 2012]] CTF in September 2012<br /> * Security Shepherd's platform was used to administer the Traditional Style CTF at the IRISS security conference in October 2012 and 2013<br /> * Security Shepherd's platform was used to deliver the Traditional Style CTF at the 2013 SOURCE Conference CTF in Facebook<br /> * Security Shepherd's platform was used to govern the EU Tour 2013 and LATAM Tour 2013 Online CTF's<br /> * Security Shepherd's platform was used to conduct the 2013 OWASP Global CTF<br /> * Security Shepherd was used as the 2014 OWASP application security summer school CTF at the Faculty of Organization and Informatics in Varaždin<br /> <br /> == Project Contributors ==<br /> <br /> The Security Shepherd project was founded and is ran by Mark Denihan. The mobile wing of Security Shepherd is lead by Sean Duggan. If you wish to contribute to the OWASP Security Shepherd project please contact at mark.denihan@owasp.org, as help in any regard of the application is very much appreciated. Security Shepherd distributions are currently maintained on [http://bit.ly/shepherdSourceForge SourceForge]. The Security Shepherd template makes it extremely easy to add additional lessons. We are actively seeking developers to add new lessons as new web technologies emerge. If you are interested in volunteering for the project, or have a comment, question, or suggestion, please join the Security Shepherd [https://lists.owasp.org/mailman/listinfo/owasp_security_shepherd mailing list].<br /> <br /> Both the Security Shepherd Platform and the Mobile Shepherd aspects of this project were initially created as part of BSc degrees in the Dublin Institute of Technology. Thanks to [http://www.dit.ie DIT] for allowing those projects to be donated to the OWASP community.<br /> <br /> == Project Sponsors ==<br /> <br /> The OWASP Security Shepherd project would like to acknowledge and thank the generous support of our sponsors. Please be certain to visit their stall at the [http://bit.ly/AppSecEu2014|OWASP AppSec EU 2014] conference as well as follow them on [http://bit.ly/bccRiskAdvisory Twitter]. <br /> [[File:BccRiskAdvisoryLogo.jpg]][[File:EdgescanLogo.jpg]]<br /> <br /> [[Category:OWASP Project|Security Shepherd Project]]<br /> [[Category:OWASP Download]]<br /> [[Category:OWASP Tool]]<br /> [[Category:OWASP Release Quality Tool]]<br /> <br /> __NOTOC__<br /> <br /> [[Category:OWASP Project]]</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=User:Tonimir_Kisasondi&diff=175136 2014-05-16T12:46:37Z

<p>Tonimir Kisasondi: </p> <hr /> <div>Tonimir Kišasondi, PhD, EUCIP<br /> <br /> Researcher @ Faculty of organization and informatics, Varazdin ([http://www.foi.hr http://www.foi.hr])<br /> Head of Open Systems and Security Laboratory<br /> OWASP educational leader, Croatia @ FOI<br /> <br /> <br /> Page: [http://www.foi.hr/djelatnici/tonimir.kisasondi/(language)/cro-HR http://www.foi.hr/djelatnici/tonimir.kisasondi/(language)/cro-HR]<br /> <br /> Twitter: [http://twitter.com/#!/kisasondi http://twitter.com/#!/kisasondi]<br /> <br /> <br /> <br /> <br /> pgp: 0x00C68442<br /> <br /> pgpid: 77FCA8315CE34BCFB1C01B0CF1D9B3A200C68442</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=Croatia&diff=114079 2011-07-18T09:38:32Z

<p>Tonimir Kisasondi: </p> <hr /> <div>{{Chapter Template|chaptername=Croatia|extra=The chapter leader is [mailto:vlatko.kosturjak@owasp.org Vlatko Kosturjak] Educational leader: [mailto:tonimir.kisasondi@owasp.org Tonimir Kisasondi]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Croatia|emailarchives=http://lists.owasp.org/pipermail/owasp-croatia/}}<br /> ==== Local News ====<br /> &lt;paypal&gt;Croatia&lt;/paypal&gt;<br /> <br /> Welcome. We're just starting organizing things here. You're invited to subscribe to the mailing list for up2date news and also if you want help in <br /> organizing local chapter. Everyone is welcome to join us at our chapter meetings. <br /> <br /> ==== Chapter Meetings ====<br /> '''Regular Meeting Location''': CARNet CERT, Ulica Josipa Marohnića 5, 10000 Zagreb, Hrvatska<br /> <br /> '''Next meeting''': OWASP round table/meetup in 22.9.2011 @ FOI security conference, More information soon <br /> <br /> <br /> <br /> ==== Croatia OWASP Chapter Leaders ====<br /> The chapter leader is [mailto:vlatko.kosturjak@owasp.org Vlatko Kosturjak]<br /> <br /> Educational leader: [mailto:tonimir.kisasondi@owasp.org Tonimir Kisasondi]<br /> __NOTOC__<br /> &lt;headertabs/&gt;<br /> [[Category:OWASP Chapter]]<br /> [[Category:Europe]]</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=Croatia&diff=114078 2011-07-18T09:37:39Z

<p>Tonimir Kisasondi: </p> <hr /> <div>{{Chapter Template|chaptername=Croatia|extra=The chapter leader is [mailto:vlatko.kosturjak@owasp.org Vlatko Kosturjak] Educational leader: [mailto:tonimir.kisasondi@owasp.org Tonimir Kisasondi]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Croatia|emailarchives=http://lists.owasp.org/pipermail/owasp-croatia/}}<br /> ==== Local News ====<br /> &lt;paypal&gt;Croatia&lt;/paypal&gt;<br /> <br /> Welcome. We're just starting organizing things here. You're invited to subscribe to the mailing list for up2date news and also if you want help in <br /> organizing local chapter. Everyone is welcome to join us at our chapter meetings. <br /> <br /> ==== Chapter Meetings ====<br /> '''Regular Meeting Location''': CARNet CERT, Ulica Josipa Marohnića 5, 10000 Zagreb, Hrvatska<br /> <br /> '''Next meeting''': 23th of January, 2009 at Barcamp Zagreb, FER, Unska 3, 10000 Zagreb <br /> <br /> OWASP round table/meetup in 22.9.2011 @ FOI security conference, More information soon<br /> <br /> ==== Croatia OWASP Chapter Leaders ====<br /> The chapter leader is [mailto:vlatko.kosturjak@owasp.org Vlatko Kosturjak]<br /> <br /> Educational leader: [mailto:tonimir.kisasondi@owasp.org Tonimir Kisasondi]<br /> __NOTOC__<br /> &lt;headertabs/&gt;<br /> [[Category:OWASP Chapter]]<br /> [[Category:Europe]]</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=Croatia&diff=114077 2011-07-18T09:31:16Z

<p>Tonimir Kisasondi: </p> <hr /> <div>{{Chapter Template|chaptername=Croatia|extra=The chapter leader is [mailto:vlatko.kosturjak@owasp.org Vlatko Kosturjak] Educational leader: [mailto:tonimir.kisasondi@owasp.org Tonimir Kisasondi]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Croatia|emailarchives=http://lists.owasp.org/pipermail/owasp-croatia/}}<br /> ==== Local News ====<br /> &lt;paypal&gt;Croatia&lt;/paypal&gt;<br /> <br /> Welcome. We're just starting organizing things here. You're invited to subscribe to the mailing list for up2date news and also if you want help in <br /> organizing local chapter. Everyone is welcome to join us at our chapter meetings. <br /> <br /> ==== Chapter Meetings ====<br /> '''Regular Meeting Location''': CARNet CERT, Ulica Josipa Marohnića 5, 10000 Zagreb, Hrvatska<br /> <br /> '''Next meeting''': 23th of January, 2009 at Barcamp Zagreb, FER, Unska 3, 10000 Zagreb <br /> <br /> ==== Croatia OWASP Chapter Leaders ====<br /> The chapter leader is [mailto:vlatko.kosturjak@owasp.org Vlatko Kosturjak]<br /> <br /> Educational leader: [mailto:tonimir.kisasondi@owasp.org Tonimir Kisasondi]<br /> __NOTOC__<br /> &lt;headertabs/&gt;<br /> [[Category:OWASP Chapter]]<br /> [[Category:Europe]]</div>

Tonimir Kisasondi https://wiki.owasp.org/index.php?title=User:Tonimir_Kisasondi&diff=114076 2011-07-18T08:57:59Z

<p>Tonimir Kisasondi: </p> <hr /> <div>Tonimir Kišasondi, MSc, EUCIP<br /> <br /> Junior Researcher @ Faculty of organization and informatics, Varazdin ([http://www.foi.hr http://www.foi.hr])<br /> <br /> OWASP educational leader, Croatia @ FOI<br /> <br /> <br /> <br /> <br /> Page: [http://www.foi.hr/djelatnici/tonimir.kisasondi/(language)/cro-HR http://www.foi.hr/djelatnici/tonimir.kisasondi/(language)/cro-HR]<br /> <br /> Twitter: [http://twitter.com/#!/kisasondi http://twitter.com/#!/kisasondi]<br /> <br /> <br /> <br /> <br /> pgp: 0x00C68442<br /> <br /> pgpid: 77FCA8315CE34BCFB1C01B0CF1D9B3A200C68442</div>

Tonimir Kisasondi