Don't blame Willy the Mailboy for software security flaws

Legalese

"Developer warrants that the software shall not contain any code that does not support a software requirement and weakens the security of the application..."

So the developer warrants that:

- all of the code is there only to support the specific [lol] requirements, and if there is any code which does not support a requirement, then that non-supporting code does not weaken the security of the application.

Rather than:

- whether or not any of the code actually fulfils the requirements, absolutely none of the code weakens the security of the application

Two very different things...

It's been a while since I used Java...

... but does it seriously compile the variable names into its byte code? That sounds unlikely to me, it might be a virtual machine but it's still a form of machine code. Plus, why would it keep variable names but not function names?

Seems more likely you'd want to do something about SOAP calls or SQL that might be embedded in your code (although you probably shouldn't be doing that anyway). If you really are worried about hackers reading the data in the String table, why not overwrite it with jibberish after you've finished with it?

Does this mean going back to the bad old days of naming all your variables A, B or C and creating unmaintainable code that no-one save the author can read?

You get what you pay for.

Quotation for developing the specified "Hello World" application to the required "Application Security Procurement Contract"

Specification: £0:10

Design: £0:10

Coding: £0:10

Testing and validation: £250,000

Certainly higher up the food chain than the programmer

To this day I never cease to be amazed at the number of companies I consult with that have no credible methodology for managing the running of their organization, far less managing their development process. Total lack of actionable requirements - both in the software development process - AND, more importantly - in the development of core business process and practice.

It's not the "little guys" as you say; indeed, in most organizations I visit, if a programmer or QA person raises the point that the design is untenable, they are usually frog-marched from the building in a matter of days or weeks.

Certification is absolutely no use what so ever: if the business users can't define what needs to be done in the first place, and complain about "unnecessary time spent" on things like requirements testing or design reviews, all the education in the world isn't worth dingo's kidneys when faced with time and budget deadlines.

Most companies would rather hope against having an issue than try to prevent one. Even standards like PCI are met only to the level that the audit requires - and problems are patched (if that) rather than solved.

The "Aurora" attack that hit Google and so many other high-profile companies SHOULD have been a wake-up call: if these companies all have common failings in their management practices that allowed an attack to be broadly pervasive, it's not the TECHNOLOGY that's the problem. Until that issue is addressed, software security flaws are the LEAST of the worries.

no released code is ever completely bug-free

it's all about minimizing risk

of course, if it has been unit tested, system tested, integration tested and user-acceptance tested, then signed off by the top brass and there are still critical bugs, it's those who sign it off at the top who must carry the can...

I know who to blame

Today's problem is that most security idi...excuse me: *experts* have decided it is a good idea to restrict communication to port 443 (and port 80 at a stretch).

This resulted in all sorts of apps starting to use port 443 and 80 for non-http traffic.

The response was to start scanning at least port 80 (and I'm sure some have opted to fiddle with certificates to facilitate some 443 scanning too) severly compromising non-http transportations.

As a result, developers when designing a classical client-server application, are forced into using webservices for everything. The http protocol overhead eats bandwidth and is strictly a pull protocol. The server cannot tell the client anything, the client has to ask. Repeatedly.

So now a few hundred clients take their toll on one server, this translates into a need for more servers. Then the developers are faced with a new choice: Do they really need to maintain state on the server? If so, they will need an extra solution for that, so that a client that suddenly request something from server #2 will have the same state.

I could go on and on like this. In many cases, we developers use the wrong tools, and the reason is that some security idiot have decided that the old ways are unsafe.

Well... Guess what... --it happens. Only now we spend more time and resources solving problems that really needed no solving. We could have used this time to make our solutions more secure, but those precious hours are spent making the unscalable scalable. And we're told to use development tools like Java, because that apparently helps us write safer code... (code that is easier to reverse engineer, which now seems to have prompted a requirement for writing more convuluted code which I'm sure will be a delight to maintain...)

I see...

I've been writing software for longer than I care to think about. I think I'm pretty good. I SHOULD be "average", but I'm not - I'm pretty good. And the reason for this is that so many of my peers are so bloody bad. I have only worked with one or two other software engineers over the last 5 years that I actually rank and would completely trust. It is a very sad state of affairs, and admittedly probably says as much about me as it does the state of the software engineering industry. These "bad" softies do indeed produce some utter rubbish sometimes. They're not stupid people though. They're quite often sloppy and lack an attention to detail, but they're not thick. Lack of experience is usually the problem, and that's not their fault (but not always - some people never learn).

Having said this, "bad" software is often not created by the engineers. One is often required to release code that one KNOWS isn't quite right. Commercial pressures, stupidly short time scales, and a general lack of appreciation and understanding by project management are usually to culprits. I don't defend releasing buggy software - to do so would be just another example of the "I was just following orders" excuse. But that is commercial reality, and I do make a point these days of refusing to release software that I know isn't right; a stand that has caused me some grief over the years.

So, blame the project management? Well, they too are often under huge pressure by higher management to deliver. As an example, some years ago now, I (along with lots of other engineers) were working on quite a complex system. We spent ages doing all sorts of design and analysis, and URL stuff etc etc - ie - we tried to do things the "proper" way. One morning, completely out of the blue, the project manager came back from some meeting he'd just had with upper management and declared that "they" didn't want fancy URL diagrams - they wanted code. They wanted something to work. So we (literally) abandoned all the design work there and then and after a cup of tea, started hammering out code. In the end, the system was still pretty good I think (I left shortly before it was fully complete), but had it failed, had it been full of bugs, who would be to blame?

No responsibility

Without autonomy

...or, failing that, a fuckton of cash.

Analyse This

"...the software shall not contain any code that does not support a software requirement AND weakens the security of the application..."

I think the 'AND' should be 'OR'. As originally written, a 'coder' could put an easter egg in the application as long as it didn't weaken the security.

The sentence would also benefit from a few brackets to make things clearer. If they can't get the basic requirement written properly then what hope is there?

IIRC Harlan Mills @ IBM Federal Systems* put it this way

"Software development is far too important to be left in the hands of people who like coding"

*Now part of Loral.

Obfuscating variable names...

... is a unbelievably terrible idea. It hampers maintainability and provides absolutely no security benefit, as anyone who has ever reverse-engineered symbol-stripped code can tell you.

Wait what??

>> [ ] Developer warrants that the software shall not contain any code that does not support a software requirement and weakens the security of the application...

I am absolutely certain that the above clause, taken form the SANS page, is about the "Vendor" as opposed to The Intern that was just hired to do Access Control List implementation. But then again...

Well, great. You might as well sign that the statement that every single line of your application is sure to not be interpreted by some Rabbi as being against the scripture in his cherished 12-volume Talmud. This includes the comments of course.

NATURALLY there will be code that does not support a software requirement; there MUST BE. Helper code, debugging code, code to make things efficient, you name it. And whether anything weakens the security of your application is of course decided WITH 20/20 HINDSIGHT.

Now, I know of projects that DO SIGN contracts with talmudic requirements and in which the vendor asserts being in FULL COMPLIANCE with said requirement. But that doesn't help at all. It's just that the call to the insurance company is getting more complicated and the rates go up.

>> In other words, when it comes to application security and QA, the buck stops with the developer.

Really, Matt? How can that happen? Apart from the fact that the "Aynan Shoulder Shrugh" is not apposite at all to a "passing the buck situation" (but what do I know), the buck just WON'T stop with the developer because the customer won't stand for it. I imagine the meeting in which 10 lawyers and representatives of companies A and B meet, with Willy the developer in the middle and not a single dude from the "SOFTWARE QUALITY ASSURANCE" floor in sight. That would be ridiculous.

Noteh that the SWEBOK is NOT a "rigor-oriented qualifications for coders". SWEBOK is the "Software Engineering Body of Knowledge" - it is NOT about coding, it is about Software Engineering. How to manage the software lifecycle, how and which documents to generate when and all that jazz. Willy the Developer won't profit from it ever, he is supposed to read the "JUnit in Action" books and apply the knowledge with friendly coaching by co-responsible team.

Read the whole line

It says:

No Malicious Code

Developer warrants that the software shall not contain any code that does not support a software requirement and weakens the security of the application, including computer viruses, worms, time bombs, back doors, Trojan horses, Easter eggs, and all other forms of malicious code.

Better luck next time with the sensationalism.

@AC "standard ports"

You missed my point by about a light year.

1) True, you should block specific ports. However, today most organisations block ALL ports, which... leads to your third point "but the way it is MISused by developers.". Well, *duh*! If your network is only open for http, then that is what most application developers will use! As a developer, you cannot use a nice and shiny peer-to-peer protocol when only http is allowed.

2, 4 and 5) I know. I've written several http servers from scratch myself.

Re-read my first post again. And THINK. If the security guys gives you peanuts, then what will you eat?

Do you want an application that is properly designed, or one that will actually work in most of the paranoid networks out there? My personal preference won't put much food on the table, so I close my eyes and use the tools at hand. From what I can tell, that is what everyone else is doing too.

Only the lawyers will win.

Say a programme I wrote goes tits up and costs company X £10,000.

Company X sues me and wins. I pay £10000 + £2000 costs

The problem was actually caused by a 3rd party encryption library. I sue 3rd party dev for £50,000 to cover lost revenue due to the bad rap the previous case has given the product.

I win and the 3rd party dev has to cough up £50,000 + £5000 costs.

He discovers the problem was down to a bug in a 3rd party library *he* was using.......

And so it goes on, and the lawyers get richer.

the problem is....

After 30 years as a developer I know for a fact that programming is a complex creative process, and to do it well requires skill, discipline and experience. I also know that that nearly all managers at the level that sets corporate policy have 0 technical understanding and usually don't actually understand the tech in their own products. Even though they work in a high-tech industry they usually only have a business degree or MBA.

Consequently most managers all make the same mistakes. Its like their MBA school removed their brain and replaced it with a single rule to try and reduce everything down to a single simple process then hire cheap labor to perform it. They are completely oblivious that programming is a skilled and creative art producing one-offs, not a production line banging out multiple exact copies of the same thing. They've only ever learnt one management approach and they're hell-bent to apply it, regardless of its fundamental unsuitability in this environment. When all you have is a hammer everything looks like a nail.

Consequently because they dont understand programming they also have no clue about the skills it requries, so they repeatedly employ underskilled people to perform complex programming work because they are cheaper up front, regardless of the actual damage and extra rework these people cause. Management always totally ignore money they can't directly account for, so the damage one incompetent programmer can do to a code baseline is never an issue because its invisible to the bean-counters as they can't calculate it up-front.

Unfortunately it seems nothing will ever change because the incompetent managers will never fire themselves. If anything ive noticed that over the 30 years I've been working as a developer managers are more blinkered than ever so the trend is getting worse.

Beer because its the only way out for developers.

Money

"There's a low rasp of a noise being made in the software world..."

"...by security certification vendor SANS"

By going off on irrelevant programmer certification and management responsibility tangents, the article blows right past the very point that it started off with:

"Security vendors want customers".

A) Customers want their business requirements met in the cheapest, quickest way possible.

B) The low/mid cost developers get the work.

C) Security certification is not included in the winning bids.

D) Security certification vendors are unhappy about this and want customers to stipulate security certification as a requirement in the tender.

E) D is not happening because of A.

pay us like doctors

If developers are to be board-certified like doctors, and are to be liable for malpractice like doctors, then they will have to be educated like doctors (8 years of college, 4 years of supervised apprenticeship), and they will have to be paid like doctors. No outsourcing to india. No ragamuffin non-college-grads.

Raise your hand if you're naive enough to think this is ever going to happen.

Not always the developers fault

I've been working on some code for the last 4 months now, and a couple of days ago the customer decided to let the PM know that they actually needed some other functionality because those that be have said so. It's supposed to be delivered to QA in a week or so.

Ok, been here many times before, another week or two and I could get the new code integrated.

Started working on it, and got a *very* basic version working as proof of concept for myself. The PM saw this today, started playing, then said "well it works pretty well, lets give them that. It's only a little bit that doesn't work".

What.The.Cock?!

After much laughing on my part I let him know (politely, of course) that if he thought I was going to put my name anywhere near that code then he had another thing coming.

Sometimes the developers just get pushed out, whilst the management decide to do their thing and *please* the customer. I was lucky (and feeling argumentative!)

Developers, Managers, Capitalism

Many developers know very well about the security issues and other kinds of bugs in their code. The only Problem is the Feature Treadmill: As soon as something is barely working, your manager tells you to "focus" on the next 25 features he urgently needs implemented.

Good engineers want to deliver high quality, but for the vast majority of the software industry and users this is something of priority #5. Developers are normally on the lowest level of company hierarchy, so they just "get used" to the fact that quick'n'dirty work is expected from them. Managers are also under pressure to deliver a ton of features yesterday. That is the expectation of the market and so the customers get it. I have never, ever heard of BP telling MS it would dump Office if they did not step up their security. Or Daimler telling the same to SAP.

All these "leading" software companies use highly failure-prone tools like C/C++, have dodgy "quality assurance" processes and are basically run on feature lists and deadlines.

It is notable that some industries actually have quite good software development processes. Avionics and Medical Electronics, namely. Boeing simply can't afford a safety/security issue in their flight control systems, so they have the right tools (Ada) and good QA processes in place.

As long as a company mandates the use of C/C++, it is absolutely uncomitted to security and first management must be rectified before you start talking to engineers. Even if management demanded some kind of "QA statement" from engineers this would be totally useless if the current tools and processes did not change.

Honestly, we simply have to live with crappy IT security for the time being, as long as the CEO of Daimler does not kick the arse of the CEO of Microsoft. Let's hope tools like SE Linux, Virtual Machines and Firewalls will contain and detect malware. May the gods of SW be with us :-)

I call bullshit on Fortify...

The biggest change that has to happen is nothing to do with the developers. It is entirely management. It is those who want a profit-led product out the door before the competition. Who announce the release of a product long before R&D is complete, giving a release date somewhere BEFORE the projected end of R&D cycle. So before that is due to finish, somehow the product has to be sorted, put together, boxed, and shipped out the door. And then, when all hell breaks loose, they look for somebody ELSE to point the finger at.

And just to show how far off the mark Fortify can be... We can't call a password variable "password"? WTF? Would you rather I called it 'q' ('p' would be too obvious). Shall my loops be 'i', 'j', and 'k' while we're at it? And what sorta COMPILED language retains variable names? Or, oh, wait, maybe their own project management was rushing them so much they never figured out how to turn off the embedded symbol table. Hey - guys - you do know all that debugger support rubbish isn't supposed to be included in a release project? :-)

Coders have to share some of the blame for bad code. But not all of it. If your boss tells you 'x' has to be done and dusted Friday night when you expected NEXT Friday (if not later), and there's no option for argument... there's two choices. Quit, or hack together some code that "works" hoping it works well enough, while feeling disillusioned by the whole thing. And, well, you know, making it ACTUALLY work can be pushed off until the next (chargeable) upgrade... Friggin' management never miss a trick...

Enough C++ bashing, FFS

I can write insecure code in _any_ language. And, jlocke, a load of avionics and medical code _is_ written in c/c++. As the original article pointed out, Java has it's own security issues as well, as do all languages. What language is SE linux written in again? And your firewall ? And your VM ?

c++

I do program C++ for a living and I like its efficiency, but I hate the security risks.

Just a few examples:

#1

char buffer[6];

int x;

for(int i=0;i<=6;i++)buffer[i]=otherString[i];

//have fun with x now

#2

struct x{int x, int y}

struct y{int x, int y,char[6] z}

x a;

x b;

y c;

memcpy(a,b,sizeof(y));

#3

vector<int> v;

v.resize(5);

v[77]=7;//no problem here, just somewhere else

#4

int i=77782;

printf("%s",i); //print some nice garbage

#5

char* ptr;

printf(ptr); //great fun probably

#6

char* ptr;

strcpy(ptr,"cissounsafe"");

#7

char* ptr=new char[100];

ptr++;

delete ptr;//have fun with your heap

#8

All sorts of totally undeterministic multithreading fun

#9

really, really slow programs after you instrument them with valgrind or Purify (to find the memory bugs)

(1/100th of original speed)

Real World Security Issues

...are 90% of time revolving around some stupid stuff like buffer/integer overflows or uninitialized pointers. Eliminating those issues simply by using a safe programming languages would kill off the vast majority of security issues. Companies sticking with C/C++ are simply not serious about security and holding developers responsible for those bugs is simply hilarious.

If you have worked for nine hours you easily forget the terminating zero or type "<=" instead of "<". That's not neglicence, that is normaly human error, because humans are not machines.