His name is Kunte Kinte.

I hold out hope that the two of them are getting air time not because they could win, but because they are more interesting than Clinton v. Bush. Plenty of time for that boring crap later.

Vendors cannot be held responsible for stupid (or non-existent) engineering and policy.

Without knowing the GS/contractor divide at OPM, it's hard to say who is ultimately to blame. If OPM gave carte blanche to the contractor, the latter is generally the one at fault. If the government micro managed the contract and ignored suggestions, the blame is back with them.

Jim Webb doesn't strike me as particularly interested in the office.

That Goldwater girl was never liberal enough to want it.

Maybe it never tried.

That and also more importantly: because nature's idea of "better" is almost never the same as our idea of "better." I think it's wonderful that the performance example that they used, happened to be binding to cancer cells. If cancer doesn't illustrate the vast gulf between us and it, I don't know what does!

Ensuring all developers in the industry are competent is a pipe dream. Take a look at the most exacting careers you can think of - and you'll find varying levels of competence.

People are imperfect (in the sense that they can have a bad day, and let typos slip by from time to time - even the very best of us). Additionally the real software lifecycle is not like frozen water. It is more like all the different states of water - solid, liquid, and gas, changing as its environment changes on a continuum from birth to death.

I agree we should do something. I think that 'something' should be more than just training and hoping they use what they've learned.

People are not perfect automatons - therefore you always run the risk, and probably will see new bugs and vulnerabilities. However, that is okay - in the sense that it will still reset the clock (assuming you caught the existing zero days in the process). Now the hackers will have to start over - and it will take them another 6 to 12 months to figure out an exploit to the bugs you introduced - assuming they are actually exploitable. Therefore it makes sense to review and refactor code on a recurring basis. The benefits outweigh the costs.

The real problem here is willingness to fund what is necessary - refactoring all code used in critical systems to ensure they are secure - and to maintain that approach over time in an iterative basis.

We should touch code (at least to review it) - every year - which research indicates is the sweet spot for zero-day exploits. We get more benefits if we refactor the code - effectively resetting the clock for exploit writers to find a new zero day, and develop applications to exploit it.

Working in IT today, I can tell you from experience no one is willing to spend money to constantly refactor code without delivering new functionality (read 'revenue generating functionality'). This approach also is counterintuitive to software engineers trained to value code reuse over rewriting or building new solutions.

Instead, they focus on cosmetic bandaids - such as firewalls, antivirus, patch updates, and policy management. All of these things are important - but in the scheme of things will not stop a zero day exploit - particularly given that most patches for zero days are not available until the zero day is discovered - and then the time it takes the developer/company in question to put out a fix - on average 6 months to a year after the zero day is discovered and reported. Meanwhile the network is wide open to anyone who has figured it out (which is roughly 6 months to a year after a new piece of software is deployed on the network). The problem is related more to how humans learn systems than any particular coding practice. Your code refactor efforts just need to fall inside of that curve - leading rather than following.

Finally - the proposed fixes, such as more regulations, will not fix the problem - and will only serve to drive people out of the business, at the precise time when we need more developers than ever to address the problem effectively.

Steps:

1. Pay for what is needed in IT instead of being cheap. If you get more specific regulation of this - you might not have a choice (e.g. Sarbanes-Oxley)

2. Let your developers as a whole spend some time on evaluating code - the more eyeballs you have the better.

3. Move away from expensive water-fall projects to more flexible agile methods, and adjust your funding protocols to match.

grep "terror" /var/log/mail.log

The article left out that terrorists will be required to send from a hostname that has the word "terror" in it. Failure to do so, is a violation and will be punished!

Well, i want to do something on Android, so Java is the way. :(

Yes, Java is still ugly, but at least it's consistently ugly.

rwa2++;