They expect the payor to do that. If you write someone a check for $50 and you see a withdrawal of $500, it's your responsibility to report it. The only thing keeping the entire sysytem from crashing down is the stiff penalties for screwing with it. I have software at work that allows me to accept a check from a customer over the phone. They literally read the numbers and I type them in. This is no less secure.
IIS doesn't really run as any specific user. The packet router, HTTP.sys, runs as LocalSystem. However the thread processing the request changes its security context very early in the request processing to a low priviledged account.
My motorcycle requires a lot of special "factory" tools to totally disassemble it. I have a CNC mill, so I make my own tools instead of paying hundreds for the official tools. I try to make tools out of sockets whenever possible because they snap right on a torque wrench. After trying several brands, I now always buy Craftsmen socket to mill into tools because the Husky, Blackhawk, and Snapon ones I've tried before dull my end mills very quickly. Craftsmen sockets cut like butter.
BTW, a typical custom tool would be a 27mm socket with the end 5mm milled down to four studs, each 3mm square. This tool fits on the interesting nut that is used to tighten the steering head bearings.
Open standards from whom? Since we aren't talking about web applications, W3C can't create standards in this space. If the Apache Software Foundation had done WPF instead of Microsoft, it would probably already have set the world on fire.
I was once a part of a software project to build a software-as-a-service course evaluation product. I have a lot of experience in for-profit training. In my industry, we lived and died by reputation and we strived to have the best educators in every classroom. My role in the project was both as a software architect and domain knowledge specialist.
I eventually left the project because any technology we introduced that seemed to accurately assess an educator was seen as a defect and made the sale really difficult. We were forced to blown sunshine up everyone's butt and create a product that would spit out reports that showed that everything was great.
Also, back in my training days, we had regular workshops that turned out to be an interesting petri dishes for educator assessments. For a short period, our yearly performance reviews were tied directly to the numeric evaluation submitted by students. We would go through recent evaluations, find weak points, and brainstorm how to get the evalution numbers up. It turned out that the easiest way to improve numbers was to present the evaluation differently. If you ask for an honest opinion, or make feedback optional, then the students who didn't really care much would skip the eval while the ones who had a specific gripe would be sure to fill out the form completely. If you present the evaluation as mandatory and ask for "detailed written feedback about how an educator could improve himself" for any non-perfect score, then it seemed like you really cared about hearing everyone's problems and addressing all of them. In reality, it discouraged some fence-sitting students from giving bad reviews and got the students who just wanted to leave to give you perfect scores. We improved every educator's evaluation scores to the highest bracket we had without changing any in-classroom behaviors.
Moral of the story -- If you make evaluations count for anything tangible, they will be gamed and abused and therefore will be less useful.
Just to be clear, I wasn't advocating rewriting library code to understand it better. I was simply suggesting that being a real programmer is always important, library or not. Code monkeys will produce bad results no matter how rich and well-debugged their library is.
Another point, you seem to think that I would know not to abuse Array.Sort because I know its implementation. On the contrary, I don't abuse any sort method precisely because I don't know its implementation, but I do know that the implementer only gauranteed me that it would properly sort. I also know that shuffling is a distict problem from sorting and there are known problems that arise from treating shuffling as random (at least inconsistently random) sorting, including crashing the library code. This would be true of a well-known sort method in a popular library, and also of idiot-Bob-down-the-hall's sort routine.
It turns out that you need a lot of CS knowledge to code, even with a large library.
Unfortunately, JavaScript was meant to be a systems language. Remember when Netscape said they would "reduce Windows to a seriers of poorly-debugged device drivers"? Also what you are asking for has already been invented. I can think of two examples; Mozilla's XUL and Microsoft's WPF. WPF is not tied to any language and there is even a partial open source implementation (Moonlight). The problem is that they don't look like web applications.
It seems that managers heard ten years ago that web applications were client-platform-independent, centrally maintainable, scalable, and easy to deploy. Since then, they have been pushing everything to be a web application. Java, that desktop Flash thing that I forgot the name, WPF, SilverLight, XUL, ClickOnce, and a host of other solutions have been invented that each solve some or all of the list of problem that web applications originally solved. However, they are not web application and therefore are not accepted. The real tragedy is that many companies are developing web apps that only run in IE6 and use ActiveX controls. That specific combination ruins almost every advantage that a web application has.
Unfortunately it isn't that easy. There was an article here a few days ago where someone tried to shuffle an array by passing a random comparer to Array.Sort(Comparer c). It didn't do what they wanted. A "real programmer" would have identified this as an off-label use of sorting and would instantly recognize the potential pitfalls. A "library user" could fall into this trap easily. Every day for a programmer is full of moments where using the wrong library call may introduce bugs. Real programmers are also pretty good at eyeballing what parts of a program are likely to be performance bottlenecks and designing the program so any one of several standard solution patterns can be applied later if necessary. These "real programmer" techniques sometimes slightly increase the amount of code written, but rarely turn into library rewrites, and almost always make fixing and altering the program more pleasant.
In the MS world, a view does not cause a table scan. A view cannot be indexed because it doesn't physically exist (the data, not the definition). When a user selects from a view, the query optimizer rewrites the query as a select on the underlying tables then optimizes it. This allows all of the indexes that exist on the underlying table to be used when a view is queried.
What about three tier applications? For connection pooling to work properly, the middle tier should always connect to the database as the same application user. Having the middle tier connect as the actual user running the application makes connections non-shareable. So, the application user needs access to everything that any user could potentially need access to. Also, the database isn't even aware of who the request is sent on behalf of.
Database-level permission also prohibits caching in the middel tier. Since the middle tier can't be trusted to make security determinations, it would always have to re-fetch data to ensure that proper security is applied. Caching is the single most powerful performance enhancement tool.
You mean like the text boxes in ASP.Net that don't accept angle brackets by default? Unfortunately, this doesn't work with SQL. The most popular escape character is the single quote, which is also common in strings (like the last name O'Brien). SQL injection protection is easy if you keep one rule in mind -- never ever ever ever use string concatenation to build SQL. Use your DB library's bind variable feature.
Unfortunately, as simple as SQL injection protection is, a large percentage of people don't do it. Much of it is due to a lack of training or conflicting information. Just look at this thread -- half of the people are piping in with the correct answer (variables) and the other half are spouting solutions which don't solve the SQL Injection problem (stored procedures and persistence libraries). Both wrong solution partially solve the problem, but not completely. Persistence libraries all have a way to specify actual SQL issued and someone always abuses this feature create a SQL Injection vulnerability. Stored procedures fix some variations of SQL Injections, but if the stored procedure call doesn't properly use bind variables, then the call itself is vulnerable to SQL Injection.
Morons are morons. Advocating stored procedures will not fix them. As more code moves to stored procedures, you'll need to hire more database developers. There is a very limited supply of non-morons in the world. Eventually, your stored procedure writing team will be populated by the same morons that wrote the interface code that made your head explode.
Unless the dynamic SQL is all generated in one Data Access Layer library that is far more searchable than the pile of seven thousand stored procedures, most of which are no longer used by any application.
I'm not saying that stored procedure are inherently bad or dynamic SQL is inherently good. I'm saying that that badness or goodness is derived from the quality of the code, not the container it resides in. Stored procedures don't magically turn morons into geniuses. I'll also add that most DBMSs have a poor native language. Java or C# are a thousand times better than T-SQL at doing conditions, loops, error handling, and all of the other stuff that goes on in a non-trivial data access layer, with the exception of set based operations.
Well, my DBA has been letting a misconfigured replication publication make one of my apps slow as molasses for 5 months now. He keeps pointing at my app whenever it comes up in meetings. However, the app runs great in the stage environment (even with the same load as production) and -- this is the best part -- he still has yet to break out SQL Profiler and give anybody any data.
So, the moral of the story is still "good people create good systems". Bad people screw stuff up whether they are developers or DBAs. I hate it when good DBAs think that all power should rest with them because everybody else is stupid.
Rest assured that I will start embedding my DBMS (BerkeleyDB or similar) into my applications if you start negatively impacting my productivity. As the number of applications that use your DBMS decreases, DBA staff will be cut.
When is the last time you used the browscap.ini file? In Microsoft land, the file was used in ASP, but ASP.Net has a different detection methodology. That means that this hasn't been the current way to do it for nine years. Dot Net framework service packs are actually pretty good about keeping up with third party browser capabilities. Even back in the bad old ASP days, no one forced anyone to use the BrowserType object, the HTTP_USER_AGENT property was fully exposed to do any alternate type of browser checking.
In my fourteen years of developing applications that run on IIS (IDC --> ASP --> ASP.Net), I've never had a problem supporting non-IE browsers. I have also never felt compelled to use ActiveX. I've been tempted by Windows Authentication for Intranet apps, but that was an example of a genuinely useful proprietary feature of IE, so useful that FireFox eventually adopted it. As for the broken DOM in IE, I suffered through that like everyone else. My suffering was not lessened by the fact that I was developing on IIS, and IIS offered no help for supporting IE's quirks. I have used a ton of Microsoft proprietary server-side technology, but most of it was browser agnostic.
IIS and IE have nothing to do with each other. The two show up in the same conversations only due to correlation -- software that attempts lock-in to IE will of course be written on a Microsoft platform and will therefore almost always run on IIS. However, most IE lock-in technologies, like the incompatible DOM and CSS quirks, can be served from any server-side platform. IE was targeted at Netscape and.Net was supposed to be the "Java killer" (there was Microsoft J++ before.Net, but nobody ever used it)
ActiveX was an attempt by the Windows team at Microsoft to subvert the entire transition to web based applications by introducing a way to create Windows applications that seemed to be web applications. The IE team has just as much reason to hate ActiveX as the Firefox or Safari guys do.
Office has always been the big money maker. It wasn't until Windows '95 that the desktop OS division started showing a profit at all. Server profits didn't take off until Microsoft starting winning the war against Novell in the late '90s.
I have a Windows server that runs a service that integrates our PBX with our applications. When we were in the design phase of setting up the system, I had a conversation with the reseller about availablity. It went like this:
Me: Can we run it on a VMware HA cluster?
Them: Nope, not supported.
Me: Really, even though this is a software-only solution?
Them: Really, nope.
Me: Can we run it on MS Cluster Server?
Them: Nope.
Me: Can we buy two of them for failover purposes?
Them: Nope, only one instance can be registered with the PBX.
Me: Can we buy a second piece of hardware and install the software on it as a cold spare?
Them: Nope, it will miss calling home and de-activate itself.
Me: Can we keep the second sever running all the time and pay for a second license?
Them: Nope, vendor will only sell one software license per PBX.
Me: What do we do when it eventually fails?
Them: Best possible plan -- back it up regularly. When it fails, restore it to a new server and give us a call. We'll be there within four hours to begin the process of reinstalling the licenses. Best possible recovery time from failure is about six hours. BTW, we are a call center and will have to shut down for a day when this happens.
PS, "Them" is one of the largest PBX vendors in the world. The software costs about $2000 a seat. This is the single most expensive and mission critcal piece of vendor software we use. It cannot be installed in a fault-tolerate manner.
No, we take a potentially lethal device, and give it to some techs who make $15 an hour, and are union. If they kill anybody, we find out about it years later through some data mining, write a report, and send them to jail. That is more effective than doubling their salary and hoping that they are now less distracted due to the reduced financial pressure in their lives. Higher pay is for people who are hard to replace, not for people who just happen to be in a gateway position.
What's important here is that it isn't an either/or scenario. We can fix the underlying problems without abandoning radiation treatment. The much quoted in this thread Therac-25 incidents are part of why this problem hasn't been solved. Twenty years ago, someone sold some radiation treatment equipment run by horribly designed and poorly debugged software. Two people died and everyone involved knew why within a few years. However, no person nor company was ever punished. No real rule changes were made. Given the history of this industry, these new events are unforgivable. It's not that hard to put some practices and regulations in place that will only add five to ten percent to the cost of the treatment and will drastically reduce these "negative patient outcomes caused by preventable circumstances".
Heck, Therac-25 is the freakin' case study that people use to learn about the possible consequences of bad software design. You'd think somebody at the FDA would have heard of it and made some sort of link to the work they were doing before approving the successor to the Therac-25.
Bug free code is nearly impossible and way too expensive. Code that has nearly zero buffer overflows and no stupid defaults or wide open side doors is do-able. The vendor will fix their feature set because the customers will force them too. All this does is create the same pressure from the security angle.
Besides, most security bugs are fixed only after there is an exploit in the wild. The practice won't change anything except the time table.
Perhaps they are trying to force a new behavior pattern where the vendors actually vet their own software for secuirty flaws before they release it. In today's climate, a big vendor can let the security firms do the hard testing and then sit back and fix whatever they care to fix. In the potential future, every vendor may be forced to release software that is nearly security-hole free and scale the features back.
So why was this not discovered during the NIST certification process?
Because the certification the hardware received only verifies that the algorithm strength is sufficient and that the device is hardened against physical tampering.
It seems to me that NIST blames the software so they will not have to take blame for their faulty certification of the hardware.
Nope, it seems that the NIST has recognized that the certification, as currently written, isn't sufficient and is looking into making it more robust. Had they audited the software, they would have discovered that the software-to-hardware interface is poorly designed and not granted the certification.
Slashdot Mirror
They expect the payor to do that. If you write someone a check for $50 and you see a withdrawal of $500, it's your responsibility to report it. The only thing keeping the entire sysytem from crashing down is the stiff penalties for screwing with it. I have software at work that allows me to accept a check from a customer over the phone. They literally read the numbers and I type them in. This is no less secure.
IIS doesn't really run as any specific user. The packet router, HTTP.sys, runs as LocalSystem. However the thread processing the request changes its security context very early in the request processing to a low priviledged account.
http://www.securityfocus.com/infocus/1765
This was all fixed seven years ago. IIS 6 and later have a pretty decent security record.
My motorcycle requires a lot of special "factory" tools to totally disassemble it. I have a CNC mill, so I make my own tools instead of paying hundreds for the official tools. I try to make tools out of sockets whenever possible because they snap right on a torque wrench. After trying several brands, I now always buy Craftsmen socket to mill into tools because the Husky, Blackhawk, and Snapon ones I've tried before dull my end mills very quickly. Craftsmen sockets cut like butter.
BTW, a typical custom tool would be a 27mm socket with the end 5mm milled down to four studs, each 3mm square. This tool fits on the interesting nut that is used to tighten the steering head bearings.
Open standards from whom? Since we aren't talking about web applications, W3C can't create standards in this space. If the Apache Software Foundation had done WPF instead of Microsoft, it would probably already have set the world on fire.
I agree with the self-assessment problems.
I was once a part of a software project to build a software-as-a-service course evaluation product. I have a lot of experience in for-profit training. In my industry, we lived and died by reputation and we strived to have the best educators in every classroom. My role in the project was both as a software architect and domain knowledge specialist.
I eventually left the project because any technology we introduced that seemed to accurately assess an educator was seen as a defect and made the sale really difficult. We were forced to blown sunshine up everyone's butt and create a product that would spit out reports that showed that everything was great.
Also, back in my training days, we had regular workshops that turned out to be an interesting petri dishes for educator assessments. For a short period, our yearly performance reviews were tied directly to the numeric evaluation submitted by students. We would go through recent evaluations, find weak points, and brainstorm how to get the evalution numbers up. It turned out that the easiest way to improve numbers was to present the evaluation differently. If you ask for an honest opinion, or make feedback optional, then the students who didn't really care much would skip the eval while the ones who had a specific gripe would be sure to fill out the form completely. If you present the evaluation as mandatory and ask for "detailed written feedback about how an educator could improve himself" for any non-perfect score, then it seemed like you really cared about hearing everyone's problems and addressing all of them. In reality, it discouraged some fence-sitting students from giving bad reviews and got the students who just wanted to leave to give you perfect scores. We improved every educator's evaluation scores to the highest bracket we had without changing any in-classroom behaviors.
Moral of the story -- If you make evaluations count for anything tangible, they will be gamed and abused and therefore will be less useful.
Just to be clear, I wasn't advocating rewriting library code to understand it better. I was simply suggesting that being a real programmer is always important, library or not. Code monkeys will produce bad results no matter how rich and well-debugged their library is.
Another point, you seem to think that I would know not to abuse Array.Sort because I know its implementation. On the contrary, I don't abuse any sort method precisely because I don't know its implementation, but I do know that the implementer only gauranteed me that it would properly sort. I also know that shuffling is a distict problem from sorting and there are known problems that arise from treating shuffling as random (at least inconsistently random) sorting, including crashing the library code. This would be true of a well-known sort method in a popular library, and also of idiot-Bob-down-the-hall's sort routine.
It turns out that you need a lot of CS knowledge to code, even with a large library.
Your top end for SSDs is too low. I just paid over $1,000.00 for a 64GB SSD for a server.
http://www.cdw.com/shop/products/default.aspx?edc=2015616&cm_mmc=ShoppingFeeds-_-Pricegrabber-_-Data%20Storage/Drives-_-HP%2064GB%202.5%20SATA%20SSD_2015616
Unfortunately, JavaScript was meant to be a systems language. Remember when Netscape said they would "reduce Windows to a seriers of poorly-debugged device drivers"? Also what you are asking for has already been invented. I can think of two examples; Mozilla's XUL and Microsoft's WPF. WPF is not tied to any language and there is even a partial open source implementation (Moonlight). The problem is that they don't look like web applications.
It seems that managers heard ten years ago that web applications were client-platform-independent, centrally maintainable, scalable, and easy to deploy. Since then, they have been pushing everything to be a web application. Java, that desktop Flash thing that I forgot the name, WPF, SilverLight, XUL, ClickOnce, and a host of other solutions have been invented that each solve some or all of the list of problem that web applications originally solved. However, they are not web application and therefore are not accepted. The real tragedy is that many companies are developing web apps that only run in IE6 and use ActiveX controls. That specific combination ruins almost every advantage that a web application has.
Unfortunately it isn't that easy. There was an article here a few days ago where someone tried to shuffle an array by passing a random comparer to Array.Sort(Comparer c). It didn't do what they wanted. A "real programmer" would have identified this as an off-label use of sorting and would instantly recognize the potential pitfalls. A "library user" could fall into this trap easily. Every day for a programmer is full of moments where using the wrong library call may introduce bugs. Real programmers are also pretty good at eyeballing what parts of a program are likely to be performance bottlenecks and designing the program so any one of several standard solution patterns can be applied later if necessary. These "real programmer" techniques sometimes slightly increase the amount of code written, but rarely turn into library rewrites, and almost always make fixing and altering the program more pleasant.
In the MS world, a view does not cause a table scan. A view cannot be indexed because it doesn't physically exist (the data, not the definition). When a user selects from a view, the query optimizer rewrites the query as a select on the underlying tables then optimizes it. This allows all of the indexes that exist on the underlying table to be used when a view is queried.
Other than that, I agree with you.
What about three tier applications? For connection pooling to work properly, the middle tier should always connect to the database as the same application user. Having the middle tier connect as the actual user running the application makes connections non-shareable. So, the application user needs access to everything that any user could potentially need access to. Also, the database isn't even aware of who the request is sent on behalf of.
Database-level permission also prohibits caching in the middel tier. Since the middle tier can't be trusted to make security determinations, it would always have to re-fetch data to ensure that proper security is applied. Caching is the single most powerful performance enhancement tool.
You mean like the text boxes in ASP.Net that don't accept angle brackets by default? Unfortunately, this doesn't work with SQL. The most popular escape character is the single quote, which is also common in strings (like the last name O'Brien). SQL injection protection is easy if you keep one rule in mind -- never ever ever ever use string concatenation to build SQL. Use your DB library's bind variable feature.
Unfortunately, as simple as SQL injection protection is, a large percentage of people don't do it. Much of it is due to a lack of training or conflicting information. Just look at this thread -- half of the people are piping in with the correct answer (variables) and the other half are spouting solutions which don't solve the SQL Injection problem (stored procedures and persistence libraries). Both wrong solution partially solve the problem, but not completely. Persistence libraries all have a way to specify actual SQL issued and someone always abuses this feature create a SQL Injection vulnerability. Stored procedures fix some variations of SQL Injections, but if the stored procedure call doesn't properly use bind variables, then the call itself is vulnerable to SQL Injection.
Morons are morons. Advocating stored procedures will not fix them. As more code moves to stored procedures, you'll need to hire more database developers. There is a very limited supply of non-morons in the world. Eventually, your stored procedure writing team will be populated by the same morons that wrote the interface code that made your head explode.
Unless the dynamic SQL is all generated in one Data Access Layer library that is far more searchable than the pile of seven thousand stored procedures, most of which are no longer used by any application.
I'm not saying that stored procedure are inherently bad or dynamic SQL is inherently good. I'm saying that that badness or goodness is derived from the quality of the code, not the container it resides in. Stored procedures don't magically turn morons into geniuses. I'll also add that most DBMSs have a poor native language. Java or C# are a thousand times better than T-SQL at doing conditions, loops, error handling, and all of the other stuff that goes on in a non-trivial data access layer, with the exception of set based operations.
Well, my DBA has been letting a misconfigured replication publication make one of my apps slow as molasses for 5 months now. He keeps pointing at my app whenever it comes up in meetings. However, the app runs great in the stage environment (even with the same load as production) and -- this is the best part -- he still has yet to break out SQL Profiler and give anybody any data.
So, the moral of the story is still "good people create good systems". Bad people screw stuff up whether they are developers or DBAs. I hate it when good DBAs think that all power should rest with them because everybody else is stupid.
Rest assured that I will start embedding my DBMS (BerkeleyDB or similar) into my applications if you start negatively impacting my productivity. As the number of applications that use your DBMS decreases, DBA staff will be cut.
When is the last time you used the browscap.ini file? In Microsoft land, the file was used in ASP, but ASP.Net has a different detection methodology. That means that this hasn't been the current way to do it for nine years. Dot Net framework service packs are actually pretty good about keeping up with third party browser capabilities. Even back in the bad old ASP days, no one forced anyone to use the BrowserType object, the HTTP_USER_AGENT property was fully exposed to do any alternate type of browser checking.
In my fourteen years of developing applications that run on IIS (IDC --> ASP --> ASP.Net), I've never had a problem supporting non-IE browsers. I have also never felt compelled to use ActiveX. I've been tempted by Windows Authentication for Intranet apps, but that was an example of a genuinely useful proprietary feature of IE, so useful that FireFox eventually adopted it. As for the broken DOM in IE, I suffered through that like everyone else. My suffering was not lessened by the fact that I was developing on IIS, and IIS offered no help for supporting IE's quirks. I have used a ton of Microsoft proprietary server-side technology, but most of it was browser agnostic.
IIS and IE have nothing to do with each other. The two show up in the same conversations only due to correlation -- software that attempts lock-in to IE will of course be written on a Microsoft platform and will therefore almost always run on IIS. However, most IE lock-in technologies, like the incompatible DOM and CSS quirks, can be served from any server-side platform. IE was targeted at Netscape and .Net was supposed to be the "Java killer" (there was Microsoft J++ before .Net, but nobody ever used it)
ActiveX was an attempt by the Windows team at Microsoft to subvert the entire transition to web based applications by introducing a way to create Windows applications that seemed to be web applications. The IE team has just as much reason to hate ActiveX as the Firefox or Safari guys do.
Office has always been the big money maker. It wasn't until Windows '95 that the desktop OS division started showing a profit at all. Server profits didn't take off until Microsoft starting winning the war against Novell in the late '90s.
Vendor lock in. Software is from the PBX vendor and is the only software that is allowed to communicate with the PBX in the manner that we need it to.
I have a Windows server that runs a service that integrates our PBX with our applications. When we were in the design phase of setting up the system, I had a conversation with the reseller about availablity. It went like this:
Me: Can we run it on a VMware HA cluster?
Them: Nope, not supported.
Me: Really, even though this is a software-only solution?
Them: Really, nope.
Me: Can we run it on MS Cluster Server?
Them: Nope.
Me: Can we buy two of them for failover purposes?
Them: Nope, only one instance can be registered with the PBX.
Me: Can we buy a second piece of hardware and install the software on it as a cold spare?
Them: Nope, it will miss calling home and de-activate itself.
Me: Can we keep the second sever running all the time and pay for a second license?
Them: Nope, vendor will only sell one software license per PBX.
Me: What do we do when it eventually fails?
Them: Best possible plan -- back it up regularly. When it fails, restore it to a new server and give us a call. We'll be there within four hours to begin the process of reinstalling the licenses. Best possible recovery time from failure is about six hours. BTW, we are a call center and will have to shut down for a day when this happens.
PS, "Them" is one of the largest PBX vendors in the world. The software costs about $2000 a seat. This is the single most expensive and mission critcal piece of vendor software we use. It cannot be installed in a fault-tolerate manner.
No, we take a potentially lethal device, and give it to some techs who make $15 an hour, and are union. If they kill anybody, we find out about it years later through some data mining, write a report, and send them to jail. That is more effective than doubling their salary and hoping that they are now less distracted due to the reduced financial pressure in their lives. Higher pay is for people who are hard to replace, not for people who just happen to be in a gateway position.
Heck, Therac-25 is the freakin' case study that people use to learn about the possible consequences of bad software design. You'd think somebody at the FDA would have heard of it and made some sort of link to the work they were doing before approving the successor to the Therac-25.
Bug free code is nearly impossible and way too expensive. Code that has nearly zero buffer overflows and no stupid defaults or wide open side doors is do-able. The vendor will fix their feature set because the customers will force them too. All this does is create the same pressure from the security angle.
Besides, most security bugs are fixed only after there is an exploit in the wild. The practice won't change anything except the time table.
Perhaps they are trying to force a new behavior pattern where the vendors actually vet their own software for secuirty flaws before they release it. In today's climate, a big vendor can let the security firms do the hard testing and then sit back and fix whatever they care to fix. In the potential future, every vendor may be forced to release software that is nearly security-hole free and scale the features back.
So why was this not discovered during the NIST certification process?
Because the certification the hardware received only verifies that the algorithm strength is sufficient and that the device is hardened against physical tampering.
It seems to me that NIST blames the software so they will not have to take blame for their faulty certification of the hardware.
Nope, it seems that the NIST has recognized that the certification, as currently written, isn't sufficient and is looking into making it more robust. Had they audited the software, they would have discovered that the software-to-hardware interface is poorly designed and not granted the certification.