bofh wrote:
> Heh.  I think we're having far too much fun in the other threads.  I
> have a serious question. 

thank goodness. :)

> I'm a mangler in a largish company.  We have
> developers, and contractors.  No coding standards and all that, so,
> things are... messy.
> 
> I'm not in charge of development, but I want to help them develop
> something useful, and secure.  Other than doing a braindump of the
> developers here, what are the things that you people have found useful
> to have in secure programming practises?
> 
> I'm looking for advice, tips, procedures, processes, whatever.  I will
> be looking through my old notes from Matt Bishop's class at SANS, and
> other things I've gathered throughout the years.

Random throughts, no particular order, no particular structure.
Don't take any of it as gospel unless it makes sense to you.  Any time
I think my own coding, I have flashbacks to a couple stupid programming
errors I made when I was young and think I better stick to the www/ tree. :)

* In addition to good coding practice, look at good DESIGN.  After you
do all you can to make the code secure, imagine that it ISN'T, and do
what you can to contain the damage.

* Decide if security is really your top goal.  Get it in writing.  If
it is, keep it that way.  Yes, the mere fact you are offering a service
over the 'net means you are taking on some risk, but at every point,
you should ask, "Is the risk worth the benefit?".  Look at the actual
risks of a loss-of-data-confinement, and ask yourself if you would be
willing to explain that decision to someone who was the victim of a
compromise brought on by that decision.  Or explain it to a jury.  So
far, the legal system has been amazingly tolerant to people who write
bad code, and instead opted to try to go after the people who commit
the theft.  Some day, however, people are going to start thinking bad
design, like a defective lock on an unguarded vault, is a crime, too.

* Don't store excess data outside the firewall:  Somethings are needed
to be stored on web applications.  Other things should be unloaded and
purged.  If someone knocks over your web app, they shouldn't find a
store of credit card numbers and personal user information, collected
over the last few years, unless there is really a reason for it to be
there.  If you have to collect sensitive info, get it moved to another
machine ASAP.

* Don't punch holes inward through your firewall: Given a choice, have
internal apps fetch data from outside machines, don't have outside
machines put data into (or fetch data from) internal machines.  Why?
If the outside machine is compromised, you don't want it to be able to
work-over machines inside your network, which presumably have a lot
more data, much of it is probably more interesting.

* Beware of people who when you talk to them about "secure programming"
immediately talk about "encryption".  Most security breaches happen
at the endpoints, not in-transit.  These people clearly don't understand
secure PROGRAMMING, just one tiny feature.

* Use things like privilege separation and chrooting PROPERLY.  For
example, the point of privilege separation isn't the buzzword itself,
but rather to make sure that the privileged code is small, secure and
correct.  Simply priv-sep'ing code and having the part that runs as
root being poorly written, bloated, unchecked, and unaudited is just
complicating things, not improving security.

* Good code first, "tricks" second.  Look at the history of OpenBSD's
security work.  Sure, we got things like W^X, Propolice, privilege
separation, chroot'ed apps, etc., but look at how it was done:  Those
things were done AFTER the basic code was cleaned up.  I.e., provide
extra protection to a secure system, not slap bandages over crap.

* Beware of experts.  Anyone who gives you one simple answer to "safe
coding" is full of it.  It ain't that simple.  Anyone who says, "I've
got all the info you need" is also probably dangerous.  Anyone eager
to jump into the computer security business and bless your project is
either a fraud or a fool.  This stuff is too complicated to ever be
able to wave your hands and say, "this is secure".  I sometimes wonder
if anyone who really understands all the threats out there is even
willing to use a computer for anything other than recreational
purposes, and (s)he'd probably never be willing to endorse someone
else's code.

* Never stop looking for problems in existing code.  Don't stick it
into use and say, "It's done".

* When you (*ahem* or someone) finds a bug/hole, don't fix it and say
"done", fix it, and go find the other instances of the same bug.  Plan
on making a longer explanation of why you couldn't find additional
instances of the same bug than you would of why the same error happened
five times.

* Management has to have an interesting balance of attitude: that
quality code is a REQUIREMENT, crap is unacceptable, and yet recognize
that Stuff Happens, and that if you condemn people for finding bugs,
they will (surprise!) find no bugs (but the bad guys will).

* There needs to be a positive attitude towards improving code, not
just adding features.  Heck, even on the OpenBSD lists, which gets more
excitement, the adding of a new feature (even if not complete!), or
the fixing of a subtle, long-time code flaw that never bit anyone (yet)?
Management has to appreciate the quality of the code, not just the cute
features the user sees.

* Plan the security in at the beginning, before the first line of code
is written.  Examine the threats the system will face, and figure out
how you minimize each one.  If the project deviates from the starting
plan or other risks are thought of, re-examine the threats.

* Use existing code you trust over re-writing the same basic task.

* Don't forget the user, and what stupid things they will do.  Sure,
you can't prevent them from doing stupid things, but you might be
able to avoid provoking them to do stupid things to get around
annoyances in your app.  (WHY oh WHY do some websites where all I'm
interested in is downloading an application and reading documentation
a: insist that I log in at all, b: have a password of 37 or more
characters, mixed case, odd punctuation, three digits and want to
know when my mother gave up her virginity?)


If you follow the above advice, you will not be guaranteed quality code,
but I can assure you your project will take much longer and cost more
than management was hoping.  And this is why shit happens.

Nick.

Reply via email to