33C3 preroll music
basically textbooks have been written
about it countless talks have been
have been Illuminating all of the errors
of our ways and still all those sucky
software is out there but
Fefe over here the hero of our show
has put out has put all of these best
practices into you know into his work to
try to create a secure website he's
going to show us how it's done so that
we can all sleep way better at night and
with that template go back and
and secure our own software and so with
that I'm going to hand it right over to
Fefe give him a round of applause
Applause
thank you I have to start
with an apology because I did submit
this talk but it was rejected so the
slides are not at the stage where they
should be these are our slides for a
previous version of the talk it contains
all the material and I tried to update
it more but that destroyed the flow so
we we're stuck with it basically the
difference was the the audience so while
I expect more developers here the other
audience was more and hackers and
business people so I try to get them
from where they are and the main question
usually is "are we there yet?" right
so about me you probably
seen this before I'm a code auditor by
trade I have a small company and
companies show us their code and I show
them bugs I find in them quite easy
but before we start I have a small
celebration to do this actually happened
just a day before the first time I
talked about this so Kaspersky
message they found some malware introduced
tied to libc
which I have written so this is
like a
Applause
some of the malware people
know what's good
so basically the main question when I
talk to customers is we spend so much
money on this why isn't it working
and the answer is you're doing it wrong
so I will try to show now what exactly
is wrong
and there's a small preface here people
usually say there's no time to do this
right and that's just wrong you have
exactly as much time per day as other
people who did great things so you can
do great things too you just need to do it
so let's play a little warm-up game
it's called how it started and how
it's going so let's have a demo round
IBM Watson is revolutionizing
10 Industries and it's going like this
whatever happened to IBM Watson that's a
typical pattern in the security industry
right so here's another one how it started
revolutionize security with AI
right we all know where this is going
Laugther
right so that's the pattern
let's play IT security mine sweeper
right so everybody here probably
knows who Gartner is they publish
recommendations and they even have a
voting section where people can say
this is the best product in this section
right so let's look at a few of them and
see what happened to people who trusted
Gartner
first is a firewall right so how
it started the number one recommendation
is for Fortinet and they have a lot of
marketing gibberish
Laughter
and if you look how it's going it's not
going so good
so let's extend the pattern a bit
why what happened to me in this regard
so I don't need a firewall
I don't have any ports open that I need
blocking right
so you don't need this
strictly speaking you don't need it
next discipline endpoint protection
so it started with Trellix this is the
number one recommendation on Gartner
I hadn't heard of them there like can make
a feed joint venture or something
who cares
they also have great marketing gibberish
and then if you look at what happened
it's like they made it worse
okay so this didn't apply to me
either because I don't use snake oil
let's see the third one password manager
also very popular
how it started recommended LastPass
you probably know where this is going
Laugther
yeah they got owned and then
people got owned
so you may notice a pattern here
this didn't apply to me because
I deserve a password authentication use
public key which has been available for
decades right so small bonus
the last one 2FA
Gartner recommends Duo which has
been bought by Cisco but doesn't matter
so if you look at what Duo does
your server asks the cloud for
permission the cloud goes to the telephone
telephone shows a popup you click yes
and then the cloud tells the server it's
okay you can let them in if you look
really closely you can notice the cloud
doesn't have to do the popup it can just
say sure so this comes pre-owned
there is no need to hack anything here
Laugther
and something many people don't
realize you don't need two factor
if you have public key that's already the
second factor
Okay, so
yeah let's skip over this briefly
Splunk is the the recommend option here
and they make the organization
more resilient unless you install it
Laughter
Applause
okay so this one is dear to my heart
because people start arguing about
whether to install patches and
which patch to install first and it used
to be simple you look for problems
then you install the patches and then
it got a bit more complicated and
the result is this right
that's a famous podcast in Germany
it's about municipality who got owned
by ransomware and then had to call the
army for help
inaudible chatter in crowd
and what you should do I'm having
this for completeness install all patches
immediately but that's a separate talk
right so you may notice a pattern here
the IT security industry
recommends something and
if you do it you're [ __ ] so don't do it
in case you can't read this says snake
repellent granules and then there's a
snake sleeping next to it
laugther
coughing
right so if we can't trust the
recommendations of the industry what
shall we do
and so I had a lot of
time on my hands because I didn't have
to clean up after crappy IT security
industry recommendations so what
what did I do with my time
and I decided I need a Blog
some time ago now and I started
thinking what do I need and it's
actually not that much I could have just
shown basically static content a little
search function would be good but it's
optional um I didn't need comments for
legal reasons because people start
posting like links to maware or
whatever I don't want that I don't
need that right so the first version was
actually really easy it was a small
standard web server and I had the
blog entries a static HTML files
one file per month it was actually really
easy if you want to search you just can
ask Google and limit it to my site so
posting was also easy had a little
script that I could run on the server
and I just SSH in and SSH I trust for
authentication so there's no new attack
surface I have that anyway and this is a
great design it's secure it's simple
there's low risk it's also high
performance but you couldn't do a talk
about it at the CCC right so
it's too boring so I started to introduce
risk in my setup
*laughter
so the first idea was I had
written a small web server I could just
implement the blog in the web server
because you know it's my code anyway
but that has downsides if the the blog
is running in the web server then it can
access all the memory of the web server
in particular it can see the TLS private
key and that I don't want people to
extract right so it can't be a module
in the web server
and the the obvious solution is
it has to run in a different user ID on
on Linux I'm using Linux or but any
Unix or Windows would be the same
basically it runs in a different user ID
and then if you if you take over the
process of the blog because there's some
bug in it you couldn't access the TLS
key and while I did that the industry
was doing this
chatter
that's like the running gag of this
talk I show all kinds of interesting
things the industry did and then show
what I did in that time right so
next question
where's the content I could just have
files on disk like static HTML as before
but I think that's not professional enough
right so for a good CCC talk you
need to be more professional
also for a different
project I had just written an LDAP server
so I decided to reuse it and
while I did that the industry did this
I took this photo at the airport of
Jerusalem so this is an actual ad it's
not photoshopped right it's for
Northrop Grumman which is a
military contractor and it's about full
spectrum cyber across all domains
chatter
so why would I write my own LDAP server
mostly because it's small and
because I'm an auditor by trade I know
that if you want a chance to actually
audit the code it needs to be small
because that's a limited resource
the time you can spend on auditing code
right so Postgres is a common SQL
database slapped in the the open LDAP
implementation of the server and tinyldap
is mine and you see it's much slower
and much smaller
yeah so there was more to this
ad campaign I collected a few funny images
right so um if someone manages to
hack the blog CGI or whatever module
I use to to have connect the blog to the
web server they can open any file that
the blog can read right the UID can read
so I should probably do something
about that that was the next step and
the industry was starting to think about
vulnerability management
so there is a mechanism on Unix
on Linux I did a separate talk about that
on the last Congress
it's called Seccomp and Seccomp it's like
a firewall for sys calls so I can use
Seccomp to block open the open sys which
is used to open files but if I have
to use open myself
then I can't block it right so what
to do about that for example my blog
calls local time which converts Unix's
time into the local time zone and for
that it opens a file containing the
description of the system time zone
and that calls open right so if
I just disabled the open system call from
my blog then it couldn't do the time
translation and this is actually
an old problem that also applies to set
ID programs and has has applied to them
for decades so what you can do is you
can reorganize your code so before you
block or before you drop privileges
generally speaking you do the open
calls in this in this example and
then you disable open and then you look
at the the data provided by the attacker
because if the attacker or any untrusted
source is trying to hack you it is via
data it gives you right it's
the environment is compromised so you look
at what kind of uh elements in the
environment are attacker supplied and
before you look at a single byte in them
you do all the dangerous stuff if you can
right so in this case I call local
time once before I drop the open sys call
and then my libc will cache the
time zone data and the next time I call it
after I have looked at the attacker
supplied code there is no need to call
open right so that's a major advantage
of Secom over similar Technologies like
SELinux where all the prohibitions
on sys calls are
applied to the whole process so there is
this is an example and you should make
use of it you should look at your
process and you can see if you have the
source code at least you can see which
parts do I need to do before I can drop
privileges and you move them up right so
that's what I did
this is actually a mockup from
the Estonian cyber security center
so this is real
okay so
next thought so let's
say someone hacks the blog module and
someone else uses the same module but
supplies a password right
this is a common problem in website
in websites there's some kind of login
something you get maybe a session token
or whatever and if someone manages to
take over the middleware
or like the server component
they can see all other connections too
if they are handled by the same
process right that's a major problem
and you can do something about it
so that's the good news here
and in my example it led to me using CGI
instead of fast CGI which is fast CGI
is a newer version of CGI
and the idea with fast CGI is that you
don't spawn a new process for every
request but you have like a Unix domain
socket or another socket to a fast CGI
process and that opens maybe a threat
per request or something but usually
in fast CGI you try to handle the
requests in the same process and then
you can use that process to cach data so
there's a perf advantage to using fast CGI
but for security reasons I don't
I don't use fast CGI so I can't do
caching right so that's a major downside
and you would expect the block to be
really really slow in the end so
first thing I need to use CGI instead of
fast CGI and secondly you could still
use debug APIs so if you use GDB or
another debugger to to look at another
process they use an API called ptrace
but that's a sys call so I can use seccomp
to disallow ptrace if I do those two
and the attacker takes over a blog process
all they can see is the data they supply
themselves right that's a major advantage
Okay so ENISA is actually an EU agency
which I find really disturbing
because they're burning lots of taxpayer
money anyway so let's assume the attacker
can hack my blog they can sill circumvent
any access control I do in the blog
so for example if I have an admin site
or some login site part of the webiste
and it's handled through the same program
and the access control is done in the blog
CGI and someone manages
to hack my blog CGI they could
just skip that so it's really hard
to do access restrictions that can be
circumvented if you do them in your own
code so the solution is not do it in
your own code I don't do any access
restriction in the blog I do it in the
LDAP server so if you connect to my blog
and supply a password then the blog
doesn't know if the password is
right or not there's an for example
there's an interface where you can add
new block entries or you can edit an old
one and for you need to supply
credentials but the block CGI doesn't know
if they are right or not it opens
the connections to the LDAP server with
that credential and then the LDAP server
says yes or no so since we removed
access to the ptraces calls and the
processes are isolated from each other
that means there is nothing to
circumvent here so if someone hacks my
blog the only advantage they get is
they can do the exact same stuff they
could do before basically they can just
talk to the LDAP server
okay so I'm starting to get into
James Bond territory here right
with the attacks they getting more
convoluted right so the industry started
doing threat intelligence feeds which
are useless don't spend money on those
okay so let's say the attacker hacked my
blog and then went to my tinyldap and now
is attacking tinyldap then they can
watch other logins because tinyldap
handles connections from other instances
of the blog too right so the same
problem we had before we just moved the
goal post a little and we need to
prevent this and the obvious solution
is to do the same thing we did
with the blog we have one process of
the LDAP server per request and then we
just allow ptrace right so now you
can't watch even if you get code execution
inside the LDAP server you can't watch
what passwords other people use
you can still see okay the industry
does some [ __ ] again you can still see
the password in the LDAP store right so
the LDAP server has to have a version of
the password to authenticate against and
the industry practice best practice is to
use salted hashes so the password is
not actually in the store
still if someone manages to attack
tinyldap through the blog they can
extract the hashes and try to crack them
but since I'm the only one adding users
I can control the password complexity so
good luck brute forcing that right
okay so this is actually a real problem
not for my blog specifically
but for other web services or services
that are reachable from the internet
what if an attacker doesn't want to steal
my data but it wants to encrypt it
so the ransomware what can you do
about that and my idea was to make
the data store read only so the UB
server has a data store that contains
all the blog entries and let's read only
to the add up process you can only read
from it and if you want to write to it
for example to add a new entry it gets
appended to a second file which I call
the
journal so SQL databases have a similar
concept and they use it to to roll back
transactions I can do the same thing
it's basically a log
file and that means um all the
differences from the last time the store
was created the Ron store all the
differences are sequentially in the log
file in the journal so that that the
performance gets worse the bigger the
journal gets so every now and then I
need to combine the readon part and the
journal to a new bigger readon part and
I do that
manually um because tiny elab couldn't
do it because I didn't allow tiny elab
to write the store right that was part
of the security here and uh so um with
set comp I can just disable whole CIS
calls I can also install filters so I
can say open is allowed but only if you
use o append o append in the open sis
call on Unix means every right you do to
this uh descriptor is automatically
added to the end so I know if someone
manages to to access the tiny Elda
binary and can write to my journal then
the only place the changes can show up
is at the end and that's actually a
really good good thing to have because
it means if someone hacks me and adds
junk to my blog I can only remove at the
end and I'm good again compare that to a
usual SQL database um if someone wrote
to the database you need to in to to
play a backup uh in to restore backup
because they could have changed anything
anywhere right so but tiny adup doesn't
even have file system level permissions
to change anything in the store so I can
re re uh sleep
soundly yeah the industry spent money on
cyber security mesh
architecture right so the journal
integration has to be done by me
manually out of band so it's not
something an automated process does um I
do it manually and when I'm doing it um
because it's not that much data it's
like for a week or two I can just read
it again and see if something doesn't
look
right this may not be available to all
other scenarios but uh you have to
realize if you have bigger data it's
usually not all the data that's big most
of it is usually static and readon and
then you have some logs that are or you
know billing data that grows and grows
but usually there's part of the data and
this is the the part with the you know
um uh identifying information personally
identifying information or you know Bill
billing details that stuff is usually
small and mostly static and you could
use this strategy for that
too well yeah
okay so the attack can still write
garbage to my blog that's still not good
right but since all they can do is a pen
to the journal I can use my text editor
open the journal and truncate at some
point and then I get all my data back
till the point where they started puting
the blog right this is still bad but
it's it's a very good position to be in
if there's an uh emergency because you
can basically investigate calmly first
you turn off right AIS then you you
delete the vandalism and the journal and
um you know you haven't lost anything
because if you want to delete an entry
in the blog you could do that too but
that means at the end of the journal you
append a statement saying delete this
record and I can just remove that and I
get the record back right so there's no
way for someone vandalizing my blog to U
damage any data that was in it before
all they can do is a pen junk at the end
and I can live with that right this is
this is should be the guiding thought
between any security you do um if
someone hacks you you will be in a very
stressful position the boss will be
behind you breathing down your neck are
We Done Yet is it fixed and you want to
have as little to do as possible at that
time you want to to move all the stress
to before you get hacked because then
you have more
time okay the industry did other things
again
um so what if the attacker doesn't write
garbage to the journal but writes some
exploit to the journal that the next
tiny El up instance that reads the
journal gets compromised
by that is a
possibility and that would be
bad so agreed that there still a problem
but uh realize how Preposterous the
scenario is so we are talking about an
attacker who found stable zero day in
the blog and then used that and another
stable zero day in tiny ad up to write
to the journal and then have the
third uh third zero day to compromise
the the journal passing code so I mean
yes it is still a problem but we reduced
the risk
significantly uh and that is what I'm
trying to to tell you here uh it's not
it's not all or nothing it's good enough
if you can half the
risk that's already very important and
you should do it so as much as you can
uh slice off the risk the better the
better off you will be if something
happens right because the smaller the
code is that is still attackable the
more you can audit it and be sure it's
good you show it to your friends and
they can audit it too uh and and you
need to save yourself that time because
it happens every now and then that I get
to get to see the whole code base and
the usual code base for commercial
products is like gigabytes of source
code nobody can read that like I'm I'm
good I'm not that
good so um this is a good place to be in
I think right so the industry was
selling dos mitigation sure whatever so
what happens if someone attacks the web
server that is still a big
problem um and it's
actually uh it it's a full damage right
that's the worst that can happen if
someone manages to attack the web server
they can see all traffic coming through
they can look inside TLS secured
connections and they can sniff all the
passwords so that's really
bad unfortunately there is not too much
you can do about that
um you could do uh um a separation so
this is something people have been
talking about for a while open S AG is
doing this they moved the dangerous
crypto stuff in a second process and use
sandboxing to lock down that process uh
that could be done but nobody has done
it for open SSL yet so so open SSL
doesn't support that um my web server
also supports embed TLS they don't
support that too so I I could spend time
on that and I've been actually um
spending some time already but it's not
it's not ready yet but this would be a
good way to reduce the risk and you may
notice that the the tools I'm using to
reduce risks are actually just a handful
there's not it's not you know it's not
witchcraft I'm I'm not inventing new
ways to look at things I'm doing the
same thing again I'm identifying the
part of the code that's dangerous and
then I think about how I can make that
part smaller maybe put it in a different
process lock it down so we need to do
the same thing with the web server
obviously um but it's an ongoing
process yeah so again whatever um why
haven't I done that yet uh so in my web
server you can it's a build time
decision if you want SSL support or not
and you can see the binary is
significantly bigger if you have SSL and
I'm showing you this because it means
the the bulk of the attack surface is
the SSL code it's not my code so if I if
I can put the SSL code in a different
process they still need to see the the
private key because that's what TLS
needs the private key otherwise it can't
do the crypto so the bug of the attack
surface would still have access to the
key I can still do it because there
might be bucks in my code and not the
SSL code but that's just 5% of the of
the overall attack surface so um
it I will probably do it at some point
but it's I don't expect miracles from it
bugs and open SSL will kill kill me
there's not much I can do about
that okay so I know what you're
thinking what about colel
bugs so I looked at a few of the recent
kernel bugs and it turns out that they
usually apply to SSS that are rarely
used in regular programs and uh because
I'm blocking all the CIS calls I don't
really need none of them apply to me
right and this is a this is a pattern
with Colonel bugs um uh there is a a
project called
Sandstorm um that also uses p trce and
and Secom tracing to reduce the csol U
surface and then puts regular Services
into a Sandbox for for web services and
they uh evaded all kinds of of Kernel
bucks just because of that so this is
like a zero effort thing because
obviously if you have a list of CIS
calls you'd use a white list and you you
have a list of things you are
explicitely low and the rest is is
disabled not the other way around right
so none of the usual kernel bugs apply
to me um because of the the seom stuff I
already do so kernel bugs aren't as big
of a problem as you might think at least
I still have them if I haven't patched
but you can't get to them via the
blog so I have a small confession to
make uh I'm a bit of a troll and that
applies to this project as well so um I
use the worst programming
language I used C right so I'm trolling
the security people and then I'm
trolling the Java people who have been
saying you should use multi-threading
for performance and not have one process
per request so I'm doing actually two
fork and xx per request um I'm trolling
the database people I don't have any
caching I don't have connection pool TOs
and the perf people too because I'm
still faster than most of the regular
Solutions so there is no there's really
no downside if you if you architect your
software to use this kind of thing um it
will be slower than other ways to do it
but most other software isn't as fast
anyway so there's enough Headway that
you can use to do security instead of
performance you will still be
faster so let's recap the the
methodology I used um first I make a
list of all the attacks I can think of
and this means concrete attacks so what
could happen and what would what would
be the problem then right and then I
think for every item on the list I
consider how to prevent this can I
prevent this uh what what I need to do
and then I do it right so that's easy
it's like this the fine man problem
solving algorithm in spirit and this
process is called threat modeling it's
it's like a it's dirty word because it
sounds like there's effort involved and
nobody wants to do it but it's really
it's easy it's just these these steps
you you look at your software you
consider all the ways it could be
attacked and then you consider what you
could do to prevent the attack or in
some cases you can't prevent the attack
and then you say well that's the risk I
have to live with right so that's called
threat moding you should try it it's
awesome and um you saw that I'm trying
to optimize something here I go for a
specific Target in this case I want as
little code as possible
um the more code there is the more bugs
there will be that's an a very old uh
Insight from I think it was originally
in IBM study and they basically found
that the number of bugs in code is a
function of the lines of code in the
code so there's a little more to it but
basically it's true so and it's not just
any code I want to have less of um if
the code is dangerous I particularly
want to have less of it and the the most
important category to to make smaller is
the the code that enforces security
guarantees so like one security
guarantee would be you can't log in if
you don't have the right password right
so the code that checks that I wanted to
be as small as possible um one or two
lines of code if if I can manage it and
then it's obvious if it if it's wrong or
not the more complex the code is the
less less easy would it be to see if
it's correct or not and that's what you
want in the end you want to be sure the
code is correct so how far did I get
it's actually pretty amazing I think um
you can write an elabs server in five
,000 lines of code the blog is 3.5 lines
of kilo lines of code um plus the Ed
client Library plus zet lip um but I'm
only using zet lip to compress not to
decompress so most attack scenarios
doesn't don't apply to to my usage of Z
Li um and the web server is also pretty
slow if you only look at the HTTP code
unfortunately uh it also contains the
SSL Library which is orders of magnitude
more than my code and that's how you
want it you want the biggest risk not to
be in the new code but in an old code
that someone else already audited if you
can manage it right so this is the
optimization strategy try to have as
little dangerous code as possible sounds
like a no-brainer but if you look at
modern software development you will
find out they do the exact opposite pull
in as many Frameworks as as they
can so this strategy is called TCB
minimization you should try it and I
gave a talk about it already it's
actually pretty easy so um I told you
what I did to the to the blog to uh uh
diminish the danger that can be done uh
if someone manages to take it over and
this is actually part of the TCB
minimization process so the blog was a
high risk area and then I took away
Privileges and removed exess checks and
in the end even if I give you remote
code execution in the blog process you
can't do anything you couldn't do before
right so it's no longer part of the TCB
the TCB is the part that uh enforces
security guarantees which the block CGI
doesn't
anymore so that's what you want to do
you want to end up in the smallest TCB
you can possibly manage and uh every
step on the way is good so no step is
too small right if you can shave off
even a little routine do
it this is the minimization part of TCB
minimization right I could I was able to
remove the block from the TCB tiny El up
still still has a risk so I I you saw
the threat model if someone manages to
take over tiny El up they can read the
hashes and try to crack them that's
still bad um but I can live with it
right uh if they vandalize the block I
can undo the damage without going to the
tape Library so that's
good if you compare that to the industry
standard you you will find that my
Approach is much better um usually in
the industry you see platform decisions
done by management not by the techies
and um it's untroubled by expertise or
risk analysis and you you get a
diffusion of responsibility because if
you even if you try to find out who's
responsible for anything you find uh
well it's that team over there but we
don't really know and then you find out
the team dissolved last week and it's
really
horrible and brand new we have ai tools
which is also a diffusion of
responsibility and then you get people
arguing well it's so bad it can't get
any worse let's go to the cloud where
obviously it gets worse
immediately so I prefer my way um I
think in the end it's important to
realize that the the lack of security
you may have in your projects right now
is self-imposed there is no guy with a
shotgun behind you
threatening you can do it you just have
to start right so this is self-imposed
helplessness you can actually help
yourself you just have to start
right how did we get here this is
obviously not a good good place to be
like all the software is crappy and
there's a few it's not just that people
are dumb there's a few reasons for that
so um back in the day you used to have
bespoke applications that were written
for a specific purpose and they used the
waterfall model and you had the
requirements specification and it was
lots of bureaucracy and really horrible
but it also Al meant that you knew what
the application had be had to be able to
do so that means you can make sure
anything else is forbidden if you know
what the application needs to be able to
do you can make sure it doesn't do any
other stuff and that is security if you
think about it deny everything that the
application wasn't supposed to be doing
and then that's what an attacker would
do if they take over the machine right
so if you know beforehand what you're
trying to get to you can actually
implement privilege even architecturally
as I've shown
you now we have more of an Ikea model
you buy parts that are uh designed by
their own teams and the teams designing
the parts don't know what the final
product will look like right in in some
cases even you don't know what the final
product will look like but it's even
worse if you consider that the the the
team building the part you make your
software from doesn't know what it will
be used for so it has to be as generic
as possible Right the more it can be
done with with it the better and that's
the opposite of security right security
means understanding what you need to do
and then disallowing the rest and this
means be as generic as you can the parts
are optimized for genericity Gen what's
the
name genericism I don't know so they are
optimized to be as flexible as possible
and they are chosen by
flexibility the developer of the part
usually has no idea what it would used
for uh and that means you can't do least
privilege because um you don't know what
the privilege will be that's least so
this this is actually a big mess so if
you use Parts programmed by other people
you will have to invest extra effort to
find out what kind of stuff you can make
it not do because it will definitely be
able to do more than you need and the
more you can clamp down the more
security you will have uh it's even
worse if you do Agile development
because then by definition you don't
know what the end result will be so if
you don't know that you can't do
security
lockdown so another argument why we got
here is economics of scale so it used to
be that if you build some kind of device
that needs to do something like I don't
know uh a
microwave then you you find parts and
you combine the parts and you solder
them together and then they solve the
problem but these days uh you don't
solder parts anymore you assemble from
pre-made parts and these are usually
programmable right so a little arm chip
cost like a tenth of a scent so why use
a special part if you can use an arm
chip and then program it but that means
you still need to use software that
actually solves the problem the hardware
is generic and that means the hardware
can be hacked and this is turning out to
be a problem right if you had a break in
in 20 years youo um it it breaked right
but now it's
programmable and people have realized
how bad that is but it is bad right so
that's that will bite Us in the
ass oops so um the response from the
industry has so far been the ostrich
method basically we we install stuff
that we know is untrustworthy and so we
install other stuff on top of it that's
also untrustworthy and then we call it
Telemetry or big data and to some risk
uh logging analysis in in aze or
whatever uh and in the end the attack
surface has mushroomed like a nuclear
explosion right so that's our fault
nobody has forced us to do this you
don't need to do this in your own
projects that's the hopeful message of
this talk in conclusion if you remember
nothing else from this talk remember
that threat modeling is a thing and you
should try it TCB minimization actually
helps least privilege is another facet
of the same thing and if you can uh use
a pendon data storage you should
consider it hm blockchain yeah not
blockchain a pend only data storage it's
not
[Applause]
[Music]
blockchain so two more you two more
slides yeah two more slides sorry I'm an
imposter no problem so the rule of thumb
should be if if the blog of some
unwashed hobbyist from the Internet is
more secure than your it security then
you should improve your it
security right that shouldn't
happen all right so that's all from my
talk I think we still have time for
questions do we yes okay awesome okay
now you can put your hand
[Applause]
together so if you want to ask a
question we have four microphones in the
room 1 2 3 4 and I'm going to take a a
question the first first question from
the internet the internet is saying you
actually got hacked or can you elaborate
on what
happened Yes actually there was an
incident where someone was able to post
stuff to my blog and because I had a
pend only data storage I Shrugged it off
basically so use use a pendon data
storage it's it will save your ass at
some point the problem was a bug in my
uh Access Control lists I had used some
some Access Control list in my alab
server and I had a line in it that I
should have removed but I forgot to
remove it and that meant you could post
without having credentials but um it
happened and it wasn't bad because my
architecture prevented damage um as
people are leaving the room could you
leave very quietly thank you um
microphone number one yeah is there a
second alternative for Windows and Mac
OS a secure alternative well so
basically you can do the the principles
I um I showed in this talk you can do on
those two so usually you will not be
hacked because your your Mac OS or
Windows had a bug I that happens too but
the bigger problem is that the software
you wrote had a bug or that you the
software that you use had a bug so I'm
I'm trying to tell you Linux isn't uh
particularly more secure than Windows
it's just it's basically you can write
secure software and insecure software on
any operating system you should still
use Linux because it has advantages but
if you apply these Tech techniques to
your software it will be secure on on
Mac OS and windows as well right so this
is not for for end users selecting the
software if you select software you have
to trust the
vendor there's no way around that but if
you write your own software then you can
reduce the risk to a point where you can
live with it and sleep soundly sure is
there a a technical alternative or
similar similarity like sa comp for
Windows and Mac OS so can you drop your
privileges after you have opened a file
for example uh uh so for meos I'm not
sure but I know that that free BSD net
BSD and open BSD have an an equivalent
thing I think uh Macos has it too but
I'm I'm not sure about that for Windows
there's are sandboxing methods you can
look at the Chrome source code for
example they have a Sandbox it's open
source you can use that to do this kind
of thing okay thanks so microphone
number two except down that's gone so
microphone number three in that
case this is four I sorry four four yes
um will your next talk be about writing
software secure software in Windows and
if no uh how much assets would you
request to compensate for all the
pain
no it's not a question of
money okay uh microphone one um have you
tried removing unnecessary features from
open
SSL uh Yes actually I've I've done this
pretty pretty early but it's still it's
still much bigger than my code
so um for example op SSL has support for
UDP based TLs but there's a lot of
shared cyers in there you can remove
ciphers you don't need and and that
helps a bit but it's still it's the
biggest part of the web server by far I
think there was an internet question was
there no doesn't look like
yes no yes no no yes okay uh then
microphone
four as someone who is uh connected or
was connected to an industry which has
programming programmable
brakes
um what is your opinion about things
like
mizra well well so there are standards
in the automotive industry for example
like misra
to make sure you write better code and
it's mostly compliance so they give you
rules like um you shouldn't use
recursion in your code for example and
the functions should would be this big
at at most and this is more I mean it
will probably help a bit but it's much
better to to invest in in good
architecture but you may have noticed I
I've said I wrote the code in C and I
said nothing about what I did to make
sure it's it's good code so that's
that's a different dimension that's
orthogonal right
so follow those standards it will it
will make your code a bit better
probably um but it won't solve all the
problems and I think personally you
should do both you should make sure or
try to make sure that there's as little
bugs as possible in your code there's
ways to do that I had to talk about that
too but after you do that you should
still have these kind of
architectural guide guard rails that
keep you on track even if someone
manages to take over the
process so now I think there was an
internet
question yes uh the internet is asking
how would it work to like scale This
truly impressive security architecture
up for more use cases and more like
larger theme or would the theme size and
the feature keep ruin it yes
so oh no oh
[Laughter]
no well I'm
sorry
[Music]
la