Let’s face the reality: constrained by
resources, many software developers ignore security entirely until they face an
incident, or are tackling security by just focusing on the options they think
to be the cheapest – which usually means just going through a checklist for
finding some of the most common problems. But is this really the cheapest
option? Just think about it: How much does it cost if the news are full of your
device being broken or website being hacked again?
To date the software development community
has learned the lesson: security started to be interwoven in the whole of the
product development lifecycle. But do not forget: while – in theory – engineers
have to be vigilant, eliminating every single bug in the code to make a product
secure, for an intelligent attacker it is enough to find a single remaining
vulnerability in a rarely-used module to use it as a vehicle for committing
cyber-crime.
During the 2000’s the software industry
started to realize the fact that in the long run, investing in their own
employees is the most effective way of doing
security. Training became the
key initial phase in the Microsoft Security Development Lifecycle, and
is also a standard practice within the Building Security in Maturity Model followed
by many. Companies started to reserve more and more from their security budget
to educate their employees, as education
tackles the problem of security right at its source: the engineer.
But, just as we can’t put a policeman on
every corner, assigning a dedicated security expert to a development group is
not enough (still better though than not doing anything at all). Usually a
single small mistake committed by one of the engineers is the root cause of a
complete system compromise, and so the overall average preparedness of all involved
software architects, programmers and testers is the one that actually counts.
From project
management point of view, it is an easy formula: your engineers work hard each
day, and produce vulnerable code, resulting in hundreds of security bugs
yearly…
…to test
…to find
…and to correct.
OR
You can send those programmers to a secure
coding training, and they’ll start to write secure code from their next working
day. The
choice is yours.
A special prudence is needed however to
teach security practices to software engineers: the trainer should not only be
an experienced software developer, but also has to have strong security
expertise. The courses should be practical but still go into enough theoretical
details; shown problems should be supported by exercises giving hands-on
experience, otherwise developers will forget most of the issues the next day;
and classes should be intensive so they don’t pull away people from their
everyday work for too long.
Our Secure Coding courses were formed based on a decade long expertise
in product security and security research. In this sense with our courses we teach what we
do. With a track record of thousands of attendees worldwide, the
trainings in our portfolio are specifically prepared to serve diverse
development groups of large companies developing any kind of software.
About Ernő Jeges - Instructor at Informator
Ernő has been a software developer ever since
his childhood, working in the area of product security and security research
for nearly fifteen years now. He has actively taken part in the elaboration of
all course materials of SCADEMY Secure Coding Academy, and is the leading
trainer with several years of teaching experience in both academic and
industrial domain; he has held numerous secure coding courses for leading
software developing companies all over North America, Europe, Africa and Asia.
