The Rise of Software Security

Gunkerty Jeb writes with an article in Threatpost. From the article: "Perhaps no segment of the security industry has evolved more in the last decade than the discipline of software security. At the start of the 2000s, software security was a small, arcane field that often was confused with security software. But several things happened in the early part of the decade that set in motion a major shift in the way people built software ... To get some perspective on how far things have come, Threatpost spoke with Gary McGraw of Cigital about the evolution of software security since 2001."

Comments

lol

[Anonymous Coward]

Finally

Slashver

[Hognoxious]

tisement much?

Re:Slashver

[kafka47]

Exactly my thought. What was that supposed to convey?

Let's not ask someone who has lots of credentials

[hesaigo999ca]

Let's ask a nobody, as compared to say a full fledged AV engineer who has been in the field since day 1....nothing like getting your information from the source....
oh wait, I get it now, this was just blatant publicity for this upcoming software security firm that needs to make a name for themselves....remind me next time I need to become someone, I should get someone to post on /. a story on me and my company....

Dont look for a sig, I aint got one...

The proof

[93 Escort Wagon]

It's been so nice watching those weekly SANS vulnerability emails get shorter and shorter over the past decade.

/sarcasm

Re:The proof

[hedwards]

Well, most of them are so short that they don't even bother to send them out.

Re:Let's not ask someone who has lots of credentia

[Dunbal]

That's why most slashdotters never bother with TFA.

Mod parent up.

[khasim]

TFA is nothing but name dropping and unsupportable claims.

So in 2001, C was a disaster, C++ was a disaster, Java was getting better, .NET was getting even better.

Yeah. Right. Check your dates. If you were using .NET in 2001 ...

You can write secure code in almost any language. It is up to the skill of the coder. Look at the various *BSD's out there.

Re:Mod parent up.

[Anonymous Coward]

Yeah. Right. Check your dates. If you were using .NET in 2001 ...

I personally started programming .NET in late 1999 (it was called something like Next Gen Services then) as a pre-release Alpha tester. It was released publicly as a Beta in 2000.

Re:Mod parent up.

[lennier]

You can write secure code in almost any language.

Perhaps you want to believe that claim.

And yet, the ongoing real world persistence of privately reported array out-of-bounds errors in critical security-dependent code continues to show that apparently, even the best programmers objectively can't write secure code even if their professional reputations depended on it.

At least, they may be occasionally capable of writing secure code, but they're not capable of never writing any insecure code, or even testing for the existence of insecure code in the code they have released. Third parties have that priviledge. We don't know how many of the third parties who find these bugs are black hats, because we only hear from the white hats. But a 50/50 split between white and black security researchers seems like a good wild-ass guess. So figure one zero-day for every reported monthly security bug. Are you scared yet? You should be.

Is this ongoing security massacre the fault of the language programmers are using? Absolutely yes. The point of security is that 99% correct isn't good enough when that 1% of errors your toolchain didn't automatically detect can get your entire customer base simultaneously rooted. And array out-of-bounds errors have been a solved problem in some languages since 1970.

In 2011, insisting on using a language, or any other tool, which doesn't solve a forty-one year old already solved problem is simply an error.

Re:Mod parent up.

[CastrTroy]

My only question is, why would you assume a 50/50 split for white hat vs. black hat. Certainly in the general population there are not 50/50 good vs. evil. If that was the case, people would be a whole lot worse off than they are now. I would say that a much larger percentage of hackers are white hat. That being said, even a small number of black hat hackers can do a serious amount of damage.

Re:Mod parent up.

[Anonymous Coward]

Really? I was going to say that was a rather optomistic split. Perhaps you haven't heard of corporations...

Re:Mod parent up.

[Anonymous Coward]

Engineering (and programming) is about trade-offs. Those insecure tools and languages have a pair of tangible (measurable) benefits that often weight more than security.

Re:Mod parent up.

[kmoser]

And yet, the ongoing real world persistence of privately reported array out-of-bounds errors in critical security-dependent code continues to show that apparently, even the best programmers objectively can't write secure code even if their professional reputations depended on it.

If they persistently write such buggy code then I wouldn't consider them the "best" programmers. And that's not even consider that we're talking about Microsoft to begin with.

Re:Mod parent up.

[Pieroxy]

My only question is, why would you assume a 50/50 split for white hat vs. black hat. Certainly in the general population there are not 50/50 good vs. evil. If that was the case, people would be a whole lot worse off than they are now. I would say that a much larger percentage of hackers are white hat. That being said, even a small number of black hat hackers can do a serious amount of damage.

It's not 50% bad 50% the rest of the world. It's 50% black hat, 50% white hat. But there is still 99% of the population not in either categories.

Re:Mod parent up.

[TheTyrannyOfForcedRe]

Rose colored glasses much? The general population is 0.01% white hat and 99.99% black hat. The cool thing about humans...they use ingenious psychological tricks on themselves so that they can ignore reality and logic when it's needed. One of the places humans need to toss objectivity and logic is when evaluating Self, close family, and close friends. Once logic and objectivity are out of the picture it's perfectly possible to believe that you, your family, and your friends are all good people; it's those OTHER assholes who are fucking things up.

The reality is that very nearly everyone is one of the assholes.

TFA teetering on the edge of spam

[dcavanaugh]

I guess banner ads are not enough.

Re:Let's not ask someone who has lots of credentia

[FormOfActionBanana]

Well, what an ignorant fuckhead you are. Cigital is not a software company but a consulting company. Gary McGraw is the original "how to do it" software security guy, and he knows his shit.

Go ahead, respond with a list of good books you've written and tell us about your AV (antivirus?) company. Your reply will constitute your Slashvertisement, and I'm always happy to be proved wrong. It's a win win.

re C and C++ were disasters

[Anonymous Coward]

Claiming that C and C++ are disasters from the standpoint of security is like saying that the IP protocol is a disaster from the standpoint of reliable transmission of data streams, or that HTTP is a disaster from the standpoint of security. Arguably so, but only if you don't supplement them with any other layers or tools.

Re:re C and C++ were disasters

[FormOfActionBanana]

C and C++ ARE disasters. gets() and >> can NOT be used safely. Period. Tons of functions in the standard libraries have been rewritten with secure variants, to try to make it vaguely possible for developers to keep track of buffer lengths. Still, some APIs screw it up and it's nearly impossible for an intelligent human to get it right every time without static analysis tools to back him up.

HTTP is not a disaster but it clearly was not envisioned with security in mind. All attacker provided data is strings, input data comes from a variety of sources; there are way more HTTP verbs than strictly necessary. The authentication provided with the spec is "encrypted" with Base64. Actually, if this protocol were designed today to its original form, it would be laughed out of its security architecture review.

Re:re C and C++ were disasters

[Anonymous Coward]

Most of the net or computers weren't designed with security in mind. They all inherited that trait as Personal Computers spread, I remember seeing OS's with out a basic password login.

Re:re C and C++ were disasters

[nzac]

C and C++ ARE disasters. gets() and >> can NOT be used safely. Period. Tons of functions in the standard libraries have been rewritten with secure variants, to try to make it vaguely possible for developers to keep track of buffer lengths. Still, some APIs screw it up and it's nearly impossible for an intelligent human to get it right every time without static analysis tools to back him up.

So don't use gets() and >> as you said there are a number of alternatives. You can stuff up the API in any language if you aren't careful and everyone has access to static analysis tools. Yes the record is poor but there are no other alternatives to compare it against. Once you build the checking into the language no one will want to use the slower executables it produces.

Open and other BSDs prove you can make a reasonably secure OS in C. People relying on C/C++ to be intrinsically secure is the disaster.

Re:re C and C++ were disasters

[Anonymous Coward]

That's ridiculous. For correctness gets is easily replaced with fgets and >> is easily replaced with .getline.

But more importantly, I would bet 99% of the gets uses don't cause any serious security flaws. By definition gets only reads from stdin and so what if the user can segfault or cause undefined behavior with one of their programs on their own machine. It only becomes a security problem when the application is setuid (creating a possibility for a privilege escalation) or some kind of server where communication is done outside the machine over stdio (remember this is gets we are talking about!) of which CGI is the only example I can think of and C wasn't exactly a popular language for that.

The vast majority of serious security problems are subtle operating system bugs and trying to get a user to not execute untrusted, potentially harmful code. Simply writing code in a different language isn't going to solve anything like that.

Re:re C and C++ were disasters

[Col Bat Guano]

"Once you build the checking into the language no one will want to use the slower executables it produces."

Except they do. Languages such as Ada, and really any language that allows compilers to understand what is happening in the code, can optimise out many of the bounds checking. The cost of bounds checking isn't as great as you may think it is, and if it eliminates -all- buffer overflows wouldn't you choose it?

Re:re C and C++ were disasters

[nzac]

Except they do. Languages such as Ada, and really any language that allows compilers to understand what is happening in the code, can optimise out many of the bounds checking.

Excuse my ignorance but where are these benchmarks. All the ones I see have Ada as marginally slower (but i guess not statistically significantly) and everything else not even close. Coding in C you can manually put the bounds checking back in at your digression and if the coder does not know where its needed then the program can hardly be trusted to be secure.

http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=gnat&lang2=gcc
If you want to quote me a better/more relevant benchmark feel free. The main issue here is the memory usage. The benchmarks where C is conclusively beaten ada uses multiples more memory (the CPU has a large cache which may be relevant here). And where it uses less it is slower. Averaging two or three times the memory usage of C exes is enough of a reason to not use it.

Also though I have no Ada experience the coding is more verbose so manually choosing bounds checking in is not necessary extra work.

Re:re C and C++ were disasters

[Anonymous Coward]

Hey idiot.,
How about you find a dictionary and look up the word "disaster', then review what you wrote...

one of these things is not like th other...

Challenger disaster

Titanic disaster

War in Iraq disaster

C disaster?

Re:re C and C++ were disasters

[Karellen]

Hmm....I'm aware of the problems of gets(), but haven't heard of possible issues with >> before. Can you give an example or link to an article that explains the issues, so I know what patterns to avoid in the future?

Re:re C and C++ were disasters

[FormOfActionBanana]

Come back to me with an identity and I'll tell you about metaphor in the English language.

Re:re C and C++ were disasters

[FormOfActionBanana]

Hmm, this operator is super difficult to Google for, that's for sure. The >> operator is unsafe to use when reading into a character buffer because it does not perform bounds checking on the size of its input. An attacker can easily send arbitrarily-sized input to the >> operator and overflow the destination buffer.

Re:re C and C++ were disasters

[FormOfActionBanana]

Yeah, if anyone knows a way I can search the Google index for sequences like ">>" please let me know!

I know I have seen this topic treated in books, but cannot find anything. I did find the following two links, however:
http://stackoverflow.com/questions/2711780/question-about-char-input
http://www.physicsforums.com/archive/index.php/t-8093.html

Re:re C and C++ were disasters

[Karellen]

Um, OK, that would cause a problem, but why on earth would you read into a character buffer? You're using C++. Why not read into a std::string?

Yes, you have to read into character buffers in C, because that's all you have. Character buffers, or arrays, are just as insecure in C++ as in C. Which is why you shouldn't use them. Use vectors, lists, or - for characters, strings. C++ has safe abstractions. Use them FFS!

Re:Let's not ask someone who has lots of credentia

[Anonymous Coward]

If you don't know of Gary McGraw and have never heard of Cigital (which has been around since 1992), then you obviously know nothing about software security. Dr. McGraw (that's a dual Ph.D in Cognitive Science and Computer Science) has probably been writing and publishing about software security for longer than you have been alive.

Re:Let's not ask someone who has lots of credentia

[Anonymous Coward]

"AV engineer"?! You clearly have no idea what the article is talking about do you? Software security and end point security are barely distant cousins.

Cynical

[mclearn]

The vast majority of commentors I've seen on both /. and the article itself are all kinds of cynical and this does not help /., and it doesn't help the community. It makes me sad.

Yes, we realize that you are an amazing h4X0r capable of creating code devoid of buffer overflows, race-conditions, (all sorts of) injection attacks, etc. Perhaps you've forgotten there is a spectrum of programmers and like it or not, you are probably an AVERAGE coder. (They don't call it average because everyone thinks they are great.) A programmer will always make assumptions about the underlying environment and will always have to sacrifice security functionality in the name of time/resource-savings. And in case you haven't noticed, some systems do not actually require DoD-level security with zero vulnerabilities. They merely require a level of security commensurate with the environment it runs in. It's one thing to design a system for physical attacks or reachable through a public IP and another thing entirely to protect against measured threats within a managed network environment or air-gapped system.

There is a wide spectrum of security risks and a wide spectrum of programmers and development practices. Corporations generally match them up appropriately, which is why you don't see outsourcing of internal top-secret DoD systems out on rent-a-coder.

Re:Cynical

[Alex Belits]

Solution: don't let "average coders" write software. If standards were that low in medicine, people would drop dead right and left thanks to "average doctors" not being able to tell flu from the hole in the ground. Fortunately, "average doctors" like those are simply not allowed to practice, and only competent ones are actually treat sick people.

Software development has exactly the same problem -- decades ago all software had lax requirements, so programmers with abilities of an average shaman from a primitive tribe could be allowed to work on any project. Now this is not the case because software is more important, and people realize that requirements have to be strict. Just like with doctors, it will work just fine, as long as idiots, charlatans, retards and people with no capabilities to be a good programmer, will be prevented from doing anything that others depend on.

Re:Cynical

[Opportunist]

There is exactly one possible situation where security is a non-issue: When the person who wrote the code is also the one running the code with no other code running on the hardware used. In other words, the only application I could now think of anymore is some kind of IC firmware with no connection to any kind of network or other form of communication.

As soon as code has to interact either with unknown other programs or unknown users, or worse, other, possibly unknown machines, security becomes a topic. I have to admit I get a bit irritated if people consider security unimportant because there is nothing "important" going on on their machine. How sure can you be that the machine will never be connected to a network and possibly affect other machines? Or how about the next person using it making the assumption that the machine works according to specifications and runs something nontrivial on it?

I do expect a programmer to know how to ensure his code will not have side effects that cause harm or affect another process negatively. If the machine is connected to the internet, this also means that the process must not affect any machine on the internet negatively. It must not be possible to feed the process faulty information to cause this to happen either.

It's a sad fact that this is NOT the standard, and I'm not even talking about some kind of hobbyist project, even big companies create code that is anything but secure. Now, bugs happen and security holes do so, too. But some are just so atrocious that you have to wonder how this could be possible. Creating a structure on the stack and not checking for bounding when filling it, hell, actually taking the structure size as an argument and not checking it for sanity is asking for trouble (in case you're wondering, that was the reason of the buffer overflow exploit in the animated cursor of Windows a few years ago).

We are, just as Alex said in the other comment, in the age of the shaman coder. Few people who call themselves programmer today actually understand how to avoid such mistakes, actually with the majority I even question their ability to understand just WHY it is a bad idea to dump structs on the stack without bound checking. They don't even know WHY they shouldn't do it, how do we expect them to understand its implications? You'd have to tell them "don't do that", and they'd probably take it as a religious commandment more than gaining the insight why it's stupid.

Since it's kinda impossible to inform people about every single possible pitfall and tripwire on their way through coding a program, bugs and exploits are bound to happen until we actually start teaching people programming outside of "here's a page where there's a code snippet from someone who had a similar problem, copy/paste and you'll be fine".

real disaster

[roman_mir]

the disasters of beginning of this century include XML. In everything. "Agile" development. IE6 and ActiveX controls. IBM Lotus Notes. "Visual" programming, especially mixed with UML and RUP. Passing parameters from URLs directly to database layers as input without sanitation. Not checking data structure boundaries and sizes. Using root for everything, this one is especially nice when combined with a password, that is used for everything in a corporation. Especially when password is some variation of "adminpass1". Buying more and more BEA/Oracle licenses to set up more and more nodes where the real speed problem could be solved with very little code on a single machine, but obviously that's not sexy and doesn't buy perks. Having no testing cycles, never having enough testing, doing irrelevant testing (this even includes automated testing, which can be huge, but still irrelevant).

Producing huge meaningless documents that end up copied in email to everybody, but eventually don't get read by anybody who they should address, having template "Architecture", where past documents are copied, whatever names are replaced, no thought is given to the project and all the details are left over to the team for the time of implementation. This, especially when combined with time lines that give 80% time to meetings/architecture, 12% time to all of the development combined and then whatever remains is running around like chickens with heads cut off, from users to testers to admins, trying to get any of it working.

All of the above and more, much more are disasters.

But the real disaster here is that pathetic article that this story refers to.

Re:real disaster

[dragonturtle69]

"Having no testing cycles, never having enough testing, doing irrelevant testing"

Not properly testing is the worst flaw. We barely test if a package works, as designed, and under the planned circumstances. Testing for security just does not happen.

The cost of testing properly is likely no where near as large as the potential loss. The compromise against great and secure code in exchange for profit is made. There is no business sense in making the existing code faster or more efficient either, as the leased hardware will be swapped out for faster stuff in the next couple of years.

No, I do not like it, but, another compromise is made; we need to eat.

Re:Let's not ask someone who has lots of credentia

[FormOfActionBanana]

AllRIGHTY then. Thank you for contributing to pants.

Re:Golden Girls!

[couchslug]

"That's about as likely as a dyke at a Tea Party meeting."

"Latent" dyke or "out" dyke?

The opposite of love isn't hate, but indifference!
                                                                                                                                          8-P

You're all wrong, and will be until about 2022

[ka9dgx]

I keep watch on "security" threads like this one, hoping to find sanity in at least one answer prior to mine.... and keep getting disappointed.

You're all wrong, so far.

Why? It's simple, it's not an application programming issue, it's an Operating System design issue.

The default permit environment present in everything except IBM's VM is the root cause of 99% of our problems.

Instead of giving each PROCESS a list of resources and permissions, Linux, OS-X, Windows, and pretty much everything else, does it at the USER level. (Yes, I know about app-armor, but that's a special case)

This means that all of the defenses are pointed in the wrong direction. (Imagine building a fort with 10 foot thick perimeter wall as its sole defense in the age of paratroopers and helicopters to get an idea of the scale of the problem).

It doesn't matter how careful or professionally trained the application programmers are, nor how safe the programming language used to write the application is, when the OS isn't even designed to limit what they can do. All programs have bugs, you shouldn't have to trust them not to have them.

Now, those skills and language enhancements are useful for building the operating system, especially when constructing the micro-kernel to run everything, so it's not wasted effort.

I predict we'll see stories like this for at least 10 more years, regardless of the effort or money put in, because we haven't changed our approach yet. It's going to take a few more years until the cognitive dissonance gets loud enough in peoples heads to prompt them to find a better OS, and a few more years to actually have something reasonably solid available. Until then, buckle up... it's going to be a VERY bumpy ride.

Re:You're all wrong, and will be until about 2022

[Beryllium Sphere(tm)]

SELinux addresses that. I like the idea of capabilities-based OSes, but worry that there may be a reason that projects like CapROS haven't caught on in the market.

Re:You're all wrong, and will be until about 2022

[FormOfActionBanana]

Very interesting point. But a bit of a one trick pony.
You really don't think cross site scripting or sql injection are a big deal?

Re:You're all wrong, and will be until about 2022

[Anonymous Coward]

it's an Operating System design issue.

SELinux addresses that.

Nnnnnnnnnnnooooooo.

Re:You're all wrong, and will be until about 2022

[Anonymous Coward]

I completely agree that, as far as operating system security goes, you are spot on.

It's helpful for people to realise that this isn't because OS designers of the past were stupid; they were just building protection for a completely different environment and threat model.

A world where many users shared one computer, had almost no network connectivity, and only the Sys admin ever installed software. Things are different now...

Re:You're all wrong, and will be until about 2022

[cras]

SELinux doesn't address the problem. I agree with grandparent, although I think the focus should be more about on the UI side. The really low level implementation could perhaps be addressed with SELinux, but it's not a practical solution for any GUI app currently. For example how would you prevent Open Office from deleting everything in your home dir with SELinux, while still allowing it to read and write arbitrary documents? Yeah, you can't unless you manually go changing the labels every time you want to write somewhere.

I thought about how to implement an actually secure operating system in 2004, where you could safely just run any random program from internet, but no one cared to listen and I moved on.

Re:You're all wrong, and will be until about 2022

[Pieroxy]

I read (part of) your paper. This seems overly naive to me. If a program is hidden from the taskbar, it is effectively running in the background and can do any kind of access. If this program has a security flaw, it is a gateway to malware just as much as current operating systems are. Granted, the malware will run in userspace. But if your program is an FTP server (for example) it will have RW access to all your drives. Hence, the malware will feel right at home.

Now, what you propose is likely to reduce malware as we know it. But I believe malware will react and adapt.

Re:You're all wrong, and will be until about 2022

[cras]

I wasn't planning on fixing all of security problems, but the typical case of clicking open random email attachments or running random programs from internet should and could be made safe, while still keeping the user interface user friendly. Those are the reasons for most of today's security problems.

Re:You're all wrong, and will be until about 2022

[ka9dgx]

Thanks for giving me a different viewpoint to consider... you've covered a lot of ground in that write-up.

I like the idea of giving access to write to an email address as a privilege supplied to a program, instead of letting it just spam the world.

I'd to the same thing when it came to reading from a website, perhaps filtering to the domain *.slashdot.org, for example. If the user wanted to follow a link outside the domain, they would have to drag/drop the link into something outside the browser's control to get authorization, and continue. Letting the user set up a double-click shortcut way of doing links would make it close enough to browsing as it's done now to be acceptable.

I'll be reading this a few times to really let it sink in... thanks so much!

Re:Let's not ask someone who has lots of credentia

[Beryllium Sphere(tm)]

Multiple published books (useful ones) aren't credentials?

Anyway, an AV engineer wouldn't necessarily be the person to listen to about SDLC.

Re:CapROS

[ka9dgx]

The reason things like CapROS haven't caught on is inertia... it's a huge pain in the ass to move things to a different desktop, let alone a completely different operating system, where you have to rewrite things, and adjust to a whole new set of annoyances.

The IBM VM model of things is a pure capability model, you give RAM, DISK, and I/O to a virtual machine, and it can't exceed it's authority. Of course the granularity is a bit rough when you have to do it in terms of disk systems instead of specific files, folders, etc. The need to have a system admin set things up, which isn't very user friendly either, so it's clearly not the exact way things will end up when capabilities go mainstream.

I see the easiest way as looking just like Windows, Linux, etc... except the shortcut to an application also includes a list of files, resources, quotas, etc... this would allow things like Accounting Applications which can't access the internet (unless you change their settings), etc.

Eventually, people will figure it out, but it's going to be a LONG wait. In the meanwhile, the insecurity of everything will get used to sell a lot of software, firewalls, etc... and the worst part is it offers the perfect excuse for filtering and censoring the internet.

I'm glad to see you here... now there are at least 2 of us. ;-)

Re:CapROS

[Anonymous Coward]

The IBM VM model of things is a pure capability model, you give RAM, DISK, and I/O to a virtual machine, and it can't exceed it's authority. Of course the granularity is a bit rough when you have to do it in terms of disk systems instead of specific files, folders, etc.

Not that I don't agree with the rest of the post, but lauding (what seems to me as) a hypervisor for security is a bit off-track. What good does the hypervisor being iron-clad secure if one can compromise every virtual machine?

Re:CapROS

[ka9dgx]

Well, the damage is limited to that specific machine, unless there are connections between the VMs. The principle of least privilege is a very powerful firewall if used correctly.

All operating systems should serve as a supervisor for the tasks running, that's why there are more than 2 rings of privilege in most CPUs. I'll go so far as to predict that eventually Linus will end up moving Linux to a micro-kernel system, but that's about 20 years from now.

The reason VMware and other virtualization is so popular right now is because it effectively does what the OS lacks... protecting things from damage. Instead of having multiple applications on a server, you just spool up a new server for each new application. It's darned close to the IBM VM model, all over again.

evolution of the security industry?

[microphage]

"Perhaps no segment of the security industry has evolved more in the last decade than the discipline of software security"

The only thing that's evolved is the amount of money lost to the `software security' sector and I stooped reading after seeing Microsoft in the same sentence as `Secure Code':

`We've also published books like "Writing Secure Code," by Michael Howard and David LeBlanc, which gives all developers the tools they need to build secure software from the ground up' - Bill Gates Jan 15 2002

`Microsoft won an industry award for innovation, for its book "Writing Secure Code", by Michael Howard and David LeBlanc, which forms the basis for the company's own efforts to make its products trustworthy' Apr 2003 link

Review ..

Re:evolution of the security industry?

[CaptainJeff]

Writing Secure Code, from Howard and LeBlanc, is an *excellent* book on the topic. It's somewhat Windows-centric, and somewhat outdated right now, but all of the application security fundamentals are in there and they are all explained very well.

Re:evolution of the security industry?

[gemcigital]

WSC is a good book. So is the SDL book by Lipner and Howard.

Probably the best book on security for builders to read is "Security Engineering" by Ross Anderson,

I happen to think that "Software Security" is good too. Then again, I wrote it.

http://www.amazon.com/Software-Security-Building-Gary-McGraw/dp/0321356705/ref=sr_1_1?ie=UTF8&qid=1314456538&sr=8-1

gem

Security can't be automated

[satuon]

C is not insecure per se, it simply requires that all the securing is done in the source code. One of the most important principles of C as I understand it is that no hidden actions are performed in the binary that are not written by the programmer in the source code, i.e. the compiler never adds code on its own. Bounds checking would be just that - silent code that executes in the binary but is not there in the source code. Destructors and a garbage collector would fall in the same category.

I understand that programmers not always write code carefully, and if they don't, C won't help there, but I don't think security can be automated anyway - for example, can you make a compiler that prevents you from writing code that's vulnerable from SQL or shell injection?

Software Security drivel

[Stonefish]

Buffer overflows, formal techniques, specialist languages were all created decades ago, Bill gates wrote the trustworthy computing memo because of the bad press that MS was getting, it was pure marketing. Systems from other vendors have evolved to provide smaller attack targets upon install that they did a decade ago. This is system design not software techniques.
This guy is a knob blowing his own trumpet.

Re:Let's not ask someone who has lots of credentia

[Anonymous Coward]

I'm a full fledged audio visual engineer! Yeehaaw!

Ask me about software sekkurity!

Re:Let's not ask someone who has lots of credentia

[CaptainJeff]

Gary McGraw is a very well-known and well-respected individual in the field of software/application security.

Re:Let's not ask someone who has lots of credentia

[hesaigo999ca]

The ignorance comes from the trolls such as you who would have to use such offending words on the internet.

I would have to agree with you, considering that when I went on the citigal website, it looked like it was made from small budget templates...
and that whoever is running that company felt it necessary to give us detailed info on Gary at this link http://www.cigital.com/gem/
funny though, no other employees have their faces , lives, religion, wives name, and dog's favorite treats listed on the website.....hmmmmm.
I guess that does show major signs of professionalism on their part. I did read they had sister offices all over the world, but you and I both know
all we have to do is find another like minded firm that would want to share namespaces and allow to use their offices to be able to call yourself global.

SO with that in mind, I would like to let you know I have found an office in russia, that is allowing me to partner with them, and they have been in IT business since 1990 and they have a department dedicated to security within the company for which I am consulting for, so now I will put up my own website,
put on there that I have been in business since 1990 AND also I have offices in Russia (the best haxors in the world) and have a multitude
of dedicated consultants to help anyone who wants to pay me..... awesome business model.....I think I like tit very much....thanks for the idea!

Re:Let's not ask someone who has lots of credentia

[hesaigo999ca]

LOLOLOLOLOLOLOLOLOL

Of course even if we RTFA , we would have to take their word that whatever is in it is 100% fact and truth...... ^_^

Re:Cross site scripting

[ka9dgx]

Cross-site data leakage IS a problem, of course...

One of the good design ideas that comes up when describing or building capability based security is the idea of moving file dialogs OUTSIDE of the control of the application. If done properly, the user might not even notice the difference, which is a very good thing.

If we move the selection of web sites outside the control of the browser in the same fashion, you could then add facilities to filter, log, proxy, etc... without the need to do anything different in the rendering part of the browser. Most of the code for a port to a capability system would survive intact, it's only the source dialog boxes and linking behavior that would have to be tweaked.

If you have a browser that works in a capability system, you would drop a connection to the web site into it, that connection could be restricted in any arbitrary number of ways by the OS, and by other helper filters it pipes through.

C/C++ a disaster? No!

[Skapare]

The author clearly does not understand programming languages if he says that, or else he's one of those kinds of programmers that just needs to stay away from languages that let you do whatever you want.

C and its somewhat object oriented cousin C++ are just tools to let programmers do whatever it is they want to do. If you know the languages and how they work, you can make whatever you like. You can make insecure programs. Or you can make secure programs. Your choice. What C and C++ suffer from is the stain of blood splatters from programmers that simply do not know what they are doing. Too many programs were written insecurely, not because the language forced them to, but because these programmers didn't know how to write different code into the programs that would make them secure.

I do admit that C has a few flaws, like certain functions that fail to properly test for string overflow conditions. One example is sprintf. Use snprintf in its place so the size of the target is known and checked in the function's own logic. But these are things good C programmers already know about.

I have my doubts about any other language. If a language is flexible enough to develop a major application with, then that language is also flexible enough to let an idiot write an insecure program. However, other programming languages might be useful to C and C++ to draw away the bad programmers. Let those other languages suffer from them for a while. Java certainly has in more recent years.

Re:Let's not ask someone who has lots of credentia

[hesaigo999ca]

Yes he has many published books on the subject of code security and java security and the like. He has also been on the board of directors for IEEE.
He is a great guy.

Re:Let's not ask someone who has lots of credentia

[gemcigital]

Here, try this one on for size:

Software Security

http://www.amazon.com/Software-Security-Building-Gary-McGraw/dp/0321356705/ref=sr_1_1?ie=UTF8&qid=1314456538&sr=8-1

gem

Re:C/C++ a disaster? No! (uh, YES!)

[gemcigital]

You know, Skapare, even Kernighan and Ritchie admit that C has serious security problems. I've talked to them both about it. As for C++, it is a complete dog of a language that would be best stricken from the planet.

You may snicker, but I am a scheme programmer at heart.

gem

Re:Let's not ask someone who has lots of credentia

[hesaigo999ca]

Fits well, nice and snug.....can't really complain about not being published....or was that my initial post at all?

Re:Let's not ask someone who has lots of credentia

[FormOfActionBanana]

Well, as promised, I really am happy to be proved wrong. You are correct, I was rude and as intelligent people have demonstrated, I could have disagreed, been corrective, and been instructive, without using rude language. I was wrong and my current "Flamebait" moderation is correct. So I apologize for that.

You're also correct that Cigital has a super hokey website.

I don't know if you've written any books on antivirus, but Gary McGraw has published 11 according to his Wikipedia page.

Good luck with your consulting company. I think any intelligent customer shouldn't care how many years you've been in business. They should only worry about:

1. Are you trustworthy? and
2. Will you do a good job?

Re:Let's not ask someone who has lots of credentia

[FormOfActionBanana]

I forgot important disclaimers!
1. Cigital is my competitor, and
2. I wrote the original Wikipedia entry for Gary McGraw

Re:Let's not ask someone who has lots of credentia

[hesaigo999ca]

There I have to applaud you for...
a) apologizing, something I never see on this site...
b) for being on the money about your comment Are you trustworthy, and will you do a good job.

I know he has written many books, and I am sure he is a great guy, but too many times /. has been used to springboard bloggers
and consultants careers based on nothing but sheer popularity ....so in return I have not read any of his books, but I do claim that just
because someone has written books, (of which even I have been published...) does not make someone an expert.

It is the peers within that community that usually recognize someone's persistent contributions to the field.
Security has become very vast and encompasses so many things today that were not even present 12 years ago when I came into the field.
I would never claim to be a haxor, nor a security specialist (something I think more of the people working at the NSA)....

My basic thoughts are as follows...if he has a hoaky site where by he has a whole page to talk about his personal stuff (religion, marriage little zen image etc...)
I feel maybe that this site is really hosted / ran by this person. Any real big corporation or company in the security business would never plaster anything
as such, thereby taking away any credibility they have. Also if he was really that great (top 10) to make some feel like what he says should weigh as much as gold....then he would have bigger accomplishments to his name (such as worked for the gov. or NSA, or etc....) but the only thing I have noticed when reading up his (small, and self maintained?) page on wiki, is that he has IEEE experience (again something anyone can get ....just for contributing).

I do not knock anyone, my point was more to show that again /. was posting a story about someone's claim that the (add your industry type here)
is (add your action type here) and that based on his professional opinion, they should (add your basic solution to a problem here)....

I just prefer the true stories with facts, like maybe the up and coming technologies on their way, or maybe how someone hacked a device to do something else ...etc.... . The stories about opinions on this and that are just that ...opinions... if he read any of the reports that some of the higher technology specialist in the security industry have to say about the current US status with regards to defense and real time infrastructure or lack of working within the government such as at the NSA or USCYBERCOM or DOD....he would see that maybe we are exactly where we were 10 years ago....still very unprotected, with just a lot more
spending going on to feel like we are protecting ourselves and our computers from unwanted attacks, viruses.

Anyways, I wish you all the best in your future and hope to see you around on /. again,
it is always nice to share view points with each other when everyone remembers we are all just here to share a good time and our humble opinions....even though they are just that....

                                            : )