Jim Manico has produced another great addition to his OWASP podcast canon, the latest discussion is with Richard Bejtlich. Jim is very good as an interviewer which means the questions are all meat and potatoes on in the trenches issues. 

One of the main points that Richard makes that is lost on many security programs is how to take information security concerns and then communicate them to the business. How do you talk about security to people (i.e. business) that could care less about SQL injection. As James McGovern says, the business doesn't want a maturity model, they want working software. 

Richard talks about extending the communication through using threats, and that this is a way to put a face on the problem. I have no doubt that this works well. The BBC show "Spooks" (called MI-5 in the US) is a pretty detailed (for a TV show) look at counter terrorism in the UK, they get into a lot of hidden assumptions we have about the intersection of security and privacy. One of the criticisms of the show is that it looks like all the problems are solved in one hour by the same three people. And this is one issue I have with using threats as the primary means for communicating security concerns to the business. I have no doubt its effective, and its for sure an important part of telling the story, but I think some aspects are not addressed if there's an overfocus on threats. Threats must be assumed but its resilience and survivability that matter in the end and that goes back to your company's mission. 

I came up originally looking at security as something that we solve through equal parts access control, defensive coding, and crypto. Those are still the basic workhorses of most software security regimes, but there is a missing piece. For me, Richard's work going back Tao of Security Monitoring is the best distillation that made me realize that all of the above areas must be backstopped by a robust detection and response lifecycle, or what Richard calls "Building Visibility In" 

So in terms of building visibility in, every process that we design/code for should have a "monitor first" mandate. We saw the lack of this just recently with the Chip and PIN fiasco. There are real challenges to getting the right amount of visibility in the app. Where you put the detection determines what you see. On the presentation layer it looks like raw HTTP, at the middle tier it looks more transaction-like and at the DAO layer you can observe the data operations. In the secure audit logging class I teach we go through each of these areas and its very interesting to see what you can see from these different angles, just like turning a Rubiks cube. 

Jim and Richard explore a couple of other areas - issues around incidents/compliance for funding (for which I propose the need for a flat tax). Jim asks about how attackers have advantage, and Richard responds with his black hat budget, in other words what can the bad guys do with a fraction of your assets.  

Jim asked Richard a question I sent in - "The trustworthiness of a digital asset is limited by the owner's capability to detect incidents compromising the integrity of that asset." Given that we don't have any high integrity database, identities or application servers - how do you detect a breach of integrity when there is no verifiable integrity in the system in the first place?"

Richard's response is that trustworthiness impossible inside an asset itself (agree)- for an asset to defend itself look outside of the asset. The network is a cheap way to watch. That logic makes perfect sense to me, but it still makes sense to push for more and better data out of the apps. There is a lot of context there about transactions, data, identity and so on that can be harvested.

I quite liked the final challenge that Richard threw down - enterprises need to focus on getting real data. How many of us have an accurate scoreboard based on real data?

Jim Manico has produced another great addition to his OWASP podcast canon, the latest discussion is with Richard Bejtlich. Jim is very good as an interviewer which means the questions are all meat and potatoes on in the trenches issues. 

One of the main points that Richard makes that is lost on many security programs is how to take information security concerns and then communicate them to the business. How do you talk about security to people (i.e. business) that could care less about SQL injection. As James McGovern says, the business doesn't want a maturity model, they want working software. 

Richard talks about extending the communication through using threats, and that this is a way to put a face on the problem. I have no doubt that this works well. The BBC show "Spooks" (called MI-5 in the US) is a pretty detailed (for a TV show) look at counter terrorism in the UK, they get into a lot of hidden assumptions we have about the intersection of security and privacy. One of the criticisms of the show is that it looks like all the problems are solved in one hour by the same three people. And this is one issue I have with using threats as the primary means for communicating security concerns to the business. I have no doubt its effective, and its for sure an important part of telling the story, but I think some aspects are not addressed if there's an overfocus on threats. Threats must be assumed but its resilience and survivability that matter in the end and that goes back to your company's mission. 

I came up originally looking at security as something that we solve through equal parts access control, defensive coding, and crypto. Those are still the basic workhorses of most software security regimes, but there is a missing piece. For me, Richard's work going back Tao of Security Monitoring is the best distillation that made me realize that all of the above areas must be backstopped by a robust detection and response lifecycle, or what Richard calls "Building Visibility In" 

So in terms of building visibility in, every process that we design/code for should have a "monitor first" mandate. We saw the lack of this just recently with the Chip and PIN fiasco. There are real challenges to getting the right amount of visibility in the app. Where you put the detection determines what you see. On the presentation layer it looks like raw HTTP, at the middle tier it looks more transaction-like and at the DAO layer you can observe the data operations. In the secure audit logging class I teach we go through each of these areas and its very interesting to see what you can see from these different angles, just like turning a Rubiks cube. 

Jim and Richard explore a couple of other areas - issues around incidents/compliance for funding (for which I propose the need for a flat tax). Jim asks about how attackers have advantage, and Richard responds with his black hat budget, in other words what can the bad guys do with a fraction of your assets.  

Jim asked Richard a question I sent in - "The trustworthiness of a digital asset is limited by the owner's capability to detect incidents compromising the integrity of that asset." Given that we don't have any high integrity database, identities or application servers - how do you detect a breach of integrity when there is no verifiable integrity in the system in the first place?"

Richard's response is that trustworthiness impossible inside an asset itself (agree)- for an asset to defend itself look outside of the asset. The network is a cheap way to watch. That logic makes perfect sense to me, but it still makes sense to push for more and better data out of the apps. There is a lot of context there about transactions, data, identity and so on that can be harvested.

I quite liked the final challenge that Richard threw down - enterprises need to focus on getting real data. How many of us have an accurate scoreboard based on real data?

by Christian Moldes

In Outliers, Malcom Gladwell analyses how plane crashes are the result of a combination of errors. I found this analysis very interesting because of the similarity with most security breaches. A brief excerpt of his book:

“Plane crashes rarely happen in real life the same way they happen in the movies. Some engine part does not explode in a fiery bang. The rudder doesn’t suddenly snap under the force of takeoff. The captain doesn’t gasp, “Dear God,” as he’s thrown back against his seat. The typical commercial jetliner – at this point in its stage of development – is about as dependable as a toaster. Plane crashes are much more likely to be the result of an accumulation of minor difficulties and seemingly trivial malfunctions.

The typical accident involves seven consecutive human errors. One of the pilots does something wrong that by itself is not a problem. Then one of them makes another error on top of that, which combined with the first error still does not amount to catastrophe. But then they make a third error on top of that, and then another and another and another and another, and it is the combination of all those errors that leads to disaster.”

Security breaches happen exactly like that. They are the result of a combination of minor or seemingly insignificant errors. Let me illustrate this. A few years ago, a merchant suffered a breach, and its case is one of the best examples for this topic. Their e-commerce website was developed in-house but some of the components had been developed by a third party. The application had been thoroughly reviewed for security vulnerabilities and none had been identified as risky. However, one of the components was not reviewed, it was added a few days after the application review had been completed, and since it was not related in any way with payment transactions, it was deemed as non-critical.

The merchant had a network IDS which was maintained and monitored by a MSS (managed security services) vendor. The device had signatures that were able to recognize SQL injection attempts and they were supposedly enabled. One of the vendor’s security analysts disabled rules monitoring attacks on port 80 and 443 for the e-commerce servers. This was probably because they generated many false-positive alerts, and was most likely intended as a temporary action. As a result, none of the attacks and unusual traffic on those ports was detected by the IDS.

The e-commerce site was using a trusted relationship to connect to the database. Credit card numbers had been encrypted in the database a few months ago. During the process as a contingency plan, the DBA exported the tables containing sensitive data before encrypting some of the columns. The backup files had been left on the database server since then.

Hackers found the security vulnerability in the e-commerce website; the third-party component was vulnerable to SQL injection. By exploiting the vulnerability, they were able to create local administrator accounts on the database server and run OS commands with local administrator privileges. Unfortunately, since the IDS was not monitoring traffic on ports 90 and 443, none of the SQL probes was detected by the IDS, nor was any other unusual traffic on those ports. Remote management tools were installed and password hashes were cracked off-line. The hackers reviewed every folder on the web server looking for scripts, source code, and data files. They found the backup files left behind by the DBA.

The merchant was only aware of the intrusion several months after the fact, when they were notified by law enforcement agents that their data was on sale on one of the carders websites.

This case clearly illustrates that even when proper security controls are in place, a breach could happen at any moment. Relying on single controls or single layers of security is never sufficient.

The case also illustrates the need to assess security controls independently of any other surrounding security or other layers of security. QSAs and internal staff in charge of PCI DSS compliance should not consider risk-based discussions until all the security controls have been independently assessed.

by Christian Moldes

In Outliers, Malcom Gladwell analyses how plane crashes are the result of a combination of errors. I found this analysis very interesting because of the similarity with most security breaches. A brief excerpt of his book:

“Plane crashes rarely happen in real life the same way they happen in the movies. Some engine part does not explode in a fiery bang. The rudder doesn’t suddenly snap under the force of takeoff. The captain doesn’t gasp, “Dear God,” as he’s thrown back against his seat. The typical commercial jetliner – at this point in its stage of development – is about as dependable as a toaster. Plane crashes are much more likely to be the result of an accumulation of minor difficulties and seemingly trivial malfunctions.

The typical accident involves seven consecutive human errors. One of the pilots does something wrong that by itself is not a problem. Then one of them makes another error on top of that, which combined with the first error still does not amount to catastrophe. But then they make a third error on top of that, and then another and another and another and another, and it is the combination of all those errors that leads to disaster.”

Security breaches happen exactly like that. They are the result of a combination of minor or seemingly insignificant errors. Let me illustrate this. A few years ago, a merchant suffered a breach, and its case is one of the best examples for this topic. Their e-commerce website was developed in-house but some of the components had been developed by a third party. The application had been thoroughly reviewed for security vulnerabilities and none had been identified as risky. However, one of the components was not reviewed, it was added a few days after the application review had been completed, and since it was not related in any way with payment transactions, it was deemed as non-critical.

The merchant had a network IDS which was maintained and monitored by a MSS (managed security services) vendor. The device had signatures that were able to recognize SQL injection attempts and they were supposedly enabled. One of the vendor’s security analysts disabled rules monitoring attacks on port 80 and 443 for the e-commerce servers. This was probably because they generated many false-positive alerts, and was most likely intended as a temporary action. As a result, none of the attacks and unusual traffic on those ports was detected by the IDS.

The e-commerce site was using a trusted relationship to connect to the database. Credit card numbers had been encrypted in the database a few months ago. During the process as a contingency plan, the DBA exported the tables containing sensitive data before encrypting some of the columns. The backup files had been left on the database server since then.

Hackers found the security vulnerability in the e-commerce website; the third-party component was vulnerable to SQL injection. By exploiting the vulnerability, they were able to create local administrator accounts on the database server and run OS commands with local administrator privileges. Unfortunately, since the IDS was not monitoring traffic on ports 90 and 443, none of the SQL probes was detected by the IDS, nor was any other unusual traffic on those ports. Remote management tools were installed and password hashes were cracked off-line. The hackers reviewed every folder on the web server looking for scripts, source code, and data files. They found the backup files left behind by the DBA.

The merchant was only aware of the intrusion several months after the fact, when they were notified by law enforcement agents that their data was on sale on one of the carders websites.

This case clearly illustrates that even when proper security controls are in place, a breach could happen at any moment. Relying on single controls or single layers of security is never sufficient.

The case also illustrates the need to assess security controls independently of any other surrounding security or other layers of security. QSAs and internal staff in charge of PCI DSS compliance should not consider risk-based discussions until all the security controls have been independently assessed.