The summary might lean towards flame bait, but the article suggests that "more brain" is the result of a developmental disorder, not an indication of a smarter person. They suggest that the natural developmental process is to start with a lot of neuron and to gradually prune the unnecessary ones.
I have done tokenization before. You'd be amazed how low the penetration actually is. Also, the implementation I've used (one of the largest in the industry) allows me to do anything I want with the token, including turning it back into a card number. It only really protects data at rest (not that it was designed to do anything else). If the whole system gets compromised, you're still screwed. The best way to think of tokens is as unbreakable encryption -- there is no way to get credit card numbers out of a pile of stolen tokens. If you end up with a compromised system, you are at risk as long as the attacker still has control of your systems. As soon as you regain control, tokens allow you you stop the bleeding.
I'm not accusing anyone of anything. The phrase "my favorite version" obviously refers to my previous experiences elsewhere; for it to mean Sony, I would have to have a long history of experiences auditing their systems, and I would have mentioned that. Also, I do understand encryption at rest. That is exactly why a decryption stored procedure is so useless as the stored procedure gets backed up with and lives on the same storage as the data. In order for the it to work, the stored procedure has to have access to the key. It's like putting the front door key under the mat.
There are limitation to those recurring charges. For example, Sony couldn't use the recurring charge for the monthly fee to submit a payment for a separate purchase. They need the card number for that. It's all about making it as easy as possible to spend your money, not security. The only reason vendors bother to encrypt data is because the payment card industry forces them to do so.
Making purchases simple creates so much revenue that it's worth almost any risk. Even if Sony had to pay every dime of every fraudulent charge that gets through, they would still come out ahead. Remember, they copies of bits, not widgets. Every add-on sale is pure profit.
There's a bigger problem... If a system is sufficiently compromised, the attacker gets the encrypted card data, the encryption algorithm, and the keys (my favorite variation is where the database has a decryption stored procedure). We learned long ago to keep all encrypted card data in systems that have no users access and to only keep surrogate keys in transactional systems. For example, in our equivalent of the PlayStation Network, your credit card number would be stored as a meaningless number like "127". In order to process a transaction against the card, "127" and the transaction data is passed to the credit card system, where the credit card system looks up the real encrypted credit card number, decrypts it, and charges it. You could make the argument that we've simply moved the problem, but the credit card system is much easier to secure since no customer or even employee should ever be able to send a packet to it -- only a handful of controlled system can. Sure, if the transactional system is compromised, the attacker can process cards with our system, but as soon as we kick them out, the card data is useless to them.
As for the cryptanalysis problem, simply use a salt the same size as the card number and XOR the card number with it. Presto, perfectly random looking plain text with no (new) differential cryptanalysis vulnerabilities. You don't even need to do this if you use proper initialization vectors and a block cipher in CBC mode
Why does everybody collect and store all these data centrally?
For recurring payments. With your scheme, every user would have to enter their password every month. The biggest problem for Sony would be that everyone would be making the decision to continue paying for the service every single month. If the number is on file, then the customer has to go out of his way to cancel, but has to do nothing to stay a customer.
I work for a huge company. The corporate standard for software development is Java, so you'd think there would have a bunch of open source tools in the processes. Instead, they are heavily into the Rational tools suite and run apps on WebSphere. On the other hand, my division writes software on.Net, but we use SubVersion, NAnt, NUnit, and Wix. Our tool set is frowned upon precisely because it's free. The enterprise attitude seems to be "if it doesn't cost an-arm-and-a-leg and doesn't come with an 800 support number, it can't be any good".
I am not going to install Windows just to look at some Microsoft product's latest "features".
Cop out. You can learn plenty about the feature by simply visiting their web site or doing a Google search. But, since you seem to have a deep-seated hatred of Microsoft, you will probably just assume it's stupid and not look into it. The best military commanders studied and learned from their greatest adversaries; discounting the best features of the "other side" is just planned ignorance.
I would expect the leading crap-writers to develop their tools to deal with complexity in the crap they write
It has nothing to do with software they write. The feature exists to help users of Visual Studio, who are predominantly not Microsoft employees. Once again, your response is simply a lash-out against Microsoft without any actual thought.
I could write all of my software in vi, just like I could walk to work without shoes. I don't do either for the same reason. Some tools, although technically unnecessary, just make the job easier.
I'm sorry, I didn't realize this. Am I ugly too? This conversation style will get you far in the world.
BTW, you said the same thing I said about complexity, so you most be stupid too. Look into Visual Studio 2010's "Layer Validation" feature to see how an IDE can help manage complexity.
...They almost certainty have rather more specialised setups for building Windows (etc) during development...
It's called Team Foundation Server. It is primarily a GUI tool. Tweaking the build process is done with XML formatted build files. The Visual Studio GUI makes editing build files a snap by giving visual assistance. It has foldable sections, intellisense, and color-coding, all made better with an excellent GUI.
I have a saying that I use with my programmers. "If you are unable to work confidently on something that you don't fully understand, then you are doomed to work on projects small enough to fit inside your head." A good IDE is an invaluable tool that frees up room in your head to think about the hard stuff.
DOS is dead. The command line in Windows NT3.5 didn't have a DOS lineage. cmd.exe is a DOS command interpreter clone originally written by someone other than Microsoft (I forget who). cmd.exe simply behaves a lot like DOS did, but it has always been a native Windows program and has always had significantly different functionality from DOS's command interpreter. For example, "route print 2>&1 | more" works in both UNIX and Windows NT, but doesn't work in the command.com interpreter or on any non-Windows NT derived version of Windows.
I'm posting this from Windows 7. I just verified that Microsoft still ships both cmd.exe and command.com with the operating system. command.com is still much slower than cmd.exe and runs using the backward compatibility subsystem (ntvdm) that is built into the operating system.
You're looking for an API, not a CLI. I hate trying to call somebody's half-assed CLI tool with its own "special" command-line parameters from a script. Parsing the output is even worse, with a few exceptions. APIs like.Net and COM are well-behaved and don't freak out when a quote or carriage return is embedded in a field somewhere.
PowerShell makes any decent API behave like a CLI anyways. Writing a CLI is almost unnecessary these days. Look at recent versions of Microsoft Exchange -- everything that can be done in the administrative console can be done through PowerShell, but it has no CLI tools.
Both scenarios in at "CLI Inc." were cases of editing config files, not using a CLI. The same sed command that was used to modify the config for the BIND server and the Cisco box could have been done better with a good GUI text editor that supports regular expression based find and replace. The Windows admin could have done exactly the same text editing (at least for DNS), or could have scripted the whole thing. I've scripted a web based GUI more than once in my career.
The sad fact is that most Windows admins are bad at automation. However, it isn't the platform's fault. Windows is so easy to administer that any half-witted moron with enough persistence can manage to hold a job. There are a lot that are good at it and Microsoft has a plethora of tools for those who see the value in them. What is important isn't a CLI, but a usable API on which to build. CLIs are the "lowest common denominator" of APIs. UNIX and Linux have had a hard time establishing a common API, so that's what they are left with. Microsoft has been through several generations of APIs, each better than the one before. In the mid 1990s, any Windows admin worth his paycheck was doing VB Script with COM. Today, they are using PowerShell with.Net classes. Both are vastly superior to a CLI. Most Windows administrative tasks already have a CLI these days. If they don't, or if you want to make a better one, simply whip up a PowerShell script to use as a CLI.
Yup. I went to the SUNY at Buffalo for Mechanical Engineering. We regularly picked up RIT students that ran out of money. Every one of them had trouble catching up academically.
Most good universities reject two thirds of their applicants. ITT has never turned down a person who qualifies for a loan. The key difference is that a school with integrity won't accept a student who has zero chance of succeeding.
Except most US states are now on the road to licensing Professional Engineers in Software Engineering. As soon as the first person earns a PE in Software, there will be confusion.
It has been decided by the courts in 48 states that the term "Engineer" refers to someone who holds the title of "Professional Engineer" from that state's licensure board. However, the entire country has decided to ignore it entirely. It's essentially a massive example of civil disobedience.
So, legally, if you aren't licensed then you aren't an engineer. In reality, the term engineer has very little specific meaning outside of construction projects.
If workstations are already rooted and have keyloggers and worse, then there is no such thing as a security...
That's a false dichotomy. All but the most sensitive organizations can get by just fine with a few compromised workstations. A compromised workstation is only a threat if it can connect to its command and control network. The tools used to protect organizations from typical security problems that happen even with corporate controlled hardware are perfectly adequate to deal with employee owned hardware.
The real problems are a lot deeper. First, people in IT are often serious control freaks. This doesn't come from a stereotype, I've personally seen a lot of decisions in IT that can only be explained by the person in charge being unable to share power. Second, is the separation of security from the rest of IT. If someone is only responsible for security and not productivity, then all of their decisions will be more conservative than if they had a broader responsibility. Creating the position of Chief Security Officer virtually guarantees draconanian measures. Third is hubris. The very statement that "If I control it, it will never get a keylogger" should be grounds for dismissal. I could name a half dozen pieces of software my company uses that make it impossible to properly secure a workstation. How do you prevent malware when application A requires unfettered Internet access, application B requires admin rights, and application C only runs on XP, and none of the three run on Citrix? We officially support over nine hundred and fifty applications on our network.
Having employee owned hardware actually helps because it frees IT from the energy wasting quest to secure the network from the workstation up. If you design your network with the built-in assumption that the workstations are untrusted, you are better off.
BTW, among our corporate standards are; we run XP, all users are local admins, and most software installations are done by the end user. We have fifty thousand workstations. If a workstation acts the slightest bit funky, we re-image it. Yet, I've never worked anywhere that had less of a virus problem than we do. Other issues brought up in this thread are also easier to deal with, like asset management. When a vendor comes into a typical organization and asks how many copies of application X are installed, a lot of companies have to go through their logs of what was installed where and match that up to the list of computers that are still active on the network. Inevitably, someone forgot to log an install or an uninstall somewhere and an exhausive search has to be performed anyways. We simply pull up a list from our inventory software and we know exactly where it is installed. By giving up control of installations, we are much more reliant on crawling the network and reporting, which makes us a lot more accurate.
The really interesting part is that I work at a small location that is managed somewhat separately from the rest of the company. At our site, we manage things more traditionally -- users are not admins and IT does all installation and configuration tasks. However, we are responsible to hit the same metrics that the rest of the company does. We consistently come in way behind in client satisfaction and below average in security compliance. It's not that we are bad at what we do, it's that rest of the company is really good at it.
What about things like software keyloggers on the hardware?
Of course, computers with the company image can never get one of those. Given that most large companies still use IE6 and IE6 has some security flaws that will never be fixed by Microsoft, every computer has swiss cheese security. Factor in the number of zero day exploits and slow fixes by vendors and it's quite obvious that the standard security posture has to already account for rooted workstations.
1. IT does exactly what you say and it takes years to get anything implemented. People are stuck on Office 2000 and Windows XP until 2015. New business initiatives become expensive if they require software. IT becomes the "No" part of the organization. This results in a secure system at a moderate real cost and very high opportunity cost.
2. IT tries to be as responsive as possible and compromises a bit, perhaps some high priority software is allowed on the network with minimal testing. This happens a few hundred times each year.
So, you get either a non-productive secure system or a productive insecure system. As always, the real answer is somewhere in the middle. Model 3 is end user systems that take important basic precautions like the installation and updating of antivirus software and have inventory management software so that the Asset Management department can account for licenses. In this model, it is assumed that end user computer may be compromised, so security systems are placed throughout the network. You end up with a system that is cost effective and productive.
Model 3 is very conducive to employee owned devices. Simply mandate that they have the standard anti-virus package installed and that regular software inventory scans are done and let them do what they want to do.
You only have fears and suspicions that these things will happen. We have let thousands of employees use their own stuff (that's just a pilot group for us), and have saved money. I'm not saying that it isn't more expensive to support personal devices, I'm saying that the saving are greater than the costs.
BTW, #9 isn't an IT problem, it's a legal problem. The only way for IT to prevent it on company owned computers would be to epoxy the USB ports and block almost all internet traffic, including email. Do you go that far?
Slashdot Mirror
The summary might lean towards flame bait, but the article suggests that "more brain" is the result of a developmental disorder, not an indication of a smarter person. They suggest that the natural developmental process is to start with a lot of neuron and to gradually prune the unnecessary ones.
I have done tokenization before. You'd be amazed how low the penetration actually is. Also, the implementation I've used (one of the largest in the industry) allows me to do anything I want with the token, including turning it back into a card number. It only really protects data at rest (not that it was designed to do anything else). If the whole system gets compromised, you're still screwed. The best way to think of tokens is as unbreakable encryption -- there is no way to get credit card numbers out of a pile of stolen tokens. If you end up with a compromised system, you are at risk as long as the attacker still has control of your systems. As soon as you regain control, tokens allow you you stop the bleeding.
I'm not accusing anyone of anything. The phrase "my favorite version" obviously refers to my previous experiences elsewhere; for it to mean Sony, I would have to have a long history of experiences auditing their systems, and I would have mentioned that. Also, I do understand encryption at rest. That is exactly why a decryption stored procedure is so useless as the stored procedure gets backed up with and lives on the same storage as the data. In order for the it to work, the stored procedure has to have access to the key. It's like putting the front door key under the mat.
There are limitation to those recurring charges. For example, Sony couldn't use the recurring charge for the monthly fee to submit a payment for a separate purchase. They need the card number for that. It's all about making it as easy as possible to spend your money, not security. The only reason vendors bother to encrypt data is because the payment card industry forces them to do so.
Making purchases simple creates so much revenue that it's worth almost any risk. Even if Sony had to pay every dime of every fraudulent charge that gets through, they would still come out ahead. Remember, they copies of bits, not widgets. Every add-on sale is pure profit.
Of course you wouldn't. But the marketing department would never allow a system where you can passively unsubscribe.
There's a bigger problem... If a system is sufficiently compromised, the attacker gets the encrypted card data, the encryption algorithm, and the keys (my favorite variation is where the database has a decryption stored procedure). We learned long ago to keep all encrypted card data in systems that have no users access and to only keep surrogate keys in transactional systems. For example, in our equivalent of the PlayStation Network, your credit card number would be stored as a meaningless number like "127". In order to process a transaction against the card, "127" and the transaction data is passed to the credit card system, where the credit card system looks up the real encrypted credit card number, decrypts it, and charges it. You could make the argument that we've simply moved the problem, but the credit card system is much easier to secure since no customer or even employee should ever be able to send a packet to it -- only a handful of controlled system can. Sure, if the transactional system is compromised, the attacker can process cards with our system, but as soon as we kick them out, the card data is useless to them.
As for the cryptanalysis problem, simply use a salt the same size as the card number and XOR the card number with it. Presto, perfectly random looking plain text with no (new) differential cryptanalysis vulnerabilities. You don't even need to do this if you use proper initialization vectors and a block cipher in CBC mode
Why does everybody collect and store all these data centrally?
For recurring payments. With your scheme, every user would have to enter their password every month. The biggest problem for Sony would be that everyone would be making the decision to continue paying for the service every single month. If the number is on file, then the customer has to go out of his way to cancel, but has to do nothing to stay a customer.
I'm not so sure.
.Net, but we use SubVersion, NAnt, NUnit, and Wix. Our tool set is frowned upon precisely because it's free. The enterprise attitude seems to be "if it doesn't cost an-arm-and-a-leg and doesn't come with an 800 support number, it can't be any good".
I work for a huge company. The corporate standard for software development is Java, so you'd think there would have a bunch of open source tools in the processes. Instead, they are heavily into the Rational tools suite and run apps on WebSphere. On the other hand, my division writes software on
Unfortunately, the same feature makes it possible to cause an FTP server to mount an attack on any server on your behalf.
I am not going to install Windows just to look at some Microsoft product's latest "features".
Cop out. You can learn plenty about the feature by simply visiting their web site or doing a Google search. But, since you seem to have a deep-seated hatred of Microsoft, you will probably just assume it's stupid and not look into it. The best military commanders studied and learned from their greatest adversaries; discounting the best features of the "other side" is just planned ignorance.
I would expect the leading crap-writers to develop their tools to deal with complexity in the crap they write
It has nothing to do with software they write. The feature exists to help users of Visual Studio, who are predominantly not Microsoft employees. Once again, your response is simply a lash-out against Microsoft without any actual thought.
I could write all of my software in vi, just like I could walk to work without shoes. I don't do either for the same reason. Some tools, although technically unnecessary, just make the job easier.
Your saying is stupid, and you are stupid.
I'm sorry, I didn't realize this. Am I ugly too? This conversation style will get you far in the world.
BTW, you said the same thing I said about complexity, so you most be stupid too. Look into Visual Studio 2010's "Layer Validation" feature to see how an IDE can help manage complexity.
...They almost certainty have rather more specialised setups for building Windows (etc) during development...
It's called Team Foundation Server. It is primarily a GUI tool. Tweaking the build process is done with XML formatted build files. The Visual Studio GUI makes editing build files a snap by giving visual assistance. It has foldable sections, intellisense, and color-coding, all made better with an excellent GUI.
I have a saying that I use with my programmers. "If you are unable to work confidently on something that you don't fully understand, then you are doomed to work on projects small enough to fit inside your head." A good IDE is an invaluable tool that frees up room in your head to think about the hard stuff.
DOS is dead. The command line in Windows NT3.5 didn't have a DOS lineage. cmd.exe is a DOS command interpreter clone originally written by someone other than Microsoft (I forget who). cmd.exe simply behaves a lot like DOS did, but it has always been a native Windows program and has always had significantly different functionality from DOS's command interpreter. For example, "route print 2>&1 | more" works in both UNIX and Windows NT, but doesn't work in the command.com interpreter or on any non-Windows NT derived version of Windows.
I'm posting this from Windows 7. I just verified that Microsoft still ships both cmd.exe and command.com with the operating system. command.com is still much slower than cmd.exe and runs using the backward compatibility subsystem (ntvdm) that is built into the operating system.
You're looking for an API, not a CLI. I hate trying to call somebody's half-assed CLI tool with its own "special" command-line parameters from a script. Parsing the output is even worse, with a few exceptions. APIs like .Net and COM are well-behaved and don't freak out when a quote or carriage return is embedded in a field somewhere.
PowerShell makes any decent API behave like a CLI anyways. Writing a CLI is almost unnecessary these days. Look at recent versions of Microsoft Exchange -- everything that can be done in the administrative console can be done through PowerShell, but it has no CLI tools.
Both scenarios in at "CLI Inc." were cases of editing config files, not using a CLI. The same sed command that was used to modify the config for the BIND server and the Cisco box could have been done better with a good GUI text editor that supports regular expression based find and replace. The Windows admin could have done exactly the same text editing (at least for DNS), or could have scripted the whole thing. I've scripted a web based GUI more than once in my career.
.Net classes. Both are vastly superior to a CLI. Most Windows administrative tasks already have a CLI these days. If they don't, or if you want to make a better one, simply whip up a PowerShell script to use as a CLI.
The sad fact is that most Windows admins are bad at automation. However, it isn't the platform's fault. Windows is so easy to administer that any half-witted moron with enough persistence can manage to hold a job. There are a lot that are good at it and Microsoft has a plethora of tools for those who see the value in them. What is important isn't a CLI, but a usable API on which to build. CLIs are the "lowest common denominator" of APIs. UNIX and Linux have had a hard time establishing a common API, so that's what they are left with. Microsoft has been through several generations of APIs, each better than the one before. In the mid 1990s, any Windows admin worth his paycheck was doing VB Script with COM. Today, they are using PowerShell with
Yup. I went to the SUNY at Buffalo for Mechanical Engineering. We regularly picked up RIT students that ran out of money. Every one of them had trouble catching up academically.
Most good universities reject two thirds of their applicants. ITT has never turned down a person who qualifies for a loan. The key difference is that a school with integrity won't accept a student who has zero chance of succeeding.
Except most US states are now on the road to licensing Professional Engineers in Software Engineering. As soon as the first person earns a PE in Software, there will be confusion.
It has been decided by the courts in 48 states that the term "Engineer" refers to someone who holds the title of "Professional Engineer" from that state's licensure board. However, the entire country has decided to ignore it entirely. It's essentially a massive example of civil disobedience.
So, legally, if you aren't licensed then you aren't an engineer. In reality, the term engineer has very little specific meaning outside of construction projects.
If workstations are already rooted and have keyloggers and worse, then there is no such thing as a security...
That's a false dichotomy. All but the most sensitive organizations can get by just fine with a few compromised workstations. A compromised workstation is only a threat if it can connect to its command and control network. The tools used to protect organizations from typical security problems that happen even with corporate controlled hardware are perfectly adequate to deal with employee owned hardware.
The real problems are a lot deeper. First, people in IT are often serious control freaks. This doesn't come from a stereotype, I've personally seen a lot of decisions in IT that can only be explained by the person in charge being unable to share power. Second, is the separation of security from the rest of IT. If someone is only responsible for security and not productivity, then all of their decisions will be more conservative than if they had a broader responsibility. Creating the position of Chief Security Officer virtually guarantees draconanian measures. Third is hubris. The very statement that "If I control it, it will never get a keylogger" should be grounds for dismissal. I could name a half dozen pieces of software my company uses that make it impossible to properly secure a workstation. How do you prevent malware when application A requires unfettered Internet access, application B requires admin rights, and application C only runs on XP, and none of the three run on Citrix? We officially support over nine hundred and fifty applications on our network.
Having employee owned hardware actually helps because it frees IT from the energy wasting quest to secure the network from the workstation up. If you design your network with the built-in assumption that the workstations are untrusted, you are better off.
BTW, among our corporate standards are; we run XP, all users are local admins, and most software installations are done by the end user. We have fifty thousand workstations. If a workstation acts the slightest bit funky, we re-image it. Yet, I've never worked anywhere that had less of a virus problem than we do. Other issues brought up in this thread are also easier to deal with, like asset management. When a vendor comes into a typical organization and asks how many copies of application X are installed, a lot of companies have to go through their logs of what was installed where and match that up to the list of computers that are still active on the network. Inevitably, someone forgot to log an install or an uninstall somewhere and an exhausive search has to be performed anyways. We simply pull up a list from our inventory software and we know exactly where it is installed. By giving up control of installations, we are much more reliant on crawling the network and reporting, which makes us a lot more accurate.
The really interesting part is that I work at a small location that is managed somewhat separately from the rest of the company. At our site, we manage things more traditionally -- users are not admins and IT does all installation and configuration tasks. However, we are responsible to hit the same metrics that the rest of the company does. We consistently come in way behind in client satisfaction and below average in security compliance. It's not that we are bad at what we do, it's that rest of the company is really good at it.
What about things like software keyloggers on the hardware?
Of course, computers with the company image can never get one of those. Given that most large companies still use IE6 and IE6 has some security flaws that will never be fixed by Microsoft, every computer has swiss cheese security. Factor in the number of zero day exploits and slow fixes by vendors and it's quite obvious that the standard security posture has to already account for rooted workstations.
This model always leads to one of two endpoints:
1. IT does exactly what you say and it takes years to get anything implemented. People are stuck on Office 2000 and Windows XP until 2015. New business initiatives become expensive if they require software. IT becomes the "No" part of the organization. This results in a secure system at a moderate real cost and very high opportunity cost.
2. IT tries to be as responsive as possible and compromises a bit, perhaps some high priority software is allowed on the network with minimal testing. This happens a few hundred times each year.
So, you get either a non-productive secure system or a productive insecure system. As always, the real answer is somewhere in the middle. Model 3 is end user systems that take important basic precautions like the installation and updating of antivirus software and have inventory management software so that the Asset Management department can account for licenses. In this model, it is assumed that end user computer may be compromised, so security systems are placed throughout the network. You end up with a system that is cost effective and productive.
Model 3 is very conducive to employee owned devices. Simply mandate that they have the standard anti-virus package installed and that regular software inventory scans are done and let them do what they want to do.
You only have fears and suspicions that these things will happen. We have let thousands of employees use their own stuff (that's just a pilot group for us), and have saved money. I'm not saying that it isn't more expensive to support personal devices, I'm saying that the saving are greater than the costs.
BTW, #9 isn't an IT problem, it's a legal problem. The only way for IT to prevent it on company owned computers would be to epoxy the USB ports and block almost all internet traffic, including email. Do you go that far?
What if they gave you $600 and a copy of Microsoft Office?