OWASP Education Presentation - Revision history

Bjoern Kimminich: /* OWASP Education Presentations */

2018-06-08T09:36:26Z

‎OWASP Education Presentations

Bjoern Kimminich: /* OWASP Education Presentations */

2018-06-08T09:36:07Z

‎OWASP Education Presentations

Bjoern Kimminich at 09:35, 8 June 2018

2018-06-08T09:35:39Z

Jsokol: Updated link to current training slides.

2017-10-28T22:26:29Z

Updated link to current training slides.

Timo Pagel: Add Security in DevOps

2017-09-29T14:35:54Z

Add Security in DevOps

Timo Pagel: Add Docker Security Workshop

2017-09-08T17:10:55Z

Add Docker Security Workshop

Timo Pagel: Add University Module "Security in Webapplication"

2017-04-25T16:18:28Z

Add University Module "Security in Webapplication"

Show changes

Mtesauro: Removing bad category

2017-02-10T17:15:30Z

Removing bad category

Jsokol: /* OWASP Education Presentations */

2016-03-10T22:08:11Z

‎OWASP Education Presentations

Timo.goosen: /* Chapter Presentations */

2015-07-16T14:31:59Z

‎Chapter Presentations

@@ Line 17: / Line 17: @@
 ! width="15%" |Level
 ! width="15%" |Date (2015-07-04)
 |-
 |[https://docs.google.com/presentation/d/1M4cx_zVFN7WCKybV2c7c8L0QG9gP5z78JAIELRhkVkg/edit?usp=sharing Security in DevOps-Strategies]
@@ Line 22: / Line 27: @@
 |Intermediate
 |2017-09-29
 |-
 |[https://docs.google.com/presentation/d/1SWCyscCQ0YGW3_Y6vCwI4ZY_Q5-TOQ-eoVZaT6qwofc/edit?usp=sharing Docker Security Workshop]

@@ Line 23: / Line 23: @@
 |2017-09-29
 |-
-|[https://github.com/bkimminich/it-security-lecture]
+|[https://github.com/bkimminich/it-security-lecture IT Security Lecture]
 |University lecture on "IT Security" as Open Educational Resources material by Björn Kimminich ''(work in progress)''
 |Novice

@@ Line 22: / Line 22: @@
 |Intermediate
 |2017-09-29
 |-
 |[https://docs.google.com/presentation/d/1SWCyscCQ0YGW3_Y6vCwI4ZY_Q5-TOQ-eoVZaT6qwofc/edit?usp=sharing Docker Security Workshop]

@@ Line 33: / Line 33: @@
 |2017-04-25
 |- valign="top"
-|[https://www.owasp.org/images/f/f2/LASCON_2015_-_Web_Application_Developer_Security_Training.pptx Web Application Developer Security Training]|| Secure Web App Development course by [[user:Jsokol | Josh Sokol]], [[user:Dancornell | Dan Cornell]] || Novice || 2015-10-21
+|[https://www.dropbox.com/s/17392fqn5osbpfu/OWASP%20-%20Web%20Application%20Developer%20Security%20Training.pdf?dl=0 Web Application Developer Security Training]|| Secure Web App Development course by [[user:Jsokol | Josh Sokol]], [[user:Dancornell | Dan Cornell]] || Novice || 2015-10-21
 |- valign="top"
 |[https://www.owasp.org/index.php/Education/Free_Training Free Developer Training]|| Developer AppSec Course by [[Eoin Keary]] and [https://www.owasp.org/index.php/User:Jmanico Jim Manico] || Intermediate || 2014-04-04

@@ Line 17: / Line 17: @@
 ! width="15%" |Level
 ! width="15%" |Date (2015-07-04)
 |-
 |[https://docs.google.com/presentation/d/1SWCyscCQ0YGW3_Y6vCwI4ZY_Q5-TOQ-eoVZaT6qwofc/edit?usp=sharing Docker Security Workshop]

@@ Line 296: / Line 296: @@
 [[Category:OWASP Education Project]]
 [[Category:OWASP Presentations]]
 [[Category:Chapter Resources]]

@@ Line 17: / Line 17: @@
 !width="15%" |Level
 !width="15%" |Date (2015-07-04)
 |-valign="top"
 |[https://www.owasp.org/index.php/Education/Free_Training Free Developer Training]|| Developer AppSec Course by [[Eoin Keary]] and [https://www.owasp.org/index.php/User:Jmanico Jim Manico] || Intermediate || 2014-04-04

← Older revision		Revision as of 14:31, 16 July 2015
Line 291:		Line 291:
	\|-valign="top"		\|-valign="top"

−	~~\|(https://www.owasp.org/index.php/User_talk:Briechenstein_Software_Studio) \|\| Open Web application Security Project\|\| Intermediate\|\| 2015-07-04 \|\|~~
−
−	~~Chapter 4~~
−
−	~~Specification Language~~
−
−	This formal specification by language example presents cybersecurity studies (of over 10 projects) of how successful OWASP educational presentations test develop design and deliver cybersecurity software efficiently supporting formal methods as mathematically based techniquesthat are needed to assist in the design and implementation of reliable cybersecurity software.
−
−	Specification by language example is a must read for anyone serious about delivering translated cybersecurity language software that matters It is the result of a research on how teams internationally specify test develop design and deliver the right cybersecurity software without defects in very short computational delivery cycles With cybersecurity case studies and real examples this presentation helps you understand how successful teams implement mathematical cybersecurity by example denoting
−	acceptable testing and behavior driven development to bridge the communication gap between committees stakeholders and contributing teams build quality into cybersecurity from the start by testing developing designing and delivering supported languagfor syntax highlighting purposes It presents the collective knowledge of about 50 cybersecurity projects ranging from high traffic websites to virtual back office cybersecurity systems implemented by teams as diverse as small startups to groups spread across different continents working in a range of processes including Extreme programming Kanban Scrum and similar processes often bundled together under the names Lean and Agile This protocol is for testers software developers business analysts and project managers working on Syntax and Agile projects or teams moving to an Agile development method that want to improve quality reduce correction of defective cybersecurity software and collaborate better with the OWASP committee.
−	~~Smith~~
−
−
−
−	*Retrieved notes from Categories Specification languages and Formal specification
−	For the last past decade computer systems have become increasingly more powerful as a result becoming more impactful to society Established engineering disciplines use mathematical analysis as the foundation of creating and validating product design Formal language specifications are one im such a way for achievement in software engineering as reliability once predicted Other methods such as testing are more commonly used to enhance code quality
−
−	Usability given as such a specification it is possible to use formal verification techniques to demonstrate that a system design is correct with respect to its specification This allows incorrect system designs to be revised before any major investments have been made into an actual implementation Another approach is to use provably correct refinement steps to transform a specification into a design which is ultimately transformed into an implementation that is correct by construction.
−
−	*It is important to note that a formal specification is not an implementation but rather it may be used to develop an implementation Formal specifications describe what a system should do not how the system should do it A good specification must have some of the following attributes: adequate internally consistent unambiguous complete satisfied constructability manageability and evolvability Usability Communicability Powerful and efficient analysis which is one of the main reasons there is interest in formal specifications that will provide an ability to perform proofs on cybersecurity software implementations These proofs may be used to validate a specification verify correctness of design, or to prove that a program satisfies a specification.
−
−	~~Limitations~~
−	A design (or implementation) cannot ever be declared “correct” on its own. It can only ever be “corrected with respect to a given specification Whether the formal specification correctly describes the problem to be solved is a separate issue It is also a difficult issue to address since it ultimately concerns the problem constructing abstracted formal representations of an informal concrete problem domain and such an abstraction step is not amenable to formal proof. However, it is possible to validate a specification by proving “challenge” theorems concerning properties that the specification is expected to exhibit.o_O If correct Olloclip In these theorems reinforce the specifier's understanding of the specification and its relationship with the underlying problem domain If not the specification probably needs to be changed to better reflect the domain understanding of those involved with producing (and implementing) the specification.
−
−
−
−
−	~~Flexibility~~
−	As far as flexibility goes a lot of software companies use agile methodologies that focus on flexibility Doing a formal specification of the whole system up front is often perceived as being the opposite of flexible However there is some research into the benefits of using formal specifications with "agile" development
−	~~Complexity is a requirement that is a high level of mathematical expertise and the analytical skills to understand and apply them effectively~~
−	~~I have a solution to develop resources and models that allow for these techniques to be implemented but hide underlying mathematics~~
−
−
−	~~I hope to accomplish a good job of specifying user interfaces and user interaction that is Not cost-effective~~
−
−
−
−
−
−	Formal specification techniques have existed in various domains and on various scales for quite some time Implementations of formal specifications will differ depending on what kind of system they are attempting to model how they are applied and at what point in the software life cycle they have been introduced These types of models can be categorized into the following specification paradigms:
−
−
−	~~History-based specification~~
−
−	~~behavior based system histories~~
−	~~assertions are interpreted over time~~
−	~~State-based Specification~~
−	~~behavior based on system states~~
−	~~series of sequential steps (e.g. a financial transaction)~~
−	~~languages such as Z, VDM or B rely on this paradigm+~~
−	~~Transition-based specification~~
−	~~behavior based on transitions from state-to-state of the system~~
−	~~best used with a reactive system~~
−	~~languages such as Statecharts PROMELA STeP-SPL RSML or SCR rely on this paradigm~~
−	~~Functional specification~~
−	~~specify a system as a structure of mathematical functions~~
−	~~OBJ, ASL, PLUSS, LARCH, HOL or PVS rely on this paradigm~~
−	~~Operational Specification~~
−	~~early languages such as Paisley GIST Petri nets or process algebras rely on this paradigm~~
−	In addition to the above paradigms there are ways to apply certain heuristics to help improve the creation of these specifications The protocol referenced here best discusses heuristics to use when designing a specification.Heuristics= a rule or method that helps you solve problems faster than you would if you did all the computing
−
−
−
−	~~Resources:~~
−	~~Algebraic specification= Providing a mathematical software engineering technique~~
−
−
−	~~References:~~
−	^ a b c d e f g h i j k l m n o Lamsweerde, A. V. (2000). "Formal specification". Proceedings of the conference on the future of Software engineering - ICSE '00. p. 147. doi:10.1145/336512.336546. ISBN
−	~~^ a b c d Sommerville, Ian (2009). "Formal Specification" (PDF). Software Engineering. Retrieved~~
−	^ a b c Nummenmaa, Timo; Tiensuu, Aleksi; Berki, Eleni; Mikkonen, Tommi; Kuittinen, Jussi; Kultima, Annakaisa (4 August 2011). "Supporting agile development by facilitating natural user interaction with executable formal specifications". ACM SIGSOFT Software Engineering Notes 36 (4): 1–10. doi:10.1145/1988997.2003643. edit
−
−
−
−	~~Best Wishes,~~
−	~~Brenda Smith~~
−	~~a55dayidream@gmail.com~~