Research

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… and 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. Share:

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. Share:

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. Share:

A friend of mine emailed yesterday, admonishing me for not writing about the Digital Ants concept discussed on Dailytech. I think it’s because he wanted me to call B.S. on the story. It seems that some security researchers are trying to mimic the behavior of ants in computer defenses to thwart attackers. From the article: Security researchers found inspiration in the common ant. Describes Wake Forest University Professor of Computer Science Errin Fulp, “In nature, we know that ants defend against threats very successfully. They can ramp up their defense rapidly, and then resume routine behavior quickly after an intruder has been stopped. We were trying to achieve that same framework in a computer system.” WFU created digital “ants” – utilities that migrate from computer to computer over networks searching for threats. When one locates a threat, others congregate on it, using so-called “swarm intelligence”. The approach allows human researchers to quickly identify and quarantine dangerous files by watching the activity of the ants. This seems like nature’s reaction du jour. Many have written about the use of ‘helpful viruses’ and viral technologies (cheese worm (PDF), anti-porn worm, wifi worm, etc.) to combat hostile computer worms and viruses. Helpful virus code finds exploits the same way a harmful virus would, but then patches the defect – curing the system instead of reproducing. But the helpful viruses tend to become an attack vector of themselves, or ‘fix’ things in very unintended ways, compounding the problem. Ants behave very differently than viruses. Real ants fill a dual role, both gathering food and defending the hive. Besides access controls, few security products can make this claim. Second, ants can detect threats. Software and systems are only marginally effective at this, even with different pieces operating (hopefully) as a coordinated unit. Finally, ants bite. They have the ability to defend themselves individually, as well as work effectively as a group. In either case they post a strong deterrent to attack, something seldom seen in the digital domain. Conceptually I like the idea of being able to systemically respond to a threat, with different parts of the system reacting to different threats. On the threat detection side this makes sense as well, as many subtle attacks require information gathered from different parts of the system to be able to identify them. SEM/SIEM has slowly been advancing this science for some time now, and it is a core piece of the ADMP concept for web application security, where the detection and prevention is systemic. It is not the idea of a swam that makes it effective, but holistic detection in combination with multiple, different reactions by systems that can provide a meaningful response. So I am not saying ant swarming behavior applied to computer security is B.S., but “ramping up responses” is not the real problem – detection and appropriate reactions are. Share:

I get some priceless email on occasion, and I thought this one was too good not to pass along. Today’s Friday summary introduction is an anonymous guest post … if it missed any cliches I apologize in advance. Internal Memorandum To: Employees From: Mega-Corp Executive Team Subject: Messaging Data: Friday, September 25th, 2009 Due to growing media scrutiny and misquotes in major trade publication (because you people can’t get the pitch right), we ask you to be cautious in dealing with the press and analysts. Please. All we ask is that our employees “stay on message.” We, Mega-Corp, Inc., pay (way too much) to have (young imbecilic twits at) large advertising agencies (put down their drugs and alcohol long enough to) work closely with our (also over-paid) CMO to carefully develop media strategies to effectively leverage our assets to increase consumer awareness and increase sales, thus generating a win-win situation for all. We cannot allow rogue employees to torpedo our finely crafted multi-media approach by deviating from the platforms that have been developed. This will ensure that all of our clients receive the same message. It is also designed to increase brand awareness by striking just the right balance between being edgy enough to appeal to the hipper, young crowd while at the same time conveying stability to our long-term clients. It is especially important at the present, due to current market conditions. While our competitors are focused on their competitive disadvantages, we see this current market as a great opportunity for growth. Our marketing campaign has thus placed its emphasis on all of the added benefits that the new product line now offers. We will not allow iconoclastic employees to remain fixated on their complaints that we have increased prices. We believe that the new price line is a bargain for the new features that we have added, and our marketing campaign is designed to educate our clients and potential clients about the new features that they will be receiving. It does not help when our branch-office employees continuously snipe that the clients do not want the new features. That is only true because we have failed to educate them sufficiently about the benefits of those features. We are confident that if we all work together, to remain on message and educate our clients and potential clients about what we have to offer, we can expect double-digit growth over the next eight quarters. In do so we that our competitors will not be able to catch up to our technological advances during that period of time and thus we will not be forced to offer new products for the next 30 months. In fact, we are so confident of this that we have right-sized our R&D department, thus proving once again that we can be lean and mean. I also know that many of you have seen reports that suggest we plan further layoffs of up to 30%. We have no idea where the 30% figure came from and can say without equivocation that no such reduction is currently planned. Of course we will always remain nimble enough to provide reasonable value to our shareholders but I know that all of you believe that is our most sacred obligation and would want nothing less. In concluding, I cannot stress enough the importance of staying on message and delivering a united theme to the public as we continue to unveil our marketing strategy across so many different media platforms, including the new emphasis on social media. There can be no doubt that our innovative use of Twitter will in itself dramatically increase sales over the next several quarters. I look forward to seeing those who do remain with us next year when we gather via video-conferencing for the annual employee meeting. Thank you for your attention in this matter (or you will be part of the next 30%), Mega-Corp Executive Team The Death Star, Moon of Endor, Outer Rim And with that, on to the Friday Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian and Rich at BusinessWeek with the Truth, Lies, and Fiction with Data Encryption video. Rich and Martin on the Network Security Podcast, Episode 167. Oh Gn0es … I am having reservations about posting this, but it is Rich Mogull and David Mortman on stage at Defcon 17 Security Jam 2. Rich may panic and delete this link later so catch it while you can! Favorite Securosis Posts Rich: Cloud Data Security: Archive and Delete. Adrian: My post on Database Encryption Benchmarking. David Meier: So it’s not new, but I thought Building a Web Application Security program was the best internal post this week. David Mortman: Database Encryption Misconceptions. Other Securosis Posts A Bit on the State of Security Metrics Stupid FUD: Weird Nominum Interview Cloud Data Security: Share (Rough Cut) FCC Wants ‘Open Internet’ Rules for Wireless Incomplete Thought: Why Is Identity and Access Management Hard? Cloud Data Security: Use (Rough Cut) Favorite Outside Posts Adrian and Rich: We have never picked the same post before, but what Star Trek Predicts About the Future of Information Security is that good. It’s not every day bloggers get to geek out to the point we bring up “gold-pressed latinum”, or make security decisions based upon subjective personality assessments of violin-playing androids with cats. Very clever post. Meier: One word: ‘awesomesauce’. Mortman: Has Technology Killed Privacy? Top News and Posts New BeEF The best AES tutorial out there… in stick figures Remote exploits available for SMB2 vulnerability Microsoft workaround for the SMB vulnerability Bank sends mail to wrong Gmail address, then sues Google. Right, I’m sure that will work. Maybe they’ll have better luck if they spill hot Google on their lap. Great NAC white paper by Jennifer Jabbusch NSS runs a good malware test Free SSO for Google Apps? 4 Dangerous Myths about Data Disposal, Debunked talking points Why a hardware security model may not be as good as you think Blam! It was like patch Tuesday on a Wednesday for Cisco. Another reason to hate lawyers Netflix is smart. Very smart. Blog Comment of

Database benchmarking is hard to do. Any of you who followed the performance testing wars of the early 90’s, or the adoption and abuse of TPC-C and TPC-D, know that the accuracy of database performance testing is a long-standing sore point. With database encryption the same questions of how to measure performance rear their heads. But in this case there are no standards. That’s not to say the issue is not important to customers – it is. You tell a customer encryption will reduce throughput by 10% or more, and your meeting is over. End of discussion. Just the fear of potential performance issues has hindered the adoption of database encryption. This is why it is incredibly important for all vendors who offer encryption for databases (OS/file system encryption vendors, drive manufacturers, database vendors, etc.) to be able to say their impact is below 10%. Or as far below that number as they can. I am not sure where it came from, but it’s a mythical number in database circles. Throughout my career I have been doing database performance testing of one variety or another. Some times I have come up with a set of tests that I thought exercised the full extent of the system. Other times I created test cases to demonstrate high and low water marks of system performance. Sometimes I captured network traffic at a customer site as a guide, so I could rerun those sessions against the database to get a better understanding of real world performance. But it is never a general use case – it’s only an approximation for that customer, approximating their applications. When testing database encryption performance several variables come into play: What queries? Do users issue 50 select statements for every insert? Are the queries a balance of select, inserts, and deletes? Do I run the queries back to back as fast as I can, like a batch job, or do I introduce latency between requests to simulate end users? Do I select queries that only run against encrypted data, or all data? Generally when testing database performance, with or without encryption, we select a couple different query profiles to see what types of queries cause problems. I know from experience I can create a test case that will drop throughput by 1%, and another that will drop it by 40% (I actually had a junior programmer unknowingly design and deploy a query with a cartesian that crashed our live server instantly, but that’s another story). What type of encryption? Full disk? Tablespace? Column Level? Table level? Media? Each variant has advantages and disadvantages. Even if they are all using AES-256, there will be differences in performance. Some have hardware acceleration; some limit the total amount of encrypted data by partitioning data sets; others must contend for thread, memory, and processor resources. Column level encryption encrypts less data than full disk encryption, so this should be an apples to apples comparison. But if the encrypted column is used as an index, it can have a significant impact on query performance, mitigating the advantage. What percentage of queries are against encrypted data? Many customers have the ability to partition sensitive data to a database or tablespace that is much smaller than the overall data set. This means that many queries do not require encryption and decryption, and the percentage impact of encryption on these systems is generally quite good. It is not unreasonable to see that encryption only impacts the entire database by 1% over the entire database in a 24 hour period, while reduces throughput against the encrypted tablespace by 25%. What is the load on the system? Encryption algorithms are CPU intensive. They take some memory as well, but it’s CPU you need to pay attention to. With two identical databases, you can get different performance results if the load on one system is high. Sounds obvious, I know, but this is not quite as apparent as you might think. For example, I have seen several cases where the impact of encryption on transactional throughput was a mere 5%, but the CPU load grew by 40%. If the CPUs on the system do not have sufficient ‘headroom’, you will slow down encryption, overall read/write requests (both encrypted and unencrypted), and the system’s transactional throughput over time. Encryption’s direct slowdown of encrypted traffic is quite different than its impact on overall system load and general responsiveness. How many cryptographic operations can be accomplished during a day is irrelevant. How many cryptographic operations can be accomplished under peak usage during the day is a more important indicator. Resource consumption is not linear, and as you get closer to the limits of the platform, performance and throughput degrade and a greater than linear rate. How do you know what impact database encryption will have on your database? You don’t. Not until you test. There is simply no way for any vendor of a product to provide a universal test case. You need to test with cases that represent your environment. You will see numbers published, and they may be accurate, but they seldom reflect your environment and are so are generally useless. Share:

I have not been blogging much this week, as I have been up to my eyeballs in a couple different research projects. But as with any research effort, I always learn a lot and it alters my perceptions and recommendations on the security subjects I cover. Sometimes the revelations are not revelatory at all, but because I misunderstood the vendor solution (d’oh!), or I was unable to keep pace with the continuous advancements across the 125+ vendors I attempt to track. Regardless, I wanted to share a couple observations concerning database encryption I think are worth mentioning. Misconception #1: Microsoft’s Approach to Database Encryption I believed Microsoft wanted SQL Server to leverage BitLocker and the associated Encrypted File System (EFS). It seemed to me that their strategy was going to be similar to what IBM does with Vormetic: leveraging a generic file system encryption system to secure both database and generic files on disk. They have lots invested in the OS, so why not? Looking at SQL Server 2008, that really does not seem to be the focus – instead Transparent Database Encryption, performed at the block level, is the preferred method for database encryption. Block level encryption is pretty fast, and as it is applied to all the data files, you cannot accidently miss one and leave data exposed. This option seems more appropriate for compliance, as you are moving key management and encryption policy decisions out of IT and into the database. In practice this may be academic, but it’s easier and offers less room for mistakes. All told, that can be the difference in making an auditor happy. If you look at the SQL Server portfolio of encryption options, they offer the API level ‘cell encryption’, block level TDE, and BitLocker OS level encryption. Coupled with the DPAPI key manager, this means Microsoft’s approach is closer to Oracle’s, with their corresponding dbms_crypto API, block level Tablespace Transparent Encryption (TTE or TDE depending on your reference), wallet key manager, and column level TDE that provides intra-block protection. It’s not surprising that IBM focuses more on storage, Microsoft more on the OS, and Oracle on the application layer, but Oracle and Microsoft now have more similarities than differences. Misconception #2: Oracle Key Management I have been known to lock myself in a server lab for a week or more, testing a product every which way, until I am confident I know how a product works. Blue fingered and frozen, I emerge with knowledge of how a product stands up to its competition and how it solves customer problems. I did this with Oracle 10G encryption a few years ago, and came away with the impression that is was very easy to use, with more than acceptable performance, but storing the keys in the database remains an issue. I seem to remember the keys being stored raw in the systems tables. What shocked me is that I learned that the external key server (what Oracle calls a ‘wallet’), is mandatory, not optional. This means that all the keys stored in the database are encrypted by the master key stored in the wallet. I have absolutely no recollection of that being the case, and while I vividly remember setting up keys, I have no memory of installing, configuring or using a wallet. Maybe I had a beta version – who knows? But I was so shocked by this I asked Rich if he knew about it and he said ‘no’. So if both of us can totally misunderstand this requirement, it’s a fair bet others have as well. The wallet as a required external key management service is important, as it encrypt the keys used to encrypt / decrypt data within the database. Encryption by a master key external to the database makes it virtually impossible for the DBA to get the keys, as they are not sitting around in cleartext on disk. Accessing the master key is a process between the database and the wallet, where the database must securely authenticate itself before it can be provided the master key it needs to decrypt data encryption keys. The master key is in turn secured in the wallet through RSA’s PKCS #5 v2.0 secure password methodology, so the master key never resides in the clear on disk either. You need to make sure the wallet is properly secured and backed up, but these minor management tasks pale in comparison to the extra key security provided. I am happy to be wrong as this is a really solid security choice on their part. Misconception #3: Application Level Security I have been saying for years, rather emphatically, that application level encryption is more secure that database encryption. You have the flexibility of what data to encrypt, external key management, the ability to decouple keys from access controls, certificate verification, and the option to double encrypt for certain types of workflow and policy enforcement. While this came at great expense in development time, you at least had the option to be as secure as you needed to be. With the database vendors offering external key managers or even hardware security modules, key hierarchies, and more flexible application of encryption, the gap has closed. While I still believe that the application level can offer a small degree of added security depending upon how well the implementation is done, it’s now splitting hairs. Compromising key security, undermining the cryptography, gaining access to keys in memory, or any attack is going to be pretty much the same regardless of the solution. The database is no longer really easier to hack, as many of the common ways to subvert the system have since been closed. Do I still think that application level encryption is a bit better than database level encryption? Yes, but only because of what’s possible, and not because of inherent design issuess with the approaches database vendors took. Share:

Well, this is interesting: the FCC Chairman announced that they do not believe wireless carriers should be able to block certain types of Internet traffic, according to the AP release a few hours ago. The thrust of the comments seems to be that they want to extend Internet usage rights over the wireless carrier networks. The chairman is now proposing to make it a formal rule that Internet carriers cannot discriminate against certain types of traffic by degrading service. That expands on the principle that they cannot “block” traffic, as articulated in a 2005 policy statement. It’s unclear how the rules would apply in practice to wireless data. For instance, carriers officially restrict how Internet-access cards for laptops are used, but rarely enforce the rules. The government also has been investigating Apple Inc.’s approval process for iPhone applications, but Genachowski isn’t directly addressing manufacturers’ right to determine which applications run on their phones. It does highlight that if you can control the applications used (available) on the devices, you can in turn control the content. Unless of course you break the protection on the phone. But still, this would appear to put the handset providers in the driver’s seat as far as what applications are acceptable. How long will it be before the carriers try to dictate acceptable applications when they negotiate deals? How will the carriers attempt to protect their turf and their investment? Could users say “screw both of you” and encrypt all of their traffic? Personally I like the idea, as it does foster invention and creativity outside the rigorous use models the carriers and phone providers support today. This is going to be a complex and dynamic struggle for the foreseeable future. Share:

Last week, a friend loaned me his copy of Emergency, by Neil Strauss, and I couldn’t put it down. It’s a non-fiction book about the author’s slow transformation from wussy city dweller to full-on survival and disaster expert. And I mean full on; we’re talking everything from normal disaster preparedness, to extensive training in weapons, wilderness and urban survival, developing escape routes from his home to other countries, planting food and fuel caches, and gaining dual citizenship… “just in case”. There’s even a bit with a goat, but not in the humorous/deviant way. I’ve never considered myself a survivalist, although I’ve had extensive survival training and experience as part of my various activities. When you tend to run towards disasters, or engage in high risk sports, it’s only prudent to get a little extra training and keep a few spare bags of gear and supplies around. After I got back from helping out with the Hurricane Katrina response I went through a bit of a freak out moment when I realized all my disaster plans were no longer effective. When I was single in Boulder I didn’t really have to worry much – as a member of the local response infrastructure, I wouldn’t be sitting at home if anything serious happened. I kept the usual 3-day supply of food and water, not that I expected to need it (since I’d be in the field), and my camping/rescue gear would take care of the rest. I lived well above the flood-line, and only had to grab a few personal items and papers in case of a fire. By the time I deployed to Katrina I was living in a different state with a wife (well, almost, at the time), pets, and an extended family who weren’t prepared themselves. The biggest change of all was that I was no longer part of the local response infrastructure – losing access to all of the resources I’d grown used to having available. The only agency I still worked for was based hundreds of miles away in Denver. Oops. Needless to say the complexities of planning for a family with children, pets, and in-laws is far different than holing up in the mountains for a few days. Seriously, do you know how hard it is to plan on bugging out with cats who don’t get along? (Yes, of course I’m taking them – I care more about my cats than I do about most people). I still don’t feel fully prepared, although the range of disasters we face in Phoenix is smaller than Colorado. I fully recognize the odds of me ever needing any of my disaster plans are slim to none, but I’ve been involved in far too many real situations to think the effort and costs aren’t worth it. Nearly all of the corporate disaster planning I’ve seen is absolute garbage (IT or otherwise). The drills are scripted, the plans fatally flawed, and the people running them are idiots who took a 2 day class and have no practical experience. If you have a plan that hasn’t been practiced under realistic conditions on a regular basis, there’s no chance it will work. Oh – and most of the H1N1 advice out there is rubbish. Just tell sick people to stay home at the first sign of a fever, and don’t count it against their vacation hours. Anyway, I highly recommend the book. It’s an amusing read with a good storyline and excellent information. And a goat. With that, it’s time for our weekly update: -Rich Webcasts, Podcasts, Outside Writing, and Conferences Rich and Adrian presented at the Data Protection Decisions in DC. Rich had a full schedule with “Understanding and Selecting a DLP Solution”, “Understanding and Selecting a Database Activity Monitoring Solution”, “and Pragmatic Data Security”. Adrian got to lounge around after presenting “Truth, Lies and Fiction about Encryption”. We’ll be doing another one in Atlanta on November 19th. Rich was quoted in SC Magazine on the acquisition of Vericept by Trustwave. Don’t forget that you can subscribe to the Friday Summary via email. Favorite Securosis Posts Rich: Adrian’s new definition: Vendor Myopia Adrian: Going back in time as it was lost in the shuffle: Format and Datatype Preserving Encryption Mortman: XML Security Overview Meier: Cloud Data Security: Store (Rough Cut). Just read it! Other Securosis Posts Google and Micropayment There Are No Trusted Sites: New York Times Edition Project Quant Posts Raw Project Quant Survey Results Favorite Outside Posts Adrian: Top security risks, per SANS. Rich: Dancho’s Ultimate Guide to Scareware. Meier: Everything (and then some) you wanted to know about Zeus/Zbot. Mortman: Not strictly a security post, but this post talks about the general reactions that many of us have to dealing with new technologies or regulations. Top News and Posts Intelligence Analyst charged with hacking. C’mon, it’s just research! Tenable Nessus 4.0.2 released. RBS WorldPay hacked: full database access. Remote Exploit Released for Vista SMB2 Vulnerability. The New School of Information Security requests performance data from the federal government. Drive-by power grid takedown. Lovely. Blog Comment of the Week This week’s best comment comes from Dave in response to Format and Data Preserving Encryption: Ok, First let me start out by admitting I am almost entirely wrong 😉 Now we have that out of the way… I was correct in asserting the resulting reduced cypher is no more secure than a native cypher of that blocksize, but failed to add that the native cypher must have the same keyspace size as the cypher being reduced – for this reason, DES was a bad example (but 128 bit DESX, which is xor(k1,DES(k2,XOR(k1,Plaintext))) would be a good one. I was in error however asserting that, in practical terms, this in any way matters – in fact, the size of the keyspace (not the blocksize) is the overwhelming factor due to the physical size of another space – the space of all possible mappings that could result from the key schedule. it is

As part of the interview process for our intern program, we asked candidates to prepare a couple slides and write a short blog post on a technical subject. Rich and I debated different subjects for the candidates to research and report on, but we both chose “XML Security”. It is a very broad subject that gave the candidates some latitude, and there was not too much research out there to read up on. It also happened to be a subject that neither Rich nor I had researched prior to the interviews. We did not want to bring biases to the subject, and we wanted to focus on presentation rather than content, to see where the candidates led us. This was not to be a full-blown research effort where we expected the candidate to take a month to dig into the subject, but rather meant a cursory effort to identify the highlights. We figured it would take between 2-10 hours depending upon the candidate’s background. Listening to the presentations by the candidates was fun as we had no idea what they would focus on or what viewpoint they would present. Each brought a different vision of what constituted XML security. Some focused on one aspect of the problem space, such as web security. Some provided an academic overview of XML issues, while others offered depth on seemingly random aspects. All of the presentation were different from each other, and far different than what I would have created, plus some of their statements were counter to my understanding of XML security issues. But the quality of the research was not really what was important – rather how they approached the task and communicated their findings. I cannot share those with you, but I found the subject interesting enough that I thought Securosis should provide some coverage on this topic, so I decided to go through the process myself. The slide deck is in the research library for you to check out if it interests you. It’s not comprehensive, but I think it covers the basics. I probably would come in second if I had been part of the competition, so it’s lucky I have already been vetted. Per my Friday Summary comment, I may learn more from this process than the interns! Share: