SDLC – Insinuator.net

April 30, 2018 by Michael Thumann

printf(“Hello World!”) Part 2

As our journey to the new product continues we are facing the typical challenges of phase 2 in the software development life cycle, the design phase (see part 1 for the overview of the phases):

Continue reading “printf(“Hello World!”) Part 2″

Building

February 23, 2018 by Michael Thumann

ERNW has a new baby, so please say “hello” to the new ERNW SecTools GmbH ;-).
But why another ERNW company? Short answer: Because we want to contribute to changing the way how software is built today: insecure, focused on profit and sometimes made by people who ignore lessons from history. So how can we contribute in this space? Start changing it ;-).

Continue reading “printf(“Hello World!”)”

Events

March 31, 2016 by Sven Nobis

Towards a LangSec-aware SDLC

At the TROOPERS’15 Jacob l. Torrey held a track about LangSec-Aware Software Development Lifecycle. He talked about programming conventions and what tools can be used for enforcing the compliance. There is a lack of metrics to understand what make software more secure or less secure. His main goals was to show that LangSec has far-reaching impacts into software security and to give the audience a framework to transform the theory into practice. A SLDC should help to find bugs sooner in the development process and reduce defect rate in production thereby. A lower defect rate in production does not only improve security it also reduces costs.

Continue reading “Towards a LangSec-aware SDLC”

Breaking

September 24, 2010 by Michael Thumann

Back to the roots

Finding exploitable vulnerabilities is getting harder. This statement of Dennis Fisher published on Kaspersky’s Threatpost blog summarizes a trend in the development lifecycle of software . The last published vulnerabilities that were gaining some attention in the public had all one thing in common, they were quite hard to exploit. The so called jailbreakme vulnerability was based on several different vulnerabilities that had to be chained together to break out of the iPhone sandbox, escalate its privileges and run arbitrary code. Modern software and especially modern operating systems are more secure, they contain less software flaws and more protection features that make reliable exploitation a big problem that can only be solved by very skilled hackers. Decades ago it was just like this, but intelligent tools and sharing of the needed knowledge enabled even low skilled people to develop working exploits and attack vulnerable systems. Nowadays we are going back to the roots where only a few very knowledgeable people are able to circumvent modern security controls, but that doesn’t mean that all problems are gone. Attackers are moving to design flaws like the DLL highjacking problem, so only the class of attacks is changing from the old school memory corruption vulnerabilities to logical flaws that still can be exploited easily. But the number of exploitable vulnerabilities is decreasing, so this might be a sign that we are on the right way to develop reliable and secure systems and that developing companies are adopting Microsofts Secure Development Lifecycle (SDL) to produce more secure software. As stated in my previous blogpost the protection features are available, but not used very often. But if they are used and if the developers are strictly following the recommendations of the SDL, this trend of “harder to exploit vulnerabilities” proves that it can be a success story to do so.

Have a bug-free day 😉
Michael

Building

July 21, 2010 by Michael Thumann

Software Developers Don’t Use Available Security Features

According to SANS NewsBites Vol. XII, Issue 53 recently published there’s a lack of 3rd party developer support for some security features Microsoft introduced already years ago. We at ERNW have made similar observations when performing security assessments of COTS [commercial off-the-shelf] software. We therefore created a methodology, a proof of concept tool and a metric to test and to rate closed source software, where (amongst other approaches) these security features are checked and their (non-) presence contributes to an overall evaluation as for the trustworthiness of the applications in question. The concept “How to rate the security in closed source software” was presented to the public at Troopers10 and at Hack in the Box 2010 in Amsterdam. The slides can be found here.