NSA Says Its Secure Dev Methods Are Publicly Known

Trailrunner7 writes "Despite its reputation for secrecy and technical expertise, the National Security Agency doesn't have a set of secret coding practices or testing methods that magically make their applications and systems bulletproof. In fact, one of the agency's top technical experts said that virtually all of the methods the NSA uses for development and information assurance are publicly known. 'Most of what we do in terms of app development and assurance is in the open literature now. Those things are known publicly now,' Neil Ziring, technical director of the NSA's Information Assurance Directorate, said in his keynote at the OWASP AppSec conference in Washington Wednesday. 'It used to be that we had some methods and practices that weren't well-known, but over time that's changed as industry has focused more on application security.'"

Comments

Here's proof that...

[Anonymous Coward]

...it is definitely possible to write secure software if you just simply follow sound and smart development methods and practices... and don't write half-assed, slipshod, thrown-together-in-a-hurry code.

Re:Here's proof that...

[mrheckman]

...it is definitely possible to write secure software if you just simply follow sound and smart development methods and practices... and don't write half-assed, slipshod, thrown-together-in-a-hurry code.

Proof? I don't see any proof in the article that the NSA produces secure software, or even a claim that they do. Instead, the NSA Technical Director quoted in the article said "even within the NSA, the problems of application security remain maddeningly difficult to solve." That doesn't sound like they have solved the problem, but that they, too, are grappling with a fundamental issue in software development.

Re:Here's proof that...

[Mr. Freeman]

It's not necessitate proof of anything. Are the NSA's applications actually bulletproof? They might distribute their coding practices but I'm pretty sure they don't distribute their source code or their applications. Therefore, no evaluation of their security can be made. Therefore, there's no evidence to show anything about the quality of their practices.

I'm not saying they're wrong. In fact, evaluation of other, open, software indicates that security does stem from good coding practices. I'm just saying that there's really no reason to point to the NSA as an example of being quality.

Re:Here's proof that...

[phek]

actually you're wrong, they do distribute the source code to their applications whenever they can (their code is often just modifications to proprietary software at which point they can't redistribute it). SELinux is a good example of this, it was started and originally released/maintained by the NSA.

There is absolutely no reason (other than copyright violations) for the NSA (or any other government agency) to not release more secure methods/code. Doing so will provide our nation with a more secure infrastructure making their job easier. Things such applications to break security are a different subject though.

I'm sure they have plenty of those applications which they don't want released to the public so that people don't know how to protect against that.

frist psot

[Anonymous Coward]

the nsa is pants

Re:frist psot

[Anonymous Coward]

This post is now diamonds.

Re:frist psot

[Anonymous Coward]

Sega cds are now in super nintendos.

I see it more like a proof that

[e065c8515d206cb0e190]

security doesn't come from obscurity

Re:I see it more like a proof that

[Jeremiah Cornelius]

"Trust us. Honesty is our business."

-- Sincerely, the 'Spooks'.

Re:I see it more like a proof that

[Applekid]

That's a closed source/open source distinction. It has nothing to do with development methodology... except that there are more eyes when it's open.

Depending on whose eyes for closed source, I'm pretty sure the NSA has plenty of great eyes looking over code.

Re:I see it more like a proof that

[icebike]

security doesn't come from obscurity

Exactly right.

The best security is the kind where everyone knows how it works, but even given the source code, you can't beat it, or you can't beat it in any useful length of time.

That being said, the automated code inspection packages you can buy these days look only for the obvious noobie programmer mistakes.

SELinux, originally from NSA, solves many of the problems of running untrusted code on your box, but even that is not 100% secure, and the maintenance problems it introduces mean that it is seldom used in real life.

The problem is not how this agency (the NSA) cleans up their code.

The problem is that we don't know about what backdoors exist in our hardware and our operating systems. Because so much code is embedded in silicon, and so few people actually look at that code, its easy to imagine all sorts of pownage living there.

A compromised Ethernet card (just sayin by way of example), would be both Obscure, and hard to detect, and have access to just about everything going in and out of your machine.

Security does not come from obscurity, but insecurity often does.

Re:I see it more like a proof that

[Locke2005]

Why would a compromised Ethernet card be any more dangerous than a compromised Ethernet cable, which presumably their networks are designed to protect against? In other words, wouldn't all data that the Ethernet sees already be 1024-bit encrypted?

Re:I see it more like a proof that

[icebike]

Because the card has smarts, and the cable does not.

Because the card lives on your bus, and the cable does not.

But try not to belabor the point, as I said, it was just an example. Substitute any other device resident in your computer which you feel better demonstrates the point.

Re:I see it more like a proof that

[LWATCDR]

Programming is math. There really are no secrets in math. It is the same everywhere.

Re:I see it more like a proof that

[Jeremiah Cornelius]

Theory and Practice.

Different.

Re:I see it more like a proof that

[K. S. Kyosuke]

Actually, programming is one of the few disciplines where practice can be exactly the same as the theory - the bits and bytes are all the same, they don't break from material fatigue; and if you write software for which you have a proof of correctness, it will simply work correctly. Few other branches of human endeavor are free from the evils of the material world to such a degree.

Re:I see it more like a proof that

[Anonymous Coward]

Unless you've implemented every bit of the software stack, from the firmware to the OS to the compiler/runtime to the applications then you could potentially have issues.

So I think the "theory and practice are different" might still apply, as nobody has the luxury of the time to formally prove all elements of all these things. It would be a Herculean undertaking.

Re:I see it more like a proof that

[sam31415]

In most cases, this is true. In paranoid cases, however, I suspect Ken Thompson would disagree with you.

Re:I see it more like a proof that

[blair1q]

Disagree. Having a correct methodology is more efficient than having many extra eyes that aren't following any particular methodology.

The trick is having a correct methodology, and applying it correctly.

Re:I see it more like a proof that

[Jah-Wren Ryel]

Because the card lives on your bus, and the cable does not.

More specifically most devices on the bus can do DMA to host memory, that enables them to read and write any byte of memory, completely bypassing OS memory protection.

In fact, firewire ports are a favorite of the digital forensics guys for exactly this reason - they can come along, plug their dohickey into the firewire port of most any PC that has one and do a complete memory dump of the system without the OS or any other program even noticing.

Re:I see it more like a proof that

[Zero__Kelvin]

"So I think the "theory and practice are different" might still apply, as nobody has the luxury of the time to formally prove all elements of all these things. It would be a Herculean undertaking."

Even if you did have an infinite amount of time, there may also be errors in the proof. Even then, if all proofs are indeed 100% correct, one still runs into Godel Incompleteness and what might be thought of as a variation of Heisenberg uncertainty (i.e. the act of measuring changes the results), especially in hard realtime systems, where all possible permutations of the input stimulus can never truly be known.

Re:I see it more like a proof that

[LWATCDR]

What?
You have taken two theories that you do not really understand and have mixed them up as bad as that stupid book Zen of Quantum Physics.
"Heisenberg uncertainty principle states by precise inequalities that certain pairs of physical properties, such as position and momentum, cannot be simultaneously known to arbitrarily high precision."
That has nothing to do with Godel's theorem except that both are taken as proof that the Universe is not deterministic. They are not in any other way related

And Godel does not imply that you can not prove that a program is correct. In fact if you read the wikipedia links you posted you would see that.

Re:I see it more like a proof that

[Stray7Xi]

Actually, programming is one of the few disciplines where practice can be exactly the same as the theory - the bits and bytes are all the same, they don't break from material fatigue; and if you write software for which you have a proof of correctness, it will simply work correctly. Few other branches of human endeavor are free from the evils of the material world to such a degree.

I disagree. If you're programming the OS it might be true (with narrow hardware compatibilities). However as soon as you write an application for a user, theory is useless. Users do the strangest things to their OS. One user might throw away all RST packets at the firewall because they read about sandvine when comcast was throttling. Another user tried to fix his own windows box, deleting important windows registry keys, so explorer freezes randomly. Another user overmounted a directory over /etc, so now there are users logged in that don't exist in /etc/passwd. All of these will break even the most basic assumptions an application programmer would have.

If your theory is broad enough to cover real-life scenarios with real screwed up people then "In theory" is the same as "In practice". But if your theory is that good then there is no point in testing software.

Re:I see it more like a proof that

[Jeremiah Cornelius]

Thank you.

Someone who has written software outside of class.

Re:I see it more like a proof that

[Zero__Kelvin]

First of all, I said that it could be thought of as a kind of Heisenberg uncertainty... and then qualified what I meant with a parenthetical, which alluded to the Observer effect. This is known as desirable conflation. Secondly, if you cannot figure out how Godel incompleteness comes into play in a discussion about using mathematical theory to prove an almost infinitely complex set of axioms, then trying to explain it to you is certainly a fools errand, even if I cannot prove it ;-)

Hint: From the very page you say says nothing about same:

"The second incompleteness theorem shows that if such a system is also capable of proving certain basic facts about the natural numbers, then one particular arithmetic truth the system cannot prove is the consistency of the system itself."

Re:I see it more like a proof that

[LWATCDR]

You are confusing a mathematically correct program one that will do the "right thing" no matter what the input is.
What a correct program will do is only behave in a deterministic way.
And example would be is if Explorer was a "correct" program and you deleted some registry keys it would exit with an error message. If a program finds any input state that is outside of a specified range and that can not be healed should terminate with an error condition. That if the OS was also "correct".
The real problem becomes one of cost. Very few applications are worth the cost of doing all the work to make it "correct". You will see in aerospace applications but almost no where else.
And even FOSS software has cost. The programmers will often pay a large amount of the cost themselves. But even the users will have to pay some of the cost in that it will take a lot longer to get the software and any new features.

The other cost is that the system must be "correct" from top to bottom. That is why the Shuttle doesn't use an I7 and why it takes so long and costs so much to get software and hardware upgraded in those type of systems.

Re:I see it more like a proof that

[Anonymous Coward]

Except that specific programs have a "finite" number of axioms.
Here is a trivial example.
You can write and prove a program that when fed a list of three integers of 32 bits or less will always return the largest. The range is limited so it is provable.
Most all programs deal with finite datasets and computers have a finite set of states. Godel deals with infinite systems.
Godel states that not every possible program can be proven it does not state that no program can be proven.
The key is to limit the input data. Once you do that the system can become deterministic and then provable.

Re:I see it more like a proof that

[Anonymous Coward]

You can talk about "Zero Kelvin", "Godel Incompleteness", "Heisenberg uncertainty" and other "geeky concepts" all you want. As long as you don't understand them, your assertions will continue to be nonsenses.

Re:I see it more like a proof that

[blueg3]

Except that that technique is not widely used, since it's extremely prone to failure (usually resulting in a blue-screen or such). As a fragile technique that requires a specialist on hand when you encounter a live machine, it doesn't see a whole lot of field use.

Re:I see it more like a proof that

[Jah-Wren Ryel]

The only fragility I'm aware of is this easily avoidable situation:

http://www.ntsecurity.nu/onmymind/2006/2006-09-02.html

Maybe the forensic toolkits are just naive.

Re:I see it more like a proof that

[Thinboy00]

"Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth

Re:I see it more like a proof that

[TheLink]

Or the "specialists" just want to be paid more ;).

Re:I see it more like a proof that

[RMH101]

Or "In theory, theory and practice are the same. In practice, they are different"!

Re:I see it more like a proof that

[Anonymous Coward]

s

(re: /. Filter error: You can type more than that for your comment. Thanks. I don't want to)

Re:I see it more like a proof that

[shentino]

Except from hardware glitches.

Re:I see it more like a proof that

[jvkjvk]

Security does not come from obscurity, but insecurity often does.

Security comes in many forms, and obscurity is actually quite a good form, as long as there are other layers.

The "best" security comes from defense in depth and obscurity can certainly be part of that, and in fact probably should be. I will go through a few different layers where security by obscurity actually works quite well.

Consider a random binary on Usenet. Even if I 'encrypt' the payload with ROT-13 I have achieved a decent amount of security simply through obscuring the target in a sea of ones and zeros.

Now, consider the challenge-response system. It used to be that some systems would tell you whether your username, password (or both) was bad. It turns out that this lack of obscurity allows attackers quicker access to systems, since they can hit upon usernames by letting the system tell them which were valid. Simply obscuring the error response fixes this.

And this brings up a good point about obscurity as a security practice. If you use it - don't tell anyone! You would have thought this was a "duh", but the previous example is a great one in that regards. Usernames are simply obscured data, but if the login system can be used as an oracle ... not so much.

Now, on a systems level, network security is often predicated on obscurity - that's why you don't find many companies publishing their internal network maps! If those maps were published, then attackers would have a much easier time to penetrate the organization. Security by obscurity.

Now, on a home level, if I am using port knocking (as one example) as one means of controlling access to ssh, then every attacker that does not know this will fail out of the box. Of course, it is better if I also have key exchange turned on, and even moreso if that and password enabled. But, even moreso if I simply run it on a non-standard port - which is security thorugh obscurity.

So, while I wouldn't rely strictly on security through obscurity (except in cases it makes sense), it is a valuable tool in a security toolbox, and generally can be a show stopper for an attacker if they aren't able to obtain the knowledge. But again, security comes from defense in depth, and one layer of that depth should be considered obscurity.

Regards.

Re:I see it more like a proof that

[TheRaven64]

except that there are more eyes when it's open

There are potentially more eyes. In practice, a lot of open source code is only ever read by its author, or occasionally by the person committing it if that's not the same person. In contrast, NSA code will go through a code review process that ensures that several people look at it.

A significant part of the point of pair programming is that it ensures that at least two people have read the code, which is one more than a lot of code gets (open or closed).

Re:I see it more like a proof that

[Anonymous Coward]

Unless your OS is using the IOMMU correctly at which point it can't actually read the entire memory space.

Re:I see it more like a proof that

[K. S. Kyosuke]

Unless you've implemented every bit of the software stack, from the firmware to the OS to the compiler/runtime to the applications then you could potentially have issues.

Actually, it's even better to use your own CPU - possibly something based on MachineForth. Mind you, modern CPUs have bugs as well.

Re:I see it more like a proof that

[Jah-Wren Ryel]

Unless your OS is using the IOMMU correctly at which point it can't actually read the entire memory space.

100% true. I considered mentioning that, but IOMMU's are still pretty rare outside the server room. Plus, sadly, most people here don't even know what an IOMMU does.

Of course they say that

[dkleinsc]

If the NSA has something that really is Schneier-proof, they wouldn't tell the public. And understandably so, since part of their job is in part to ensure signal security for US agencies that deal in classified information.

Re:Of course they say that

[hedwards]

But it's almost certainly true. Just look at OpenBSD's record. They went for a full decade without any vulnerabilities in the base system before one was eventually found. And that's from a group of mostly volunteers. Just imagine what you could get from programmers that are both paid and required to use secure coding practices.

What's really embarrassing is that most of it has been known about for quite some time, but for one reason or another the organization funding the programming doesn't feel like paying for it to be done securely. It's a similar problem to programming style.

Re:Of course they say that

[MozeeToby]

It's just software, we're not talking about something that takes billions of dollars worth of resources to produce. If the couple hundred software guys that the NSA employs can think of something, you can put good money on at least one of the hundreds of thousands of software guys that don't work for the NSA coming up with a similar idea. Now, if we were talking about some novel decryption scheme sure, there aren't that many people working on that outside of intelligence circles. But we're talking about writing secure, consistent software, something that is of interest to every CS and CE professor in the world.

Re:Of course they say that

[lewiscr]

Just imagine what you could get from programmers that are both paid and required to use secure coding practices.

Windows XP?

Re:Of course they say that

[jd]

It depends. The best place to hide something is in plain sight. And the best way to hide encrypted somethings is in a sea of equally encrypted somethings. If the NSA had some algorithm that they felt OK with others knowing and also using themselves, then any traffic of theirs using said algorithm would be indistinguishable from any other traffic. An attacker would need to decrypt everything in order to establish whether or not anything was being sent that was of interest. Even if there was a vulnerability in the encryption that reduced the search space to something theoretically manageable, having to break each and every single conversation on the Internet would push the search space back into the unmanageable region.

ObSidetrackingRant: This is why sites that use SSL should use SSL for everything - it adds noise which conceals the encrypted packets which would actually be of interest. Don't forget that the biggest weakness in secure systems is context. If you have enough context, you can bypass a lot of system security. A simple example would be the "secret question" systems that are popular. If you know enough about a person, the odds are high that you can guess what the answers are. Another example would be social engineering - if you have enough personal information, you could pretend to be that person to a system admin. Social engineering is really the sum total of all the new cracking/viral methods that are being used these days. Far from being new, it's merely better-automated and better-documented. Social engineering was standard back in the BBS days.

Re:Of course they say that

[LWATCDR]

Security doesn't sell in the consumer market.
Mainframe and Minicomputer OSs and applications tended to be very secure. VMS and IBMs OS where and are very secure. PCs come from the microcomputer world. Security was never an issue with them. I mean they where single users systems and almost never networked. Even when you had Networks they tended to be Lans.
It is the mind set that security is an after thought. Why should a picture viewing program ever worry about an exploit?

On the PC side it just was never a "feature" worth putting any effort into until recently.
 

Re:Of course they say that

[forgottenusername]

Be serious, the government would never lie to us.

Re:Of course they say that

[phek]

it may just be me, but as someone who has been a sysadmin and developer for high traffic sites, making everything on a site https isn't practical at all. https uses a LOT more resources than http. you would roughly need 3 times the number of servers to hide something that's already encrypted. a MUCH better solution would be to use only strong, non-anonymous ciphers for your encrypted pages.

Re:Of course they say that

[drsmithy]

But it's almost certainly true. Just look at OpenBSD's record. They went for a full decade without any vulnerabilities in the base system before one was eventually found.

Remote vulnerabilities. In the default install. Which isn't that hard to achieve when your default install doesn't really do much and hardly anyone uses your system.

Just imagine what you could get from programmers that are both paid and required to use secure coding practices.

Who didn't have to work towards any specific deadlines or goals ? And had essentially nothing to lose if they didn't get there ? I'd expect much the same.

When you have nothing in particular to achieve, all the time in the world to achieve it, and no real consequences if you don't, then you'd expect anything that was done would be done well. However, the real world doesn't work like that.

Re:Of course they say that

[Anonymous Coward]

Security doesn't sell in the consumer market.

For 2 good reasons...

1. Security is diametrically opposed to ease-of-use.
2. General consumers don't understand what "security" truly means. They think "secure" means "system won't let determined user install spyware". No system can be "secure" like that so they have no faith in the notion and this amplifies Point #1.

General consumers will get more accustomed to proper computer usage as time goes on, but will never truly be hardened as secure users. Just won't happen. For this reason, viruses will always exist and antivirus companies will continue to stay in business.

Re:Of course they say that

[LWATCDR]

I do agree with number 2.
Not so much on number 1.
Yes if you run a program and then give it admin access to your system it is not a software security issue. It is a user IQ issue.

Re:Of course they say that

[jonwil]

In the consumer space (Windows specifically) security is often at odds with backwards compatibility. (including compatibility with things at the other end of a network link)

I am suer there are hundreds of changes to Windows that could be made that would make Windows more secure except that it would break backwards compatibility so the changes cant be made.

Re:Of course they say that

[Zero__Kelvin]

"PCs come from the microcomputer world. Security was never an issue with them. I mean they where single users systems and almost never networked. ... On the PC side it just was never a feature" worth putting any effort into until recently."

Unless when you say "recently" you mean since 1993 then you are quite mistaken.

Re:Of course they say that

[Anonymous Coward]

But it's almost certainly true. Just look at OpenBSD's record. They went for a full decade without any vulnerabilities in the base system before one was eventually found.

Ouch! How did THIS get modded Insightful?

The truth is that OpenBSD has had several vulnerabilities in pretty much every release: just check out the errata. OpenBSD 4.7, for example, had two security fixes applied to it; 4.6 and 4.5 had three each; 4.4 had four; 4.3 had eight; 4.2 had nine; 4.1 had ten; 4.0 had eleven; and so on. And that's not counting reliability fixes.

That said, these holes are either local, or limited in their impact; the two holes that were eventually found in OpenBSD were *remote root* holes. (On a side note, it did not take "a full decade" for one of these to be found: it was about 5 years.)

Now, none of this is intended to rag on OpenBSD, BTW; the developers are doing a great job, and their diligence in actually responding to vulnerabilities and promptly issuing fixes is laudable. If anything, it shows that even when you're very diligent and extremely focussed on security, vulnerabilities will STILL happen: not just the rare huge ones but also many run-of-the-mill smaller ones.

Re:Of course they say that

[TheRaven64]

It's worth noting that the OpenBSD folks regard potential DoS attacks as security holes, so things that cause a crash but no possibility of an attacker gaining control or accessing more than they should are counted as security holes. This makes their list of security fixes bigger than it would be with some other projects, which only regard this kind of problem as a reliability issue.

Re:Of course they say that

[LWATCDR]

Please there was Unix before Slackware for the PC. And no security wasn't a feature that sold or was even much of a worry even in 93.
Security as a feature that sold in the consumer space? Windows 95, 98, ME all show clearly that it wasn't. Windows 2000 and XP where big leaps forward. Vista is ME 2.0 and will soon be forgotten. Seven is much better.
BTW Unix in 93 also was not all that secure. No ACLs and telnet and FTP where commonly used and SSH wasn't even released until 1995! and then it took a while to catch on.
As I said it wasn't really a feature worth putting any effort into until recently for the consumer space.
Linux is not strong even now in the consumer space outside of embedded applications.
So yes I stand by every word.

Re:Of course they say that

[jd]

HTTPS uses more resources because people use software encryption (which is expensive). If you used hardware acceleration, you'd have no overheads at all at the machine level. You wouldn't need even one extra server. And hardware acceleration doesn't cost the same as 2 beefy servers.

Secondly, you're not limited to HTTPS - most firewalls are quite capable of supporting IPSec in opportunistic mode (ie: keys are generated and exchanged at the time the tunnel is set up). It serves much the same purpose, in that all data going off-site is encrypted.

The use of strong ciphers relies on the ciphers being strong. A cipher can be broken at any time and unless the person breaking it tells you, you do not - and cannot - know they have done so. Relying too heavily on the strength of the cipher alone is not a good approach.

This is why the DoD mandates that users of encrypted telephone systems should keep open context to a minimum and enable the encryption as soon as possible. Chit-chat, however innocent, can help an attacker know what they are to look for and how they should look. I think it safe to say that if the DoD trusted strong ciphers alone to do the job, they wouldn't be so paranoid.

(Indeed, if encryption alone were sufficient, you'd see classified material - albeit encrypted - on unclassified networks. Again, that is verboten. Those with their jobs, egos and indeed purpose on the line do not trust encryption to ever be strong enough on its own.)

Ok, what about all those admins who can't even afford a cheap accelerator card? (And by "cheap", I would include any card that carries an FPGA large enough to hold one of the public, open-source cryptographic hardware implementations and is also fast enough to out-perform a pure software solution.)

Well, is the firewall capable of acting as a secure proxy (ie: providing all the SSL)? If so, what's the problem? There's nothing that requires the web servers themselves to do the SSL in order for the Internet to see SSL.

If not, then can you afford a server that has a beefy processor but minimal memory (diskless is fine) that can act as a secure proxy in a DMZ-type situation? All it needs to do is handle SSL traffic to the outside world and non-SSL traffic back to the web servers. It needn't even run a true OS.

If you can't afford a DMZ and can't afford a cryptographic NIC or crypto engine, then you probably can't afford to maintain what hardware you do have. (A decent hardware RAID array will cost you more than a decent cryptographic system, and woe betide those with no spares, for hardware has a nasty habit of failing.)

Re:Of course they say that

[phek]

you've just made so many holes in the setup with what you've said and your DoD statement is incorrect. Per what you said, the DoD wants you to use encryption as soon as possible to avoid saying anything over unencrypted talk. That means they do trust encryption (obviously only to a point). There are plenty of ways to get information pre/post encryption which is what they're worried about and what you've presented with your other solutions.

Re:Of course they say that

[jd]

They trust encryption combined with a lack of context. I specified that they do not trust encryption WITH context. Do try and read before you bitch.

And, no, hardware encryption has no holes. Neither does encryption via an FPGA. Nor indeed does an IPSec tunnel. Not one of these offers context and all offer encryption as good, or better, than SSL.

Using a DMZ is secure, since the unencrypted network is not publicly visible. It is an isolated network. Having a firewall that only permits traffic to/from the proxy also reduces exposure. A diskless, OS-less proxy is virtually impossible to compromise (there being no logins to hack, no system commands and no privileged services).

Seems to me that your awareness of security is, well, pretty feeble.

Re:Of course they say that

[phek]

uhmm actually i work in the security industry and your setup just failed a simple pci audit.

"A diskless, OS-less proxy is virtually impossible to compromise"
If you think this is a valid statement you have no business maintaining any network.

I also have no idea what point you're trying to argue. I simply said that providing encryption for all traffic of a high traffic site isn't practical. If you have a high traffic site, then most of your data sent doesn't need to be secure. Of course there are a few exceptions such as banks, but then they should be used to not being practical and can afford a more expensive set up.
You in turn have argued that you should encrypt all traffic over the internet but its ok to have plain text over your internal network.

The reality of it is that there are budgets that IT departments have to stay within otherwise there's no reason for them to have a site/network/whatever because they'll be losing money on it. Encrypting all your traffic when in reality only 0.001% needs to be encrypted will balloon your costs.

Re:Of course they say that

[jd]

If there is no OS (ie: it's a bare-metal application), there's no user accounts, there's no shells, there's no login daemons (there's no daemons or services of any kind), there's no threads (threads need an OS), it's a pure round-robin (since anything else needs an OS).

Since there's no management (no OS, no threads), all packets are dumb. You have packets going in, getting decrypted and being passed to the internal network. Likewise, packets come in, get encrypted, get pushed out.

Because the maximum size of a packet can have is fixed, and because it's round-robin, you can use a fixed-size round-robin window with fixed-size entries in it. Therefore no dynamic memory problems. In fact you have to, since a lack of OS means no memory management means no dynamic memory.

Ok, so there's no way you can do a buffer overflow attack, no way you can do underruns, no way you can break the stack (cos there isn't one), no way to inject commands (and even if you could find a vulnerability the lack of threading means the box failsafes to no I/O if you inject an instruction).

If there's no OS, you can't have device drivers for things like USB keys or any other pluggable device. If it's a diskless station (ie: everything runs out of flash or eeprom, since there's nowhere else to get the data), other physical attacks - such as adding a drive or inserting a floppy - would do nothing.

(Even if you rebooted the machine, you couldn't do anything - no filesystem. It's a raw image.)

So if you want to tell me that a diskless OS-less proxy -is- possible to compromise, you'd best be able to prove it. None of the above is implementation-dependent, so don't weazel out. Either you're this super-cool expert that can find a way to break the above or you're not. And if you can, you'd best damn-well be able to prove it.

You have yet to prove that the above solution would "balloon costs". (Hell, you've yet to show that adding an RSA card to machines would balloon costs, given the cost of a typical datacenter.)

So I'm giving you the chance to do so. I want you to price up the cost of a complete system - two NIC cards, a chipset with built-in PRNG, 256K RAM (way more than you need, but you might even need to go higher as I'm not sure if you can buy in units that small at a decent price) and maybe 128K Flash (again you may need to buy larger) and a minimalistic motherboard. PC104 would be fine.

(You can skip the cards if the motherboard has two independent NICs built onto it.)

I want you to tell me how much that would set an IT department back, using decent components (not high-grade, just decent).

You're a fool if you think there's no value in an IT department that loses money. It is the NET value to a business that matters, not the local value.

You're also a fool if you think only a tiny fraction "has" to be encrypted - context is everything, as I said. It's how virtually all social engineers operate, it's how virtually all hackers operate. Cripple the context and you cripple them all.

If you've no idea what point I'm trying to argue, you're not much of a security guy. In fact, I'd call you pathetic.

Re:Of course they say that

[phek]

if you have physical access to the network you can simply spoof the proxy (or a target on the network). This would be especially easy to do since that proxy is being used to encrypt traffic for the network and would therefor be sending plain text over the network.

I have no idea what you're trying to argue because on one hand you want everything encrypted but on the other hand you have no problem with everything being plain text over the dmz. I also just noticed you said "Using a DMZ is secure, since the unencrypted network is not publicly visible." which is scary.

I'm not about to waste the time pricing out anything because I simply know that 3 servers cost more than 1. You could as you said buy a card which will encrypt the data for you however if you're building a server farm, one of those is going to add on about a 1/3 of the cost of each server (based on the last time i saw the price of one which was probably 5 years ago). Can you even do https over an rsa card? because the whole point here is to make traffic for public websites (and other services) encrypted.

I never said that there's no value in an it department that loses money, I said that there's no value in an it department if it's losing money for the company. That's why companies create budgets for departments, they know that having this department can increase their sales X dollars so the company will be willing to spend X - Y dollars on it.

Finally regarding context, there are much more efficient ways of removing context than trying to encrypt everything. Just because all you have is a hammer doesn't mean everything is a nail.

Re:Of course they say that

[jd]

My argument is that you're choosing the most expensive implementation of a specification and then blaming the specification for the price.

There are affordable, practical ways to achieve the same results and that totally eliminates the price side of your complaint (which, apparently, still has this fictional multiplication of servers which I've already demonstrated is not required).

If you want to argue against the idea, fine. But produce a VALID argument, not a bullshit one. I have no respect for bullshit artists.

Unless...

[The MAZZTer]

...that's what they WANT us to think...

Most...

[mbone]

It's that word most in "Most of what we do..." that may be important here. Most doesn't mean all. Also note he did not mention their cryptographic techniques, which is where I would expect them to be especially advanced.

Re:Most...

[hedwards]

But cryptographic techniques aren't where most vulnerabilities are found. Most vulnerabilities are ones which could be avoided using secure programming practices.

In fact the FBI failed to break into a set of hard disks encrypted with Truecrypt and another program using 256-bit AES. Which pretty clearly indicates that as long as you choose an appropriate encryption algorithm, the vulnerability is almost always going to be in either the implementation, user error or in access to the machine.

Re:Most...

[StikyPad]

Also note he did not mention their cryptographic techniques, which is where I would expect them to be especially advanced.

From a design standpoint, it's cheaper and more effective to leverage solutions that can be widely vetted and tested than it is to work strictly in a closed environment implementing your own solution and hoping you thought of everything. I'd frankly be *very* surprised if the NSA had anything more than potential (if promising) avenues of exploration with regards to "next-gen" encryption, and certainly wouldn't expect that they'd be using untested solutions in the field.

I may or may not know what I'm talking about, but then, the person quoted in the article may or may not have been spreading misinformation. ;)

Re:Most...

[Anonymous Coward]

Unfortuantely, "secure programming practices" often put the keys, including the master keys for replacing other keys, under NSA control. Take a good look at "Trusted Computing" and who would hold the keys. There was never a procedure enabled for keeping the keys entirely in private hands, only for keeping them in central repositories such as those owned by Microsoft. And never a procedure published for requiring a court order to obtain the keys: the entire thing was handwaved.

Looking back further, the "secure" Clipper Chip was discarded when it was discovered that people could generate their own private keys, without any central repository access. (http://en.wikipedia.org/wiki/Clipper_chip).

The NSA's mandate is not to provide security for US citizens. It is, in fact, to *break* security to monitor foreign communications. (Go read their original charter, available at http://www.austinlinks.com/Crypto/charter.html) One of their most effective techniques is to assure that commercial encryption worldwide is entirely accessible to them, and their history of ensuring this by blocking encryption they don't "p0wn" is very clear.

practical application

[Tom]

Security, especially in software development, doesn't suffer from the "we don't know how to do it" problem. It suffers from the "we don't have time/budget/patience/interest in doing what we know we should be doing" issue.

Re:practical application

[faichai]

Of course. Though budget buys time, which buys patience and 911 pretty much secured interest. Oh look: http://www.upi.com/Top_News/US/2010/10/28/US-intelligence-budget-tops-80-billion/UPI-37231288307113/

Re:practical application

[H0p313ss]

Of course. Though budget buys time, which buys patience and 911 pretty much secured interest.

Perhaps in some parts of government, particularly security oriented agencies like military, CIA, FBI and NSA. But I'd bet that in the majority of government and business 9/11 had little to no impact on security considerations for IT projects. It has certainly not impacted my software projects, and they've been sold to a whole plethora of government agencies and fortune 500 companies.

Re:practical application

[bhcompy]

Well, security also generally means performance hit, so it's also a balance of performance and security. When you're wiretapping half the nation looking for those keywords that send up red flags you gotta be lightning fast

Re:practical application

[Tom]

Mostly nonsense. Unless you are doing some really insane crypto, work with embedded systems or have unusually high requirements (some realtime applications), the performance impact of security largely doesn't matter.

Doesn't make sense

[clarkkent09]

Despite its reputation for secrecy and technical expertise, ... virtually all of the methods the NSA uses for development and information assurance are publicly known.
 
  Secrecy doesn't have to extend to every single thing. I'm sure NSA uses regular toilets too, not the top secret kind. As for reputation for technical expertise, how does using tried and tested development methods goes against that?

Re:Doesn't make sense

[hedwards]

I suspect it's more along the lines of people expecting there to be something significant that they have for writing secure code. I'm willing to bet that the only thing they have that most other organizations don't have is a substantial budget for auditing the code for vulnerabilities. They probably wait longer before deploying code as well until it's been thoroughly vetted.

Re:Doesn't make sense

[jd]

If we start with the fact that the NSA is responsible for the Rainbow Series, partly responsible for Common Criteria, totally responsible for the NSA guidebook on securing Linux, and also totally responsible for the concepts in SELinux (remember, they talk about methods not code), it follows that the NSA is implying that the processes used to develop this public information are rigorous, sound and the methods the NSA use internally for projects they don't talk about. It actually doesn't say that what the NSA publishes is what they use - they only say that methods that are public are what they use. The source is implied.

Re:Doesn't make sense

[blair1q]

I'm willing to bet they have a code base that's been fully developed using secure methodologies.

Most people don't.

Re:Doesn't make sense

[blair1q]

IOW, if you go here you'll get what they have.

Not their code. Just their style.

Re:Doesn't make sense

[failedlogic]

In a corporation, you not only have accounting, HR, managers, VPs and such looking over your budget but you also have investors. If it costs you too much to produce something of "equal" quality to a competitor, they will start asking questions. A problem with insecure code probably won't cost the company the entire business.

The NSA, I think, mostly has a black budget. There's only a few people who know how much, where and to whom (employees) this money goes to. So there's not really a budget you have to account for. A problem (leak) because of bad code or anything else could be damaging to National Security. It will also, likely, become a political embarrassment and one to the DoD, NSA/CIA establishments. The people who approve the budgets will almost undoubtedly approve expenses to account for increases in security in any area incl. programming.

Re:Doesn't make sense

[jd]

That's part of things, but not the whole of things. The CERT stuff eliminates a lot of the bugs that introduce security holes, but it doesn't really cover any of the access controls within the app or between the app and OS, nor does it really cover how to have provably secure software*.

*If you can prove that your dynamic memory library, your I/O libraries and your access control library are correct, and that all dynamic memory and I/O accesses that have the potential to do Bad Things when used without authorization are routed through the access control library, then you have provably secure software. This is NOT the same as having software that can handle provably insecure users, it merely proves that the software cannot behave other than as intended.

You don't need a whole lot of extra code or a whole lot of extra work. For example, if you had a malloc replacement library that was proven correct, you don't need to have one written for every program and you don't need to do a whole lot of cleanup in existing software.

If you also had a drop-in replacement for sockets and file I/O, again using the standard APIs but where the code was proven correct, the same thing applies.

Finally, if all these drop-in replacements made sure they called system functions protected by SELinux, GRSecurity or another security module where applicable, you've got the access controls nailed.

The only things that are needed to be 100% bullet-proof are these libraries and the security module in the kernel. Getting them to 100% is the hard part, which is why "secure" programming languages often don't allow things like dynamic memory at all and severely restrict all other channels.

Obviously, getting the rest as close to 100% correct as possible is a Good Thing, but it is actually very difficult to have provably correct software of any level of complexity. Not impossible, but very very difficult. (There ARE cases where it is impossible, but the proof of this doesn't say what cases, only that there are a non-empty set of them.)

And yet we live in the non-ideal real world

[Anonymous Coward]

Ziring said that even within the NSA, the problems of application security remain maddeningly difficult to solve.

"Very few applications start from a clean slate. They're built on the existing code bases and they have to work with other existing apps and they have to be updated frequently."

Re:And yet we live in the non-ideal real world

[jd]

Not starting from a clean slate is immaterial. A new component can be 100% self-contained (and therefore verifiably clean within itself), communicating via some intermediary layer that handles legacy APIs, network connections, pipes, shared memory, et al.

The new component can therefore be as provably secure as you want. Security holes will then be contained (they must be in pre-existing code and cannot spread into new code).

This is not often done in the business world because they're stupid and prefer to burn huge amounts covering their backsides when inevitable breakins occur rather than the relatively small extra needed to properly secure systems in the first place. (It's stupid because such a method can never be cost-efficient in the long-run and only looks very marginally better on the books in the short-term.)

Re:And yet we live in the non-ideal real world

[pavon]

Except that many, if not most, security holes come from the interactions between components, and are not contained within any single component. This is exasperated by the fact that many legacy systems don't have well-defined interfaces or their behavior does not meet the documentation. When you run up against a hole caused by crappy documentation, you can pound the table all you want about how the bug is in the legacy system, but the fact is that the introduction of your code made the system as a whole less secure. In the end that is what matters - the entire system, not just your part - and it is hard to build a secure system with buggy parts.

Re:And yet we live in the non-ideal real world

[jd]

If the security flaws are not spread, then they stop being a "required" part of the system. It is when they are perpetuated that they become unfixable because fixing them will break things.

By having properly-built secure components, you make it so that it is possible to safely replace the buggy components over time. This is the only way that "expected" security flaws ever really get fixed.

So it's not really an "except" at all. What I described is a necessary first step. If both the original component and the new component require the security flaw, fixing the original component will break the new component. If the new component optionally supports the insecure method but also supports the correct, secure method, then fixing the old component doesn't break anything. Better still, it also allows you to eliminate the shim, accelerating performance.

Tin foil hat time.

[johncadengo]

And thats exactly what they want you to think...

Re:Tin foil hat time.

[hedwards]

Indeed, because the new mind control devices are only blocked by those stupid cheese head hats.

Gunter Janek...

[CohibaVancouver]

What about all this "Setec Astronomy" business then?

Social engineering always wins

[boristdog]

The Soviets almost never used to crack codes. They just social-engineered (blackmail, sex, gifts, schmoozed, etc) to get all the information they wanted.

It's how Mitnick did most of his work as well.

Re:Social engineering always wins

[blair1q]

But that's expensive, slow, and labor-intensive.

Trojan bots are cheap, easy to distribute, and hard to double against you.

Security is about preventing unintended outcomes

[Anonymous Coward]

Writing bulletproof code isn't really all that hard, but it does take discipline. Discipline to use only those constucts which have been verified with both the compiler and linker.

Some simple things that coders can do:
- avoid the use of pointers.
- Initialize all variables to known values.
- Perform comparisons with the LHS using a static variable, so you don't accidentally get an assignment instead of a comparison
- When you are done with a value, reset it to a "known" value. Zero is usually good.
- Keep functions less than 1 page long. If you can't see the entire function on a single editor page, it is too long.

Simple.

BTW, I wrote code for real-time space vehicle flight control systems. When I look at OSS and see variables not set to initial values, I cringe. Sure, it is probably ok, but there isn't any cost to initializing the variables. This is a compile-time decision. Without knowing it, many programmers are counting on memory being zero'ed as the program gets loaded. Not all OSes do this, so if you are writing cross platform code, don't trust it will happen. Do it yourself.

Oh, and if you want secure programs, loosely typed languages are scary.

Formal development methods

[Anonymous Coward]

One cornerstone of secure software development is the application of formal methods. The NSA Tokeneer project has been made completely open-source, demonstrating the feasability of applying formal methods to secure development problems.

Re:Security is about preventing unintended outcome

[HomelessInLaJolla]

Initialize all variables to known values

And remember to reset them to known values as soon as they are no longer necessary. Not only is it good practice, whether or not the compiler has a job, but it encourages the programmer to keep his variables in mind.

I knew it!

[Anonymous Coward]

They're using Agile practices! They just developed them before anyone else, about twenty years ago!

Incidentally, this also explains why they haven't done any groundbreaking work in twenty years... ~~~~

It doesn't matter

[metrix007]

This won't do anything to convince all the people who believe that the NSA can zoom in and enhance bad quality photos to a 10000 times. Despite it not being possible, the government probably has secret technology. Sigh.

Re:It doesn't matter

[zero0ne]

you mean something like this?

Re:It doesn't matter

[metrix007]

No, advanced guessing is not the same as creating information out of nothing.

people who put body in the subject

[X0563511]

really piss me off.

Why Math isn't the same as Software

[Zero__Kelvin]

"You can write and prove a program that when fed a list of three integers of 32 bits or less will always return the largest. The range is limited so it is provable."

No, you cannot. You can prove that it should do so, but you cannot prove that it will always do so. For example, your assumption is that the interpreter or compiler behaves the way you think it does, when you in fact have operated on numerous unproved assumptions.

Re:Why Math isn't the same as Software

[Anonymous Coward]

I think you don't know the meaning of the word 'proof'. From your perspective, nobody can ever prove anything at all.

In reality, all deductive logical proof relies on assumptions. Whether you believe the proof partially relies on whether you believe the assumptions. You may as well worry about random bit errors in the hardware, as whether the compiler is reliable. Or whether the hardware was fabricated correctly. Or whether reality is but a dream of mine, and you're not real.

So, you can argue about the reliability of the assumptions, but you are wrong to say it is not a proof.

Re:Why Math isn't the same as Software

[Zero__Kelvin]

"I think you don't know the meaning of the word 'proof'. From your perspective, nobody can ever prove anything at all."

I know the meaning of the word proof. You just don't know the meaning of the word Software, which is my whole point. Math and Software are not the same, amd mathematicians should stick to Math, and Software Engineers should worry about Software rather than Mathematical theory, as the two are quite different indeed.

Re:Why Math isn't the same as Software

[HeckRuler]

Or hardware fails. When an instruction to add 1 to the PC register simply doesn't, it can cause everything to fall apart. That's bad, but it's obvious. Worse still is when data gets a random blip. Now the program continues to function, but the output is wrong. And not necessarily obviously wrong. Just wrong enough to propagate.

If you are operating in the real world you must work on a system of probabilities. What's the acceptable rate for this thing to fail? If it can get kicked over weekly without fuss, then git'er'done. If it has to have five nine up time, you'd best have redundancy and fail-overs. If you're calculating the Xth digit of PI, then you need to something to check your memory for errors in real-time.

This is a hard lesson for com sci majors, but the real world isn't theoretical. I think a simple robotics course would really hammer this into their heads.

Re:Why Math isn't the same as Software

[Anonymous Coward]

heh, yes, I know the meaning of software. While I agree software isn't *all* about math, a large part of it is. You can not have a proof without starting with "unproved assumptions", as you put it. Once again displaying that you don't know the meaning of the word.

Re:Why Math isn't the same as Software

[Zero__Kelvin]

Excellent elaboration. Now all we have to do is sit back and wait for all the people who were loudly proclaiming that it's all just math to reply back and admit they are wrong. Should we take bets on the likelihood of that happening? ;-)

Cheers!

No Lie Here

[flyingkillerrobots]

"Most"

Re:Security is about preventing unintended outcome

[Anonymous Coward]

Introductory programming advice is now informative on Slashdot? This place really has declined...

No surprise

[Teunis]

For anyone who's read security posts on this site - all too often NSA folks pop up and respond :)

(and are frequently very helpful)

Re:Security is about preventing unintended outcome

[Anonymous Coward]

That only applies when you're using an inferior language. Variables should initialize to zero by themselves and go out of scope when I'm done with them.

Perform comparisons with the LHS using a static variable, so you don't accidentally get an assignment instead of a comparison

Static variable? You probably mean put a constant or expression on the left of the ==. That's awkward to read. How hard can it be to distinguish = from == from ===? I'd say if you have trouble keeping those apart, you should switch to COBOL.

d('w')b

[Anonymous Coward]

if you believe this tripe, you're clearly a fool.

the article is just a fluff piece for the so called war on cyber-terrorism (which is in itself just an excuse to exert greater control over the interwebs) -- "hey guys all our secrets are in books, please stop looking to see if we have any more! 'cause we really don't! honest!"

Re:Security is about preventing unintended outcome

[Jahava]

Writing bulletproof code isn't really all that hard, but it does take discipline. Discipline to use only those constucts which have been verified with both the compiler and linker.

Some simple things that coders can do: - avoid the use of pointers.

Pointers aren't themselves bad; they just add some layers of complication to the otherwise stack-oriented game. The only reason the stack is nicer than pointers is because they're implicitly managed for you.

Rather than avoid pointers, what you need is good code structure. Design functions that either manage the lifecycle of a pointer or are explicitly clear about how and what the pointer is going to be used as. Use const aggressively, and avoid typecasting as much as possible. Using good pointer naming techniques and management functions also dissipate the burden. Pointers are too useful to avoid religiously ... rather, build pointer security and management techniques into your coding style from the ground up. Choose descriptive names and try and constrain each pointer to its specific type (this lets the compiler help you keep your pointers straight).

Initialize all variables to known values.

Meh, I'm divided on this one. It's one thing to explicitly initialize global variables to either zero (which costs nothing, since they just end up in BSS sections) or non-zero (which puts them statically in the data segment). Stack variables, on the other hand, only really need to be initialized before they're used the first time. Pre-initializing them could lead to wasted instructions initializing them multiple times or cause them to be initialized in all code paths when they're only used in a few. My general rule of thumb is to be smart about it and, once again, naming conventions.

Perform comparisons with the LHS using a static variable, so you don't accidentally get an assignment instead of a comparison

Great tip; it's weird at first writing "if( NULL != p )", and you get a few funny stares, but after seeing enough "if( i = 10 )"s lying within seemingly-functional code, it's an easy selling point to make.

- When you are done with a value, reset it to a "known" value. Zero is usually good.

Definitely do this with pointers, descriptors, and other handle types. It also makes cleanup and pointer management easier. Less important to do with things like iterators and intermediate variables.

- Keep functions less than 1 page long. If you can't see the entire function on a single editor page, it is too long.

It's a good rule of thumb. I would like to add "any time you can't do this, make absolutely certain that you're not doing it for a good reason."

Good tips, though. One thing I'd like to add: -Wall -Wextra -Werror (or your language's equivalent). If your code can't compile without a single warning, then you need to re-write your code and either manually disarm situations (e.g., override the compiler's common-sense with an assurance that you know what you're doing) or fix the warnings, which are actually bugs and errors. It's always fun to take someone's "bulletproof" code and turn on these flags and watch the crap spill out. Warnings are amazing, and they are absolutely your friend when it comes to writing bug-free and secure code.

Re:Security is about preventing unintended outcome

[Kjella]

Some simple things that languages can do:

- Have all variables initialize to known values. I mostly program in C++/Qt and QString, QByteArray etc. don't need initialization. All numbers should initialize to 0, all pointers to NULL.
- Don't make the difference between assignment and comparison be a simple typo. If I were to design a language, "=" would not be a valid operator. ":=" for assignment, "==" for comparison. (You could keep all the "+=" etc. but not plain "=")
- Smarter scoping hints, like letting you call a function and *pass* the variable, which ends its scope.

Keep functions less than 1 page long. If you can't see the entire function on a single editor page, it is too long.

In my experience that is not practical and leads to too many artificial functions. But you should try reducing the complexity of how many different variables get involved. It's easy to read a three page function if only things are scoped out properly so only the important variables stay in scope. E.g.

void longFunction()
{
int foo = 0;
{ // 10 lines of code to calculate foo, some various temp variables etc.
} // Here only foo is left in scope
}

Re:Security is about preventing unintended outcome

[TheRaven64]

Without knowing it, many programmers are counting on memory being zero'ed as the program gets loaded

Any compliant C compiler will initialise all statics to 0 (stack values are different - they are not automatically initialised). From the C99 spec, 5.1.2:

All objects with static storage duration shall be initialized (set to their initial values) before program startup.

From 6.7.8.10:

If an object that has static storage duration is not initialized explicitly, then:

• if it has pointer type, it is initialized to a null pointer;
• if it has arithmetic type, it is initialized to (positive or unsigned) zero;
• if it is an aggregate, every member is initialized (recursively) according to these rules;
• if it is a union, the first named member is initialized (recursively) according to these rules.

You can guarantee that any standards-compliant C implementation will do this. You can't guarantee anything about an implementation that doesn't comply with the standard - it may deviate from it in other ways.

Re:Security is about preventing unintended outcome

[TheRaven64]

Stack variables, on the other hand, only really need to be initialized before they're used the first time. Pre-initializing them could lead to wasted instructions initializing them multiple times or cause them to be initialized in all code paths when they're only used in a few.

Unless your compiler really sucks, it will perform some trivial dataflow analysis and not generate code for the initialisation if the value is never used. Even really simply C compilers do this. If the value is used uninitialised on any code paths, then the initialisation will be used (although it may be moved to those code paths), and you don't want the compiler to remove it.

From the flags you recommend, I'm guessing that you use gcc, which not only does this analysis it will even tell you if the value is used uninitialised.

FTW

[Zero__Kelvin]

"You can not have a proof without starting with "unproved assumptions", as you put it. Once again displaying that you don't know the meaning of the word."

Bullshit. The fact that you admit that you start with unproved assumptions is an admission that you cannot prove the correctness. The fact that you are posting as an AC, but still following up with what is tantamount to a troll would be proof that you are a troll, were I not operating on the unproven assumption that you are in fact the same poster as you imply. ;-)

Re:Security is about preventing unintended outcome

[noidentity]

Great tip; it's weird at first writing "if( NULL != p )", and you get a few funny stares, but after seeing enough "if( i = 10 )"s lying within seemingly-functional code, it's an easy selling point to make.

I'm strongly against this. I use a compiler so I can write clear code, rather than assembly language. A compiler can catch all unintented assignments like this, by giving a warning whenever the result of an assignment is used as the condition, without any further comparison.

I find that it's much clearer to me to put the changing value on the left, and the thing it should equal on the right. So let's say I've got a loop that steps i through various values, and if i matches j, I do something. I'd write that as if(i==j), not if(j==i), even though they are equivalent. Mentally asking if "the value I'm looking for matches the value of i" is just backwards. Again, the compiler's job is to allow me to express things clearly. It can warn of assignments in if conditions, so I enable that and get on with coding for clarity.