Questions About “Proxy” Authentications

June 5, 2009

Summary:

“When is it appropriate to use an ‘application ID’ to authenticate with the back end application or database engine?”  This is a question that I periodically receive from application designers and developers.  Working in financial services, the answer continues to seem obvious to me…

Make use of the authenticated user’s identity end-to-end — using alternatives only where there are material financial disincentives and where those alternatives comply with all applicable laws, regulations, and contracts.

Supporting Discussion:

When the other variables remain the same, increasing complexity of an application, system, or process tends to introduce more defects.  And a certain portion of those defects will result in risk-enhancing vulnerabilities.  As a result, simplicity still ranks high on my list of architectural “ilities.”

In the financial services industry, “compliance” on many fronts requires that individuals are held accountable for their behaviors.  In general, application infrastructure is responsible for generating the trail of individual’s activities.  Applications must do so in a manner that delivers that trail at a fairly high level of integrity.  This is sometimes called an “audit trail,” but I believe it is often more accurately a “compliance trail.”

Surely, there are other related tasks such as real-time or periodic monitoring for indicators or evidence of unauthorized activity or outright attack, and generating alerts as is risk-appropriate.  Sometimes the “compliance” and “monitoring” activities can be served via one code-base.  But in other instances, the tasks are so different that it would be unbusinesslike to attempt their combination.

The implementation details will vary depending on the nature of the business process, the type of business activity, along with the applicable laws, regulations, policies, standards, and customer expectations.  The rigor used to secure a system that dispenses public documentation — maintaining authentication and access information only for demographic and marketing purposes — will generally be radically different from one that enables large-scale wire-transfers — where movement of sums greater than $100M US. would be routine.

So, I add this up and what results is my “rule of thumb” for authenticating with back end or database systems:

“Make use of the authenticated user’s identity end-to-end — using alternatives only where there are material financial disincentives and where those alternatives comply with all applicable laws, regulations, and contracts.”

It is often more difficult to maintain the integrity of the activity trail when alternative IDs are employed.  And that translates into increased complexity, defects, and vulnerabilities.  In the long run, I believe that this too-often results in unplanned and unproductive expenses.

Sure, there are situations where this rule may not apply.  Consider application interactions that are part of a periodic “batch.”  There is no “authenticated user.”  This situation will appear in a number of “automation” systems and “workflow.”  Sometimes this requires using an “application ID,” or a credential used by one application to authenticate to another, or to a database engine.  Permissions can be checked for that identity and access to resources as permitted.  This is often, although not always, a relatively straight-forward effort.

There are also situations where an application requires elevated rights at a certain stage of execution.  Again, it may be useful to employ an “application ID” here as well.  But use caution, ineffective application architecture or design may be the root cause here.  There may be situations where another application design may not require the elevated rights.

When application architects or designer want to employ an alternative identity, have a discussion about the details of their problem-set.  It might be more appropriate to re-design the application.


A Signal That You Are No Longer Targeting Effective Risk Management

May 27, 2009

Over the years, I have been witness to many instances of “responsible”/”accountable” word feuds.  In truth, I have been maneuvered into the early stages of these tangents on more than one occasion.  I believe that their presence is almost always an signal that effective risk management is no longer the mission.

Whenever compliance discussions evolve into arguments about the meaning of “responsible” versus “accountable,” stop and think about the trajectory of your effort.  Chances are that you are no longer involved in “risk management.”  The key is generally to ensure that there remains a strong link to compliance monitoring, reporting, and enforcement.  Where there is no link, there is no information security, infrastructure, or infrastructure operations risk management activity.  If you are a lawyer, and your focus is to use the “responsible”/”accountable” vocabulary to achieve some gain or to dodge some liability for your corporation, you have my support, but it is not related to the security business.

Tight-enough coupling between the descriptions of what must or should be achieved, and the monitoring, reporting, and enforcement used to ensure an appropriate level of compliance is a key indicator of an effective risk management focus.

Absent that coupling, attempt to re-focus the effort participant’s energy away from “responsible”/”accountable” word-smithing, and back toward the job at hand.


Mass Misunderstanding in Global Business — Can It Happen on The Information Security Front

May 17, 2009

Leaders in many industries seem to employ hope, and a belief in “what others are doing” as a primary risk management technique.  I recently read a piece about the biofuels industry and watched a documentary on Bernie Madoff’s Ponzie scheme that seem to demonstrate weaknesses in the way we manage key risks in globalized industries today.  In financial services, we use software to integrated much of our operations in hostile environments.  I believe that it would be useful for our most senior leaders to invest some of their best resources in an intense re-evaluation of their risk management strategies across all dimensions of their business.

Philip Brasher wrote a brief blog entry earlier this week about how over the last few years, biofuel entrepreneurs, producers, investors, farmers, and politicians all failed to deal with some relatively well-established market risks.  In the U.S. Midwest, biofuels generally means ethanol and biodiesel.  During the recent ethanol boom years, boosters seemed to reason that “what product could fail when it had no competitors and government was prepared to make its consumption mandatory?  Many in the industry assume their government mandates and subsidies are a virtual guarantee of success.  Both ethanol and biodiesel are now in a deep slump.  The price of, and demand for these biofuels is relatively-tightly coupled to traditional energy markets (primarily oil) and to agricultural commodity prices.  As a result, the biofuels industry operates in an international market.  The dynamics of oil and agricultural markets are extensively documented, analyzed, and reported on — and mandates and subsidies are not distributed evenly across the globe.

Creating the infrastructure to produce ethanol and biodiesel on a commercial scale is a complex engineering and capital-intensive exercise.  Whole hordes of intelligent people worked out every facet of this new industry.  Most of this effort took place in public, and with relatively extensive academic support from major universities.  How could they have gotten it so wrong?  And are they preparing to do so again?  Mr.Brasher references work by Ross McCracken, that seems to suggest they might by expecting both rising oil prices and falling production costs, while at the same time neglecting to deal with their own product pricing and raw materials costs.

So what does all that have to do with information security in the financial services industry?

Software is increasingly and enabler for “everything” in our business.  Every facet of our businesses depend upon layer after layer of software, most of which is expressed in interface after interface.  Our business leaders have been wringing “savings” out of our infrastructure for years.  Many seem to think that this savings-train is both endless and under their command.  Unfortunately, there are other forces that can influence the costs and risks associated with operating a large, complex, often globally-distributed infrastructures.

Much of our infrastructure is now connected to the Internet, as well as to our partner and customer infrastructures.  Our business “plumbing” and our brands require this connectivity in the financial services industry.  All of it is exposed to more or less hostile influences.  Many of our leaders depend upon contracts, laws, regulations, and regulators to work out how we will deal with the risks.  Some add informal reviews of “what others do,” or search for “industry best practices.”  Some include insurance in the mix as well.  My translation of this behavior is that it means they hope that “their” corporation will not experience a related loss on their watch.  And hope is not a viable risk management plan.

When you need to protect $ millions or $ billions of other people’s money, writing and deploying risk-appropriate software, even a relatively simple application, is fiendishly difficult.  This task is made more challenging because nature, scope, and intensity of the threats in the deployment environment are evolving.  Many applications never receive even an informal security code review or a vulnerability assessment.  At the same time, the “tools” available to criminals, insiders or outsiders, continue to mature and pose serious threats to our information, operations, and assets.  Most of these tools attack, in one way or another, our applications.  From one perspective, this is a very dynamic battle-space (war-fighting vocabulary intentional).  That is not the perspective of most of our executive corp.

Any population in financial services depending on hope, and a first-person experience of avoiding disaster, ought to review the recent FrontLine documentary on “The Madoff Affair.”  In the presence of a relatively vast regulatory apparatus, thousands of top tier investors, investment advisors & analysts, brokers, hedge fund gurus “lost” as much as $65 billion U.S. in a Ponzi scheme.  That was also in spite of a small cadre of investment specialists and a few reporters who repeatedly pointed out that Madoff’s returns were not supported by market or mathematical facts.  The primary regulator performed several review of Madoff’s investment operations and reported that there were no problems.  From our perspective today — Dec. 11, 2008, Bernard L. Madoff confessed that his investment buisness was all a lie — this seems like some mass madness.  Professional and wealthy elietes do not make mistakes of this magnatude — but now many of them lost much, or in some cases, all for their fortunes.  So much for hope and regulation…

It is risk-inappropriate to wait for a catastrophic attack on our financial services infrastructure before investing in intellectually-viable information, infrastructure, and infrastructure operations risk management practices.  I believe that it is time for our most senior leaders to invest some of their best resources in an intense re-evaluation of their risk management strategies across all dimensions of their business.

– References –

“Biofuels at risk.” Philip Brasher, May 11, 2009, http://blogs.desmoinesregister.com/dmr/index.php/2009/05/11/biofuels-at-risk/

There was also a follow-on article in the Sunday Des Moines Register (print edition), “Lawmakers try to ease regulation on biofuel’s environmental effect.” May 17, 2009, page 4D.”The Madoff Affair.” FrontLine, PBS, http://www.pbs.org/wgbh/pages/frontline/madoff/


What Motivates C-Level Executive Investments in Security?

April 22, 2009

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

April 17, 2009

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]

April 2, 2009

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.


What is Information Security and How Does it Help?

March 28, 2009

A peer recently pointed me to a discussion about information security as a “business enabler.” Daniel Miessler argued that:

‘Security isn’t an “enabler”; that line can hurt us. Security is about NOT doing things wrong, as part of overall quality.’

and later in his essay that

“In a CEO’s big picture, there’s no difference between a web application firewall and a fire alarm and sprinkler system. Ultimately they both reduce to one thing: an operating expense.”

There followed a number of thoughtful comments, and dialog.

The same day, Jeremiah Grossman [WhiteHat Security] wrote an essay about selling application security. He offered that application security should enable:

“solutions to be implemented in the time and place that maximizes return, demonstrates success, and by extension justifies the investment to the business in the language they understand.”

He linked to a number of other’s writing about the topic and argued that one of the critical goals must be to help CIOs and CSOs “understand the relevant issues.” He appears to have worked with the Web Application Security Consortium (WASC) and The SANS Institute to initiate a joint open community project to build out a “risk-based enterprise website security strategy.” Mr. Grossman’s essay was followed by more thoughtful commenting and discussion.

After reading a number of the links and thinking about these two threads, I think that both have value. Any rant about sales “lines” that get repeated without a thought is a good thing in-and-of-itself. I think that both writers express frustration at the difficulty of motivating senior corporate leaders to part with their money for “security-related” investments. That is understandable. “Investment” funding is difficult for everyone today. I am working in financial services — where trillions of dollars of assets that we depended upon have simply disappeared. Money is very tight here. I understand why product and services vendors have been increasingly manic, frantic, and sometimes even bullying in the messages they email and leave on my phone.

So, what do I have to offer?

As a bumper sticker, “security as a business enabler” is just more vacuous blather. But if it is used as part of a more serious attempt to get at the problems of taking business-appropriate risks, or performing risk-appropriate business, then work like that proposed for “risk-based enterprise website security strategy” might be useful. I believe that the most effective information and technology operations risk management decision-making today happens because of the joint efforts of serious information security professionals and leaders (formal and informal) across the various organizations that make up modern corporations in most fields today. Depending on the given corporate culture, this is less or more process-driven.

  • Sometimes it is strictly a matter of personal relationships (a risk-elevating situation).
  • In other situations, project processes link these communities for long enough to work out understandings and plans that can facilitate effectively dealing with risks.
  • Some organizations have broad and deep formalization of their organizational relationships, and the processes and information flows to maintain a shared understanding of threats, risks, controls & mitigations, current state, etc.

I believe that the first two situations above dominate, and that the third is an exception. As a result, what ever we do to support creation of a “risk-based enterprise website security strategy” or to find a new broad description of what information security is valuable, it needs to be useful in those organizations that depend heavily on cross-domain relationships between serious professionals to prioritize risk management investments. This is not meant to imply that information and application security specialists are not valuable. They are critical to the success of most organizations. I am responding to the focus on “selling.” Successful sales will require connecting with and delivering an effective message to those who can pay, or can materially influence those who can pay. My experience has been that this is an increasingly-small population.

For a number of years, I was intermittently called upon to assist a large corporate merger & acquisition team. We would review the target infrastructure, its operations, and the staff in the context of that target requiring quick and efficient on-boarding. There appeared to be a pattern, where the “best” IT, information security, and risk management teams were most tightly integrated into the broader corporate business operations. They viewed themselves as an integral member of the team — the only team, the one that served customers, partners, and investors. Sure, that is difficult in large, diversified corporations. It just didn’t stop some individuals, orother groups of IT and security professionals. A couple years ago, Gunnar Peterson wrote that

“The role of the security architecture is not to steer the business away from risk, but rather to educate their business partners about the risks they are taking and provide countermeasures that enable the business to take as much risk as suits their goals.”

This seems like a good description of a small slice of what I saw at those few M&A targets where there was a minimum of cultural separation between executive management, marketing, sales, product development, logistics, support, security, and the IT organization’s technical specialists who kept the “plumbing” humming so that it all worked. All this is not to imply that everybody needed to know everything. Decision-makers of all kinds understood that they needed a threshold understanding of short and long term goals along many of the specialty-dimensions that were required to operate in their field.

None of that excluded the kind of data-rich analytical work proposed recently by Ron Charette. His notion of collecting specific buckets of “strongly-typed” information about application security to support analysis and reporting — essential for making informed decisions, makes a lot of sense.

It seems, though, that in many corporate environments, it requires data, along with individuals having a critical mass of professional risk management experience and what I will abbreviate as “adult business behaviors,” to effectively join teams of leaders (at all levels) to deal with risk in a manner that expresses a time-product-and-location-bound risk tolerances. That professional and “adult” combination is still a barrier for too many, and no new strategy will break through that barrier.

There is little, and shrinking room for techno-centric (“geek”) information security pros in the business communities where serious information or technology infrastructure operations risk decision-making takes place. Similarly, there appears to be dwindling room for experience-light or even experience-free “professional leaders.” Some career security team members engage all their work-life energy in the details, technologies, and operations of what is a modern information security organization, and then attempt to apply what they know to the various projects that come their way. They serve a valuable purpose, but they require constant management attention. They will tend to be of little assistance when we need to help translate pools of valuable data into a material resource for business decision-making, and even less when we have only a fine mist of information available.

A serious, expert, security professional is not only the holder of a credential. They need to have worked through at least a decade (see: “The Making of an Expert.” HBR 1 Jul 2007) of intense practice and dedicated coaching, constantly pushing themselves beyond their comfort zones to understand enough of the history, theory, craft, and rigorous intellectual practices that support risk management in a modern diversified corporate environment. A key component of that professionalization is learning how to share with and learn from leaders (formal and informal) throughout a business. In a highly dynamic business environment, they need to be able to synthesize new knowledge from their learning and experiences. Some are able to “simply” join that broader business environment. Others need to help construct more formalized processes, even new organizations to facilitate the level of cross-domain interaction required to effectively align risk decision-making and implementations with the other business dimensions essential for success in the marketplace. In either situation, this is what I meant by “adult business behaviors” above. Get a new model for “selling” information security as an enabler, or a new enterprise website security strategy into their hands, and I believe that you will begin to get traction.

– References –
The Problem With Selling Information Security as a “Business Enabler” By Daniel Miessler on March 26th, 2009: http://dmiessler.com/blog/the-problem-with-selling-information-security-as-a-business-enabler

“Website security needs a strategy.” By Jeremiah Grossman, Thursday, March 26, 2009: http://jeremiahgrossman.blogspot.com/2009/03/website-security-needs-strategy.html

“Security Architecture Blueprint.” By Gunnar Peterson: http://arctecgroup.net/pdf/ArctecSecurityArchitectureBlueprint.pdf and http://1raindrop.typepad.com/1_raindrop/2007/05/security_archit.html

“Proposal of Web Application Security Metric Framework to Compliance/Configuration Management Vendors.” By Ron Charette: http://roncharette.blogspot.com/2009/03/proposal-of-web-application-security_26.html

“The Making of an Expert.” HBR 1 Jul 2007, By K. Anders Ericsson, Michael J. Prietula, and Edward T. Cokely (requires login or purchase to access most of the article): http://hbr.harvardbusiness.org/2007/07/the-making-of-an-expert/ar/1


Partial Knowledge is Extraordinarily Dangerous

March 22, 2009

“Partial knowledge is extraordinarily dangerous.”

I am sometimes asked about how to evaluate the information security and risk management needs of a given organization.  Other times a similar issue comes up, where a leader wants to understand what it would take to have some of their people become “security” experts.  In either situation, I am somewhat uncomfortable with my capabilities in the area of learning, and of the types of measurements that might help identify who is prepared to deal with material information security and risk management issues in diversified corporate environments, and why.  I currently have no formulaic response, no elevator speech.  I could use your input on this topic.

I was reading earlier this weekend.  CSPAN was on in the background.  And at some point, I heard Justice David Souter (U.S.Supreme Court) respond to a question about the scope about the value of Humanities education in a way that may help a little with the puzzle I posed above.

Justice Souter said that, “If I were attempting to develop a strategy (in support of Humanities), it would be based on the assumption that ‘A little learning is a dangerous thing… and an analog to that is that partial learning is a dangerous thing.’”  He went on:

“We have a number of examples of partial learning thrust on us over the last few years.  We know a lot more about military defense than we do about the divisions among the Muslim world.  We have a State Department that I have read, frequently, does not have very many Arabic speakers in it.  And one could go on with examples in the arena of what could be publicly-serviceable knowledge, and I think that if I have to have a starting point, I think that it would be that ‘Partial knowledge is extraordinarily dangerous.’” [this was around 1:16 into the program]

Later [around 1:36 into the program] Carolyn Brown, Director – Office of Scholarly Programs, Library of Congress, asked a question about defining with greater precision what the panelists mean by “Habits of mind?” and what should we do with it?

In response, Justice Souter summarized part of a speech by

“Howard Mumford Jones, where, after suggesting that ‘all Harvard graduates are illiterate, and committed to remaining illiterate,’ and he was sort of gently berating his audience by analyzing a day down to where there were, I don’t know… only 18 minutes left free, and then he asked: what should you do with it? — there was a pause — and answered (with passion) ‘You could read a book!’”

Souter went on to say that at some point one will “find a book so familiar that when there is a moment, one will open it.”  “Opening enough of those books,” he said “results in a lesson best described by Judge Learnard Hand, ‘who once said that if he could have his way, he would have engraved over every library, school, statehouse, and courthouse all over the the United States, a quote by Oliver Cromwell: ‘Consider that yea may be wrong…””  He concluded his thought with, “The habit of mind which characterizes the liberal arts, the habit of mind that opens the book, is also the habit which teaches us that lesson of Oliver Cromwell.  One is a physical habit, and the other is a habit of judgment that is likely to follow from it.”

Soon after, Patricia Q. Stonesifer, Chairwoman, Smithsonian Institution, cautioned of “The enormous danger of anyone living in a state of certainty…”  And she asked us to “Develop a state of uncertainty and combine it with a habit of real learning…”  Then she concluded with “One of habits of the mind is staying open to uncertainty.”

I think that there is some wisdom in these quotes for anyone attempting to assess their information risk management needs in a large corporate organization, or for anyone attempting to design an information security curriculum for individuals and groups who, until recently (or possibly until some point in the future) had never really thought about the topic.  Information security and risk management in a large, diversified, infrastructure-heavy corporate environment requires some of the breadth and specialization found in the university-level Humanities.  The differences between information security staff who can do what they are told, and those who can lead, involve a range of dimensions, but they are all dependent upon judgment.  I believe that there is a relatively healthy connection between the “habits of the mind” that Justice Souter and the other panelists discussed, and the type of judgment required for leaders in the information security field today.

What do you think?

– References –

American Academy of Arts and Sciences Symposium – Washington, DC
“The Humanities in a Civil Society.”
Recorded on Monday, March 9, 2009, at George Washington University.
Moderator: Leslie Berlowitz, Chief Executive Officer, American Academy
Speakers:

  • Edward L. Ayers, President, University of Richmond
  • Don Michael Randel, President, The Mellon Foundation
  • David Souter, Associate Justice, United States Supreme Court
  • Patricia Q. Stonesifer, Chairwoman, Smithsonian Institution

http://www.amacad.org/events/recent.aspx

Watch C-SPAN’s coverage of this Symposium: http://www.c-span.org/Watch/watch.aspx?MediaId=HP-A-16159

Justice David Souter: http://en.wikipedia.org/wiki/David_Souter and his official bio at http://www.supremecourtus.gov/about/biographiescurrent.pdf

Carolyn Brown: http://www.loc.gov/loc/lcib/0605/staff.html

Howard Mumford Jones: http://en.wikipedia.org/wiki/Howard_Mumford_Jones

Learned Hand: http://en.wikipedia.org/wiki/Learned_Hand

Oliver Cromwell: http://en.wikipedia.org/wiki/Oliver_Cromwell or for more in-depth material see http://www.olivercromwell.org/


Analysis of a Credit Card Theft Scam

March 20, 2009

It is easy to build mental models of cyber-criminals.  My experience is that it seems to help many individuals to find some sort of work-life balance, and to offer comfort that “high-tech” criminals are a world-apart from the rest of us.  They are alien, and easily identifiable in the first person (of course, most will never have knowing, real-time, first-person interaction with an active cyber-criminal or credit card fraudster).   Building these images and living in comfort, though, does not mean that those images are even remotely factual or relevant in any way to what is going on in the information security and fraud fields today.  Assuming that the world matches what we wish it to be is a relatively common cognitive trap — one that has no place in information security and risk management professions.

In that vein, Jacob Apelbaum offers a valuable and interesting overview and analysis of a credit card theft scam operation.

He received a couple credit card scam calls lasting only a relatively short time, but he listened carefully, collected data, and shares with us an illuminating tale.

As the result of this experience, he wrote,

“My mental image of the on-line fraudster has changed irrevocably.  Whereas before I viewed fraud as an opportunistic low tech effort executed by crafty individuals, I now view it as an commercial operation, in many ways similar to a legitimate telemarketing niche industry.  It employs a well trained workforce, cutting edge BI and telecom technology and a large database of would be “customers”.”

He concluded that:

“At its core, fraud is propagated via subtle means and recognizing it requires the aggregation of many nuances which individually may appear inconsequential.”

Mr. Apelbaum outlines some of the more interesting elements of his experience:

  1. Psychological Usage of Ambient Sound–likely a recording simulating a response hot-line designed to create the illusion of a busy call center…
  2. Call Traceability and Legitimacy–When asked, the “call center representative” said that her call center was located in a state corresponded to the area code appearing on his caller ID.  When tested, the number rang and then rolled to a voice mail system saying that “due to the high call valume I have reached a mail box and should leave a message”…
  3. Well Scripted Dialogs–During the conversation, the “call center representative” responded in a consistent manner to his questions, emphasizing the positive, and assuring him that any risks were covered…
  4. Plausibility–Whenever the conversation drifted away from “call center representative’s” primary objective (i.e. getting his credit card and other personal information), they eloquently and skillfully navigated him back to the same spot…
  5. Professional Composure and Manners–The “call center representative” remained polite and composed, always maintaining a businesslike demeanor and projecting a image of a legitimacy.
  6. Effective Use of Higher Authority–Brought in the “supervisor” when requested.

My bullets above are only abbreviations of his descriptions, which I highly recommend to everyone involved in information security and financial services risk management.

– References –

“An Afternoon with a Fraudster.” http://apelbaum.wordpress.com/2009/03/20/an-afternoon-with-a-fraudster/

Jacob Apelbaum: http://www.linkedin.com/in/japelbaum


Measuring Security Program Value

March 12, 2009

I recently read an essay by Matthew Rosenquist titled: “Top Techniques for Measuring Security Value.”  The content was from a class he taught periodically.  In this section, he was attempting to teach “how to think critically while calculating information security value.”  He presents a list of “methods to show value.”  He makes it clear that they are presented as “archetypes” of measuring techniques along with his quick summary of strengths, weaknesses, and applicability for each.

I recommend the list to security professionals.  It leaves me uncomfortable, and wondering “what next.”  Each of the archetypes are proposed periodically by individuals I work with, by writers in trade publications, by industry experts, by consultants, by pre-sales engineers working for the great, global “security” firms.  Too often they are, to me, the noise attempting to fill the space that is senior management desire for a simple story.  None are easy.  All have serious implementation issues.  And when I read quickly through the eight metrics, they ring hollow.

It is not entirely clear to me, but it seems like they do for Matthew Rosenquist as well.  He sums up his essay with, “Let common sense prevail.  If the value must be understood to compare to other options, articulate security posture, or justify spending, then do an assessment.  Otherwise, ask yourself if it is really needed.”  He offers that it is OK “to not measure the value of a security program.”

I hope that Mr. Rosenquist has the opportunity to build out his argument and rationale.  The mass of effort devoted to outlining the archetypes, and the quick proposal that they can be ignored is supremely unsatisfying.  This is rich territory.  There are such vast economic forces behind the application of one or more of his archetypes, and historical momentum [at least in my experience] tends to exaggerate their mass — it is difficult to imagine that senior leaders will come around to the “Let common sense prevail” approach.

There is some risk, though, that one individual’s common sense is an absurdity to another.  Professionalism, experience, and a drive to become an expert in risk management matter.  The opinions of a novice, or an “outsider” may have their place in corporate information, infrastructure, and technology operations risk management, but they bring with them a risk rich challenge.  I’ll save a discussion on that topic for another day.

Read Mr. Rosenquist’s essay and let me know what you think.

– References –

Matthew Rosenquist: http://communities.intel.com/people/MatthewRosenquist

“Top Techniques for Measuring Security Value.” http://communities.intel.com/openport/community/openportit/it/blog/2009/03/02/top-techniques-for-measuring-security-value