Login  |  Register  |  Contact
Tuesday, August 31, 2010

Understanding and Selecting an Enterprise Firewall: Introduction

By Mike Rothman

Today we begin the our next blog series: Understanding and Selecting an Enterprise Firewall.

Yes, really. Shock was the first reaction from most folks. They figure firewalls have evolved about as much over the last 5 years as ant traps. They’re wrong, of course, but most people think of firewalls as old, static, and generally uninteresting. In fact, most security folks begin their indentured servitude looking after the firewalls, where they gain seasoning before anyone lets them touch important gear like the IPS.

As you’ll see over the next few weeks, there’s definitely activity on the firewall front which can and should impact your perimeter architecture and selection process. That doesn’t mean we will be advocating yet another rip and replace job on your perimeter (sorry vendors), but there are definitely new capabilities that warrant consideration, especially as the maintenance renewals come due.

To state the obvious, the firewall tends to be the anchor of the enterprise perimeter, protecting your network from most of the badness out there on the Intertubes. We do see some use of internal firewalling, driven mostly by network segmentation. Pesky regulations like PCI mandate that private data is at a minimum logically segmented from non-private data, so some organizations use firewalls to keep their in scope systems separate from the rest, although most organizations use network-level technologies to implement their segmentation.

In the security market, firewalls resides in the must have category along with anti-virus (AV). I’m sure there are organizations that don’t use firewalls to protect their Internet connections, but I have yet to come across one. I guess they are the same companies that give you that blank, vacant stare when you ask if it was a conscious choice not to use AV. The prevalence of the technology means we see a huge range of price points and capabilities among firewalls.

Consumer uses aside, firewalls range in price from about $750 to over $250,000. Yes, you can spend a quarter of a million dollars on a firewall. It’s not easy, but you can do it. Obviously there is a huge difference between the low end boxes protecting branch and remote offices and the gear protecting the innards of a service provider’s network, but ultimately the devices do the same thing. Protect one network from another based on a defined set of rules. For this series we are dealing with the enterprise firewall, which is designed for use in larger organizations (2,500+ employees). That doesn’t mean our research won’t be applicable to smaller companies, but enterprise is the focus.

From an innovation standpoint, not much happened on firewalls for a long time. But three major trends have hit and are forcing a general re-architecting of firewalls:

  • Performance/Scale: Networks aren’t getting slower and that means the perimeter must keep pace. Where Internet connections used to be sold in multiples of T1 speed, now we see speeds in the hundreds of megabits/sec or gigabits/sec, and to support internal network segmentation and carrier uses these devices need to scale to and past 10gbps. This is driving new technical architectures to better utilizing advanced packet processing and silicon.
  • Integration: Most network perimeters have evolved along with the threats. That means the firewall/VPN is there, along with an IPS, but also an anti-spam gateway, web filter, web application firewall, and probably 3-4 other types of devices. Yeah, this perimeter sprawl creates a management nightmare, so there has been a drive for integration of some of these capabilities into a single device. Most likely it’s firewall and IDS/IPS, but there is clearly increasing interest in broader integration (UTM: unified threat management) even at the high end of the market. This is also driving new technical architectures because moving beyond port/protocol filtering seriously taxes the devices.
  • Application Awareness: It seems everything nowadays gets encapsulated into port 80. That means your firewall makes like three blind mice for a large portion of your traffic, which is clearly problematic. This has resulted in much of the perimeter sprawl described above. But through the magic of Moore’s law and some savvy integration of some IPS-like capabilities, the firewall can enforce rules on specific applications. This climbing of the stack by the firewall will have a dramatic impact on not just firewalls, but also IDS/IPS, web filters, WAFs, and network-layer DLP before it’s over. We will dig very deeply into this topic, so I’ll leave it at that for now.

So it’s time to revisit how we select an enterprise firewall. In the next few posts we’ll look at this need for application awareness by digging into use cases for application-centric rules before we jump into technical architectures.

—Mike Rothman

Security Briefing: August 31st

By Liquidmatrix

newspapera.jpg

A good morning to all. There are some interesting articles this morning. There is a good article by Adrian Lane leading off this morning (full disclosure: we’re both at Securosis, LLC) and we round out the list with news of a data breach in Delaware where a consulting firm, Aon Consulting, posted personal information of some 22,000 state retirees.

Have a great day!

cheers,
Dave

Click here to subscribe to Liquidmatrix Security Digest!.

And now, the news…

  1. The Essentials Of Database Assessment | Dark Reading
  2. Apple QuickTime backdoor creates code-execution peril | The Register
  3. Cisco patches bug that crashed 1 percent of Internet | The Reuters
  4. India Extends Time for RIM to Develop Strategy for Government Security Access | TMCnet
  5. ‘Defaced gov’t websites another black eye for RP’ | ABS CBN News
  6. 3M offers $943M for biometric security vendor Cogent Systems | Business Week
  7. Back to School Safety Tips — Social Media, Device Security, Malware | Huffington Post
  8. India seeks ‘lawful access’ to all telecom data | Times of India
  9. State retiree data breached | Delaware Online

—Liquidmatrix

Security Briefing: August 31st

By Liquidmatrix

newspapera.jpg

A good morning to all. There are some interesting articles this morning. There is a good article by Adrian Lane leading off this morning (full disclosure: we’re both at Securosis, LLC) and we round out the list with news of a data breach in Delaware where a consulting firm, Aon Consulting, posted personal information of some 22,000 state retirees.

Have a great day!

cheers,
Dave

Click here to subscribe to Liquidmatrix Security Digest!.

And now, the news…

  1. The Essentials Of Database Assessment | Dark Reading
  2. Apple QuickTime backdoor creates code-execution peril | The Register
  3. Cisco patches bug that crashed 1 percent of Internet | Reuters
  4. India Extends Time for RIM to Develop Strategy for Government Security Access | TMCnet
  5. ‘Defaced gov’t websites another black eye for RP’ | ABS CBN News
  6. 3M offers $943M for biometric security vendor Cogent Systems | Business Week
  7. Back to School Safety Tips — Social Media, Device Security, Malware | Huffington Post
  8. India seeks ‘lawful access’ to all telecom data | Times of India
  9. State retiree data breached | Delaware Online

—Liquidmatrix

Monday, August 30, 2010

Data Encryption for PCI 101: Selection Criteria

By Adrian Lane

As a merchant your goal is to protect stored credit card numbers (PAN), as well as other card data such as card-holder name, service code, and expiration date. You need to protect these fields from both unwanted physical (e.g., disk, tape backup, USB) and logical (e.g., database queries, file reads) inspection. And detect and stop misuse if possible, as well.

Our goal for this paper is to offer pragmatic advice so you can accomplish those goals quickly and cost-effectively, so we won’t mince words. For PCI compliance, we only recommend one of two encryption choices: Transparent Database Encryption (TDE) or application layer encryption.

There are many reasons these are the best options. Both offer protection from unwanted inspection of media, with similar acquisition costs. Both offer good performance and support external key management services to provide separation of duties between local platform administrators, storage administrators, and database administrators. And provided you encrypt the entire database with TDE, both are good at preventing data leakage.

Choosing which is appropriate for your requirements comes down to the applications you use and how they are deployed within your IT environment. Here are some common reasons for choosing TDE:

Transparent Database Encryption

  • Time: If you are under pressure to get compliant quickly – perhaps because you can’t possibly see how you can comply by your next audit. The key TDE services are very simple to set up, and flipping the switch on encryption is simple enough to roll out in an afternoon.
  • Modifying Legacy Applications: Legacy applications are typically complex in function and design, which makes modification difficult and raises the possibility of problematic side effects in processing and UI. Most scatter database communication across thousands of queries in different program areas. To modify the application and deal with the side effects can be very costly – in terms of both time and money.
  • Application Sprawl: As with hub-and-spoke workflows and retail systems, you could easily have 20+ applications that all reference the same transaction database. Employing encryption within the central hub saves time and is far less likely to generate application errors. You must still mask output in the applications for users who are not entitled to view credit card numbers and pay for that masking, but TDE deployment is still simpler and likely cheaper.

Application Layer Encryption

Transparent encryption is easier to deploy and its impact on the environment is more predictable, but it is less secure and flexible than employing encryption at the application layer. Given the choice, most people choose cheaper and less risky every time, but there are compelling arguments in favor of application layer encryption:

  • Web Applications: These often use multiple storage media, for relational and non-relational data. Encryption at the application layer allows data storage in files or databases – even to different databases and file types simultaneously. And it’s just as easy to embed encryption in new applications as it is to implement TDE.
  • Access Control: Per our discussion in Supporting Systems earlier, application layer encryption offers a much better opportunity to control access to PAN data because it inherently de-couples user privileges from encryption keys. The application can require additional credentials (for both user and service accounts) to access credit card information; this provides greater control over access and reduces susceptibility to account hijacking.
  • Masking: The PCI specification requires masking PAN data displayed to those who are not authorized to see the raw data. Application layer encryption better at determining who is properly authorized, and also better at performing the masking itself. Most commercial masking technologies use a method called ‘ETL’ which replaces PAN data in the database, and is complicates secure storage of the original PAN data. View-based masks in the database require an unencrypted copy of the PAN data, meaning the data is accessible to DBAs.
  • Security in General: Application layer encryption provides better security: there are fewer places where the data is unencrypted, fewer administrative access points, better access controls, more contextual information to determine misuse, and one less possible platform (the database) to exploit. Application layer encryption allows multiple keys to be used in parallel. While both solutions are subject to many of the same attacks, application layer encryption is more secure.

Deployment at the application layer used to be a nightmare: application interfaces to the cryptographic libraries required an intricate understanding of encryption, were very difficult to use, and required extensive code changes. Additionally, all the affected database tables required changes to accept the ciphertext. Today integration is much faster and less complex, with easy-to-use APIs, off-the-shelf integration with key managers, and development tools that integrate right into the development environment.

Comments on OS/File Encryption

For PCI compliance there few use cases where we recommend OS/file-level encryption, transparent or otherwise. In cases where a smaller merchant is performing a PCI self assessment, OS/file-level encryption offers considerable flexibility. Merchant can encrypt at either the file or database levels. Most small merchants buy off-the-shelf software and don’t make significant alterations, and their IT operations are very simple. Performance is as good as or better than other encryption options. Great care must be taken to ensure all relevant data is encrypted, but even with a small IT staff you can quickly deploy both encryption packages and key management services.

We don’t recommend OS/file-level encryption for Tier 1 and 2 merchants, or any large enterprise. It’s difficult to audit and ensure that encryption is being applied to all the appropriate documents, database files, and directories that contain sensitive information. Deployment and configuration is applied by the local administrator, making it nearly impossible to maintain separation of duties. And it is difficult to ensure encryption is consistently applied in virtual environments. For PCI, transparent database encryption offers most of the advantages with fewer possibilities for mistakes and mishaps.

Transparent encryption is also easiest to deploy. While integration is more complex and more time-consuming, the broader storage options can be leveraged to provide greater security. The decision will likely come down to your environment, and you’ll find that in order to meet some part of the PCI specification, you will likely need to choose one or the other, depending on your architecture.

—Adrian Lane

Have DLP Questions or Feedback? Want Free Answers?

By Rich

Back when I started Securosis my first white paper was Understanding and Selecting a DLP Solution. It has been downloaded many thousands of times (about 400 times a month for the first couple years), and I still see it showing up all the time when I talk with clients. (Some people call it the DLP Bible, but if I said that it would be really pretentious). Although the paper is still accurate, it’s time for an update.

Over the next month I’ll be putting together the new revision of the paper and I want to make sure it reflects what you all need.

My plans right now are to:

  1. Update the technology details. While there haven’t been any major shifts, we’ve definitely seen some useful new features and functions to consider when looking for a tool.
  2. Update the section on DLP as a Feature. The current paper focuses almost completely on full-suite solutions. While that’s still the option I usually recommend, I know some of you are only looking for coverage in a particular area. I plan to add a new section so you understand how the single channel or DLP features of other security tools work.
  3. Updated selection process. This is where I plan on putting most of myt effort… I’ll be creating a decision tree to help you prioritize your process. This section will also be released as a worksheet you can use during your selection process. It won’t name solutions, but will walk you through, and help you figure out your priorities and how those translate to technology decisions.
  4. Prettier pictures.

But these are just my early ideas. If you have anything specific you want covered, feedback on the first version of the paper, or any other feedback on DLP, please let me know. You can drop it in the comments here or email me directly at rmogull@securosis.com.

Also, although I’ll still follow our Totally Transparent Research process, it doesn’t make sense to post copy edits and tweaks as blog posts. I’ll post new sections and some major edits, but you’ll have to read the paper for the rest.

—Rich

NSO Quant: Take the Survey and Win an iPad

By Mike Rothman

One of the coolest things about how we do research at Securosis is the inclusiveness of our findings. We always post our work to the blog first and let the community have at it. In many cases it gets poked and prodded, ridiculed, and broken down. It’s certainly a hard process for the ego, but in the end makes the work better.

So we are now asking for more help as we get into the final phase of our Network Security Operations Quant research. We have already posted the high level process maps and broken those into subprocesses for each of the major areas (Monitoring, Manage Firewall, and Manage IDS/IPS). Now it’s time for validation, and that means we need your help.

We are kicking off our NSO Quant survey. As with most of our surveys, we’ve set this up so you can take it anonymously, and all the raw results (anonymized, in spreadsheet format) will be released after our analysis.

This survey is a bit different in that we are really focused on the processes you take to perform these activities, and a bit on the metrics you use to determine success and improve operationally. We also ask a bit about organizational responsibilities and outsourcing.

Click here to take the survey, and please spread the word. This is a pretty wide-ranging research initiative, so the survey is fairly detailed. We hope you can get through it in 20 minutes or so.

Since we understand filling out surveys is a pain in the behind, we want to provide a bit of incentive, so we’ll give a 32gb WiFi iPad to a random participant. You don’t need to provide an email address to take the survey, but you do if you want the iPad. If we get a lot of recipients (let’s say over 200) we’ll cough up for more iPads, so the odds stay better than the lottery.

We are tracking where we get our responses from, so if you take the survey in response to this post, please use “Securosis Blog.” If you re-post the link, you can make up your own code and email it to us. We’ll let you know how many people responded to your referral. If there is sufficient response, we’ll be happy to give you a custom slice of the data.

Thanks again for your help. We’ll keep the survey open at least 2 weeks, and then we’ll begin analysis.

—Mike Rothman

Security Briefing: August 30th

By Liquidmatrix

newspapera.jpg

Interesting security news afoot this Monday morning. I was especially intrigued with the article about breaking quantum crypto which leads off the briefing this morning.

cheers,
Dave

Click here to subscribe to Liquidmatrix Security Digest!.

And now, the news…

  1. Hackers blind quantum cryptographers | Nature.com
  2. Detective fined £4,000 for disclosing police data | BBC
  3. Hackers attack Philippine government website | AFP
  4. Building Society Laptop Stolen Along With Passwords | eWeek Europe
  5. City hosting state’s first hacker confab | Charleston Daily Mail
  6. India BlackBerry ban averted for 60 more days | Miami Herald
  7. New 64-Bit Windows Rootkit Already ‘In The Wild’ | eSecurity Planet
  8. MI5 Called In On MI6 Spy Riddle | Express.co.uk

—Liquidmatrix

Security Briefing: August 30th

By Liquidmatrix

newspapera.jpg

Interesting security news afoot this Monday morning. I was especially intrigued with the article about breaking quantum crypto which leads off the briefing this morning.

cheers,
Dave

Click here to subscribe to Liquidmatrix Security Digest!.

And now, the news…

  1. Hackers blind quantum cryptographers | Nature.com
  2. Detective fined £4,000 for disclosing police data | BBC
  3. Hackers attack Philippine government website | AFP
  4. Building Society Laptop Stolen Along With Passwords | eWeek Europe
  5. City hosting state’s first hacker confab | Charleston Daily Mail
  6. India BlackBerry ban averted for 60 more days | Miami Herald
  7. New 64-Bit Windows Rootkit Already ‘In The Wild’ | eSecurity Planet
  8. MI5 Called In On MI6 Spy Riddle | Express.co.uk

—Liquidmatrix

Friday, August 27, 2010

Home Security Alarm Tips

By Rich

This is one of those posts I’ve been thinking about writing for a while – ever since I saw one of those dumb-ass ADT commercials with the guy with the black knit cap breaking in through the front door while some ‘helpless’ woman was in the kitchen.

I’m definitely no home-alarm security expert, but being a geek I really dug into the design and technology when I purchased systems for the two homes I’ve lived in here in Phoenix. We’re in a nice area, but home break-ins are a bit more common here than in Boulder. In one home I added an aftermarket system, and in the other we had it wired as the house was built. Here are some things to keep in mind:

  • If you purchase an aftermarket system it will almost always be wireless, unless you want to rip your walls open. These systems can be attacked via timing and jamming, but most people don’t need to worry about that.
  • With a wireless system you have a visible box on each door and window covered. An attacker can almost always see these, so make sure you don’t skip any.
  • Standard door and window sensors are magnetic contact closure sensors. They only trigger if the magnet and the sensor are separated, which means they won’t detect the bad guy breaking the glass if the sensor doesn’t separate. You know, like they show in all those commercials (for the record I use ADT).
  • The same is true for wired sensors, except they aren’t as visible.
  • Unless you pay extra, all systems use your existing phone line with a special “capture” port that overrides other calls when the alarm needs it. For (possibly a lot) more you can get a dedicated cell phone line integrated into the alarm, so the call center still gets the alarm even if the phone lines are down. You probably want to make sure they aren’t on AT&T.
  • Most of the cheap alarm deals only give you a certain number of contact closure sensors and one “pet immune” motion sensor (placed centrally to trigger when someone walks down your major connecting hallway). Pay more to get all your first floor doors and windows covered. Get used to the ugly white boxes on everything.
  • Most alarm systems do not cover your exterior garage doors. The standard install protocol is to put a sensor on the door from your garage to the interior of the house. The only time we’ve been robbed is when we left our garage doors open, so since then we’ve always had them added to the system. They take a special contact closure sensor since the normal ones aren’t good with the standard rattling of a garage door and will trigger with the wind. Now every night when we set our alarm in “Stay” mode it won’t enable unless the doors are closed.
  • None of the basic systems includes a glass break detector. Most of these are noise sensors tuned to the frequency of glass breaking, rather than shatter sensors attached to each window. I highly suggest these and recommend you put them near the windows most likely to be broken into (ones hard to see from the street). Mine has only gone off once, when I dropped something down the stairs.
  • Understand which sensors are active in the two primary alarm modes – Stay and Away. Stay is the mode you use at night when you are sleeping (or if you are a helpless female in the kitchen in an ADT commercial). It usually arms the exterior sensors but not the motion sensor. Away is when you are out and turns on everything. I suggest having glass breaks active in Stay mode, but if you have a killer stereo/surround sound system that might not work out too well for you. There are also differences in arming times and disarming windows (the time from opening a door to entering your code).
  • When your alarm triggers it starts a call to the call center, who will call you back and then call the police. I’ve had my alarm going for a good 30 seconds without the outbound call hitting the alarm center. It isn’t like TV, and the cops won’t be showing up right away.
  • Most basic systems don’t cover the second story in a multilevel home. While few bad guys will use a ladder, know your home and if there are areas they can climb to easily using trees, gutters, etc. – such as windows over a low roof. Make sure you alarm these. Especially if you have daughters and want some control over their dating lives.
  • Most systems come with key fob remotes, so you don’t have to mess with the panel when you are going in and out. If you’re one of those people who parks in your driveway and leaves your garage and alarm remotes in the car, please send me your address and a list of your valuables. Extra points if you’re a Foursquare user.
  • Most alarms don’t come with a smoke detector, which is one of the most valuable components of the system. You regular detectors aren’t wired into an alarm sensor and are just to wake you up. Since we have pets, and mostly like them, we have a smoke detector in a central location as part of our alarm so the fire department will show up even if we aren’t around. We also have a residential sprinkler system, and as a former firefighter those things are FTW (no known deaths due to fire when one is installed and operational).

My alarm guys looked at me funny when I designed the system since it included extras they normally skip (garage doors, glass break, second story coverage, smoke detector). But we have a system that didn’t cost much more than the usual cheap ones, and provides much better protection. It’s also more useful, especially with the garage sensors to help make sure we don’t leave the doors open.

The one thing I’m not really big on is cameras. For my home I worry a lot more about someone getting in than capturing them after the fact. And we live in a densely populated subdivision with neighbors we know well and inform before we leave on big trips. That and an alarm sign out front are better than any crazy camera system.

Finally, make sure you test the system from time to time. It’s possible to mess up your phone connection or for the monitoring center to lose track of your account. If something does go wrong beat them like dogs – your safety is at risk. If you are paying $20+ per month for monitoring, they really should monitor.

—Rich

Data Encryption for PCI 101: Supporting Systems

By Adrian Lane

Continuing our series on PCI Encryption basics, we delve into the supporting systems that make encryption work. Key management and access controls are important building blocks, and subject to audit to ensure compliance with the Data Security Standard.

Key Management

Key management considerations for PCI are pretty much the same as for any secure deployment: you need to protect encryption keys from unauthorized physical and logical access. And to the extent it’s possible, prevent misuse. Those are the basics things you really need to get right so they are our focus here. As per our introduction, we will avoid talking about ISO specifications, key bit lengths, key generation, and distribution requirements, because quite frankly you should not care. More precisely you should not need to care because you pay commercial vendors to get these details right. Since PCI is what drives their sales most of their products have evolved to meet PCI requirements.

What you want to consider is how the key management system fits within your organization and works with your systems. There are three basic deployment models for key management services; external software, external hardware or HSM, and embedded within the application or database.

  • External Hardware: Commonly called Hardware Security Modules, or HSMs, these devices provide extraordinary physical security, and most are custom-designed to provide strong logical security as well. Most have undergone rigorous certifications, the details of which the vendors are happy to share with you because they take a lot of time and money to pass. HSMs offer very good performance and take care of key synchronization and distribution automatically. The downside is cost – this is by far the most expensive key management option. And for disaster recovery planning and failover, you’re not just buying one of these devices, but several. They don’t work as well with virtual environments as software. We have received a handful of customer complaints that the APIs were difficult to use when integrating with custom applications, but this concern is mitigated by the fact that many off-the-shelf applications and database vendors provide the integration glue.
  • External Software: The most common option is software-based key management. These products are typically bundled with encryption software but there are some standalone products as well. The advantages are reduced cost, compatibility with most commercial operating systems, and good performance in virtual environments. Most offer the same functions as their HSM counterparts, and will perform and scale provided you provide the platform resources they depend on. The downside is that these services are easier to compromise, both physically and logically. They benefit from being deployed on dedicated systems, and you must ensure that their platforms are fully secured.
  • Embedded: Some key management offerings are embedded within application platforms – try to avoid these. For years database vendors offer database encryption but left the keys in the database. That means not only the DBAs had access to the keys, so did any attacker who successfuly executed an injection attack, buffer overflow, or password guess. Some legacy applications still rely on internal keys and they may be expensive to change, but you must in order to achieve compliance. If you are using database encryption or any kind of transparent encryption, make sure the keys are externally managed. This way it is possible to enforce separation of duties, provide adequate logical security, and make it easier to detect misuse.

By design all external key management servers have the capacity to provide central key services, meaning all applications go to the same place to get keys. The PCI specification calls for limiting the number of places keys are stored to reduce exposure. You will need to find a comfortable middle ground that works for you. Too few key servers cause performance bottlenecks and poor failover response. Too many cause key synchronization issues, increased cost, and increased potential for exposure.

Over and above that, the key management service you select needs must provide several other features to comply with PCI:

  • Dual Control: To provide administrative separation of duties, master keys are not known by any one person; instead two or three people each possess a fragment of the key. No single administrator has the key, so some key operations require multiple administrators to participate. This deters fraud and reduces the chance of accidental disclosure. Your vendor should offer this feature.
  • Re-Keying: Sometimes called key substitution, this is a method for swapping keys in case a key might be compromised. In case a key is no longer trusted, all associated data should be re-encrypted, and the key management system should have this facility built in to discover, decrypt, and re-encrypt. The PCI specification recommends key rotation once a year.
  • Key Identification: There are two considerations here. If keys are rotated, the key management system must have some method to identify which key was used. Many systems – both PCI-specific and general-purpose – employ key rotation on a regular basis, so they provide a means to identify which keys were used. Further, PCI requires that key management systems detect key substitutions.

Each of these features needs to be present, and you will need to verify that they perform to your expectations during an evaluation, but these criteria are secondary.

Access Control

Key management protects keys, but access control determines who gets to use them. The focus here is how best to deploy access control to support key management. There are a couple points of guidance in the PCI specification concerning the use of decryption keys and access control settings that frame the relevant discussion points:

First, the specification advises against using local OS user accounts for determining who can have logical access to encrypted data when using disk encryption. This recommendation is in contrast to using “file – or column-level database encryption”, meaning it’s not a requirement for those encrypting database contents. This is nonsense. In reality you should eschew local operating system access controls for both database and disk encryption. Both suffer from the same security issues including potential discrepancies in configuration, so local administrative roles should not be considered equivalent to domain administrative roles. Use domain access controls for both.

Section 3.4.1 of the specification is where most people get confused. The assertion that “Decryption keys must not be tied to user accounts” leaves a lot of room for interpretation, but if you carefully consider this statement it actually cuts to the heart of the matter. Some interpret this as meaning keys should not be tied to a single user account, but rather a service account specifically configured for sensitive data access. Most merchants regard this statement as nothing more than a redundant way of saying you need to set domain level access controls, placing the assertion in context with the rest of Section 3.4. Still others feel this demands a separation of identity management and authorization, meaning the right to decrypt data is not equivalent to possessing account credentials.

We recommend you comply with all three interpretations:

  • Service Account: Use a service account that requires additional credentials over and above what normal users provide. Using a service account is much easier for account management, and has the added benefit that auditing chores are easier when you can focus on a single account.
  • Domain-Level Identity Management: You need to use domain level credentials to avoid attacks predicated on misconfigured servers or inappropriate rights bestowed on a local administrator.
  • Verify Authorization: Above what’s provided by access control, verify authorization rights that take into account proper use policies. For example, while domain access controls like Active Directory and LDAP services may be used, applications and databases typically maintain authorization rights internally. They do not inherit rights from the domain – only identity. Databases provide extensive facilities to map authorization rights. Similarly, implementing encryption at the application layer has the inherent benefit of gating access based upon business context: data is decrypted only when it makes sense in the context of the function being performed. This is a great way to detect misuse!

Auditing and Verification

Any system you choose should provide audit logs of all administrative activity, failed logins, and system failure. If you are a Tier One merchant you are required to provide your auditor with not only these logs, but with specific reports on system setup as well. Your vendor should be able to provide the necessary reports for checking configuration, reviewing administrative access history, listing approved administrators, detailing system failures, and any other pertinent security information. They should provide documentation that discusses key management processes, as well as reports from third party analysis or security certifications. These reports, and the means to collect the audit data to populate them, should be built into the product.

—Adrian Lane

Friday Summary: August 27, 2010

By Rich

My original plan for this week’s summary was to geek out a bit and talk about my home automation setup. Including the time I recently discovered that even household electrical is powerful enough to arc weld your wire strippers if you aren’t too careful.

Then I read some stuff.

Some really bad stuff.

First up was an article in USA Today that I won’t even dignify with a link. It was on the iTunes account phishing that’s been going on, and it was pretty poorly written. Here’s a hint – if you are reading an article about a security issue and all the quotes are from a particular category of vendor, and the conclusion is to buy products made by those vendors, it’s okay to be a little skeptical. This is the second time in the past couple weeks I’ve read something by that author that suffered from the same problem. Vendor folk make fine sources – I have plenty of friends and contacts in different security companies who help me out when I need it, but the job of a journalist is to filter and balance. At least it used to be.

Next up are the multitude of stories on the US Department of Defense getting infected in 2008 via USB drives. Notice I didn’t say “attacked”, because despite all the stories surfacing today it seems that this may not have been a deliberate act by a foreign power. The malware involved was pretty standard stuff – there is no need to attribute it to espionage. Now look, I don’t have any insider knowledge and maybe it was one of those cute Russian spies we deported, but this isn’t the first time we’ve seen government related stories coming from sources that might – just might – be seeking increased budget or authority.

I’m really tired of a lazy press that single-sources stories and fails to actually research the issues. I know the pressure is nasty in today’s newsrooms, but there has to be a line someplace.

I write for a living myself, and have some close friends in the trade press I respect a heck of a lot, so I know it’s possible to hit deadlines without sacrificing quality.

But then you don’t get to put “Apple” in the title of every article to increase your page count.

On another note it seems my wife is supposed to have a baby today… or sometime in the next week or two. Some of you may have noticed my posting rate is down and I’ll be in paternity leave mode.

On to the Summary:

Webcasts, Podcasts, Outside Writing, and Conferences

Favorite Securosis Posts

Other Securosis Posts

Favorite Outside Posts

Project Quant Posts

Research Reports and Presentations

Top News and Posts

Blog Comment of the Week

Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. This week’s best comment goes to Jay, in response to Backtalk Doublespeak on Encryption.

I don’t want to give this article too much attention, too much FUD, too few facts, but I thought this was worth a quote:

“…the bad guys do not attack encrypted data directly…”

which is followed up with: “When you encrypt a small field with a limited number of possible values, like the expiry date, you risk giving a determined (and sophisticated) attacker a potential route to compromising your entire cardholder database.” … by attacking the encrypted data directly?

The other point I had was that there are 1 of 2 ways to create the same output given the same input (in “strong” symmetric ciphers), use ECB mode or re-use the same initialization vector (IV) over and over. I think most financial places lean towards the former because managing/transferring the IV is more overhead.

The problem isn’t so much the deterministic output, but that ECB mode allows patterns in the plaintext to be transferred into the cipher text. Wikipedia has a visual on this at http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation

—Rich

Thursday, August 26, 2010

White Paper Released: Understand and Selecting SIEM/Log Management

By Mike Rothman

In this report we spotlight both the grim realities and real benefits of SIEM/Log Management platforms. The vendors are certainly not going to tell you about the bad stuff in their products – they just shout out the same fantastic advantages touted in the latest quadrant report. Trust us when we say there are many pissed-off SIEM users, but plenty of happy ones as well. We focused this paper on resetting expectations and making sure you know enough to focus on success, which will save you much heartburn later.

This fairly comprehensive paper delves into the use cases for the technology, the technology itself, how to deploy it, and ultimately how to select it. We assembled this paper from the Understand and Selecting a SIEM/Log Management blog series from June and July 2010.

Special thanks to Nitro Security for sponsoring the research.

You can download the paper (PDF) directly or visit the landing page.

—Mike Rothman

Wednesday, August 25, 2010

Starting the Understanding and Selecting an Enterprise Firewall Project

By Mike Rothman

I joined Securosis back in January and took on coverage of network and endpoint security. My goal this year was to lay the foundation by doing fairly in-depth research projects on the key fundamental areas in each patch. I started with Endpoint Security Fundamentals (I’m doing some webcasts next month) and continued with the Network Security Operations Quant project (which I’m now working through) to focus on the processes to manage network security devices. But clearly selecting the anchor device in the perimeter – the firewall – demands a full and detailed analysis.

So next week I’ll start a series on “Understanding and Selecting an Enterprise Firewall.” As always, we’ll use the Totally Transparent Research process, which means everything will be posted to the blog and only after taking a round of feedback will we package the content as a paper.

In preparation for the series I’m (as always) looking for more data points on what’s changing on the perimeter, specifically for the enterprise firewall. Are you looking at updating/re-architecting your firewall implementation? Happy with the incumbent? Looking to add more capabilities, such as UTM-like functions? Do you give a crap about all this application visibility hype? How do you manage 15-200 devices? I only need 15-20 minutes and any help is much appreciated. If you have opinions send me email: mrothman (at) securosis (dot) com and we’ll schedule some time to talk.

—Mike Rothman

Security Briefing: August 25th

By Liquidmatrix

newspapera.jpg

In the news today we see more churn on the cloud security front as well as new guidance from VISA on securing payment applications. Also, there are new security patches available from Apple and Adobe. Make it a great day everyone.

cheers,
Dave

Click here to subscribe to Liquidmatrix Security Digest!.

And now, the news…

  1. Defense official discloses cyberattack | The Washington Post
  2. Visa offers new guidance on securing payment applications | Computer World
  3. WikiLeaks Plans to Release CIA Paper Later Today | Mashable
  4. Verizon cloud first to clear credit card test, targets payments segment now | International Business Times
  5. Apple Releases Security Update 2010-005 | PC World
  6. Adobe patch 18 critical holes in Shockwave Player | The H Security
  7. A proposed federal data security law… one more time! | Wisconsin Technology Network
  8. Novell Touts Access Security for the Cloud | Internet News
  9. Fraudsters Drain PayPal Accounts Through iTunes | Tech Crunch
  10. U.S. denies WikiLeaks claim | Detroit Free Press
  11. LANDesk to be acquired by private equity firm | Infosecurity Magazine

—Liquidmatrix

Security Briefing: August 25th

By Liquidmatrix

newspapera.jpg

In the news today we see more churn on the cloud security front as well as new guidance from VISA on securing payment applications. Also, there are new security patches available from Apple and Adobe. Make it a great day everyone.

cheers,
Dave

Click here to subscribe to Liquidmatrix Security Digest!.

And now, the news…

  1. Defense official discloses cyberattack | The Washington Post
  2. Visa offers new guidance on securing payment applications | Computer World
  3. WikiLeaks Plans to Release CIA Paper Later Today | Mashable
  4. Verizon cloud first to clear credit card test, targets payments segment now | International Business Times
  5. Apple Releases Security Update 2010-005 | PC World
  6. Adobe patch 18 critical holes in Shockwave Player | The H Security
  7. A proposed federal data security law… one more time! | Wisconsin Technology Network
  8. Novell Touts Access Security for the Cloud | Internet News
  9. Fraudsters Drain PayPal Accounts Through iTunes | Tech Crunch
  10. U.S. denies WikiLeaks claim | Detroit Free Press
  11. LANDesk to be acquired by private equity firm | Infosecurity Magazine

—Liquidmatrix