What Motivates C-Level Executive Investments in Security?

Boards of financial services corporations appear to exist in a bubble that isolates them from most of the types of information security and infrastructure & operations risk management issues that fill most of our days.  I admit, I am not even an intermittent member of that club, and that I have not figured out the relevant dimensions or characteristics of the Board bubble.  As a result, it just confounds me.  Information from my board is conveyed via direct questions that get passed my way, and via hints and statements in our standard SEC filings.  Sure, boards of all major financial services corporations have a broad suite of issues they must understand and influence.  It does not seem that many hold information security and infrastructure & operations risk management in their set of top priority considerations.  Given the regular drum beat of data loss in the news, this is not a healthy signal for our industry.  I have worked with executives in financial services for years.  Senior executives seem to consistently service their boards.

So, what motivates our C-level executive investments in security?  Generally, it seems like it is the existence of legal and regulatory mandates.  Information Week reported that in a recent Information Week Analytics survey of 326 IT professionals, their

“data points strongly to a single source: regulations.  Industry and government compliance mandates are cited as the top influence on information security programs.”

If compliance — with the law, governmental or industry regulations, or even customer and partner contracts — is the only goal, we are sunk.  Depending on which of the major financial services corporations you work for, we are tasked with protecting anywhere from hundreds of billions to trillions of dollars worth of other people’s money, while attempting to:

• interconnect almost everything,
• connect all that to the Internet,
• make all types of interactions easier for the end users.

In business, technology infrastructure & operations, and software environments as dynamic and complex as are found in all large financial services corporations, it seems relatively easy to understand that we begin every day at seriously-elevated risk.  Law and rule-making processes in United States are messy — generally rich in compromise, sometimes transparently corrupt, and often strongly influenced by the industries being targeted with controls.  As a result, compliance is usually not a high bar.  It may not, and in my experience, is usually not a close relative to risk-appropriate information security.

We need to do a better job communicating with senior leaders.  Our infrastructures incorporate and expose real vulnerabilities.  There are real and relevant threats.  And we owe more to our customers, partners, employees, and shareholders than the cheapest and easiest route to technical compliance.  Checking some boxes, printing reports, and passing a contract compliance assessor’s review must not be the only corporate security goal.

We are living through a global financial decline of still-unknown proportions.  It was caused in part by too many people, especially, but not exclusively, at the top of our financial services corporations, choosing to set grossly-inappropriate goals.  We all know that the scope and breadth of criminal, and national-centric, activity focused on critical Internet-connected infrastructure is expanding every week.  I believe that treating information security and technology infrastructure & operations risk management as a compliance exercise will lead to a similarly dark downturn — and I believe will result in the end of some more of our financial services peers.

What do you think?

– References –

DatalossDB: http://datalossdb.org/statistics

Information Week Analytics Survey Summary: http://www.informationweek.com/news/security/management/showArticle.jhtml?articleID=213901162

Full report “A Unified Front: Exploring What Executives Really Think Of Security.” https://i.cmpnet.com/custom/cxoreport/assets/InformationWeek-Analytics-Dark-Reading-CEOs-And-Security.pdf .  You might want to link from the article above and fill out the form so that they earn enough money to keep doing these surveys.

2009 Data Breach Investigations Report–by Verizon Business Incident Response

“2009 Data Breach Investigations Report” was released this week.  It is a 52-page study conducted by the Verizon Business Incident Response team describing its work.

Keep in mind, this report is a description of Verizon Business Incident Response engagements.  As they did in their 2008 report, the Verizon team emphasizes external attack and services that they sell.  It is an unusual report.  Verizon does, I believe, a great job describing what their Incident Response practice found last year.  I have no reason to doubt any of their data.  It presents a picture of great diversity over their 2008 engagements.  But the top five breaches included in this report account for 93 percent of total records compromised. (page 34)   This made the many of the statistics throughout the rest of the report almost irrationally skewed…

Maybe it would be best to read this paper as an “Annual Report” of the Verizon business unit performing Incident Response services.  I believe that would be a difficult stretch to try to turn it into something that has broadly-applicable meaning for the financial services industry, or for the full spectrum of technology-rich Internet-dependent businesses across the globe.

In that context, though, there is still some interesting reading.  The report is based on their experience in 150 forensic engagements in 2008.   90 of those were confirmed data breach investigations — so the report data is from those 90 engagements.
These 90 cases resulted in more than 285 million data records breached — exceeding the combined total from all Verizon Business Incident Response engagements from 2004 to 2007.

For their customer base, they reported that “breaches still go undiscovered and uncontained for weeks or months in 75 percent of cases.” (page 38)  I work for a geographically-dispersed, diversified financial services corporation, and this finding generates a little catch in my breathing…

Verizon reported that nearly half of their caseload was described as being comprised of different sets of interrelated incidents, and that “quite often” that meant the same individual(s) committed the multiple attacks.

This is a sometimes-dense, 50-some page report, so you would need to fetch a copy and read it to get a sense of the scope of information that Verizon presents.  That said,  here are some statistics from the report that I found interesting:

Breach Distribution by business sector:

31% Retail

30% Financial Services

14% Food and Beverage

6% Manufacturing

6% Business Services

6% Hospitality

3% Technology

4% Other

Industries represented by percent of records breached:

93% Financial Services

7% Everyone Else

Targeted attacks accounted for 90% of all compromised records. (page 31)

Compromised database and application servers accounted for 42% of breaches and 94% of breached records. (page 33)

Median number of records compromised per breach:

External 37,847

Internal 100,000

Partner 27,000

Compromised data types by percent of breaches / records:

Payment Card Data 81% / 98%

Personal Information 36% / 1.5%

Authentication Credentials 31% / <0.1%

Account Numbers 16 / 0.5%

Intellectual Property 13%

Monetary Assets / Funds 11%

Corporate Financial Data 6%

Other 11%

Threat categories by percent of breaches / records:

Malware

% of breach cases: 38%

% of records: 90%

Hacking

% of breach cases: 64%

% of records: 94%

Misuse

% of breach cases: 22%

% of records: 2%

Deceit

% of breach cases: 12%

% of records: 6%

Physical

% of breach cases: 9%

% of records: 2%

Error

% of breach cases: 1%

% of records: 0%

Types of hacking by number of breaches / percent of records:

Unauthorized Access via Default or Shared Credentials 17 / 53 %

SQL Injection 16 / 79%

Improperly Constrained or Misconfigured ACLs 9 / 66%

Unauthorized Access via Stolen Credentials 7 / 0.1%

Authentication Bypass 5 / 0.1%

Brute-Force 4 / 7%

Privilege Escalation 4 / 0%

Exploitation of Session Variables 3 / 0%

Buffer Overflow 3 / 0%

Cross-Site Scripting 1 / 0%

Attack pathways by number of breaches / percent of records:

Remote Access & Mgt. 22 / 27%

Web Application 21 / 79%

Other Server or Application 7 / 7%

Network Devices 6 / 11%

End -User Systems 1 / 26%

Malware functionality by number of breaches:

Key logger or Spyware 17
Backdoor or Command Shell 16
Capture and Store Data 13
Attacks Other Systems 2
Disables Security Controls 2
Other 2

What is that “1% cross-site scripting” is telling us?  Does it really represent reality for our Internet-facing applications?  I really have doubts…  It must say more about the types of technology and services Verizon sells.

What do you think?

– References –

“2009 Data Breach Investigations Report — A study conducted by the Verizon Business RISK team:” http://www.verizonbusiness.com/resources/security/reports/2009_databreach_rp.pdf

String-Matching in a Web Application Firewall [WAF]

In a review of a loaner web application firewall, a colleague noticed that it seemed to be regex-centric.  I asked if it was possible for him to extract a list of the regexs used by the applicance and then send me a copy of the set.  I really didn’t have much hope for getting the list, but there it was in my email that evening.

My colleague had set of a test environment having an application server, the WAF (web application firewall), a traditional firewall, and his client PC.  All traffic travelling between the client PC and the application server had to traverse the firewall and the WAF.  He reported that the WAF did a good job identifying and denying his cross site scripting (XSS) and SQL injection attacks on the web application, and did not exhibit excessive false positives during his testing.  It appeared to be equally capable regardless of attempts to attack form fields, hidden fields, or any type of POST or GET values.  Based on that finding alone, this appliance might be worth its cost for specific, known-vulnerable, high-risk situations where it is impossible to remediate the application weaknesses or those repairs will take an extended period of time.  Vulnerable vendor applications come to mind…

So, based on a quick review of the information in the email from my associate, the WAF organizes its regex patterns into the following categories:command injection, credit card numbers, cross site scriptin (XSS), directory traversal, protected files, protected directories, forbidden UNC references, LDAP injection, restricted characters, quotes, carriage return line feed, carriage return, tab,  SQL injection, and SSI injection.  Given the layout of this data, it was difficult for me to immediately determine whether there was a bias or focus on one area over another, so I spent some time reviewing the regexes more carefully.  They fall into the following distribution:

124 command injection,
92 SQL injection,
71 cross site scripting (XSS),
29 restricted characters,
14 SSI injection,
12 credit card numbers,
8 LDAP injection,
4 protected files,
4 protected directories,
2 directory traversal,
2 quotes,
2 carriage return line feed,
1 forbidden UNC references,
1 carriage return,
1 tab.

They appear to be written in a way that requires many of them to be used in combination with each other in order to fire positive alarms without too many false positives.  The appliance does not reveal how it assembles these combinations, or what rules it uses when it identifies certain patterns of rule-firing.

Also, there are some vulnerability categories that were not represented in the regex category listing.  When I think of the common web application vulnerability lists (for example OWASP) along with my own environment, I wonder about the absence of XPath injection, cookie poisoning, some common types of URI parameter tampering, and inappropriate error messages.  There are more as well…

There are certain types of vulnerable applications for which it might be a poor match.  If the application vulnerabilities are clustered around inappropriate use of URI values for identification or access control, then it appeared that this applicance would be especially difficult to configure so that it might resist misuse of those URI-related vulnerabilities.

Based only on reading and some brief experimenting, it appears that WAFs may fit some difficult risk management issues that we already have or expect to see in the near future.  I am very interested in any experience that you might have employing web application firewalls in your infrastructure.