Securosis: On Holiday

By Adrian, Rich

As it's the middle of summer, it's freakin' hot here. Rich and I have been cranking away like crazy since RSA on a couple different projects and are in need of a break. Now it's time for a little R&R, so like you, we going on a mini summer break. That means no Friday Summary this week. We'll be back around the 7th, and return to normal Friday posts on the 10th. Until then, enjoy yourself over the July 4th holiday (even if you're not in the U.S.)! If you haven't yet taken the Project Quant survey, go ahead and stop by SurveyMonkey on your way out for the long weekend.

–Adrian, Rich

Database Security: The Other First Steps

By Adrian

Going through my feed reader this morning when I ran across this post on Dark Reading about Your First Three Steps for database security. As these are supposed to be your first steps with database security,
the suggestions not only struck me as places I would not start, it offered a method that I would not employ. I believe that there there is a better way to proceed, so I offer you my alternative set of recommendations.

The biggest issue I had with the article was not that these steps did not improve security, or that the tools were not right for the job, but the path you are taken down by performing these steps are the wrong ones. Theoretically its a good idea to understand the scope of the database security challenge when starting, but infeasible in practice. Databases are large, complex applications, and starting with a grand plan on how to deal with all of them is a great way to grind the process to a halt and require multiple restarts when your plan beaks apart. This article advises you start your process by cataloging every single database instance, and then try to catalog all of the sensitive data in those databases. This is the security equivalent to a 'cartesian product' with a database select statement. And just as it is with database queries, it results in an enormous, unwieldy amount of data. You can labor through the result and determine what to protect, but not how.

At Securosis, we're all about simplifying security, I am a personal advocate of the 'divide and conquer' methodology. Start small. Pick the one or two critical databases in your organization, and start there. Your database administrator knows which database is the critical one. Heck, even your CFO knows which one that is: it's that giant SAP/Oracle one in the corner that he is still pissed off he had to sign the $10 million dollar requisition for.

Now, here are the basics steps:

• Patch your databases to address most known security issues. Highly recommended you test the patch prior to operational deployment.
• Configuring your database. Consult the vendor recommendations on security. You will need to balance these suggestions with operational consistency (i.e. don't break you applications). There are also third party security practitioners who offer advice on their blogs for free, and free assessment tools that will help a lot.
• Get rid of the default passwords, remove unneeded user accounts, and make sure that nothing (users, web connections, stored procedures, modules, etc) is available to the 'public'.

Consider this an education exercise to provide base understanding of what needs to be addressed and how best to proceed. At this point you should be ready to a) you can document what exactly your 'corporate configuration policies' are and b) develop a tiered plan of action to tackle databases in descending order of priority. Keep in mind that these are just a fraction of the preventative security controls you might employ, and does not address active security measures or forensic analysis. You are still a ways off from employing more intermediate and advanced security stuff ... like Database Activity Monitoring, auditing and Data Loss Prevention.

–Adrian

Three Database Roles: Programmer, DBA, Architect

By Adrian

When I interview database candidates, I want to asses their skills in three different areas; how well they can set-up and maintain a database, how well they can program to a database, and how well they can design database systems. These coincide with the three roles I would typically hire: database administrator, database programmer and database architect. Even though I am hiring for just one of these roles, and I don't expect any single candidate to be fully proficient in all three areas, I do want to understand the breadth of their exposure. It is an indicator of how much empathy they will have for their team members when working on database projects, and understand the sometimes competing challenges each faces. While there will always be some overlap, the divisions of responsibility are broken down as follows

• Database administrator - Installs, configures, manages the database installation. This will include access control, provisioning and patch management. Typically provide analysis into resource usage and performance.
• Database architect - Selects and designs the platforms, and designs or approves schema. It's the architect's responsibility to understand how data is used, processed and stored within the database. They typically select which database platform is appropriate, and will make judgment calls whether or not to use partitioning, replication, and other advanced features to support database applications.
• Database programmer - Responsible for coding the queries and use of the database infrastructure. Selection of data types and table design, and assists with

We talk a lot about database security on this blog, but we should probably spend more time talking about the people who affect database security. In my experience database programmers are the least knowledgeable about the database, but have the greatest impact on database security and performance. I have been seeing a disturbing trend of development teams, especially web application programmers, who perform every function in the application and regard the database as a bucket where they dump stuff to save application state. This is reflected in the common choice of smaller, lighter databases that provide less functionality, and the use of abstraction techniques that clean up the object model but lose native functions that benefit performance, data integrity and security. Worse, they really don't care the details of how it works as long as their database connection driver is reasonably reliable and the queries are easy to write.

Why this is important, especially as it pertains to database security, is that you need to view security from these three perspectives and leverage these other practitioner skills within the organization. And if you have the luxury of being able to afford to employ all of these three disciplines, then by all means, have them cooperate in development, deployment and maintenance of database security. You architect is going to know where the critical data is and how it is moved through the system. Your DBA is going to understand how the databases are configured and what operations would be best moved into the database. If you are not already doing it, I highly recommend that you have your DBA's and Architects do a sanity check on developer schema designs, review any application code that uses the database, and provide support to the development in team access control planning and data processing. It's hard to willingly submit code for review, but better fix it prior to deployment than after.

–Adrian

Cracking a 200 Year Old Cipher

By Adrian

I have a half dozen books on Thomas Jefferson's life, but this is a pretty cool story I had never heard before. The Wall Street Journal this morning has a story about a Professor Robert Patterson, who had developed what appears to be a reasonably advanced cipher, and sent an enciphered message to President Jefferson in 1801. He provided Jefferson with the the message, the cipher, and hints as to how it worked, but it is assumed that Jefferson was never able to decrypt the message. The message was only recently decrypted by Dr. Lawren Smithline, a 36-year-old mathematician who works at the Center for Communications Research in Princeton, N.J., a division of the Institute for Defense Analyses.

The key to the code consisted of a series of two-digit pairs. The first digit indicated the line number within a section, while the second was the number of letters added to the beginning of that row. For instance, if the key was 58, 71, 33, that meant that Mr. Patterson moved row five to the first line of a section and added eight random letters; then moved row seven to the second line and added one letter, and then moved row three to the third line and added three random letters. Mr. Patterson estimated that the potential combinations to solve the puzzle was "upwards of ninety millions of millions."

After about a week of working on the puzzle, the numerical key to Mr. Patterson's cipher emerged -- 13, 34, 57, 65, 22, 78, 49. Using that digital key, he was able to unfurl the cipher's text: "In Congress, July Fourth, one thousand seven hundred and seventy six. A declaration by the Representatives of the United States of America in Congress assembled. When in the course of human events..."

I am not sure why I am fascinated by this discovery. Perhaps it's a bit like discovering hidden treasure.

–Adrian

Database Encryption, Part 5: Key Management

By Adrian

This is Part 5 of our Database Encryption Series. Part 1, Part 2, Part 3, Part 4, and the supporting posts on Database vs. Application Encryption, & Database Encryption: Fact or Fiction are online.

I think key management scares people.

Application developers, IT managers, and database administrators all know effective key management support for encryption is critical, but it remains scary for most practitioners. Despite the incredible mathematical complexity behind the ciphers and the finesse required to implement those ciphers in a secure fashion, they don't have to understand the gears and cogs inside the machine. Encryption is provided as libraries or fully functional services, so you send out clear text, and you get back encrypted data -- easy. Key management worries people because if you don't get the key management piece right, the whole system fails, and you are the responsible party. To illustrate what I mean, I want to share a couple stories about developers and IT practitioners who manage these systems.

Building database applications from scratch, developers have access to good crypto libraries, but generally little understanding of key management practices and few key management resources. The application developers I know took great pride in securing database fields through encryption, but when I asked them how they stored the key, the answer was usually "in the properties file". That meant the key was stored on the disk, unencrypted, and in a directory readable by anyone who could access the application. When I pressed the point, I was assured that the key 'needed' to be there, otherwise the application would not be able to get the key and thus fail to restart. I have even had developers tell me this is a "chicken vs. egg" conundrum, that if you encrypt the key you cannot access it, therefore a key needed to be kept in clear text somewhere. I kid you not, with my last employer (who, by the way, developed security products), this was the reason the 'senior' programmer implemented key management this way, and why he didn't see a problem with it. The argument always ends the same: a key as a tangible object is fine, but obfuscated and hidden is not. The unspoken reason is something every programmer knows: code has bugs, and a key management bug could be devastating and unrecoverable.

On the IT side, administrators I know have a different, equally frightening, set of problems with key management. Every IT manager I have spoken with has one or more of these questions: What happens if/when I lose keys? How to I back keys up securely? How do I replicate keys across multiple key servers for redundancy? I have 1,000 users reliant on public key cryptography, so how do I share these keys for all these users? If I expire and rotate keys, do I lose access to data archives? If I try to recover data from a tape, how do I get the right key? If I am using specialized key management hardware, how do I recover from fire or other disasters? All are risks in the minds of IT professionals every day.

Lose your key, lose your data. Lose your data, lose your job. And that scares the heck out of people!

Our goal in this section is to discuss key management options for database encryption. The introduction is meant to underscore the state of key management services today, and help illustrate why key management products are deployed the way they are. Yes, you can download excellent encryption tools for free, you can mix and match best of breed features, and you can develop your own operational key management process that is application agnostic, but this approach is becoming a rarity. And that's a good thing because key management needs to performed by people who know what they are doing. Centralized, automated, embedded, pre-packaged and available as a complete service is the common choice. This removes the complexity and the responsibility of management, and much of the worry about reliability of your developers and IT administrators. Make no mistake, this trade-off comes at a price. Let's dig into some key management practices for databases and how they are used.

Internally Managed

For database encryption, we define "internal key management" as key services within the database and provided by the database vendor. All of the relational database management platforms provide encryption packages, and included in these packages are key management functions. Typical services include key creation, storage, and retrieval, security; and most systems can handle symmetric and public key encryption options. Usage of the keys can be handled by proxy, as with the transparent encryption options, or through direct API calls to the database package. The keys are stored within the database, usually within a special table that resides in the administrative database or schema. Each vendor's approach to securing keys varies significantly. Some vendors rely upon simple access controls tied to administrative accounts, some encrypt individuals' keys with a single master key, while others do not allow any access to keys at all, and perform all key functions within a proxied service.

If you are using transparent encryption options (see Part 2: Selection Process Overview for terminology definitions) provided by the database vendor, all key operations is performed on the users' behalf. For example, when a query for data within an encrypted column is made, the database performs the typical authorization checks, and when successfully authorized, automatically decrypts the data for the users. Neither the users nor the application need be aware the data is encrypted, needs to make a specific request to decrypt, or needs to supply a decryption key to the database. It is all handled on their behalf, and often performed without their knowledge.

Transparent key management's greatest asset is just that: its transparency. The storage, management, security, sharing, and backup of the keys is handled by the database. With internally managed encryption keys, there is not a lot for the application to do, or even care about, since all of the use and management of the keys is performed inside the database. The services runs autonomously and is turned on by simple alteration of database parameters, so the DBA need only worry about backing up the system, and running the occasional disaster recovery drill so they are no unexpected 'gotchas'. The database vendors have worked hard to perfect these operations and made them fast, efficient and reliable. As the functions are bundled with the core database by most vendors, and priced attractively. Finally this flavor has the flexibility to support API calls as well as transparent operation.

On the downside, these keys are typically only as secure as your least trustworthy DBA. In every platform that stores the keys in a database table, they will be accessible to database administrators. Despite vendor advertisements to the contrary, there are attacks that can sniff the key operations within the database, or even scan through database memory structures where the keys reside during use. When you boil it down, transparent encryption and associated internal key management is a very simple and cost effective way to secure data at rest, and not particularly effective at securing keys from database administrators.

Externally Managed

With external key management all key operations are performed outside the database in a dedicated key management server. External key management servers are either dedicated software or hardware appliances (aka Hardware Security Modules, or HSMs), and available through network or application procedure calls. Both provide a full range of functions including key creation, storage, and retrieval; they also support both for symmetric and public key cryptosystems. But they usually have a lot more to offer as well, with administrative support for access management, sharing keys across multiple key managers, and help with policies for key expiration/rotation. They provide additional advantages over internally managed keys in that the platform is dedicated to this function and provides faster cryptographic operations, they produce better results, and they store keys more securely than is possible within the database. They can perform the encryption and decryption operations on the users' behalf, outside the database, as well.

External key management can be used in two ways: by calling the key management server directly, or by having the database make the requests on behalf of users and applications. All relational database now have their own Cryptographic API support. By calling the database through an established database communication port, application developers get external key management services within the same 'database' connection. These API calls are performed in the same context and in the same programmatic language as other database queries. This approach offers the security advantage of enforcing separation of duties, keeping the encryption keys out of the hands of database administrators, and puts them into the hands of the application developers. It allows application developers to choose just how granular they want to get with data encryption, and provides a great deal of flexibility in access control enforcement and key usage. That approach still leverages the database itself to perform the encryption, and can still take advantage of database features to address many structural and systems management challenges.

The other external key management option is calling the key manager directly, and having it perform all of the cryptographic functions on your behalf. In this case you're outside the realm of database encryption and have moved to external, or application layer, encryption. By performing all encryption outside the database, leveraging none of the built in functions, the database becomes a simple repository for encrypted data. The advantages are that the database does not suffer the performance impact associated with encryption, the network latency of a database API call is not incurred, remote key storage enables separation of admin duties, and these facilities can be used across many different systems. It also means that all of the cryptographic operations are now the responsibility of the application developer, all user and key management must be performed within the application logic, and your database design must be altered to accommodate required changes.

External key management will pick up the key sharing, backup and other services that you lose by not using the database internals. Most customers we speak with now are opting for dedicated hardware to support key management operations. Performance is on advantage of HSMs, as hardware acceleration can generally handle encryption tasks an order of magnitude faster than their software routines on general-purpose (database) servers. Another is high-quality entropy to seed cryptographic ciphers. Additionally, sharing of keys across servers is well secured, and the APIs can be accessed by multiple applications. Finally, HSMs are well protected from physical tampering and electronic eavesdropping, making them the most secure key storage options discussed here.

That is not to say that dedicated software key management does not have its own advantages. Simplicity is major factor; as is support for multiple platforms, which provides some flexibility and conformity in hardware requisition and maintenance; the biggest advantage of dedicated software key management is the flexibility to run anywhere. Running on generic hardware helps to rapidly recover from disasters, and is far easier to use in virtual environments than hardware. Downsides are that the quality of the cryptography is dependent upon its supporting hardware for entropy, and that the keys are not as strongly secured as with dedicated devices.

Hardware based HSMs tend to be very expensive, compared to software (either DBMS features or software encryption applications). With any of these architectures, it's important to confirm that the key management functions you need are supported by the database and encryption APIs.

One final word about key management database APIs: Each database vendor supports the basic requirements, but not all available functions, so you need to verify what is available through the API is what you need.

In our next post we will discuss common use cases that customers are trying to solve, and how each variant addresses these problems.

–Adrian

Things To Do In Encryption When You’re Dead

By Rich

Technically the title should be Things to do With Encryption..., but then I wouldn't have a semi-obscure movie reference.

Cory Doctorow of BoingBoing linked to a column of his over at The Guardian entitled If I'm dead how will my loved ones break my password?. As a new father myself, I recently went through the estate planning process with my lawyer, and this is one issue I've long thought needed more attention. A few years ago I even considered building a startup around it.

Much of my important data is encrypted -- especially logins to bank accounts and such. Also, a fair bit of my other data is either encrypted, or protected in ways many of you fair readers could circumvent, but my family members can't. I also have a ton of "personal institutional knowledge" in my head -- everything from how to keep this blog running, to locations of family photos, to all the old email correspondence I kept when my wife and I started dating. If I get hit by a truck (or, more likely, kill myself in some bizarrely stupid way right after saying, "okay, check this out"), all of that would either be lost to the ether, or complex to recover.

Heck, I have content that might be important to my family in applications in virtual machines on encrypted drives.

Part of my estate planning process is ensuring that not only do my family and business partners have access to this information if I'm not around, but that they'll know where the important bits are in the first place.

Unlike Cory I'm not concerned with using split keys in different countries to prevent exposure to the government, but I also don't think I'm as organized as he is in terms of where I keep everything.

Thus, as part of my estate planning, I'm looking at the best way to make this information available on the off chance my sense of self-preservation fails to mature. Here's the plan right now:

1. Compile my passphrases, locations of important information, and other documentation into a single repository. I'm considering using 1Password since it already has the logins to nearly everything, I use it daily, and it can export to an encrypted PDF or a few other formats. 1Password supports secure notes for random instructions and other documentation.
2. On a regular basis, I will export the information to an encrypted file which I'll provide to my lawyer, and store in a secure online repository. I have a lot of options for this, but for the rest of you it might be better to set up a Hotmail/Yahoo/Whatever email account you don't ever use for anything else, and send it there. You can then give your lawyer or executor access to that account (remember, the contents up there are still encrypted). This makes it easy to keep the information up to date, and it's protected from your lawyer's office burning down with your encrypted hard drive. It may be worth it to use two different services, just in case. Remember that if your lawyer doesn't have direct access, it may be difficult for him/her to legally obtain access after death.
3. I'll give my lawyer the locations of the information and the passphrase for my 1Password export in a sealed envelope. Since he's my brother in law, and might be with me when I accidentally blow up that propane tank, I'll make sure his partner also has a copy in a separate physical location.

That should cover it -- my information is still protected (assuming I trust my lawyer), and it includes logins, locations of important electronic documents, and so on. I'm in the middle of setting this up, and haven't even talked to my lawyer about the details yet, but it's as important as any other aspects of my trust.

A separate issue, and the other half of my vaporware startup, is what happens to all my correspondence/photos/movies after I die? Historically, the archives of individuals, handed down through generations, are an important part of the human record. This isn't just an ego thing -- letters and photos of regular folks are as important to historians over the ages. Right now, as a society, this isn't an issue we've really addressed.

–Rich

The Network Security Podcast, Episode 156

By Rich

Martin is off in Japan this week, so I’m joined by our good friend Amrit Williams from BigFix and the Techbuddha blog. Amrit and I start off by talking about the rolling blackouts in California and disaster preparedness, before jumping into the week’s security news.

Network Security Podcast, Episode 156
Time:  41:28

Show Notes:

• The New York Times and Wikipedia censor reports of a captured reporter to protect him.
• Dave Shackleford on 10 things your auditor doesn’t want you to know.
• Trojan steals FTP credentials
• Juniper pulls ATM hacking talk from Black Hat
• Most systems have unpatched software. Is anyone surprised?
• Tonight’s Music:  Since I haven’t figured out how to get the podcasting rights to Jimmy Buffett’s entire collection, there’s no music for tonight’s close.

–Rich

Creating a Standard for Data Breach Costs

By Rich

One thing that's really tweaked me over the years when evaluating data breaches is the complete lack of consistency in costs reporting. On one side we have reports and surveys coming up with "per record" costs, often without any transparency as to where the numbers came from. On the other side are those that try and look at lost share value, or directly reported losses from public companies in their financial statements, but I think we all know how inconsistent those numbers are as well.

Also, from what I can tell, in most of the "per record" surveys, the biggest chunk (by far) are fuzzy soft costs like "reputation damage". Not that there aren't any losses due to reputation damage, but I've never seen any sort of justified model that accurately measures those costs over time. Take TJX for example -- they grew sales after their breach.

So here's a modest proposal for how we could break out breach costs in a more consistent manner:

Per Incident (Hard Costs):

1. Incident investigation
2. Incident remediation/recovery
3. PR/media relations costs
4. Optional: Legal fees
5. Optional: Compliance violation penalties
6. Optional: Legal settlements

Per Record (Hard Costs):

1. Notification costs (list creation, printing, postal fees).
2. Optional: Customer response costs (help desk per-call costs).
3. Optional: Customer protection costs (fraud alerts, credit monitoring).

Per Incident

(Soft Costs... e.g., not always directly attributable to the incident): Trending is key here -- especially trends that predate the incident.

1. Customer Churn (% increase over trailing 6 month rate): 1 week, 1 month, 6 months, 12 months, n months.
2. Stock Hit (not sure of best metric here, maybe earnings per share): 1 week, 1 month, 6 months, 12 months, n months.
3. Revenue Impact (compared to trailing 12 months): 1 week, 1 month, 6 months, 12 months, n months.

I tried to break them out into hard and soft costs (hard being directly tied to the incident, soft being polluted by other factors). Also, I recognize that not every organization can measure every category for every incident.

Not that I expect everyone to magically adopt this for standard reporting, but until we transition to a mechanism like this we don't have any chance of really understanding breach costs.

–Rich

Mid-Project Update and Trip Report

By Rich

The week before last I headed up to Microsoft to present a mid-term report on Project Quant.

I was up there for the better part of two days, and mostly gave the attached presentation to internal teams so they had an idea of what we've been working on. It also allowed me to get some face-to-face feedback on the project. As much as I'm a virtual kind of guy, every now and then it's good to throw your ideas in front of a live audience.

In keeping with out transparent research process, here's a quick summary of some of the feedback I received:

• The model doesn't currently account for predictability or maintenance windows. (While Microsoft obviously is a bit invested in patch predictability, I don't consider this an MS-specific bias). I'm struggling to figure out how to incorporate this into the model with "hard" metrics, since downtime or disruption isn't always the easiest thing to measure until it happens. I suspect that's how we'll have to include it in the model, but am open to better ideas.
• The model doesn't currently account for extended-support programs where an end-user requests a specific patch from their vendor. A variety of vendors offer this for post-support and/or specialized products, and it's very common even in mid-sized organizations (depending on vertical).
• The model doesn't incorporate feedback to the vendor on patches -- e.g., for bad patches or improper documentation.
• There are other organizations we should look at contacting to get more community involvement (I lost my copy of the list, so can't post it here -- one was the Security Leader's LinkedIn group, which I am a member of -- I sent them a message to last week).
• The initial survey results are very interesting -- especially since it looks like some of the weakest areas of patching are aligned with the highest growth areas of attack (e.g., desktop applications).
• The model doesn't account for the costs of not patching. I think we will have to be very clear that that isn't the purpose of this model, and additional risk analysis is better suited for those costs. On the other hand, that opens up the model to be misused to state that patching provides no benefit. I'm open to ideas on this one, so long as they are hard metrics we can really measure. Perhaps I'm just not being creative enough.

Those were the major points (I wasn't keeping notes). Most of the discussion was around the survey results and the top level structure of the model.

Since that visit, we are at 76 survey responses and I've posted all of the detailed phases of the patch management process.

So if you are curious to see what I presented, take a look:

ProjectQuantUpdate.pdf

And don't forget to fill out the Open Patch Management Survey!

–Rich

Project Quant: Document and Update Configuration Changes

By Rich

In the age of compliance, the job isn't finished until it's fully documented. Okay, that's probably always been true, but you are talking to a guy who got a D in FORTRAN because, despite completing all my programming assignments, I sort of never documented them (50% of the grade).

There are two kinds of documentation in this phase:

• Documenting the successful patch deployment (that systems are patched and up to date).
• Documenting any configuration standard changes.

As with all the other phases, this is merely my first attempt and it could use feedback.

This also concludes all the detailed steps of the various phases of the patch management cycle. Our next step is to convert this into the metrics model, and I expect a fair bit may change in that process.

–Rich

Project Quant: Clean Up Phase

By Rich

We might need to adjust the name for this phase, since we also have "clean up" as part of the deploy phase, but I think it does a reasonable job of representing the issues around redeploying failed updates. This isn't just a time to push out failed updates again, but to figure out why an update failed and any changes required to achieve a successful patch. Back in my operational days this was one of the more frustrating aspects of patch deployment. Most of the time patching went fairly smoothly, but those exceptions could double the amount of time we spent getting any particular update out to the entire organization.

I'm also curious as to what failure rate people see in the reports from their patch management tools. As you'll see when I load up some of the preliminary survey results, most organizations confirm successful patch deployment based on reports from the patch management tool. But in my humble experience, not all tools are completely accurate in confirming a successful deployment -- actually, most have some sort of error rate. Without some additional tool, such as vulnerability management, this could lead to 'stealth' unpatched systems.

Anyway, more on that later, and here's my first stab at detailing out the clean up phase:

–Rich

Project Quant: Confirm Deployment Phase

By Rich

The goal in this phase is to determine that patches successfully deployed.

I suspect the variables will change a bit as we convert this one into the quantitative model. Based on the initial survey results, organizations use a ton of different techniques to confirm successful patch deployments, and any single organization uses various techniques for different platforms.

Notice that we are testing both successful deployment, and successful functioning of the patch. Again, I realize not all organizations consistently test for both, but we are trying to include all possible options in the model.

–Rich

Friday Summary: June 26, 2009

By Rich

Yesterday I had the opportunity to speak at a joint ISSA and ISACA event on cloud computing security down in Austin (for the record, when I travel I never expect it to be hotter AND more humid than Phoenix).

I'll avoid my snarky comments on the development and use of the term "cloud", since I think we are finally hitting a coherent consensus on what it means (thanks in large part to Chris Hoff). I've always thought the fundamental technologies now being lumped into the generic term are extremely important advances, but the marketing just kills me some days.

Since I flew in and out the same day, I missed a big chunk of the event before I hopped on stage to host a panel of cloud providers -- all of whom are also cloud consumers (mostly on the infrastructure side). One of the most fascinating conclusions of the panel was that if the data or application is critical, don't send it to a public cloud (private may be okay). Keep in mind, every one of these panelists sells external and/or public cloud services, and not a single one recommended sending something critical to the cloud (hopefully they're all still employed on Monday). By the end of a good Q&A session, we seemed to come to the following consensus, which aligns with a lot of the other work published on cloud computing security:

• In general, the cloud is immature. Internal virtualization and SaaS are higher on the maturity end, with PaaS and IaaS (especially public/external) on the bottom. This is consistent with what other groups, like the Cloud Security Alliance, have published.
• Treat external clouds like any other kind of outsourcing -- your SLAs and contracts are your first line of defense.
• Start with less-critical applications/uses to dip your toes in the water and learn the technologies.
• Everyone wants standards, especially for interoperability, but you'll be in the cloud long before the standards are standard. The market forces don't support independent development of standards, and you should expect standards-by-default to emerge from the larger vendors. If you can easily move from cloud to cloud it forces the providers to compete almost completely on price, so they'll be dragged in kicking and screaming. What you can expect is that once someone like Amazon becomes the de facto leader in a certain area, competitors will emulate their APIs to steal business, thus creating a standard of sorts.
• As much as we talk SLAs, a lot of users want some starting templates. Might be some opportunities for some open projects here.

I followed the panel with a presentation -- "Everything You Need to Know About Cloud Security in 30 Minutes or Less". Nothing Earth-shattering in it, but the attendees told me it was a good, practical summary for the day. It's no Hoff's Frogs, and is more at the tadpole level. I'll try and get it posted on Monday.

And one more time, in case you wanted to take the Project Quant survey and just have not had time: Stop what you are doing and hit the SurveyMonkey. We are over 70 responses, and will release the raw data when we hit 100.

-Rich

And now for the week in review:

Webcasts, Podcasts, Outside Writing, and Conferences

• Rich provides a quote on his use of AV for CSO magazine
• Rich & Martin on the Network Security Podcast #155.
• Rich hosted a panel and gave a talk at the Austin ISSA/ISACA meeting.
• Rich was quoted on database security over at Network Computing.

Favorite Securosis Posts

• Rich: Cyberskeptic: Cynicism vs. Skepticism. I've been addicted to The Skeptics' Guide to the Universe podcast for a while now, and am looking for more ways to apply scientific principles to the practice of security.
• Adrian: Rich's post on How I Use Social Media. I wish I could say I understood my own stance towards these media as well as Rich does. Appropriate use was the very subject Martin McKeay and I discussed one evening during RSA, and neither of us were totally comfortable for various reasons of privacy and paranoia. Good post!

Other Securosis Posts

• You Don't Own Yourself
• Database Patches, Ad Nauseum
• Mike Andrews Releases Free Web and Application Security Series
• SIEM, Today and Tomorrow
• Kindle and DRM Content
• Database Encryption: Fact vs. Fiction

Project Quant Posts

• Project Quant: Deploy Phase
• Project Quant: Create and Test Deployment Package
• Project Quant: Test and Approve Phase

Favorite Outside Posts

• Adrian: Adam's comment in The emergent chaos of fingerprinting at airports post: '... additional layers of "no" will expose conditions unimagined by their designers'. This statement describes most software and a great number of the processes I encounter. Brilliantly captured!
• Rich: Jack Daniel nails one of the biggest problems with security metrics. Remember, the answer is always 42-ish.

Top News and Posts

• TJX down another $9.75M in breach costs. Too bad they grew, like, a few billion dollars after the breach. I think they can pull $9.75M from the "need a penny/leave a penny" trays at the stores.
• Boaz talks about how Nevada mandates PCI -- even for non-credit-card data. I suppose it's a start, but we'll have to see the enforcement mechanism. Does this mean companies that collect private data, but not credit card data, have to use PCI assessors?
• The return of the all-powerful L0pht Heavy Industries.
• Microsoft releases a Beta of Morro- their free AV. I talked about this once before.
• Lori MacVittie on clickjacking protection using x-frame-options in Firefox. Once we put up something worth protecting, we'll have to enable that.
• German police totally freak out and clear off a street after finding a "nuke" made by two 6-year-olds.
• Critical Security Patch for Shockwave.
• Spam 'King' pleads guilty.
• Microsoft AntiVirus Beta Software was announced, and informally reviewed over at Digital Soapbox.
• Clear out of business, and they're selling all that biometric data.

Blog Comment of the Week

This week's best comment comes from Andrew in response to Science, Skepticism, and Security:

I'd love to see skepticism applied to the wide range of security controls that are proposed. Not that I believe they are wrong; but I suspect many don't really matter very much. If we can establish from evidence what controls have a significant impact, we can make much better use of our security budgets.

–Rich

You Don’t Own Yourself

By Rich

Gee, is anyone out there surprised by this?

Out of business, Clear may sell customer data.

Here's the thing -- when you share your information with a company -- any company, they view that information as one of their assets. As far as they are concerned, they own it, not you. This also includes any information any company can collect on you through legal means. Our laws (in the U.S. -- it isn't as bad in Europe and a few other regions) fully support this business model.

Think you are protected by a customer agreement or privacy policy? Odds are you aren't -- the vast majority are written carefully so the company can change them pretty much whenever they want. Amazon's done it, as have most major sites/organizations. If you don't have a signed contract saying you own your own data, you don't. This is especially true when companies go out of business -- one of the key assets sold to recoup investor losses is customer data.

In the case of Clear, this includes biometrics (fingerprint and iris scan) -- never mind all the financial data and the background checks they ran.

But don't worry; they'll only sell it to another registered traveler company. Trust them.

–Rich

Project Quant: Deploy Phase

By Rich

Yep, today is a Quant two-fer as we continue to roll through and detail out the model.

The deployment phase seems pretty straightforward -- you prep a target, deploy the patch to it, install the patch, then clean up the deployment package/patch/other detritus (we'll cover confirming deployment and cleaning up problems in the next two phases).

This is the phase where the degree of your automation will likely have the greatest impact. I tried to account for issues like bandwidth by adding in the time to distribute the patch/deployment package. One thing this isn't capturing yet is the downtime associated with installing a patch, and the impact of patching in or out of maintenance windows. I'm thinking that will figure in as a separate metric outside the phases of the cycle itself.

Again, please let me know how this fits with what you are doing out there. To be honest this is more in-depth than our processes back when I was responsible for patching, but I won't claim we were the most mature organization in the world.

–Rich