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):
Design and Components
The new tool will deal with Active Directory security so it has to integrate
into large scale Windows based customer environments, which in turn makes the
decision about the components quite easy ;-). We have chosen .NET as our primary
development platform including key components from Microsoft to run our
application, these components include the IIS and Microsoft SQL Express/Server
and of course one Windows Server.
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 ;-).
Confucius said: “The man who moves a mountain begins by carrying away small
stones” and that’s our way to go. It is not about building error free or
unbreakable software, it is about changing the way how software is built today,
about improving security and about raising the bar.
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.
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.
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.
