Re: A Question of Quality

["Yousef Syed" <yousef.syed () gmail com>]

Hi Marco, All,
I think the first time that I really got into the whole quality at the
code level was waay back in 2000 when I was involved in my first
Extreme Programming project.
It was mandated that all methods follow Design by Contract
(http://en.wikipedia.org/wiki/Design_by_contract), so we used
Assertions at the beginning and end of each method to validate the pre
and post conditions of any method - on top of that we had Unit Testing
of every method for Correct, Incorrect, Null and Boundary conditions.
It took a little while to get into this, but after a couple of weeks,
it was all second nature. The little extra time in upfront effort &
quality, saved a lot of time later on in bug fixes.
Since then, the technology has moved on. I know that with Struts, you
can use a Validation.xml to validate all inputs.
http://struts.apache.org/2.0.12/docs/validation.html
We can use parametrized Stored procedures to help protect against SQL
injections...
I've performed numerous code reviews and security code reviews and
where possible raised the game of the people around me. But that
doesn't change the fact that we appear to have extremely low
expectations for our deliverables unless stipulated in a cast iron
contract.
I've worked in many CMMI Level 3 (and some that claimed to be level 5)
where the quality of code being pushed out was appalling - they
delivered to the contract, so nobody cared.
I've worked in places where despite best efforts to put a quality
program in place, it was undermined by management...


However, my point was from a slightly different angle - and perhaps it
is a bad analogy, but I'll make it anyway.
If I go to a car mechanic to get new Tyres, I don't need to TELL the
mechanic to tighten each of the bolts on each wheel, firmly when he
returns the car; it is simply expected - can you imagine the mechanic
saying: "I left them loose because he didn't specifically ask me to
tighten them"! You can find countless other examples in other
industries where a certain level of service is provided without any
need to stipulate it in any contract.
For some reason, our industry isn't anywhere near that, yet. If it
hasn't been written, then it hasn't been said.

Our circumstances are even worse because a lot of our requirements
come from people with little or no knowledge of the technologies
delivering the solution, nor of the potential vulnerabilities that are
being exposed. How many business analysts know what XSS or SQL
injections are? Worse still, it isn't in the interests of the
development team to notify the business analysts, because it just
means more money for them as they call for an RFC in the future -
Kerching!

I know that, as an industry, we are overburdened by large a proportion
of poor developers that have:
 a) never been taught quality practices
 b) don't know why they are important to follow
 c) all they know are the basics of getting a program to function
according to the basic requirements - and that was enough to pass in
school
 d) now they have managers that let them get away to that sloppy
approach in the real world because it isn't in the spec...

We have many managers that have zero technical background and thus no
appreciation of the complexities involved in your average application
- the complexities today are enormous. I've had the pleasure of
working with some extremely good managers, even non-technical managers
that would leave the technical decisions upto the pros. However, we
have far too many that are governed by budget, time and resourcing -
and because they had no appreciation of the technical difficulties,
they planned the time and resources poorly - and the rest of us joined
the death march.


So what can we as industry professionals do to fix this? I'll admit
that a lot of the points mentioned are out of our hands, but I do
think that we need to be raising the level our client's assumed
expectations.
I think that my initial list was pretty basic and I can think of a few
other items that could be added to it.

Given the amount of time, effort and money that can be saved by doing
things right upfront, in my experience at least, this stuff pays for
itself and that is the way to sell it to the client. Raising the
quality of the people that are producing the solution is a far more
difficult task. I try to get people through my own network, but I'm
not always afforded that luxury.

I believe that as Security Professionals we should be making an effort
as a group to address these short comings and not just as individuals
on our own projects.
Thanks,
ys

--
Yousef Syed
CISSP

http://www.linkedin.com/in/musashi



2008/11/3 Marco Morana <marco.m.morana () gmail com>
> Syed
>
> when is the last time that you tried to make this happen for an
> organization? The fact that we (security practitioners/consultants
> etc) all know what to do to build security in and that this is
> documented and vetted by experts and that fact that we have tools and
> procedures to use is simply not enough.
>
> You need to look from the perspective of making an assessment first of
> the maturity levels and capabilities that organizations have to build
> security into their SDLC. Then you can build the case for it. Most of
> organizations (at least from my experience) are not like Microsoft
> where a Bill Gates memo makes software security happening. You need to
> build from the ground up showing the business cases and gaining ground
> by partnering with project stakeholders.
>
> Regards
>
> Marco Morana
> Writing Secure Software Blogger
>
> Why, because you are dealing with a people
>
> On Thu, Oct 30, 2008 at 7:55 PM, Yousef Syed <yousef.syed () gmail com> wrote:
> > Why isn't Quality Assumed?
> > Why isn't Security Assumed?
> > Why are these concepts thought of as add ons to Applications and Services?
> >
> > Why do they need to be specified, when they should be taken for granted?
> >  - Input Validation
> >  - Boundary Conditions
> >  - Encrypt Data as necessary
> >  - Least Privilege Access
> >  - White lists are better than Black lists
> >
> > I'm approaching this from more of a development/services perspective,
> > but I'm sure it applies to others. So why should the need for any of
> > the above genuinely need to be stipulated?
> > The knowledge is out there.
> > The tools are out there.
> > And it doesn't take a huge effort to do - but can save a huge effort
> > in the future.
> >
> >
> > I realize that this is a bit of a rant, but I really do believe that
> > software quality and our expectations surrounding software quality is
> > worth talking about. During the development life-cycle of a product,
> > various requirements are stipulated; however, all quality and security
> > seems to get ignored unless each specific matter has been added to the
> > requirements.
> > Architects and designers don't push back on requirements due to
> > quality or security issues; but rather, due to the difficulty to
> > implement it. Code reviews don't through back client code with
> > username/passwords embedded, but they do throw it back because it
> > doesn't follow the stipulated coding/naming standards. Testing and
> > reviewing have their place in this, but I do feel that our focus is
> > often on some of the wrong things.
> >
> >
> > I'll leave it there for now so you guys can comment.
> >
> > ys
> >
> > --
> > Yousef Syed
> > CISSP
> >
> > http://www.linkedin.com/in/musashi