Very insightful. I agree completely.
One complication: large organizations have more complex requirements: they often have to deal with compliance issues, have more departments that they have to inter-operate with, and more legacy. Systems are larger and more complex, so integration is inherently more difficult. Systems tend to evolve as spaghetti because of the focus on this year's budget (cheapest always wins), and so legacy systems tend to be very, very hard to change.
But these things withstanding, I agree completely with the poster ("refactored").
I agree. PERL lacks encapsulation: it is impossible to tell at a glance what the inputs and outputs are. And PERL's syntax is cryptic. PERL is one of the hardest to maintain languages there is, once the developer leaves. It leads to key person dependencies. I have seen organizations struggle with the PERL problem.
You are apparently talking about black-box testing. For starters, you need a security team to perform penetration testing on the apps in a production-like environment. But if you have home-grown software, you need to address the problem of insecure systems being built by your programmers. The programmers need to understand application security. For a somewhat theoretical but still practical treatment, I recommend my own book, High-Assurance Design (Addison-Wesley, 2005). You should also check out Michael Howard's book and his blog. And then there are Gary McGraw's books which address process. - Cliff
Hi. You should look at functional languages, such as Haskel (which is fairly new).
Yes, I do seriously think corporations will chase a new paradigm. It is a matter of CIOs being concerned with constant technology churn and getting poor productivity out of IT in spite of all the "new" languages and tools. (Ruby is new - NOT. Ruby introduces new concepts - NOT. XML is a step forward - NOT - and introduces new concepts - NOT.) My job is to consult to CIOs, so I know what they think. IT leadership is starting to look more closely at HOW things are developed and not leave it to the whims of programmers as they have in the past. Programmers are going to have to get more serious about things that matter to the corporation, such as assurance, maintainability, and transparency into why particular solutions are chosen over others.
Hi. Thanks for your thoughtful response. However, I must respectfully disagree with you. I feel that procedural programming is not here to stay. I have programmed compilers that took functions as input and generated highly concurrent procedural code (microcode). The input was not procedural; the output was. There is no reason why humans must define procedures. Humans can define programs in non-procedural ways, and the benefit is that there are non-procedural programming paradigms that lend themselves to expressing more of the intention of the human rather than a particular procedure. Procedural programming leads to errors in parallel processing, it is fundamentally insecure, and a procedure defines an implementation rather than an intention. It is fundamentally flawed in so many ways. And there are alternatives. I believe that we would be better off with a combination of functional languages to express behavior, and structural design languages to express structure for defining security boundaries, data conduits, and trust models.
Also, please note that the fundamental architecture of computers is in fact about to change. Massively parallel systems are just the beginning. We are headed toward machines that do not have pre-defined instruction sets, and in which applications choose the hardware architecture that is most appropriate for the application, dynamically. This is not too far away, and is enabled by new classes of electronics that have been developed. The compilers for these systems will not need to be procedural at all (even on the output side) because the underlying substrate will not have a fixed instruction set: it can be a data flow machine or whatever is appropriate for each application, and can be changed at memory access speed. This technology has been written about in many credible sources. You have made some good points about "we have heard that before" and it is true. But we must not become complacent just because little has changed: a time will come again when a sea change in computing will occur.
Programming's days are numbered. Do you really think people are going to be hacking away at procedural code in 20 years? I don't. I have my thoughts about the direction things will take, as do others. But I am sure that we will rise out of this procedural "programming" rut.
You are correct.
A security vulnerability is a defect if and only if the defect represents a failure with respect to a requirement. In fact, security is but one dimension of reliability, and so if the vendor is responsible for reliability, then the vendor should also be responsible for security.
If there is no requirement for security, then it is not a defect.
One of the posters mentioned that software that is sold for the intended purpose of general use on the Internet carries with it some implied requirements. (Merchantability.) Thus, just because the requirement for security is not explicitly stated does not mean that it is not there.
If security is a requirement for a given environment of use, then a vulnerability is a defect, by definition.
And yes, producers of software should be accountable in some manner for any and all defects, according to the terms of any explicit or implied warrantee.
Not sure if it is of interest, but my own book, High-Assurance Design (2005, Addison-Wesley; http://assuredbydesign.com/haa/) attempts to identify a useful set of "principles" pertaining to both security and reliability for practical software engineering. I tried to target practicing software architects, and so the book is not written as a "security book" or a "reliability textbook", but a handbook of sorts. The taxonomy includes about 180+ principles, each explained in detail, with design patterns. It is not a programmer's book, as there is not alot of code in it, but rather a book about design. It also contains a taxonomy of social engineering techniques, which you might not find elsewhere. The book has a foreword by Peter G. Neumann, one of the pioneers of Multics and of secure design in general. I hope it is of value. Best regards, - Cliff.
I agree. Procedural programming is the fundamental problem. Arguing about which procedural language will succeed is like Neanderthals arguing which kind of stone will succeed the one before it. And OO languages are procedural languages in disguise. As Anonymous Coward says, we need to get out of the procedural trap. This is why programs have so many bugs. Let's stop hacking and looking for the next great tool, the next fad, and what our friends are using. Let's look at what approach is truly best.
In my 2005 book, High-Assurance Design (which you can also buy from Amazon), I point out that:
1. The average programmer is woefully untrained in basic principles related to reliability and security.
2. The tools available to programmers are woefully inadequate to expect that the average programmer can produce reliable and secure applications.
3. Organizations that procure applications are woefully unaware of this state of affairs, and take far too much for granted with regard to security and reliability.
The problems are therefore deep and structural. One cannot blame one segment of the industry.
In terms of what developers in IT can control, I would recommend that we take design seriously. Design does not mean waterfall process. And design is critical for security. Programmers work in a much too ad-hoc manner. We need to stop embracing the latest cool thing, the latest trendy language, and try to be more critical and thoughtful. We should ask ourselves, "is this a good tool - even if few currently use it?" and "what language would enable me to develop a well-designed system?" instead of "what is everyone else doing?"
It so happens that my book provides a great amount of guidance at an architectural level, and I feel that one should start there. But it does not end there. One must also be aware of the shortcomings in current technologies (that is what most hacking books are about). The foundation is a good understanding of secure design principles and architecture. Security is about careful design and good process. Unfortunately, the tools and languages that are generally in use do not make it easy to design and implement secure systems: it is all up to the programmer. Thus, it is essential that the programmer be extremely knowledgeable, and develop a secure architecture from the outset - at least until secure design languages emerge (if they ever do).
In my experience as CTO of a respected software development company (Digital Focus), and since then as a consultant in the field of assurance and methodology, I have found that in general developers are not interested in security. E.g., my book, High-Assurance Design, which looks at application architecture from a security and reliability perspective, sells in very low numbers, while my Java books sold in very high numbers. "Hacker" books sell well because many developers want a "quick fix" to their apps, without really understanding security. And consumers are not interested in security either. Just look at Vista: its primary value proposition is that it is more secure. As a result, it is slower, and some drivers and apps don't work. (If you make things more secure, some things will break.) Witness the tremendous push-back by people, claiming that Vista is a "step backward". I myself use a Mac most of the time, but even given Vista's ill-conceived attempts at content protection, I find it interesting that people do not recognize the core value of Vista over XP (security). To me, it proves my point: people don't value security, until something bad happens to them personally.
Yes Mr. Johnson, you are right. And therein lies the dilemma: industry has not provided the computers that we need that can be used safely by average users. So what do we do?
Regrettably, it is really a matter of the lesser of two evils: (1) allow users to use unsafe systems; or (2) give users systems with limited capability.
I am not saying that ALL users should have thin client systems. But most should. I do not agree that thin client jobs will be replaced by automation. Most jobs do not require a PC, with local storage and locally installed applications. Even for knowledge workers, most large organizations today DO lock down PCs, disallowing people to install apps; but this is only partially effective because the OSs are not fully secure, nor are browsers, which can sometimes install things that they should not be able to install, by taking advantage of system flaws and application flaws.
Also, hardening the network does precious little to safeguard desktops. Basically, if a system allows in content from the outside, it is vulnerable, and the network is pretty helpless to do anything about it. Content scanning is only effective for yesterday's malware.
A third solution that has not been mentioned is to just say NO to the mainstream OSs and use a secure OS. E.g., many Linux distros (e.g. RedHat) have SE Linus built in, but to use it for real you have to enable it. But even SE Linux is missing many security features related to "need to know" concepts and compartmentalization. In the end, security breaches will occur, and the best protection of all is to segregate data so that no person has access to any significant portion of any type of data that the organization has. Given the extremely poor state of security with today's systems, this is the best strategy.
While driving Warwick Ford (CTO of Verisign) to the airport a few years ago, I asked him what he thought was the greatest challenge with respect to security, and he said he thought it was the insecurity of operating systems. I agree with him. Further, OSs are way too complex to administer for the average user, and if you (unknowingly) administer it improperly, it is insecure. Therefore, it is almost academic that average users cannot be trusted to maintain secure OSs. Ergo, if an organization values security, average users should not administer their OS. I would go even further, that the average user should not even have an OS at their disposal, given that so many exploits are the result of inappropriate usage of applications (such as browsers). I am not advocating going back to the days of VT 100s, but it is a sad fact that today's situation, with non tech-savvy people using general purpose insecure OSs and applications, that organizations are constantly at great risk, and it is a game of Russian roulette: something really bad and embarrassing for the organization will happen if the organization is merely a little bit unlucky. That is not a good place for an organization to be. (There is some kind of big corporate security disaster story in the news almost every week.) Desktop systems should be completely locked down in terms of what can be installed, and what the configuration is; and it is better if users who don't really need a desktop OS have instead a thin client so that they cannot run anything outside of the sandbox imposed by the server.
If OSs and application security ever improve, I will change my mind.
It is also ironic that the industry realizes that people won't pay for the security that is needed, or tolerate its inconvenience, yet the insecurity of today's systems is responsible for huge indirect costs to all of us.
CORBA uses IDL for interface definition. Therefore, you don't even have to write code to parse it: the parsing code is generated automatically. So the arguments about parsing are non issues. With regard to content, one can define content in IDL very easily. I have not used the APIs you refer to (e.g., Thrift), so I cannot comment on those. I will say this though: when I used to write apps 10 years ago using CORBA, it took me so little time to throw a system-to-system interface together that I almost didn't even think about it. The same with EJB, except that persistent EJBs were flawed and so EJBs lost credibility even though the API model (similar to CORBA) was (and is) extremely easy to use. Then people started wanting to communicate across firewalls, and OMG didn't get its act together and make IIOP capable of traversing firewalls before people got hooked on hand-coding HTTP messaging, which then led to XML messages and SOAP and Web services. The right answer was to fix the OMG spec for pushing IIOP through firewalls in a standard way. Nowadays, whenever I have to create an inter-system interface and the options involve SOAP or Web services or some other XML-based interface, I groan and it takes me ten times as long to get the interface built and reliable. That is not progress. I will look at Thrift and the other API that you mention, and we may disagree on some thing (e.g., the value of type safety), but I agree with you that XML-based messaging has been a huge, huge step backwards.
Gaming is definitely here to stay. In fact, it is differentiating and becoming ever more sophisticated every day. What gaming will become will be full virtual worlds, with total immersion. Display technology is poised to become extremely cheap, and we will have wall-sized displays in our homes. Eventually they will be 3-D, and the graphics will benefit from massive parallelism to make the scenes indistinguishable from reality. And just as with alcohol and every other attraction that can be abused, there will be many people who live in a fake world every moment when they are not working; and just as the majority of people do not grow mentally once they leave school, there will be a majority that go home every night and live in the game world and do nothing of significance in the real world. Meanwhile, the game makers will fly their jet planes and have real-life experiences while the masses live in a dream world, drugged on the synthetic products created for them. I see nothing wrong with where the technology is headed; I just lament that most people will be controlled by it instead of controlling it: but not all.
Re:Too many 'this stuff sucks' moments
on
The Future of XML
·
· Score: 1
Your point is well taken with regard to the Gopher comparison. But politely, I think you are missing my point. Browsers are not bloated because of features. They are bloated because of the over-complexity of multitude of standards that they must support. I agree that easy-to-create business functionality is important, but browsers provide anything but that. Today, in order to create reliable front ends in a browser, it is way, way too complicated and tricky. The tools that support this must support so many different, competing technologies and standards. That is why the tools are bloated, and the browsers are bloated. Further, getting back to XML, I think that the XML standards communities have done a disservice to us all by re-inventing so many wheels. There is nothing new there: all of it has been done before. XML and browsers have simply re-invented so many things in the new context of the Internet. And in doing so, they have created a mess. That was the point of the prior poster, who I was responding to and agreeing with. I agree with you that the functionality is important and valuable. My point is that the implementation of the functionality is a mess. So no, I do not long for "gopher". I embrace new things, but in browsers I see little that is actually new - just different, and in most cases inferior. It is the Internet that enables these things to have more value than their predecessors. By themselves, they are poor excuses for client technologies, again because of the implementation and its fragmentation and over-complexity. If asked to demonstrate the over-complexity of these technology implementations, I can: I am well-versed in the XML standards (or at least was at one time, and am somewhat rusty now). One of my favorite examples is WSDL, which has a boat-load of functionality that is completely unnecessary; not to mention that the most important interface definition between applications is NOT at the message level, but is at the API level, and so WSDL's entire reason for existence is questionable. Another example is the war over many competing standards to simply render line graphics! How many of these must a browser support? And more are on the way. Another example is HTML 5 versus XHTML: what the heck is going on? Where is the W3C's leadership? Another example is the need for embedding content in the first place: why cannot the core HTML mode handled the kinds of things that the plugins do? Flash? There are HTML-based standards to do that kind of things. Having a plugin introduces all kinds of security issues and reliability issues. I am not saying don't have plugins, but we take it for granted that everyone must have them. It should be a rare exception for handling unique functionality that the browser cannot provide. Why have multiple rendering engines running? - just to waste memory? And then we have the "security model" of the browser: oh-my-god. Just look at the state of affairs that that has created: cross-site scripting and so on. To repeat the prior poster's repeated conclusion: this stuff sucks. Just to re-iterate my point one more time: it is not the need for functionality that I question, but the implementation, based largely on the very poor, overly complex, and fragmented yet still inadequate XML "standards". This stuff suck.
Re:Too many 'this stuff sucks' moments
on
The Future of XML
·
· Score: 1
How refreshing to see so many people arguing intelligently that "the Emperor has no clothes". Indeed, XML is a terrible solution to almost all of the uses it is put to. It does solve the parsing problem, in that the syntax is pre-defined, but it is too bad that we don't have a better "standard syntax" or easier to use parser toolkit standard. I used to write compilers many, many years ago and the tools were designed for gurus. XML came along because it made the job of parsing easy, and XML messaging caught on because it was ascii and could be use to trick firewalls by pushing messages through HTTP which was intended for browsers. But I agree: XML actually sucks. And it is a very, very poor choice for a messaging specification syntax, for the many reasons stated by others. Incredibly, Web services and SOA are built around XML: so I conclude that their days are numbered, since the very underpinning is so defective by design. But then again, people said that about Windows.... Someone here asked what the alternative is. There are many levels to the answer to this: at one level, someone should create something better, something that makes a clean break from XML. But for those who simply want an existing tool to use for an application, I would suggest that if you are creating a persistent file, use a persistence API - don't write XML; and if you are doing messaging or remote procedure calls, use a native protocol - don't define your message interface in WSDL (because it is the WORST interface approach there is); but if you must define a document syntax of some kind, consider XML, because it is actually effective (although cumbersome) for that, and there is nothing better currently. And above all, be willing to say that the Emperor has no clothes: expose the many fragmented and overlapping XML standards for what they are: a disorganized jumbled junk heap of overly, overly, overly complex make-work. What we really need is a small number of specs designed by a small number of smart individuals, and all designed to work together with the minimum of complexity instead of the maximum. And I for one am tired of the ever increasing complexity of HTML and consequent browsers that must have a 100Mb footprint. Indeed, this stuff sucks.
This is an example of an enticement scheme. There is a full taxonomy of schemes in chapter 5 of my book High-Assurance Design. The chapter can be downloaded from http://assuredbydesign.com/haa/chs/Berg_ch05.pdf.
Agree.
Inevitably, electronic recorded content will (for the most part) have to be given away free, as promotional, or sold at a very low price (e.g. 99 cents a song or a few dollars for a movie).
Electronic recorded content has only existed for the past 100 years. How did musicians make money before that?
By performing....
And now with the Internet, it is possible to broadcast a live performance around the world - and eventually people will be able to view these in high quality on cellphones as well as computers. If performers can't make a business model out of that, then something is truly wrong.
All your comments bring back to my mind the criticisms of XML-based messaging technologies (SOAP, Web services). "A huge step backwards", "incompatible with existing technologies and approaches" (BNF, parsers, languages), "inefficient" (compared to binary formats), etc.
Those complaints were right, but they fell on deaf ears, just as these will....
IT is driven by fads and the availability of high-productivity gizmos. Ironically, productivity often suffers in the long run, as people then have to deal with the mess that gets created using approaches that are fundamentally wrong.
I agree.
I have found that it is fairly easy to uncover program structure. But UNDERSTANDING the intention of each line or function is another matter.
This is where one wishes that there were documentation of design decisions. This is why whenever I build something I simultaneously maintain a design document in which I record each decision that I make and each pattern that I devise and use. As I revisit decisions, I do it in the design, and only when I have worked out the design do I try to code it. This is not the traditional "big up front design" - it is an agile approach to design, attacking it incrementally and in a just-what-is-needed manner.
Open source software is not necessarily created by volunteers. In fact, I suspect that the most popular open source projects are coded by paid programmers, using donations from private industry. Consortiums often fund open source projects so that they can undermine a competitive entity (such as MS). Thus, for these projects - and I think these are the largest ones - there is a definite commercial incentive. Such efforts are not efforts of volunteers.
The volunteers come in mostly on the small 1-3 person projects - including all the half-abandoned ones on sourceforge.
I used to feel somewhat that way. And when I was in grad school I used to swear like a sailor too with my friends. In fact, the more abusively I addressed one of my friends, the more endearing it was. "Jay you mother-f******!" and so on. It was great fun, and it made us laugh. But I outgrew it. I am 51 now. As I got older, I started to appreciate having beauty around me and reducing the ugliness in the world, which there is a great deal of. Remember that a blog is read by a great variety of people of all ages - not just your chronological and social peers. So why alienate a mainstream segment by using language that offends them? Doing so reduces your credibility whether you like it or not. And you might blame the reader, but if you know in advance that certain language offends that very large group of people, then you really can't complain that they are offended. People who advance in the world learn this because you would not go into a board room using foul language, and you would not speak that way to a professor in a university - especially your adviser in your PhD program - and you would not speak that way to others who you respect in an environment that is conservative. So why broadcast your opinion in a manner that is offensive to a large portion of the population? It is not necessary. I am not trying to have an argument with you. I think I perhaps offended you in the way that I described the guy's blog, but that was honestly my reaction. It sounded like trailer trash talk. That is the impression it left on me. I also was not trying to insult the author of the blog. I did not write to him. I merely voiced my impression for other slashdot readers in response to the posting about the blog entry. No flame intended. No argument desired.
Hey, slashdot is a blog too, so I can say "whatever goes through my head when my fingers are on the keyboard", as you put it. If YOU don't like it then don't read it.....Kind of pointless, right? So, i.e., my feeling is that if someone has only garbage to say, they should not bother to blog about it, write about it, or whatever. If you are going to publish something - and a blog IS a form of publication - then you really should make it fit for others to read. It is certainly not for the author to read - they are writing it and don't need to read it. A blog is for OTHERS to read. Thus, to be meaningful and credible, it should be clearly articulated and as logically laid out as one can. Given that blogs are somewhat stream-of-consciousness, one can still endeavor to be logical. I for one have known many people who are capable of being logical, clear, and articulate when speaking with a stream of consciousness.
I am not trying to "flame" the person. I do not believe in doing that. I try to be polite if at all possible, but the guy's blog was so crass, low-brow, and full of the f-word that it was hard to be polite, and I found it impossible to read without being offended constantly, so it failed in its mission to make its points. Perhaps people who are not offended by gutter language because they also live with it daily can get more from the commentary.
I am not sure what your comment "Oh look mum, they posted my comment on Slashdot! Whoa I'm on the web! I'm important!" is supposed to mean. I miss your point. If you are poking fun at me, you should know that I have published four books, founded and grew a $16M company (from zero), and have been a CTO and creator of compilers. What have you done? If you can't top that, then don't poke fun at me. I also have known many, many very resourceful and talented people, and the majority of them are clear thinkers, articulate, polite, and do not use foul language when expressing themselves about their work.
Slashdot Mirror
Very insightful. I agree completely. One complication: large organizations have more complex requirements: they often have to deal with compliance issues, have more departments that they have to inter-operate with, and more legacy. Systems are larger and more complex, so integration is inherently more difficult. Systems tend to evolve as spaghetti because of the focus on this year's budget (cheapest always wins), and so legacy systems tend to be very, very hard to change. But these things withstanding, I agree completely with the poster ("refactored").
I agree. PERL lacks encapsulation: it is impossible to tell at a glance what the inputs and outputs are. And PERL's syntax is cryptic. PERL is one of the hardest to maintain languages there is, once the developer leaves. It leads to key person dependencies. I have seen organizations struggle with the PERL problem.
You are apparently talking about black-box testing. For starters, you need a security team to perform penetration testing on the apps in a production-like environment. But if you have home-grown software, you need to address the problem of insecure systems being built by your programmers. The programmers need to understand application security. For a somewhat theoretical but still practical treatment, I recommend my own book, High-Assurance Design (Addison-Wesley, 2005). You should also check out Michael Howard's book and his blog. And then there are Gary McGraw's books which address process. - Cliff
Hi. You should look at functional languages, such as Haskel (which is fairly new).
Yes, I do seriously think corporations will chase a new paradigm. It is a matter of CIOs being concerned with constant technology churn and getting poor productivity out of IT in spite of all the "new" languages and tools. (Ruby is new - NOT. Ruby introduces new concepts - NOT. XML is a step forward - NOT - and introduces new concepts - NOT.) My job is to consult to CIOs, so I know what they think. IT leadership is starting to look more closely at HOW things are developed and not leave it to the whims of programmers as they have in the past. Programmers are going to have to get more serious about things that matter to the corporation, such as assurance, maintainability, and transparency into why particular solutions are chosen over others.
Hi. Thanks for your thoughtful response. However, I must respectfully disagree with you. I feel that procedural programming is not here to stay. I have programmed compilers that took functions as input and generated highly concurrent procedural code (microcode). The input was not procedural; the output was. There is no reason why humans must define procedures. Humans can define programs in non-procedural ways, and the benefit is that there are non-procedural programming paradigms that lend themselves to expressing more of the intention of the human rather than a particular procedure. Procedural programming leads to errors in parallel processing, it is fundamentally insecure, and a procedure defines an implementation rather than an intention. It is fundamentally flawed in so many ways. And there are alternatives. I believe that we would be better off with a combination of functional languages to express behavior, and structural design languages to express structure for defining security boundaries, data conduits, and trust models.
Also, please note that the fundamental architecture of computers is in fact about to change. Massively parallel systems are just the beginning. We are headed toward machines that do not have pre-defined instruction sets, and in which applications choose the hardware architecture that is most appropriate for the application, dynamically. This is not too far away, and is enabled by new classes of electronics that have been developed. The compilers for these systems will not need to be procedural at all (even on the output side) because the underlying substrate will not have a fixed instruction set: it can be a data flow machine or whatever is appropriate for each application, and can be changed at memory access speed. This technology has been written about in many credible sources. You have made some good points about "we have heard that before" and it is true. But we must not become complacent just because little has changed: a time will come again when a sea change in computing will occur.
Programming's days are numbered. Do you really think people are going to be hacking away at procedural code in 20 years? I don't. I have my thoughts about the direction things will take, as do others. But I am sure that we will rise out of this procedural "programming" rut.
You are correct. A security vulnerability is a defect if and only if the defect represents a failure with respect to a requirement. In fact, security is but one dimension of reliability, and so if the vendor is responsible for reliability, then the vendor should also be responsible for security. If there is no requirement for security, then it is not a defect. One of the posters mentioned that software that is sold for the intended purpose of general use on the Internet carries with it some implied requirements. (Merchantability.) Thus, just because the requirement for security is not explicitly stated does not mean that it is not there. If security is a requirement for a given environment of use, then a vulnerability is a defect, by definition. And yes, producers of software should be accountable in some manner for any and all defects, according to the terms of any explicit or implied warrantee.
Not sure if it is of interest, but my own book, High-Assurance Design (2005, Addison-Wesley; http://assuredbydesign.com/haa/) attempts to identify a useful set of "principles" pertaining to both security and reliability for practical software engineering. I tried to target practicing software architects, and so the book is not written as a "security book" or a "reliability textbook", but a handbook of sorts. The taxonomy includes about 180+ principles, each explained in detail, with design patterns. It is not a programmer's book, as there is not alot of code in it, but rather a book about design. It also contains a taxonomy of social engineering techniques, which you might not find elsewhere. The book has a foreword by Peter G. Neumann, one of the pioneers of Multics and of secure design in general. I hope it is of value. Best regards, - Cliff.
I agree. Procedural programming is the fundamental problem. Arguing about which procedural language will succeed is like Neanderthals arguing which kind of stone will succeed the one before it. And OO languages are procedural languages in disguise. As Anonymous Coward says, we need to get out of the procedural trap. This is why programs have so many bugs. Let's stop hacking and looking for the next great tool, the next fad, and what our friends are using. Let's look at what approach is truly best.
The problems are therefore deep and structural. One cannot blame one segment of the industry.
In terms of what developers in IT can control, I would recommend that we take design seriously. Design does not mean waterfall process. And design is critical for security. Programmers work in a much too ad-hoc manner. We need to stop embracing the latest cool thing, the latest trendy language, and try to be more critical and thoughtful. We should ask ourselves, "is this a good tool - even if few currently use it?" and "what language would enable me to develop a well-designed system?" instead of "what is everyone else doing?"
It so happens that my book provides a great amount of guidance at an architectural level, and I feel that one should start there. But it does not end there. One must also be aware of the shortcomings in current technologies (that is what most hacking books are about). The foundation is a good understanding of secure design principles and architecture. Security is about careful design and good process. Unfortunately, the tools and languages that are generally in use do not make it easy to design and implement secure systems: it is all up to the programmer. Thus, it is essential that the programmer be extremely knowledgeable, and develop a secure architecture from the outset - at least until secure design languages emerge (if they ever do).
In my experience as CTO of a respected software development company (Digital Focus), and since then as a consultant in the field of assurance and methodology, I have found that in general developers are not interested in security. E.g., my book, High-Assurance Design, which looks at application architecture from a security and reliability perspective, sells in very low numbers, while my Java books sold in very high numbers. "Hacker" books sell well because many developers want a "quick fix" to their apps, without really understanding security. And consumers are not interested in security either. Just look at Vista: its primary value proposition is that it is more secure. As a result, it is slower, and some drivers and apps don't work. (If you make things more secure, some things will break.) Witness the tremendous push-back by people, claiming that Vista is a "step backward". I myself use a Mac most of the time, but even given Vista's ill-conceived attempts at content protection, I find it interesting that people do not recognize the core value of Vista over XP (security). To me, it proves my point: people don't value security, until something bad happens to them personally.
Yes Mr. Johnson, you are right. And therein lies the dilemma: industry has not provided the computers that we need that can be used safely by average users. So what do we do?
Regrettably, it is really a matter of the lesser of two evils: (1) allow users to use unsafe systems; or (2) give users systems with limited capability.
I am not saying that ALL users should have thin client systems. But most should. I do not agree that thin client jobs will be replaced by automation. Most jobs do not require a PC, with local storage and locally installed applications. Even for knowledge workers, most large organizations today DO lock down PCs, disallowing people to install apps; but this is only partially effective because the OSs are not fully secure, nor are browsers, which can sometimes install things that they should not be able to install, by taking advantage of system flaws and application flaws.
Also, hardening the network does precious little to safeguard desktops. Basically, if a system allows in content from the outside, it is vulnerable, and the network is pretty helpless to do anything about it. Content scanning is only effective for yesterday's malware.
A third solution that has not been mentioned is to just say NO to the mainstream OSs and use a secure OS. E.g., many Linux distros (e.g. RedHat) have SE Linus built in, but to use it for real you have to enable it. But even SE Linux is missing many security features related to "need to know" concepts and compartmentalization. In the end, security breaches will occur, and the best protection of all is to segregate data so that no person has access to any significant portion of any type of data that the organization has. Given the extremely poor state of security with today's systems, this is the best strategy.
While driving Warwick Ford (CTO of Verisign) to the airport a few years ago, I asked him what he thought was the greatest challenge with respect to security, and he said he thought it was the insecurity of operating systems. I agree with him. Further, OSs are way too complex to administer for the average user, and if you (unknowingly) administer it improperly, it is insecure. Therefore, it is almost academic that average users cannot be trusted to maintain secure OSs. Ergo, if an organization values security, average users should not administer their OS. I would go even further, that the average user should not even have an OS at their disposal, given that so many exploits are the result of inappropriate usage of applications (such as browsers). I am not advocating going back to the days of VT 100s, but it is a sad fact that today's situation, with non tech-savvy people using general purpose insecure OSs and applications, that organizations are constantly at great risk, and it is a game of Russian roulette: something really bad and embarrassing for the organization will happen if the organization is merely a little bit unlucky. That is not a good place for an organization to be. (There is some kind of big corporate security disaster story in the news almost every week.) Desktop systems should be completely locked down in terms of what can be installed, and what the configuration is; and it is better if users who don't really need a desktop OS have instead a thin client so that they cannot run anything outside of the sandbox imposed by the server.
If OSs and application security ever improve, I will change my mind.
It is also ironic that the industry realizes that people won't pay for the security that is needed, or tolerate its inconvenience, yet the insecurity of today's systems is responsible for huge indirect costs to all of us.
Interesting thoughts. Could you please explain how some of the technologies that you mention improve on this? Thanks.
CORBA uses IDL for interface definition. Therefore, you don't even have to write code to parse it: the parsing code is generated automatically. So the arguments about parsing are non issues. With regard to content, one can define content in IDL very easily. I have not used the APIs you refer to (e.g., Thrift), so I cannot comment on those. I will say this though: when I used to write apps 10 years ago using CORBA, it took me so little time to throw a system-to-system interface together that I almost didn't even think about it. The same with EJB, except that persistent EJBs were flawed and so EJBs lost credibility even though the API model (similar to CORBA) was (and is) extremely easy to use. Then people started wanting to communicate across firewalls, and OMG didn't get its act together and make IIOP capable of traversing firewalls before people got hooked on hand-coding HTTP messaging, which then led to XML messages and SOAP and Web services. The right answer was to fix the OMG spec for pushing IIOP through firewalls in a standard way. Nowadays, whenever I have to create an inter-system interface and the options involve SOAP or Web services or some other XML-based interface, I groan and it takes me ten times as long to get the interface built and reliable. That is not progress. I will look at Thrift and the other API that you mention, and we may disagree on some thing (e.g., the value of type safety), but I agree with you that XML-based messaging has been a huge, huge step backwards.
Gaming is definitely here to stay. In fact, it is differentiating and becoming ever more sophisticated every day. What gaming will become will be full virtual worlds, with total immersion. Display technology is poised to become extremely cheap, and we will have wall-sized displays in our homes. Eventually they will be 3-D, and the graphics will benefit from massive parallelism to make the scenes indistinguishable from reality. And just as with alcohol and every other attraction that can be abused, there will be many people who live in a fake world every moment when they are not working; and just as the majority of people do not grow mentally once they leave school, there will be a majority that go home every night and live in the game world and do nothing of significance in the real world. Meanwhile, the game makers will fly their jet planes and have real-life experiences while the masses live in a dream world, drugged on the synthetic products created for them. I see nothing wrong with where the technology is headed; I just lament that most people will be controlled by it instead of controlling it: but not all.
Your point is well taken with regard to the Gopher comparison. But politely, I think you are missing my point. Browsers are not bloated because of features. They are bloated because of the over-complexity of multitude of standards that they must support. I agree that easy-to-create business functionality is important, but browsers provide anything but that. Today, in order to create reliable front ends in a browser, it is way, way too complicated and tricky. The tools that support this must support so many different, competing technologies and standards. That is why the tools are bloated, and the browsers are bloated. Further, getting back to XML, I think that the XML standards communities have done a disservice to us all by re-inventing so many wheels. There is nothing new there: all of it has been done before. XML and browsers have simply re-invented so many things in the new context of the Internet. And in doing so, they have created a mess. That was the point of the prior poster, who I was responding to and agreeing with. I agree with you that the functionality is important and valuable. My point is that the implementation of the functionality is a mess. So no, I do not long for "gopher". I embrace new things, but in browsers I see little that is actually new - just different, and in most cases inferior. It is the Internet that enables these things to have more value than their predecessors. By themselves, they are poor excuses for client technologies, again because of the implementation and its fragmentation and over-complexity. If asked to demonstrate the over-complexity of these technology implementations, I can: I am well-versed in the XML standards (or at least was at one time, and am somewhat rusty now). One of my favorite examples is WSDL, which has a boat-load of functionality that is completely unnecessary; not to mention that the most important interface definition between applications is NOT at the message level, but is at the API level, and so WSDL's entire reason for existence is questionable. Another example is the war over many competing standards to simply render line graphics! How many of these must a browser support? And more are on the way. Another example is HTML 5 versus XHTML: what the heck is going on? Where is the W3C's leadership? Another example is the need for embedding content in the first place: why cannot the core HTML mode handled the kinds of things that the plugins do? Flash? There are HTML-based standards to do that kind of things. Having a plugin introduces all kinds of security issues and reliability issues. I am not saying don't have plugins, but we take it for granted that everyone must have them. It should be a rare exception for handling unique functionality that the browser cannot provide. Why have multiple rendering engines running? - just to waste memory? And then we have the "security model" of the browser: oh-my-god. Just look at the state of affairs that that has created: cross-site scripting and so on. To repeat the prior poster's repeated conclusion: this stuff sucks. Just to re-iterate my point one more time: it is not the need for functionality that I question, but the implementation, based largely on the very poor, overly complex, and fragmented yet still inadequate XML "standards". This stuff suck.
How refreshing to see so many people arguing intelligently that "the Emperor has no clothes". Indeed, XML is a terrible solution to almost all of the uses it is put to. It does solve the parsing problem, in that the syntax is pre-defined, but it is too bad that we don't have a better "standard syntax" or easier to use parser toolkit standard. I used to write compilers many, many years ago and the tools were designed for gurus. XML came along because it made the job of parsing easy, and XML messaging caught on because it was ascii and could be use to trick firewalls by pushing messages through HTTP which was intended for browsers. But I agree: XML actually sucks. And it is a very, very poor choice for a messaging specification syntax, for the many reasons stated by others. Incredibly, Web services and SOA are built around XML: so I conclude that their days are numbered, since the very underpinning is so defective by design. But then again, people said that about Windows.... Someone here asked what the alternative is. There are many levels to the answer to this: at one level, someone should create something better, something that makes a clean break from XML. But for those who simply want an existing tool to use for an application, I would suggest that if you are creating a persistent file, use a persistence API - don't write XML; and if you are doing messaging or remote procedure calls, use a native protocol - don't define your message interface in WSDL (because it is the WORST interface approach there is); but if you must define a document syntax of some kind, consider XML, because it is actually effective (although cumbersome) for that, and there is nothing better currently. And above all, be willing to say that the Emperor has no clothes: expose the many fragmented and overlapping XML standards for what they are: a disorganized jumbled junk heap of overly, overly, overly complex make-work. What we really need is a small number of specs designed by a small number of smart individuals, and all designed to work together with the minimum of complexity instead of the maximum. And I for one am tired of the ever increasing complexity of HTML and consequent browsers that must have a 100Mb footprint. Indeed, this stuff sucks.
This is an example of an enticement scheme. There is a full taxonomy of schemes in chapter 5 of my book High-Assurance Design. The chapter can be downloaded from http://assuredbydesign.com/haa/chs/Berg_ch05.pdf.
Agree. Inevitably, electronic recorded content will (for the most part) have to be given away free, as promotional, or sold at a very low price (e.g. 99 cents a song or a few dollars for a movie). Electronic recorded content has only existed for the past 100 years. How did musicians make money before that? By performing.... And now with the Internet, it is possible to broadcast a live performance around the world - and eventually people will be able to view these in high quality on cellphones as well as computers. If performers can't make a business model out of that, then something is truly wrong.
All your comments bring back to my mind the criticisms of XML-based messaging technologies (SOAP, Web services). "A huge step backwards", "incompatible with existing technologies and approaches" (BNF, parsers, languages), "inefficient" (compared to binary formats), etc. Those complaints were right, but they fell on deaf ears, just as these will.... IT is driven by fads and the availability of high-productivity gizmos. Ironically, productivity often suffers in the long run, as people then have to deal with the mess that gets created using approaches that are fundamentally wrong.
I agree. I have found that it is fairly easy to uncover program structure. But UNDERSTANDING the intention of each line or function is another matter. This is where one wishes that there were documentation of design decisions. This is why whenever I build something I simultaneously maintain a design document in which I record each decision that I make and each pattern that I devise and use. As I revisit decisions, I do it in the design, and only when I have worked out the design do I try to code it. This is not the traditional "big up front design" - it is an agile approach to design, attacking it incrementally and in a just-what-is-needed manner.
Open source software is not necessarily created by volunteers. In fact, I suspect that the most popular open source projects are coded by paid programmers, using donations from private industry. Consortiums often fund open source projects so that they can undermine a competitive entity (such as MS). Thus, for these projects - and I think these are the largest ones - there is a definite commercial incentive. Such efforts are not efforts of volunteers. The volunteers come in mostly on the small 1-3 person projects - including all the half-abandoned ones on sourceforge.
I used to feel somewhat that way. And when I was in grad school I used to swear like a sailor too with my friends. In fact, the more abusively I addressed one of my friends, the more endearing it was. "Jay you mother-f******!" and so on. It was great fun, and it made us laugh. But I outgrew it. I am 51 now. As I got older, I started to appreciate having beauty around me and reducing the ugliness in the world, which there is a great deal of. Remember that a blog is read by a great variety of people of all ages - not just your chronological and social peers. So why alienate a mainstream segment by using language that offends them? Doing so reduces your credibility whether you like it or not. And you might blame the reader, but if you know in advance that certain language offends that very large group of people, then you really can't complain that they are offended. People who advance in the world learn this because you would not go into a board room using foul language, and you would not speak that way to a professor in a university - especially your adviser in your PhD program - and you would not speak that way to others who you respect in an environment that is conservative. So why broadcast your opinion in a manner that is offensive to a large portion of the population? It is not necessary. I am not trying to have an argument with you. I think I perhaps offended you in the way that I described the guy's blog, but that was honestly my reaction. It sounded like trailer trash talk. That is the impression it left on me. I also was not trying to insult the author of the blog. I did not write to him. I merely voiced my impression for other slashdot readers in response to the posting about the blog entry. No flame intended. No argument desired.
Hey, slashdot is a blog too, so I can say "whatever goes through my head when my fingers are on the keyboard", as you put it. If YOU don't like it then don't read it. ....Kind of pointless, right? So, i.e., my feeling is that if someone has only garbage to say, they should not bother to blog about it, write about it, or whatever. If you are going to publish something - and a blog IS a form of publication - then you really should make it fit for others to read. It is certainly not for the author to read - they are writing it and don't need to read it. A blog is for OTHERS to read. Thus, to be meaningful and credible, it should be clearly articulated and as logically laid out as one can. Given that blogs are somewhat stream-of-consciousness, one can still endeavor to be logical. I for one have known many people who are capable of being logical, clear, and articulate when speaking with a stream of consciousness.
I am not trying to "flame" the person. I do not believe in doing that. I try to be polite if at all possible, but the guy's blog was so crass, low-brow, and full of the f-word that it was hard to be polite, and I found it impossible to read without being offended constantly, so it failed in its mission to make its points. Perhaps people who are not offended by gutter language because they also live with it daily can get more from the commentary.
I am not sure what your comment "Oh look mum, they posted my comment on Slashdot! Whoa I'm on the web! I'm important!" is supposed to mean. I miss your point. If you are poking fun at me, you should know that I have published four books, founded and grew a $16M company (from zero), and have been a CTO and creator of compilers. What have you done? If you can't top that, then don't poke fun at me. I also have known many, many very resourceful and talented people, and the majority of them are clear thinkers, articulate, polite, and do not use foul language when expressing themselves about their work.