Login  |  Register  |  Contact
Friday, October 16, 2009

Where Art Thou, Security Logging?

By David J. Meier

Today you’d be hard pressed to find a decent sized network that doesn’t have some implementation of Security Event Management (SEM). It’s just a fact of modern regulation that a centralized system to collect all that logolicious information makes sense (and may be mandatory). Part of the problem with architecting and managing these systems is that one runs into the issue of securely collecting the information and subsequently verifying its authenticity.

Almost every network-aware product you might buy today has a logging capability, generally based on syslogRFC3164. Unfortunately, as defined, syslog doesn’t provide much security. In fact if you need a good laugh I’d suggest reading section 6 of the RFC. You’ll know you’re in the right place when you start to digest information about odors, moths and spiders. It becomes apparent, very quickly, when reading subparagraphs 6.1 through 6.10, that the considerations outlined are there more to tip you off that the authors already know syslog provides minimal security – so don’t complain to them. At this point most sane people question using such a protocol at all because surely there must be something better, right? Yes and no.

First let me clarify: I didn’t set out to create an exhaustive comparison of [enter your favorite alternative to syslog here] for this writeup. Sure RFC5424 obsoletes the originally discussed RFC3164 and yes RFC5425 addresses using TLS as a transport to secure syslog. Or maybe it would be better to configure BEEP on your routers and let’s not forget about the many proprietary and open source agents that you can install on your servers and workstations. I freely admit there are some great technologies to read about in event logging technology. The point though is that since there is considerable immaturity and many options to choose from, most environments fall back to the path of least resistance: good ol’ syslog over UDP.

Unfortunately I’ve never been asked how to do logging right by a client. As long as events are streaming to the SEM and showing up on the glass in the NOC/SOC, it’s not a question that comes up. It may not even be a big deal right now, but I’d be willing to bet you’ll see more on the topic as audits become more scrutinizing. Shouldn’t the integrity of that data be something a little more robust than the unreliable, unauthentic, repudiable and completely insecure protocol you probably have in production? You don’t have to thank me later, but I’d start thinking about it now.

—David J. Meier

Thursday, October 15, 2009

IDM: Reality Sets In

By David Mortman

As I have mentioned in previous posts, although in principle IDM isn’t that complicated, real world practicalities make it fairly challenging. To quote myself:

Businesses can have hundreds if not thousands of applications (GM purportedly had over 15,000 apps at one point) and each application itself can have hundreds or thousands of roles within it. Combine this with multiple methods of authentication and authorization, and you have a major problem on your hands which makes digging into the morass challenging to say the least.

I was chatting with Rich the other day, and he reminded me that there were several issues that I hadn’t brought up yet. By way of example, he sent me the following list:

  • Most organizations of even moderate size have already lost control of identities.
  • The challenge is to regain control, while instituting the processes you describe.
  • The average large enterprise has 1 custom application for every 100 employees
  • A surprising number of enterprise applications have more roles than users (especially ERP systems, as admins “cheat” and create new roles for different tasks of a user to deal with application restrictions).
  • Due to compliance, for in-scope applications you often need a full user/role analysis… 2 years ago.
  • Because of these factors, the IDM market is massive and has been one of the fastest growing in the security industry for years (I think it’s tapering off now, but it really isn’t my area so I could be wrong).
  • The IDM market itself is complex, with multiyear implementations, and customer satisfaction is often low until the pain of implementation is complete.
  • There are still a lot of issues integrating any kind of IDM into many custom applications.

As if that weren’t enough to make you want to go do something easier, the problem gets even worse when you realize that while compliance forces organizations to evaluate annually whether people should still have the roles they do, there is little to no compliance required around regularly adjusting the roles themselves within applications. As a result, the roles themselves only get reevaluated at major upgrade times (and often not even then) which means maybe every 18-24 months. The ugliness comes in because the business tends to change its needs much more quickly – this is why most major ERM, ERP, CRM, etc. rollouts fail: IT simply can’t keep up with the business. So it’s not enough to just solve the process problem, but in the long run, you will also need to deal with some fundamental business and IT cultural issues of how applications are handled. Essentially, IT will have to become a lot more agile in its ability to respond to changing business needs. While this is hardly limited to the IDM space, IDM nicely highlights the issue. After all, if the roles are meaningless, knowing who has what role may be helpful from an incident response or investigation standpoint, but cannot really help understand your risk or compliance profile.

—David Mortman

It Isn’t Risk Management If You Can’t Lose

By Rich

I was reviewing the recent Health and Human Services guidance on medical data breach notifications and it’s clear that the HHS either was bought off, or doesn’t understand the fundamentals of risk assessment. Having a little bit of inside experience within HHS, my vote is for willful ignorance.

Basically, the HHS provides some good security guidance, then totally guts it. Here’s a bit from the source article with the background:

The American Recovery and Reinvestment Act of 2009 (ARRA) required HHS to issue a rule on breach notification. In its interim final rule, HHS established a harm standard: breach does not occur unless the access, use or disclosure poses “a significant risk of financial, reputational, or other harm to individual.” In the event of a breach, HHS’ rule requires covered entities to perform a risk assessment to determine if the harm standard is met. If they decide that the risk of harm to the individual is not significant, the covered entities never have to tell their patients that their sensitive health information was breached.

You have to love a situation where the entity performing the risk assessment for a different entity (patients) is always negatively impacted by disclosure, and never impacted by secrecy. In other words, the group that would be harmed by protecting you gets to decide your risk.

Yeah, that will work.

This is like the credit rating agencies, many aspects of fraud and financial services, and more than a few breach notification laws. The entities involved face different sources of potential losses, but the entity performing the assessment has an inherent bias to mis-assess (usually by under-assessing) the risk faced by the target.

Now, if everyone involved is altruistic and unbiased this all works like a charm. Hell, even in Star Trek they don’t think human behavior that perfect.


Wednesday, October 14, 2009

Which Bits Are the Right Bits?

By Adrian Lane

(The following post covers some rather esoteric bits of security philosophy, or what Rich has affectionately called “Security Jazz” in the past. Unless you are into obscure data-centric security minutiae, you will probably not be interested).

Richard Bejtlich tweeted and posted on data integrity:

The trustworthiness of a digital asset is limited by the owner’s capability to detect incidents compromising the integrity of that asset.

This statement is absolutely correct and a really important point that is often overlooked. The problem is that most technologies which produce digital assets do not build tamper detection in, thus giving owners no way to detect integrity violtaions. And far too often people confuse interested party with owner of digital assets, as there can be many copies, each in the possession of a different person or group. It’s not that we can’t provide validation, because technology exists to provide assurance and authenticity.

Let’s look at an example: Who owns syslog data? Is it the IT administrator? The security professional? An auditor? In my opinion, none of them do. The OS owns the syslog, as it created the content. Much like you may think you own ‘your’ credit card number, but you don’t – it is something the issuing bank created and owns. They are the custodians of that number, and change it when they choose to.

syslog has no way to verify the contents of the log it creates over time. We take it on faith that it is unlikely a log file was corrupted or altered. If we need to verify integrity in the future, too bad. If you did not build in safeguards and a method for validating integrity when you created the data, it’s too late. The trustworthiness of the digital asset is limited to the owner’s capability to detect a compromise, and for many digital assets like syslog, that is nil.

For most digital assets, it is sufficient that we use them every day, as this provides sufficient confidence in their integrity. Encryption keys are a useful example. If the keys are corrupted, especially in a public-key situation, either the encryption or decryption operations fail. We may keep a backup somewhere safe to compare our working copy to, and while that can be effective in the most common problem situations, it’s only relevant for certain (common) use cases. Digital assets have an additional challenge over physical objects in terms of generations. Even if we can verify a particular iteration of a digital object, we can have infinite copies, so we need to be able to verify the most current iteration is in use.

For digital assets like encryption keys, account numbers, access tokens, and digital representations of self, the owner has a strong vested interest in not sharing the asset, keeping it safe, and possibly even keeping redundant copies against future emergencies or for verification. There are several technologies to prove integrity, they are just not used much. I posted a comment on Richard’s blog to this effect:

The trustworthiness of a digital asset is limited more by the trustworthiness of the owner than tamper detection. An owner with desire of privacy and data integrity has the means to protect digital assets.

Richard’s premise is an important one as we very seldom build in safeguards to validate ownership, state, authenticity or integrity. Non-repudiation tools and digital escrow services are nearly non-existent. There simply is not enough motivation to implement the tools we have which can provide assurance.

Gunnar Peterson blogged on this subject earlier this week as well, taking a slightly more applied look at the problem. His statement that these issues are outside the purview of DLP are absolutely correct. DLP is an outside-in model. This discussion has more to do with Digital Rights Management, which is an inside-out model. The owner must attest to integrity, and while a 3rd party proxy such as a DLP service could be entrusted with object escrow and integrity certification, it would require an alteration of the DLP’s “discover and protect” model. DRM is designed to be part of the application that creates the digital object, and while it is not often discussed, digital object ownership is part of that responsibility. Attestation to ownership is not possible without some form of integrity and state checking.

I have seen select DRM systems that were interested in high integrity, but none were commercially viable. Which answers Gunnar’s question:

Our ability using today’s technologies to deliver vastly improved audit logging is, I believe, a worthwhile and achievable goal. But it’s fair to ask - why hasn’t it happened yet?

There has been no financial incentive to do so. We have had excellent immutable log technologies for years but they are only used in limited cases. Web application audit trails are an interesting application of this technology and easy to do, but there is no compelling business problem motivating people to spend money on retrofitting what they have. I would like to see this type of feature for consumer protection, built into financial transactions where we really need to protect consumers from shoddy corporate record-keeping and failed banking institutions.

—Adrian Lane

Tuesday, October 13, 2009

Barracuda Networks Acquires Purewire

By Adrian Lane

Today Barracuda Networks announced their acquisition of Purewire. Barracuda has an incredibly broad product suite, including AV, WAF, Anti-spam, anti-malware, SSL gateways, and so on, but are behind their competition in web filtering and seriously lacking in solutions delivered as SaaS. The Purewire product set closes Barracuda’s biggest product gap, giving them URL filtering and some basic content inspection. But most importantly it can be delivered as SaaS. This is important for two reasons: first, Barracuda has been losing market share to email and web security vendors with comprehensive SaaS product lines. SaaS offers flexible deployment and extends the usable lifespan of existing appliance/software security investments. Second, SaaS can be sold ‘up-market’ or ‘down-market’, as pricing is simply adjusted for the desired capacity. This will keep the handful of Barracuda enterprise customers happy, and provide SME customers the ability to add capacity as needed, hopefully keeping them from bolting to other providers.

I have never had my hands on the Purewire product so I have little knowledge of its internal workings or competitive differentiators. I have only spoken with a couple customers but they seemed to be satisfied with the web filtering capabilities. No wholehearted endorsements, but I did not hear any complaints either – nothing wrong if the endorsements are not passionate as often the best than can be said for web filtering products is they perform their jobs and go unnoticed. Based on recent press releases and joint customer announcements, I was expecting Proofpoint to be the acquirer. Regardless, this is a better fit for both companies given Proofpoint’s significant overlap with Purewire. And Barracuda has greater need for this technology. It has been a long time coming but they are finally turning around and showing a dedication to a service based delivery model. Remember, it was only two years ago that Barracuda bet on Web Application Firewalls acquired with Netcontinuum. That bet did not pay off particularly well, as the WAF market never blossomed as predicted. And it further entrenched Barracuda as a box shop. This is a move in the right direction.

—Adrian Lane

Microsoft Security Updates for October 2009

By Adrian Lane

We don’t normally cover Patch Tuesday unless there is something unusual, but the October 2009 advanced notification appears to be just that. It lists patches for 13 different security bulletins, for what looks like 30 separate security problems. Eight of the bulletins are for critical vulnerabilities with the possibility of remote code execution. The majority of the patches are for Windows itself, with a couple for SQL Server, Office, and Forefront, but it looks like just about every production version of Windows is affected. Given the scope of this security patch and the seriousness of the bugs, it looks like IT departments are going to be working overtime for a while.

Details of each of the vulnerabilities will be released later today, and I will update this post with specific points of interest as I find them. I am assuming that at least one of the patches is in response to the Server Message Block vulnerability discovered back in August. IIS is not listed as one of the affected products, but odds are the underlying OS will be, and folks will be restarting app servers either way. I am still trying to determine the issue with SQL Server. More to come…

==== Updated ==== Microsoft has updated the bulletin and included the security advisory links and some details on the threats. The SQL Server vulnerability is not within the core database engine, but the GDI ActiveX library in the print server. It’s in 2005, not 2000.

When SQL Server Reporting Services is installed, the affected installations of SQL Server software may host the RSClientPrint ActiveX control. This ActiveX control distributes a copy of gdiplus.dll containing the affected code. Customers are only impacted when the RSClientPrint ActiveX control is installed on Microsoft Windows 2000 operating systems. If the RSClientPrint ActiveX control is installed on any other operating system, the system version of GDI+ will be used and the corresponding operating system update will protect them.

The GDI+ vulnerability pretty much allows you to take down any Microsoft platform or function that uses the GDI dll, which is basically anything that uses images for forms, which is just about everything. My earlier comment that IIS was not listed was true, but there is in fact a bug linked to IIS: version 5.0 of the FTP service is vulnerable to remote code exploitation. Some of the exploits have workarounds and can be masked through firewall and web application firewall settings, however given the number and severity of the issues, we do recommend patching as soon as possible.

—Adrian Lane

Monday, October 12, 2009

Personal Information Dump

By Adrian Lane

Interesting story of a San Francisco commercial landlord who found 46 boxes of personal information and financial data for thousands of people left behind by a failed title company.

The boxes were the detitrus of what was until last year a thriving business, Financial Title. Then the economy tanked, and the company folded up its locations all across California, including the one Tookoian rented to it.

“They basically abruptly closed shop,” he said as he walked past the company’s logo still affixed to a white wall. “Turned the lights off, closed the door and walked away.”

Despite all of the data breaches and crazy stuff we see in the data security profession, I am still shocked at this type of carelessness. I expect to see prosecutors go after the owners of the company for failure to exercise their custodial responsibilities for these records.

Ridout says the Federal Trade Commission has implemented new laws requiring businesses to properly dispose of sensitive personal information. So far, an Illinois mortgage company was fined $50,000 for throwing personal records in a dumpster. But fines like that are rare.

And after his good deed of having the records destroyed, the landlord still had to pay the bill. Perhaps the FTC will set an example in this case.

—Adrian Lane

Friday, October 09, 2009

Friday Summary - October 9, 2009

By Adrian Lane

A lot of not this week. I was not at SECtor, although I understand it was a good time. I am not going to Oracle Open World. I should be going, but too many projects are either beginning or remain unfinished for me to travel to the Bay Area, visiting old friends and finding a good bar to hang out at. That is lots of fun I will not be having. I will not be going to Atlanta in November as the Tech Target event for data security has been knocked off the calendar. And I am not taking a free Mexican holiday in Peurta de Cancun or wherever Rich is enjoying himself. Oh well, weather has been awesome in Phoenix.

With the posts for Dark Reading this week I spent a bunch of time rummaging around for old database versions and looking through notes for database audit performance testing. Some of the old Oracle 7.3 tests with nearly 50% transactional degradation still seem unreal, but I guess it should not surprising that auditing features in older databases are a problem. They were not designed to audit transactions like we do today. They were designed to capture a sample of activity so administrators could understand how people were using the database. Performance and resource allocation were the end goals. Once a sample was collected, auditing was turned off. Security was not really a consideration, and no thought given to compliance. Yet the order of use and priority has been turned upside down, as they fill a critical compliance need but require careful deployment.

While I was at RSA this year, one database vendor pointed out some of the security vendors citing this 50% penalty as what you could expect. Bollocks! Database security and compliance vendors who do not use native database auditing would like you to embrace this performance myth. They have a competitive offering to sell, so the more people are fearful of performance degradation, the better their odds of selling you an alternative to accomplish this task. I hear DBAs complain a lot about using native auditing features because it used to be a huge performance problem, and DBAs would get complaints from database and application users.

Auditing produces a lot of data. Something has to be done with that data. It needs to be parsed for significant events, reported on, acted upon, erased or backed up, or some combination thereof. In the past, database administrators performed these functions manually, or wrote scripts to partially automate the responsibility, and rewrote them any time something within IT changed. As a form of self preservation, DBAs in general do not like accepting this responsibility. And I admit, it takes a little time to get it set up right, and you may even discover some settings to be counter-intuitive. However, auditing is a powerful tool and it should not be dismissed out of hand. It is not my first choice for database security; no way, no how! But for compliance reporting and control validation, especially for SOX, it’s really effective. Plus, much of this burden can be removed by using third party vendors to handle the setup, data extraction, cleanup, and reporting.

Anyway, enough about database auditing. On to the Summary:

Webcasts, Podcasts, Outside Writing, and Conferences

Favorite Securosis Posts

Favorite Outside Posts

Top News and Posts

Blog Comment of the Week

This week’s best comment comes from Adam in response to Mortman’s Online Fraud Report:

It’s sort of hard to answer without knowing more about what data he has, but what I’d like is raw data, anonymized to the extent needed, and shared in both data and analyzed forms, so other people can apply their own analysis to the data.

—Adrian Lane

Wednesday, October 07, 2009

Online Fraud Report: What Would You Want To See?

By David Mortman

So a buddy of mine back from when I was on the customer side contacted me recently. He’s at a new company doing some very interesting work on detecting certain classes of online fraud and amounts of malware on websites. So far he’s gathered some fascinating data on just how bad the problem is, and I’m trying to convince him that he should start publishing some of his aggregate data in a quarterly or semi-annual report. He is very interested but would love some community input on what the report should look like, which brings me to you.

Some of what should be in such a report is obvious – such as rate of detected fraud overall and by various industry verticals. The rest isn’t so clear and that’s where you all come in. Put on whatever hat you like – CISO, CFO, security researcher, risk officer, consumer, or whatever else – and what would you like to see in such a report? Are there things you hate about other reports? Or are there things you wish they covered which they never do? Throw out your requests, rants, comments, ideas, and questions in the comments and I’ll collect them all together and summarize them in a future post. If this really takes off, I’ll move it over to the forums.

—David Mortman

Tuesday, October 06, 2009

Visa’s Data Field Encryption

By Adrian Lane

I was reading Martin McKeay’s blog this morning and saw his reference to Visa’s Data Field Encryption white paper. Martin’s point that Visa is the author, rather than the PCI council, is a good one. Now that I’ve read the paper, I don’t think Visa is putting it out as a sort of litmus test on behalf of the council, but instead Visa is taking a stand on what technologies they want endorsed. And if that is the case, Rich’s feeling prediction that “Tokenization Will Become the Dominant Payment Transaction Architecture” will happen far faster than we anticipated.

A couple observations about the paper:

… data field encryption renders cardholder data useless to criminals in the event of a merchant data breach decryption.

Use robust key management solutions…


Visa has developed best practices to assist merchants in evaluating the new encryption…

Use an alternate account or transaction identifier for business processes that requires[sic] the primary account number…

The recommendations could describe tokenization or format preserving encryption, but it looks to me like they have tokenization in mind. And by tokenization I mean the PAN and other sensitive data are fully encrypted at the POS, and their response to the merchant is a token. I like the fact that their goals do not dictate technology choices, and are worded in such a way that they should not be obsolete within a year.

But the document appears to have been rushed to publication. For example, goal #4: protect the cryptographic operations within devices from physical or logical compromises. It’s the cryptographic operations you want to protect; the device should be considered expendable and not sensitive to compromise.

Similarly, goal #1 states:

Limit cleartext availability of cardholder data and sensitive authentication data to the point of encryption and the point of decryption.

But where is the “point of encryption”? It’s one thing to be at the POS terminal, but if this is a web transaction environment, does that mean it happens at the web server? At the browser level? Somewhere else? Reading the document it seems clear that the focus is on POS and not web based transactional security, which looks likes a big mistake to me.

Martin already pointed out that the authors lumped encryption and hashing into a single domain, but that may have been deliberate, to make the document easier to read. But if clarity was the goal, who thought “Data Field Encryption” was a good term? It does not describe what is being proected. And with tokenization, encryption is only part of the picture. If you are a web application or database developer, you will see why this phrase is really inappropriate.

Make no mistake – Visa has put a stake in the ground and it will be interesting to see how the PCI Council reacts.

—Adrian Lane

Database Audit Events

By Adrian Lane

I have attended a lot of database developer events and DBA forums around the country in the last 6 years. One benefit of attending lectures by database administrators for database administrators is the wealth of information on tools, tricks, and tips for managing databases. And not just the simple administrative tasks, but clever ways to accomplish more complex tasks. A lot of these tricks never seem to make it into the mainstream, instead remaining part of the DBA’s exclusive repertoire. I wish I had kept better notes. And unfortunately I am not going to Oracle Open World, but I wanted to for this very reason.

As part of a presentation I worked on a number for years ago at one of these events, I provided an overview of the common elements in the audit logs. I wanted to show how to comb through logs to find events of interest. I have placed a catalog of audit events for several relational database platforms into the Database Security section of our research library. For those of you interested in “roll your own” database auditing, it may be useful. I have listed out the audit-able events for Sybase, Oracle, SQL Server, and DB2. I had a small shell script that would grab the events I was interested in from the audit trail, place them into a separate file, and then clean up the reviewed audit logs or event monitor resource space. What you choose to do with the data will vary.

As part of my latest submission to Dark Reading, I referred to the essential audit-able events most commonly required for regulatory and security efforts. These files list out the specifics for each of those suggestions. If anyone in the community would like to contribute similar information for MySQL or even Postgres, I will add those into the library as well.

—Adrian Lane

Friday, October 02, 2009

Friday Summary- October 2, 2009

By Rich

I hate to admit it, but I have a bad habit of dropping administrative tasks or business development to focus on the research. It’s kind of like programmer days – I loved coding, but hated debugging or documentation. But eventually I realize I haven’t invoiced for a quarter, or forgot to tell prospects we have stuff they can pay for. Those are the nights I don’t sleep very well.

Thus I’ve spent a fair bit of time this week catching up on things. I still have more invoices to push out, and spent a lot of time editing materials for our next papers, and my contributions to the next version of the Cloud Security Alliance Guidance report. I even updated our retainer programs for users, vendors, and investors. Not that I’ve sent it to anyone – I sort of hate getting intrusive sales calls, so I assume I’m annoying someone if I mention they can pay me for stuff. Probably not the best trait for an entrepreneur.

Thus I’m looking forward to a little downtime next week as my wife and I head off for vacation. It starts tonight at a black tie charity event at the Phoenix Zoo (first time I’ll be in a penguin suit in something like 10 years). Then, on Monday, we head to Puerto Vallarta for a 5 day vacation we won in a raffle at… the Phoenix Zoo. It’s our first time away from the baby since we had her, so odds are instead of hanging out at the beach or diving we’ll be sleeping about 20 hours a day.

We’ll see how that goes.

And with that, on to the Friday Summary:

Webcasts, Podcasts, Outside Writing, and Conferences

Favorite Securosis Posts

Other Securosis Posts

Favorite Outside Posts

Top News and Posts

Blog Comment of the Week

This week’s best comment comes from Slavik in response to SQL Injection Prevention:

Hi Adrian, good stuff.

I just wanted to point out that the fact that you use stored procedures (or packages) is not in itself a protection against SQL injection. It’s enough to briefly glance at the many examples on milw0rm to see how even Oracle with their supplied built-in packages can make mistakes and be vulnerable to SQL injections that will allow an attacker to completely control the database. I agree that if you use only static queries then you’re safe inside the procedure but it does not make your web application safe (especially with databases that support multiple commands in the same call like SQL server batches). Of course, if you use dynamic queries, it’s even worse. Unfortunately, there are times when dynamic queries are necessary and it makes the code very difficult to write securely.

The most important advice regarding SQL injection I would give developers is to use bind variables (parametrized queries) in their applications. There are many frameworks out there that encourage such usage and developers should utilize them.


Thursday, October 01, 2009

SQL Injection Prevention

By Adrian Lane

The team over at Dark Reading was kind enough to invite me to blog on their Database Security portal. This week I started a mini-series on threat detection and prevention by leveraging native database features. This week’s post is on using stored procedures to combat SQL injection attacks. But those posts are fairly short and written for a different audience. Here, I will be cross-posting additional points and advanced content I left out of those articles.

My goal was to demystify how stored procedures can help combat SQL injection. There are other options to detect and block SQL injection attacks, many of which have been in use with limited success for some time now.

What can you do about SQL injection? You can patch your database to block known threats. You can buy firewalls to try to intercept these rogue statements, but the application and general network firewalls have shown only limited effectiveness. You need to have a very clear signature for the threat, as well as a written a policy that does not break your application. Many Database Activity Monitoring vendors can block queries before they arrive. Early DAM versions detected SQL injection based on exact pattern matching that was easy for attackers to avoid, back when DAM policy management could not accommodate business policy issues; this resulted in too many false negatives, too many false positives, and deadlocked applications. These platforms are now much better at policy management and enforcement. There are memory scanners to examine statement execution and parameters, as well as lexical and content analyzers to detect and block (with fair success). Some employ a hybrid approach, with assessment to detect known vulnerabilities, and database/application monitoring to provide ‘virtual patching’ as a complement.

I have witnessed many presentations at conferences during the last two years demonstrating how a SQL injection attack works. Many vendors have also posted examples on their web sites and show how easy it is to compromise and unsecured database with SQL injection. At the end of the session, “how to fix” is left dangling. “Buy our product and we will fix this problem for you” is often their implication. That may be true or false, but you do not necessarily need a product to do this, and a bolt-on product is not always the best way. Most are reactive and not 100% effective.

As an application developer and database designer, I always took SQL injection attacks personally. The only reason the SQL injection attack succeeded was a flaw in my code, and probably a bad one. The applications I produced in the late 90s and early 2000s were immune to this form of attack (unless someone snuck an ad-hoc query into the code somewhere without validating the inputs) because of stored procedures. Some of you might say note this was really before SQL injection was fashionable, but as part of my testing efforts, I adopted early forms of fuzzing scripts to do range testing and try everything possible to get the stored procedures to crash. Binary inputs and obtuse ‘where’ clauses were two such variations. I used to write a lot of code in stored procedures and packages. And I used to curse and swear a lot as packages (Oracle’s version, anyway) are syntactically challenging. Demanding. Downright rigorous in enforcing data type requirements, making it very difficult to transition data to and from Java applications. But it was worth it. Stored procedures are incredibly effective at stopping SQL injection, but they can be a pain in the ass for more complex objects. But from the programmer and DBA perspectives, they are incredibly effective for controlling the behavior of queries in your database. And if you have ever had a junior programmer put a three-table cartesian product select statement into a production database, you understand why having only certified queries stored in your database as part of quality control is a very good thing (you don’t need a botnet to DDoS a database, just an exuberant young programmer writing the query to end all queries). And don’t get me started on the performance gains stored procedures offer, or this would be a five-page post …

If you like waiting around for your next SQL injection 0-day patch, keep doing what you have been doing.

—Adrian Lane

Wednesday, September 30, 2009

Tokenization Will Become the Dominant Payment Transaction Architecture

By Rich

I realize I might be dating myself a bit, but to this day I still miss the short-lived video arcade culture of the 1980’s. Aside from the excitement of playing on “big hardware” that far exceeded my Atari 2600 or C64 back home (still less powerful than the watch on my wrist today), I enjoyed the culture of lining up my quarters or piling around someone hitting some ridiculous level of Tempest.

One thing I didn’t really like was the whole “token” thing. Rather than playing with quarters, some arcades (pioneered by the likes of that other Big Mouse) issued tokens that would only work on their machines. On the upside you would occasionally get 5 tokens for a dollar, but overall it was frustrating as a kid. Years later I realized that tokens were a parental security control – worthless for anything other than playing games in that exact location, they keep the little ones from buying gobs of candy 2 heartbeats after a pile of quarters hits their hands.

With the increasing focus on payment transaction security due to the quantum-entangled forces of breaches and PCI, we are seeing a revitalization of tokenization as a security control. I believe it will become the dominant credit card transaction processing architecture until we finally dump our current plain-text, PAN-based system.

I first encountered the idea a few years ago while talking with a top-tier retailer about database encryption. Rather than trying to encrypt all credit card data in all their databases, they were exploring the possibility of concentrating the numbers in one master database, and then replacing the card numbers with “tokens” in all the other systems. The master database would be highly hardened and encrypted, and keep track of which token matched which credit card. Other systems would send the tokens to the master system for processing, which would then interface with the external transaction processing systems.

By swapping out all the card numbers, they could focus most of their security efforts on one controlled system that’s easier to control. Sure, someone might be able to hack the application logic of some server and kick off an illicit payment, but they’d have to crack the hardened master server to get card numbers for any widespread fraud.

We’ve written about it a little bit in other posts, and I have often recommended it directly to users, but I probably screwed up by not pushing the concept on a wider basis. Tokenization solves far more problems than trying to encrypt in place, and while complex it is still generally easier to implement than alternatives. Well-designed tokens fit the structure of credit card numbers, which may require fewer application changes in distributed systems. The assessment scope for PCI is reduced, since card numbers are only in one location, which can reduce associated costs. From a security standpoint, it allows you to focus more effort on one hardened location. Tokenization also reduces data spillage, since there are far fewer locations which use card numbers, and fewer business units that need them for legitimate functions, such as processing refunds (one of the main reasons to store card numbers in retail environments).

Today alone we were briefed on two different commercial tokenization offerings – one from RSA and First Data Corp, the other from Voltage. The RSA/FDC product is a partnership where RSA provides the encryption/tokenization tech FDC uses in their processing service, while Voltage offers tokenization as an option to their Format Preserving Encryption technology. (Voltage is also partnering with Heartland Payment Systems on the processing side, but that deal uses their encryption offering rather than tokenization).

There are some extremely interesting things you can do with tokenization. For example, with the RSA/FDC offering, the card number is encrypted on collection at the point of sale terminal with the public key of the tokenization service, then sent to the tokenization server which returns a token that still “resembles” a card number (it passes the LUHN check and might even include the same last 4 digits – the rest is random). The real card number is stored in a highly secured database up at the processor (FDC). The token is the stored value on the merchant site, and since it’s paired with the real number on the processor side, can still be used for refunds and such. This particular implementation always requires the original card for new purchases, but only the token for anything else.

Thus the real card number is never stored in the clear (or even encrypted) on the merchant side. There’s really nothing to steal, which eliminates any possibility of a card number breach (according to the Data Breach Triangle). The processor (FDC) is still at risk, so they will need to use a different set of technologies to lock down and encrypt the plain text numbers. The numbers still look like real card numbers, reducing any retrofitting requirements for existing applications and databases, but they’re useless for most forms of fraud. This implementation won’t work for recurring payments and such, which they’ll handle differently.

Over the past year or so I’ve become a firm believer that tokenization is the future of transaction processing – at least until the card companies get their stuff together and design a stronger system. Encryption is only a stop-gap in most organizations, and once you hit the point where you have to start making application changes anyway, go with tokenization.

Even payment processors should be able to expand use of tokenization, relying on encryption to cover the (few) tokenization databases which still need the PAN.

Messing with your transaction systems, especially legacy databases and applications, is never easy. But once you have to crack them open, it’s hard to find a downside to tokenization.


Tuesday, September 29, 2009

Realistic Security

By David J. Meier

Finally, it’s here: my first post! Although I doubt anyone has been holding their breath, I have had a much harder than anticipated time trying to nail down my first topic. This is probably due in part to the much larger and more focused audience at Securosis than I have ever written for in the past. That said, I’d like to thank Rich and Adrian for supporting me in this particular role and I hope to bring a different perspective to Securosis with increased frequency as I move forward.

Last week provided a situation that brought out a heated discussion with a colleague (I have a bad habit of forgetting that not everyone enjoys heated debate as much as I do). Actually, the argument only heated up when he mentioned that vulnerability scanning and penetration testing aren’t required to validate a security program. At this point I was thoroughly confused because when I asked how he could measure the effectiveness of such a security program without those tools, he didn’t have a response. Another bad habit: I prefer debating with someone who actually justifies their positions.

My position is that if you can’t measure or test the effectiveness of your security, you can’t possibly have a functioning security program.

For example, let’s briefly use the Securosis “Building a Web Application Security Program” white paper as a reference. If I take the lifecycle outline (now please turn your PDFs to page 11, class) there’s no possible way I can fulfill the Secure Deployment step without using VA and pen testing to validate our security controls are effective. Similarly, consider the current version of PCI DSS without any pen testing – again you fail in multiple requirement areas. This is the point at which I start formulating a clearer perspective on why we see security failing so frequently in certain organizations.

I believe one of the major reasons we still see this disconnect is that many people have confused compliance, frameworks, and checklists with what’s needed to keep their organizations secure. As a consultant, I see it all the time in my professional engagements. It’s like taking the first draft blueprints for a car, building said car, and assuming everything will work without any engineering, functional, or other tests. What’s interesting is that our compliance requirements are evolving to reflect, and close, this disconnect.

Here’s my thought: year over year compliance is becoming more challenging from a technical perspective. The days of paper-only compliance are now dead. Those who have already been slapped in the face with high visibility breach incidents can probably attest (but never will) that policy said one thing and reality said another. After all they were compliant – it can’t be their fault that they’ve been breached after they complied with the letter of the rules.

Let’s make a clear distinction between how security is viewed from a high level that makes sense (well, at least to me) by defining “paper security” versus “realistic security”. From the perspective of the colleague I was talking with, he believed that all controls and processes on paper would somehow magically roll over into the digital boundaries of infrastructure as he defined them. The problem is: how can anyone write those measures if there isn’t any inherent technology mapping during development of the policies? Likewise how can anyone validate a measure’s existence and future validity without some level of testing? This is exactly the opposite of my definition of realistic security. Realistic security can only be created by mapping technology controls and policies together within the security program, and that’s why we see both the technical and testing requirements growing in the various regulations.

To prove the point that technical requirements in compliance are only getting more well defined, I did some quick spot checking between DSS 1.1 and 1.2.1. Take a quick look at a few of the technically specific things expanded in 1.2.1:

  • 1.3.6 states: ‘…run a port scanner on all TCP ports with “syn reset” or “syn ack” bits set’ – new as of 1.2.
  • 6.5.10 states: “Failure to restrict URL access (Consistently enforce access control in presentation layer and business logic for all URLs.)” – new as of 1.2.
  • 11.1.b states: “If a wireless IDS/IPS is implemented, verify the configuration will generate alerts to personnel” – new as of 1.2.

Anyone can see the changes between 1.1 and 1.2.1 are relatively minor. But think about how, as compliance matures, both its scope and specificity increase. This is why it seems obvious that technical requirements, as well as direct mappings to frameworks and models for security development, will continue to be added and expanded in future revisions of compliance regulations.

This, my friends, is on the track of what “realistic security” is to me. It can succinctly be defined as a never ending Test Driven Development (TDD) methodology applied to a security posture: if it is written in your policy then you should be able to test and verify it; and if you can’t, don’t, or fail during testing, then you need to address it. Rinse, wash, and repeat. Can you honestly say those reams of printed policy are what you have in place today? C’mon – get real(istic).

—David J. Meier