Security and Risk Management Strategies Blog

An Introduction to Data aliasing, AKA “tokenization” and “pseudonymization”

Blogger: Ramon Krikken

I recently finished a set of documents on what we now call data aliasing. If nothing else, the issue of terminology proved to be a challenge, with different industries having their own terms to describe this process of reversibly transforming confidential data into an alias that maintains, or is similar to, the original data format. In health informatics this transform is called pseudonymization, which allows private health information (PHI) to be de-identified for certain uses. In the world of payment systems it is called tokenization, and applies – perhaps obviously – to reduce the amount of sensitive card information subject to PCI-DSS regulation. To use a generalized term, data aliasing (as subset of data masking) it is.

 

At the surface the concept is simple, but the devil – as usual – is in the details. There are different aliasing algorithms (randomization versus encryption), aliasing service architectures (interfacing, and location of databases), and application architectures (where is the aliasing performed). The choice of what to use, in today’s environment where product choices are limited, is not trivial. Luckily, as products mature we should see more flexible solutions that are conducive to supporting many of these options, and proper architectural planning can go a long way.

 

However, the enterprise should not jump on the product bandwagon without considering the big picture. The business and IT should work together to decide on whether to suppress, redact, anonymize, or alias information in order to protect it (and consider not only the security pros and cons, but also those related to usability, availability, etc.) As I discussed in “Will 2010 be "the year of the data?" an information-centric security strategy is vital … perhaps we can use the current buzz around data aliasing, mostly in the form of data tokenization for PCI-DSS, as a way to focus on information as being the core asset.

 

This is only the beginning of an ongoing thread on data management and data security. Joe Bugajski from out Data Management Strategies team and I will lead off the information-centric security track of our Catalyst Europe conference, discussing how trends in data management and security interact and drive the needs and solutions in the enterprise. And at the RSA 2010 conference I will be on a panel to discuss tokenization in the payment industry. Hope to see you at these conferences, and stay tuned for more.

Static Analysis: How Important is Accuracy?

Software security - or application security, if you prefer - is (to no surprise, I'm sure) a significant ongoing research topic for us. Most recently I completed two documents on static software security analysis, which should publish in the coming 90 days. Talking to users and vendors many important aspects of the static analysis practice came to light, and it is clear that it provides a tremendous value in reducing software security flaws. Most important, of course, is that tools find those "holes you can drive a truck through." I.e. the ones that would be particularly embarrassing to make it into production. And although one would expect these to be easy to find, they may not always be.

There have been various studies of static analysis accuracy, both in the academic and commercial world. Not all are public, and with some of the public ones the detailed results are unfortunately not publicly available. We also spoke with customers about their product evaluations, and even have one customer who performed an incredibly detailed test of several types of security testing tools and services. The results show non-trivial variability in accuracy, inconsistency in the relative performance between products, and potential impact of code structure factors (such as complexity). One study pegs best-case tool performance around 60% for critical flaws. And while this by no means diminish the usefulness of static analysis, it may certainly complicate a customer's evaluation process. Many only perform a comparative analysis of tools run on enterprise code, and thus do not have a baseline to compare against - a method which may or may not actually provide the right decision-making information (but there is often no cost-effective alternative).

A big question of course is how much accuracy really matters. After all, many who use the static analysis and dynamic testing tools are finding large numbers of vulnerabilities already. Being able to work with the results to efficiently identify root causes and put in place effective fixes may for them well be more important than finding even more. Still, the results of the various studies should serve as a reminder that accuracy in the field may be less predictable than one would think, and that ongoing improvements (and more studies) are desirable.

On a related note, the Catalyst workshop Application Security: Process, Tools, and Architecture is now available online at the Burton Group Institute web site. In this workshop I provide an overview of common application security failings and describe at a mid-level detail the components of a software security program.

This Green Bar Will Save Your Life!

Well … maybe not.

SSL: great idea; not always well executed. Certificate Authorities (CAs) that issue SSL certificates for websites are supposed to carefully vet the requester, to make sure the business is valid (lookup in D&B, for example), that the administrator actually works for the company in question (HR query), and that the DNS domain is owned by that enterprise. Once all these hoops are jumped through, the cert is issued.

It turns out, however, that it’s much easier and cheaper simply to check whether a given domain name is legitimate (for varying values of “legitimate”) and the person requesting a cert can receive email at that domain. This is what several CAs started to do for SSL—especially during price wars a half-decade ago—and is why https://phish-all-day.example.com could have its SSL cert despite nefarious intent.

Extended Validation (EV) certificates were supposed to solve this problem. By introducing a governance organization (the CA/Browser Forum http://www.cabforum.org/), creating new rules for vetting, refactoring Certificate Policies (CPs), and requiring stringent audits of CAs, EV-SSL-requesting businesses were supposed to receive special scrutiny to avoid fraud and mayhem in cert issuance. Furthermore, and importantly, browsers implement a candy-colored URL status bar 

to show users whether they’re browsing an EV-cert-equipped website or not (in truth, browser implementations to date are simply green or not-green specifically for EV-cert status; additional candy-coating is applied for reputation filters and other stuff). A side effect of this newfound rigor is more $$ charged for certificates.

Less fraud is a good thing, yes? Here’s the bad news: EV certs can be bypassed. As reported by The Register, “Websites that use an enhanced form of digital authentication remain just as vulnerable to a common form of spoofing attack.” www.theregister.co.uk/2009/03/28/ev_ssl_spoofing/) More than one person has stated that the green bar really doesn’t matter to users; it’s just a way for CAs to make more money. And although I believe in good intentions of the CA/Browser Forum, it seems that they went after the high-end revenue-generating solution and missed some essentials.

To Err is Human

Blogger: Eric Maiwald

I was reading an article this week about the “hacking” of Intel’s Trusted Execution Technology. For some reason I was not surprised. Then today, I saw “Experts Reveal 25 Coding Errors That Let In Hackers.” The quote that I found interesting in this article was this “The Sans Institute said it was shocking that most of these common security errors are not understood by programmers.” I have to admit that I don’t find that shocking at all (whether the issue is the programmers making the mistakes or whether the problem is that their training was insufficient). What I’m shocked about is that security folks are shocked about it!

Humans are imperfect. We make mistakes all the time. If I ever forget that part I just have to type a few words and watch how many times I need to backspace to correct a typing error. We make mistakes when we design and build systems and products. Sometimes the mistakes are obvious (like when I type “dhe” instead of “the”) and sometimes the mistakes are subtle and hard to find.

Since we make mistakes, we have learned to live with this fact. A lot of times, people who build complex systems understand the likelihood of a mistake and they either build in some type of verification step within the system or the process of building the system requires multiple reviews and tests before it is put into use. For systems that control processes where the consequences of something bad happening are high, we not only build in verification checks but we also monitor the system. Often we also have people monitoring the people monitoring the system!

So why is it news when we find an error, or a mistake, or a vulnerability in software or hardware products? Why don’t we just assume that there will be mistakes in what we do? I’m not suggesting that we stop testing products or performing code reviews but I think we need to realize that the product of an imperfect human is going to be itself imperfect.

How does this translate into security and risk management? Well, if we assume that there will be errors and vulnerabilities in products and systems, we do not rely on a single control to manage our risk. It really is that simple. Oh sure, there are low risk cases where it does not make sense to pay for extra controls but when we have systems whose compromise will impact the enterprise or potentially cause injury or death, it behooves us to implement defense in depth. We don’t assume one control will always work. We install multiple controls. We monitor the system so that we can identify problems and react accordingly.

Last year, I wrote a blog entry On Response that mentioned how hard prevention is to do. Our mistakes are what make prevention hard. We can’t possibly construct the perfect preventative mechanism so we have to include additional controls that detect when our preventative controls fail and allow us to respond. This is just the way things are in our imperfect world. Rather than being surprised when you read about the latest vulnerability or error, just look at it as another reason why we don’t rely on just a single control.

The lost art of least privilege?

Blogger: Ramon Krikken

There comes a point in every security professional’s career where you think that certain aspects of secure application design must now be like common sense – everyone’s doing it. But then one morning, reading whichever syndicated news feed, you see an item with a screen shot: an application’s administrative interface with a list of people’s names, addresses, phone numbers, email addresses, and … passwords … in plain text … for the whole world to see. Some of these passwords were reported to be the same as the password used on PayPal accounts associated with the listed email address. Oops, our bad – luckily nothing more than a ‘minor hacking incident’, at least according to the site owner.

I’m talking, as some might already have guessed, about the recent hack of Bill O'Reilly's 'premium members' web site administrative interface, which purportedly was in response to his comments on the Sarah Palin email hack (Mark Diodati covered the Palin incident in this post over at the IdPS blog.) I certainly don’t think it’s very nice – or legal, for that matter – to perform such a hack and then post unsuspecting people’s contact information and passwords for all to see, but I’m also not very impressed with the poor application design that allowed the information, and passwords in particular, to be exposed like this. Not to mention that the interface was apparently not protected, allowing it to be found by a brute-force enumeration of web site URLs, but we’ll ignore that mistake for purposes of this post.

Now, I’m not writing this to pick on Bill and his design team, and I also wondered whether this is just so basic a mistake that it wouldn’t even be something interesting to write about. After all, in most enterprises a flaw like this wouldn’t pass QA, if it even got that far. However, It’s not too long ago that credit card companies printed full card numbers on statements, or that my whole social security number was displayed on some web page (and worse, used as the ‘subscriber identifier’ for an insurance company.) So most of those were fixed, but even now the ‘secret answers’ to the ‘security questions’ used for resetting a main password are displayed in plain text on many a ‘my account’ page.

What all of these issues have in common is that they are violations of least privilege or need-to-know principles (which in my opinion includes ‘already-should-know-so-please-don’t-repeat’) in the application’s business logic, and it happens a lot more often than it needs to. It’s not that the problem has been ignored, it’s just that there were more pressing issues to deal with. As a result, business logic flaws like these are not the first thing that comes to mind when we think of ‘application security’ – the onus is still very much on the developer in writing the code, less so on the business analyst developing the requirements, and even less on the business users themselves.

We’ve been very focused on the underlying technical vulnerabilities such as those in the OWASP top 10, which makes sense given the current threat environment. If we didn’t address these problems, there simply wouldn’t be such a thing as web application security. However, it’s definitely time to start working more and more on the business logic side of things. One of the advantages, if we manage to start early enough in the SDLC, is that we may not even have to worry so much about technical controls – we’ll simply have decided that a piece of information will not be stored, or that we’ll mask part of certain information in order to reduce exposure.

Least privilege and need-to-know are powerful security principles we can apply to reduce the amount of information that is exposed to begin with --- let’s make sure we advocate its use to the business customers.

Can I just comment out these lines of code?

Blogger: Ramon Krikken

A seemingly innocent question on a mailing list - which I paraphrased for brevity - set in motion a series of events with dire consequences. The specific code, which was generating error messages in a certain software quality assurance tool, happened to be a critical part of the random number generator in a cryptographic library package. By removing this code, the strength of the cryptographic key material was reduced to a point where cracking the key would take minutes instead of decades. The unfortunate thing about cryptography and randomness is that good and bad can be virtually indistinguishable, and in this case the result still looked so random that the problem went unnoticed for about two years. The impact - needing to regenerate two years worth of key material, and casting doubt on encrypted communication and access performed with those keys - has understandably led to some vigorous discussion and finger pointing. Search Google for "debian openssl" for more discussions than I can link to.

The action - making a change without following a standardized process  - is certainly not unique to this situation, and "the system was slow so I turned off this feature", or "I just fiddled around with it and it just started working" are phrases all too commonly heard in many aspects of IT. Some might argue that a commercial development process would likely have prevented this occurrence, but to simply turn this into a comparison of open source and commercial development ignores some very important aspects. There are important lessons to be learned that could benefit any software development process, particularly when process parts are being adapted to encompass ever changing development and security landscapes. In the ideal world, source code would be based on well-documented requirements, consistently structured, well commented, and maintained by easy-to-reach teams that understand the code inside and out. The reality of dealing with the pressure of delivery deadlines, distributed development teams, and code written either long ago or by a third party can make coding a daunting task ... and quality assurance next to impossible, especially if breakdowns in process or communication occur. The myriad of testing tools, sometimes producing output that can run in the hundreds of pages, coupled with a lack of understanding about their testing coverage, doesn't make the task any easier.

Looking at how this specific event unfolded can lead us down many paths of analysis, all of which will provide valuable information in attempting to determine a root cause. Unfortunately - and this is something that is also not unique to any specific kind of environment - not all parties involved are neutral, and there can also be a tendency to fixate on symptoms rather than the cause. One reason for this may be the assumption that it's possible to fix specific process parts without necessarily re-evaluating the process as a whole; another is that risks and the resulting need for assurance, including process assurance, may be underestimated. Looking at the failures in the flaw finding process purportedly followed in the Therac 25 accidents it's easy to see how this can result in unacceptable consequences. And while likely not resulting in loss of life, the potential economic loss associated with a failure of a cryptographic module suggests that a critical security component can't be treated like just any other piece of software.

How ever unfortunate, this event presents a good opportunity to take a moment and look at our own development processes. Particularly as we start to embrace service orientation, where we loosely couple different business functions while relying on centralized, and often externally developed, security and reliability services, we increase the possibility of creating situations such as this. Using a risk-based process, and testing and revisiting the process itself to ensure it stays current, will be vital in providing appropriate levels of software, system, and information assurance. Building a high-assurance component using a low-assurance process just isn't worth the risk.

The Fox and the Henhouse

Blogger: Bob Blakley

Yesterday Societe Generale, the second-biggest bank in France, announced that it had suffered almost 5 billion Euros in losses due to the activities of one of the bank's derivatives traders.

Societe Generale apologized for the losses, and explained a three-day delay in announcing the fraud publicly by saying that bank officials needed time to unwind as many of the fraudulent positions as possible in order to limit the bank¹s losses.

Although Societe Generale did not identify the trader responsible for the fraud in their initial communications, he has subsequently been identified as one Jerome Kerviel.

Societe Generale's press release regarding the incident can be found here:
http://www.telegraph.co.uk/money/graphics/2008/01/24/socgen.pdf.

The details of the fraud are not yet completely clear, and uninformed speculation is not likely to be helpful.  But the first paragraph of the bank¹s press release deserves comment.

Societe Generale begins by saying this: "Societe Generale Group (the "Group") has uncovered a fraud, exceptional in its size and nature: one trader, responsible for plain vanilla futures hedging on European equity market indices, had taken massive fraudulent directional positions in 2007 and 2008 beyond his limited authority."

Three things about this sentence are worrying.  First, the fraud is described as "exceptional in size and nature".   The good ones always are exceptional in size and nature.  Common frauds aren¹t usually hard to prevent after you¹ve seen a lot of them; the reason you pay a risk manager is to prevent the exceptional frauds.

Second, the bank describes Kerviel¹s job as "plain vanilla futures hedging." The worry here is that the bank¹s risk managers think futures hedging risks not worth worrying about because they¹re just "plain vanilla."

The third worrying thing is the last clause: "one trader... had taken massive fraudulent directional positions... beyond his limited authority." Clearly his authority was NOT limited; the risk management and governance mechanisms of the bank apparently failed to prevent Kerviel from exceeding his authority, and they also apparently failed to detect his actions in time to limit the damage.

Societe Generale goes on to say this in the last half of the first paragraph: "Aided by his in-depth knowledge of the control procedures, resulting from his former employment in the middle-office, he managed to conceal these positions through a scheme of elaborate fictitious transactions."

The governance and risk management lessons are the two usual ones:

1. The fox is a dangerous guard for the henhouse.  It may be safe to move traders into the design of risk-management systems; it is probably not a great idea to move the risk management personnel onto the trading desk.

2. The most dangerous assumption in the security business is the assumption that there are good guys. The risk management system MUST be designed to be secure even against attacks by insiders who have developed and operated it.

The only way to design a system to be secure against these insider attacks is to have strong attestation, transaction tracking, dual control, and supervision features - in other words, to ensure that activities are carried out in public and reviewed in a timely way.

Societe Generale appears to acknowledge these lessons later in the press release, when the bank notes that "The individuals in charge of his [Kerviel's - ed.] supervision will leave the Group."  Firing Kerviel's bosses will not fix the problem; only improving the bank¹s governance will prevent future frauds.

IBM bought Watchfire and HP bought SPI: But who’s going to win the software security trifecta?

Blogger: Diana Kelley

Over two years ago, in the Market analysis section of a Burton Report on application security I wrote, “As the technology and market matures, Burton Group expects that large, established vendors who supply complementary technologies will either develop their own tools or add one of the startups to their portfolio.”  Based on my assessment of the tools and the market, I genuinely believed we’d see that happen sometime in 2006. I was wrong. But, only by a few months.

This month we saw two titans purchase web application testing tools. IBM was first out of the gate, with the acquisition of Watchfire. And HP followed suit this week with the announcement that they’d scooped up SPI Dynamics. These are powerful data points proving that “large, established vendors” are taking the security of applications seriously. Both acquisitions make sense, IBM has a strong history in software development and owns the Rational line. HP put out a clear message about application testing last year when they purchased Mercury Interactive.

From an application security perspective, this is a really exciting shift in the market – but it surprised me that both companies picked web application testing as the strongest horses. My first questions were: Why didn’t either go for a static software analysis vendor? And, what about WAF (web application firewalls)?

IBM had a strong Rational Unified Process (RUP) relationship with static source code analysis vendor Secure Software, the original owners of the Comprehensive Lightweight Application Security Process (CLASP), which has since moved to OWASP. But Secure Software was acquired by competing static source code analysis vendor Fortify in January of this year, not by IBM. And WAF’s (like those from F5, Citrix, Breach, NetContinuum, and Imperva) dynamically learn where and how an application may be failing while it’s in production. While the WAFs can be configured to protect the application against its failures, wouldn’t it be sweet if they could consume information from the penetration testing tools, like SPI and Watchifire, and not only provide stronger protection against known vulnerabilities but also communicate their knowledge back to static source code analysis tools (Fortify, Klockwork, Ounce) – the very tools that can point a developer to the exact line of code where the problems may have originated?

Security guys – we know about defense in depth – and I think it’s time to apply that to software. Both in the SDLC and in production. Specifically, the company that really gets this right is going take the software security tool trifecta; the “shadrack, meshack, and abendigo” (gotta imagine Marlon Brando saying that in his best Sky Masterson voice) of software security. This means, static source code analysis (both in the IDE and stand-alone), pen testing tools, and WAFs – integrated and working together.

IBM – you’re first out of the gate – are you willing to make the acquisitions and do the integration work required to cross the finish line? CA and HP – you’re well positioned, are either of you willing to take the big win? And Symantec and McAfee – take note. Focusing on risk is a great direction – but let’s not forget that the software running our systems, our transactions, our core business processes directly informs what we have to “secure” after the fact. Making that software stronger is imperative.

I’m not a betting man (person?), but if I were, I’d also bet that IBM is going to figure this out first.

Short disclaimer: If you’ve read previous writings of mine on software security, you’ll know I don’t think this is a tools only problem. If you haven’t: it’s not a tools only problem. Robust software means a robust SDLC and there’s a lot of people and process in there, stuff a tool can’t always catch, that must be security aware.

Welcome to the blog of Burton Group's Security and Risk Management Strategies (SRMS) team!

Blogger: Dan Blum

This blog is created with the following in mind:

Industry perspectives: Whether it’s a denial of service attack on DNS servers, a rule covering electronic evidence or a hot vendor acquisition such as Cisco snapping up Reactivity in February, SRMS wants the option to weigh in. We have a unique perspective from many years of experience, many months of in-depth research on any number of topics, and hundreds or thousands of insightful customer interactions and probing vendor briefings.

Analysts unplugged: Have you ever sat down for 15 minutes to read your inbox, but an hour later you’re still at it? This happens all the time for me, but often as not it is a rewarding, not frustrating experience. Our analysts and consultants get into incredible discussions from time to time; I’ve often thought “I wish he/she would publish this!” Now we can, as a team. This blog won’t be like our architectural Technical Positions – where we bend over backwards to achieve consensus – it’ll be more of a backstage view.

Realism about security: SRMS promotes a systematic, comprehensive approach to security. However, we understand that information protection is more than a model; it must always happen within the larger context of the business. There are so many aspects to this that it’s hard to know where to begin. Even risk management - which is where we say to start - can be treacherous, and this has led us to addressing methodologies for both quantifiable and non-quantifiable risks.

Thematic focus: In our recent VantagePoint 2007 webcast, we identified five themes that we’ll be tracking closely: proactive security, de-perimeterization, raising the bar on OS (and endpoint) security, creating information-centric security architecture and achieving sustainable compliance. As important events or thoughts on these themes emerge, we’ll be sure to address them in the blog.

Make a difference: Information security is not a game; bad things are happening to people and organizations all the time. Yes, we’re in this business to make money, but what also keeps us motivated is the opportunity to score wins for the defense. Whether it’s improving the thought process, encouraging responsible behavior or promoting better practices, standards or better ways for information protection to work, we want to be on it. In keeping with current coverage themes, we’re very interested false positives reduction, reputation based trust, data redaction, endpoint and data virtualization, security event standards and other areas where breakthroughs are needed.

Feedback loop: Comments are turned on, and we’ll use them to have a discussion with the industry. If you have further ideas on what we’ve covered, or even if you disagree with something we wrote, please chime in. Time permitting, we’ll also to participate in ongoing blogosphere discussions, even if they occur on other blogs.