RiskPundit

Verizon Business extends its thought leadership in security incident metrics

The Verizon Business Security Incident Response team, whose yearly published Data Breach Investigations Reports I've written about here, has has extended its thought leadership in security incident metrics with the release of its Incident Sharing Framework. Their purpose is to enable those responsible for incident response to "create data sets that can be used and compared because of their commonality. Together, we can work to eliminate both equivocality (sic) and uncertainty, and help defend the organizations we serve." The document can be found here.

Of course Verizon Business is a for-profit organization and the license terms are as follows:

Verizon grants you a limited, revocable, personal and nontransferable license to use the Verizon Incident Sharing Framework for purposes of collecting, organizing and reporting security incident information for non-­‐commercial purposes.

Nevertheless, I do hope that this or an alternative incident sharing framework becomes an industry standard which enables the publishing and sharing of a larger number incidents from which we can all learn and improve our security policies and processes.

Top 25 Most Dangerous Programming Errors

Mitre, via its Common Weakness Enumeration effort, in conjunction with SANS, just published the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors. Heading the list are:

1. Cross-site Scripting (Score = 346)
2. SQL Injection (330)
3. Classic Buffer Overflow (273)
4. Cross-Site Request Forgery (261)
5. Improper Access Control (219)

For each weakness this report provides a Description, Prevention and Mitigation techniques, and links to more reference material. This is well worth reading.

Google discloses breach and new threat type from China - Advanced Persistent Threats

Earlier this week Google took the unprecedented step of disclosing a breach which does not legally require disclosure. Google's reasons for the disclosure are tightly linked to its concerns about human rights in China and its views on China's reasons for breaching Google's email systems. These last two points are well worth discussing and are being discussed at length all over the blogosphere. However, I am going to focus on the security and disclosure issues.

First regarding disclosure, IT risk reduction strategies greatly benefit from public breach disclosure information. In other words, organizations learn best what to do and avoid overreacting to vendor scare tactics by understanding the threats that actually result in breaches. This position is best articulated by Adam Shostack and Andrew Stewart in their book, "The New School of Information Security."

I blogged about Verizon Business's forensic team's empirical 2009 Data Breach Investigations Supplemental Report here. This report shows cause-and-effect between threat types and breaches. You could not ask for better data to guide your IT risk reduction strategies.

Organizations have been so reluctant to publicly admit they suffered breaches, the Federal and many state governments had to pass laws to force organizations to disclose breaches when customer or employee personal information was stolen.

Regarding the attack itself, it represents a type of attack that is relatively new called "advanced persistent threats" (APT) which in the past had primarily been focused on governments. Now they are targeting companies to steal intellectual property. McAfee describes the combination of spear fishing, zero-day threats, and crafted malware here. The implications:

The world has changed. Everyone’s threat model now needs to be adapted to the new reality of these advanced persistent threats. In addition to worrying about Eastern European cybercriminals trying to siphon off credit card databases, you have to focus on protecting all of your core intellectual property, private nonfinancial customer information and anything else of intangible value. 

Gunter Ollman, VP of Research at Damballa, discusses APT's further here, focusing on detecting these attacks by detecting and breaking the Command and Control (CnC) component of the threat. The key point he makes is:

Malware is just a tool. The fundamental element to these (and any espionage attack) lies with the tether that connects the victim with the attacker. Advanced Persistent Threats (APT), like their bigger and more visible brother “botnets”, are meaningless without that tether – which is more often labeled as Command and Control (CnC).

Jeremiah Grossman points out the implications of Google's breach disclosure for all cloud-based product offerings here, countering Google's announcement of Default https access for Gmail.

Indeed, the threat landscape has changed.

Schneier's take on aviation security as theater

In light of TSA's reaction to the near-miss catastrophe on Northwest Flight 253 on Christmas Day, I'm glad to see that CNN republished an article by Bruce Schneier entitled, "Is Aviation security mostly for show?"

Verizon Business 2009 DBIR Supplemental Report provides empirical guidance for unifying security and compliance priorities

The Verizon Business security forensics group's recently released 2009 Data Breach Investigations Supplemental Report provides common ground between those in the enterprise who are compliance oriented and those who are security oriented. While in theory, there should be no difference between these groups, in practice there is.   

Table 8 on page 28 evaluates the breach data set from the perspective of data types breached. Number one by far is Payment Card Data at 84%. Second is Personal Information at 31%. (Obviously each case in their data set can be categorized in multiple data breach categories.) These are exactly the types of breaches regulatory compliance standards like PCI and breach disclosure laws like Mass 201 CMR 17 are focused on.

Therefore there is high value in using the report's "threat action types" analysis to prioritize risk reduction as well as compliance programs, processes, and technologies.

While the original 2009 DBIR did provide similar information in Figure 29 on page 33, it's the Supplemental report which provides the threat action type analysis that can drive a common set of risk reduction and compliance priorities.

Relational databases dead for log management?

Larry Walsh wrote an interesting post this week, Splunk Disrupts Security Log Auditing, in which he claims that Splunk's success is due to capturing market share in the security log auditing market because of it's Google-like approach to storing log data rather than using a "relational database."

There was also a very good blog post at Securosis in response - Splunk and Unstructured Data.

While there is no doubt that Splunk has been successful as a company, I am not so sure it's due to security log auditing.

It's my understanding that the primary use case for Splunk is actually in Operations where, for example, a network administrator wants to search logs to resolve an Alert generated by an SNMP-based network management system. Most SNMP-based network management systems are good at telling you "what" is going on, but not very good at telling you "why."

So when the network management system generates an Alert, the admin goes to Splunk to find the logs that would show what actually happened so s/he can fix the root cause of the Alert. For this use case, you don't really need more than a day's worth of logs.

Splunk's brilliant move was to allow "free" usage of the software for one day's worth of logs or some limited amount of storage that generally would not exceed one day. In reality, a few hours of logs is very valuable. This freemium model has been very successful.

Security log auditing is a very different use case. It can require a year or more of data and sophisticated reporting capabilities. That is not to say that a Google-like storage approach cannot accomplish this.

In fact, security log auditing is just another online analytical processing (OLAP) application, albeit with potentially huge amounts of data. It's been at least ten years that the IT industry realized that OLAP applications require a different way to organize stored data compared to online transaction processing (OLTP) applications. OLTP applications still use traditional relational databases.

There has been much experimentation about ways to store data for OLAP applications. However, there is still a lot of value in the SQL language as a kind of open industry standard API to stored data.

So I would agree that traditional relational database products are not appropriate for log management data storage, but SQL as a language has merit as the "API layer" between the query and reporting tools and the data.

Canadian study reports breaches triple in 2009. Is this a valid statistic?

Earlier this week, Telus released the results of their 2009 joint Telus/Rotman School of Management at the University of Toronto study on Canadian IT Security Practices, which claimed that the number of breaches tripled to an average of 11.3. Here is the press release. But are these valid claims?

First, let's take a deeper look at the average of 11.3. By simply taking the raw answers of the 2009 question about the number of breaches during the last 12 months, the average, i.e. mean, is indeed 11.3. However, let's take a closer look at the actual responses:

Number of Breaches   Percentage of Organizations

0                                      14%

1                                        6%

2 to 5                                 33% 

6 to 10                                9%

11 to 25                              7%

26 to 50                              3%

51 to 100                            2%

More than 100                     2%

Don't know                          23%

Given the number of outliers, the average (mean) is not really a valid number. Those outliers significantly skew the average. The mode, between 2 and 5, is much more meaningful.

Also, there is no attempt to correlate the number of breaches an organization suffered with the organization's size. Of the 500 organizations participating, 31% had under 100 employees and 23% had over 10,000 employees. The point here is that the outliers may very well be a small group of very large organizations.

Now let's address the claim of "tripling." What could account for this huge increase?

1. It may just be a case of people being more honest this year, i.e. reporting more breaches. After all, this is just a survey.
2. It may be that organizations actually have better security controls in place and therefore detected more breaches.
3. It may be a function of the organizations participating. In 2008, there were only 297 versus 500 in 2009.
4. It could be the change in the way the question was worded in 2009 versus 2008. Here is the question from 2008 (In fact the only place in the study that uses real numbers rather than percentages):

Q40. A major IT security incident can be defined as one which causes a disruption to normal activities such that significant time, resources, and/or payments are required to resolve the situation. Based on this definition, how many major security incidents do you estimate your organization has experienced in the last 12 months?

1 to 5             63%

6 to 10             2%

More than 10    1%

Don't know       24%

The 2009 study question:

Q48. How many Security breaches do you estimate your organization has experienced in the past 12 months?

I provided the responses earlier in this post. The point is that in 2008, the question specifically asked about major incidents while in 2009 the question was about all breaches.

Also note, in both cases the organizations were asked for "estimates." Don't most of these organizations have Security Incident Response Teams? At least the 69% with over 100 full time employees? Wouldn't they know exactly how many "incidents" they investigated and how many were actual breaches? 

I suppose studies like these, based on surveys, have some value, but we really need information based on facts and analysis based on sound techniques.

Twenty Critical Cyber Security Controls - a blueprint for reducing IT security risk

The Center for Strategic & International Studies, a think tank founded in 1962 focused on strategic defense and security issues, published a consensus driven set of "Twenty Critical Controls for Effective Cyber Defense." While aimed at federal agencies, their recommendations are applicable to commercial enterprises as well. Fifteen of the twenty can be validated at least in part in an automated manner.

Also of note, the SANS' Top Cyber Security Risks report of September 2009 refers to this document as, "Best Practices in Mitigation and Control of The Top Risks."

Here are the twenty critical controls:

1. Inventory of authorized and unauthorized devices
2. Inventory of authorized and unauthorized software
3. Secure configurations of hardware and software on laptops, workstations, and servers
4. Secure configurations for network devices such as firewalls, routers, and switches
5. Boundary defense
6. Maintenance, monitoring, and analysis of Security Audit Logs
7. Application software security
8. Controlled use of administrative privileges
9. Controlled access based on need to know
10. Continuous vulnerability assessment and remediation
11. Account monitoring and control
12. Malware defenses
13. Limitation and control of network ports, protocols, and services
14. Wireless device control
15. Data loss prevention
16. Secure network engineering
17. Penetration tests and red team exercises
18. Incident response capability
19. Data recovery capability
20. Security skills assessment and appropriate training to fill gaps

I find this document compelling because of its breadth and brevity at only 49 pages. Furthermore, for each control it lays out "Quick Wins ... that can help an organization rapidly improve its security stance generally without major procedural, architectural, or technical changes to its environment," and three successively more comprehensive categories of subcontrols.

Apache.org site hacked - details published

The Apache.org team published the details of a recent incident where one of their web sites was breached. While the details are, of course, very technical, it provides a great learning experience for the rest of us. Dan Goodin of the Register summarized the incident.

Unfortunately, most organizations are very reluctant to even admit when they are hacked, let alone share the details of the experience. Hence the various federal and state laws forcing organizations to report incidents where people's personal and/or financial information may have been disclosed.

Given the fact that Apache produces open source software (the number one web server software), it is appropriate that they would be so open about a breach.

Court allows bank customer to sue bank for "negligent" security practices

Computerworld reported last week that a judge in Illinois ruled that a couple who lost $26,500 when their bank account was breached can sue the bank for negligence for not implementing "state-of-the-art" security measures which would have prevented the breach.

While bank credit card issuers have been suing credit card processors and retailers regularly to recoup losses due to breaches, this is the first time that I am aware of that a judge has ruled that a customer can sue the bank for negligence.

The more detailed blog post by attorney David Johnson, upon which the Computerworld article is based, discusses some really interesting details of this case.

The plaintiffs sued Citizens Financial Bank for negligence because it had not implemented multifactor authentication. The timeline is important here. The Federal Financial Institutions Examination Council (FFIEC) issued multifactor authentication guidelines in 2005. By 2007, when the plaintiffs' breach occurred, the bank had still not implemented multifactor authentication. The judge, Rebecca Pallmeyer of the District Court of Northern Illinois, found this two year delay unacceptable. 

Two interesting complications - (1) The account from which the money was stolen was from a home equity line of credit account, not a deposit or consumer asset account. (2) This credit account was linked to the plaintiffs' business checking account. I discussed the differences between consumer and business account liability here. Fortunately for the plaintiffs, the judge brushed these issues aside and focused on the lack of multifactor authentication.

One issue that was not addressed - where was Fiserv in all of this? They are the provider of the online banking software used by Citizens Financial Bank. Were they offering some type of multifactor authentication? I would assume yes, although I have not been able to confirm this.

In conclusion, attorney David Johnson makes clear that this ruling increases the risk to banks (and possibly other organizations responsible for protecting money and/or other assets of value) if they do not implement state-of-the-art security measures.