Enseñar sobre desarrollo seguro

Un debate interesante en QoTW #43: Teaching a loved one about secure coding practices: ¿En qué momento del aprendizaje debemos pasar del ‘funciona’ a ‘es difícil que falle, incluso en malas condiciones’?

Y empezamos con algo que creo que no hacemos bien del todo: cuando enseñamos no tenemos en cuenta la seguridad (ni la robustez en muchos casos):

The very first link points towards w3schools.com.

A quick browse through the site looks good. Nice, simple, easy to follow tutorials on the basics of PHP and HTML. Wait, are they really teaching unparameterized queries? In 2013? Really? I’d like to point you to this website. In particular, this quote.

Alguna respuesta interesante, si aprendemos mal luego tendremos que ‘desaprender’:

The problem I see, is that secure programming is taught as an add on. Best practices should be taught from the beginning (including security). The lie people are taught is that practice makes perfect. The truth is practice makes permanent. So if you are doing it wrong, you have to unlearn what you have learned. That is a bassackwards approach. I would say that secure coding practices should be taught from day one. There’s no reason to learn how to do it, and then learn how to do it securely. It’s a waste of time and money…

Pero claro, cuando enseñamos necesitamos cierta ‘tranquilidad’ para poder mostrar los conceptos sin excesiva sobregarca:

It’s great to say “Secure coding practices should be taught from day one”, and very hard to demonstrate how that day-one “Hello World” program may be vulnerable, especially when “what is a computer program” is a new concept for the class.

Un camino, una vez que hayamos empezado:

Once a flaw has been found, have her rewrite the application to fix the flaw. Doing so will allow her to appreciate the effect of things like sanitation and validation of user inputs and parameterized queries. Take incremental steps. I wouldn’t jump straight into designing a new application with security in mind before truly understanding what type of codes result in security flaws.

El hilo original estaba en Teaching a loved one about secure coding practices.

Anuncios

Algo de historia de la enseñanza en informática

Nos desviamos un poco de los temas habituales para señalar otros que también nos gustan: The Evolution of the Computer Science Degree. Un poco de historia sobre la enseñanza en informática.

Los primeros pasos.

By 1962, the ACM had established a curriculum committee to set out standards for the new field (a panel discussion on the topic, chaired by Forsythe, was held the previous year). In March of 1968, the ACM published the famous “Curriculum 1968,” its recommendations for computer science programs. There was some urgency to the deliberations. According to Gupta, Thomas Keenan reminded his colleagues “that over 15,000 computers were in use at the time with a production rate of 500 computers a month.” Keenan was concerned that “the ability to build computers was outstripping the ability to educate people who could make intelligent use of the machines.”

Y sobre el campo:

Indeed, famously, in 1967, three of the field’s pioneers tried to answer the skeptics in a letter to Science. After giving a dead simple explanation, “Computer science is the study of computers,” they went on to detail answers to a half dozen objections by other academics.

Enseñar a engañar

En Teaching the Security Mindset la referencia a un artículo interesante: [PDF] Embracing the Kobayashi Maru: Why You Should Teach Your Students to Cheat.

En una clase de guerra cibernética (‘cyberwarfare’) la idea es que los estudiantes se enfrentarán a ‘malos’ que tratarán de engañarlos, así que no está mal que ellos adquieran esa mentalidad del mentiroso, que trata de hacer daño y saltarse las reglas.

Con ese objetivo, proponen un examen insuperable (aprenderse el número pi con 100 dígitos) para obligar a los estudiantes a hacer trampas y les avisan de que justamente eso es lo que se espera de ellos: que traten de aprobar sin conseguir los objetivos (que, por otra parte, eran muy difíciles por el camino del estudio).

… we informed the class that we had no expectation that they would actually memorize the digits of pi, we expected them to cheat.

Entre las tramas: diversas formas de copia, sustituir la hoja del examen e incluso (esta es creativa, pero seguro que funciona en más casos) la de aprenderse los diez primeros dígitos de pi y luego poner inventados, esperando que el profesor no lo comprobará).

Las estrategias pueden clasificarse en:

– Utilizar el entorno
– Utilizar la confianza
– Utilizar ventajas personales (una chuleta en chino mandarín).
– Utilizar las debilidades de los otros.
– Tener planes alternativos.

Si los estudiantes aprendieron no sólo lo que ellos hicieron, sino lo que hicieron los demás, parece una forma adecuada de configurar la mentalidad para el futuro.

Al final, la seguridad tiene que ver con estados mentales y estar atento a cosas que damos muchas veces por supuestas.

Formación en Ingeniería del Software

A pesar de que me dedico a ello, en esta bitácora no suelo hablar mucho de formación y enseñanza. En todo caso, vi If You’re Going to Teach an Undergrad Intro to Software Engineering… y pensé que aunque no es un tema de mi especialidad debería guardarlo en algún sitio. ¿Cuál mejor que este?

Además, me ha interesado que varias referencias tratan sobre desarrollo de software libre, lo que me parece un plus.

La recursividad no es difícil

En Stop Telling Students Recursion is Hard hacen un elogio de la recursividad y la explican com método de razonamiento para desarrollar programas y el pensamiento computacional.

Yo tampoco creo que sea difícil (es más, como dice el autor, ayuda a comprender algunas cosas y a hacerlas mejor aunque luego no se utilice) pero muchas veces chocamos con el pensamiento de los que están acostumbrados a otros paradigmas y la habitual resistencia a los cambios y novedades.

Un curso sobre Ingeniería del Software Seguro

El otro día nombraba de pasada mi asignatura sobre estos temas (las transparencias) y tenía reservada para comentar la página de Holger Peine sobre su curso de Secure Software Engineering. Se pueden descargas las transparencias y las he encontrado bastante útiles. Si alguien más gusta …